Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.maint.python > #11218

Re: Numpy migration?

Show key headers only | View raw

[Multipart message — attachments visible in raw view] - view raw

Hi Mattia, all,

On 07-01-2019 17:20, Mattia Rizzolo wrote:
> On Mon, Jan 07, 2019 at 09:03:11AM +0100, Ole Streicher wrote:
>> Mattia Rizzolo <mattia@debian.org> writes:
>>> On Sun, Jan 06, 2019 at 05:07:41PM +0100, Ole Streicher wrote:
>>>> Now it turns out that there is a new migration problem, which is aplpy:
>>>> Current aplpy (2.0~rc2-2) CI test works well
>>>
>>> You probably mean aplpy 1.1.1-4.
>>
>> No, I meant the one above (although the unstable test was not done on
>> ci.d.n when I wrote my last mail).
> 
> Right, that explains why I didn't see it.
> It seems now britney is triggering aplpy test with a big set of
> triggers (I suppose the result of the several Breaks that have been
> added in the meantime), so it's indeed trying to move everything
> together.

Indeed.

>> The problem is that aplpy uses matplotlib, and the old matplotlib uses
>> the deprecated numpy function np.asscalar(), which leads to a
>> DeprecationWarning, which is (on purpose, by upstream) thrown as error.
>>
>> https://ci.debian.net/data/autopkgtest/testing/amd64/a/aplpy/1658948/log.gz
>>
>> This does only happen in the combination "new numpy + old matplotlib",
>> but this is the one that is tested for the CI test.
> 
> mhh… for this, indeed a breaks numpy -> matplotlib could be used, but it
> feels a bit too strong to me, as nothing was really broken since it's
> just deprecations.
> 
> elbrus; this is a case where I think I could use your input (tl;dr: new
> numpy causes deprecations in testing's version of matplotlib (fixed in
> unstable), which in turn causes failures in new aplpy, how to make the
> stack happy?).

The commit, with lots of comments [1], that implemented most of the
related logic is here:
https://salsa.debian.org/release-team/britney2/commit/18633e275c34973379f1426542047bf30c7829c3

With the current code your options are:
- *versioned* depends on one of the binary packages from the source you
want from unstable in any of the binary packages that is going to be
taken from unstable
- *versioned* breaks or conflicts on the binary packages from the source
you want from unstable in any of the binary packages that is going to be
taken from unstable
- *versioned* test dependency in the package that is used for
autopkgtest (only helps if the version that is tested is already taken
from unstable). The version of the test dependency will NOT be added to
the triggers (maybe, I have to think about it, that could be an britney
improvement), but if the version of the autopktest is going to be taken
from unstable already due to other considerations, with the current
settings of ci.d.n and autopkgtest the required version will be installed.

Personally I don't think it is an issue to add the breaks, but I can see
why people find it heavy in cases like this one.

As discussed in the med-fichier bug, britney may want to grow knowledge
from a X-breaks-autopkgtest-of-source header, but that doesn't exist now
and I am not extremely keen about adding it because I fear people may
too easily add it when a normal breaks is in order.

Paul

[1]
+        # Here we figure out what is required from the source suite
+        # for the test to install successfully.
+        #
+        # Loop over all binary packages from trigger and
+        # recursively look up which *versioned* dependencies are
+        # only satisfied in the source suite.
+        #
+        # For all binaries found, look up which packages they
+        # break/conflict with in the target suite, but not in the
+        # source suite. The main reason to do this is to cover test
+        # dependencies, so we will check Testsuite-Triggers as
+        # well.
+        #
+        # OI: do we need to do the first check in a smart way
+        # (i.e. only for the packages that are actully going to be
+        # installed) for the breaks/conflicts set as well, i.e. do
+        # we need to check if any of the packages that we now
+        # enforce being from the source suite, actually have new
+        # versioned depends and new breaks/conflicts.
+        #
+        # For all binaries found, add the set of unique source
+        # packages to the list of triggers.

Back to linux.debian.maint.python | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Numpy migration? Ole Streicher <olebole@debian.org> - 2019-01-05 15:20 +0100
  Re: Numpy migration? Mattia Rizzolo <mattia@debian.org> - 2019-01-05 15:40 +0100
    Re: Numpy migration? Ole Streicher <olebole@debian.org> - 2019-01-05 16:20 +0100
      Re: Numpy migration? Mattia Rizzolo <mattia@debian.org> - 2019-01-05 16:40 +0100
        Re: Numpy migration? Ole Streicher <olebole@debian.org> - 2019-01-05 20:50 +0100
          Re: Numpy migration? Scott Kitterman <debian@kitterman.com> - 2019-01-05 21:00 +0100
          Re: Numpy migration? Mattia Rizzolo <mattia@debian.org> - 2019-01-06 01:40 +0100
            Re: Numpy migration? Ole Streicher <olebole@debian.org> - 2019-01-06 17:30 +0100
              Re: Numpy migration? Steffen Möller <steffen_moeller@gmx.de> - 2019-01-06 18:20 +0100
                Re: Numpy migration? Mattia Rizzolo <mattia@debian.org> - 2019-01-06 18:50 +0100
              Re: Numpy migration? Mattia Rizzolo <mattia@debian.org> - 2019-01-06 19:00 +0100
                Re: Numpy migration? Ole Streicher <olebole@debian.org> - 2019-01-07 09:30 +0100
                Re: Numpy migration? Mattia Rizzolo <mattia@debian.org> - 2019-01-07 17:30 +0100
                Re: Numpy migration? Ole Streicher <olebole@debian.org> - 2019-01-07 18:10 +0100
                Re: Numpy migration? Paul Gevers <elbrus@debian.org> - 2019-01-07 21:10 +0100
    Re: Numpy migration? Ole Streicher <olebole@debian.org> - 2019-01-05 16:40 +0100
      Re: Numpy migration? Mattia Rizzolo <mattia@debian.org> - 2019-01-05 16:50 +0100

csiph-web