e) Questing/Noble/Jammy uploads, d/changelog Why are you changing these old/past changelog entries? Is it a process thing? I see something similar happened in the previous SRU.
This is a diff of d/changelog between what is currently in questing, and your questing upload, but it's similar in jammy and noble also: ```diff @@ -9,8 +126,9 @@ snapd (2.74.1+ubuntu25.10.4) questing; urgency=medium -- Ernest Lotter <[email protected]> Thu, 02 Apr 2026 08:44:00 +0200 -snapd (2.74.1+ubuntu25.10) questing; urgency=medium +snapd (2.74.1) xenial; urgency=medium + * New upstream release, LP: #2138629 - FDE: measure DeployedMode and AuditMode variables if they appear as disabled in the event log to avoid a potential reseal-failure boot loop @@ -29,8 +147,9 @@ snapd (2.74.1+ubuntu25.10) questing; urgency=medium -- Ernest Lotter <[email protected]> Thu, 12 Feb 2026 21:27:23 +0200 -snapd (2.74+ubuntu25.10) questing; urgency=medium +snapd (2.74) xenial; urgency=medium + * New upstream release, LP: #2138629 - FDE: use new activation API from secboot - FDE: use activation API also with non keydata keys - FDE: ignore internal recovery key expiration during install @@ -136,7 +255,7 @@ snapd (2.74+ubuntu25.10) questing; urgency=medium -- Ernest Lotter <[email protected]> Tue, 20 Jan 2026 18:54:17 +0200 -snapd (2.73+ubuntu25.10) questing; urgency=medium +snapd (2.73) xenial; urgency=medium * New upstream release, LP: #2132084 - FDE: do not save incomplete FDE state when resealing was skipped ``` f) Vendoring differences betweem questing and resolute When I compare the questing and resolute uploads, I see some vendoring differences, was that on purpose, or just a side effect of when and how the source tarball was prepared, or do questing and resolute really have different requirements for secboot and go-tpm2? For example: --- a/go.mod (questing) +++ b/go.mod (resolute) @@ -9,7 +9,7 @@ require ( github.com/bmatcuk/doublestar/v4 v4.6.1 github.com/canonical/go-efilib v1.7.0 github.com/canonical/go-sp800.90a-drbg v0.0.0-20210314144037-6eeb1040d6c3 // indirect - github.com/canonical/go-tpm2 v1.13.0 + github.com/canonical/go-tpm2 v1.15.0 github.com/coreos/go-systemd v0.0.0-20191104093116-d3cd4ed1dbcf github.com/godbus/dbus/v5 v5.1.0 github.com/gorilla/mux v1.8.0 @@ -22,7 +22,7 @@ require ( github.com/mvo5/libseccomp-golang v0.9.1-0.20180308152521-f4de83b52afb // old trusty builds only github.com/seccomp/libseccomp-golang v0.9.2-0.20220502024300-f57e1d55ea18 github.com/snapcore/go-gettext v0.0.0-20191107141714-82bbea49e785 - github.com/snapcore/secboot v0.0.0-20260302105957-77bc2457cc76 + github.com/snapcore/secboot v0.0.0-20260410084611-3f8b98c2db70 golang.org/x/crypto v0.23.0 golang.org/x/net v0.21.0 // indirect golang.org/x/sync v0.8.0 Actually, now that I check, I see this d/changelog entry in RESOLUTE: snapd (2.75+ubuntu26.04.2) resolute; urgency=medium - FDE: run early boot check only once per boot - FDE: update secboot to revision 77bc2457cc76 ... But resolute's go.mod has: github.com/snapcore/secboot v0.0.0-20260410084611-3f8b98c2db70 Which agrees with what the diff above is showing. So secboot in resolute was actually not updated? From an SRU perspective, I'm just making sure these changes are intended as they are. When I see an SRU where the same version is being pushed to all ubuntu releases, it's standard practice to check that all releases are getting the same thing, bar expected deviations. This might be such an expected deviation. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2143882 Title: [SRU] 2.75.2 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/2143882/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
