Skip to content

Latest commit

 

History

History
1131 lines (814 loc) · 38.9 KB

INSTALL.org

File metadata and controls

1131 lines (814 loc) · 38.9 KB
Raw

Installing GNU Guix

Table of Contents

Introduction

NEWS FLASH: GNU Guix can be installed in one go on most Linux installations!

See the The one-step tarball installation below

Software packaging is part of the programmer’s toolbox. First and foremost, for development you need a dependable and reproducable environment. Second, to deploy software and test it you want dependable and reproducable environments. Few existing software package management systems can guarantee that.

GNU Guix is a next generation software package installer with a range of features, including sane dependency handling, transactional and reproducable installs which can be rolled back. In short, GNU Guix has resolved the fundamental problems of software deployment and management.

Here we list the fundamental Guix bootstrap options, and run through post-build installation.

Note that GuixSD is a fully blown Linux distribution in its own right. I find, however, that at this point I prefer a hybrid Debian/Guix system. GNU GuixSD is maturing fast, so you may want to give that a shot instead.

Install in conjunction with another package manager

It is to be expected that sometime the major package managers will install GNU Guix out of the box. Similar to allowing Docker, Perl or Python software packagers, there should be no exception for the GNU package manager. In fact, the GNU Guix is less intrusive than the others, since it does not install software in the same directories as the underlying package manager (such as apt or rpm). But, until the Linux distributions decide to include GNU Guix, we’ll have to use one of the other following options to install Guix inside an existing distribution.

Binary installation

A binary install is easy because all properly installed Guix packages are independent from the underlying distribution - a package can be created which contains a software with all its dependencies. The only real dependency is the (Linux) kernel. The fundamental Linux API does not change that often so a binary distribution can be copied from machine to machine. Of course, also the build target architecture has to match. With a binary distribution it is possible to simply unpack the package, create the build group and permissions.

The one-step tarball installation

Ricardo has written a nice introduction. Also the guix documentation may be more up-to-date. There may also be Docker images

In principle, fetch the GNU Guix binary tar ball from https://www.gnu.org/software/guix/download/ and unpack it in the root directory (note that it is an FTP server which may give problems with proxy setups). See also the Guix online instructions for up-to-date information. In principle

tar -C / --xz -xvf guix-binary-$(version).x86_64-linux.tar.xz

Add the guix-profile to the path

export PATH=~/.guix-profile/bin:$PATH

Start the daemon after creating the build users as described below.

From an existing GNU Guix installation

I thought I would be able to bootstrap using a USB image and copy that to a local hard disk.

To bootstrap I have successfully downloaded a GNU Guix tarball

wget http://alpha.gnu.org/gnu/guix/gnu-usb-install-$(version).x86_64-linux.xz
xz -d gnu-usb-install-$(version).x86_64-linux.xz

mount it with kpartx

kpartx -v -a gnu-usb-install-$(version).x86_64-linux
mkdir mnt
mkdir tmp
mount /dev/mapper/loop0p1 mnt
cp -vau mnt/gnu tmp
mv tmp/gnu/ /

Create build group and users

Now we have the /gnu/store in place we need to create a group and users with build permissions for the Guix daemon. In bash

builders=10
groupadd guixbuild
for i in `seq 1 $builders`; do
    useradd -g guixbuild -G guixbuild           \
        -d /var/empty -s `which nologin`          \
        -c "Guix build user $i" --system          \
        guix-builder$i;
done

(set the number of builders to the number of cores).

Also the store comes with meta-data in the form of a sqlite database. This sits in /var/guix. Copy also this directory to the new system before running guix.

Set the store permissions

This part is normally done automatically by the guix-daemon

chgrp guixbuild -R /gnu/store

Mounting /gnu elsewhere

The directory /gnu/store contains all packages. This is by design so that contents are reproducible (all paths a fully coded, there is no use for relative paths). Sometimes you want to move /gnu/store somewhere else. This is possble using mount –bind. This /etc/fstab entry will work

