While we're on the topic: work on minimal-bootstrap in #nixpkgs has actually been picked up again since this thesis was written (October 2025).
Not only that but, as of a few hours ago, the PR implementing the last step of hooking it up to become the actual bootstrap stdenv in Nixpkgs has been merged!
https://github.com/NixOS/nixpkgs/pull/479322
#fullsourcebootstrap #reproduciblebuilds #stage0 #minimalbootstrap #bootstrappablebuilds
@filippo Meanwhile, bootstrapping a current OpenJDK involves compiling multiple ancient packages (each with its own set of outdated dependencies, of course) and then going up all the way from Java 7, version by version.
@stikonas has described this tedious process and developed some ebuilds for Gentoo here: https://git.stikonas.eu/andrius/gentoo-bootstrap
This also applies to Rust in a way, but at least it's not as bad there – not yet, as the old versions might eventually succumb to bitrot, too.
Please, dear programming language community, can we do better at this? For resilience, for reproducibility, for reliability, for portability and for preservation?
#bootstrappablebuilds #bootstrapping #reproduciblebuilds #trustingtrust #gentoo #openjdk #rust
Edit: Added &c=my-comment to the URL,
please like my comment, or otherwise help me to reach LaurieWired? Boost=❤️ #askfedi
@regtur @reproducible_builds @guix @ekaitz_zarraga
@nlnet
@fsf
@fsfe
@gnutools
Seems #fedi didn't do their thing just yet, so I logged into the Evil Empire and added a comment. Not sure if that will do any good, tho. I guess maybe one or two of you who read this, and still have a Google account, could like my comment, but there are already comments with > 3K likes, so yeah.
Also, no idea how to reach them; they're talking about trust, and then only seem to on Big Tech platforms like TPPKAB (the platform previously known as birdsite), instagram, etc.
<https://www.youtube.com/watch?v=Fu3laL5VYdM&lc=UgxAf-w-tTYM5syB3x94AaABAg>
#bootstrappablebuilds #guix #gnu #reproducibleBuilds #supplyChainSecurity #trustingTrust
@regtur
Wait what? #GNU #Mes isn't being mentioned? Not even in the comments?
Fediverse do your thing!
cc: @lauriewired @reproducible_builds
@guix
@ekaitz_zarraga
@nlnet #bootstrappable
#bootstrappablebuilds
#guix
#trustingtrust
#GNU Mes 0.27.1 released: A bug-fix release that supports
* development build with gcc-14
* building with M2-Planet 1.12.0
* building on x86-linux with M2-Planet 1.13.0
* building bootstrappable-tcc using 1.00.02 <= NYACC <= 2.02.2
<https://lists.gnu.org/archive/html/info-gnu/2025-08/msg00005.html>
Thanks to @ekaitz_zarraga and @stikonas!
#GnuMes
#bootstrappable
#BootstrappableBuilds
#ReproducibleBuilds
@reproducible_builds
@fsf
@fsfe
@gnutools
@nlnet
Bootstrapping of an older version of re2c:
Note to self:
I must admit I probably could have used a slide about why #ReproducibleBuilds is important in my talk yesterday.
More and more I would like to stress that reproducible builds are most importantly about being able to say that a given artifact was produced from specific bit of source code, and all of the security and other benefits derive directly or indirectly from that.
Ideally you can recursively make such assertions all the way down, and you end up with #BootstrappableBuilds
A talk about live-bootstrap and builder-hex0 by Rick Masters:
https://www.youtube.com/watch?v=ycLdhqn5VI4
https://github.com/ironmeld/builder-hex0
I was just reviewing the new x86 hex0 bootstrap seed: https://github.com/oriansj/stage0-posix-x86/blob/master/hex0_x86.hex0. Big thanks to Noah Goldstein for making it smaller.
Now it is only 190 bytes. Excluding ELF header that's only 106 bytes of code.
For a couple of years hex0 binary was 256 bytes and before that hex0 was 357 bytes (this is the number that is still mentioned in https://guix.gnu.org/manual/devel/en/html_node/Full_002dSource-Bootstrap.html).
I will be presenting
"Two Ways to Trustworthy"
at @SeaGL this year!
It will be a comparison of #Debian and #Guix largely as they relate to #ReproducibleBuilds and #BootStrappableBuilds highlighting the differing strengths and challenges each project faces...
@filip The current project is focused on running the compiler in a Scheme implementation, and generating native code with a C compiler.
The bootstrapping story is really a question of "how much Scheme" and "how much C". I'd love for Pre-Scheme to run on GNU Mes, but that hasn't been investigated yet. I'm in touch with folks in the bootstrapping community who are experts in minimal C compilers, and intend to do a detailed analysis of compatibility at some point. Early diagnosis is that Pre-Scheme isn't very demanding of a C compiler and targeting minimal compilers should be possible.
Beyond that, there's the possibility for adding new backends to the Pre-Scheme compiler. The original compiler described in "Compilation By Program Transformation" emitted m68k assembly. The paper "A Tractable Native-Code Scheme System" describes re-purposing the compiler as a bytecode optimizer, which involved writing a backend to emit Scheme 48 bytecode. I also have colleagues who are very interested in the possibility of a WebAssembly backend.
@harrysintonen Thanks for the links.
I'm looking into going further for compilers, especially self-hosted: if we assume that the compiler's repository is already backdoored (ex: like xz, adding/modifying a test file affects the final binary) for a few generations since being built from a more trusted toolchain that has multiple implementations (C compiler), how could we detect such backdoor in order to block it from being propagated to the next generation?
#BootstrappableBuilds
@harrysintonen @vegard These days we also have #BootstrappableBuilds that prevent this kind of attack (at least at the software level).
@rsc @timbray Indeed. #ReproducibleBuilds and #BootstrappableBuilds cannot replace auditing source.
@khinsen @SReyCoyrehourcq @zimoun @civodul Wouldn't hurt to contact upstream about the cycle they created and ask if they have or are working on a solution
#bootstrappablebuilds
There is now an interesting guide by @mid_kid (https://mid-kid.root.sx/git/mid-kid/bootstrap/src/branch/master/gentoo-2024/gentoo.txt) on installing #Gentoo from just source and a tiny 200 byte kernel. At the moment it's a bit longish and starts with #livebootstrap then pivots to #LFS to obtain 64-bit toolchain and finally bootstraps #Gentoo from there.
Potentially some steps could be optimized, and #LFS removed but it works.
I think it just makes no sense to, at some arbitrary level, say: "Listen, we're not going to build this package from source, because: 'Well, we actually don't have any good reason for it but we just won't.'"
#bootstrappable
#bootstrappability
#bootstrappableBuilds
#freeSoftware
I've just updated my gentoo-bootstrap overlay (https://gitlab.com/stikonas/gentoo-bootstrap) with fixes to GCC →OpenJDK 8 bootstrap. (There was a bit of breakage due to some old ecj tarballs disappearing from distfiles.gentoo.org)
#GNU Mes 0.26 released: With greatly enhanced #Guile compatibility, Guile-style modules, and supporting Gash and Gash-Utils.
https://lists.gnu.org/archive/html/info-gnu/2023-12/msg00000.html
Thanks to the amazing work of Timothy Sample (and myself :)
#GnuMes
#bootstrappable
#BootstrappableBuilds
#ReproducibleBuilds
@fsf
@fsfe
#GNU Mes 0.25 released: Supporting the bootstrap for riscv64-linux.
https://lists.gnu.org/archive/html/info-gnu/2023-11/msg00001.html
Thanks to the amazing work of @ekaitz_zarraga and
@stikonas!
#GnuMes
#bootstrappable
#BootstrappableBuilds
#ReproducibleBuilds
@fsf
@fsfe
