Official MesCC bootstrap binaries differ from my locally built ones

  • Done
  • quality assurance status badge
Details
6 participants
  • Bengt Richter
  • Jan Nieuwenhuizen
  • Ludovic Courtès
  • Marius Bakke
  • Mark H Weaver
  • Ricardo Wurmus
Owner
unassigned
Submitted by
Mark H Weaver
Severity
serious
M
M
Mark H Weaver wrote on 21 Jul 2019 00:43
(address . bug-guix@gnu.org)
875znwcoo9.fsf@netris.org
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.

Toggle snippet (6 lines)
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

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:

Toggle snippet (5 lines)
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

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:

Toggle snippet (7 lines)
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")])


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

Toggle snippet (137 lines)
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
This message was truncated. Download the full message here.
J
J
Jan Nieuwenhuizen wrote on 21 Jul 2019 15:34
(name . Mark H Weaver)(address . mhw@netris.org)(address . 36747@debbugs.gnu.org)
87ef2j1pgt.fsf@gnu.org
Mark H Weaver writes:

Toggle quote (18 lines)
> 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 :(

Toggle quote (3 lines)
> 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?

Toggle quote (4 lines)
> 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

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

Toggle snippet (18 lines)
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"

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

Thanks again for looking into this!

Greetings,
janneke
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(-)

Toggle diff (50 lines)
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
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(-)

Toggle diff (35 lines)
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
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(-)

Toggle diff (31 lines)
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
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(-)

Toggle diff (30 lines)
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
--
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com| Avatar® http://AvatarAcademy.com
M
M
Mark H Weaver wrote on 21 Jul 2019 17:30
(no subject)
(address . control@debbugs.gnu.org)
87tvbf9zgl.fsf@netris.org
severity 36747 serious
thanks
M
M
Mark H Weaver wrote on 22 Jul 2019 02:56
Re: bug#36747: Official MesCC bootstrap binaries differ from my locally built ones
(name . Jan Nieuwenhuizen)(address . janneke@gnu.org)(address . 36747@debbugs.gnu.org)
87ftmy51kk.fsf@netris.org
Hi Janneke,

Thanks very much for the quick response to this issue.

Jan Nieuwenhuizen <janneke@gnu.org> wrote:
Toggle quote (8 lines)
> 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:

Toggle quote (10 lines)
> 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".


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
J
J
Jan Nieuwenhuizen wrote on 22 Jul 2019 08:18
(name . Mark H Weaver)(address . mhw@netris.org)(address . 36747@debbugs.gnu.org)
87muh6sib4.fsf@gnu.org
Mark H Weaver writes:

Hi Mark,

Toggle quote (6 lines)
> 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.

Toggle quote (11 lines)
> 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


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).

Toggle quote (7 lines)
> 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...

Toggle quote (8 lines)
> 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
J
J
Jan Nieuwenhuizen wrote on 22 Jul 2019 08:26
(name . Mark H Weaver)(address . mhw@netris.org)(address . 36747@debbugs.gnu.org)
87d0i2shyg.fsf@gnu.org
Jan Nieuwenhuizen writes:

Toggle quote (3 lines)
> 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
J
J
Jan Nieuwenhuizen wrote on 22 Jul 2019 10:26
(name . Mark H Weaver)(address . mhw@netris.org)(address . 36747@debbugs.gnu.org)
878ssqsceh.fsf@gnu.org
Jan Nieuwenhuizen writes:

Toggle quote (13 lines)
>> 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

Toggle snippet (4 lines)
./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


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
M
M
Mark H Weaver wrote on 22 Jul 2019 10:31
(name . Jan Nieuwenhuizen)(address . janneke@gnu.org)(address . 36747@debbugs.gnu.org)
877e8a79mz.fsf@netris.org
Hi Janneke,

Jan Nieuwenhuizen <janneke@gnu.org> wrote:
Toggle quote (10 lines)
>> 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
J
J
Jan Nieuwenhuizen wrote on 22 Jul 2019 19:41
(name . Mark H Weaver)(address . mhw@netris.org)(address . 36747@debbugs.gnu.org)
87pnm2ufv1.fsf@gnu.org
Mark H Weaver writes:

