IRC channel logs

2025-09-04.log

back to list of logs

<vasi>I tried to reproduce the Azure Linux bootstrap, but wasn't able to yet: https://codeberg.org/vasi/bootstrappable-distros/issues/1
<vasi>One observation is that few distros support x86 nowadays, so there's an awkward gap between live-bootstrap's 32-bit userland and bootstrapping a distro
<vasi>I noted some existing projects that attempt to go from l-b to a native userland here: https://codeberg.org/vasi/bootstrappable-distros/issues/1#issuecomment-6885061 But would love to know if others have seen anything more suitable
<stikonas>vasi: probabl the better option would be to extend bootstrap to x86_64
<stikonas>it shouldn't be that much work
<stikonas>but we also don't have that many people who have worked on hex->gcc bootstrap, so progress is slow
<Googulator>vasi: I almost forgot that I first installed pcre2 by mistake instead of pcre, then reverted to pcre 1 to make grep -P work, but didn't clean up pcre2 - turns out, something else does need pcre2
<Googulator>as for Go, I originally built all versions except 1.23 with a 32-bit kernel, then built and booted the 64-bit kernel, and then built 1.23
<Googulator>But probably just building 1.23 with the exact command I listed should help
<vasi>the commands you have listed say GOARCH=386
<vasi>also did you have to install ncurses for `tic` like i did?
<vasi>maybe i'll try building x64 Go and seeing if that works better
<Googulator>...tic?
<vasi>See one of the errors i posted here: https://codeberg.org/vasi/bootstrappable-distros/issues/1#issuecomment-6885001 (search for "run_tic.sh"). It's trying to run the `tic` command as part of building ncurses in the toolchain, but we're cross-compiling so it doesn't realize it can use the just-built version of ncurses, and tries to use the one on the system
<Googulator>oh right - turns out I did try to install ncurses as a dependency for rpm, but while it appeared to install, rpm would continue to complain that it couldn't find ncurses, so I just passed `-DWITH_READLINE=off` to cmake to skip the ncurses dependency, and never recorded ncurses as part of the bootstrap chain
<Googulator>so tic is actually installed on my system, yes
<Googulator>I just never realized something does use it
<Googulator>as I had to disable readline (which depends on ncurses) in both rpm and parted
<Googulator>GOARCH=386 might have been just a copy-paste error, except on the last build
<stikonas>well, it would be good to add ncurses and readline to live-bootstrap too...
<Googulator>also, I didn't want to include ncurses in the chain, if at all possible, because it requires autoconf-dickey to regenerate ./configure
<stikonas>well, it's not strictly required for bootstrap but a lot of built tools have very poor command editing capabilities (e.g. bash or python)
<Googulator>and autoconf-dickey, in turn, also has its own configure script, which in turn can only be regenerated with, you guessed it, itself!
<Googulator>That makes it impossible to include ncurses while maintaining a strict ban on pregenerated files
<stikonas>oh yeah, I saw that autoconf-dickey when I briefly checked ncurses (for live-bootstrap) but I didn't get to anything useful
<Googulator>vasi: did you find a way to bootstrap autoconf-dickey? or did you just use its pregen configure script?
<vasi>i just used the pregen script
<vasi>i figure since the azure toolchain builds ncurses, and i assume uses pregen configure, we're not really losing anything?
<vasi>just changing at which point our ban on pregen files ends
<Googulator>yeah, that's not gonna pass muster for live-bootstrap inclusion, especially in the wake of xz
<stikonas>Googulator: hmm, just trying now
<stikonas>does it not just work with normal autoconf?
<vasi>it does not
<stikonas>I ran autoconf-2.72 on it
<stikonas>and it seems to work
<Googulator>no, and Dickey explicitly doesn't want it to work
<vasi>it _runs_, but it leaves some junk un-substituted in several files, so it fails when you get to `make`
<Googulator>he has a long running beef with autotools maintainers
<stikonas>oh I see
<stikonas>hmm, is it in git?
<stikonas>I should try to build from there, maybe fewer pregenerated files...
<stikonas>hmm, looks like it's not...
<stikonas>hmm, strange but I can't reproduce those errors
<Googulator> https://salsa.debian.org/joachim-guest/autoconf-dickey this is the best I could find
<Googulator>also, I don't think live-bootstrap has 2.72
<stikonas>I used https://invisible-island.net/datafiles/release/autoconf.tar.gz
<stikonas>then rm configure
<stikonas>autoconf-2.72
<stikonas>Googulator: no, we probably didn't add 2.72
<stikonas>but it should be easy enough (I just used whatever was default in my Gentoo system)
<Googulator>is autoconf alone sufficient here? don't we need autoreconf?
<stikonas>there is no Makefile.am there
<stikonas>but let's check
<Googulator>Because IIRC it's in some other part of autoreconf that it goes all wrong (aclocal, perhaps)
<stikonas>hmm, maybe we need aclocal...
<stikonas>oh, maybe that's why
<Googulator>also, Dickey's words: "The configure script which I generate and deliver with my programs is what I have tested. The script is portable. There is no need to regenerate it, unless someone finds an error in the script. The number of people who want to run autoreconf is orders of magnitude larger than those who provide useful patches for the configure
<Googulator>script."
<Googulator>...someone tell this guy about the Xz hack...
<stikonas>anyway, it's aclocal that breaks something
<stikonas>autoconf itself seems to work
<Googulator> https://github.com/ThomasDickey/autoconf-252-snapshots this is the best we have for a Git repo
<Googulator>he does his development in RCS, which he explicitly refuses to publish as-is
<stikonas>perhaps some older version of aclocal would work, haven't tried them...
<stikonas>Googulator: actually I don't think we need to run aclocall
<stikonas>this is a perfectly fine and readable file https://github.com/ThomasDickey/autoconf-252-snapshots/blob/master/aclocal.m4
<stikonas>I don't think anybody can complain that it is pregenerated
<stikonas>so yes, autoreconf doesn't work on it
<stikonas>but I think we can rebuild relevant files with gnu autoconf
<Googulator>right, that aclocal.m4 appears to be handwritten, looking at the official GNU Autoconf Git history
<Googulator>see https://github.com/autotools-mirror/autoconf/commit/10b394d34f740362d2beefa0102b33ac6a287a95#diff-d05beee91e3fb3e91d08b841553b74a24b9cfb9f3d238314e53229f2cf416475 where one generated by aclocal.m4 got replaced by a handwritten version (slightly mangled by some kind of VCS import)