/export/gnu/store /gnu/store none defaults,bind 0 0

Start the GNU Guix daemon

Now you should be able to run Guix daemon and client directly from the store

/gnu/store/(...)-guix-(...)/bin/guix-daemon --build-users-group=guixbuild

and you should be able to use the client also from the store

/gnu/store/(...)-guix-(...)/bin/guix --help

Until root.guix-profile has been set, you may want to use this path directly. The Guix documentation suggests symlinking to /usr/local/bin, but this may confuse later work.

I first set the key and do a guix pull as discussed below.

Set the key

To enable binary installs you need to authorize it with a key which can be found with guix

guix archive --authorize < ~/.config/guix/current/share/guix/ci.guix.gnu.org.pub

Make sure to use the right key file. Note also that you can also call GNU Guix from its direct path, e.g.

/gnu/store/8lays(...)-guix-0.8.47739f5/bin/guix archive --authorize < /gnu/store/8lay(...)-guix-0.8.47739f5/share/guix/keyfile

Update the package list (guix pull)

(see the health warning at the end of this section)

guix pull

downloads the latest Guix source code and package descriptions, and deploys it. Update guix (do this as root so the daemon does not get garbage collected later).

guix package -i guix

you may want to restart the daemon after a successful upgrade.

Guix pull has options to fetch older versions of the tree using a git HASH. There is also guix ‘timemachine’ you can explore.

Use guix as a normal user

As a normal user you can now install software (see below install the hello package). Guix will ask you to install a dir for the user in var/guix/profiles/per-user. As root

mkdir /var/guix/profiles/per-user/pjotr
chown pjotr /var/guix/profiles/per-user/pjotr

Now run guix the first time from the store (using the path that the root version of guix has) and install guix client itself

su pjotr
/gnu/store/(...)guix(...)/bin/guix package -i guix

and update the path

export PATH=$HOME/.guix-profile/bin:$PATH
which guix

Install the hello package

guix package -i hello

  The following package will be installed:
    hello-2.9    out     /gnu/store/yfipxvqnibw17ncp4c828hhcwsbxc3d7-hello-2.9
  The following file will be downloaded:
    /gnu/store/yfipxvqnibw17ncp4c828hhcwsbxc3d7-hello-2.9
  found valid signature for '/gnu/store/yfipxvqnibw17ncp4c828hhcwsbxc3d7-hello-2.9', from 'http://hydra.gnu.org/nar/yfipxvqnibw17ncp4c828hhcwsbxc3d7-hello-2.9'
  downloading `/gnu/store/yfipxvqnibw17ncp4c828hhcwsbxc3d7-hello-2.9' from `http://hydra.gnu.org/nar/yfipxvqnibw17ncp4c828hhcwsbxc3d7-hello-2.9' (0.2 MiB installed)...
  http://hydra.gnu.org/nar/yfipxvqnibw17ncp4c828hhcwsbxc3d7-hello-2.9       43.0 KiB transferred2 packages in profile

did a binary install of the hello package. A symlink was created in ~/.guix-profile/bin/ pointing to /gnu/store/yfipxvqnibw17ncp4c828hhcwsbxc3d7-hello-2.9/bin/hello.

Note that you have the great luxury of interrupting GNU Guix at any point during build and installation. That is because it is TRANSACTION SAFE!

Another luxury is that you can copy packages from one dir/machine to another. It is SAFE because each package is isolated from another. Note: you may need to copy the dependencies too.

Add symlinks to the PATH

After adding to the path

export PATH=$HOME/.guix-profile/bin:$PATH

we can run

hello

  Hello, world!

Since GNU Guix development revolves around guile (the Scheme programming language) and emacs, let us install

guix package -i guile
guix package -i emacs

in both cases I got a successful install for guile and emacs.

To build a package from source, checkout the repository with git and run

./pre-inst-env guix build hello

