[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Jan Nieuwenhuizen
Subject: bug#36747: Official MesCC bootstrap binaries differ from my locally built ones
Date: Mon, 22 Jul 2019 08:18:55 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux)

Mark H Weaver writes:

Hi Mark,

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

Yes, I understand the last bit.  However, it is only now with my failure
to remove them that we found something possiblby fishy?  IWBN if we knew
that the hashes are reproducible before we remove them.  Hmm, that might
be a good argument to have two packages, a merely static/content
stripped version and a hashes-stripped version.

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

> 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

Right, that commit is two commits up or my core-updates branch @ gitlab

    https://gitlab.com/janneke/guix @ core-updates    

it's core-updates plus the two first patches I sent.  I could push a
wip-core-updates branch (but I'll first try the master thing, see

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

Ah, hadn't thought about that...

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

Hmm, I'm not sure how much work it would be.  If we're lucky then the
recipes from gnu/packages/bootstrap.scm for mescc-tools-static-stripped
and mes-minimal-stripped and their tarballs could be put into and used
on master to build.  I'll have a look into this.

If we could find how you can reproduce the current flawed hash-containing
bootstrap binaries that we have on core-updates, that would be nice...I'm
hoping for Ludo' to step in and say something insightful about the
differences you found :)


Jan Nieuwenhuizen <address@hidden> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

reply via email to

[Prev in Thread] Current Thread [Next in Thread]