On Tue, 2022-02-22 at 22:37 +0000, Peter Green wrote: > > To the best of my knowledge there is no mechanism to automatically remove > packages with broken build-dependencies from testing. I certainly > don't recall collectd being listed for autoremoval at the time I filed the > bug.
No idea, but things work as expected, got this mail on january 9th: collectd 5.12.0-7 is marked for autoremoval from testing on 2022-02-04 It (build-)depends on packages with these RC bugs: 997189: liboping: FTBFS: oping.c:1159:25: error: format not a string literal and no format arguments [-Werror=format-security] https://bugs.debian.org/997189 > > The auto-removals system does take account of reverse build-dependencies when > deciding what extra removals to trigger, but unfortunately the same does not > apply to manual removals by the release team. > Not sure, but in the next mail the removal date changed, I'd assume as the removal from testing was used as base date for the autoremoval, not the filed bug: (mail from january 31st) collectd 5.12.0-8 is marked for autoremoval from testing on 2022-02-28 It (build-)depends on packages with these RC bugs: 1002985: ruby-redis, src:ruby-fakeredis: ruby-redis breaks ruby-fakeredis autopkgtest https://bugs.debian.org/1002985 997189: liboping: FTBFS: oping.c:1159:25: error: format not a string literal and no format arguments [-Werror=format-security] https://bugs.debian.org/997189 > In particular the following scenario can happen. > > Package a build-depends (but does not depend) on package b. > Package b is rc buggy. > The autoremovals system sends out mails notifying maintainers that if the > situation doesn't change, it will remove packages b and a > Package b gets manually removed by the release team. > The package with the rc bug is no longer in testing, so it drops off the > autoremoval system's list of issues. > Package a does not actually get autoremoved despite the earlier mail from the > autoremovals system. > > I suspect that may well be what happened here (liboping was manually > removed from testing as it was blocking the perl transition). > > > > Don't think so, at least thats how I interpret the mails I've got. > > It basically adds the extra work of tracking and closing this bug manually. > > I understand that and that is why I am selective about when I file such bugs. > If I see indications that the underlying issue is likely to be fixed on > a reasonable timescale, I generally will hold-off filing bugs on the reverse > dependencies. > > In this case I saw no such indications. The bug report was over a month > old with no maintainer response, and the package had not seen a maintainer > upload in over a year. > The maintainer is busy with real life, if I'd have known that it blocks the perl transition, I'd have fixed oping earlier. > > > > If you want to add such bugs, please link them properly to the bugs that > > caused the issue and make sure that it is closed automatically as soon as > > the > > issue is fixed. > > If the bts had a system to automatically close bugs when another package > migrates > to testing I would use it but afaict it doesn't. > > I am not going to build custom automation for such a small volume of bugs. > Ah thought that it would be automatically generated. > It certainly makes sense to link to the underlying bug though, I'll try and > remember > that next time. > That would be appreciated. > I guess I could also set "blocks", but i'm not entirely convinced it's > appropriate, > it's the maintainers call not mine as to whether to fix the issue by fixing > the > unmaintained package they build-depend on or by eliminating the > build-dependency > on it. True. But I still think that these things shouldn't need manual investigation and bugs at all, if autoremovals doesn't handle manual removals (I guess it does, but add a delay), that should be fixed. Manually filing bugs also needs time. Cheers, Bernd -- Bernd Zeimetz Debian GNU/Linux Developer http://bzed.de http://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
