Copyright @copyright{} 2016, 2017, 2018 Chris Marusich@*
Copyright @copyright{} 2016, 2017, 2018, 2019, 2020 Efraim Flashner@*
Copyright @copyright{} 2016 John Darrington@*
-Copyright @copyright{} 2016, 2017 ng0@*
-Copyright @copyright{} 2016, 2017, 2018, 2019 Jan Nieuwenhuizen@*
+Copyright @copyright{} 2016, 2017 Nikita Gillmann@*
+Copyright @copyright{} 2016, 2017, 2018, 2019, 2020 Jan Nieuwenhuizen@*
Copyright @copyright{} 2016 Julien Lepiller@*
Copyright @copyright{} 2016 Alex ter Weele@*
Copyright @copyright{} 2016, 2017, 2018, 2019 Christopher Baines@*
* Invoking guix environment:: Setting up development environments.
* Invoking guix pack:: Creating software bundles.
+* The GCC toolchain:: Working with languages supported by GCC.
Programming Interface
~root/.config/guix/current
@end example
-Source @file{etc/profile} to augment @code{PATH} and other relevant
+Source @file{etc/profile} to augment @env{PATH} and other relevant
environment variables:
@example
@c https://lists.gnu.org/archive/html/guix-devel/2017-01/msg01199.html
@example
-# cp ~root/.config/guix/current/lib/systemd/system/guix-daemon.service \
+# cp ~root/.config/guix/current/lib/systemd/system/gnu-store.mount \
+ ~root/.config/guix/current/lib/systemd/system/guix-daemon.service \
/etc/systemd/system/
-# systemctl enable --now guix-daemon
+# systemctl enable --now gnu-store.mount guix-daemon
@end example
If your host distro uses the Upstart init system:
@end itemize
You can influence the directory where the daemon stores build trees
-@i{via} the @code{TMPDIR} environment variable. However, the build tree
+@i{via} the @env{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
+This way, the value of @env{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}).
+@vindex https_proxy
+The daemon also honors the @env{http_proxy} and @env{https_proxy}
+environment variables for HTTP and HTTPS 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 @option{--disable-chroot}.
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
+its @env{TMPDIR} environment variable. This directory is shared with
the container for the duration of the build, though within the container,
the build tree is always called @file{/tmp/guix-build-@var{name}.drv-0}.
as the @option{--cores} option of @command{guix build} (@pxref{Invoking
guix build}).
-The effect is to define the @code{NIX_BUILD_CORES} environment variable
+The effect is to define the @env{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}.
This option can be repeated multiple times, in which case
@command{guix-daemon} accepts connections on all the specified
endpoints. Users can tell client commands what endpoint to connect to
-by setting the @code{GUIX_DAEMON_SOCKET} environment variable
-(@pxref{The Store, @code{GUIX_DAEMON_SOCKET}}).
+by setting the @env{GUIX_DAEMON_SOCKET} environment variable
+(@pxref{The Store, @env{GUIX_DAEMON_SOCKET}}).
@quotation Note
The daemon protocol is @emph{unauthenticated and unencrypted}. Using
@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
+available with Guix and then define the @env{GUIX_LOCPATH} environment
variable:
@example
917@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
+The @env{GUIX_LOCPATH} variable plays a role similar to @env{LOCPATH}
+(@pxref{Locale Names, @env{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
+@env{GUIX_LOCPATH} is honored only by the libc in Guix, and not by the libc
+provided by foreign distros. Thus, using @env{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
+libc suffixes each entry of @env{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
When you install Emacs packages with Guix, the Elisp files are placed
under the @file{share/emacs/site-lisp/} directory of the profile in
which they are installed. The Elisp libraries are made available to
-Emacs through the @code{EMACSLOADPATH} environment variable, which is
+Emacs through the @env{EMACSLOADPATH} environment variable, which is
set when installing Emacs itself.
Additionally, autoload definitions are automatically evaluated at the
can do so by running Emacs with the @option{--no-site-file} option
(@pxref{Init File,,, emacs, The GNU Emacs Manual}).
-@subsection The GCC toolchain
-
-@c XXX: The contents of this section were moved under
-@c ``Development'', since it makes more sense there and is not specific
-@c foreign distros. Remove it from here eventually?
-@xref{Packages for C Development}, for information on packages for C/C++
-development.
@node Upgrading Guix
@section Upgrading Guix
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
+Alternatively, run @command{info info} in another tty to keep the manual
available.
@end quotation
@end ifinfo
@section Preparing for Installation
Once you have booted, you can use the guided graphical installer, which makes
-it easy to get started (@pxref{Guided Graphical Installation}). Alternately,
+it easy to get started (@pxref{Guided Graphical Installation}). Alternatively,
if you are already familiar with GNU/Linux and if you want more control than
what the graphical installer provides, you can choose the ``manual''
installation process (@pxref{Manual Installation}).
@quotation Note
@cindex sudo vs. @command{guix pull}
Note that @command{sudo guix} runs your user's @command{guix} command and
-@emph{not} root's, because @command{sudo} leaves @code{PATH} unchanged. To
+@emph{not} root's, because @command{sudo} leaves @env{PATH} unchanged. To
explicitly run root's @command{guix}, type @command{sudo -i guix @dots{}}.
The difference matters here, because @command{guix pull} updates
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
+@file{$HOME/.guix-profile/bin} to their @env{PATH} environment
variable, and so on.
@cindex search paths
If you are not using Guix System, consider adding the
$ guix package -p foo -p bar --search-paths
@end example
-The last command above reports about the @code{GUILE_LOAD_PATH}
+The last command above reports about the @env{GUILE_LOAD_PATH}
variable, even though, taken individually, neither @file{foo} nor
@file{bar} would lead to that recommendation.
@item --search=@var{regexp}
@itemx -s @var{regexp}
+@anchor{guix-search}
@cindex searching for packages
List the available packages whose name, synopsis, or description matches
@var{regexp} (in a case-insensitive fashion), sorted by relevance.
@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}
+package variant in a Guile module and add it to @env{GUIX_PACKAGE_PATH}
(@pxref{Defining Packages}).
@node Substitutes
@noindent
@cindex reproducible builds
-If the ACL contains only the key for @code{b.example.org}, and if
-@code{a.example.org} happens to serve the @emph{exact same} substitutes,
-then Guix will download substitutes from @code{a.example.org} because it
+If the ACL contains only the key for @samp{b.example.org}, and if
+@samp{a.example.org} happens to serve the @emph{exact same} substitutes,
+then Guix will download substitutes from @samp{a.example.org} because it
comes first in the list and can be considered a mirror of
-@code{b.example.org}. In practice, independent build machines usually
+@samp{b.example.org}. In practice, independent build machines usually
produce the same binaries, thanks to bit-reproducible builds (see
below).
@subsection Proxy Settings
@vindex http_proxy
-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}.
+@vindex https_proxy
+Substitutes are downloaded over HTTP or HTTPS. The @env{http_proxy} and
+@env{https_proxy} environment variables can be set in the environment of
+@command{guix-daemon} and are honored for downloads of substitutes.
+Note that the value of those environment variables in the environment
+where @command{guix build}, @command{guix package}, and other client
+commands are run has @emph{absolutely no effect}.
@node Substitution Failure
@subsection Substitution Failure
produce a list of channel specifications in Recutils format.
@end table
+@item --list-formats
+Display available formats for @option{--format} option.
+
@item --profile=@var{profile}
@itemx -p @var{profile}
Display information about @var{profile}.
easily distributed to users who do not run Guix.
@menu
-* Invoking guix environment:: Setting up development environments.
-* Invoking guix pack:: Creating software bundles.
-* Packages for C Development:: Working with C code with Guix.
+* Invoking guix environment:: Setting up development environments.
+* Invoking guix pack:: Creating software bundles.
+* The GCC toolchain:: Working with languages supported by GCC.
@end menu
@node Invoking guix environment
applications such as a web browser. To run Eolie, we must expose and
share some files and directories; we include @code{nss-certs} and expose
@file{/etc/ssl/certs/} for HTTPS authentication; finally we preserve the
-the @code{DISPLAY} environment variable since containerized graphical
+the @env{DISPLAY} environment variable since containerized graphical
applications won't display without it.
@example
@end example
This example runs @command{mpirun} in a context where the only environment
-variables defined are @code{PATH}, environment variables whose name starts
-with @code{SLURM}, as well as the usual ``precious'' variables (@code{HOME},
-@code{USER}, etc.)
+variables defined are @env{PATH}, environment variables whose name starts
+with @samp{SLURM}, as well as the usual ``precious'' variables (@env{HOME},
+@env{USER}, etc.)
@item --search-paths
Display the environment variable definitions that make up the
@dfn{user namespaces} in the kernel Linux; when passed
@emph{twice}@footnote{Here's a trick to memorize it: @code{-RR}, which adds
PRoot support, can be thought of as the abbreviation of ``Really
-Relocatable''. Neat, isn't it?}, relocatable binaries fall to back to PRoot
-if user namespaces are unavailable, and essentially work anywhere---see below
-for the implications.
+Relocatable''. Neat, isn't it?}, relocatable binaries fall to back to
+other techniques if user namespaces are unavailable, and essentially
+work anywhere---see below for the implications.
For example, if you create a pack containing Bash with:
To produce relocatable binaries that work even in the absence of user
namespaces, pass @option{--relocatable} or @option{-R} @emph{twice}. In that
-case, binaries will try user namespace support and fall back to PRoot if user
-namespaces are not supported.
+case, binaries will try user namespace support and fall back to another
+@dfn{execution engine} if user namespaces are not supported. The
+following execution engines are supported:
+
+@table @code
+@item default
+Try user namespaces and fall back to PRoot if user namespaces are not
+supported (see below).
+
+@item performance
+Try user namespaces and fall back to Fakechroot if user namespaces are
+not supported (see below).
-The @uref{https://proot-me.github.io/, PRoot} program provides the necessary
+@item userns
+Run the program through user namespaces and abort if they are not
+supported.
+
+@item proot
+Run through PRoot. The @uref{https://proot-me.github.io/, PRoot} program
+provides the necessary
support for file system virtualization. It achieves that by using the
@code{ptrace} system call on the running program. This approach has the
advantage to work without requiring special kernel support, but it incurs
run-time overhead every time a system call is made.
+
+@item fakechroot
+Run through Fakechroot. @uref{https://github.com/dex4er/fakechroot/,
+Fakechroot} virtualizes file system accesses by intercepting calls to C
+library functions such as @code{open}, @code{stat}, @code{exec}, and so
+on. Unlike PRoot, it incurs very little overhead. However, it does not
+always work: for example, some file system accesses made from within the
+C library are not intercepted, and file system accesses made @i{via}
+direct syscalls are not intercepted either, leading to erratic behavior.
+@end table
+
+@vindex GUIX_EXECUTION_ENGINE
+When running a wrapped program, you can explicitly request one of the
+execution engines listed above by setting the
+@code{GUIX_EXECUTION_ENGINE} environment variable accordingly.
@end quotation
@cindex entry point, for Docker images
(@pxref{Common Build Options}) and all the package transformation
options (@pxref{Package Transformation Options}).
-@node Packages for C Development
-@section Packages for C Development
+
+@node The GCC toolchain
+@section The GCC toolchain
@cindex GCC
@cindex ld-wrapper
@cindex linker wrapper
@cindex toolchain, for C development
+@cindex toolchain, for Fortran development
If you need a complete toolchain for compiling and linking C or C++
source code, use the @code{gcc-toolchain} package. This package
passed to the linker, add corresponding @code{-rpath} arguments, and
invoke the actual linker with this new set of arguments. You can instruct the
wrapper to refuse to link against libraries not in the store by setting the
-@code{GUIX_LD_WRAPPER_ALLOW_IMPURITIES} environment variable to @code{no}.
-
+@env{GUIX_LD_WRAPPER_ALLOW_IMPURITIES} environment variable to @code{no}.
+The package @code{gfortran-toolchain} provides a complete GCC toolchain
+for Fortran development. For other languages, please use
+@samp{guix search gcc toolchain} (@pxref{guix-search,, Invoking guix package}).
@c *********************************************************************
@node Programming Interface
name and module name must match. For instance, the @code{(my-packages
emacs)} module must be stored in a @file{my-packages/emacs.scm} file
relative to the load path specified with @option{--load-path} or
-@code{GUIX_PACKAGE_PATH}. @xref{Modules and the File System,,,
+@env{GUIX_PACKAGE_PATH}. @xref{Modules and the File System,,,
guile, GNU Guile Reference Manual}, for details.}. There are two ways to make
these package definitions visible to the user interfaces:
@item
By adding the directory containing your package modules to the search path
with the @code{-L} flag of @command{guix package} and other commands
-(@pxref{Common Build Options}), or by setting the @code{GUIX_PACKAGE_PATH}
+(@pxref{Common Build Options}), or by setting the @env{GUIX_PACKAGE_PATH}
environment variable described below.
@item
channels.
@end enumerate
-@code{GUIX_PACKAGE_PATH} works similarly to other search path variables:
+@env{GUIX_PACKAGE_PATH} works similarly to other search path variables:
@defvr {Environment Variable} GUIX_PACKAGE_PATH
This is a colon-separated list of directories to search for additional
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}.
+That derivation is stored in a @file{.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}).
@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.
+A bytevector containing the SHA-256 hash of the source. This is
+equivalent to providing a @code{content-hash} SHA256 object in the
+@code{hash} field described below.
+
+@item @code{hash}
+The @code{content-hash} object of the source---see below for how to use
+@code{content-hash}.
You can obtain this information using @code{guix download}
(@pxref{Invoking guix download}) or @code{guix hash} (@pxref{Invoking
@end table
@end deftp
+@deftp {Data Type} content-hash @var{value} [@var{algorithm}]
+Construct a content hash object for the given @var{algorithm}, and with
+@var{value} as its hash value. When @var{algorithm} is omitted, assume
+it is @code{sha256}.
+
+@var{value} can be a literal string, in which case it is base32-decoded,
+or it can be a bytevector.
+
+The following forms are all equivalent:
+
+@lisp
+(content-hash "05zxkyz9bv3j9h0xyid1rhvh3klhsmrpkf3bcs6frvlgyr2gwilj")
+(content-hash "05zxkyz9bv3j9h0xyid1rhvh3klhsmrpkf3bcs6frvlgyr2gwilj"
+ sha256)
+(content-hash (base32
+ "05zxkyz9bv3j9h0xyid1rhvh3klhsmrpkf3bcs6frvlgyr2gwilj"))
+(content-hash (base64 "kkb+RPaP7uyMZmu4eXPVkM4BN8yhRd8BTHLslb6f/Rc=")
+ sha256)
+@end lisp
+
+Technically, @code{content-hash} is currently implemented as a macro.
+It performs sanity checks at macro-expansion time, when possible, such
+as ensuring that @var{value} has the right size for @var{algorithm}.
+@end deftp
@node Build Systems
@section Build Systems
resulting image. @code{build-program} requires a list of Common Lisp
expressions to be passed as the @code{#:entry-program} argument.
-If the system is not defined within its own @code{.asd} file of the same
+If the system is not defined within its own @file{.asd} file of the same
name, then the @code{#:asd-file} parameter should be used to specify
which file the system is defined in. Furthermore, if the package
defines a system for its tests in a separate file, it will be loaded
@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}
+that appropriately set the @env{XDG_DATA_DIRS} and @env{GTK_PATH}
environment variables.
It is possible to exclude specific package outputs from that wrapping
directory as OCaml, which is not what we want in guix. In particular, they
will install @file{.so} files in their module's directory, which is usually
fine because it is in the OCaml compiler directory. In guix though, these
-libraries cannot be found and we use @code{CAML_LD_LIBRARY_PATH}. This
+libraries cannot be found and we use @env{CAML_LD_LIBRARY_PATH}. This
variable points to @file{lib/ocaml/site-lib/stubslibs} and this is where
@file{.so} libraries should be installed.
@end defvr
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}
+it takes care of wrapping these programs so that their @env{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
@defvr {Scheme Variable} r-build-system
This variable is exported by @code{(guix build-system r)}. It
implements the build procedure used by @uref{https://r-project.org, R}
-packages, which essentially is little more than running @code{R CMD
+packages, which essentially is little more than running @samp{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
+@env{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} texlive-build-system
This variable is exported by @code{(guix build-system texlive)}. It is
used to build TeX packages in batch mode with a specified engine. The
-build system sets the @code{TEXINPUTS} variable to find all TeX source
+build system sets the @env{TEXINPUTS} variable to find all TeX source
files in the inputs.
By default it runs @code{luatex} on all files ending on @code{ins}. A
@item configure
The phase runs @code{meson} with the flags specified in
-@code{#:configure-flags}. The flag @option{--build-type} is always set to
-@code{plain} unless something else is specified in @code{#:build-type}.
+@code{#:configure-flags}. The flag @option{--buildtype} is always set to
+@code{debugoptimized} unless something else is specified in
+@code{#:build-type}.
@item build
The phase runs @code{ninja} to build the package in parallel by default, but
daemon, and to perform RPCs. These are described below. By default,
@code{open-connection}, and thus all the @command{guix} commands,
connect to the local daemon or to the URI specified by the
-@code{GUIX_DAEMON_SOCKET} environment variable.
+@env{GUIX_DAEMON_SOCKET} environment variable.
@defvr {Environment Variable} GUIX_DAEMON_SOCKET
When set, the value of this variable should be a file name or a URI
@cindex SSH access to build daemons
These URIs allow you to connect to a remote daemon over SSH. This
feature requires Guile-SSH (@pxref{Requirements}) and a working
-@code{guile} binary in @code{PATH} on the destination machine. It
+@command{guile} binary in @env{PATH} on the destination machine. It
supports public key and GSSAPI authentication. A typical URL might look
like this:
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
+name end in @file{.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}).
@dots{})} expression to construct the file name @emph{at run time}.
@end deffn
+@deffn {Scheme Syntax} let-system @var{system} @var{body}@dots{}
+@deffnx {Scheme Syntax} let-system (@var{system} @var{target}) @var{body}@dots{}
+Bind @var{system} to the currently targeted system---e.g.,
+@code{"x86_64-linux"}---within @var{body}.
+
+In the second case, additionally bind @var{target} to the current
+cross-compilation target---a GNU triplet such as
+@code{"arm-linux-gnueabihf"}---or @code{#f} if we are not
+cross-compiling.
+
+@code{let-system} is useful in the occasional case where the object
+spliced into the gexp depends on the target system, as in this example:
+
+@example
+#~(system*
+ #+(let-system system
+ (cond ((string-prefix? "armhf-" system)
+ (file-append qemu "/bin/qemu-system-arm"))
+ ((string-prefix? "x86_64-" system)
+ (file-append qemu "/bin/qemu-system-x86_64"))
+ (else
+ (error "dunno!"))))
+ "-net" "user" #$image)
+@end example
+@end deffn
+
@deffn {Scheme Syntax} with-parameters ((@var{parameter} @var{value}) @dots{}) @var{exp}
This macro is similar to the @code{parameterize} form for
dynamically-bound @dfn{parameters} (@pxref{Parameters,,, guile, GNU
This option implies @option{--no-offload}, and it has no effect when
connecting to a remote daemon with a @code{guix://} URI (@pxref{The
-Store, the @code{GUIX_DAEMON_SOCKET} variable}).
+Store, the @env{GUIX_DAEMON_SOCKET} variable}).
@item --keep-going
@itemx -k
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.
+building honor the @env{GUIX_BUILD_OPTIONS} environment variable.
@defvr {Environment Variable} GUIX_BUILD_OPTIONS
Users can define this variable to a list of command line options that
@command{guix download} verifies HTTPS server certificates by loading
the certificates of X.509 authorities from the directory pointed to by
-the @code{SSL_CERT_DIR} environment variable (@pxref{X.509
+the @env{SSL_CERT_DIR} environment variable (@pxref{X.509
Certificates}), unless @option{--no-check-certificate} is used.
The following options are available:
@table @code
+@item --hash=@var{algorithm}
+@itemx -H @var{algorithm}
+Compute a hash using the specified @var{algorithm}. @xref{Invoking guix
+hash}, for more information.
+
@item --format=@var{fmt}
@itemx -f @var{fmt}
Write the hash in the format specified by @var{fmt}. For more
@table @code
+@item --hash=@var{algorithm}
+@itemx -H @var{algorithm}
+Compute a hash using the specified @var{algorithm}, @code{sha256} by
+default.
+
+@var{algorithm} must the name of a cryptographic hash algorithm
+supported by Libgcrypt @i{via} Guile-Gcrypt---e.g., @code{sha512} or
+@code{sha3-256} (@pxref{Hash Functions,,, guile-gcrypt, Guile-Gcrypt
+Reference Manual}).
+
@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}
+Supported formats: @code{base64}, @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}
@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:
+The command command below imports metadata for the Acme::Boolean Perl
+module:
@example
guix import cpan Acme::Boolean
central repository for the @uref{https://r-project.org, GNU@tie{}R
statistical and graphical environment}.
-Information is extracted from the @code{DESCRIPTION} file of the package.
+Information is extracted from the @file{DESCRIPTION} file of the package.
-The command command below imports metadata for the @code{Cairo}
-R package:
+The command command below imports metadata for the Cairo R package:
@example
guix import cran Cairo
packages for for the analysis and comprehension of high-throughput
genomic data in bioinformatics.
-Information is extracted from the @code{DESCRIPTION} file contained in the
+Information is extracted from the @file{DESCRIPTION} file contained in the
package archive.
-The command below imports metadata for the @code{GenomicRanges}
-R package:
+The command below imports metadata for the GenomicRanges R package:
@example
guix import cran --archive=bioconductor GenomicRanges
@end table
The command below imports metadata for the latest version of the
-@code{HTTP} Haskell package without including test dependencies and
+HTTP Haskell package without including test dependencies and
specifying the value of the flag @samp{network-uri} as @code{false}:
@example
in Guix.
@end table
-The command below imports metadata for the @code{HTTP} Haskell package
+The command below imports metadata for the HTTP Haskell package
included in the LTS Stackage release version 7.18:
@example
gnu/packages/glib.scm:77:12: glib would be upgraded from 2.34.3 to 2.37.0
@end example
-Alternately, one can specify packages to consider, in which case a
+Alternatively, one can specify packages to consider, in which case a
warning is emitted for packages that lack an updater:
@example
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
+an API token, set the environment variable @env{GUIX_GITHUB_TOKEN} to a
token procured from @uref{https://github.com/settings/tokens} or
otherwise.
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.
+When looking at the profile returned by @command{guix size}, you may
+find yourself wondering why a given package shows up in the profile at
+all. To understand it, you can use @command{guix graph --path -t
+references} to display the shortest path between the two packages
+(@pxref{Invoking guix graph}).
+
The available options are:
@table @option
HTML page with embedded JavaScript code to display a ``chord diagram''
in a Web browser, using the @uref{https://d3js.org/, d3.js} library, or
emit Cypher queries to construct a graph in a graph database supporting
-the @uref{https://www.opencypher.org/, openCypher} query language.
-The general syntax is:
+the @uref{https://www.opencypher.org/, openCypher} query language. With
+@option{--path}, it simply displays the shortest path between two
+packages. The general syntax is:
@example
guix graph @var{options} @var{package}@dots{}
Nice little graph, no?
+You may find it more pleasant to navigate the graph interactively with
+@command{xdot} (from the @code{xdot} package):
+
+@example
+guix graph coreutils | xdot -
+@end example
+
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
For instance, the following command:
@example
-guix graph --type=bag-emerged coreutils | dot -Tpdf > dag.pdf
+guix graph --type=bag-emerged coreutils
@end example
...@: yields this bigger graph:
module that defines the @code{guile} package:
@example
-guix graph -t module guile | dot -Tpdf > module-graph.pdf
+guix graph -t module guile | xdot -
@end example
@end table
@end table
+@cindex shortest path, between packages
+Often, the graph of the package you are interested in does not fit on
+your screen, and anyway all you want to know is @emph{why} that package
+actually depends on some seemingly unrelated package. The
+@option{--path} option instructs @command{guix graph} to display the
+shortest path between two packages (or derivations, or store items,
+etc.):
+
+@example
+$ guix graph --path emacs libunistring
+emacs@@26.3
+mailutils@@3.9
+libunistring@@0.9.10
+$ guix graph --path -t derivation emacs libunistring
+/gnu/store/@dots{}-emacs-26.3.drv
+/gnu/store/@dots{}-mailutils-3.9.drv
+/gnu/store/@dots{}-libunistring-0.9.10.drv
+$ guix graph --path -t references emacs libunistring
+/gnu/store/@dots{}-emacs-26.3
+/gnu/store/@dots{}-libidn2-2.2.0
+/gnu/store/@dots{}-libunistring-0.9.10
+@end example
+
The available options are the following:
@table @option
Currently, the available backends are Graphviz and d3.js.
+@item --path
+Display the shortest path between two nodes of the type specified by
+@option{--type}. The example below shows the shortest path between
+@code{libreoffice} and @code{llvm} according to the references of
+@code{libreoffice}:
+
+@example
+$ guix graph --path -t references libreoffice llvm
+/gnu/store/@dots{}-libreoffice-6.4.2.2
+/gnu/store/@dots{}-libepoxy-1.5.4
+/gnu/store/@dots{}-mesa-19.3.4
+/gnu/store/@dots{}-llvm-9.0.1
+@end example
+
@item --expression=@var{expr}
@itemx -e @var{expr}
Consider the package @var{expr} evaluates to.
This automatically invokes @command{diffoscope}, which displays detailed
information about files that differ.
-Alternately, we can do something along these lines (@pxref{Invoking guix
+Alternatively, we can do something along these lines (@pxref{Invoking guix
archive}):
@example
@vindex %base-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}
+on the system, for all user accounts---i.e., in every user's @env{PATH}
environment variable---in addition to the per-user profiles
(@pxref{Invoking guix package}). The @code{%base-packages} variable
provides all the tools one would expect for basic user and administrator
Manual}, for more information on these flags.
@item @code{options} (default: @code{#f})
-This is either @code{#f}, or a string denoting mount options passed to the
-file system driver. @xref{Mount-Unmount-Remount,,, libc, The GNU C Library
-Reference Manual}, for details and run @command{man 8 mount} for options for
-various file systems.
+This is either @code{#f}, or a string denoting mount options passed to
+the file system driver. @xref{Mount-Unmount-Remount,,, libc, The GNU C
+Library Reference Manual}, for details and run @command{man 8 mount} for
+options for various file systems. Note that the
+@code{file-system-options->alist} and @code{alist->file-system-options}
+procedures from @code{(gnu system file-systems)} can be used to convert
+file system options given as an association list to the string
+representation, and vice-versa.
@item @code{mount?} (default: @code{#t})
This value indicates whether to automatically mount the file system when
@code{fuse.ko} kernel module to be loaded.
@end defvr
+@node Btrfs file system
+@subsection Btrfs file system
+
+The Btrfs has special features, such as subvolumes, that merit being
+explained in more details. The following section attempts to cover
+basic as well as complex uses of a Btrfs file system with the Guix
+System.
+
+In its simplest usage, a Btrfs file system can be described, for
+example, by:
+
+@lisp
+(file-system
+ (mount-point "/home")
+ (type "btrfs")
+ (device (file-system-label "my-home")))
+@end lisp
+
+The example below is more complex, as it makes use of a Btrfs
+subvolume, named @code{rootfs}. The parent Btrfs file system is labeled
+@code{my-btrfs-pool}, and is located on an encrypted device (hence the
+dependency on @code{mapped-devices}):
+
+@lisp
+(file-system
+ (device (file-system-label "my-btrfs-pool"))
+ (mount-point "/")
+ (type "btrfs")
+ (options "subvol=rootfs")
+ (dependencies mapped-devices))
+@end lisp
+
+Some bootloaders, for example GRUB, only mount a Btrfs partition at its
+top level during the early boot, and rely on their configuration to
+refer to the correct subvolume path within that top level. The
+bootloaders operating in this way typically produce their configuration
+on a running system where the Btrfs partitions are already mounted and
+where the subvolume information is readily available. As an example,
+@command{grub-mkconfig}, the configuration generator command shipped
+with GRUB, reads @file{/proc/self/mountinfo} to determine the top-level
+path of a subvolume.
+
+The Guix System produces a bootloader configuration using the operating
+system configuration as its sole input; it is therefore necessary to
+extract the subvolume name on which @file{/gnu/store} lives (if any)
+from that operating system configuration. To better illustrate,
+consider a subvolume named 'rootfs' which contains the root file system
+data. In such situation, the GRUB bootloader would only see the top
+level of the root Btrfs partition, e.g.:
+
+@example
+/ (top level)
+├── rootfs (subvolume directory)
+ ├── gnu (normal directory)
+ ├── store (normal directory)
+[...]
+@end example
+
+Thus, the subvolume name must be prepended to the @file{/gnu/store} path
+of the kernel, initrd binaries and any other files referred to in the
+GRUB configuration that must be found during the early boot.
+
+The next example shows a nested hierarchy of subvolumes and
+directories:
+
+@example
+/ (top level)
+├── rootfs (subvolume)
+ ├── gnu (normal directory)
+ ├── store (subvolume)
+[...]
+@end example
+
+This scenario would work without mounting the 'store' subvolume.
+Mounting 'rootfs' is sufficient, since the subvolume name matches its
+intended mount point in the file system hierarchy. Alternatively, the
+'store' subvolume could be referred to by setting the @code{subvol}
+option to either @code{/rootfs/gnu/store} or @code{rootfs/gnu/store}.
+
+Finally, a more contrived example of nested subvolumes:
+
+@example
+/ (top level)
+├── root-snapshots (subvolume)
+ ├── root-current (subvolume)
+ ├── guix-store (subvolume)
+[...]
+@end example
+
+Here, the 'guix-store' subvolume doesn't match its intended mount point,
+so it is necessary to mount it. The subvolume must be fully specified,
+by passing its file name to the @code{subvol} option. To illustrate,
+the 'guix-store' subvolume could be mounted on @file{/gnu/store} by using
+a file system declaration such as:
+
+@lisp
+(file-system
+ (device (file-system-label "btrfs-pool-1"))
+ (mount-point "/gnu/store")
+ (type "btrfs")
+ (options "subvol=root-snapshots/root-current/guix-store,\
+compress-force=zstd,space_cache=v2"))
+@end lisp
+
@node Mapped Devices
@section Mapped Devices
@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}).
+@env{LOCPATH} environment variable (@pxref{locales-and-locpath,
+@env{LOCPATH} and locale packages}).
The @code{locale-definition} form is provided by the @code{(gnu system
locale)} module. Details are given below.
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, of the locale data from libc 2.21 (specifically, @code{LC_COLLATE}
+all, of the locale data from libc 2.21 (specifically, @env{LC_COLLATE}
data is incompatible); thus calls to @code{setlocale} may fail, but
programs will not abort.
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}).
+and define @env{GUIX_LOCPATH} accordingly (@pxref{locales-and-locpath,
+@env{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
descending order.
@item @code{term} (default: @code{#f})
-A string containing the value used for the @code{TERM} environment
+A string containing the value used for the @env{TERM} environment
variable.
@item @code{eight-bits?} (default: @code{#f})
subsystem request.
The command @command{internal-sftp} implements an in-process SFTP
-server. Alternately, one can specify the @command{sftp-server} command:
+server. Alternatively, one can specify the @command{sftp-server} command:
@lisp
(service openssh-service-type
(openssh-configuration
Each string gets on its own line. See the @code{AcceptEnv} option in
@code{man sshd_config}.
-This example allows ssh-clients to export the @code{COLORTERM} variable.
+This example allows ssh-clients to export the @env{COLORTERM} variable.
It is set by terminal emulators, which support colors. You can use it in
your shell's resource file to enable colors for the prompt and commands
if this variable is set.
@deftypevr {@code{files-configuration} parameter} file-name server-keychain
Specifies the location of TLS certificates and private keys. CUPS will
-look for public and private keys in this directory: a @code{.crt} files
-for PEM-encoded certificates and corresponding @code{.key} files for
+look for public and private keys in this directory: @file{.crt} files
+for PEM-encoded certificates and corresponding @file{.key} files for
PEM-encoded private keys.
Defaults to @samp{"/etc/cups/ssl"}.
@quotation Warning
This service overrides per-user configuration files. If you want
PulseAudio to honor configuraton files in @file{~/.config/pulse} you
-have to unset the environment variables @code{PULSE_CONFIG} and
-@code{PULSE_CLIENTCONFIG} in your @file{~/.bash_profile}.
+have to unset the environment variables @env{PULSE_CONFIG} and
+@env{PULSE_CLIENTCONFIG} in your @file{~/.bash_profile}.
@end quotation
@quotation Warning
configuration. Here is an example of a service that polls the Guix repository
and builds the packages from a manifest. Some of the packages are defined in
the @code{"custom-packages"} input, which is the equivalent of
-@code{GUIX_PACKAGE_PATH}.
+@env{GUIX_PACKAGE_PATH}.
@lisp
(define %cuirass-specs
Some @code{volume} elements must be added to automatically mount volumes
at login. Here's an example allowing the user @code{alice} to mount her
-encrypted @code{HOME} directory and allowing the user @code{bob} to mount
+encrypted @env{HOME} directory and allowing the user @code{bob} to mount
the partition where he stores his data:
@lisp
can also install their own certificate package in
their profile. A number of environment variables need to be defined so
that applications and libraries know where to find them. Namely, the
-OpenSSL library honors the @code{SSL_CERT_DIR} and @code{SSL_CERT_FILE}
+OpenSSL library honors the @env{SSL_CERT_DIR} and @env{SSL_CERT_FILE}
variables. Some applications add their own environment variables; for
instance, the Git version control system honors the certificate bundle
-pointed to by the @code{GIT_SSL_CAINFO} environment variable. Thus, you
+pointed to by the @env{GIT_SSL_CAINFO} environment variable. Thus, you
would typically run something like:
@example
export GIT_SSL_CAINFO="$SSL_CERT_FILE"
@end example
-As another example, R requires the @code{CURL_CA_BUNDLE} environment
+As another example, R requires the @env{CURL_CA_BUNDLE} environment
variable to point to a certificate bundle, so you would have to run
something like this:
initialization system.
@item --root=@var{root}
-Mount @var{root} as the root file system. @var{root} can be a
-device name like @code{/dev/sda1}, a file system label, or a file system
-UUID.
+Mount @var{root} as the root file system. @var{root} can be a device
+name like @code{/dev/sda1}, a file system label, or a file system UUID.
+When unspecified, the device name from the root file system of the
+operating system declaration is used.
@item --system=@var{system}
Have @file{/run/booted-system} and @file{/run/current-system} point to
program to run in that initrd.
@deffn {Scheme Procedure} expression->initrd @var{exp} @
- [#:guile %guile-static-stripped] [#:name "guile-initrd"]
+ [#:guile %guile-3.0-static-stripped] [#:name "guile-initrd"]
Return as a file-like object a Linux initrd (a gzipped cpio archive)
containing @var{guile} and that evaluates @var{exp}, a G-expression,
upon booting. All the derivations referenced by @var{exp} are
@end table
@end deftp
-@defvr {Scheme Variable} %default-theme
-This is the default GRUB theme used by the operating system if no
+@deffn {Scheme Procedure} grub-theme
+Return the default GRUB theme used by the operating system if no
@code{theme} field is specified in @code{bootloader-configuration}
record.
It comes with a fancy background image displaying the GNU and Guix
logos.
-@end defvr
+@end deffn
For example, to override the default resolution, you may use something
like
(bootloader-configuration
;; @dots{}
(theme (grub-theme
- (inherit %default-theme)
+ (inherit (grub-theme))
(gfxmode '("1024x786x32" "auto"))))))
@end lisp
container, you may need to pass the @option{--privileged} option to
@code{docker create}.
+Last, the @option{--network} option applies to @command{guix system
+docker-image}: it produces an image where network is supposedly shared
+with the host, and thus without services like nscd or NetworkManager.
+
@item container
Return a script to run the operating system declared in @var{file}
within a container. Containers are a set of lightweight isolation
The command:
@example
-$ guix system extension-graph @var{file} | dot -Tpdf > services.pdf
+$ guix system extension-graph @var{file} | xdot -
@end example
-produces a PDF file showing the extension relations among services.
+shows the extension relations among services.
@anchor{system-shepherd-graph}
@item shepherd-graph
@end example
From there on, GDB will pick up debugging information from the
-@code{.debug} files under @file{~/.guix-profile/lib/debug}.
+@file{.debug} files under @file{~/.guix-profile/lib/debug}.
In addition, you will most likely want GDB to be able to show the source
code being debugged. To do that, you will have to unpack the source
@dfn{bootstrap binaries}.
These bootstrap binaries are ``taken for granted'', though we can also
-re-create them if needed (more on that later).
-
-For @code{i686-linux} and @code{x86_64-linux} the Guix bootstrap process is
-more elaborate, @pxref{Reduced Binary Seed Bootstrap}.
+re-create them if needed (@pxref{Preparing to Use the Bootstrap
+Binaries}).
@menu
* Reduced Binary Seed Bootstrap:: A Bootstrap worthy of GNU.
GNU C Library (@pxref{Bootstrapping}). Usually, these bootstrap binaries are
``taken for granted.''
-Taking these binaries for granted means that we consider them to be a correct
-and trustworthy `seed' for building the complete system. Therein lies a
-problem: the current combined size of these bootstrap binaries is about 250MB
-(@pxref{Bootstrappable Builds,,, mes, GNU Mes}). Auditing or even inspecting
-these is next to impossible.
+Taking the bootstrap binaries for granted means that we consider them to
+be a correct and trustworthy ``seed'' for building the complete system.
+Therein lies a problem: the combined size of these bootstrap binaries is
+about 250MB (@pxref{Bootstrappable Builds,,, mes, GNU Mes}). Auditing
+or even inspecting these is next to impossible.
-For @code{i686-linux} and @code{x86_64-linux}, Guix now features a ``Reduced
-Binary Seed'' bootstrap @footnote{We would like to say: ``Full Source
-Bootstrap'' and while we are working towards that goal it would be hyperbole
-to use that term for what we do now.}.
+For @code{i686-linux} and @code{x86_64-linux}, Guix now features a
+``Reduced Binary Seed'' bootstrap @footnote{We would like to say: ``Full
+Source Bootstrap'' and while we are working towards that goal it would
+be hyperbole to use that term for what we do now.}.
The Reduced Binary Seed bootstrap removes the most critical tools---from a
trust perspective---from the bootstrap binaries: GCC, Binutils and the GNU C
Library are replaced by: @code{bootstrap-mescc-tools} (a tiny assembler and
linker) and @code{bootstrap-mes} (a small Scheme Interpreter and a C compiler
-written in Scheme and the Mes C Library, built for TinyCC and for GCC). Using
-these new binary seeds and a new set of
-@c
-packages@footnote{@c
-nyacc-boot,
-mes-boot,
-tcc-boot0,
-tcc-boot,
-make-mesboot0,
-diffutils-mesboot,
-binutils-mesboot0,
-gcc-core-mesboot,
-mesboot-headers,
-glibc-mesboot0,
-gcc-mesboot0,
-binutils-mesboot,
-make-mesboot,
-gcc-mesboot1,
-gcc-mesboot1-wrapper,
-glibc-headers-mesboot,
-glibc-mesboot,
-gcc-mesboot,
-and
-gcc-mesboot-wrapper.
-}
-@c
-the ``missing'' Binutils, GCC, and the GNU C Library are built from source.
-From here on the more traditional bootstrap process resumes. This approach
-has reduced the bootstrap binaries in size to about 130MB. Work is ongoing to
-reduce this further. If you are interested, join us on @code{#bootstrappable}
-on the Freenode IRC network.
-
-@c ./pre-inst-env guix graph --type=bag -e '(begin (use-modules (guix packages)) (%current-system "i686-linux") (@@ (gnu packages commencement) gcc-mesboot))' > doc/images/gcc-mesboot-bag-graph.dot
-@c dot -T png doc/images/gcc-mesboot-bag-graph.dot > doc/images/gcc-mesboot-bag-graph.png
-
-Below is the generated dependency graph for @code{gcc-mesboot}, the bootstrap
-compiler used to build the rest of GuixSD.
-
-@image{images/gcc-mesboot-bag-graph,6in,,Dependency graph of the gcc-mesboot}
+written in Scheme and the Mes C Library, built for TinyCC and for GCC).
+
+Using these new binary seeds the ``missing'' Binutils, GCC, and the GNU
+C Library are built from source. From here on the more traditional
+bootstrap process resumes. This approach has reduced the bootstrap
+binaries in size to about 145MB in Guix v1.1.
+
+The next step that Guix has taken is to replace the shell and all its
+utilities with implementations in Guile Scheme, the @emph{Scheme-only
+bootstrap}. Gash (@pxref{Gash,,, gash, The Gash manual}) is a
+POSIX-compatible shell that replaces Bash, and it comes with Gash Utils
+which has minimalist replacements for Awk, the GNU Core Utilities, Grep,
+Gzip, Sed, and Tar. The rest of the bootstrap binary seeds that were
+removed are now built from source.
+
+Building the GNU System from source is currently only possibly by adding
+some historical GNU packages as intermediate steps@footnote{Packages
+such as @code{gcc-2.95.3}, @code{binutils-2.14}, @code{glibc-2.2.5},
+@code{gzip-1.2.4}, @code{tar-1.22}, and some others. For details, see
+@file{gnu/packages/commencement.scm}.}. As Gash and Gash Utils mature,
+and GNU packages become more bootstrappable again (e.g., new releases of
+GNU Sed will also ship as gzipped tarballs again, as alternative to the
+hard to bootstrap @code{xz}-compression), this set of added packages can
+hopefully be reduced again.
+
+The graph below shows the resulting dependency graph for
+@code{gcc-core-mesboot0}, the bootstrap compiler used for the
+traditional bootstrap of the rest of the Guix System.
+
+@c ./pre-inst-env guix graph -e '(@@ (gnu packages commencement) gcc-core-mesboot0)' | sed -re 's,((bootstrap-mescc-tools|bootstrap-mes|guile-bootstrap).*shape =) box,\1 ellipse,' > doc/images/gcc-core-mesboot0-graph.dot
+@image{images/gcc-core-mesboot0-graph,6in,,Dependency graph of gcc-core-mesboot0}
+
+The only significant binary bootstrap seeds that remain@footnote{
+Ignoring the 68KB @code{mescc-tools}; that will be removed later,
+together with @code{mes}.} are a Scheme intepreter and a Scheme
+compiler: GNU Mes and GNU Guile@footnote{Not shown in this graph are the
+static binaries for @file{bash}, @code{tar}, and @code{xz} that are used
+to get Guile running.}.
+
+This further reduction has brought down the size of the binary seed to
+about 60MB for @code{i686-linux} and @code{x86_64-linux}.
+
+Work is ongoing to remove all binary blobs from our free software
+bootstrap stack, working towards a Full Source Bootstrap. Also ongoing
+is work to bring these bootstraps to the @code{arm-linux} and
+@code{aarch64-linux} architectures and to the Hurd.
+
+If you are interested, join us on @samp{#bootstrappable} on the Freenode
+IRC network or discuss on @email{bug-mes@@gnu.org} or
+@email{gash-devel@@nongnu.org}.
@node Preparing to Use the Bootstrap Binaries
@section Preparing to Use the Bootstrap Binaries
| dot -Tps > gcc.ps
@end example
-or, for the Reduced Binary Seed bootstrap
+or, for the further Reduced Binary Seed bootstrap
@example
guix graph -t derivation \
Once @code{guile-bootstrap-2.0.drv} is built, we have a functioning
Guile that can be used to run subsequent build programs. Its first task
is to download tarballs containing the other pre-built binaries---this
-is what the @code{.tar.xz.drv} derivations do. Guix modules such as
+is what the @file{.tar.xz.drv} derivations do. Guix modules such as
@code{ftp-client.scm} are used for this purpose. The
@code{module-import.drv} derivations import those modules in a directory
in the store, using the original layout. The
@example
guix graph -t bag \
-e '(@@@@ (gnu packages commencement)
- glibc-final-with-bootstrap-bash)' | dot -Tps > t.ps
+ glibc-final-with-bootstrap-bash)' | xdot -
@end example
@noindent
-produces the dependency graph leading to the ``final'' C
+displays the dependency graph leading to the ``final'' C
library@footnote{You may notice the @code{glibc-intermediate} label,
suggesting that it is not @emph{quite} final, but as a good
approximation, we will consider it final.}, depicted below.
HCoop / jackhill / guix / guix.git / blobdiff