downloaded a few more packages for building and compiled a new hello. This time with a different path, presumably because these are different dependencies. This we can check:

guix gc --references $(guix build hello)

  /gnu/store/1qf4rsznfhvdis39jzdmx0dfjy2jwzgz-gcc-4.8.3-lib
  /gnu/store/scmy8hnpccld0jszbgdw5csdc9z8f9jf-glibc-2.19
  /gnu/store/yfipxvqnibw17ncp4c828hhcwsbxc3d7-hello-2.9

To get the other one

guix gc --references /gnu/store/77dzhv9yx5x2rq370swp8scsps961pj6-hello-2.9

  /gnu/store/3h38sfay2f02rk4i768ci8xabl706rf9-glibc-2.20
  /gnu/store/px5ks6hyjszqp269l9b91354zjclv6c2-gcc-4.8.3-lib
  /gnu/store/77dzhv9yx5x2rq370swp8scsps961pj6-hello-2.9

And you can tell that the dependencies are not the same. It gets better. You can list the build dependencies too

guix gc --requisites /gnu/store/77dzhv9yx5x2rq370swp8scsps961pj6-hello-2.9

  /gnu/store/2sflarfdfpcjkywy4hwknwrwxmx4rrhi-glibc-2.20-locales
  /gnu/store/px5ks6hyjszqp269l9b91354zjclv6c2-gcc-4.8.3-lib
  /gnu/store/3h38sfay2f02rk4i768ci8xabl706rf9-glibc-2.20
  /gnu/store/77dzhv9yx5x2rq370swp8scsps961pj6-hello-2.9

How many package managers can achieve that?

Set locale

If you see the message

warning: failed to install locale: Invalid argument

it means your locale needs to be found. Guix comes with a small locale database

guix package -i glibc-locales

Set the GUIX_LOCPATH

export GUIX_LOCPATH=$HOME/.guix-profile/lib/locale

Choose one from

ls $GUIX_LOCPATH/2.22/
export LC_ALL=en_US.UTF-8

When you keep getting locale errors it may mean that you are actually running tools linked against a different glibc version (!2.22). Say you get an error with bash

ldd `which bash`

lists

libc.so.6 => /gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/lib/libc.so.6 (0x00007f4905aec000)

Aha, here we have version 2.23. You need to install also the locale that ends up in $GUIX_LOCPATH/2.23/

guix package -A locale
  glibc-locales   2.23    out     gnu/packages/base.scm:763:2
guix package -i glibc-locales@2.23

export GUIX_LOCPATH=~/.guix-profile/lib/locale/
export LC_ALL=en_GB.UTF-8

and all should be well - at least for tools installed with Guix.

Not recommended: set the LOCPATH to that of your underlying distribution - incompatibilities may exist. See also the Guix docs.

Fonts

When installing fonts they end up in ~/.guix-profile/share/fonts.

The fontconfig package contains utilities that help sort font issues. E.g.

fc-list

will show the fonts in scope which tend to be the underlying distribution’s.

fc-list :scalable=true:spacing=mono: family
FreeMono
xterm -fa "FreeMono:size=16:antialias=false"

or

fc-match fixed
n019003l.pfb: "Nimbus Sans L" "Regular"
xterm -fn 7x13 -fa "Nimbus Sans L:size=16"

another option I use is

xterm -fa Fixed-20

The majority of graphical applications uses Fontconfig to locate and load font and perform X11-client-side rendering. Guix’s address@hidden package looks for fonts in the user’s profile by default, so you have to install them there.

FIXME: but actually Fontconfig’s cache will have the host distro’s fonts listed, so maybe this is not a problem?

Please drop this as ~/.config/fontconfig/fonts.conf:

<fontconfig><dir>/run/current-system/profile/share/fonts</dir></fontconfig>

Probably the most comprehensive description of fonts can be found here. With GNU Guix the relevant dirs will be found in ~/.guix-profile.

SysV startup of Guix daemon

