Official MesCC bootstrap binaries differ from my locally built ones

DoneSubmitted by Mark H Weaver.
Details
6 participants
  • Bengt Richter
  • Jan Nieuwenhuizen
  • Ludovic Courtès
  • Marius Bakke
  • Mark H Weaver
  • Ricardo Wurmus
Owner
unassigned
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. Towardthat end, I locally built the new bootstrap tarballs by running thefollowing command from a git checkout at commitef809e3ac036eccc5f9c9edd8fb661d14ae15f2f.
./pre-inst-env guix build bootstrap-tarballs --system=i686-linux
This produces a mescc-tools-static-0.5.2-0.bb062b0-i686-linux.tar.xztarball that differs from the official one. See below for the precisedifferences, but what they boil down to is that the official tarballcontains 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'tinclude any references to the store.
However, it also raises the curious question of how I ended up withreferences to a different glibc than the one referenced by the officialtarball. Any idea what happened here?
Note that I have copies of _both_ of the above glibc outputs on my localmachine, as well as their derivations and build logs. Everything onthis 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.bz2mhw@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 builton my local machine on 16 December 2018, when I built an earlier versionof the bootstrap binaries for independent verification, using Guix atcommit da3c6a7f19ef1243af725f63c16c8fd92fde33b4. I've retained themever since, because I registered a GC root for them, and I run myguix-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 downfor the precise differences between the official MesCC bootstrapbinaries 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; echoDerive([("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; echoDerive([("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 (239 lines)mhw@jojen ~/new-bootstrap-binaries/unpacked-mescc-tools-static$ diff -ru official locally-builtBinary files official/blood-elf and locally-built/blood-elf differdiff -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 differdiff -ru official/hex2.hex locally-built/hex2.hex--- official/hex2.hex 2019-07-20 17:48:03.140331043 -0400+++ locally-built/hex2.hex 2019-07-20 17:48:02.488327810 -0400@@ -23990,16 +23990,16 @@ 0005f4b0 68 61 72 73 65 74 3d 00 20 09 0a 00 25 73 2f 25 |harset=. ...%s/%| 0005f4c0 73 00 4c 41 4e 47 55 41 47 45 00 50 4f 53 49 58 |s.LANGUAGE.POSIX| 0005f4d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|-0005f4e0 2f 67 6e 75 2f 73 74 6f 72 65 2f 78 6a 72 39 72 |/gnu/store/xjr9r|-0005f4f0 76 31 70 34 76 67 67 39 73 63 6c 77 7a 73 61 69 |v1p4vgg9sclwzsai|-0005f500 31 37 67 71 69 31 63 31 64 39 6a 2d 67 6c 69 62 |17gqi1c1d9j-glib|+0005f4e0 2f 67 6e 75 2f 73 74 6f 72 65 2f 67 67 6a 39 31 |/gnu/store/ggj91|+0005f4f0 36 34 61 68 68 6e 31 6b 6d 64 63 79 6c 33 73 6d |64ahhn1kmdcyl3sm|+0005f500 32 37 71 73 78 6b 34 36 68 30 31 2d 67 6c 69 62 |27qsxk46h01-glib| 0005f510 63 2d 32 2e 32 38 2f 73 68 61 72 65 2f 6c 6f 63 |c-2.28/share/loc| 0005f520 61 6c 65 00 6d 65 73 73 61 67 65 73 00 6c 6c 6f |ale.messages.llo| 0005f530 00 6c 6c 78 00 49 00 6c 6c 75 00 6c 6c 58 00 6c |.llx.I.llu.llX.l| 0005f540 6c 64 00 6c 6c 69 00 72 63 65 00 00 2f 67 6e 75 |ld.lli.rce../gnu|-0005f550 2f 73 74 6f 72 65 2f 78 6a 72 39 72 76 31 70 34 |/store/xjr9rv1p4|-0005f560 76 67 67 39 73 63 6c 77 7a 73 61 69 31 37 67 71 |vgg9sclwzsai17gq|-0005f570 69 31 63 31 64 39 6a 2d 67 6c 69 62 63 2d 32 2e |i1c1d9j-glibc-2.|+0005f550 2f 73 74 6f 72 65 2f 67 67 6a 39 31 36 34 61 68 |/store/ggj9164ah|+0005f560 68 6e 31 6b 6d 64 63 79 6c 33 73 6d 32 37 71 73 |hn1kmdcyl3sm27qs|+0005f570 78 6b 34 36 68 30 31 2d 67 6c 69 62 63 2d 32 2e |xk46h01-glibc-2.| 0005f580 32 38 2f 73 68 61 72 65 2f 6c 6f 63 61 6c 65 00 |28/share/locale.| 0005f590 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0005f5a0 b0 f8 04 08 b0 f8 04 08 58 f7 04 08 90 f7 04 08 |........X.......|@@ -24516,9 +24516,9 @@ 000616a0 61 74 75 73 20 3d 3d 20 5f 5f 47 43 4f 4e 56 5f |atus == __GCONV_| 000616b0 46 55 4c 4c 5f 4f 55 54 50 55 54 00 5f 5f 6d 62 |FULL_OUTPUT.__mb| 000616c0 73 72 74 6f 77 63 73 5f 6c 00 00 00 2f 67 6e 75 |srtowcs_l.../gnu|-000616d0 2f 73 74 6f 72 65 2f 78 6a 72 39 72 76 31 70 34 |/store/xjr9rv1p4|-000616e0 76 67 67 39 73 63 6c 77 7a 73 61 69 31 37 67 71 |vgg9sclwzsai17gq|-000616f0 69 31 63 31 64 39 6a 2d 67 6c 69 62 63 2d 32 2e |i1c1d9j-glibc-2.|+000616d0 2f 73 74 6f 72 65 2f 67 67 6a 39 31 36 34 61 68 |/store/ggj9164ah|+000616e0 68 6e 31 6b 6d 64 63 79 6c 33 73 6d 32 37 71 73 |hn1kmdcyl3sm27qs|+000616f0 78 6b 34 36 68 30 31 2d 67 6c 69 62 63 2d 32 2e |xk46h01-glibc-2.| 00061700 32 38 2f 6c 69 62 65 78 65 63 2f 67 65 74 63 6f |28/libexec/getco| 00061710 6e 66 00 47 45 54 43 4f 4e 46 5f 44 49 52 00 4c |nf.GETCONF_DIR.L| 00061720 50 36 34 5f 4f 46 46 36 34 00 4c 50 42 49 47 5f |P64_OFF64.LPBIG_|@@ -24875,9 +24875,9 @@ 00062db0 43 53 2d 32 42 45 2f 2f 00 55 4e 49 43 4f 44 45 |CS-2BE//.UNICODE| 00062dc0 42 49 47 2f 2f 00 00 00 00 00 00 00 00 00 00 00 |BIG//...........| 00062dd0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|-00062de0 2f 67 6e 75 2f 73 74 6f 72 65 2f 78 6a 72 39 72 |/gnu/store/xjr9r|-00062df0 76 31 70 34 76 67 67 39 73 63 6c 77 7a 73 61 69 |v1p4vgg9sclwzsai|-00062e00 31 37 67 71 69 31 63 31 64 39 6a 2d 67 6c 69 62 |17gqi1c1d9j-glib|+00062de0 2f 67 6e 75 2f 73 74 6f 72 65 2f 67 67 6a 39 31 |/gnu/store/ggj91|+00062df0 36 34 61 68 68 6e 31 6b 6d 64 63 79 6c 33 73 6d |64ahhn1kmdcyl3sm|+00062e00 32 37 71 73 78 6b 34 36 68 30 31 2d 67 6c 69 62 |27qsxk46h01-glib| 00062e10 63 2d 32 2e 32 38 2f 6c 69 62 2f 67 63 6f 6e 76 |c-2.28/lib/gconv| 00062e20 00 67 63 6f 6e 76 5f 62 75 69 6c 74 69 6e 2e 63 |.gconv_builtin.c| 00062e30 00 00 00 00 63 6e 74 20 3c 20 73 69 7a 65 6f 66 |....cnt < sizeof|@@ -24978,9 +24978,9 @@ 00063420 5f 5f 67 63 6f 6e 76 5f 74 72 61 6e 73 66 6f 72 |__gconv_transfor| 00063430 6d 5f 69 6e 74 65 72 6e 61 6c 5f 75 63 73 34 00 |m_internal_ucs4.| 00063440 c0 e0 f0 f8 fc 47 43 4f 4e 56 5f 50 41 54 48 00 |.....GCONV_PATH.|-00063450 2f 67 6e 75 2f 73 74 6f 72 65 2f 78 6a 72 39 72 |/gnu/store/xjr9r|-00063460 76 31 70 34 76 67 67 39 73 63 6c 77 7a 73 61 69 |v1p4vgg9sclwzsai|-00063470 31 37 67 71 69 31 63 31 64 39 6a 2d 67 6c 69 62 |17gqi1c1d9j-glib|+00063450 2f 67 6e 75 2f 73 74 6f 72 65 2f 67 67 6a 39 31 |/gnu/store/ggj91|+00063460 36 34 61 68 68 6e 31 6b 6d 64 63 79 6c 33 73 6d |64ahhn1kmdcyl3sm|+00063470 32 37 71 73 78 6b 34 36 68 30 31 2d 67 6c 69 62 |27qsxk46h01-glib| 00063480 63 2d 32 2e 32 38 2f 6c 69 62 2f 67 63 6f 6e 76 |c-2.28/lib/gconv| 00063490 2f 67 63 6f 6e 76 2d 6d 6f 64 75 6c 65 73 2e 63 |/gconv-modules.c| 000634a0 61 63 68 65 00 67 63 6f 6e 76 5f 64 6c 2e 63 00 |ache.gconv_dl.c.|@@ -28453,9 +28453,9 @@ 00071450 10 00 00 00 01 00 00 00 47 4e 55 00 7f 45 4c 46 |........GNU..ELF| 00071460 01 01 01 03 00 00 00 00 7f 45 4c 46 01 01 01 00 |.........ELF....| 00071470 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|-00071480 2f 67 6e 75 2f 73 74 6f 72 65 2f 78 6a 72 39 72 |/gnu/store/xjr9r|-00071490 76 31 70 34 76 67 67 39 73 63 6c 77 7a 73 61 69 |v1p4vgg9sclwzsai|-000714a0 31 37 67 71 69 31 63 31 64 39 6a 2d 67 6c 69 62 |17gqi1c1d9j-glib|+00071480 2f 67 6e 75 2f 73 74 6f 72 65 2f 67 67 6a 39 31 |/gnu/store/ggj91|+00071490 36 34 61 68 68 6e 31 6b 6d 64 63 79 6c 33 73 6d |64ahhn1kmdcyl3sm|+000714a0 32 37 71 73 78 6b 34 36 68 30 31 2d 67 6c 69 62 |27qsxk46h01-glib| 000714b0 63 2d 32 2e 32 38 2f 6c 69 62 2f 00 64 6c 2d 6c |c-2.28/lib/.dl-l| 000714c0 6f 6f 6b 75 70 2e 63 00 20 28 6e 6f 20 76 65 72 |ookup.c. (no ver| 000714d0 73 69 6f 6e 20 73 79 6d 62 6f 6c 73 29 00 2c 20 |sion symbols)., |Binary files official/M1 and locally-built/M1 differdiff -ru official/M1.hex locally-built/M1.hex--- official/M1.hex 2019-07-20 17:48:03.360332134 -0400+++ locally-built/M1.hex 2019-07-20 17:48:02.708328901 -0400@@ -23998,16 +23998,16 @@ 0005f490 68 61 72 73 65 74 3d 00 20 09 0a 00 25 73 2f 25 |harset=. ...%s/%| 0005f4a0 73 00 4c 41 4e 47 55 41 47 45 00 50 4f 53 49 58 |s.LANGUAGE.POSIX| 0005f4b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|-0005f4c0 2f 67 6e 75 2f 73 74 6f 72 65 2f 78 6a 72 39 72 |/gnu/store/xjr9r|-0005f4d0 76 31 70 34 76 67 67 39 73 63 6c 77 7a 73 61 69 |v1p4vgg9sclwzsai|-0005f4e0 31 37 67 71 69 31 63 31 64 39 6a 2d 67 6c 69 62 |17gqi1c1d9j-glib|+0005f4c0 2f 67 6e 75 2f 73 74 6f 72 65 2f 67 67 6a 39 31 |/gnu/store/ggj91|+0005f4d0 36 34 61 68 68 6e 31 6b 6d 64 63 79 6c 33 73 6d |64ahhn1kmdcyl3sm|+0005f4e0 32 37 71 73 78 6b 34 36 68 30 31 2d 67 6c 69 62 |27qsxk46h01-glib| 0005f4f0 63 2d 32 2e 32 38 2f 73 68 61 72 65 2f 6c 6f 63 |c-2.28/share/loc| 0005f500 61 6c 65 00 6d 65 73 73 61 67 65 73 00 6c 6c 6f |ale.messages.llo| 0005f510 00 6c 6c 78 00 49 00 6c 6c 75 00 6c 6c 58 00 6c |.llx.I.llu.llX.l| 0005f520 6c 64 00 6c 6c 69 00 72 63 65 00 00 2f 67 6e 75 |ld.lli.rce../gnu|-0005f530 2f 73 74 6f 72 65 2f 78 6a 72 39 72 76 31 70 34 |/store/xjr9rv1p4|-0005f540 76 67 67 39 73 63 6c 77 7a 73 61 69 31 37 67 71 |vgg9sclwzsai17gq|-0005f550 69 31 63 31 64 39 6a 2d 67 6c 69 62 63 2d 32 2e |i1c1d9j-glibc-2.|+0005f530 2f 73 74 6f 72 65 2f 67 67 6a 39 31 36 34 61 68 |/store/ggj9164ah|+0005f540 68 6e 31 6b 6d 64 63 79 6c 33 73 6d 32 37 71 73 |hn1kmdcyl3sm27qs|+0005f550 78 6b 34 36 68 30 31 2d 67 6c 69 62 63 2d 32 2e |xk46h01-glibc-2.| 0005f560 32 38 2f 73 68 61 72 65 2f 6c 6f 63 61 6c 65 00 |28/share/locale.| 0005f570 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0005f580 80 f9 04 08 80 f9 04 08 28 f8 04 08 60 f8 04 08 |........(...`...|@@ -24524,9 +24524,9 @@ 00061680 61 74 75 73 20 3d 3d 20 5f 5f 47 43 4f 4e 56 5f |atus == __GCONV_| 00061690 46 55 4c 4c 5f 4f 55 54 50 55 54 00 5f 5f 6d 62 |FULL_OUTPUT.__mb| 000616a0 73 72 74 6f 77 63 73 5f 6c 00 00 00 2f 67 6e 75 |srtowcs_l.../gnu|-000616b0 2f 73 74 6f 72 65 2f 78 6a 72 39 72 76 31 70 34 |/store/xjr9rv1p4|-000616c0 76 67 67 39 73 63 6c 77 7a 73 61 69 31 37 67 71 |vgg9sclwzsai17gq|-000616d0 69 31 63 31 64 39 6a 2d 67 6c 69 62 63 2d 32 2e |i1c1d9j-glibc-2.|+000616b0 2f 73 74 6f 72 65 2f 67 67 6a 39 31 36 34 61 68 |/store/ggj9164ah|+000616c0 68 6e 31 6b 6d 64 63 79 6c 33 73 6d 32 37 71 73 |hn1kmdcyl3sm27qs|+000616d0 78 6b 34 36 68 30 31 2d 67 6c 69 62 63 2d 32 2e |xk46h01-glibc-2.| 000616e0 32 38 2f 6c 69 62 65 78 65 63 2f 67 65 74 63 6f |28/libexec/getco| 000616f0 6e 66 00 47 45 54 43 4f 4e 46 5f 44 49 52 00 4c |nf.GETCONF_DIR.L| 00061700 50 36 34 5f 4f 46 46 36 34 00 4c 50 42 49 47 5f |P64_OFF64.LPBIG_|@@ -24883,9 +24883,9 @@ 00062d90 43 53 2d 32 42 45 2f 2f 00 55 4e 49 43 4f 44 45 |CS-2BE//.UNICODE| 00062da0 42 49 47 2f 2f 00 00 00 00 00 00 00 00 00 00 00 |BIG//...........| 00062db0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|-00062dc0 2f 67 6e 75 2f 73 74 6f 72 65 2f 78 6a 72 39 72 |/gnu/store/xjr9r|-00062dd0 76 31 70 34 76 67 67 39 73 63 6c 77 7a 73 61 69 |v1p4vgg9sclwzsai|-00062de0 31 37 67 71 69 31 63 31 64 39 6a 2d 67 6c 69 62 |17gqi1c1d9j-glib|+00062dc0 2f 67 6e 75 2f 73 74 6f 72 65 2f 67 67 6a 39 31 |/gnu/store/ggj91|+00062dd0 36 34 61 68 68 6e 31 6b 6d 64 63 79 6c 33 73 6d |64ahhn1kmdcyl3sm|+00062de0 32 37 71 73 78 6b 34 36 68 30 31 2d 67 6c 69 62 |27qsxk46h01-glib| 00062df0 63 2d 32 2e 32 38 2f 6c 69 62 2f 67 63 6f 6e 76 |c-2.28/lib/gconv| 00062e00 00 67 63 6f 6e 76 5f 62 75 69 6c 74 69 6e 2e 63 |.gconv_builtin.c| 00062e10 00 00 00 00 63 6e 74 20 3c 20 73 69 7a 65 6f 66 |....cnt < sizeof|@@ -24986,9 +24986,9 @@ 00063400 5f 5f 67 63 6f 6e 76 5f 74 72 61 6e 73 66 6f 72 |__gconv_transfor| 00063410 6d 5f 69 6e 74 65 72 6e 61 6c 5f 75 63 73 34 00 |m_internal_ucs4.| 00063420 c0 e0 f0 f8 fc 47 43 4f 4e 56 5f 50 41 54 48 00 |.....GCONV_PATH.|-00063430 2f 67 6e 75 2f 73 74 6f 72 65 2f 78 6a 72 39 72 |/gnu/store/xjr9r|-00063440 76 31 70 34 76 67 67 39 73 63 6c 77 7a 73 61 69 |v1p4vgg9sclwzsai|-00063450 31 37 67 71 69 31 63 31 64 39 6a 2d 67 6c 69 62 |17gqi1c1d9j-glib|+00063430 2f 67 6e 75 2f 73 74 6f 72 65 2f 67 67 6a 39 31 |/gnu/store/ggj91|+00063440 36 34 61 68 68 6e 31 6b 6d 64 63 79 6c 33 73 6d |64ahhn1kmdcyl3sm|+00063450 32 37 71 73 78 6b 34 36 68 30 31 2d 67 6c 69 62 |27qsxk46h01-glib| 00063460 63 2d 32 2e 32 38 2f 6c 69 62 2f 67 63 6f 6e 76 |c-2.28/lib/gconv| 00063470 2f 67 63 6f 6e 76 2d 6d 6f 64 75 6c 65 73 2e 63 |/gconv-modules.c| 00063480 61 63 68 65 00 67 63 6f 6e 76 5f 64 6c 2e 63 00 |ache.gconv_dl.c.|@@ -28461,9 +28461,9 @@ 00071430 10 00 00 00 01 00 00 00 47 4e 55 00 7f 45 4c 46 |........GNU..ELF| 00071440 01 01 01 03 00 00 00 00 7f 45 4c 46 01 01 01 00 |.........ELF....| 00071450 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|-00071460 2f 67 6e 75 2f 73 74 6f 72 65 2f 78 6a 72 39 72 |/gnu/store/xjr9r|-00071470 76 31 70 34 76 67 67 39 73 63 6c 77 7a 73 61 69 |v1p4vgg9sclwzsai|-00071480 31 37 67 71 69 31 63 31 64 39 6a 2d 67 6c 69 62 |17gqi1c1d9j-glib|+00071460 2f 67 6e 75 2f 73 74 6f 72 65 2f 67 67 6a 39 31 |/gnu/store/ggj91|+00071470 36 34 61 68 68 6e 31 6b 6d 64 63 79 6c 33 73 6d |64ahhn1kmdcyl3sm|+00071480 32 37 71 73 78 6b 34 36 68 30 31 2d 67 6c 69 62 |27qsxk46h01-glib| 00071490 63 2d 32 2e 32 38 2f 6c 69 62 2f 00 64 6c 2d 6c |c-2.28/lib/.dl-l| 000714a0 6f 6f 6b 75 70 2e 63 00 20 28 6e 6f 20 76 65 72 |ookup.c. (no ver| 000714b0 73 69 6f 6e 20 73 79 6d 62 6f 6c 73 29 00 2c 20 |sion symbols)., |
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; atleast 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 ordepended on: if our bootstrap build is clean those references will notexist when the bootstrap binaries run.
In any case, if store references are present in bootstrap binaries, thenthey should be reproducible. Removing store references is one way tomake 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 ifit cannot be used anyway, removing it could hide the fact that it maydiffers 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 andmes using attched patches that remove store references (also on myhttps://gitlab.com/janneke/guixcore-updates).
I have just verified that tcc-boot0 builds by using this localmodification
Toggle snippet (18 lines)15:05:56 janneke@dundal:~/src/guix/core-updates [env]$ git diffdiff --git a/gnu/packages/bootstrap.scm b/gnu/packages/bootstrap.scmindex 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 2001From: Jan Nieuwenhuizen <janneke@gnu.org>Date: Sun, 21 Jul 2019 11:40:54 +0200Subject: [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.scmindex 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 2001From: Jan Nieuwenhuizen <janneke@gnu.org>Date: Sun, 21 Jul 2019 14:27:07 +0200Subject: [PATCH 2/4] bootstrap: mes-minimal-stripped: Remove store references.
* gnu/packages/make-bootstrap.scm (%mes-minimal-stripped): Remove storereferences.--- 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.scmindex 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 2001From: Jan Nieuwenhuizen <janneke@gnu.org>Date: Sun, 21 Jul 2019 14:38:52 +0200Subject: [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.scmindex 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 2001From: Jan Nieuwenhuizen <janneke@gnu.org>Date: Sun, 21 Jul 2019 14:42:35 +0200Subject: [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.scmindex 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.orgFreelance 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 seriousthanks
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 componentof 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 wasdone in our older bootstrap binaries, which we've been using for manyyears, since the early days of Guix.
I'd like to build the new bootstrap binaries, but I'm unsure how toproceed. In your new batch of commits, you reference the commit thatwas 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 commit2e13b6fff94027158b3de5d3a1469dc9f89b0c39. However, that commit is noton Savannah, as demonstrated by the following URL, which reports "Badcommit reference: 2e13b6fff94027158b3de5d3a1469dc9f89b0c39".
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=2e13b6fff94027158b3de5d3a1469dc9f89b0c39
The other issue is that your proposed new fixes do not seem to apply to'master'. Did you build the newly fixed bootstrap tarballs fromsomething based on 'core-updates'? If so, that leaves me no way toindependently verify the new bootstrap without putting my trust in theslightly older bootstrap -- the same one that I just failed toreproduce.
What I need is a way to build the new bootstrap tarballs without usingthe existing 'core-updates' branch. I need a way to build them from abranch that's based upon the much older bootstrap binaries that we'vebeen using for many years. Preferably, they should be built fromsomething 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 failureto remove them that we found something possiblby fishy? IWBN if we knewthat the hashes are reproducible before we remove them. Hmm, that mightbe a good argument to have two packages, a merely static/contentstripped 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
https://gitlab.com/janneke/guix@ core-updates
it's core-updates plus the two first patches I sent. I could push awip-core-updates branch (but I'll first try the master thing, seebelow).
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 therecipes from gnu/packages/bootstrap.scm for mescc-tools-static-strippedand mes-minimal-stripped and their tarballs could be put into and usedon master to build. I'll have a look into this.
If we could find how you can reproduce the current flawed hash-containingbootstrap binaries that we have on core-updates, that would be nice...I'mhoping for Ludo' to step in and say something insightful about thedifferences you found :)
janneke
-- Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.orgFreelance 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.orgFreelance 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 mesbootstrap 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
here: http://lilypond.org/janneke/guix/20190722/
Once the patches are cleaned-up/we decide how we want it, we can buildand inject the resulting binaries into current core-updates. I don'treally like it a lot to have built them on a totally new branch but it'sthe best we can do right now, I think.
Greetings,janneke
-- Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.orgFreelance 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 atcommit ef809e3ac036eccc5f9c9edd8fb661d14ae15f2f (the commit used tobuild the current bootstrap binaries for core-updates) and applying thefixes there? Then you can push that new branch to savannah, and we canbuild it and see if we get the same thing? Hopefully, the onlydifference 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 thatbranched off of master; so mine are athttp://lilypond.org/janneke/guix/20190722/
After this commit should come the update-commit, using them inbootstrap.scm.
HTH,janneke
-- Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.orgFreelance 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.xz1acd8f83e27d2fac311a5ca78e9bf11a9a1638b82469870d5c854c4e7afaa26a linux-libre-headers-stripped-4.14.67-i686-linux.tar.xz021543d9bb6af55f39e68d69692e3cb74646ced2cad0bb9ac0047ef81e9d7330 mescc-tools-static-stripped-0.5.2-0.bb062b0-i686-linux.tar.xzfb32090071b39fc804fb9a7fba96f0bc5eb844a0efd268fb24c42e6bfa959de0 mes-minimal-stripped-0.19-i686-linux.tar.xz9ee954dc19db5c8d4113c73a702fd8f79f26c51024220f2617d0572c0a85e69c 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 bootstrapbinaries 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.xz1acd8f83e27d2fac311a5ca78e9bf11a9a1638b82469870d5c854c4e7afaa26a /gnu/store/hd3lk0f08a0sq40qqa6yv1q9gbk7gxww-bootstrap-tarballs-0/linux-libre-headers-stripped-4.14.67-i686-linux.tar.xz021543d9bb6af55f39e68d69692e3cb74646ced2cad0bb9ac0047ef81e9d7330 /gnu/store/hd3lk0f08a0sq40qqa6yv1q9gbk7gxww-bootstrap-tarballs-0/mescc-tools-static-stripped-0.5.2-0.bb062b0-i686-linux.tar.xzfb32090071b39fc804fb9a7fba96f0bc5eb844a0efd268fb24c42e6bfa959de0 /gnu/store/hd3lk0f08a0sq40qqa6yv1q9gbk7gxww-bootstrap-tarballs-0/mes-minimal-stripped-0.19-i686-linux.tar.xzc80cdd17b0a24eebdd75570ff72c4ec06e129bd702ac008186b57f6301c448e7 /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 (andhopefully 1.0.0) and mescc-tools-0.6 and building on Debian ootb.
There's no real reason to update bootstrap tarballs for those versionsand I cannot promise a release date yet.
Further work on mes-0.21 should bring the Reduced Binary Seed bootstrapto 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.orgFreelance 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:
https://lists.gnu.org/archive/html/guix-devel/2018-12/msg00046.html
This was on commit 4ae7dc7b9af64794081b1913740b97acd89c91bc, which isearlier than the one you’re looking at (commitef809e3ac036eccc5f9c9edd8fb661d14ae15f2f, 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 rightcommits. Then, if there are still differences, I suggest a cursory lookat the output of ‘diffoscope’ to see if there’s anything obvious(non-determinism in .go files is apparently still a problem, forexample.)
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 thatthe bash-4.4 configure script produces an incorrect compile-timeconfiguration when built on Linux 5.x or later. It boils down to thiscode 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. Weshould probably fix that.
Anyway, it appears that our static-binaries-0-i686-linux.tar.xz tarballcan 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, commiteefabc1db04c91d6954306e319820cd95190c25d. 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 buildto be deterministic.
It would also be good to enable building the bootstrap binaries from acommit 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 commit4ae7dc7b9af64794081b1913740b97acd89c91bc was bogus, because at thatcommit, %bootstrap-inputs had already been changed to use an earlierdraft of the reduced binary seed, based on unverified bootstrap tarballsdownloaded from lilypond.org.
In order to perform a truly independent verification, we need to buildthe 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 thenew '%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.orgFreelance 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 patcheswere needed to match the bootstrap binaries that 'core-updates' iscurrently based on.
I ended up deleting and repushing a revised 'wip-binaries' to Savannah.It includes slightly modified versions of the two commits you hadincluded, as well as some additional cherry-picked commits of yours toupdate mescc-tools and add linux-libre-headers-bootstrap-tarball, and afew of my own.
I built the new bootstrap tarballs at the new 'wip-binaries', commitc67becb31c30a5cd7685f166970ac4793e3a34a9, and here's what I got:
Toggle snippet (13 lines)mhw@jojen ~/guix-wip-binaries$ git describev1.0.1-2404-gc67becb31cmhw@jojen ~/guix-wip-binaries$ ./pre-inst-env guix build --system=i686-linux bootstrap-tarballs/gnu/store/bg086i2qw1fn2jgbd15d9v91hyjrjsb2-bootstrap-tarballs-0mhw@jojen ~/guix-wip-binaries$ cd /gnu/store/bg086i2qw1fn2jgbd15d9v91hyjrjsb2-bootstrap-tarballs-0mhw@jojen /gnu/store/bg086i2qw1fn2jgbd15d9v91hyjrjsb2-bootstrap-tarballs-0$ sha256sum *3e50c070a100b6bcf84c4bf5c868f9cd0a9fd1570f5d82fbfb78f8411959091b guile-static-stripped-2.2.4-i686-linux.tar.xz1acd8f83e27d2fac311a5ca78e9bf11a9a1638b82469870d5c854c4e7afaa26a linux-libre-headers-stripped-4.14.67-i686-linux.tar.xz021543d9bb6af55f39e68d69692e3cb74646ced2cad0bb9ac0047ef81e9d7330 mescc-tools-static-stripped-0.5.2-0.bb062b0-i686-linux.tar.xzfb32090071b39fc804fb9a7fba96f0bc5eb844a0efd268fb24c42e6bfa959de0 mes-minimal-stripped-0.19-i686-linux.tar.xzc80cdd17b0a24eebdd75570ff72c4ec06e129bd702ac008186b57f6301c448e7 static-binaries-0-i686-linux.tar.xz
All of these match what you posted here earlier except forguile-static-stripped-2.2.4. In my final commit to 'wip-binaries'I disabled the parallel build in guile-static, which I hope mightmake that build deterministic.
Can you try "guix build --system=i686-linux bootstrap-tarballs" at thenew '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' wasto 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 officialrelease 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 gitcommit: 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.2and 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 thereview of the integration of the reduced binary seed bootstrap intocore-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 inbootstrap tarballs. We built bootstrap variants of mescc-tools and mesusing 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.orgFreelance 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 thisadditional patch:
Toggle diff (62 lines)diff --git a/gnu/packages/mes.scm b/gnu/packages/mes.scmindex 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.xz1acd8f83e27d2fac311a5ca78e9bf11a9a1638b82469870d5c854c4e7afaa26a linux-libre-headers-stripped-4.14.67-i686-linux.tar.xz021543d9bb6af55f39e68d69692e3cb74646ced2cad0bb9ac0047ef81e9d7330 mescc-tools-static-stripped-0.5.2-i686-linux.tar.xzfb32090071b39fc804fb9a7fba96f0bc5eb844a0efd268fb24c42e6bfa959de0 mes-minimal-stripped-0.19-i686-linux.tar.xzc80cdd17b0a24eebdd75570ff72c4ec06e129bd702ac008186b57f6301c448e7 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-linuxbootstrap-tarballs":
/gnu/store/ld82vli1msfrlimjaryznrqcwm0jc5ii-bootstrap-tarballs-0.drv
I will report back with hashes once it finishes building. It would begreat if someone else could try to resolve the merge and see if they getthe same derivation.
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCgAdFiEEu7At3yzq9qgNHeZDoqBt8qM6VPoFAl1UItsACgkQoqBt8qM6VPqTUAf+KginaSq7wY/hWl+fb1Mz9mCWAJsReukB7pnVvV081ESR65pXc7NuMkZqB1S1FguPrB6pu68l9JdhfwLFSSjX0GfIS+9kVL7OyjNWA6HFHjiuq+o0XjMPomPz03Kc8yyC+n9nMYJe6nGsC12WZ6ktVnEQhCCwUw74BjvxgUx5/DJ4XQ/V68Qt+YH01onByXaxMrDhBd8JpGUAUPRO/Cmh8vQAlGXkE+asrRmHH1BBv6lb1mlGS46XMTSgdOrxA+nLmxrk/HUycmY/S9Q1OgDKKlNDBub8zlnZmnnJ3hSe5v8wdITZjBS+qHAPRXL4zuAI3mVWFo5vQQlsTG0ndNCF0g===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.xz9e34b26526b184912b0d97df96e316151fd97ede24aec2f22dd13ed33438b2e4 linux-libre-headers-stripped-4.19.56-i686-linux.tar.xz7db07a7097a7920e17f6f1794098b9f29bc3522c36a33cf797123f64581cdc34 mescc-tools-static-0.5.2-i686-linux.tar.xz3a9b050c1a2b61bb1cbed16ee07aecdc83e9097ce4a914623aa1b9808abe57f4 mes-minimal-stripped-0.19-i686-linux.tar.xz1ccb4f39656eb977706db7a4aa811461785200b0a11e847035bb89fef91b85ab 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-----
iQEzBAEBCgAdFiEEu7At3yzq9qgNHeZDoqBt8qM6VPoFAl1UROgACgkQoqBt8qM6VPrTeAf9FbX5Z8Um/gufD1oRY9qMDEL3sV1bjn3MxFUs4PIYK/FUGEZWhKn6U3PmulaIo6yQjyZ19ZveFRv5SEk/wb1eaOX1x25mndCea8RA+GUqSnu1Lj8i9kfzKjNt+xwqGyVyjNkY13+yHvdkPC6LPwMqs4uuvvKzw8HySwi8SwTG4ps7tFuvAgMLtSMKf6GO44+OdjPGZYwgtZzUMht5IdDmuDMRjoWdSfSYfhrWWEb3+DJwgTGFk1jOOaAB0qAFbOY7xcfARCOfTf2M0nEu5FAae8SyKYcNWvC31qds0aqryxEOTVl/8L8pVA3FHXUPwgoW5rWiM+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 commit78ced7975b0665e810834391d826c9f0ef7277e1 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 beapplied 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 setunconditionally set on systems based on Linux (the kernel), regardlessof 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 onthe 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 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 someonetemporarily uploads the new binaries somewhere else, and adjusts'%bootstrap-base-urls' accordingly. The key is for the hashes and filenames 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, butI'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 itshould ideally be done before starting the rebuild. It's not crucial,but it would be nice to fix this potential source of non-determinism inthe 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 workedafter merging the branch, since it was non-trivial. Mainly to make thecommit 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 bashfix for 5.0, and updating the bootstrap binary URLs and hashes. I willdo this in a 'core-updates-next' branch. I would also like to mergewip-binaries into it as a final step, unless someone has objections.
Ludovic should be back in a couple of days and can hopefully take careof 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-----
iQEzBAEBCgAdFiEEu7At3yzq9qgNHeZDoqBt8qM6VPoFAl1UZ3YACgkQoqBt8qM6VPrb4Qf/W6gi8ZSes1eH2Wd6Fn9R7kgLIeFK1mpVJc4aaXIfB+0M5BJol7k882qhoLpkVyEH/cWwmaOdhegmIPeDztQKNhDDHQibOJis2/Eg9KIhi5JlI4A9HrUE6zsJt3L1ID7l4Ykojlx2RBVbvtHDKqf69rc8UxTyaR7hPV8eYCTc0aRsqueYpx4XYToqL2ADyEEXjrY6oVcG5wlTqr5XBWN3afU+g/4d4oB3FLMQ44jwXz+w8f9ulp0IPE1+CxLCIFp57n5Ef65sYlPmzdyT8SXEezcla0/CHr8vGccXnPb/6l0SsR6yYtPfyFF1Ttd7wGTyGEbJB+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 mergedinto 'master', rather than 'core-updates'. That would allow people toeasily 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 newbinaries from 'core-updates' anyway, because 'core-updates' hasdifferent 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 therecent 'staging' merge), and excluding the update of mescc-tools to thegit checkout.
I built the bootstrap-tarballs for i686-linux and got the same hashesthat we've previously agreed on here. I used "guix download" to loadthe new bootstrap binaries into my store, and am now testing theattached draft patch to 'core-updates'.
Thanks, Mark
From e3e477c92af3b62eb8f65a5c4459f02faf60e857 Mon Sep 17 00:00:00 2001From: Mark H Weaver <mhw@netris.org>Date: Thu, 15 Aug 2019 15:39:57 -0400Subject: [PATCH] gnu: bootstrap: Update to the 20190815 bootstrap binaries.
* gnu/packages/bootstrap.scm (%bootstrap-linux-libre-headers): Update thedownload 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.scmindex 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 themnow.
Mark
From e3e477c92af3b62eb8f65a5c4459f02faf60e857 Mon Sep 17 00:00:00 2001From: Mark H Weaver <mhw@netris.org>Date: Thu, 15 Aug 2019 15:39:57 -0400Subject: [PATCH 1/2] gnu: bootstrap: Update to the 20190815 bootstrap binaries.
* gnu/packages/bootstrap.scm (%bootstrap-linux-libre-headers): Update thedownload 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.scmindex 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 2001From: Mark H Weaver <mhw@netris.org>Date: Thu, 15 Aug 2019 16:45:03 -0400Subject: [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.mkindex 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.scmindex 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.patchnew file mode 100644index 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 togive 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-----
iQEzBAEBCgAdFiEEu7At3yzq9qgNHeZDoqBt8qM6VPoFAl1VzFgACgkQoqBt8qM6VPot/gf+K2Ji25Bd7GaW76GBwXKNoPD2It9FPkgnkwrwCtcqWQ8cxgmrS3/4Gb00+Lvt6kaYlNY/tgLnO8SN5la+ZJjXL7VkZwEXDCj5ic/8hGlTJ9Fk2e107vSQttmScdrYHL9U4Kt11RDDi1zcl+jbdpY/WPH9X1Hc713Snejee57EZMmK2goEp9FxnYaj9FWWPD8JAoDej5606u9TgCKhuY20KZwXbuUnFXdtylrvjA3k46/qgS+xoP68S6sAR7YfU7QbD5roC2a3rV1SGoZ/ZSzTI2KadTfJewscG1154o4Uz5pSAqO3z2NG2ggBDqS9jaL2k/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. Theseslight changes to the bootstrap binaries to make them builddeterministically should almost certainly make no difference to anythingelse in 'core-updates', so the only time we'll lose is the time neededfor Berlin to rebuild.
If we make any additional changes to 'core-updates', such as updatingSQLite or adding more architectures, it will likely cause additionalproblems that need to be debugged. This 'core-updates' cycle hasalready 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 currentlybuilding out that branch on my X200. So far I've successfully built thecore packages and 'hello', and am now continuing on to build the rest ofmy Guix system.
Anyway, I'm long past the point where the slight differences made to thenew bootstrap binaries to make them deterministic should have anyeffects, so I think it's fairly safe to predict that these commits willnot 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 pushthem to 'core-updates', after the new bootstrap binaries have eitherbeen 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 thefiles that Mark mentions above to ftp.gnu.org this time (Ricardo shouldalso 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:
https://ci.guix.gnu.org/jobset/core-updates-next
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 atcommit 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 describev1.0.1-2479-g9e6256ba0fmhw@jojen ~/guix-wip-binaries$ ./pre-inst-env guix build --system=i686-linux bootstrap-tarballs/gnu/store/rdwyr8mh7dvhfkb5g4cws6q40hp23rbi-bootstrap-tarballs-0mhw@jojen ~/guix-wip-binaries$ cd /gnu/store/rdwyr8mh7dvhfkb5g4cws6q40hp23rbi-bootstrap-tarballs-0mhw@jojen /gnu/store/rdwyr8mh7dvhfkb5g4cws6q40hp23rbi-bootstrap-tarballs-0$ sha256sum *3e50c070a100b6bcf84c4bf5c868f9cd0a9fd1570f5d82fbfb78f8411959091b guile-static-stripped-2.2.4-i686-linux.tar.xz1acd8f83e27d2fac311a5ca78e9bf11a9a1638b82469870d5c854c4e7afaa26a linux-libre-headers-stripped-4.14.67-i686-linux.tar.xz021543d9bb6af55f39e68d69692e3cb74646ced2cad0bb9ac0047ef81e9d7330 mescc-tools-static-stripped-0.5.2-i686-linux.tar.xzfb32090071b39fc804fb9a7fba96f0bc5eb844a0efd268fb24c42e6bfa959de0 mes-minimal-stripped-0.19-i686-linux.tar.xzc80cdd17b0a24eebdd75570ff72c4ec06e129bd702ac008186b57f6301c448e7 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 uploadthe files above, along with digital signatures, to the following newdirectory:
https://alpha.gnu.org/gnu/guix/bootstrap/i686-linux/20190815/
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 commit82eaac49ac983f28768d6623d802f41cbd7f779b.
However, that file name _was_ present in an older version of'core-updates-next', before it was deleted on Savannah at some time inthe past. I know this because I checked out 'core-updates-next' fromanother one of my computers, and found that it was actually at commit89e7f90d0b40bc4f15f902cc3b82c3effa87dd02 from last November. I ran "gitfetch" and "git reset --hard origin/core-updates-next" to fix it, butmaybe there's a better way.
How is this kind of issue normally dealt with? Is there a git cache inCuirass 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 (withGTK), git, openssh, gnupg, evince, gnome-terminal, and hundreds of otherpackages. 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 tolookup bits of the target Guix, hence the confusion.
I fixed it by setting it to the empty list as it should:
update specifications set load_path_inputs = '()' where name = 'core-updates-next';
(The specs can be seen at https://ci.guix.gnu.org/specifications.)
It’s currently being evaluated:
https://ci.guix.gnu.org/jobset/core-updates-next
Ludo’.
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 someonemanually added the new bootstrap tarballs to Berlin's store, or uploadedthem 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 myuser profile, based on 'core-updates-next'. I'm typing this messagefrom that system, and am currently working on building the chain of Rustcompilers 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 failedto 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 describeGeneration 1 Aug 18 2019 12:04:54 (current) guix 9e6256b repository URL: https://git.savannah.gnu.org/git/guix.git branch: wip-binaries commit: 9e6256ba0f32ab12d61c914a3fed879dac881762ludo@bayfront ~$ ./wip-binaries/bin/guix build -s i686-linux bootstrap-tarballs/gnu/store/rdwyr8mh7dvhfkb5g4cws6q40hp23rbi-bootstrap-tarballs-0ludo@bayfront ~$ (cd /gnu/store/rdwyr8mh7dvhfkb5g4cws6q40hp23rbi-bootstrap-tarballs-0 ; sha256sum *)3e50c070a100b6bcf84c4bf5c868f9cd0a9fd1570f5d82fbfb78f8411959091b guile-static-stripped-2.2.4-i686-linux.tar.xz1acd8f83e27d2fac311a5ca78e9bf11a9a1638b82469870d5c854c4e7afaa26a linux-libre-headers-stripped-4.14.67-i686-linux.tar.xz021543d9bb6af55f39e68d69692e3cb74646ced2cad0bb9ac0047ef81e9d7330 mescc-tools-static-stripped-0.5.2-i686-linux.tar.xzfb32090071b39fc804fb9a7fba96f0bc5eb844a0efd268fb24c42e6bfa959de0 mes-minimal-stripped-0.19-i686-linux.tar.xzc80cdd17b0a24eebdd75570ff72c4ec06e129bd702ac008186b57f6301c448e7 static-binaries-0-i686-linux.tar.xz
(I’m actually surprised Guile is 100% reproducible; ISTR there werestill 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 (notalpha.gnu.org, but same directory as you wrote) tomorrow.
Thank you, and apologies for the delay!
Ludo’.
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEPORkVYqE/cadtAz7CQsRmT2a67UFAl1dudwACgkQCQsRmT2a67UEFw/+JpMswWacGUdW2eZmneP4Py+X3piQleclGmPDX8WqV2HiAMb4Be0JhdVWwWEf7iWMC4PEr/MPm9mRfA26OfqKTMYL7qkI4GCIckLg3Bttz+PtcZ9j4Ywg7IbeQLDOsnoeHCotSvcCOMEmTAuVHenc9tZFQ02iePXzVFxXyw+3oN7jRZ8Dxjsha1pf6nZBXidOmOX1uX7Aa7tOqSwNNmDUHPlkhyo8ARiEsGqgNs1X+gsEtbG6RT/1Yw+15+OOgdwku74N/0k6bLRj8FzM2uynEYgXzQmwNcY4UM8croNlNe0QwUWLZ8hF2VnM6nn2fn5PIpW1bXZDMRpz68Rwc/qWfbeEGDym4lqj1xHEhNAZpn/UTCRcFmNXPOH2PVIT5eUrAnNOa5qzK5DJkZ2mGrPGpZGQ8M5ZTjbZYd3QjO5qhvdhvwD3qbU6xYQiPXNEqrLgwmhX0WJi75hDzY23r3zHIHcvwBWPPZoS3dcVI3fY2qEG4ts26L85aVNUT4glsHTeRwNObdP3hdixqIM+Bs/y6MTMut3LQwdONTjp23vtiayajkdSbRgE/N/mksJMOOve2PNW9LVPOWtJTBCKGmnTg8ABNurH4pJ8WcATN6a9IWp3LPjLRBEjmr+2DJ7311kulMsJtZjolFoA7DP/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 aswell, 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 somepreliminary investigation, and my guess is that the gensyms produced byGuile's compiler sometimes depends on whether dependent modules werepreviously 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 beextended 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 tohttps://ftp.gnu.org/gnu/guix/bootstrap/i686-linux/20190815/. Iadjusted ‘%bootstrap-base-urls’ and the branch is now being evaluatedfor real:
https://ci.guix.gnu.org/jobset/core-updates-next
Thanks everyone for verifying and “fixing” these bootstrap binaries, andapologies 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 thatwe’re delaying merging of ‘core-updates’ into ‘master’ until‘core-updates-next’ becomes ‘core-updates’. Is this what you had inmind? (I’m asking because ‘core-updates’ was almost entirely builtIIRC.)
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 d4bc93abe59e8ffcb8304050c05e727fe0230651Author: 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 82eaac49ac983f28768d6623d802f41cbd7f779bAuthor: 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 47fcdfac44c5bf236299679781133468be6f0207Author: 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 packagesthat build successfully, modulo non-determistic build failures. Theonly additional time it should require is the time needed for Berlin torebuild the branch.
Otherwise, 'core-updates-next' seems to be in good shape, and possiblyalmost ready to merge into 'master'. I admit that this assessment isbased 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 ofpackages I use myself.
In my opinion, 'core-updates' in its current form should never be mergedinto 'master', because it's built upon non-deterministic bootstraptarballs 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 thatindicates 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 onarchitectures, not just x86. So I’ll probably ungraft my Ghostscriptfix (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 thesituation, though it’s not equivalent to comparing with anotherevaluation.
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 nextcore-updates cycle. The problem was quite severe in bash-4.4, whichbuilds incorrectly on linux-5.0 or later, but the issue in bash-5.0 isfar less likely to cause problems in practice: it will build differentlyon 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 anundesirable 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 causingproblems, 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 inthe commit that actually adds those binaries to boostrap.scm. Maybethat 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 thebranch 'core-updates-next', which has a different role than usual and isarguably misnamed. It's only 3 commits. Of those 3, one has a faultycommit log, and another should be postponed. I could simply push therevised 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 areremaining 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 tohave 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 forevaluation 7008, which corresponds to the new commits I just pushed, toswitch to the new bootstrap tarballs. The second URL above returns "500Internal 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.
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.tmprm -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/reccalctouch examples/c/reccalc/scan.stamp.tmptouch 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.lmv examples/c/reccalc/scan.stamp.tmp examples/c/reccalc/scan.stampmv examples/c/reccalc/scan.stamp.tmp examples/c/reccalc/scan.stampmake[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 directorymake[1]: *** [Makefile:6855: examples/c/reccalc/scan.stamp] Error 1make[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 2command "make" "-j" "8" "ARFLAGS=crD" "RANLIB=ranlib" "V=1" failed with status 2builder 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 westill 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 wehave 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 commit6cf84a43bb6160e11ede96820a8bc563aa7461ef on berlin.
I confirm that visiting this URL still results in an error:
https://ci.guix.gnu.org/eval/7008
(Looks like the cuirass-web service still writes to the same log file,so I can’t actually see the message amidst all the build logs…)
--Ricardo
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 webinterface:
https://ci.guix.gnu.org/jobset/core-updates-core-updates https://ci.guix.gnu.org/eval/7029
The second URL works this time, but it shows no results: 0 scheduledbuilds, 0 succeeded builds, 0 failed builds, and it says "No elementshere."
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 whichbash is /home/bokr/.guix-profile/bin/bashwhich 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 circumstancesand silently give up if not repositionable, causing mystery errors?
Also, I am in the foreign (ArchLinux) host environment twilight zoneof mixed /usr vs ~/.guix-profile name searches and wonder ifthere are hidden /usr dependencies baked statically into some /gnu/store executablesthat are causing me problems.
exec is a bash built-in, and I suppose that is usually doesn't matterif a guile script is launched via
#!/usr/bin/bash exec guile ...
but I have a hunch that sometimes it does matter, because editing scriptsto 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/systemdto launch /gnu/.../bash ?
I had hoped a binary install could give me clean separation ofguix pull goodies vs pacman -Syu (ArchLinux's package installer/updater)stuff, but it seems difficult to control the env name environment thatboth guix and non-guix use.
My setup, fwiw:guix describe:
Generation 11 Aug 25 2019 20:58:43 (current) guix a707484 repository URL: https://git.savannah.gnu.org/git/guix.git branch: master commit: a707484d64e7e46f8cb8401c660fbb6eb77ab9c6
uname -a:Linux PhantoNv4ArchGx 5.2.9-arch1-1-ARCH #1 SMP PREEMPT Fri Aug 16 11:29:43 UTC 2019 x86_64 GNU/Linux
Well, sorry if these observations are explained in a FAQ.I note that there is no -pie in the guix version of this:
[15:14 ~/bs]$ which -a gcc|while read line;do { echo -e "$line: ";$line -v --version|& cat -n|egrep -on -e ' -pie ' ; } ;done/home/bokr/.guix-profile/bin/gcc:/usr/bin/gcc:32: -pie34: -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 timedout. I restarted manually earlier today with a larger timeout. Itsucceeded 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 getany 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 andthen 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 email to 36747@debbugs.gnu.org