Hi Mark,

Toggle quote (9 lines)
> 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

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
M
M
Mark H Weaver wrote on 23 Jul 2019 07:42
(name . Jan Nieuwenhuizen)(address . janneke@gnu.org)
87lfwpqpb7.fsf@netris.org
Hi Janneke,

Toggle quote (7 lines)
> 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:

Toggle snippet (8 lines)
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?

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.

Toggle quote (3 lines)
> 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
J
J
Jan Nieuwenhuizen wrote on 23 Jul 2019 08:28
(name . Mark H Weaver)(address . mhw@netris.org)
87o91luuvs.fsf@gnu.org
Mark H Weaver writes:

Hi Mark,

Toggle quote (18 lines)
>> 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

Toggle quote (6 lines)
> 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

Toggle quote (7 lines)
>> 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.

Toggle quote (2 lines)
> 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
L
L
Ludovic Courtès wrote on 23 Jul 2019 12:03
(name . Mark H Weaver)(address . mhw@netris.org)
875znt2hlc.fsf@gnu.org
Hi Mark,

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

Toggle quote (20 lines)
> 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:


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

Toggle quote (6 lines)
> 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’.
M
M
Mark H Weaver wrote on 12 Aug 2019 02:21
(name . Jan Nieuwenhuizen)(address . janneke@gnu.org)(address . 36747@debbugs.gnu.org)
878srz9qrm.fsf@netris.org
Jan Nieuwenhuizen <janneke@gnu.org> writes:

Toggle quote (37 lines)
> 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:

Toggle snippet (6 lines)
linux*) LOCAL_LDFLAGS=-rdynamic # allow dynamic loading
case "`uname -r`" in
2.[[456789]]*|[[34]]*) AC_DEFINE(PGRP_PIPE) ;;
esac ;;

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

Toggle snippet (7 lines)
linux*) LOCAL_LDFLAGS=-rdynamic # allow dynamic loading
case "`uname -r`" in
1.*|2.[[0123]]*) : ;;
*) AC_DEFINE(PGRP_PIPE) ;;
esac ;;

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
M
M
Mark H Weaver wrote on 12 Aug 2019 06:11
(name . Jan Nieuwenhuizen)(address . janneke@gnu.org)(address . 36747@debbugs.gnu.org)
874l2n9g5k.fsf@netris.org
I wrote earlier:

Toggle quote (17 lines)
> 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
M
M
Mark H Weaver wrote on 12 Aug 2019 09:08
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 36747@debbugs.gnu.org)
87zhke97xj.fsf@netris.org
Hi Ludovic,

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

Toggle quote (28 lines)
> 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
J
J
Jan Nieuwenhuizen wrote on 12 Aug 2019 11:01
(name . Mark H Weaver)(address . mhw@netris.org)
87h86mdaex.fsf@gnu.org
Mark H Weaver writes:

Toggle quote (3 lines)
> 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
M
M
Mark H Weaver wrote on 13 Aug 2019 08:42
(name . Jan Nieuwenhuizen)(address . janneke@gnu.org)(address . 36747@debbugs.gnu.org)
8736i5a7mb.fsf@netris.org
Hi Janneke,

Jan Nieuwenhuizen <janneke@gnu.org> writes:

Toggle quote (7 lines)
> 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:

Toggle snippet (13 lines)
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

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:


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
J
J
Jan Nieuwenhuizen wrote on 13 Aug 2019 12:17
(name . Mark H Weaver)(address . mhw@netris.org)(address . 36747@debbugs.gnu.org)
87mugdbc9r.fsf@gnu.org
Mark H Weaver writes:

Hi Mark,

Toggle quote (12 lines)
>> 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.

Toggle quote (18 lines)
> 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/

Toggle quote (15 lines)
> 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

Toggle snippet (7 lines)
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.

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
M
M
Marius Bakke wrote on 14 Aug 2019 17:03
(address . 36747@debbugs.gnu.org)
8736i3iyas.fsf@devup.no
Jan Nieuwenhuizen <janneke@gnu.org> writes:

