If you want to hack Guix itself, it is recommended to use the latest version from the Git repository:
git clone https://git.savannah.gnu.org/git/guix.git
How do you ensure that you obtained a genuine copy of the repository?
To do that, run
guix git authenticate, passing it the commit
and OpenPGP fingerprint of the channel introduction
(see Invoking guix git authenticate):
git fetch origin keyring:keyring guix git authenticate 9edb3f66fd807b096b48283debdcddccfea34bad \ "BBB0 2DDF 2CEA F6A8 0D1D E643 A2A0 6DF2 A33A 54FA"
This command completes with exit code zero on success; it prints an error message and exits with a non-zero code otherwise.
As you can see, there is a chicken-and-egg problem: you first need to have Guix installed. Typically you would install Guix System (see System Installation) or Guix on top of another distro (see Binary Installation); in either case, you would verify the OpenPGP signature on the installation medium. This “bootstraps” the trust chain.
The easiest way to set up a development environment for Guix is, of course, by using Guix! The following command starts a new shell where all the dependencies and appropriate environment variables are set up to hack on Guix:
guix shell -D guix --pure
See Invoking guix shell, for more information on that command.
If you are unable to use Guix when building Guix from a checkout, the following are the required packages in addition to those mentioned in the installation instructions (see Requirements).
On Guix, extra dependencies can be added by instead running
guix shell -D guix help2man git strace --pure
From there you can generate the build system infrastructure using Autoconf and Automake:
If you get an error like this one:
configure.ac:46: error: possibly undefined macro: PKG_CHECK_MODULES
it probably means that Autoconf couldn’t find pkg.m4, which is provided by pkg-config. Make sure that pkg.m4 is available. The same holds for the guile.m4 set of macros provided by Guile. For instance, if you installed Automake in /usr/local, it wouldn’t look for .m4 files in /usr/share. In that case, you have to invoke the following command:
See Macro Search Path in The GNU Automake Manual, for more information.
... where /var is the normal
(see The Store, for information about this). Note that you will
probably not run
make install at the end (you don’t have to)
but it’s still important to pass the right
Finally, you can build Guix and, if you feel so inclined, run the tests (see Running the Test Suite):
make make check
If anything fails, take a look at installation instructions (see Installation) or send a message to the mailing list.
From there on, you can authenticate all the commits included in your checkout by running:
The first run takes a couple of minutes, but subsequent runs are faster.
Or, when your configuration for your local Git repository doesn’t match
the default one, you can provide the reference for the
branch through the variable
GUIX_GIT_KEYRING. The following
example assumes that you have a Git remote called ‘myremote’
pointing to the official repository:
make authenticate GUIX_GIT_KEYRING=myremote/keyring
Note: You are advised to run
make authenticateafter every
git pullinvocation. This ensures you keep receiving valid changes to the repository.
After updating the repository,
make might fail with an error
similar to the following example:
error: failed to load 'gnu/packages/dunst.scm': ice-9/eval.scm:293:34: In procedure abi-check: #<record-type <origin>>: record ABI mismatch; recompilation needed
This means that one of the record types that Guix defines (in this
origin record) has changed, and all of guix needs
to be recompiled to take that change into account. To do so, run
make clean-go followed by