IRC channel logs

<Googulator>back at my computer, Guix build (in chroot'd live-bootstrap) reached Guile 3.0.9, and then died with a test failure - given how far it got, I'd guess this is related to chroot. Will retry on bare metal, which has just got ready for an attempt at a Guix bootstrap.

<Googulator>the failure appears to be getaddrinfo failing within the Guix build environment - this could be chroot-related, or it could be /etc/services missing in that environment (or something else altogether)

<Googulator>looks like we need a real /etc/hosts with at least "127.0.0.1 localhost" in it for Guix to complete tests :)

<fossy>Googulator: regarding sbin->bin; just simplicity; and i think that it is probably the most compatible solution when it comes to bootstrapping things on top was my original thought; but happy to hear otherwise

<fossy>Googulator: also, what's the end goal of #469? Everything required to bootstrap guix, or actually bootstrapping guix? I don't think we want guix in the main path, and we don't have any kind of even de-facto plugin standard yet..

<Googulator>At this point, it's just prerequisite changes to existing packages

<fossy>Okay cool

<fossy>that's totally fine with me then

<Googulator>All the new code used for Guix is in the gist

<fossy>good changes to make regardless anyways

<Googulator>Eventually I do plan to turn the other prerequisites into real live-bootstrap packages, maybe even Guix (the package manager) itself, behind a bootstrap.cfg option

<Googulator>but calling the system image build is definitely not something to put in the bootstrap chain

<fossy>mmm, okay

<Googulator>But #469 is only fixes to enable bootstrapping the rest on top

<fossy>:D

<Googulator>(btw, compiling Guix's scheme files is really slow on real hardware, so it definitely would need to be default-off, if we ever add the option)

<fossy>why "on real hardware"?

<fossy>is that as in not in qemu/chroot or something?

<Googulator>I'm doing bare metal bootstraps on Core 2-era hardware, which I consider old enough that it's unlikely anyone could have hid a hardware backdoor that anticipates how we would use the system for bootstrapping, and subverts it

<Googulator>but new enough that it 1.) has enough performance, and 2.) probably cannot be maliciously emulated on even the most modern bleeding edge hardware

<fossy>Ah, right

<Googulator>Whew, got past another major hurdle: after several successful builds as part of guix's bootstrap, it would try to fetch a clean copy of the Guix Git repository - from the URL #f (as I understand it, that's what Scheme calls null)

<Googulator>turns out, this was caused by 2 separate issues: /usr/manifest wasn't populated (populating it took a lot of trial and error due to sparse documentation on the manifest format), and Guix has a weird behavior where it ignores the manifest if the Guix binary's full path doesn't end with "/bin/guix"

<Googulator>of course, in LB, /usr/bin == /usr/sbin, and /usr/sbin somehow came earlier on the $PATH, so Guix was running as /usr/sbin/guix

<Googulator>with both of those fixed (and an upgrade to libgit2 & guile-git, as there appears to be some 32-vs-64-bit issues in the older version), it's now finally cloning the Guix Git repository!

<Googulator>bad news: libxml2 build successfully (including the Python bindings), but our Python 3.11 fails to load it - because Guix builds it against glibc, which has fcntl64, unlike Musl.

<Googulator>For some reason, the host Python and the host libc get dragged into the build environment at that point, which is a bit surprising to me given how Guix is supposed to work.

IRC channel logs

2024-05-24.log