<OriansJ`>mihi: it certainly would nice to see Debian properly bootstrapped (even if from Guix) <OriansJ`>stikonas: mescc could be extended to be able to compile newer TCC versions (Even GCC) if sufficient developer effort is thrown at it. However the question of is that the optimal choice is perhaps a much harder one; one I delegate to the people who choose to do the work or not. <OriansJ`>gforce_de1977: in regards to pushd/popd and bashisms in live-bootstrap; it might be more convincing if you got a different shell (like dash) lower in the bootstrap chain that might clean up some kaemisms. <stikonas>OriansJ`: dash proved to be hard to compile... <OriansJ`>stikonas: possibly the wrong example but the premise remains <pabs3>anyone know how to contact rain1? <bauen1>gforce_d11977: so i've grepped the log for `autom4te.cfg` and compared to all other autoconf runs in the same log, the commands directly above are using `autom4te` instead of `autom4te.cfg` <bauen1>`mv autom4te.tmp autom4te` should probably be `mv autom4te.tmp autom4te.cfg` <bauen1>i've also noticed that make seems to be a bit fragile, i got it to segfault just because of a missing program <fossy>gforce_d11977: that is a good ticket <bauen1>autoconf-2.57/lib/Makefile.in also contains the make recipe for autom4te.cfg basically hard coded with no variable replacement, perhaps you could recover the generated Makefile from a run where this issue happens ? <bauen1>either make is faulty or what ever generated autoconf-2.57/lib/Makefile from Makefile.in occasionally strips the \.cfg from autom4te <bauen1>gforce_d11977: do you have a normal run log for comparision ? <gforce_d11977>ok, i will also share a normal run an a diff (sorry, was away) <gforce_d11977>bauen1: sorry i cannot recover anything, but i can add for the next mass-run a "cat Makefile"? <bauen1>gforce_d11977: maybe you can inject `--debug` to the make invokations of binutils-2.57 (warning *a lot* of logs) <bauen1>and maybe, just so it's easier to spot differencees do a sha256 of *every* file at the end / abort of a bootstrap, but that's also gonna take some time <bauen1>mostly because checksum coverage isn't great at the moment <bauen1>gforce_d11977: --debug will allow us to see **why** autoconf-2.57/bin/Makefile wants to run autom4te instead of building the other binaries <bauen1>gforce_d11977: if you add it to every make call, that will be very very big log files (1gb or more per run wouldn't surprise me) <gforce_d11977>bauen1: hmmm...space is not an issue here, so i will go for it <bauen1>gforce_d11977: cover /after/bin, /after/lib, /after/include <bauen1>gforce_d11977: but yes, adding --debug to every make call will allow us to see any time stamp related differences <bauen1>gforce_d11977: oh and i think /after/share if it exists <bauen1>gforce_d11977: maybe you can also start to include the last git commit in the logs <bauen1>and if the tree was modified, that should make it easy to find the right source tree to go with the logs <bauen1>gforce_d11977: i may have found a hint at why autoconf-2.57 is failing <bauen1>autoconf2.57/bin/Makefile.in:454 `$(srcdir)/autoconf.in: $(srcdir)/autoconf.as # FIXME: $(m4sh_m4f_dependencies)` <bauen1>that is the rule that seems to execute `01h50m15s | ../tests/autom4te --language M4sh --cache '' ./autoconf.as -o autoconf.in` <bauen1>and the FIXME hints at a variable that contains `$(AUTOM4TE_CFG)` <bauen1>so probably make needs to know about a dependency <bauen1>and sometimes the timestamps don't quite align and it tries to run the command that depends on $(AUTOM4TE_CFG) before it was build <bauen1>maybe a `touch bin/*.in` will fix things <bauen1>gforce_d11977: does your kernel support high resolution time stamps ? <gforce_d11977>ok, the touch is a good idea. high res timetimestamps are not compiled it, but i can add this: very good idea. maybe this fixes everything 8-) <gforce_d11977>ok, will make a mass-testrun with # CONFIG_SCHED_HRTICK=y # CONFIG_HZ_100=y # CONFIG_HIGH_RES_TIMERS=y - maybe something changes ***ChanServ sets mode: +o rekado
<stikonas>just kernel changes on its own wouldn't fix those errors <stikonas>cause I saw them on normal linux kernel too <bauen1>gforce_d11977: those are without touching a few files ? <bauen1>gforce_d11977: by the way you can use haproxy to mix vpn / ssh / https over port 443 <bauen1>gforce_d11977: by the filename i'm assuming it took around 14 runs at least to find a bad one ? <bauen1>so something curious: for autoconf-2.53 the good run had `make[1]: Nothing to be done for `all'.` but the bad run tried to update the man and info pages <bauen1>the fact that bin/Makefile.in contains a target for bin/autoconf.in from bin/autoconf.as also leads me to believe that bin/autoconf.in in the autoconf-2.57 (and possibly others) is a generated file <bauen1>gforce_d11977: and in general i would be quite interested in 2 runs where `--debug` is passed to any make invokation, that could highlight a few more issues <stikonas>bauen1: yeah, that might be true, looks like it's updated from autoconf.as <gforce_d11977>bauen1: i took one run to find a bad one, but they all (24) run in parallel <bauen1>gforce_d11977: i was wondering if the high precision timer has an effect on the failure rate, but i'm not sure if 24 runs are significant enough <stikonas>looks like it's introduced in autoconf 2.54 <gforce_d11977>bauen1: strange, i add --debug to all make invocations, but it does not seems to have an effect <gforce_d11977>bauen1: I found my mistake: i only added it to src_install() not in src_compile() will do and have another run <bauen1>gforce_d11977: some scripts also invoke `make` manually, but i think that should cover most <bauen1>if that computer has nothing else to do, you could use those 70 minutes to figure out what it should do after ;) <stikonas>bauen1: maybe open an issue for autoconf.in file? <stikonas>can we not just run autom4te --language M4sh ./autoconf.as -o autoconf.in <bauen1>can't edit the title, but this issue is about the symptoms of using the pregenerated autoconf.in <bauen1>stikonas: i'm not too sure, you should take a look at bin/Makefile.in in autoconf-2.57 since in theory there is a target to generate it <stikonas>it's just that we might be using older autom4te <stikonas>instead of that build-in progress autom4te form current tarball <bauen1>ah yes and autom4te requires autom4te.cfg <stikonas>not the one that is installed in /after/bin <bauen1>i understand too little about autohell \o/ <bauen1>if that command makes things work then that looks good enough <stikonas>well, I guess it would be autom4te --language M4sh ./bin/autoconf.as -o bin/autoconf.in <bauen1>being verify specific in what version of those tools you want will probably be a requirement if my work is merged, i can't really deal with multiple "pseudo packages" providing /after/bin/aclocal nicely <bauen1>and you'll have to specify a version anyway <stikonas>well, at the moment aclocal symlinks are created to point to the latest version... <stikonas>at least until latest autoconf and automake are built <stikonas>after that it's basically almost always the latest version that we want to use <stikonas>later versions of autotools are significantly more compatible anywya <stikonas>but yes, in most places we explicitely specify e.g. autoconf-2.52 <bauen1>i'll be finding every place where we don't lol <gforce_d11977>stikonas: bauen1: there is something really strange happening, and i'am out of ideas now. i must have something to do with buffering and so with the underlying libc IMHO <stikonas>definitely not as frequent here as 20%... <bauen1>gforce_d11977: and you're displaying sha256sum of basically after/{bin,lib,share} ? <bauen1>well the good news is that none of the sha256sums seem to mismatch between the good / bad run <bauen1>but i suppose that's bad news too <bauen1>and the make debug output already shows a few timing differences, e.g. `01h11m32s | Prerequisite `include/gettext.h' is newer than target `builtins/common.c'.` <bauen1>i'm not sure if we want to remove pregenerated man pages / documentation, but imho yes <stikonas>bauen1: yes, I think we want. I already opened an issue some time ago <stikonas>as they are clearly not used in building anything later <bauen1>right, and they're slightly affecting what make does (depending on timing) as seen in the logs above <bauen1>i should probably put my commits for fixing DESTDIR in various cases, this and some other tiny fixes together for a mr <bauen1>ah that great moment when tcc is finally compiled and stuff starts to actually happen ... <stikonas>bauen1: well, there is always pder/overlay to speed things up <stikonas>although, I think my python PR will break it <stikonas>since I'm changing some of the early stuff <gforce_d11977>i'am digging through musl.git: git log --grep=bug | wc -l = 4323 <bauen1>stikonas: actually you're adding support to not use a tmpfs (without taking a chainsaw to rootfs.sh), so now we'd only need to get kaem / bash to skip rebuilding if the checksums already match <stikonas>I only had an option to pick another dir for tmpfs mount <gforce_d11977>tonight i will add a job to build 500 CI-runs for getting better numbers how often each error occurs....cu tomorrow. when i should add something for debugging, let me know <stikonas>fixing those intermittent errors is annoying.. <stikonas>but it looks like at least some of those are bugs in releases ***lukedashjr is now known as luke-jr
<stikonas>hmm, got qemu upgrade... now it prints qemu: initrd is too large, cannot support.(max: 8224767, need 151816704) <stikonas>although, most of the stuff inside is in compressed tarballs