<achaninja>I made a bit of progress on my own alternate bootstrap <achaninja>I was able to build a working qbe and cproc c compiler <achaninja>cproc is able to build a patched musl and patched gcc 4.7 and <achaninja>so in the end it might be a shorter bootstrap path <achaninja>though its only for arm64, riscv64 and x86_64 atm <achaninja>oriansj: why does the git tag Release_1.5 of stage0-posix have a version 1.3 of stage0 in it? <achaninja>I build it and do kaem --version and get 1.3 <fossy>kernel is looking difficult ngl <fossy>markjenkinssksp: tinycc has quite a few problems for kernels iirc <fossy>achaninja: stage0-posix versions do not match mescc-tools versions which is where kaem is from <achaninja>that is really confusing, especially because the latest release of mescc wants a newer version of M2 than stage0 posix provides <fossy>hmm... are you sure about that? <fossy>we're using latest stage0-posix and mes... <fossy>oh, we might be using head stage0-posix <fossy>no, we updated a few days ago, stikonas[m] did it <fossy>no, that doesn't run under kaem <fossy>what are you running the configure script with? <achaninja>if you get the latest stage0-posix add it to PATH and run ./configure it will failt before you can do anything <achaninja>because it asks for a different version of M2 and hex <fossy>how does one even use the configure script in a bootstrap <achaninja>also my bootstrap assumes the shell is trusted <achaninja>my one assumes kernel + a subset of userspace is trusted <achaninja>so technically I *could* use the configure script, though I am not <fossy>ah ok, so more like guix, where guile/mes are trusted <achaninja>yeah my main purpose is to install software on any linux distro - assuming nothing about the host. <achaninja>but I can and should have a way to cross check with livebootstrap <fossy>after the part where the paths diverge the checksums wont be the same and that sok <achaninja>I can run my scripts from within livebootstrap and cross check the result <achaninja>its a longer chain, but its a way to double check it <achaninja>I'm currently just manually installing the mescc.in and mescc.scm.in <achaninja>but its good news that livebootstrap uses 0.24 with stage0-posix since it shows it still works <achaninja>I manually installed mescc without the configure scripts etc <doras>As far as I can tell, something is broken with the qemu script. <doras>It doesn't actually create a partition on the loop device. ***civodul` is now known as civodul
<fossy>doras: hmm, it should, does your diff touch lib/*.py? <ekaitz>hi all, does anyone know what's the process of calling as from gcc? I have my backported gcc to riscv "working" but when calling as it's setting the options wrong <ekaitz>instead of -k -march=rv64gc it's doing -k-march=rv64gc <ekaitz>can anyone help me find where does that come from? <janneke>ekaitz: doesn't that show when you run gcc -v? <janneke>you may want to look at "gcc -dumpspecs" too <ekaitz>i run it like gcc -v and it has shown me the as call it does <ekaitz>but what I need to know is where is it set to be like that and why <ekaitz>in the define ASM_SPEC I was missing a space before of the newline <ekaitz>omg thanks to the heaven that I found it <ekaitz>i could spend 3 years looking for this <Hagfish>heh, yeah, i think that developer experience is underrated as a goal for most projects <Hagfish>having the right debug tools can pay for themselves in time saved <ekaitz>this one is a really hard one, gcc has many weird things like this <Hagfish>i guess it's a problem like AI, where you want the system to expose its internal logic (and flaws) in a human-meaningful way <ekaitz>yesterday i spent the whole day looking to the build process because it was iterating over a list and ended with an empty value <ekaitz>and it was because it was appending to an empty variable instead of rewriting <Hagfish>yeah, all magic needs a verbose equivalent <ekaitz>this kind of things are a pain in the butt ***lukedashjr is now known as luke-jr
<doras>The loop device doesn't have a "p1". <doras>I found the issue. The losetup command was missing a required argument (-P). ***lukedashjr is now known as luke-jr
<doras>Yes, submitting in a minute. <stikonas>achaninja: you probably would still have to go via quite a bit of steps even with cproc <stikonas>lots of steps are independent of compiler <stikonas>at least if you do no-prebuilt file bootstrap <stikonas>we need to build autotools, perl, bison, flex <stikonas>just that ends up to be about 35 steps in parts.rst <rkeene>That one is hard to build because cross-compiling it is terrible <stikonas[m]>Certainly not very pleasant but better than initially expected <muurkha>Congratulations. You're not using Eunice. <stikonas[m]>And a few iterations of newer and newer versions of Perl... <rkeene>stikonas[m], It requires SSH or serial access to the target system -- there's a patch to add support for a GNU autoconf build that's sane, but it's a PITA <stikonas[m]>rkeene: we don't use Perl's build system or autoconf to build perl <stikonas[m]>Even if it's added to the latest version, that's not good for bootsrapping <rkeene>Ah -- I just didn't use Perl at all in my system because it was so obnoxious <stikonas>so actually even if perl switches to autotools, that's a circular dependency (might be weak circular dependency but still) <stikonas>automake is writen in perl and newer autoconfs are also written in perl (older ones use shell) <doras>"xbps-create: ERROR: architecture not set!" <doras>The line above it is "automake-1.16.3: creating package." <stikonas>hmm, we call xbps-create -A "${ARCH}" -n "${pkg}_${revision}" -s "${pkg}" --compression xz "${DESTDIR}" <stikonas>we do set it in early bootstrap but it probably wouldn't propagate to sysc <doras>ARCH is read from bootstrap.cfg, and I forgot that I made a change to simplify something there. <doras>Basically I don't want to EXPORT it. <doras>Not sure why I used capitals there. <doras>Because then it pollutes the build environment of every single package. <doras>There seems to be XBPS_TARGET_ARCH in the code which specifically exports it for xbps, but this variable is unused. <stikonas>well, you could rename ARCH to something else <stikonas>but a lot of early packages are poluted with env variables anyway <stikonas>all early kaem variables propagate early in the bootstrap <doras>Well, it's mostly a nice addition. I also want to use boostrap.cfg in sysa and sysc as-is without needing to add "export" to every line. <doras>I think it's better to keep these variables local to scripts where they are actually used, rather than export it to the entire bootstrap. It also means we can skip this additional processing. <doras>They are actually rarely used. <stikonas>yeah, I agree about keeping things local <stikonas>we should also switch more variables in helper.sh to local ones <doras>Actually, it seems that helpers.sh does have ". bootstrap.cfg", so it should have its ARCH variable set... <stikonas>yes, that's why I was surprised that we export them <stikonas>maybe you can just remove export and it will work <doras>Oh, that's odd. It seems that my bootstrap.cfg is missing ARCH. <stikonas>doras: ARCH variable is added on that L101 that you gave me <stikonas>it's not present in initial bootstrap.cfg <doras>I removed that part intentionally. <stikonas>because ARCH is already set in stage0-posix <stikonas>and setting it in two places is confusing <doras>So I'll only add it to the bootstrap.cfg, I guess. <stikonas>on a separate note, xbps packages seem quite nice as one can unpack them with just tar/xz <doras>Yeah, this is the explanation :) <doras>Also, another strange thing I just noticed, it seems DISK is added twice to bootstrap.cfg <doras>Once by rootfs.py, and again by sysb/run.sh <doras>Does the QEMU build go though sysb? If so, it explains why I only noticed it now. <stikonas>but DISK might be unset, especially if you bootstrap on real HW <stikonas>and then sysb will interactively ask you what disk you want to use <doras>Can't we only set if it's not already set though? <stikonas>and if I remember correctly, fossy just thought it's simpler to set it unconditionally <stikonas>but I think I might have asked about that before <doras>fossy: I think there can be two cases here: either DISK was set in bootstrap.cfg and then we don't prompt about in sysb, or it isn't set and we do prompt about it. Only in the latter case it makes sense to add it to bootstrap.cfg, otherwise we have it twice there. <stikonas>doras: sysb is used when kernel is built <doras>fossy: it's not harmful or anything, but it's a bit strange. I can remove it if you agree that it's not necessary (I'm already making changes around bootstrap.cfg). <doras>I will be removing its "export", so I'll be touching that line anyway :)