All of the reverse dependencies should be okay when #1109389 is fixed.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Oh thank you!

/Simon

19 juli 2025 kl. 22:05 skrev Bastian Germann <Bastian.Germann@gmx.de>:


I have already filed bug#1109540 (unblock: golang-github-containers-ocicrypt/1.1.10-3)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

severity 1108992 normal
thanks

Bastian Germann <bastian.germann@gmx.de> 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

-----BEGIN PGP SIGNATURE-----

iQNoBAEWCAMQFiEEo8ychwudMQq61M8vUXIrCP5HRaIFAmh9+IMUHHNpbW9uQGpv c2Vmc3Nvbi5vcmfCHCYAmDMEXJLOtBYJKwYBBAHaRw8BAQdACIcrZIvhrxDBkK9f V+QlTmXxo2naObDuGtw58YaxlOu0JVNpbW9uIEpvc2Vmc3NvbiA8c2ltb25Aam9z ZWZzc29uLm9yZz6IlgQTFggAPgIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgBYh BLHSvRN1vst4TPT4xNc89jjFPAa+BQJn0XQkBQkNZGbwAAoJENc89jjFPAa+BtIA /iR73CfBurG9y8pASh3cbGOMHpDZfMAtosu6jbpO69GHAP4p7l57d+iVty2VQMsx +3TCSAvZkpr4P/FuTzZ8JZe8BrgzBFySz4EWCSsGAQQB2kcPAQEHQOxTCIOaeXAx I2hIX4HK9bQTpNVei708oNr1Klm8qCGKiPUEGBYIACYCGwIWIQSx0r0Tdb7LeEz0 +MTXPPY4xTwGvgUCZ9F0SgUJDWRmSQCBdiAEGRYIAB0WIQSjzJyHC50xCrrUzy9R cisI/kdFogUCXJLPgQAKCRBRcisI/kdFoqdMAQCgH45aseZgIrwKOvUOA9QfsmeE 8GZHYNuFHmM9FEQS6AD6A4x5aYvoY6lo98pgtw2HPDhmcCXFItjXCrV4A0GmJA4J ENc89jjFPAa+wUUBAO64fbZek6FPlRK0DrlWsrjCXuLi6PUxyzCAY6lG2nhUAQC6 qobB9mkZlZ0qihy1x4JRtflqFcqqT9n7iUZkCDIiDbg4BFySz2oSCisGAQQBl1UB BQEBB0AxlRumDW6nZY7A+VCfek9VpEx6PJmdJyYPt3lNHMd6HAMBCAeIfgQYFggA JgIbDBYhBLHSvRN1vst4TPT4xNc89jjFPAa+BQJn0XTSBQkNZGboAAoJENc89jjF PAa+0M0BAPPRq73kLnHYNDMniVBOzUdi2XeF32idjEWWfjvyIJUOAP4wZ+ALxIeh is3Uw2BzGZE6ttXQ2Q+DeCJO3TPpIqaXDAAKCRBRcisI/kdFogYqAQDpYrjdI0iZ UKH/dxBQ7qPtm3ocyc6mL3l4DACBmTkoRQEAqyqPXQXJI5+acnj8Vu3+fZhDrriq DXXF/wjmYgw7VA4=
=rnBt
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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 <simon@josefsson.org> writes:

severity 1108992 normal
thanks

Bastian Germann <bastian.germann@gmx.de> 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

-----BEGIN PGP SIGNATURE-----