Guix comes with a script for systemd. For SysV’s startup I use /etc/init.d/guix-daemon which looks like

#!/bin/sh
### BEGIN INIT INFO
# Provides:          guix-daemon
# Required-Start:    mountdevsubfs
# Required-Stop:
# Should-Start:
# Should-Stop:
# X-Start-Before:
# X-Stop-After:
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
### END INIT INFO

SCRIPTNAME=/etc/init.d/guix-daemon

. /lib/lsb/init-functions

[ -x /root/.guix-profile/bin/guix-daemon ] || exit 0

do_start()
{
        # /root/.guix-profile/bin/guix-daemon --build-users-group=guixbuild 2>/dev/null || return 2
        /root/.guix-profile/bin/guix-daemon --build-users-group=guixbuild 2> /var/log/guix.log &
}

case "$1" in
  start)
        log_action_begin_msg "Setting up GNU Guix daemon"
        do_start
        case "$?" in
                0|1) log_action_end_msg 0 ;;
                2) log_action_end_msg 1 ;;
        esac
        ;;
  stop|restart|force-reload|status)
        log_action_begin_msg "Killing GNU Guix daemon"
        killall guix-daemon
        ;;
  *)
        echo "Usage: $SCRIPTNAME start" >&2
        exit 3
        ;;
esac

and (on Debian)

update-rc.d guix-daemon defaults

Building Guix from source

Before you try, read this

Note that above guix tarball binary installation is by far the easiest if your package manager does not support Guix by default. Every distribution contains its own dependencies which may interfere with a Guix source install. But then, some of us are more adventurous than others and you may need the git tree to package new software and work on reproducible builds.

Fetch repository with git

Use one of https://savannah.gnu.org/git/?group=guix and clone with sub modules:

git clone --recurse git://git.savannah.gnu.org/guix.git

when updating

git pull --recurse-submodules git-URI

A note on bootstrap from source

Bootstrapping from source, after checking out the git Guix source tree can be surprisingly tricky because of the build dependencies. Your mileage may vary, but currently I recommend starting from the tar-ball install described above instead and build Guix using Guix tools with an environment and profile (explained in the next section).

For building from source it is particularly important not to mix Guix and native dependencies. Also make sure you are using the proper localstatedir.

Building GNU Guix from source (using Guix) - the bullet proof way

This is my recommended route for building from source. It is a great route because it uses Guix packages isolated from the rest of the system using a Guix container (environment).

You can re-build and re-install Guix using a system that already runs Guix. To do so (copied from the Guix README). For example, after the binary tar install described above:

Install the dependencies and build tools using Guix:

Install packages after setting the path/environment with

. ~/.guix-profile/etc/profile
guix --version

Make sure you have a recent version.

And create the build environment using a recent guix with

guix environment -C guix --ad-hoc bash vim guile-json

The -C makes it a container. If you have run a guix pull you can do

~/.config/guix/current/bin/guix environment -C guix --ad-hoc bash vim guile-json

Tip: once you have built guix successfully you can also use the ./pre-inst-env prefix:

./pre-inst-env guix environment -C guix --ad-hoc bash vim guile-json

i.e., alternatively you can use any guix on your system and even create the environment by hand (this may be useful to get out of a pickle)

screen -S guix-build # I tend to build in screen
env -i /bin/bash --login --noprofile --norc
/gnu/store/h410qzgv3ilk9pivi1a99q0pq0dlzkki-guix-0.ver.0-5.228a398/bin/guix environment guix --ad-hoc help2man git strace \
  pkg-config less vim binutils coreutils grep guile guile-git gcc guile-json po4a guile-sqlite3 --no-grafts
bash # you may want this shell

Use the –no-grafts switch if you have built packages that way before to avoid triggering a full rebuild.

