Re: Bootstrapping and autotools
2024 m. balandžio 18 d., ketvirtadienis 23:18:53 BST Andrius Štikonas via rb- general rašė: > 2024 m. balandžio 18 d., ketvirtadienis 23:11:41 BST kpcyrd rašė: > > hello, > > > > does somebody know what the bootstrapping status of autotools is? > > It can be done. See https://github.com/fosslinux/live-bootstrap/blob/master/ > parts.rst > > > Also, is something considered "bootstrapped from source" if the build is > > making use of a pre-generated `./configure` script that is 25k lines long? > > Yes, I agree and that's what live-bootstrap does. Sorry, this ended up confusing. I wanted to say that live-bootstrap reuilds all pre-generated files (at least as far as we are aware): autotools scripts, bison/flex files, pregenerated header files, etc... > > > In my opinion something is only "bootstrapped from source" if autoreconf > > is used as part of the build instead of executing some pre-compiled > > `./configure` script. This however means that, to compile bash, one > > needs to compile autotools first. > > No, that doesn't mean that you need to compile autotools first. There are > other options, e.g. you can hand-write makefile. > > Also note that we recently learned that autoreconf -f is not guaranteed to > rebuild all pre-generated files. > > Andrius > > > curious, > > kpcyrd
Re: Bootstrapping and autotools
2024 m. balandžio 18 d., ketvirtadienis 23:11:41 BST kpcyrd rašė: > hello, > > does somebody know what the bootstrapping status of autotools is? It can be done. See https://github.com/fosslinux/live-bootstrap/blob/master/ parts.rst > > Also, is something considered "bootstrapped from source" if the build is > making use of a pre-generated `./configure` script that is 25k lines long? > Yes, I agree and that's what live-bootstrap does. > In my opinion something is only "bootstrapped from source" if autoreconf > is used as part of the build instead of executing some pre-compiled > `./configure` script. This however means that, to compile bash, one > needs to compile autotools first. No, that doesn't mean that you need to compile autotools first. There are other options, e.g. you can hand-write makefile. Also note that we recently learned that autoreconf -f is not guaranteed to rebuild all pre-generated files. Andrius > > curious, > kpcyrd
Re: [bootstrappable] Re: diverse double-compilation
2023 m. lapkričio 14 d., antradienis 11:32:58 GMT HW42 rašė: > I guess you are referring to using stage0-uefi and live-bootstrap here, > right? Or maybe there's also some Guix work on top of it that wasn't > described in the blog yet. I haven't followed the development that > closely or maybe I have missed some announcement. I was thinking about live-bootstrap and Rick Master's kernel: https://github.com/ironmeld/builder-hex0 This is an x86 kernel. It's actually multi-stage and first part is kind of baremetal form of hex0 that uses BIOS calls for I/O. It can then load proper builder-hex0 which can take us all the way to tcc and ext4 userspace tools that are used to build and boot into Fiwix kernel which is good enough till we can bootstrap Linux. I guess stage0-uefi is similar but it's just stage0, doesn't go beoynd that, we haven't ported GNU Mes to UEFI. > Simon > signature.asc Description: This is a digitally signed message part.
Re: GNU Mes 0.25 released
2023 m. lapkričio 14 d., antradienis 14:27:11 GMT aho...@0w.se rašė: > The term by itself does not even mention the programming language(s) > involved. That's because the process involves multiple languages. Do you want it to be called Bootstrap of C/C++Bash/Perl/Bison/Scheme/... (and many more) > > My quick search of a definition on the web did not uncover anything like > your suggestion of the "very thing" either. > > > So by citing some other project that allegedly got there first, by > > depending on an already existing C development toolchain; it seems like > > comparing apples to oranges or maybe even broccoli. > > The blog pretends to be "there" first, you are trying to redefine "there" > to fit Guix but not VSOBFS. > > * Why is the use of a random C toolchain in a solution "less of a > solution" than a use of a random binary loader? How do you verify the > latter without doing the bootstrap on various loaders and comparing > the result? You read the loader. E.g. hex0 on x86 is 256 bytes (and not insignificant part is elf header). At these sizes well commented machine code is readable: https://github.com/oriansj/bootstrap-seeds/blob/master/POSIX/x86/hex0_x86.hex0 (or https://github.com/ironmeld/builder-hex0/blob/main/builder-hex0-mini.hex0 for baremetal version) and if you look at binary file it's in 1-to-1 correspondence to source file (except for comments that are not in binary file). > * How is the result (if reproducible and verifiable all the way) > of one of those routes better than the corresponding result of the other? Of course it is reproducible. In fact reproducibility is far easier to achieve, because you don't have any unknowns (and paths in particular) coming from initial toolchain. > * Both of the contending platforms (Guix and VSOBFS, alphabetical order) > can be used to bootstrap further into anything else and/or each other. > In this meaning they are equivalent. > > The feat accomplished and presented in the contended blog > entry is making a certain almost-fully-from-source bootstrap to > host a Linux distribution. That's nice. > > At the same time the blog in question goes out of its way[2] to create an > impression that there haven't been any from-source-bootstrap-solutions > comparable to the one it talks about. > > This is very far from a fair depiction and this is where the potential > for distrust and flames comes from. > > In other words, the blog strikingly pretends that VSOBFS never > existed, despite VSOBFS having presented a pedantic solution to > source-only-bootstrap and illustrated that a binary seed is redundant. > > > and replying to each > > and every post referencing the alleged "false claims" seems actively > > disruptive to me. > > A post publicly promoting an untrue priority claim, in this case regarding > "Full-Source Bootstrap", is an insult against someone having made a > substantiated corresponding claim earlier. > > Notably, this insult has been repeated despite my protests. > Yes, I try to be actively disruptive against unfair practices. > > Misrepresentations disorient the actual people who the solutions are > meant to benefit. They affect also where public resources are invested. > > I do not chase any funding but I care about being recognized as the first > at full-source Unix/Posix bootstrap. When was it released? > > > live well, > > vagrant > > Regards, > an > > [1] "a form of stipulative definition which purports to describe the true > or commonly accepted meaning of a term, while in reality stipulating > an uncommon or altered use, usually to support an argument for some view" > https://en.wikipedia.org/wiki/Persuasive_definition > > [2] For a casual reader, this is what caused my reaction: > "[...] something that had never been achieved, to our knowledge, since the > birth of Unix. > We refer to this as the Full-Source Bootstrap" > > signature.asc Description: This is a digitally signed message part.
Re: [bootstrappable] Re: diverse double-compilation
Hi Martin, Diverse double-compilation kind of doesn't make sense (or is superseeded) in the context of full source bootstrap. DDC works in the following way: you start with a "trusted" compiler A and "unknown" compiler B Then A->B->B and B->B should produce identical hashes in the last stage, which would mean B is trusted. What is a "trusted" compiler in the bootstrapping context? We can define "trusted" compiler to be the one that is bootstrapped from a tiny binary seed, say compiler A was built from hex0, so it is trusted. If you start doing 1st DDC chain A->B, you have just bootstrapped B and now B is automatically trusted, so there is no more need to do another step and compare with just B->B. By the way, live-bootstrap [1] might be the package pipeline that you are looking for (that is readily usable for applications). It produces fully reproducible (mostly static) binaries that are needed for modern system (including GCC13) and is also used as a starting point in building Freedesktop SDK (that is then used for most Flatpaks). [1] https://github.com/fosslinux/live-bootstrap/ Kind regards, Andrius 2023 m. lapkričio 13 d., pirmadienis 06:27:02 GMT Martin Monperrus rašė: > Hi Vagrant, > > For example, I look forward (with a long view) to a bootstrap path that > > embeds diverse double-compilation as part of the bootstrap > This resonates here! We're also looking for DDC of GCC in a package pipeline, > that is readily usable > for applications. > > Should anybody have pointers, thanks a lot > > --Martin > > > > > signature.asc Description: This is a digitally signed message part.
stage0-posix release
Hi, I would like to announce a new stage0-posix 1.6.0 release. Note that current stable release of mes is not fully compatible with stage0-posix 1.6.0 but we should soon have mes 0.25. For the list of main changes see https://github.com/oriansj/stage0-posix/releases/tag/Release_1.6.0 Thanks to all people who contributed to it. Tarballs with their sha256sum's and gpg signatures * stage0-posix 1.6.0 (combines all components) https://github.com/oriansj/stage0-posix/releases/download/Release_1.6.0/stage0-posix-1.6.0.tar.gz 9260ff69278366e5c056af7b8c436b74773eaa1330a0c6a6b8ab1b5f92e5065c https://github.com/oriansj/stage0-posix/releases/download/Release_1.6.0/stage0-posix-1.6.0.tar.gz.asc * M2-Planet 1.11.0 https://github.com/oriansj/M2-Planet/releases/download/Release_1.11.0/m2-planet-1.11.0.tar.gz 683c5e7d9e22104334c3caba5a8dab8ff6f8c05057a64ee5f6b25755ca05a1b0 https://github.com/oriansj/M2-Planet/releases/download/Release_1.11.0/m2-planet-1.11.0.tar.gz.asc * M2-Mesoplanet 1.11.0 https://github.com/oriansj/M2-Mesoplanet/releases/download/Release_1.11.0/m2-mesoplanet-1.11.0.tar.gz 3c9bcb55e48a22a40efa18b804401f5ca46a6363744e31cc24fd572047f9808f https://github.com/oriansj/M2-Mesoplanet/releases/download/Release_1.11.0/m2-mesoplanet-1.11.0.tar.gz.asc * mescc-tools 1.5.0 https://github.com/oriansj/mescc-tools/releases/download/Release_1.5.0/mescc-tools-1.5.0.tar.gz 009c8cc171d9f238bcca12bcae86e7bcb9be7083bb8c46536772652f15fd4cee https://github.com/oriansj/mescc-tools/releases/download/Release_1.5.0/mescc-tools-1.5.0.tar.gz.asc * mescc-tools-extra 1.3.0 https://github.com/oriansj/mescc-tools-extra/releases/download/Release_1.3.0/mescc-tools-extra-1.3.0.tar.gz df8e6e1a8ec854bb51c1288772ef9d2fc1dbf5cf8a31c6c8b7c9b27e25b8b326 https://github.com/oriansj/mescc-tools-extra/releases/download/Release_1.3.0/mescc-tools-extra-1.3.0.tar.gz.asc Best, Andrius signature.asc Description: This is a digitally signed message part.
