i just reply-all, so gmail will set To to the original from - all these msgs are meant for the involved packages maintainer
Paul, maybe you should use a service email address instead of your own for these reports? On Sat, May 12, 2018 at 3:41 PM Paul Gevers <[email protected]> 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 > >> ============ > > > > > > -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi G+: https://plus.google.com/u/0/+SandroTosi _______________________________________________ Python-modules-team mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team
