Newer
Older
\input texinfo
@c -*-texinfo-*-
@c %**start of header
@setfilename guix.info
@documentencoding UTF-8
@c %**end of header
@include version.texi
Copyright @copyright{} 2012, 2013, 2014, 2015, 2016 Ludovic Courtès@*
Copyright @copyright{} 2013, 2014, 2016 Andreas Enge@*
Taylan Ulrich Bayırlı/Kammer
committed
Copyright @copyright{} 2013 Nikita Karetnikov@*
Copyright @copyright{} 2015, 2016 Mathieu Lirzin@*
Copyright @copyright{} 2014 Pierre-Antoine Rault@*
Copyright @copyright{} 2015 Taylan Ulrich Bayırlı/Kammer@*
Copyright @copyright{} 2015, 2016 Leo Famulari@*
Copyright @copyright{} 2016 Ben Woodcroft@*
Copyright @copyright{} 2016 Chris Marusich@*
Copyright @copyright{} 2016 Efraim Flashner
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.3 or
any later version published by the Free Software Foundation; with no
Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A
copy of the license is included in the section entitled ``GNU Free
Documentation License''.
@end copying
* Guix: (guix). Manage installed software and system configuration.
* guix package: (guix)Invoking guix package. Installing, removing, and upgrading packages.
* guix build: (guix)Invoking guix build. Building packages.
* guix gc: (guix)Invoking guix gc. Reclaiming unused disk space.
* guix pull: (guix)Invoking guix pull. Update the list of available packages.
* guix system: (guix)Invoking guix system. Manage the operating system configuration.
@dircategory Software development
@direntry
* guix environment: (guix)Invoking guix environment. Building development environments with Guix.
@dircategory Emacs
@direntry
* Guix user interface: (guix)Emacs Interface. Package management from the comfort of Emacs.
@end direntry
@title GNU Guix Reference Manual
@subtitle Using the GNU Guix Functional Package Manager
@author The GNU Guix Developers
@page
@vskip 0pt plus 1filll
Edition @value{EDITION} @*
@value{UPDATED} @*
@end titlepage
@contents
@c *********************************************************************
@node Top
This document describes GNU Guix version @value{VERSION}, a functional
package management tool written for the GNU system.
@menu
* Introduction:: What is Guix about?
* Installation:: Installing Guix.
* Package Management:: Package installation, upgrade, etc.
* Emacs Interface:: Using Guix from Emacs.
* Programming Interface:: Using Guix in Scheme.
* Utilities:: Package management commands.
* GNU Distribution:: Software for your friendly GNU system.
* Contributing:: Your help needed!
* Acknowledgments:: Thanks!
* GNU Free Documentation License:: The license of this manual.
* Concept Index:: Concepts.
* Programming Index:: Data types, functions, and variables.
@detailmenu
--- The Detailed Node Listing ---
Installation
* Binary Installation:: Getting Guix running in no time!
* Requirements:: Software needed to build and run Guix.
* Running the Test Suite:: Testing Guix.
* Setting Up the Daemon:: Preparing the build daemon's environment.
* Invoking guix-daemon:: Running the build daemon.
* Application Setup:: Application-specific setup.
Setting Up the Daemon
* Build Environment Setup:: Preparing the isolated build environment.
* Daemon Offload Setup:: Offloading builds to remote machines.
Package Management
* Features:: How Guix will make your life brighter.
* Invoking guix package:: Package installation, removal, etc.
* Substitutes:: Downloading pre-built binaries.
* Packages with Multiple Outputs:: Single source package, multiple outputs.
* Invoking guix gc:: Running the garbage collector.
* Invoking guix pull:: Fetching the latest Guix and distribution.
* Invoking guix archive:: Exporting and importing store files.
Emacs Interface
* Initial Setup: Emacs Initial Setup. Preparing @file{~/.emacs}.
* Package Management: Emacs Package Management. Managing packages and generations.
* Licenses: Emacs Licenses. Interface for licenses of Guix packages.
* Package Source Locations: Emacs Package Locations. Interface for package location files.
* Popup Interface: Emacs Popup Interface. Magit-like interface for guix commands.
* Prettify Mode: Emacs Prettify. Abbreviating @file{/gnu/store/@dots{}} file names.
* Build Log Mode: Emacs Build Log. Highlighting Guix build logs.
* Completions: Emacs Completions. Completing @command{guix} shell command.
* Development: Emacs Development. Tools for Guix developers.
* Hydra: Emacs Hydra. Interface for Guix build farm.
Programming Interface
* Defining Packages:: Defining new packages.
* Build Systems:: Specifying how packages are built.
* The Store:: Manipulating the package store.
* Derivations:: Low-level interface to package derivations.
* The Store Monad:: Purely functional interface to the store.
* G-Expressions:: Manipulating build expressions.
Defining Packages
* package Reference:: The package data type.
* origin Reference:: The origin data type.
Utilities
* Invoking guix build:: Building packages from the command line.
* Invoking guix download:: Downloading a file and printing its hash.
* Invoking guix hash:: Computing the cryptographic hash of a file.
* Invoking guix import:: Importing package definitions.
* Invoking guix refresh:: Updating package definitions.
* Invoking guix lint:: Finding errors in package definitions.
* Invoking guix graph:: Visualizing the graph of packages.
* Invoking guix environment:: Setting up development environments.
* Invoking guix publish:: Sharing substitutes.
* Invoking guix challenge:: Challenging substitute servers.
* Invoking guix container:: Process isolation.
Invoking @command{guix build}
* Common Build Options:: Build options for most commands.
* Package Transformation Options:: Creating variants of packages.
* Additional Build Options:: Options specific to 'guix build'.
GNU Distribution
* System Installation:: Installing the whole operating system.
* System Configuration:: Configuring the operating system.
* Installing Debugging Files:: Feeding the debugger.
* Security Updates:: Deploying security fixes quickly.
* Package Modules:: Packages from the programmer's viewpoint.
* Packaging Guidelines:: Growing the distribution.
* Bootstrapping:: GNU/Linux built from scratch.
* Porting:: Targeting another platform or kernel.
System Installation
* Limitations:: What you can expect.
* Hardware Considerations:: Supported hardware.
* USB Stick Installation:: Preparing the installation medium.
* Preparing for Installation:: Networking, partitioning, etc.
* Proceeding with the Installation:: The real thing.
* Building the Installation Image:: How this comes to be.
System Configuration
* Using the Configuration System:: Customizing your GNU system.
* operating-system Reference:: Detail of operating-system declarations.
* File Systems:: Configuring file system mounts.
* Mapped Devices:: Block device extra processing.
* User Accounts:: Specifying user accounts.
* Locales:: Language and cultural convention settings.
* Services:: Specifying system services.
* Setuid Programs:: Programs running with root privileges.
* X.509 Certificates:: Authenticating HTTPS servers.
* Name Service Switch:: Configuring libc's name service switch.
* Initial RAM Disk:: Linux-Libre bootstrapping.
* GRUB Configuration:: Configuring the boot loader.
* Invoking guix system:: Instantiating a system configuration.
* Running GuixSD in a VM:: How to run GuixSD in a virtual machine.
* Defining Services:: Adding new service definitions.
Services
* Base Services:: Essential system services.
* Scheduled Job Execution:: The mcron service.
* Networking Services:: Network setup, SSH daemon, etc.
* X Window:: Graphical display.
* Desktop Services:: D-Bus and desktop services.
* Database Services:: SQL databases.
* Web Services:: Web servers.
Defining Services
* Service Composition:: The model for composing services.
* Service Types and Services:: Types and services.
* Service Reference:: API reference.
* Shepherd Services:: A particular type of service.
* Software Freedom:: What may go into the distribution.
* Package Naming:: What's in a name?
* Version Numbers:: When the name is not enough.
* Synopses and Descriptions:: Helping users find the right package.
* Python Modules:: Taming the snake.
* Perl Modules:: Little pearls.
* Java Packages:: Coffee break.
Contributing
* Building from Git:: The latest and greatest.
* Running Guix Before It Is Installed:: Hacker tricks.
* The Perfect Setup:: The right tools.
* Coding Style:: Hygiene of the contributor.
* Submitting Patches:: Share your work.
Coding Style
* Programming Paradigm:: How to compose your elements.
* Modules:: Where to store your code?
* Data Types and Pattern Matching:: Implementing data structures.
* Formatting Code:: Writing conventions.
@end menu
@c *********************************************************************
@node Introduction
@chapter Introduction
GNU Guix@footnote{``Guix'' is pronounced like ``geeks'', or ``ɡiːks''
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
using the international phonetic alphabet (IPA).} is a package
management tool for the GNU system. Guix makes it easy for unprivileged
users to install, upgrade, or remove packages, to roll back to a
previous package set, to build packages from source, and generally
assists with the creation and maintenance of software environments.
@cindex user interfaces
Guix provides a command-line package management interface
(@pxref{Invoking guix package}), a set of command-line utilities
(@pxref{Utilities}), a visual user interface in Emacs (@pxref{Emacs
Interface}), as well as Scheme programming interfaces
(@pxref{Programming Interface}).
@cindex build daemon
Its @dfn{build daemon} is responsible for building packages on behalf of
users (@pxref{Setting Up the Daemon}) and for downloading pre-built
binaries from authorized sources (@pxref{Substitutes}).
@cindex extensibility of the distribution
@cindex customization of packages
Guix includes package definitions for many GNU and non-GNU packages, all
of which @uref{https://www.gnu.org/philosophy/free-sw.html, respect the
user's computing freedom}. It is @emph{extensible}: users can write
their own package definitions (@pxref{Defining Packages}) and make them
available as independent package modules (@pxref{Package Modules}). It
is also @emph{customizable}: users can @emph{derive} specialized package
definitions from existing ones, including from the command line
(@pxref{Package Transformation Options}).
@cindex Guix System Distribution
@cindex GuixSD
You can install GNU@tie{}Guix on top of an existing GNU/Linux system
where it complements the available tools without interference
(@pxref{Installation}), or you can use it as part of the standalone
@dfn{Guix System Distribution} or GuixSD (@pxref{GNU Distribution}).
With GNU@tie{}GuixSD, you @emph{declare} all aspects of the operating
system configuration and Guix takes care of instantiating the
configuration in a transactional, reproducible, and stateless fashion
(@pxref{System Configuration}).
@cindex functional package management
Under the hood, Guix implements the @dfn{functional package management}
discipline pioneered by Nix (@pxref{Acknowledgments}).
In Guix, the package build and installation process is seen
as a @emph{function}, in the mathematical sense. That function takes inputs,
Nikita Karetnikov
committed
such as build scripts, a compiler, and libraries, and
returns an installed package. As a pure function, its result depends
solely on its inputs---for instance, it cannot refer to software or
scripts that were not explicitly passed as inputs. A build function
Nikita Karetnikov
committed
always produces the same result when passed a given set of inputs. It
cannot alter the environment of the running system in
any way; for instance, it cannot create, modify, or delete files outside
of its build and installation directories. This is achieved by running
build processes in isolated environments (or @dfn{containers}), where only their
Nikita Karetnikov
committed
explicit inputs are visible.
The result of package build functions is @dfn{cached} in the file
system, in a special directory called @dfn{the store} (@pxref{The
Store}). Each package is installed in a directory of its own in the
store---by default under @file{/gnu/store}. The directory name contains
a hash of all the inputs used to build that package; thus, changing an
input yields a different directory name.
This approach is the foundation for the salient features of Guix: support
for transactional package upgrade and rollback, per-user installation, and
garbage collection of packages (@pxref{Features}).
@c *********************************************************************
@node Installation
@chapter Installation
GNU Guix is available for download from its website at
@url{http://www.gnu.org/software/guix/}. This section describes the
software requirements of Guix, as well as how to install it and get
ready to use it.
Note that this section is concerned with the installation of the package
manager, which can be done on top of a running GNU/Linux system. If,
instead, you want to install the complete GNU operating system,
@pxref{System Installation}.
@cindex foreign distro
When installed on a running GNU/Linux system---thereafter called a
@dfn{foreign distro}---GNU@tie{}Guix complements the available tools
without interference. Its data lives exclusively in two directories,
usually @file{/gnu/store} and @file{/var/guix}; other files on your
system, such as @file{/etc}, are left untouched.
* Binary Installation:: Getting Guix running in no time!
* Requirements:: Software needed to build and run Guix.
* Running the Test Suite:: Testing Guix.
* Setting Up the Daemon:: Preparing the build daemon's environment.
* Invoking guix-daemon:: Running the build daemon.
* Application Setup:: Application-specific setup.
@node Binary Installation
@section Binary Installation
This section describes how to install Guix on an arbitrary system from a
self-contained tarball providing binaries for Guix and for all its
dependencies. This is often quicker than installing from source, which
is described in the next sections. The only requirement is to have
GNU@tie{}tar and Xz.
Installing goes along these lines:
@enumerate
@item
Download the binary tarball from
@indicateurl{ftp://alpha.gnu.org/gnu/guix/guix-binary-@value{VERSION}.@var{system}.tar.xz},
where @var{system} is @code{x86_64-linux} for an @code{x86_64} machine
already running the kernel Linux, and so on.
Make sure to download the associated @file{.sig} file and to verify the
authenticity of the tarball against it, along these lines:
@example
$ wget ftp://alpha.gnu.org/gnu/guix/guix-binary-@value{VERSION}.@var{system}.tar.xz.sig
$ gpg --verify guix-binary-@value{VERSION}.@var{system}.tar.xz.sig
@end example
If that command fails because you do not have the required public key,
then run this command to import it:
@example
$ gpg --keyserver pgp.mit.edu --recv-keys 090B11993D9AEBB5
@end example
@noindent
and rerun the @code{gpg --verify} command.
@item
As @code{root}, run:
@example
# tar --warning=no-timestamp -xf \
guix-binary-@value{VERSION}.@var{system}.tar.xz
# mv var/guix /var/ && mv gnu /
@end example
This creates @file{/gnu/store} (@pxref{The Store}) and @file{/var/guix}.
The latter contains a ready-to-use profile for @code{root} (see next
step.)
Do @emph{not} unpack the tarball on a working Guix system since that
would overwrite its own essential files.
The @code{--warning=no-timestamp} option makes sure GNU@tie{}tar does
not emit warnings about ``implausibly old time stamps'' (such
warnings were triggered by GNU@tie{}tar 1.26 and older; recent
versions are fine.)
They stem from the fact that all the
files in the archive have their modification time set to zero (which
means January 1st, 1970.) This is done on purpose to make sure the
archive content is independent of its creation time, thus making it
reproducible.
@item
Make @code{root}'s profile available under @file{~/.guix-profile}:
@example
# ln -sf /var/guix/profiles/per-user/root/guix-profile \
~root/.guix-profile
@end example
@item
Create the group and user accounts for build users as explained below
(@pxref{Build Environment Setup}).
Run the daemon, and set it to automatically start on boot.
If your host distro uses the systemd init system, this can be achieved
with these commands:
@example
# cp ~root/.guix-profile/lib/systemd/system/guix-daemon.service \
/etc/systemd/system/
# systemctl start guix-daemon && systemctl enable guix-daemon
@end example
If your host distro uses the Upstart init system:
# cp ~root/.guix-profile/lib/upstart/system/guix-daemon.conf /etc/init/
# start guix-daemon
@end example
Otherwise, you can still start the daemon manually with:
@example
# ~root/.guix-profile/bin/guix-daemon --build-users-group=guixbuild
@end example
@item
Make the @command{guix} command available to other users on the machine,
for instance with:
@example
# mkdir -p /usr/local/bin
# cd /usr/local/bin
# ln -s /var/guix/profiles/per-user/root/guix-profile/bin/guix
It is also a good idea to make the Info version of this manual available
there:
@example
# mkdir -p /usr/local/share/info
# cd /usr/local/share/info
# for i in /var/guix/profiles/per-user/root/guix-profile/share/info/* ;
do ln -s $i ; done
@end example
That way, assuming @file{/usr/local/share/info} is in the search path,
running @command{info guix} will open this manual (@pxref{Other Info
Directories,,, texinfo, GNU Texinfo}, for more details on changing the
Info search path.)
To use substitutes from @code{hydra.gnu.org} or one of its mirrors
(@pxref{Substitutes}), authorize them:
# guix archive --authorize < ~root/.guix-profile/share/guix/hydra.gnu.org.pub
@end enumerate
This completes root-level install of Guix. Each user will need to
perform additional steps to make their Guix envionment ready for use,
@pxref{Application Setup}.
You can confirm that Guix is working by installing a sample package into
the root profile:
@end example
The @code{guix} package must remain available in @code{root}'s profile,
or it would become subject to garbage collection---in which case you
would find yourself badly handicapped by the lack of the @command{guix}
command. In other words, do not remove @code{guix} by running
@code{guix package -r guix}.
The binary installation tarball can be (re)produced and verified simply
by running the following command in the Guix source tree:
@example
make guix-binary.@var{system}.tar.xz
@end example
@node Requirements
@section Requirements
This section lists requirements when building Guix from source. The
build procedure for Guix is the same as for other GNU software, and is
not covered here. Please see the files @file{README} and @file{INSTALL}
in the Guix source tree for additional details.
GNU Guix depends on the following packages:
@itemize
@item @url{http://gnu.org/software/guile/, GNU Guile}, version 2.0.7 or later;
@item @url{http://gnupg.org/, GNU libgcrypt};
@item @url{http://www.gnu.org/software/make/, GNU Make}.
@end itemize
The following dependencies are optional:
@itemize
@item
Installing @uref{http://gnutls.org/, GnuTLS-Guile} will allow you to
access @code{https} URLs for substitutes, which is highly recommended
(@pxref{Substitutes}). It also allows you to access HTTPS URLs with the
@command{guix download} command (@pxref{Invoking guix download}), the
@command{guix import pypi} command, and the @command{guix import cpan}
command. @xref{Guile Preparations, how to install the GnuTLS bindings
for Guile,, gnutls-guile, GnuTLS-Guile}.
@url{http://savannah.nongnu.org/projects/guile-json/, Guile-JSON} will
allow you to use the @command{guix import pypi} command (@pxref{Invoking
guix import}). It is of
interest primarily for developers and not for casual users.
@end itemize
Unless @code{--disable-daemon} was passed to @command{configure}, the
following packages are also needed:
@itemize
@item @url{http://sqlite.org, SQLite 3};
@item @url{http://www.bzip.org, libbz2};
@item @url{http://gcc.gnu.org, GCC's g++}, with support for the
C++11 standard.
When configuring Guix on a system that already has a Guix installation,
be sure to specify the same state directory as the existing installation
using the @code{--localstatedir} option of the @command{configure}
script (@pxref{Directory Variables, @code{localstatedir},, standards,
GNU Coding Standards}). The @command{configure} script protects against
unintended misconfiguration of @var{localstatedir} so you do not
inadvertently corrupt your store (@pxref{The Store}).
Nikita Karetnikov
committed
When a working installation of @url{http://nixos.org/nix/, the Nix package
manager} is available, you
can instead configure Guix with @code{--disable-daemon}. In that case,
Nikita Karetnikov
committed
Nix replaces the three dependencies above.
Guix is compatible with Nix, so it is possible to share the same store
between both. To do so, you must pass @command{configure} not only the
same @code{--with-store-dir} value, but also the same
Nikita Karetnikov
committed
@code{--localstatedir} value. The latter is essential because it
specifies where the database that stores metadata about the store is
located, among other things. The default values for Nix are
@code{--with-store-dir=/nix/store} and @code{--localstatedir=/nix/var}.
Nikita Karetnikov
committed
Note that @code{--disable-daemon} is not required if
your goal is to share the store with Nix.
@node Running the Test Suite
@section Running the Test Suite
After a successful @command{configure} and @code{make} run, it is a good
idea to run the test suite. It can help catch issues with the setup or
environment, or bugs in Guix itself---and really, reporting test
failures is a good way to help improve the software. To run the test
suite, type:
@example
make check
@end example
Test cases can run in parallel: you can use the @code{-j} option of
GNU@tie{}make to speed things up. The first run may take a few minutes
on a recent machine; subsequent runs will be faster because the store
that is created for test purposes will already have various things in
cache.
It is also possible to run a subset of the tests by defining the
@code{TESTS} makefile variable as in this example:
@example
make check TESTS="tests/store.scm tests/cpio.scm"
@end example
By default, tests results are displayed at a file level. In order to
see the details of every individual test cases, it is possible to define
the @code{SCM_LOG_DRIVER_FLAGS} makefile variable as in this example:
@example
make check TESTS="tests/base64.scm" SCM_LOG_DRIVER_FLAGS="--brief=no"
@end example
Upon failure, please email @email{bug-guix@@gnu.org} and attach the
@file{test-suite.log} file. Please specify the Guix version being used
as well as version numbers of the dependencies (@pxref{Requirements}) in
your message.
Guix also comes with a whole-system test suite that tests complete
GuixSD operating system instances. It can only run on systems where
Guix is already installed, using:
@example
make check-system
@end example
@noindent
or, again, by defining @code{TESTS} to select a subset of tests to run:
@example
make check-system TESTS="basic mcron"
@end example
These system tests are defined in the @code{(gnu tests @dots{})}
modules. They work by running the operating systems under test with
lightweight instrumentation in a virtual machine (VM). They can be
computationally intensive or rather cheap, depending on whether
substitutes are available for their dependencies (@pxref{Substitutes}).
Some of them require a lot of storage space to hold VM images.
Again in case of test failures, please send @email{bug-guix@@gnu.org}
all the details.
@node Setting Up the Daemon
@section Setting Up the Daemon
@cindex daemon
Operations such as building a package or running the garbage collector
are all performed by a specialized process, the @dfn{build daemon}, on
behalf of clients. Only the daemon may access the store and its
associated database. Thus, any operation that manipulates the store
goes through the daemon. For instance, command-line tools such as
@command{guix package} and @command{guix build} communicate with the
daemon (@i{via} remote procedure calls) to instruct it what to do.
The following sections explain how to prepare the build daemon's
environment. See also @ref{Substitutes}, for information on how to allow
the daemon to download pre-built binaries.
@menu
* Build Environment Setup:: Preparing the isolated build environment.
* Daemon Offload Setup:: Offloading builds to remote machines.
@end menu
@node Build Environment Setup
@subsection Build Environment Setup
In a standard multi-user setup, Guix and its daemon---the
@command{guix-daemon} program---are installed by the system
administrator; @file{/gnu/store} is owned by @code{root} and
@command{guix-daemon} runs as @code{root}. Unprivileged users may use
Guix tools to build packages or otherwise access the store, and the
daemon will do it on their behalf, ensuring that the store is kept in a
consistent state, and allowing built packages to be shared among users.
@cindex build users
When @command{guix-daemon} runs as @code{root}, you may not want package
build processes themselves to run as @code{root} too, for obvious
security reasons. To avoid that, a special pool of @dfn{build users}
should be created for use by build processes started by the daemon.
These build users need not have a shell and a home directory: they will
just be used when the daemon drops @code{root} privileges in build
processes. Having several such users allows the daemon to launch
distinct build processes under separate UIDs, which guarantees that they
do not interfere with each other---an essential feature since builds are
regarded as pure functions (@pxref{Introduction}).
On a GNU/Linux system, a build user pool may be created like this (using
Bash syntax and the @code{shadow} commands):
@c See http://lists.gnu.org/archive/html/bug-guix/2013-01/msg00239.html
@c for why `-G' is needed.
# groupadd --system guixbuild
# for i in `seq -w 1 10`;
useradd -g guixbuild -G guixbuild \
-d /var/empty -s `which nologin` \
-c "Guix build user $i" --system \
guixbuilder$i;
done
@end example
@noindent
The number of build users determines how many build jobs may run in
parallel, as specified by the @option{--max-jobs} option
(@pxref{Invoking guix-daemon, @option{--max-jobs}}). To use
@command{guix system vm} and related commands, you may need to add the
build users to the @code{kvm} group so they can access @file{/dev/kvm},
using @code{-G guixbuild,kvm} instead of @code{-G guixbuild}
(@pxref{Invoking guix system}).
The @code{guix-daemon} program may then be run as @code{root} with the
following command@footnote{If your machine uses the systemd init system,
dropping the @file{@var{prefix}/lib/systemd/system/guix-daemon.service}
file in @file{/etc/systemd/system} will ensure that
@command{guix-daemon} is automatically started. Similarly, if your
machine uses the Upstart init system, drop the
@file{@var{prefix}/lib/upstart/system/guix-daemon.conf}
file in @file{/etc/init}.}:
# guix-daemon --build-users-group=guixbuild
@cindex chroot
@noindent
This way, the daemon starts build processes in a chroot, under one of
the @code{guixbuilder} users. On GNU/Linux, by default, the chroot
environment contains nothing but:
@c Keep this list in sync with libstore/build.cc! -----------------------
@itemize
@item
a minimal @code{/dev} directory, created mostly independently from the
host @code{/dev}@footnote{``Mostly'', because while the set of files
that appear in the chroot's @code{/dev} is fixed, most of these files
can only be created if the host has them.};
@item
the @code{/proc} directory; it only shows the processes of the container
since a separate PID name space is used;
@item
@file{/etc/passwd} with an entry for the current user and an entry for
user @file{nobody};
@item
@file{/etc/group} with an entry for the user's group;
@item
@file{/etc/hosts} with an entry that maps @code{localhost} to
@code{127.0.0.1};
@item
a writable @file{/tmp} directory.
@end itemize
You can influence the directory where the daemon stores build trees
@i{via} the @code{TMPDIR} environment variable. However, the build tree
within the chroot is always called @file{/tmp/guix-build-@var{name}.drv-0},
where @var{name} is the derivation name---e.g., @code{coreutils-8.24}.
This way, the value of @code{TMPDIR} does not leak inside build
environments, which avoids discrepancies in cases where build processes
capture the name of their build tree.
@vindex http_proxy
The daemon also honors the @code{http_proxy} environment variable for
HTTP downloads it performs, be it for fixed-output derivations
(@pxref{Derivations}) or for substitutes (@pxref{Substitutes}).
If you are installing Guix as an unprivileged user, it is still possible
to run @command{guix-daemon} provided you pass @code{--disable-chroot}.
However, build processes will not be isolated from one another, and not
from the rest of the system. Thus, build processes may interfere with
each other, and may access programs, libraries, and other files
available on the system---making it much harder to view them as
@emph{pure} functions.
@node Daemon Offload Setup
@subsection Using the Offload Facility
@cindex offloading
@cindex build hook
When desired, the build daemon can @dfn{offload}
derivation builds to other machines
running Guix, using the @code{offload} @dfn{build hook}. When that
feature is enabled, a list of user-specified build machines is read from
@file{/etc/guix/machines.scm}; every time a build is requested, for
instance via @code{guix build}, the daemon attempts to offload it to one
of the machines that satisfy the constraints of the derivation, in
particular its system type---e.g., @file{x86_64-linux}. Missing
prerequisites for the build are copied over SSH to the target machine,
which then proceeds with the build; upon success the output(s) of the
build are copied back to the initial machine.
The @file{/etc/guix/machines.scm} file typically looks like this:
@example
(list (build-machine
(name "eightysix.example.org")
(system "x86_64-linux")
(user "bob")
(speed 2.)) ; incredibly fast!
(build-machine
(name "meeps.example.org")
(system "mips64el-linux")
(user "alice")
(private-key
(string-append (getenv "HOME")
@end example
@noindent
In the example above we specify a list of two build machines, one for
the @code{x86_64} architecture and one for the @code{mips64el}
architecture.
In fact, this file is---not surprisingly!---a Scheme file that is
evaluated when the @code{offload} hook is started. Its return value
must be a list of @code{build-machine} objects. While this example
shows a fixed list of build machines, one could imagine, say, using
DNS-SD to return a list of potential build machines discovered in the
local network (@pxref{Introduction, Guile-Avahi,, guile-avahi, Using
Avahi in Guile Scheme Programs}). The @code{build-machine} data type is
detailed below.
This data type represents build machines to which the daemon may offload
builds. The important fields are:
@table @code
@item name
The system type of the remote machine---e.g., @code{"x86_64-linux"}.
@item user
The user account to use when connecting to the remote machine over SSH.
Note that the SSH key pair must @emph{not} be passphrase-protected, to
allow non-interactive logins.
@end table
A number of optional fields may be specified:
Port number of SSH server on the machine (default: 22).
@item private-key
The SSH private key file to use when connecting to the machine.
Currently offloading uses GNU@tie{}lsh as its SSH client
(@pxref{Invoking lsh,,, GNU lsh Manual}). Thus, the key file here must
be an lsh key file. This may change in the future, though.
@item parallel-builds
The number of builds that may run in parallel on the machine (1 by
default.)
@item speed
A ``relative speed factor''. The offload scheduler will tend to prefer
machines with a higher speed factor.
@item features
A list of strings denoting specific features supported by the machine.
An example is @code{"kvm"} for machines that have the KVM Linux modules
and corresponding hardware support. Derivations can request features by
name, and they will be scheduled on matching build machines.
@end table
The @code{guix} command must be in the search path on the build
machines, since offloading works by invoking the @code{guix archive} and
@code{guix build} commands. In addition, the Guix modules must be in
@code{$GUILE_LOAD_PATH} on the build machine---you can check whether
this is the case by running:
@example
lsh build-machine guile -c "'(use-modules (guix config))'"
There is one last thing to do once @file{machines.scm} is in place. As
explained above, when offloading, files are transferred back and forth
between the machine stores. For this to work, you first need to
generate a key pair on each machine to allow the daemon to export signed
archives of files from the store (@pxref{Invoking guix archive}):
@example
# guix archive --generate-key
@end example
@noindent
Each build machine must authorize the key of the master machine so that
it accepts store items it receives from the master:
@example
# guix archive --authorize < master-public-key.txt
@end example
@noindent
Likewise, the master machine must authorize the key of each build machine.
All the fuss with keys is here to express pairwise mutual trust
relations between the master and the build machines. Concretely, when
the master receives files from a build machine (and @i{vice versa}), its
build daemon can make sure they are genuine, have not been tampered
with, and that they are signed by an authorized key.
@node Invoking guix-daemon
@section Invoking @command{guix-daemon}
The @command{guix-daemon} program implements all the functionality to
access the store. This includes launching build processes, running the
garbage collector, querying the availability of a build result, etc. It
is normally run as @code{root} like this:
@example
# guix-daemon --build-users-group=guixbuild
@end example
@noindent
For details on how to set it up, @pxref{Setting Up the Daemon}.
@cindex chroot
@cindex container, build environment
@cindex build environment
@cindex reproducible builds
By default, @command{guix-daemon} launches build processes under
different UIDs, taken from the build group specified with
@code{--build-users-group}. In addition, each build process is run in a
chroot environment that only contains the subset of the store that the
build process depends on, as specified by its derivation
(@pxref{Programming Interface, derivation}), plus a set of specific
system directories. By default, the latter contains @file{/dev} and
@file{/dev/pts}. Furthermore, on GNU/Linux, the build environment is a
@dfn{container}: in addition to having its own file system tree, it has
a separate mount name space, its own PID name space, network name space,
etc. This helps achieve reproducible builds (@pxref{Features}).
When the daemon performs a build on behalf of the user, it creates a
build directory under @file{/tmp} or under the directory specified by
its @code{TMPDIR} environment variable; this directory is shared with
the container for the duration of the build. Be aware that using a
directory other than @file{/tmp} can affect build results---for example,
with a longer directory name, a build process that uses Unix-domain
sockets might hit the name length limitation for @code{sun_path}, which
it would otherwise not hit.
The build directory is automatically deleted upon completion, unless the
build failed and the client specified @option{--keep-failed}
(@pxref{Invoking guix build, @option{--keep-failed}}).
The following command-line options are supported:
@table @code
@item --build-users-group=@var{group}
Take users from @var{group} to run build processes (@pxref{Setting Up
the Daemon, build users}).
Do not use substitutes for build products. That is, always build things
locally instead of allowing downloads of pre-built binaries
(@pxref{Substitutes}).
By default substitutes are used, unless the client---such as the
@command{guix package} command---is explicitly invoked with
@code{--no-substitutes}.
When the daemon runs with @code{--no-substitutes}, clients can still
explicitly enable substitution @i{via} the @code{set-build-options}
remote procedure call (@pxref{The Store}).
@item --substitute-urls=@var{urls}
@anchor{daemon-substitute-urls}
Consider @var{urls} the default whitespace-separated list of substitute
source URLs. When this option is omitted,
@indicateurl{https://mirror.hydra.gnu.org https://hydra.gnu.org} is used
(@code{mirror.hydra.gnu.org} is a mirror of @code{hydra.gnu.org}).
This means that substitutes may be downloaded from @var{urls}, as long
as they are signed by a trusted signature (@pxref{Substitutes}).
@cindex build hook
@item --no-build-hook
Do not use the @dfn{build hook}.
The build hook is a helper program that the daemon can start and to
which it submits build requests. This mechanism is used to offload
builds to other machines (@pxref{Daemon Offload Setup}).
@item --cache-failures
Cache build failures. By default, only successful builds are cached.
When this option is used, @command{guix gc --list-failures} can be used
to query the set of store items marked as failed; @command{guix gc
--clear-failures} removes store items from the set of cached failures.
@xref{Invoking guix gc}.
@item --cores=@var{n}
@itemx -c @var{n}
Use @var{n} CPU cores to build each derivation; @code{0} means as many
as available.
The default value is @code{0}, but it may be overridden by clients, such
as the @code{--cores} option of @command{guix build} (@pxref{Invoking
guix build}).
The effect is to define the @code{NIX_BUILD_CORES} environment variable
in the build process, which can then use it to exploit internal
parallelism---for instance, by running @code{make -j$NIX_BUILD_CORES}.
@item --max-jobs=@var{n}
@itemx -M @var{n}
Allow at most @var{n} build jobs in parallel. The default value is
@code{1}. Setting it to @code{0} means that no builds will be performed
locally; instead, the daemon will offload builds (@pxref{Daemon Offload
Setup}), or simply fail.
@item --rounds=@var{N}
Build each derivation @var{n} times in a row, and raise an error if
consecutive build results are not bit-for-bit identical. Note that this
setting can be overridden by clients such as @command{guix build}
(@pxref{Invoking guix build}).
When used in conjunction with @option{--keep-failed}, the differing
output is kept in the store, under @file{/gnu/store/@dots{}-check}.
This makes it easy to look for differences between the two results.
@item --debug
Produce debugging output.
This is useful to debug daemon start-up issues, but then it may be
overridden by clients, for example the @code{--verbosity} option of
@command{guix build} (@pxref{Invoking guix build}).
@item --chroot-directory=@var{dir}
Add @var{dir} to the build chroot.
Doing this may change the result of build processes---for instance if
they use optional dependencies found in @var{dir} when it is available,
and not otherwise. For that reason, it is not recommended to do so.
Instead, make sure that each derivation declares all the inputs that it
needs.
@item --disable-chroot
Disable chroot builds.
Using this option is not recommended since, again, it would allow build
processes to gain access to undeclared dependencies. It is necessary,
though, when @command{guix-daemon} is running under an unprivileged user
account.
@item --disable-log-compression
Disable compression of the build logs.
Unless @code{--lose-logs} is used, all the build logs are kept in the
@var{localstatedir}. To save space, the daemon automatically compresses
them with bzip2 by default. This option disables that.
Ludovic Courtès
committed
@item --disable-deduplication
@cindex deduplication
Disable automatic file ``deduplication'' in the store.
By default, files added to the store are automatically ``deduplicated'':
Ludovic Courtès
committed
if a newly added file is identical to another one found in the store,
the daemon makes the new file a hard link to the other file. This can
noticeably reduce disk usage, at the expense of slightly increased
Ludovic Courtès
committed
input/output load at the end of a build process. This option disables
this optimization.
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
@item --gc-keep-outputs[=yes|no]
Tell whether the garbage collector (GC) must keep outputs of live
derivations.
When set to ``yes'', the GC will keep the outputs of any live derivation
available in the store---the @code{.drv} files. The default is ``no'',
meaning that derivation outputs are kept only if they are GC roots.
@item --gc-keep-derivations[=yes|no]
Tell whether the garbage collector (GC) must keep derivations
corresponding to live outputs.
When set to ``yes'', as is the case by default, the GC keeps
derivations---i.e., @code{.drv} files---as long as at least one of their
outputs is live. This allows users to keep track of the origins of
items in their store. Setting it to ``no'' saves a bit of disk space.
Note that when both @code{--gc-keep-derivations} and
@code{--gc-keep-outputs} are used, the effect is to keep all the build
prerequisites (the sources, compiler, libraries, and other build-time
tools) of live objects in the store, regardless of whether these
prerequisites are live. This is convenient for developers since it
saves rebuilds or downloads.
@item --impersonate-linux-2.6
On Linux-based systems, impersonate Linux 2.6. This means that the
kernel's @code{uname} system call will report 2.6 as the release number.
This might be helpful to build programs that (usually wrongfully) depend
on the kernel version number.
@item --lose-logs
Do not keep build logs. By default they are kept under
@code{@var{localstatedir}/guix/log}.
@item --system=@var{system}
Assume @var{system} as the current system type. By default it is the
architecture/kernel pair found at configure time, such as
@code{x86_64-linux}.
@item --listen=@var{socket}
Listen for connections on @var{socket}, the file name of a Unix-domain
socket. The default socket is
@file{@var{localstatedir}/daemon-socket/socket}. This option is only
useful in exceptional circumstances, such as if you need to run several
daemons on the same machine.
@node Application Setup
@section Application Setup
@cindex foreign distro
When using Guix on top of GNU/Linux distribution other than GuixSD---a
so-called @dfn{foreign distro}---a few additional steps are needed to
get everything in place. Here are some of them.
@anchor{locales-and-locpath}
@cindex locales, when not on GuixSD
@vindex GUIX_LOCPATH
Packages installed @i{via} Guix will not use the locale data of the
host system. Instead, you must first install one of the locale packages
available with Guix and then define the @code{GUIX_LOCPATH} environment
variable:
@example
$ guix package -i glibc-locales
$ export GUIX_LOCPATH=$HOME/.guix-profile/lib/locale
@end example
Note that the @code{glibc-locales} package contains data for all the
locales supported by the GNU@tie{}libc and weighs in at around
110@tie{}MiB. Alternatively, the @code{glibc-utf8-locales} is smaller but
limited to a few UTF-8 locales.
The @code{GUIX_LOCPATH} variable plays a role similar to @code{LOCPATH}
(@pxref{Locale Names, @code{LOCPATH},, libc, The GNU C Library Reference
Manual}). There are two important differences though:
@enumerate
@item
@code{GUIX_LOCPATH} is honored only by the libc in Guix, and not by the libc
provided by foreign distros. Thus, using @code{GUIX_LOCPATH} allows you
to make sure the programs of the foreign distro will not end up loading
incompatible locale data.
@item
libc suffixes each entry of @code{GUIX_LOCPATH} with @code{/X.Y}, where
@code{X.Y} is the libc version---e.g., @code{2.22}. This means that,
should your Guix profile contain a mixture of programs linked against
different libc version, each libc version will only try to load locale
data in the right format.
@end enumerate
This is important because the locale data format used by different libc
versions may be incompatible.
The majority of graphical applications use Fontconfig to locate and
load fonts and perform X11-client-side rendering. The @code{fontconfig}
package in Guix looks for fonts in @file{$HOME/.guix-profile}
by default. Thus, to allow graphical applications installed with Guix
to display fonts, you have to install fonts with Guix as well.
Essential font packages include @code{gs-fonts}, @code{font-dejavu}, and
To display text written in Chinese languages, Japanese, or Korean in
graphical applications, consider installing
@code{font-adobe-source-han-sans} or @code{font-wqy-zenhei}. The former
has multiple outputs, one per language family (@pxref{Packages with
Multiple Outputs}). For instance, the following command installs fonts
for Chinese languages:
@example
guix package -i font-adobe-source-han-sans:cn
@end example
@subsection X.509 Certificates
The @code{nss-certs} package provides X.509 certificates, which allow
programs to authenticate Web servers accessed over HTTPS.
When using Guix on a foreign distro, you can install this package and
define the relevant environment variables so that packages know where to
look for certificates. @pxref{X.509 Certificates}, for detailed
information.
@subsection Emacs Packages
When you install Emacs packages with Guix, the elisp files may be placed
either in @file{$HOME/.guix-profile/share/emacs/site-lisp/} or in
sub-directories of
@file{$HOME/.guix-profile/share/emacs/site-lisp/guix.d/}. The latter
directory exists because potentially there may exist thousands of Emacs
packages and storing all their files in a single directory may be not
reliable (because of name conflicts). So we think using a separate
directory for each package is a good idea. It is very similar to how
the Emacs package system organizes the file structure (@pxref{Package
Files,,, emacs, The GNU Emacs Manual}).
By default, Emacs (installed with Guix) ``knows'' where these packages
are placed, so you do not need to perform any configuration. If, for
some reason, you want to avoid auto-loading Emacs packages installed
with Guix, you can do so by running Emacs with @code{--no-site-file}
option (@pxref{Init File,,, emacs, The GNU Emacs Manual}).
@c *********************************************************************
@node Package Management
@chapter Package Management
The purpose of GNU Guix is to allow users to easily install, upgrade, and
remove software packages, without having to know about their build
procedures or dependencies. Guix also goes beyond this obvious set of
features.
This chapter describes the main features of Guix, as well as the package
management tools it provides. Two user interfaces are provided for
routine package management tasks: A command-line interface described below
(@pxref{Invoking guix package, @code{guix package}}), as well as a visual user
interface in Emacs described in a subsequent chapter (@pxref{Emacs Interface}).
@menu
* Features:: How Guix will make your life brighter.
* Invoking guix package:: Package installation, removal, etc.
* Substitutes:: Downloading pre-built binaries.
* Packages with Multiple Outputs:: Single source package, multiple outputs.
* Invoking guix gc:: Running the garbage collector.
* Invoking guix pull:: Fetching the latest Guix and distribution.
* Invoking guix archive:: Exporting and importing store files.
@end menu
@node Features
@section Features
When using Guix, each package ends up in the @dfn{package store}, in its
own directory---something that resembles
@file{/gnu/store/xxx-package-1.2}, where @code{xxx} is a base32 string
(note that Guix comes with an Emacs extension to shorten those file
Instead of referring to these directories, users have their own
@dfn{profile}, which points to the packages that they actually want to
use. These profiles are stored within each user's home directory, at
@code{$HOME/.guix-profile}.
For example, @code{alice} installs GCC 4.7.2. As a result,
@file{/home/alice/.guix-profile/bin/gcc} points to
@file{/gnu/store/@dots{}-gcc-4.7.2/bin/gcc}. Now, on the same machine,
@code{bob} had already installed GCC 4.8.0. The profile of @code{bob}
simply continues to point to
@file{/gnu/store/@dots{}-gcc-4.8.0/bin/gcc}---i.e., both versions of GCC
coexist on the same system without any interference.
The @command{guix package} command is the central tool to manage
packages (@pxref{Invoking guix package}). It operates on the per-user
profiles, and can be used @emph{with normal user privileges}.
The command provides the obvious install, remove, and upgrade
operations. Each invocation is actually a @emph{transaction}: either
the specified operation succeeds, or nothing happens. Thus, if the
@command{guix package} process is terminated during the transaction,
or if a power outage occurs during the transaction, then the user's
profile remains in its previous state, and remains usable.
In addition, any package transaction may be @emph{rolled back}. So, if,
for example, an upgrade installs a new version of a package that turns
out to have a serious bug, users may roll back to the previous instance
of their profile, which was known to work well. Similarly, the global
system configuration on GuixSD is subject to
transactional upgrades and roll-back
(@pxref{Using the Configuration System}).
All packages in the package store may be @emph{garbage-collected}.
Guix can determine which packages are still referenced by user
profiles, and remove those that are provably no longer referenced
(@pxref{Invoking guix gc}). Users may also explicitly remove old
generations of their profile so that the packages they refer to can be
collected.
@cindex reproducibility
@cindex reproducible builds
Finally, Guix takes a @dfn{purely functional} approach to package
management, as described in the introduction (@pxref{Introduction}).
Each @file{/gnu/store} package directory name contains a hash of all the
inputs that were used to build that package---compiler, libraries, build
scripts, etc. This direct correspondence allows users to make sure a
given package installation matches the current state of their
distribution. It also helps maximize @dfn{build reproducibility}:
thanks to the isolated build environments that are used, a given build
is likely to yield bit-identical files when performed on different
machines (@pxref{Invoking guix-daemon, container}).
This foundation allows Guix to support @dfn{transparent binary/source
deployment}. When a pre-built binary for a @file{/gnu/store} item is
available from an external source---a @dfn{substitute}, Guix just
downloads it and unpacks it;
otherwise, it builds the package from source, locally
(@pxref{Substitutes}). Because build results are usually bit-for-bit
reproducible, users do not have to trust servers that provide
substitutes: they can force a local build and @emph{challenge} providers
(@pxref{Invoking guix challenge}).
Control over the build environment is a feature that is also useful for
developers. The @command{guix environment} command allows developers of
a package to quickly set up the right development environment for their
package, without having to manually install the dependencies of the
package into their profile (@pxref{Invoking guix environment}).
@node Invoking guix package
@section Invoking @command{guix package}
The @command{guix package} command is the tool that allows users to
install, upgrade, and remove packages, as well as rolling back to
previous configurations. It operates only on the user's own profile,
and works with normal user privileges (@pxref{Features}). Its syntax
is:
@example
guix package @var{options}
Primarily, @var{options} specifies the operations to be performed during
the transaction. Upon completion, a new profile is created, but
previous @dfn{generations} of the profile remain available, should the user
want to roll back.
For example, to remove @code{lua} and install @code{guile} and
@code{guile-cairo} in a single transaction:
@example
guix package -r lua -i guile guile-cairo
@end example
@command{guix package} also supports a @dfn{declarative approach}
whereby the user specifies the exact set of packages to be available and
passes it @i{via} the @option{--manifest} option
(@pxref{profile-manifest, @option{--manifest}}).
For each user, a symlink to the user's default profile is automatically
created in @file{$HOME/.guix-profile}. This symlink always points to the
current generation of the user's default profile. Thus, users can add
@file{$HOME/.guix-profile/bin} to their @code{PATH} environment
variable, and so on.
@cindex search paths
If you are not using the Guix System Distribution, consider adding the
following lines to your @file{~/.bash_profile} (@pxref{Bash Startup
Files,,, bash, The GNU Bash Reference Manual}) so that newly-spawned
shells get all the right environment variable definitions:
@example
GUIX_PROFILE="$HOME/.guix-profile" \
source "$HOME/.guix-profile/etc/profile"
@end example
In a multi-user setup, user profiles are stored in a place registered as
a @dfn{garbage-collector root}, which @file{$HOME/.guix-profile} points
to (@pxref{Invoking guix gc}). That directory is normally
@code{@var{localstatedir}/profiles/per-user/@var{user}}, where
@var{localstatedir} is the value passed to @code{configure} as
@code{--localstatedir}, and @var{user} is the user name. The
@file{per-user} directory is created when @command{guix-daemon} is
started, and the @var{user} sub-directory is created by @command{guix
package}.
The @var{options} can be among the following:
@item --install=@var{package} @dots{}
@itemx -i @var{package} @dots{}
Install the specified @var{package}s.
Each @var{package} may specify either a simple package name, such as
@code{guile}, or a package name followed by an at-sign and version number,
such as @code{guile@@1.8.8} or simply @code{guile@@1.8} (in the latter
case, the newest version prefixed by @code{1.8} is selected.)
If no version number is specified, the
newest available version will be selected. In addition, @var{package}
may contain a colon, followed by the name of one of the outputs of the
package, as in @code{gcc:doc} or @code{binutils@@2.22:lib}
(@pxref{Packages with Multiple Outputs}). Packages with a corresponding
name (and optionally version) are searched for among the GNU
distribution modules (@pxref{Package Modules}).
@cindex propagated inputs
Sometimes packages have @dfn{propagated inputs}: these are dependencies
that automatically get installed along with the required package
(@pxref{package-propagated-inputs, @code{propagated-inputs} in
@code{package} objects}, for information about propagated inputs in
package definitions).
An example is the GNU MPC library: its C header files refer to those of
the GNU MPFR library, which in turn refer to those of the GMP library.
Thus, when installing MPC, the MPFR and GMP libraries also get installed
in the profile; removing MPC also removes MPFR and GMP---unless they had
Besides, packages sometimes rely on the definition of environment
variables for their search paths (see explanation of
@code{--search-paths} below). Any missing or possibly incorrect
environment variable definitions are reported here.
@item --install-from-expression=@var{exp}
@itemx -e @var{exp}
Install the package @var{exp} evaluates to.
@var{exp} must be a Scheme expression that evaluates to a
@code{<package>} object. This option is notably useful to disambiguate
between same-named variants of a package, with expressions such as
@code{(@@ (gnu packages base) guile-final)}.
Note that this option installs the first output of the specified
package, which may be insufficient when needing a specific output of a
multiple-output package.
@item --install-from-file=@var{file}
@itemx -f @var{file}
Install the package that the code within @var{file} evaluates to.
As an example, @var{file} might contain a definition like this
(@pxref{Defining Packages}):
@example
@verbatiminclude package-hello.scm
@end example
Developers may find it useful to include such a @file{guix.scm} file
in the root of their project source tree that can be used to test
development snapshots and create reproducible development environments
(@pxref{Invoking guix environment}).
@item --remove=@var{package} @dots{}
@itemx -r @var{package} @dots{}
Remove the specified @var{package}s.
As for @code{--install}, each @var{package} may specify a version number
and/or output name in addition to the package name. For instance,
@code{-r glibc:debug} would remove the @code{debug} output of
@code{glibc}.
@item --upgrade[=@var{regexp} @dots{}]
@itemx -u [@var{regexp} @dots{}]
Upgrade all the installed packages. If one or more @var{regexp}s are
specified, upgrade only installed packages whose name matches a
@var{regexp}. Also see the @code{--do-not-upgrade} option below.
Note that this upgrades package to the latest version of packages found
in the distribution currently installed. To update your distribution,
you should regularly run @command{guix pull} (@pxref{Invoking guix
pull}).
@item --do-not-upgrade[=@var{regexp} @dots{}]
When used together with the @code{--upgrade} option, do @emph{not}
upgrade any packages whose name matches a @var{regexp}. For example, to
upgrade all packages in the current profile except those containing the
substring ``emacs'':
@example
$ guix package --upgrade . --do-not-upgrade emacs
@end example
@item @anchor{profile-manifest}--manifest=@var{file}
@cindex profile declaration
@cindex profile manifest
Create a new generation of the profile from the manifest object
returned by the Scheme code in @var{file}.
This allows you to @emph{declare} the profile's contents rather than
constructing it through a sequence of @code{--install} and similar
commands. The advantage is that @var{file} can be put under version
control, copied to different machines to reproduce the same profile, and
so on.
@c FIXME: Add reference to (guix profile) documentation when available.
@var{file} must return a @dfn{manifest} object, which is roughly a list
of packages:
(use-package-modules guile emacs)
@item --roll-back
Roll back to the previous @dfn{generation} of the profile---i.e., undo
the last transaction.
When combined with options such as @code{--install}, roll back occurs
before any other actions.
Ludovic Courtès
committed
When rolling back from the first generation that actually contains
installed packages, the profile is made to point to the @dfn{zeroth
generation}, which contains no files apart from its own metadata.
Ludovic Courtès
committed
After having rolled back, installing, removing, or upgrading packages
overwrites previous future generations. Thus, the history of the
generations in a profile is always linear.
@item --switch-generation=@var{pattern}
@itemx -S @var{pattern}
Switch to a particular generation defined by @var{pattern}.
@var{pattern} may be either a generation number or a number prefixed
with ``+'' or ``-''. The latter means: move forward/backward by a
specified number of generations. For example, if you want to return to
the latest generation after @code{--roll-back}, use
@code{--switch-generation=+1}.
The difference between @code{--roll-back} and
@code{--switch-generation=-1} is that @code{--switch-generation} will
not make a zeroth generation, so if a specified generation does not
exist, the current generation will not be changed.
@item --search-paths[=@var{kind}]
@cindex search paths
Report environment variable definitions, in Bash syntax, that may be
needed in order to use the set of installed packages. These environment
variables are used to specify @dfn{search paths} for files used by some
of the installed packages.
For example, GCC needs the @code{CPATH} and @code{LIBRARY_PATH}
environment variables to be defined so it can look for headers and
libraries in the user's profile (@pxref{Environment Variables,,, gcc,
Using the GNU Compiler Collection (GCC)}). If GCC and, say, the C
library are installed in the profile, then @code{--search-paths} will
suggest setting these variables to @code{@var{profile}/include} and
@code{@var{profile}/lib}, respectively.
The typical use case is to define these environment variables in the
shell:
@example
$ eval `guix package --search-paths`
@end example
@var{kind} may be one of @code{exact}, @code{prefix}, or @code{suffix},
meaning that the returned environment variable definitions will either
be exact settings, or prefixes or suffixes of the current value of these
variables. When omitted, @var{kind} defaults to @code{exact}.
This option can also be used to compute the @emph{combined} search paths
of several profiles. Consider this example:
@example
$ guix package -p foo -i guile
$ guix package -p bar -i guile-json
$ guix package -p foo -p bar --search-paths
@end example
The last command above reports about the @code{GUILE_LOAD_PATH}
variable, even though, taken individually, neither @file{foo} nor
@file{bar} would lead to that recommendation.
@item --profile=@var{profile}
@itemx -p @var{profile}
Use @var{profile} instead of the user's default profile.
Ludovic Courtès
committed
@item --verbose
Produce verbose output. In particular, emit the build log of the
environment on the standard error port.
Ludovic Courtès
committed
@item --bootstrap
Use the bootstrap Guile to build the profile. This option is only
useful to distribution developers.
@end table
In addition to these actions, @command{guix package} supports the
following options to query the current state of a profile, or the
availability of packages:
@item --search=@var{regexp}
@itemx -s @var{regexp}
@cindex searching for packages
List the available packages whose name, synopsis, or description matches
@var{regexp}. Print all the metadata of matching packages in
@code{recutils} format (@pxref{Top, GNU recutils databases,, recutils,
GNU recutils manual}).
This allows specific fields to be extracted using the @command{recsel}
command, for instance:
@example
$ guix package -s malloc | recsel -p name,version
name: glibc
version: 2.17
name: libgc
version: 7.2alpha6
@end example
Similarly, to show the name of all the packages available under the
terms of the GNU@tie{}LGPL version 3:
@example
$ guix package -s "" | recsel -p name -e 'license ~ "LGPL 3"'
name: elfutils
name: gmp
@dots{}
@end example
It is also possible to refine search results using several @code{-s}
flags. For example, the following command returns a list of board
games:
@example
$ guix package -s '\<board\>' -s game | recsel -p name
name: gnubg
@dots{}
@end example
If we were to omit @code{-s game}, we would also get software packages
that deal with printed circuit boards; removing the angle brackets
around @code{board} would further add packages that have to do with
keyboards.
And now for a more elaborate example. The following command searches
for cryptographic libraries, filters out Haskell, Perl, Python, and Ruby
libraries, and prints the name and synopsis of the matching packages:
@example
$ guix package -s crypto -s library | \
recsel -e '! (name ~ "^(ghc|perl|python|ruby)")' -p name,synopsis
@end example
@noindent
@xref{Selection Expressions,,, recutils, GNU recutils manual}, for more
information on @dfn{selection expressions} for @code{recsel -e}.
1673
1674
1675
1676
1677
1678
1679
1680
1681
1682
1683
1684
1685
1686
1687
1688
1689
1690
1691
1692
1693
1694
1695
1696
@item --show=@var{package}
Show details about @var{package}, taken from the list of available packages, in
@code{recutils} format (@pxref{Top, GNU recutils databases,, recutils, GNU
recutils manual}).
@example
$ guix package --show=python | recsel -p name,version
name: python
version: 2.7.6
name: python
version: 3.3.5
@end example
You may also specify the full name of a package to only get details about a
specific version of it:
@example
$ guix package --show=python-3.3.5 | recsel -p name,version
name: python
version: 3.3.5
@end example
@item --list-installed[=@var{regexp}]
@itemx -I [@var{regexp}]
List the currently installed packages in the specified profile, with the
most recently installed packages shown last. When @var{regexp} is
specified, list only installed packages whose name matches @var{regexp}.
For each installed package, print the following items, separated by
tabs: the package name, its version string, the part of the package that
is installed (for instance, @code{out} for the default output,
@code{include} for its headers, etc.), and the path of this package in
the store.
@item --list-available[=@var{regexp}]
@itemx -A [@var{regexp}]
List packages currently available in the distribution for this system
(@pxref{GNU Distribution}). When @var{regexp} is specified, list only
installed packages whose name matches @var{regexp}.
For each package, print the following items separated by tabs: its name,
its version string, the parts of the package (@pxref{Packages with
Multiple Outputs}), and the source location of its definition.
@item --list-generations[=@var{pattern}]
@itemx -l [@var{pattern}]
Return a list of generations along with their creation dates; for each
generation, show the installed packages, with the most recently
installed packages shown last. Note that the zeroth generation is never
shown.
For each installed package, print the following items, separated by
tabs: the name of a package, its version string, the part of the package
that is installed (@pxref{Packages with Multiple Outputs}), and the
location of this package in the store.
When @var{pattern} is used, the command returns only matching
generations. Valid patterns include:
@itemize
@item @emph{Integers and comma-separated integers}. Both patterns denote
generation numbers. For instance, @code{--list-generations=1} returns
the first one.
And @code{--list-generations=1,8,2} outputs three generations in the
specified order. Neither spaces nor trailing commas are allowed.
@item @emph{Ranges}. @code{--list-generations=2..9} prints the
specified generations and everything in between. Note that the start of
It is also possible to omit the endpoint. For example,
@code{--list-generations=2..}, returns all generations starting from the
second one.
@item @emph{Durations}. You can also get the last @emph{N}@tie{}days, weeks,
or months by passing an integer along with the first letter of the
Ludovic Courtès
committed
duration. For example, @code{--list-generations=20d} lists generations
that are up to 20 days old.
@end itemize
@item --delete-generations[=@var{pattern}]
@itemx -d [@var{pattern}]
Ludovic Courtès
committed
When @var{pattern} is omitted, delete all generations except the current
one.
This command accepts the same patterns as @option{--list-generations}.
Ludovic Courtès
committed
When @var{pattern} is specified, delete the matching generations. When
@var{pattern} specifies a duration, generations @emph{older} than the
specified duration match. For instance, @code{--delete-generations=1m}
deletes generations that are more than one month old.
If the current generation matches, it is @emph{not} deleted. Also, the
zeroth generation is never deleted.
Note that deleting generations prevents rolling back to them.
Consequently, this command must be used with care.
Finally, since @command{guix package} may actually start build
processes, it supports all the common build options (@pxref{Common Build
Options}). It also supports package transformation options, such as
@option{--with-source} (@pxref{Package Transformation Options}).
However, note that package transformations are lost when upgrading; to
preserve transformations across upgrades, you should define your own
package variant in a Guile module and add it to @code{GUIX_PACKAGE_PATH}
(@pxref{Defining Packages}).
@node Substitutes
@section Substitutes
@cindex substitutes
@cindex pre-built binaries
Guix supports transparent source/binary deployment, which means that it
can either build things locally, or download pre-built items from a
server. We call these pre-built items @dfn{substitutes}---they are
substitutes for local build results. In many cases, downloading a
substitute is much faster than building things locally.
Substitutes can be anything resulting from a derivation build
(@pxref{Derivations}). Of course, in the common case, they are
pre-built package binaries, but source tarballs, for instance, which
also result from derivation builds, can be available as substitutes.
The @code{hydra.gnu.org} server is a front-end to a build farm that
builds packages from the GNU distribution continuously for some
architectures, and makes them available as substitutes (@pxref{Emacs
Hydra}, for information on how to query the continuous integration
server). This is the
default source of substitutes; it can be overridden by passing the
@option{--substitute-urls} option either to @command{guix-daemon}
(@pxref{daemon-substitute-urls,, @code{guix-daemon --substitute-urls}})
or to client tools such as @command{guix package}
(@pxref{client-substitute-urls,, client @option{--substitute-urls}
option}).
Substitute URLs can be either HTTP or HTTPS@footnote{For HTTPS access,
the Guile bindings of GnuTLS must be installed. @xref{Requirements}.}
HTTPS is recommended because communications are encrypted; conversely,
using HTTP makes all communications visible to an eavesdropper, who
could use the information gathered to determine, for instance, whether
your system has unpatched security vulnerabilities.
@cindex security
@cindex digital signatures
To allow Guix to download substitutes from @code{hydra.gnu.org} or a
mirror thereof, you
1824
1825
1826
1827
1828
1829
1830
1831
1832
1833
1834
1835
1836
1837
1838
1839
1840
1841
1842
1843
1844
1845
1846
1847
1848
1849
1850
1851
1852
1853
1854
1855
1856
1857
1858
1859
1860
1861
1862
1863
1864
1865
1866
1867
1868
1869
1870
must add its public key to the access control list (ACL) of archive
imports, using the @command{guix archive} command (@pxref{Invoking guix
archive}). Doing so implies that you trust @code{hydra.gnu.org} to not
be compromised and to serve genuine substitutes.
This public key is installed along with Guix, in
@code{@var{prefix}/share/guix/hydra.gnu.org.pub}, where @var{prefix} is
the installation prefix of Guix. If you installed Guix from source,
make sure you checked the GPG signature of
@file{guix-@value{VERSION}.tar.gz}, which contains this public key file.
Then, you can run something like this:
@example
# guix archive --authorize < hydra.gnu.org.pub
@end example
Once this is in place, the output of a command like @code{guix build}
should change from something like:
@example
$ guix build emacs --dry-run
The following derivations would be built:
/gnu/store/yr7bnx8xwcayd6j95r2clmkdl1qh688w-emacs-24.3.drv
/gnu/store/x8qsh1hlhgjx6cwsjyvybnfv2i37z23w-dbus-1.6.4.tar.gz.drv
/gnu/store/1ixwp12fl950d15h2cj11c73733jay0z-alsa-lib-1.0.27.1.tar.bz2.drv
/gnu/store/nlma1pw0p603fpfiqy7kn4zm105r5dmw-util-linux-2.21.drv
@dots{}
@end example
@noindent
to something like:
@example
$ guix build emacs --dry-run
The following files would be downloaded:
/gnu/store/pk3n22lbq6ydamyymqkkz7i69wiwjiwi-emacs-24.3
/gnu/store/2ygn4ncnhrpr61rssa6z0d9x22si0va3-libjpeg-8d
/gnu/store/71yz6lgx4dazma9dwn2mcjxaah9w77jq-cairo-1.12.16
/gnu/store/7zdhgp0n1518lvfn8mb96sxqfmvqrl7v-libxrender-0.9.7
@dots{}
@end example
@noindent
This indicates that substitutes from @code{hydra.gnu.org} are usable and
will be downloaded, when possible, for future builds.
Guix ignores substitutes that are not signed, or that are not signed by
one of the keys listed in the ACL. It also detects and raises an error
when attempting to use a substitute that has been tampered with.
Substitutes are downloaded over HTTP or HTTPS.
The @code{http_proxy} environment
variable can be set in the environment of @command{guix-daemon} and is
honored for downloads of substitutes. Note that the value of
@code{http_proxy} in the environment where @command{guix build},
@command{guix package}, and other client commands are run has
@emph{absolutely no effect}.
When using HTTPS, the server's X.509 certificate is @emph{not} validated
(in other words, the server is not authenticated), contrary to what
HTTPS clients such as Web browsers usually do. This is because Guix
authenticates substitute information itself, as explained above, which
is what we care about (whereas X.509 certificates are about
authenticating bindings between domain names and public keys.)
The substitute mechanism can be disabled globally by running
@code{guix-daemon} with @code{--no-substitutes} (@pxref{Invoking
guix-daemon}). It can also be disabled temporarily by passing the
@code{--no-substitutes} option to @command{guix package}, @command{guix
build}, and other command-line tools.
@unnumberedsubsec On Trusting Binaries
Today, each individual's control over their own computing is at the
mercy of institutions, corporations, and groups with enough power and
determination to subvert the computing infrastructure and exploit its
weaknesses. While using @code{hydra.gnu.org} substitutes can be
convenient, we encourage users to also build on their own, or even run
their own build farm, such that @code{hydra.gnu.org} is less of an
interesting target. One way to help is by publishing the software you
build using @command{guix publish} so that others have one more choice
of server to download substitutes from (@pxref{Invoking guix publish}).
Guix has the foundations to maximize build reproducibility
(@pxref{Features}). In most cases, independent builds of a given
package or derivation should yield bit-identical results. Thus, through
a diverse set of independent package builds, we can strengthen the
integrity of our systems. The @command{guix challenge} command aims to
help users assess substitute servers, and to assist developers in
finding out about non-deterministic package builds (@pxref{Invoking guix
challenge}). Similarly, the @option{--check} option of @command{guix
build} allows users to check whether previously-installed substitutes
are genuine by rebuilding them locally (@pxref{build-check,
@command{guix build --check}}).
In the future, we want Guix to have support to publish and retrieve
binaries to/from other users, in a peer-to-peer fashion. If you would
like to discuss this project, join us on @email{guix-devel@@gnu.org}.
@node Packages with Multiple Outputs
@section Packages with Multiple Outputs
@cindex multiple-output packages
@cindex package outputs
Often, packages defined in Guix have a single @dfn{output}---i.e., the
source package leads to exactly one directory in the store. When running
1934
1935
1936
1937
1938
1939
1940
1941
1942
1943
1944
1945
1946
1947
1948
1949
1950
1951
1952
1953
1954
1955
1956
1957
1958
1959
@command{guix package -i glibc}, one installs the default output of the
GNU libc package; the default output is called @code{out}, but its name
can be omitted as shown in this command. In this particular case, the
default output of @code{glibc} contains all the C header files, shared
libraries, static libraries, Info documentation, and other supporting
files.
Sometimes it is more appropriate to separate the various types of files
produced from a single source package into separate outputs. For
instance, the GLib C library (used by GTK+ and related packages)
installs more than 20 MiB of reference documentation as HTML pages.
To save space for users who do not need it, the documentation goes to a
separate output, called @code{doc}. To install the main GLib output,
which contains everything but the documentation, one would run:
@example
guix package -i glib
@end example
The command to install its documentation is:
@example
guix package -i glib:doc
@end example
Some packages install programs with different ``dependency footprints''.
For instance, the WordNet package installs both command-line tools and
graphical user interfaces (GUIs). The former depend solely on the C
library, whereas the latter depend on Tcl/Tk and the underlying X
libraries. In this case, we leave the command-line tools in the default
output, whereas the GUIs are in a separate output. This allows users
who do not need the GUIs to save space. The @command{guix size} command
can help find out about such situations (@pxref{Invoking guix size}).
@command{guix graph} can also be helpful (@pxref{Invoking guix graph}).
There are several such multiple-output packages in the GNU distribution.
Other conventional output names include @code{lib} for libraries and
possibly header files, @code{bin} for stand-alone programs, and
@code{debug} for debugging information (@pxref{Installing Debugging
Files}). The outputs of a packages are listed in the third column of
the output of @command{guix package --list-available} (@pxref{Invoking
guix package}).
@node Invoking guix gc
@section Invoking @command{guix gc}
Packages that are installed, but not used, may be @dfn{garbage-collected}.
The @command{guix gc} command allows users to explicitly run the garbage
collector to reclaim space from the @file{/gnu/store} directory. It is
the @emph{only} way to remove files from @file{/gnu/store}---removing
files or directories manually may break it beyond repair!
The garbage collector has a set of known @dfn{roots}: any file under
@file{/gnu/store} reachable from a root is considered @dfn{live} and
cannot be deleted; any other file is considered @dfn{dead} and may be
deleted. The set of garbage collector roots includes default user
profiles, and may be augmented with @command{guix build --root}, for
example (@pxref{Invoking guix build}).
Prior to running @code{guix gc --collect-garbage} to make space, it is
often useful to remove old generations from user profiles; that way, old
package builds referenced by those generations can be reclaimed. This
is achieved by running @code{guix package --delete-generations}
(@pxref{Invoking guix package}).
The @command{guix gc} command has three modes of operation: it can be
used to garbage-collect any dead files (the default), to delete specific
files (the @code{--delete} option), to print garbage-collector
information, or for more advanced queries. The garbage collection
options are as follows:
@table @code
@item --collect-garbage[=@var{min}]
@itemx -C [@var{min}]
Collect garbage---i.e., unreachable @file{/gnu/store} files and
sub-directories. This is the default operation when no option is
specified.
When @var{min} is given, stop once @var{min} bytes have been collected.
@var{min} may be a number of bytes, or it may include a unit as a
suffix, such as @code{MiB} for mebibytes and @code{GB} for gigabytes
(@pxref{Block size, size specifications,, coreutils, GNU Coreutils}).
When @var{min} is omitted, collect all the garbage.
@item --free-space=@var{free}
@itemx -F @var{free}
Collect garbage until @var{free} space is available under
@file{/gnu/store}, if possible; @var{free} denotes storage space, such
as @code{500MiB}, as described above.
When @var{free} or more is already available in @file{/gnu/store}, do
nothing and exit immediately.
@item --delete
@itemx -d
Attempt to delete all the store files and directories specified as
arguments. This fails if some of the files are not in the store, or if
they are still live.
@item --list-failures
List store items corresponding to cached build failures.
This prints nothing unless the daemon was started with
@option{--cache-failures} (@pxref{Invoking guix-daemon,
@option{--cache-failures}}).
@item --clear-failures
Remove the specified store items from the failed-build cache.
Again, this option only makes sense when the daemon is started with
@option{--cache-failures}. Otherwise, it does nothing.
@item --list-dead
Show the list of dead files and directories still present in the
store---i.e., files and directories no longer reachable from any root.
@item --list-live
Show the list of live store files and directories.
@end table
In addition, the references among existing store files can be queried:
@table @code
@item --references
@itemx --referrers
List the references (respectively, the referrers) of store files given
as arguments.
List the requisites of the store files passed as arguments. Requisites
include the store files themselves, their references, and the references
of these, recursively. In other words, the returned list is the
@dfn{transitive closure} of the store files.
@xref{Invoking guix size}, for a tool to profile the size of the closure
of an element. @xref{Invoking guix graph}, for a tool to visualize
Lastly, the following options allow you to check the integrity of the
store and to control disk usage.
@table @option
@item --verify[=@var{options}]
@cindex integrity, of the store
@cindex integrity checking
Verify the integrity of the store.
By default, make sure that all the store items marked as valid in the
database of the daemon actually exist in @file{/gnu/store}.
When provided, @var{options} must be a comma-separated list containing one
or more of @code{contents} and @code{repair}.
When passing @option{--verify=contents}, the daemon computse the
content hash of each store item and compares it against its hash in the
2099
2100
2101
2102
2103
2104
2105
2106
2107
2108
2109
2110
2111
2112
2113
2114
2115
2116
2117
2118
2119
2120
2121
database. Hash mismatches are reported as data corruptions. Because it
traverses @emph{all the files in the store}, this command can take a
long time, especially on systems with a slow disk drive.
@cindex repairing the store
Using @option{--verify=repair} or @option{--verify=contents,repair}
causes the daemon to try to repair corrupt store items by fetching
substitutes for them (@pxref{Substitutes}). Because repairing is not
atomic, and thus potentially dangerous, it is available only to the
system administrator.
@item --optimize
@cindex deduplication
Optimize the store by hard-linking identical files---this is
@dfn{deduplication}.
The daemon performs deduplication after each successful build or archive
import, unless it was started with @code{--disable-deduplication}
(@pxref{Invoking guix-daemon, @code{--disable-deduplication}}). Thus,
this option is primarily useful when the daemon was running with
@code{--disable-deduplication}.
@end table
@node Invoking guix pull
@section Invoking @command{guix pull}
Packages are installed or upgraded to the latest version available in
the distribution currently available on your local machine. To update
that distribution, along with the Guix tools, you must run @command{guix
pull}: the command downloads the latest Guix source code and package
descriptions, and deploys it.
On completion, @command{guix package} will use packages and package
versions from this just-retrieved copy of Guix. Not only that, but all
the Guix commands and Scheme modules will also be taken from that latest
version. New @command{guix} sub-commands added by the update also
become available.
Any user can update their Guix copy using @command{guix pull}, and the
effect is limited to the user who run @command{guix pull}. For
instance, when user @code{root} runs @command{guix pull}, this has no
effect on the version of Guix that user @code{alice} sees, and vice
versa@footnote{Under the hood, @command{guix pull} updates the
@file{~/.config/guix/latest} symbolic link to point to the latest Guix,
and the @command{guix} command loads code from there.}.
The @command{guix pull} command is usually invoked with no arguments,
but it supports the following options:
@table @code
@item --verbose
Produce verbose output, writing build logs to the standard error output.
@item --url=@var{url}
Download the source tarball of Guix from @var{url}.
By default, the tarball is taken from its canonical address at
@code{gnu.org}, for the stable branch of Guix.
@item --bootstrap
Use the bootstrap Guile to build the latest Guix. This option is only
useful to Guix developers.
@end table
@node Invoking guix archive
@section Invoking @command{guix archive}
The @command{guix archive} command allows users to @dfn{export} files
from the store into a single archive, and to later @dfn{import} them.
In particular, it allows store files to be transferred from one machine
2171
2172
2173
2174
2175
2176
2177
2178
2179
2180
2181
2182
2183
2184
2185
2186
2187
2188
2189
2190
2191
2192
2193
2194
to the store on another machine.
To export store files as an archive to standard output, run:
@example
guix archive --export @var{options} @var{specifications}...
@end example
@var{specifications} may be either store file names or package
specifications, as for @command{guix package} (@pxref{Invoking guix
package}). For instance, the following command creates an archive
containing the @code{gui} output of the @code{git} package and the main
output of @code{emacs}:
@example
guix archive --export git:gui /gnu/store/...-emacs-24.3 > great.nar
@end example
If the specified packages are not built yet, @command{guix archive}
automatically builds them. The build process may be controlled with the
common build options (@pxref{Common Build Options}).
To transfer the @code{emacs} package to a machine connected over SSH,
one would run:
guix archive --export -r emacs | ssh the-machine guix archive --import
Similarly, a complete user profile may be transferred from one machine
to another like this:
@example
guix archive --export -r $(readlink -f ~/.guix-profile) | \
ssh the-machine guix-archive --import
@end example
@noindent
However, note that, in both examples, all of @code{emacs} and the
profile as well as all of their dependencies are transferred (due to
@code{-r}), regardless of what is already available in the store on the
target machine. The @code{--missing} option can help figure out which
items are missing from the target store.
Archives are stored in the ``Nix archive'' or ``Nar'' format, which is
comparable in spirit to `tar', but with a few noteworthy differences
that make it more appropriate for our purposes. First, rather than
recording all Unix metadata for each file, the Nar format only mentions
the file type (regular, directory, or symbolic link); Unix permissions
and owner/group are dismissed. Second, the order in which directory
entries are stored always follows the order of file names according to
the C locale collation order. This makes archive production fully
deterministic.
When exporting, the daemon digitally signs the contents of the archive,
and that digital signature is appended. When importing, the daemon
verifies the signature and rejects the import in case of an invalid
signature or if the signing key is not authorized.
@c FIXME: Add xref to daemon doc about signatures.
The main options are:
@table @code
@item --export
Export the specified store files or packages (see below.) Write the
resulting archive to the standard output.
Dependencies are @emph{not} included in the output, unless
@code{--recursive} is passed.
@item -r
@itemx --recursive
When combined with @code{--export}, this instructs @command{guix
archive} to include dependencies of the given items in the archive.
Thus, the resulting archive is self-contained: it contains the closure
of the exported store items.
@item --import
Read an archive from the standard input, and import the files listed
therein into the store. Abort if the archive has an invalid digital
signature, or if it is signed by a public key not among the authorized
keys (see @code{--authorize} below.)
@item --missing
Read a list of store file names from the standard input, one per line,
and write on the standard output the subset of these files missing from
the store.
@item --generate-key[=@var{parameters}]
Generate a new key pair for the daemon. This is a prerequisite before
archives can be exported with @code{--export}. Note that this operation
usually takes time, because it needs to gather enough entropy to
generate the key pair.
The generated key pair is typically stored under @file{/etc/guix}, in
@file{signing-key.pub} (public key) and @file{signing-key.sec} (private
key, which must be kept secret.) When @var{parameters} is omitted,
an ECDSA key using the Ed25519 curve is generated, or, for Libgcrypt
versions before 1.6.0, it is a 4096-bit RSA key.
@code{genkey} parameters suitable for Libgcrypt (@pxref{General
public-key related Functions, @code{gcry_pk_genkey},, gcrypt, The
Libgcrypt Reference Manual}).
@item --authorize
@cindex authorizing, archives
Authorize imports signed by the public key passed on standard input.
The public key must be in ``s-expression advanced format''---i.e., the
same format as the @file{signing-key.pub} file.
The list of authorized keys is kept in the human-editable file
@file{/etc/guix/acl}. The file contains
@url{http://people.csail.mit.edu/rivest/Sexp.txt, ``advanced-format
s-expressions''} and is structured as an access-control list in the
@url{http://theworld.com/~cme/spki.txt, Simple Public-Key Infrastructure
(SPKI)}.
@item --extract=@var{directory}
@itemx -x @var{directory}
Read a single-item archive as served by substitute servers
(@pxref{Substitutes}) and extract it to @var{directory}. This is a
low-level operation needed in only very narrow use cases; see below.
For example, the following command extracts the substitute for Emacs
served by @code{hydra.gnu.org} to @file{/tmp/emacs}:
@example
$ wget -O - \
https://hydra.gnu.org/nar/@dots{}-emacs-24.5 \
| bunzip2 | guix archive -x /tmp/emacs
@end example
Single-item archives are different from multiple-item archives produced
by @command{guix archive --export}; they contain a single store item,
and they do @emph{not} embed a signature. Thus this operation does
@emph{no} signature verification and its output should be considered
unsafe.
The primary purpose of this operation is to facilitate inspection of
archive contents coming from possibly untrusted substitute servers.
@c *********************************************************************
@include emacs.texi
@c *********************************************************************
@node Programming Interface
@chapter Programming Interface
GNU Guix provides several Scheme programming interfaces (APIs) to
define, build, and query packages. The first interface allows users to
write high-level package definitions. These definitions refer to
familiar packaging concepts, such as the name and version of a package,
its build system, and its dependencies. These definitions can then be
turned into concrete build actions.
Build actions are performed by the Guix daemon, on behalf of users. In a
standard setup, the daemon has write access to the store---the
@file{/gnu/store} directory---whereas users do not. The recommended
setup also has the daemon perform builds in chroots, under a specific
build users, to minimize interference with the rest of the system.
@cindex derivation
Lower-level APIs are available to interact with the daemon and the
store. To instruct the daemon to perform a build action, users actually
provide it with a @dfn{derivation}. A derivation is a low-level
representation of the build actions to be taken, and the environment in
which they should occur---derivations are to package definitions what
assembly is to C programs. The term ``derivation'' comes from the fact
that build results @emph{derive} from them.
This chapter describes all these APIs in turn, starting from high-level
package definitions.
* Build Systems:: Specifying how packages are built.
* The Store:: Manipulating the package store.
* Derivations:: Low-level interface to package derivations.
* The Store Monad:: Purely functional interface to the store.
@end menu
@node Defining Packages
@section Defining Packages
The high-level interface to package definitions is implemented in the
@code{(guix packages)} and @code{(guix build-system)} modules. As an
example, the package definition, or @dfn{recipe}, for the GNU Hello
package looks like this:
@example
(define-module (gnu packages hello)
#:use-module (guix packages)
#:use-module (guix download)
#:use-module (guix build-system gnu)
#:use-module (guix licenses)
#:use-module (gnu packages gawk))
(define-public hello
(package
(name "hello")
(method url-fetch)
(uri (string-append "mirror://gnu/hello/hello-" version
".tar.gz"))
(sha256
(base32
"0ssi1wpaf7plaswqqjwigppsg5fyh99vdlb9kzl7c9lng89ndq1i"))))
(build-system gnu-build-system)
(arguments `(#:configure-flags '("--enable-silent-rules")))
(synopsis "Hello, GNU world: An example GNU package")
(description "Guess what GNU Hello prints!")
(home-page "http://www.gnu.org/software/hello/")
(license gpl3+)))
@end example
@noindent
Without being a Scheme expert, the reader may have guessed the meaning
of the various fields here. This expression binds the variable
@code{hello} to a @code{<package>} object, which is essentially a record
(@pxref{SRFI-9, Scheme records,, guile, GNU Guile Reference Manual}).
This package object can be inspected using procedures found in the
@code{(guix packages)} module; for instance, @code{(package-name hello)}
returns---surprise!---@code{"hello"}.
With luck, you may be able to import part or all of the definition of
the package you are interested in from another repository, using the
@code{guix import} command (@pxref{Invoking guix import}).
In the example above, @var{hello} is defined in a module of its own,
@code{(gnu packages hello)}. Technically, this is not strictly
necessary, but it is convenient to do so: all the packages defined in
modules under @code{(gnu packages @dots{})} are automatically known to
the command-line tools (@pxref{Package Modules}).
There are a few points worth noting in the above package definition:
@itemize
@item
The @code{source} field of the package is an @code{<origin>} object
(@pxref{origin Reference}, for the complete reference).
Here, the @code{url-fetch} method from @code{(guix download)} is used,
meaning that the source is a file to be downloaded over FTP or HTTP.
The @code{mirror://gnu} prefix instructs @code{url-fetch} to use one of
the GNU mirrors defined in @code{(guix download)}.
The @code{sha256} field specifies the expected SHA256 hash of the file
being downloaded. It is mandatory, and allows Guix to check the
integrity of the file. The @code{(base32 @dots{})} form introduces the
base32 representation of the hash. You can obtain this information with
@code{guix download} (@pxref{Invoking guix download}) and @code{guix
hash} (@pxref{Invoking guix hash}).
@cindex patches
When needed, the @code{origin} form can also have a @code{patches} field
listing patches to be applied, and a @code{snippet} field giving a
Scheme expression to modify the source code.
@item
@cindex GNU Build System
The @code{build-system} field specifies the procedure to build the
package (@pxref{Build Systems}). Here, @var{gnu-build-system}
represents the familiar GNU Build System, where packages may be
configured, built, and installed with the usual @code{./configure &&
make && make check && make install} command sequence.
@item
The @code{arguments} field specifies options for the build system
(@pxref{Build Systems}). Here it is interpreted by
@var{gnu-build-system} as a request run @file{configure} with the
@code{--enable-silent-rules} flag.
@item
The @code{inputs} field specifies inputs to the build process---i.e.,
build-time or run-time dependencies of the package. Here, we define an
input called @code{"gawk"} whose value is that of the @var{gawk}
variable; @var{gawk} is itself bound to a @code{<package>} object.
Note that GCC, Coreutils, Bash, and other essential tools do not need to
be specified as inputs here. Instead, @var{gnu-build-system} takes care
of ensuring that they are present (@pxref{Build Systems}).
However, any other dependencies need to be specified in the
@code{inputs} field. Any dependency not specified here will simply be
unavailable to the build process, possibly leading to a build failure.
@end itemize
Taylan Ulrich Bayırlı/Kammer
committed
@xref{package Reference}, for a full description of possible fields.
Once a package definition is in place, the
package may actually be built using the @code{guix build} command-line
tool (@pxref{Invoking guix build}). You can easily jump back to the
package definition using the @command{guix edit} command
(@pxref{Invoking guix edit}).
@xref{Packaging Guidelines}, for
more information on how to test package definitions, and
@ref{Invoking guix lint}, for information on how to check a definition
for style conformance.
Finally, updating the package definition to a new upstream version
can be partly automated by the @command{guix refresh} command
(@pxref{Invoking guix refresh}).
Behind the scenes, a derivation corresponding to the @code{<package>}
object is first computed by the @code{package-derivation} procedure.
That derivation is stored in a @code{.drv} file under @file{/gnu/store}.
The build actions it prescribes may then be realized by using the
@code{build-derivations} procedure (@pxref{The Store}).
@deffn {Scheme Procedure} package-derivation @var{store} @var{package} [@var{system}]
Return the @code{<derivation>} object of @var{package} for @var{system}
(@pxref{Derivations}).
@var{package} must be a valid @code{<package>} object, and @var{system}
must be a string denoting the target system type---e.g.,
@code{"x86_64-linux"} for an x86_64 Linux-based GNU system. @var{store}
must be a connection to the daemon, which operates on the store
(@pxref{The Store}).
@end deffn
@noindent
@cindex cross-compilation
Similarly, it is possible to compute a derivation that cross-builds a
package for some other system:
@deffn {Scheme Procedure} package-cross-derivation @var{store} @
@var{package} @var{target} [@var{system}]
Return the @code{<derivation>} object of @var{package} cross-built from
@var{system} to @var{target}.
@var{target} must be a valid GNU triplet denoting the target hardware
and operating system, such as @code{"mips64el-linux-gnu"}
(@pxref{Configuration Names, GNU configuration triplets,, configure, GNU
Configure and Build System}).
@end deffn
Taylan Ulrich Bayırlı/Kammer
committed
2514
2515
2516
2517
2518
2519
2520
2521
2522
2523
2524
2525
2526
2527
2528
2529
2530
2531
2532
2533
2534
2535
2536
@menu
* package Reference :: The package data type.
* origin Reference:: The origin data type.
@end menu
@node package Reference
@subsection @code{package} Reference
This section summarizes all the options available in @code{package}
declarations (@pxref{Defining Packages}).
@deftp {Data Type} package
This is the data type representing a package recipe.
@table @asis
@item @code{name}
The name of the package, as a string.
@item @code{version}
The version of the package, as a string.
@item @code{source}
An object telling how the source code for the package should be
acquired. Most of the time, this is an @code{origin} object, which
denotes a file fetched from the Internet (@pxref{origin Reference}). It
can also be any other ``file-like'' object such as a @code{local-file},
which denotes a file from the local file system (@pxref{G-Expressions,
@code{local-file}}).
Taylan Ulrich Bayırlı/Kammer
committed
@item @code{build-system}
The build system that should be used to build the package (@pxref{Build
Systems}).
@item @code{arguments} (default: @code{'()})
The arguments that should be passed to the build system. This is a
list, typically containing sequential keyword-value pairs.
@item @code{inputs} (default: @code{'()})
@itemx @code{native-inputs} (default: @code{'()})
@itemx @code{propagated-inputs} (default: @code{'()})
@cindex inputs, of packages
These fields list dependencies of the package. Each one is a list of
tuples, where each tuple has a label for the input (a string) as its
first element, a package, origin, or derivation as its second element,
and optionally the name of the output thereof that should be used, which
defaults to @code{"out"} (@pxref{Packages with Multiple Outputs}, for
more on package outputs). For example, the list below specifies three
Taylan Ulrich Bayırlı/Kammer
committed
@example
`(("libffi" ,libffi)
("libunistring" ,libunistring)
("glib:bin" ,glib "bin")) ;the "bin" output of Glib
@end example
@cindex cross compilation, package dependencies
The distinction between @code{native-inputs} and @code{inputs} is
necessary when considering cross-compilation. When cross-compiling,
dependencies listed in @code{inputs} are built for the @emph{target}
architecture; conversely, dependencies listed in @code{native-inputs}
are built for the architecture of the @emph{build} machine.
@code{native-inputs} is typically used to list tools needed at
build time, but not at run time, such as Autoconf, Automake, pkg-config,
Gettext, or Bison. @command{guix lint} can report likely mistakes in
this area (@pxref{Invoking guix lint}).
@anchor{package-propagated-inputs}
Lastly, @code{propagated-inputs} is similar to @code{inputs}, but the
specified packages will be automatically installed alongside the package
they belong to (@pxref{package-cmd-propagated-inputs, @command{guix
package}}, for information on how @command{guix package} deals with
propagated inputs.)
For example this is necessary when a C/C++ library needs headers of
another library to compile, or when a pkg-config file refers to another
one @i{via} its @code{Requires} field.
Another example where @code{propagated-inputs} is useful is for languages
that lack a facility to record the run-time search path akin to the
@code{RUNPATH} of ELF files; this includes Guile, Python, Perl, GHC, and
more. To ensure that libraries written in those languages can find
library code they depend on at run time, run-time dependencies must be
listed in @code{propagated-inputs} rather than @code{inputs}.
Taylan Ulrich Bayırlı/Kammer
committed
@item @code{self-native-input?} (default: @code{#f})
This is a Boolean field telling whether the package should use itself as
a native input when cross-compiling.
@item @code{outputs} (default: @code{'("out")})
The list of output names of the package. @xref{Packages with Multiple
Outputs}, for typical uses of additional outputs.
@item @code{native-search-paths} (default: @code{'()})
@itemx @code{search-paths} (default: @code{'()})
A list of @code{search-path-specification} objects describing
search-path environment variables honored by the package.
@item @code{replacement} (default: @code{#f})
This must be either @code{#f} or a package object that will be used as a
Taylan Ulrich Bayırlı/Kammer
committed
@dfn{replacement} for this package. @xref{Security Updates, grafts},
for details.
@item @code{synopsis}
A one-line description of the package.
@item @code{description}
A more elaborate description of the package.
@item @code{license}
The license of the package; a value from @code{(guix licenses)},
or a list of such values.
Taylan Ulrich Bayırlı/Kammer
committed
@item @code{home-page}
The URL to the home-page of the package, as a string.
@item @code{supported-systems} (default: @var{%supported-systems})
The list of systems supported by the package, as strings of the form
@code{architecture-kernel}, for example @code{"x86_64-linux"}.
@item @code{maintainers} (default: @code{'()})
The list of maintainers of the package, as @code{maintainer} objects.
@item @code{location} (default: source location of the @code{package} form)
The source location of the package. It is useful to override this when
Taylan Ulrich Bayırlı/Kammer
committed
2640
2641
2642
2643
2644
2645
2646
2647
2648
2649
2650
2651
2652
2653
2654
2655
2656
2657
2658
2659
2660
2661
2662
inheriting from another package, in which case this field is not
automatically corrected.
@end table
@end deftp
@node origin Reference
@subsection @code{origin} Reference
This section summarizes all the options available in @code{origin}
declarations (@pxref{Defining Packages}).
@deftp {Data Type} origin
This is the data type representing a source code origin.
@table @asis
@item @code{uri}
An object containing the URI of the source. The object type depends on
the @code{method} (see below). For example, when using the
@var{url-fetch} method of @code{(guix download)}, the valid @code{uri}
values are: a URL represented as a string, or a list thereof.
@item @code{method}
Taylan Ulrich Bayırlı/Kammer
committed
Examples include:
@table @asis
@item @var{url-fetch} from @code{(guix download)}
download a file from the HTTP, HTTPS, or FTP URL specified in the
Taylan Ulrich Bayırlı/Kammer
committed
@code{uri} field;
Taylan Ulrich Bayırlı/Kammer
committed
@item @var{git-fetch} from @code{(guix git-download)}
clone the Git version control repository, and check out the revision
specified in the @code{uri} field as a @code{git-reference} object; a
@code{git-reference} looks like this:
@example
(git-reference
(url "git://git.debian.org/git/pkg-shadow/shadow")
(commit "v4.1.5.1"))
@end example
@end table
@item @code{sha256}
A bytevector containing the SHA-256 hash of the source. Typically the
@code{base32} form is used here to generate the bytevector from a
base-32 string.
You can obtain this information using @code{guix download}
(@pxref{Invoking guix download}) or @code{guix hash} (@pxref{Invoking
guix hash}).
Taylan Ulrich Bayırlı/Kammer
committed
@item @code{file-name} (default: @code{#f})
The file name under which the source code should be saved. When this is
@code{#f}, a sensible default value will be used in most cases. In case
the source is fetched from a URL, the file name from the URL will be
used. For version control checkouts, it is recommended to provide the
Taylan Ulrich Bayırlı/Kammer
committed
file name explicitly because the default is not very descriptive.
@item @code{patches} (default: @code{'()})
A list of file names containing patches to be applied to the source.
@item @code{snippet} (default: @code{#f})
A G-expression (@pxref{G-Expressions}) or S-expression that will be run
in the source directory. This is a convenient way to modify the source,
sometimes more convenient than a patch.
Taylan Ulrich Bayırlı/Kammer
committed
@item @code{patch-flags} (default: @code{'("-p1")})
A list of command-line flags that should be passed to the @code{patch}
command.
@item @code{patch-inputs} (default: @code{#f})
Input packages or derivations to the patching process. When this is
@code{#f}, the usual set of inputs necessary for patching are provided,
such as GNU@tie{}Patch.
@item @code{modules} (default: @code{'()})
A list of Guile modules that should be loaded during the patching
process and while running the code in the @code{snippet} field.
@item @code{patch-guile} (default: @code{#f})
The Guile package that should be used in the patching process. When
this is @code{#f}, a sensible default is used.
@end table
@end deftp
@node Build Systems
@section Build Systems
@cindex build system
Each package definition specifies a @dfn{build system} and arguments for
that build system (@pxref{Defining Packages}). This @code{build-system}
field represents the build procedure of the package, as well as implicit
dependencies of that build procedure.
Build systems are @code{<build-system>} objects. The interface to
create and manipulate them is provided by the @code{(guix build-system)}
module, and actual build systems are exported by specific modules.
@cindex bag (low-level package representation)
Under the hood, build systems first compile package objects to
@dfn{bags}. A @dfn{bag} is like a package, but with less
ornamentation---in other words, a bag is a lower-level representation of
a package, which includes all the inputs of that package, including some
that were implicitly added by the build system. This intermediate
representation is then compiled to a derivation (@pxref{Derivations}).
Build systems accept an optional list of @dfn{arguments}. In package
definitions, these are passed @i{via} the @code{arguments} field
(@pxref{Defining Packages}). They are typically keyword arguments
(@pxref{Optional Arguments, keyword arguments in Guile,, guile, GNU
Guile Reference Manual}). The value of these arguments is usually
evaluated in the @dfn{build stratum}---i.e., by a Guile process launched
by the daemon (@pxref{Derivations}).
The main build system is @var{gnu-build-system}, which implements the
standard build procedure for GNU and many other packages. It
is provided by the @code{(guix build-system gnu)} module.
@defvr {Scheme Variable} gnu-build-system
@var{gnu-build-system} represents the GNU Build System, and variants
thereof (@pxref{Configuration, configuration and makefile conventions,,
standards, GNU Coding Standards}).
@cindex build phases
In a nutshell, packages using it are configured, built, and installed with
2769
2770
2771
2772
2773
2774
2775
2776
2777
2778
2779
2780
2781
2782
2783
2784
2785
2786
2787
2788
2789
2790
2791
2792
the usual @code{./configure && make && make check && make install}
command sequence. In practice, a few additional steps are often needed.
All these steps are split up in separate @dfn{phases},
notably@footnote{Please see the @code{(guix build gnu-build-system)}
modules for more details about the build phases.}:
@table @code
@item unpack
Unpack the source tarball, and change the current directory to the
extracted source tree. If the source is actually a directory, copy it
to the build tree, and enter that directory.
@item patch-source-shebangs
Patch shebangs encountered in source files so they refer to the right
store file names. For instance, this changes @code{#!/bin/sh} to
@code{#!/gnu/store/@dots{}-bash-4.3/bin/sh}.
@item configure
Run the @file{configure} script with a number of default options, such
as @code{--prefix=/gnu/store/@dots{}}, as well as the options specified
by the @code{#:configure-flags} argument.
@item build
Run @code{make} with the list of flags specified with
@code{#:make-flags}. If the @code{#:parallel-build?} argument is true
2794
2795
2796
2797
2798
2799
2800
2801
2802
2803
2804
2805
2806
2807
2808
2809
2810
2811
2812
2813
2814
2815
2816
2817
2818
2819
2820
2821
2822
2823
(the default), build with @code{make -j}.
@item check
Run @code{make check}, or some other target specified with
@code{#:test-target}, unless @code{#:tests? #f} is passed. If the
@code{#:parallel-tests?} argument is true (the default), run @code{make
check -j}.
@item install
Run @code{make install} with the flags listed in @code{#:make-flags}.
@item patch-shebangs
Patch shebangs on the installed executable files.
@item strip
Strip debugging symbols from ELF files (unless @code{#:strip-binaries?}
is false), copying them to the @code{debug} output when available
(@pxref{Installing Debugging Files}).
@end table
@vindex %standard-phases
The build-side module @code{(guix build gnu-build-system)} defines
@var{%standard-phases} as the default list of build phases.
@var{%standard-phases} is a list of symbol/procedure pairs, where the
procedure implements the actual phase.
The list of phases used for a particular package can be changed with the
@code{#:phases} parameter. For instance, passing:
@example
#:phases (modify-phases %standard-phases (delete 'configure))
means that all the phases described above will be used, except the
@code{configure} phase.
In addition, this build system ensures that the ``standard'' environment
for GNU packages is available. This includes tools such as GCC, libc,
Coreutils, Bash, Make, Diffutils, grep, and sed (see the @code{(guix
build-system gnu)} module for a complete list). We call these the
@dfn{implicit inputs} of a package, because package definitions do not
have to mention them.
@end defvr
Other @code{<build-system>} objects are defined to support other
conventions and tools used by free software packages. They inherit most
of @var{gnu-build-system}, and differ mainly in the set of inputs
implicitly added to the build process, and in the list of phases
executed. Some of these build systems are listed below.
2844
2845
2846
2847
2848
2849
2850
2851
2852
2853
2854
2855
2856
2857
2858
2859
2860
2861
2862
2863
2864
@defvr {Scheme Variable} ant-build-system
This variable is exported by @code{(guix build-system ant)}. It
implements the build procedure for Java packages that can be built with
@url{http://ant.apache.org/, Ant build tool}.
It adds both @code{ant} and the @dfn{Java Development Kit} (JDK) as
provided by the @code{icedtea} package to the set of inputs. Different
packages can be specified with the @code{#:ant} and @code{#:jdk}
parameters, respectively.
When the original package does not provide a suitable Ant build file,
the parameter @code{#:jar-name} can be used to generate a minimal Ant
build file @file{build.xml} with tasks to build the specified jar
archive.
The parameter @code{#:build-target} can be used to specify the Ant task
that should be run during the @code{build} phase. By default the
``jar'' task will be run.
@end defvr
@defvr {Scheme Variable} cmake-build-system
This variable is exported by @code{(guix build-system cmake)}. It
implements the build procedure for packages using the
@url{http://www.cmake.org, CMake build tool}.
It automatically adds the @code{cmake} package to the set of inputs.
Which package is used can be specified with the @code{#:cmake}
parameter.
Ludovic Courtès
committed
The @code{#:configure-flags} parameter is taken as a list of flags
passed to the @command{cmake} command. The @code{#:build-type}
parameter specifies in abstract terms the flags passed to the compiler;
it defaults to @code{"RelWithDebInfo"} (short for ``release mode with
debugging information''), which roughly means that code is compiled with
@code{-O2 -g}, as is the case for Autoconf-based packages by default.
@defvr {Scheme Variable} glib-or-gtk-build-system
This variable is exported by @code{(guix build-system glib-or-gtk)}. It
is intended for use with packages making use of GLib or GTK+.
This build system adds the following two phases to the ones defined by
@var{gnu-build-system}:
@table @code
@item glib-or-gtk-wrap
The phase @code{glib-or-gtk-wrap} ensures that programs in
@file{bin/} are able to find GLib ``schemas'' and
@uref{https://developer.gnome.org/gtk3/stable/gtk-running.html, GTK+
modules}. This is achieved by wrapping the programs in launch scripts
that appropriately set the @code{XDG_DATA_DIRS} and @code{GTK_PATH}
environment variables.
Ludovic Courtès
committed
It is possible to exclude specific package outputs from that wrapping
process by listing their names in the
@code{#:glib-or-gtk-wrap-excluded-outputs} parameter. This is useful
when an output is known not to contain any GLib or GTK+ binaries, and
where wrapping would gratuitously add a dependency of that output on
GLib and GTK+.
@item glib-or-gtk-compile-schemas
The phase @code{glib-or-gtk-compile-schemas} makes sure that all
@uref{https://developer.gnome.org/gio/stable/glib-compile-schemas.html,
GSettings schemas} of GLib are compiled. Compilation is performed by the
@command{glib-compile-schemas} program. It is provided by the package
@code{glib:bin} which is automatically imported by the build system.
The @code{glib} package providing @command{glib-compile-schemas} can be
specified with the @code{#:glib} parameter.
@end table
Both phases are executed after the @code{install} phase.
@end defvr
@defvr {Scheme Variable} python-build-system
This variable is exported by @code{(guix build-system python)}. It
implements the more or less standard build procedure used by Python
packages, which consists in running @code{python setup.py build} and
then @code{python setup.py install --prefix=/gnu/store/@dots{}}.
For packages that install stand-alone Python programs under @code{bin/},
it takes care of wrapping these programs so that their @code{PYTHONPATH}
environment variable points to all the Python libraries they depend on.
Which Python package is used to perform the build can be specified with
the @code{#:python} parameter. This is a useful way to force a package
to be built for a specific version of the Python interpreter, which
might be necessary if the package is only compatible with a single
interpreter version.
@end defvr
@defvr {Scheme Variable} perl-build-system
This variable is exported by @code{(guix build-system perl)}. It
implements the standard build procedure for Perl packages, which either
consists in running @code{perl Build.PL --prefix=/gnu/store/@dots{}},
followed by @code{Build} and @code{Build install}; or in running
@code{perl Makefile.PL PREFIX=/gnu/store/@dots{}}, followed by
@code{make} and @code{make install}, depending on which of
@code{Build.PL} or @code{Makefile.PL} is present in the package
distribution. Preference is given to the former if both @code{Build.PL}
and @code{Makefile.PL} exist in the package distribution. This
preference can be reversed by specifying @code{#t} for the
@code{#:make-maker?} parameter.
The initial @code{perl Makefile.PL} or @code{perl Build.PL} invocation
passes flags specified by the @code{#:make-maker-flags} or
@code{#:module-build-flags} parameter, respectively.
Which Perl package is used can be specified with @code{#:perl}.
@end defvr
@defvr {Scheme Variable} r-build-system
This variable is exported by @code{(guix build-system r)}. It
implements the build procedure used by @uref{http://r-project.org, R}
packages, which essentially is little more than running @code{R CMD
INSTALL --library=/gnu/store/@dots{}} in an environment where
@code{R_LIBS_SITE} contains the paths to all R package inputs. Tests
are run after installation using the R function
@code{tools::testInstalledPackage}.
@end defvr
@defvr {Scheme Variable} ruby-build-system
This variable is exported by @code{(guix build-system ruby)}. It
implements the RubyGems build procedure used by Ruby packages, which
involves running @code{gem build} followed by @code{gem install}.
The @code{source} field of a package that uses this build system
typically references a gem archive, since this is the format that Ruby
developers use when releasing their software. The build system unpacks
the gem archive, potentially patches the source, runs the test suite,
repackages the gem, and installs it. Additionally, directories and
tarballs may be referenced to allow building unreleased gems from Git or
a traditional source release tarball.
Which Ruby package is used can be specified with the @code{#:ruby}
parameter. A list of additional flags to be passed to the @command{gem}
command can be specified with the @code{#:gem-flags} parameter.
@defvr {Scheme Variable} waf-build-system
This variable is exported by @code{(guix build-system waf)}. It
implements a build procedure around the @code{waf} script. The common
phases---@code{configure}, @code{build}, and @code{install}---are
implemented by passing their names as arguments to the @code{waf}
script.
The @code{waf} script is executed by the Python interpreter. Which
Python package is used to run the script can be specified with the
@code{#:python} parameter.
@end defvr
@defvr {Scheme Variable} haskell-build-system
This variable is exported by @code{(guix build-system haskell)}. It
implements the Cabal build procedure used by Haskell packages, which
involves running @code{runhaskell Setup.hs configure
--prefix=/gnu/store/@dots{}} and @code{runhaskell Setup.hs build}.
Instead of installing the package by running @code{runhaskell Setup.hs
install}, to avoid trying to register libraries in the read-only
compiler store directory, the build system uses @code{runhaskell
Setup.hs copy}, followed by @code{runhaskell Setup.hs register}. In
addition, the build system generates the package documentation by
running @code{runhaskell Setup.hs haddock}, unless @code{#:haddock? #f}
is passed. Optional Haddock parameters can be passed with the help of
the @code{#:haddock-flags} parameter. If the file @code{Setup.hs} is
not found, the build system looks for @code{Setup.lhs} instead.
Which Haskell compiler is used can be specified with the @code{#:haskell}
parameter which defaults to @code{ghc}.
@defvr {Scheme Variable} emacs-build-system
This variable is exported by @code{(guix build-system emacs)}. It
implements an installation procedure similar to the packaging system
of Emacs itself (@pxref{Packages,,, emacs, The GNU Emacs Manual}).
It first creates the @code{@var{package}-autoloads.el} file, then it
byte compiles all Emacs Lisp files. Differently from the Emacs
packaging system, the Info documentation files are moved to the standard
documentation directory and the @file{dir} file is deleted. Each
package is installed in its own directory under
@file{share/emacs/site-lisp/guix.d}.
@end defvr
Lastly, for packages that do not need anything as sophisticated, a
``trivial'' build system is provided. It is trivial in the sense that
it provides basically no support: it does not pull any implicit inputs,
and does not have a notion of build phases.
@defvr {Scheme Variable} trivial-build-system
This variable is exported by @code{(guix build-system trivial)}.
This build system requires a @code{#:builder} argument. This argument
must be a Scheme expression that builds the package output(s)---as
with @code{build-expression->derivation} (@pxref{Derivations,
@code{build-expression->derivation}}).
@end defvr
@node The Store
@section The Store
Conceptually, the @dfn{store} is the place where derivations that have
been built successfully are stored---by default, @file{/gnu/store}.
Sub-directories in the store are referred to as @dfn{store items} or
sometimes @dfn{store paths}. The store has an associated database that
contains information such as the store paths referred to by each store
path, and the list of @emph{valid} store items---results of successful
builds. This database resides in @file{@var{localstatedir}/guix/db},
where @var{localstatedir} is the state directory specified @i{via}
@option{--localstatedir} at configure time, usually @file{/var}.
The store is @emph{always} accessed by the daemon on behalf of its clients
(@pxref{Invoking guix-daemon}). To manipulate the store, clients
connect to the daemon over a Unix-domain socket, send requests to it,
and read the result---these are remote procedure calls, or RPCs.
@quotation Note
Users must @emph{never} modify files under @file{/gnu/store} directly.
This would lead to inconsistencies and break the immutability
assumptions of Guix's functional model (@pxref{Introduction}).
@xref{Invoking guix gc, @command{guix gc --verify}}, for information on
how to check the integrity of the store and attempt recovery from
accidental modifications.
@end quotation
The @code{(guix store)} module provides procedures to connect to the
daemon, and to perform RPCs. These are described below.
@deffn {Scheme Procedure} open-connection [@var{file}] [#:reserve-space? #t]
Connect to the daemon over the Unix-domain socket at @var{file}. When
@var{reserve-space?} is true, instruct it to reserve a little bit of
extra space on the file system so that the garbage collector can still
operate should the disk become full. Return a server object.
@var{file} defaults to @var{%default-socket-path}, which is the normal
location given the options that were passed to @command{configure}.
@end deffn
@deffn {Scheme Procedure} close-connection @var{server}
Close the connection to @var{server}.
@end deffn
@defvr {Scheme Variable} current-build-output-port
This variable is bound to a SRFI-39 parameter, which refers to the port
where build and error logs sent by the daemon should be written.
@end defvr
Procedures that make RPCs all take a server object as their first
argument.
@deffn {Scheme Procedure} valid-path? @var{server} @var{path}
@cindex invalid store items
Return @code{#t} when @var{path} designates a valid store item and
@code{#f} otherwise (an invalid item may exist on disk but still be
invalid, for instance because it is the result of an aborted or failed
build.)
A @code{&nix-protocol-error} condition is raised if @var{path} is not
prefixed by the store directory (@file{/gnu/store}).
@deffn {Scheme Procedure} add-text-to-store @var{server} @var{name} @var{text} [@var{references}]
Add @var{text} under file @var{name} in the store, and return its store
path. @var{references} is the list of store paths referred to by the
resulting store path.
@end deffn
@deffn {Scheme Procedure} build-derivations @var{server} @var{derivations}
Build @var{derivations} (a list of @code{<derivation>} objects or
derivation paths), and return when the worker is done building them.
Return @code{#t} on success.
Note that the @code{(guix monads)} module provides a monad as well as
monadic versions of the above procedures, with the goal of making it
more convenient to work with code that accesses the store (@pxref{The
Store Monad}).
@c FIXME
@i{This section is currently incomplete.}
@node Derivations
@section Derivations
@cindex derivations
Low-level build actions and the environment in which they are performed
are represented by @dfn{derivations}. A derivation contains the
3135
3136
3137
3138
3139
3140
3141
3142
3143
3144
3145
3146
3147
3148
3149
3150
3151
3152
3153
3154
3155
3156
3157
3158
3159
3160
3161
3162
3163
3164
3165
3166
3167
3168
3169
3170
3171
following pieces of information:
@itemize
@item
The outputs of the derivation---derivations produce at least one file or
directory in the store, but may produce more.
@item
The inputs of the derivations, which may be other derivations or plain
files in the store (patches, build scripts, etc.)
@item
The system type targeted by the derivation---e.g., @code{x86_64-linux}.
@item
The file name of a build script in the store, along with the arguments
to be passed.
@item
A list of environment variables to be defined.
@end itemize
@cindex derivation path
Derivations allow clients of the daemon to communicate build actions to
the store. They exist in two forms: as an in-memory representation,
both on the client- and daemon-side, and as files in the store whose
name end in @code{.drv}---these files are referred to as @dfn{derivation
paths}. Derivations paths can be passed to the @code{build-derivations}
procedure to perform the build actions they prescribe (@pxref{The
Store}).
The @code{(guix derivations)} module provides a representation of
derivations as Scheme objects, along with procedures to create and
otherwise manipulate derivations. The lowest-level primitive to create
a derivation is the @code{derivation} procedure:
@deffn {Scheme Procedure} derivation @var{store} @var{name} @var{builder} @
@var{args} [#:outputs '("out")] [#:hash #f] [#:hash-algo #f] @
[#:recursive? #f] [#:inputs '()] [#:env-vars '()] @
[#:system (%current-system)] [#:references-graphs #f] @
[#:allowed-references #f] [#:disallowed-references #f] @
[#:leaked-env-vars #f] [#:local-build? #f] @
[#:substitutable? #t]
Build a derivation with the given arguments, and return the resulting
@code{<derivation>} object.
When @var{hash} and @var{hash-algo} are given, a
@dfn{fixed-output derivation} is created---i.e., one whose result is
known in advance, such as a file download. If, in addition,
@var{recursive?} is true, then that fixed output may be an executable
file or a directory and @var{hash} must be the hash of an archive
containing this output.
When @var{references-graphs} is true, it must be a list of file
name/store path pairs. In that case, the reference graph of each store
path is exported in the build environment in the corresponding file, in
a simple text format.
When @var{allowed-references} is true, it must be a list of store items
or outputs that the derivation's output may refer to. Likewise,
@var{disallowed-references}, if true, must be a list of things the
outputs may @emph{not} refer to.
When @var{leaked-env-vars} is true, it must be a list of strings
denoting environment variables that are allowed to ``leak'' from the
daemon's environment to the build environment. This is only applicable
to fixed-output derivations---i.e., when @var{hash} is true. The main
use is to allow variables such as @code{http_proxy} to be passed to
derivations that download files.
When @var{local-build?} is true, declare that the derivation is not a
good candidate for offloading and should rather be built locally
(@pxref{Daemon Offload Setup}). This is the case for small derivations
where the costs of data transfers would outweigh the benefits.
When @var{substitutable?} is false, declare that substitutes of the
derivation's output should not be used (@pxref{Substitutes}). This is
useful, for instance, when building packages that capture details of the
host CPU instruction set.
@end deffn
@noindent
Here's an example with a shell script as its builder, assuming
@var{store} is an open connection to the daemon, and @var{bash} points
to a Bash executable in the store:
@lisp
(use-modules (guix utils)
(guix store)
(guix derivations))
(let ((builder ; add the Bash script to the store
(add-text-to-store store "my-builder.sh"
"echo hello world > $out\n" '())))
(derivation store "foo"
bash `("-e" ,builder)
#:env-vars '(("HOME" . "/homeless"))))
@result{} #<derivation /gnu/store/@dots{}-foo.drv => /gnu/store/@dots{}-foo>
As can be guessed, this primitive is cumbersome to use directly. A
better approach is to write build scripts in Scheme, of course! The
best course of action for that is to write the build code as a
``G-expression'', and to pass it to @code{gexp->derivation}. For more
information, @pxref{G-Expressions}.
Once upon a time, @code{gexp->derivation} did not exist and constructing
derivations with build code written in Scheme was achieved with
@code{build-expression->derivation}, documented below. This procedure
is now deprecated in favor of the much nicer @code{gexp->derivation}.
@deffn {Scheme Procedure} build-expression->derivation @var{store} @
@var{name} @var{exp} @
[#:system (%current-system)] [#:inputs '()] @
[#:outputs '("out")] [#:hash #f] [#:hash-algo #f] @
[#:recursive? #f] [#:env-vars '()] [#:modules '()] @
[#:references-graphs #f] [#:allowed-references #f] @
[#:disallowed-references #f] @
3255
3256
3257
3258
3259
3260
3261
3262
3263
3264
3265
3266
3267
3268
3269
3270
3271
3272
3273
3274
3275
3276
3277
[#:local-build? #f] [#:substitutable? #t] [#:guile-for-build #f]
Return a derivation that executes Scheme expression @var{exp} as a
builder for derivation @var{name}. @var{inputs} must be a list of
@code{(name drv-path sub-drv)} tuples; when @var{sub-drv} is omitted,
@code{"out"} is assumed. @var{modules} is a list of names of Guile
modules from the current search path to be copied in the store,
compiled, and made available in the load path during the execution of
@var{exp}---e.g., @code{((guix build utils) (guix build
gnu-build-system))}.
@var{exp} is evaluated in an environment where @code{%outputs} is bound
to a list of output/path pairs, and where @code{%build-inputs} is bound
to a list of string/output-path pairs made from @var{inputs}.
Optionally, @var{env-vars} is a list of string pairs specifying the name
and value of environment variables visible to the builder. The builder
terminates by passing the result of @var{exp} to @code{exit}; thus, when
@var{exp} returns @code{#f}, the build is considered to have failed.
@var{exp} is built using @var{guile-for-build} (a derivation). When
@var{guile-for-build} is omitted or is @code{#f}, the value of the
@code{%guile-for-build} fluid is used instead.
See the @code{derivation} procedure for the meaning of
@var{references-graphs}, @var{allowed-references},
@var{disallowed-references}, @var{local-build?}, and
@var{substitutable?}.
@end deffn
@noindent
Here's an example of a single-output derivation that creates a directory
containing one file:
@lisp
(let ((builder '(let ((out (assoc-ref %outputs "out")))
(mkdir out) ; create /gnu/store/@dots{}-goo
(call-with-output-file (string-append out "/test")
(lambda (p)
(display '(hello guix) p))))))
(build-expression->derivation store "goo" builder))
@result{} #<derivation /gnu/store/@dots{}-goo.drv => @dots{}>
@end lisp
3299
3300
3301
3302
3303
3304
3305
3306
3307
3308
3309
3310
3311
3312
3313
3314
3315
3316
3317
3318
3319
3320
3321
@node The Store Monad
@section The Store Monad
@cindex monad
The procedures that operate on the store described in the previous
sections all take an open connection to the build daemon as their first
argument. Although the underlying model is functional, they either have
side effects or depend on the current state of the store.
The former is inconvenient: the connection to the build daemon has to be
carried around in all those functions, making it impossible to compose
functions that do not take that parameter with functions that do. The
latter can be problematic: since store operations have side effects
and/or depend on external state, they have to be properly sequenced.
@cindex monadic values
@cindex monadic functions
This is where the @code{(guix monads)} module comes in. This module
provides a framework for working with @dfn{monads}, and a particularly
useful monad for our uses, the @dfn{store monad}. Monads are a
construct that allows two things: associating ``context'' with values
(in our case, the context is the store), and building sequences of
computations (here computations include accesses to the store). Values
in a monad---values that carry this additional context---are called
@dfn{monadic values}; procedures that return such values are called
@dfn{monadic procedures}.
Consider this ``normal'' procedure:
@example
(define (sh-symlink store)
;; Return a derivation that symlinks the 'bash' executable.
(let* ((drv (package-derivation store bash))
(out (derivation->output-path drv))
(sh (string-append out "/bin/bash")))
(build-expression->derivation store "sh"
`(symlink ,sh %output))))
Using @code{(guix monads)} and @code{(guix gexp)}, it may be rewritten
as a monadic function:
(mlet %store-monad ((drv (package->derivation bash)))
(gexp->derivation "sh"
#~(symlink (string-append #$drv "/bin/bash")
#$output))))
There are several things to note in the second version: the @code{store}
parameter is now implicit and is ``threaded'' in the calls to the
@code{package->derivation} and @code{gexp->derivation} monadic
procedures, and the monadic value returned by @code{package->derivation}
is @dfn{bound} using @code{mlet} instead of plain @code{let}.
As it turns out, the call to @code{package->derivation} can even be
omitted since it will take place implicitly, as we will see later
(@pxref{G-Expressions}):
@example
(define (sh-symlink)
(gexp->derivation "sh"
#~(symlink (string-append #$bash "/bin/bash")
#$output)))
@end example
@c <https://syntaxexclamation.wordpress.com/2014/06/26/escaping-continuations/>
@c for the funny quote.
Calling the monadic @code{sh-symlink} has no effect. As someone once
said, ``you exit a monad like you exit a building on fire: by running''.
So, to exit the monad and get the desired effect, one must use
@code{run-with-store}:
(run-with-store (open-connection) (sh-symlink))
@result{} /gnu/store/...-sh-symlink
Note that the @code{(guix monad-repl)} module extends the Guile REPL with
new ``meta-commands'' to make it easier to deal with monadic procedures:
@code{run-in-store}, and @code{enter-store-monad}. The former is used
3384
3385
3386
3387
3388
3389
3390
3391
3392
3393
3394
3395
3396
3397
3398
3399
3400
3401
3402
3403
3404
3405
3406
3407
to ``run'' a single monadic value through the store:
@example
scheme@@(guile-user)> ,run-in-store (package->derivation hello)
$1 = #<derivation /gnu/store/@dots{}-hello-2.9.drv => @dots{}>
@end example
The latter enters a recursive REPL, where all the return values are
automatically run through the store:
@example
scheme@@(guile-user)> ,enter-store-monad
store-monad@@(guile-user) [1]> (package->derivation hello)
$2 = #<derivation /gnu/store/@dots{}-hello-2.9.drv => @dots{}>
store-monad@@(guile-user) [1]> (text-file "foo" "Hello!")
$3 = "/gnu/store/@dots{}-foo"
store-monad@@(guile-user) [1]> ,q
scheme@@(guile-user)>
@end example
@noindent
Note that non-monadic values cannot be returned in the
@code{store-monad} REPL.
The main syntactic forms to deal with monads in general are provided by
the @code{(guix monads)} module and are described below.
@deffn {Scheme Syntax} with-monad @var{monad} @var{body} ...
Evaluate any @code{>>=} or @code{return} forms in @var{body} as being
in @var{monad}.
@end deffn
@deffn {Scheme Syntax} return @var{val}
Return a monadic value that encapsulates @var{val}.
@end deffn
@deffn {Scheme Syntax} >>= @var{mval} @var{mproc} ...
@dfn{Bind} monadic value @var{mval}, passing its ``contents'' to monadic
procedures @var{mproc}@dots{}@footnote{This operation is commonly
referred to as ``bind'', but that name denotes an unrelated procedure in
Guile. Thus we use this somewhat cryptic symbol inherited from the
Haskell language.}. There can be one @var{mproc} or several of them, as
in this example:
@example
(run-with-state
(with-monad %state-monad
(>>= (return 1)
(lambda (x) (return (+ 1 x)))
(lambda (x) (return (* 2 x)))))
'some-state)
@result{} 4
@result{} some-state
@end example
@end deffn
@deffn {Scheme Syntax} mlet @var{monad} ((@var{var} @var{mval}) ...) @
@var{body} ...
@deffnx {Scheme Syntax} mlet* @var{monad} ((@var{var} @var{mval}) ...) @
@var{body} ...
Bind the variables @var{var} to the monadic values @var{mval} in
@var{body}. The form (@var{var} -> @var{val}) binds @var{var} to the
``normal'' value @var{val}, as per @code{let}.
@code{mlet*} is to @code{mlet} what @code{let*} is to @code{let}
(@pxref{Local Bindings,,, guile, GNU Guile Reference Manual}).
@end deffn
@deffn {Scheme System} mbegin @var{monad} @var{mexp} ...
Bind @var{mexp} and the following monadic expressions in sequence,
returning the result of the last expression.
This is akin to @code{mlet}, except that the return values of the
monadic expressions are ignored. In that sense, it is analogous to
@code{begin}, but applied to monadic expressions.
@end deffn
3462
3463
3464
3465
3466
3467
3468
3469
3470
3471
3472
3473
3474
3475
3476
3477
3478
3479
3480
3481
3482
3483
3484
3485
3486
3487
3488
3489
3490
3491
3492
3493
3494
3495
3496
3497
3498
3499
3500
3501
3502
3503
3504
3505
3506
3507
3508
3509
3510
3511
3512
3513
3514
@cindex state monad
The @code{(guix monads)} module provides the @dfn{state monad}, which
allows an additional value---the state---to be @emph{threaded} through
monadic procedure calls.
@defvr {Scheme Variable} %state-monad
The state monad. Procedures in the state monad can access and change
the state that is threaded.
Consider the example below. The @code{square} procedure returns a value
in the state monad. It returns the square of its argument, but also
increments the current state value:
@example
(define (square x)
(mlet %state-monad ((count (current-state)))
(mbegin %state-monad
(set-current-state (+ 1 count))
(return (* x x)))))
(run-with-state (sequence %state-monad (map square (iota 3))) 0)
@result{} (0 1 4)
@result{} 3
@end example
When ``run'' through @var{%state-monad}, we obtain that additional state
value, which is the number of @code{square} calls.
@end defvr
@deffn {Monadic Procedure} current-state
Return the current state as a monadic value.
@end deffn
@deffn {Monadic Procedure} set-current-state @var{value}
Set the current state to @var{value} and return the previous state as a
monadic value.
@end deffn
@deffn {Monadic Procedure} state-push @var{value}
Push @var{value} to the current state, which is assumed to be a list,
and return the previous state as a monadic value.
@end deffn
@deffn {Monadic Procedure} state-pop
Pop a value from the current state and return it as a monadic value.
The state is assumed to be a list.
@end deffn
@deffn {Scheme Procedure} run-with-state @var{mval} [@var{state}]
Run monadic value @var{mval} starting with @var{state} as the initial
state. Return two values: the resulting value, and the resulting state.
@end deffn
The main interface to the store monad, provided by the @code{(guix
store)} module, is as follows.
The store monad---an alias for @var{%state-monad}.
Values in the store monad encapsulate accesses to the store. When its
effect is needed, a value of the store monad must be ``evaluated'' by
passing it to the @code{run-with-store} procedure (see below.)
@end defvr
@deffn {Scheme Procedure} run-with-store @var{store} @var{mval} [#:guile-for-build] [#:system (%current-system)]
Run @var{mval}, a monadic value in the store monad, in @var{store}, an
open store connection.
@end deffn
@deffn {Monadic Procedure} text-file @var{name} @var{text} [@var{references}]
Return as a monadic value the absolute file name in the store of the file
containing @var{text}, a string. @var{references} is a list of store items that the
resulting text file refers to; it defaults to the empty list.
@deffn {Monadic Procedure} interned-file @var{file} [@var{name}] @
[#:recursive? #t] [#:select? (const #t)]
Return the name of @var{file} once interned in the store. Use
@var{name} as its store name, or the basename of @var{file} if
@var{name} is omitted.
When @var{recursive?} is true, the contents of @var{file} are added
recursively; if @var{file} designates a flat file and @var{recursive?}
is true, its contents are added, and its permission bits are kept.
When @var{recursive?} is true, call @code{(@var{select?} @var{file}
@var{stat})} for each directory entry, where @var{file} is the entry's
absolute file name and @var{stat} is the result of @code{lstat}; exclude
entries for which @var{select?} does not return true.
The example below adds a file to the store, under two different names:
@example
(run-with-store (open-connection)
(mlet %store-monad ((a (interned-file "README"))
(b (interned-file "README" "LEGU-MIN")))
(return (list a b))))
@result{} ("/gnu/store/rwm@dots{}-README" "/gnu/store/44i@dots{}-LEGU-MIN")
@end example
@end deffn
The @code{(guix packages)} module exports the following package-related
monadic procedures:
@deffn {Monadic Procedure} package-file @var{package} [@var{file}] @
[#:system (%current-system)] [#:target #f] @
value in the absolute file name of @var{file} within the @var{output}
directory of @var{package}. When @var{file} is omitted, return the name
of the @var{output} directory of @var{package}. When @var{target} is
true, use it as a cross-compilation target triplet.
@end deffn
@deffn {Monadic Procedure} package->derivation @var{package} [@var{system}]
@deffnx {Monadic Procedure} package->cross-derivation @var{package} @
@var{target} [@var{system}]
Monadic version of @code{package-derivation} and
@code{package-cross-derivation} (@pxref{Defining Packages}).
@node G-Expressions
@section G-Expressions
@cindex G-expression
@cindex build code quoting
So we have ``derivations'', which represent a sequence of build actions
to be performed to produce an item in the store (@pxref{Derivations}).
These build actions are performed when asking the daemon to actually
build the derivations; they are run by the daemon in a container
(@pxref{Invoking guix-daemon}).
@cindex strata of code
It should come as no surprise that we like to write these build actions
in Scheme. When we do that, we end up with two @dfn{strata} of Scheme
code@footnote{The term @dfn{stratum} in this context was coined by
Manuel Serrano et al.@: in the context of their work on Hop. Oleg
Kiselyov, who has written insightful
@url{http://okmij.org/ftp/meta-programming/#meta-scheme, essays and code
on this topic}, refers to this kind of code generation as
@dfn{staging}.}: the ``host code''---code that defines packages, talks
to the daemon, etc.---and the ``build code''---code that actually
performs build actions, such as making directories, invoking
@command{make}, etc.
To describe a derivation and its build actions, one typically needs to
embed build code inside host code. It boils down to manipulating build
code as data, and the homoiconicity of Scheme---code has a direct
representation as data---comes in handy for that. But we need more than
the normal @code{quasiquote} mechanism in Scheme to construct build
expressions.
The @code{(guix gexp)} module implements @dfn{G-expressions}, a form of
S-expressions adapted to build expressions. G-expressions, or
@dfn{gexps}, consist essentially of three syntactic forms: @code{gexp},
@code{ungexp}, and @code{ungexp-splicing} (or simply: @code{#~},
@code{#$}, and @code{#$@@}), which are comparable to
@code{quasiquote}, @code{unquote}, and @code{unquote-splicing},
respectively (@pxref{Expression Syntax, @code{quasiquote},, guile,
GNU Guile Reference Manual}). However, there are major differences:
@itemize
@item
Gexps are meant to be written to a file and run or manipulated by other
processes.
@item
When a high-level object such as a package or derivation is unquoted
inside a gexp, the result is as if its output file name had been
introduced.
@item
Gexps carry information about the packages or derivations they refer to,
and these dependencies are automatically added as inputs to the build
processes that use them.
@end itemize
@cindex lowering, of high-level objects in gexps
This mechanism is not limited to package and derivation
objects: @dfn{compilers} able to ``lower'' other high-level objects to
derivations or files in the store can be defined,
such that these objects can also be inserted
into gexps. For example, a useful type of high-level objects that can be
inserted in a gexp is ``file-like objects'', which make it easy to
derivations and such (see @code{local-file} and @code{plain-file}
below.)
To illustrate the idea, here is an example of a gexp:
@example
(define build-exp
#~(begin
(mkdir #$output)
(chdir #$output)
(symlink (string-append #$coreutils "/bin/ls")
"list-files")))
@end example
This gexp can be passed to @code{gexp->derivation}; we obtain a
derivation that builds a directory containing exactly one symlink to
@file{/gnu/store/@dots{}-coreutils-8.22/bin/ls}:
@example
(gexp->derivation "the-thing" build-exp)
@end example
As one would expect, the @code{"/gnu/store/@dots{}-coreutils-8.22"} string is
substituted to the reference to the @var{coreutils} package in the
actual build code, and @var{coreutils} is automatically made an input to
the derivation. Likewise, @code{#$output} (equivalent to @code{(ungexp
output)}) is replaced by a string containing the directory name of the
output of the derivation.
3678
3679
3680
3681
3682
3683
3684
3685
3686
3687
3688
3689
3690
3691
3692
3693
3694
3695
3696
3697
3698
3699
3700
3701
@cindex cross compilation
In a cross-compilation context, it is useful to distinguish between
references to the @emph{native} build of a package---that can run on the
host---versus references to cross builds of a package. To that end, the
@code{#+} plays the same role as @code{#$}, but is a reference to a
native package build:
@example
(gexp->derivation "vi"
#~(begin
(mkdir #$output)
(system* (string-append #+coreutils "/bin/ln")
"-s"
(string-append #$emacs "/bin/emacs")
(string-append #$output "/bin/vi")))
#:target "mips64el-linux")
@end example
@noindent
In the example above, the native build of @var{coreutils} is used, so
that @command{ln} can actually run on the host; but then the
cross-compiled build of @var{emacs} is referenced.
3702
3703
3704
3705
3706
3707
3708
3709
3710
3711
3712
3713
3714
3715
3716
3717
3718
3719
3720
3721
3722
3723
3724
3725
@cindex imported modules, for gexps
@findex with-imported-modules
Another gexp feature is @dfn{imported modules}: sometimes you want to be
able to use certain Guile modules from the ``host environment'' in the
gexp, so those modules should be imported in the ``build environment''.
The @code{with-imported-modules} form allows you to express that:
@example
(let ((build (with-imported-modules '((guix build utils))
#~(begin
(use-modules (guix build utils))
(mkdir-p (string-append #$output "/bin"))))))
(gexp->derivation "empty-dir"
#~(begin
#$build
(display "success!\n")
#t)))
@end example
@noindent
In this example, the @code{(guix build utils)} module is automatically
pulled into the isolated build environment of our gexp, such that
@code{(use-modules (guix build utils))} works as expected.
The syntactic form to construct gexps is summarized below.
@deffn {Scheme Syntax} #~@var{exp}
@deffnx {Scheme Syntax} (gexp @var{exp})
Return a G-expression containing @var{exp}. @var{exp} may contain one
or more of the following forms:
@table @code
@item #$@var{obj}
@itemx (ungexp @var{obj})
Introduce a reference to @var{obj}. @var{obj} may have one of the
supported types, for example a package or a
derivation, in which case the @code{ungexp} form is replaced by its
output file name---e.g., @code{"/gnu/store/@dots{}-coreutils-8.22}.
If @var{obj} is a list, it is traversed and references to supported
objects are substituted similarly.
If @var{obj} is another gexp, its contents are inserted and its
dependencies are added to those of the containing gexp.
If @var{obj} is another kind of object, it is inserted as is.
@item #$@var{obj}:@var{output}
@itemx (ungexp @var{obj} @var{output})
This is like the form above, but referring explicitly to the
@var{output} of @var{obj}---this is useful when @var{obj} produces
multiple outputs (@pxref{Packages with Multiple Outputs}).
@item #+@var{obj}
@itemx #+@var{obj}:output
@itemx (ungexp-native @var{obj})
@itemx (ungexp-native @var{obj} @var{output})
Same as @code{ungexp}, but produces a reference to the @emph{native}
build of @var{obj} when used in a cross compilation context.
@item #$output[:@var{output}]
@itemx (ungexp output [@var{output}])
Insert a reference to derivation output @var{output}, or to the main
output when @var{output} is omitted.
This only makes sense for gexps passed to @code{gexp->derivation}.
@item #$@@@var{lst}
@itemx (ungexp-splicing @var{lst})
Like the above, but splices the contents of @var{lst} inside the
containing list.
@item #+@@@var{lst}
@itemx (ungexp-native-splicing @var{lst})
Like the above, but refers to native builds of the objects listed in
@var{lst}.
@end table
G-expressions created by @code{gexp} or @code{#~} are run-time objects
of the @code{gexp?} type (see below.)
@end deffn
@deffn {Scheme Syntax} with-imported-modules @var{modules} @var{body}@dots{}
Mark the gexps defined in @var{body}@dots{} as requiring @var{modules}
in their execution environment. @var{modules} must be a list of Guile
module names, such as @code{'((guix build utils) (guix build gremlin))}.
This form has @emph{lexical} scope: it has an effect on the gexps
directly defined in @var{body}@dots{}, but not on those defined, say, in
procedures called from @var{body}@dots{}.
@end deffn
@deffn {Scheme Procedure} gexp? @var{obj}
Return @code{#t} if @var{obj} is a G-expression.
@end deffn
G-expressions are meant to be written to disk, either as code building
some derivation, or as plain files in the store. The monadic procedures
below allow you to do that (@pxref{The Store Monad}, for more
information about monads.)
@deffn {Monadic Procedure} gexp->derivation @var{name} @var{exp} @
[#:system (%current-system)] [#:target #f] [#:graft? #t] @
[#:hash #f] [#:hash-algo #f] @
[#:recursive? #f] [#:env-vars '()] [#:modules '()] @
[#:module-path @var{%load-path}] @
[#:references-graphs #f] [#:allowed-references #f] @
[#:leaked-env-vars #f] @
[#:script-name (string-append @var{name} "-builder")] @
[#:local-build? #f] [#:substitutable? #t] [#:guile-for-build #f]
Return a derivation @var{name} that runs @var{exp} (a gexp) with
@var{guile-for-build} (a derivation) on @var{system}; @var{exp} is
stored in a file called @var{script-name}. When @var{target} is true,
it is used as the cross-compilation target triplet for packages referred
to by @var{exp}.
@var{modules} is deprecated in favor of @code{with-imported-modules}.
Its meaning is to
make @var{modules} available in the evaluation context of @var{exp};
@var{modules} is a list of names of Guile modules searched in
@var{module-path} to be copied in the store, compiled, and made available in
the load path during the execution of @var{exp}---e.g., @code{((guix
build utils) (guix build gnu-build-system))}.
@var{graft?} determines whether packages referred to by @var{exp} should be grafted when
applicable.
When @var{references-graphs} is true, it must be a list of tuples of one of the
following forms:
@example
(@var{file-name} @var{package})
(@var{file-name} @var{package} @var{output})
(@var{file-name} @var{derivation})
(@var{file-name} @var{derivation} @var{output})
(@var{file-name} @var{store-item})
@end example
The right-hand-side of each element of @var{references-graphs} is automatically made
an input of the build process of @var{exp}. In the build environment, each
@var{file-name} contains the reference graph of the corresponding item, in a simple
text format.
@var{allowed-references} must be either @code{#f} or a list of output names and packages.
In the latter case, the list denotes store items that the result is allowed to
refer to. Any reference to another store item will lead to a build error.
Similarly for @var{disallowed-references}, which can list items that must not be
referenced by the outputs.
The other arguments are as for @code{derivation} (@pxref{Derivations}).
The @code{local-file}, @code{plain-file}, @code{computed-file},
@code{program-file}, and @code{scheme-file} procedures below return
@dfn{file-like objects}. That is, when unquoted in a G-expression,
these objects lead to a file in the store. Consider this G-expression:
@example
#~(system* (string-append #$glibc "/sbin/nscd") "-f"
#$(local-file "/tmp/my-nscd.conf"))
@end example
The effect here is to ``intern'' @file{/tmp/my-nscd.conf} by copying it
to the store. Once expanded, for instance @i{via}
@code{gexp->derivation}, the G-expression refers to that copy under
@file{/gnu/store}; thus, modifying or removing the file in @file{/tmp}
does not have any effect on what the G-expression does.
@code{plain-file} can be used similarly; it differs in that the file
content is directly passed as a string.
@deffn {Scheme Procedure} local-file @var{file} [@var{name}] @
[#:recursive? #f] [#:select? (const #t)]
Return an object representing local file @var{file} to add to the store; this
object can be used in a gexp. If @var{file} is a relative file name, it is looked
up relative to the source file where this form appears. @var{file} will be added to
the store under @var{name}--by default the base name of @var{file}.
When @var{recursive?} is true, the contents of @var{file} are added recursively; if @var{file}
designates a flat file and @var{recursive?} is true, its contents are added, and its
permission bits are kept.
When @var{recursive?} is true, call @code{(@var{select?} @var{file}
@var{stat})} for each directory entry, where @var{file} is the entry's
absolute file name and @var{stat} is the result of @code{lstat}; exclude
entries for which @var{select?} does not return true.
This is the declarative counterpart of the @code{interned-file} monadic
procedure (@pxref{The Store Monad, @code{interned-file}}).
@end deffn
@deffn {Scheme Procedure} plain-file @var{name} @var{content}
Return an object representing a text file called @var{name} with the given
@var{content} (a string) to be added to the store.
This is the declarative counterpart of @code{text-file}.
@end deffn
@deffn {Scheme Procedure} computed-file @var{name} @var{gexp} @
[#:options '(#:local-build? #t)]
Return an object representing the store item @var{name}, a file or
directory computed by @var{gexp}. @var{options}
is a list of additional arguments to pass to @code{gexp->derivation}.
This is the declarative counterpart of @code{gexp->derivation}.
@end deffn
@deffn {Monadic Procedure} gexp->script @var{name} @var{exp}
Return an executable script @var{name} that runs @var{exp} using
@var{guile}, with @var{exp}'s imported modules in its search path.
The example below builds a script that simply invokes the @command{ls}
command:
@example
(use-modules (guix gexp) (gnu packages base))
(gexp->script "list-files"
#~(execl (string-append #$coreutils "/bin/ls")
"ls"))
@end example
When ``running'' it through the store (@pxref{The Store Monad,
@code{run-with-store}}), we obtain a derivation that produces an
executable file @file{/gnu/store/@dots{}-list-files} along these lines:
@example
#!/gnu/store/@dots{}-guile-2.0.11/bin/guile -ds
!#
(execl (string-append "/gnu/store/@dots{}-coreutils-8.22"/bin/ls")
"ls")
@end example
@end deffn
@deffn {Scheme Procedure} program-file @var{name} @var{exp} @
[#:guile #f]
Return an object representing the executable store item @var{name} that
runs @var{gexp}. @var{guile} is the Guile package used to execute that
script.
This is the declarative counterpart of @code{gexp->script}.
@end deffn
@deffn {Monadic Procedure} gexp->file @var{name} @var{exp} @
[#:set-load-path? #t]
Return a derivation that builds a file @var{name} containing @var{exp}.
When @var{set-load-path?} is true, emit code in the resulting file to
set @code{%load-path} and @code{%load-compiled-path} to honor
@var{exp}'s imported modules.
The resulting file holds references to all the dependencies of @var{exp}
or a subset thereof.
@end deffn
@deffn {Scheme Procedure} scheme-file @var{name} @var{exp}
Return an object representing the Scheme file @var{name} that contains
@var{exp}.
This is the declarative counterpart of @code{gexp->file}.
@end deffn
@deffn {Monadic Procedure} text-file* @var{name} @var{text} @dots{}
Return as a monadic value a derivation that builds a text file
containing all of @var{text}. @var{text} may list, in addition to
strings, objects of any type that can be used in a gexp: packages,
derivations, local file objects, etc. The resulting store file holds
references to all these.
This variant should be preferred over @code{text-file} anytime the file
to create will reference items from the store. This is typically the
case when building a configuration file that embeds store file names,
like this:
@example
(define (profile.sh)
;; Return the name of a shell script in the store that
;; initializes the 'PATH' environment variable.
(text-file* "profile.sh"
"export PATH=" coreutils "/bin:"
grep "/bin:" sed "/bin\n"))
@end example
In this example, the resulting @file{/gnu/store/@dots{}-profile.sh} file
will reference @var{coreutils}, @var{grep}, and @var{sed}, thereby
preventing them from being garbage-collected during its lifetime.
@end deffn
@deffn {Scheme Procedure} mixed-text-file @var{name} @var{text} @dots{}
Return an object representing store file @var{name} containing
@var{text}. @var{text} is a sequence of strings and file-like objects,
as in:
@example
(mixed-text-file "profile"
"export PATH=" coreutils "/bin:" grep "/bin")
@end example
This is the declarative counterpart of @code{text-file*}.
@end deffn
Of course, in addition to gexps embedded in ``host'' code, there are
also modules containing build tools. To make it clear that they are
meant to be used in the build stratum, these modules are kept in the
@code{(guix build @dots{})} name space.
@cindex lowering, of high-level objects in gexps
Internally, high-level objects are @dfn{lowered}, using their compiler,
to either derivations or store items. For instance, lowering a package
yields a derivation, and lowering a @code{plain-file} yields a store
item. This is achieved using the @code{lower-object} monadic procedure.
@deffn {Monadic Procedure} lower-object @var{obj} [@var{system}] @
[#:target #f]
Return as a value in @var{%store-monad} the derivation or store item
corresponding to @var{obj} for @var{system}, cross-compiling for
@var{target} if @var{target} is true. @var{obj} must be an object that
has an associated gexp compiler, such as a @code{<package>}.
@end deffn
@c *********************************************************************
@node Utilities
@chapter Utilities
This section describes Guix command-line utilities. Some of them are
primarily targeted at developers and users who write new package
definitions, while others are more generally useful. They complement
the Scheme programming interface of Guix in a convenient way.
* Invoking guix build:: Building packages from the command line.
* Invoking guix download:: Downloading a file and printing its hash.
* Invoking guix hash:: Computing the cryptographic hash of a file.
* Invoking guix import:: Importing package definitions.
* Invoking guix refresh:: Updating package definitions.
* Invoking guix lint:: Finding errors in package definitions.
* Invoking guix graph:: Visualizing the graph of packages.
* Invoking guix environment:: Setting up development environments.
* Invoking guix publish:: Sharing substitutes.
* Invoking guix challenge:: Challenging substitute servers.
* Invoking guix container:: Process isolation.
@node Invoking guix build
@section Invoking @command{guix build}
The @command{guix build} command builds packages or derivations and
their dependencies, and prints the resulting store paths. Note that it
does not modify the user's profile---this is the job of the
@command{guix package} command (@pxref{Invoking guix package}). Thus,
it is mainly useful for distribution developers.
The general syntax is:
guix build @var{options} @var{package-or-derivation}@dots{}
As an example, the following command builds the latest versions of Emacs
and of Guile, displays their build logs, and finally displays the
resulting directories:
@example
guix build emacs guile
@end example
Similarly, the following command builds all the available packages:
@example
`guix package -A | cut -f1,2 --output-delimiter=@@`
@end example
@var{package-or-derivation} may be either the name of a package found in
the software distribution such as @code{coreutils} or
@code{coreutils-8.20}, or a derivation such as
@file{/gnu/store/@dots{}-coreutils-8.19.drv}. In the former case, a
package with the corresponding name (and optionally version) is searched
for among the GNU distribution modules (@pxref{Package Modules}).
Alternatively, the @code{--expression} option may be used to specify a
Scheme expression that evaluates to a package; this is useful when
disambiguating among several same-named packages or package variants is
needed.
There may be zero or more @var{options}. The available options are
described in the subsections below.
@menu
* Common Build Options:: Build options for most commands.
* Package Transformation Options:: Creating variants of packages.
4097
4098
4099
4100
4101
4102
4103
4104
4105
4106
4107
4108
4109
4110
4111
4112
4113
4114
4115
4116
4117
4118
4119
* Additional Build Options:: Options specific to 'guix build'.
@end menu
@node Common Build Options
@subsection Common Build Options
A number of options that control the build process are common to
@command{guix build} and other commands that can spawn builds, such as
@command{guix package} or @command{guix archive}. These are the
following:
@table @code
@item --load-path=@var{directory}
@itemx -L @var{directory}
Add @var{directory} to the front of the package module search path
(@pxref{Package Modules}).
This allows users to define their own packages and make them visible to
the command-line tools.
@item --keep-failed
@itemx -K
Keep the build tree of failed builds. Thus, if a build fails, its build
4121
4122
4123
4124
4125
4126
4127
4128
4129
4130
4131
4132
4133
4134
4135
4136
4137
4138
4139
4140
4141
4142
4143
4144
4145
4146
4147
4148
4149
tree is kept under @file{/tmp}, in a directory whose name is shown at
the end of the build log. This is useful when debugging build issues.
@item --keep-going
@itemx -k
Keep going when some of the derivations fail to build; return only once
all the builds have either completed or failed.
The default behavior is to stop as soon as one of the specified
derivations has failed.
@item --dry-run
@itemx -n
Do not build the derivations.
@item --fallback
When substituting a pre-built binary fails, fall back to building
packages locally.
@item --substitute-urls=@var{urls}
@anchor{client-substitute-urls}
Consider @var{urls} the whitespace-separated list of substitute source
URLs, overriding the default list of URLs of @command{guix-daemon}
(@pxref{daemon-substitute-urls,, @command{guix-daemon} URLs}).
This means that substitutes may be downloaded from @var{urls}, provided
they are signed by a key authorized by the system administrator
(@pxref{Substitutes}).
When @var{urls} is the empty string, substitutes are effectively
disabled.
@item --no-substitutes
Do not use substitutes for build products. That is, always build things
locally instead of allowing downloads of pre-built binaries
(@pxref{Substitutes}).
@item --no-grafts
Do not ``graft'' packages. In practice, this means that package updates
available as grafts are not applied. @xref{Security Updates}, for more
information on grafts.
@item --rounds=@var{n}
Build each derivation @var{n} times in a row, and raise an error if
consecutive build results are not bit-for-bit identical.
This is a useful way to detect non-deterministic builds processes.
Non-deterministic build processes are a problem because they make it
practically impossible for users to @emph{verify} whether third-party
binaries are genuine. @xref{Invoking guix challenge}, for more.
Note that, currently, the differing build results are not kept around,
so you will have to manually investigate in case of an error---e.g., by
stashing one of the build results with @code{guix archive --export}
(@pxref{Invoking guix archive}), then rebuilding, and finally comparing
the two results.
@item --no-build-hook
Do not attempt to offload builds @i{via} the ``build hook'' of the daemon
4180
4181
4182
4183
4184
4185
4186
4187
4188
4189
4190
4191
4192
4193
4194
4195
4196
4197
4198
4199
4200
(@pxref{Daemon Offload Setup}). That is, always build things locally
instead of offloading builds to remote machines.
@item --max-silent-time=@var{seconds}
When the build or substitution process remains silent for more than
@var{seconds}, terminate it and report a build failure.
@item --timeout=@var{seconds}
Likewise, when the build or substitution process lasts for more than
@var{seconds}, terminate it and report a build failure.
By default there is no timeout. This behavior can be restored with
@code{--timeout=0}.
@item --verbosity=@var{level}
Use the given verbosity level. @var{level} must be an integer between 0
and 5; higher means more verbose output. Setting a level of 4 or more
may be helpful when debugging setup issues with the build daemon.
@item --cores=@var{n}
@itemx -c @var{n}
4201
4202
4203
4204
4205
4206
4207
4208
4209
4210
4211
4212
4213
4214
4215
4216
4217
4218
4219
4220
4221
4222
4223
4224
4225
4226
4227
4228
4229
4230
4231
4232
4233
4234
Allow the use of up to @var{n} CPU cores for the build. The special
value @code{0} means to use as many CPU cores as available.
@item --max-jobs=@var{n}
@itemx -M @var{n}
Allow at most @var{n} build jobs in parallel. @xref{Invoking
guix-daemon, @code{--max-jobs}}, for details about this option and the
equivalent @command{guix-daemon} option.
@end table
Behind the scenes, @command{guix build} is essentially an interface to
the @code{package-derivation} procedure of the @code{(guix packages)}
module, and to the @code{build-derivations} procedure of the @code{(guix
derivations)} module.
In addition to options explicitly passed on the command line,
@command{guix build} and other @command{guix} commands that support
building honor the @code{GUIX_BUILD_OPTIONS} environment variable.
@defvr {Environment Variable} GUIX_BUILD_OPTIONS
Users can define this variable to a list of command line options that
will automatically be used by @command{guix build} and other
@command{guix} commands that can perform builds, as in the example
below:
@example
$ export GUIX_BUILD_OPTIONS="--no-substitutes -c 2 -L /foo/bar"
@end example
These options are parsed independently, and the result is appended to
the parsed command-line options.
@end defvr
@node Package Transformation Options
@subsection Package Transformation Options
@cindex package variants
Another set of command-line options supported by @command{guix build}
and also @command{guix package} are @dfn{package transformation
options}. These are options that make it possible to define @dfn{package
variants}---for instance, packages built from different source code.
This is a convenient way to create customized packages on the fly
without having to type in the definitions of package variants
(@pxref{Defining Packages}).
@table @code
@item --with-source=@var{source}
Use @var{source} as the source of the corresponding package.
@var{source} must be a file name or a URL, as for @command{guix
download} (@pxref{Invoking guix download}).
The ``corresponding package'' is taken to be the one specified on the
command line the name of which matches the base of @var{source}---e.g.,
if @var{source} is @code{/src/guile-2.0.10.tar.gz}, the corresponding
package is @code{guile}. Likewise, the version string is inferred from
@var{source}; in the previous example, it is @code{2.0.10}.
4260
4261
4262
4263
4264
4265
4266
4267
4268
4269
4270
4271
4272
4273
4274
4275
4276
4277
4278
4279
4280
4281
4282
4283
This option allows users to try out versions of packages other than the
one provided by the distribution. The example below downloads
@file{ed-1.7.tar.gz} from a GNU mirror and uses that as the source for
the @code{ed} package:
@example
guix build ed --with-source=mirror://gnu/ed/ed-1.7.tar.gz
@end example
As a developer, @code{--with-source} makes it easy to test release
candidates:
@example
guix build guile --with-source=../guile-2.0.9.219-e1bb7.tar.xz
@end example
@dots{} or to build from a checkout in a pristine environment:
@example
$ git clone git://git.sv.gnu.org/guix.git
$ guix build guix --with-source=./guix
@end example
@item --with-input=@var{package}=@var{replacement}
Replace dependency on @var{package} by a dependency on
@var{replacement}. @var{package} must be a package name, and
@var{replacement} must be a package specification such as @code{guile}
or @code{guile@@1.8}.
For instance, the following command builds Guix, but replaces its
dependency on the current stable version of Guile with a dependency on
the development version of Guile, @code{guile-next}:
@example
guix build --with-input=guile=guile-next guix
@end example
This is a recursive, deep replacement. So in this example, both
@code{guix} and its dependency @code{guile-json} (which also depends on
@code{guile}) get rebuilt against @code{guile-next}.
However, implicit inputs are left unchanged.
@node Additional Build Options
@subsection Additional Build Options
The command-line options presented below are specific to @command{guix
build}.
@item --quiet
@itemx -q
Build quietly, without displaying the build log. Upon completion, the
build log is kept in @file{/var} (or similar) and can always be
retrieved using the @option{--log-file} option.
@item --file=@var{file}
@itemx -f @var{file}
Build the package or derivation that the code within @var{file}
evaluates to.
As an example, @var{file} might contain a package definition like this
(@pxref{Defining Packages}):
@example
@verbatiminclude package-hello.scm
@end example
@item --expression=@var{expr}
@itemx -e @var{expr}
Build the package or derivation @var{expr} evaluates to.
For example, @var{expr} may be @code{(@@ (gnu packages guile)
guile-1.8)}, which unambiguously designates this specific variant of
version 1.8 of Guile.
Alternatively, @var{expr} may be a G-expression, in which case it is used
as a build program passed to @code{gexp->derivation}
(@pxref{G-Expressions}).
Lastly, @var{expr} may refer to a zero-argument monadic procedure
(@pxref{The Store Monad}). The procedure must return a derivation as a
monadic value, which is then passed through @code{run-with-store}.
Build the source derivations of the packages, rather than the packages
For instance, @code{guix build -S gcc} returns something like
@file{/gnu/store/@dots{}-gcc-4.7.2.tar.bz2}, which is the GCC
source tarball.
The returned source tarball is the result of applying any patches and
code snippets specified in the package @code{origin} (@pxref{Defining
@item --sources
Fetch and return the source of @var{package-or-derivation} and all their
dependencies, recursively. This is a handy way to obtain a local copy
of all the source code needed to build @var{packages}, allowing you to
eventually build them even without network access. It is an extension
of the @code{--source} option and can accept one of the following
optional argument values:
@table @code
@item package
This value causes the @code{--sources} option to behave in the same way
as the @code{--source} option.
@item all
Build the source derivations of all packages, including any source that
might be listed as @code{inputs}. This is the default value.
@example
$ guix build --sources tzdata
The following derivations will be built:
/gnu/store/@dots{}-tzdata2015b.tar.gz.drv
/gnu/store/@dots{}-tzcode2015b.tar.gz.drv
@end example
@item transitive
Build the source derivations of all packages, as well of all transitive
inputs to the packages. This can be used e.g. to
prefetch package source for later offline building.
@example
$ guix build --sources=transitive tzdata
The following derivations will be built:
/gnu/store/@dots{}-tzcode2015b.tar.gz.drv
/gnu/store/@dots{}-findutils-4.4.2.tar.xz.drv
/gnu/store/@dots{}-grep-2.21.tar.xz.drv
/gnu/store/@dots{}-coreutils-8.23.tar.xz.drv
/gnu/store/@dots{}-make-4.1.tar.xz.drv
/gnu/store/@dots{}-bash-4.3.tar.xz.drv
@dots{}
@end example
@end table
@item --system=@var{system}
@itemx -s @var{system}
Attempt to build for @var{system}---e.g., @code{i686-linux}---instead of
An example use of this is on Linux-based systems, which can emulate
different personalities. For instance, passing
@code{--system=i686-linux} on an @code{x86_64-linux} system allows users
to build packages in a complete 32-bit environment.
@item --target=@var{triplet}
@cindex cross-compilation
Cross-build for @var{triplet}, which must be a valid GNU triplet, such
as @code{"mips64el-linux-gnu"} (@pxref{Configuration Names, GNU
configuration triplets,, configure, GNU Configure and Build System}).
@anchor{build-check}
@item --check
@cindex determinism, checking
@cindex reproducibility, checking
Rebuild @var{package-or-derivation}, which are already available in the
store, and raise an error if the build results are not bit-for-bit
identical.
This mechanism allows you to check whether previously installed
substitutes are genuine (@pxref{Substitutes}), or whether the build result
of a package is deterministic. @xref{Invoking guix challenge}, for more
When used in conjunction with @option{--keep-failed}, the differing
output is kept in the store, under @file{/gnu/store/@dots{}-check}.
This makes it easy to look for differences between the two results.
@item --derivations
@itemx -d
Return the derivation paths, not the output paths, of the given
packages.
@item --root=@var{file}
@itemx -r @var{file}
Make @var{file} a symlink to the result, and register it as a garbage
collector root.
@item --log-file
Return the build log file names or URLs for the given
@var{package-or-derivation}, or raise an error if build logs are
missing.
This works regardless of how packages or derivations are specified. For
instance, the following invocations are equivalent:
@example
guix build --log-file `guix build -d guile`
guix build --log-file `guix build guile`
guix build --log-file guile
guix build --log-file -e '(@@ (gnu packages guile) guile-2.0)'
@end example
If a log is unavailable locally, and unless @code{--no-substitutes} is
passed, the command looks for a corresponding log on one of the
substitute servers (as specified with @code{--substitute-urls}.)
So for instance, imagine you want to see the build log of GDB on MIPS,
but you are actually on an @code{x86_64} machine:
$ guix build --log-file gdb -s mips64el-linux
https://hydra.gnu.org/log/@dots{}-gdb-7.10
@end example
You can freely access a huge library of build logs!
@end table
@node Invoking guix edit
@section Invoking @command{guix edit}
@cindex package definition, editing
So many packages, so many source files! The @command{guix edit} command
facilitates the life of packagers by pointing their editor at the source
file containing the definition of the specified packages. For instance:
@example
guix edit gcc@@4.9 vim
launches the program specified in the @code{VISUAL} or in the
@code{EDITOR} environment variable to edit the recipe of GCC@tie{}4.9.3
If you are using Emacs, note that the Emacs user interface provides the
@kbd{M-x guix-edit} command and a similar functionality in the ``package
info'' and ``package list'' buffers created by the @kbd{M-x
guix-search-by-name} and similar commands (@pxref{Emacs Commands}).
@node Invoking guix download
@section Invoking @command{guix download}
When writing a package definition, developers typically need to download
a source tarball, compute its SHA256 hash, and write that
hash in the package definition (@pxref{Defining Packages}). The
@command{guix download} tool helps with this task: it downloads a file
from the given URI, adds it to the store, and prints both its file name
in the store and its SHA256 hash.
The fact that the downloaded file is added to the store saves bandwidth:
when the developer eventually tries to build the newly defined package
with @command{guix build}, the source tarball will not have to be
downloaded again because it is already in the store. It is also a
convenient way to temporarily stash files, which may be deleted
eventually (@pxref{Invoking guix gc}).
The @command{guix download} command supports the same URIs as used in
package definitions. In particular, it supports @code{mirror://} URIs.
@code{https} URIs (HTTP over TLS) are supported @emph{provided} the
Guile bindings for GnuTLS are available in the user's environment; when
they are not available, an error is raised. @xref{Guile Preparations,
how to install the GnuTLS bindings for Guile,, gnutls-guile,
GnuTLS-Guile}, for more information.
The following option is available:
@table @code
@item --format=@var{fmt}
@itemx -f @var{fmt}
Write the hash in the format specified by @var{fmt}. For more
information on the valid values for @var{fmt}, @pxref{Invoking guix hash}.
@node Invoking guix hash
@section Invoking @command{guix hash}
The @command{guix hash} command computes the SHA256 hash of a file.
It is primarily a convenience tool for anyone contributing to the
distribution: it computes the cryptographic hash of a file, which can be
used in the definition of a package (@pxref{Defining Packages}).
The general syntax is:
@example
guix hash @var{option} @var{file}
@end example
@command{guix hash} has the following option:
@table @code
@item --format=@var{fmt}
@itemx -f @var{fmt}
Write the hash in the format specified by @var{fmt}.
Supported formats: @code{nix-base32}, @code{base32}, @code{base16}
(@code{hex} and @code{hexadecimal} can be used as well).
If the @option{--format} option is not specified, @command{guix hash}
will output the hash in @code{nix-base32}. This representation is used
in the definitions of packages.
@item --recursive
@itemx -r
Compute the hash on @var{file} recursively.
In this case, the hash is computed on an archive containing @var{file},
including its children if it is a directory. Some of the metadata of
@var{file} is part of the archive; for instance, when @var{file} is a
regular file, the hash is different depending on whether @var{file} is
executable or not. Metadata such as time stamps has no impact on the
hash (@pxref{Invoking guix archive}).
@c FIXME: Replace xref above with xref to an ``Archive'' section when
@c it exists.
@vindex git-fetch
As an example, here is how you would compute the hash of a Git checkout,
which is useful when using the @code{git-fetch} method (@pxref{origin
Reference}):
@example
$ git clone http://example.org/foo.git
$ cd foo
$ rm -rf .git
$ guix hash -r .
@end example
@node Invoking guix import
@section Invoking @command{guix import}
@cindex importing packages
@cindex package import
@cindex package conversion
The @command{guix import} command is useful for people who would like to
add a package to the distribution with as little work as
possible---a legitimate demand. The command knows of a few
repositories from which it can ``import'' package metadata. The result
is a package definition, or a template thereof, in the format we know
(@pxref{Defining Packages}).
The general syntax is:
@example
guix import @var{importer} @var{options}@dots{}
@end example
@var{importer} specifies the source from which to import package
metadata, and @var{options} specifies a package identifier and other
options specific to @var{importer}. Currently, the available
``importers'' are:
@table @code
@item gnu
Import metadata for the given GNU package. This provides a template
for the latest version of that GNU package, including the hash of its
source tarball, and its canonical synopsis and description.
Additional information such as the package dependencies and its
license needs to be figured out manually.
For example, the following command returns a package definition for
GNU@tie{}Hello:
@example
guix import gnu hello
@end example
Specific command-line options are:
@table @code
@item --key-download=@var{policy}
As for @code{guix refresh}, specify the policy to handle missing OpenPGP
keys when verifying the package signature. @xref{Invoking guix
refresh, @code{--key-download}}.
@end table
@item pypi
@cindex pypi
Import metadata from the @uref{https://pypi.python.org/, Python Package
Index}@footnote{This functionality requires Guile-JSON to be installed.
@xref{Requirements}.}. Information is taken from the JSON-formatted
description available at @code{pypi.python.org} and usually includes all
the relevant information, including package dependencies. For maximum
efficiency, it is recommended to install the @command{unzip} utility, so
that the importer can unzip Python wheels and gather data from them.
The command below imports metadata for the @code{itsdangerous} Python
package:
@example
guix import pypi itsdangerous
@end example
RubyGems}@footnote{This functionality requires Guile-JSON to be
installed. @xref{Requirements}.}. Information is taken from the
JSON-formatted description available at @code{rubygems.org} and includes
most relevant information, including runtime dependencies. There are
some caveats, however. The metadata doesn't distinguish between
synopses and descriptions, so the same string is used for both fields.
Additionally, the details of non-Ruby dependencies required to build
native extensions is unavailable and left as an exercise to the
packager.
The command below imports metadata for the @code{rails} Ruby package:
@example
guix import gem rails
@end example
Import metadata from @uref{https://www.metacpan.org/, MetaCPAN}@footnote{This
functionality requires Guile-JSON to be installed.
@xref{Requirements}.}.
Information is taken from the JSON-formatted metadata provided through
@uref{https://api.metacpan.org/, MetaCPAN's API} and includes most
relevant information, such as module dependencies. License information
should be checked closely. If Perl is available in the store, then the
@code{corelist} utility will be used to filter core modules out of the
list of dependencies.
The command command below imports metadata for the @code{Acme::Boolean}
Perl module:
@example
guix import cpan Acme::Boolean
@end example
Import metadata from @uref{http://cran.r-project.org/, CRAN}, the
central repository for the @uref{http://r-project.org, GNU@tie{}R
statistical and graphical environment}.
Information is extracted from the @code{DESCRIPTION} file of the package.
The command command below imports metadata for the @code{Cairo}
R package:
@example
guix import cran Cairo
@end example
When @code{--archive=bioconductor} is added, metadata is imported from
@uref{http://www.bioconductor.org/, Bioconductor}, a repository of R
packages for for the analysis and comprehension of high-throughput
genomic data in bioinformatics.
Information is extracted from the @code{DESCRIPTION} file of a package
published on the web interface of the Bioconductor SVN repository.
The command below imports metadata for the @code{GenomicRanges}
R package:
@example
guix import cran --archive=bioconductor GenomicRanges
@end example
Import metadata from a local copy of the source of the
@uref{http://nixos.org/nixpkgs/, Nixpkgs distribution}@footnote{This
relies on the @command{nix-instantiate} command of
@uref{http://nixos.org/nix/, Nix}.}. Package definitions in Nixpkgs are
typically written in a mixture of Nix-language and Bash code. This
command only imports the high-level package structure that is written in
the Nix language. It normally includes all the basic fields of a
package definition.
When importing a GNU package, the synopsis and descriptions are replaced
by their canonical upstream variant.
Usually, you will first need to do:
@example
export NIX_REMOTE=daemon
@end example
@noindent
so that @command{nix-instantiate} does not try to open the Nix database.
As an example, the command below imports the package definition of
LibreOffice (more precisely, it imports the definition of the package
bound to the @code{libreoffice} top-level attribute):
@example
guix import nix ~/path/to/nixpkgs libreoffice
@end example
Import metadata from the Haskell community's central package archive
@uref{https://hackage.haskell.org/, Hackage}. Information is taken from
Cabal files and includes all the relevant information, including package
dependencies.
Specific command-line options are:
@table @code
@item --stdin
@itemx -s
@item --no-test-dependencies
@itemx -t
Do not include dependencies required only by the test suites.
@item --cabal-environment=@var{alist}
@itemx -e @var{alist}
@var{alist} is a Scheme alist defining the environment in which the
Cabal conditionals are evaluated. The accepted keys are: @code{os},
@code{arch}, @code{impl} and a string representing the name of a flag.
The value associated with a flag has to be either the symbol
@code{true} or @code{false}. The value associated with other keys
has to conform to the Cabal file format definition. The default value
associated with the keys @code{os}, @code{arch} and @code{impl} is
@samp{linux}, @samp{x86_64} and @samp{ghc}, respectively.
The command below imports metadata for the latest version of the
@code{HTTP} Haskell package without including test dependencies and
specifying the value of the flag @samp{network-uri} as @code{false}:
guix import hackage -t -e "'((\"network-uri\" . false))" HTTP
@end example
A specific package version may optionally be specified by following the
package name by an at-sign and a version number as in the following example:
guix import hackage mtl@@2.1.3.1
Import metadata from an Emacs Lisp Package Archive (ELPA) package
repository (@pxref{Packages,,, emacs, The GNU Emacs Manual}).
Specific command-line options are:
@table @code
@item --archive=@var{repo}
@itemx -a @var{repo}
@var{repo} identifies the archive repository from which to retrieve the
information. Currently the supported repositories and their identifiers
are:
@itemize -
@item
@uref{http://elpa.gnu.org/packages, GNU}, selected by the @code{gnu}
identifier. This is the default.
@item
@uref{http://stable.melpa.org/packages, MELPA-Stable}, selected by the
@code{melpa-stable} identifier.
@item
@uref{http://melpa.org/packages, MELPA}, selected by the @code{melpa}
identifier.
@end itemize
@end table
@end table
The structure of the @command{guix import} code is modular. It would be
useful to have more importers for other package formats, and your help
is welcome here (@pxref{Contributing}).
@node Invoking guix refresh
@section Invoking @command{guix refresh}
The primary audience of the @command{guix refresh} command is developers
of the GNU software distribution. By default, it reports any packages
provided by the distribution that are outdated compared to the latest
upstream version, like this:
@example
$ guix refresh
gnu/packages/gettext.scm:29:13: gettext would be upgraded from 0.18.1.1 to 0.18.2.1
gnu/packages/glib.scm:77:12: glib would be upgraded from 2.34.3 to 2.37.0
@end example
It does so by browsing the FTP directory of each package and determining
the highest version number of the source tarballs therein. The command
knows how to update specific types of packages: GNU packages, ELPA
packages, etc.---see the documentation for @option{--type} below. The
are many packages, though, for which it lacks a method to determine
whether a new upstream release is available. However, the mechanism is
extensible, so feel free to get in touch with us to add a new method!
When passed @code{--update}, it modifies distribution source files to
update the version numbers and source tarball hashes of those package
recipes (@pxref{Defining Packages}). This is achieved by downloading
each package's latest source tarball and its associated OpenPGP
signature, authenticating the downloaded tarball against its signature
using @command{gpg}, and finally computing its hash. When the public
key used to sign the tarball is missing from the user's keyring, an
attempt is made to automatically retrieve it from a public key server;
when this is successful, the key is added to the user's keyring; otherwise,
@command{guix refresh} reports an error.
The following options are supported:
@table @code
@item --expression=@var{expr}
@itemx -e @var{expr}
Consider the package @var{expr} evaluates to.
This is useful to precisely refer to a package, as in this example:
@example
guix refresh -l -e '(@@@@ (gnu packages commencement) glibc-final)'
@end example
This command lists the dependents of the ``final'' libc (essentially all
the packages.)
Update distribution source files (package recipes) in place. This is
usually run from a checkout of the Guix source tree (@pxref{Running
Guix Before It Is Installed}):
@example
$ ./pre-inst-env guix refresh -s non-core
@end example
@xref{Defining Packages}, for more information on package definitions.
@item --select=[@var{subset}]
@itemx -s @var{subset}
Select all the packages in @var{subset}, one of @code{core} or
@code{non-core}.
The @code{core} subset refers to all the packages at the core of the
distribution---i.e., packages that are used to build ``everything
else''. This includes GCC, libc, Binutils, Bash, etc. Usually,
changing one of these packages in the distribution entails a rebuild of
all the others. Thus, such updates are an inconvenience to users in
terms of build time or bandwidth used to achieve the upgrade.
The @code{non-core} subset refers to the remaining packages. It is
typically useful in cases where an update of the core packages would be
inconvenient.
@item --type=@var{updater}
@itemx -t @var{updater}
Select only packages handled by @var{updater} (may be a comma-separated
list of updaters). Currently, @var{updater} may be one of:
@table @code
@item gnu
the updater for GNU packages;
@item gnome
the updater for GNOME packages;
@item xorg
the updater for X.org packages;
the updater for @uref{http://elpa.gnu.org/, ELPA} packages;
@item cran
the updater for @uref{http://cran.r-project.org/, CRAN} packages;
@item bioconductor
the updater for @uref{http://www.bioconductor.org/, Bioconductor} R packages;
the updater for @uref{https://pypi.python.org, PyPI} packages.
@item gem
the updater for @uref{https://rubygems.org, RubyGems} packages.
@item github
the updater for @uref{https://github.com, GitHub} packages.
@item hackage
the updater for @uref{https://hackage.haskell.org, Hackage} packages.
For instance, the following command only checks for updates of Emacs
packages hosted at @code{elpa.gnu.org} and for updates of CRAN packages:
$ guix refresh --type=elpa,cran
gnu/packages/statistics.scm:819:13: r-testthat would be upgraded from 0.10.0 to 0.11.0
gnu/packages/emacs.scm:856:13: emacs-auctex would be upgraded from 11.88.6 to 11.88.9
@end example
@end table
In addition, @command{guix refresh} can be passed one or more package
names, as in this example:
@example
$ ./pre-inst-env guix refresh -u emacs idutils gcc-4.8.4
@end example
@noindent
The command above specifically updates the @code{emacs} and
@code{idutils} packages. The @code{--select} option would have no
effect in this case.
When considering whether to upgrade a package, it is sometimes
convenient to know which packages would be affected by the upgrade and
should be checked for compatibility. For this the following option may
be used when passing @command{guix refresh} one or more package names:
@table @code
@item --list-updaters
@itemx -L
List available updaters and exit (see @option{--type} above.)
@item --list-dependent
@itemx -l
List top-level dependent packages that would need to be rebuilt as a
result of upgrading one or more packages.
@end table
Be aware that the @code{--list-dependent} option only
@emph{approximates} the rebuilds that would be required as a result of
an upgrade. More rebuilds might be required under some circumstances.
@example
$ guix refresh --list-dependent flex
Building the following 120 packages would ensure 213 dependent packages are rebuilt:
hop-2.4.0 geiser-0.4 notmuch-0.18 mu-0.9.9.5 cflow-1.4 idutils-4.6 @dots{}
@end example
The command above lists a set of packages that could be built to check
for compatibility with an upgraded @code{flex} package.
The following options can be used to customize GnuPG operation:
@table @code
@item --gpg=@var{command}
Use @var{command} as the GnuPG 2.x command. @var{command} is searched
for in @code{$PATH}.
@item --key-download=@var{policy}
Handle missing OpenPGP keys according to @var{policy}, which may be one
of:
@table @code
@item always
Always download missing OpenPGP keys from the key server, and add them
to the user's GnuPG keyring.
@item never
Never try to download missing OpenPGP keys. Instead just bail out.
@item interactive
When a package signed with an unknown OpenPGP key is encountered, ask
the user whether to download it or not. This is the default behavior.
@end table
@item --key-server=@var{host}
Use @var{host} as the OpenPGP key server when importing a public key.
The @code{github} updater uses the
@uref{https://developer.github.com/v3/, GitHub API} to query for new
releases. When used repeatedly e.g. when refreshing all packages,
GitHub will eventually refuse to answer any further API requests. By
default 60 API requests per hour are allowed, and a full refresh on all
GitHub packages in Guix requires more than this. Authentication with
GitHub through the use of an API token alleviates these limits. To use
an API token, set the environment variable @code{GUIX_GITHUB_TOKEN} to a
token procured from @uref{https://github.com/settings/tokens} or
otherwise.
@node Invoking guix lint
@section Invoking @command{guix lint}
The @command{guix lint} command is meant to help package developers avoid
common errors and use a consistent style. It runs a number of checks on
a given set of packages in order to find common mistakes in their
definitions. Available @dfn{checkers} include (see
@code{--list-checkers} for a complete list):
@table @code
@item synopsis
@itemx description
Validate certain typographical and stylistic rules about package
descriptions and synopses.
@item inputs-should-be-native
Identify inputs that should most likely be native inputs.
@item source
@itemx home-page
@itemx source-file-name
Probe @code{home-page} and @code{source} URLs and report those that are
invalid. Check that the source file name is meaningful, e.g. is not
just a version number or ``git-checkout'', without a declared
@code{file-name} (@pxref{origin Reference}).
@cindex security vulnerabilities
@cindex CVE, Common Vulnerabilities and Exposures
Report known vulnerabilities found in the Common Vulnerabilities and
Exposures (CVE) databases of the current and past year
@uref{https://nvd.nist.gov/download.cfm#CVE_FEED, published by the US
NIST}.
To view information about a particular vulnerability, visit pages such as:
@itemize
@item
@indicateurl{https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-YYYY-ABCD}
@item
@indicateurl{https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-YYYY-ABCD}
@end itemize
@noindent
where @code{CVE-YYYY-ABCD} is the CVE identifier---e.g.,
@code{CVE-2015-7554}.
Package developers can specify in package recipes the
@uref{https://nvd.nist.gov/cpe.cfm,Common Platform Enumeration (CPE)}
name and version of the package when they differ from the name that Guix
uses, as in this example:
@example
(package
(name "grub")
;; @dots{}
;; CPE calls this package "grub2".
(properties '((cpe-name . "grub2"))))
@end example
@item formatting
Warn about obvious source code formatting issues: trailing white space,
use of tabulations, etc.
The general syntax is:
@example
guix lint @var{options} @var{package}@dots{}
@end example
If no package is given on the command line, then all packages are checked.
The @var{options} may be zero or more of the following:
@table @code
@item --list-checkers
@itemx -l
List and describe all the available checkers that will be run on packages
and exit.
@item --checkers
@itemx -c
Only enable the checkers specified in a comma-separated list using the
names returned by @code{--list-checkers}.
@node Invoking guix size
@section Invoking @command{guix size}
The @command{guix size} command helps package developers profile the
disk usage of packages. It is easy to overlook the impact of an
additional dependency added to a package, or the impact of using a
single output for a package that could easily be split (@pxref{Packages
with Multiple Outputs}). Such are the typical issues that
5127
5128
5129
5130
5131
5132
5133
5134
5135
5136
5137
5138
5139
5140
5141
5142
5143
5144
5145
5146
5147
5148
5149
5150
5151
5152
@command{guix size} can highlight.
The command can be passed a package specification such as @code{gcc-4.8}
or @code{guile:debug}, or a file name in the store. Consider this
example:
@example
$ guix size coreutils
store item total self
/gnu/store/@dots{}-coreutils-8.23 70.0 13.9 19.8%
/gnu/store/@dots{}-gmp-6.0.0a 55.3 2.5 3.6%
/gnu/store/@dots{}-acl-2.2.52 53.7 0.5 0.7%
/gnu/store/@dots{}-attr-2.4.46 53.2 0.3 0.5%
/gnu/store/@dots{}-gcc-4.8.4-lib 52.9 15.7 22.4%
/gnu/store/@dots{}-glibc-2.21 37.2 37.2 53.1%
@end example
@cindex closure
The store items listed here constitute the @dfn{transitive closure} of
Coreutils---i.e., Coreutils and all its dependencies, recursively---as
would be returned by:
@example
$ guix gc -R /gnu/store/@dots{}-coreutils-8.23
@end example
Here the output shows three columns next to store items. The first column,
labeled ``total'', shows the size in mebibytes (MiB) of the closure of
the store item---that is, its own size plus the size of all its
dependencies. The next column, labeled ``self'', shows the size of the
item itself. The last column shows the ratio of the size of the item
itself to the space occupied by all the items listed here.
In this example, we see that the closure of Coreutils weighs in at
70@tie{}MiB, half of which is taken by libc. (That libc represents a
large fraction of the closure is not a problem @i{per se} because it is
always available on the system anyway.)
When the package passed to @command{guix size} is available in the
store, @command{guix size} queries the daemon to determine its
dependencies, and measures its size in the store, similar to @command{du
-ms --apparent-size} (@pxref{du invocation,,, coreutils, GNU
Coreutils}).
When the given package is @emph{not} in the store, @command{guix size}
reports information based on the available substitutes
(@pxref{Substitutes}). This makes it possible it to profile disk usage of
store items that are not even on disk, only available remotely.
You can also specify several package names:
@example
$ guix size coreutils grep sed bash
store item total self
/gnu/store/@dots{}-coreutils-8.24 77.8 13.8 13.4%
/gnu/store/@dots{}-grep-2.22 73.1 0.8 0.8%
/gnu/store/@dots{}-bash-4.3.42 72.3 4.7 4.6%
/gnu/store/@dots{}-readline-6.3 67.6 1.2 1.2%
@dots{}
total: 102.3 MiB
@end example
@noindent
In this example we see that the combination of the four packages takes
102.3@tie{}MiB in total, which is much less than the sum of each closure
since they have a lot of dependencies in common.
@item --substitute-urls=@var{urls}
Use substitute information from @var{urls}.
@xref{client-substitute-urls, the same option for @code{guix build}}.
Write a graphical map of disk usage in PNG format to @var{file}.
For the example above, the map looks like this:
@image{images/coreutils-size-map,5in,, map of Coreutils disk usage
produced by @command{guix size}}
This option requires that
@uref{http://wingolog.org/software/guile-charting/, Guile-Charting} be
installed and visible in Guile's module search path. When that is not
the case, @command{guix size} fails as it tries to load it.
@item --system=@var{system}
@itemx -s @var{system}
Consider packages for @var{system}---e.g., @code{x86_64-linux}.
@end table
@node Invoking guix graph
@section Invoking @command{guix graph}
@cindex DAG
Packages and their dependencies form a @dfn{graph}, specifically a
directed acyclic graph (DAG). It can quickly become difficult to have a
mental model of the package DAG, so the @command{guix graph} command
provides a visual representation of the DAG. @command{guix graph}
emits a DAG representation in the input format of
@uref{http://www.graphviz.org/, Graphviz}, so its output can be passed
directly to the @command{dot} command of Graphviz. The general
syntax is:
@example
guix graph @var{options} @var{package}@dots{}
@end example
For example, the following command generates a PDF file representing the
package DAG for the GNU@tie{}Core Utilities, showing its build-time
dependencies:
@example
guix graph coreutils | dot -Tpdf > dag.pdf
@end example
The output looks like this:
@image{images/coreutils-graph,2in,,Dependency graph of the GNU Coreutils}
Nice little graph, no?
But there is more than one graph! The one above is concise: it is the
graph of package objects, omitting implicit inputs such as GCC, libc,
grep, etc. It is often useful to have such a concise graph, but
sometimes one may want to see more details. @command{guix graph} supports
several types of graphs, allowing you to choose the level of detail:
This is the default type used in the example above. It shows the DAG of
package objects, excluding implicit dependencies. It is concise, but
filters out many details.
@item bag-emerged
This is the package DAG, @emph{including} implicit inputs.
For instance, the following command:
@example
guix graph --type=bag-emerged coreutils | dot -Tpdf > dag.pdf
@end example
... yields this bigger graph:
@image{images/coreutils-bag-graph,,5in,Detailed dependency graph of the GNU Coreutils}
At the bottom of the graph, we see all the implicit inputs of
@var{gnu-build-system} (@pxref{Build Systems, @code{gnu-build-system}}).
Now, note that the dependencies of these implicit inputs---that is, the
@dfn{bootstrap dependencies} (@pxref{Bootstrapping})---are not shown
here, for conciseness.
@item bag
Similar to @code{bag-emerged}, but this time including all the bootstrap
dependencies.
@item bag-with-origins
Similar to @code{bag}, but also showing origins and their dependencies.
@item derivations
This is the most detailed representation: It shows the DAG of
derivations (@pxref{Derivations}) and plain store items. Compared to
the above representation, many additional nodes are visible, including
For this type of graph, it is also possible to pass a @file{.drv} file
name instead of a package name, as in:
@example
guix graph -t derivation `guix system build -d my-config.scm`
@end example
All the types above correspond to @emph{build-time dependencies}. The
following graph type represents the @emph{run-time dependencies}:
@table @code
@item references
This is the graph of @dfn{references} of a package output, as returned
by @command{guix gc --references} (@pxref{Invoking guix gc}).
If the given package output is not available in the store, @command{guix
graph} attempts to obtain dependency information from substitutes.
Here you can also pass a store file name instead of a package name. For
example, the command below produces the reference graph of your profile
(which can be big!):
@example
guix graph -t references `readlink -f ~/.guix-profile`
@end example
@end table
The available options are the following:
@table @option
@item --type=@var{type}
@itemx -t @var{type}
Produce a graph output of @var{type}, where @var{type} must be one of
the values listed above.
@item --list-types
List the supported graph types.
@item --expression=@var{expr}
@itemx -e @var{expr}
Consider the package @var{expr} evaluates to.
This is useful to precisely refer to a package, as in this example:
@example
guix graph -e '(@@@@ (gnu packages commencement) gnu-make-final)'
@end example
@node Invoking guix environment
@section Invoking @command{guix environment}
@cindex reproducible build environments
@cindex development environments
The purpose of @command{guix environment} is to assist hackers in
creating reproducible development environments without polluting their
package profile. The @command{guix environment} tool takes one or more
packages, builds all of their inputs, and creates a shell
environment to use them.
The general syntax is:
@example
guix environment @var{options} @var{package}@dots{}
@end example
The following example spawns a new shell set up for the development of
GNU@tie{}Guile:
@example
guix environment guile
@end example
If the needed dependencies are not built yet, @command{guix environment}
automatically builds them. The environment of the new shell is an augmented
version of the environment that @command{guix environment} was run in.
It contains the necessary search paths for building the given package
added to the existing environment variables. To create a ``pure''
environment, in which the original environment variables have been unset,
use the @code{--pure} option@footnote{Users sometimes wrongfully augment
environment variables such as @code{PATH} in their @file{~/.bashrc}
file. As a consequence, when @code{guix environment} launches it, Bash
may read @file{~/.bashrc}, thereby introducing ``impurities'' in these
environment variables. It is an error to define such environment
variables in @file{.bashrc}; instead, they should be defined in
@file{.bash_profile}, which is sourced only by log-in shells.
@xref{Bash Startup Files,,, bash, The GNU Bash Reference Manual}, for
details on Bash start-up files.}.
@vindex GUIX_ENVIRONMENT
@command{guix environment} defines the @code{GUIX_ENVIRONMENT}
variable in the shell it spawns. This allows users to, say, define a
specific prompt for development environments in their @file{.bashrc}
(@pxref{Bash Startup Files,,, bash, The GNU Bash Reference Manual}):
@example
if [ -n "$GUIX_ENVIRONMENT" ]
then
export PS1="\u@@\h \w [dev]\$ "
fi
@end example
Additionally, more than one package may be specified, in which case the
union of the inputs for the given packages are used. For example, the
command below spawns a shell where all of the dependencies of both Guile
and Emacs are available:
@example
guix environment guile emacs
@end example
Sometimes an interactive shell session is not desired. An arbitrary
command may be invoked by placing the @code{--} token to separate the
command from the rest of the arguments:
guix environment guile -- make -j4
In other situations, it is more convenient to specify the list of
packages needed in the environment. For example, the following command
runs @command{python} from an environment containing Python@tie{}2.7 and
NumPy:
@example
guix environment --ad-hoc python2-numpy python-2.7 -- python
Furthermore, one might want the dependencies of a package and also some
additional packages that are not build-time or runtime dependencies, but
are useful when developing nonetheless. Because of this, the
@code{--ad-hoc} flag is positional. Packages appearing before
@code{--ad-hoc} are interpreted as packages whose dependencies will be
added to the environment. Packages appearing after are interpreted as
packages that will be added to the environment directly. For example,
the following command creates a Guix development environment that
additionally includes Git and strace:
@example
guix environment guix --ad-hoc git strace
@end example
Sometimes it is desirable to isolate the environment as much as
possible, for maximal purity and reproducibility. In particular, when
using Guix on a host distro that is not GuixSD, it is desirable to
prevent access to @file{/usr/bin} and other system-wide resources from
the development environment. For example, the following command spawns
a Guile REPL in a ``container'' where only the store and the current
working directory are mounted:
@example
guix environment --ad-hoc --container guile -- guile
@end example
@quotation Note
The @code{--container} option requires Linux-libre 3.19 or newer.
@end quotation
The available options are summarized below.
@table @code
@item --expression=@var{expr}
@itemx -e @var{expr}
Create an environment for the package or list of packages that
@var{expr} evaluates to.
For example, running:
@example
guix environment -e '(@@ (gnu packages maths) petsc-openmpi)'
@end example
starts a shell with the environment for this specific variant of the
PETSc package.
Running:
@example
@end example
starts a shell with all the GuixSD base packages available.
The above commands only the use default output of the given packages.
To select other outputs, two element tuples can be specified:
@example
guix environment --ad-hoc -e '(list (@ (gnu packages bash) bash) "include")'
@end example
@item --load=@var{file}
@itemx -l @var{file}
Create an environment for the package or list of packages that the code
within @var{file} evaluates to.
As an example, @var{file} might contain a definition like this
(@pxref{Defining Packages}):
@example
@verbatiminclude environment-gdb.scm
@end example
@item --ad-hoc
Include all specified packages in the resulting environment, as if an
@i{ad hoc} package were defined with them as inputs. This option is
useful for quickly creating an environment without having to write a
package expression to contain the desired inputs.
For instance, the command:
@example
guix environment --ad-hoc guile guile-sdl -- guile
@end example
runs @command{guile} in an environment where Guile and Guile-SDL are
available.
Note that this example implicitly asks for the default output of
@code{guile} and @code{guile-sdl}, but it is possible to ask for a
specific output---e.g., @code{glib:bin} asks for the @code{bin} output
of @code{glib} (@pxref{Packages with Multiple Outputs}).
This option may be composed with the default behavior of @command{guix
environment}. Packages appearing before @code{--ad-hoc} are interpreted
as packages whose dependencies will be added to the environment, the
default behavior. Packages appearing after are interpreted as packages
that will be added to the environment directly.
@item --pure
Unset existing environment variables when building the new environment.
This has the effect of creating an environment in which search paths
only contain package inputs.
@item --search-paths
Display the environment variable definitions that make up the
environment.
@item --system=@var{system}
@itemx -s @var{system}
Attempt to build for @var{system}---e.g., @code{i686-linux}.
@item --container
@itemx -C
@cindex container
Run @var{command} within an isolated container. The current working
directory outside the container is mapped inside the container.
Additionally, a dummy home directory is created that matches the current
user's home directory, and @file{/etc/passwd} is configured accordingly.
The spawned process runs as the current user outside the container, but
has root privileges in the context of the container.
5549
5550
5551
5552
5553
5554
5555
5556
5557
5558
5559
5560
5561
5562
5563
5564
5565
5566
5567
5568
5569
@item --network
@itemx -N
For containers, share the network namespace with the host system.
Containers created without this flag only have access to the loopback
device.
@item --expose=@var{source}[=@var{target}]
For containers, expose the file system @var{source} from the host system
as the read-only file system @var{target} within the container. If
@var{target} is not specified, @var{source} is used as the target mount
point in the container.
The example below spawns a Guile REPL in a container in which the user's
home directory is accessible read-only via the @file{/exchange}
directory:
@example
guix environment --container --expose=$HOME=/exchange guile -- guile
@end example
For containers, share the file system @var{source} from the host system
as the writable file system @var{target} within the container. If
@var{target} is not specified, @var{source} is used as the target mount
point in the container.
The example below spawns a Guile REPL in a container in which the user's
home directory is accessible for both reading and writing via the
@file{/exchange} directory:
@example
guix environment --container --share=$HOME=/exchange guile -- guile
@end example
@end table
It also supports all of the common build options that @command{guix
build} supports (@pxref{Common Build Options}).
@node Invoking guix publish
@section Invoking @command{guix publish}
The purpose of @command{guix publish} is to enable users to easily share
their store with others, who can then use it as a substitute server
(@pxref{Substitutes}).
When @command{guix publish} runs, it spawns an HTTP server which allows
anyone with network access to obtain substitutes from it. This means
that any machine running Guix can also act as if it were a build farm,
since the HTTP interface is compatible with Hydra, the software behind
the @code{hydra.gnu.org} build farm.
For security, each substitute is signed, allowing recipients to check
their authenticity and integrity (@pxref{Substitutes}). Because
@command{guix publish} uses the signing key of the system, which is only
readable by the system administrator, it must be started as root; the
@code{--user} option makes it drop root privileges early on.
The signing key pair must be generated before @command{guix publish} is
launched, using @command{guix archive --generate-key} (@pxref{Invoking
guix archive}).
5611
5612
5613
5614
5615
5616
5617
5618
5619
5620
5621
5622
5623
5624
5625
5626
5627
5628
5629
5630
5631
5632
5633
5634
5635
5636
5637
The general syntax is:
@example
guix publish @var{options}@dots{}
@end example
Running @command{guix publish} without any additional arguments will
spawn an HTTP server on port 8080:
@example
guix publish
@end example
Once a publishing server has been authorized (@pxref{Invoking guix
archive}), the daemon may download substitutes from it:
@example
guix-daemon --substitute-urls=http://example.org:8080
@end example
The following options are available:
@table @code
@item --port=@var{port}
@itemx -p @var{port}
Listen for HTTP requests on @var{port}.
@item --listen=@var{host}
Listen on the network interface for @var{host}. The default is to
accept connections from any interface.
@item --user=@var{user}
@itemx -u @var{user}
Change privileges to @var{user} as soon as possible---i.e., once the
server socket is open and the signing key has been read.
@item --ttl=@var{ttl}
Produce @code{Cache-Control} HTTP headers that advertise a time-to-live
(TTL) of @var{ttl}. @var{ttl} must denote a duration: @code{5d} means 5
days, @code{1m} means 1 month, and so on.
This allows the user's Guix to keep substitute information in cache for
@var{ttl}. However, note that @code{guix publish} does not itself
guarantee that the store items it provides will indeed remain available
for as long as @var{ttl}.
@item --repl[=@var{port}]
@itemx -r [@var{port}]
Spawn a Guile REPL server (@pxref{REPL Servers,,, guile, GNU Guile
Reference Manual}) on @var{port} (37146 by default). This is used
primarily for debugging a running @command{guix publish} server.
Enabling @command{guix publish} on a GuixSD system is a one-liner: just
add a call to @code{guix-publish-service} in the @code{services} field
of the @code{operating-system} declaration (@pxref{guix-publish-service,
@code{guix-publish-service}}).
@node Invoking guix challenge
@section Invoking @command{guix challenge}
@cindex reproducible builds
@cindex verifiable builds
Do the binaries provided by this server really correspond to the source
code it claims to build? Is a package build process deterministic?
These are the questions the @command{guix challenge} command attempts to
answer.
The former is obviously an important question: Before using a substitute
server (@pxref{Substitutes}), one had better @emph{verify} that it
provides the right binaries, and thus @emph{challenge} it. The latter
is what enables the former: If package builds are deterministic, then
independent builds of the package should yield the exact same result,
bit for bit; if a server provides a binary different from the one
obtained locally, it may be either corrupt or malicious.
We know that the hash that shows up in @file{/gnu/store} file names is
the hash of all the inputs of the process that built the file or
directory---compilers, libraries, build scripts,
etc. (@pxref{Introduction}). Assuming deterministic build processes,
one store file name should map to exactly one build output.
@command{guix challenge} checks whether there is, indeed, a single
mapping by comparing the build outputs of several independent builds of
any given store item.
$ guix challenge --substitute-urls="https://hydra.gnu.org https://guix.example.org"
updating list of substitutes from 'https://hydra.gnu.org'... 100.0%
updating list of substitutes from 'https://guix.example.org'... 100.0%
/gnu/store/@dots{}-openssl-1.0.2d contents differ:
local hash: 0725l22r5jnzazaacncwsvp9kgf42266ayyp814v7djxs7nk963q
https://hydra.gnu.org/nar/@dots{}-openssl-1.0.2d: 0725l22r5jnzazaacncwsvp9kgf42266ayyp814v7djxs7nk963q
https://guix.example.org/nar/@dots{}-openssl-1.0.2d: 1zy4fmaaqcnjrzzajkdn3f5gmjk754b43qkq47llbyak9z0qjyim
/gnu/store/@dots{}-git-2.5.0 contents differ:
local hash: 00p3bmryhjxrhpn2gxs2fy0a15lnip05l97205pgbk5ra395hyha
https://hydra.gnu.org/nar/@dots{}-git-2.5.0: 069nb85bv4d4a6slrwjdy8v1cn4cwspm3kdbmyb81d6zckj3nq9f
https://guix.example.org/nar/@dots{}-git-2.5.0: 0mdqa9w1p6cmli6976v4wi0sw9r4p5prkj7lzfd1877wk11c9c73
/gnu/store/@dots{}-pius-2.1.1 contents differ:
local hash: 0k4v3m9z1zp8xzzizb7d8kjj72f9172xv078sq4wl73vnq9ig3ax
https://hydra.gnu.org/nar/@dots{}-pius-2.1.1: 0k4v3m9z1zp8xzzizb7d8kjj72f9172xv078sq4wl73vnq9ig3ax
https://guix.example.org/nar/@dots{}-pius-2.1.1: 1cy25x1a4fzq5rk0pmvc8xhwyffnqz95h2bpvqsz2mpvlbccy0gs
@end smallexample
@noindent
In this example, @command{guix challenge} first scans the store to
determine the set of locally-built derivations---as opposed to store
items that were downloaded from a substitute server---and then queries
all the substitute servers. It then reports those store items for which
the servers obtained a result different from the local build.
@cindex non-determinism, in package builds
As an example, @code{guix.example.org} always gets a different answer.
Conversely, @code{hydra.gnu.org} agrees with local builds, except in the
case of Git. This might indicate that the build process of Git is
non-deterministic, meaning that its output varies as a function of
various things that Guix does not fully control, in spite of building
packages in isolated environments (@pxref{Features}). Most common
sources of non-determinism include the addition of timestamps in build
results, the inclusion of random numbers, and directory listings sorted
by inode number. See @uref{https://reproducible-builds.org/docs/}, for
To find out what is wrong with this Git binary, we can do something along
these lines (@pxref{Invoking guix archive}):
@example
$ wget -q -O - https://hydra.gnu.org/nar/@dots{}-git-2.5.0 \
$ diff -ur --no-dereference /gnu/store/@dots{}-git.2.5.0 /tmp/git
@end example
This command shows the difference between the files resulting from the
local build, and the files resulting from the build on
@code{hydra.gnu.org} (@pxref{Overview, Comparing and Merging Files,,
diffutils, Comparing and Merging Files}). The @command{diff} command
works great for text files. When binary files differ, a better option
is @uref{https://diffoscope.org/, Diffoscope}, a tool that helps
visualize differences for all kinds of files.
Once you have done that work, you can tell whether the differences are due
to a non-deterministic build process or to a malicious server. We try
hard to remove sources of non-determinism in packages to make it easier
to verify substitutes, but of course, this is a process that
involves not just Guix, but a large part of the free software community.
In the meantime, @command{guix challenge} is one tool to help address
the problem.
If you are writing packages for Guix, you are encouraged to check
whether @code{hydra.gnu.org} and other substitute servers obtain the
same build result as you did with:
@example
$ guix challenge @var{package}
@end example
@noindent
where @var{package} is a package specification such as
@code{guile@@2.0} or @code{glibc:debug}.
The general syntax is:
@example
guix challenge @var{options} [@var{packages}@dots{}]
@end example
When a difference is found between the hash of a locally-built item and
that of a server-provided substitute, or among substitutes provided by
different servers, the command displays it as in the example above and
its exit code is 2 (other non-zero exit codes denote other kinds of
errors.)
The one option that matters is:
@table @code
@item --substitute-urls=@var{urls}
Consider @var{urls} the whitespace-separated list of substitute source
URLs to compare to.
@end table
@node Invoking guix container
@section Invoking @command{guix container}
@cindex container
@quotation Note
As of version @value{VERSION}, this tool is experimental. The interface
is subject to radical change in the future.
@end quotation
The purpose of @command{guix container} is to manipulate processes
running within an isolated environment, commonly known as a
``container'', typically created by the @command{guix environment}
5809
5810
5811
5812
5813
5814
5815
5816
5817
5818
5819
5820
5821
5822
5823
5824
5825
5826
5827
5828
5829
5830
5831
5832
5833
(@pxref{Invoking guix environment}) and @command{guix system container}
(@pxref{Invoking guix system}) commands.
The general syntax is:
@example
guix container @var{action} @var{options}@dots{}
@end example
@var{action} specifies the operation to perform with a container, and
@var{options} specifies the context-specific arguments for the action.
The following actions are available:
@table @code
@item exec
Execute a command within the context of a running container.
The syntax is:
@example
guix container exec @var{pid} @var{program} @var{arguments}@dots{}
@end example
@var{pid} specifies the process ID of the running container.
@var{program} specifies an executable file name within the root file
system of the container. @var{arguments} are the additional options that
will be passed to @var{program}.
The following command launches an interactive login shell inside a
GuixSD container, started by @command{guix system container}, and whose
process ID is 9001:
@example
guix container exec 9001 /run/current-system/profile/bin/bash --login
@end example
Note that the @var{pid} cannot be the parent process of a container. It
must be PID 1 of the container or one of its child processes.
@c *********************************************************************
@node GNU Distribution
@chapter GNU Distribution
@cindex Guix System Distribution
Guix comes with a distribution of the GNU system consisting entirely of
free software@footnote{The term ``free'' here refers to the
@url{http://www.gnu.org/philosophy/free-sw.html,freedom provided to
users of that software}.}. The
distribution can be installed on its own (@pxref{System Installation}),
but it is also possible to install Guix as a package manager on top of
an installed GNU/Linux system (@pxref{Installation}). To distinguish
between the two, we refer to the standalone distribution as the Guix
The distribution provides core GNU packages such as GNU libc, GCC, and
Binutils, as well as many GNU and non-GNU applications. The complete
list of available packages can be browsed
@url{http://www.gnu.org/software/guix/packages,on-line} or by
running @command{guix package} (@pxref{Invoking guix package}):
guix package --list-available
Our goal is to provide a practical 100% free software distribution of
Linux-based and other variants of GNU, with a focus on the promotion and
tight integration of GNU components, and an emphasis on programs and
tools that help users exert that freedom.
Packages are currently available on the following platforms:
@table @code
@item x86_64-linux
Intel/AMD @code{x86_64} architecture, Linux-Libre kernel;
@item i686-linux
Intel 32-bit architecture (IA32), Linux-Libre kernel;
ARMv7-A architecture with hard float, Thumb-2 and NEON,
using the EABI hard-float application binary interface (ABI),
and Linux-Libre kernel.
@item mips64el-linux
little-endian 64-bit MIPS processors, specifically the Loongson series,
GuixSD itself is currently only available on @code{i686} and @code{x86_64}.
@noindent
For information on porting to other architectures or kernels,
* System Installation:: Installing the whole operating system.
* System Configuration:: Configuring the operating system.
* Installing Debugging Files:: Feeding the debugger.
* Security Updates:: Deploying security fixes quickly.
* Package Modules:: Packages from the programmer's viewpoint.
* Packaging Guidelines:: Growing the distribution.
* Bootstrapping:: GNU/Linux built from scratch.
* Porting:: Targeting another platform or kernel.
@end menu
Building this distribution is a cooperative effort, and you are invited
to join! @xref{Contributing}, for information about how you can help.
@node System Installation
@section System Installation
@cindex Guix System Distribution
This section explains how to install the Guix System Distribution
on a machine. The Guix package manager can
also be installed on top of a running GNU/Linux system,
@pxref{Installation}.
@quotation Note
@c This paragraph is for people reading this from tty2 of the
@c installation image.
You are reading this documentation with an Info reader. For details on
how to use it, hit the @key{RET} key (``return'' or ``enter'') on the
link that follows: @pxref{Top, Info reader,, info-stnd, Stand-alone GNU
Info}. Hit @kbd{l} afterwards to come back here.
Alternately, run @command{info info} in another tty to keep the manual
available.
@end quotation
* Limitations:: What you can expect.
* Hardware Considerations:: Supported hardware.
* USB Stick Installation:: Preparing the installation medium.
* Preparing for Installation:: Networking, partitioning, etc.
* Proceeding with the Installation:: The real thing.
* Building the Installation Image:: How this comes to be.
@end menu
@node Limitations
As of version @value{VERSION}, the Guix System Distribution (GuixSD) is
not production-ready. It may contain bugs and lack important
features. Thus, if you are looking for a stable production system that
respects your freedom as a computer user, a good solution at this point
is to consider @url{http://www.gnu.org/distros/free-distros.html, one of
the more established GNU/Linux distributions}. We hope you can soon switch
to the GuixSD without fear, of course. In the meantime, you can
also keep using your distribution and try out the package manager on top
of it (@pxref{Installation}).
Before you proceed with the installation, be aware of the following
noteworthy limitations applicable to version @value{VERSION}:
@itemize
@item
The installation process does not include a graphical user interface and
requires familiarity with GNU/Linux (see the following subsections to
get a feel of what that means.)
@item
Support for the Logical Volume Manager (LVM) is missing.
@item
Few system services are currently supported out-of-the-box
(@pxref{Services}).
@item
More than 3,200 packages are available, but you may
occasionally find that a useful package is missing.
@item
GNOME, Xfce, and Enlightenment are available (@pxref{Desktop Services}),
as well as a number of X11 window managers. However, some graphical
applications may be missing, as well as KDE.
You have been warned! But more than a disclaimer, this is an invitation
to report issues (and success stories!), and to join us in improving it.
@xref{Contributing}, for more info.
@node Hardware Considerations
@subsection Hardware Considerations
@cindex hardware support on GuixSD
GNU@tie{}GuixSD focuses on respecting the user's computing freedom. It
builds around the kernel Linux-libre, which means that only hardware for
which free software drivers and firmware exist is supported. Nowadays,
a wide range of off-the-shelf hardware is supported on
GNU/Linux-libre---from keyboards to graphics cards to scanners and
Ethernet controllers. Unfortunately, there are still areas where
hardware vendors deny users control over their own computing, and such
hardware is not supported on GuixSD.
@cindex WiFi, hardware support
One of the main areas where free drivers or firmware are lacking is WiFi
devices. WiFi devices known to work include those using Atheros chips
(AR9271 and AR7010), which corresponds to the @code{ath9k} Linux-libre
driver, and for which free firmware exists and is available
out-of-the-box on GuixSD, as part of @var{%base-firmware}
(@pxref{operating-system Reference, @code{firmware}}).
@cindex RYF, Respects Your Freedom
The @uref{https://www.fsf.org/, Free Software Foundation} runs
@uref{https://www.fsf.org/ryf, @dfn{Respects Your Freedom}} (RYF), a
certification program for hardware products that respect your freedom
and your privacy and ensure that you have control over your device. We
encourage you to check the list of RYF-certified devices.
Another useful resource is the @uref{https://www.h-node.org/, H-Node}
web site. It contains a catalog of hardware devices with information
about their support in GNU/Linux.
@node USB Stick Installation
@subsection USB Stick Installation
An installation image for USB sticks can be downloaded from
@indicateurl{ftp://alpha.gnu.org/gnu/guix/guixsd-usb-install-@value{VERSION}.@var{system}.xz},
6037
6038
6039
6040
6041
6042
6043
6044
6045
6046
6047
6048
6049
6050
6051
6052
6053
6054
6055
6056
6057
where @var{system} is one of:
@table @code
@item x86_64-linux
for a GNU/Linux system on Intel/AMD-compatible 64-bit CPUs;
@item i686-linux
for a 32-bit GNU/Linux system on Intel-compatible CPUs.
@end table
This image contains a single partition with the tools necessary for an
installation. It is meant to be copied @emph{as is} to a large-enough
USB stick.
To copy the image to a USB stick, follow these steps:
@enumerate
@item
Decompress the image using the @command{xz} command:
@example
xz -d guixsd-usb-install-@value{VERSION}.@var{system}.xz
Insert a USB stick of 1@tie{}GiB or more into your machine, and determine
its device name. Assuming that the USB stick is known as @file{/dev/sdX},
copy the image with:
@example
dd if=guixsd-usb-install-@value{VERSION}.x86_64 of=/dev/sdX
@end example
Access to @file{/dev/sdX} usually requires root privileges.
@end enumerate
Once this is done, you should be able to reboot the system and boot from
the USB stick. The latter usually requires you to get in the BIOS' boot
menu, where you can choose to boot from the USB stick.
@node Preparing for Installation
@subsection Preparing for Installation
Once you have successfully booted the image on the USB stick, you should
end up with a root prompt. Several console TTYs are configured and can
be used to run commands as root. TTY2 shows this documentation,
browsable using the Info reader commands (@pxref{Top,,, info-stnd,
Stand-alone GNU Info}). The installation system runs the GPM mouse
daemon, which allows you to select text with the left mouse button and
to paste it with the middle button.
@quotation Note
Installation requires access to the Internet so that any missing
dependencies of your system configuration can be downloaded. See the
``Networking'' section below.
@end quotation
The installation system includes many common tools needed for this task.
But it is also a full-blown GuixSD system, which means that you can
install additional packages, should you need it, using @command{guix
package} (@pxref{Invoking guix package}).
@subsubsection Keyboard Layout
@cindex keyboard layout
The installation image uses the US qwerty keyboard layout. If you want
to change it, you can use the @command{loadkeys} command. For example,
the following command selects the Dvorak keyboard layout:
@example
loadkeys dvorak
@end example
See the files under @file{/run/current-system/profile/share/keymaps} for
a list of available keyboard layouts. Run @command{man loadkeys} for
more information.
@subsubsection Networking
Run the following command see what your network interfaces are called:
@noindent
@dots{} or, using the GNU/Linux-specific @command{ip} command:
@example
ip a
@end example
@c http://cgit.freedesktop.org/systemd/systemd/tree/src/udev/udev-builtin-net_id.c#n20
6130
6131
6132
6133
6134
6135
6136
6137
6138
6139
6140
6141
6142
6143
6144
6145
6146
6147
6148
6149
6150
6151
6152
6153
6154
6155
6156
6157
6158
6159
Wired interfaces have a name starting with @samp{e}; for example, the
interface corresponding to the first on-board Ethernet controller is
called @samp{eno1}. Wireless interfaces have a name starting with
@samp{w}, like @samp{w1p2s0}.
@table @asis
@item Wired connection
To configure a wired network run the following command, substituting
@var{interface} with the name of the wired interface you want to use.
@example
ifconfig @var{interface} up
@end example
@item Wireless connection
To configure wireless networking, you can create a configuration file
for the @command{wpa_supplicant} configuration tool (its location is not
important) using one of the available text editors such as
@command{zile}:
@example
zile wpa_supplicant.conf
@end example
As an example, the following stanza can go to this file and will work
for many wireless networks, provided you give the actual SSID and
passphrase for the network you are connecting to:
@example
network=@{
ssid="@var{my-ssid}"
key_mgmt=WPA-PSK
psk="the network's secret passphrase"
@}
@end example
Start the wireless service and run it in the background with the
following command (substitute @var{interface} with the name of the
network interface you want to use):
@example
wpa_supplicant -c wpa_supplicant.conf -i @var{interface} -B
@end example
Run @command{man wpa_supplicant} for more information.
@end table
At this point, you need to acquire an IP address. On a network where IP
addresses are automatically assigned @i{via} DHCP, you can run:
@example
Try to ping a server to see if networking is up and running:
@example
ping -c 3 gnu.org
@end example
Setting up network access is almost always a requirement because the
image does not contain all the software and tools that may be needed.
@subsubsection Disk Partitioning
Unless this has already been done, the next step is to partition, and
then format the target partition(s).
The installation image includes several partitioning tools, including
Parted (@pxref{Overview,,, parted, GNU Parted User Manual}),
@command{fdisk}, and @command{cfdisk}. Run it and set up your disk with
the partition layout you want:
@example
cfdisk
@end example
Once you are done partitioning the target hard disk drive, you have to
create a file system on the relevant partition(s)@footnote{Currently
GuixSD pretty much assumes an ext4 file system. In particular, code
that reads partition UUIDs and labels only works with ext4. This will
be fixed in the future.}.
Preferably, assign partitions a label so that you can easily and
reliably refer to them in @code{file-system} declarations (@pxref{File
Systems}). This is typically done using the @code{-L} option of
@command{mkfs.ext4} and related commands. So, assuming the target root
partition lives at @file{/dev/sda1}, a file system with the label
@code{my-root} can be created with:
@example
mkfs.ext4 -L my-root /dev/sda1
@end example
@c FIXME: Uncomment this once GRUB fully supports encrypted roots.
@c A typical command sequence may be:
@c
@c @example
@c # fdisk /dev/sdX
@c @dots{} Create partitions etc.@dots{}
@c # cryptsetup luksFormat /dev/sdX1
@c # cryptsetup open --type luks /dev/sdX1 my-partition
@c # mkfs.ext4 -L my-root /dev/mapper/my-partition
@c @end example
In addition to e2fsprogs, the suite of tools to manipulate
ext2/ext3/ext4 file systems, the installation image includes
Cryptsetup/LUKS for disk encryption.
Once that is done, mount the target root partition under @file{/mnt}
with a command like (again, assuming @file{/dev/sda1} is the root
partition):
@example
mount /dev/sda1 /mnt
@end example
Finally, if you plan to use one or more swap partitions (@pxref{Memory
Concepts, swap space,, libc, The GNU C Library Reference Manual}), make
sure to initialize them with @command{mkswap}. Assuming you have one
swap partition on @file{/dev/sda2}, you would run:
@example
mkswap /dev/sda2
@end example
@node Proceeding with the Installation
@subsection Proceeding with the Installation
With the target partitions ready and the target root mounted on
@file{/mnt}, we're ready to go. First, run:
@example
herd start cow-store /mnt
@end example
This makes @file{/gnu/store} copy-on-write, such that packages added to it
during the installation phase are written to the target disk on @file{/mnt}
rather than kept in memory. This is necessary because the first phase of
the @command{guix system init} command (see below) entails downloads or
builds to @file{/gnu/store} which, initially, is an in-memory file system.
Next, you have to edit a file and
provide the declaration of the operating system to be installed. To
that end, the installation system comes with two text editors: GNU nano
(@pxref{Top,,, nano, GNU nano Manual}), and GNU Zile, an Emacs clone.
We strongly recommend storing that file on the target root file system, say,
as @file{/mnt/etc/config.scm}. Failing to do that, you will have lost your
configuration file once you have rebooted into the newly-installed system.
6280
6281
6282
6283
6284
6285
6286
6287
6288
6289
6290
6291
6292
6293
6294
6295
6296
6297
6298
6299
6300
6301
6302
6303
6304
6305
6306
@xref{Using the Configuration System}, for an overview of the
configuration file. The example configurations discussed in that
section are available under @file{/etc/configuration} in the
installation image. Thus, to get started with a system configuration
providing a graphical display server (a ``desktop'' system), you can run
something along these lines:
@example
# mkdir /mnt/etc
# cp /etc/configuration/desktop.scm /mnt/etc/config.scm
# zile /mnt/etc/config.scm
@end example
You should pay attention to what your configuration file contains, and
in particular:
@itemize
@item
Make sure the @code{grub-configuration} form refers to the device you
want to install GRUB on.
@item
Be sure that your partition labels match the value of their respective
@code{device} fields in your @code{file-system} configuration, assuming
your @code{file-system} configuration sets the value of @code{title} to
@code{'label}.
@end itemize
Once you are done preparing the configuration file, the new system must
be initialized (remember that the target root file system is mounted
under @file{/mnt}):
@example
guix system init /mnt/etc/config.scm /mnt
@end example
@noindent
This copies all the necessary files and installs GRUB on
@file{/dev/sdX}, unless you pass the @option{--no-grub} option. For
more information, @pxref{Invoking guix system}. This command may trigger
downloads or builds of missing packages, which can take some time.
Once that command has completed---and hopefully succeeded!---you can run
@command{reboot} and boot into the new system. The @code{root} password
in the new system is initially empty; other users' passwords need to be
initialized by running the @command{passwd} command as @code{root},
unless your configuration specifies otherwise
(@pxref{user-account-password, user account passwords}).
Join us on @code{#guix} on the Freenode IRC network or on
@file{guix-devel@@gnu.org} to share your experience---good or not so
good.
@node Building the Installation Image
@subsection Building the Installation Image
The installation image described above was built using the @command{guix
system} command, specifically:
@c FIXME: 1G is too much; see <http://bugs.gnu.org/23077>.
guix system disk-image --image-size=1G gnu/system/install.scm
Have a look at @file{gnu/system/install.scm} in the source tree,
and see also @ref{Invoking guix system} for more information
about the installation image.
@node System Configuration
@section System Configuration
@cindex system configuration
The Guix System Distribution supports a consistent whole-system configuration
mechanism. By that we mean that all aspects of the global system
configuration---such as the available system services, timezone and
locale settings, user accounts---are declared in a single place. Such
a @dfn{system configuration} can be @dfn{instantiated}---i.e., effected.
One of the advantages of putting all the system configuration under the
control of Guix is that it supports transactional system upgrades, and
makes it possible to roll back to a previous system instantiation,
should something go wrong with the new one (@pxref{Features}). Another
advantage is that it makes it easy to replicate the exact same configuration
across different machines, or at different points in time, without
having to resort to additional administration tools layered on top of
@c Yes, we're talking of Puppet, Chef, & co. here. ↑
This section describes this mechanism. First we focus on the system
administrator's viewpoint---explaining how the system is configured and
instantiated. Then we show how this mechanism can be extended, for
instance to support new system services.
@menu
* Using the Configuration System:: Customizing your GNU system.
* operating-system Reference:: Detail of operating-system declarations.
* File Systems:: Configuring file system mounts.
* Mapped Devices:: Block device extra processing.
* User Accounts:: Specifying user accounts.
* Locales:: Language and cultural convention settings.
* Services:: Specifying system services.
* Setuid Programs:: Programs running with root privileges.
* X.509 Certificates:: Authenticating HTTPS servers.
* Name Service Switch:: Configuring libc's name service switch.
* Initial RAM Disk:: Linux-Libre bootstrapping.
* GRUB Configuration:: Configuring the boot loader.
* Invoking guix system:: Instantiating a system configuration.
* Running GuixSD in a VM:: How to run GuixSD in a virtual machine.
* Defining Services:: Adding new service definitions.
@end menu
@node Using the Configuration System
@subsection Using the Configuration System
The operating system is configured by providing an
@code{operating-system} declaration in a file that can then be passed to
the @command{guix system} command (@pxref{Invoking guix system}). A
simple setup, with the default system services, the default Linux-Libre
kernel, initial RAM disk, and boot loader looks like this:
@findex operating-system
@lisp
@include os-config-bare-bones.texi
This example should be self-describing. Some of the fields defined
above, such as @code{host-name} and @code{bootloader}, are mandatory.
Others, such as @code{packages} and @code{services}, can be omitted, in
which case they get a default value.
Below we discuss the effect of some of the most important fields
(@pxref{operating-system Reference}, for details about all the available
fields), and how to @dfn{instantiate} the operating system using
@command{guix system}.
@unnumberedsubsubsec Globally-Visible Packages
The @code{packages} field lists packages that will be globally visible
on the system, for all user accounts---i.e., in every user's @code{PATH}
environment variable---in addition to the per-user profiles
(@pxref{Invoking guix package}). The @var{%base-packages} variable
provides all the tools one would expect for basic user and administrator
tasks---including the GNU Core Utilities, the GNU Networking Utilities,
the GNU Zile lightweight text editor, @command{find}, @command{grep},
etc. The example above adds tcpdump to those, taken from the @code{(gnu
packages admin)} module (@pxref{Package Modules}).
@findex specification->package
Referring to packages by variable name, like @var{tcpdump} above, has
the advantage of being unambiguous; it also allows typos and such to be
diagnosed right away as ``unbound variables''. The downside is that one
needs to know which module defines which package, and to augment the
@code{use-package-modules} line accordingly. To avoid that, one can use
the @code{specification->package} procedure of the @code{(gnu packages)}
module, which returns the best package for a given name or name and
version:
@lisp
(use-modules (gnu packages))
(operating-system
;; ...
(packages (append (map specification->package
'("tcpdump" "htop" "gnupg@@2.0"))
%base-packages)))
@end lisp
@unnumberedsubsubsec System Services
@vindex %base-services
The @code{services} field lists @dfn{system services} to be made
available when the system starts (@pxref{Services}).
The @code{operating-system} declaration above specifies that, in
addition to the basic services, we want the @command{lshd} secure shell
daemon listening on port 2222 (@pxref{Networking Services,
@code{lsh-service}}). Under the hood,
@code{lsh-service} arranges so that @code{lshd} is started with the
right command-line options, possibly with supporting configuration files
generated as needed (@pxref{Defining Services}).
@cindex customization, of services
@findex modify-services
Occasionally, instead of using the base services as is, you will want to
customize them. To do this, use @code{modify-services} (@pxref{Service
Reference, @code{modify-services}}) to modify the list.
For example, suppose you want to modify @code{guix-daemon} and Mingetty
(the console log-in) in the @var{%base-services} list (@pxref{Base
Services, @code{%base-services}}). To do that, you can write the
following in your operating system declaration:
(define %my-services
;; My very own list of services.
(modify-services %base-services
(guix-service-type config =>
(guix-configuration
(inherit config)
(use-substitutes? #f)
(extra-options '("--gc-keep-derivations"))))
(mingetty-service-type config =>
(mingetty-configuration
(inherit config)
(motd (plain-file "motd" "Howdy!"))))))
(operating-system
;; @dots{}
(services %my-services))
This changes the configuration---i.e., the service parameters---of the
@code{guix-service-type} instance, and that of all the
@code{mingetty-service-type} instances in the @var{%base-services} list.
Observe how this is accomplished: first, we arrange for the original
configuration to be bound to the identifier @code{config} in the
@var{body}, and then we write the @var{body} so that it evaluates to the
desired configuration. In particular, notice how we use @code{inherit}
to create a new configuration which has the same values as the old
configuration, but with a few modifications.
The configuration for a typical ``desktop'' usage, with the X11 display
server, GNOME and Xfce (users can choose which of these desktop
environments to use at the log-in screen by pressing @kbd{F1}), network
management, power management, and more, would look like this:
@lisp
@include os-config-desktop.texi
@end lisp
A graphical environment with a choice of lightweight window managers
instead of full-blown desktop environments would look like this:
@lisp
@include os-config-lightweight-desktop.texi
@end lisp
@xref{Desktop Services}, for the exact list of services provided by
@var{%desktop-services}. @xref{X.509 Certificates}, for background
information about the @code{nss-certs} package that is used here.
Again, @var{%desktop-services} is just a list of service objects. If
you want to remove services from there, you can do so using the
procedures for list filtering (@pxref{SRFI-1 Filtering and
Partitioning,,, guile, GNU Guile Reference Manual}). For instance, the
following expression returns a list that contains all the services in
@var{%desktop-services} minus the Avahi service:
@example
(remove (lambda (service)
(eq? (service-kind service) avahi-service-type))
%desktop-services)
@end example
@unnumberedsubsubsec Instantiating the System
Assuming the @code{operating-system} declaration
is stored in the @file{my-system-config.scm}
file, the @command{guix system reconfigure my-system-config.scm} command
instantiates that configuration, and makes it the default GRUB boot
entry (@pxref{Invoking guix system}).
The normal way to change the system configuration is by updating this
file and re-running @command{guix system reconfigure}. One should never
have to touch files in @command{/etc} or to run commands that modify the
system state such as @command{useradd} or @command{grub-install}. In
fact, you must avoid that since that would not only void your warranty
but also prevent you from rolling back to previous versions of your
system, should you ever need to.
@cindex roll-back, of the operating system
Speaking of roll-back, each time you run @command{guix system
reconfigure}, a new @dfn{generation} of the system is created---without
modifying or deleting previous generations. Old system generations get
an entry in the GRUB boot menu, allowing you to boot them in case
something went wrong with the latest generation. Reassuring, no? The
@command{guix system list-generations} command lists the system
generations available on disk.
@unnumberedsubsubsec The Programming Interface
At the Scheme level, the bulk of an @code{operating-system} declaration
is instantiated with the following monadic procedure (@pxref{The Store
Monad}):
@deffn {Monadic Procedure} operating-system-derivation os
Return a derivation that builds @var{os}, an @code{operating-system}
object (@pxref{Derivations}).
The output of the derivation is a single directory that refers to all
the packages, configuration files, and other supporting files needed to
instantiate @var{os}.
@end deffn
This procedure is provided by the @code{(gnu system)} module. Along
with @code{(gnu services)} (@pxref{Services}), this module contains the
guts of GuixSD. Make sure to visit it!
@node operating-system Reference
@subsection @code{operating-system} Reference
This section summarizes all the options available in
@code{operating-system} declarations (@pxref{Using the Configuration
System}).
@deftp {Data Type} operating-system
This is the data type representing an operating system configuration.
By that, we mean all the global system configuration, not per-user
configuration (@pxref{Using the Configuration System}).
@table @asis
@item @code{kernel} (default: @var{linux-libre})
The package object of the operating system kernel to use@footnote{Currently
only the Linux-libre kernel is supported. In the future, it will be
possible to use the GNU@tie{}Hurd.}.
@item @code{kernel-arguments} (default: @code{'()})
List of strings or gexps representing additional arguments to pass on
the command-line of the kernel---e.g., @code{("console=ttyS0")}.
The system bootloader configuration object. @xref{GRUB Configuration}.
@item @code{initrd} (default: @code{base-initrd})
A two-argument monadic procedure that returns an initial RAM disk for
the Linux kernel. @xref{Initial RAM Disk}.
@item @code{firmware} (default: @var{%base-firmware})
@cindex firmware
List of firmware packages loadable by the operating system kernel.
The default includes firmware needed for Atheros-based WiFi devices
(Linux-libre module @code{ath9k}). @xref{Hardware Considerations}, for
more info on supported hardware.
@item @code{host-name}
The host name.
@item @code{hosts-file}
@cindex hosts file
A file-like object (@pxref{G-Expressions, file-like objects}) for use as
@file{/etc/hosts} (@pxref{Host Names,,, libc, The GNU C Library
Reference Manual}). The default is a file with entries for
@code{localhost} and @var{host-name}.
@item @code{mapped-devices} (default: @code{'()})
A list of mapped devices. @xref{Mapped Devices}.
@item @code{file-systems}
A list of file systems. @xref{File Systems}.
@item @code{swap-devices} (default: @code{'()})
@cindex swap devices
A list of strings identifying devices to be used for ``swap space''
(@pxref{Memory Concepts,,, libc, The GNU C Library Reference Manual}).
For example, @code{'("/dev/sda3")}.
@item @code{users} (default: @code{%base-user-accounts})
@itemx @code{groups} (default: @var{%base-groups})
List of user accounts and groups. @xref{User Accounts}.
@item @code{skeletons} (default: @code{(default-skeletons)})
A list target file name/file-like object tuples (@pxref{G-Expressions,
file-like objects}). These are the skeleton files that will be added to
the home directory of newly-created user accounts.
For instance, a valid value may look like this:
@example
`((".bashrc" ,(plain-file "bashrc" "echo Hello\n"))
(".guile" ,(plain-file "guile"
"(use-modules (ice-9 readline))
(activate-readline)")))
@end example
@item @code{issue} (default: @var{%default-issue})
A string denoting the contents of the @file{/etc/issue} file, which is
displayed when users log in on a text console.
@item @code{packages} (default: @var{%base-packages})
The set of packages installed in the global profile, which is accessible
at @file{/run/current-system/profile}.
The default set includes core utilities and it is good practice to
install non-core utilities in user profiles (@pxref{Invoking guix
package}).
@item @code{timezone}
A timezone identifying string---e.g., @code{"Europe/Paris"}.
You can run the @command{tzselect} command to find out which timezone
string corresponds to your region. Choosing an invalid timezone name
causes @command{guix system} to fail.
@item @code{locale} (default: @code{"en_US.utf8"})
The name of the default locale (@pxref{Locale Names,,, libc, The GNU C
Library Reference Manual}). @xref{Locales}, for more information.
@item @code{locale-definitions} (default: @var{%default-locale-definitions})
The list of locale definitions to be compiled and that may be used at
run time. @xref{Locales}.
@item @code{locale-libcs} (default: @code{(list @var{glibc})})
The list of GNU@tie{}libc packages whose locale data and tools are used
to build the locale definitions. @xref{Locales}, for compatibility
considerations that justify this option.
@item @code{name-service-switch} (default: @var{%default-nss})
Configuration of the libc name service switch (NSS)---a
@code{<name-service-switch>} object. @xref{Name Service Switch}, for
details.
@item @code{services} (default: @var{%base-services})
A list of service objects denoting system services. @xref{Services}.
@item @code{pam-services} (default: @code{(base-pam-services)})
@cindex PAM
@cindex pluggable authentication modules
Linux @dfn{pluggable authentication module} (PAM) services.
@c FIXME: Add xref to PAM services section.
@item @code{setuid-programs} (default: @var{%setuid-programs})
List of string-valued G-expressions denoting setuid programs.
@xref{Setuid Programs}.
@item @code{sudoers-file} (default: @var{%sudoers-specification})
@cindex sudoers file
The contents of the @file{/etc/sudoers} file as a file-like object
(@pxref{G-Expressions, @code{local-file} and @code{plain-file}}).
This file specifies which users can use the @command{sudo} command, what
they are allowed to do, and what privileges they may gain. The default
is that only @code{root} and members of the @code{wheel} group may use
@code{sudo}.
@end table
@end deftp
@node File Systems
@subsection File Systems
The list of file systems to be mounted is specified in the
@code{file-systems} field of the operating system declaration
(@pxref{Using the Configuration System}). Each file system is declared
using the @code{file-system} form, like this:
(file-system
(mount-point "/home")
(device "/dev/sda3")
(type "ext4"))
As usual, some of the fields are mandatory---those shown in the example
above---while others can be omitted. These are described below.
@deftp {Data Type} file-system
Objects of this type represent file systems to be mounted. They
contain the following members:
@table @asis
@item @code{type}
This is a string specifying the type of the file system---e.g.,
@code{"ext4"}.
@item @code{mount-point}
This designates the place where the file system is to be mounted.
@item @code{device}
This names the ``source'' of the file system. By default it is the name
of a node under @file{/dev}, but its meaning depends on the @code{title}
field described below.
@item @code{title} (default: @code{'device})
This is a symbol that specifies how the @code{device} field is to be
interpreted.
When it is the symbol @code{device}, then the @code{device} field is
interpreted as a file name; when it is @code{label}, then @code{device}
is interpreted as a partition label name; when it is @code{uuid},
@code{device} is interpreted as a partition unique identifier (UUID).
UUIDs may be converted from their string representation (as shown by the
@command{tune2fs -l} command) using the @code{uuid} form@footnote{The
@code{uuid} form expects 16-byte UUIDs as defined in
@uref{https://tools.ietf.org/html/rfc4122, RFC@tie{}4122}. This is the
form of UUID used by the ext2 family of file systems and others, but it
is different from ``UUIDs'' found in FAT file systems, for instance.},
like this:
@example
(file-system
(mount-point "/home")
(type "ext4")
(title 'uuid)
(device (uuid "4dab5feb-d176-45de-b287-9b0a6e4c01cb")))
@end example
The @code{label} and @code{uuid} options offer a way to refer to disk
partitions without having to hard-code their actual device
name@footnote{Note that, while it is tempting to use
@file{/dev/disk/by-uuid} and similar device names to achieve the same
result, this is not recommended: These special device nodes are created
by the udev daemon and may be unavailable at the time the device is
mounted.}.
However, when the source of a file system is a mapped device (@pxref{Mapped
Ludovic Courtès
committed
Devices}), its @code{device} field @emph{must} refer to the mapped
device name---e.g., @file{/dev/mapper/root-partition}---and consequently
@code{title} must be set to @code{'device}. This is required so that
the system knows that mounting the file system depends on having the
corresponding device mapping established.
@item @code{flags} (default: @code{'()})
This is a list of symbols denoting mount flags. Recognized flags
include @code{read-only}, @code{bind-mount}, @code{no-dev} (disallow
access to special files), @code{no-suid} (ignore setuid and setgid
bits), and @code{no-exec} (disallow program execution.)
@item @code{options} (default: @code{#f})
This is either @code{#f}, or a string denoting mount options.
@item @code{mount?} (default: @code{#t})
This value indicates whether to automatically mount the file system when
the system is brought up. When set to @code{#f}, the file system gets
an entry in @file{/etc/fstab} (read by the @command{mount} command) but
is not automatically mounted.
@item @code{needed-for-boot?} (default: @code{#f})
This Boolean value indicates whether the file system is needed when
booting. If that is true, then the file system is mounted when the
initial RAM disk (initrd) is loaded. This is always the case, for
instance, for the root file system.
@item @code{check?} (default: @code{#t})
This Boolean indicates whether the file system needs to be checked for
errors before being mounted.
@item @code{create-mount-point?} (default: @code{#f})
When true, the mount point is created if it does not exist yet.
@item @code{dependencies} (default: @code{'()})
This is a list of @code{<file-system>} objects representing file systems
that must be mounted before (and unmounted after) this one.
As an example, consider a hierarchy of mounts: @file{/sys/fs/cgroup} is
a dependency of @file{/sys/fs/cgroup/cpu} and
@file{/sys/fs/cgroup/memory}.
The @code{(gnu system file-systems)} exports the following useful
variables.
@defvr {Scheme Variable} %base-file-systems
These are essential file systems that are required on normal systems,
such as @var{%pseudo-terminal-file-system} and @var{%immutable-store} (see
below.) Operating system declarations should always contain at least
these.
@end defvr
@defvr {Scheme Variable} %pseudo-terminal-file-system
This is the file system to be mounted as @file{/dev/pts}. It supports
@dfn{pseudo-terminals} created @i{via} @code{openpty} and similar
functions (@pxref{Pseudo-Terminals,,, libc, The GNU C Library Reference
Manual}). Pseudo-terminals are used by terminal emulators such as
@command{xterm}.
@end defvr
@defvr {Scheme Variable} %shared-memory-file-system
This file system is mounted as @file{/dev/shm} and is used to support
memory sharing across processes (@pxref{Memory-mapped I/O,
@code{shm_open},, libc, The GNU C Library Reference Manual}).
@end defvr
@defvr {Scheme Variable} %immutable-store
This file system performs a read-only ``bind mount'' of
@file{/gnu/store}, making it read-only for all the users including
@code{root}. This prevents against accidental modification by software
running as @code{root} or by system administrators.
The daemon itself is still able to write to the store: it remounts it
read-write in its own ``name space.''
@end defvr
@defvr {Scheme Variable} %binary-format-file-system
The @code{binfmt_misc} file system, which allows handling of arbitrary
executable file types to be delegated to user space. This requires the
@code{binfmt.ko} kernel module to be loaded.
@end defvr
@defvr {Scheme Variable} %fuse-control-file-system
The @code{fusectl} file system, which allows unprivileged users to mount
and unmount user-space FUSE file systems. This requires the
@code{fuse.ko} kernel module to be loaded.
@end defvr
6879
6880
6881
6882
6883
6884
6885
6886
6887
6888
6889
6890
6891
6892
6893
6894
6895
6896
6897
6898
6899
6900
6901
6902
6903
6904
@node Mapped Devices
@subsection Mapped Devices
@cindex device mapping
@cindex mapped devices
The Linux kernel has a notion of @dfn{device mapping}: a block device,
such as a hard disk partition, can be @dfn{mapped} into another device,
with additional processing over the data that flows through
it@footnote{Note that the GNU@tie{}Hurd makes no difference between the
concept of a ``mapped device'' and that of a file system: both boil down
to @emph{translating} input/output operations made on a file to
operations on its backing store. Thus, the Hurd implements mapped
devices, like file systems, using the generic @dfn{translator} mechanism
(@pxref{Translators,,, hurd, The GNU Hurd Reference Manual}).}. A
typical example is encryption device mapping: all writes to the mapped
device are encrypted, and all reads are deciphered, transparently.
Mapped devices are declared using the @code{mapped-device} form:
@example
(mapped-device
(source "/dev/sda3")
(target "home")
(type luks-device-mapping))
@end example
Or, better yet, like this:
@example
(mapped-device
(source (uuid "cb67fc72-0d54-4c88-9d4b-b225f30b0f44"))
(target "home")
(type luks-device-mapping))
@end example
@cindex disk encryption
@cindex LUKS
This example specifies a mapping from @file{/dev/sda3} to
@file{/dev/mapper/home} using LUKS---the
@url{http://code.google.com/p/cryptsetup,Linux Unified Key Setup}, a
standard mechanism for disk encryption. In the second example, the UUID
(unique identifier) is the LUKS UUID returned for the device by a
command like:
@example
cryptsetup luksUUID /dev/sdx9
@end example
The @file{/dev/mapper/home}
device can then be used as the @code{device} of a @code{file-system}
declaration (@pxref{File Systems}). The @code{mapped-device} form is
detailed below.
@deftp {Data Type} mapped-device
Objects of this type represent device mappings that will be made when
the system boots up.
@table @code
@item source
This string specifies the name of the block device to be mapped, such as
@code{"/dev/sda3"}.
@item target
This string specifies the name of the mapping to be established. For
example, specifying @code{"my-partition"} will lead to the creation of
the @code{"/dev/mapper/my-partition"} device.
@item type
This must be a @code{mapped-device-kind} object, which specifies how
@var{source} is mapped to @var{target}.
@end table
@end deftp
@defvr {Scheme Variable} luks-device-mapping
This defines LUKS block device encryption using the @command{cryptsetup}
command from the package with the same name. It relies on the
@code{dm-crypt} Linux kernel module.
@end defvr
@node User Accounts
@subsection User Accounts
User accounts and groups are entirely managed through the
@code{operating-system} declaration. They are specified with the
@code{user-account} and @code{user-group} forms:
@example
(user-account
(name "alice")
(group "users")
(supplementary-groups '("wheel" ;allow use of sudo, etc.
"audio" ;sound card
"video" ;video devices such as webcams
"cdrom")) ;the good ol' CD-ROM
(comment "Bob's sister")
(home-directory "/home/alice"))
@end example
When booting or upon completion of @command{guix system reconfigure},
the system ensures that only the user accounts and groups specified in
the @code{operating-system} declaration exist, and with the specified
properties. Thus, account or group creations or modifications made by
directly invoking commands such as @command{useradd} are lost upon
reconfiguration or reboot. This ensures that the system remains exactly
as declared.
@deftp {Data Type} user-account
Objects of this type represent user accounts. The following members may
be specified:
@table @asis
@item @code{name}
The name of the user account.
@item @code{group}
This is the name (a string) or identifier (a number) of the user group
this account belongs to.
@item @code{supplementary-groups} (default: @code{'()})
Optionally, this can be defined as a list of group names that this
account belongs to.
@item @code{uid} (default: @code{#f})
This is the user ID for this account (a number), or @code{#f}. In the
latter case, a number is automatically chosen by the system when the
account is created.
@item @code{comment} (default: @code{""})
A comment about the account, such as the account owner's full name.
@item @code{home-directory}
This is the name of the home directory for the account.
@item @code{shell} (default: Bash)
This is a G-expression denoting the file name of a program to be used as
the shell (@pxref{G-Expressions}).
@item @code{system?} (default: @code{#f})
This Boolean value indicates whether the account is a ``system''
account. System accounts are sometimes treated specially; for instance,
graphical login managers do not list them.
@anchor{user-account-password}
@item @code{password} (default: @code{#f})
You would normally leave this field to @code{#f}, initialize user
passwords as @code{root} with the @command{passwd} command, and then let
users change it with @command{passwd}. Passwords set with
@command{passwd} are of course preserved across reboot and
reconfiguration.
If you @emph{do} want to have a preset password for an account, then
this field must contain the encrypted password, as a string.
@xref{crypt,,, libc, The GNU C Library Reference Manual}, for more information
on password encryption, and @ref{Encryption,,, guile, GNU Guile Reference
Manual}, for information on Guile's @code{crypt} procedure.
User group declarations are even simpler:
@example
(user-group (name "students"))
@end example
@deftp {Data Type} user-group
This type is for, well, user groups. There are just a few fields:
@table @asis
@item @code{name}
@item @code{id} (default: @code{#f})
The group identifier (a number). If @code{#f}, a new number is
automatically allocated when the group is created.
@item @code{system?} (default: @code{#f})
This Boolean value indicates whether the group is a ``system'' group.
System groups have low numerical IDs.
@item @code{password} (default: @code{#f})
What, user groups can have a password? Well, apparently yes. Unless
@code{#f}, this field specifies the password of the group.
For convenience, a variable lists all the basic user groups one may
expect:
@defvr {Scheme Variable} %base-groups
This is the list of basic user groups that users and/or packages expect
to be present on the system. This includes groups such as ``root'',
``wheel'', and ``users'', as well as groups used to control access to
specific devices such as ``audio'', ``disk'', and ``cdrom''.
@end defvr
@defvr {Scheme Variable} %base-user-accounts
This is the list of basic system accounts that programs may expect to
find on a GNU/Linux system, such as the ``nobody'' account.
Note that the ``root'' account is not included here. It is a
special-case and is automatically added whether or not it is specified.
@end defvr
@node Locales
@subsection Locales
@cindex locale
A @dfn{locale} defines cultural conventions for a particular language
and region of the world (@pxref{Locales,,, libc, The GNU C Library
Reference Manual}). Each locale has a name that typically has the form
@code{@var{language}_@var{territory}.@var{codeset}}---e.g.,
@code{fr_LU.utf8} designates the locale for the French language, with
cultural conventions from Luxembourg, and using the UTF-8 encoding.
@cindex locale definition
Usually, you will want to specify the default locale for the machine
using the @code{locale} field of the @code{operating-system} declaration
(@pxref{operating-system Reference, @code{locale}}).
The selected locale is automatically added to the @dfn{locale
definitions} known to the system if needed, with its codeset inferred
from its name---e.g., @code{bo_CN.utf8} will be assumed to use the
@code{UTF-8} codeset. Additional locale definitions can be specified in
the @code{locale-definitions} slot of @code{operating-system}---this is
useful, for instance, if the codeset could not be inferred from the
locale name. The default set of locale definitions includes some widely
used locales, but not all the available locales, in order to save space.
For instance, to add the North Frisian locale for Germany, the value of
that field may be:
@example
(cons (locale-definition
(name "fy_DE.utf8") (source "fy_DE"))
%default-locale-definitions)
@end example
Likewise, to save space, one might want @code{locale-definitions} to
list only the locales that are actually used, as in:
@example
(list (locale-definition
(name "ja_JP.eucjp") (source "ja_JP")
(charset "EUC-JP")))
@end example
@vindex LOCPATH
The compiled locale definitions are available at
@file{/run/current-system/locale/X.Y}, where @code{X.Y} is the libc
version, which is the default location where the GNU@tie{}libc provided
by Guix looks for locale data. This can be overridden using the
@code{LOCPATH} environment variable (@pxref{locales-and-locpath,
@code{LOCPATH} and locale packages}).
7135
7136
7137
7138
7139
7140
7141
7142
7143
7144
7145
7146
7147
7148
7149
7150
7151
7152
7153
7154
7155
7156
7157
7158
7159
The @code{locale-definition} form is provided by the @code{(gnu system
locale)} module. Details are given below.
@deftp {Data Type} locale-definition
This is the data type of a locale definition.
@table @asis
@item @code{name}
The name of the locale. @xref{Locale Names,,, libc, The GNU C Library
Reference Manual}, for more information on locale names.
@item @code{source}
The name of the source for that locale. This is typically the
@code{@var{language}_@var{territory}} part of the locale name.
@item @code{charset} (default: @code{"UTF-8"})
The ``character set'' or ``code set'' for that locale,
@uref{http://www.iana.org/assignments/character-sets, as defined by
IANA}.
@end table
@end deftp
@defvr {Scheme Variable} %default-locale-definitions
A list of commonly used UTF-8 locales, used as the default
value of the @code{locale-definitions} field of @code{operating-system}
@cindex locale name
@cindex normalized codeset in locale names
These locale definitions use the @dfn{normalized codeset} for the part
that follows the dot in the name (@pxref{Using gettextized software,
normalized codeset,, libc, The GNU C Library Reference Manual}). So for
instance it has @code{uk_UA.utf8} but @emph{not}, say,
@code{uk_UA.UTF-8}.
7173
7174
7175
7176
7177
7178
7179
7180
7181
7182
7183
7184
7185
7186
7187
7188
7189
7190
7191
7192
7193
7194
7195
7196
7197
7198
7199
7200
7201
7202
7203
7204
7205
7206
7207
7208
7209
7210
7211
7212
7213
7214
7215
7216
7217
7218
7219
7220
7221
7222
7223
@subsubsection Locale Data Compatibility Considerations
@cindex incompatibility, of locale data
@code{operating-system} declarations provide a @code{locale-libcs} field
to specify the GNU@tie{}libc packages that are used to compile locale
declarations (@pxref{operating-system Reference}). ``Why would I
care?'', you may ask. Well, it turns out that the binary format of
locale data is occasionally incompatible from one libc version to
another.
@c See <https://sourceware.org/ml/libc-alpha/2015-09/msg00575.html>
@c and <https://lists.gnu.org/archive/html/guix-devel/2015-08/msg00737.html>.
For instance, a program linked against libc version 2.21 is unable to
read locale data produced with libc 2.22; worse, that program
@emph{aborts} instead of simply ignoring the incompatible locale
data@footnote{Versions 2.23 and later of GNU@tie{}libc will simply skip
the incompatible locale data, which is already an improvement.}.
Similarly, a program linked against libc 2.22 can read most, but not
all, the locale data from libc 2.21 (specifically, @code{LC_COLLATE}
data is incompatible); thus calls to @code{setlocale} may fail, but
programs will not abort.
The ``problem'' in GuixSD is that users have a lot of freedom: They can
choose whether and when to upgrade software in their profiles, and might
be using a libc version different from the one the system administrator
used to build the system-wide locale data.
Fortunately, unprivileged users can also install their own locale data
and define @var{GUIX_LOCPATH} accordingly (@pxref{locales-and-locpath,
@code{GUIX_LOCPATH} and locale packages}).
Still, it is best if the system-wide locale data at
@file{/run/current-system/locale} is built for all the libc versions
actually in use on the system, so that all the programs can access
it---this is especially crucial on a multi-user system. To do that, the
administrator can specify several libc packages in the
@code{locale-libcs} field of @code{operating-system}:
@example
(use-package-modules base)
(operating-system
;; @dots{}
(locale-libcs (list glibc-2.21 (canonical-package glibc))))
@end example
This example would lead to a system containing locale definitions for
both libc 2.21 and the current version of libc in
@file{/run/current-system/locale}.
@node Services
@subsection Services
@cindex system services
An important part of preparing an @code{operating-system} declaration is
listing @dfn{system services} and their configuration (@pxref{Using the
Configuration System}). System services are typically daemons launched
when the system boots, or other actions needed at that time---e.g.,
Services are managed by the GNU@tie{}Shepherd (@pxref{Introduction,,,
shepherd, The GNU Shepherd Manual}). On a running system, the
@command{herd} command allows you to list the available services, show
their status, start and stop them, or do other specific operations
(@pxref{Jump Start,,, shepherd, The GNU Shepherd Manual}). For example:
@end example
The above command, run as @code{root}, lists the currently defined
services. The @command{herd doc} command shows a synopsis of the given
Run libc's name service cache daemon (nscd).
@end example
The @command{start}, @command{stop}, and @command{restart} sub-commands
have the effect you would expect. For instance, the commands below stop
the nscd service and restart the Xorg display server:
@example
# herd restart xorg-server
Service xorg-server has been stopped.
Service xorg-server has been started.
@end example
The following sections document the available services, starting with
the core services, that may be used in an @code{operating-system}
declaration.
@menu
* Base Services:: Essential system services.
* Scheduled Job Execution:: The mcron service.
* Networking Services:: Network setup, SSH daemon, etc.
* X Window:: Graphical display.
* Desktop Services:: D-Bus and desktop services.
* Mail Services:: IMAP, POP3, SMTP, and all that.
@node Base Services
@subsubsection Base Services
The @code{(gnu services base)} module provides definitions for the basic
services that one expects from the system. The services exported by
this module are listed below.
@defvr {Scheme Variable} %base-services
This variable contains a list of basic services (@pxref{Service Types
and Services}, for more information on service objects) one would
expect from the system: a login service (mingetty) on each tty, syslogd,
the libc name service cache daemon (nscd), the udev device manager, and
This is the default value of the @code{services} field of
@code{operating-system} declarations. Usually, when customizing a
system, you will want to append services to @var{%base-services}, like
this:
@end example
@end defvr
@deffn {Scheme Procedure} host-name-service @var{name}
Return a service that sets the host name to @var{name}.
@end deffn
@deffn {Scheme Procedure} mingetty-service @var{config}
Return a service to run mingetty according to @var{config}, a
@code{<mingetty-configuration>} object, which specifies the tty to run, among
other things.
@deftp {Data Type} mingetty-configuration
This is the data type representing the configuration of Mingetty, which
implements console log-in.
@table @asis
@item @code{tty}
The name of the console this Mingetty runs on---e.g., @code{"tty1"}.
@item @code{motd}
A file-like object containing the ``message of the day''.
@item @code{auto-login} (default: @code{#f})
When true, this field must be a string denoting the user name under
which the system automatically logs in. When it is @code{#f}, a
user name and password must be entered to log in.
@item @code{login-program} (default: @code{#f})
This must be either @code{#f}, in which case the default log-in program
is used (@command{login} from the Shadow tool suite), or a gexp denoting
the name of the log-in program.
@item @code{login-pause?} (default: @code{#f})
When set to @code{#t} in conjunction with @var{auto-login}, the user
will have to press a key before the log-in shell is launched.
@item @code{mingetty} (default: @var{mingetty})
The Mingetty package to use.
@end table
@end deftp
Ludovic Courtès
committed
@cindex name service cache daemon
@cindex nscd
@deffn {Scheme Procedure} nscd-service [@var{config}] [#:glibc glibc] @
[#:name-services '()]
Return a service that runs the libc name service cache daemon (nscd) with the
given @var{config}---an @code{<nscd-configuration>} object. @xref{Name
Service Switch}, for an example.
Ludovic Courtès
committed
@defvr {Scheme Variable} %nscd-default-configuration
This is the default @code{<nscd-configuration>} value (see below) used
by @code{nscd-service}. It uses the caches defined by
Ludovic Courtès
committed
@var{%nscd-default-caches}; see below.
@end defvr
@deftp {Data Type} nscd-configuration
This is the data type representing the name service cache daemon (nscd)
Ludovic Courtès
committed
configuration.
@table @asis
@item @code{name-services} (default: @code{'()})
List of packages denoting @dfn{name services} that must be visible to
the nscd---e.g., @code{(list @var{nss-mdns})}.
@item @code{glibc} (default: @var{glibc})
Package object denoting the GNU C Library providing the @command{nscd}
command.
Ludovic Courtès
committed
@item @code{log-file} (default: @code{"/var/log/nscd.log"})
Name of the nscd log file. This is where debugging output goes when
Ludovic Courtès
committed
@code{debug-level} is strictly positive.
@item @code{debug-level} (default: @code{0})
Integer denoting the debugging levels. Higher numbers mean that more
Ludovic Courtès
committed
7382
7383
7384
7385
7386
7387
7388
7389
7390
7391
7392
7393
7394
7395
7396
7397
7398
7399
7400
7401
7402
7403
7404
7405
7406
7407
7408
7409
7410
7411
7412
7413
7414
7415
7416
7417
7418
7419
7420
7421
7422
7423
7424
7425
7426
7427
7428
7429
7430
7431
debugging output is logged.
@item @code{caches} (default: @var{%nscd-default-caches})
List of @code{<nscd-cache>} objects denoting things to be cached; see
below.
@end table
@end deftp
@deftp {Data Type} nscd-cache
Data type representing a cache database of nscd and its parameters.
@table @asis
@item @code{database}
This is a symbol representing the name of the database to be cached.
Valid values are @code{passwd}, @code{group}, @code{hosts}, and
@code{services}, which designate the corresponding NSS database
(@pxref{NSS Basics,,, libc, The GNU C Library Reference Manual}).
@item @code{positive-time-to-live}
@itemx @code{negative-time-to-live} (default: @code{20})
A number representing the number of seconds during which a positive or
negative lookup result remains in cache.
@item @code{check-files?} (default: @code{#t})
Whether to check for updates of the files corresponding to
@var{database}.
For instance, when @var{database} is @code{hosts}, setting this flag
instructs nscd to check for updates in @file{/etc/hosts} and to take
them into account.
@item @code{persistent?} (default: @code{#t})
Whether the cache should be stored persistently on disk.
@item @code{shared?} (default: @code{#t})
Whether the cache should be shared among users.
@item @code{max-database-size} (default: 32@tie{}MiB)
Maximum size in bytes of the database cache.
@c XXX: 'suggested-size' and 'auto-propagate?' seem to be expert
@c settings, so leave them out.
@end table
@end deftp
@defvr {Scheme Variable} %nscd-default-caches
List of @code{<nscd-cache>} objects used by default by
@code{nscd-configuration} (see above).
Ludovic Courtès
committed
It enables persistent and aggressive caching of service and host name
lookups. The latter provides better host name lookup performance,
resilience in the face of unreliable name servers, and also better
privacy---often the result of host name lookups is in local cache, so
external name servers do not even need to be queried.
@end defvr
@deffn {Scheme Procedure} syslog-service @
[#:config-file @var{%default-syslog.conf}]
Return a service that runs @command{syslogd}. If the configuration file
name @var{config-file} is not specified, use some reasonable default
@xref{syslogd invocation,,, inetutils, GNU Inetutils}, for more
information on the configuration file syntax.
@anchor{guix-configuration-type}
@deftp {Data Type} guix-configuration
This data type represents the configuration of the Guix build daemon.
@xref{Invoking guix-daemon}, for more information.
@table @asis
@item @code{guix} (default: @var{guix})
The Guix package to use.
@item @code{build-group} (default: @code{"guixbuild"})
Name of the group for build user accounts.
@item @code{build-accounts} (default: @code{10})
Number of build user accounts to create.
@item @code{authorize-key?} (default: @code{#t})
Whether to authorize the substitute key for @code{hydra.gnu.org}
(@pxref{Substitutes}).
@item @code{use-substitutes?} (default: @code{#t})
Whether to use substitutes.
@item @code{substitute-urls} (default: @var{%default-substitute-urls})
The list of URLs where to look for substitutes by default.
@item @code{extra-options} (default: @code{'()})
List of extra command-line options for @command{guix-daemon}.
@item @code{lsof} (default: @var{lsof})
@itemx @code{lsh} (default: @var{lsh})
The lsof and lsh packages to use.
@end table
@end deftp
@deffn {Scheme Procedure} guix-service @var{config}
Return a service that runs the Guix build daemon according to
@var{config}.
@deffn {Scheme Procedure} udev-service [#:udev udev]
Run @var{udev}, which populates the @file{/dev} directory dynamically.
@end deffn
@deffn {Scheme Procedure} urandom-seed-service @var{#f}
Save some entropy in @var{%random-seed-file} to seed @file{/dev/urandom}
when rebooting.
@end deffn
@defvr {Scheme Variable} %random-seed-file
This is the name of the file where some random bytes are saved by
@var{urandom-seed-service} to seed @file{/dev/urandom} when rebooting.
It defaults to @file{/var/lib/random-seed}.
@end defvr
@deffn {Scheme Procedure} console-keymap-service @var{files} ...
@cindex keyboard layout
Return a service to load console keymaps from @var{files} using
@command{loadkeys} command. Most likely, you want to load some default
keymap, which can be done like this:
@example
(console-keymap-service "dvorak")
@end example
Or, for example, for a Swedish keyboard, you may need to combine
the following keymaps:
@example
(console-keymap-service "se-lat6" "se-fi-lat6")
@end example
Also you can specify a full file name (or file names) of your keymap(s).
See @code{man loadkeys} for details.
@deffn {Scheme Procedure} gpm-service [#:gpm @var{gpm}] @
[#:options]
Run @var{gpm}, the general-purpose mouse daemon, with the given
command-line @var{options}. GPM allows users to use the mouse in the console,
notably to select, copy, and paste text. The default value of @var{options}
uses the @code{ps2} protocol, which works for both USB and PS/2 mice.
This service is not part of @var{%base-services}.
@end deffn
@anchor{guix-publish-service}
@deffn {Scheme Procedure} guix-publish-service [#:guix @var{guix}] @
[#:port 80] [#:host "localhost"]
Return a service that runs @command{guix publish} listening on @var{host}
and @var{port} (@pxref{Invoking guix publish}).
This assumes that @file{/etc/guix} already contains a signing key pair as
created by @command{guix archive --generate-key} (@pxref{Invoking guix
archive}). If that is not the case, the service will fail to start.
@end deffn
@anchor{rngd-service}
@deffn {Scheme Procedure} rngd-service [#:rng-tools @var{rng-tools}] @
[#:device "/dev/hwrng"]
Return a service that runs the @command{rngd} program from @var{rng-tools}
to add @var{device} to the kernel's entropy pool. The service will fail if
@var{device} does not exist.
@end deffn
@node Scheduled Job Execution
@subsubsection Scheduled Job Execution
@cindex cron
@cindex scheduling jobs
The @code{(gnu services mcron)} module provides an interface to
GNU@tie{}mcron, a daemon to run jobs at scheduled times (@pxref{Top,,,
mcron, GNU@tie{}mcron}). GNU@tie{}mcron is similar to the traditional
Unix @command{cron} daemon; the main difference is that it is
implemented in Guile Scheme, which provides a lot of flexibility when
specifying the scheduling of jobs and their actions.
The example below defines an operating system that runs the
@command{updatedb} (@pxref{Invoking updatedb,,, find, Finding Files})
and the @command{guix gc} commands (@pxref{Invoking guix gc}) daily, as
well as the @command{mkid} command on behalf of an unprivileged user
(@pxref{mkid invocation,,, idutils, ID Database Utilities}). It uses
gexps to introduce job definitions that are passed to mcron
(@pxref{G-Expressions}).
@lisp
(use-modules (guix) (gnu) (gnu services mcron))
;; Run 'updatedb' at 3AM every day. Here we write the
;; job's action as a Scheme procedure.
(lambda ()
(execl (string-append #$findutils "/bin/updatedb")
"updatedb"
"--prunepaths=/tmp /var/tmp /gnu/store"))))
(define garbage-collector-job
;; Collect garbage 5 minutes after midnight every day.
#~(job "5 0 * * *" ;Vixie cron syntax
"guix gc -F 1G"))
(define idutils-jobs
;; Update the index database as user "charlie" at 12:15PM
;; and 19:15PM. This runs from the user's home directory.
#~(job '(next-minute-from (next-hour '(12 19)) '(15))
(string-append #$idutils "/bin/mkid src")
#:user "charlie"))
(operating-system
;; @dots{}
(services (cons (mcron-service (list garbage-collector-job
7608
7609
7610
7611
7612
7613
7614
7615
7616
7617
7618
7619
7620
7621
7622
7623
7624
7625
7626
7627
7628
7629
7630
7631
7632
7633
7634
7635
7636
7637
7638
7639
7640
7641
7642
7643
7644
7645
7646
7647
7648
7649
7650
%base-services)))
@end lisp
@xref{Guile Syntax, mcron job specifications,, mcron, GNU@tie{}mcron},
for more information on mcron job specifications. Below is the
reference of the mcron service.
@deffn {Scheme Procedure} mcron-service @var{jobs} [#:mcron @var{mcron2}]
Return an mcron service running @var{mcron} that schedules @var{jobs}, a
list of gexps denoting mcron job specifications.
This is a shorthand for:
@example
(service mcron-service-type
(mcron-configuration (mcron mcron) (jobs jobs)))
@end example
@end deffn
@defvr {Scheme Variable} mcron-service-type
This is the type of the @code{mcron} service, whose value is an
@code{mcron-configuration} object.
This service type can be the target of a service extension that provides
it additional job specifications (@pxref{Service Composition}). In
other words, it is possible to define services that provide addition
mcron jobs to run.
@end defvr
@deftp {Data Type} mcron-configuration
Data type representing the configuration of mcron.
@table @asis
@item @code{mcron} (default: @var{mcron2})
The mcron package to use.
@item @code{jobs}
This is a list of gexps (@pxref{G-Expressions}), where each gexp
corresponds to an mcron job specification (@pxref{Syntax, mcron job
specifications,, mcron, GNU@tie{}mcron}).
@end table
@end deftp
@node Networking Services
@subsubsection Networking Services
The @code{(gnu services networking)} module provides services to configure
@cindex DHCP, networking service
@deffn {Scheme Procedure} dhcp-client-service [#:dhcp @var{isc-dhcp}]
Return a service that runs @var{dhcp}, a Dynamic Host Configuration
Protocol (DHCP) client, on all the non-loopback network interfaces.
@end deffn
@deffn {Scheme Procedure} static-networking-service @var{interface} @var{ip} @
[#:gateway #f] [#:name-servers @code{'()}]
Return a service that starts @var{interface} with address @var{ip}. If
@var{gateway} is true, it must be a string specifying the default network
gateway.
@end deffn
@cindex network management
@deffn {Scheme Procedure} wicd-service [#:wicd @var{wicd}]
Return a service that runs @url{https://launchpad.net/wicd,Wicd}, a network
management daemon that aims to simplify wired and wireless networking.
This service adds the @var{wicd} package to the global profile, providing
several commands to interact with the daemon and configure networking:
@command{wicd-client}, a graphical user interface, and the @command{wicd-cli}
and @command{wicd-curses} user interfaces.
@cindex NetworkManager
@deffn {Scheme Procedure} network-manager-service @
[#:network-manager @var{network-manager}]
Return a service that runs NetworkManager, a network connection manager
attempting to keep network connectivity active when available.
@cindex Connman
@deffn {Scheme Procedure} connman-service @
[#:connman @var{connman}]
Return a service that runs @url{https://01.org/connman,Connman}, a network
connection manager.
This service adds the @var{connman} package to the global profile, providing
several the @command{connmanctl} command to interact with the daemon and
configure networking."
@end deffn
@deffn {Scheme Procedure} ntp-service [#:ntp @var{ntp}] @
[#:name-service @var{%ntp-servers}]
Return a service that runs the daemon from @var{ntp}, the
@uref{http://www.ntp.org, Network Time Protocol package}. The daemon will
keep the system clock synchronized with that of @var{servers}.
@end deffn
@defvr {Scheme Variable} %ntp-servers
List of host names used as the default NTP servers.
@end defvr
@deffn {Scheme Procedure} tor-service [@var{config-file}] [#:tor @var{tor}]
Return a service to run the @uref{https://torproject.org, Tor} anonymous
networking daemon.
The daemon runs as the @code{tor} unprivileged user. It is passed
@var{config-file}, a file-like object, with an additional @code{User tor} line
and lines for hidden services added via @code{tor-hidden-service}. Run
@command{man tor} for information about the configuration file.
@end deffn
@deffn {Scheme Procedure} tor-hidden-service @var{name} @var{mapping}
Define a new Tor @dfn{hidden service} called @var{name} and implementing
@var{mapping}. @var{mapping} is a list of port/host tuples, such as:
@example
'((22 "127.0.0.1:22")
(80 "127.0.0.1:8080"))
@end example
In this example, port 22 of the hidden service is mapped to local port 22, and
port 80 is mapped to local port 8080.
This creates a @file{/var/lib/tor/hidden-services/@var{name}} directory, where
the @file{hostname} file contains the @code{.onion} host name for the hidden
service.
See @uref{https://www.torproject.org/docs/tor-hidden-service.html.en, the Tor
project's documentation} for more information.
@deffn {Scheme Procedure} bitlbee-service [#:bitlbee bitlbee] @
[#:interface "127.0.0.1"] [#:port 6667] @
[#:extra-settings ""]
Return a service that runs @url{http://bitlbee.org,BitlBee}, a daemon that
acts as a gateway between IRC and chat networks.
The daemon will listen to the interface corresponding to the IP address
specified in @var{interface}, on @var{port}. @code{127.0.0.1} means that only
local clients can connect, whereas @code{0.0.0.0} means that connections can
come from any networking interface.
In addition, @var{extra-settings} specifies a string to append to the
configuration file.
@end deffn
Furthermore, @code{(gnu services ssh)} provides the following services.
@deffn {Scheme Procedure} lsh-service [#:host-key "/etc/lsh/host-key"] @
[#:daemonic? #t] [#:interfaces '()] [#:port-number 22] @
[#:allow-empty-passwords? #f] [#:root-login? #f] @
[#:syslog-output? #t] [#:x11-forwarding? #t] @
[#:tcp/ip-forwarding? #t] [#:password-authentication? #t] @
[#:public-key-authentication? #t] [#:initialize? #t]
Run the @command{lshd} program from @var{lsh} to listen on port @var{port-number}.
@var{host-key} must designate a file containing the host key, and readable
only by root.
When @var{daemonic?} is true, @command{lshd} will detach from the
controlling terminal and log its output to syslogd, unless one sets
@var{syslog-output?} to false. Obviously, it also makes lsh-service
depend on existence of syslogd service. When @var{pid-file?} is true,
@command{lshd} writes its PID to the file called @var{pid-file}.
When @var{initialize?} is true, automatically create the seed and host key
upon service activation if they do not exist yet. This may take long and
require interaction.
When @var{initialize?} is false, it is up to the user to initialize the
randomness generator (@pxref{lsh-make-seed,,, lsh, LSH Manual}), and to create
a key pair with the private key stored in file @var{host-key} (@pxref{lshd
basics,,, lsh, LSH Manual}).
When @var{interfaces} is empty, lshd listens for connections on all the
network interfaces; otherwise, @var{interfaces} must be a list of host names
or addresses.
@var{allow-empty-passwords?} specifies whether to accept log-ins with empty
passwords, and @var{root-login?} specifies whether to accept log-ins as
The other options should be self-descriptive.
@end deffn
7795
7796
7797
7798
7799
7800
7801
7802
7803
7804
7805
7806
7807
7808
7809
7810
7811
7812
7813
7814
7815
7816
7817
7818
7819
7820
7821
7822
7823
7824
7825
7826
7827
7828
7829
7830
7831
7832
7833
7834
7835
@deffn {Scheme Procedure} dropbear-service [@var{config}]
Run the @uref{https://matt.ucc.asn.au/dropbear/dropbear.html,Dropbear SSH
daemon} with the given @var{config}, a @code{<dropbear-configuration>}
object.
For example, to specify a Dropbear service listening on port 1234, add
this call to the operating system's @code{services} field:
@example
(dropbear-service (dropbear-configuration
(port-number 1234)))
@end example
@end deffn
@deftp {Data Type} dropbear-configuration
This data type represents the configuration of a Dropbear SSH daemon.
@table @asis
@item @code{dropbear} (default: @var{dropbear})
The Dropbear package to use.
@item @code{port-number} (default: 22)
The TCP port where the daemon waits for incoming connections.
@item @code{syslog-output?} (default: @code{#t})
Whether to enable syslog output.
@item @code{pid-file} (default: @code{"/var/run/dropbear.pid"})
File name of the daemon's PID file.
@item @code{root-login?} (default: @code{#f})
Whether to allow @code{root} logins.
@item @code{allow-empty-passwords?} (default: @code{#f})
Whether to allow empty passwords.
@item @code{password-authentication?} (default: @code{#t})
Whether to enable password-based authentication.
@end table
@end deftp
@defvr {Scheme Variable} %facebook-host-aliases
This variable contains a string for use in @file{/etc/hosts}
(@pxref{Host Names,,, libc, The GNU C Library Reference Manual}). Each
line contains a entry that maps a known server name of the Facebook
on-line service---e.g., @code{www.facebook.com}---to the local
host---@code{127.0.0.1} or its IPv6 equivalent, @code{::1}.
This variable is typically used in the @code{hosts-file} field of an
@code{operating-system} declaration (@pxref{operating-system Reference,
@file{/etc/hosts}}):
@example
(use-modules (gnu) (guix))
(operating-system
(host-name "mymachine")
;; ...
(hosts-file
;; Create a /etc/hosts file with aliases for "localhost"
;; and "mymachine", as well as for Facebook servers.
(plain-file "hosts"
(string-append (local-host-aliases host-name)
%facebook-host-aliases))))
@end example
This mechanism can prevent programs running locally, such as Web
browsers, from accessing Facebook.
@end defvr
The @code{(gnu services avahi)} provides the following definition.
@deffn {Scheme Procedure} avahi-service [#:avahi @var{avahi}] @
[#:host-name #f] [#:publish? #t] [#:ipv4? #t] @
[#:ipv6? #t] [#:wide-area? #f] @
[#:domains-to-browse '()] [#:debug? #f]
Return a service that runs @command{avahi-daemon}, a system-wide
mDNS/DNS-SD responder that allows for service discovery and
"zero-configuration" host name lookups (see @uref{http://avahi.org/}), and
extends the name service cache daemon (nscd) so that it can resolve
@code{.local} host names using
@uref{http://0pointer.de/lennart/projects/nss-mdns/, nss-mdns}. Additionally,
add the @var{avahi} package to the system profile so that commands such as
@command{avahi-browse} are directly usable.
If @var{host-name} is different from @code{#f}, use that as the host name to
publish for this machine; otherwise, use the machine's actual host name.
When @var{publish?} is true, publishing of host names and services is allowed;
in particular, avahi-daemon will publish the machine's host name and IP
address via mDNS on the local network.
When @var{wide-area?} is true, DNS-SD over unicast DNS is enabled.
Boolean values @var{ipv4?} and @var{ipv6?} determine whether to use IPv4/IPv6
sockets.
@end deffn
@node X Window
@subsubsection X Window
Support for the X Window graphical display system---specifically
Xorg---is provided by the @code{(gnu services xorg)} module. Note that
there is no @code{xorg-service} procedure. Instead, the X server is
started by the @dfn{login manager}, currently SLiM.
@deffn {Scheme Procedure} slim-service [#:allow-empty-passwords? #f] @
[#:auto-login? #f] [#:default-user ""] [#:startx] @
[#:theme @var{%default-slim-theme}] @
Sou Bunnbu (宋文武)
committed
[#:theme-name @var{%default-slim-theme-name}]
Return a service that spawns the SLiM graphical login manager, which in
turn starts the X display server with @var{startx}, a command as returned by
@code{xorg-start-command}.
@cindex X session
SLiM automatically looks for session types described by the @file{.desktop}
files in @file{/run/current-system/profile/share/xsessions} and allows users
to choose a session from the log-in screen using @kbd{F1}. Packages such as
@var{xfce}, @var{sawfish}, and @var{ratpoison} provide @file{.desktop} files;
adding them to the system-wide set of packages automatically makes them
available at the log-in screen.
In addition, @file{~/.xsession} files are honored. When available,
@file{~/.xsession} must be an executable that starts a window manager
and/or other X clients.
When @var{allow-empty-passwords?} is true, allow logins with an empty
password. When @var{auto-login?} is true, log in automatically as
@var{default-user}.
If @var{theme} is @code{#f}, use the default log-in theme; otherwise
@var{theme} must be a gexp denoting the name of a directory containing the
theme to use. In that case, @var{theme-name} specifies the name of the
theme.
@defvr {Scheme Variable} %default-theme
@defvrx {Scheme Variable} %default-theme-name
The G-Expression denoting the default SLiM theme and its name.
@end defvr
@deffn {Scheme Procedure} xorg-start-command [#:guile] @
[#:configuration-file #f] [#:xorg-server @var{xorg-server}]
Return a derivation that builds a @var{guile} script to start the X server
from @var{xorg-server}. @var{configuration-file} is the server configuration
file or a derivation that builds it; when omitted, the result of
@code{xorg-configuration-file} is used.
Usually the X server is started by a login manager.
@end deffn
@deffn {Scheme Procedure} xorg-configuration-file @
[#:drivers '()] [#:resolutions '()] [#:extra-config '()]
Return a configuration file for the Xorg server containing search paths for
all the common drivers.
@var{drivers} must be either the empty list, in which case Xorg chooses a
graphics driver automatically, or a list of driver names that will be tried in
this order---e.g., @code{(\"modesetting\" \"vesa\")}.
Likewise, when @var{resolutions} is the empty list, Xorg chooses an
appropriate screen resolution; otherwise, it must be a list of
resolutions---e.g., @code{((1024 768) (640 480))}.
Last, @var{extra-config} is a list of strings or objects appended to the
@code{text-file*} argument list. It is used to pass extra text to be added
verbatim to the configuration file.
@end deffn
@deffn {Scheme Procedure} screen-locker-service @var{package} [@var{name}]
Add @var{package}, a package for a screen-locker or screen-saver whose
command is @var{program}, to the set of setuid programs and add a PAM entry
for it. For example:
@lisp
(screen-locker-service xlockmore "xlock")
@end lisp
makes the good ol' XlockMore usable.
@end deffn
@node Desktop Services
@subsubsection Desktop Services
The @code{(gnu services desktop)} module provides services that are
usually useful in the context of a ``desktop'' setup---that is, on a
machine running a graphical display server, possibly with graphical user
interfaces, etc. It also defines services that provide specific desktop
environments like GNOME and XFCE.
To simplify things, the module defines a variable containing the set of
services that users typically expect on a machine with a graphical
environment and networking:
@defvr {Scheme Variable} %desktop-services
This is a list of services that builds upon @var{%base-services} and
adds or adjusts services for a typical ``desktop'' setup.
In particular, it adds a graphical login manager (@pxref{X Window,
@code{slim-service}}), screen lockers,
a network management tool (@pxref{Networking
Services, @code{wicd-service}}), energy and color management services,
the @code{elogind} login and seat manager, the Polkit privilege service,
the GeoClue location service, an NTP client (@pxref{Networking
Services}), the Avahi daemon, and has the name service switch service
configured to be able to use @code{nss-mdns} (@pxref{Name Service
Switch, mDNS}).
@end defvr
The @var{%desktop-services} variable can be used as the @code{services}
field of an @code{operating-system} declaration (@pxref{operating-system
Reference, @code{services}}).
8011
8012
8013
8014
8015
8016
8017
8018
8019
8020
8021
8022
8023
8024
8025
8026
8027
8028
8029
8030
8031
8032
8033
8034
8035
8036
8037
8038
8039
8040
8041
8042
8043
8044
8045
8046
8047
8048
8049
8050
8051
8052
8053
8054
8055
8056
8057
8058
8059
8060
8061
Additionally, the @code{gnome-desktop-service} and
@code{xfce-desktop-service} procedures can add GNOME and/or XFCE to a
system. To ``add GNOME'' means that system-level services like the
backlight adjustment helpers and the power management utilities are
added to the system, extending @code{polkit} and @code{dbus}
appropriately, allowing GNOME to operate with elevated privileges on a
limited number of special-purpose system interfaces. Additionally,
adding a service made by @code{gnome-desktop-service} adds the GNOME
metapackage to the system profile. Likewise, adding the XFCE service
not only adds the @code{xfce} metapackage to the system profile, but it
also gives the Thunar file manager the ability to open a ``root-mode''
file management window, if the user authenticates using the
administrator's password via the standard polkit graphical interface.
@deffn {Scheme Procedure} gnome-desktop-service
Return a service that adds the @code{gnome} package to the system
profile, and extends polkit with the actions from
@code{gnome-settings-daemon}.
@end deffn
@deffn {Scheme Procedure} xfce-desktop-service
Return a service that adds the @code{xfce} package to the system profile,
and extends polkit with the abilit for @code{thunar} to manipulate the
file system as root from within a user session, after the user has
authenticated with the administrator's password.
@end deffn
Because the GNOME and XFCE desktop services pull in so many packages,
the default @code{%desktop-services} variable doesn't include either of
them by default. To add GNOME or XFCE, just @code{cons} them onto
@code{%desktop-services} in the @code{services} field of your
@code{operating-system}:
@example
(use-modules (gnu))
(use-service-modules desktop)
(operating-system
...
;; cons* adds items to the list given as its last argument.
(services (cons* (gnome-desktop-service)
(xfce-desktop-service)
%desktop-services))
...)
@end example
These desktop environments will then be available as options in the
graphical login window.
The actual service definitions included in @code{%desktop-services} and
provided by @code{(gnu services dbus)} and @code{(gnu services desktop)}
are described below.
@deffn {Scheme Procedure} dbus-service [#:dbus @var{dbus}] [#:services '()]
Return a service that runs the ``system bus'', using @var{dbus}, with
support for @var{services}.
@uref{http://dbus.freedesktop.org/, D-Bus} is an inter-process communication
facility. Its system bus is used to allow system services to communicate
and to be notified of system-wide events.
@var{services} must be a list of packages that provide an
@file{etc/dbus-1/system.d} directory containing additional D-Bus configuration
and policy files. For example, to allow avahi-daemon to use the system bus,
@var{services} must be equal to @code{(list avahi)}.
@deffn {Scheme Procedure} elogind-service [#:config @var{config}]
Return a service that runs the @code{elogind} login and
seat management daemon. @uref{https://github.com/andywingo/elogind,
Elogind} exposes a D-Bus interface that can be used to know which users
are logged in, know what kind of sessions they have open, suspend the
system, inhibit system suspend, reboot the system, and other tasks.
Elogind handles most system-level power events for a computer, for
example suspending the system when a lid is closed, or shutting it down
when the power button is pressed.
The @var{config} keyword argument specifies the configuration for
elogind, and should be the result of an @code{(elogind-configuration
8090
8091
8092
8093
8094
8095
8096
8097
8098
8099
8100
8101
8102
8103
8104
8105
8106
8107
8108
8109
8110
8111
8112
8113
8114
8115
8116
8117
8118
8119
8120
8121
8122
8123
8124
8125
8126
8127
8128
8129
8130
8131
8132
8133
8134
8135
8136
8137
8138
8139
8140
8141
8142
8143
8144
8145
8146
(@var{parameter} @var{value})...)} invocation. Available parameters and
their default values are:
@table @code
@item kill-user-processes?
@code{#f}
@item kill-only-users
@code{()}
@item kill-exclude-users
@code{("root")}
@item inhibit-delay-max-seconds
@code{5}
@item handle-power-key
@code{poweroff}
@item handle-suspend-key
@code{suspend}
@item handle-hibernate-key
@code{hibernate}
@item handle-lid-switch
@code{suspend}
@item handle-lid-switch-docked
@code{ignore}
@item power-key-ignore-inhibited?
@code{#f}
@item suspend-key-ignore-inhibited?
@code{#f}
@item hibernate-key-ignore-inhibited?
@code{#f}
@item lid-switch-ignore-inhibited?
@code{#t}
@item holdoff-timeout-seconds
@code{30}
@item idle-action
@code{ignore}
@item idle-action-seconds
@code{(* 30 60)}
@item runtime-directory-size-percent
@code{10}
@item runtime-directory-size
@code{#f}
@item remove-ipc?
@code{#t}
@item suspend-state
@code{("mem" "standby" "freeze")}
@item suspend-mode
@code{()}
@item hibernate-state
@code{("disk")}
@item hibernate-mode
@code{("platform" "shutdown")}
@item hybrid-sleep-state
@code{("disk")}
@item hybrid-sleep-mode
@code{("suspend" "platform" "shutdown")}
@end table
@end deffn
@deffn {Scheme Procedure} polkit-service @
Return a service that runs the
@uref{http://www.freedesktop.org/wiki/Software/polkit/, Polkit privilege
management service}, which allows system administrators to grant access to
privileged operations in a structured way. By querying the Polkit service, a
privileged system component can know when it should grant additional
capabilities to ordinary users. For example, an ordinary user can be granted
the capability to suspend the system if the user is logged in locally.
@deffn {Scheme Procedure} upower-service [#:upower @var{upower}] @
[#:watts-up-pro? #f] @
[#:poll-batteries? #t] @
[#:ignore-lid? #f] @
[#:use-percentage-for-policy? #f] @
[#:percentage-low 10] @
[#:percentage-critical 3] @
[#:percentage-action 2] @
[#:time-low 1200] @
[#:time-critical 300] @
[#:time-action 120] @
[#:critical-power-action 'hybrid-sleep]
Return a service that runs @uref{http://upower.freedesktop.org/,
@command{upowerd}}, a system-wide monitor for power consumption and battery
levels, with the given configuration settings. It implements the
@code{org.freedesktop.UPower} D-Bus interface, and is notably used by
GNOME.
@end deffn
@deffn {Scheme Procedure} udisks-service [#:udisks @var{udisks}]
Return a service for @uref{http://udisks.freedesktop.org/docs/latest/,
UDisks}, a @dfn{disk management} daemon that provides user interfaces with
notifications and ways to mount/unmount disks. Programs that talk to UDisks
include the @command{udisksctl} command, part of UDisks, and GNOME Disks.
@end deffn
@deffn {Scheme Procedure} colord-service [#:colord @var{colord}]
Return a service that runs @command{colord}, a system service with a D-Bus
interface to manage the color profiles of input and output devices such as
screens and scanners. It is notably used by the GNOME Color Manager graphical
tool. See @uref{http://www.freedesktop.org/software/colord/, the colord web
site} for more information.
@end deffn
@deffn {Scheme Procedure} geoclue-application name [#:allowed? #t] [#:system? #f] [#:users '()]
Return a configuration allowing an application to access GeoClue
location data. @var{name} is the Desktop ID of the application, without
the @code{.desktop} part. If @var{allowed?} is true, the application
will have access to location information by default. The boolean
@var{system?} value indicates whether an application is a system component
or not. Finally @var{users} is a list of UIDs of all users for which
this application is allowed location info access. An empty users list
means that all users are allowed.
@end deffn
@defvr {Scheme Variable} %standard-geoclue-applications
The standard list of well-known GeoClue application configurations,
granting authority to the GNOME date-and-time utility to ask for the
current location in order to set the time zone, and allowing the
IceCat and Epiphany web browsers to request location information.
IceCat and Epiphany both query the user before allowing a web page to
know the user's location.
@end defvr
@deffn {Scheme Procedure} geoclue-service [#:colord @var{colord}] @
[#:whitelist '()] @
[#:wifi-geolocation-url "https://location.services.mozilla.com/v1/geolocate?key=geoclue"] @
[#:submit-data? #f]
[#:wifi-submission-url "https://location.services.mozilla.com/v1/submit?key=geoclue"] @
[#:submission-nick "geoclue"] @
[#:applications %standard-geoclue-applications]
Return a service that runs the GeoClue location service. This service
provides a D-Bus interface to allow applications to request access to a
user's physical location, and optionally to add information to online
location databases. See
@uref{https://wiki.freedesktop.org/www/Software/GeoClue/, the GeoClue
web site} for more information.
@end deffn
@deffn {Scheme Procedure} bluetooth-service [#:bluez @var{bluez}]
Return a service that runs the @command{bluetoothd} daemon, which manages
all the Bluetooth devices and provides a number of D-Bus interfaces.
Users need to be in the @code{lp} group to access the D-Bus service.
@end deffn
@node Database Services
@subsubsection Database Services
The @code{(gnu services databases)} module provides the following services.
@deffn {Scheme Procedure} postgresql-service [#:postgresql postgresql] @
[#:config-file] [#:data-directory ``/var/lib/postgresql/data'']
Return a service that runs @var{postgresql}, the PostgreSQL database
server.
The PostgreSQL daemon loads its runtime configuration from
@var{config-file} and stores the database cluster in
@var{data-directory}.
@end deffn
8249
8250
8251
8252
8253
8254
8255
8256
8257
8258
8259
8260
8261
8262
8263
8264
8265
8266
8267
8268
8269
@deffn {Scheme Procedure} mysql-service [#:config (mysql-configuration)]
Return a service that runs @command{mysqld}, the MySQL or MariaDB
database server.
The optional @var{config} argument specifies the configuration for
@command{mysqld}, which should be a @code{<mysql-configuraiton>} object.
@end deffn
@deftp {Data Type} mysql-configuration
Data type representing the configuration of @var{mysql-service}.
@table @asis
@item @code{mysql} (default: @var{mariadb})
Package object of the MySQL database server, can be either @var{mariadb}
or @var{mysql}.
For MySQL, a temorary root password will be displayed at activation time.
For MariaDB, the root password is empty.
@end table
@end deftp
@node Mail Services
@subsubsection Mail Services
The @code{(gnu services mail)} module provides Guix service definitions
for mail services. Currently the only implemented service is Dovecot,
an IMAP, POP3, and LMTP server.
Guix does not yet have a mail transfer agent (MTA), although for some
lightweight purposes the @code{esmtp} relay-only MTA may suffice. Help
is needed to properly integrate a full MTA, such as Postfix. Patches
welcome!
To add an IMAP/POP3 server to a GuixSD system, add a
@code{dovecot-service} to the operating system definition:
@deffn {Scheme Procedure} dovecot-service [#:config (dovecot-configuration)]
Return a service that runs the Dovecot IMAP/POP3/LMTP mail server.
@end deffn
By default, Dovecot does not need much configuration; the default
configuration object created by @code{(dovecot-configuration)} will
suffice if your mail is delivered to @code{~/Maildir}. A self-signed
certificate will be generated for TLS-protected connections, though
Dovecot will also listen on cleartext ports by default. There are a
number of options, though, which mail administrators might need to change,
8295
8296
8297
8298
8299
8300
8301
8302
8303
8304
8305
8306
8307
8308
8309
8310
8311
8312
8313
8314
8315
8316
8317
8318
8319
8320
8321
8322
8323
8324
8325
8326
8327
8328
and as is the case with other services, Guix allows the system
administrator to specify these parameters via a uniform Scheme interface.
For example, to specify that mail is located at @code{maildir~/.mail},
one would instantiate the Dovecot service like this:
@example
(dovecot-service #:config
(dovecot-configuration
(mail-location "maildir:~/.mail")))
@end example
The available configuration parameters follow. Each parameter
definition is preceded by its type; for example, @samp{string-list foo}
indicates that the @code{foo} parameter should be specified as a list of
strings. There is also a way to specify the configuration as a string,
if you have an old @code{dovecot.conf} file that you want to port over
from some other system; see the end for more details.
@c The following documentation was initially generated by
@c (generate-documentation) in (gnu services mail). Manually maintained
@c documentation is better, so we shouldn't hesitate to edit below as
@c needed. However if the change you want to make to this documentation
@c can be done in an automated way, it's probably easier to change
@c (generate-documentation) than to make it below and have to deal with
@c the churn as dovecot updates.
Available @code{dovecot-configuration} fields are:
@deftypevr {@code{dovecot-configuration} parameter} package dovecot
The dovecot package.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} comma-separated-string-list listen
A list of IPs or hosts where to listen for connections. @samp{*}
listens on all IPv4 interfaces, @samp{::} listens on all IPv6
interfaces. If you want to specify non-default ports or anything more
complex, customize the address and port fields of the
@samp{inet-listener} of the specific services you are interested in.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} protocol-configuration-list protocols
List of protocols we want to serve. Available protocols include
@samp{imap}, @samp{pop3}, and @samp{lmtp}.
Available @code{protocol-configuration} fields are:
@deftypevr {@code{protocol-configuration} parameter} string name
The name of the protocol.
@end deftypevr
@deftypevr {@code{protocol-configuration} parameter} string auth-socket-path
UNIX socket path to the master authentication server to find users.
It defaults to @samp{"/var/run/dovecot/auth-userdb"}.
8350
8351
8352
8353
8354
8355
8356
8357
8358
8359
8360
8361
8362
8363
8364
8365
8366
8367
8368
8369
8370
8371
8372
8373
8374
8375
8376
8377
8378
@end deftypevr
@deftypevr {@code{protocol-configuration} parameter} space-separated-string-list mail-plugins
Space separated list of plugins to load.
@end deftypevr
@deftypevr {@code{protocol-configuration} parameter} non-negative-integer mail-max-userip-connections
Maximum number of IMAP connections allowed for a user from each IP
address. NOTE: The username is compared case-sensitively.
Defaults to @samp{10}.
@end deftypevr
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} service-configuration-list services
List of services to enable. Available services include @samp{imap},
@samp{imap-login}, @samp{pop3}, @samp{pop3-login}, @samp{auth}, and
@samp{lmtp}.
Available @code{service-configuration} fields are:
@deftypevr {@code{service-configuration} parameter} string kind
The service kind. Valid values include @code{director},
@code{imap-login}, @code{pop3-login}, @code{lmtp}, @code{imap},
@code{pop3}, @code{auth}, @code{auth-worker}, @code{dict},
@code{tcpwrap}, @code{quota-warning}, or anything else.
@end deftypevr
@deftypevr {@code{service-configuration} parameter} listener-configuration-list listeners
Listeners for the service. A listener is either a
@code{unix-listener-configuration}, a @code{fifo-listener-configuration}, or
an @code{inet-listener-configuration}.
Defaults to @samp{()}.
Available @code{unix-listener-configuration} fields are:
@deftypevr {@code{unix-listener-configuration} parameter} file-name path
The file name on which to listen.
@end deftypevr
@deftypevr {@code{unix-listener-configuration} parameter} string mode
The access mode for the socket.
Defaults to @samp{"0600"}.
@end deftypevr
@deftypevr {@code{unix-listener-configuration} parameter} string user
8397
8398
8399
8400
8401
8402
8403
8404
8405
8406
8407
8408
8409
8410
8411
8412
8413
8414
8415
8416
8417
Defaults to @samp{""}.
@end deftypevr
@deftypevr {@code{unix-listener-configuration} parameter} string group
The group to own the socket.
Defaults to @samp{""}.
@end deftypevr
Available @code{fifo-listener-configuration} fields are:
@deftypevr {@code{fifo-listener-configuration} parameter} file-name path
The file name on which to listen.
@end deftypevr
@deftypevr {@code{fifo-listener-configuration} parameter} string mode
The access mode for the socket.
Defaults to @samp{"0600"}.
@end deftypevr
@deftypevr {@code{fifo-listener-configuration} parameter} string user
8419
8420
8421
8422
8423
8424
8425
8426
8427
8428
8429
8430
8431
8432
8433
8434
8435
8436
8437
8438
8439
8440
8441
8442
8443
8444
8445
8446
8447
8448
8449
8450
8451
8452
8453
8454
8455
8456
8457
8458
8459
8460
8461
8462
8463
8464
8465
8466
8467
8468
8469
8470
8471
8472
8473
8474
8475
8476
8477
8478
8479
8480
8481
8482
8483
8484
Defaults to @samp{""}.
@end deftypevr
@deftypevr {@code{fifo-listener-configuration} parameter} string group
The group to own the socket.
Defaults to @samp{""}.
@end deftypevr
Available @code{inet-listener-configuration} fields are:
@deftypevr {@code{inet-listener-configuration} parameter} string protocol
The protocol to listen for.
@end deftypevr
@deftypevr {@code{inet-listener-configuration} parameter} string address
The address on which to listen, or empty for all addresses.
Defaults to @samp{""}.
@end deftypevr
@deftypevr {@code{inet-listener-configuration} parameter} non-negative-integer port
The port on which to listen.
@end deftypevr
@deftypevr {@code{inet-listener-configuration} parameter} boolean ssl?
Whether to use SSL for this service; @samp{yes}, @samp{no}, or
@samp{required}.
Defaults to @samp{#t}.
@end deftypevr
@end deftypevr
@deftypevr {@code{service-configuration} parameter} non-negative-integer service-count
Number of connections to handle before starting a new process.
Typically the only useful values are 0 (unlimited) or 1. 1 is more
secure, but 0 is faster. <doc/wiki/LoginProcess.txt>.
Defaults to @samp{1}.
@end deftypevr
@deftypevr {@code{service-configuration} parameter} non-negative-integer process-min-avail
Number of processes to always keep waiting for more connections.
Defaults to @samp{0}.
@end deftypevr
@deftypevr {@code{service-configuration} parameter} non-negative-integer vsz-limit
If you set @samp{service-count 0}, you probably need to grow
this.
Defaults to @samp{256000000}.
@end deftypevr
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} dict-configuration dict
Dict configuration, as created by the @code{dict-configuration}
constructor.
Available @code{dict-configuration} fields are:
@deftypevr {@code{dict-configuration} parameter} free-form-fields entries
A list of key-value pairs that this dict should hold.
Defaults to @samp{()}.
@end deftypevr
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} passdb-configuration-list passdbs
A list of passdb configurations, each one created by the
8486
8487
8488
8489
8490
8491
8492
8493
8494
8495
8496
8497
8498
8499
8500
8501
8502
8503
8504
8505
8506
8507
8508
8509
8510
8511
8512
8513
8514
8515
8516
8517
8518
8519
8520
8521
8522
8523
8524
8525
8526
8527
8528
8529
8530
8531
8532
8533
8534
8535
8536
8537
8538
8539
8540
8541
8542
8543
8544
8545
8546
8547
8548
8549
8550
8551
8552
8553
8554
8555
8556
8557
8558
8559
8560
8561
8562
@code{passdb-configuration} constructor.
Available @code{passdb-configuration} fields are:
@deftypevr {@code{passdb-configuration} parameter} string driver
The driver that the passdb should use. Valid values include
@samp{pam}, @samp{passwd}, @samp{shadow}, @samp{bsdauth}, and
@samp{static}.
Defaults to @samp{"pam"}.
@end deftypevr
@deftypevr {@code{passdb-configuration} parameter} free-form-args args
A list of key-value args to the passdb driver.
Defaults to @samp{()}.
@end deftypevr
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} userdb-configuration-list userdbs
List of userdb configurations, each one created by the
@code{userdb-configuration} constructor.
Available @code{userdb-configuration} fields are:
@deftypevr {@code{userdb-configuration} parameter} string driver
The driver that the userdb should use. Valid values include
@samp{passwd} and @samp{static}.
Defaults to @samp{"passwd"}.
@end deftypevr
@deftypevr {@code{userdb-configuration} parameter} free-form-args args
A list of key-value args to the userdb driver.
Defaults to @samp{()}.
@end deftypevr
@deftypevr {@code{userdb-configuration} parameter} free-form-args override-fields
Override fields from passwd.
Defaults to @samp{()}.
@end deftypevr
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} plugin-configuration plugin-configuration
Plug-in configuration, created by the @code{plugin-configuration}
constructor.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} list-of-namespace-configuration namespaces
List of namespaces. Each item in the list is created by the
@code{namespace-configuration} constructor.
Available @code{namespace-configuration} fields are:
@deftypevr {@code{namespace-configuration} parameter} string name
Name for this namespace.
@end deftypevr
@deftypevr {@code{namespace-configuration} parameter} string type
Namespace type: @samp{private}, @samp{shared} or @samp{public}.
Defaults to @samp{"private"}.
@end deftypevr
@deftypevr {@code{namespace-configuration} parameter} string separator
Hierarchy separator to use. You should use the same separator for
all namespaces or some clients get confused. @samp{/} is usually a good
one. The default however depends on the underlying mail storage
format.
Defaults to @samp{""}.
@end deftypevr
@deftypevr {@code{namespace-configuration} parameter} string prefix
Prefix required to access this namespace. This needs to be
different for all namespaces. For example @samp{Public/}.
Defaults to @samp{""}.
@end deftypevr
@deftypevr {@code{namespace-configuration} parameter} string location
Physical location of the mailbox. This is in the same format as
8564
8565
8566
8567
8568
8569
8570
8571
8572
8573
8574
8575
8576
8577
8578
8579
8580
8581
8582
8583
8584
mail_location, which is also the default for it.
Defaults to @samp{""}.
@end deftypevr
@deftypevr {@code{namespace-configuration} parameter} boolean inbox?
There can be only one INBOX, and this setting defines which
namespace has it.
Defaults to @samp{#f}.
@end deftypevr
@deftypevr {@code{namespace-configuration} parameter} boolean hidden?
If namespace is hidden, it's not advertised to clients via NAMESPACE
extension. You'll most likely also want to set @samp{list? #f}. This is mostly
useful when converting from another server with different namespaces
which you want to deprecate but still keep working. For example you can
create hidden namespaces with prefixes @samp{~/mail/}, @samp{~%u/mail/}
and @samp{mail/}.
Defaults to @samp{#f}.
@end deftypevr
@deftypevr {@code{namespace-configuration} parameter} boolean list?
Show the mailboxes under this namespace with the LIST command. This
makes the namespace visible for clients that do not support the NAMESPACE
extension. The special @code{children} value lists child mailboxes, but
hides the namespace prefix.
Defaults to @samp{#t}.
@end deftypevr
@deftypevr {@code{namespace-configuration} parameter} boolean subscriptions?
Namespace handles its own subscriptions. If set to @code{#f}, the
parent namespace handles them. The empty prefix should always have this
8596
8597
8598
8599
8600
8601
8602
8603
8604
8605
8606
8607
8608
8609
8610
8611
8612
8613
8614
8615
8616
8617
8618
8619
8620
8621
8622
8623
8624
8625
8626
8627
8628
8629
8630
8631
8632
8633
8634
8635
8636
8637
8638
8639
Defaults to @samp{#t}.
@end deftypevr
@deftypevr {@code{namespace-configuration} parameter} mailbox-configuration-list mailboxes
List of predefined mailboxes in this namespace.
Defaults to @samp{()}.
Available @code{mailbox-configuration} fields are:
@deftypevr {@code{mailbox-configuration} parameter} string name
Name for this mailbox.
@end deftypevr
@deftypevr {@code{mailbox-configuration} parameter} string auto
@samp{create} will automatically create this mailbox.
@samp{subscribe} will both create and subscribe to the mailbox.
Defaults to @samp{"no"}.
@end deftypevr
@deftypevr {@code{mailbox-configuration} parameter} space-separated-string-list special-use
List of IMAP @code{SPECIAL-USE} attributes as specified by RFC 6154.
Valid values are @code{\All}, @code{\Archive}, @code{\Drafts},
@code{\Flagged}, @code{\Junk}, @code{\Sent}, and @code{\Trash}.
Defaults to @samp{()}.
@end deftypevr
@end deftypevr
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} file-name base-dir
Base directory where to store runtime data.
Defaults to @samp{"/var/run/dovecot/"}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} string login-greeting
Greeting message for clients.
Defaults to @samp{"Dovecot ready."}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} space-separated-string-list login-trusted-networks
List of trusted network ranges. Connections from these IPs are
allowed to override their IP addresses and ports (for logging and for
authentication checks). @samp{disable-plaintext-auth} is also ignored
for these networks. Typically you would specify your IMAP proxy servers
here.
Defaults to @samp{()}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} space-separated-string-list login-access-sockets
List of login access check sockets (e.g. tcpwrap).
Defaults to @samp{()}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} boolean verbose-proctitle?
Show more verbose process titles (in ps). Currently shows user name
and IP address. Useful for seeing who is actually using the IMAP
processes (e.g. shared mailboxes or if the same uid is used for multiple
accounts).
Defaults to @samp{#f}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} boolean shutdown-clients?
Should all processes be killed when Dovecot master process shuts down.
Setting this to @code{#f} means that Dovecot can be upgraded without
forcing existing client connections to close (although that could also
be a problem if the upgrade is e.g. due to a security fix).
8663
8664
8665
8666
8667
8668
8669
8670
8671
8672
8673
8674
8675
8676
8677
8678
8679
8680
8681
8682
8683
8684
8685
8686
8687
8688
8689
8690
8691
8692
8693
8694
8695
8696
8697
8698
8699
8700
8701
8702
8703
8704
8705
8706
8707
8708
8709
8710
8711
8712
8713
8714
8715
8716
8717
8718
8719
8720
8721
8722
8723
8724
8725
8726
8727
8728
8729
8730
8731
8732
8733
8734
8735
8736
8737
8738
8739
8740
8741
8742
8743
8744
8745
8746
8747
8748
8749
8750
8751
8752
8753
8754
8755
8756
8757
8758
8759
8760
8761
8762
8763
8764
8765
8766
8767
8768
8769
8770
8771
8772
8773
8774
8775
8776
8777
8778
8779
8780
8781
8782
8783
8784
8785
8786
8787
8788
8789
8790
8791
8792
8793
8794
8795
8796
8797
8798
8799
8800
8801
8802
8803
8804
8805
8806
8807
8808
8809
8810
8811
8812
8813
8814
8815
8816
8817
8818
8819
8820
8821
8822
8823
8824
8825
8826
8827
8828
8829
8830
8831
8832
8833
8834
8835
8836
8837
8838
8839
8840
8841
8842
8843
8844
8845
8846
8847
8848
8849
8850
8851
8852
8853
8854
8855
8856
8857
8858
8859
8860
8861
8862
8863
8864
8865
8866
8867
8868
8869
8870
8871
8872
8873
8874
8875
8876
8877
8878
8879
8880
8881
8882
8883
8884
8885
8886
8887
8888
8889
8890
8891
8892
8893
8894
8895
8896
8897
8898
8899
8900
8901
8902
8903
8904
8905
8906
8907
8908
8909
8910
8911
8912
8913
8914
8915
8916
8917
8918
8919
8920
8921
8922
8923
8924
8925
8926
8927
8928
8929
8930
8931
8932
8933
8934
8935
8936
8937
8938
8939
8940
8941
8942
8943
8944
8945
8946
8947
8948
8949
8950
8951
8952
8953
8954
8955
8956
8957
8958
8959
8960
8961
8962
8963
8964
8965
8966
8967
8968
8969
8970
8971
8972
8973
8974
8975
8976
8977
8978
8979
8980
8981
8982
8983
8984
8985
8986
8987
8988
8989
8990
8991
8992
8993
8994
8995
8996
8997
8998
8999
9000
9001
9002
9003
9004
9005
9006
9007
9008
9009
9010
9011
9012
9013
9014
9015
9016
9017
9018
9019
9020
9021
9022
9023
9024
9025
9026
9027
9028
9029
9030
9031
9032
9033
9034
9035
9036
9037
9038
9039
9040
9041
9042
9043
9044
9045
9046
9047
9048
9049
9050
9051
9052
9053
9054
9055
9056
9057
9058
9059
9060
9061
9062
9063
9064
9065
9066
9067
9068
9069
9070
9071
9072
9073
9074
9075
9076
9077
9078
9079
9080
9081
9082
9083
9084
9085
9086
9087
9088
9089
9090
9091
9092
9093
9094
9095
9096
9097
9098
9099
9100
9101
9102
9103
9104
9105
9106
9107
9108
9109
9110
9111
9112
9113
9114
9115
9116
9117
9118
9119
9120
9121
9122
9123
9124
9125
9126
9127
9128
9129
9130
9131
9132
9133
9134
9135
9136
9137
9138
9139
9140
9141
9142
9143
9144
9145
9146
9147
9148
9149
9150
9151
9152
9153
9154
9155
9156
9157
9158
9159
9160
9161
9162
9163
9164
9165
9166
9167
9168
9169
9170
9171
9172
9173
9174
9175
9176
9177
9178
9179
9180
9181
9182
9183
9184
9185
9186
9187
9188
9189
9190
9191
9192
9193
9194
9195
9196
9197
9198
9199
9200
9201
9202
9203
9204
9205
9206
9207
9208
9209
9210
9211
9212
9213
9214
9215
9216
9217
9218
9219
9220
9221
9222
9223
9224
9225
9226
9227
9228
9229
9230
9231
Defaults to @samp{#t}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} non-negative-integer doveadm-worker-count
If non-zero, run mail commands via this many connections to doveadm
server, instead of running them directly in the same process.
Defaults to @samp{0}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} string doveadm-socket-path
UNIX socket or host:port used for connecting to doveadm server.
Defaults to @samp{"doveadm-server"}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} space-separated-string-list import-environment
List of environment variables that are preserved on Dovecot startup
and passed down to all of its child processes. You can also give
key=value pairs to always set specific settings.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} boolean disable-plaintext-auth?
Disable LOGIN command and all other plaintext authentications unless
SSL/TLS is used (LOGINDISABLED capability). Note that if the remote IP
matches the local IP (i.e. you're connecting from the same computer),
the connection is considered secure and plaintext authentication is
allowed. See also ssl=required setting.
Defaults to @samp{#t}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} non-negative-integer auth-cache-size
Authentication cache size (e.g. @samp{#e10e6}). 0 means it's disabled.
Note that bsdauth, PAM and vpopmail require @samp{cache-key} to be set
for caching to be used.
Defaults to @samp{0}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} string auth-cache-ttl
Time to live for cached data. After TTL expires the cached record
is no longer used, *except* if the main database lookup returns internal
failure. We also try to handle password changes automatically: If
user's previous authentication was successful, but this one wasn't, the
cache isn't used. For now this works only with plaintext
authentication.
Defaults to @samp{"1 hour"}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} string auth-cache-negative-ttl
TTL for negative hits (user not found, password mismatch).
0 disables caching them completely.
Defaults to @samp{"1 hour"}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} space-separated-string-list auth-realms
List of realms for SASL authentication mechanisms that need them.
You can leave it empty if you don't want to support multiple realms.
Many clients simply use the first one listed here, so keep the default
realm first.
Defaults to @samp{()}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} string auth-default-realm
Default realm/domain to use if none was specified. This is used for
both SASL realms and appending @@domain to username in plaintext
logins.
Defaults to @samp{""}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} string auth-username-chars
List of allowed characters in username. If the user-given username
contains a character not listed in here, the login automatically fails.
This is just an extra check to make sure user can't exploit any
potential quote escaping vulnerabilities with SQL/LDAP databases. If
you want to allow all characters, set this value to empty.
Defaults to @samp{"abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890.-_@@"}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} string auth-username-translation
Username character translations before it's looked up from
databases. The value contains series of from -> to characters. For
example @samp{#@@/@@} means that @samp{#} and @samp{/} characters are
translated to @samp{@@}.
Defaults to @samp{""}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} string auth-username-format
Username formatting before it's looked up from databases. You can
use the standard variables here, e.g. %Lu would lowercase the username,
%n would drop away the domain if it was given, or @samp{%n-AT-%d} would
change the @samp{@@} into @samp{-AT-}. This translation is done after
@samp{auth-username-translation} changes.
Defaults to @samp{"%Lu"}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} string auth-master-user-separator
If you want to allow master users to log in by specifying the master
username within the normal username string (i.e. not using SASL
mechanism's support for it), you can specify the separator character
here. The format is then <username><separator><master username>.
UW-IMAP uses @samp{*} as the separator, so that could be a good
choice.
Defaults to @samp{""}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} string auth-anonymous-username
Username to use for users logging in with ANONYMOUS SASL
mechanism.
Defaults to @samp{"anonymous"}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} non-negative-integer auth-worker-max-count
Maximum number of dovecot-auth worker processes. They're used to
execute blocking passdb and userdb queries (e.g. MySQL and PAM).
They're automatically created and destroyed as needed.
Defaults to @samp{30}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} string auth-gssapi-hostname
Host name to use in GSSAPI principal names. The default is to use
the name returned by gethostname(). Use @samp{$ALL} (with quotes) to
allow all keytab entries.
Defaults to @samp{""}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} string auth-krb5-keytab
Kerberos keytab to use for the GSSAPI mechanism. Will use the
system default (usually /etc/krb5.keytab) if not specified. You may
need to change the auth service to run as root to be able to read this
file.
Defaults to @samp{""}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} boolean auth-use-winbind?
Do NTLM and GSS-SPNEGO authentication using Samba's winbind daemon
and @samp{ntlm-auth} helper.
<doc/wiki/Authentication/Mechanisms/Winbind.txt>.
Defaults to @samp{#f}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} file-name auth-winbind-helper-path
Path for Samba's @samp{ntlm-auth} helper binary.
Defaults to @samp{"/usr/bin/ntlm_auth"}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} string auth-failure-delay
Time to delay before replying to failed authentications.
Defaults to @samp{"2 secs"}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} boolean auth-ssl-require-client-cert?
Require a valid SSL client certificate or the authentication
fails.
Defaults to @samp{#f}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} boolean auth-ssl-username-from-cert?
Take the username from client's SSL certificate, using
@code{X509_NAME_get_text_by_NID()} which returns the subject's DN's
CommonName.
Defaults to @samp{#f}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} space-separated-string-list auth-mechanisms
List of wanted authentication mechanisms. Supported mechanisms are:
@samp{plain}, @samp{login}, @samp{digest-md5}, @samp{cram-md5},
@samp{ntlm}, @samp{rpa}, @samp{apop}, @samp{anonymous}, @samp{gssapi},
@samp{otp}, @samp{skey}, and @samp{gss-spnego}. NOTE: See also
@samp{disable-plaintext-auth} setting.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} space-separated-string-list director-servers
List of IPs or hostnames to all director servers, including ourself.
Ports can be specified as ip:port. The default port is the same as what
director service's @samp{inet-listener} is using.
Defaults to @samp{()}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} space-separated-string-list director-mail-servers
List of IPs or hostnames to all backend mail servers. Ranges are
allowed too, like 10.0.0.10-10.0.0.30.
Defaults to @samp{()}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} string director-user-expire
How long to redirect users to a specific server after it no longer
has any connections.
Defaults to @samp{"15 min"}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} non-negative-integer director-doveadm-port
TCP/IP port that accepts doveadm connections (instead of director
connections) If you enable this, you'll also need to add
@samp{inet-listener} for the port.
Defaults to @samp{0}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} string director-username-hash
How the username is translated before being hashed. Useful values
include %Ln if user can log in with or without @@domain, %Ld if mailboxes
are shared within domain.
Defaults to @samp{"%Lu"}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} string log-path
Log file to use for error messages. @samp{syslog} logs to syslog,
@samp{/dev/stderr} logs to stderr.
Defaults to @samp{"syslog"}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} string info-log-path
Log file to use for informational messages. Defaults to
@samp{log-path}.
Defaults to @samp{""}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} string debug-log-path
Log file to use for debug messages. Defaults to
@samp{info-log-path}.
Defaults to @samp{""}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} string syslog-facility
Syslog facility to use if you're logging to syslog. Usually if you
don't want to use @samp{mail}, you'll use local0..local7. Also other
standard facilities are supported.
Defaults to @samp{"mail"}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} boolean auth-verbose?
Log unsuccessful authentication attempts and the reasons why they
failed.
Defaults to @samp{#f}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} boolean auth-verbose-passwords?
In case of password mismatches, log the attempted password. Valid
values are no, plain and sha1. sha1 can be useful for detecting brute
force password attempts vs. user simply trying the same password over
and over again. You can also truncate the value to n chars by appending
":n" (e.g. sha1:6).
Defaults to @samp{#f}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} boolean auth-debug?
Even more verbose logging for debugging purposes. Shows for example
SQL queries.
Defaults to @samp{#f}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} boolean auth-debug-passwords?
In case of password mismatches, log the passwords and used scheme so
the problem can be debugged. Enabling this also enables
@samp{auth-debug}.
Defaults to @samp{#f}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} boolean mail-debug?
Enable mail process debugging. This can help you figure out why
Dovecot isn't finding your mails.
Defaults to @samp{#f}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} boolean verbose-ssl?
Show protocol level SSL errors.
Defaults to @samp{#f}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} string log-timestamp
Prefix for each line written to log file. % codes are in
strftime(3) format.
Defaults to @samp{"\"%b %d %H:%M:%S \""}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} space-separated-string-list login-log-format-elements
List of elements we want to log. The elements which have a
non-empty variable value are joined together to form a comma-separated
string.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} string login-log-format
Login log format. %s contains @samp{login-log-format-elements}
string, %$ contains the data we want to log.
Defaults to @samp{"%$: %s"}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} string mail-log-prefix
Log prefix for mail processes. See doc/wiki/Variables.txt for list
of possible variables you can use.
Defaults to @samp{"\"%s(%u): \""}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} string deliver-log-format
Format to use for logging mail deliveries. You can use variables:
@table @code
@item %$
Delivery status message (e.g. @samp{saved to INBOX})
@item %m
Message-ID
@item %s
Subject
@item %f
From address
@item %p
Physical size
@item %w
Virtual size.
@end table
Defaults to @samp{"msgid=%m: %$"}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} string mail-location
Location for users' mailboxes. The default is empty, which means
that Dovecot tries to find the mailboxes automatically. This won't work
if the user doesn't yet have any mail, so you should explicitly tell
Dovecot the full location.
If you're using mbox, giving a path to the INBOX
file (e.g. /var/mail/%u) isn't enough. You'll also need to tell Dovecot
where the other mailboxes are kept. This is called the "root mail
directory", and it must be the first path given in the
@samp{mail-location} setting.
There are a few special variables you can use, eg.:
@table @samp
@item %u
username
@item %n
user part in user@@domain, same as %u if there's no domain
@item %d
domain part in user@@domain, empty if there's no domain
@item %h
home director
@end table
See doc/wiki/Variables.txt for full list. Some examples:
@table @samp
@item maildir:~/Maildir
@item mbox:~/mail:INBOX=/var/mail/%u
@item mbox:/var/mail/%d/%1n/%n:INDEX=/var/indexes/%d/%1n/%
@end table
Defaults to @samp{""}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} string mail-uid
System user and group used to access mails. If you use multiple,
userdb can override these by returning uid or gid fields. You can use
either numbers or names. <doc/wiki/UserIds.txt>.
Defaults to @samp{""}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} string mail-gid
Defaults to @samp{""}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} string mail-privileged-group
Group to enable temporarily for privileged operations. Currently
this is used only with INBOX when either its initial creation or
dotlocking fails. Typically this is set to "mail" to give access to
/var/mail.
Defaults to @samp{""}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} string mail-access-groups
Grant access to these supplementary groups for mail processes.
Typically these are used to set up access to shared mailboxes. Note
that it may be dangerous to set these if users can create
symlinks (e.g. if "mail" group is set here, ln -s /var/mail ~/mail/var
could allow a user to delete others' mailboxes, or ln -s
/secret/shared/box ~/mail/mybox would allow reading it).
Defaults to @samp{""}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} boolean mail-full-filesystem-access?
Allow full filesystem access to clients. There's no access checks
other than what the operating system does for the active UID/GID. It
works with both maildir and mboxes, allowing you to prefix mailboxes
names with e.g. /path/ or ~user/.
Defaults to @samp{#f}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} boolean mmap-disable?
Don't use mmap() at all. This is required if you store indexes to
shared filesystems (NFS or clustered filesystem).
Defaults to @samp{#f}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} boolean dotlock-use-excl?
Rely on @samp{O_EXCL} to work when creating dotlock files. NFS
supports @samp{O_EXCL} since version 3, so this should be safe to use
nowadays by default.
Defaults to @samp{#t}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} string mail-fsync
When to use fsync() or fdatasync() calls:
@table @code
@item optimized
Whenever necessary to avoid losing important data
@item always
Useful with e.g. NFS when write()s are delayed
@item never
Never use it (best performance, but crashes can lose data).
@end table
Defaults to @samp{"optimized"}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} boolean mail-nfs-storage?
Mail storage exists in NFS. Set this to yes to make Dovecot flush
NFS caches whenever needed. If you're using only a single mail server
this isn't needed.
Defaults to @samp{#f}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} boolean mail-nfs-index?
Mail index files also exist in NFS. Setting this to yes requires
@samp{mmap-disable? #t} and @samp{fsync-disable? #f}.
Defaults to @samp{#f}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} string lock-method
Locking method for index files. Alternatives are fcntl, flock and
dotlock. Dotlocking uses some tricks which may create more disk I/O
than other locking methods. NFS users: flock doesn't work, remember to
change @samp{mmap-disable}.
Defaults to @samp{"fcntl"}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} file-name mail-temp-dir
Directory in which LDA/LMTP temporarily stores incoming mails >128
kB.
Defaults to @samp{"/tmp"}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} non-negative-integer first-valid-uid
Valid UID range for users. This is mostly to make sure that users can't
log in as daemons or other system users. Note that denying root logins is
hardcoded to dovecot binary and can't be done even if @samp{first-valid-uid}
is set to 0.
Defaults to @samp{500}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} non-negative-integer last-valid-uid
Defaults to @samp{0}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} non-negative-integer first-valid-gid
Valid GID range for users. Users having non-valid GID as primary group ID
aren't allowed to log in. If user belongs to supplementary groups with
non-valid GIDs, those groups are not set.
Defaults to @samp{1}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} non-negative-integer last-valid-gid
Defaults to @samp{0}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} non-negative-integer mail-max-keyword-length
Maximum allowed length for mail keyword name. It's only forced when
trying to create new keywords.
Defaults to @samp{50}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} colon-separated-file-name-list valid-chroot-dirs
List of directories under which chrooting is allowed for mail
processes (i.e. /var/mail will allow chrooting to /var/mail/foo/bar
too). This setting doesn't affect @samp{login-chroot}
@samp{mail-chroot} or auth chroot settings. If this setting is empty,
"/./" in home dirs are ignored. WARNING: Never add directories here
which local users can modify, that may lead to root exploit. Usually
this should be done only if you don't allow shell access for users.
<doc/wiki/Chrooting.txt>.
Defaults to @samp{()}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} string mail-chroot
Default chroot directory for mail processes. This can be overridden
for specific users in user database by giving /./ in user's home
directory (e.g. /home/./user chroots into /home). Note that usually
there is no real need to do chrooting, Dovecot doesn't allow users to
access files outside their mail directory anyway. If your home
directories are prefixed with the chroot directory, append "/." to
@samp{mail-chroot}. <doc/wiki/Chrooting.txt>.
Defaults to @samp{""}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} file-name auth-socket-path
UNIX socket path to master authentication server to find users.
This is used by imap (for shared users) and lda.
Defaults to @samp{"/var/run/dovecot/auth-userdb"}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} file-name mail-plugin-dir
Directory where to look up mail plugins.
Defaults to @samp{"/usr/lib/dovecot"}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} space-separated-string-list mail-plugins
List of plugins to load for all services. Plugins specific to IMAP,
LDA, etc. are added to this list in their own .conf files.
Defaults to @samp{()}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} non-negative-integer mail-cache-min-mail-count
The minimum number of mails in a mailbox before updates are done to
cache file. This allows optimizing Dovecot's behavior to do less disk
writes at the cost of more disk reads.
Defaults to @samp{0}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} string mailbox-idle-check-interval
When IDLE command is running, mailbox is checked once in a while to
see if there are any new mails or other changes. This setting defines
the minimum time to wait between those checks. Dovecot can also use
dnotify, inotify and kqueue to find out immediately when changes
occur.
Defaults to @samp{"30 secs"}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} boolean mail-save-crlf?
Save mails with CR+LF instead of plain LF. This makes sending those
mails take less CPU, especially with sendfile() syscall with Linux and
FreeBSD. But it also creates a bit more disk I/O which may just make it
slower. Also note that if other software reads the mboxes/maildirs,
they may handle the extra CRs wrong and cause problems.
Defaults to @samp{#f}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} boolean maildir-stat-dirs?
By default LIST command returns all entries in maildir beginning
with a dot. Enabling this option makes Dovecot return only entries
which are directories. This is done by stat()ing each entry, so it
causes more disk I/O.
(For systems setting struct @samp{dirent->d_type} this check is free
and it's done always regardless of this setting).
Defaults to @samp{#f}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} boolean maildir-copy-with-hardlinks?
When copying a message, do it with hard links whenever possible.
This makes the performance much better, and it's unlikely to have any
side effects.
Defaults to @samp{#t}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} boolean maildir-very-dirty-syncs?
Assume Dovecot is the only MUA accessing Maildir: Scan cur/
directory only when its mtime changes unexpectedly or when we can't find
the mail otherwise.
Defaults to @samp{#f}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} space-separated-string-list mbox-read-locks
Which locking methods to use for locking mbox. There are four
available:
@table @code
@item dotlock
Create <mailbox>.lock file. This is the oldest and most NFS-safe
solution. If you want to use /var/mail/ like directory, the users will
need write access to that directory.
@item dotlock-try
Same as dotlock, but if it fails because of permissions or because there
isn't enough disk space, just skip it.
@item fcntl
Use this if possible. Works with NFS too if lockd is used.
@item flock
May not exist in all systems. Doesn't work with NFS.
9233
9234
9235
9236
9237
9238
9239
9240
9241
9242
9243
9244
9245
9246
9247
9248
9249
9250
9251
9252
9253
9254
9255
9256
9257
9258
9259
9260
9261
9262
9263
9264
9265
9266
9267
9268
9269
9270
9271
9272
9273
9274
9275
9276
9277
9278
9279
9280
9281
9282
9283
9284
9285
9286
9287
9288
9289
9290
9291
9292
9293
9294
9295
9296
9297
9298
9299
9300
9301
9302
9303
9304
9305
9306
9307
9308
9309
9310
9311
9312
9313
9314
9315
9316
9317
9318
9319
9320
9321
9322
9323
9324
9325
9326
9327
9328
9329
9330
9331
9332
9333
9334
9335
9336
9337
9338
9339
9340
9341
9342
9343
9344
9345
9346
9347
9348
9349
9350
9351
9352
9353
9354
9355
9356
9357
9358
9359
9360
9361
9362
9363
9364
9365
9366
9367
9368
9369
9370
9371
9372
9373
9374
9375
9376
9377
9378
9379
9380
9381
9382
9383
9384
9385
9386
9387
9388
9389
9390
9391
9392
9393
9394
9395
9396
9397
9398
9399
9400
9401
9402
9403
9404
9405
9406
9407
9408
9409
9410
9411
9412
9413
9414
9415
9416
9417
9418
9419
9420
9421
9422
9423
9424
9425
9426
9427
9428
9429
9430
9431
9432
9433
9434
9435
9436
9437
9438
9439
9440
9441
9442
9443
9444
9445
9446
9447
9448
9449
9450
9451
9452
9453
9454
9455
9456
9457
9458
9459
9460
9461
9462
9463
9464
9465
9466
9467
9468
9469
9470
9471
9472
9473
9474
9475
9476
9477
9478
9479
9480
9481
9482
9483
9484
9485
9486
9487
9488
9489
9490
9491
9492
9493
9494
9495
9496
9497
9498
9499
9500
9501
9502
9503
9504
9505
9506
9507
9508
9509
9510
9511
9512
9513
9514
9515
9516
9517
9518
9519
9520
9521
9522
9523
9524
9525
9526
9527
9528
9529
9530
9531
9532
9533
9534
9535
9536
9537
9538
9539
9540
9541
9542
9543
9544
9545
9546
9547
9548
9549
9550
9551
9552
9553
9554
9555
9556
9557
9558
9559
9560
9561
9562
9563
9564
9565
9566
9567
9568
9569
9570
9571
9572
9573
9574
9575
9576
9577
9578
9579
9580
9581
9582
9583
9584
9585
9586
9587
9588
9589
9590
9591
9592
9593
9594
9595
9596
9597
9598
9599
9600
9601
9602
9603
9604
9605
9606
9607
9608
9609
9610
9611
9612
9613
9614
9615
9616
9617
9618
9619
9620
9621
9622
9623
9624
9625
9626
9627
9628
9629
9630
9631
9632
9633
9634
9635
9636
9637
9638
@item lockf
May not exist in all systems. Doesn't work with NFS.
@end table
You can use multiple locking methods; if you do the order they're declared
in is important to avoid deadlocks if other MTAs/MUAs are using multiple
locking methods as well. Some operating systems don't allow using some of
them simultaneously.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} space-separated-string-list mbox-write-locks
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} string mbox-lock-timeout
Maximum time to wait for lock (all of them) before aborting.
Defaults to @samp{"5 mins"}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} string mbox-dotlock-change-timeout
If dotlock exists but the mailbox isn't modified in any way,
override the lock file after this much time.
Defaults to @samp{"2 mins"}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} boolean mbox-dirty-syncs?
When mbox changes unexpectedly we have to fully read it to find out
what changed. If the mbox is large this can take a long time. Since
the change is usually just a newly appended mail, it'd be faster to
simply read the new mails. If this setting is enabled, Dovecot does
this but still safely fallbacks to re-reading the whole mbox file
whenever something in mbox isn't how it's expected to be. The only real
downside to this setting is that if some other MUA changes message
flags, Dovecot doesn't notice it immediately. Note that a full sync is
done with SELECT, EXAMINE, EXPUNGE and CHECK commands.
Defaults to @samp{#t}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} boolean mbox-very-dirty-syncs?
Like @samp{mbox-dirty-syncs}, but don't do full syncs even with SELECT,
EXAMINE, EXPUNGE or CHECK commands. If this is set,
@samp{mbox-dirty-syncs} is ignored.
Defaults to @samp{#f}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} boolean mbox-lazy-writes?
Delay writing mbox headers until doing a full write sync (EXPUNGE
and CHECK commands and when closing the mailbox). This is especially
useful for POP3 where clients often delete all mails. The downside is
that our changes aren't immediately visible to other MUAs.
Defaults to @samp{#t}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} non-negative-integer mbox-min-index-size
If mbox size is smaller than this (e.g. 100k), don't write index
files. If an index file already exists it's still read, just not
updated.
Defaults to @samp{0}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} non-negative-integer mdbox-rotate-size
Maximum dbox file size until it's rotated.
Defaults to @samp{2000000}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} string mdbox-rotate-interval
Maximum dbox file age until it's rotated. Typically in days. Day
begins from midnight, so 1d = today, 2d = yesterday, etc. 0 = check
disabled.
Defaults to @samp{"1d"}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} boolean mdbox-preallocate-space?
When creating new mdbox files, immediately preallocate their size to
@samp{mdbox-rotate-size}. This setting currently works only in Linux
with some filesystems (ext4, xfs).
Defaults to @samp{#f}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} string mail-attachment-dir
sdbox and mdbox support saving mail attachments to external files,
which also allows single instance storage for them. Other backends
don't support this for now.
WARNING: This feature hasn't been tested much yet. Use at your own risk.
Directory root where to store mail attachments. Disabled, if empty.
Defaults to @samp{""}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} non-negative-integer mail-attachment-min-size
Attachments smaller than this aren't saved externally. It's also
possible to write a plugin to disable saving specific attachments
externally.
Defaults to @samp{128000}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} string mail-attachment-fs
Filesystem backend to use for saving attachments:
@table @code
@item posix
No SiS done by Dovecot (but this might help FS's own deduplication)
@item sis posix
SiS with immediate byte-by-byte comparison during saving
@item sis-queue posix
SiS with delayed comparison and deduplication.
@end table
Defaults to @samp{"sis posix"}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} string mail-attachment-hash
Hash format to use in attachment filenames. You can add any text and
variables: @code{%@{md4@}}, @code{%@{md5@}}, @code{%@{sha1@}},
@code{%@{sha256@}}, @code{%@{sha512@}}, @code{%@{size@}}. Variables can be
truncated, e.g. @code{%@{sha256:80@}} returns only first 80 bits.
Defaults to @samp{"%@{sha1@}"}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} non-negative-integer default-process-limit
Defaults to @samp{100}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} non-negative-integer default-client-limit
Defaults to @samp{1000}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} non-negative-integer default-vsz-limit
Default VSZ (virtual memory size) limit for service processes.
This is mainly intended to catch and kill processes that leak memory
before they eat up everything.
Defaults to @samp{256000000}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} string default-login-user
Login user is internally used by login processes. This is the most
untrusted user in Dovecot system. It shouldn't have access to anything
at all.
Defaults to @samp{"dovenull"}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} string default-internal-user
Internal user is used by unprivileged processes. It should be
separate from login user, so that login processes can't disturb other
processes.
Defaults to @samp{"dovecot"}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} string ssl?
SSL/TLS support: yes, no, required. <doc/wiki/SSL.txt>.
Defaults to @samp{"required"}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} string ssl-cert
PEM encoded X.509 SSL/TLS certificate (public key).
Defaults to @samp{"</etc/dovecot/default.pem"}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} string ssl-key
PEM encoded SSL/TLS private key. The key is opened before
dropping root privileges, so keep the key file unreadable by anyone but
root.
Defaults to @samp{"</etc/dovecot/private/default.pem"}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} string ssl-key-password
If key file is password protected, give the password here.
Alternatively give it when starting dovecot with -p parameter. Since
this file is often world-readable, you may want to place this setting
instead to a different.
Defaults to @samp{""}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} string ssl-ca
PEM encoded trusted certificate authority. Set this only if you
intend to use @samp{ssl-verify-client-cert? #t}. The file should
contain the CA certificate(s) followed by the matching
CRL(s). (e.g. @samp{ssl-ca </etc/ssl/certs/ca.pem}).
Defaults to @samp{""}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} boolean ssl-require-crl?
Require that CRL check succeeds for client certificates.
Defaults to @samp{#t}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} boolean ssl-verify-client-cert?
Request client to send a certificate. If you also want to require
it, set @samp{auth-ssl-require-client-cert? #t} in auth section.
Defaults to @samp{#f}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} string ssl-cert-username-field
Which field from certificate to use for username. commonName and
x500UniqueIdentifier are the usual choices. You'll also need to set
@samp{auth-ssl-username-from-cert? #t}.
Defaults to @samp{"commonName"}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} hours ssl-parameters-regenerate
How often to regenerate the SSL parameters file. Generation is
quite CPU intensive operation. The value is in hours, 0 disables
regeneration entirely.
Defaults to @samp{168}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} string ssl-protocols
SSL protocols to use.
Defaults to @samp{"!SSLv2"}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} string ssl-cipher-list
SSL ciphers to use.
Defaults to @samp{"ALL:!LOW:!SSLv2:!EXP:!aNULL"}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} string ssl-crypto-device
SSL crypto device to use, for valid values run "openssl engine".
Defaults to @samp{""}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} string postmaster-address
Address to use when sending rejection mails.
Default is postmaster@@<your domain>. %d expands to recipient domain.
Defaults to @samp{""}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} string hostname
Hostname to use in various parts of sent mails (e.g. in Message-Id)
and in LMTP replies. Default is the system's real hostname@@domain.
Defaults to @samp{""}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} boolean quota-full-tempfail?
If user is over quota, return with temporary failure instead of
bouncing the mail.
Defaults to @samp{#f}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} file-name sendmail-path
Binary to use for sending mails.
Defaults to @samp{"/usr/sbin/sendmail"}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} string submission-host
If non-empty, send mails via this SMTP host[:port] instead of
sendmail.
Defaults to @samp{""}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} string rejection-subject
Subject: header to use for rejection mails. You can use the same
variables as for @samp{rejection-reason} below.
Defaults to @samp{"Rejected: %s"}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} string rejection-reason
Human readable error message for rejection mails. You can use
variables:
@table @code
@item %n
CRLF
@item %r
reason
@item %s
original subject
@item %t
recipient
@end table
Defaults to @samp{"Your message to <%t> was automatically rejected:%n%r"}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} string recipient-delimiter
Delimiter character between local-part and detail in email
address.
Defaults to @samp{"+"}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} string lda-original-recipient-header
Header where the original recipient address (SMTP's RCPT TO:
address) is taken from if not available elsewhere. With dovecot-lda -a
parameter overrides this. A commonly used header for this is
X-Original-To.
Defaults to @samp{""}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} boolean lda-mailbox-autocreate?
Should saving a mail to a nonexistent mailbox automatically create
it?.
Defaults to @samp{#f}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} boolean lda-mailbox-autosubscribe?
Should automatically created mailboxes be also automatically
subscribed?.
Defaults to @samp{#f}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} non-negative-integer imap-max-line-length
Maximum IMAP command line length. Some clients generate very long
command lines with huge mailboxes, so you may need to raise this if you
get "Too long argument" or "IMAP command line too large" errors
often.
Defaults to @samp{64000}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} string imap-logout-format
IMAP logout format string:
@table @code
@item %i
total number of bytes read from client
@item %o
total number of bytes sent to client.
@end table
Defaults to @samp{"in=%i out=%o"}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} string imap-capability
Override the IMAP CAPABILITY response. If the value begins with '+',
add the given capabilities on top of the defaults (e.g. +XFOO XBAR).
Defaults to @samp{""}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} string imap-idle-notify-interval
How long to wait between "OK Still here" notifications when client
is IDLEing.
Defaults to @samp{"2 mins"}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} string imap-id-send
ID field names and values to send to clients. Using * as the value
makes Dovecot use the default value. The following fields have default
values currently: name, version, os, os-version, support-url,
support-email.
Defaults to @samp{""}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} string imap-id-log
ID fields sent by client to log. * means everything.
Defaults to @samp{""}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} space-separated-string-list imap-client-workarounds
Workarounds for various client bugs:
@table @code
@item delay-newmail
Send EXISTS/RECENT new mail notifications only when replying to NOOP and
CHECK commands. Some clients ignore them otherwise, for example OSX
Mail (<v2.1). Outlook Express breaks more badly though, without this it
may show user "Message no longer in server" errors. Note that OE6
still breaks even with this workaround if synchronization is set to
"Headers Only".
@item tb-extra-mailbox-sep
Thunderbird gets somehow confused with LAYOUT=fs (mbox and dbox) and
adds extra @samp{/} suffixes to mailbox names. This option causes Dovecot to
ignore the extra @samp{/} instead of treating it as invalid mailbox name.
@item tb-lsub-flags
Show \Noselect flags for LSUB replies with LAYOUT=fs (e.g. mbox).
This makes Thunderbird realize they aren't selectable and show them
greyed out, instead of only later giving "not selectable" popup error.
@end table
Defaults to @samp{()}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} string imap-urlauth-host
Host allowed in URLAUTH URLs sent by client. "*" allows all.
Defaults to @samp{""}.
@end deftypevr
Whew! Lots of configuration options. The nice thing about it though is
that GuixSD has a complete interface to Dovecot's configuration
language. This allows not only a nice way to declare configurations,
but also offers reflective capabilities as well: users can write code to
inspect and transform configurations from within Scheme.
However, it could be that you just want to get a @code{dovecot.conf} up
and running. In that case, you can pass an
@code{opaque-dovecot-configuration} as the @code{#:config} paramter to
@code{dovecot-service}. As its name indicates, an opaque configuration
does not have easy reflective capabilities.
Available @code{opaque-dovecot-configuration} fields are:
@deftypevr {@code{opaque-dovecot-configuration} parameter} package dovecot
The dovecot package.
@end deftypevr
@deftypevr {@code{opaque-dovecot-configuration} parameter} string string
The contents of the @code{dovecot.conf}, as a string.
@end deftypevr
For example, if your @code{dovecot.conf} is just the empty string, you
could instantiate a dovecot service like this:
@example
(dovecot-service #:config
(opaque-dovecot-configuration
(string "")))
@end example
@node Web Services
@subsubsection Web Services
The @code{(gnu services web)} module provides the following service:
@deffn {Scheme Procedure} nginx-service [#:nginx nginx] @
[#:log-directory ``/var/log/nginx''] @
[#:run-directory ``/var/run/nginx''] @
[#:config-file]
Return a service that runs @var{nginx}, the nginx web server.
The nginx daemon loads its runtime configuration from @var{config-file}.
Log files are written to @var{log-directory} and temporary runtime data
files are written to @var{run-directory}. For proper operation, these
arguments should match what is in @var{config-file} to ensure that the
Loading
Loading full blame...