Toggle quote (76 lines)
> 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:
Toggle diff (62 lines)
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

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.
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEu7At3yzq9qgNHeZDoqBt8qM6VPoFAl1UItsACgkQoqBt8qM6
VPqTUAf+KginaSq7wY/hWl+fb1Mz9mCWAJsReukB7pnVvV081ESR65pXc7NuMkZq
B1S1FguPrB6pu68l9JdhfwLFSSjX0GfIS+9kVL7OyjNWA6HFHjiuq+o0XjMPomPz
03Kc8yyC+n9nMYJe6nGsC12WZ6ktVnEQhCCwUw74BjvxgUx5/DJ4XQ/V68Qt+YH0
1onByXaxMrDhBd8JpGUAUPRO/Cmh8vQAlGXkE+asrRmHH1BBv6lb1mlGS46XMTSg
dOrxA+nLmxrk/HUycmY/S9Q1OgDKKlNDBub8zlnZmnnJ3hSe5v8wdITZjBS+qHAP
RXL4zuAI3mVWFo5vQQlsTG0ndNCF0g==
=UXHE
-----END PGP SIGNATURE-----

M
M
Marius Bakke wrote on 14 Aug 2019 19:29
(address . 36747@debbugs.gnu.org)
87zhkbhd07.fsf@devup.no
Marius Bakke <mbakke@fastmail.com> writes:

Toggle quote (160 lines)
> 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?
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEu7At3yzq9qgNHeZDoqBt8qM6VPoFAl1UROgACgkQoqBt8qM6
VPrTeAf9FbX5Z8Um/gufD1oRY9qMDEL3sV1bjn3MxFUs4PIYK/FUGEZWhKn6U3Pm
ulaIo6yQjyZ19ZveFRv5SEk/wb1eaOX1x25mndCea8RA+GUqSnu1Lj8i9kfzKjNt
+xwqGyVyjNkY13+yHvdkPC6LPwMqs4uuvvKzw8HySwi8SwTG4ps7tFuvAgMLtSMK
f6GO44+OdjPGZYwgtZzUMht5IdDmuDMRjoWdSfSYfhrWWEb3+DJwgTGFk1jOOaAB
0qAFbOY7xcfARCOfTf2M0nEu5FAae8SyKYcNWvC31qds0aqryxEOTVl/8L8pVA3F
HXUPwgoW5rWiM+SwfxB9Wj9uUIn3HA==
=z3ye
-----END PGP SIGNATURE-----

M
M
Mark H Weaver wrote on 14 Aug 2019 20:35
(name . Marius Bakke)(address . mbakke@fastmail.com)
87v9uz4msh.fsf@netris.org
Hi Marius,

Marius Bakke <mbakke@fastmail.com> writes:

Toggle quote (146 lines)
> 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?

Toggle quote (10 lines)
>> 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!

Toggle quote (2 lines)
>> 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.

Toggle quote (15 lines)
>> 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.

Toggle quote (2 lines)
> @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
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
M
M
Mark H Weaver wrote on 14 Aug 2019 20:43
(name . Marius Bakke)(address . mbakke@fastmail.com)(address . 36747@debbugs.gnu.org)
87pnl74mg9.fsf@netris.org
Earlier I wrote:

