GNU Mes 0.27 released

[Simon Tournier]

Hi Andrius,

On Tue, 09 Jul 2024 at 23:15, Andrius Štikonas <andrius at stikonas.eu> wrote:

>> Do you mean remove guile-bootstrap from the picture?  The root of this
>> graph:
>
> I think what janneke means (correct me if I'm wrong) is that before now gash 
> and gash utils could only run on guile but not on mes. So that arrow that was 
> pointing from gash to guile-bootstrap will point to mes.

It would mean to have mes-bootstrap (instead of guile-bootstrap) that
would be indirectly used by mes-boot.

Right?


>>     https://www.gnu.org/software/mes/manual/images/gcc-mesboot-graph.png
>> 
>> ?  What’s the plan?  Replace the requirements of stage0-posix provided
>> by Gash and Gash-Utils by increasing bootstrap-seeds?
>
> bootstrap seeds bubble in that graph refers to [1], so it wouldn't be changing 
> as we don't add anything else there.
>
> stage0-posix requirements are related to package manager and/or limitations of 
> source distribution method. If stage0-posix exists in unpacked form, it can 
> run the whole bootstrap chain itself using either kaem-optional-seed [2] in 
> userspace/POSIX bootstrap (e.g. just kernel and initramfs with bootstrap-seeds 
> and source) or builder-hex0 [3] (plus sources) in MBR/BIOS bootstrap (where we 
> bootstrap linux kernel too). And then no guile-bootstrap is needed at all. 
> Both of these problems are already solved on x86 (though now new x86 machines 
> generally come without BIOS and bootstrapping on UEFI is only partially done).

Thanks for explaining.

[...]

> What would be interesting from bootstrapping perspective is to make those 
> additional seeds (guile-bootstrap in particular) fully bootstrappable/
> reproducible not just from inside Guix but also without Guix, so that we don't 
> have chicken and egg problem of how to build guile-bootstrap binary when we
> don't yet have Guix.

Hum, I am missing something, I guess.  Well, from my poor understanding,
one way is what you explained just above or something as “Extreme“
Bootstrapping as discussed in [4], and the other way is to root the
graph in some binary driver (as guile-bootstrap).

For sure, the binary guile-bootstrap could be replaced by another
lighter, smaller and surely more reproducible other binary as
mes-bootstrap but that would not tackle the chicken-or-the-egg problem,
IMHO.  However, it could be nice to reduce again the binary footprint.

Well, from my weak understanding, maybe one direction (but huge work)
would to implement all the features required by the whole graph and
provided by gash-boot and gash-utils-boot directly in auditable binary.
Yeah, it’s a piece of work and I do not volunteer. ;-)

Cheers,
simon

4: https://guix.gnu.org/en/blog/2019/reproducible-builds-summit-5th-edition/