IRC channel logs

<xentrac>cosinusoidally: that's excellent!

<lanodan>siraben: I once had bootstrap-initrd (tcc+musl manually seeded from Alpine apks) working for jslinux on riscv https://hacktivis.me/jslinux/vm.html but I need to debug it a bit (plus I really wish Fabrice Bellard would distribute the tarball of latest jslinux).

<siraben>docker run --rm -it alpine:latest sh -c 'apk add --no-cache ca-certificates wget patch time && cd /tmp && wget -qO- https://github.com/siraben/blynn-bootstrap/archive/refs/heads/portability.tar.gz | tar xz && cd blynn-bootstrap-portability && /usr/bin/time -p sh -c '"'"'M2_OS=Linux sh scripts/bootstrap-blynn.sh && build/tinycc-boot-hcc/bin/tcc -version'"'"''

<siraben>This is for running alpine docker. gets to tcc in around 15 minutes for me on my machine

<lanodan>Thats's quite a lot of seeds ^^

<siraben>real 1432.25 user 1296.69 sys 72.20

<siraben>lanodan: cool, will look into it

<siraben>glad to see that people keep stumbling on the same tasks

<aggi>nice aspect with YASM moved into tiny-bootstrap, it's a drop-in replacement for GNU as almost, and is available early during live-bootstrap

<aggi>there's too a chance yasm can process the syslinux/isolinux.asm pieces which follows NASM syntax

<aggi>to my knowledge isolinux.bin had not been re-assembled for a long-time (+10years) even with the gentoo ebuild i checked

<aggi>together with cdrdtools, it is possible to emit x86 bootable.iso very early, long before the whole perl/autotools/python dependency graph builds up

<aggi>it's will not be some isohybrid one though, because isohbyrid needs perl, so such a tiny-bootstrap.iso can be booted from cd-rw only, not usb-flash

<aggi>of cause there will be support for isohybrid too, but it's more important to keep the dependency graph as small as possible with the early bootstrapping pieces

<aggi>and there, emitting bootable.iso with syslinux/isolinux is a precious thing

<aggi>it's x86-only though; because for all other ARCH there's a few pieces missing, and it's unavoidable hence to build up the complete dependency graph up until linux5+/GRUB2

<aggi>which is a peculiarity still in GNU live-bootstrap, grub2 bootloader is available rather late (don't know if it could be moved into the early steps/ before autotools/perl etc)

<aggi>the busybox-1.2 is done already too, so it's cdrtools missing mainly (whose buildsystem is a pain, i've almost complete this step/ nonetheless)

<aggi>the major criteria seems to be support for other ARCH, which threatens live-bootstrap with a dependency hell

<aggi>i don't know yet about kexec-fiwix with a fully-native stage0 bootstrap, if it's kernel would permit cdrecord then, and i don't intend to divert too much from live-bootstrap

<aggi>but a kexec-linux for the 2.4 fork here is a feasible option too; currently i'm testing inside /chroot anyway

<aggi>and well, i've not moved the linux-tcc Kbuild.sh into a steps/pass.sh script yet, should be trivial almost

<aggi>just in case i'm hit by SHTF here, the most relevant pieces are uploaded to codeberg.org already

<aggi>except cdrtools since it's shell-scripting, tbh, just sucks (i got that zipped into a custom ebuild here for cross-compilation support and static linking with tcc already)

<aggi>but i've raised the QA a tad bit for the re-integration into configurator/steps/ system

<aggi>since the full(!) portage fork fur tcc-toolchain support, it's hundreds of patches and hacks all over the place for ~500ebuilds which i just tried to make it work somehow

<aggi>that's why i don't want to git-push that, because it's too much clutter and confusion

<aggi>in any case, this type of x86 bootstrapped C-toolchain driven system-integration must not be lost

<aggi>the fact it's tied to some ancient linux-2.4 kernel is one of it's great benefits besides

<aggi>because, for any ARCH other then x86, you _must_ use some most recent kernel versions almost always

<aggi>that's why, for example, RISC-V or aarch64 are problematic; those do need some recent gcc4.x at least and most recent kernel versions

<aggi>so it's too moot to discuss, if GNU mes, gcc and the whole infrastructure should be ported for riscv/aarch64, you _must_ do this for those ARCH

<aggi>you can't just easily pick some older or exotic kernel - i'm not aware of any for riscv/aarch64 to begin with

<aggi>there's been notable political nonsense debates spilled over some of my proposals elsewhere

