<bauen1>stikonas: your rootfs.py script is nice, but lacks some feedback (more on that tomorrow) <stikonas>if it wasn't present in rootfs.sh, it's not regression :) <OriansJ`>well I got tests 000 to 009 working in mes-m2 <OriansJ`>test010 however is a bit of a problem because quasiquote isn't implemented in mes.c but I guess I'll deal with that later <OriansJ`>(probably have to define a minimal boot.scm which provides quasiquote) <OriansJ`>(or I'll have to port the C version of quasiquote that I previously wrote to mes-m2) <OriansJ`>I guess cond isn't a primitive either, so guess I need to fix test017 <OriansJ`>or move load-module to test010 and write a cond definition in terms of if and stick to pure guile syntax for the remaining tests <OriansJ`>although guile can't do (define (display n) (display n)); mes.c can so why do core:display when you can define display in terms of a more primitive display? <OriansJ`>ok mes/module/mes/boot-02.scm loads just fine but mes/module/mes/boot-03.scm segfaults <OriansJ`>ok boot-03.scm fixed by doing (primitive-load (open-input-file "/dev/stdin")) instead of (primitive-load 0) <OriansJ`>or even just plain (primitive-load "/dev/stdin") <OriansJ`>up to test017 working (except 10 of course) <OriansJ`>So progress being made; just haven't figured out the cause of the segfault yet. <OriansJ`>I guess I'll hammer more tomorrow (unless someone else spots the problem first) <bauen1>stikonas[m]: so rootfs.sh was verbose and actually showed me what is was doing, the python one doesn't <stikonas>bauen1: oh I see what you mean. Yes, we can add some more print() stagements to make things more verbose <bauen1>also i've noticed that live-bootstrap has this odd dependency on env = { PATH="/bin" } ; not sure why <stikonas>bauen1: this is known and fix is clear, I just didn't get to it yet <stikonas>that's PATH=/bin is needed to find chroot binary <stikonas>ideally we would run in empty environment with just env -i <stikonas>so we need to find where chroot binary is located and use absolute path <stikonas>it was actaully running with even more poluted environment <bauen1>stikonas: if you hardcode chroot path and remove the PATH= then the chroot and initial few steps of build will succeed but eventually kaem will terminate with failure during the early stages (long before bash) <stikonas>because it runs just fine in qemu which clearly has no initial environment <stikonas>bauen1: well, what would set the environment in qemu? <bauen1>i wouldn't be surprised if the kernel does it <stikonas>at least on my current system environment of pid 1 is really small <stikonas>TERM=linuxBOOT_IMAGE=/rootfs/boot/vmlinuz-5.10.27-gentoo-gnuintel_iommu=on <bauen1>i'll look into what exactly went wrong <stikonas>(my output was from cat /proc/1/environ but inside live-bootstrap /proc is not mounted) ***pgreco_ is now known as pgreco
<stikonas>pder: maybe it's worth upstreaming your mes crt1 fix? <fitzsim>is anyone working on ppc64le support for mescc? <fitzsim>Guix ppc64le support is making progress, which I was happy to see <stikonas>hmm, riscv will probably be trickier in later bootstrap stages <stikonas>(tcc, binutils-2.14, and gcc I guess don't support it) <bauen1>tcc has some support for risc-v in mob <bauen1>or you could do some x86-to-risc-v emulation layer up until you have a gcc that can cross compile to risc-v again <bauen1>funny, i could work on a "risc-v to x86 transpiler for static binaries" this semester so maybe lol <bauen1>wait no that's the wrong way around <wumpus>yup i noticed that tcc has been adding riscv support (64 bit, the same i'm focusing on), agree gcc is likely going to be an obstacle; also thought of the x86 transpiler thing but thought it would be too circuitous, but if it is acceptable as a temporary solution at least, it seems more straightforward than porting fully fledged riscv support so far back <bauen1>that's the nice thing about having all the pieces laid out in front of you: you now know where changes are necessary, and in the best case can optimise the bootstrap or change it to add new architectures more easily <stikonas>wumpus: well, gcc 4 might be doable, it's not too old <wumpus>very likely less bad than 2.95, is the problem that tcc cannot compile it directly <stikonas>wumpus: and tcc can compile it directly just fine <stikonas>I've built 4.0.4 directly and with no pregenerated files <stikonas>that means not using shipped configure, Makefile.in, config.h files, no bison/flex prebuilt files <wumpus>oh perfect that's very enlightening <stikonas>it's slightly out of date though, and was never 100% accurate <stikonas>bottom of the graph has much better dependency arrows, but later, once autotools are used, it's probably quite inaccurate <wumpus>understandable, it becomes so complex there <bauen1>stikonas: if you want to improve the autotools part you can take a look at my add-gnu-stow branch that specifies the concrete version of autotools used in every script <stikonas>hmm, I probably won't update that graph right now... <stikonas>and I'm doing some refactoring at the bottom <Hagfish>i've not kept track of all the great ideas being implemented right now <Hagfish>is stow actively being pursued as something like a package/dependency manager? <Hagfish>and what is the refactoring that's planned for the bottom steps in the graph? <bauen1>Hagfish: if you want to test something with stow i can also pr my commits that add stow and chroot to live-bootstrap <Hagfish>i don't really have an environment for testing things, but i've enjoyed reading the diff <bauen1>oof i messed up rebase and now github thinks i've made all those commits by other people ... <bauen1>well i'll be pushing a rebased onto latest master with rootfs.py momentarely <bauen1>Hagfish: a replacement for rootfs.sh <Hagfish>it actually has some great comments in it too, thank you <stikonas>Hagfish: rootfs.py is just because shell is not really ideal language for anything more complicated <Hagfish>what version of python does it need? <bauen1>stikonas: so i've reproduced the error, not sure if it's due to wrong user namespace / chroot setup, but `../bin/kaem --verbose --strict -f mescc-tools-full-kaem.kaem` exits with an error (without any additional output) when the env used to enter the chroot is empty <stikonas>Hagfish: not sure, I guess any recent 3.x would work <stikonas>bauen1: hmm, so that's even in stage0-posix... <Hagfish>i was mostly wondering in terms of how "self-hosting" the repo is, even if that's not something that's needed in practice <stikonas>well, we haven't bootstrapped python yet... <stikonas>but in any case live-bootstrap system is not really ready yet <Hagfish>python looks relatively sane in terms of bootstrapping <stikonas>yeah, python should be almost buildable (might need to build some dependencies like openssl first) <bauen1>let's actually test it then, see you in ~1-2h lol 