Ah, right, although this bug would not necessarily have any activity since the real issue was golang-github-containers-ocicrypt but that is now fixed in testing. And the autoremoval was for 2025-08-22, not 2025-07-22 which my summer heated brain incorrectly read it as...
However if the intention to keep 'opendnssec' out of trixie, maybe this bug should be escalated into a removal request from the release team? I'm not sure if autoremoval works during the final freeze? The release date is 2025-08-09 and the autoremoval trigger is now on 2025-08-07, but probably this email will bump it further if your theory is correct... /Simon Ondřej Surý <[email protected]> writes: > I believe the auto removal counter resets when there’s an activity on > the bug. Or at least it was the case in the past (or my memory is > failing me). > > Ondrej > -- > Ondřej Surý (He/Him) > >> On 23. 7. 2025, at 10:57, Simon Josefsson <[email protected]> wrote: >> >> severity 1108992 grave >> thanks >> >> Bumping severity again since golang-github-containers-ocicrypt is now in >> testing, so removing opendnssec from testing should be possible. I >> realized the summer heat caused me to confuse the autoremoval date of >> 2025-08-22 with 2025-07-22 so there were no real urgency here... >> >> /Simon >> >> Simon Josefsson <[email protected]> writes: >> >>> severity 1108992 normal >>> thanks >>> >>> Bastian Germann <[email protected]> writes: >>> >>>> I have already filed bug#1109540 (unblock: >>>> golang-github-containers-ocicrypt/1.1.10-3) >>> >>> It seems the autoremoval is more aggresive than the override permission, >>> with autoremoval removing a lot of packages tomorrow that (indirectly) >>> depends on opendnssec, but the release team override will come into >>> effect ~2 days later and only allow golang-github-containers-ocicrypt >>> into testing until after the autoremoval has removed a bunch of >>> packages. >>> >>> I'm lowering the severity of this bug, to give >>> golang-github-containers-ocicrypt some time to enter testing first, so >>> that we can raise the severity of this bug again to trigger autoremoval >>> of the opendnssec package. >>> >>> Is there a better way to handle this? I hope this is okay. I think the >>> original report is about removing opendnssec from trixie, not about >>> removing everything that depends on opendnssec by mistake, i.e., >>> everything behind golang-github-containers-ocicrypt, which involves a >>> lot of packages: >>> >>> podman >>> buildah >>> cosign >>> gitsign >>> gittuf >>> sigstore-go >>> ... >>> >>> I guess another way is to turn this bug into a release team request to >>> drop opendnssec from trixie? And not use the autoremoval mechanism to >>> achieve this. Then the release team can wait for >>> golang-github-containers-ocicrypt to enter testing, and then remove >>> opendnssec from testing. >>> >>> /Simon >>> >> <signature.asc> >
signature.asc
Description: PGP signature
