IRC channel logs

<stikonas>fossy: any thoughts about what to do here? Should we add squashfs-tools to live-bootstrap?

<mid-kid>stikonas: I was planning on forking live-bootstrap to do the whole gentoo bootstrap, and I'll just add squashfs tools there.

<mid-kid>Don't think it makes sense to add to live-bootstrap as it's not a requirement for any of {gcc,binutils,glibc}

<stikonas>perhaps not

<mid-kid>Unless you guys plan on adding anything that could be useful for bootstrapping

<stikonas>but with forking it's also harder to maintain...

<stikonas>well, let's see what fossy thinks

<stikonas>of course some stuff in gentoo-bootstrap has to be outside main live-bootstrap core

<stikonas>e.g. we don't want to build portage stuff there

<stikonas>but maybe fossy had some ideas about how to integrate that

<mid-kid>Yeah, I want to be able to run rootfs.py and build gentoo

<mid-kid>Long term I want to make sure it's reproducible

<mid-kid>So regardless of how it's integrated I'll build squashfs-tools as part of the gentoo part.

<stikonas>perhaps rather than full fork some hook can be added to rootfs.py

<stikonas>and then gentoo-bootstrap code can be in a separate repo

<stikonas>that you clone alongside rootfs.py

<mid-kid>Maybe, but I will pin the commit of the live-bootstrap repo to make sure all the intermediate hashes match as well (I'll be checking binpkgs, if I can get that going)

<stikonas>hmm, live-bootstrap as submodule of your repo?

<stikonas>so that you have more control

<stikonas>and the hook could still be upstreamed

<mid-kid>The current repo structure is already good enough in terms of how things are decoupled, I would only need to modify the manifest file, and everything else can live in separate files and not touch any of the live-bootstrap code.

<stikonas>yeah ok...

<stikonas>maybe rebase wouldn't be too bad then

<mid-kid>So updating with the current structure would just be git pull, or rebase, yeah

<mid-kid>Whatever I do I'll make sure I can easily track what I added and update from live-bootstrap.

<mid-kid>If you guys have plans for a hooking mechanism, I can provide feedback once I'm a bit further along.

<mid-kid>And if it ends up implemented I'll switch to using that :)

<stikonas>well, at the moment last step of live-bootstrap is actually a hook called after

<stikonas>so it calls https://github.com/fosslinux/live-bootstrap/blob/master/steps/improve/after.sh

<stikonas>i.e. you can put your post-live-bootstrap hooks to /steps/after/*.sh

<mid-kid>Oh, huh!

<mid-kid>I'll see if that's enough for me, thanks!

<stikonas>shoudl be enough, you can always create a new manifest

<stikonas>for gentoo steps

<stikonas>and call it from /steps/after/*.sh script

<stikonas>so you can still use manifests but without touching any of the existing files

<stikonas>hmm, though maybe you'll have to touch SHA256SUMS.pkgs...

<stikonas>that could probably be sorted out too

<stikonas>unhardcode it to take some environmental variable

<stikonas>and then you can set it to e.g. SHA256SUMS.gentoo.pkgs

<stikonas>then i think you can avoid touching any existing files at all

<mid-kid>Yeah I'm still not sure how I'll handle obtaining all the distfiles and hashing the outputs

IRC channel logs

2025-08-22.log