Dear all, On 22-10-2019 17:04, Matthias Klose wrote: > He suggested to make the removal plan more > concrete and having a timeline. To be more precise on what I meant, I'm talking here about *every* package that wants to drop a Python 2 binary package, discuss (and ideally agree on, but I understand that that can be hard) the time line with their reverse dependencies. If this is done globally, fine, but please, give reverse dependencies time to adapt. I'm already seeing quite some annoyance on the fact that in several cases the ground is pulled away under one's package. Yes, there's a bug in britney somewhere that allows the migration, we're trying to find it. Paul For those that are curious, the britney output [1] shows at the end binary packages in testing that are not build from source anymore but are left in testing due to dependencies. Those that aren't in libs/oldlibs shouldn't be there and are make their reverse dependencies RC buggy. On top of that, Dose [2] shows packages that can't be build from source in testing. There's quite some python2 packages listing as causing that. Again, all those packages are RC buggy (often the bug hasn't been filed yet). [1] https://release.debian.org/britney/update_output.txt.gz [2] https://qa.debian.org/dose/debcheck/src_testing_main/ (pick the latest amd64 log, it should be empty except for cmucl)
Attachment:
signature.asc
Description: OpenPGP digital signature