[Python-modules-team] New version of python-numpy breaks autopkgtests of python-scipy in testing

[Sandro Tosi]

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 <elbrus at debian.org> 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 <elbrus at debian.org> 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 debian-ci at lists.debian.org
> >> [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: debian-ci at lists.debian.org
> >> 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: debian-ci at lists.debian.org
> >> 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