IRC channel logs
2024-12-15.log
back to list of logs
<lanodan>Well github/codeberg/… autogenerated tarballs have the same kind of problem as any kind of snapshot though <stikonas>though release tarballs have another problem, they are usually full of generated code :( <Googulator>fossy: probably OK as a stopgap, but obviously not a full long-term fix <stikonas>perhaps contacting Savannah people might make sense? <fossy>yeah, that would be sensible <fossy>if they did it on purpose i have no idea what a long-term fix would be :\ <fossy>hmm, actually we could do it through gitweb instead of cgit, they haven't disabled .tar.gz downloads there <fossy>the urls are reallly ugly though, but whatever <aggi>nice, after sanitizing musl-libc for linux-2.4 ABI and patching a few dozen builds almost everything seems to work: vis-editor, gdb, htop shows processes now <aggi>with yaft terminal there's some decent unicode support <aggi>that was a two-year hackjob to get it done <aggi>lanodan: i am aware of the problems with coreboot relying upon gnu dependency graph <aggi>ekaitz: however, even when risc-v support progressed for any type of POSIX that needs bootstrapping, if risc-v dependency graph was not sanitizied and continued to rely upon x86_32 <aggi>bootstrapping problems accumulate, because risc-v (or arm) rely upon x86 bootstrapping/crossdev plus all the problems that risc-v build-time dependency graph may or may not introduce atop <aggi>hence it's moot pointing to x86 bootstrapping issues to justifiy risc-v if x86 could not be avoided anayway <aggi>furthermore, even when UEFI firmware would hide 16bit real-mode with or without proprietary malice, then this doesn't mean the related bootstrapping issues of 16bit real-mode would be absent <aggi>"you should only need an uefi bootloader"... that circuumvents the question how the the UEFI subsystem malice got introduced <aggi>similar to 16bit x86 BIOS which remains an open issue indefinitely, UEFI just adds malice atop of it <aggi>"you should only need an uefi bootloader" <aggi>this doesn't solve any problems, it introduces even more <stikonas>kpcyrd: hi, in May you had a question about ruby and pregenerated files <stikonas>I've spend a couple of hours on that and had some success <stikonas>well, I've got toe the latest ruby, without too much difficulty... <kpcyrd>stikonas: May is a while back, I don't remember the question. happy to hear the answer though. :) <stikonas>(I'm not claiming this is the shortest way but that worked for me) <stikonas>so I just grabbed something old from live-bootstrap <stikonas>by current bison 3.8 was not compatible with those <stikonas>perhaps it created .c and .h files but they failed to compile <stikonas>and I've just tried to skip 2.2 completely, but that doesn't work <stikonas>well, 2.2 has this bison annoyance, 2.7 then has an annoying issue with openssl (it requires it but openssl 3 is not supported) <stikonas>3.0 and later ones had no issues at all... <stikonas>and this was tested on ruby git repo, so hopefully on other pregenerated files <kpcyrd>hm, I think there was more context why I was asking this question. I remember it was very directly tied to whatsrc. but cool that you've figured it out! <kpcyrd>I think for a distro like Arch Linux it's eventually going to boil down to "can you bootstrap it from the bootstrappable-builds distro" <stikonas>it might have been in the hindsight of xz <kpcyrd>yes, but I forgot why ruby specifically <stikonas>probably other things too, just ruby is one of them... <kpcyrd>since I don't really use it personally. might be due to something raised by some other Arch Linux person who was more involved with ruby (possibly anthraxx). <kpcyrd>anyway, cool to know it can be bootstrapped!