iQNoBAEWCAMQFiEEo8ychwudMQq61M8vUXIrCP5HRaIFAmiAoqsUHHNpbW9uQGpv c2Vmc3Nvbi5vcmfCHCYAmDMEXJLOtBYJKwYBBAHaRw8BAQdACIcrZIvhrxDBkK9f V+QlTmXxo2naObDuGtw58YaxlOu0JVNpbW9uIEpvc2Vmc3NvbiA8c2ltb25Aam9z ZWZzc29uLm9yZz6IlgQTFggAPgIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgBYh BLHSvRN1vst4TPT4xNc89jjFPAa+BQJn0XQkBQkNZGbwAAoJENc89jjFPAa+BtIA /iR73CfBurG9y8pASh3cbGOMHpDZfMAtosu6jbpO69GHAP4p7l57d+iVty2VQMsx +3TCSAvZkpr4P/FuTzZ8JZe8BrgzBFySz4EWCSsGAQQB2kcPAQEHQOxTCIOaeXAx I2hIX4HK9bQTpNVei708oNr1Klm8qCGKiPUEGBYIACYCGwIWIQSx0r0Tdb7LeEz0 +MTXPPY4xTwGvgUCZ9F0SgUJDWRmSQCBdiAEGRYIAB0WIQSjzJyHC50xCrrUzy9R cisI/kdFogUCXJLPgQAKCRBRcisI/kdFoqdMAQCgH45aseZgIrwKOvUOA9QfsmeE 8GZHYNuFHmM9FEQS6AD6A4x5aYvoY6lo98pgtw2HPDhmcCXFItjXCrV4A0GmJA4J ENc89jjFPAa+wUUBAO64fbZek6FPlRK0DrlWsrjCXuLi6PUxyzCAY6lG2nhUAQC6 qobB9mkZlZ0qihy1x4JRtflqFcqqT9n7iUZkCDIiDbg4BFySz2oSCisGAQQBl1UB BQEBB0AxlRumDW6nZY7A+VCfek9VpEx6PJmdJyYPt3lNHMd6HAMBCAeIfgQYFggA JgIbDBYhBLHSvRN1vst4TPT4xNc89jjFPAa+BQJn0XTSBQkNZGboAAoJENc89jjF PAa+0M0BAPPRq73kLnHYNDMniVBOzUdi2XeF32idjEWWfjvyIJUOAP4wZ+ALxIeh is3Uw2BzGZE6ttXQ2Q+DeCJO3TPpIqaXDAAKCRBRcisI/kdFovXGAQDI504UBDc6 R2zPtODSGM6v9ulhZ57c6EUOGaflsKSG8QEA5KMQT3IfgtxvbI3JINL59OfJMljZ ERo4JfAabegJ7wU=
=tJ1/
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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ý <ondrej@sury.org> 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 <simon@josefsson.org> 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 <simon@josefsson.org> writes:

severity 1108992 normal
thanks

Bastian Germann <bastian.germann@gmx.de> 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>

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQNoBAEWCAMQFiEEo8ychwudMQq61M8vUXIrCP5HRaIFAmiAs/oUHHNpbW9uQGpv c2Vmc3Nvbi5vcmfCHCYAmDMEXJLOtBYJKwYBBAHaRw8BAQdACIcrZIvhrxDBkK9f V+QlTmXxo2naObDuGtw58YaxlOu0JVNpbW9uIEpvc2Vmc3NvbiA8c2ltb25Aam9z ZWZzc29uLm9yZz6IlgQTFggAPgIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgBYh BLHSvRN1vst4TPT4xNc89jjFPAa+BQJn0XQkBQkNZGbwAAoJENc89jjFPAa+BtIA /iR73CfBurG9y8pASh3cbGOMHpDZfMAtosu6jbpO69GHAP4p7l57d+iVty2VQMsx +3TCSAvZkpr4P/FuTzZ8JZe8BrgzBFySz4EWCSsGAQQB2kcPAQEHQOxTCIOaeXAx I2hIX4HK9bQTpNVei708oNr1Klm8qCGKiPUEGBYIACYCGwIWIQSx0r0Tdb7LeEz0 +MTXPPY4xTwGvgUCZ9F0SgUJDWRmSQCBdiAEGRYIAB0WIQSjzJyHC50xCrrUzy9R cisI/kdFogUCXJLPgQAKCRBRcisI/kdFoqdMAQCgH45aseZgIrwKOvUOA9QfsmeE 8GZHYNuFHmM9FEQS6AD6A4x5aYvoY6lo98pgtw2HPDhmcCXFItjXCrV4A0GmJA4J ENc89jjFPAa+wUUBAO64fbZek6FPlRK0DrlWsrjCXuLi6PUxyzCAY6lG2nhUAQC6 qobB9mkZlZ0qihy1x4JRtflqFcqqT9n7iUZkCDIiDbg4BFySz2oSCisGAQQBl1UB BQEBB0AxlRumDW6nZY7A+VCfek9VpEx6PJmdJyYPt3lNHMd6HAMBCAeIfgQYFggA JgIbDBYhBLHSvRN1vst4TPT4xNc89jjFPAa+BQJn0XTSBQkNZGboAAoJENc89jjF PAa+0M0BAPPRq73kLnHYNDMniVBOzUdi2XeF32idjEWWfjvyIJUOAP4wZ+ALxIeh is3Uw2BzGZE6ttXQ2Q+DeCJO3TPpIqaXDAAKCRBRcisI/kdFomopAP9XNqc5MAvK X55OoVHp7l0omX2oaPwU+yBJsX2PL6Si6QEAmEGjvwsXLdbkovRcvGYgn81SP/0v 99NajN8/NddY7AU=i47H
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)