Hi Matthias, On Fri, Mar 27, 2026 at 05:36:05PM +0100, Matthias Klose wrote: >Package: src:shim >Version: 16.1-1 >Severity: serious >Tags: sid forky > >First, thanks for updating to a more recent compiler version. However this >is still not using the default GCC version. A bit disappointed about this, >plus unanswered pings on irc during the past months.
Crap, sorry - it looks like I've missed your most recent pings while buried under a catastrophically busy project in $dayjob. :-( >You still haven't answered, if you want to vendor the compiler used to build >shim, so I would have expected either using the default compiler, or a >vendored compiler. So what *exactly* do you mean by a "vendored compiler"? I don't *think* we need a special particular build/version of the compiler to build shim. What we *do* need is to be able to rely on building consistently reproducible (byte-identical) binaries in unstable/testing for a short(-ish) period. That period is typically a few weeks (but potentially up to a few months), depending on how long it takes for people to reproduce and review our builds during the shim review process: https://github.com/rhboot/shim-review/ In this case, the exact sha256sum of the binaries we build have to match what other people can build, so updates to the toolchain are likely to cause problems. Building with the default compiler in unstable is likely to be prone to changes that will break this reproducibility, and that's why I've been picking older versions of gcc that won't change in the period we need. Obviously, building updates for oldstable, stable, etc. is not likely to be affected here - this is just a worry with a moving-target compiler like the default we get in *unstable*. Shim is also quite special compared to other packages in Debian in that we're very unlikely to produce new shim packages more than 2 or 3 times per stable release; that's typically just in a small window when we bump to a new upstream version then perform one or two cycles of tweaks and bugfixes on that. Once we've done the review and submitted to Microsoft for signing, the base shim source package doesn't change. People *can* rebuild that package later, but it's basically pointless - the entire point for shim is to have a stable signed *binary* including Debian's Secure Boot CA key to act as a trusted base for our other SB packages. >If you need a compiler prior to GCC 15, then please use gcc-13. I would >rather use that one if necessary instead of gcc-14. Sure, I can easily and happily switch to gcc-13 if you'd prefer that. Should I do that right now? In the longer term, after we have binaries signed I would *love* it if we could somehow drop the build-dependency link here. We won't care at all, and keeping an old compiler in the archive just for the sake of potentially rebuilding a *very* special-case package is less than ideal really. If the release team (in CC) can come up with something acceptable there so that we could do this (add an ignore on the B-D for the shim source package, or something?), that would save you and/or other GCC maintainers from having to care so much here. We clearly won't be uploading a new version of shim that needs that old compiler, and we can't be doing a new shim source upload just to change that B-D. >If you still plan to vendor the compiler for shim and need help with that, >please reach out, as discussed at DebConf 2025. But just ignoring people >doesn't seem to be the right thing to do. Sorry, ignoring you wasn't my intention at all. :-( -- Steve McIntyre, Cambridge, UK. [email protected] Who needs computer imagery when you've got Brian Blessed?
