[ Apologies, I thought I'd already sent this a couple of days
  back. :-( ]

Hey folks,

Related to the wider issue report in #1135716:

We should update fwupd in bookworm to aid with the UEFI Secure Boot CA
updates process that I've laid out in

https://wiki.debian.org/SecureBoot/CAChanges

and in #1138871

As well as in trixie (#1139251), we'd therefore like to update to
2.0.20 in bookworm. We know that version works for the CA updates, but
it does involve a major step forward in what we have in bookworm here.

We'd also need to update a couple of the build-deps to match what's
in trixie:

* libjcat
* libxmlb

but those are much more straightforward.

Mario has already prepped the changes in git, but not yet uploaded
anything. We'd like to get approval before doing that please.

The debdiff is large, too large to sensibly include in mail. :-(

Control: tag -1 moreinfo

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?

Thanks,

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1139587
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1139586

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.

Control: tag -1 moreinfo

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,

Yes; like the other packages that need to bump.
The individual ABI changes that went with the SONAME bump are documented
here.

https://github.com/fwupd/fwupd/blob/2.0.20/libfwupd/README.md

I don't believe they are added symbols only.  I do recall for example
that we dropped fwupd_build_machine_id() in 2.0.0 (and oldstable is at
1.8.12).

https://github.com/fwupd/fwupd/commit/740d0817d

There are multiple cases like this.

So unfortunately I think this does mean a need for a rebuild and some
testing of of gnome-software, plasma-discover, and gnome-firmware to do
the upgrade.

https://salsa.debian.org/qt-kde-team/kde/plasma-discover/-/commit/afca7536787af4d0f58d3aa22a9962c2265b58d5
https://salsa.debian.org/gnome-team/gnome-software/-/commit/bdfe5c691a1c3302cf61da0781b290c67f88ba6b
https://salsa.debian.org/gnome-team/gnome-firmware/-/commit/851182b25b8bd4f79d849337fa4b8cf11b47178d

cu
Adrian

Thanks Adrian for finding those.

I've got gnome-firmware building successfully, I'll attach the debdiff.

will follow up with the others later when I get them working.

Oh, I had a completely dim moment and forgot the old symbols file is
removed completely - just skimmed the new one and got confused. Sorry.

Please coordinate with affected maintainers to get things ready, and
ideally affected packages would get a versioned build-dep now which will
make things easier later. I'll get the two other libraries sorted out.

Keep me posted.

Thanks,

OK - I've got gnome-software and plasma-discover building too.  Attached
are the debdiffs.

Do you suggest filing a bug with all 3 packages and requesting
maintainers to ack doing an NMU for their packages referencing this bug?

I think a p-u bug for each package, including patch, with 'affects' and
explicitly copying the maintainers would make the fewest round-trips.

One doubt in my mind - should we wait until we have an ack for the 3
rdepends bookworm-pu bugs so all 4 can upload at same time?

Hi,

Please go ahead with a fixed version as discussed.

Thanks,

No, they will be queued together and I'll handle ordering. More important
is to get the final packages uploaded and visible.