bug#36747: Official MesCC bootstrap binaries differ from my locally built ones

bug#36747: Official MesCC bootstrap binaries differ from my locally built ones

[Mark H Weaver]

I'm working to independently verify the new bootstrap binaries.  Toward
that end, I locally built the new bootstrap tarballs by running the
following command from a git checkout at commit
ef809e3ac036eccc5f9c9edd8fb661d14ae15f2f.

  ./pre-inst-env guix build bootstrap-tarballs --system=i686-linux

This produces a mescc-tools-static-0.5.2-0.bb062b0-i686-linux.tar.xz
tarball that differs from the official one.  See below for the precise
differences, but what they boil down to is that the official tarball
contains several references to:

  /gnu/store/xjr9rv1p4vgg9sclwzsai17gqi1c1d9j-glibc-2.28

Whereas in my locally built tarball, these references are instead to:

  /gnu/store/ggj9164ahhn1kmdcyl3sm27qsxk46h01-glibc-2.28

First of all, I hope we can agree that our bootstrap binaries shouldn't
include any references to the store.

However, it also raises the curious question of how I ended up with
references to a different glibc than the one referenced by the official
tarball.  Any idea what happened here?

Note that I have copies of _both_ of the above glibc outputs on my local
machine, as well as their derivations and build logs.  Everything on
this machine is locally built, since I never use substitutes.

--8<---------------cut here---------------start------------->8---
mhw@jojen ~$ guix build --log-file /gnu/store/xjr9rv1p4vgg9sclwzsai17gqi1c1d9j-glibc-2.28
/var/log/guix/drvs/s5/s8yb94gdp1ym2hgyyygqrh038gsiqw-glibc-2.28.drv.bz2
mhw@jojen ~$ guix build --log-file /gnu/store/ggj9164ahhn1kmdcyl3sm27qsxk46h01-glibc-2.28
/var/log/guix/drvs/wf/yp8sg7afy9m2vlhar8rvmn22w25hmc-glibc-2.28.drv.bz2
--8<---------------cut here---------------end--------------->8---

The glibc referenced in the official MesCC bootstrap binaries was built
on my local machine on 16 December 2018, when I built an earlier version
of the bootstrap binaries for independent verification, using Guix at
commit da3c6a7f19ef1243af725f63c16c8fd92fde33b4.  I've retained them
ever since, because I registered a GC root for them, and I run my
guix-daemon with --gc-keep-derivations=yes and --gc-keep-outputs=yes.

The other glibc, referenced in my locally built MesCC bootstrap binary,
was built only a few hours ago:

--8<---------------cut here---------------start------------->8---
mhw@jojen ~$ ls -l /var/log/guix/drvs/s5/s8yb94gdp1ym2hgyyygqrh038gsiqw-glibc-2.28.drv.bz2 /var/log/guix/drvs/wf/yp8sg7afy9m2vlhar8rvmn22w25hmc-glibc-2.28.drv.bz2
-rw-r--r-- 1 root root 285219 Dec 16  2018 /var/log/guix/drvs/s5/s8yb94gdp1ym2hgyyygqrh038gsiqw-glibc-2.28.drv.bz2
-rw-r--r-- 1 root root 285154 Jul 20 03:11 /var/log/guix/drvs/wf/yp8sg7afy9m2vlhar8rvmn22w25hmc-glibc-2.28.drv.bz2
--8<---------------cut here---------------end--------------->8---

See below for the contents of these two derivations, and further down
for the precise differences between the official MesCC bootstrap
binaries and the ones built on my machine.

Any idea what's going on here?

     Thanks,
       Mark


Comparison of the derivations that produced these two glibc outputs:

--8<---------------cut here---------------start------------->8---
mhw@jojen ~$ cat /gnu/store/s5s8yb94gdp1ym2hgyyygqrh038gsiqw-glibc-2.28.drv; echo
Derive([("debug","/gnu/store/p526py2jj23zg378033qa1094kjkvlzk-glibc-2.28-debug","",""),("out","/gnu/store/xjr9rv1p4vgg9sclwzsai17gqi1c1d9j-glibc-2.28","",""),("static","/gnu/store/ws5z6apb5sg8khg17sk06xhk2pj5g518-glibc-2.28-static","","")],[("/gnu/store/0rl51d8dy35mlaggp8j6syfrrgivfhsj-srfi-43.scm.drv",["out"]),("/gnu/store/1dz9ddx84s4lgpcayy71kd01w493ab8f-guile-bootstrap-2.0.drv",["out"]),("/gnu/store/22g8aki15frq5cdmq4v32kz7pkd5x3rf-binutils-cross-boot0-2.31.1.drv",["out"]),("/gnu/store/22qdy2xdjsfzaxq8g9xwsl47ldcc0azm-bison-3.0.5.drv",["out"]),("/gnu/store/2bdw2779cqxqczg0k4fci100fnfr6g44-diffutils-boot0-3.6.drv",["out"]),("/gnu/store/2z7q85qm0g37i8p6494yb23n04jsh7h4-perl-boot0-5.28.0.drv",["out"]),("/gnu/store/42frdzbk7gkqfhwqaim9yk4li0y6ns01-gettext-boot0-0.19.8.1.drv",["out"]),("/gnu/store/5vd6z8f6y78ryr18j34gzy1l7cf9lhc4-texinfo-6.5.drv",["out"]),("/gnu/store/6h6gq4z3gfzpax4kagi5a245xb8nfbqf-bootstrap-mes-0.drv",["out"]),("/gnu/store/6vrfl0m6frvb7qg6k1xh5kv19n1g63m4-module-import-compiled.drv",["out"]),("/gnu/store/739ssha506n08va2n959vpb2fg0cf5x4-make-boot0-4.2.1.drv",["out"]),("/gnu/store/8921l4sb2y3hy054z56q5h08j98fdh41-file-boot0-5.33.drv",["out"]),("/gnu/store/8ckhpzhv764wycnyvkpkvvhw0bx1d4d5-gcc-mesboot-4.9.4.drv",["out"]),("/gnu/store/b52z5rshzynh46dl5140v1959y2bc7ng-bash-static-4.4.23.drv",["out"]),("/gnu/store/dsfnzzdl7lxdgh5j7wsbwcxaajy662nb-linux-libre-headers-bootstrap-0.drv",["out"]),("/gnu/store/fzx2xaih5x4cr3y8m3i6s9xi35jzbyb1-findutils-boot0-4.6.0.drv",["out"]),("/gnu/store/g6zayh2j861qhspkn4grl53ikm5nqzcz-gcc-cross-boot0-5.5.0.drv",["out"]),("/gnu/store/k6kqmd9vq3zyy9z4r6yns5i0wb4jprsx-module-import.drv",["out"]),("/gnu/store/l3rbwq6s3kq2hf9ijizyqyc75qgl776g-gcc-mesboot-wrapper-4.7.4.drv",["out"]),("/gnu/store/mb0j1fpzasjx1036hd9dbkdgvk7467gs-linux-libre-headers-4.14.67.drv",["out"]),("/gnu/store/msmqmwxx2lap7c4lvxjj0l40627pr09r-ld-wrapper-boot0-0.drv",["out"]),("/gnu/store/s6ygb5hnq73yhmbqq91a7hm1wq0jn4ba-m4-1.4.18.drv",["out"]),("/gnu/store/scnwi0hfmk6wmc222a61mkglflsb4k82-glibc-2.28.tar.xz.drv",["out"]),("/gnu/store/vlzyim2nn5nznkfa2dspbchp4sb70bxq-bootstrap-binaries-0.drv",["out"]),("/gnu/store/yd9vch8dlfif0hgkkmjkimc87s41fcrv-bootstrap-mescc-tools-0.5.2.drv",["out"]),("/gnu/store/z2rq1cj3f7vjiaxsjrmy4d5shjz6wwwg-glibc-mesboot-2.16.0.drv",["out"])],["/gnu/store/a245dby8gf25c9ikifgdi5zf9z32wfz9-glibc-2.28-guile-builder"],"i686-linux","/gnu/store/djh3drjx3hnxlx1bsdnixdm3xjbg5v2c-guile-bootstrap-2.0/bin/guile",["--no-auto-compile","-L","/gnu/store/iqr0nr40sg7cgpaxjjg7vibax69nsq8h-module-import","/gnu/store/a245dby8gf25c9ikifgdi5zf9z32wfz9-glibc-2.28-guile-builder"],[("GUILE_LOAD_COMPILED_PATH","/gnu/store/plym8lbl9610vj6ylxg70sx86s9m3c2b-module-import-compiled"),("allowedReferences","/gnu/store/ay5p7413ryib96gr488hp066m8mpw2yi-gcc-cross-boot0-5.5.0-lib /gnu/store/k6h5pi0gjpwg4mzb5f0vh8f3hz4abvzz-linux-libre-headers-4.14.67 /gnu/store/8aac1rm5n1q3w6l5djhzaw1hwbz6nldj-bash-static-4.4.23 out debug static"),("debug","/gnu/store/p526py2jj23zg378033qa1094kjkvlzk-glibc-2.28-debug"),("out","/gnu/store/xjr9rv1p4vgg9sclwzsai17gqi1c1d9j-glibc-2.28"),("static","/gnu/store/ws5z6apb5sg8khg17sk06xhk2pj5g518-glibc-2.28-static")])
mhw@jojen ~$ cat /gnu/store/wfyp8sg7afy9m2vlhar8rvmn22w25hmc-glibc-2.28.drv; echo
Derive([("debug","/gnu/store/j9vhacdrjlrv3bzrgbrvigdybvnql09p-glibc-2.28-debug","",""),("out","/gnu/store/ggj9164ahhn1kmdcyl3sm27qsxk46h01-glibc-2.28","",""),("static","/gnu/store/s10gqbx5m4sz3yn126zfqlrwxaks0slm-glibc-2.28-static","","")],[("/gnu/store/4rbgkir0nbsyw47wgm6iha57dlqgd4xr-file-boot0-5.33.drv",["out"]),("/gnu/store/7r27xar6limlz2wxis5v078bk8w5wqr4-gettext-boot0-0.19.8.1.drv",["out"]),("/gnu/store/7zgc2ikwf87gh3h5zmj6mhnywck5r0l8-bootstrap-binaries-0.drv",["out"]),("/gnu/store/86ws6viwkkffgs0f2lp25kzc6nq0d0jw-m4-1.4.18.drv",["out"]),("/gnu/store/9ai57qjjjd0iq9v99jyini6sy60x92vv-bison-3.2.2.drv",["out"]),("/gnu/store/b2r1g8wds9v60g7q8215lvl7bfidsfy4-glibc-2.28.tar.xz.drv",["out"]),("/gnu/store/b5nn5fjkvs06m4vlj853qzza08azcgxj-bootstrap-mes-0.drv",["out"]),("/gnu/store/b75j8fwz1nx5qkg8jz4hqvzbdw8mmsak-bash-static-4.4.23.drv",["out"]),("/gnu/store/bcybhh9l1075m2rpcw7vxysr9mdncqm7-gcc-mesboot-wrapper-4.7.4.drv",["out"]),("/gnu/store/bgqxrpdrrmfvp7n5r0hv770gmzdvnbg4-guile-bootstrap-2.0.drv",["out"]),("/gnu/store/cmy9vnca89r58mq7y03a4brrsla5rc9r-bootstrap-mescc-tools-0.5.2.drv",["out"]),("/gnu/store/gp09w4n2cfxkczrbvw3288gr4cprjgib-gcc-cross-boot0-5.5.0.drv",["out"]),("/gnu/store/gsmclbr9x7l4gk24jv6snd9bna02vdcb-module-import.drv",["out"]),("/gnu/store/hjd5zrg6bdqlqxzv2y7jcwmij6r8983x-glibc-mesboot-2.16.0.drv",["out"]),("/gnu/store/if9k5sdlfpwsc7rd4b3grmlfwgdb4m5g-perl-boot0-5.28.1.drv",["out"]),("/gnu/store/j9z73l4x81xgnxz0skyj0njrqy2nfhxy-gcc-mesboot-4.9.4.drv",["out"]),("/gnu/store/jczyw8ihvlh3yy9ypi3rnphgszpwvij7-linux-libre-headers-bootstrap-0.drv",["out"]),("/gnu/store/k1j5swxajphrrjcmznmkl6xajq7pnb21-ld-wrapper-boot0-0.drv",["out"]),("/gnu/store/kgizc8jv7id3xyczddj325lh98f8ii0w-module-import-compiled.drv",["out"]),("/gnu/store/lr079n33vdvik6wmrpkclqpmb4969psv-binutils-cross-boot0-2.31.1.drv",["out"]),("/gnu/store/m7vr8r3gfbq0zklay0k7n46lqzwwnzvs-linux-libre-headers-4.14.67.drv",["out"]),("/gnu/store/q0n0l5shcnsrgdgqfpzzqzis5p3hwjgn-diffutils-boot0-3.6.drv",["out"]),("/gnu/store/q6wfr6nywlgk7hbh46qrddzdkx66r6lr-make-boot0-4.2.1.drv",["out"]),("/gnu/store/s1jn1lp0kfdd881xvjjkypp1mk9yx7wk-findutils-boot0-4.6.0.drv",["out"]),("/gnu/store/v0cahwnlwzmdgvw09fg4sq4hv558n2yy-srfi-43.scm.drv",["out"]),("/gnu/store/yg6lplxhwh3iwlagiji5m58wym5r0mb2-texinfo-6.5.drv",["out"])],["/gnu/store/fc0phdb4hp943vj48mvf7fq0hvc2cijx-glibc-2.28-guile-builder"],"i686-linux","/gnu/store/djh3drjx3hnxlx1bsdnixdm3xjbg5v2c-guile-bootstrap-2.0/bin/guile",["--no-auto-compile","-L","/gnu/store/72ng0zh4qr4lfhaxmz6pgfsn8rcnk85w-module-import","/gnu/store/fc0phdb4hp943vj48mvf7fq0hvc2cijx-glibc-2.28-guile-builder"],[("GUILE_LOAD_COMPILED_PATH","/gnu/store/ivfirsrq74c0i76i2ri0r9ra78y0llv7-module-import-compiled"),("allowedReferences","/gnu/store/f2w43qwpwyi10yqmx23kbwp7giczq25l-gcc-cross-boot0-5.5.0-lib /gnu/store/hwxvrxfyrmcrn4i8kzl9gwnkpkrjdkhj-linux-libre-headers-4.14.67 /gnu/store/yz3q2266n3ganhranh7xqg5fs0lkp3py-bash-static-4.4.23 out debug static"),("debug","/gnu/store/j9vhacdrjlrv3bzrgbrvigdybvnql09p-glibc-2.28-debug"),("out","/gnu/store/ggj9164ahhn1kmdcyl3sm27qsxk46h01-glibc-2.28"),("static","/gnu/store/s10gqbx5m4sz3yn126zfqlrwxaks0slm-glibc-2.28-static")])
--8<---------------cut here---------------end--------------->8---


Detailed comparison of the official mescc bootstrap tarball contents,
compared to the one I built locally:

--8<---------------cut here---------------start------------->8---
mhw@jojen ~/new-bootstrap-binaries/unpacked-mescc-tools-static$ diff -ru official locally-built
Binary files official/blood-elf and locally-built/blood-elf differ
diff -ru official/blood-elf.hex locally-built/blood-elf.hex
--- official/blood-elf.hex	2019-07-20 17:48:02.924329972 -0400
+++ locally-built/blood-elf.hex	2019-07-20 17:48:02.268326719 -0400
@@ -23719,16 +23719,16 @@
 0005e2f0  73 00 4c 41 4e 47 55 41  47 45 00 50 4f 53 49 58  |s.LANGUAGE.POSIX|
 0005e300  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
 *
-0005e320  2f 67 6e 75 2f 73 74 6f  72 65 2f 78 6a 72 39 72  |/gnu/store/xjr9r|
-0005e330  76 31 70 34 76 67 67 39  73 63 6c 77 7a 73 61 69  |v1p4vgg9sclwzsai|
-0005e340  31 37 67 71 69 31 63 31  64 39 6a 2d 67 6c 69 62  |17gqi1c1d9j-glib|
+0005e320  2f 67 6e 75 2f 73 74 6f  72 65 2f 67 67 6a 39 31  |/gnu/store/ggj91|
+0005e330  36 34 61 68 68 6e 31 6b  6d 64 63 79 6c 33 73 6d  |64ahhn1kmdcyl3sm|
+0005e340  32 37 71 73 78 6b 34 36  68 30 31 2d 67 6c 69 62  |27qsxk46h01-glib|
 0005e350  63 2d 32 2e 32 38 2f 73  68 61 72 65 2f 6c 6f 63  |c-2.28/share/loc|
 0005e360  61 6c 65 00 6d 65 73 73  61 67 65 73 00 6c 6c 6f  |ale.messages.llo|
 0005e370  00 6c 6c 78 00 49 00 6c  6c 75 00 6c 6c 58 00 6c  |.llx.I.llu.llX.l|
 0005e380  6c 64 00 6c 6c 69 00 72  63 65 00 00 2f 67 6e 75  |ld.lli.rce../gnu|
-0005e390  2f 73 74 6f 72 65 2f 78  6a 72 39 72 76 31 70 34  |/store/xjr9rv1p4|
-0005e3a0  76 67 67 39 73 63 6c 77  7a 73 61 69 31 37 67 71  |vgg9sclwzsai17gq|
-0005e3b0  69 31 63 31 64 39 6a 2d  67 6c 69 62 63 2d 32 2e  |i1c1d9j-glibc-2.|
+0005e390  2f 73 74 6f 72 65 2f 67  67 6a 39 31 36 34 61 68  |/store/ggj9164ah|
+0005e3a0  68 6e 31 6b 6d 64 63 79  6c 33 73 6d 32 37 71 73  |hn1kmdcyl3sm27qs|
+0005e3b0  78 6b 34 36 68 30 31 2d  67 6c 69 62 63 2d 32 2e  |xk46h01-glibc-2.|
 0005e3c0  32 38 2f 73 68 61 72 65  2f 6c 6f 63 61 6c 65 00  |28/share/locale.|
 0005e3d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
 0005e3e0  b0 e9 04 08 b0 e9 04 08  58 e8 04 08 90 e8 04 08  |........X.......|
@@ -24245,9 +24245,9 @@
 000604e0  61 74 75 73 20 3d 3d 20  5f 5f 47 43 4f 4e 56 5f  |atus == __GCONV_|
 000604f0  46 55 4c 4c 5f 4f 55 54  50 55 54 00 5f 5f 6d 62  |FULL_OUTPUT.__mb|
 00060500  73 72 74 6f 77 63 73 5f  6c 00 00 00 2f 67 6e 75  |srtowcs_l.../gnu|
-00060510  2f 73 74 6f 72 65 2f 78  6a 72 39 72 76 31 70 34  |/store/xjr9rv1p4|
-00060520  76 67 67 39 73 63 6c 77  7a 73 61 69 31 37 67 71  |vgg9sclwzsai17gq|
-00060530  69 31 63 31 64 39 6a 2d  67 6c 69 62 63 2d 32 2e  |i1c1d9j-glibc-2.|
+00060510  2f 73 74 6f 72 65 2f 67  67 6a 39 31 36 34 61 68  |/store/ggj9164ah|
+00060520  68 6e 31 6b 6d 64 63 79  6c 33 73 6d 32 37 71 73  |hn1kmdcyl3sm27qs|
+00060530  78 6b 34 36 68 30 31 2d  67 6c 69 62 63 2d 32 2e  |xk46h01-glibc-2.|
 00060540  32 38 2f 6c 69 62 65 78  65 63 2f 67 65 74 63 6f  |28/libexec/getco|
 00060550  6e 66 00 47 45 54 43 4f  4e 46 5f 44 49 52 00 4c  |nf.GETCONF_DIR.L|
 00060560  50 36 34 5f 4f 46 46 36  34 00 4c 50 42 49 47 5f  |P64_OFF64.LPBIG_|
@@ -24604,9 +24604,9 @@
 00061bf0  43 53 2d 32 42 45 2f 2f  00 55 4e 49 43 4f 44 45  |CS-2BE//.UNICODE|
 00061c00  42 49 47 2f 2f 00 00 00  00 00 00 00 00 00 00 00  |BIG//...........|
 00061c10  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
-00061c20  2f 67 6e 75 2f 73 74 6f  72 65 2f 78 6a 72 39 72  |/gnu/store/xjr9r|
-00061c30  76 31 70 34 76 67 67 39  73 63 6c 77 7a 73 61 69  |v1p4vgg9sclwzsai|
-00061c40  31 37 67 71 69 31 63 31  64 39 6a 2d 67 6c 69 62  |17gqi1c1d9j-glib|
+00061c20  2f 67 6e 75 2f 73 74 6f  72 65 2f 67 67 6a 39 31  |/gnu/store/ggj91|
+00061c30  36 34 61 68 68 6e 31 6b  6d 64 63 79 6c 33 73 6d  |64ahhn1kmdcyl3sm|
+00061c40  32 37 71 73 78 6b 34 36  68 30 31 2d 67 6c 69 62  |27qsxk46h01-glib|
 00061c50  63 2d 32 2e 32 38 2f 6c  69 62 2f 67 63 6f 6e 76  |c-2.28/lib/gconv|
 00061c60  00 67 63 6f 6e 76 5f 62  75 69 6c 74 69 6e 2e 63  |.gconv_builtin.c|
 00061c70  00 00 00 00 63 6e 74 20  3c 20 73 69 7a 65 6f 66  |....cnt < sizeof|
@@ -24707,9 +24707,9 @@
 00062260  5f 5f 67 63 6f 6e 76 5f  74 72 61 6e 73 66 6f 72  |__gconv_transfor|
 00062270  6d 5f 69 6e 74 65 72 6e  61 6c 5f 75 63 73 34 00  |m_internal_ucs4.|
 00062280  c0 e0 f0 f8 fc 47 43 4f  4e 56 5f 50 41 54 48 00  |.....GCONV_PATH.|
-00062290  2f 67 6e 75 2f 73 74 6f  72 65 2f 78 6a 72 39 72  |/gnu/store/xjr9r|
-000622a0  76 31 70 34 76 67 67 39  73 63 6c 77 7a 73 61 69  |v1p4vgg9sclwzsai|
-000622b0  31 37 67 71 69 31 63 31  64 39 6a 2d 67 6c 69 62  |17gqi1c1d9j-glib|
+00062290  2f 67 6e 75 2f 73 74 6f  72 65 2f 67 67 6a 39 31  |/gnu/store/ggj91|
+000622a0  36 34 61 68 68 6e 31 6b  6d 64 63 79 6c 33 73 6d  |64ahhn1kmdcyl3sm|
+000622b0  32 37 71 73 78 6b 34 36  68 30 31 2d 67 6c 69 62  |27qsxk46h01-glib|
 000622c0  63 2d 32 2e 32 38 2f 6c  69 62 2f 67 63 6f 6e 76  |c-2.28/lib/gconv|
 000622d0  2f 67 63 6f 6e 76 2d 6d  6f 64 75 6c 65 73 2e 63  |/gconv-modules.c|
 000622e0  61 63 68 65 00 67 63 6f  6e 76 5f 64 6c 2e 63 00  |ache.gconv_dl.c.|
@@ -28182,9 +28182,9 @@
 00070290  10 00 00 00 01 00 00 00  47 4e 55 00 7f 45 4c 46  |........GNU..ELF|
 000702a0  01 01 01 03 00 00 00 00  7f 45 4c 46 01 01 01 00  |.........ELF....|
 000702b0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
-000702c0  2f 67 6e 75 2f 73 74 6f  72 65 2f 78 6a 72 39 72  |/gnu/store/xjr9r|
-000702d0  76 31 70 34 76 67 67 39  73 63 6c 77 7a 73 61 69  |v1p4vgg9sclwzsai|
-000702e0  31 37 67 71 69 31 63 31  64 39 6a 2d 67 6c 69 62  |17gqi1c1d9j-glib|
+000702c0  2f 67 6e 75 2f 73 74 6f  72 65 2f 67 67 6a 39 31  |/gnu/store/ggj91|
+000702d0  36 34 61 68 68 6e 31 6b  6d 64 63 79 6c 33 73 6d  |64ahhn1kmdcyl3sm|
+000702e0  32 37 71 73 78 6b 34 36  68 30 31 2d 67 6c 69 62  |27qsxk46h01-glib|
 000702f0  63 2d 32 2e 32 38 2f 6c  69 62 2f 00 64 6c 2d 6c  |c-2.28/lib/.dl-l|
 00070300  6f 6f 6b 75 70 2e 63 00  20 28 6e 6f 20 76 65 72  |ookup.c. (no ver|
 00070310  73 69 6f 6e 20 73 79 6d  62 6f 6c 73 29 00 2c 20  |sion symbols)., |
Binary files official/hex2 and locally-built/hex2 differ
diff -ru official/hex2.hex locally-built/hex2.hex
--- official/hex2.hex	2019-07-20 17:48:03.140331043 -0400
+++ locally-built/hex2.hex	2019-07-20 17:48:02.488327810 -0400
@@ -23990,16 +23990,16 @@
 0005f4b0  68 61 72 73 65 74 3d 00  20 09 0a 00 25 73 2f 25  |harset=. ...%s/%|
 0005f4c0  73 00 4c 41 4e 47 55 41  47 45 00 50 4f 53 49 58  |s.LANGUAGE.POSIX|
 0005f4d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
-0005f4e0  2f 67 6e 75 2f 73 74 6f  72 65 2f 78 6a 72 39 72  |/gnu/store/xjr9r|
-0005f4f0  76 31 70 34 76 67 67 39  73 63 6c 77 7a 73 61 69  |v1p4vgg9sclwzsai|
-0005f500  31 37 67 71 69 31 63 31  64 39 6a 2d 67 6c 69 62  |17gqi1c1d9j-glib|
+0005f4e0  2f 67 6e 75 2f 73 74 6f  72 65 2f 67 67 6a 39 31  |/gnu/store/ggj91|
+0005f4f0  36 34 61 68 68 6e 31 6b  6d 64 63 79 6c 33 73 6d  |64ahhn1kmdcyl3sm|
+0005f500  32 37 71 73 78 6b 34 36  68 30 31 2d 67 6c 69 62  |27qsxk46h01-glib|
 0005f510  63 2d 32 2e 32 38 2f 73  68 61 72 65 2f 6c 6f 63  |c-2.28/share/loc|
 0005f520  61 6c 65 00 6d 65 73 73  61 67 65 73 00 6c 6c 6f  |ale.messages.llo|
 0005f530  00 6c 6c 78 00 49 00 6c  6c 75 00 6c 6c 58 00 6c  |.llx.I.llu.llX.l|
 0005f540  6c 64 00 6c 6c 69 00 72  63 65 00 00 2f 67 6e 75  |ld.lli.rce../gnu|
-0005f550  2f 73 74 6f 72 65 2f 78  6a 72 39 72 76 31 70 34  |/store/xjr9rv1p4|
-0005f560  76 67 67 39 73 63 6c 77  7a 73 61 69 31 37 67 71  |vgg9sclwzsai17gq|
-0005f570  69 31 63 31 64 39 6a 2d  67 6c 69 62 63 2d 32 2e  |i1c1d9j-glibc-2.|
+0005f550  2f 73 74 6f 72 65 2f 67  67 6a 39 31 36 34 61 68  |/store/ggj9164ah|
+0005f560  68 6e 31 6b 6d 64 63 79  6c 33 73 6d 32 37 71 73  |hn1kmdcyl3sm27qs|
+0005f570  78 6b 34 36 68 30 31 2d  67 6c 69 62 63 2d 32 2e  |xk46h01-glibc-2.|
 0005f580  32 38 2f 73 68 61 72 65  2f 6c 6f 63 61 6c 65 00  |28/share/locale.|
 0005f590  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
 0005f5a0  b0 f8 04 08 b0 f8 04 08  58 f7 04 08 90 f7 04 08  |........X.......|
@@ -24516,9 +24516,9 @@
 000616a0  61 74 75 73 20 3d 3d 20  5f 5f 47 43 4f 4e 56 5f  |atus == __GCONV_|
 000616b0  46 55 4c 4c 5f 4f 55 54  50 55 54 00 5f 5f 6d 62  |FULL_OUTPUT.__mb|
 000616c0  73 72 74 6f 77 63 73 5f  6c 00 00 00 2f 67 6e 75  |srtowcs_l.../gnu|
