<Hagfish>that's really good advice to give to someone, actually. <Hagfish>you shouldn't expect everyone to always agree with you, even when you're right, but if you can take pleasure from hearing preposterous excuses (and/or proving the doubters wrong) then there's a lot of joy out there to be found <stikonas>hmm, guile is too big to bootstrap in just RAM of live-bootstrap on 32-bit kernel... <fossy>stikonas: thats why im moving to disk <fossy>once I find the correct kernel config settings then it will just work I hope <stikonas>I think I'll push guile to branch for now, but we don't have to merge it right now <stikonas>this is now rebased on top of g++ and no longer needs gperf patched out <Hagfish>"Fortunately, it is easy to patch it out and resulting ``g++`` compiler is capable of building ``gperf``." <Hagfish>i feel like now is the time to start chilling the champagne :) <dongcarl>So it sounds like we just need some tooling to build Guix's bootstrap binaries with live-bootstrap? Most of the big stumbling blocks are solved with the new branch? <dongcarl>Might be helpful, also comes with a visual map of dependencies <Hagfish>that sounds right, and thanks for the document, that looks really thorough, with a very readable diagram :) <Hagfish>"At the time of writing (July 5th, 2021) the systemd unit for "updated Guix" is guix-daemon-latest.service, therefore, you should do the following" <Hagfish>ugh, what a pity to be reminded of systemd in that wonderful document :) <stikonas>dongcarl: yeah, most of the tools are already available in live-bootstrap from that link <stikonas>I think all text transformation/i18n tools are built as part of live-bootstrap <stikonas>build system tools are mostly there except for cmake. Older versions (probably around 3.0) of cmake actually builds on live-bootstrap but latest cmake will first need newer g++, but shouldn't be hard <stikonas>but anyway, it sounds more like "packaging job" than bootstrapping job at this stage <oriansj>Hagfish: if you want something deeply satisfying, go into a meeting with someone who is willing to do the setup. Suggesting that the project you are working on failed. Then the target proceeds to claim it is all your fault and you never listened to them. Then wait a beat, say I take full responsibility for the outcome of the project. Wait another beat and then drop the boom that you successfully completed the project ahead of time, <oriansj>underbudget and delivered thanks to the efforts of *named people other than target* and watch them try to claw back credit. ***Noisytoot_ is now known as Noisytoot
<stikonas>one interesting thing about live-bootstrap was that we didn't know in advance where we will end up. Initially goal was to build gcc 2.95.3 then glibc and go from there. In the end musl was built really early and then gcc 4.0.4 was built directly and somehow we stayed with musl libc there. Of course glibc should be easily buildable now... <stikonas>(if somebody needs to bootstrap glibc based distro) <oriansj>stikonas: I like to think of it as we don't need a plan, we just do awesome shit that looks like fun. <stikonas>hmm, something actually goes wrong in live-bootstrap when I run in qemu mode (as opposed to chroot) <oriansj>stikonas: 2 guesses: 1) you ran out of disk space or 2) you ran out of RAM <Hagfish>oriansj: i would love to watch that meeting, apart from the feeling of cringe as the target tries to dig themselves out of their hole <stikonas[m]>fossy: haven't tried yet, maybe it's indeed RAM... Linkers often use a lot <fossy>seems to take a very long time to unmount the disk though. probably syncing some buffer <fossy>given that it mounted successfully. just need to make sure it actually boots into it now <fossy>i took ubuntu's 6.04 kernel config instead of using defconfig <stikonas[m]>If RAM, then your work would automatically solve it... <fossy>depends if you mean full initrd or just using up all the ram <fossy>i doubt it is using up all the RAM tho cause it's not multithrea <fossy>hm. need to disable all of these stupid CDROM drivers <fossy>the kernel detects the drive on boot which is perfect but dosen't mount it - guessing it doesn't know fstype. i'll give it some help ***rt is now known as robin
<stikonas>yes, I think it was lack of RAM, g++ builds fine when I give qemu 10g ***mihi_ is now known as mihi
<stikonas>hmm, guile branch in live-bootstrap also has some problems with reproducibility, I get different hashes for libffi...