Note that you can opt to start guix by installing the binary tar ball, or copying it from another machine using the rather useful `guix archive’ or guix pack commands.

Now build it

You may want to take a note of these running versions

gcc --version
guile --version
rm -rf autom4te.cache/ # to be sure
make clean
./bootstrap
./configure --localstatedir=/var
make clean    # to be really sure
make clean-go # to be even surer
time make

Once you have done it you should be able to run

./pre-inst-env guix --version

In case of problems, on the mailing list it was suggested to actually clean everything, git clone a new repository as a test. Or, try this (warning: this will remove ALL untracked files and undo ALL changes):

make distclean
git clean -dfx
git reset --hard

the only other thing I can think to clean is your Guile ccache (although I don’t think it’s likely the cause), which I believe you can safely do with the following command:

 rm -rf ~/.cache/guile/ccache

Finally, especially if you do not use containers (-C switch) the safest route is by using guix environment after starting a clean shell (note environment does not clutter up your main profile because you get a temporary one!):

screen -S guix-build # I tend to build in screen
env -i /bin/bash --login --noprofile --norc

Alternative build route using a Guix profile

Note: this is a lesser option than using guix environment because there may be issues with a ‘polluted’ environment. Use above if you can.

Display the search paths and set them, e.g.

guix package --search-paths
export PATH="$HOME/.guix-profile/bin:$HOME/.guix-profile/sbin"
export INFOPATH="$HOME/.guix-profile/share/info"

Note that if you want full isolation you may want to use ‘guix environment’, but here we opt for the lazy version. E.g.

guix package --install autoconf automake bzip2 gcc-toolchain gettext \
                       guile libgcrypt pkg-config sqlite m4 make \
                       gnutls guile-json

I also run

guix package --install grep sed texinfo graphviz \
  binutils coreutils xz tar findutils gawk git

which may be used during build time.

In fact, I create a special (isolated) build profile using -p and add that to the PATH instead. I use -p $HOME/opt/guix-build-system so the full thing becomes (with some additional tools I use)

mkdir $HOME/opt
guix package -p $HOME/opt/guix-build-system --install autoconf \
   automake bzip2 gcc-toolchain gettext guile libgcrypt \
   pkg-config sqlite m4 make grep sed texinfo graphviz bash \
   help2man binutils coreutils xz tar findutils gawk git less \
   time which diffutils vim help2man gnutls guile-json
export PATH=$HOME/opt/guix-build-system/bin:$PATH
guix package -p ~/opt/guix-build-system --search-paths

Note You can also use your own caching server as described in REPRODUCIBLE.org.

Note that the –no-grafts should align with that of your caching server.

Set the Guix environment variables

Guix recommends you to set during the package installation process: ACLOCAL_PATH, CPATH, LIBRARY_PATH, PKG_CONFIG_PATH

You can view the environment variable definitions Guix recommends with

guix package --search-paths

or when using a profile

guix package -p ~/opt/guix-build-system --search-paths

To get rid of the LOCALE errors, do something like

export GUIX_LOCPATH=$HOME/.guix-profile/lib/locale
export LC_ALL=en_US.utf8

Mine are for the build system

export PATH="/home/pjotr/opt/guix-build-system/bin:/home/pjotr/opt/guix-build-system/sbin"
export ACLOCAL_PATH="/home/pjotr/opt/guix-build-system/share/aclocal"
export C_INCLUDE_PATH="/home/pjotr/opt/guix-build-system/include"
export CPLUS_INCLUDE_PATH="/home/pjotr/opt/guix-build-system/include"
export LIBRARY_PATH="/home/pjotr/opt/guix-build-system/lib"
export GUILE_LOAD_PATH="/home/pjotr/opt/guix-build-system/share/guile/site/2.0"
export GUILE_LOAD_COMPILED_PATH="/home/pjotr/opt/guix-build-system/lib/guile/2.0/site-ccache:/home/pjotr/opt/guix-build-system/share/guile/site/2.0"
export PKG_CONFIG_PATH="/home/pjotr/opt/guix-build-system/lib/pkgconfig"
export INFOPATH="/home/pjotr/opt/guix-build-system/share/info"
export BASH_LOADABLES_PATH="/home/pjotr/opt/guix-build-system/lib/bash"
export GIT_EXEC_PATH="/home/pjotr/opt/guix-build-system/libexec/git-core"

Check before build

Make sure the path is pointing to the build path

which env

should give

$HOME/opt/guix-build-system/bin/env

And build it

Re-run the ‘configure’ script passing it the option ‘–with-libgcrypt-prefix=$HOME/.guix-profile/’ if needed, as well as ‘–localstatedir=/somewhere’, where ‘/somewhere’ is the ‘localstatedir’ value of the currently installed Guix (failing to do that would lead the new Guix to consider the store to be empty!). E.g., the simple form

./configure --localstatedir=/var

If that did not work try recreating configure with bootstrap

./bootstrap
./configure --localstatedir=/var

Run `make’ (and optionally `make check’) every time you change something in the repository. Make can do parallel builds so for 4 cores

make clean ; time make

Those cores get used well! When you got to this point you can always rebuild the Guix tools from the git checkout of the master branch. All you need to do is (re)use the tools installed in ~/opt/guix-build-system/.

Troubleshooting

If you encounter problems at this stage, for example a missing autoreconf, it is probably because the PATHs have not been set correctly. Do not mix in paths from the underlying Linux distribution. They should show cleanly what

guix package -p ~/opt/guix-build-system --search-paths

suggests! Maybe check

set|grep guix

which should show the same environment.

And run it

You may want to avoid “make install” since it will probably install the guix binaries in /usr and you want to run it in the source dir with ./pre-inst-env, e.g.,

./pre-inst-env guix package -A ruby
  ruby    1.8.7-p374      out     gnu/packages/ruby.scm:156:2
  ruby    2.1.8   out     gnu/packages/ruby.scm:123:2
  ruby    2.2.4   out     gnu/packages/ruby.scm:104:2
  ruby    2.3.0   out     gnu/packages/ruby.scm:47:2
  ruby-activesupport      4.2.4   out     gnu/packages/ruby.scm:2466:2
  (... 137 more gems as per Feb 2016 ...)

At this point check whether the database path (localstatedir) was correct by checking what packages it can find and what packages you have installed with

./pre-inst-env guix package -I

And you can upgrade GNU Guix itself to the latest and greatest with

./pre-inst-env guix package -i guix

Now you may want to make sure the PATH only points to $HOME/.guix-profile/bin or, at least, that it comes first.

export PATH=$HOME/.guix-profile/bin:/usr/bin:/bin
set|grep guix

Run the latest guix server from the git repo

After building I run the latest version of the daemon (as root) with something similar to

env TMPDIR=/gnu/tmp ./pre-inst-env ./guix-daemon --build-users-group=guixbuild -c 6 -M 4

Note that this will not honour binary downloads because it won’t see the key - so for building only.

Without the pre-inst-env script the daemon won’t be able to find the substitute checker:

substitute: error: executing `/usr/local/libexec/guix/substitute': No such file or directory
guix package: error: build failed: substituter `substitute' died unexpectedly

If you get something like “error while loading shared libraries: libsqlite3.so.0: cannot open shared object file: No such file or directory” you may want to add the LD_LIBRARY_PATH to run the server after setting up the paths suggested by ‘guix package –search-paths’.

env LD_LIBRARY_PATH=$LIBRARY_PATH ./pre-inst-env ./guix-daemon --build-users-group=guixbuild

Alterneative build routes

Building GNU Guix from source (Debian native)

Note: I have used this option in a while.

Before autumn 2014, I was not successful in installing GNU Guix from source, in fact, to get GNU Guix running on Debian proved surprisingly hard. But with Guix 0.7 I got a working installation on Debian (building from the source tarball using Debian packages) and David and I created the first Ruby package in September 2014.

Even so, the recommended route is bootstrapping Guix from Guix in
Debian (see above section).

To do a Debian install make sure to remove all references to guix in the PATH and other settings. Use the full native dependencies too bootstrap from source. I.e.

export BASH=/bin/bash
export PATH=/usr/local/bin:/usr/bin:/bin
set|grep -i guix

With guix 0.7 and 0.8 I have built from source on Debian.

which guix
    /usr/local/bin/guix

guix --version
  guix (GNU Guix) 0.8

NOTE: When upgrading guix through guix (i.e., ‘guix package -i guix’) make sure the same metadata is seen by the new daemon! The old one may be using the /usr/local prefix, so the metadata will be in /usr/local/var/guix while the new one may expect the data in /var/guix. A symlink may solve it.

Bootstrap with Nix

No longer supported. It is possible to reintroduce a Nix package for GNU Guix, but the binary installer is just as convenient.

Bootstrap with Docker

Docker allows isolation of packages. For installing Docker follow the instructions on http://www.docker.com/. Docker should play well with Guix, though I have not tried it (yet). There is a description of a Docker install online.

The store /gnu/store can be mounted inside a Docker image. This not only allows sharing packages between docker images, but also gives the perspective of using Docker for bootstrapping Guix.

Note that Guix comes with its own container manager built-in. So you may not need Docker after all.

Sharing profiles

Guix has this amazing facility called ‘profiles’ (originally coming from Nix) which does away with hacks like Unix modules and Debian alternatives. Any user can create any number of profiles in his/her home directory to, for example, address the need of running different Python versions. For the use of profiles see the GNU Guix documentation.

One thing we like to do is share profiles. The current situation is to have one ‘master’ user on the system that can install profiles in /usr/local/guix-profiles and these can easily be used by others. So

guix package -p /usr/local/guix-profiles/shared-profile -i vim

and any user can add the profile to the path

export PATH="/usr/local/guix-profiles/shared-profile/bin:$PATH"

and run vim. On Debian we can use the alternative system to link to these again (as root)

cd /etc/alternatives
ln -s /usr/local/guix-profiles/shared-profile/bin/vi
ln -s /usr/local/guix-profiles/shared-profile/bin/view
ln -s /usr/local/guix-profiles/shared-profile/bin/vim

And now all users are all sharing the Guix installation of vim rather than then underlying Debian one.

Continue with Ruby installation and environment

See GNU Guix Ruby

Continue with Python installation and environment

See GNU Guix Python

Add your own package

See GNU Guix HACKING

Install GNU Guix system/software distribution (SD)

See GuixSD.org.

Trouble shooting

Failed to connect to daemon

If you get on a guix command

guix package: error: failed to connect to `/var/guix/daemon-socket/socket': Connection refused

it means the daemon is not running.

X.509 certificate error

E.g.

guix/build/download.scm:424:6: X.509 certificate of 'rubygems.org' could not be verified:
  insecure-algorithm
  signer-not-found
  invalid

When you get the X.509 certificate error it means that openssl can not find the certificates.

Install the certificates with

guix package -i nss-certs

and set the environment as suggested by Guix. E.g.,

export GIT_SSL_CAINFO="$HOME/.guix-profile/etc/ssl/certs/ca-certificates.crt${GIT_SSL_CAINFO:+:}$GIT_SSL_CAINFO"
export SSL_CERT_DIR="$HOME/.guix-profile/etc/ssl/certs${SSL_CERT_DIR:+:}$SSL_CERT_DIR"

If that does not work for git try

guix package -i nss-certs git
export PATH=$HOME/.guix-profile/bin:$PATH
export GIT_SSL_CAINFO="$HOME/.guix-profile/etc/ssl/certs/ca-certificates.crt"
export SSL_CERT_DIR="$HOME/.guix-profile/etc/ssl/certs"
~/.guix-profile/bin/git pull

to make sure all ducks are in a row.

Certificate search paths are a bit of a mess. I have found the following you can set depending on what is used:

ENV
SSL_CERT_FILE and SSL_CERT_DIRopenssl
ARVADOS_API_HOST_INSECUREarvados
HTTPLIB2_CA_CERTSpython-httplib2
GIT_SSL_CAINFOgit
CURL_CA_BUNDLEcurl

and the list goes on.

In a pinch you can override checking for certificates. Examples for git.

guix pull: error: Git error: the SSL certificate is invalid

Solution, see above X.509 certificate error

Guix complains about locales

Particularly on non-Guix distros it is possible to encounter during a build

Backtrace:
           2 (primitive-load "/gnu/store/k0pjy673zfsxl8sqwmqm7nvpsxc?")
In ice-9/eval.scm:
    619:8  1 (_ #f)
In unknown file:
           0 (setlocale 6 "en_US.utf8")

ERROR: In procedure setlocale:
In procedure setlocale: Invalid argument

The fix is to install the daemon with a locale and restart it from there, e.g. on Debian

~/opt/guix-latest/bin/guix package -i glibc-utf8-locales guix -p ~/opt/guix-daemon
cd ~
sudo opt/guix-daemon/bin/guix-daemon  --build-users-group=_guixbuild

error: build failed: substituter `substitute’ died unexpectedly

Make sure the keys are working. The real error appears to be related to the daemon loading libraries. Best is to revert the daemon to an older version already installed in the store. E.g.,

/gnu/store/0g9k45d7s5xak5mj2wqvahkphfgyxm4j-guix-0.10.0-0.7611/bin/guix-daemon  --build-users-group=guixbuild

and see if it fixes the problem. When it works take the opportunity to install a latest guix

./pre-inst-env guix package -i guix

so you can recover from that later.

ERROR: In procedure scm-error: no code for module (gcrypt hash)

Guix is built with Guile and Guile has trouble finding the gcrypt package. Fix it by installing guix in a profile and setting the LOAD PATHS, e.g.:

guix package -i guix -p ~/opt/guix

Look for

find ~/opt/guix/ -name gcrypt*

and

export GUILE_LOAD_PATH=~/opt/guix/share/guile/site/3.0
export GUILE_LOAD_COMPILED_PATH=~/opt/guix/lib/guile/3.0/site-ccache

or after a guix pull

export GUILE_LOAD_PATH=~/.config/guix/current/share/guile/site/3.0
export GUILE_LOAD_COMPILED_PATH=~/.config/guix/current/lib/guile/3.0/site-ccache

Note: Guix only recently moved to guile3! This means if you are dealing with different versions of guile it gets a bit more complicated. My trick is to have an older version of guix in ~/opt/guix-old and something like

export GUILE_LOAD_PATH=~/opt/guix-old/share/guile/site/2.2/
export GUILE_LOAD_COMPILED_PATH=~/opt/guix-old/share/guile/site/2.2/

error: hash-algorithm: unbound variable

Recent versions of Guix (May 2020) introduce this error for gcrypt. You’ll have to upgrade to a more recent version of Guix, perhaps using guix pull.

packages.scm error

This error means you have to upgrade the guix daemon:

guix/packages.scm:871:27: In procedure thunk:
guix/packages.scm:871:27: In procedure struct_vtable: Wrong type argument in position 1 (expecting struct): #f

In this case you may need the –no-grafts switch. See also the procedure described in bug#25775: Can’t install packages after guix pull.

When you run into unexplainable errors upgrading the guix daemon is a good thing to try anyway.

error while loading shared libraries: libgsl.so.23: cannot open shared object file: No such file or directory

You are probably not linking with ld-wrapper but are using a native /bin/ld

updating Guix - when all goes wrong

When you get stuck with Guix it may be possible to unpack the binary installation tarball from the main website and copy the files in gnu/store into your own store. Now you can run that guix from there

/gnu/store/hash-guix-version/bin/guix package -i guix

The resident database may or may not work (the database format does not change often). If the database fails, you can overwrite the database files in /var/guix, but note that when you run a garbage collect most files are not tracked and will be deleted.