Re: Numpy migration?

2019-01-07 Thread Paul Gevers
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:

Re: Numpy migration?

2019-01-07 Thread Ole Streicher
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

Re: Numpy migration?

2019-01-07 Thread Ole Streicher
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

Re: Numpy migration?

2019-01-06 Thread Mattia Rizzolo
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 >

Re: Numpy migration?

2019-01-06 Thread Steffen Möller
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

Re: Numpy migration?

2019-01-06 Thread Ole Streicher
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

Re: Numpy migration?

2019-01-05 Thread Mattia Rizzolo
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

Re: Numpy migration?

2019-01-05 Thread Scott Kitterman
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

Re: Numpy migration?

2019-01-05 Thread Ole Streicher
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

Re: Numpy migration?

2019-01-05 Thread Mattia Rizzolo
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

Re: Numpy migration?

2019-01-05 Thread Mattia Rizzolo
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

Re: Numpy migration?

2019-01-05 Thread Ole Streicher
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

Re: Numpy migration?

2019-01-05 Thread Ole Streicher
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

Re: Numpy migration?

2019-01-05 Thread Mattia Rizzolo
)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