-000616d0  2f 73 74 6f 72 65 2f 78  6a 72 39 72 76 31 70 34  |/store/xjr9rv1p4|
-000616e0  76 67 67 39 73 63 6c 77  7a 73 61 69 31 37 67 71  |vgg9sclwzsai17gq|
-000616f0  69 31 63 31 64 39 6a 2d  67 6c 69 62 63 2d 32 2e  |i1c1d9j-glibc-2.|
+000616d0  2f 73 74 6f 72 65 2f 67  67 6a 39 31 36 34 61 68  |/store/ggj9164ah|
+000616e0  68 6e 31 6b 6d 64 63 79  6c 33 73 6d 32 37 71 73  |hn1kmdcyl3sm27qs|
+000616f0  78 6b 34 36 68 30 31 2d  67 6c 69 62 63 2d 32 2e  |xk46h01-glibc-2.|
 00061700  32 38 2f 6c 69 62 65 78  65 63 2f 67 65 74 63 6f  |28/libexec/getco|
 00061710  6e 66 00 47 45 54 43 4f  4e 46 5f 44 49 52 00 4c  |nf.GETCONF_DIR.L|
 00061720  50 36 34 5f 4f 46 46 36  34 00 4c 50 42 49 47 5f  |P64_OFF64.LPBIG_|
@@ -24875,9 +24875,9 @@
 00062db0  43 53 2d 32 42 45 2f 2f  00 55 4e 49 43 4f 44 45  |CS-2BE//.UNICODE|
 00062dc0  42 49 47 2f 2f 00 00 00  00 00 00 00 00 00 00 00  |BIG//...........|
 00062dd0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
-00062de0  2f 67 6e 75 2f 73 74 6f  72 65 2f 78 6a 72 39 72  |/gnu/store/xjr9r|
-00062df0  76 31 70 34 76 67 67 39  73 63 6c 77 7a 73 61 69  |v1p4vgg9sclwzsai|
-00062e00  31 37 67 71 69 31 63 31  64 39 6a 2d 67 6c 69 62  |17gqi1c1d9j-glib|
+00062de0  2f 67 6e 75 2f 73 74 6f  72 65 2f 67 67 6a 39 31  |/gnu/store/ggj91|
+00062df0  36 34 61 68 68 6e 31 6b  6d 64 63 79 6c 33 73 6d  |64ahhn1kmdcyl3sm|
+00062e00  32 37 71 73 78 6b 34 36  68 30 31 2d 67 6c 69 62  |27qsxk46h01-glib|
 00062e10  63 2d 32 2e 32 38 2f 6c  69 62 2f 67 63 6f 6e 76  |c-2.28/lib/gconv|
 00062e20  00 67 63 6f 6e 76 5f 62  75 69 6c 74 69 6e 2e 63  |.gconv_builtin.c|
 00062e30  00 00 00 00 63 6e 74 20  3c 20 73 69 7a 65 6f 66  |....cnt < sizeof|
@@ -24978,9 +24978,9 @@
 00063420  5f 5f 67 63 6f 6e 76 5f  74 72 61 6e 73 66 6f 72  |__gconv_transfor|
 00063430  6d 5f 69 6e 74 65 72 6e  61 6c 5f 75 63 73 34 00  |m_internal_ucs4.|
 00063440  c0 e0 f0 f8 fc 47 43 4f  4e 56 5f 50 41 54 48 00  |.....GCONV_PATH.|
-00063450  2f 67 6e 75 2f 73 74 6f  72 65 2f 78 6a 72 39 72  |/gnu/store/xjr9r|
-00063460  76 31 70 34 76 67 67 39  73 63 6c 77 7a 73 61 69  |v1p4vgg9sclwzsai|
-00063470  31 37 67 71 69 31 63 31  64 39 6a 2d 67 6c 69 62  |17gqi1c1d9j-glib|
+00063450  2f 67 6e 75 2f 73 74 6f  72 65 2f 67 67 6a 39 31  |/gnu/store/ggj91|
+00063460  36 34 61 68 68 6e 31 6b  6d 64 63 79 6c 33 73 6d  |64ahhn1kmdcyl3sm|
+00063470  32 37 71 73 78 6b 34 36  68 30 31 2d 67 6c 69 62  |27qsxk46h01-glib|
 00063480  63 2d 32 2e 32 38 2f 6c  69 62 2f 67 63 6f 6e 76  |c-2.28/lib/gconv|
 00063490  2f 67 63 6f 6e 76 2d 6d  6f 64 75 6c 65 73 2e 63  |/gconv-modules.c|
 000634a0  61 63 68 65 00 67 63 6f  6e 76 5f 64 6c 2e 63 00  |ache.gconv_dl.c.|
@@ -28453,9 +28453,9 @@
 00071450  10 00 00 00 01 00 00 00  47 4e 55 00 7f 45 4c 46  |........GNU..ELF|
 00071460  01 01 01 03 00 00 00 00  7f 45 4c 46 01 01 01 00  |.........ELF....|
 00071470  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
-00071480  2f 67 6e 75 2f 73 74 6f  72 65 2f 78 6a 72 39 72  |/gnu/store/xjr9r|
-00071490  76 31 70 34 76 67 67 39  73 63 6c 77 7a 73 61 69  |v1p4vgg9sclwzsai|
-000714a0  31 37 67 71 69 31 63 31  64 39 6a 2d 67 6c 69 62  |17gqi1c1d9j-glib|
+00071480  2f 67 6e 75 2f 73 74 6f  72 65 2f 67 67 6a 39 31  |/gnu/store/ggj91|
+00071490  36 34 61 68 68 6e 31 6b  6d 64 63 79 6c 33 73 6d  |64ahhn1kmdcyl3sm|
+000714a0  32 37 71 73 78 6b 34 36  68 30 31 2d 67 6c 69 62  |27qsxk46h01-glib|
 000714b0  63 2d 32 2e 32 38 2f 6c  69 62 2f 00 64 6c 2d 6c  |c-2.28/lib/.dl-l|
 000714c0  6f 6f 6b 75 70 2e 63 00  20 28 6e 6f 20 76 65 72  |ookup.c. (no ver|
 000714d0  73 69 6f 6e 20 73 79 6d  62 6f 6c 73 29 00 2c 20  |sion symbols)., |
Binary files official/M1 and locally-built/M1 differ
diff -ru official/M1.hex locally-built/M1.hex
--- official/M1.hex	2019-07-20 17:48:03.360332134 -0400
+++ locally-built/M1.hex	2019-07-20 17:48:02.708328901 -0400
@@ -23998,16 +23998,16 @@
 0005f490  68 61 72 73 65 74 3d 00  20 09 0a 00 25 73 2f 25  |harset=. ...%s/%|
 0005f4a0  73 00 4c 41 4e 47 55 41  47 45 00 50 4f 53 49 58  |s.LANGUAGE.POSIX|
 0005f4b0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
-0005f4c0  2f 67 6e 75 2f 73 74 6f  72 65 2f 78 6a 72 39 72  |/gnu/store/xjr9r|
-0005f4d0  76 31 70 34 76 67 67 39  73 63 6c 77 7a 73 61 69  |v1p4vgg9sclwzsai|
-0005f4e0  31 37 67 71 69 31 63 31  64 39 6a 2d 67 6c 69 62  |17gqi1c1d9j-glib|
+0005f4c0  2f 67 6e 75 2f 73 74 6f  72 65 2f 67 67 6a 39 31  |/gnu/store/ggj91|
+0005f4d0  36 34 61 68 68 6e 31 6b  6d 64 63 79 6c 33 73 6d  |64ahhn1kmdcyl3sm|
+0005f4e0  32 37 71 73 78 6b 34 36  68 30 31 2d 67 6c 69 62  |27qsxk46h01-glib|
 0005f4f0  63 2d 32 2e 32 38 2f 73  68 61 72 65 2f 6c 6f 63  |c-2.28/share/loc|
 0005f500  61 6c 65 00 6d 65 73 73  61 67 65 73 00 6c 6c 6f  |ale.messages.llo|
 0005f510  00 6c 6c 78 00 49 00 6c  6c 75 00 6c 6c 58 00 6c  |.llx.I.llu.llX.l|
 0005f520  6c 64 00 6c 6c 69 00 72  63 65 00 00 2f 67 6e 75  |ld.lli.rce../gnu|
