Hello Janneke!
It’s taken me a while but I successfully built
/gnu/store/58q6748dydqxrhrw8xn2gsf60djl6gvv-hello-2.10
for i686 from commit 5d8b7131c23d2285dd3546c59022dd5953508943 of
‘wip-bootstrap’. :-)
--8<---------------cut here---------------start------------->8---
$ guix hash -r /gnu/store/58q6748dydqxrhrw8xn2gsf60djl6gvv-hello-2.10
005zi21nvhmygjam6vsvkgmw9awsmyacz6a65naxcblrpbra1g94
--8<---------------cut here---------------end--------------->8---
The “interesting commits” are these:
5d8b7131c * gnu: mes: Oops, use mirror://gnu download url.
1ff6d26ac * bootstrap: Replace GNU toolchain seeds with Mes for i686-linux.
ca8895bdb * bootstrap: Add Mes bootstrap.
be65bf958 * gnu: Add Mes bootstrap seeds.
45856f886 * gnu: Add linux-libre-headers-bootstrap-tarball.
cd9830fcd * guix: copy-linux-headers: Prepare for Mes bootstrap.
6265040e7 * guix: package-from-tarball: Allow PROGRAM-TO-TEST to be #f.
8d9c16ed3 * gnu: texinfo-boot0: Remove bootstrap leaks.
f9a76a79c * gnu: bison-boot0: Remove bootstrap leaks.
12394cc83 * gnu: m4-boot0: New variable.
6891da335 * gnu: perl-boot0: Remove bootstrap leaks.
f933b162c * gnu: file-boot0: Remove bootstrap leaks.
9c0912a20 * gnu: findutils-boot0: Remove bootstrap leaks.
53616d896 * gnu: diffutils-boot0: Remove bootstrap leaks.
7503cee76 * bootstrap: %bootstrap-inputs+toolchain: Prepare for Mes bootstrap.
80bd4a995 * bootstrap: %bootstrap-inputs: Prepare for Mes bootstrap.
I looked at the result and overall it LGTM! So I think the next step is
to rebase the branch on ‘core-updates’ (or merge it) and rename it
‘core-updates-next’. WDYT? Ricardo?
Previously we discussed that “-s i686-linux” on x86_64 would lead to a
different graph compared to a native i686-linux run. Is it still the
case? It looks like 80bd4a995 does the right thing in that respect.
Some comments on things that I think could be improved, in no particular
order:
• It would be good to update the “Bootstrapping” section of the
manual—no urgency though. It would be useful both to Guix
developers and to outsiders interested in bootstrapping
(Bootstrappable, Reproducible Builds, maybe projects like GNU/Linux
From Scratch, etc.)
• I think all the “mesboot” & co. packages in commencement.scam can be
made private–i.e., changing ‘define-public’ to ‘define’.
• There’s a couple of tests (for example in tests/debug-link.scm) that
rely on %gcc-bootstrap, on the assumption that building it is
cheap. We should double-check that these are still okay on i686.
• IWBN to add comments for gcc-mesboot1-wrapper,
glibc-headers-mesboot, %bootstrap-inputs+toolchain, just a line or
two giving some context.
• I saw a couple of hanging parens in commencement.scm, they want to
be next to their friends. ;-)
• Minor style issues:
`(,@(substitute-keyword-arguments …)) → (substitute-keyword-arguments …)
(zero? (system* …)) → (invoke …)
• Could you add a couple of lines of explanation at the top of the new
gnu/packages/patches/*.patch files, as we do for other patches?
Some of them could also be simplified; for instance
‘glibc-boot-2.2.5.patch’ contains the diff of what looks like a
leftover file.
• For ‘binutils-mesboot0’: package/inherit → package (inherit …)
since replacement for ‘binutils’ certainly won’t apply to
‘binutils-mesboot0’.
• For commit 80bd4a995 for instance, instead of “Prepare for Mes
bootstrap”, the message could be “Wrap input lists into thunks.” or
something like that to clarify what the actual change is.
I noticed that:
./pre-inst-env guix graph -e '(begin (use-modules (guix utils))
(%current-system "i686-linux")(@@ (gnu packages commencement) gnu-make-boot0))'
| dot -Tps > t.ps
shows lots of repetitions, which defeats eq? memoization, but the
problem is not new; I’ll try to look into fixing this.
As we were discussing on IRC, we’ll have to figure out what the next
step should be, once this branch has become ‘core-updates-next’. One
interesting bit is to remove the mes.M1 seed, as you wrote. Another one
might be to do x86_64 bootstrapping (using i686 binaries at the
beginning of the graph, until we reach gcc@4.9, at which point we should
be able to build x86_64 binaries; though maybe I’m just too naive here
:-)). Another low-hanging fruit (I think!) is using Gash instead of
Bash, though that’s completely orthogonal.
Thoughts?
Thank you for the amazing work, and again apologies for taking so long
to get back to you!
Ludo’.
