IRC channel logs
2024-05-21.log
back to list of logs
<matrix_bridge><Andrius Štikonas> Bridge room is also aliased to #bootstrappable:kde.org <Googulator>fossy: what's the reasoning behind the sbin->bin merge in live-bootstrap? It seems to be a rather nonstandard configuration. <stikonas>so there is no point of splitting programs that are only available for root <Googulator>Just hope it won't come back to bite us when bootstrapping something on top... <Googulator>just like how linking almost everything statically is already causing headaches there <Googulator>well, not static linking per se, but the combination of static linking and Musl <Googulator>(Musl disables dlopen support when it's built statically) <stikonas>well, if necessary, we could switch to glibc in the late bootstrap... <stikonas>or just start using more of the dynamic linking... <stikonas>Googulator: not sure if you saw it yet but riscv userspace bootstrapping is now possible <stikonas>first of all because it depends on tcc mob... <Googulator>I'd also like to do a "pivot-to-x64" option on the same codebase as riscv64 support <stikonas>the biggest are already merged with 0.26 <Googulator>where we start out using a 32-bit userland, and then either build the Linux kernel already 64-bit, or build an initial 32-bit kernel, then build and kexec over to a 64-bit version <stikonas>yaeh, bit-switching might be useful in some cases <Googulator>& of course, using ekaitz's tcc & gcc also for pure x86 <stikonas>e.g. right now if you start bootstrapping on UEFI (with preexisting kernel), you can't do kexec to linux kernel from live-bootstrap <stikonas>we haven't done much testing of that gcc for x86 <ekaitz>i think my changes in tcc don't change anything in x86 <ekaitz>but i made a fix in x86's extended asm <stikonas>but in the worst case x86 can use upstream gcc 4.6.4 <ekaitz>i don't think i changed anything there either <ekaitz>in fact, now it should have also musl support for x86 <ekaitz>but i didn't make that perfect probably <stikonas>well, integration into bootstrapping projects will test everything more... <stikonas>well, I should still look at longjmp problem in meslibc... <Googulator>out of curiosity, why was 4.6.4 selected instead of 4.7.4? <stikonas>Googulator: I think ekaitz selected it because it had split tarballs <stikonas>i.e. you can just take core and C++ separately <stikonas>though arguably if we area making our own fork, we could do the same with 4.7.4... <Googulator>assuming 4.7.4 didn't rearrange the code in a way that makes that harder <Googulator>e.g. makefiles assuming that every source component is present <stikonas>or maybe it's vice versa and riscv patches apply fairly cleanly to 4.7.4... <ekaitz>i also used that because i was told to <ekaitz>but yeah it's the latest modular distribution <stikonas>the good thing is that at least I don't think 4.7.4 gives us much more over 4.6.4 <Googulator>but modularity is indeed really useful for maintaining the 256MiB footprint target <stikonas>but 4.6 already unlocks as new kernel as 4.7 <Googulator>most importantly, 4.6.4 already unlocks Linux 4.19 <stikonas>oh that just build project is strange... <stikonas>I don't see any advantages over proper bootstrapping <Googulator>the next SLTS, Linux 5.10, is unfortunately impossible, unless we can backport the necessary GCC 4.9 compiler features (and make gcc-bootstrap lie about its version) <Googulator>for the 1.0 release, OpenELA supports the 4.14 kernel "at least until the end of 2024" (hopefully we can roll out 1.1 before that happens) <stikonas>otherwise your new checksum file will be missing some entries <Googulator>assuming you're using --update-checksums to update checksums <stikonas>though right now we have too many entries (base.tar.bz2 is included in the final list) <stikonas>well, when some library changes (musl or mes) you basically have to do that <Googulator>realistically, in the overwhelming majority of runs using it, --update-checksums actually means "I don't want to fail for checksum changes, but also don't care about the final checksums" <Googulator>perhaps skipping the final checksum update step if --build-kernels wasn't also specified <stikonas>well, final checksum update is inside chroot anywya <Googulator>noticed this while debugging another issue where bash-5.2.15 would proceed straight to the extraction phase, skipping the download, and then fail because the tarball didn't exist, if I changed the 2nd build of musl-1.2.4 to build dynamic libraries