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

[Mark H Weaver <mhw@netris.org>]

Hi Janneke,

Thanks very much for the quick response to this issue.

Jan Nieuwenhuizen <janneke@gnu.org> wrote:
> 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 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.

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:

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

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.

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?

     Thanks,
       Mark