[...]
Toggle quote (16 lines)
> (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
M
M
Marius Bakke wrote on 14 Aug 2019 21:56
(name . Mark H Weaver)(address . mhw@netris.org)
87woffh66h.fsf@devup.no
Mark H Weaver <mhw@netris.org> writes:

Toggle quote (154 lines)
> 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.

Toggle quote (21 lines)
>>> 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.

Toggle quote (18 lines)
>>> 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.

Toggle quote (34 lines)
>> @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?
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEu7At3yzq9qgNHeZDoqBt8qM6VPoFAl1UZ3YACgkQoqBt8qM6
VPrb4Qf/W6gi8ZSes1eH2Wd6Fn9R7kgLIeFK1mpVJc4aaXIfB+0M5BJol7k882qh
oLpkVyEH/cWwmaOdhegmIPeDztQKNhDDHQibOJis2/Eg9KIhi5JlI4A9HrUE6zsJ
t3L1ID7l4Ykojlx2RBVbvtHDKqf69rc8UxTyaR7hPV8eYCTc0aRsqueYpx4XYToq
L2ADyEEXjrY6oVcG5wlTqr5XBWN3afU+g/4d4oB3FLMQ44jwXz+w8f9ulp0IPE1+
CxLCIFp57n5Ef65sYlPmzdyT8SXEezcla0/CHr8vGccXnPb/6l0SsR6yYtPfyFF1
Ttd7wGTyGEbJB+vbJOxYpje7SjvhfQ==
=6vry
-----END PGP SIGNATURE-----

M
M
Mark H Weaver wrote on 14 Aug 2019 22:43
(name . Marius Bakke)(address . mbakke@fastmail.com)(address . 36747@debbugs.gnu.org)
87imqz4gv3.fsf@netris.org
Hi Marius,

Marius Bakke <mbakke@fastmail.com> writes:

Toggle quote (4 lines)
> 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.

[...]

Toggle quote (4 lines)
> [...] 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
M
M
Mark H Weaver wrote on 15 Aug 2019 21:44
(name . Marius Bakke)(address . mbakke@fastmail.com)(address . 36747@debbugs.gnu.org)
87r25mfc2s.fsf@netris.org
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
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(-)

Toggle diff (54 lines)
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
M
M
Mark H Weaver wrote on 15 Aug 2019 22:56
(name . Marius Bakke)(address . mbakke@fastmail.com)(address . 36747@debbugs.gnu.org)
87mugaf8ph.fsf@netris.org
Hi,

Marius Bakke <mbakke@fastmail.com> writes:
Toggle quote (3 lines)
> 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
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(-)

Toggle diff (54 lines)
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
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

Toggle diff (66 lines)
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
M
M
Marius Bakke wrote on 15 Aug 2019 23:19
(name . Mark H Weaver)(address . mhw@netris.org)(address . 36747@debbugs.gnu.org)
87r25mgm93.fsf@devup.no
Mark H Weaver <mhw@netris.org> writes:

Toggle quote (9 lines)
> 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.
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEu7At3yzq9qgNHeZDoqBt8qM6VPoFAl1VzFgACgkQoqBt8qM6
VPot/gf+K2Ji25Bd7GaW76GBwXKNoPD2It9FPkgnkwrwCtcqWQ8cxgmrS3/4Gb00
+Lvt6kaYlNY/tgLnO8SN5la+ZJjXL7VkZwEXDCj5ic/8hGlTJ9Fk2e107vSQttmS
cdrYHL9U4Kt11RDDi1zcl+jbdpY/WPH9X1Hc713Snejee57EZMmK2goEp9FxnYaj
9FWWPD8JAoDej5606u9TgCKhuY20KZwXbuUnFXdtylrvjA3k46/qgS+xoP68S6sA
R7YfU7QbD5roC2a3rV1SGoZ/ZSzTI2KadTfJewscG1154o4Uz5pSAqO3z2NG2ggB
DqS9jaL2k/y2JtKc07fB29qPfYKH9g==
=V3pM
-----END PGP SIGNATURE-----

M
M
Mark H Weaver wrote on 16 Aug 2019 01:16
(name . Marius Bakke)(address . mbakke@fastmail.com)(address . 36747@debbugs.gnu.org)
87imqyf28l.fsf@netris.org
Marius Bakke <mbakke@fastmail.com> writes:

Toggle quote (20 lines)
> 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
M
M
Mark H Weaver wrote on 16 Aug 2019 09:42
(name . Marius Bakke)(address . mbakke@fastmail.com)(address . 36747@debbugs.gnu.org)
87y2zteet0.fsf@netris.org
Hi Marius,

Earlier I wrote:

Toggle quote (7 lines)
> 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:
Toggle quote (3 lines)
> 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
L
L
Ludovic Courtès wrote on 16 Aug 2019 12:49
(name . Marius Bakke)(address . mbakke@fastmail.com)
87o90pgzak.fsf@gnu.org
Hello,

Marius Bakke <mbakke@fastmail.com> skribis:

Toggle quote (2 lines)
> Mark H Weaver <mhw@netris.org> writes:

[...]

Toggle quote (40 lines)
>> 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?

Toggle quote (3 lines)
> 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:


However, evaluation fails with:

Toggle snippet (33 lines)
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?

Ludo’.
M
M
Mark H Weaver wrote on 16 Aug 2019 18:59
(name . Ludovic Courtès)(address . ludo@gnu.org)
87mug9cagh.fsf@netris.org
Hi Ludovic,

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

Toggle quote (52 lines)
> 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

Toggle snippet (13 lines)
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?

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:


Toggle quote (7 lines)
>> 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.

Toggle quote (36 lines)
> 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
M
M
Mark H Weaver wrote on 17 Aug 2019 18:49
(name . Marius Bakke)(address . mbakke@fastmail.com)(address . 36747@debbugs.gnu.org)
87ef1j20v8.fsf@netris.org
Earlier, I wrote:

Toggle quote (5 lines)
> 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
L
L
Ludovic Courtès wrote on 17 Aug 2019 23:38
(name . Mark H Weaver)(address . mhw@netris.org)
87v9uvbhhh.fsf@gnu.org
Hi Mark,

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

Toggle quote (6 lines)
> 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.

Toggle quote (9 lines)
>> 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:


Ludo’.
M
M
Mark H Weaver wrote on 18 Aug 2019 03:17
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 36747@debbugs.gnu.org)
875zmv1db7.fsf@netris.org
Hi Ludovic,

