Re: Numpy migration?
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 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. signature.asc Description: OpenPGP digital signature
Re: Numpy migration?
Mattia Rizzolo writes: > On Mon, Jan 07, 2019 at 09:03:11AM +0100, Ole Streicher wrote: >> 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?). BTW, same is true for astropy-healpix and pyregion (both not maintained by me). Just to shorten the list of relevant CI failures. Cheers Ole
Re: Numpy migration?
Mattia Rizzolo 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). >> - with numpy-1.15.4-2 (testing) and matplotlib-2.2.2-4 (testing), >> - with numpy-1.16.0~rc2-1 (unstable) and matplotlib-3.0.2-2 (unstable). >> >> However it does not work well when combining numpy-1.16.0~rc2 (unstable) >> and matplotlib-2.2.2-4 (testing), which is the combination that is >> tested for migration of numpy. Needless to say that matplotlib migrates >> only after numpy. What should one do here? Declaring another >> "Breaks: matplotlib (<< 3.0)" in numpy? > > Well, to me it seems it's python3-astropy that is missing a dependency > on python3-skimage there, to be honest: > |> from skimage.measure import block_reduce > |E ModuleNotFoundError: No module named 'skimage' > | > |/usr/lib/python3/dist-packages/astropy/nddata/utils.py:370: > ModuleNotFoundError > > However I wouldn't be able to tell you why it would pass with numpy and > matplotlib from unstable, given that neither pulls in skimage… astropy needs askimage only in some cases, so it is (should be) a suggestion and not a recommendation. aplpy is however one of these cases -- but this is not the problem here, since aplpy 2.0~rc2-2 has skimage in its test dependency. 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. best Ole
Re: Numpy migration?
On Sun, Jan 06, 2019 at 06:19:15PM +0100, Steffen Möller wrote: > > The reverse build deps of python-astropy in testing are pyregion and > > veusz. Veusz has the build-dep removed in unstable, but didn't migrate > > since 192 days. > This is because it does not build on arm64 and others > (https://buildd.debian.org/status/fetch.php?pkg=veusz=arm64=3.0-1=1530124204=0) > - also because of some Numpy issue if I get this right: Looks so indeed. However it builds on reproducible (on arm64), and the error is the same on mips and mips64el, so I asked for the build to be retried. However there is after that a different RC bug (that I can fix once the build is confirmed to be fixed as well). -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: Numpy migration?
On 06.01.19 17:07, Ole Streicher wrote:
Mattia Rizzolo writes:
On Sat, Jan 05, 2019 at 08:30:28PM +0100, Ole Streicher wrote:
This would remove one dependent party (release team) from the chain of
blocking causes for the migration.
Given your email on -mentors a few minutes ago I see there are troubles
on removing python-astropy from unstable (I'll reply to that in a bit),
but for testing is quite easy.
Just file a bug against release.debian.org asking to remove it from
testing, and one against python-astropy at RC-level with "not release
with buster", and it will be out of testing beofore you even notice.
The reverse build deps of python-astropy in testing are pyregion and
veusz. Veusz has the build-dep removed in unstable, but didn't migrate
since 192 days.
This is because it does not build on arm64 and others
(https://buildd.debian.org/status/fetch.php?pkg=veusz=arm64=3.0-1=1530124204=0)
- also because of some Numpy issue if I get this right:
dpkg-buildpackage
-
dpkg-buildpackage: info: source package veusz
dpkg-buildpackage: info: source version 3.0-1
dpkg-buildpackage: info: source distribution unstable
dpkg-source --before-build veusz-3.0
dpkg-buildpackage: info: host architecture arm64
fakeroot debian/rules clean
dh clean --with python3,sphinxdoc --buildsystem=pybuild
dh_auto_clean -O--buildsystem=pybuild
I: pybuild base:217: python3.7 setup.py clean
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/numpy/core/__init__.py", line 16, in
from . import multiarray
ImportError: cannot import name 'multiarray' from 'numpy.core'
(/usr/lib/python3/dist-packages/numpy/core/__init__.py)
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "setup.py", line 31, in
import numpy
File "/usr/lib/python3/dist-packages/numpy/__init__.py", line 142, in
from . import add_newdocs
File "/usr/lib/python3/dist-packages/numpy/add_newdocs.py", line 13, in
from numpy.lib import add_newdoc
File "/usr/lib/python3/dist-packages/numpy/lib/__init__.py", line 8, in
from .type_check import *
File "/usr/lib/python3/dist-packages/numpy/lib/type_check.py", line 11, in
import numpy.core.numeric as _nx
File "/usr/lib/python3/dist-packages/numpy/core/__init__.py", line 26, in
raise ImportError(msg)
ImportError:
Importing the multiarray numpy extension module failed. Most
likely you are trying to import a failed build of numpy.
If you're working with a numpy git repo, try `git clean -xdf` (removes all
files not under version control). Otherwise reinstall numpy.
Original error was: cannot import name 'multiarray' from 'numpy.core'
(/usr/lib/python3/dist-packages/numpy/core/__init__.py)
E: pybuild pybuild:336: clean: plugin distutils failed with: exit code=1:
python3.7 setup.py clean
dh_auto_clean: pybuild --clean -i python{version} -p "3.7 3.6" returned exit
code 13
debian/rules:22: recipe for target 'clean' failed
make: *** [clean] Error 25
dpkg-buildpackage: error: fakeroot debian/rules clean subprocess returned exit
status 2
Build finished at 2018-06-27T18:29:58Z
Finished
Re: Numpy migration?
Mattia Rizzolo writes: > On Sat, Jan 05, 2019 at 08:30:28PM +0100, Ole Streicher wrote: >> This would remove one dependent party (release team) from the chain of >> blocking causes for the migration. > > Given your email on -mentors a few minutes ago I see there are troubles > on removing python-astropy from unstable (I'll reply to that in a bit), > but for testing is quite easy. > Just file a bug against release.debian.org asking to remove it from > testing, and one against python-astropy at RC-level with "not release > with buster", and it will be out of testing beofore you even notice. The reverse build deps of python-astropy in testing are pyregion and veusz. Veusz has the build-dep removed in unstable, but didn't migrate since 192 days. Pyregion just got an upload with a fix, but will probably only migrate after numpy (which will not migrate until python-astropy is removed). Now it turns out that there is a new migration problem, which is aplpy: Current aplpy (2.0~rc2-2) CI test works well - with numpy-1.15.4-2 (testing) and matplotlib-2.2.2-4 (testing), - with numpy-1.16.0~rc2-1 (unstable) and matplotlib-3.0.2-2 (unstable). However it does not work well when combining numpy-1.16.0~rc2 (unstable) and matplotlib-2.2.2-4 (testing), which is the combination that is tested for migration of numpy. Needless to say that matplotlib migrates only after numpy. What should one do here? Declaring another "Breaks: matplotlib (<< 3.0)" in numpy? Best Ole
Re: Numpy migration?
On Sat, Jan 05, 2019 at 08:30:28PM +0100, Ole Streicher wrote: > >> Python-astropy is however going to be removed completely; it has > >> however some cruft rdeps left in unstable. So, it cannot removed from > >> unstable now, and therefore still remains in testing and > >> (unnecessarily) blocks the numpy migration. Python-astropy already > >> has an RC bug, but its autoremoval from testing is still not even > >> announced yet. > > > > Maybe you could ask the release team to hasten the removal of > > python-astropy and rdeps from testing? If the plan is to not relase > > it in buster I don't see a reason to keep it further. > > Couldn't we just also add a "breaks" to numpy? The important fact here > is, that the new numpy and the current python-astropy don't work > together; and this is independent of whether a fixed python-astropy > version exists. That wouldn't quite work, as without a working version of python-astropy it would unilateraly block the migration of numpy as long as python-astropy is in testing. > This would remove one dependent party (release team) from the chain of > blocking causes for the migration. Given your email on -mentors a few minutes ago I see there are troubles on removing python-astropy from unstable (I'll reply to that in a bit), but for testing is quite easy. Just file a bug against release.debian.org asking to remove it from testing, and one against python-astropy at RC-level with "not release with buster", and it will be out of testing beofore you even notice. > >> The migration blocking CI tests seem to cause much more headaches than > >> just "fix your bugs"... > > > > Well, from what I see, it has helped a lot in this half a year detect a > > ton of regressions that would have otherwise bothered several people in > > a later moment… > > I usually regularly look into my packages and file bugs if a CI test > fails caused by a buggy updated dependency. This works well without the > need of blocks. It would also work, when a failing CI test would > automatically trigger a bug report against the updated package, which > then could be re-assigned to the rdep in case the problem was there. There is elbrus that does that regularly (Except these last few weeks when it was on vaction). I think he said complete automation would miss too many things that he is filtering out by hand for now. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: Numpy migration?
On Saturday, January 05, 2019 08:30:28 PM Ole Streicher wrote: > Mattia Rizzolo writes: > > On Sat, Jan 05, 2019 at 04:02:35PM +0100, Ole Streicher wrote: > >> I'll do tonight. It however looks a bit suboptimal: when the CI test > >> with a new version fails for an old reverse dependency, then the new > >> version obviously breaks that old package. So, the breakage could be > >> detected (and taken into account) automatically. Why do we need a manual > >> action then? > > > > Let me try to suggest you see from another side: the goal of the Breaks > > field is to prevent a given combination of known broken packages to be > > installed. > > Currently autopkgtest blocks the migration of numpy, but if there wasn't > > that block a Breaks should still be added, as the astropy in testing is > > not compatible with the new numpy. The fact that it hints britney to > > trigger the right tests is just a "side effects", the Breaks should be > > added nonetheless, theoretically; in practice, we rarely did it before > > autopkgtest started blocking the testing migration. > > I agree (with the explanation in your other mail) here; it just states > the fact that they really don't go together very well (at least in > situation similar to the specific CI test). For what it's worth, I hit (AIUI) the same situation when I updated python- bleach. It broke python-readme-renderer. I reuploaded python-bleach with the breaks and a new version of python-readme-renderer (which worked with the new bleach) and both migrated two days later (since they both had autopkgtests). Scott K
Re: Numpy migration?
Mattia Rizzolo writes: > On Sat, Jan 05, 2019 at 04:02:35PM +0100, Ole Streicher wrote: >> I'll do tonight. It however looks a bit suboptimal: when the CI test >> with a new version fails for an old reverse dependency, then the new >> version obviously breaks that old package. So, the breakage could be >> detected (and taken into account) automatically. Why do we need a manual >> action then? > > Let me try to suggest you see from another side: the goal of the Breaks > field is to prevent a given combination of known broken packages to be > installed. > Currently autopkgtest blocks the migration of numpy, but if there wasn't > that block a Breaks should still be added, as the astropy in testing is > not compatible with the new numpy. The fact that it hints britney to > trigger the right tests is just a "side effects", the Breaks should be > added nonetheless, theoretically; in practice, we rarely did it before > autopkgtest started blocking the testing migration. I agree (with the explanation in your other mail) here; it just states the fact that they really don't go together very well (at least in situation similar to the specific CI test). >> Python-astropy is however going to be removed completely; it has >> however some cruft rdeps left in unstable. So, it cannot removed from >> unstable now, and therefore still remains in testing and >> (unnecessarily) blocks the numpy migration. Python-astropy already >> has an RC bug, but its autoremoval from testing is still not even >> announced yet. > > Maybe you could ask the release team to hasten the removal of > python-astropy and rdeps from testing? If the plan is to not relase > it in buster I don't see a reason to keep it further. Couldn't we just also add a "breaks" to numpy? The important fact here is, that the new numpy and the current python-astropy don't work together; and this is independent of whether a fixed python-astropy version exists. This would remove one dependent party (release team) from the chain of blocking causes for the migration. >> The migration blocking CI tests seem to cause much more headaches than >> just "fix your bugs"... > > Well, from what I see, it has helped a lot in this half a year detect a > ton of regressions that would have otherwise bothered several people in > a later moment… I usually regularly look into my packages and file bugs if a CI test fails caused by a buggy updated dependency. This works well without the need of blocks. It would also work, when a failing CI test would automatically trigger a bug report against the updated package, which then could be re-assigned to the rdep in case the problem was there. So, I value very much the CI tests by themself: they are the greatest invention since sliced bread, but I still dislike the inflexible handling of blocks. Often, a failing CI test makes a package only buggy with respect to a certain feature, so it would correspond to a "important" or "normal" bug severity. They are however always handled like a "serious" bug by preventing migration. I miss the "That was not a serious failure" button. Thanks fur your help! Best Ole
Re: Numpy migration?
On Sat, Jan 05, 2019 at 04:15:04PM +0100, Ole Streicher wrote: > There is one more problem, which are transitional dependencies: > > The new python3-numpy version breaks (f.e.) python3-pyregion because of > the problem in python3-astropy. The new upload of python3-astropy fixes > this, so in unstable everything is OK. Even when one now adds a > > Breaks: python3-astropy (<< fixed-version) > > to python-numpy, it will not migrate due to the test failure of > python3-pyregion in testing. Adding a "Breaks: python3-pyregion" is > however wrong, since pyregion is perfect for the new numpy version. If I understood correctly, pyregion is perfectly fine and needs no action. In that case, it's not a problem: with the "Breaks: python3-astropy (<< fixed-ver)" in place, the pyregion test would install the fixed version of python3-astropy from unstable as the broken version from testing would not be installable using the numpy from unstable. > So, how to handle this? No action needed once both astropy and numpy are "fixed". :) -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: Numpy migration?
On Sat, Jan 05, 2019 at 04:02:35PM +0100, Ole Streicher wrote: > I'll do tonight. It however looks a bit suboptimal: when the CI test > with a new version fails for an old reverse dependency, then the new > version obviously breaks that old package. So, the breakage could be > detected (and taken into account) automatically. Why do we need a manual > action then? Let me try to suggest you see from another side: the goal of the Breaks field is to prevent a given combination of known broken packages to be installed. Currently autopkgtest blocks the migration of numpy, but if there wasn't that block a Breaks should still be added, as the astropy in testing is not compatible with the new numpy. The fact that it hints britney to trigger the right tests is just a "side effects", the Breaks should be added nonetheless, theoretically; in practice, we rarely did it before autopkgtest started blocking the testing migration. > >> Another CI problem is python-astropy, which is the Python 2 version of > >> Astropy. python-astropy is going to be removed as soon as there are no > >> backward dependencies left; however there is still some cruft in > >> unstable that depends on python-astropy. But this should not hinder > >> numpy to migrate. > > > > I don't understand this, I don't see any python2-related issue right > > now. Could you please expand? > > The new python-numpy breaks python-astropy in testing. Oh, sorry. I didn't realize python-astropy is a different source package… > Python-astropy is > however going to be removed completely; it has however some cruft rdeps > left in unstable. So, it cannot removed from unstable now, and therefore > still remains in testing and (unnecessarily) blocks the numpy migration. > Python-astropy already has an RC bug, but its autoremoval from testing > is still not even announced yet. Maybe you could ask the release team to hasten the removal of python-astropy and rdeps from testing? If the plan is to not relase it in buster I don't see a reason to keep it further. > The migration blocking CI tests seem to cause much more headaches than > just "fix your bugs"... Well, from what I see, it has helped a lot in this half a year detect a ton of regressions that would have otherwise bothered several people in a later moment… For sure it's not just "fix your bugs" but more like "fix your bugs AND all your rdeps", in fact you'd expect the maintainer of the package breaking everything to be a tad more proactive, but in many cases like this, it's not. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: Numpy migration?
Mattia Rizzolo writes: > The way forward in cases like these is for the package that originally > cuased the breakage (i.e. numpy) to declare a versioned Breaks on the > borken and now fixed package (i.e. astropy (<< 3.1-1)). This way > britney and debci will know they have to test numpy and astropy > together, and will be able to correctly migrate to testing at the same > time, and properly avoid a situation when two incompatible packages > are installed. > Maybe you could open a bug on numpy to get the maintainer to add the breaks. There is one more problem, which are transitional dependencies: The new python3-numpy version breaks (f.e.) python3-pyregion because of the problem in python3-astropy. The new upload of python3-astropy fixes this, so in unstable everything is OK. Even when one now adds a Breaks: python3-astropy (<< fixed-version) to python-numpy, it will not migrate due to the test failure of python3-pyregion in testing. Adding a "Breaks: python3-pyregion" is however wrong, since pyregion is perfect for the new numpy version. So, how to handle this? Cheers Ole
Re: Numpy migration?
Mattia Rizzolo writes: > The way forward in cases like these is for the package that originally > cuased the breakage (i.e. numpy) to declare a versioned Breaks on the > borken and now fixed package (i.e. astropy (<< 3.1-1)). This way > britney and debci will know they have to test numpy and astropy > together, and will be able to correctly migrate to testing at the same > time, and properly avoid a situation when two incompatible packages > are installed. > Maybe you could open a bug on numpy to get the maintainer to add the > breaks. I'll do tonight. It however looks a bit suboptimal: when the CI test with a new version fails for an old reverse dependency, then the new version obviously breaks that old package. So, the breakage could be detected (and taken into account) automatically. Why do we need a manual action then? >> Another CI problem is python-astropy, which is the Python 2 version of >> Astropy. python-astropy is going to be removed as soon as there are no >> backward dependencies left; however there is still some cruft in >> unstable that depends on python-astropy. But this should not hinder >> numpy to migrate. > > I don't understand this, I don't see any python2-related issue right > now. Could you please expand? The new python-numpy breaks python-astropy in testing. Python-astropy is however going to be removed completely; it has however some cruft rdeps left in unstable. So, it cannot removed from unstable now, and therefore still remains in testing and (unnecessarily) blocks the numpy migration. Python-astropy already has an RC bug, but its autoremoval from testing is still not even announced yet. The migration blocking CI tests seem to cause much more headaches than just "fix your bugs"... Best Ole
Re: Numpy migration?
)On Sat, Jan 5, 2019 at 3:18 PM Ole Streicher wrote: > However, astropy cannot migrate now, to testing, since it depends on the > new numpy version (and therefore can only migrate after numpy). And > numpy is blocked by the CI failure of astropy ... > > Looks like a deadlock. Which will be resolved before the migration delay > ends. Which is in the second half of february, and therefore will cause > all packages that depend on numpy and are not in testing yet to be kept > outside of Buster (due to the release timeline). Starting from half a month ago CI regressions are de-facto release blockers. The way forward in cases like these is for the package that originally cuased the breakage (i.e. numpy) to declare a versioned Breaks on the borken and now fixed package (i.e. astropy (<< 3.1-1)). This way britney and debci will know they have to test numpy and astropy together, and will be able to correctly migrate to testing at the same time, and properly avoid a situation when two incompatible packages are installed. Maybe you could open a bug on numpy to get the maintainer to add the breaks. BTW, that numpy upload also blocked our effort to remove Python 3.6 from buster... > Another CI problem is python-astropy, which is the Python 2 version of > Astropy. python-astropy is going to be removed as soon as there are no > backward dependencies left; however there is still some cruft in > unstable that depends on python-astropy. But this should not hinder > numpy to migrate. I don't understand this, I don't see any python2-related issue right now. Could you please expand? -- regards, Mattia Rizzolo GPG Key: 4096R/B9444540 http://goo.gl/I8TMB more about me: http://mapreri.org Launchpad User: https://launchpad.net/~mapreri Ubuntu Wiki page: https://wiki.ubuntu.com/MattiaRizzolo
Numpy migration?
Hi all, Since a few days, a new RC is stalled in unstable: testing: 1:1.15.4-2 unstable: 1:1.16.0~rc1-3 The reason that it can't migrate is that it breaks the CI tests of several packages in testing. For example astropy (where I am the uploader), and its dependencies. The CI test failures were caused by astropy (#917466) and are fixed since a week in unstable. However, astropy cannot migrate now, to testing, since it depends on the new numpy version (and therefore can only migrate after numpy). And numpy is blocked by the CI failure of astropy ... Looks like a deadlock. Which will be resolved before the migration delay ends. Which is in the second half of february, and therefore will cause all packages that depend on numpy and are not in testing yet to be kept outside of Buster (due to the release timeline). What is the way to resolve those problems? These deadlocks probably appear regularly when a package gets a major update: package A breaks the CI test of the rdep B in testing, and a rebuild of B in unstable depends on the newer version of A. Another CI problem is python-astropy, which is the Python 2 version of Astropy. python-astropy is going to be removed as soon as there are no backward dependencies left; however there is still some cruft in unstable that depends on python-astropy. But this should not hinder numpy to migrate. How to solve this? Best Ole
