bug#36747: Official MesCC bootstrap binaries differ from my locally built ones

[Ludovic Courtès]

Hi Mark,

Mark H Weaver <address@hidden> skribis:

> Ludovic Courtès <address@hidden> 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 <address@hidden>
> 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 <address@hidden>
> 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 <address@hidden>
> 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.

> I'm confident that this will make no difference to the set of packages
> that build successfully, modulo non-determistic build failures.  The
> only additional time it should require is the time needed for Berlin to
> rebuild the branch.
>
> Otherwise, 'core-updates-next' seems to be in good shape, and possibly
> almost ready to merge into 'master'.  I admit that this assessment is
> based solely on the fact that I'm currently using it on my own machine,
> and it works well.  Without Hydra's interface for comparing evaluations,
> I'm mostly blind to the status of the branch beyond of the set of
> packages I use myself.

I find that ‘guix weather -c’ gives a rather good overview of the
situation, though it’s not equivalent to comparing with another
evaluation.

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

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