Ludovic Courtès <ludo@gnu.org> wrote:
Toggle quote (4 lines)
> 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
L
L
Ludovic Courtès wrote on 18 Aug 2019 11:26
(name . Mark H Weaver)(address . mhw@netris.org)(address . 36747@debbugs.gnu.org)
87o90mbz8v.fsf@gnu.org
Hi,

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

Toggle quote (9 lines)
> 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’.
M
M
Mark H Weaver wrote on 20 Aug 2019 20:40
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 36747@debbugs.gnu.org)
874l2bvfwd.fsf@netris.org
Hi Ludovic,

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

Toggle quote (15 lines)
> 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
M
M
Mark H Weaver wrote on 21 Aug 2019 22:15
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 36747@debbugs.gnu.org)
87v9uq2s1o.fsf@netris.org
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
L
L
Ludovic Courtès wrote on 21 Aug 2019 23:38
(name . Mark H Weaver)(address . mhw@netris.org)
87ftlujj1f.fsf@gnu.org
Hi Mark,

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

Toggle quote (20 lines)
> 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:

Toggle snippet (16 lines)
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

(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?

Toggle quote (6 lines)
> 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’.
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEPORkVYqE/cadtAz7CQsRmT2a67UFAl1dudwACgkQCQsRmT2a
67UEFw/+JpMswWacGUdW2eZmneP4Py+X3piQleclGmPDX8WqV2HiAMb4Be0JhdVW
wWEf7iWMC4PEr/MPm9mRfA26OfqKTMYL7qkI4GCIckLg3Bttz+PtcZ9j4Ywg7Ibe
QLDOsnoeHCotSvcCOMEmTAuVHenc9tZFQ02iePXzVFxXyw+3oN7jRZ8Dxjsha1pf
6nZBXidOmOX1uX7Aa7tOqSwNNmDUHPlkhyo8ARiEsGqgNs1X+gsEtbG6RT/1Yw+1
5+OOgdwku74N/0k6bLRj8FzM2uynEYgXzQmwNcY4UM8croNlNe0QwUWLZ8hF2VnM
6nn2fn5PIpW1bXZDMRpz68Rwc/qWfbeEGDym4lqj1xHEhNAZpn/UTCRcFmNXPOH2
PVIT5eUrAnNOa5qzK5DJkZ2mGrPGpZGQ8M5ZTjbZYd3QjO5qhvdhvwD3qbU6xYQi
PXNEqrLgwmhX0WJi75hDzY23r3zHIHcvwBWPPZoS3dcVI3fY2qEG4ts26L85aVNU
T4glsHTeRwNObdP3hdixqIM+Bs/y6MTMut3LQwdONTjp23vtiayajkdSbRgE/N/m
ksJMOOve2PNW9LVPOWtJTBCKGmnTg8ABNurH4pJ8WcATN6a9IWp3LPjLRBEjmr+2
DJ7311kulMsJtZjolFoA7DP/jsakjpVd0Ah6W+L9Ppg4b2+i3VE=
=q1aw
-----END PGP SIGNATURE-----

M
M
Mark H Weaver wrote on 22 Aug 2019 00:57
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 36747@debbugs.gnu.org)
87r25e2kjz.fsf@netris.org
Hi Ludovic,

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

