<stikonas>hmm, that bash 5.1 is a bit broken... I'll have a fix though <fossy>stikonas: if you don't mind, i'll do this one a bit more in-depth than some of the other simpler ones, as GCC 4.0.4 is a pretty big piece of software <fossy>but i will take a look today <stikonas>I still couldn't get dynamic linking to work, so static only for now <stikonas>(something was wrong with relocations when I tried dynamic linking) <pder>stikonas: nice work! will take a look soon <Hagfish>has it really increased in duration that much? <Hagfish>i guess it takes as long as it takes and there's not much that can be done to optimise things without changing the upstream sources <Hagfish>oh "Rebuild GCC against latest musl." <Hagfish>so there are two builds of gcc in there, that makes sense <Hagfish>test -f /dev/null && rm /dev/null && mknod -m 666 /dev/null c 1 3 <Hagfish>what permissions do you need for doing stuff with dev/null like that? <Hagfish>anyway, the PR looks great, from my limited understanding <Hagfish>i guess there isn't any point trying to reduce the duplication between pass1.sh and pass2.sh using something like inheritance <Hagfish>maybe if there was a pass3.sh then the "rule of 3" would encourage taking another look at that ***mephista is now known as spicy_icecream
***mephista is now known as spicy_icecream
<stikonas[m]>Hagfish: it's much quicker on my machine. Anyway, ci was already taking 1h15 min... <stikonas>and this is actually the first bash build (before GCC) <fossy>stikonas: i am looking at that now. i just noticed also <fossy>checksums file seems to be correct <stikonas>well, I think my gcc rebuild checksums don't match either (but that might be because of how I obtained them), so I'm rerunning it now and might force-push <fossy>do you mean force push ur gcc branch to retrigger CI there <stikonas>yeah, I obviously wouldn't force push to published branch :D <stikonas>I remember a couple of times people did it in my work... Usually that breaks more CI stuff than expected ... <fossy>i cant really think of any time when it would be nessecary <fossy>maybe if there was secret data pushed? <fossy>or a massive file in commit history? <stikonas>no, just something minor (I guess thought quickly force push some minor fixed before anybody pulled) <stikonas>probably newer GCC... and maybe with C++ <stikonas>oh, maybe I can try to get newer libtool... ***ChanServ sets mode: +o rekado
<stikonas>Hagfish: by the way, regarding timeout, it might be possible to optimize it if we redirect output to build logs... <pder>stikonas: do you think its best to stay with musl for now until a newer gcc is built or try to switch to glibc? <pder>Also, is bash 5.1 pass1 of any use or could it be delayed until after gcc? <stikonas[m]>And I'll check bash.... Tcc miscompiled bash 5.1, so I had to rebuild <stikonas[m]>Or maybe we can remove it completely like you suggest... <pder>The only things you are building when you have tcc compiled bash 5.1 are automake-1.9.6 and gcc pass1 <pder>In any case, this is really exciting progress <pder>In gcc pass1 I notice you run autoconf-2.61 in libmudflap directory but then disable it in configure. Maybe not needed? <pder>I think CFLAGS should probably be changed to CPPFLAGS especially since we might soon have a c++ compiler <pder>And would want any preprocessor defines to apply to both gcc and g++ <pder>in gcc pass1.sh line 69: should LIBGCC2_INCLUDES now be ${prefix}/include without the musl subdirectory? <stikonas[m]>Yeah, maybe not needed to run autoreconf but I thought better be safe <pder>Yeah, CXXFLAGS are specific to C++ and CPPFLAGS apply to both C and C++ normally <pder>CPPFLAGS is for the preprocessor <stikonas[m]>Well, hopefully we won't need to tweak them too much manually <pder>That's true. I tested building bash 5.1 only after gcc and that works. <stikonas>maybe it's also worth building bash after musl... <stikonas>for now we use static libraries, so it makes sense to build C library as early as possible <pder>that diff doesnt include renaming the checksum and making pass2 pass1. <stikonas>I'm just back to my laptop today, so will not start running things <stikonas>hmm, messed up something: install: too few arguments <stikonas>pder: do you think we should build tar 1.22? <stikonas>I think our autotools allows us to build it <stikonas>I guess we should rebuild at least tar, gawk, coreutils and libtool <pder>tar 1.22 definitely makes sense. Current tar is from tcc-mes and old <pder>gawk and coreutils should be straightforward too I think <stikonas>yeah, although, we might want to build newer version <stikonas>well, for coreutils we can either go with 6 which we already have <Hagfish>maybe the bootstrap process should document the SWHIDs of each input ***Noisytoot is now known as LPBot_
***LPBot_ is now known as Noisytoot
<Hagfish>wow, and there's actually an implementation of an append-only log for signed software releases <bauen1>Hagfish: i've rambled a bit some time ago about how you can use a basic hash tree to skip reviews / reduce the code you need to review every time <Hagfish>yeah, in theory it should help auditors focus on just the changed lines (although i'm sure there are clever malicious tricks that can be done by ignoring context) <bauen1>and basically you don't need to do very advanced things (and you don't want to), every time you "do" the bootstrap you verify by hand that hex0, a small editor, maybe cat and a hash implementation are correct <Hagfish>i guess if you trust the bootstrap code, then you trust its hashes <bauen1>from a previous bootstrap you still (have remembered) the root hash of the tree and you copy the tree, verify that the root matches what you remembered and then you can verify that the hash of source code still matches what is in the tree before compiling <bauen1>then you just go from there, if you need to change something of course the source code hash changes and you need to remember that <bauen1>after you're finished you just need to remember e.g. a sha256 sum of your tree, and have a copy of the tree source some where you can access (but doesn't have to be secure) <Hagfish>i'm not sure what the use case is for doing the bootstrap multiple times <bauen1>Hagfish: perhaps you've created a small patch that removes the need for a component, you've lost confidence in your existing system (e.g. integrity comprimised one way or another) <bauen1>or maybe you want to add additional checks along the way <Hagfish>yeah, i guess it's useful when the bootstrap process itself is still being improved <bauen1>Hagfish: you might also have to take a break in the bootstrap process because it's so long, and you don't want to loose your progress <bauen1>and another scenario is that you have a trusted computer and a bit of trusted storage, but not enough for your entire source code, so you review it hash it add it to your tree and can grab the source code from an external medium (e.g. an http server) at a later time again without reviewing it <Hagfish>it will be interesting to see what sort of constraints emerge when people try running the process on their hand-soldered machines :) <bauen1>i'm sure you can find some smart ways around some of these problems too <bauen1>also i'm seeing you're still making good progress (gcc 4 sounds very nice) <Hagfish>yeah, gcc 4 is a fantastic milestone <Hagfish>i'm not sure what would be a good "finishing line" where we could point at the work done by this community and say that a specific version of the bootstrapping problem has been solved <Hagfish>to some extent the work will never be done, as more architectures are supported, and invented, but it's good to celebrate milestones <Hagfish>i guess "self-hosting" might be such a well-understood milestone <Hagfish>but there are questions about how basic you can make the host environment <stikonas>well, in any case this is minimal gcc 4 without C++. But I'm sure building more stuff will be significantly easier... <stikonas>even as C compiler, GCC should be significantly better <Hagfish>there are probably still people out there running machines that only support gcc 4 without C++ <Hagfish>it would be interesting to know what approach they would take from here, but i'm hopeful the path ahead is no more complicated than the journey so far <stikonas>still, 4.0.4 is also significantly newer than 2.95.3 <stikonas>pder: I briefly tried to build tar 1.22 and it fails, some problem in getdate.c (generated from getdate.y), although, one option is to just use your getdate stub