Control: reassign -1 grub-efi-amd64-signed
Control: fixed -1 1+2.12+1+b1
Control: close -1

On Sun, Mar 24, 2024 at 06:23:56PM +0100, Eduard Bloch wrote:

reopen 1067486
reassign 1067486 apt
severity 1067486 normal
thanks

This is stupid, you should know better.

Am Fri, Mar 22, 2024 at 11:46:02PM +0100 schrieb Julian Andres Klode:

Please upload a new version so grub-efi-amd64-signed can be installable. Thanks!

I'm getting a bit tired of this. This is normal, the packages are automatically generated but need to be approved by ftpteam.

This might be a normal condition but a) this is not transparent to user,
and b) it really does break apt's operation, at least partly.

For a) maybe we should make this somehow auto-checked remotely and shown
in reportbug? Or would you have a better idea?

And for b) all "dist-upgrade" or "full-upgrade" failed suddenly. Yes, failing, user getting completely locked out. And "upgrade" operation installed just a fraction of the potential candidates (there were more reasons for that but the lack of dist-upgrade feature is still PITA).
And the reason has not been obvious, and even debugging with -oDebug::pkgProblemResolver=true is NO FUN on bigger upgrades.

And the eventual solution was close examination, and some
guessing/observing that apt is confused and jumps between amd64 and
i386, and then some FORCE magic, i.e.

dpkg --remove --force-depends grub-common:i386

(don't ask me how this package got installed before, that system
installation has been migrated a lot). Another candidate was an old iproute:i386 package which I also had to remove.

These kinds of issues will be resolved eventually on grubs side, but
that aside, if you want to run unstable, you gotta learn to live with
these kind of situations and you gotta know what is a bug and what is
not. Seemingly you don't know how to deal with unstable, because you
should know that this is not a bug in apt.

This was a conscious decision by the release team to not have an unstable-proposed and gate unstable by installability (and testing),
and we gotta live with it.

Users should be running testing, not unstable. We do not provide any
guarantees that dependencies can be resolved or that a dist-upgrade
won't remove your entire system for unstable. You should not use it.

The unsolicited backport to bookworm was worse because people trying
to install that also ended up with breakage, sadly there is no migration
for backports, there should be a bookworm-backports-proposed and a
britney. Again this is a process issue that you are welcome to raise
with the ftp team, release team, and backports team.

--
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer i speak de, en

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