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.
Attachment:
signature.asc
Description: OpenPGP digital signature