IRC channel logs
2023-01-27.log
back to list of logs
<stikonas>yeah, aarch64 is still not anywhere close <stikonas>well, probably mes/tcc steps are the most problematic <stikonas>python can launch a browser just by running import statement <fossy>hm, after gcc might look at attempting to improve the mes libc->musl transition so that we don't need /usr/lib/musl <fossy>/usr/lib/musl irks me a bit, it's non-standard and adds a bit of annoying complexity <fossy>or perhaps utilise doras' PR to use triplet notation <fossy>that's probably the best way actually <fossy>because that's the standard nowadays <doras>fossy: I can rebase it if you wish. It mostly needs to be expanded to a few additional packages that were added since and have its package hashes recalculated <doras>But we'll need to merge it without much delay qfter the rebase. It touches many files and can easily run into conflicts. <doras>I can maybe rename the LIBDIR variable to something with less chance to affect buildsystems. <doras>Previously I wanted it not to be used as an environment variable, but this requires some work on how the variables we use are preserved when dropping to shell. <doras>stikonas @stikonas:libera.chat: CI passed with static Python, so we're probably fine. <fossy>doras: can we start with #197 actually, could you rebase it? <fossy>btw, HOME & SOURCE_DATE_EPOCH are designed to affect build systems, they are not internal, so we can leave those exported <fossy>(added since you made the PR) <fossy>sorry, #197 and #201 have been on my radar for a while, i just didn't have the time to properly consider them until recently - then i forgot about them :P <doras>fossy: #197 is fine but one thing stikonas noted is that when dropping to interactive shell (after post-bootstrap or due to an error) we lose the variables. <doras>I thought maybe to save the variables to a file similarly to bootstrap.cfg and then include them using the dot operation in each script that needs them, but I ran out of time to experiment with this. <fossy>hm, we can probably jsut have some variable such as ENV="PATH=${PATH} PREFIX=${PREFIX}"... like on line 143 at the beginning of the file, and use that in the trap and exec invocations? <doras>But then the build environment would be different for interactive vs. noninteractive shells. Noninteractive would have a "clean" environment and iteractive would have an environment "polluted" with variables that could be picked up by package buildsystems and result in different hashes. <doras>For example, as you can see with automake and gettext in my MR. <doras>So if we loaded variables in every script individually using the dot operation, like we do for helpers.sh and bootstrap.cfg, then one may consider this issue solved. <doras>I think it should work in theory. <doras>So instead of scripts passing variables to one another using environment variables, each simply includes the same file using the dot operation. <fossy>well, can't we just do the ENV thing for interactive drop-out, and pass variables for after.sh (same as how you do it right now)? <fossy>i have no issues with interactive being different to non-interactive. <fossy>interactive is meant to only really be used for development and playing <fossy>dot operation, yes that would probably work in theory? <fossy>that might be a bit cleaner than the current approach as well <fossy>i have no strong feelings about this though, so whatever makes the most sense <doras>I can try to experiment with it to see if it makes sense. <fossy>If you have the time available, go ahead :) <doras>fossy: we currently have a duplication between SRCDIR and SOURCES. Is this accidental or does it actually serve a purpose? <fossy>i believe accidental, let me check <stikonas[m]>yes, interactive drop-out is mostly for development, though I was proposing to just dump all vars in a file, so that one can easily source them if necessary, otherwise we can keep environment clean <stikonas[m]>whatever people do in interactive environment (e.g. install some distro) doesn't have to be so reproducible as output of live-bootstrap <doras>How does one build a kernel for QEMU properly? <doras>I used the x86_64 defconfig but got a strange build failure in sysb. <pder>I think with live-bootstrap the kernel has to be a 32 bit build, but that may have changed <stikonas[m]>or to be more precise, 32-bit kexec does not work with 64-bit kernel <clemens3>if anyone has a minimal kernel config working for qemu, i would also be interested.. <stikonas>clemens3: the one from live-bootstrap would definitely work <stikonas>but basically anything 32-bit would work <stikonas>I don't remember which config options are required, but it's really just a few (compared to allnoconfig) <stikonas>and soonish rickmasters might even add support for fiwix <Piraty>so this is the place to talk about boatstrip yes? <doras>Not of a fan of this recommendation myself, but spellcheck is complaining about it. <stikonas[m]>I guess I'm fine with ignoring it but let's confirm with fossy <doras>I used a file to pass variables between scripts, allowing interactive shell to simply . /usr/src/.env to get them defined for its context. <doras>Works fairly well, it seems. <doras>I won't rebase the MR to switch from /usr/lib/musl to /usr/lib/i386-linux-musl until this is merged to avoid having to rebase it multiple times. It affects many hashes. <stikonas>yeah, that's fine, let's merge this one first <fossy>yeah, i don't really care for doing any more work on minimising the seed kernel when we're going to strip it out in the near future (hopefully) <oriansj>Piraty: bootstrapping not boatstrip. Is that something of interest to you?