IRC channel logs
2026-03-28.log
back to list of logs
<alganet>Also, almost zero host tools required (no parted, python, etc) to build the initial image. All tools are stage0-build on the host too, except for a few obvious requirements (mkdir, cd, find, wget, etc basic arrangement utilities) <alganet>Next step is the mes build! I'm hitting a roadblock on ungz under stage-uefi (can't ungz/untar mes distfiles under pure stage0-uefi), but I'm working on it. <gabif>alganet: how does ungz/untar fail? i'm also very interested in amd64/EFI bootstrap path. <alganet>the untar issue is related to directories, can't pin it down. Pre-creating the directories to workaround for now. Next roadblock was the UEFI watchdog killing the build, made a small utility to disable it. Simple mes-m2 is now building! <stikonas>alganet: we already disable UEFI watchdog in kaem as far as I remember <stikonas>oh I guess other applications that take more than 5 minutes or so still can be killed <stikonas>alganet: and you are missing --non-strict option when untarring mes tarball <alganet>If you look at the error, --verbose shows that it happens before any symlink (the reason for --non-strict, mostly). The issue is with creating directories. <alganet>It works fine if I pre-create the dirs, or extract mes on the host and make the image with it pre-extracted. This is using my homegrown mkfat.c and putfat.c, so there could be some bug there too (I consider being able to create the own image from bootstrap tools an essential part of the process) <alganet>abuild is a little more strict than live-bootstrap in that sense, it foolishly tries to solve the "making the first image" problem too <stikonas>well, live-bootstrap image can in principle be made by hand too <stikonas>the problem is putting it into storage media or RAM <stikonas>modern hardware is not really designed for that <stikonas>you need something like front panel of pdp-8 with switches <stikonas>or perhaps some paper tape or punch card reader <zcram>I've heard paper tape when well kept outlasts magnetic media <alganet>in practice, it's a non-goal, I get it <alganet>but one can think of it as in terms of bootstrapping debt: how early can a bootstrappable system build itself? It then becomes a tangible measure <alganet>it takes the full live-bootstrap for it to build itself, or almost (up until python), so it pays the debt after a lot of binaries have been built <alganet>in theory, you can skip python and build it in simpler terms (I started abuild by attempting that!), but it's a debt *in practice* <alganet>it's not a hard problem when framed like that, it is in fact easy, but laborious. abuild pays that just after stage0 (not considering emulation, which is framed in the setup as a test dependency only) <aggi>don't know yet, but the reasoning to keep the dependency graph small is relevant <aggi>for the pieces that are mandatory with bootstrapping, and keeping all else optional <alganet>I think so too! I don't know enough to work on more meaningful parts of the bootstrap. While I learn, I might as well also deliver something in this easier realm of detangling the setup dependencies