<stikonas>well, hopefully fewer mass rebuilds in the future <stikonas>this one fixes quite a few problems that we observed before... <stikonas>well, weak sybols are hacky but so far seem to work <stikonas>might be a good idea to rebuild after binutils <stikonas>hmm, but so far perl doesn't look that scary <stikonas>(need to rebase on top of cp and musl PRs once they are merged) <stikonas>I've also done a few perl cleanups (so that we don't have to hardcode version so many times) <stikonas>fossy: do you think we should rebuild tcc again? after pder's musl recompilation <stikonas>so that tcc also has non-buggy floats in case it uses them <fossy>musl is compiled, and musl has buggy floats <fossy>tcc-musl then has buggy floats <stikonas>tcc-mes just displays garbage when you print floats <fossy>musl is recompiled so now musl does not have buggy floats but tcc-musl may still have buggy floats <fossy>yes, probably worth it to recompile tcc again then <stikonas>although, tcc-musl might not use floats for anything <stikonas>and by the way, tcc from guix is also just as buggy <stikonas>fossy: by the way, I was thinking about src_cleanup too, but it's not clear how to properly implement it. Some cleanup actions are best done before default_src_install and some after <stikonas>something like src_cleanup_preinstall and src_cleanup_postinstall <Hagfish>that looks like a common pattern from package managers and test frameworks <Hagfish>speaking of which (and i apologise if this is an ill-informed question) would it make sense to have a test suite for some of the functions in the bootstrap code? <Hagfish>i guess to some extent the bootstrap process itself is the test, but maybe there are engineering reasons for having unit tests <Hagfish>it would be cool, for example, to have a test which proves that if a source package has the wrong checksum, it is rejected <Hagfish>but i wouldn't know how to write that test in a way that doesn't either make the existing code more complicated, or involve simulating network connections <OriansJ>Hagfish: or just use existing network test tools <pder>what do you guys think about combining Part 20 and Part 21 into one part that that is all building tcc-musl toolchain? <pder>These are the steps: build musl with tcc-mes, build tcc with tcc-0.9.26 followed by tcc-musl, rebuild musl with tcc-musl, rebuild tcc with tcc-musl. <Hagfish>hmm, that does sound like a fairly self-contained process <Hagfish>i'm thinking that each Part should be like a puzzle that someone could try to reduce the number of steps for (without decreasing the readability) <Hagfish>and each puzzle shouldn't have too many irrelevant parts in <Hagfish>so i guess it's a trade off, but i would try to consider what sort of knowledge someone would need to tackle a single Part on its own <pder>On the other hand, the build is more oriented to working on one directory or package at a time <fossy>stikonas[m]: maybe src_cleanup() and root_cleanup() <fossy>one to clean up the source files and another to clean up the rootfs <fossy>although sometimes we may need to cleanup the rootfs pre install, true <gforce_de1977>also interesting: only the helicopter uses Linux, the rest is VxWorks stuff <OriansJ>gforce_de1977: PowerPCv1.1 (32bit) is just another on the long list of bootstraps that will have to be done. <stikonas>fossy: so regarding /dev/null, the file I'm deleting it's just file. In principle we can create a proper /dev/null device node but musl's configure script breaks it (not sure why) <stikonas>so if we want to create real node, we should probably wait until after musl <OriansJ>stikonas: when in doubt strip the configure out <OriansJ>autotools and configure are about figuring about what you have installed. In bootstrapping we know EXACTLY what we have. <stikonas>it's a small handwritten configure script <stikonas[m]>Well, in principle I can add test -f too, but why would there be /dev/null? <stikonas>gforce_de1977: ok, I pushed that test -f variant <stikonas>but it will only be useful if we device to rebuild musl after we create real /dev/null and only if we figure out why configure was breaking real /dev/null <stikonas[m]>Strange, isn't /dev/null created by user space, not kernel? <stikonas>anyway, I've added it in case it will be useful later (if we decide to rebuild musl) ***ChanServ sets mode: +o rekado_
***rekado_ is now known as rekado
<pder>fossy: can you please update the README and resync the step numbers run.sh and kaem.after.run with the addition of the checksumming? <stikonas[m]>Thanks! I'll rebase perl once you merge the other two PRs ***mihi_ is now known as mihi
<fossy>right, back to the linux kernel we go <stikonas>fossy: pder asked if you can do checksums <stikonas>[16:34] <pder> fossy: can you please update the README and resync the step numbers run.sh and kaem.after.run with the addition of the checksumming? <stikonas>I guess at least cp shouldn't be too hard... <stikonas>but the other musl rebuild will probably be annoying <stikonas>but oh well... And my PR is already blocked on those two