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 below). > 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 :) janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | AvatarĀ® http://AvatarAcademy.com