<stikonas>pder: so I was playing a bit with binutils, have some updates... <stikonas>I was able to regenerate 9 out of 10 configure scripts <stikonas>and for some reason intl/configure fails <stikonas>especially considering that we run with --disable-intl <stikonas>I get /after/include/musl/bits/alltypes.h:148: error: identifier expected <stikonas>so that leaves intl/configure and quite a few Makefile.am files that we still need to deal with) <stikonas>this should be quite uncontroversial and wouldn't conflict with anything <fossy>oh yeah, meant to merge that <stikonas>ok, I think I'll fix autoconf tomorrow after you merge your readme changes.. <stikonas>I might try to also try to install it in some versioned folder, so that we can hav multiple autoconfs <fossy>or, install the binary/script as autoconf252 <stikonas>I think by default autoconf's install does autoconf-2.52 <OriansJ`>so that it matches standard sha256sum file1 file2 ... fileN behavior and standard sha256sum -c file1 file2 .. fileN behavior as well. <OriansJ`>The only parts I skipped were exit codes and the counting of number of correct/incorrect <OriansJ`>with some tweaking to M2-Planet+M2libc and the source code, it could possibly be built by M2-Planet+M2libc and be made available earlier in the bootstrap chain. <marusich>In short, the bug is that cross-compiling the bootstrap binaries for powerpc64-linux-gnu (and also for powerpc64le-linux-gnu, and perhaps for other architectures, too) from x86_64-linux Guix, produces a different GCC 5.5.0 when everything is built entirely from source (i.e., without substitutes) on different machines. <marusich>The update of interest to bootstrappable is that I think I have narrowed down the likely causes to about 21 derivations, and many of them appear to come from the "reduced bootstrap" packages, which use mes and so forth. <marusich>I am curious to know if anyone knows of known reproducibililty issues or has any ideas, after reading my latest update there. I'm wondering if the guile 2 vs guile 3 difference is significant. <marusich>One side effect result of my testing is that it shows clearly that some derivations like those used to build mesboot, gash-utils, etc., are definitely not reproducible, even when built on the same system. ***mephista is now known as spicy_icecream
<OriansJ`>marusich: my first thought was the guix hashing producing the difference; however guile2 vs guile3 is a big difference. And gash-utils+bootar have not been tested for reproducibility yet. <OriansJ`>but I know for certain that reproducible builds spent a great deal of effort on GCC reproducibility and they probably didn't backport those fixes to earlier GCC versions. <roptat>hi! any idea about the build time for the rust bootstrap chain (from mrustc) in Guix? and for gcc (from mes)? <stikonas>well, maybe depends on which gcc versoin <stikonas>so rust-1.19 to rust 1.50 or so would take a few days on slower machine <roptat>let's say gcc 7, since that's the default one in Guix <stikonas>well, for gcc bootstrap slowest steps are scheme... <roptat>which scheme do you build? I thought it was all from mes? <roptat>so, in total, from mes to gcc 7? <stikonas>well, mes and tcc takes about 20 minutes <roptat>yeah, sounds like a very good machine ^^ <roptat>I remember build times going on for ~5-10 hours for a single version of gcc when I built LFS systems <stikonas>can't really remember exactly the last time I did it... <roptat>yeah, that was like 10 years ago ^^ <stikonas>well, live-bootstrap currently takes maybe 25 minutes, but that's obviously not finished, we haven't reached gcc there <roptat>I managed to build in one week-end by building everything up to gcc on Saturday, building gcc during the night, and finishing the system on Sunday ^^ <roptat>maybe there's a way I could test on my machine, with the current guix bootstrap? <stikonas>well, if you do guix gc and clean everything and do git pull it should rebuild everything from mes <roptat>a bit wasteful, but I guess it would work if I ask to build gcc@7 with --no-substitutes? <stikonas>a few people here build with no-substitutes <stikonas>I rebuild janneke's wip-m2 branch from hex0 to stuff like latest rust <roptat>what's missing from the branch for merging in Guix? (apart from having ci build it) <stikonas>well, with a little bit of uusual cheating that guix does <stikonas>roptat: like I said, guix reuses guile to run some of the things, then it uses pregenerated bison files, pregenerated configure scripts <stikonas>that's why fossy, pder and I are working on live-bootstrap project which does not do these things <stikonas>so we basically dealt with the first two problems, and halfway through the last one <stikonas>roptat: not sure if you saw my reply, you got disconnected <roptat>oh I see, there's guile from guix which gets injected in the build environment, to drive the build <roptat>and some pregenerated files that are not removed <roptat>actually, I got a nice idea to get an estimate of the build time: look at ci's build times :) <roptat>there seems to be a lot of variation depending on the versions <stikonas>roptat: so at this stage live-bootstrap diverged a bit from guix bootstrap, to bootstrap bison we had to switch to musl C library <stikonas>then to bootstrap autotools, we had to do some partial perl bootstrapping <stikonas>but I hope that we might be able to skip old GCC and jump to newer one ***pgreco_ is now known as pgreco
<roptat>oh, ci doesn't show correct information for rust < 1.46 <roptat>but estimating from numbers I found, it should be between 1 and 3 days ***cbaines_ is now known as cbaines
<stikonas>fossy (cc pder), so I'm mostly done with my autotools changes, but I've rebased them on top of unmerged part numbering change PR, so I guess that has to go first <stikonas>it's much nicer now with automatic numbering <fossy>Before it didnt and I was so confuse <stikonas>fossy: yeah, but I had some problems with rst2html on your file <fossy>I bet I could just remove that line <stikonas>much nicer to work with automatic numbering now... <fossy>Ok ill remove that and merge <stikonas>and after autoconf I guess pder can do bash... <stikonas>but maybe will wait for previous CI to pass <fossy>a push cancels the previous one <fossy>but stops waste of time i guess <fossy>omg, our first autotools created program! <stikonas>and different versions should be coinstallable <stikonas>but running these overwrites those files <stikonas>good that automake can be basically built with just autoconf <stikonas>just had to install manually without makefile <stikonas>fossy: hmm, as long as autoconf and automake pass, I guess pre-removing configure script does not gain us anything... <fossy>stikonas: i would prefer the rm for clarity; it makes it extremely clear which files are being regenerated <stikonas>"./aclocal.m4:46: error: Autoconf version 2.54 or higher is required for this script" <stikonas>but bash can be rebuilt with 2.52, so I thought it's worth doing that anyway <stikonas>since we'll finally get interactive shell <stikonas>fossy: oh, I think we also need autoconf 2.12.1 <stikonas>do you want me to add it or merge current PR first? <stikonas>so only need to regenerate automake stuff <stikonas>But it's more of the same (autoconf 2.12 now ) <stikonas>fossy: pder so I think I can build binutils I might need to do minimal build/install <stikonas>i.e. enter binutils or ld dirs and run make there <stikonas>otherwise I get some problems with documentation build (pod2man is missing) <stikonas>hmm, maybe I should tweak makefiles do kill po and doc dirs... <stikonas>pder: maybe let's rebuild bash after binutils then?