Toggle quote (24 lines)
> 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.

Toggle quote (3 lines)
> (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.

Toggle quote (2 lines)
> So, green light, right?

Yes!

Toggle quote (9 lines)
>> 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
L
L
Ludovic Courtès wrote on 22 Aug 2019 12:09
(name . Mark H Weaver)(address . mhw@netris.org)(address . 36747@debbugs.gnu.org)
87imqpqzos.fsf@gnu.org
Hello,

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

Toggle quote (29 lines)
> 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.

Toggle quote (8 lines)
>> (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.

Toggle quote (16 lines)
>> 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
adjusted ‘%bootstrap-base-urls’ and the branch is now being evaluated
for real:


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

Ludo’.
L
L
Ludovic Courtès wrote on 24 Aug 2019 15:31
(name . Marius Bakke)(address . mbakke@fastmail.com)
874l26y9j0.fsf@gnu.org
Hello,

Marius Bakke <mbakke@fastmail.com> skribis:

Toggle quote (2 lines)
> Mark H Weaver <mhw@netris.org> writes:

[...]

Toggle quote (37 lines)
>> 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’.
M
M
Mark H Weaver wrote on 24 Aug 2019 22:34
(name . Ludovic Courtès)(address . ludo@gnu.org)
87d0guuwt4.fsf@netris.org
Hi Ludovic,

Ludovic Courtès <ludo@gnu.org> wrote:
Toggle quote (6 lines)
> 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':

Toggle snippet (30 lines)
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'.

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?

Toggle quote (2 lines)
> 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
L
L
Ludovic Courtès wrote on 26 Aug 2019 10:25
(name . Mark H Weaver)(address . mhw@netris.org)
87zhjw1gfm.fsf@gnu.org
Hi Mark,

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

Toggle quote (42 lines)
> 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.

Toggle quote (12 lines)
> 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.

Toggle quote (6 lines)
> 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?

Toggle quote (7 lines)
>> 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’.
M
M
Mark H Weaver wrote on 26 Aug 2019 20:36
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 36747@debbugs.gnu.org)
871rx7pyco.fsf@netris.org
Hi Ludovic,

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

Toggle quote (48 lines)
> 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?

Toggle quote (9 lines)
>>> 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
M
M
Mark H Weaver wrote on 27 Aug 2019 05:58
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 36747@debbugs.gnu.org)
87a7bvnts4.fsf@netris.org
Hi Ludovic,

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

Toggle quote (12 lines)
> 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
L
L
Ludovic Courtès wrote on 27 Aug 2019 11:38
(name . Mark H Weaver)(address . mhw@netris.org)(address . 36747@debbugs.gnu.org)
875zmjrlrc.fsf@gnu.org
Hi Mark,

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

Toggle quote (4 lines)
> Ludovic Courtès <ludo@gnu.org> writes:
>
>> Mark H Weaver <mhw@netris.org> skribis:

[...]

Toggle quote (10 lines)
>>> 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.

[...]

Toggle quote (12 lines)
>> 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’.
L
L
Ludovic Courtès wrote on 27 Aug 2019 11:40
(name . Mark H Weaver)(address . mhw@netris.org)(address . 36747@debbugs.gnu.org)
87y2zfq746.fsf@gnu.org
Mark H Weaver <mhw@netris.org> skribis:

