unofficial mirror of bug-guix@gnu.org 
 help / color / mirror / code / Atom feed
From: Mark H Weaver <mhw@netris.org>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: 36747@debbugs.gnu.org
Subject: bug#36747: Official MesCC bootstrap binaries differ from my locally built ones
Date: Fri, 16 Aug 2019 12:59:31 -0400	[thread overview]
Message-ID: <87mug9cagh.fsf@netris.org> (raw)
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")

Hi Ludovic,

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

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

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

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

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

Do you get the same results?

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

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

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

Thank you.

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

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

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

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

      Thanks,
        Mark

  reply	other threads:[~2019-08-16 17:01 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-20 22:43 bug#36747: Official MesCC bootstrap binaries differ from my locally built ones Mark H Weaver
2019-07-21 13:34 ` Jan Nieuwenhuizen
2019-07-22  0:56   ` Mark H Weaver
2019-07-22  6:18     ` Jan Nieuwenhuizen
2019-07-22  6:26       ` Jan Nieuwenhuizen
2019-07-22  8:26       ` Jan Nieuwenhuizen
2019-07-22  8:31       ` Mark H Weaver
2019-07-22 17:41         ` Jan Nieuwenhuizen
2019-07-23  5:42           ` Mark H Weaver
2019-07-23  6:28             ` Jan Nieuwenhuizen
2019-08-12  0:21               ` Mark H Weaver
2019-08-12  4:11                 ` Mark H Weaver
2019-07-23 10:03             ` Ludovic Courtès
2019-08-12  7:08               ` Mark H Weaver
2019-08-12  9:01                 ` Jan Nieuwenhuizen
2019-08-13  6:42                   ` Mark H Weaver
2019-08-13 10:17                     ` Jan Nieuwenhuizen
2019-08-14 15:03                       ` Marius Bakke
2019-08-14 17:29                         ` Marius Bakke
2019-08-14 18:35                           ` Mark H Weaver
2019-08-14 18:43                             ` Mark H Weaver
2019-08-14 19:56                             ` Marius Bakke
2019-08-14 20:43                               ` Mark H Weaver
2019-08-15 19:44                               ` Mark H Weaver
2019-08-15 21:19                                 ` Marius Bakke
2019-08-15 23:16                                   ` Mark H Weaver
2019-08-15 20:56                               ` Mark H Weaver
2019-08-16  7:42                                 ` Mark H Weaver
2019-08-17 16:49                                   ` Mark H Weaver
2019-08-16 10:49                               ` Ludovic Courtès
2019-08-16 16:59                                 ` Mark H Weaver [this message]
2019-08-17 21:38                                   ` Ludovic Courtès
2019-08-18  1:17                                     ` Mark H Weaver
2019-08-18  9:26                                       ` Ludovic Courtès
2019-08-20 18:40                                         ` Mark H Weaver
2019-08-21 20:15                                           ` Mark H Weaver
2019-08-21 21:38                                   ` Ludovic Courtès
2019-08-21 22:57                                     ` Mark H Weaver
2019-08-22 10:09                                       ` Ludovic Courtès
2019-08-24 13:31                               ` Ludovic Courtès
2019-08-24 20:34                                 ` Mark H Weaver
2019-08-26  8:25                                   ` Ludovic Courtès
2019-08-26 18:36                                     ` Mark H Weaver
2019-08-27  9:38                                       ` Ludovic Courtès
2019-08-29 22:28                                         ` Bengt Richter
2019-08-27  3:58                                     ` Mark H Weaver
2019-08-27  9:40                                       ` Ludovic Courtès
2019-08-27 14:27                                         ` Mark H Weaver
2019-08-27 16:04                                           ` Ludovic Courtès
2019-08-27 16:46                                             ` Mark H Weaver
2019-08-28  0:55                                               ` Mark H Weaver
2019-08-28 22:12                                                 ` Ludovic Courtès
2019-08-29  5:46                                                   ` Ricardo Wurmus
2019-08-29  6:32                                                     ` Ricardo Wurmus
2019-08-29 19:28                                                   ` Mark H Weaver
2019-08-29 23:23                                                     ` Ludovic Courtès
2019-08-30 19:52                                                       ` Mark H Weaver
2019-08-31 12:44                                                         ` Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87mug9cagh.fsf@netris.org \
    --to=mhw@netris.org \
    --cc=36747@debbugs.gnu.org \
    --cc=ludo@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).