Re: Problem bootstrapping Guix - "make update-guix-package" result: no code for module (gcrypt hash)

["Ludovic Courtès" <ludo@gnu.org>]

Hi Danny,

Danny Milosavljevic <dannym@scratchpost.org> skribis:

> I'm doing a project for Heads where we are trying to switch over their build
> system to something that makes their builds more reproducible (for example
> Guix).
>
> They are using github and gitlab test runners for a lot of things, so one of
> the ways we are trying to do continuous integration is to do the following:
>
> (1) Have guix-the-package-manager be built and published on
> repository.gitlab.com.  It eventually does "./pre-inst-env guix pack guix"
> and then puts the result into a new docker container.  I can't see how to do that
> after a guix pull.  Note that I don't want to also carry garbage (this entire
> thing has to be verified for security eventually, so...).  Currently, guix
> is being bootstrapped from Alpine, and I don't want Alpine to remain in there.

Why not just run “guix pack guix” with a “guix pull”-provided Guix?
You’d benefit from transparency and provenance tracking, the reduced
binary seeds, etc., which is very different from what you get by
building on top of Alpine.

If you need a specific Guix commit, you can also run:

  guix pack guix \
    --with-commit=guix=a2ed00f79fd5bf69c6cca3fa7bdc62726bf848fa \
    --with-git-url=guix=https://git.savannah.gnu.org/git/guix.git

You can still get test failures if there’s a problem on that commit, as
we’ve seen before, but apart from that it looks like what you need no?

(The ‘--with-git-url’ is only necessary because the default URL uses the
“dumb” transparent, which libgit2 apparently dislikes.)

> (2) Use the result in order to build boards using tiny Dockerfiles
> which would just say
>
>   FROM repository.gitlab.com/guix-on-docker
>   RUN guix build heads-kgpe-d16
>
> and throw away the derivation (or publish it, too?)--but keep the log file
> and exit status.

Then again, why even go through Docker?  You could just as well in one
go do:

  guix time-machine --commit=a2ed00f79fd5bf69c6cca3fa7bdc62726bf848fa -- \
    build heads-kgpe-d16

I’ve used Guix with GitLab-CI for instance, and it makes absolutely no
sense to me to resort to Docker if you already have Guix running.

> Note that (1) should pin a specific Guix commit for a long time since Heads
> does not want to build on a moving target since they do hash verification
> on bootup, and firmware is hard to keep working (i.e. someone has to
> manually verify, on real hardware, whether stuff still works after an
> update of the toolchain).  And Heads basically is ONLY security-relevant
> stuff.

An additional reason to avoid hopping through Alpine…

HTH!

Ludo’.