SUSE r-b

[David A. Wheeler]

> On Jul 31, 2025, at 9:31 AM, Bernhard M. Wiedemann via rb-general <rb-general at lists.reproducible-builds.org> wrote:
> ...
> But that changed earlier this year when reproducible-builds for SLES-16 became an official goal for the product. More people are talking about digital sovereignty and supply-chain security now.
> Since then I have been testing and sending fixes as fast as I could.
> 
> In the July monthly report [2] we now have more SUSEans contribute fixes than I ever thought would happen. Even for complicated stuff like emacs.
> And we fixed issues that were around for years (e.g. in llvm since at least 2018, numpy, mozilla-nss...)
> 
> While there are still some issues left, we document in a README [3] how to verify binaries anyway for many of them, e.g.
> colord: needs AVX2 on the build machine (bsc#1237156)
> java-21-openjdk: needs to be built on a 4-core VM (bsc#1221224)
> memcached: needs to be built before year 2038 (bsc#1246407)
> 
> And I added a package named SLES-reproducible-builds that blocks installation of remaining known-unverifiable packages via rpm's "Conflicts" mechanism.
> 
> Today, only 9 of 3319 (source) packages have significant problems left (plus 7 with pending fixes), so 99.5% of packages have reproducible builds.

This is ABSOLUTELY FANTASTIC!
Every time another real-world package that users actually *use* becomes reproducible,
that's an improvement. It's a *big* improvement when a widely-used
distro (like SUSE) systemically manages to do it. I'm hoping this will spur others as well.

My heartfelt congratulations to you and the entire SUSE team. I also give a heartful congratulations
to everyone who even indirectly contributed (many of them are on this mailing list!).

I *really* like the idea of having a *simple* way to configure a system
that says "only install reproducible packages". One problem with the "Conflicts:" package
approach is that it only blocks known-unverifiable packages; it doesn't *ensure* that packages
are reproducible (e.g., if they're from another repo). Still, this is easily implemented (because
it works well the existing packaging mechanisms) and makes it *easy* to
enforce common cases. So I wholeheartedly praise the "conflicts" package too.
It'd be nice if a better way to verify package reproducibility by installers
could be developed long-term, but that shouldn't distract anyone from taking these huge positive steps.

Reproducible builds are still challenging in some cases (as noted here and elsewhere),
and obviously, you're still working on some things. Nevertheless, this is a fantastic milestone.
Great job!

<applause>

--- David A. Wheeler