Hi Peter, On 16-12-2019 01:21, peter green wrote: > I have been observing a number of python cruft packages that are still > in testing recently, and I noticed that there seems to be an issue with > an auto-removal. cruft has never been supposed to be in testing. There was a bug in britney that we believe is fixed. The end of the output.txt has the packages which shouldn't have been left in testing: List of old libraries in the target suite (96): [...] (libraries in smooth update transitions) python-colorama: amd64 arm64 armel armhf i386 mips64el mipsel ppc64el s390x python-colorlog: amd64 arm64 i386 mips64el ppc64el python-fonttools: amd64 i386 python-fs: amd64 i386 python-terminado: amd64 i386 python-waitress: amd64 arm64 armel armhf i386 mips64el mipsel ppc64el s390x > My understanding is that auto-removals is supposed to keep track of > reverse dependencies and initially delay auto-removal, then later, if > the package remains rc buggy for long enough, remove the > reverse-dependencies as well. Correct, if you mean with "remove the reverse-dependencies as well" that these reverse-dependencies are removed together when the "main" package. > However in the case of python-easydev auto-removals seems to be trying > to remove python-easydev without also removing it's reverse dependency > hinge. Any idea why? I see, probably a bug somewhere. I think the code that generates the list for autoremoval is this one: https://salsa.debian.org/qa/udd/blob/master/udd/testing_autoremovals_gatherer.pl Paul
Attachment:
signature.asc
Description: OpenPGP digital signature