Mattia Rizzolo <mat...@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). >> - 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
