IRC channel logs

<Googulator>oh, and somehow it would only happen in chroot mode, not with kernel bootstrap

<Googulator>src_get is missing from the unset list :)

<Googulator>which means, if a build script overrides it, that override persists until either another script overrides src_get, or we move to a new bash process (by switching to a new kernel or a new build of bash)

<Googulator>the only scripts that actually override src_get are kexec-linux, and musl-1.2.4 pass1

<Googulator>which pass2 symlinks to

<Googulator>so from kexec-linux to musl pass2, src_get is effectively disabled

<Googulator>then musl pass2 (identical to pass1 except for the patches used) resets src_get to a functional version, so when we get to bash-5.2.15 (the first package to be downloaded over the network), we can src_get again

<Googulator>(and then we switch bash, so the override is cleared)

<Googulator>but to make the pass2 musl dynamic, I changed the symlink to point to pass3 instead, which doesn't override src_get, so kexec-linux's override stayed in effect for bash-5.2.15 in chroot mode

<stikonas>hmm, using subshells would be better...

<stikonas>but at some point there was an issue with some traps...

<Googulator>outside chroot, the override is cleared by an intervening kexec step, so it didn't happen in qemu or bare metal mode

<Googulator>but the funny thing is, the entire src_get override in musl-1.2.4 pass1 is obsolete, since the preservation of source tarballs needed between Linux build and network buildup is now handled elsewhere

<Googulator>except, deleting it would have triggered this bug without me monkeying around with the pass2 symlink

<stikonas>well, good spot

<pabs3>Googulator: IIRC Arch merges bin/ sbin/ and Fedora/Debian are thinking about it too

<pabs3>I expect like usrmerge, it will become the standard for distros

<Zopolis4>last time I checked debian usrmerge faq (https://wiki.debian.org/UsrMerge) it said there weren't any plans to merge the two

<Zopolis4>although that page may be out of date

<pabs3>yeah, there were some discussions in the last few months

<Googulator>MILESTONE: "make -j8" running for Guix on top of live-bootstrap as we speak! See https://gist.github.com/Googulator/338cce370b2e2a65f23e4f6a5b5c3881

<Googulator>(although I tried to regenerate build systems, I can't vouch for pregens in this - in particular, I'm pretty sure Guix's make process at some point downloaded / will download a binary bootstrap-guile...)

<Googulator>and of course, it's still building as we speak, so no guarantee it will even finish :)

<stikonas>Googulator: yeah, it will be using all the Guix bootstrap seeds

<stikonas>so bootstrap guile, bash, xz and a few others if I remember correctly

<stikonas>mkdir and tar too (https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/bootstrap.scm#n110)

<stikonas>if you want to bootstrap those properly it is a much harder process

<Googulator>yeah - that's gonna be another task to replace those with new ones

<stikonas>I think luke-jr has done it

<stikonas>I think you need to replace them with your binaries. (that will cause all guix output hashes to be different) and then you ask guix to builds those guix bootstrap binaries

<stikonas>not as easy as Gentoo to bootstrap without binaries...

<Googulator>the eventual goal with this is a reproducible Guix install ISO image not derived from any outside binary (except for builder-hex0-x86-stage-1 of course)

<Googulator>I wonder if the "graft" feature can help us here

<Googulator>if I understand it correctly, it basically allows a package to be replaced with a newer version without changing the hash of dependent packages

<Googulator>originally intended for security updates

<stikonas>hmm, perhaps you can graft bootstrap-seeds then

<stikonas>but I'm not familiar with grafting there

<Googulator>bootstrap-seeds is not the problem package IIRC

<stikonas>well, I meant those seeds from bootstrap.scm...

<stikonas>but yeah, hashes in guix work very differently from the ones in live-bootstrap

<stikonas>in live-bootstrap it's hash of output binaries

<Googulator>guile-bootstrap is the evil one

<Googulator>bootstrap-seeds is just the stage0 seed, "blessed as source"

<Googulator>it seems the other binaries aren't considered packages by Guix

<stikonas>yeah, so you won't be able to graft them

<Googulator> https://git.savannah.gnu.org/cgit/guix.git/commit/gnu/packages/bootstrap/i686-linux?id=4c0d38bee3a4b264490f33adf45bb226c110716c is where the binaries come from

<Googulator>(unfortunately not much info provided on how they were built...)

<Googulator>Got as far as actually building and installing Guix itself, but then "guix build"s would all fail due to bwrap's "fake root" user - retrying on bare metal with real user management :)

<Googulator>for reference, the script for reproducing this is https://gist.github.com/Googulator/338cce370b2e2a65f23e4f6a5b5c3881 and it requires https://github.com/fosslinux/live-bootstrap/pull/469

<stikonas>Googulator: there is a package bootstrap-binaries

<stikonas>I think it's that one

<stikonas>but you might need to use specific guix commit to build it

<Googulator>nope, that one is a lie

<stikonas>ask on #guix then...

<Googulator>it's part of the old bootstrap chain, before full source

<Googulator>I mean, the actual binaries used were apparently built in 2013

<Googulator>and then uploaded to their present location in 2015

<Googulator>for now, I'd like to see a successful "guix build" or "guix install" regardless of bootstrap binaries involved, before moving further

IRC channel logs

2024-05-22.log