IRC channel logs

<oriansj>stikonas: merged (took a bit to fully review)

<stikonas>oriansj: thanks!

<stikonas>yes, kaem had some changes in offsets

<stikonas>luckily it was mostly off by two

<stikonas>oriansj: by the way, aarch64 kaem seed is also a bit broken (for unrelated issues)

<stikonas>but it also fails to propagate failures

<fossy>stikonas: i'm keeping with c & c++. if we want to add more, let's do it in gcc 12

<stikonas>oh it's definitely in the last gcc, not earlier ones

<stikonas>c and c++ is probably good enough (unless we need to build e.g. some go stuff)

<fossy>yeah. gccgo is a little bit cursed though

<fossy>i've got past autocrap with gcc 10 now, i think

<fossy>also, no worries with aclocal.m4, because no directory has no configure AND yes aclocal.m4 (so it will always be picked up with autoreconf)

<stikonas>oh, some pregenerated files in gccgo?

<stikonas>fossy: so you can jump from 4.7.4 to gcc 10?

<stikonas>doras: so I've just pushed kaem fix to live-bootstrap

<fossy>stikonas: it appears so.. unless i run into an error in the current build

<fossy>no pregened files, it's just a bit strange when building go applications

<fossy>doesn't always work

<stikonas>fossy: oh possibly, but as long as it can build go itself, that should be enough

<fossy>stikonas: oh, sure

<fossy>not sure if it can actually do that, but go1.4 is still a very easy route to go

<fossy>go is not a hard language to bootstrap

<stikonas>true

<stikonas>though not sure which one supports more arches

<stikonas>but x86 is definitely supported there

<nektro>filed https://github.com/oriansj/mescc-tools-extra/pull/16 to update m2libc, should i make one for stage0-posix as well?

<stikonas[m]>nektro: stage0-posix should have the latest

<stikonas[m]>In fact that's the copy that everything uses during bootstrap

<nektro>stage0-posix has b774c03 too

<nektro>which is almost a year old

<stikonas[m]> https://github.com/oriansj/stage0-posix says 1139

<stikonas[m]>There is M2libc folder in top level directory

<nektro>ohh i was looking at the commit of stage0-posix currently linked in stage0

<nektro>yeah master stage0-posix is showing right for me too

<stikonas[m]>Oh stage0 just links to it for information only

<nektro>thanks for the pointers lately :)

<nektro>managed to get stage0-posix building fully in my custom package manager https://git.sr.ht/~nektro/wifilylinux/tree/master/item/packages/bootstrap/

<stikonas[m]>Oh that is quite granular

<stikonas[m]>Not like live-bootstrap that builds stage0-posix in one go

<nektro>atm its based on https://github.com/fosslinux/live-bootstrap/blob/master/parts.rst to get the poc working, but ill prolly end up merging parts of it together later

<nektro>later on i wanna try and short circuit certain paths with zig too

<fossy>there's pros-and-cons to both stage0-posix and splitting it out

<fossy>for live-bootstrap im reasonably convinced stage0-posix is the right way

<fossy>for package managers it may not be

<oriansj>nektro: the pieces are also mirror'd on sourcehut if you prefer that as well

<oriansj>nektro: merged

<fossy>stikonas thoughts on untying tmpfs logic from chroot/qemu/whatever style and providing an option regardless of the style being used?

<stikonas[m]>fossy: I'm fine with ot but need to check, maybe e.g. bwrap doesn't work with tmpfs

<doras>stikonas @stikonas:libera.chat: thanks! I see that the hash for checksum-transcriber had changed, wqs that expected?

<doras>was*

<stikonas[m]>doras: in think so, there were probably updates to M2-Planet too since last update

<fossy>stikonas[m]: ah, yep

<stikonas[m]>Should be possible to just add checks to ban broken configurations

<fossy>yeah

<nektro>does mes have a bug tracker or is bug-mes@gnu.org the only recommended way? the included ./kaem.run doesnt have +x set

<nektro>running it through kaem directly works, but just as a heads up since it has a sh shebang

<stikonas[m]>+x doesn't do much in kaem

<stikonas[m]>sh shebang is mostly for syntax highlighting

<nektro>i was pointing out shell and bash check it

<stikonas[m]>Well, send an email to that list

<doras>stikonas, fossy: should live-bootstrap remove /usr/src when the bootstrap completes?

<doras>I'm trying to think of the best approach for /distfiles. Is the output of the bootstrap the sysc system itself, or the packages in /distfiles?

<doras>We need the final system to be smaller in size (Python just made it too large for our CI) so I'm trying to think how to approach the cleanup.

<doras>I can obviously do it in the freedesktop-sdk side, but I often prefer to contribute to live-bootstrap where it makes sense.

<doras>s/often//

<doras>I added an after.sh script on the freedesktop-sdk side for now: https://gitlab.com/freedesktop-sdk/freedesktop-sdk-binary-seed/-/merge_requests/23/diffs?commit_id=561d5d0eaac1e78581e0295b7e1e512af7e5dfd4

<stikonas[m]>after.sh on your side should be good enough

<doras>Sure, we can keep it this way.

<doras>I was mostly wondering if it was something that we wanted to have something of the sort in live-bootstrap too (seeing that we do clean up things from sysa before switching to the next system).

<doras>something that we wanted to have in live-bootstrap too*

<stikonas[m]>Not sure... You can ask fossy. sysa cleanup is more important due to 3G RAM limit on 32-bit Linux

<stikonas[m]>Usually disk space in sysc would be far cheaper

<stikonas[m]>Also sysa is a bit of a mess, especially due to early steps. We don't have access to "cd" till quite late in stage0-posix

IRC channel logs

2023-01-23.log