Toggle quote (4 lines)
> 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’.
M
M
Mark H Weaver wrote on 27 Aug 2019 16:27
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 36747@debbugs.gnu.org)
874l22of8l.fsf@netris.org
Hi Ludovic,

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

Toggle quote (9 lines)
> 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.

Toggle quote (9 lines)
>> 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.

Toggle quote (2 lines)
> 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
L
L
Ludovic Courtès wrote on 27 Aug 2019 18:04
(name . Mark H Weaver)(address . mhw@netris.org)(address . 36747@debbugs.gnu.org)
87zhjuoarz.fsf@gnu.org
Hello,

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

Toggle quote (13 lines)
> 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.

Toggle quote (19 lines)
>>> 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’.
M
M
Mark H Weaver wrote on 27 Aug 2019 18:46
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 36747-done@debbugs.gnu.org)
87zhjumu88.fsf@netris.org
Ludovic Courtès <ludo@gnu.org> writes:

Toggle quote (6 lines)
> 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
Closed
M
M
Mark H Weaver wrote on 28 Aug 2019 02:55
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 36747@debbugs.gnu.org)
87k1aym7kf.fsf@netris.org
Hi Ludovic,

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


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
L
L
Ludovic Courtès wrote on 29 Aug 2019 00:12
(name . Mark H Weaver)(address . mhw@netris.org)
87d0gpdjmi.fsf@gnu.org
Hi,

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

Toggle quote (10 lines)
> 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:


Excerpt:

Toggle snippet (22 lines)
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

I’ve addressed it by a hack in c55fae452032aa4b1b63406983e9abdf70adc957.

Toggle quote (2 lines)
> 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?

Toggle quote (2 lines)
> 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’.
R
R
Ricardo Wurmus wrote on 29 Aug 2019 07:46
(name . Ludovic Courtès)(address . ludo@gnu.org)
87blw8h6b9.fsf@elephly.net
Ludovic Courtès <ludo@gnu.org> writes:

Toggle quote (48 lines)
> 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:


(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
R
R
Ricardo Wurmus wrote on 29 Aug 2019 08:32
(name . Ludovic Courtès)(address . ludo@gnu.org)
87a7bsh47w.fsf@elephly.net
Ricardo Wurmus <rekado@elephly.net> writes:

Toggle quote (3 lines)
> (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
M
M
Mark H Weaver wrote on 29 Aug 2019 21:28
(address . 36747@debbugs.gnu.org)
87lfvblqiv.fsf@netris.org
Hi Ludovic and Ricardo,

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

Toggle quote (15 lines)
> 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
[...]
Toggle quote (2 lines)
> 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:


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
B
B
Bengt Richter wrote on 30 Aug 2019 00:28
(name . Ludovic Courtès)(address . ludo@gnu.org)
20190829222814.GA2437@PhantoNv4ArchGx.localdomain
On +2019-08-27 11:38:31 +0200, Ludovic Courtès wrote:
Toggle quote (44 lines)
> 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
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
L
L
Ludovic Courtès wrote on 30 Aug 2019 01:23
(name . Mark H Weaver)(address . mhw@netris.org)
871rx3imj7.fsf@gnu.org
Hi,

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

Toggle quote (7 lines)
> 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’.
M
M
Mark H Weaver wrote on 30 Aug 2019 21:52
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 36747@debbugs.gnu.org)
87v9uexwfk.fsf@netris.org
Hi Ludovic,

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

Toggle quote (14 lines)
> 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
L
L
Ludovic Courtès wrote on 31 Aug 2019 14:44
(name . Mark H Weaver)(address . mhw@netris.org)(address . 36747@debbugs.gnu.org)
87y2z9ec71.fsf@gnu.org
Hi,

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

Toggle quote (18 lines)
> 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.

Toggle quote (3 lines)
> I'm unable to get any information from the web interface on what went
> wrong.

Yup. :-/

Ludo’.
?
Your comment

This issue is archived.

To comment on this conversation send an email to 36747@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 36747
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch