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:
>>>
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 err
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 prob
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
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.
> - with numpy-1.15.4-2 (testing) and matplotlib-2.2.2-4 (testing),
> - with n
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:/
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
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-
> >> (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
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
l (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)
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 unsta
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 ther
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 astro
stable. 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
)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 resolve
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
17 matches
Mail list logo