-0005f530  2f 73 74 6f 72 65 2f 78  6a 72 39 72 76 31 70 34  |/store/xjr9rv1p4|
-0005f540  76 67 67 39 73 63 6c 77  7a 73 61 69 31 37 67 71  |vgg9sclwzsai17gq|
-0005f550  69 31 63 31 64 39 6a 2d  67 6c 69 62 63 2d 32 2e  |i1c1d9j-glibc-2.|
+0005f530  2f 73 74 6f 72 65 2f 67  67 6a 39 31 36 34 61 68  |/store/ggj9164ah|
+0005f540  68 6e 31 6b 6d 64 63 79  6c 33 73 6d 32 37 71 73  |hn1kmdcyl3sm27qs|
+0005f550  78 6b 34 36 68 30 31 2d  67 6c 69 62 63 2d 32 2e  |xk46h01-glibc-2.|
 0005f560  32 38 2f 73 68 61 72 65  2f 6c 6f 63 61 6c 65 00  |28/share/locale.|
 0005f570  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
 0005f580  80 f9 04 08 80 f9 04 08  28 f8 04 08 60 f8 04 08  |........(...`...|
@@ -24524,9 +24524,9 @@
 00061680  61 74 75 73 20 3d 3d 20  5f 5f 47 43 4f 4e 56 5f  |atus == __GCONV_|
 00061690  46 55 4c 4c 5f 4f 55 54  50 55 54 00 5f 5f 6d 62  |FULL_OUTPUT.__mb|
 000616a0  73 72 74 6f 77 63 73 5f  6c 00 00 00 2f 67 6e 75  |srtowcs_l.../gnu|
-000616b0  2f 73 74 6f 72 65 2f 78  6a 72 39 72 76 31 70 34  |/store/xjr9rv1p4|
-000616c0  76 67 67 39 73 63 6c 77  7a 73 61 69 31 37 67 71  |vgg9sclwzsai17gq|
-000616d0  69 31 63 31 64 39 6a 2d  67 6c 69 62 63 2d 32 2e  |i1c1d9j-glibc-2.|
+000616b0  2f 73 74 6f 72 65 2f 67  67 6a 39 31 36 34 61 68  |/store/ggj9164ah|
+000616c0  68 6e 31 6b 6d 64 63 79  6c 33 73 6d 32 37 71 73  |hn1kmdcyl3sm27qs|
+000616d0  78 6b 34 36 68 30 31 2d  67 6c 69 62 63 2d 32 2e  |xk46h01-glibc-2.|
 000616e0  32 38 2f 6c 69 62 65 78  65 63 2f 67 65 74 63 6f  |28/libexec/getco|
 000616f0  6e 66 00 47 45 54 43 4f  4e 46 5f 44 49 52 00 4c  |nf.GETCONF_DIR.L|
 00061700  50 36 34 5f 4f 46 46 36  34 00 4c 50 42 49 47 5f  |P64_OFF64.LPBIG_|
@@ -24883,9 +24883,9 @@
 00062d90  43 53 2d 32 42 45 2f 2f  00 55 4e 49 43 4f 44 45  |CS-2BE//.UNICODE|
 00062da0  42 49 47 2f 2f 00 00 00  00 00 00 00 00 00 00 00  |BIG//...........|
 00062db0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
-00062dc0  2f 67 6e 75 2f 73 74 6f  72 65 2f 78 6a 72 39 72  |/gnu/store/xjr9r|
-00062dd0  76 31 70 34 76 67 67 39  73 63 6c 77 7a 73 61 69  |v1p4vgg9sclwzsai|
-00062de0  31 37 67 71 69 31 63 31  64 39 6a 2d 67 6c 69 62  |17gqi1c1d9j-glib|
+00062dc0  2f 67 6e 75 2f 73 74 6f  72 65 2f 67 67 6a 39 31  |/gnu/store/ggj91|
+00062dd0  36 34 61 68 68 6e 31 6b  6d 64 63 79 6c 33 73 6d  |64ahhn1kmdcyl3sm|
+00062de0  32 37 71 73 78 6b 34 36  68 30 31 2d 67 6c 69 62  |27qsxk46h01-glib|
 00062df0  63 2d 32 2e 32 38 2f 6c  69 62 2f 67 63 6f 6e 76  |c-2.28/lib/gconv|
 00062e00  00 67 63 6f 6e 76 5f 62  75 69 6c 74 69 6e 2e 63  |.gconv_builtin.c|
 00062e10  00 00 00 00 63 6e 74 20  3c 20 73 69 7a 65 6f 66  |....cnt < sizeof|
@@ -24986,9 +24986,9 @@
 00063400  5f 5f 67 63 6f 6e 76 5f  74 72 61 6e 73 66 6f 72  |__gconv_transfor|
 00063410  6d 5f 69 6e 74 65 72 6e  61 6c 5f 75 63 73 34 00  |m_internal_ucs4.|
 00063420  c0 e0 f0 f8 fc 47 43 4f  4e 56 5f 50 41 54 48 00  |.....GCONV_PATH.|
-00063430  2f 67 6e 75 2f 73 74 6f  72 65 2f 78 6a 72 39 72  |/gnu/store/xjr9r|
-00063440  76 31 70 34 76 67 67 39  73 63 6c 77 7a 73 61 69  |v1p4vgg9sclwzsai|
-00063450  31 37 67 71 69 31 63 31  64 39 6a 2d 67 6c 69 62  |17gqi1c1d9j-glib|
+00063430  2f 67 6e 75 2f 73 74 6f  72 65 2f 67 67 6a 39 31  |/gnu/store/ggj91|
+00063440  36 34 61 68 68 6e 31 6b  6d 64 63 79 6c 33 73 6d  |64ahhn1kmdcyl3sm|
+00063450  32 37 71 73 78 6b 34 36  68 30 31 2d 67 6c 69 62  |27qsxk46h01-glib|
 00063460  63 2d 32 2e 32 38 2f 6c  69 62 2f 67 63 6f 6e 76  |c-2.28/lib/gconv|
 00063470  2f 67 63 6f 6e 76 2d 6d  6f 64 75 6c 65 73 2e 63  |/gconv-modules.c|
 00063480  61 63 68 65 00 67 63 6f  6e 76 5f 64 6c 2e 63 00  |ache.gconv_dl.c.|
@@ -28461,9 +28461,9 @@
 00071430  10 00 00 00 01 00 00 00  47 4e 55 00 7f 45 4c 46  |........GNU..ELF|
 00071440  01 01 01 03 00 00 00 00  7f 45 4c 46 01 01 01 00  |.........ELF....|
 00071450  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
-00071460  2f 67 6e 75 2f 73 74 6f  72 65 2f 78 6a 72 39 72  |/gnu/store/xjr9r|
-00071470  76 31 70 34 76 67 67 39  73 63 6c 77 7a 73 61 69  |v1p4vgg9sclwzsai|
-00071480  31 37 67 71 69 31 63 31  64 39 6a 2d 67 6c 69 62  |17gqi1c1d9j-glib|
+00071460  2f 67 6e 75 2f 73 74 6f  72 65 2f 67 67 6a 39 31  |/gnu/store/ggj91|
+00071470  36 34 61 68 68 6e 31 6b  6d 64 63 79 6c 33 73 6d  |64ahhn1kmdcyl3sm|
+00071480  32 37 71 73 78 6b 34 36  68 30 31 2d 67 6c 69 62  |27qsxk46h01-glib|
 00071490  63 2d 32 2e 32 38 2f 6c  69 62 2f 00 64 6c 2d 6c  |c-2.28/lib/.dl-l|
 000714a0  6f 6f 6b 75 70 2e 63 00  20 28 6e 6f 20 76 65 72  |ookup.c. (no ver|
 000714b0  73 69 6f 6e 20 73 79 6d  62 6f 6c 73 29 00 2c 20  |sion symbols)., |
--8<---------------cut here---------------end--------------->8---

bug#36747: Official MesCC bootstrap binaries differ from my locally built ones

[Jan Nieuwenhuizen]

[-- Attachment #1: Type: text/plain, Size: 3181 bytes --]

Mark H Weaver writes:

> I'm working to independently verify the new bootstrap binaries.  Toward
> that end, I locally built the new bootstrap tarballs by running the
> following command from a git checkout at commit
> ef809e3ac036eccc5f9c9edd8fb661d14ae15f2f.
>
>   ./pre-inst-env guix build bootstrap-tarballs --system=i686-linux
>
> This produces a mescc-tools-static-0.5.2-0.bb062b0-i686-linux.tar.xz
> tarball that differs from the official one.  See below for the precise
> differences, but what they boil down to is that the official tarball
> contains several references to:
>
>   /gnu/store/xjr9rv1p4vgg9sclwzsai17gqi1c1d9j-glibc-2.28
>
> Whereas in my locally built tarball, these references are instead to:
>
>   /gnu/store/ggj9164ahhn1kmdcyl3sm27qsxk46h01-glibc-2.28

Aww, that's not good :(

> First of all, I hope we can agree that our bootstrap binaries shouldn't
> include any references to the store.

I think that is our policy and it is probably safest not to do so; at
least in code.  A piece of documentation can include a string
/gnu/store/.... as long at it is static and not really a reference.

Store references in bootstrap binaries or scripts cannot be used or
depended on: if our bootstrap build is clean those references will not
exist when the bootstrap binaries run.

In any case, if store references are present in bootstrap binaries, then
they should be reproducible.  Removing store references is one way to
make them reproducible but I'm not sure if that's the best way?

Making a reference invalid helps making sure that it isn't used.  But if
it cannot be used anyway, removing it could hide the fact that it may
differs accros builds, as we are finding out right now.  Thoughts?

> However, it also raises the curious question of how I ended up with
> references to a different glibc than the one referenced by the official
> tarball.  Any idea what happened here?

Yes, that's something that I would like to know...

Anyway, I have built a new set of bootstrap binaries for mescc-tools and
mes using attched patches that remove store references (also on my
https://gitlab.com/janneke/guix core-updates).

I have just verified that tcc-boot0 builds by using this local
modification

--8<---------------cut here---------------start------------->8---
15:05:56 janneke@dundal:~/src/guix/core-updates [env]
$ git diff
diff --git a/gnu/packages/bootstrap.scm b/gnu/packages/bootstrap.scm
index 73fc7d3e5e..bca90bec94 100644
--- a/gnu/packages/bootstrap.scm
+++ b/gnu/packages/bootstrap.scm
@@ -288,7 +288,8 @@ or false to signal an error."
 
 (define %bootstrap-base-urls
   ;; This is where the initial binaries come from.
-  '("https://alpha.gnu.org/gnu/guix/bootstrap"
+  '("http://lilypond.org/janneke/guix"
+    "https://alpha.gnu.org/gnu/guix/bootstrap"
     "http://alpha.gnu.org/gnu/guix/bootstrap"
     "ftp://alpha.gnu.org/gnu/guix/bootstrap"
     "http://www.fdn.fr/~lcourtes/software/guix/packages"
--8<---------------cut here---------------end--------------->8---

and running
 
    ./pre-inst-env guix build --system=i686-linux -e '(@@ (gnu packages commencement) tcc-boot0)'

Thanks again for looking into this!

Greetings,
janneke


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-bootstrap-mescc-tools-static-stripped-Remove-store-r.patch --]
[-- Type: text/x-patch, Size: 2658 bytes --]

From 11c12e30bbdb1a10fd56dc9d5c14548e49b63c12 Mon Sep 17 00:00:00 2001
From: Jan Nieuwenhuizen <janneke@gnu.org>
Date: Sun, 21 Jul 2019 11:40:54 +0200
Subject: [PATCH 1/4] bootstrap: mescc-tools-static-stripped: Remove store
 references.

* gnu/packages/make-bootstrap.scm (%mescc-tools-static-stripped): Rename from
%mescc-tools-static; update users.  Remove store references.
---
 gnu/packages/make-bootstrap.scm | 27 +++++++++++++++++++--------
 1 file changed, 19 insertions(+), 8 deletions(-)

diff --git a/gnu/packages/make-bootstrap.scm b/gnu/packages/make-bootstrap.scm
index 2163b646f6..8cc4eef430 100644
--- a/gnu/packages/make-bootstrap.scm
+++ b/gnu/packages/make-bootstrap.scm
@@ -585,16 +585,27 @@ for `sh' in $PATH, and without nscd, and with static NSS modules."
            #t))))
     (inputs `(("gcc" ,%gcc-static)))))
 
-(define %mescc-tools-static
-  ;; A statically linked MesCC Tools for bootstrap.
+(define %mescc-tools-static-stripped
+  ;; A statically linked Mescc Tools with store references removed, for
+  ;; bootstrap.
   (package
     (inherit mescc-tools)
-    (name "mescc-tools-static")
+    (name "mescc-tools-static-stripped")
     (arguments
-     `(#:system "i686-linux"
-       ,@(substitute-keyword-arguments (package-arguments mescc-tools)
-           ((#:make-flags flags)
-            `(cons "CC=gcc -static" ,flags)))))))
+     `(#:make-flags (list (string-append "PREFIX=" (assoc-ref %outputs "out"))
+                          "CC=gcc -static")
+       #:test-target "test"
+       #:phases (modify-phases %standard-phases
+                  (delete 'configure)
+                  (add-after 'install 'strip-store-references
+                    (lambda _
+                      (let* ((out (assoc-ref %outputs "out"))
+                             (bin (string-append out "/bin")))
+                        (for-each (lambda (file)
+                                 (let ((target (string-append bin "/" file)))
+                                   (format #t "strippingg `~a'...~%" target)
+                                   (remove-store-references target)))
+                               '( "M1" "blood-elf" "hex2"))))))))))
 
 (define-public %mes-minimal-stripped
   ;; A minimal Mes without documentation dependencies, for bootstrap.
@@ -791,7 +802,7 @@ for `sh' in $PATH, and without nscd, and with static NSS modules."
 
 (define %mescc-tools-bootstrap-tarball
   ;; A tarball with MesCC binary seed.
-  (tarball-package %mescc-tools-static))
+  (tarball-package %mescc-tools-static-stripped))
 
 (define %mes-bootstrap-tarball
   ;; A tarball with Mes ASCII Seed and binary Mes C Library.
-- 
2.21.0


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: 0002-bootstrap-mes-minimal-stripped-Remove-store-referenc.patch --]
[-- Type: text/x-patch, Size: 2040 bytes --]

From 2e13b6fff94027158b3de5d3a1469dc9f89b0c39 Mon Sep 17 00:00:00 2001
From: Jan Nieuwenhuizen <janneke@gnu.org>
Date: Sun, 21 Jul 2019 14:27:07 +0200
Subject: [PATCH 2/4] bootstrap: mes-minimal-stripped: Remove store references.

* gnu/packages/make-bootstrap.scm (%mes-minimal-stripped): Remove store
references.
---
 gnu/packages/make-bootstrap.scm | 15 +++++++++++----
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/gnu/packages/make-bootstrap.scm b/gnu/packages/make-bootstrap.scm
index 8cc4eef430..af89ca8c3c 100644
--- a/gnu/packages/make-bootstrap.scm
+++ b/gnu/packages/make-bootstrap.scm
@@ -621,6 +621,7 @@ for `sh' in $PATH, and without nscd, and with static NSS modules."
          #:configure-flags '("--mes")
          #:phases
          (modify-phases %standard-phases
+           (delete 'patch-shebangs)
            (add-after 'install 'strip-install
              (lambda _
                (let* ((out (assoc-ref %outputs "out"))
@@ -628,10 +629,16 @@ for `sh' in $PATH, and without nscd, and with static NSS modules."
                  (delete-file-recursively (string-append out "/lib/guile"))
                  (delete-file-recursively (string-append share "/guile"))
                  (delete-file-recursively (string-append share "/mes/scaffold"))
-                 (for-each
-                  delete-file
-                  (find-files (string-append share  "/mes/lib")
-                              "\\.(h|c)")))))))))))
+
+                 (for-each delete-file
+                           (find-files
+                            (string-append share "/mes/lib") "\\.(h|c)"))
+
+                 (for-each (lambda (dir)
+                             (for-each remove-store-references
+                                       (find-files (string-append out "/" dir)
+                                                   ".*")))
+                           '("bin" "share/mes")))))))))))
 
 (define %guile-static
   ;; A statically-linked Guile that is relocatable--i.e., it can search
-- 
2.21.0


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #4: 0003-bootstrap-bootstrap-mescc-tools-Update.patch --]
[-- Type: text/x-patch, Size: 1704 bytes --]

From 172ee1045689cd42d2de837ee560d32c43730cc3 Mon Sep 17 00:00:00 2001
From: Jan Nieuwenhuizen <janneke@gnu.org>
Date: Sun, 21 Jul 2019 14:38:52 +0200
Subject: [PATCH 3/4] bootstrap: bootstrap-mescc-tools: Update.

    Built with
        2e13b6fff94027158b3de5d3a1469dc9f89b0c39 bootstrap: mes-minimal-stripped: Remove store references.

    * gnu/packages/bootstrap.scm (%bootstrap-mescc-tools): Update.
---
 gnu/packages/bootstrap.scm | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/gnu/packages/bootstrap.scm b/gnu/packages/bootstrap.scm
index 8dbe52435e..a8a5c93e01 100644
--- a/gnu/packages/bootstrap.scm
+++ b/gnu/packages/bootstrap.scm
@@ -703,7 +703,7 @@ exec ~a/bin/.gcc-wrapped -B~a/lib \
   ;; %MESCC-TOOLS-BOOTSTRAP-TARBALL.
   (package
     (name "bootstrap-mescc-tools")
-    (version "0.5.2")
+    (version "1")
     (source #f)
     (build-system trivial-build-system)
     (arguments
@@ -735,12 +735,12 @@ exec ~a/bin/.gcc-wrapped -B~a/lib \
             (method url-fetch)
             (uri (map
                   (cute string-append <>
-                        "/i686-linux/20181020/"
-                        "mescc-tools-static-0.5.2-0.bb062b0-i686-linux.tar.xz")
+                        "/i686-linux/20190721/"
+                        "mescc-tools-static-stripped-0.5.2-0.bb062b0-i686-linux.tar.xz")
                   %bootstrap-base-urls))
             (sha256
              (base32
-              "11lniw0vg61kmyhvnwkmcnkci9ym6hbmiksiqggd0hkipbq7hvlz")))))))
+              "0h7sbc5im74gxjx3xybqavq7hacbg7gcl4sznc1mpw67yja49f75")))))))
     (synopsis "Bootstrap binaries of MesCC Tools")
     (description synopsis)
     (home-page #f)
-- 
2.21.0


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #5: 0004-bootstrap-bootstrap-mes-Update.patch --]
[-- Type: text/x-patch, Size: 1591 bytes --]

From e316146f23dce4156fc8c5b3b28cd5e180487cda Mon Sep 17 00:00:00 2001
From: Jan Nieuwenhuizen <janneke@gnu.org>
Date: Sun, 21 Jul 2019 14:42:35 +0200
Subject: [PATCH 4/4] bootstrap: bootstrap-mes: Update.

    Built with
        2e13b6fff94027158b3de5d3a1469dc9f89b0c39 bootstrap: mes-minimal-stripped: Remove store references.

* gnu/packages/bootstrap.scm (%bootstrap-mes): Update.
---
 gnu/packages/bootstrap.scm | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/gnu/packages/bootstrap.scm b/gnu/packages/bootstrap.scm
index a8a5c93e01..73fc7d3e5e 100644
--- a/gnu/packages/bootstrap.scm
+++ b/gnu/packages/bootstrap.scm
@@ -752,7 +752,7 @@ exec ~a/bin/.gcc-wrapped -B~a/lib \
   ;; %MES-BOOTSTRAP-TARBALL.
   (package
     (name "bootstrap-mes")
-    (version "0")
+    (version "1")
     (source #f)
     (build-system trivial-build-system)
     (arguments
@@ -784,12 +784,12 @@ exec ~a/bin/.gcc-wrapped -B~a/lib \
             (method url-fetch)
             (uri (map
                   (cute string-append <>
-                        "/i686-linux/20181020/"
+                        "/i686-linux/20190721/"
                         "mes-minimal-stripped-0.19-i686-linux.tar.xz")
                   %bootstrap-base-urls))
             (sha256
              (base32
-              "0k7kkl68a6xaadv47ij0nr9jm5ca1ffj38n7f2lg80y72wdkwr9h")))))))
+              "0c8j9p84vx4w8fz6bkxf57wsarq3ng1ka09h18lv3lfxxvnpiak6")))))))
     (supported-systems '("i686-linux" "x86_64-linux"))
     (synopsis "Bootstrap binaries of Mes")
     (description synopsis)
-- 
2.21.0


[-- Attachment #6: Type: text/plain, Size: 152 bytes --]


-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

bug#36747: Official MesCC bootstrap binaries differ from my locally built ones

[Mark H Weaver]

Hi Janneke,

Thanks very much for the quick response to this issue.

Jan Nieuwenhuizen <janneke@gnu.org> wrote:
> In any case, if store references are present in bootstrap binaries, then
> they should be reproducible.  Removing store references is one way to
> make them reproducible but I'm not sure if that's the best way?
>
> Making a reference invalid helps making sure that it isn't used.  But if
> it cannot be used anyway, removing it could hide the fact that it may
> differs accros builds, as we are finding out right now.  Thoughts?

I agree that store references should be removed, i.e. the hash component
of the store file names should be replaced with all eeeeee's.  Note that
'e' is never found in a valid Nix base32 hash string.  This is what was
done in our older bootstrap binaries, which we've been using for many
years, since the early days of Guix.

I'd like to build the new bootstrap binaries, but I'm unsure how to
proceed.  In your new batch of commits, you reference the commit that
was used to perform the build:

> From 172ee1045689cd42d2de837ee560d32c43730cc3 Mon Sep 17 00:00:00 2001
> From: Jan Nieuwenhuizen <janneke@gnu.org>
> Date: Sun, 21 Jul 2019 14:38:52 +0200
> Subject: [PATCH 3/4] bootstrap: bootstrap-mescc-tools: Update.
> 
>     Built with
>         2e13b6fff94027158b3de5d3a1469dc9f89b0c39 bootstrap: mes-minimal-stripped: Remove store references.
> 
>     * gnu/packages/bootstrap.scm (%bootstrap-mescc-tools): Update.

I guess that I should build from a checkout of commit
2e13b6fff94027158b3de5d3a1469dc9f89b0c39.  However, that commit is not
on Savannah, as demonstrated by the following URL, which reports "Bad
commit reference: 2e13b6fff94027158b3de5d3a1469dc9f89b0c39".

  https://git.savannah.gnu.org/cgit/guix.git/commit/?id=2e13b6fff94027158b3de5d3a1469dc9f89b0c39

The other issue is that your proposed new fixes do not seem to apply to
'master'.  Did you build the newly fixed bootstrap tarballs from
something based on 'core-updates'?  If so, that leaves me no way to
independently verify the new bootstrap without putting my trust in the
slightly older bootstrap -- the same one that I just failed to
reproduce.

What I need is a way to build the new bootstrap tarballs without using
the existing 'core-updates' branch.  I need a way to build them from a
branch that's based upon the much older bootstrap binaries that we've
been using for many years.  Preferably, they should be built from
something close to current 'master'.

Is this feasible?

     Thanks,
       Mark

bug#36747: Official MesCC bootstrap binaries differ from my locally built ones

[Jan Nieuwenhuizen]

Mark H Weaver writes:

Hi Mark,

> I agree that store references should be removed, i.e. the hash component
> of the store file names should be replaced with all eeeeee's.  Note that
> 'e' is never found in a valid Nix base32 hash string.  This is what was
> done in our older bootstrap binaries, which we've been using for many
> years, since the early days of Guix.

Yes, I understand the last bit.  However, it is only now with my failure
to remove them that we found something possiblby fishy?  IWBN if we knew
that the hashes are reproducible before we remove them.  Hmm, that might
be a good argument to have two packages, a merely static/content
stripped version and a hashes-stripped version.

> I'd like to build the new bootstrap binaries, but I'm unsure how to
> proceed.  In your new batch of commits, you reference the commit that
> was used to perform the build:

> I guess that I should build from a checkout of commit
> 2e13b6fff94027158b3de5d3a1469dc9f89b0c39.  However, that commit is not
> on Savannah, as demonstrated by the following URL, which reports "Bad
> commit reference: 2e13b6fff94027158b3de5d3a1469dc9f89b0c39".
>
>   https://git.savannah.gnu.org/cgit/guix.git/commit/?id=2e13b6fff94027158b3de5d3a1469dc9f89b0c39

Right, that commit is two commits up or my core-updates branch @ gitlab

    https://gitlab.com/janneke/guix @ core-updates    

it's core-updates plus the two first patches I sent.  I could push a
wip-core-updates branch (but I'll first try the master thing, see
below).

> The other issue is that your proposed new fixes do not seem to apply to
> 'master'.  Did you build the newly fixed bootstrap tarballs from
> something based on 'core-updates'?  If so, that leaves me no way to
> independently verify the new bootstrap without putting my trust in the
> slightly older bootstrap -- the same one that I just failed to
> reproduce.

Ah, hadn't thought about that...

> What I need is a way to build the new bootstrap tarballs without using
> the existing 'core-updates' branch.  I need a way to build them from a
> branch that's based upon the much older bootstrap binaries that we've
> been using for many years.  Preferably, they should be built from
> something close to current 'master'.
>
> Is this feasible?

Hmm, I'm not sure how much work it would be.  If we're lucky then the
recipes from gnu/packages/bootstrap.scm for mescc-tools-static-stripped
and mes-minimal-stripped and their tarballs could be put into and used
on master to build.  I'll have a look into this.

If we could find how you can reproduce the current flawed hash-containing
bootstrap binaries that we have on core-updates, that would be nice...I'm
hoping for Ludo' to step in and say something insightful about the
differences you found :)

janneke

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

bug#36747: Official MesCC bootstrap binaries differ from my locally built ones

[Jan Nieuwenhuizen]

Jan Nieuwenhuizen writes:

> Hmm, I'm not sure how much work it would be.  If we're lucky then the
> recipes from gnu/packages/bootstrap.scm

 *gnu/packages/make-bootstrap.scm

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

bug#36747: Official MesCC bootstrap binaries differ from my locally built ones

[Jan Nieuwenhuizen]

Jan Nieuwenhuizen writes:

>> What I need is a way to build the new bootstrap tarballs without using
>> the existing 'core-updates' branch.  I need a way to build them from a
>> branch that's based upon the much older bootstrap binaries that we've
>> been using for many years.  Preferably, they should be built from
>> something close to current 'master'.
>>
>> Is this feasible?
>
> Hmm, I'm not sure how much work it would be.  If we're lucky then the
> recipes from gnu/packages/bootstrap.scm for mescc-tools-static-stripped
> and mes-minimal-stripped and their tarballs could be put into and used
> on master to build.  I'll have a look into this.

Yes, this probably works.  I have pushed a `wip-binaries' branch,
branched-off of current master and added recipes for mescc-tools and mes
bootstrap tarballs.

I have put the results of

--8<---------------cut here---------------start------------->8---
./pre-inst-env guix build --system=i686-linux mes-minimal-stripped-tarball
./pre-inst-env guix build --system=i686-linux mescc-tools-static-stripped-tarball
--8<---------------cut here---------------end--------------->8---

here: http://lilypond.org/janneke/guix/20190722/

Once the patches are cleaned-up/we decide how we want it, we can build
and inject the resulting binaries into current core-updates.  I don't
really like it a lot to have built them on a totally new branch but it's
the best we can do right now, I think.

Greetings,
janneke

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

bug#36747: Official MesCC bootstrap binaries differ from my locally built ones

[Mark H Weaver]

Hi Janneke,

Jan Nieuwenhuizen <janneke@gnu.org> wrote:
>> What I need is a way to build the new bootstrap tarballs without using
>> the existing 'core-updates' branch.  I need a way to build them from a
>> branch that's based upon the much older bootstrap binaries that we've
>> been using for many years.  Preferably, they should be built from
>> something close to current 'master'.
>>
>> Is this feasible?
>
> Hmm, I'm not sure how much work it would be.

Actually, I have a better idea.  How about starting a new branch at
commit ef809e3ac036eccc5f9c9edd8fb661d14ae15f2f (the commit used to
build the current bootstrap binaries for core-updates) and applying the
fixes there?  Then you can push that new branch to savannah, and we can
build it and see if we get the same thing?  Hopefully, the only
difference will be those store references in MesCC.

What do you think?

      Mark

bug#36747: Official MesCC bootstrap binaries differ from my locally built ones

[Jan Nieuwenhuizen]

Mark H Weaver writes:

Hi Mark,

> Actually, I have a better idea.  How about starting a new branch at
> commit ef809e3ac036eccc5f9c9edd8fb661d14ae15f2f (the commit used to
> build the current bootstrap binaries for core-updates) and applying the
> fixes there?  Then you can push that new branch to savannah, and we can
> build it and see if we get the same thing?  Hopefully, the only
> difference will be those store references in MesCC.
>
> What do you think?

I have added a very similar set of two patches to wip-cu-binaries,
branched @ ef809e3ac036eccc5f9c9edd8fb661d14ae15f2f.

They give the same md5sum for me as the wip-binaries branch that
branched off of master; so mine are at
http://lilypond.org/janneke/guix/20190722/

After this commit should come the update-commit, using them in
bootstrap.scm.

HTH,
janneke

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

bug#36747: Official MesCC bootstrap binaries differ from my locally built ones

[Mark H Weaver]

Hi Janneke,

> I have added a very similar set of two patches to wip-cu-binaries,
> branched @ ef809e3ac036eccc5f9c9edd8fb661d14ae15f2f.
>
> They give the same md5sum for me as the wip-binaries branch that
> branched off of master; so mine are at
> http://lilypond.org/janneke/guix/20190722/

I built these, and here are the results:

--8<---------------cut here---------------start------------->8---
mhw@jojen /gnu/store/hd3lk0f08a0sq40qqa6yv1q9gbk7gxww-bootstrap-tarballs-0$ sha256sum *
b5915c71ff5ea722864e1097ce1e7ed50fd68ad7544521f2dd6969173c260276  guile-static-stripped-2.2.4-i686-linux.tar.xz
1acd8f83e27d2fac311a5ca78e9bf11a9a1638b82469870d5c854c4e7afaa26a  linux-libre-headers-stripped-4.14.67-i686-linux.tar.xz
021543d9bb6af55f39e68d69692e3cb74646ced2cad0bb9ac0047ef81e9d7330  mescc-tools-static-stripped-0.5.2-0.bb062b0-i686-linux.tar.xz
fb32090071b39fc804fb9a7fba96f0bc5eb844a0efd268fb24c42e6bfa959de0  mes-minimal-stripped-0.19-i686-linux.tar.xz
9ee954dc19db5c8d4113c73a702fd8f79f26c51024220f2617d0572c0a85e69c  static-binaries-0-i686-linux.tar.xz
--8<---------------cut here---------------end--------------->8---

Do these match what you built?

For the sake of completeness, I built these by running

  ./pre-inst-env guix build bootstrap-tarballs --system=i686-linux

from a git checkout at commit 5a6465e41a84b4320940d33709b80d78c1aff9d0.

> After this commit should come the update-commit, using them in
> bootstrap.scm.

Right, except those commits should be applied to the tip of
'core-updates', and not until we're sure that these new bootstrap
binaries are good.

Ludovic, what do you think?

     Thanks,
       Mark

bug#36747: Official MesCC bootstrap binaries differ from my locally built ones

[Jan Nieuwenhuizen]

Mark H Weaver writes:

Hi Mark,

>> I have added a very similar set of two patches to wip-cu-binaries,
>> branched @ ef809e3ac036eccc5f9c9edd8fb661d14ae15f2f.
>>
>> They give the same md5sum for me as the wip-binaries branch that
>> branched off of master; so mine are at
>> http://lilypond.org/janneke/guix/20190722/
>
> I built these, and here are the results:
>
> mhw@jojen /gnu/store/hd3lk0f08a0sq40qqa6yv1q9gbk7gxww-bootstrap-tarballs-0$ sha256sum *
> b5915c71ff5ea722864e1097ce1e7ed50fd68ad7544521f2dd6969173c260276  guile-static-stripped-2.2.4-i686-linux.tar.xz
> 1acd8f83e27d2fac311a5ca78e9bf11a9a1638b82469870d5c854c4e7afaa26a  linux-libre-headers-stripped-4.14.67-i686-linux.tar.xz
> 021543d9bb6af55f39e68d69692e3cb74646ced2cad0bb9ac0047ef81e9d7330  mescc-tools-static-stripped-0.5.2-0.bb062b0-i686-linux.tar.xz
> fb32090071b39fc804fb9a7fba96f0bc5eb844a0efd268fb24c42e6bfa959de0  mes-minimal-stripped-0.19-i686-linux.tar.xz
> 9ee954dc19db5c8d4113c73a702fd8f79f26c51024220f2617d0572c0a85e69c  static-binaries-0-i686-linux.tar.xz
>
> Do these match what you built?

Well...

08:16:12 janneke@dundal:~/src/guix/wip-cu-binaries [env]
$ sha256sum /gnu/store/hd3lk0f08a0sq40qqa6yv1q9gbk7gxww-bootstrap-tarballs-0/*
adce360f68ed0083c7356c267c24271fa4907f8082c9d47db28b603f9da5e763  /gnu/store/hd3lk0f08a0sq40qqa6yv1q9gbk7gxww-bootstrap-tarballs-0/guile-static-stripped-2.2.4-i686-linux.tar.xz
1acd8f83e27d2fac311a5ca78e9bf11a9a1638b82469870d5c854c4e7afaa26a  /gnu/store/hd3lk0f08a0sq40qqa6yv1q9gbk7gxww-bootstrap-tarballs-0/linux-libre-headers-stripped-4.14.67-i686-linux.tar.xz
021543d9bb6af55f39e68d69692e3cb74646ced2cad0bb9ac0047ef81e9d7330  /gnu/store/hd3lk0f08a0sq40qqa6yv1q9gbk7gxww-bootstrap-tarballs-0/mescc-tools-static-stripped-0.5.2-0.bb062b0-i686-linux.tar.xz
fb32090071b39fc804fb9a7fba96f0bc5eb844a0efd268fb24c42e6bfa959de0  /gnu/store/hd3lk0f08a0sq40qqa6yv1q9gbk7gxww-bootstrap-tarballs-0/mes-minimal-stripped-0.19-i686-linux.tar.xz
c80cdd17b0a24eebdd75570ff72c4ec06e129bd702ac008186b57f6301c448e7  /gnu/store/hd3lk0f08a0sq40qqa6yv1q9gbk7gxww-bootstrap-tarballs-0/static-binaries-0-i686-linux.tar.xz

...for mescc-tools and mes: yes.  I have put them all up here: http://lilypond.org/janneke/guix/20190722

> For the sake of completeness, I built these by running
>
>   ./pre-inst-env guix build bootstrap-tarballs --system=i686-linux
>
> from a git checkout at commit 5a6465e41a84b4320940d33709b80d78c1aff9d0.

/me too

>> After this commit should come the update-commit, using them in
>> bootstrap.scm.
>
> Right, except those commits should be applied to the tip of
> 'core-updates', and not until we're sure that these new bootstrap
> binaries are good.

Yes.

> Ludovic, what do you think?

FWIW, I'm working on a mes-0.20 release that supports Nyacc-0.99.0 (and
hopefully 1.0.0) and mescc-tools-0.6 and building on Debian ootb.

There's no real reason to update bootstrap tarballs for those versions
and I cannot promise a release date yet.

Further work on mes-0.21 should bring the Reduced Binary Seed bootstrap
to ARM (lots of work still) and replace the `static-binaries' with Gash,
reducing the size of our bootstrap binaries once again by ~50%.

janneke

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

bug#36747: Official MesCC bootstrap binaries differ from my locally built ones

[Ludovic Courtès]

Hi Mark,

Mark H Weaver <mhw@netris.org> skribis:

> Hi Janneke,
>
>> I have added a very similar set of two patches to wip-cu-binaries,
>> branched @ ef809e3ac036eccc5f9c9edd8fb661d14ae15f2f.
>>
>> They give the same md5sum for me as the wip-binaries branch that
>> branched off of master; so mine are at
>> http://lilypond.org/janneke/guix/20190722/
>
> I built these, and here are the results:
>
> mhw@jojen /gnu/store/hd3lk0f08a0sq40qqa6yv1q9gbk7gxww-bootstrap-tarballs-0$ sha256sum *
> b5915c71ff5ea722864e1097ce1e7ed50fd68ad7544521f2dd6969173c260276  guile-static-stripped-2.2.4-i686-linux.tar.xz
> 1acd8f83e27d2fac311a5ca78e9bf11a9a1638b82469870d5c854c4e7afaa26a  linux-libre-headers-stripped-4.14.67-i686-linux.tar.xz
> 021543d9bb6af55f39e68d69692e3cb74646ced2cad0bb9ac0047ef81e9d7330  mescc-tools-static-stripped-0.5.2-0.bb062b0-i686-linux.tar.xz
> fb32090071b39fc804fb9a7fba96f0bc5eb844a0efd268fb24c42e6bfa959de0  mes-minimal-stripped-0.19-i686-linux.tar.xz
> 9ee954dc19db5c8d4113c73a702fd8f79f26c51024220f2617d0572c0a85e69c  static-binaries-0-i686-linux.tar.xz
>
> Do these match what you built?

We verified things back then:

  https://lists.gnu.org/archive/html/guix-devel/2018-12/msg00046.html

This was on commit 4ae7dc7b9af64794081b1913740b97acd89c91bc, which is
earlier than the one you’re looking at (commit
ef809e3ac036eccc5f9c9edd8fb661d14ae15f2f, right?)

> For the sake of completeness, I built these by running
>
>   ./pre-inst-env guix build bootstrap-tarballs --system=i686-linux
>
> from a git checkout at commit 5a6465e41a84b4320940d33709b80d78c1aff9d0.

Hmm I don’t have this commit here.

I think we should first make sure we’re starting from the right
commits.  Then, if there are still differences, I suggest a cursory look
at the output of ‘diffoscope’ to see if there’s anything obvious
(non-determinism in .go files is apparently still a problem, for
example.)

Thanks for checking!

Ludo’.

bug#36747: Official MesCC bootstrap binaries differ from my locally built ones

[Mark H Weaver]

Jan Nieuwenhuizen <janneke@gnu.org> writes:

> Mark H Weaver writes:
>
> Hi Mark,
>
>>> I have added a very similar set of two patches to wip-cu-binaries,
>>> branched @ ef809e3ac036eccc5f9c9edd8fb661d14ae15f2f.
>>>
>>> They give the same md5sum for me as the wip-binaries branch that
>>> branched off of master; so mine are at
>>> http://lilypond.org/janneke/guix/20190722/
>>
>> I built these, and here are the results:
>>
>> mhw@jojen /gnu/store/hd3lk0f08a0sq40qqa6yv1q9gbk7gxww-bootstrap-tarballs-0$ sha256sum *
>> b5915c71ff5ea722864e1097ce1e7ed50fd68ad7544521f2dd6969173c260276  guile-static-stripped-2.2.4-i686-linux.tar.xz
>> 1acd8f83e27d2fac311a5ca78e9bf11a9a1638b82469870d5c854c4e7afaa26a  linux-libre-headers-stripped-4.14.67-i686-linux.tar.xz
>> 021543d9bb6af55f39e68d69692e3cb74646ced2cad0bb9ac0047ef81e9d7330  mescc-tools-static-stripped-0.5.2-0.bb062b0-i686-linux.tar.xz
>> fb32090071b39fc804fb9a7fba96f0bc5eb844a0efd268fb24c42e6bfa959de0  mes-minimal-stripped-0.19-i686-linux.tar.xz
>> 9ee954dc19db5c8d4113c73a702fd8f79f26c51024220f2617d0572c0a85e69c  static-binaries-0-i686-linux.tar.xz
>>
>> Do these match what you built?
>
> Well...
>
> 08:16:12 janneke@dundal:~/src/guix/wip-cu-binaries [env]
> $ sha256sum /gnu/store/hd3lk0f08a0sq40qqa6yv1q9gbk7gxww-bootstrap-tarballs-0/*
> adce360f68ed0083c7356c267c24271fa4907f8082c9d47db28b603f9da5e763
> /gnu/store/hd3lk0f08a0sq40qqa6yv1q9gbk7gxww-bootstrap-tarballs-0/guile-static-stripped-2.2.4-i686-linux.tar.xz
> 1acd8f83e27d2fac311a5ca78e9bf11a9a1638b82469870d5c854c4e7afaa26a
> /gnu/store/hd3lk0f08a0sq40qqa6yv1q9gbk7gxww-bootstrap-tarballs-0/linux-libre-headers-stripped-4.14.67-i686-linux.tar.xz
> 021543d9bb6af55f39e68d69692e3cb74646ced2cad0bb9ac0047ef81e9d7330
> /gnu/store/hd3lk0f08a0sq40qqa6yv1q9gbk7gxww-bootstrap-tarballs-0/mescc-tools-static-stripped-0.5.2-0.bb062b0-i686-linux.tar.xz
> fb32090071b39fc804fb9a7fba96f0bc5eb844a0efd268fb24c42e6bfa959de0
> /gnu/store/hd3lk0f08a0sq40qqa6yv1q9gbk7gxww-bootstrap-tarballs-0/mes-minimal-stripped-0.19-i686-linux.tar.xz
> c80cdd17b0a24eebdd75570ff72c4ec06e129bd702ac008186b57f6301c448e7
> /gnu/store/hd3lk0f08a0sq40qqa6yv1q9gbk7gxww-bootstrap-tarballs-0/static-binaries-0-i686-linux.tar.xz

There are two bootstrap tarballs that differ:

(1) static-binaries
(2) guile-static-stripped

In this message, I'll address only the 'static-binaries'.

The only difference in the static-binaries is bash.  It turns out that
the bash-4.4 configure script produces an incorrect compile-time
configuration when built on Linux 5.x or later.  It boils down to this
code in Bash's configure.ac:

--8<---------------cut here---------------start------------->8---
linux*)         LOCAL_LDFLAGS=-rdynamic          # allow dynamic loading
                case "`uname -r`" in
                2.[[456789]]*|[[34]]*)  AC_DEFINE(PGRP_PIPE) ;;
                esac ;;
--8<---------------cut here---------------end--------------->8---

In bash-5.0, this code has been changed to:

--8<---------------cut here---------------start------------->8---
linux*)         LOCAL_LDFLAGS=-rdynamic          # allow dynamic loading
                case "`uname -r`" in
                1.*|2.[[0123]]*)        : ;;
                *)      AC_DEFINE(PGRP_PIPE) ;;
                esac ;;
--8<---------------cut here---------------end--------------->8---

which is certainly an improvement, but still nondeterministic.  We
should probably fix that.

Anyway, it appears that our static-binaries-0-i686-linux.tar.xz tarball
can only be built correctly on a machine running Linux 4.x or earlier.

       Mark

bug#36747: Official MesCC bootstrap binaries differ from my locally built ones

[Mark H Weaver]

I wrote earlier:

> There are two bootstrap tarballs that differ:
>
> (1) static-binaries
> (2) guile-static-stripped
>
> In this message, I'll address only the 'static-binaries'.
>
> The only difference in the static-binaries is bash.  It turns out that
> the bash-4.4 configure script produces an incorrect compile-time
> configuration when built on Linux 5.x or later.  It boils down to this
> code in Bash's configure.ac:
>
> linux*)         LOCAL_LDFLAGS=-rdynamic          # allow dynamic loading
>                 case "`uname -r`" in
>                 2.[[456789]]*|[[34]]*)  AC_DEFINE(PGRP_PIPE) ;;
>                 esac ;;

I pushed a fix for this issue to the 'wip-cu-binaries' branch, commit
eefabc1db04c91d6954306e319820cd95190c25d.  With this fix, my
'static-binaries' tarball now matches yours.

What remains is to make 'guile-static-stripped' deterministic.  For now,
I suspect it might be sufficient to build it with #:parallel-build #f,
although of course it would be good to eventually fix the parallel build
to be deterministic.

It would also be good to enable building the bootstrap binaries from a
commit that's somewhere along the linear history of the 'master' branch.

To be continued...

     Mark

bug#36747: Official MesCC bootstrap binaries differ from my locally built ones

[Mark H Weaver]

Hi Ludovic,

Ludovic Courtès <ludo@gnu.org> writes:

> Mark H Weaver <mhw@netris.org> skribis:
>
>>> I have added a very similar set of two patches to wip-cu-binaries,
>>> branched @ ef809e3ac036eccc5f9c9edd8fb661d14ae15f2f.
>>>
>>> They give the same md5sum for me as the wip-binaries branch that
>>> branched off of master; so mine are at
>>> http://lilypond.org/janneke/guix/20190722/
>>
>> I built these, and here are the results:
>>
>> mhw@jojen /gnu/store/hd3lk0f08a0sq40qqa6yv1q9gbk7gxww-bootstrap-tarballs-0$ sha256sum *
>> b5915c71ff5ea722864e1097ce1e7ed50fd68ad7544521f2dd6969173c260276  guile-static-stripped-2.2.4-i686-linux.tar.xz
>> 1acd8f83e27d2fac311a5ca78e9bf11a9a1638b82469870d5c854c4e7afaa26a  linux-libre-headers-stripped-4.14.67-i686-linux.tar.xz
>> 021543d9bb6af55f39e68d69692e3cb74646ced2cad0bb9ac0047ef81e9d7330  mescc-tools-static-stripped-0.5.2-0.bb062b0-i686-linux.tar.xz
>> fb32090071b39fc804fb9a7fba96f0bc5eb844a0efd268fb24c42e6bfa959de0  mes-minimal-stripped-0.19-i686-linux.tar.xz
>> 9ee954dc19db5c8d4113c73a702fd8f79f26c51024220f2617d0572c0a85e69c  static-binaries-0-i686-linux.tar.xz
>>
>> Do these match what you built?
>
> We verified things back then:
>
>   https://lists.gnu.org/archive/html/guix-devel/2018-12/msg00046.html
>
> This was on commit 4ae7dc7b9af64794081b1913740b97acd89c91bc, which is
> earlier than the one you’re looking at (commit
> ef809e3ac036eccc5f9c9edd8fb661d14ae15f2f, right?)

Yes.  However, I just noticed a more serious problem.

The "independent verification" that you and I performed at commit
4ae7dc7b9af64794081b1913740b97acd89c91bc was bogus, because at that
commit, %bootstrap-inputs had already been changed to use an earlier
draft of the reduced binary seed, based on unverified bootstrap tarballs
downloaded from lilypond.org.

In order to perform a truly independent verification, we need to build
the new bootstrap binaries without using the new bootstrap binaries.
Otherwise our verification is circular.

It seems to me that the best way to accomplish this is to backport the
new '%bootstrap-tarballs' from 'wip-cu-binaries' to the 'master' branch.

What do you think?

      Thanks,
        Mark

bug#36747: Official MesCC bootstrap binaries differ from my locally built ones

[Jan Nieuwenhuizen]

Mark H Weaver writes:

> It seems to me that the best way to accomplish this is to backport the
> new '%bootstrap-tarballs' from 'wip-cu-binaries' to the 'master' branch.

I called that `wip-binaries', @master from three weeks ago.

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

bug#36747: Official MesCC bootstrap binaries differ from my locally built ones

[Mark H Weaver]

Hi Janneke,

Jan Nieuwenhuizen <janneke@gnu.org> writes:

> Mark H Weaver writes:
>
>> It seems to me that the best way to accomplish this is to backport the
>> new '%bootstrap-tarballs' from 'wip-cu-binaries' to the 'master' branch.
>
> I called that `wip-binaries', @master from three weeks ago.

Thank you, that was a good start.  I found that some additional patches
were needed to match the bootstrap binaries that 'core-updates' is
currently based on.

I ended up deleting and repushing a revised 'wip-binaries' to Savannah.
It includes slightly modified versions of the two commits you had
included, as well as some additional cherry-picked commits of yours to
update mescc-tools and add linux-libre-headers-bootstrap-tarball, and a
few of my own.

I built the new bootstrap tarballs at the new 'wip-binaries', commit
c67becb31c30a5cd7685f166970ac4793e3a34a9, and here's what I got:

--8<---------------cut here---------------start------------->8---
mhw@jojen ~/guix-wip-binaries$ git describe
v1.0.1-2404-gc67becb31c
mhw@jojen ~/guix-wip-binaries$ ./pre-inst-env guix build --system=i686-linux bootstrap-tarballs
/gnu/store/bg086i2qw1fn2jgbd15d9v91hyjrjsb2-bootstrap-tarballs-0
mhw@jojen ~/guix-wip-binaries$ cd /gnu/store/bg086i2qw1fn2jgbd15d9v91hyjrjsb2-bootstrap-tarballs-0
mhw@jojen /gnu/store/bg086i2qw1fn2jgbd15d9v91hyjrjsb2-bootstrap-tarballs-0$ sha256sum *
3e50c070a100b6bcf84c4bf5c868f9cd0a9fd1570f5d82fbfb78f8411959091b  guile-static-stripped-2.2.4-i686-linux.tar.xz
1acd8f83e27d2fac311a5ca78e9bf11a9a1638b82469870d5c854c4e7afaa26a  linux-libre-headers-stripped-4.14.67-i686-linux.tar.xz
021543d9bb6af55f39e68d69692e3cb74646ced2cad0bb9ac0047ef81e9d7330  mescc-tools-static-stripped-0.5.2-0.bb062b0-i686-linux.tar.xz
fb32090071b39fc804fb9a7fba96f0bc5eb844a0efd268fb24c42e6bfa959de0  mes-minimal-stripped-0.19-i686-linux.tar.xz
c80cdd17b0a24eebdd75570ff72c4ec06e129bd702ac008186b57f6301c448e7  static-binaries-0-i686-linux.tar.xz
--8<---------------cut here---------------end--------------->8---

All of these match what you posted here earlier except for
guile-static-stripped-2.2.4.  In my final commit to 'wip-binaries'
I disabled the parallel build in guile-static, which I hope might
make that build deterministic.

Can you try "guix build --system=i686-linux bootstrap-tarballs" at the
new 'wip-binaries' branch and see if you get the same results?

Also, I have a question: One of the changes I made to 'wip-binaries' was
to update mescc-tools to 0.5.2-0.bb062b0, to match the
%bootstrap-mescc-tools that's currently being used in 'core-updates'.

However, I noticed that you have also apparently built the official
release of mescc-tools-0.5.2, which is on your site:

  http://lilypond.org/janneke/guix/20190722/mescc-tools-static-stripped-0.5.2-i686-linux.tar.xz

and that this tarball is identical to the build output of the later git
commit: mescc-tools-static-stripped-0.5.2-0.bb062b0-i686-linux.tar.xz.

With this in mind, could we just use 0.5.2?  What changed between 0.5.2
and 0.5.2-0.bb062b0, and what was the rationale for updating to bb062b0?
Here's the relevant commit:

  commit 7cbf6f1ca268a7a179d715aaba2a451a8886ab44
  Author: Jan Nieuwenhuizen <janneke@gnu.org>
  Date:   Fri Oct 12 08:19:53 2018 +0200
  
      gnu: mescc-tools: Update to 0.5.2-0.bb062b0d.
      
      * gnu/packages/mes.scm (mescc-tools): Update to 0.5.2-0.bb062b0d.
      mescc
      * gnu/packages/commencement.scm (mescc-tools-boot): Stay at 0.5.2

Anyway, thanks for all of your work on this.

     Best,
      Mark

bug#36747: Official MesCC bootstrap binaries differ from my locally built ones

[Jan Nieuwenhuizen]

Mark H Weaver writes:

Hi Mark,

>> I called that `wip-binaries', @master from three weeks ago.
>
> Thank you, that was a good start.  I found that some additional patches
> were needed to match the bootstrap binaries that 'core-updates' is
> currently based on.
>
> I ended up deleting and repushing a revised 'wip-binaries' to Savannah.
> It includes slightly modified versions of the two commits you had
> included, as well as some additional cherry-picked commits of yours to
> update mescc-tools and add linux-libre-headers-bootstrap-tarball, and a
> few of my own.

Very nice.

> I built the new bootstrap tarballs at the new 'wip-binaries', commit
> c67becb31c30a5cd7685f166970ac4793e3a34a9, and here's what I got:
>
> mhw@jojen ~/guix-wip-binaries$ git describe
> v1.0.1-2404-gc67becb31c
> mhw@jojen ~/guix-wip-binaries$ ./pre-inst-env guix build --system=i686-linux bootstrap-tarballs
> /gnu/store/bg086i2qw1fn2jgbd15d9v91hyjrjsb2-bootstrap-tarballs-0
> mhw@jojen ~/guix-wip-binaries$ cd /gnu/store/bg086i2qw1fn2jgbd15d9v91hyjrjsb2-bootstrap-tarballs-0
> mhw@jojen /gnu/store/bg086i2qw1fn2jgbd15d9v91hyjrjsb2-bootstrap-tarballs-0$ sha256sum *
> 3e50c070a100b6bcf84c4bf5c868f9cd0a9fd1570f5d82fbfb78f8411959091b  guile-static-stripped-2.2.4-i686-linux.tar.xz
> 1acd8f83e27d2fac311a5ca78e9bf11a9a1638b82469870d5c854c4e7afaa26a  linux-libre-headers-stripped-4.14.67-i686-linux.tar.xz
> 021543d9bb6af55f39e68d69692e3cb74646ced2cad0bb9ac0047ef81e9d7330  mescc-tools-static-stripped-0.5.2-0.bb062b0-i686-linux.tar.xz
> fb32090071b39fc804fb9a7fba96f0bc5eb844a0efd268fb24c42e6bfa959de0  mes-minimal-stripped-0.19-i686-linux.tar.xz
> c80cdd17b0a24eebdd75570ff72c4ec06e129bd702ac008186b57f6301c448e7  static-binaries-0-i686-linux.tar.xz

> Can you try "guix build --system=i686-linux bootstrap-tarballs" at the
> new 'wip-binaries' branch and see if you get the same results?

Yes, on c67becb31c30a5cd7685f166970ac4793e3a34a9 running
"./pre-inst-env guix build --system=i686-linux bootstrap-tarballs" gives me exactly this,
also for guile-static-stripped! \o/

> Also, I have a question: One of the changes I made to 'wip-binaries' was
> to update mescc-tools to 0.5.2-0.bb062b0, to match the
> %bootstrap-mescc-tools that's currently being used in 'core-updates'.
>
> However, I noticed that you have also apparently built the official
> release of mescc-tools-0.5.2, which is on your site:
>
>   http://lilypond.org/janneke/guix/20190722/mescc-tools-static-stripped-0.5.2-i686-linux.tar.xz
>
> and that this tarball is identical to the build output of the later git
> commit: mescc-tools-static-stripped-0.5.2-0.bb062b0-i686-linux.tar.xz.
>
> With this in mind, could we just use 0.5.2?  What changed between 0.5.2
> and 0.5.2-0.bb062b0, and what was the rationale for updating to bb062b0?

Good catch.  We probably can, we might try that.

I think the need for updating to bb062b0 has been removed during the
review of the integration of the reduced binary seed bootstrap into
core-updates by Ludovic.

For historical reasons, I think this mescc-tools commit

--8<---------------cut here---------------start------------->8---
commit c184e95096881a13f29ebd7fc507fe305d3d8de5 (gitlab/janneke, janneke)
Author: Jan Nieuwenhuizen <janneke@gnu.org>
Date:   Thu Oct 4 22:03:31 2018 +0200

    build.sh: Update for mes 0.18.
--8<---------------cut here---------------end--------------->8---

was needed at a time that we did not have mescc-tools or mes in
bootstrap tarballs.  We built bootstrap variants of mescc-tools and mes
using a externally (outside fo Guix) built mescc-tools-seed and
(an almost pure ASCII) mes-seed.

Greetings,
janneke

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

bug#36747: Official MesCC bootstrap binaries differ from my locally built ones

[Marius Bakke]

[-- Attachment #1.1: Type: text/plain, Size: 3853 bytes --]

Jan Nieuwenhuizen <janneke@gnu.org> writes:

> Mark H Weaver writes:
>
> Hi Mark,
>
>>> I called that `wip-binaries', @master from three weeks ago.
>>
>> Thank you, that was a good start.  I found that some additional patches
>> were needed to match the bootstrap binaries that 'core-updates' is
>> currently based on.
>>
>> I ended up deleting and repushing a revised 'wip-binaries' to Savannah.
>> It includes slightly modified versions of the two commits you had
>> included, as well as some additional cherry-picked commits of yours to
>> update mescc-tools and add linux-libre-headers-bootstrap-tarball, and a
>> few of my own.
>
> Very nice.
>
>> I built the new bootstrap tarballs at the new 'wip-binaries', commit
>> c67becb31c30a5cd7685f166970ac4793e3a34a9, and here's what I got:
>>
>> mhw@jojen ~/guix-wip-binaries$ git describe
>> v1.0.1-2404-gc67becb31c
>> mhw@jojen ~/guix-wip-binaries$ ./pre-inst-env guix build --system=i686-linux bootstrap-tarballs
>> /gnu/store/bg086i2qw1fn2jgbd15d9v91hyjrjsb2-bootstrap-tarballs-0
>> mhw@jojen ~/guix-wip-binaries$ cd /gnu/store/bg086i2qw1fn2jgbd15d9v91hyjrjsb2-bootstrap-tarballs-0
>> mhw@jojen /gnu/store/bg086i2qw1fn2jgbd15d9v91hyjrjsb2-bootstrap-tarballs-0$ sha256sum *
>> 3e50c070a100b6bcf84c4bf5c868f9cd0a9fd1570f5d82fbfb78f8411959091b  guile-static-stripped-2.2.4-i686-linux.tar.xz
>> 1acd8f83e27d2fac311a5ca78e9bf11a9a1638b82469870d5c854c4e7afaa26a  linux-libre-headers-stripped-4.14.67-i686-linux.tar.xz
>> 021543d9bb6af55f39e68d69692e3cb74646ced2cad0bb9ac0047ef81e9d7330  mescc-tools-static-stripped-0.5.2-0.bb062b0-i686-linux.tar.xz
>> fb32090071b39fc804fb9a7fba96f0bc5eb844a0efd268fb24c42e6bfa959de0  mes-minimal-stripped-0.19-i686-linux.tar.xz
>> c80cdd17b0a24eebdd75570ff72c4ec06e129bd702ac008186b57f6301c448e7  static-binaries-0-i686-linux.tar.xz
>
>> Can you try "guix build --system=i686-linux bootstrap-tarballs" at the
>> new 'wip-binaries' branch and see if you get the same results?
>
> Yes, on c67becb31c30a5cd7685f166970ac4793e3a34a9 running
> "./pre-inst-env guix build --system=i686-linux bootstrap-tarballs" gives me exactly this,
> also for guile-static-stripped! \o/
>
>> Also, I have a question: One of the changes I made to 'wip-binaries' was
>> to update mescc-tools to 0.5.2-0.bb062b0, to match the
>> %bootstrap-mescc-tools that's currently being used in 'core-updates'.
>>
>> However, I noticed that you have also apparently built the official
>> release of mescc-tools-0.5.2, which is on your site:
>>
>>   http://lilypond.org/janneke/guix/20190722/mescc-tools-static-stripped-0.5.2-i686-linux.tar.xz
>>
>> and that this tarball is identical to the build output of the later git
>> commit: mescc-tools-static-stripped-0.5.2-0.bb062b0-i686-linux.tar.xz.
>>
>> With this in mind, could we just use 0.5.2?  What changed between 0.5.2
>> and 0.5.2-0.bb062b0, and what was the rationale for updating to bb062b0?
>
> Good catch.  We probably can, we might try that.
>
> I think the need for updating to bb062b0 has been removed during the
> review of the integration of the reduced binary seed bootstrap into
> core-updates by Ludovic.
>
> For historical reasons, I think this mescc-tools commit
>
> --8<---------------cut here---------------start------------->8---
> commit c184e95096881a13f29ebd7fc507fe305d3d8de5 (gitlab/janneke, janneke)
> Author: Jan Nieuwenhuizen <janneke@gnu.org>
> Date:   Thu Oct 4 22:03:31 2018 +0200
>
>     build.sh: Update for mes 0.18.
> --8<---------------cut here---------------end--------------->8---
>
> was needed at a time that we did not have mescc-tools or mes in
> bootstrap tarballs.  We built bootstrap variants of mescc-tools and mes
> using a externally (outside fo Guix) built mescc-tools-seed and
> (an almost pure ASCII) mes-seed.

I tried building the i686 bootstrap tarballs from wip-binaries with this
additional patch:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: mes.diff --]
[-- Type: text/x-patch, Size: 2654 bytes --]

diff --git a/gnu/packages/mes.scm b/gnu/packages/mes.scm
index e298cb05c1..380cac6c88 100644
--- a/gnu/packages/mes.scm
+++ b/gnu/packages/mes.scm
@@ -139,33 +139,31 @@ Guile.")
     (license gpl3+)))
 
 (define-public mescc-tools
-  (let ((commit "bb062b0da7bf2724ca40f9002b121579898d4ef7")
-        (revision "0")
-        (version "0.5.2"))
-    (package
-      (name "mescc-tools")
-      (version (string-append version "-" revision "." (string-take commit 7)))
-      (source (origin
-                (method url-fetch)
-                (uri (string-append
-                      "https://git.savannah.nongnu.org/cgit/mescc-tools.git/snapshot/"
-                      name "-" commit
-                      ".tar.gz"))
-                (sha256
-                 (base32
-                  "1h6j57wyf91i42b26f8msbv6451cw3nm4nmpl1fckp9c7vi8mwkh"))))
-      (build-system gnu-build-system)
-      (supported-systems '("i686-linux" "x86_64-linux"))
-      (arguments
-       `(#:make-flags (list (string-append "PREFIX=" (assoc-ref %outputs "out")))
-         #:test-target "test"
-         #:phases (modify-phases %standard-phases
-                    (delete 'configure))))
-      (synopsis "Tools for the full source bootstrapping process")
-      (description
-       "Mescc-tools is a collection of tools for use in a full source
+  (package
+    (name "mescc-tools")
+    (version "0.5.2")
+    (source (origin
+              (method url-fetch)
+              (uri (string-append
+                    "https://git.savannah.nongnu.org/cgit/mescc-tools.git/snapshot/"
+                    name "-Release_" version
+                    ".tar.gz"))
+              (file-name (string-append name "-" version ".tar.gz"))
+              (sha256
+               (base32
+                "01x7bhmgwyf6mc2g1hcvibhps98nllacqm4f0j5l51b1mbi18pc2"))))
+    (build-system gnu-build-system)
+    (supported-systems '("i686-linux" "x86_64-linux"))
+    (arguments
+     `(#:make-flags (list (string-append "PREFIX=" (assoc-ref %outputs "out")))
+       #:test-target "test"
+       #:phases (modify-phases %standard-phases
+                  (delete 'configure))))
+    (synopsis "Tools for the full source bootstrapping process")
+    (description
+     "Mescc-tools is a collection of tools for use in a full source
 bootstrapping process.  It consists of the M1 macro assembler, the hex2
 linker, the blood-elf symbol table generator, the kaem shell, exec_enable and
 get_machine.")
     (home-page "https://savannah.nongnu.org/projects/mescc-tools")
-    (license gpl3+))))
+    (license gpl3+)))

[-- Attachment #1.3: Type: text/plain, Size: 1062 bytes --]


And got this result:

$ cd /gnu/store/rdwyr8mh7dvhfkb5g4cws6q40hp23rbi-bootstrap-tarballs-0
$ sha256sum *
3e50c070a100b6bcf84c4bf5c868f9cd0a9fd1570f5d82fbfb78f8411959091b  guile-static-stripped-2.2.4-i686-linux.tar.xz
1acd8f83e27d2fac311a5ca78e9bf11a9a1638b82469870d5c854c4e7afaa26a  linux-libre-headers-stripped-4.14.67-i686-linux.tar.xz
021543d9bb6af55f39e68d69692e3cb74646ced2cad0bb9ac0047ef81e9d7330  mescc-tools-static-stripped-0.5.2-i686-linux.tar.xz
fb32090071b39fc804fb9a7fba96f0bc5eb844a0efd268fb24c42e6bfa959de0  mes-minimal-stripped-0.19-i686-linux.tar.xz
c80cdd17b0a24eebdd75570ff72c4ec06e129bd702ac008186b57f6301c448e7  static-binaries-0-i686-linux.tar.xz

I also merged the branch to core-updates and reverted the bash patch,
which produced this derivation for "guix build -d -s i686-linux
bootstrap-tarballs":

/gnu/store/ld82vli1msfrlimjaryznrqcwm0jc5ii-bootstrap-tarballs-0.drv

I will report back with hashes once it finishes building.  It would be
great if someone else could try to resolve the merge and see if they get
the same derivation.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

bug#36747: Official MesCC bootstrap binaries differ from my locally built ones

[Marius Bakke]

[-- Attachment #1: Type: text/plain, Size: 8545 bytes --]

Marius Bakke <mbakke@fastmail.com> writes:

> Jan Nieuwenhuizen <janneke@gnu.org> writes:
>
>> Mark H Weaver writes:
>>
>> Hi Mark,
>>
>>>> I called that `wip-binaries', @master from three weeks ago.
>>>
>>> Thank you, that was a good start.  I found that some additional patches
>>> were needed to match the bootstrap binaries that 'core-updates' is
>>> currently based on.
>>>
>>> I ended up deleting and repushing a revised 'wip-binaries' to Savannah.
>>> It includes slightly modified versions of the two commits you had
>>> included, as well as some additional cherry-picked commits of yours to
>>> update mescc-tools and add linux-libre-headers-bootstrap-tarball, and a
>>> few of my own.
>>
>> Very nice.
>>
>>> I built the new bootstrap tarballs at the new 'wip-binaries', commit
>>> c67becb31c30a5cd7685f166970ac4793e3a34a9, and here's what I got:
>>>
>>> mhw@jojen ~/guix-wip-binaries$ git describe
>>> v1.0.1-2404-gc67becb31c
>>> mhw@jojen ~/guix-wip-binaries$ ./pre-inst-env guix build --system=i686-linux bootstrap-tarballs
>>> /gnu/store/bg086i2qw1fn2jgbd15d9v91hyjrjsb2-bootstrap-tarballs-0
>>> mhw@jojen ~/guix-wip-binaries$ cd /gnu/store/bg086i2qw1fn2jgbd15d9v91hyjrjsb2-bootstrap-tarballs-0
>>> mhw@jojen /gnu/store/bg086i2qw1fn2jgbd15d9v91hyjrjsb2-bootstrap-tarballs-0$ sha256sum *
>>> 3e50c070a100b6bcf84c4bf5c868f9cd0a9fd1570f5d82fbfb78f8411959091b  guile-static-stripped-2.2.4-i686-linux.tar.xz
>>> 1acd8f83e27d2fac311a5ca78e9bf11a9a1638b82469870d5c854c4e7afaa26a  linux-libre-headers-stripped-4.14.67-i686-linux.tar.xz
>>> 021543d9bb6af55f39e68d69692e3cb74646ced2cad0bb9ac0047ef81e9d7330  mescc-tools-static-stripped-0.5.2-0.bb062b0-i686-linux.tar.xz
>>> fb32090071b39fc804fb9a7fba96f0bc5eb844a0efd268fb24c42e6bfa959de0  mes-minimal-stripped-0.19-i686-linux.tar.xz
>>> c80cdd17b0a24eebdd75570ff72c4ec06e129bd702ac008186b57f6301c448e7  static-binaries-0-i686-linux.tar.xz
>>
>>> Can you try "guix build --system=i686-linux bootstrap-tarballs" at the
>>> new 'wip-binaries' branch and see if you get the same results?
>>
>> Yes, on c67becb31c30a5cd7685f166970ac4793e3a34a9 running
>> "./pre-inst-env guix build --system=i686-linux bootstrap-tarballs" gives me exactly this,
>> also for guile-static-stripped! \o/
>>
>>> Also, I have a question: One of the changes I made to 'wip-binaries' was
>>> to update mescc-tools to 0.5.2-0.bb062b0, to match the
>>> %bootstrap-mescc-tools that's currently being used in 'core-updates'.
>>>
>>> However, I noticed that you have also apparently built the official
>>> release of mescc-tools-0.5.2, which is on your site:
>>>
>>>   http://lilypond.org/janneke/guix/20190722/mescc-tools-static-stripped-0.5.2-i686-linux.tar.xz
>>>
>>> and that this tarball is identical to the build output of the later git
>>> commit: mescc-tools-static-stripped-0.5.2-0.bb062b0-i686-linux.tar.xz.
>>>
>>> With this in mind, could we just use 0.5.2?  What changed between 0.5.2
>>> and 0.5.2-0.bb062b0, and what was the rationale for updating to bb062b0?
>>
>> Good catch.  We probably can, we might try that.
>>
>> I think the need for updating to bb062b0 has been removed during the
>> review of the integration of the reduced binary seed bootstrap into
>> core-updates by Ludovic.
>>
>> For historical reasons, I think this mescc-tools commit
>>
>> --8<---------------cut here---------------start------------->8---
>> commit c184e95096881a13f29ebd7fc507fe305d3d8de5 (gitlab/janneke, janneke)
>> Author: Jan Nieuwenhuizen <janneke@gnu.org>
>> Date:   Thu Oct 4 22:03:31 2018 +0200
>>
>>     build.sh: Update for mes 0.18.
>> --8<---------------cut here---------------end--------------->8---
>>
>> was needed at a time that we did not have mescc-tools or mes in
>> bootstrap tarballs.  We built bootstrap variants of mescc-tools and mes
>> using a externally (outside fo Guix) built mescc-tools-seed and
>> (an almost pure ASCII) mes-seed.
>
> I tried building the i686 bootstrap tarballs from wip-binaries with this
> additional patch:
>
> diff --git a/gnu/packages/mes.scm b/gnu/packages/mes.scm
> index e298cb05c1..380cac6c88 100644
> --- a/gnu/packages/mes.scm
> +++ b/gnu/packages/mes.scm
> @@ -139,33 +139,31 @@ Guile.")
>      (license gpl3+)))
>  
>  (define-public mescc-tools
> -  (let ((commit "bb062b0da7bf2724ca40f9002b121579898d4ef7")
> -        (revision "0")
> -        (version "0.5.2"))
> -    (package
> -      (name "mescc-tools")
> -      (version (string-append version "-" revision "." (string-take commit 7)))
> -      (source (origin
> -                (method url-fetch)
> -                (uri (string-append
> -                      "https://git.savannah.nongnu.org/cgit/mescc-tools.git/snapshot/"
> -                      name "-" commit
> -                      ".tar.gz"))
> -                (sha256
> -                 (base32
> -                  "1h6j57wyf91i42b26f8msbv6451cw3nm4nmpl1fckp9c7vi8mwkh"))))
> -      (build-system gnu-build-system)
> -      (supported-systems '("i686-linux" "x86_64-linux"))
> -      (arguments
> -       `(#:make-flags (list (string-append "PREFIX=" (assoc-ref %outputs "out")))
> -         #:test-target "test"
> -         #:phases (modify-phases %standard-phases
> -                    (delete 'configure))))
> -      (synopsis "Tools for the full source bootstrapping process")
> -      (description
> -       "Mescc-tools is a collection of tools for use in a full source
> +  (package
> +    (name "mescc-tools")
> +    (version "0.5.2")
> +    (source (origin
> +              (method url-fetch)
> +              (uri (string-append
> +                    "https://git.savannah.nongnu.org/cgit/mescc-tools.git/snapshot/"
> +                    name "-Release_" version
> +                    ".tar.gz"))
> +              (file-name (string-append name "-" version ".tar.gz"))
> +              (sha256
> +               (base32
> +                "01x7bhmgwyf6mc2g1hcvibhps98nllacqm4f0j5l51b1mbi18pc2"))))
> +    (build-system gnu-build-system)
> +    (supported-systems '("i686-linux" "x86_64-linux"))
> +    (arguments
> +     `(#:make-flags (list (string-append "PREFIX=" (assoc-ref %outputs "out")))
> +       #:test-target "test"
> +       #:phases (modify-phases %standard-phases
> +                  (delete 'configure))))
> +    (synopsis "Tools for the full source bootstrapping process")
> +    (description
> +     "Mescc-tools is a collection of tools for use in a full source
>  bootstrapping process.  It consists of the M1 macro assembler, the hex2
>  linker, the blood-elf symbol table generator, the kaem shell, exec_enable and
>  get_machine.")
>      (home-page "https://savannah.nongnu.org/projects/mescc-tools")
> -    (license gpl3+))))
> +    (license gpl3+)))
>
> And got this result:
>
> $ cd /gnu/store/rdwyr8mh7dvhfkb5g4cws6q40hp23rbi-bootstrap-tarballs-0
> $ sha256sum *
> 3e50c070a100b6bcf84c4bf5c868f9cd0a9fd1570f5d82fbfb78f8411959091b  guile-static-stripped-2.2.4-i686-linux.tar.xz
> 1acd8f83e27d2fac311a5ca78e9bf11a9a1638b82469870d5c854c4e7afaa26a  linux-libre-headers-stripped-4.14.67-i686-linux.tar.xz
> 021543d9bb6af55f39e68d69692e3cb74646ced2cad0bb9ac0047ef81e9d7330  mescc-tools-static-stripped-0.5.2-i686-linux.tar.xz
> fb32090071b39fc804fb9a7fba96f0bc5eb844a0efd268fb24c42e6bfa959de0  mes-minimal-stripped-0.19-i686-linux.tar.xz
> c80cdd17b0a24eebdd75570ff72c4ec06e129bd702ac008186b57f6301c448e7  static-binaries-0-i686-linux.tar.xz
>
> I also merged the branch to core-updates and reverted the bash patch,
> which produced this derivation for "guix build -d -s i686-linux
> bootstrap-tarballs":
>
> /gnu/store/ld82vli1msfrlimjaryznrqcwm0jc5ii-bootstrap-tarballs-0.drv

Here are the hashes from this derivation:

$ cd /gnu/store/srsqilb3g70r8c7vma0gpam21z1zmg2w-bootstrap-tarballs-0
$ sha256sum *
4e5b219be4d9ad4d125f17b8a8a991e78be3908aadc8d22d1a115e96ec856279  guile-static-stripped-2.2.6-i686-linux.tar.xz
9e34b26526b184912b0d97df96e316151fd97ede24aec2f22dd13ed33438b2e4  linux-libre-headers-stripped-4.19.56-i686-linux.tar.xz
7db07a7097a7920e17f6f1794098b9f29bc3522c36a33cf797123f64581cdc34  mescc-tools-static-0.5.2-i686-linux.tar.xz
3a9b050c1a2b61bb1cbed16ee07aecdc83e9097ce4a914623aa1b9808abe57f4  mes-minimal-stripped-0.19-i686-linux.tar.xz
1ccb4f39656eb977706db7a4aa811461785200b0a11e847035bb89fef91b85ab  static-binaries-0-i686-linux.tar.xz

@Mark: do you think we are ready to merge this now?  Can you do it?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

bug#36747: Official MesCC bootstrap binaries differ from my locally built ones

[Mark H Weaver]

Hi Marius,

Marius Bakke <mbakke@fastmail.com> writes:

> Marius Bakke <mbakke@fastmail.com> writes:
>
>> Jan Nieuwenhuizen <janneke@gnu.org> writes:
>>
>>> Mark H Weaver writes:
>>>
>>> Hi Mark,
>>>
>>>>> I called that `wip-binaries', @master from three weeks ago.
>>>>
>>>> Thank you, that was a good start.  I found that some additional patches
>>>> were needed to match the bootstrap binaries that 'core-updates' is
>>>> currently based on.
>>>>
>>>> I ended up deleting and repushing a revised 'wip-binaries' to Savannah.
>>>> It includes slightly modified versions of the two commits you had
>>>> included, as well as some additional cherry-picked commits of yours to
>>>> update mescc-tools and add linux-libre-headers-bootstrap-tarball, and a
>>>> few of my own.
>>>
>>> Very nice.
>>>
>>>> I built the new bootstrap tarballs at the new 'wip-binaries', commit
>>>> c67becb31c30a5cd7685f166970ac4793e3a34a9, and here's what I got:
>>>>
>>>> mhw@jojen ~/guix-wip-binaries$ git describe
>>>> v1.0.1-2404-gc67becb31c
>>>> mhw@jojen ~/guix-wip-binaries$ ./pre-inst-env guix build --system=i686-linux bootstrap-tarballs
>>>> /gnu/store/bg086i2qw1fn2jgbd15d9v91hyjrjsb2-bootstrap-tarballs-0
>>>> mhw@jojen ~/guix-wip-binaries$ cd /gnu/store/bg086i2qw1fn2jgbd15d9v91hyjrjsb2-bootstrap-tarballs-0
>>>> mhw@jojen /gnu/store/bg086i2qw1fn2jgbd15d9v91hyjrjsb2-bootstrap-tarballs-0$ sha256sum *
>>>> 3e50c070a100b6bcf84c4bf5c868f9cd0a9fd1570f5d82fbfb78f8411959091b  guile-static-stripped-2.2.4-i686-linux.tar.xz
>>>> 1acd8f83e27d2fac311a5ca78e9bf11a9a1638b82469870d5c854c4e7afaa26a  linux-libre-headers-stripped-4.14.67-i686-linux.tar.xz
>>>> 021543d9bb6af55f39e68d69692e3cb74646ced2cad0bb9ac0047ef81e9d7330  mescc-tools-static-stripped-0.5.2-0.bb062b0-i686-linux.tar.xz
>>>> fb32090071b39fc804fb9a7fba96f0bc5eb844a0efd268fb24c42e6bfa959de0  mes-minimal-stripped-0.19-i686-linux.tar.xz
>>>> c80cdd17b0a24eebdd75570ff72c4ec06e129bd702ac008186b57f6301c448e7  static-binaries-0-i686-linux.tar.xz
>>>
>>>> Can you try "guix build --system=i686-linux bootstrap-tarballs" at the
>>>> new 'wip-binaries' branch and see if you get the same results?
>>>
>>> Yes, on c67becb31c30a5cd7685f166970ac4793e3a34a9 running
>>> "./pre-inst-env guix build --system=i686-linux bootstrap-tarballs" gives me exactly this,
>>> also for guile-static-stripped! \o/
>>>
>>>> Also, I have a question: One of the changes I made to 'wip-binaries' was
>>>> to update mescc-tools to 0.5.2-0.bb062b0, to match the
>>>> %bootstrap-mescc-tools that's currently being used in 'core-updates'.
>>>>
>>>> However, I noticed that you have also apparently built the official
>>>> release of mescc-tools-0.5.2, which is on your site:
>>>>
>>>>   http://lilypond.org/janneke/guix/20190722/mescc-tools-static-stripped-0.5.2-i686-linux.tar.xz
>>>>
>>>> and that this tarball is identical to the build output of the later git
>>>> commit: mescc-tools-static-stripped-0.5.2-0.bb062b0-i686-linux.tar.xz.
>>>>
>>>> With this in mind, could we just use 0.5.2?  What changed between 0.5.2
>>>> and 0.5.2-0.bb062b0, and what was the rationale for updating to bb062b0?
>>>
>>> Good catch.  We probably can, we might try that.
>>>
>>> I think the need for updating to bb062b0 has been removed during the
>>> review of the integration of the reduced binary seed bootstrap into
>>> core-updates by Ludovic.
>>>
>>> For historical reasons, I think this mescc-tools commit
>>>
>>> --8<---------------cut here---------------start------------->8---
>>> commit c184e95096881a13f29ebd7fc507fe305d3d8de5 (gitlab/janneke, janneke)
>>> Author: Jan Nieuwenhuizen <janneke@gnu.org>
>>> Date:   Thu Oct 4 22:03:31 2018 +0200
>>>
>>>     build.sh: Update for mes 0.18.
>>> --8<---------------cut here---------------end--------------->8---
>>>
>>> was needed at a time that we did not have mescc-tools or mes in
>>> bootstrap tarballs.  We built bootstrap variants of mescc-tools and mes
>>> using a externally (outside fo Guix) built mescc-tools-seed and
>>> (an almost pure ASCII) mes-seed.
>>
>> I tried building the i686 bootstrap tarballs from wip-binaries with this
>> additional patch:
>>
>> diff --git a/gnu/packages/mes.scm b/gnu/packages/mes.scm
>> index e298cb05c1..380cac6c88 100644
>> --- a/gnu/packages/mes.scm
>> +++ b/gnu/packages/mes.scm
>> @@ -139,33 +139,31 @@ Guile.")
>>      (license gpl3+)))
>>  
>>  (define-public mescc-tools
>> -  (let ((commit "bb062b0da7bf2724ca40f9002b121579898d4ef7")
>> -        (revision "0")
>> -        (version "0.5.2"))
>> -    (package
>> -      (name "mescc-tools")
>> -      (version (string-append version "-" revision "." (string-take commit 7)))
>> -      (source (origin
>> -                (method url-fetch)
>> -                (uri (string-append
>> -                      "https://git.savannah.nongnu.org/cgit/mescc-tools.git/snapshot/"
>> -                      name "-" commit
>> -                      ".tar.gz"))
>> -                (sha256
>> -                 (base32
>> -                  "1h6j57wyf91i42b26f8msbv6451cw3nm4nmpl1fckp9c7vi8mwkh"))))
>> -      (build-system gnu-build-system)
>> -      (supported-systems '("i686-linux" "x86_64-linux"))
>> -      (arguments
>> -       `(#:make-flags (list (string-append "PREFIX=" (assoc-ref %outputs "out")))
>> -         #:test-target "test"
>> -         #:phases (modify-phases %standard-phases
>> -                    (delete 'configure))))
>> -      (synopsis "Tools for the full source bootstrapping process")
>> -      (description
>> -       "Mescc-tools is a collection of tools for use in a full source
>> +  (package
>> +    (name "mescc-tools")
>> +    (version "0.5.2")
>> +    (source (origin
>> +              (method url-fetch)
>> +              (uri (string-append
>> +                    "https://git.savannah.nongnu.org/cgit/mescc-tools.git/snapshot/"
>> +                    name "-Release_" version
>> +                    ".tar.gz"))
>> +              (file-name (string-append name "-" version ".tar.gz"))
>> +              (sha256
>> +               (base32
>> +                "01x7bhmgwyf6mc2g1hcvibhps98nllacqm4f0j5l51b1mbi18pc2"))))
>> +    (build-system gnu-build-system)
>> +    (supported-systems '("i686-linux" "x86_64-linux"))
>> +    (arguments
>> +     `(#:make-flags (list (string-append "PREFIX=" (assoc-ref %outputs "out")))
>> +       #:test-target "test"
>> +       #:phases (modify-phases %standard-phases
>> +                  (delete 'configure))))
>> +    (synopsis "Tools for the full source bootstrapping process")
>> +    (description
>> +     "Mescc-tools is a collection of tools for use in a full source
>>  bootstrapping process.  It consists of the M1 macro assembler, the hex2
>>  linker, the blood-elf symbol table generator, the kaem shell, exec_enable and
>>  get_machine.")
>>      (home-page "https://savannah.nongnu.org/projects/mescc-tools")
>> -    (license gpl3+))))
>> +    (license gpl3+)))

I guess this is equivalent to reverting commit
78ced7975b0665e810834391d826c9f0ef7277e1 on the 'wip-binaries' branch,
yes?

>> And got this result:
>>
>> $ cd /gnu/store/rdwyr8mh7dvhfkb5g4cws6q40hp23rbi-bootstrap-tarballs-0
>> $ sha256sum *
>> 3e50c070a100b6bcf84c4bf5c868f9cd0a9fd1570f5d82fbfb78f8411959091b  guile-static-stripped-2.2.4-i686-linux.tar.xz
>> 1acd8f83e27d2fac311a5ca78e9bf11a9a1638b82469870d5c854c4e7afaa26a  linux-libre-headers-stripped-4.14.67-i686-linux.tar.xz
>> 021543d9bb6af55f39e68d69692e3cb74646ced2cad0bb9ac0047ef81e9d7330  mescc-tools-static-stripped-0.5.2-i686-linux.tar.xz
>> fb32090071b39fc804fb9a7fba96f0bc5eb844a0efd268fb24c42e6bfa959de0  mes-minimal-stripped-0.19-i686-linux.tar.xz
>> c80cdd17b0a24eebdd75570ff72c4ec06e129bd702ac008186b57f6301c448e7  static-binaries-0-i686-linux.tar.xz

Great, looks good to me!

>> I also merged the branch to core-updates and reverted the bash patch,

I think that 'bash-4.4-linux-pgrp-pipe.patch', adapted to 5.0, should be
applied to all 'bash' packages in 'core-updates'.  To be more precise,
the patch should be applied to the main 'bash' package in bash.scm,
inherited from all other bash packages, so that PGRP_PIPE is set
unconditionally set on systems based on Linux (the kernel), regardless
of the kernel version running on the build machine.

>> which produced this derivation for "guix build -d -s i686-linux
>> bootstrap-tarballs":
>>
>> /gnu/store/ld82vli1msfrlimjaryznrqcwm0jc5ii-bootstrap-tarballs-0.drv
>
> Here are the hashes from this derivation:
>
> $ cd /gnu/store/srsqilb3g70r8c7vma0gpam21z1zmg2w-bootstrap-tarballs-0
> $ sha256sum *
> 4e5b219be4d9ad4d125f17b8a8a991e78be3908aadc8d22d1a115e96ec856279  guile-static-stripped-2.2.6-i686-linux.tar.xz
> 9e34b26526b184912b0d97df96e316151fd97ede24aec2f22dd13ed33438b2e4  linux-libre-headers-stripped-4.19.56-i686-linux.tar.xz
> 7db07a7097a7920e17f6f1794098b9f29bc3522c36a33cf797123f64581cdc34  mescc-tools-static-0.5.2-i686-linux.tar.xz
> 3a9b050c1a2b61bb1cbed16ee07aecdc83e9097ce4a914623aa1b9808abe57f4  mes-minimal-stripped-0.19-i686-linux.tar.xz
> 1ccb4f39656eb977706db7a4aa811461785200b0a11e847035bb89fef91b85ab  static-binaries-0-i686-linux.tar.xz

What was the purpose of building these?  'core-updates' is built upon on
the earlier, unverified, reduced binary seed bootstrap binaries.

> @Mark: do you think we are ready to merge this now?  Can you do it?

I think what needs to be done is the following:

(1) commit 78ced7975b0665e810834391d826c9f0ef7277e1 on 'wip-binaries'
    should be reverted, to downgrade mescc-tools to the 0.5.2 release.

(2) The 'wip-binaries' tarballs should be uploaded to a new subdirectory
    of <https://alpha.gnu.org/gnu/guix/bootstrap/i686-linux/>, along
    with digital signatures, of course.  I'm talking about these in
    particular:

    3e50c070a100b6bcf84c4bf5c868f9cd0a9fd1570f5d82fbfb78f8411959091b  guile-static-stripped-2.2.4-i686-linux.tar.xz
    1acd8f83e27d2fac311a5ca78e9bf11a9a1638b82469870d5c854c4e7afaa26a  linux-libre-headers-stripped-4.14.67-i686-linux.tar.xz
    021543d9bb6af55f39e68d69692e3cb74646ced2cad0bb9ac0047ef81e9d7330  mescc-tools-static-stripped-0.5.2-i686-linux.tar.xz
    fb32090071b39fc804fb9a7fba96f0bc5eb844a0efd268fb24c42e6bfa959de0  mes-minimal-stripped-0.19-i686-linux.tar.xz
    c80cdd17b0a24eebdd75570ff72c4ec06e129bd702ac008186b57f6301c448e7  static-binaries-0-i686-linux.tar.xz

(3) The following bootstrap packages in 'core-updates' bootstrap.scm
    should be updated to use the new binaries above:

     (a) %bootstrap-linux-libre-headers
     (b) %bootstrap-mescc-tools
     (c) %bootstrap-mes

(4) Berlin should start rebuilding 'core-updates'.

If desired, steps (3) and (4) could come before (2) if someone
temporarily uploads the new binaries somewhere else, and adjusts
'%bootstrap-base-urls' accordingly.  The key is for the hashes and file
names to match what we've agreed on here, as I listed in (2) above.

What do you think?

It will be a couple of days before I can do more solid work on this, but
I'd be grateful if others could carry it forward in the meantime.

     Thanks!
       Mark

bug#36747: Official MesCC bootstrap binaries differ from my locally built ones

[Mark H Weaver]

Earlier I wrote:

[...]
> (3) The following bootstrap packages in 'core-updates' bootstrap.scm
>     should be updated to use the new binaries above:
>
>      (a) %bootstrap-linux-libre-headers
>      (b) %bootstrap-mescc-tools
>      (c) %bootstrap-mes
>
> (4) Berlin should start rebuilding 'core-updates'.
>
> If desired, steps (3) and (4) could come before (2) if someone
> temporarily uploads the new binaries somewhere else, and adjusts
> '%bootstrap-base-urls' accordingly.  The key is for the hashes and file
> names to match what we've agreed on here, as I listed in (2) above.
>
> What do you think?

I should have inserted the following item in the TODO list above:

(3.5) I think that 'bash-4.4-linux-pgrp-pipe.patch', adapted to 5.0, should be
    applied to all 'bash' packages in 'core-updates'.  To be more precise,
    the patch should be applied to the main 'bash' package in bash.scm,
    inherited from all other bash packages, so that PGRP_PIPE is set
    unconditionally set on systems based on Linux (the kernel), regardless
    of the kernel version running on the build machine.

This change would also entail a full rebuild of core-updates, so it
should ideally be done before starting the rebuild.  It's not crucial,
but it would be nice to fix this potential source of non-determinism in
the Bash builds.

      Thanks,
        Mark

bug#36747: Official MesCC bootstrap binaries differ from my locally built ones

[Marius Bakke]

[-- Attachment #1: Type: text/plain, Size: 12146 bytes --]

Mark H Weaver <mhw@netris.org> writes:

> Hi Marius,
>
> Marius Bakke <mbakke@fastmail.com> writes:
>
>> Marius Bakke <mbakke@fastmail.com> writes:
>>
>>> Jan Nieuwenhuizen <janneke@gnu.org> writes:
>>>
>>>> Mark H Weaver writes:
>>>>
>>>> Hi Mark,
>>>>
>>>>>> I called that `wip-binaries', @master from three weeks ago.
>>>>>
>>>>> Thank you, that was a good start.  I found that some additional patches
>>>>> were needed to match the bootstrap binaries that 'core-updates' is
>>>>> currently based on.
>>>>>
>>>>> I ended up deleting and repushing a revised 'wip-binaries' to Savannah.
>>>>> It includes slightly modified versions of the two commits you had
>>>>> included, as well as some additional cherry-picked commits of yours to
>>>>> update mescc-tools and add linux-libre-headers-bootstrap-tarball, and a
>>>>> few of my own.
>>>>
>>>> Very nice.
>>>>
>>>>> I built the new bootstrap tarballs at the new 'wip-binaries', commit
>>>>> c67becb31c30a5cd7685f166970ac4793e3a34a9, and here's what I got:
>>>>>
>>>>> mhw@jojen ~/guix-wip-binaries$ git describe
>>>>> v1.0.1-2404-gc67becb31c
>>>>> mhw@jojen ~/guix-wip-binaries$ ./pre-inst-env guix build --system=i686-linux bootstrap-tarballs
>>>>> /gnu/store/bg086i2qw1fn2jgbd15d9v91hyjrjsb2-bootstrap-tarballs-0
>>>>> mhw@jojen ~/guix-wip-binaries$ cd /gnu/store/bg086i2qw1fn2jgbd15d9v91hyjrjsb2-bootstrap-tarballs-0
>>>>> mhw@jojen /gnu/store/bg086i2qw1fn2jgbd15d9v91hyjrjsb2-bootstrap-tarballs-0$ sha256sum *
>>>>> 3e50c070a100b6bcf84c4bf5c868f9cd0a9fd1570f5d82fbfb78f8411959091b  guile-static-stripped-2.2.4-i686-linux.tar.xz
>>>>> 1acd8f83e27d2fac311a5ca78e9bf11a9a1638b82469870d5c854c4e7afaa26a  linux-libre-headers-stripped-4.14.67-i686-linux.tar.xz
>>>>> 021543d9bb6af55f39e68d69692e3cb74646ced2cad0bb9ac0047ef81e9d7330  mescc-tools-static-stripped-0.5.2-0.bb062b0-i686-linux.tar.xz
>>>>> fb32090071b39fc804fb9a7fba96f0bc5eb844a0efd268fb24c42e6bfa959de0  mes-minimal-stripped-0.19-i686-linux.tar.xz
>>>>> c80cdd17b0a24eebdd75570ff72c4ec06e129bd702ac008186b57f6301c448e7  static-binaries-0-i686-linux.tar.xz
>>>>
>>>>> Can you try "guix build --system=i686-linux bootstrap-tarballs" at the
>>>>> new 'wip-binaries' branch and see if you get the same results?
>>>>
>>>> Yes, on c67becb31c30a5cd7685f166970ac4793e3a34a9 running
>>>> "./pre-inst-env guix build --system=i686-linux bootstrap-tarballs" gives me exactly this,
>>>> also for guile-static-stripped! \o/
>>>>
>>>>> Also, I have a question: One of the changes I made to 'wip-binaries' was
>>>>> to update mescc-tools to 0.5.2-0.bb062b0, to match the
>>>>> %bootstrap-mescc-tools that's currently being used in 'core-updates'.
>>>>>
>>>>> However, I noticed that you have also apparently built the official
>>>>> release of mescc-tools-0.5.2, which is on your site:
>>>>>
>>>>>   http://lilypond.org/janneke/guix/20190722/mescc-tools-static-stripped-0.5.2-i686-linux.tar.xz
>>>>>
>>>>> and that this tarball is identical to the build output of the later git
>>>>> commit: mescc-tools-static-stripped-0.5.2-0.bb062b0-i686-linux.tar.xz.
>>>>>
>>>>> With this in mind, could we just use 0.5.2?  What changed between 0.5.2
>>>>> and 0.5.2-0.bb062b0, and what was the rationale for updating to bb062b0?
>>>>
>>>> Good catch.  We probably can, we might try that.
>>>>
>>>> I think the need for updating to bb062b0 has been removed during the
>>>> review of the integration of the reduced binary seed bootstrap into
>>>> core-updates by Ludovic.
>>>>
>>>> For historical reasons, I think this mescc-tools commit
>>>>
>>>> --8<---------------cut here---------------start------------->8---
>>>> commit c184e95096881a13f29ebd7fc507fe305d3d8de5 (gitlab/janneke, janneke)
>>>> Author: Jan Nieuwenhuizen <janneke@gnu.org>
>>>> Date:   Thu Oct 4 22:03:31 2018 +0200
>>>>
>>>>     build.sh: Update for mes 0.18.
>>>> --8<---------------cut here---------------end--------------->8---
>>>>
>>>> was needed at a time that we did not have mescc-tools or mes in
>>>> bootstrap tarballs.  We built bootstrap variants of mescc-tools and mes
>>>> using a externally (outside fo Guix) built mescc-tools-seed and
>>>> (an almost pure ASCII) mes-seed.
>>>
>>> I tried building the i686 bootstrap tarballs from wip-binaries with this
>>> additional patch:
>>>
>>> diff --git a/gnu/packages/mes.scm b/gnu/packages/mes.scm
>>> index e298cb05c1..380cac6c88 100644
>>> --- a/gnu/packages/mes.scm
>>> +++ b/gnu/packages/mes.scm
>>> @@ -139,33 +139,31 @@ Guile.")
>>>      (license gpl3+)))
>>>  
>>>  (define-public mescc-tools
>>> -  (let ((commit "bb062b0da7bf2724ca40f9002b121579898d4ef7")
>>> -        (revision "0")
>>> -        (version "0.5.2"))
>>> -    (package
>>> -      (name "mescc-tools")
>>> -      (version (string-append version "-" revision "." (string-take commit 7)))
>>> -      (source (origin
>>> -                (method url-fetch)
>>> -                (uri (string-append
>>> -                      "https://git.savannah.nongnu.org/cgit/mescc-tools.git/snapshot/"
>>> -                      name "-" commit
>>> -                      ".tar.gz"))
>>> -                (sha256
>>> -                 (base32
>>> -                  "1h6j57wyf91i42b26f8msbv6451cw3nm4nmpl1fckp9c7vi8mwkh"))))
>>> -      (build-system gnu-build-system)
>>> -      (supported-systems '("i686-linux" "x86_64-linux"))
>>> -      (arguments
>>> -       `(#:make-flags (list (string-append "PREFIX=" (assoc-ref %outputs "out")))
>>> -         #:test-target "test"
>>> -         #:phases (modify-phases %standard-phases
>>> -                    (delete 'configure))))
>>> -      (synopsis "Tools for the full source bootstrapping process")
>>> -      (description
>>> -       "Mescc-tools is a collection of tools for use in a full source
>>> +  (package
>>> +    (name "mescc-tools")
>>> +    (version "0.5.2")
>>> +    (source (origin
>>> +              (method url-fetch)
>>> +              (uri (string-append
>>> +                    "https://git.savannah.nongnu.org/cgit/mescc-tools.git/snapshot/"
>>> +                    name "-Release_" version
>>> +                    ".tar.gz"))
>>> +              (file-name (string-append name "-" version ".tar.gz"))
>>> +              (sha256
>>> +               (base32
>>> +                "01x7bhmgwyf6mc2g1hcvibhps98nllacqm4f0j5l51b1mbi18pc2"))))
>>> +    (build-system gnu-build-system)
>>> +    (supported-systems '("i686-linux" "x86_64-linux"))
>>> +    (arguments
>>> +     `(#:make-flags (list (string-append "PREFIX=" (assoc-ref %outputs "out")))
>>> +       #:test-target "test"
>>> +       #:phases (modify-phases %standard-phases
>>> +                  (delete 'configure))))
>>> +    (synopsis "Tools for the full source bootstrapping process")
>>> +    (description
>>> +     "Mescc-tools is a collection of tools for use in a full source
>>>  bootstrapping process.  It consists of the M1 macro assembler, the hex2
>>>  linker, the blood-elf symbol table generator, the kaem shell, exec_enable and
>>>  get_machine.")
>>>      (home-page "https://savannah.nongnu.org/projects/mescc-tools")
>>> -    (license gpl3+))))
>>> +    (license gpl3+)))
>
> I guess this is equivalent to reverting commit
> 78ced7975b0665e810834391d826c9f0ef7277e1 on the 'wip-binaries' branch,
> yes?

Indeed.

>>> And got this result:
>>>
>>> $ cd /gnu/store/rdwyr8mh7dvhfkb5g4cws6q40hp23rbi-bootstrap-tarballs-0
>>> $ sha256sum *
>>> 3e50c070a100b6bcf84c4bf5c868f9cd0a9fd1570f5d82fbfb78f8411959091b  guile-static-stripped-2.2.4-i686-linux.tar.xz
>>> 1acd8f83e27d2fac311a5ca78e9bf11a9a1638b82469870d5c854c4e7afaa26a  linux-libre-headers-stripped-4.14.67-i686-linux.tar.xz
>>> 021543d9bb6af55f39e68d69692e3cb74646ced2cad0bb9ac0047ef81e9d7330  mescc-tools-static-stripped-0.5.2-i686-linux.tar.xz
>>> fb32090071b39fc804fb9a7fba96f0bc5eb844a0efd268fb24c42e6bfa959de0  mes-minimal-stripped-0.19-i686-linux.tar.xz
>>> c80cdd17b0a24eebdd75570ff72c4ec06e129bd702ac008186b57f6301c448e7  static-binaries-0-i686-linux.tar.xz
>
> Great, looks good to me!
>
>>> I also merged the branch to core-updates and reverted the bash patch,
>
> I think that 'bash-4.4-linux-pgrp-pipe.patch', adapted to 5.0, should be
> applied to all 'bash' packages in 'core-updates'.  To be more precise,
> the patch should be applied to the main 'bash' package in bash.scm,
> inherited from all other bash packages, so that PGRP_PIPE is set
> unconditionally set on systems based on Linux (the kernel), regardless
> of the kernel version running on the build machine.

Got it.

>>> which produced this derivation for "guix build -d -s i686-linux
>>> bootstrap-tarballs":
>>>
>>> /gnu/store/ld82vli1msfrlimjaryznrqcwm0jc5ii-bootstrap-tarballs-0.drv
>>
>> Here are the hashes from this derivation:
>>
>> $ cd /gnu/store/srsqilb3g70r8c7vma0gpam21z1zmg2w-bootstrap-tarballs-0
>> $ sha256sum *
>> 4e5b219be4d9ad4d125f17b8a8a991e78be3908aadc8d22d1a115e96ec856279  guile-static-stripped-2.2.6-i686-linux.tar.xz
>> 9e34b26526b184912b0d97df96e316151fd97ede24aec2f22dd13ed33438b2e4  linux-libre-headers-stripped-4.19.56-i686-linux.tar.xz
>> 7db07a7097a7920e17f6f1794098b9f29bc3522c36a33cf797123f64581cdc34  mescc-tools-static-0.5.2-i686-linux.tar.xz
>> 3a9b050c1a2b61bb1cbed16ee07aecdc83e9097ce4a914623aa1b9808abe57f4  mes-minimal-stripped-0.19-i686-linux.tar.xz
>> 1ccb4f39656eb977706db7a4aa811461785200b0a11e847035bb89fef91b85ab  static-binaries-0-i686-linux.tar.xz
>
> What was the purpose of building these?  'core-updates' is built upon on
> the earlier, unverified, reduced binary seed bootstrap binaries.

I wanted to check that the bootstrap-tarballs machinery still worked
after merging the branch, since it was non-trivial.  Mainly to make the
commit that created them reachable forever, but maybe we don't need it.

>> @Mark: do you think we are ready to merge this now?  Can you do it?
>
> I think what needs to be done is the following:
>
> (1) commit 78ced7975b0665e810834391d826c9f0ef7277e1 on 'wip-binaries'
>     should be reverted, to downgrade mescc-tools to the 0.5.2 release.
>
> (2) The 'wip-binaries' tarballs should be uploaded to a new subdirectory
>     of <https://alpha.gnu.org/gnu/guix/bootstrap/i686-linux/>, along
>     with digital signatures, of course.  I'm talking about these in
>     particular:
>
>     3e50c070a100b6bcf84c4bf5c868f9cd0a9fd1570f5d82fbfb78f8411959091b  guile-static-stripped-2.2.4-i686-linux.tar.xz
>     1acd8f83e27d2fac311a5ca78e9bf11a9a1638b82469870d5c854c4e7afaa26a  linux-libre-headers-stripped-4.14.67-i686-linux.tar.xz
>     021543d9bb6af55f39e68d69692e3cb74646ced2cad0bb9ac0047ef81e9d7330  mescc-tools-static-stripped-0.5.2-i686-linux.tar.xz
>     fb32090071b39fc804fb9a7fba96f0bc5eb844a0efd268fb24c42e6bfa959de0  mes-minimal-stripped-0.19-i686-linux.tar.xz
>     c80cdd17b0a24eebdd75570ff72c4ec06e129bd702ac008186b57f6301c448e7  static-binaries-0-i686-linux.tar.xz
>
> (3) The following bootstrap packages in 'core-updates' bootstrap.scm
>     should be updated to use the new binaries above:
>
>      (a) %bootstrap-linux-libre-headers
>      (b) %bootstrap-mescc-tools
>      (c) %bootstrap-mes
>
> (4) Berlin should start rebuilding 'core-updates'.
>
> If desired, steps (3) and (4) could come before (2) if someone
> temporarily uploads the new binaries somewhere else, and adjusts
> '%bootstrap-base-urls' accordingly.  The key is for the hashes and file
> names to match what we've agreed on here, as I listed in (2) above.
>
> What do you think?

Thank you for the excellent summary.  I can look into adjusting the bash
fix for 5.0, and updating the bootstrap binary URLs and hashes.  I will
do this in a 'core-updates-next' branch.  I would also like to merge
wip-binaries into it as a final step, unless someone has objections.

Ludovic should be back in a couple of days and can hopefully take care
of the uploads.

Ricardo: can you instruct Cuirass to add a reduced jobset for
'core-updates-next', that only builds builds the "core" package subset?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

bug#36747: Official MesCC bootstrap binaries differ from my locally built ones

[Mark H Weaver]

Hi Marius,

Marius Bakke <mbakke@fastmail.com> writes:

> I wanted to check that the bootstrap-tarballs machinery still worked
> after merging the branch, since it was non-trivial.  Mainly to make the
> commit that created them reachable forever, but maybe we don't need it.

[...]

> [...] I will do this in a 'core-updates-next' branch.  I would also
> like to merge wip-binaries into it as a final step, unless someone has
> objections.

I think that 'wip-binaries' (or something close to it) should be merged
into 'master', rather than 'core-updates'.  That would allow people to
easily verify the new bootstrap binaries from 'master'.

Of course, anything merged into 'master' will eventually be merged into
'core-updates' as well, but no one will be able to verify the new
binaries from 'core-updates' anyway, because 'core-updates' has
different versions of 'bash', 'guile', and maybe some other things.

What do you think?

      Mark

bug#36747: Official MesCC bootstrap binaries differ from my locally built ones

[Mark H Weaver]

[-- Attachment #1: Type: text/plain, Size: 432 bytes --]

I rebased 'wip-binaries' on top of current master (which includes the
recent 'staging' merge), and excluding the update of mescc-tools to the
git checkout.

I built the bootstrap-tarballs for i686-linux and got the same hashes
that we've previously agreed on here.  I used "guix download" to load
the new bootstrap binaries into my store, and am now testing the
attached draft patch to 'core-updates'.

      Thanks,
        Mark



[-- Attachment #2: [PATCH] gnu: bootstrap: Update to the 20190815 bootstrap binaries --]
[-- Type: text/x-patch, Size: 2993 bytes --]

From e3e477c92af3b62eb8f65a5c4459f02faf60e857 Mon Sep 17 00:00:00 2001
From: Mark H Weaver <mhw@netris.org>
Date: Thu, 15 Aug 2019 15:39:57 -0400
Subject: [PATCH] gnu: bootstrap: Update to the 20190815 bootstrap binaries.

* gnu/packages/bootstrap.scm (%bootstrap-linux-libre-headers): Update the
download URL.
(%bootstrap-mescc-tools, %bootstrap-mes): Update the download URL and hash.
---
 gnu/packages/bootstrap.scm | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/gnu/packages/bootstrap.scm b/gnu/packages/bootstrap.scm
index 8dbe52435e..1982c9706f 100644
--- a/gnu/packages/bootstrap.scm
+++ b/gnu/packages/bootstrap.scm
@@ -1,6 +1,6 @@
 ;;; GNU Guix --- Functional package management for GNU
 ;;; Copyright © 2012, 2013, 2014, 2015, 2016, 2017, 2018, 2019 Ludovic Courtès <ludo@gnu.org>
-;;; Copyright © 2014, 2015, 2018 Mark H Weaver <mhw@netris.org>
+;;; Copyright © 2014, 2015, 2018, 2019 Mark H Weaver <mhw@netris.org>
 ;;; Copyright © 2017 Efraim Flashner <efraim@flashner.co.il>
 ;;; Copyright © 2018 Jan (janneke) Nieuwenhuizen <janneke@gnu.org>
 ;;;
@@ -490,7 +490,7 @@ $out/bin/guile --version~%"
      (origin
        (method url-fetch)
        (uri (map (cute string-append <>
-                       "/i686-linux/20181020/"
+                       "/i686-linux/20190815/"
                        "linux-libre-headers-stripped-4.14.67-i686-linux.tar.xz")
                  %bootstrap-base-urls))
        (sha256
@@ -735,12 +735,12 @@ exec ~a/bin/.gcc-wrapped -B~a/lib \
             (method url-fetch)
             (uri (map
                   (cute string-append <>
-                        "/i686-linux/20181020/"
-                        "mescc-tools-static-0.5.2-0.bb062b0-i686-linux.tar.xz")
+                        "/i686-linux/20190815/"
+                        "mescc-tools-static-stripped-0.5.2-i686-linux.tar.xz")
                   %bootstrap-base-urls))
             (sha256
              (base32
-              "11lniw0vg61kmyhvnwkmcnkci9ym6hbmiksiqggd0hkipbq7hvlz")))))))
+              "0c3kklgghzh4q2dbpl6asb74cimp7hp6jscdwqwmzxbapgcl6582")))))))
     (synopsis "Bootstrap binaries of MesCC Tools")
     (description synopsis)
     (home-page #f)
@@ -784,12 +784,12 @@ exec ~a/bin/.gcc-wrapped -B~a/lib \
             (method url-fetch)
             (uri (map
                   (cute string-append <>
-                        "/i686-linux/20181020/"
+                        "/i686-linux/20190815/"
                         "mes-minimal-stripped-0.19-i686-linux.tar.xz")
                   %bootstrap-base-urls))
             (sha256
              (base32
-              "0k7kkl68a6xaadv47ij0nr9jm5ca1ffj38n7f2lg80y72wdkwr9h")))))))
+              "1q4xjpx6nbn44kxnilpgl12bhpmwy2bblzwszc2ci7xkf400jcpv")))))))
     (supported-systems '("i686-linux" "x86_64-linux"))
     (synopsis "Bootstrap binaries of Mes")
     (description synopsis)
-- 
2.22.1

bug#36747: Official MesCC bootstrap binaries differ from my locally built ones

[Mark H Weaver]

[-- Attachment #1: Type: text/plain, Size: 244 bytes --]

Hi,

Marius Bakke <mbakke@fastmail.com> writes:
> I can look into adjusting the bash fix for 5.0, and updating the
> bootstrap binary URLs and hashes.

I've attached preliminary untested patches for these.  I'm testing them
now.

       Mark



[-- Attachment #2: [PATCH 1/2] gnu: bootstrap: Update to the 20190815 bootstrap binaries --]
[-- Type: text/x-patch, Size: 2999 bytes --]

From e3e477c92af3b62eb8f65a5c4459f02faf60e857 Mon Sep 17 00:00:00 2001
From: Mark H Weaver <mhw@netris.org>
Date: Thu, 15 Aug 2019 15:39:57 -0400
Subject: [PATCH 1/2] gnu: bootstrap: Update to the 20190815 bootstrap
 binaries.

* gnu/packages/bootstrap.scm (%bootstrap-linux-libre-headers): Update the
download URL.
(%bootstrap-mescc-tools, %bootstrap-mes): Update the download URL and hash.
---
 gnu/packages/bootstrap.scm | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/gnu/packages/bootstrap.scm b/gnu/packages/bootstrap.scm
index 8dbe52435e..1982c9706f 100644
--- a/gnu/packages/bootstrap.scm
+++ b/gnu/packages/bootstrap.scm
@@ -1,6 +1,6 @@
 ;;; GNU Guix --- Functional package management for GNU
 ;;; Copyright © 2012, 2013, 2014, 2015, 2016, 2017, 2018, 2019 Ludovic Courtès <ludo@gnu.org>
-;;; Copyright © 2014, 2015, 2018 Mark H Weaver <mhw@netris.org>
+;;; Copyright © 2014, 2015, 2018, 2019 Mark H Weaver <mhw@netris.org>
 ;;; Copyright © 2017 Efraim Flashner <efraim@flashner.co.il>
 ;;; Copyright © 2018 Jan (janneke) Nieuwenhuizen <janneke@gnu.org>
 ;;;
@@ -490,7 +490,7 @@ $out/bin/guile --version~%"
      (origin
        (method url-fetch)
        (uri (map (cute string-append <>
-                       "/i686-linux/20181020/"
+                       "/i686-linux/20190815/"
                        "linux-libre-headers-stripped-4.14.67-i686-linux.tar.xz")
                  %bootstrap-base-urls))
        (sha256
@@ -735,12 +735,12 @@ exec ~a/bin/.gcc-wrapped -B~a/lib \
             (method url-fetch)
             (uri (map
                   (cute string-append <>
-                        "/i686-linux/20181020/"
-                        "mescc-tools-static-0.5.2-0.bb062b0-i686-linux.tar.xz")
+                        "/i686-linux/20190815/"
+                        "mescc-tools-static-stripped-0.5.2-i686-linux.tar.xz")
                   %bootstrap-base-urls))
             (sha256
              (base32
-              "11lniw0vg61kmyhvnwkmcnkci9ym6hbmiksiqggd0hkipbq7hvlz")))))))
+              "0c3kklgghzh4q2dbpl6asb74cimp7hp6jscdwqwmzxbapgcl6582")))))))
     (synopsis "Bootstrap binaries of MesCC Tools")
     (description synopsis)
     (home-page #f)
@@ -784,12 +784,12 @@ exec ~a/bin/.gcc-wrapped -B~a/lib \
             (method url-fetch)
             (uri (map
                   (cute string-append <>
-                        "/i686-linux/20181020/"
+                        "/i686-linux/20190815/"
                         "mes-minimal-stripped-0.19-i686-linux.tar.xz")
                   %bootstrap-base-urls))
             (sha256
              (base32
-              "0k7kkl68a6xaadv47ij0nr9jm5ca1ffj38n7f2lg80y72wdkwr9h")))))))
+              "1q4xjpx6nbn44kxnilpgl12bhpmwy2bblzwszc2ci7xkf400jcpv")))))))
     (supported-systems '("i686-linux" "x86_64-linux"))
     (synopsis "Bootstrap binaries of Mes")
     (description synopsis)
-- 
2.22.1


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: [PATCH 2/2] UNTESTED: bash: Unconditionally configure PGRP_PIPE for *-linux systems --]
[-- Type: text/x-patch, Size: 3540 bytes --]

From 1e609d70cd29af6eed7ceb81b840ac0a4f29fe42 Mon Sep 17 00:00:00 2001
From: Mark H Weaver <mhw@netris.org>
Date: Thu, 15 Aug 2019 16:45:03 -0400
Subject: [PATCH 2/2] UNTESTED: bash: Unconditionally configure PGRP_PIPE for
 *-linux systems.

* gnu/packages/patches/bash-linux-pgrp-pipe.patch: New file.
* gnu/local.mk (dist_patch_DATA): Add it.
* gnu/packages/bash.scm (bash)[source]: Add the patch.
---
 gnu/local.mk                                  |  1 +
 gnu/packages/bash.scm                         |  3 +-
 .../patches/bash-linux-pgrp-pipe.patch        | 32 +++++++++++++++++++
 3 files changed, 35 insertions(+), 1 deletion(-)
 create mode 100644 gnu/packages/patches/bash-linux-pgrp-pipe.patch

diff --git a/gnu/local.mk b/gnu/local.mk
index 08bc205623..2e6d4776b9 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -697,6 +697,7 @@ dist_patch_DATA =						\
   %D%/packages/patches/awesome-reproducible-png.patch		\
   %D%/packages/patches/azr3.patch				\
   %D%/packages/patches/bash-completion-directories.patch	\
+  %D%/packages/patches/bash-linux-pgrp-pipe.patch		\
   %D%/packages/patches/bastet-change-source-of-unordered_set.patch	\
   %D%/packages/patches/bazaar-CVE-2017-14176.patch		\
   %D%/packages/patches/beets-python-3.7-fix.patch		\
diff --git a/gnu/packages/bash.scm b/gnu/packages/bash.scm
index d3abeec6e6..f1ef7047bf 100644
--- a/gnu/packages/bash.scm
+++ b/gnu/packages/bash.scm
@@ -115,7 +115,8 @@ number/base32-hash tuples, directly usable in the 'patch-series' form."
                (base32
                 "0kgvfwqdcd90waczf4gx39xnrxzijhjrzyzv7s8v4w31qqm0za5l"))
               (patch-flags '("-p0"))
-              (patches %patch-series-5.0)))
+              (patches (cons (search-patch "bash-linux-pgrp-pipe.patch")
+                             %patch-series-5.0))))
      (version (string-append version "." (number->string (length %patch-series-5.0))))
      (build-system gnu-build-system)
 
diff --git a/gnu/packages/patches/bash-linux-pgrp-pipe.patch b/gnu/packages/patches/bash-linux-pgrp-pipe.patch
new file mode 100644
index 0000000000..234a55e897
--- /dev/null
+++ b/gnu/packages/patches/bash-linux-pgrp-pipe.patch
@@ -0,0 +1,32 @@
+Unconditionally enable PGRP_PIPE on Linux (the kernel), regardless of
+the kernel version in use on the build machine.
+
+--- configure.ac.orig	2019-01-02 09:38:44.000000000 -0500
++++ configure.ac	2019-08-15 16:40:24.271758379 -0400
+@@ -1108,10 +1108,7 @@
+ solaris2*)	LOCAL_CFLAGS=-DSOLARIS ;;
+ lynxos*)	LOCAL_CFLAGS=-DRECYCLES_PIDS ;;
+ linux*)		LOCAL_LDFLAGS=-rdynamic		 # allow dynamic loading
+-		case "`uname -r`" in
+-		1.*|2.[[0123]]*)	: ;;
+-		*)	AC_DEFINE(PGRP_PIPE) ;;
+-		esac ;;
++		AC_DEFINE(PGRP_PIPE) ;;
+ netbsd*|openbsd*)	LOCAL_CFLAGS="-DDEV_FD_STAT_BROKEN" ;;
+ *qnx[[67]]*)	LOCAL_LIBS="-lncurses" ;;
+ *qnx*)		LOCAL_CFLAGS="-Dqnx -F -3s" LOCAL_LDFLAGS="-3s" LOCAL_LIBS="-lunix -lncurses" ;;
+--- configure.orig	2019-01-02 09:43:04.000000000 -0500
++++ configure	2019-08-15 16:41:44.440155912 -0400
+@@ -16312,11 +16312,7 @@
+ solaris2*)	LOCAL_CFLAGS=-DSOLARIS ;;
+ lynxos*)	LOCAL_CFLAGS=-DRECYCLES_PIDS ;;
+ linux*)		LOCAL_LDFLAGS=-rdynamic		 # allow dynamic loading
+-		case "`uname -r`" in
+-		1.*|2.[0123]*)	: ;;
+-		*)	$as_echo "#define PGRP_PIPE 1" >>confdefs.h
+- ;;
+-		esac ;;
++		$as_echo "#define PGRP_PIPE 1" >>confdefs.h ;;
+ netbsd*|openbsd*)	LOCAL_CFLAGS="-DDEV_FD_STAT_BROKEN" ;;
+ *qnx[67]*)	LOCAL_LIBS="-lncurses" ;;
+ *qnx*)		LOCAL_CFLAGS="-Dqnx -F -3s" LOCAL_LDFLAGS="-3s" LOCAL_LIBS="-lunix -lncurses" ;;
-- 
2.22.1

bug#36747: Official MesCC bootstrap binaries differ from my locally built ones

[Marius Bakke]

[-- Attachment #1: Type: text/plain, Size: 768 bytes --]

Mark H Weaver <mhw@netris.org> writes:

> I rebased 'wip-binaries' on top of current master (which includes the
> recent 'staging' merge), and excluding the update of mescc-tools to the
> git checkout.
>
> I built the bootstrap-tarballs for i686-linux and got the same hashes
> that we've previously agreed on here.  I used "guix download" to load
> the new bootstrap binaries into my store, and am now testing the
> attached draft patch to 'core-updates'.

Excellent, thank you!  The patches LGTM.

I wonder if we should run these through a 'core-updates-next' branch to
give ourselves a little time to bootstrap the different architectures.

(also, it would be neat to get SQLite 3.29.0 in..)

Thoughts?  I don't have a strong opinion, so do what you think is best.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

bug#36747: Official MesCC bootstrap binaries differ from my locally built ones

[Mark H Weaver]

Marius Bakke <mbakke@fastmail.com> writes:

> Mark H Weaver <mhw@netris.org> writes:
>
>> I rebased 'wip-binaries' on top of current master (which includes the
>> recent 'staging' merge), and excluding the update of mescc-tools to the
>> git checkout.
>>
>> I built the bootstrap-tarballs for i686-linux and got the same hashes
>> that we've previously agreed on here.  I used "guix download" to load
>> the new bootstrap binaries into my store, and am now testing the
>> attached draft patch to 'core-updates'.
>
> Excellent, thank you!  The patches LGTM.
>
> I wonder if we should run these through a 'core-updates-next' branch to
> give ourselves a little time to bootstrap the different architectures.
>
> (also, it would be neat to get SQLite 3.29.0 in..)
>
> Thoughts?  I don't have a strong opinion, so do what you think is best.

I think we should continue to treat 'core-updates' as frozen.  These
slight changes to the bootstrap binaries to make them build
deterministically should almost certainly make no difference to anything
else in 'core-updates', so the only time we'll lose is the time needed
for Berlin to rebuild.

If we make any additional changes to 'core-updates', such as updating
SQLite or adding more architectures, it will likely cause additional
problems that need to be debugged.  This 'core-updates' cycle has
already taken too long, IMO.

Any other opinions?

      Thanks,
        Mark

bug#36747: Official MesCC bootstrap binaries differ from my locally built ones

[Mark H Weaver]

Hi Marius,

Earlier I wrote:

> Marius Bakke <mbakke@fastmail.com> writes:
>> I can look into adjusting the bash fix for 5.0, and updating the
>> bootstrap binary URLs and hashes.
>
> I've attached preliminary untested patches for these.  I'm testing them
> now.

I pushed those two commits to 'core-updates-next', and am currently
building out that branch on my X200.  So far I've successfully built the
core packages and 'hello', and am now continuing on to build the rest of
my Guix system.

Anyway, I'm long past the point where the slight differences made to the
new bootstrap binaries to make them deterministic should have any
effects, so I think it's fairly safe to predict that these commits will
not introduce new problems.

Marius Bakke <mbakke@fastmail.com> wrote:
> Ricardo: can you instruct Cuirass to add a reduced jobset for
> 'core-updates-next', that only builds builds the "core" package subset?

For now, I did as you suggested and pushed the commits to
'core-updates-next', although personally I'd be inclined to simply push
them to 'core-updates', after the new bootstrap binaries have either
been uploaded or manually added to Berlin's store.

What do you think?

      Mark

bug#36747: Official MesCC bootstrap binaries differ from my locally built ones

[Ludovic Courtès]

Hello,

Marius Bakke <mbakke@fastmail.com> skribis:

> Mark H Weaver <mhw@netris.org> writes:

[...]

>> I think what needs to be done is the following:
>>
>> (1) commit 78ced7975b0665e810834391d826c9f0ef7277e1 on 'wip-binaries'
>>     should be reverted, to downgrade mescc-tools to the 0.5.2 release.
>>
>> (2) The 'wip-binaries' tarballs should be uploaded to a new subdirectory
>>     of <https://alpha.gnu.org/gnu/guix/bootstrap/i686-linux/>, along
>>     with digital signatures, of course.  I'm talking about these in
>>     particular:
>>
>>     3e50c070a100b6bcf84c4bf5c868f9cd0a9fd1570f5d82fbfb78f8411959091b  guile-static-stripped-2.2.4-i686-linux.tar.xz
>>     1acd8f83e27d2fac311a5ca78e9bf11a9a1638b82469870d5c854c4e7afaa26a  linux-libre-headers-stripped-4.14.67-i686-linux.tar.xz
>>     021543d9bb6af55f39e68d69692e3cb74646ced2cad0bb9ac0047ef81e9d7330  mescc-tools-static-stripped-0.5.2-i686-linux.tar.xz
>>     fb32090071b39fc804fb9a7fba96f0bc5eb844a0efd268fb24c42e6bfa959de0  mes-minimal-stripped-0.19-i686-linux.tar.xz
>>     c80cdd17b0a24eebdd75570ff72c4ec06e129bd702ac008186b57f6301c448e7  static-binaries-0-i686-linux.tar.xz
>>
>> (3) The following bootstrap packages in 'core-updates' bootstrap.scm
>>     should be updated to use the new binaries above:
>>
>>      (a) %bootstrap-linux-libre-headers
>>      (b) %bootstrap-mescc-tools
>>      (c) %bootstrap-mes
>>
>> (4) Berlin should start rebuilding 'core-updates'.
>>
>> If desired, steps (3) and (4) could come before (2) if someone
>> temporarily uploads the new binaries somewhere else, and adjusts
>> '%bootstrap-base-urls' accordingly.  The key is for the hashes and file
>> names to match what we've agreed on here, as I listed in (2) above.
>>
>> What do you think?
>
> Thank you for the excellent summary.  I can look into adjusting the bash
> fix for 5.0, and updating the bootstrap binary URLs and hashes.  I will
> do this in a 'core-updates-next' branch.  I would also like to merge
> wip-binaries into it as a final step, unless someone has objections.
>
> Ludovic should be back in a couple of days and can hopefully take care
> of the uploads.

I haven’t quite caught up yet, but I trust you and I can upload the
files that Mark mentions above to ftp.gnu.org this time (Ricardo should
also be able to upload them, if needed.)

How can I reproduce them or fetch them?

> Ricardo: can you instruct Cuirass to add a reduced jobset for
> 'core-updates-next', that only builds builds the "core" package subset?

Should be ready now:

  https://ci.guix.gnu.org/jobset/core-updates-next

However, evaluation fails with:

--8<---------------cut here---------------start------------->8---
Backtrace:
In guix/packages.scm:
  1188:25 19 (bag->derivation #<store-connection 256.99 2860c60> #<?> ?)
In srfi/srfi-1.scm:
   592:29 18 (map1 (("source" #<origin ("http://fossies.org/lin?>) ?))
   592:17 17 (map1 (("bash" #<package bash-minimal@4.4.23 gnu/p?>) ?))
In guix/packages.scm:
   979:16 16 (expand-input #<store-connection 256.99 2860c60> #<pac?> ?)
   936:16 15 (cache! #<weak-table 2/113> #<package bash-minimal@4.4?> ?)
  1255:22 14 (thunk)
  1188:25 13 (bag->derivation #<store-connection 256.99 2860c60> #<?> ?)
In srfi/srfi-1.scm:
   592:29 12 (map1 (("source" #<origin "mirror://gnu/bash/bash-?>) ?))
   592:17 11 (map1 (("gcc" #<package gcc@5.5.0 gnu/packages/boo?>) ?))
In guix/packages.scm:
   979:16 10 (expand-input #<store-connection 256.99 2860c60> #<pac?> ?)
   936:16  9 (cache! #<weak-table 2/113> #<package gcc@5.5.0 gnu/pa?> ?)
  1255:22  8 (thunk)
  1188:25  7 (bag->derivation #<store-connection 256.99 2860c60> #<?> ?)
In srfi/srfi-1.scm:
   592:29  6 (map1 (("source" #<origin "mirror://gnu/gcc/gcc-5.?>) ?))
   592:17  5 (map1 (("texinfo" #<package texinfo@6.5 gnu/packag?>) ?))
In guix/packages.scm:
   979:16  4 (expand-input #<store-connection 256.99 2860c60> #<pac?> ?)
   936:16  3 (cache! #<weak-table 2/113> #<package texinfo@6.5 gnu/?> ?)
  1255:22  2 (thunk)
  1188:25  1 Exception thrown while printing backtrace:
Throw to key `srfi-34' with args `(#<condition &message [message: "texinfo-perl-compat.patch: patch not found"] 56ac3c0>)'.

srfi/srfi-1.scm:592:17: In procedure map1:
Throw to key `srfi-34' with args `(#<condition &message [message: "texinfo-perl-compat.patch: patch not found"] 51bb5c0>)'.
--8<---------------cut here---------------end--------------->8---

Am I missing something?

Ludo’.

bug#36747: Official MesCC bootstrap binaries differ from my locally built ones

[Mark H Weaver]

Hi Ludovic,

Ludovic Courtès <ludo@gnu.org> writes:

> Marius Bakke <mbakke@fastmail.com> skribis:
>
>> Mark H Weaver <mhw@netris.org> writes:
>
> [...]
>
>>> I think what needs to be done is the following:
>>>
>>> (1) commit 78ced7975b0665e810834391d826c9f0ef7277e1 on 'wip-binaries'
>>>     should be reverted, to downgrade mescc-tools to the 0.5.2 release.
>>>
>>> (2) The 'wip-binaries' tarballs should be uploaded to a new subdirectory
>>>     of <https://alpha.gnu.org/gnu/guix/bootstrap/i686-linux/>, along
>>>     with digital signatures, of course.  I'm talking about these in
>>>     particular:
>>>
>>>     3e50c070a100b6bcf84c4bf5c868f9cd0a9fd1570f5d82fbfb78f8411959091b  guile-static-stripped-2.2.4-i686-linux.tar.xz
>>>     1acd8f83e27d2fac311a5ca78e9bf11a9a1638b82469870d5c854c4e7afaa26a  linux-libre-headers-stripped-4.14.67-i686-linux.tar.xz
>>>     021543d9bb6af55f39e68d69692e3cb74646ced2cad0bb9ac0047ef81e9d7330  mescc-tools-static-stripped-0.5.2-i686-linux.tar.xz
>>>     fb32090071b39fc804fb9a7fba96f0bc5eb844a0efd268fb24c42e6bfa959de0  mes-minimal-stripped-0.19-i686-linux.tar.xz
>>>     c80cdd17b0a24eebdd75570ff72c4ec06e129bd702ac008186b57f6301c448e7  static-binaries-0-i686-linux.tar.xz
>>>
>>> (3) The following bootstrap packages in 'core-updates' bootstrap.scm
>>>     should be updated to use the new binaries above:
>>>
>>>      (a) %bootstrap-linux-libre-headers
>>>      (b) %bootstrap-mescc-tools
>>>      (c) %bootstrap-mes
>>>
>>> (4) Berlin should start rebuilding 'core-updates'.
>>>
>>> If desired, steps (3) and (4) could come before (2) if someone
>>> temporarily uploads the new binaries somewhere else, and adjusts
>>> '%bootstrap-base-urls' accordingly.  The key is for the hashes and file
>>> names to match what we've agreed on here, as I listed in (2) above.
>>>
>>> What do you think?
>>
>> Thank you for the excellent summary.  I can look into adjusting the bash
>> fix for 5.0, and updating the bootstrap binary URLs and hashes.  I will
>> do this in a 'core-updates-next' branch.  I would also like to merge
>> wip-binaries into it as a final step, unless someone has objections.
>>
>> Ludovic should be back in a couple of days and can hopefully take care
>> of the uploads.
>
> I haven’t quite caught up yet, but I trust you and I can upload the
> files that Mark mentions above to ftp.gnu.org this time (Ricardo should
> also be able to upload them, if needed.)
>
> How can I reproduce them or fetch them?

You can reproduce them with the following command from a git checkout at
commit 9e6256ba0f32ab12d61c914a3fed879dac881762, which is the tip of the
'wip-binaries' branch, based on recent 'master':

  ./pre-inst-env guix build --system=i686-linux bootstrap-tarballs

--8<---------------cut here---------------start------------->8---
mhw@jojen ~/guix-wip-binaries$ git describe
v1.0.1-2479-g9e6256ba0f
mhw@jojen ~/guix-wip-binaries$ ./pre-inst-env guix build --system=i686-linux bootstrap-tarballs
/gnu/store/rdwyr8mh7dvhfkb5g4cws6q40hp23rbi-bootstrap-tarballs-0
mhw@jojen ~/guix-wip-binaries$ cd /gnu/store/rdwyr8mh7dvhfkb5g4cws6q40hp23rbi-bootstrap-tarballs-0
mhw@jojen /gnu/store/rdwyr8mh7dvhfkb5g4cws6q40hp23rbi-bootstrap-tarballs-0$ sha256sum *
3e50c070a100b6bcf84c4bf5c868f9cd0a9fd1570f5d82fbfb78f8411959091b  guile-static-stripped-2.2.4-i686-linux.tar.xz
1acd8f83e27d2fac311a5ca78e9bf11a9a1638b82469870d5c854c4e7afaa26a  linux-libre-headers-stripped-4.14.67-i686-linux.tar.xz
021543d9bb6af55f39e68d69692e3cb74646ced2cad0bb9ac0047ef81e9d7330  mescc-tools-static-stripped-0.5.2-i686-linux.tar.xz
fb32090071b39fc804fb9a7fba96f0bc5eb844a0efd268fb24c42e6bfa959de0  mes-minimal-stripped-0.19-i686-linux.tar.xz
c80cdd17b0a24eebdd75570ff72c4ec06e129bd702ac008186b57f6301c448e7  static-binaries-0-i686-linux.tar.xz
--8<---------------cut here---------------end--------------->8---

Do you get the same results?

To match what 'core-updates-next' expects, it would be good to upload
the files above, along with digital signatures, to the following new
directory:

  https://alpha.gnu.org/gnu/guix/bootstrap/i686-linux/20190815/

>> Ricardo: can you instruct Cuirass to add a reduced jobset for
>> 'core-updates-next', that only builds builds the "core" package subset?
>
> Should be ready now:
>
>   https://ci.guix.gnu.org/jobset/core-updates-next

Thank you.

> However, evaluation fails with:
>
> Backtrace:
> In guix/packages.scm:
>   1188:25 19 (bag->derivation #<store-connection 256.99 2860c60> #<?> ?)
> In srfi/srfi-1.scm:
>    592:29 18 (map1 (("source" #<origin ("http://fossies.org/lin?>) ?))
>    592:17 17 (map1 (("bash" #<package bash-minimal@4.4.23 gnu/p?>) ?))
> In guix/packages.scm:
>    979:16 16 (expand-input #<store-connection 256.99 2860c60> #<pac?> ?)
>    936:16 15 (cache! #<weak-table 2/113> #<package bash-minimal@4.4?> ?)
>   1255:22 14 (thunk)
>   1188:25 13 (bag->derivation #<store-connection 256.99 2860c60> #<?> ?)
> In srfi/srfi-1.scm:
>    592:29 12 (map1 (("source" #<origin "mirror://gnu/bash/bash-?>) ?))
>    592:17 11 (map1 (("gcc" #<package gcc@5.5.0 gnu/packages/boo?>) ?))
> In guix/packages.scm:
>    979:16 10 (expand-input #<store-connection 256.99 2860c60> #<pac?> ?)
>    936:16  9 (cache! #<weak-table 2/113> #<package gcc@5.5.0 gnu/pa?> ?)
>   1255:22  8 (thunk)
>   1188:25  7 (bag->derivation #<store-connection 256.99 2860c60> #<?> ?)
> In srfi/srfi-1.scm:
>    592:29  6 (map1 (("source" #<origin "mirror://gnu/gcc/gcc-5.?>) ?))
>    592:17  5 (map1 (("texinfo" #<package texinfo@6.5 gnu/packag?>) ?))
> In guix/packages.scm:
>    979:16  4 (expand-input #<store-connection 256.99 2860c60> #<pac?> ?)
>    936:16  3 (cache! #<weak-table 2/113> #<package texinfo@6.5 gnu/?> ?)
>   1255:22  2 (thunk)
>   1188:25  1 Exception thrown while printing backtrace:
> Throw to key `srfi-34' with args `(#<condition &message [message: "texinfo-perl-compat.patch: patch not found"] 56ac3c0>)'.
>
> srfi/srfi-1.scm:592:17: In procedure map1:
> Throw to key `srfi-34' with args `(#<condition &message [message: "texinfo-perl-compat.patch: patch not found"] 51bb5c0>)'.
>
> Am I missing something?

The string "texinfo-perl-compat" does not occur in the current
'core-updates-next' branch on Savannah, which is at commit
82eaac49ac983f28768d6623d802f41cbd7f779b.

However, that file name _was_ present in an older version of
'core-updates-next', before it was deleted on Savannah at some time in
the past.  I know this because I checked out 'core-updates-next' from
another one of my computers, and found that it was actually at commit
89e7f90d0b40bc4f15f902cc3b82c3effa87dd02 from last November.  I ran "git
fetch" and "git reset --hard origin/core-updates-next" to fix it, but
maybe there's a better way.

How is this kind of issue normally dealt with?  Is there a git cache in
Cuirass that can be cleaned?

      Thanks,
        Mark

bug#36747: Official MesCC bootstrap binaries differ from my locally built ones

[Mark H Weaver]

Earlier, I wrote:

> I pushed those two commits to 'core-updates-next', and am currently
> building out that branch on my X200.  So far I've successfully built the
> core packages and 'hello', and am now continuing on to build the rest of
> my Guix system.

FYI, on 'core-updates-next', I've built the full 'emacs' package (with
GTK), git, openssh, gnupg, evince, gnome-terminal, and hundreds of other
packages.  I'm currently focused on building the 'gnome' package.

      Mark

bug#36747: Official MesCC bootstrap binaries differ from my locally built ones

[Ludovic Courtès]

Hi Mark,

Mark H Weaver <mhw@netris.org> skribis:

> You can reproduce them with the following command from a git checkout at
> commit 9e6256ba0f32ab12d61c914a3fed879dac881762, which is the tip of the
> 'wip-binaries' branch, based on recent 'master':
>
>   ./pre-inst-env guix build --system=i686-linux bootstrap-tarballs

OK, I’ll give it a try and report back, probably end of next week.

>> srfi/srfi-1.scm:592:17: In procedure map1:
>> Throw to key `srfi-34' with args `(#<condition &message [message: "texinfo-perl-compat.patch: patch not found"] 51bb5c0>)'.
>>
>> Am I missing something?
>
> The string "texinfo-perl-compat" does not occur in the current
> 'core-updates-next' branch on Savannah, which is at commit
> 82eaac49ac983f28768d6623d802f41cbd7f779b.

Oh, I had misconfigured the ‘core-updates-next’ jobset: its
‘load_path_input’ was '("core-updates-next"), which led the host Guix to
lookup bits of the target Guix, hence the confusion.

I fixed it by setting it to the empty list as it should:

  update specifications set load_path_inputs = '()' where name = 'core-updates-next';

(The specs can be seen at <https://ci.guix.gnu.org/specifications>.)

It’s currently being evaluated:

  https://ci.guix.gnu.org/jobset/core-updates-next

Ludo’.

bug#36747: Official MesCC bootstrap binaries differ from my locally built ones

[Mark H Weaver]

Hi Ludovic,

Ludovic Courtès <ludo@gnu.org> wrote:
> It’s currently being evaluated:
>
>   https://ci.guix.gnu.org/jobset/core-updates-next

Thanks, although I guess all of the builds will fail, unless someone
manually added the new bootstrap tarballs to Berlin's store, or uploaded
them to one of the URLs in %bootstrap-base-urls.

      Mark

bug#36747: Official MesCC bootstrap binaries differ from my locally built ones

[Ludovic Courtès]

Hi,

Mark H Weaver <mhw@netris.org> skribis:

> Ludovic Courtès <ludo@gnu.org> wrote:
>> It’s currently being evaluated:
>>
>>   https://ci.guix.gnu.org/jobset/core-updates-next
>
> Thanks, although I guess all of the builds will fail, unless someone
> manually added the new bootstrap tarballs to Berlin's store, or uploaded
> them to one of the URLs in %bootstrap-base-urls.

Indeed, it’s failing for that reason now, I hadn’t realized.

To be continued…

Ludo’.

bug#36747: Official MesCC bootstrap binaries differ from my locally built ones

[Mark H Weaver]

Hi Ludovic,

Ludovic Courtès <ludo@gnu.org> writes:

> Mark H Weaver <mhw@netris.org> skribis:
>
>> Ludovic Courtès <ludo@gnu.org> wrote:
>>> It’s currently being evaluated:
>>>
>>>   https://ci.guix.gnu.org/jobset/core-updates-next
>>
>> Thanks, although I guess all of the builds will fail, unless someone
>> manually added the new bootstrap tarballs to Berlin's store, or uploaded
>> them to one of the URLs in %bootstrap-base-urls.
>
> Indeed, it’s failing for that reason now, I hadn’t realized.
>
> To be continued…

In the meantime, I've rebuilt my GNOME-based Guix system, and most of my
user profile, based on 'core-updates-next'.  I'm typing this message
from that system, and am currently working on building the chain of Rust
compilers on the way to IceCat.

It would be good to get Berlin started on building the new branch soon.

       Mark

bug#36747: Official MesCC bootstrap binaries differ from my locally built ones

[Mark H Weaver]

FYI, I've fully switched my entire GNOME-based Guix system to
'core-updates-next' now.  Of the packages that I use, only three failed
to build: diffoscope, openimageio (needed by blender), and simple-scan.

       Mark

bug#36747: Official MesCC bootstrap binaries differ from my locally built ones

[Ludovic Courtès]

[-- Attachment #1: Type: text/plain, Size: 3227 bytes --]

Hi Mark,

Mark H Weaver <mhw@netris.org> skribis:

> You can reproduce them with the following command from a git checkout at
> commit 9e6256ba0f32ab12d61c914a3fed879dac881762, which is the tip of the
> 'wip-binaries' branch, based on recent 'master':
>
>   ./pre-inst-env guix build --system=i686-linux bootstrap-tarballs
>
> mhw@jojen ~/guix-wip-binaries$ git describe
> v1.0.1-2479-g9e6256ba0f
> mhw@jojen ~/guix-wip-binaries$ ./pre-inst-env guix build --system=i686-linux bootstrap-tarballs
> /gnu/store/rdwyr8mh7dvhfkb5g4cws6q40hp23rbi-bootstrap-tarballs-0
> mhw@jojen ~/guix-wip-binaries$ cd /gnu/store/rdwyr8mh7dvhfkb5g4cws6q40hp23rbi-bootstrap-tarballs-0
> mhw@jojen /gnu/store/rdwyr8mh7dvhfkb5g4cws6q40hp23rbi-bootstrap-tarballs-0$ sha256sum *
> 3e50c070a100b6bcf84c4bf5c868f9cd0a9fd1570f5d82fbfb78f8411959091b  guile-static-stripped-2.2.4-i686-linux.tar.xz
> 1acd8f83e27d2fac311a5ca78e9bf11a9a1638b82469870d5c854c4e7afaa26a  linux-libre-headers-stripped-4.14.67-i686-linux.tar.xz
> 021543d9bb6af55f39e68d69692e3cb74646ced2cad0bb9ac0047ef81e9d7330  mescc-tools-static-stripped-0.5.2-i686-linux.tar.xz
> fb32090071b39fc804fb9a7fba96f0bc5eb844a0efd268fb24c42e6bfa959de0  mes-minimal-stripped-0.19-i686-linux.tar.xz
> c80cdd17b0a24eebdd75570ff72c4ec06e129bd702ac008186b57f6301c448e7  static-binaries-0-i686-linux.tar.xz
>
> Do you get the same results?

I built it on bayfront and got the exact same result:

--8<---------------cut here---------------start------------->8---
ludo@bayfront ~$ ./wip-binaries/bin/guix describe
Generation 1    Aug 18 2019 12:04:54    (current)
  guix 9e6256b
    repository URL: https://git.savannah.gnu.org/git/guix.git
    branch: wip-binaries
    commit: 9e6256ba0f32ab12d61c914a3fed879dac881762
ludo@bayfront ~$ ./wip-binaries/bin/guix build -s i686-linux bootstrap-tarballs
/gnu/store/rdwyr8mh7dvhfkb5g4cws6q40hp23rbi-bootstrap-tarballs-0
ludo@bayfront ~$ (cd /gnu/store/rdwyr8mh7dvhfkb5g4cws6q40hp23rbi-bootstrap-tarballs-0 ; sha256sum *)
3e50c070a100b6bcf84c4bf5c868f9cd0a9fd1570f5d82fbfb78f8411959091b  guile-static-stripped-2.2.4-i686-linux.tar.xz
1acd8f83e27d2fac311a5ca78e9bf11a9a1638b82469870d5c854c4e7afaa26a  linux-libre-headers-stripped-4.14.67-i686-linux.tar.xz
021543d9bb6af55f39e68d69692e3cb74646ced2cad0bb9ac0047ef81e9d7330  mescc-tools-static-stripped-0.5.2-i686-linux.tar.xz
fb32090071b39fc804fb9a7fba96f0bc5eb844a0efd268fb24c42e6bfa959de0  mes-minimal-stripped-0.19-i686-linux.tar.xz
c80cdd17b0a24eebdd75570ff72c4ec06e129bd702ac008186b57f6301c448e7  static-binaries-0-i686-linux.tar.xz
--8<---------------cut here---------------end--------------->8---

(I’m actually surprised Guile is 100% reproducible; ISTR there were
still issues with gensyms in .go files, but maybe I’m wrong.)

So, green light, right?

> To match what 'core-updates-next' expects, it would be good to upload
> the files above, along with digital signatures, to the following new
> directory:
>
>   https://alpha.gnu.org/gnu/guix/bootstrap/i686-linux/20190815/

Unless you disagree, I’ll upload these to ftp.gnu.org (not
alpha.gnu.org, but same directory as you wrote) tomorrow.

Thank you, and apologies for the delay!

Ludo’.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

bug#36747: Official MesCC bootstrap binaries differ from my locally built ones

[Mark H Weaver]

Hi Ludovic,

Ludovic Courtès <ludo@gnu.org> writes:

> Mark H Weaver <mhw@netris.org> skribis:
>
>> You can reproduce them with the following command from a git checkout at
>> commit 9e6256ba0f32ab12d61c914a3fed879dac881762, which is the tip of the
>> 'wip-binaries' branch, based on recent 'master':
>>
>>   ./pre-inst-env guix build --system=i686-linux bootstrap-tarballs
>>
>> mhw@jojen ~/guix-wip-binaries$ git describe
>> v1.0.1-2479-g9e6256ba0f
>> mhw@jojen ~/guix-wip-binaries$ ./pre-inst-env guix build --system=i686-linux bootstrap-tarballs
>> /gnu/store/rdwyr8mh7dvhfkb5g4cws6q40hp23rbi-bootstrap-tarballs-0
>> mhw@jojen ~/guix-wip-binaries$ cd /gnu/store/rdwyr8mh7dvhfkb5g4cws6q40hp23rbi-bootstrap-tarballs-0
>> mhw@jojen /gnu/store/rdwyr8mh7dvhfkb5g4cws6q40hp23rbi-bootstrap-tarballs-0$ sha256sum *
>> 3e50c070a100b6bcf84c4bf5c868f9cd0a9fd1570f5d82fbfb78f8411959091b  guile-static-stripped-2.2.4-i686-linux.tar.xz
>> 1acd8f83e27d2fac311a5ca78e9bf11a9a1638b82469870d5c854c4e7afaa26a  linux-libre-headers-stripped-4.14.67-i686-linux.tar.xz
>> 021543d9bb6af55f39e68d69692e3cb74646ced2cad0bb9ac0047ef81e9d7330  mescc-tools-static-stripped-0.5.2-i686-linux.tar.xz
>> fb32090071b39fc804fb9a7fba96f0bc5eb844a0efd268fb24c42e6bfa959de0  mes-minimal-stripped-0.19-i686-linux.tar.xz
>> c80cdd17b0a24eebdd75570ff72c4ec06e129bd702ac008186b57f6301c448e7  static-binaries-0-i686-linux.tar.xz
>>
>> Do you get the same results?
>
> I built it on bayfront and got the exact same result:

I'm glad to hear it!  Marius and Janneke got these exact results as
well, albeit at a different commit which should be equivalent.

> (I’m actually surprised Guile is 100% reproducible; ISTR there were
> still issues with gensyms in .go files, but maybe I’m wrong.)

It's apparently not reproducible unless built sequentially.  I did some
preliminary investigation, and my guess is that the gensyms produced by
Guile's compiler sometimes depends on whether dependent modules were
previously compiled or not.

> So, green light, right?

Yes!

>> To match what 'core-updates-next' expects, it would be good to upload
>> the files above, along with digital signatures, to the following new
>> directory:
>>
>>   https://alpha.gnu.org/gnu/guix/bootstrap/i686-linux/20190815/
>
> Unless you disagree, I’ll upload these to ftp.gnu.org (not
> alpha.gnu.org, but same directory as you wrote) tomorrow.

That's fine, although I guess %bootstrap-base-urls will need to be
extended to include the new base URL.

    Thank you!
       Mark

bug#36747: Official MesCC bootstrap binaries differ from my locally built ones

[Ludovic Courtès]

Hello,

Mark H Weaver <mhw@netris.org> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>> Mark H Weaver <mhw@netris.org> skribis:
>>
>>> You can reproduce them with the following command from a git checkout at
>>> commit 9e6256ba0f32ab12d61c914a3fed879dac881762, which is the tip of the
>>> 'wip-binaries' branch, based on recent 'master':
>>>
>>>   ./pre-inst-env guix build --system=i686-linux bootstrap-tarballs
>>>
>>> mhw@jojen ~/guix-wip-binaries$ git describe
>>> v1.0.1-2479-g9e6256ba0f
>>> mhw@jojen ~/guix-wip-binaries$ ./pre-inst-env guix build --system=i686-linux bootstrap-tarballs
>>> /gnu/store/rdwyr8mh7dvhfkb5g4cws6q40hp23rbi-bootstrap-tarballs-0
>>> mhw@jojen ~/guix-wip-binaries$ cd /gnu/store/rdwyr8mh7dvhfkb5g4cws6q40hp23rbi-bootstrap-tarballs-0
>>> mhw@jojen /gnu/store/rdwyr8mh7dvhfkb5g4cws6q40hp23rbi-bootstrap-tarballs-0$ sha256sum *
>>> 3e50c070a100b6bcf84c4bf5c868f9cd0a9fd1570f5d82fbfb78f8411959091b  guile-static-stripped-2.2.4-i686-linux.tar.xz
>>> 1acd8f83e27d2fac311a5ca78e9bf11a9a1638b82469870d5c854c4e7afaa26a  linux-libre-headers-stripped-4.14.67-i686-linux.tar.xz
>>> 021543d9bb6af55f39e68d69692e3cb74646ced2cad0bb9ac0047ef81e9d7330  mescc-tools-static-stripped-0.5.2-i686-linux.tar.xz
>>> fb32090071b39fc804fb9a7fba96f0bc5eb844a0efd268fb24c42e6bfa959de0  mes-minimal-stripped-0.19-i686-linux.tar.xz
>>> c80cdd17b0a24eebdd75570ff72c4ec06e129bd702ac008186b57f6301c448e7  static-binaries-0-i686-linux.tar.xz
>>>
>>> Do you get the same results?
>>
>> I built it on bayfront and got the exact same result:
>
> I'm glad to hear it!  Marius and Janneke got these exact results as
> well, albeit at a different commit which should be equivalent.

Great.

>> (I’m actually surprised Guile is 100% reproducible; ISTR there were
>> still issues with gensyms in .go files, but maybe I’m wrong.)
>
> It's apparently not reproducible unless built sequentially.  I did some
> preliminary investigation, and my guess is that the gensyms produced by
> Guile's compiler sometimes depends on whether dependent modules were
> previously compiled or not.

I see.

>> So, green light, right?
>
> Yes!
>
>>> To match what 'core-updates-next' expects, it would be good to upload
>>> the files above, along with digital signatures, to the following new
>>> directory:
>>>
>>>   https://alpha.gnu.org/gnu/guix/bootstrap/i686-linux/20190815/
>>
>> Unless you disagree, I’ll upload these to ftp.gnu.org (not
>> alpha.gnu.org, but same directory as you wrote) tomorrow.
>
> That's fine, although I guess %bootstrap-base-urls will need to be
> extended to include the new base URL.

Uploaded to
<https://ftp.gnu.org/gnu/guix/bootstrap/i686-linux/20190815/>.  I
adjusted ‘%bootstrap-base-urls’ and the branch is now being evaluated
for real:

  https://ci.guix.gnu.org/jobset/core-updates-next

Thanks everyone for verifying and “fixing” these bootstrap binaries, and
apologies for delaying the process!

Ludo’.

bug#36747: Official MesCC bootstrap binaries differ from my locally built ones

[Ludovic Courtès]

Hello,

Marius Bakke <mbakke@fastmail.com> skribis:

> Mark H Weaver <mhw@netris.org> writes:

[...]

>> I think what needs to be done is the following:
>>
>> (1) commit 78ced7975b0665e810834391d826c9f0ef7277e1 on 'wip-binaries'
>>     should be reverted, to downgrade mescc-tools to the 0.5.2 release.
>>
>> (2) The 'wip-binaries' tarballs should be uploaded to a new subdirectory
>>     of <https://alpha.gnu.org/gnu/guix/bootstrap/i686-linux/>, along
>>     with digital signatures, of course.  I'm talking about these in
>>     particular:
>>
>>     3e50c070a100b6bcf84c4bf5c868f9cd0a9fd1570f5d82fbfb78f8411959091b  guile-static-stripped-2.2.4-i686-linux.tar.xz
>>     1acd8f83e27d2fac311a5ca78e9bf11a9a1638b82469870d5c854c4e7afaa26a  linux-libre-headers-stripped-4.14.67-i686-linux.tar.xz
>>     021543d9bb6af55f39e68d69692e3cb74646ced2cad0bb9ac0047ef81e9d7330  mescc-tools-static-stripped-0.5.2-i686-linux.tar.xz
>>     fb32090071b39fc804fb9a7fba96f0bc5eb844a0efd268fb24c42e6bfa959de0  mes-minimal-stripped-0.19-i686-linux.tar.xz
>>     c80cdd17b0a24eebdd75570ff72c4ec06e129bd702ac008186b57f6301c448e7  static-binaries-0-i686-linux.tar.xz
>>
>> (3) The following bootstrap packages in 'core-updates' bootstrap.scm
>>     should be updated to use the new binaries above:
>>
>>      (a) %bootstrap-linux-libre-headers
>>      (b) %bootstrap-mescc-tools
>>      (c) %bootstrap-mes
>>
>> (4) Berlin should start rebuilding 'core-updates'.
>>
>> If desired, steps (3) and (4) could come before (2) if someone
>> temporarily uploads the new binaries somewhere else, and adjusts
>> '%bootstrap-base-urls' accordingly.  The key is for the hashes and file
>> names to match what we've agreed on here, as I listed in (2) above.
>>
>> What do you think?
>
> Thank you for the excellent summary.  I can look into adjusting the bash
> fix for 5.0, and updating the bootstrap binary URLs and hashes.  I will
> do this in a 'core-updates-next' branch.  I would also like to merge
> wip-binaries into it as a final step, unless someone has objections.

I don’t think we explicitly discussed it, but my assumption is that
we’re delaying merging of ‘core-updates’ into ‘master’ until
‘core-updates-next’ becomes ‘core-updates’.  Is this what you had in
mind?  (I’m asking because ‘core-updates’ was almost entirely built
IIRC.)

Also, what’s the next step for ‘wip-binaries’?

Thanks,
Ludo’.

bug#36747: Official MesCC bootstrap binaries differ from my locally built ones

[Mark H Weaver]

Hi Ludovic,

Ludovic Courtès <ludo@gnu.org> wrote:
> I don’t think we explicitly discussed it, but my assumption is that
> we’re delaying merging of ‘core-updates’ into ‘master’ until
> ‘core-updates-next’ becomes ‘core-updates’.  Is this what you had in
> mind?  (I’m asking because ‘core-updates’ was almost entirely built
> IIRC.)

My preference would be to merge 'core-updates-next' into 'core-updates',
or equivalently, to apply the following 3 commits to 'core-updates':

--8<---------------cut here---------------start------------->8---
commit d4bc93abe59e8ffcb8304050c05e727fe0230651
Author: Mark H Weaver <mhw@netris.org>
Date:   Thu Aug 15 15:39:30 2019 -0400

  gnu: bootstrap: Update to the 20190815 bootstrap binaries.
  
  * gnu/packages/bootstrap.scm (%bootstrap-linux-libre-headers): Update the
  download URL.
  (%bootstrap-mescc-tools, %bootstrap-mes): Update the download URL and hash.

commit 82eaac49ac983f28768d6623d802f41cbd7f779b
Author: Mark H Weaver <mhw@netris.org>
Date:   Thu Aug 15 16:44:36 2019 -0400

  gnu: bash: Unconditionally configure PGRP_PIPE for *-linux systems.
  
  * gnu/packages/patches/bash-linux-pgrp-pipe.patch: New file.
  * gnu/local.mk (dist_patch_DATA): Add it.
  * gnu/packages/bash.scm (bash)[source]: Add the patch.

commit 47fcdfac44c5bf236299679781133468be6f0207
Author: Ludovic Courtès <ludo@gnu.org>
Date:   Thu Aug 22 11:47:27 2019 +0200

  gnu: bootstrap: Add ftp.gnu.org to '%bootstrap-base-urls'.
  
  * gnu/packages/bootstrap.scm (%bootstrap-base-urls): Add
  ftp.gnu.org/gnu/guix/bootstrap.
--8<---------------cut here---------------end--------------->8---

These commits are the only difference between 'core-updates' and
'core-updates-next'.

I'm confident that this will make no difference to the set of packages
that build successfully, modulo non-determistic build failures.  The
only additional time it should require is the time needed for Berlin to
rebuild the branch.

Otherwise, 'core-updates-next' seems to be in good shape, and possibly
almost ready to merge into 'master'.  I admit that this assessment is
based solely on the fact that I'm currently using it on my own machine,
and it works well.  Without Hydra's interface for comparing evaluations,
I'm mostly blind to the status of the branch beyond of the set of
packages I use myself.

In my opinion, 'core-updates' in its current form should never be merged
into 'master', because it's built upon non-deterministic bootstrap
tarballs that cannot be independently verified.

What do you think?

> Also, what’s the next step for ‘wip-binaries’?

Good question!  First, I think we should tag it with a name that
indicates that it was used to build the 20190815 bootstrap binaries.

Optionally, I would advocate merging 'wip-binaries' into 'master'.

What do you think?

      Thanks,
        Mark

bug#36747: Official MesCC bootstrap binaries differ from my locally built ones

[Ludovic Courtès]

Hi Mark,

Mark H Weaver <mhw@netris.org> skribis:

> Ludovic Courtès <ludo@gnu.org> wrote:
>> I don’t think we explicitly discussed it, but my assumption is that
>> we’re delaying merging of ‘core-updates’ into ‘master’ until
>> ‘core-updates-next’ becomes ‘core-updates’.  Is this what you had in
>> mind?  (I’m asking because ‘core-updates’ was almost entirely built
>> IIRC.)
>
> My preference would be to merge 'core-updates-next' into 'core-updates',
> or equivalently, to apply the following 3 commits to 'core-updates':
>
> commit d4bc93abe59e8ffcb8304050c05e727fe0230651
> Author: Mark H Weaver <mhw@netris.org>
> Date:   Thu Aug 15 15:39:30 2019 -0400
>
>   gnu: bootstrap: Update to the 20190815 bootstrap binaries.
>   
>   * gnu/packages/bootstrap.scm (%bootstrap-linux-libre-headers): Update the
>   download URL.
>   (%bootstrap-mescc-tools, %bootstrap-mes): Update the download URL and hash.
>
> commit 82eaac49ac983f28768d6623d802f41cbd7f779b
> Author: Mark H Weaver <mhw@netris.org>
> Date:   Thu Aug 15 16:44:36 2019 -0400
>
>   gnu: bash: Unconditionally configure PGRP_PIPE for *-linux systems.
>   
>   * gnu/packages/patches/bash-linux-pgrp-pipe.patch: New file.
>   * gnu/local.mk (dist_patch_DATA): Add it.
>   * gnu/packages/bash.scm (bash)[source]: Add the patch.
>
> commit 47fcdfac44c5bf236299679781133468be6f0207
> Author: Ludovic Courtès <ludo@gnu.org>
> Date:   Thu Aug 22 11:47:27 2019 +0200
>
>   gnu: bootstrap: Add ftp.gnu.org to '%bootstrap-base-urls'.
>   
>   * gnu/packages/bootstrap.scm (%bootstrap-base-urls): Add
>   ftp.gnu.org/gnu/guix/bootstrap.
>
> These commits are the only difference between 'core-updates' and
> 'core-updates-next'.

OK.  The Bash change means we’re rebuilding from scratch on
architectures, not just x86.  So I’ll probably ungraft my Ghostscript
fix (466ff55c72959ba1499ce3ec69f534b3038eb30b) while we’re at it.

> I'm confident that this will make no difference to the set of packages
> that build successfully, modulo non-determistic build failures.  The
> only additional time it should require is the time needed for Berlin to
> rebuild the branch.
>
> Otherwise, 'core-updates-next' seems to be in good shape, and possibly
> almost ready to merge into 'master'.  I admit that this assessment is
> based solely on the fact that I'm currently using it on my own machine,
> and it works well.  Without Hydra's interface for comparing evaluations,
> I'm mostly blind to the status of the branch beyond of the set of
> packages I use myself.

I find that ‘guix weather -c’ gives a rather good overview of the
situation, though it’s not equivalent to comparing with another
evaluation.

> In my opinion, 'core-updates' in its current form should never be merged
> into 'master', because it's built upon non-deterministic bootstrap
> tarballs that cannot be independently verified.
>
> What do you think?

That sounds good to me.  I think we should start real soon, then.
Marius?

>> Also, what’s the next step for ‘wip-binaries’?
>
> Good question!  First, I think we should tag it with a name that
> indicates that it was used to build the 20190815 bootstrap binaries.
>
> Optionally, I would advocate merging 'wip-binaries' into 'master'.

Fine with me!  Could you take care of tagging and merging?

Thanks,
Ludo’.

bug#36747: Official MesCC bootstrap binaries differ from my locally built ones

[Mark H Weaver]

Hi Ludovic,

Ludovic Courtès <ludo@gnu.org> writes:

> Mark H Weaver <mhw@netris.org> skribis:
>
>> Ludovic Courtès <ludo@gnu.org> wrote:
>>> I don’t think we explicitly discussed it, but my assumption is that
>>> we’re delaying merging of ‘core-updates’ into ‘master’ until
>>> ‘core-updates-next’ becomes ‘core-updates’.  Is this what you had in
>>> mind?  (I’m asking because ‘core-updates’ was almost entirely built
>>> IIRC.)
>>
>> My preference would be to merge 'core-updates-next' into 'core-updates',
>> or equivalently, to apply the following 3 commits to 'core-updates':
>>
>> commit d4bc93abe59e8ffcb8304050c05e727fe0230651
>> Author: Mark H Weaver <mhw@netris.org>
>> Date:   Thu Aug 15 15:39:30 2019 -0400
>>
>>   gnu: bootstrap: Update to the 20190815 bootstrap binaries.
>>   
>>   * gnu/packages/bootstrap.scm (%bootstrap-linux-libre-headers): Update the
>>   download URL.
>>   (%bootstrap-mescc-tools, %bootstrap-mes): Update the download URL and hash.
>>
>> commit 82eaac49ac983f28768d6623d802f41cbd7f779b
>> Author: Mark H Weaver <mhw@netris.org>
>> Date:   Thu Aug 15 16:44:36 2019 -0400
>>
>>   gnu: bash: Unconditionally configure PGRP_PIPE for *-linux systems.
>>   
>>   * gnu/packages/patches/bash-linux-pgrp-pipe.patch: New file.
>>   * gnu/local.mk (dist_patch_DATA): Add it.
>>   * gnu/packages/bash.scm (bash)[source]: Add the patch.
>>
>> commit 47fcdfac44c5bf236299679781133468be6f0207
>> Author: Ludovic Courtès <ludo@gnu.org>
>> Date:   Thu Aug 22 11:47:27 2019 +0200
>>
>>   gnu: bootstrap: Add ftp.gnu.org to '%bootstrap-base-urls'.
>>   
>>   * gnu/packages/bootstrap.scm (%bootstrap-base-urls): Add
>>   ftp.gnu.org/gnu/guix/bootstrap.
>>
>> These commits are the only difference between 'core-updates' and
>> 'core-updates-next'.
>
> OK.  The Bash change means we’re rebuilding from scratch on
> architectures, not just x86.  So I’ll probably ungraft my Ghostscript
> fix (466ff55c72959ba1499ce3ec69f534b3038eb30b) while we’re at it.

Hmm, good point.  Perhaps we should postpone the Bash fix until the next
core-updates cycle.  The problem was quite severe in bash-4.4, which
builds incorrectly on linux-5.0 or later, but the issue in bash-5.0 is
far less likely to cause problems in practice: it will build differently
on linux-2.3 or earlier.

What do you think?

>>> Also, what’s the next step for ‘wip-binaries’?
>>
>> Good question!  First, I think we should tag it with a name that
>> indicates that it was used to build the 20190815 bootstrap binaries.
>>
>> Optionally, I would advocate merging 'wip-binaries' into 'master'.
>
> Fine with me!  Could you take care of tagging and merging?

Sure, will do.

    Thanks,
      Mark

bug#36747: Official MesCC bootstrap binaries differ from my locally built ones

[Mark H Weaver]

Hi Ludovic,

Ludovic Courtès <ludo@gnu.org> writes:

> Mark H Weaver <mhw@netris.org> skribis:
>
>> Ludovic Courtès <ludo@gnu.org> wrote:
>>> Also, what’s the next step for ‘wip-binaries’?
>>
>> Good question!  First, I think we should tag it with a name that
>> indicates that it was used to build the 20190815 bootstrap binaries.
>>
>> Optionally, I would advocate merging 'wip-binaries' into 'master'.
>
> Fine with me!  Could you take care of tagging and merging?

I tagged 'wip-binaries' and merged it into master, but there's an
undesirable side effect.  After the merge, "git describe" from 'master'
now returns "bootstrap-20190815-222-g32e18e9b94".

        Mark

bug#36747: Official MesCC bootstrap binaries differ from my locally built ones

[Ludovic Courtès]

Hi Mark,

Mark H Weaver <mhw@netris.org> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>> Mark H Weaver <mhw@netris.org> skribis:

[...]

>>> commit 82eaac49ac983f28768d6623d802f41cbd7f779b
>>> Author: Mark H Weaver <mhw@netris.org>
>>> Date:   Thu Aug 15 16:44:36 2019 -0400
>>>
>>>   gnu: bash: Unconditionally configure PGRP_PIPE for *-linux systems.
>>>   
>>>   * gnu/packages/patches/bash-linux-pgrp-pipe.patch: New file.
>>>   * gnu/local.mk (dist_patch_DATA): Add it.
>>>   * gnu/packages/bash.scm (bash)[source]: Add the patch.

[...]

>> OK.  The Bash change means we’re rebuilding from scratch on
>> architectures, not just x86.  So I’ll probably ungraft my Ghostscript
>> fix (466ff55c72959ba1499ce3ec69f534b3038eb30b) while we’re at it.
>
> Hmm, good point.  Perhaps we should postpone the Bash fix until the next
> core-updates cycle.  The problem was quite severe in bash-4.4, which
> builds incorrectly on linux-5.0 or later, but the issue in bash-5.0 is
> far less likely to cause problems in practice: it will build differently
> on linux-2.3 or earlier.
>
> What do you think?

Your call: if you think this Bash fix can be delayed without causing
problems, then please revert it and we’ll apply it on the next cycle.
That would allow us to merge ‘core-updates’ more quickly for sure!

Thanks,
Ludo’.

bug#36747: Official MesCC bootstrap binaries differ from my locally built ones

[Ludovic Courtès]

Mark H Weaver <mhw@netris.org> skribis:

> I tagged 'wip-binaries' and merged it into master, but there's an
> undesirable side effect.  After the merge, "git describe" from 'master'
> now returns "bootstrap-20190815-222-g32e18e9b94".

I think that’s OK.

Ideally, we’d have mentioned the commit used to build the binaries in
the commit that actually adds those binaries to boostrap.scm.  Maybe
that can still be done with a Git graft?

Thanks,
Ludo’.

bug#36747: Official MesCC bootstrap binaries differ from my locally built ones

[Mark H Weaver]

Hi Ludovic,

Ludovic Courtès <ludo@gnu.org> wrote:

> Mark H Weaver <mhw@netris.org> skribis:
>
>> Hmm, good point.  Perhaps we should postpone the Bash fix until the next
>> core-updates cycle. [...]
>
> Your call: if you think this Bash fix can be delayed without causing
> problems, then please revert it and we’ll apply it on the next cycle.
> That would allow us to merge ‘core-updates’ more quickly for sure!

Okay, let's delay the bash fix until the next cycle.

>> I tagged 'wip-binaries' and merged it into master, but there's an
>> undesirable side effect.  After the merge, "git describe" from 'master'
>> now returns "bootstrap-20190815-222-g32e18e9b94".
>
> I think that’s OK.
>
> Ideally, we’d have mentioned the commit used to build the binaries in
> the commit that actually adds those binaries to boostrap.scm.

Agreed, that was an important omission on my part.

> Maybe that can still be done with a Git graft?

I think it's easier than that.  I personally see no need to preserve the
branch 'core-updates-next', which has a different role than usual and is
arguably misnamed.  It's only 3 commits.  Of those 3, one has a faulty
commit log, and another should be postponed.  I could simply push the
revised commits to 'core-updates' directly.

What do you think?

      Mark

bug#36747: Official MesCC bootstrap binaries differ from my locally built ones

[Ludovic Courtès]

Hello,

Mark H Weaver <mhw@netris.org> skribis:

> Ludovic Courtès <ludo@gnu.org> wrote:
>
>> Mark H Weaver <mhw@netris.org> skribis:
>>
>>> Hmm, good point.  Perhaps we should postpone the Bash fix until the next
>>> core-updates cycle. [...]
>>
>> Your call: if you think this Bash fix can be delayed without causing
>> problems, then please revert it and we’ll apply it on the next cycle.
>> That would allow us to merge ‘core-updates’ more quickly for sure!
>
> Okay, let's delay the bash fix until the next cycle.

OK.

>>> I tagged 'wip-binaries' and merged it into master, but there's an
>>> undesirable side effect.  After the merge, "git describe" from 'master'
>>> now returns "bootstrap-20190815-222-g32e18e9b94".
>>
>> I think that’s OK.
>>
>> Ideally, we’d have mentioned the commit used to build the binaries in
>> the commit that actually adds those binaries to boostrap.scm.
>
> Agreed, that was an important omission on my part.
>
>> Maybe that can still be done with a Git graft?
>
> I think it's easier than that.  I personally see no need to preserve the
> branch 'core-updates-next', which has a different role than usual and is
> arguably misnamed.  It's only 3 commits.  Of those 3, one has a faulty
> commit log, and another should be postponed.  I could simply push the
> revised commits to 'core-updates' directly.

That sounds good me, please do!

Thank you,
Ludo’.

bug#36747: Official MesCC bootstrap binaries differ from my locally built ones

[Mark H Weaver]

Ludovic Courtès <ludo@gnu.org> writes:

> Mark H Weaver <mhw@netris.org> skribis:
>
>> I could simply push the revised commits to 'core-updates' directly.
>
> That sounds good me, please do!

Done.  I'm closing this bug now, but feel free to reopen if there are
remaining issues that I've overlooked.

     Thanks!
       Mark

bug#36747: Official MesCC bootstrap binaries differ from my locally built ones

[Mark H Weaver]

Hi Ludovic,

I pushed the revised commits to 'core-updates', but something seems to
have gone wrong with the new evaluation on Berlin:

  https://ci.guix.gnu.org/jobset/core-updates-core-updates
  https://ci.guix.gnu.org/eval/7008

The first URL above shows a big "X" in the "Success" column for
evaluation 7008, which corresponds to the new commits I just pushed, to
switch to the new bootstrap tarballs.  The second URL above returns "500
Internal Server Error".

Is there a way to find out what went wrong?

       Mark

bug#36747: Official MesCC bootstrap binaries differ from my locally built ones

[Ludovic Courtès]

Hi,

Mark H Weaver <mhw@netris.org> skribis:

> I pushed the revised commits to 'core-updates', but something seems to
> have gone wrong with the new evaluation on Berlin:
>
>   https://ci.guix.gnu.org/jobset/core-updates-core-updates
>   https://ci.guix.gnu.org/eval/7008
>
> The first URL above shows a big "X" in the "Success" column for
> evaluation 7008, which corresponds to the new commits I just pushed, to
> switch to the new bootstrap tarballs.

We had a Bison build failure:

  https://ci.guix.gnu.org/log/4rvzs59q3smm4kwyfnf7m58a48rql0fs-bison-3.4.1

Excerpt:

--8<---------------cut here---------------start------------->8---
make[1]: Entering directory '/tmp/guix-build-bison-3.4.1.drv-0/bison-3.4.1'
make[1]: Entering directory '/tmp/guix-build-bison-3.4.1.drv-0/bison-3.4.1'
rm -f examples/c/reccalc/scan.stamp examples/c/reccalc/scan.stamp.tmp
rm -f examples/c/reccalc/scan.stamp examples/c/reccalc/scan.stamp.tmp
/gnu/store/7fimyv3n4jn7nbyl5f5bzdhnm25qmk3m-bootstrap-binaries-0/bin/mkdir -p examples/c/reccalc
/gnu/store/7fimyv3n4jn7nbyl5f5bzdhnm25qmk3m-bootstrap-binaries-0/bin/mkdir -p examples/c/reccalc
touch examples/c/reccalc/scan.stamp.tmp
touch examples/c/reccalc/scan.stamp.tmp
: -oexamples/c/reccalc/scan.c --header-file=examples/c/reccalc/scan.h ./examples/c/reccalc/scan.l
: -oexamples/c/reccalc/scan.c --header-file=examples/c/reccalc/scan.h ./examples/c/reccalc/scan.l
mv examples/c/reccalc/scan.stamp.tmp examples/c/reccalc/scan.stamp
mv examples/c/reccalc/scan.stamp.tmp examples/c/reccalc/scan.stamp
make[1]: Leaving directory '/tmp/guix-build-bison-3.4.1.drv-0/bison-3.4.1'
mv: cannot stat 'examples/c/reccalc/scan.stamp.tmp': No such file or directory
make[1]: *** [Makefile:6855: examples/c/reccalc/scan.stamp] Error 1
make[1]: Leaving directory '/tmp/guix-build-bison-3.4.1.drv-0/bison-3.4.1'
make: *** [Makefile:6847: examples/c/reccalc/scan.h] Error 2
command "make" "-j" "8" "ARFLAGS=crD" "RANLIB=ranlib" "V=1" failed with status 2
builder for `/gnu/store/wwysm0mdkbvpyp3n4im5pfwcf2brc23p-bison-3.4.1.drv' failed with exit code 1
@ build-failed /gnu/store/wwysm0mdkbvpyp3n4im5pfwcf2brc23p-bison-3.4.1.drv - 1 builder for `/gnu/store/wwysm0mdkbvpyp3n4im5pfwcf2brc23p-bison-3.4.1.drv' failed with exit code 1
--8<---------------cut here---------------end--------------->8---

I’ve addressed it by a hack in c55fae452032aa4b1b63406983e9abdf70adc957.

> The second URL above returns "500 Internal Server Error".

Bah, that’s another thing in Cuirass that we kind of fixed in Git but we
still need to reconfigure I guess.  Ricardo, is that correct?

> Is there a way to find out what went wrong?

For evaluation failures, I simply browse /var/log/cuirass.log…  Until we
have something better, we should maybe just publish that file.

Thanks,
Ludo’.

bug#36747: Official MesCC bootstrap binaries differ from my locally built ones

[Ricardo Wurmus]

Ludovic Courtès <ludo@gnu.org> writes:

> Mark H Weaver <mhw@netris.org> skribis:
>
>> I pushed the revised commits to 'core-updates', but something seems to
>> have gone wrong with the new evaluation on Berlin:
>>
>>   https://ci.guix.gnu.org/jobset/core-updates-core-updates
>>   https://ci.guix.gnu.org/eval/7008
>>
>> The first URL above shows a big "X" in the "Success" column for
>> evaluation 7008, which corresponds to the new commits I just pushed, to
>> switch to the new bootstrap tarballs.
>
> We had a Bison build failure:
>
>   https://ci.guix.gnu.org/log/4rvzs59q3smm4kwyfnf7m58a48rql0fs-bison-3.4.1
>
> Excerpt:
>
> --8<---------------cut here---------------start------------->8---
> make[1]: Entering directory '/tmp/guix-build-bison-3.4.1.drv-0/bison-3.4.1'
> make[1]: Entering directory '/tmp/guix-build-bison-3.4.1.drv-0/bison-3.4.1'
> rm -f examples/c/reccalc/scan.stamp examples/c/reccalc/scan.stamp.tmp
> rm -f examples/c/reccalc/scan.stamp examples/c/reccalc/scan.stamp.tmp
> /gnu/store/7fimyv3n4jn7nbyl5f5bzdhnm25qmk3m-bootstrap-binaries-0/bin/mkdir -p examples/c/reccalc
> /gnu/store/7fimyv3n4jn7nbyl5f5bzdhnm25qmk3m-bootstrap-binaries-0/bin/mkdir -p examples/c/reccalc
> touch examples/c/reccalc/scan.stamp.tmp
> touch examples/c/reccalc/scan.stamp.tmp
> : -oexamples/c/reccalc/scan.c --header-file=examples/c/reccalc/scan.h ./examples/c/reccalc/scan.l
> : -oexamples/c/reccalc/scan.c --header-file=examples/c/reccalc/scan.h ./examples/c/reccalc/scan.l
> mv examples/c/reccalc/scan.stamp.tmp examples/c/reccalc/scan.stamp
> mv examples/c/reccalc/scan.stamp.tmp examples/c/reccalc/scan.stamp
> make[1]: Leaving directory '/tmp/guix-build-bison-3.4.1.drv-0/bison-3.4.1'
> mv: cannot stat 'examples/c/reccalc/scan.stamp.tmp': No such file or directory
> make[1]: *** [Makefile:6855: examples/c/reccalc/scan.stamp] Error 1
> make[1]: Leaving directory '/tmp/guix-build-bison-3.4.1.drv-0/bison-3.4.1'
> make: *** [Makefile:6847: examples/c/reccalc/scan.h] Error 2
> command "make" "-j" "8" "ARFLAGS=crD" "RANLIB=ranlib" "V=1" failed with status 2
> builder for `/gnu/store/wwysm0mdkbvpyp3n4im5pfwcf2brc23p-bison-3.4.1.drv' failed with exit code 1
> @ build-failed /gnu/store/wwysm0mdkbvpyp3n4im5pfwcf2brc23p-bison-3.4.1.drv - 1 builder for `/gnu/store/wwysm0mdkbvpyp3n4im5pfwcf2brc23p-bison-3.4.1.drv' failed with exit code 1
> --8<---------------cut here---------------end--------------->8---
>
> I’ve addressed it by a hack in c55fae452032aa4b1b63406983e9abdf70adc957.
>
>> The second URL above returns "500 Internal Server Error".
>
> Bah, that’s another thing in Cuirass that we kind of fixed in Git but we
> still need to reconfigure I guess.  Ricardo, is that correct?

We use a very slightly modified Cuirass at commit
6cf84a43bb6160e11ede96820a8bc563aa7461ef on berlin.

I confirm that visiting this URL still results in an error:

   https://ci.guix.gnu.org/eval/7008

(Looks like the cuirass-web service still writes to the same log file,
so I can’t actually see the message amidst all the build logs…)

--
Ricardo

bug#36747: Official MesCC bootstrap binaries differ from my locally built ones

[Ricardo Wurmus]

Ricardo Wurmus <rekado@elephly.net> writes:

> (Looks like the cuirass-web service still writes to the same log file,
> so I can’t actually see the message amidst all the build logs…)

It now logs to cuirass-web.log.

-- 
Ricardo

bug#36747: Official MesCC bootstrap binaries differ from my locally built ones

[Mark H Weaver]

Hi Ludovic and Ricardo,

Ludovic Courtès <ludo@gnu.org> writes:

> Mark H Weaver <mhw@netris.org> skribis:
>
>> I pushed the revised commits to 'core-updates', but something seems to
>> have gone wrong with the new evaluation on Berlin:
>>
>>   https://ci.guix.gnu.org/jobset/core-updates-core-updates
>>   https://ci.guix.gnu.org/eval/7008
>>
>> The first URL above shows a big "X" in the "Success" column for
>> evaluation 7008, which corresponds to the new commits I just pushed, to
>> switch to the new bootstrap tarballs.
>
> We had a Bison build failure:
>
>   https://ci.guix.gnu.org/log/4rvzs59q3smm4kwyfnf7m58a48rql0fs-bison-3.4.1
[...]
> I’ve addressed it by a hack in c55fae452032aa4b1b63406983e9abdf70adc957.

Thanks.  The next evaluation got further, but eventually failed.  Again,
there seems no way to get any details on what went wrong from the web
interface:

  https://ci.guix.gnu.org/jobset/core-updates-core-updates
  https://ci.guix.gnu.org/eval/7029

The second URL works this time, but it shows no results: 0 scheduled
builds, 0 succeeded builds, 0 failed builds, and it says "No elements
here."

Can you see what happened?

      Thanks,
        Mark

bug#36747: Official MesCC bootstrap binaries differ from my locally built ones

[Bengt Richter]

On +2019-08-27 11:38:31 +0200, Ludovic Courtès wrote:
> Hi Mark,
> 
> Mark H Weaver <mhw@netris.org> skribis:
> 
> > Ludovic Courtès <ludo@gnu.org> writes:
> >
> >> Mark H Weaver <mhw@netris.org> skribis:
> 
> [...]
> 
> >>> commit 82eaac49ac983f28768d6623d802f41cbd7f779b
> >>> Author: Mark H Weaver <mhw@netris.org>
> >>> Date:   Thu Aug 15 16:44:36 2019 -0400
> >>>
> >>>   gnu: bash: Unconditionally configure PGRP_PIPE for *-linux systems.
> >>>   
> >>>   * gnu/packages/patches/bash-linux-pgrp-pipe.patch: New file.
> >>>   * gnu/local.mk (dist_patch_DATA): Add it.
> >>>   * gnu/packages/bash.scm (bash)[source]: Add the patch.
> 
> [...]
> 
> >> OK.  The Bash change means we’re rebuilding from scratch on
> >> architectures, not just x86.  So I’ll probably ungraft my Ghostscript
> >> fix (466ff55c72959ba1499ce3ec69f534b3038eb30b) while we’re at it.
> >
> > Hmm, good point.  Perhaps we should postpone the Bash fix until the next
> > core-updates cycle.  The problem was quite severe in bash-4.4, which
> > builds incorrectly on linux-5.0 or later, but the issue in bash-5.0 is
> > far less likely to cause problems in practice: it will build differently
> > on linux-2.3 or earlier.
> >
> > What do you think?
> 
> Your call: if you think this Bash fix can be delayed without causing
> problems, then please revert it and we’ll apply it on the next cycle.
> That would allow us to merge ‘core-updates’ more quickly for sure!
> 
> Thanks,
> Ludo’.
> 
> 
> 

Hi,

(Just in case this might be relevant, sorry if not :)

I noticed that the guix-built version of bash is not position-independent,
and also differences in built-for versions, wondered why:

$ type bash which
bash is /home/bokr/.guix-profile/bin/bash
which is /home/bokr/.guix-profile/bin/which

$ which -a bash
/home/bokr/.guix-profile/bin/bash
/usr/bin/bash
$ 
$ which -a bash|xargs readlink -f
/gnu/store/qn1ax1fkj16x280m1rv7mcimfmn9l2pf-bash-4.4.23/bin/bash
/usr/bin/bash
$ 

$ which -a bash|xargs readlink -f|xargs file
/gnu/store/qn1ax1fkj16x280m1rv7mcimfmn9l2pf-bash-4.4.23/bin/bash:
    ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked,
               ^^^^^^^^^^^^^^ 
    interpreter /gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/lib/ld-linux-x86-64.so.2,
    for GNU/Linux 2.6.32, not stripped
                  ^^^^^^
/usr/bin/bash:
    ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked,
    	       ^^^^^^^^^^^^^^^^^^
    interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=21a51cb5f7d727370e4d8099d283d7cd20222571,
    for GNU/Linux 3.2.0, stripped
                  ^^^^^

If you substitute guile for bash in the above, it shows the same differences.

Could something need position-independence only under special circumstances
and silently give up if not repositionable, causing mystery errors?

Also, I am in the foreign (ArchLinux) host environment twilight zone
of mixed /usr vs ~/.guix-profile name searches and wonder if
there are hidden /usr dependencies baked statically into some /gnu/store executables
that are causing me problems.

exec is a bash built-in, and I suppose that is usually doesn't matter
if a guile script is launched via

    #!/usr/bin/bash
    exec guile ...

but I have a hunch that sometimes it does matter, because editing scripts
to do hash-bang with

#!/home/bokr/.guix-profile/bin/bash

has made a locale error ("guile: warning: failed to install locale")
go away and the script execute successfully, vs not executing beyond the error.

Also, what about the shell that runs first, when I log in?
Should I set SHELL=/gnu/... ? And/or reconfigure to get login/systemd
to launch /gnu/.../bash ?

I had hoped a binary install could give me clean separation of
guix pull goodies vs pacman -Syu (ArchLinux's package installer/updater)
stuff, but it seems difficult to control the env name environment that
both guix and non-guix use.

My setup, fwiw:
guix describe:

Generation 11	Aug 25 2019 20:58:43	(current)
  guix a707484
    repository URL: https://git.savannah.gnu.org/git/guix.git
    branch: master
    commit: a707484d64e7e46f8cb8401c660fbb6eb77ab9c6

uname -a:
Linux PhantoNv4ArchGx 5.2.9-arch1-1-ARCH #1 SMP PREEMPT Fri Aug 16 11:29:43 UTC 2019 x86_64 GNU/Linux

Well, sorry if these observations are explained in a FAQ.
I note that there is no -pie in the guix version of this:

[15:14 ~/bs]$ which -a gcc|while read line;do { echo -e "$line:   ";$line -v --version|& cat -n|egrep -on -e ' -pie ' ; } ;done
/home/bokr/.guix-profile/bin/gcc:
/usr/bin/gcc:
32: -pie
34: -pie
[15:14 ~/bs]$

HTH in some way, PMJI if not.
Regards,
Bengt Richter

bug#36747: Official MesCC bootstrap binaries differ from my locally built ones

[Ludovic Courtès]

Hi,

Mark H Weaver <mhw@netris.org> skribis:

> Thanks.  The next evaluation got further, but eventually failed.  Again,
> there seems no way to get any details on what went wrong from the web
> interface:
>
>   https://ci.guix.gnu.org/jobset/core-updates-core-updates
>   https://ci.guix.gnu.org/eval/7029

A Guile build of
/gnu/store/lbbgpkrs9mpw68k1bz0dwpi8ch6gp557-guile-2.2.6.drv had timed
out.  I restarted manually earlier today with a larger timeout.  It
succeeded and a new evaluation is now “in progress”…

Ludo’.

bug#36747: Official MesCC bootstrap binaries differ from my locally built ones

[Mark H Weaver]

Hi Ludovic,

Ludovic Courtès <ludo@gnu.org> writes:

> Mark H Weaver <mhw@netris.org> skribis:
>
>> Thanks.  The next evaluation got further, but eventually failed.  Again,
>> there seems no way to get any details on what went wrong from the web
>> interface:
>>
>>   https://ci.guix.gnu.org/jobset/core-updates-core-updates
>>   https://ci.guix.gnu.org/eval/7029
>
> A Guile build of
> /gnu/store/lbbgpkrs9mpw68k1bz0dwpi8ch6gp557-guile-2.2.6.drv had timed
> out.  I restarted manually earlier today with a larger timeout.  It
> succeeded and a new evaluation is now “in progress”…

Thanks.  It has since failed again, same as before.  I'm unable to get
any information from the web interface on what went wrong.

       Mark

bug#36747: Official MesCC bootstrap binaries differ from my locally built ones

[Ludovic Courtès]

Hi,

Mark H Weaver <mhw@netris.org> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>> Mark H Weaver <mhw@netris.org> skribis:
>>
>>> Thanks.  The next evaluation got further, but eventually failed.  Again,
>>> there seems no way to get any details on what went wrong from the web
>>> interface:
>>>
>>>   https://ci.guix.gnu.org/jobset/core-updates-core-updates
>>>   https://ci.guix.gnu.org/eval/7029
>>
>> A Guile build of
>> /gnu/store/lbbgpkrs9mpw68k1bz0dwpi8ch6gp557-guile-2.2.6.drv had timed
>> out.  I restarted manually earlier today with a larger timeout.  It
>> succeeded and a new evaluation is now “in progress”…
>
> Thanks.  It has since failed again, same as before.

This time it was ENOSPC of a Guile derivation.  I’ve restarted it and
then restarted the evaluation.

> I'm unable to get any information from the web interface on what went
> wrong.

Yup.  :-/

Ludo’.