IRC channel logs

<Googulator>Seems like I managed to avoid that weird Guile bug by not using --target and --system together - just --system alone is sufficient to force an AMD64 build on an x86 host userspace (I've already built an AMD64 kernel, so no issue there)

<Googulator>specifying both --target and --system caused 2 separate versions of glibc-mesboot to be built, and the 2nd one failed with that weird error

<Googulator>Is Vala's bootstrapping being tracked anywhere, besides Guix's issue https://issues.guix.gnu.org/56584 ?

<Googulator>The standard build "bootstraps" it from .c files generated by Vala's own transpiler, included in release tarballs

<Googulator>i.e. blatant pregenerated code

<Googulator>Looks like we have a working bootstrapped Guix installer image ;)

<matrix_bridge><Andrius Štikonas> Googulator: probably no... Though I've seen it briefly mentioned here

<matrix_bridge><Andrius Štikonas> No work done though

<janneke>hi!

<janneke>i'm having two puzzles/questions

<janneke>there's this commit

<janneke>XXX DRAFT mescc: Use long-r when extending unsigned 4-byte integers.

<janneke>which' message says

<janneke>This breaks 16-cast, 17-compare-unsigned-le in x86_64

<janneke>i guess we need this for RISC-V; should we set 16-cast and 17-compare-unsigned-le to XFAIL on x86-64?

<janneke>(haven't checked this remark, just reading from the commit msg)

<janneke>it would be bad if x86_64-linux breaks, even if we're not really using/supporting it yet in the bootstrap

<janneke>then there is the 80-setjmp.c test; does/will it pass for the regular guix package that builds with gcc and m2-planet using ./configure --bootstrap?

<janneke>(and if so, [why] wasn't that a problem before building the regular guix package?)

<janneke>i'll postpone/move putenv to the gcc-4 branch, i also already had a putenv stub there

<oriansj>Googulator: yeah, no one has taken the time to solve the Vala yet but most likely a version chain will solve that.

<janneke>* ./configure --with-bootstrap

<oriansj>as it was originally bootstrapped in C and one need only build the chain out in guix to solve it (assuming no Bison like bad bootstrapping behavior)

<Googulator>Working LB->Guix bootstrap, produces a usable 64-bit Guix installer: https://gist.github.com/Googulator/338cce370b2e2a65f23e4f6a5b5c3881

<Googulator>next step, replace Guix's bootstrap binaries with ones we can reproduce

<civodul>as in https://guix.gnu.org/manual/devel/en/html_node/Preparing-to-Use-the-Bootstrap-Binaries.html#Building-the-Bootstrap-Binaries ? :-)

<Googulator>Unfortunately this doesn't reproduce the binaries currently in use - indeed even guix time-machine can't go back far enough for that

<Googulator>also, we need to build the bootstrap binaries both inside and outside Guix, with identical results

<Googulator>otherwise it's another chicken-and-egg

<civodul>yeah, right

IRC channel logs

2024-06-03.log