Re: Confusing migration excuse regarding mips64el
On Sat, 2016-07-16 at 13:52 -0700, Afif Elghraoui wrote:
> I had previously requested removal of outdated binaries for python-pysam
> to enable testing migration, but I did not do so for mips64el because
> the migration excuse[1] says:
>
> ~~~
> missing build on mips64el: python-pysam, python-pysam-tests,
> python3-pysam (from 0.9.0+ds-1) (but mips64el isn't keeping up, so
> nevermind)
> ~~~
>
> It seems that this actually does matter, since migration has not
> happened despite the other outdated binary packages having been removed
> for several days.
There are other reasons why the migration might not have occurred. The
excuse in question finishes with "valid candidate", indicating that this
is /not/ a blocker.
> So what does the "nevermind" part mean?
It means exactly what it says, that mips64el is not a blocker for
migration. If you check the logs, you will find the actual issue:
trying: python-pysam
skipped: python-pysam (0, 16, 15)
got: 70+1071: a-3:i-20:a-0:a-0:a-0:m-0:m-3:p-43:p-0:s-1:m-1071
* mipsel: pbbarcode, python-kineticstools, python-pbh5tools
This is due to the fact that each of those packages depends on
python-pbcore, which in turn depends on python-pysam. As you've removed
the mipsel binaries for python-pysam, migrating the new version would
therefore render those packages uninstallable in testing, so britney
refuses.
As the dependent packages appear to have the same version numbers in
testing and unstable, this also means that they will currently be
uninstallable (and therefore RC-buggy) in unstable. If python-pysam is
not intended to be reintroduced on mipsel, the binaries of the other
packages will also need removing on that architecture.
Regards,
Adam
Reply to: