IRC channel logs
2024-12-14.log
back to list of logs
<stikonas>non stable downloads is probably one of the most annoying things that affected us in live-bootstrap <stikonas>it's not the same project, sometimes it was openssl, now savannah... <temp64>going to build all of that tomorrow <stikonas>most of the sources are set to mirrors.kernel.org, not ftp.gnu.org <aggi>meanwhile, sanitized musl-libc to exclude functions and syscalls which linux-2.4 does not support <aggi>that is 200 syscalls less than what linux got nowadays, and this caused almost no regressions against those ~500builds that i maintain for support with tinycc <aggi>there's only a few troublemakers, introduced to avoid race-conditions with thread support from kernel, pselect() for example and openat with O_CLOEXEC support <aggi>nonetheless, for kernel-bootstrapping the tcc/musl/linux-2.4 seems a decent approach, to emit a complete distribution even <aggi>since when musl-libc got sanitized last night, almost all regressions of linux-2.4 ABI and musl should be revealed compile-time now, and hopefully there won't be too many sporadic run-time ones <aggi>a few quick initial tests, links2 -g browser works already, mutt mailer, busybox etc. etc.; that's heavyweights which imply broad test coverage passed <aggi>with a tinycc compiled musl-libc/linux-2.4 <aggi>hence for bootstrapping it is possible to fork a complete distribution as soon as tinycc and musl-libc are available, without bootstrapping any later kernel version nor gcc etc. <aggi>much less lines of code, much less compile-time, and _more_ software available, including gdb, strace etc. <homo>is linux 2.4 easiest of all kernels to start bootstrap with? what about hurd/mach? <aggi>nope, the tinycc/linux-2.4/musl-libc certainly isn't the "easiest", but it seems the most practical one hitting the sweet spot <aggi>in between absent hardware support (absent usb with fiwix/munix/mach etc) and the excess software-bloat common nowadays <aggi>furthermore, linux-2.4/musl-libc provide a sufficiently complete syscall/posix api/abi for recent software versions <matrix_bridge><Andrius Štikonas> homo: that's not really a correct question, you don't need linux 2.4 to bootstrap <matrix_bridge><Andrius Štikonas> what do you want to bootstrap? userspace: modern kernel is the easiest. kernel: you should start with something really simple such as builder-hex0 and then build Fiwix kernel <matrix_bridge><Andrius Štikonas> then you can build Linux kernel from there <aggi>yes, but linux-2.x can be integrated into a clean bootstrapping path, _and_ it provides sufficient features for a somewhat complete distribution rather early within the bootstrapping path with far less dependency clutter <aggi>than a modern linux-kernel and gcc would need <stikonas>I don't think I agree with what is clean bootstrapping path. what is not clean about live-bootstrap <aggi>live-bootstrap seems fine, i see problems with gcc and recent kernel versions <stikonas>more dependencies, perhaps, but I wouldn't call it unclean <homo>after many hours of reading source code of hugs, I don't understand it at all, I really hoped this tiny patch was enough to have bangpatterns just so that I don't need to patch them out of microhs https://paste.debian.net/1339807/ <homo>it should be possible to bootstrap microhs from hugs as it uses extensions available in hugs <rekado>Rutherther: thanks for the hints! It works now. I think I have enough information together to write a Cookbook entry. <rekado>(though perhaps we should consider adding a window-manager-service-type as an alternative to desktop-service-type) <stikonas>rootfs.py also creates configuration file I think (bootstrap.cfg) <stikonas>temp64: also keep in mind, that only x86 bootstrap works now <stikonas>mescc->tcc step is still buggy and crashes <stikonas>we can build very first tcc binary, but it is only partially functional <stikonas>riscv64 actually is in a better state than amd64... <stikonas>though riscv64 work also helped with some amd64 bugs, it goes a bit further on amd64 now than before <temp64>can't you just cross-compile amd64 binaries after x86 bootstrap though? <stikonas>sure, that's what I have done for my current OS <stikonas>generally, the bootstrap path should be more or less the same <stikonas>it's just various bugs that are preventing it <rekado>ACTION wrote to the wrong channel, oops <aggi>temp64: tinycc and fiwix do not support x86_64 to keep it brief, and those are crucial to bootstrapping <stikonas>tinycc does support x86_64, only fiwix doesn't <aggi>stikonas: last time i tried (2 years ago) significant parts for 64bit asm processing were absent <aggi>and i feel urged to respond to another thing <aggi>2024-12-14 12:12:05 <stikonas> more dependencies, perhaps, but I wouldn't call it unclean <stikonas>assembly opcode is just some sequence of bits <aggi>^ i didn't call live-bootstrap nor kernel unclean <stikonas>(plus the bits corresponding to registers and / or immediates) <stikonas>so assembly is really far far easier to implement than any compiler <aggi>nonetheless assembly support for any architecture is signifcant efforts, finally bundled into binutils, and rewriting this isn't trivial <stikonas>well, binutils have far better coverage of assembly <stikonas>but that's because everybody uses binutils, if instruction is not in binutils, nobody would be using that instruction <aggi>it's both a blessing all that got implemented with binutils, and it's too a burden <aggi>anyway, i didn't call live-bootstrap unclean, never <ekaitz>aggi: i can add more if you want <aggi>ekaitz: it's x86_32 in this case, but some advice would be appreciated <ekaitz>a x86 is not really my thing... i added riscv things only <aggi>ekaitz: i've not played with some risc-v, i merely hope it's dependency graph won't blow up like the arm u-boot one did (attaching python/swig/c++ build-time dependency to the boot-loader) <aggi>because if it did, bootstrapping u-boot loader got blocked <aggi>if >gcc-4.7.4/g++ cannot be avoided with any kernel version needed for risc-v, this too would trap risc-v bootstrapping onto x86 bootstrapping/cross-compilation/ <aggi>to my knowledge it's difficult to compile/link/assemble any later kernel version than linux-2.4 (or fiwix) with tcc (regardless of the ISA) <aggi>furthermore, Intel is phasing out x86_32 UEFI/CSM support; with the consequence of x86 hardware being available with a somewhat clean bootstrapping path cannot boot 16bit real-mode anylonger then <aggi>that's triple the fun, and quardrupled if all that remained was qemu, where some discussion indicated rust-lang creeped into too, <aggi>that's fivefold fun with bootstrapping then <lanodan>For riscv boards which aren't meant to be microcontrollers you should only need an uefi bootloader. Could have the question of the boot firmware that's on a dedicated chip but you'd need to consider coreboot for x86 then. <Googulator>rekado: did you intended to post that here, or in #guix ? <fossy>hmmm, i recently redownloaded gnulibs, so this must have been in the last few weeks <fossy>ugh, that is really annoying <stikonas>we could predownload gnulibs with git and export locally <fossy>Googulator already did that in commit 25443468 <fossy>we always have files.bootstrapping.world as a backup <fossy>painfully, the github tarballs are not identical to the cgit tarballs, because github includes the full commit hash <deesix>(changes in compression config giving different archives) <lanodan>well compression config should be obsolete, git comes with it's own gzip <lanodan>That said sometimes makes me feel like having a barebones implementation of git's protocol, because that one would work regardless of the forge and be more easily verifiable. <deesix>Git is not the only thing out there. <fossy>it's what everything live-bootstrap cares about uses <fossy>Googulator: when you have a minute, what do you think about changing gnulib to getting sources from https://github.com/coreutils/gnulib? we'd need to reupload all the gnulib tarballs to files.bootstrapping.world. (cgit for gnulib has disabled .tar.gz downloads :\) <lanodan>yeah git isn't alone but well… the others are much nicher and I guess could be bootstrappable from tarball/git fine (and I say this with packaging few things using cvs, mercurial and had bzr at one point) <lanodan>In fact checking live-bootstrap which I guess has the most extensive bootstrap steps, a `grep -v git steps/*/sources` seems to only show ones that are likely static archives.