Hi Ludovic, Ludovic Courtès writes: > Marius Bakke skribis: > >> Mark H Weaver 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 , along >>> with digital signatures, of course. I'm talking about these in >>> particular: >>> >>> 3e50c070a100b6bcf84c4bf5c868f9cd0a9fd1570f5d82fbfb78f8411959091b guile-static-stripped-2.2.4-i686-linux.tar.xz >>> 1acd8f83e27d2fac311a5ca78e9bf11a9a1638b82469870d5c854c4e7afaa26a linux-libre-headers-stripped-4.14.67-i686-linux.tar.xz >>> 021543d9bb6af55f39e68d69692e3cb74646ced2cad0bb9ac0047ef81e9d7330 mescc-tools-static-stripped-0.5.2-i686-linux.tar.xz >>> fb32090071b39fc804fb9a7fba96f0bc5eb844a0efd268fb24c42e6bfa959de0 mes-minimal-stripped-0.19-i686-linux.tar.xz >>> c80cdd17b0a24eebdd75570ff72c4ec06e129bd702ac008186b57f6301c448e7 static-binaries-0-i686-linux.tar.xz >>> >>> (3) The following bootstrap packages in 'core-updates' bootstrap.scm >>> should be updated to use the new binaries above: >>> >>> (a) %bootstrap-linux-libre-headers >>> (b) %bootstrap-mescc-tools >>> (c) %bootstrap-mes >>> >>> (4) Berlin should start rebuilding 'core-updates'. >>> >>> If desired, steps (3) and (4) could come before (2) if someone >>> temporarily uploads the new binaries somewhere else, and adjusts >>> '%bootstrap-base-urls' accordingly. The key is for the hashes and file >>> names to match what we've agreed on here, as I listed in (2) above. >>> >>> What do you think? >> >> Thank you for the excellent summary. I can look into adjusting the bash >> fix for 5.0, and updating the bootstrap binary URLs and hashes. I will >> do this in a 'core-updates-next' branch. I would also like to merge >> wip-binaries into it as a final step, unless someone has objections. >> >> Ludovic should be back in a couple of days and can hopefully take care >> of the uploads. > > I haven’t quite caught up yet, but I trust you and I can upload the > files that Mark mentions above to ftp.gnu.org this time (Ricardo should > also be able to upload them, if needed.) > > How can I reproduce them or fetch them? You can reproduce them with the following command from a git checkout at commit 9e6256ba0f32ab12d61c914a3fed879dac881762, which is the tip of the 'wip-binaries' branch, based on recent 'master': ./pre-inst-env guix build --system=i686-linux bootstrap-tarballs --8<---------------cut here---------------start------------->8--- mhw@jojen ~/guix-wip-binaries$ git describe v1.0.1-2479-g9e6256ba0f mhw@jojen ~/guix-wip-binaries$ ./pre-inst-env guix build --system=i686-linux bootstrap-tarballs /gnu/store/rdwyr8mh7dvhfkb5g4cws6q40hp23rbi-bootstrap-tarballs-0 mhw@jojen ~/guix-wip-binaries$ cd /gnu/store/rdwyr8mh7dvhfkb5g4cws6q40hp23rbi-bootstrap-tarballs-0 mhw@jojen /gnu/store/rdwyr8mh7dvhfkb5g4cws6q40hp23rbi-bootstrap-tarballs-0$ sha256sum * 3e50c070a100b6bcf84c4bf5c868f9cd0a9fd1570f5d82fbfb78f8411959091b guile-static-stripped-2.2.4-i686-linux.tar.xz 1acd8f83e27d2fac311a5ca78e9bf11a9a1638b82469870d5c854c4e7afaa26a linux-libre-headers-stripped-4.14.67-i686-linux.tar.xz 021543d9bb6af55f39e68d69692e3cb74646ced2cad0bb9ac0047ef81e9d7330 mescc-tools-static-stripped-0.5.2-i686-linux.tar.xz fb32090071b39fc804fb9a7fba96f0bc5eb844a0efd268fb24c42e6bfa959de0 mes-minimal-stripped-0.19-i686-linux.tar.xz c80cdd17b0a24eebdd75570ff72c4ec06e129bd702ac008186b57f6301c448e7 static-binaries-0-i686-linux.tar.xz --8<---------------cut here---------------end--------------->8--- Do you get the same results? To match what 'core-updates-next' expects, it would be good to upload the files above, along with digital signatures, to the following new directory: https://alpha.gnu.org/gnu/guix/bootstrap/i686-linux/20190815/ >> Ricardo: can you instruct Cuirass to add a reduced jobset for >> 'core-updates-next', that only builds builds the "core" package subset? > > Should be ready now: > > https://ci.guix.gnu.org/jobset/core-updates-next Thank you. > However, evaluation fails with: > > Backtrace: > In guix/packages.scm: > 1188:25 19 (bag->derivation # # ?) > In srfi/srfi-1.scm: > 592:29 18 (map1 (("source" #) ?)) > 592:17 17 (map1 (("bash" #) ?)) > In guix/packages.scm: > 979:16 16 (expand-input # # ?) > 936:16 15 (cache! # # ?) > 1255:22 14 (thunk) > 1188:25 13 (bag->derivation # # ?) > In srfi/srfi-1.scm: > 592:29 12 (map1 (("source" #) ?)) > 592:17 11 (map1 (("gcc" #) ?)) > In guix/packages.scm: > 979:16 10 (expand-input # # ?) > 936:16 9 (cache! # # ?) > 1255:22 8 (thunk) > 1188:25 7 (bag->derivation # # ?) > In srfi/srfi-1.scm: > 592:29 6 (map1 (("source" #) ?)) > 592:17 5 (map1 (("texinfo" #) ?)) > In guix/packages.scm: > 979:16 4 (expand-input # # ?) > 936:16 3 (cache! # # ?) > 1255:22 2 (thunk) > 1188:25 1 Exception thrown while printing backtrace: > Throw to key `srfi-34' with args `(#)'. > > srfi/srfi-1.scm:592:17: In procedure map1: > Throw to key `srfi-34' with args `(#)'. > > Am I missing something? The string "texinfo-perl-compat" does not occur in the current 'core-updates-next' branch on Savannah, which is at commit 82eaac49ac983f28768d6623d802f41cbd7f779b. However, that file name _was_ present in an older version of 'core-updates-next', before it was deleted on Savannah at some time in the past. I know this because I checked out 'core-updates-next' from another one of my computers, and found that it was actually at commit 89e7f90d0b40bc4f15f902cc3b82c3effa87dd02 from last November. I ran "git fetch" and "git reset --hard origin/core-updates-next" to fix it, but maybe there's a better way. How is this kind of issue normally dealt with? Is there a git cache in Cuirass that can be cleaned? Thanks, Mark