I'll look into it tomorrow, scipy is due for an update anyway. On 12.05.2018 21:41, Paul Gevers wrote: > Hi Sandro, > > On 12-05-18 21:29, Sandro Tosi wrote: >> the np.random.dirichlet errors seem a bug in how scipy calls that function: >> https://docs.scipy.org/doc/numpy-1.14.0/reference/generated/numpy.random.dirichlet.html > > Can you file a bug against python-scipy for this then? > >> the other issues with numerical values are hard to understand from my POV - >> can you get upstream involved? > > Not me, but I hope some of the people in my original TO. I have no > knowledge at all about these python packages or their upstream, that is > why I sent out the mail to start with. > > Paul > >> On Tue, May 8, 2018 at 1:51 PM Paul Gevers <[email protected]> wrote: >> >>> Dear maintainers, >> >>> [This e-mail is automatically sent. V2 (20180508)] >> >>> As recently announced [1] Debian is now running autopkgtests in testing >>> to check if the migration of a new source package causes regressions. It >>> does this with the binary packages of the new version of the source >>> package from unstable. >> >>> With a recent upload of python-numpy the autopkgtest of python-scipy >>> started to fail in testing [2]. This is currently delaying the migration >>> of python-numpy version 1:1.14.3-2 [3]. >> >>> This e-mail is meant to trigger prompt direct communication between the >>> maintainers of the involved packages as one party has insight in what >>> changed and the other party insight in what is being tested. Please >>> therefore get in touch with each other with your ideas about what the >>> causes of the problem might be, proposed patches, etc. A regression in a >>> reverse dependency can be due to one of the following reasons (of course >>> not complete): >>> * new bug in the candidate package (fix the package) >>> * bug in the test case that only gets triggered due to the update (fix >>> the reverse dependency, but see below) >>> * out-of-date reference date in the test case that captures a former bug >>> in the candidate package (fix the reverse dependency, but see below) >>> * deprecation of functionality that is used in the reverse dependency >>> and/or its test case (discussion needed) >>> Triaging tips are being collected on the Debian Wiki [4]. >> >>> Unfortunately sometimes a regression is only intermittent. Ideally this >>> should be fixed, but it may be OK to just have the autopkgtest retried >>> (a link is available in the excuses [3]). >> >>> There are cases where it is required to have multiple packages migrate >>> together to have the test cases pass, e.g. when there was a bug in a >>> regressing test case of a reverse dependency and that got fixed. In that >>> case the test cases need to be triggered with both packages from >>> unstable (reply to this e-mail and/or contact the ci-team [5]) or just >>> wait until the aging time is over (if the fixed reverse dependency >>> migrates before that time, the failed test can be retriggered [3]). >> >>> Of course no system is perfect. In case a framework issue is suspected, >>> don't hesitate to raise the issue via BTS or to the ci-team [5] (reply to >>> me is also fine for initial cross-check). >> >>> To avoid stepping on peoples toes, this e-mail does not automatically >>> generate a bug in the BTS, but it is highly recommended to forward this >>> e-mail there (psuedo-header boilerplate below [6,7]) in case it is >>> clear which package should solve this regression. >> >>> It can be appropriate to file an RC bug against the depended-on package, >>> if the regression amounts to an RC bug in the depending package, and to >>> keep it open while the matter is investigated. That will prevent >>> migration of an RC regression. >> >>> If the maintainers of the depending package don't have available effort >>> to fix a problem, it is appropriate for the maintainers of the >>> depended-on package to consider an NMU of the depending package. Any >>> such an NMU should take place in accordance with the normal NMU rules. >> >>> Neither of the above steps should be seen as hostile; they are part of >>> trying to work together to keep Debian in tip-top shape. >> >>> If you find that you are not able to agree between you about the right >>> next steps, bug severities, etc., please try to find a neutral third >>> party to help you mediate and/or provide a third opinion. Failing that >>> your best bet is probably to post to debian-devel. >> >>> [1] https://lists.debian.org/debian-devel-announce/2018/05/msg00001.html >>> [2] https://ci.debian.net/packages/p/python-scipy/testing/amd64/ >>> [3] https://qa.debian.org/excuses.php?package=python-numpy >>> [4] https://wiki.debian.org/ContinuousIntegration/TriagingTips >>> [5] #debci on oftc or [email protected] >>> [6] python-numpy has an issue >>> ============ >>> Source: python-numpy >>> Version: 1:1.14.3-2 >>> Severity: normal or higher >>> Control: affects -1 src:python-scipy >>> User: [email protected] >>> Usertags: breaks >>> ============ >>> [7] python-scipy has an issue >>> ============ >>> Source: python-scipy >>> Version: 0.19.1-2 >>> Severity: normal or higher >>> Control: affects -1 src:python-numpy >>> User: [email protected] >>> Usertags: needs-update >>> ============ >> >> >> >
_______________________________________________ Python-modules-team mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team
