على السبت 16 تـمـوز 2016 14:26، كتب Adam D. Barratt: > 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.
Ok, I guess I expected the excuses page to have all the relevant information. > >> 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. > Thanks for clearing this up. I've requested removal of those rdeps on mipsel and armel. Thanks and regards Afif -- Afif Elghraoui | عفيف الغراوي http://afif.ghraoui.name
