New version of numexpr breaks autopkgtests of pytables in testing

Sandro Tosi morph at debian.org
Sat May 12 20:12:22 BST 2018


On Sat, May 12, 2018 at 9:12 AM Paul Gevers <elbrus at debian.org> wrote:

> Hi Frederic-Emmanuel,

> On 12-05-18 10:53, PICCA Frederic-Emmanuel wrote:
> > It seems to me that the real culprite is python-numpy.

> I agree. All errors are like:
> ======================================================================
> ERROR: test06_attributes
> (tables.tests.test_tables.RecArrayThreeWriteTestCase)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>    File "/usr/lib/python2.7/dist-packages/tables/tests/test_tables.py",
> line 138, in setUp
>      self.populateFile()
>    File "/usr/lib/python2.7/dist-packages/tables/tests/test_tables.py",
> line 213, in populateFile
>      self.initRecArray()
>    File "/usr/lib/python2.7/dist-packages/tables/tests/test_tables.py",
> line 207, in initRecArray
>      shape=self.expectedrows)
>    File "/usr/lib/python2.7/dist-packages/numpy/core/records.py", line
> 847, in array
>      return fromrecords(obj, dtype=dtype, shape=shape, **kwds)
>    File "/usr/lib/python2.7/dist-packages/numpy/core/records.py", line
> 708, in fromrecords
>      retval = sb.array(recList, dtype=descr)
> TypeError: a float is required

> But is this an issue that:
> 1) just means the autopkgtests of pytables need updating as this is a
>     corner-case use and python-numpy has been warning for this change for
>     years?

it could be, but we dont track super-closely every numpy release, so some
deprecation warnings may have been missed. do we have historical
autopkgtests logs to check?

i would file a bug on pytables upstream issue tracker and ask to make it
compatible with a more recent numpy

> 2) means that pytables is now unusable at all and needs adaptations for
>     the new situation (python-numpy should add a proper "Breaks"
>     relation)
> 3) python-numpy should be updated to add a grace period for this use
>     case as they dropped this support suddenly and the use is very common
>     (RC bug for python-numpy as it shouldn't migrate to testing)
> 4) means something else.

> Please add your thoughts.

> Paul
> ________________________________________
> > De : debian-science-maintainers
[debian-science-maintainers-bounces+picca=
synchrotron-soleil.fr at alioth-lists.debian.net] de la part de Paul Gevers [
elbrus at debian.org]
> > Envoyé : samedi 12 mai 2018 10:10
> > À : numexpr at packages.debian.org; pytables at packages.debian.org
> > Cc : Paul Gevers
> > Objet : New version of numexpr breaks autopkgtests of pytables in
testing
> >
> > 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 numexpr the autopkgtest of pytables
> > started to fail in testing [2]. This is currently delaying the migration
> > of numexpr version 2.6.5-1 [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/pytables/testing/amd64/
> > [3] https://qa.debian.org/excuses.php?package=numexpr
> > [4] https://wiki.debian.org/ContinuousIntegration/TriagingTips
> > [5] #debci on oftc or debian-ci at lists.debian.org
> > [6] numexpr has an issue
> > ============
> > Source: numexpr
> > Version: 2.6.5-1
> > Severity: normal or higher
> > Control: affects -1 src:pytables
> > User: debian-ci at lists.debian.org
> > Usertags: breaks
> > ============
> > [7] pytables has an issue
> > ============
> > Source: pytables
> > Version: 3.4.3-1
> > Severity: normal or higher
> > Control: affects -1 src:numexpr
> > User: debian-ci at lists.debian.org
> > Usertags: needs-update
> > ============
> >
> > --
> > debian-science-maintainers mailing list
> > debian-science-maintainers at alioth-lists.debian.net
> >
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
> >



-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
G+: https://plus.google.com/u/0/+SandroTosi



More information about the debian-science-maintainers mailing list