Control: tag -1 moreinfo On Sun, Jun 14, 2026 at 02:46:06PM +0100, Steve McIntyre wrote: > On Mon, Jun 08, 2026 at 08:46:37PM +0100, Jonathan Wiltshire wrote: > >Control: tag -1 moreinfo > > > >On Sun, Jun 07, 2026 at 05:55:33PM +0100, Steve McIntyre wrote: > >> We'd also need to update a couple of the build-deps to match what's > >> in trixie: > >> > >> * libjcat > >> * libxmlb > > > >These will need to happen first for fwupd to build against, with their own > >request bugs and debdiffs please. > > > >Is there a source debdiff for fwupd too? > > Mario has followed up with that (as jmw and I have seen), but it's way > too large for the BTS and/or list to have seen. Basically, I > acknowledge that this *is* a very large step forward but I think it's > justified here. We really need to get the UEFI CA updates onto most > people's machines.
The BTS does get big diffs, it's only the list which struggles. I've discussed with Adam because yes, this is normally unacceptable because (amongst others): - there's a SONAME change, which means a library transition, which is not really something we're set up for in stable - the proposal is essentially unreviewable by human means - it is critical infrastructure and has a high potential impact on millions of machines (including bricking) - it needs other library updates first, with their own reverse dependencies and a whole chain of implications there However if we don't update fwupd, we and/or users are left with a pickle if there is a security update for shim (including an SBAT revocation for grub) in the next two years (assuming it becomes 2023-signed only): - if we release the shim update, users must partially upgrade to trixie in a hurry, then apply the dbx/KEK updates via fwupd, then complete the upgrade including shim. A reboot at any stage in that process will likely fail. Users who have not caught wind of what is going on will simply be faced with failed package installation. Users should not have to do an unplanned major upgrade to install a simple security update. - if we steer fwupd towards backports, it will stop existing soon and users who do not take steps in the next few weeks are later left with the same problem - if we keep fwupd back and hope there isn't a grub/shim update, then it becomes *us* (well, LTS) who are stuck having to do major unplanned things in a rush. The likelihood of there being a short-notice shim update in the next two years we assess to be somewhere between possible and probable, but short of certain. Although Debian will no longer support bookworm by then, it is undoubtedly in our users' interests that LTS can do a good job during that time (SC4). We'd rather have that pain now in a more controlled way. Therefore we will proceed with this update proposal despite the increased risks. Looking at the proposed diff itself: - the version again needs to be ~deb12u1 not +deb12u1 - I do not understand the SONAME change when there are only added symbols as far as I can see? Avoiding that makes a big difference to the rebuilds required for libfwupd2->3. Thanks, -- Jonathan Wiltshire [email protected] Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1