<aggi>(which wasn't foss people, but some other realm entangled into EU/politics/shareholder interests invested into things like helsing.ai)

<aggi>and i'm too seeing, EU was funding some notable pieces of live-bootstrap

<aggi>after all, what i've been through in recent month again, with ignorance and denial including that of EU and government cash affiliated entities

<aggi>see, when skimming job proposals at helsing.ai while ago (out of curiosity), that's all been rust-lang there

<aggi>EU dumped hundreds of millions into this alone

<aggi>then, i've summed up a few notes at my web-site, and found all of the sudden some high-ranking charlatans and posers in EU politics hijack terminology of my scribblings

<aggi>and ALL my inquiries got denied again meanwhile, at dozens of universities, hr offices, startup funding

<aggi>but ministry of defense in germany boasts about the great "interoperability" of their investments

<aggi>all else, they rather not get lost in menial "tiny tiny little details"

<aggi>anyway, a few of those political charlatans got beheaded, FDP liberal party here, who are closely attached to FSF Europe in Hamburg

<aggi>and of cause, they're all a little nervouse, because Nvidia shareholder holder value is on loose ground

<aggi>i mean, i couldn't care less if anyone is doing the dirty work for RISCV for them

<aggi>other than that, i was considered for hiring as professor at a university in Thuringia

<aggi>for that matter i was occupied with other tasks than system integration in my "carreer"

<aggi>but in the end, their council couldn't consent with anything, and after more than 6month i gave up asking again

<aggi>this university demanded just _more_ documents without any contracting nor salary, to showcase i was sufficiently qualified with what i'm doing

<aggi>and i suspect it's been Telekom (the political aspect of it, not the technical one) again involved behind the scenes, since they're donating professors for "digital transformation"

<aggi>i've got some real bad memories of the interference of such entities

<ekaitz>aggi: the gcc4.x riscv64 work is "done"

<aggi>ekaitz: excellent

<ekaitz>it's probably not great, but there it is

<ekaitz>and I don't expect aarch64 to be hard to add

<ekaitz>if you want to give it a shot: https://codeberg.org/ekaitz-zarraga/gcc

<aggi>i'm trapped in x86 for other reasons

<aggi>but it doesn't matter anymore anyway

<mwette>ACTION cut parse time by 75%

<aleksi_>snuik: later tell stabbles: Hi, I've seen you've asked about AArch64. I have a working AArch64 mescc draft over here: https://codeberg.org/aleksi/mes/src/branch/aarch64 -- I also did some work on the tinycc assembler front. There's a full bootstrap path as a Nixpkgs draft PR over here: https://github.com/NixOS/nixpkgs/pull/487398

<aleksi_>Oh, snuik isn't here ):

<FransFaase>aleksi_: We got tcc-0.9.26 and tcc-0.9.27 compiled on AArch64 producing AArch64. Yesterday, I asked if it was worth the effort for creating a pull request for live-bootstrap and I did not get an answer. The patches (involving some files from musl) also work for x86_64/amd64.

<aleksi>Nice, I for one would like to see this hit live-bootstrap some day. I think the next step realistically would be porting Fiwix

<aggi>yep

<aggi>just keep in mind i failed porting qemu with tinycc/linux-2.4 to align qemu a little bit closer to bootstrappable criteria

<aggi>in practice this doesn't matter alot, if any aarch64/riscv etc were test-run on qemu

<aggi>for myself (Tinycc/OS) i excluded qemu already from the list

<aggi>just keep in mind, qemu opens a giant can of worms, in particular it's recent versions (documented on tinycc-devel while ago)

<siraben>aggi: what's some of the worms?

<aggi>siraben: early versions of qemu, that was a few MiB for their source.tar.gz, nowadays it's >150MiB already

<aggi>all else is just a side note, such as compiling this with tcc (after all both tcc and qemu originate from bellard)

<alganet>aleksi: I didn't knew you had a working aarch64 mes, ended up doing it as well https://github.com/alganet/mes/pull/1 (I'll probably use your branch instead now)

<alganet>In other news, I completed the first abuild prototype. From firmware (not inclusive) to first-kernel (builder-hex0 inspired) up to mes-m2 in 4 architectures, plus some variants https://github.com/alganet/abuild (x86-bios, amd64-uefi, aarch64-virt, aarch64-raspi3b, riscv64-uefi, riscv64-virt, riscv64-sifive_u).

<alganet>That includes prototype work on stage0-uefi, m2libc (stil out of sync with upstream though) and bootstrap-seeds (for riscv64-uefi). I'll be focusing now on polishing those so they're ready for contributing back.

<alganet>It's likely that the new builder-hex0 inspired new kernels (riscv64, aarch64) are too slow and buggy by the way. They were literally tested just up to mes-m2. I remember seeing a lot of work on builder-hex0 x86 needed to run the following steps, and I'm not there yet, but they do complete stage0 flawlessly with checksum verification for now (CI

<alganet>proof, has all logs for all builds: https://github.com/alganet/abuild/actions/runs/26993062343 )

<aleksi>Oh wow, fun to see another approach at the aarch64 backend

<aleksi>abuild in general seems interesting

<siraben>oh wow, very cool to see another person do CI for their builds too

<siraben>Work in progress... https://siraben.github.io/blynn-bootstrap/ . type bootstrap RET and wait a while

IRC channel logs

2026-06-05.log