From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark H Weaver Subject: bug#36747: Official MesCC bootstrap binaries differ from my locally built ones Date: Fri, 16 Aug 2019 12:59:31 -0400 Message-ID: <87mug9cagh.fsf@netris.org> References: <875znwcoo9.fsf@netris.org> <87ef2j1pgt.fsf@gnu.org> <87ftmy51kk.fsf@netris.org> <87muh6sib4.fsf@gnu.org> <877e8a79mz.fsf@netris.org> <87pnm2ufv1.fsf@gnu.org> <87lfwpqpb7.fsf@netris.org> <875znt2hlc.fsf@gnu.org> <87zhke97xj.fsf@netris.org> <87h86mdaex.fsf@gnu.org> <8736i5a7mb.fsf@netris.org> <87mugdbc9r.fsf@gnu.org> <8736i3iyas.fsf@devup.no> <87zhkbhd07.fsf@devup.no> <87v9uz4msh.fsf@netris.org> <87woffh66h.fsf@devup.no> <87o90pgzak.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:48175) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1hyfb7-00019Z-9I for bug-guix@gnu.org; Fri, 16 Aug 2019 13:01:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hyfb3-0001jT-Rk for bug-guix@gnu.org; Fri, 16 Aug 2019 13:01:03 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:46023) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hyfb3-0001jK-OG for bug-guix@gnu.org; Fri, 16 Aug 2019 13:01:01 -0400 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <87o90pgzak.fsf@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22'\?\= \=\?utf-8\?Q\?s\?\= message of "Fri, 16 Aug 2019 12:49:55 +0200") List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: "bug-Guix" To: Ludovic =?UTF-8?Q?Court=C3=A8s?= Cc: 36747@debbugs.gnu.org Hi Ludovic, Ludovic Court=C3=A8s 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 g= uile-static-stripped-2.2.4-i686-linux.tar.xz >>> 1acd8f83e27d2fac311a5ca78e9bf11a9a1638b82469870d5c854c4e7afaa26a l= inux-libre-headers-stripped-4.14.67-i686-linux.tar.xz >>> 021543d9bb6af55f39e68d69692e3cb74646ced2cad0bb9ac0047ef81e9d7330 m= escc-tools-static-stripped-0.5.2-i686-linux.tar.xz >>> fb32090071b39fc804fb9a7fba96f0bc5eb844a0efd268fb24c42e6bfa959de0 m= es-minimal-stripped-0.19-i686-linux.tar.xz >>> c80cdd17b0a24eebdd75570ff72c4ec06e129bd702ac008186b57f6301c448e7 s= tatic-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=E2=80=99t quite caught up yet, but I trust you and I can upload t= he > 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=3Di686-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=3Di686-li= nux bootstrap-tarballs /gnu/store/rdwyr8mh7dvhfkb5g4cws6q40hp23rbi-bootstrap-tarballs-0 mhw@jojen ~/guix-wip-binaries$ cd /gnu/store/rdwyr8mh7dvhfkb5g4cws6q40hp23r= bi-bootstrap-tarballs-0 mhw@jojen /gnu/store/rdwyr8mh7dvhfkb5g4cws6q40hp23rbi-bootstrap-tarballs-0$= sha256sum * 3e50c070a100b6bcf84c4bf5c868f9cd0a9fd1570f5d82fbfb78f8411959091b guile-sta= tic-stripped-2.2.4-i686-linux.tar.xz 1acd8f83e27d2fac311a5ca78e9bf11a9a1638b82469870d5c854c4e7afaa26a linux-lib= re-headers-stripped-4.14.67-i686-linux.tar.xz 021543d9bb6af55f39e68d69692e3cb74646ced2cad0bb9ac0047ef81e9d7330 mescc-too= ls-static-stripped-0.5.2-i686-linux.tar.xz fb32090071b39fc804fb9a7fba96f0bc5eb844a0efd268fb24c42e6bfa959de0 mes-minim= al-stripped-0.19-i686-linux.tar.xz c80cdd17b0a24eebdd75570ff72c4ec06e129bd702ac008186b57f6301c448e7 static-bi= naries-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