IRC channel logs

<mid-kid>I'm going to be upgrading the gentoo bootstrap to 2025.8 (coincidentally I actually need it right now, lol)

<mid-kid>But I want to fully script it this time. Ideally you'd just run rootfs.py and get a working gentoo system

<mid-kid>That way I can also just have a variable to select the architecture

<mid-kid>I'm wondering how to approach it

<mid-kid>I have three possible solutions:

<mid-kid>- keep the steps as they are, rebuilding and adding some 32-bit software needed to cross compile through portage, trampling over the original live-bootstrap files and producing a weird franken-live-bootstrap. I feel this is rather brittle as ensuring compatibility between the tools built by live-bootstrap and those built by portage is difficult (I can't cross compile gcc14, likely due to

<mid-kid>this)

<mid-kid>- install portage and all its tools needed for cross compilation to a prefix, like /cross. This would greatly simplify the steps, and ensure compatibility, but it'd needlessly rebuild a lot of tools and libraries that are already available in live-bootstrap, and take a lot of time.

<mid-kid>or

<mid-kid>- make live-bootstrap compilation scripts for all the tools necessary for portage's cross compilation. This would involve upgrading at least gcc and python, and some other packages that care about being the same version as the package you're cross compiling.

<mid-kid>The last one is interesting in the sense that it would be building generic cross compilers that can be used to bootstrap other distributions. It's also a lot more work and I'm not sure it'd be fully compatible with how portage sets up the toolchain.

<fossy>i agree that #1 is a bad idea. i would typically recommend setting up a new environment where possible because the end result of live-bootstrap is... fairly strange

<fossy>#2 is i think the easiest

<fossy>you say "rebuild a lot of tools and libraries", but as you point out in #3, you need to get specific versions and setups anyways, and presumably you'd want to rebuild everything against that new toolchain regardless?

<fossy>maybe start with #2, and then with more time consider porting to #3?

<mid-kid>I think my idea with #1 was minimizing the amount of compilation needed without having to write the compilation steps myself, basically #3 but leveraging portage

<mid-kid>But you're right, I should start by scripting #2 and I can always go back and do #3 instead

<mid-kid>It'd just involve removing the step of building the gentoo prefix

<lanodan>For something #3-ish… maybe put live-bootstrap versions in something like package.provided?

<mid-kid>lanodan: that's the #1 :P

<lanodan>Ah

<stikonas>mid-kid: yeah #1 sounds very fragile

<stikonas>how about first building 32-bit portage prefix and then use gentoo tools to cross-compile 64-bit prefix

<stikonas>but yes, the more automated it is the better

<stikonas>I did it using your 1st generation instructions in 2024 and it was a lot of manual work

<stikonas>perhaps a bit of extra stuff can be added to live-bootstrap itself?

<lanodan>Or maybe more to gentoo prefix.sh or similar script? After all live-bootstrap should give pretty much everything that's needed and more.

<mid-kid>stikonas: the 2024 one was awful, I find the 2025.8 instructions way more manageable

<stikonas>yeah, even those 2nd generation instructions were already much better

<mid-kid>s/2025.8/2025/

<mid-kid>But yeah

<mid-kid>I don't think setting up a prefix is gonna simplify a lot, but I'll try

<stikonas>mid-kid: can you remind why we are using squashfs image?

<stikonas>I thought there are also tarballs

<mid-kid>stikonas: because the monthly squashfs images stay on the distfiles server forever

<mid-kid>The tarballs get removed within a month

IRC channel logs

2025-08-21.log