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
