Merge branch 'master' into core-updates

1 files changed, 889 insertions, 167 deletions

diff --git a/doc/guix.texi b/doc/guix.texi
index 5286d41ca7..7b4e60c47e 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -41,7 +41,7 @@ Copyright @copyright{} 2016, 2017, 2018, 2019, 2020, 2021 Julien Lepiller@*
 Copyright @copyright{} 2016 Alex ter Weele@*
 Copyright @copyright{} 2016, 2017, 2018, 2019, 2020, 2021 Christopher Baines@*
 Copyright @copyright{} 2017, 2018, 2019 Clément Lassieur@*
-Copyright @copyright{} 2017, 2018, 2020, 2021 Mathieu Othacehe@*
+Copyright @copyright{} 2017, 2018, 2020, 2021, 2022 Mathieu Othacehe@*
 Copyright @copyright{} 2017 Federico Beffa@*
 Copyright @copyright{} 2017, 2018 Carlo Zancanaro@*
 Copyright @copyright{} 2017 Thomas Danckaert@*
@@ -88,7 +88,7 @@ Copyright @copyright{} 2020 Daniel Brooks@*
 Copyright @copyright{} 2020 John Soo@*
 Copyright @copyright{} 2020 Jonathan Brielmaier@*
 Copyright @copyright{} 2020 Edgar Vincent@*
-Copyright @copyright{} 2021 Maxime Devos@*
+Copyright @copyright{} 2021, 2022 Maxime Devos@*
 Copyright @copyright{} 2021 B. Wilson@*
 Copyright @copyright{} 2021 Xinglu Chen@*
 Copyright @copyright{} 2021 Raghav Gururajan@*
@@ -100,6 +100,10 @@ Copyright @copyright{} 2021 Josselin Poiret@*
 Copyright @copyright{} 2021 Andrew Tropin@*
 Copyright @copyright{} 2021 Sarah Morgensen@*
 Copyright @copyright{} 2021 Josselin Poiret@*
+Copyright @copyright{} 2022 Remco van 't Veer@*
+Copyright @copyright{} 2022 Aleksandr Vityazev@*
+Copyright @copyright{} 2022 Philip M@sup{c}Grath@*
+Copyright @copyright{} 2022 Karl Hallsby@*
 
 Permission is granted to copy, distribute and/or modify this document
 under the terms of the GNU Free Documentation License, Version 1.3 or
@@ -171,6 +175,7 @@ Weblate} (@pxref{Translating Guix}).
 * Development::                 Guix-aided software development.
 * Programming Interface::       Using Guix in Scheme.
 * Utilities::                   Package management commands.
+* Foreign Architectures::       Build for foreign architectures.
 * System Configuration::        Configuring the operating system.
 * Home Configuration::          Configuring the home environment.
 * Documentation::               Browsing software user manuals.
@@ -277,6 +282,7 @@ Programming Interface
 * Package Modules::             Packages from the programmer's viewpoint.
 * Defining Packages::           Defining new packages.
 * Defining Package Variants::   Customizing packages.
+* Writing Manifests::           The bill of materials of your environment.
 * Build Systems::               Specifying how packages are built.
 * Build Phases::                Phases of the build process of a package.
 * Build Utilities::             Helpers for your package definitions and more.
@@ -318,6 +324,10 @@ Invoking @command{guix build}
 * Additional Build Options::    Options specific to 'guix build'.
 * Debugging Build Failures::    Real life packaging experience.
 
+Foreign Architectures
+* Cross-Compilation::   Cross-compiling for another architecture.
+* Native Builds::       Targeting another architecture through native builds.
+
 System Configuration
 
 * Using the Configuration System::  Customizing your GNU system.
@@ -1552,7 +1562,11 @@ is normally run as @code{root} like this:
 # guix-daemon --build-users-group=guixbuild
 @end example
 
-@noindent
+@cindex socket activation, for @command{guix-daemon}
+This daemon can also be started following the systemd ``socket
+activation'' protocol (@pxref{Service De- and Constructors,
+@code{make-systemd-constructor},, shepherd, The GNU Shepherd Manual}).
+
 For details on how to set it up, @pxref{Setting Up the Daemon}.
 
 @cindex chroot
@@ -2323,8 +2337,8 @@ Installation}).
 
 The installation system provides root shells on TTYs 3 to 6; press
 @kbd{ctrl-alt-f3}, @kbd{ctrl-alt-f4}, and so on to reach them.  It includes
-many common tools needed to install the system.  But it is also a full-blown
-Guix System, which means that you can install additional packages, should you
+many common tools needed to install the system, but is also a full-blown
+Guix System.  This means that you can install additional packages, should you
 need it, using @command{guix package} (@pxref{Invoking guix package}).
 
 @menu
@@ -3372,7 +3386,6 @@ 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:
 
@@ -3387,30 +3400,7 @@ of packages:
        (list guile-2.0 "debug")))
 @end lisp
 
-@findex specifications->manifest
-In this example we have to know which modules define the @code{emacs}
-and @code{guile-2.0} variables to provide the right
-@code{use-package-modules} line, which can be cumbersome.  We can
-instead provide regular package specifications and let
-@code{specifications->manifest} look up the corresponding package
-objects, like this:
-
-@lisp
-(specifications->manifest
- '("emacs" "guile@@2.2" "guile@@2.2:debug"))
-@end lisp
-
-@findex package->development-manifest
-You might also want to create a manifest for all the dependencies of a
-package, rather than the package itself:
-
-@lisp
-(package->development-manifest (specification->package "emacs"))
-@end lisp
-
-The example above gives you all the software required to develop Emacs,
-similar to what @command{guix environment emacs} provides.
-
+@xref{Writing Manifests}, for information on how to write a manifest.
 @xref{export-manifest, @option{--export-manifest}}, to learn how to
 obtain a manifest file from an existing profile.
 
@@ -3468,7 +3458,7 @@ The typical use case is to define these environment variables in the
 shell:
 
 @example
-$ eval `guix package --search-paths`
+$ eval $(guix package --search-paths)
 @end example
 
 @var{kind} may be one of @code{exact}, @code{prefix}, or @code{suffix},
@@ -4705,7 +4695,7 @@ want to install in your profile the current @code{guile} package, along with
 the @code{guile-json} as it existed in an older revision of Guix---perhaps
 because the newer @code{guile-json} has an incompatible API and you want to
 run your code against the old API@.  To do that, you could write a manifest for
-use by @code{guix package --manifest} (@pxref{Invoking guix package}); in that
+use by @code{guix package --manifest} (@pxref{Writing Manifests}); in that
 manifest, you would create an inferior for that old Guix revision you care
 about, and you would look up the @code{guile-json} package in the inferior:
 
@@ -5192,7 +5182,7 @@ write in @code{~/.config/guix/channels.scm} this specification:
 @noindent
 From there on, @command{guix pull} will fetch code from the @code{super-hacks}
 branch of the repository at @code{example.org}.  The authentication concern is
-addressed below ((@pxref{Channel  Authentication}).
+addressed below (@pxref{Channel Authentication}).
 
 @node Replicating Guix
 @section Replicating Guix
@@ -5219,7 +5209,7 @@ say, on another machine, by providing a channel specification in
 
 The @command{guix describe --format=channels} command can even generate this
 list of channels directly (@pxref{Invoking guix describe}).  The resulting
-file can be used with the -C options of @command{guix pull}
+file can be used with the @option{-C} option of @command{guix pull}
 (@pxref{Invoking guix pull}) or @command{guix time-machine}
 (@pxref{Invoking guix time-machine}).
 
@@ -5687,17 +5677,22 @@ before @command{guix shell} was invoked.  The next garbage collection
 (@pxref{Invoking guix gc}) may clean up packages that were installed in
 the environment and that are no longer used outside of it.
 
-As an added convenience, when running from a directory that contains a
-@file{manifest.scm} or a @file{guix.scm} file (in this order), possibly
-in a parent directory, @command{guix shell} automatically loads the
-file---provided the directory is listed in
-@file{~/.config/guix/shell-authorized-directories}, and only for
-interactive use:
+As an added convenience, @command{guix shell} will try to do what you
+mean when it is invoked interactively without any other arguments
+as in:
 
 @example
 guix shell
 @end example
 
+If it finds a @file{manifest.scm} in the current working directory or
+any of its parents, it uses this manifest as though it was given via @code{--manifest}.
+Likewise, if it finds a @file{guix.scm} in the same directories, it uses
+it to build a development profile as though both @code{--development}
+and @code{--file} were present.
+In either case, the file will only be loaded if the directory it
+resides in is listed in
+@file{~/.config/guix/shell-authorized-directories}.
 This provides an easy way to define, share, and enter development
 environments.
 
@@ -5777,6 +5772,7 @@ former is sourced only by log-in shells.  @xref{Bash Startup Files,,,
 bash, The GNU Bash Reference Manual}, for details on Bash start-up
 files.
 
+@anchor{shell-development-option}
 @item --development
 @itemx -D
 Cause @command{guix shell} to include in the environment the
@@ -5818,6 +5814,10 @@ To select other outputs, two element tuples can be specified:
 guix shell -e '(list (@@ (gnu packages bash) bash) "include")'
 @end example
 
+@xref{package-development-manifest,
+@code{package->development-manifest}}, for information on how to write a
+manifest for the development environment of a package.
+
 @item --file=@var{file}
 @itemx -f @var{file}
 Create an environment containing the package or list of packages that
@@ -5837,6 +5837,7 @@ running:
 guix shell -D -f gdb-devel.scm
 @end example
 
+@anchor{shell-manifest}
 @item --manifest=@var{file}
 @itemx -m @var{file}
 Create an environment for the packages contained in the manifest object
@@ -5847,6 +5848,56 @@ This is similar to the same-named option in @command{guix package}
 (@pxref{profile-manifest, @option{--manifest}}) and uses the same
 manifest files.
 
+@xref{Writing Manifests}, for information on how to write a manifest.
+See @option{--export-manifest} below on how to obtain a first manifest.
+
+@cindex manifest, exporting
+@anchor{shell-export-manifest}
+@item --export-manifest
+Write to standard output a manifest suitable for @option{--manifest}
+corresponding to given command-line options.
+
+This is a way to ``convert'' command-line arguments into a manifest.
+For example, imagine you are tired of typing long lines and would like
+to get a manifest equivalent to this command line:
+
+@example
+guix shell -D guile git emacs emacs-geiser emacs-geiser-guile
+@end example
+
+Just add @option{--export-manifest} to the command line above:
+
+@example
+guix shell --export-manifest \
+  -D guile git emacs emacs-geiser emacs-geiser-guile
+@end example
+
+@noindent
+... and you get a manifest along these lines:
+
+@lisp
+(concatenate-manifests
+  (list (specifications->manifest
+          (list "git"
+                "emacs"
+                "emacs-geiser"
+                "emacs-geiser-guile"))
+        (package->development-manifest
+          (specification->package "guile"))))
+@end lisp
+
+You can store it into a file, say @file{manifest.scm}, and from there
+pass it to @command{guix shell} or indeed pretty much any @command{guix}
+command:
+
+@example
+guix shell -m manifest.scm
+@end example
+
+Voilà, you've converted a long command line into a manifest!  That
+conversion process honors package transformation options (@pxref{Package
+Transformation Options}) so it should be lossless.
+
 @item --profile=@var{profile}
 @itemx -p @var{profile}
 Create an environment containing the packages installed in @var{profile}. 
@@ -6234,6 +6285,10 @@ This is similar to the same-named option in @command{guix package}
 (@pxref{profile-manifest, @option{--manifest}}) and uses the same
 manifest files.
 
+@xref{shell-export-manifest, @command{guix shell --export-manifest}},
+for information on how to ``convert'' command-line options into a
+manifest.
+
 @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
@@ -6678,6 +6733,7 @@ This has the same purpose as the same-named option in @command{guix
 build} (@pxref{Additional Build Options, @option{--expression} in
 @command{guix build}}).
 
+@anchor{pack-manifest}
 @item --manifest=@var{file}
 @itemx -m @var{file}
 Use the packages contained in the manifest object returned by the Scheme
@@ -6692,6 +6748,11 @@ for use on machines that do not have Guix installed.  Note that you can
 specify @emph{either} a manifest file @emph{or} a list of packages,
 but not both.
 
+@xref{Writing Manifests}, for information on how to write a manifest.
+@xref{shell-export-manifest, @command{guix shell --export-manifest}},
+for information on how to ``convert'' command-line options into a
+manifest.
+
 @item --system=@var{system}
 @itemx -s @var{system}
 Attempt to build for @var{system}---e.g., @code{i686-linux}---instead of
@@ -6894,6 +6955,7 @@ package definitions.
 * Package Modules::             Packages from the programmer's viewpoint.
 * Defining Packages::           Defining new packages.
 * Defining Package Variants::   Customizing packages.
+* Writing Manifests::           The bill of materials of your environment.
 * Build Systems::               Specifying how packages are built.
 * Build Phases::                Phases of the build process of a package.
 * Build Utilities::             Helpers for your package definitions and more.
@@ -7303,7 +7365,8 @@ for details.
 A one-line description of the package.
 
 @item @code{description}
-A more elaborate description of the package.
+A more elaborate description of the package, as a string in Texinfo
+syntax.
 
 @item @code{license}
 @cindex license, of packages
@@ -7898,6 +7961,312 @@ when @var{cut?} returns true for a given package.  When @var{deep?} is true, @va
 applied to implicit inputs as well.
 @end deffn
 
+@node Writing Manifests
+@section Writing Manifests
+
+@cindex manifest
+@cindex bill of materials (manifests)
+@command{guix} commands let you specify package lists on the command
+line.  This is convenient, but as the command line becomes longer and
+less trivial, it quickly becomes more convenient to have that package
+list in what we call a @dfn{manifest}.  A manifest is some sort of a
+``bill of materials'' that defines a package set.  You would typically
+come up with a code snippet that builds the manifest, store it in a
+file, say @file{manifest.scm}, and then pass that file to the
+@option{-m} (or @option{--manifest}) option that many @command{guix}
+commands support.  For example, here's what a manifest for a simple
+package set might look like:
+
+@lisp
+;; Manifest for three packages.
+(specifications->manifest '("gcc-toolchain" "make" "git"))
+@end lisp
+
+Once you have that manifest, you can pass it, for example, to
+@command{guix package} to install just those three packages to your
+profile (@pxref{profile-manifest, @option{-m} option of @command{guix
+package}}):
+
+@example
+guix package -m manifest.scm
+@end example
+
+@noindent
+... or you can pass it to @command{guix shell} (@pxref{shell-manifest,
+@command{-m} option of @command{guix shell}}) to spawn an ephemeral
+environment:
+
+@example
+guix shell -m manifest.scm
+@end example
+
+@noindent
+... or you can pass it to @command{guix pack} in pretty much the same
+way (@pxref{pack-manifest, @option{-m} option of @command{guix pack}}).
+You can store the manifest under version control, share it with others
+so they can easily get set up, etc.
+
+But how do you write your first manifest?  To get started, maybe you'll
+want to write a manifest that mirrors what you already have in a
+profile.  Rather than start from a blank page, @command{guix package}
+can generate a manifest for you (@pxref{export-manifest, @command{guix
+package --export-manifest}}):
+
+@example
+# Write to 'manifest.scm' a manifest corresponding to the
+# default profile, ~/.guix-profile.
+guix package --export-manifest > manifest.scm
+@end example
+
+Or maybe you'll want to ``translate'' command-line arguments into a
+manifest.  In that case, @command{guix shell} can help
+(@pxref{shell-export-manifest, @command{guix shell --export-manifest}}):
+
+@example
+# Write a manifest for the packages specified on the command line.
+guix shell --export-manifest gcc-toolchain make git > manifest.scm
+@end example
+
+In both cases, the @option{--export-manifest} option tries hard to
+generate a faithful manifest; in particular, it takes package
+transformation options into account (@pxref{Package Transformation
+Options}).
+
+@quotation Note
+Manifests are @emph{symbolic}: they refer to packages of the channels
+@emph{currently in use} (@pxref{Channels}).  In the example above,
+@code{gcc-toolchain} might refer to version 11 today, but it might refer
+to version 13 two years from now.
+
+If you want to ``pin'' your software environment to specific package
+versions and variants, you need an additional piece of information: the
+list of channel revisions in use, as returned by @command{guix
+describe}.  @xref{Replicating Guix}, for more information.
+@end quotation
+
+Once you've obtained your first manifest, perhaps you'll want to
+customize it.  Since your manifest is code, you now have access to all
+the Guix programming interfaces!
+
+Let's assume you want a manifest to deploy a custom variant of GDB, the
+GNU Debugger, that does not depend on Guile, together with another
+package.  Building on the example seen in the previous section
+(@pxref{Defining Package Variants}), you can write a manifest along
+these lines:
+
+@lisp
+(use-modules (guix packages)
+             (gnu packages gdb)               ;for 'gdb'
+             (gnu packages version-control))  ;for 'git'
+
+;; Define a variant of GDB without a dependency on Guile.
+(define gdb-sans-guile
+  (package
+    (inherit gdb)
+    (inputs (modify-inputs (package-inputs gdb)
+              (delete "guile")))))
+
+;; Return a manifest containing that one package plus Git.
+(packages->manifest (list gdb-sans-guile git))
+@end lisp
+
+Note that in this example, the manifest directly refers to the
+@code{gdb} and @code{git} variables, which are bound to a @code{package}
+object (@pxref{package Reference}), instead of calling
+@code{specifications->manifest} to look up packages by name as we did
+before.  The @code{use-modules} form at the top lets us access the core
+package interface (@pxref{Defining Packages}) and the modules that
+define @code{gdb} and @code{git} (@pxref{Package Modules}).  Seamlessly,
+we're weaving all this together---the possibilities are endless, unleash
+your creativity!
+
+The data type for manifests as well as supporting procedures are defined
+in the @code{(guix profiles)} module, which is automatically available
+to code passed to @option{-m}.  The reference follows.
+
+@deftp {Data Type} manifest
+Data type representing a manifest.
+
+It currently has one field:
+
+@table @code
+@item entries
+This must be a list of @code{manifest-entry} records---see below.
+@end table
+@end deftp
+
+@deftp {Data Type} manifest-entry
+Data type representing a manifest entry.  A manifest entry contains
+essential metadata: a name and version string, the object (usually a
+package) for that entry, the desired output (@pxref{Packages with
+Multiple Outputs}), and a number of optional pieces of information
+detailed below.
+
+Most of the time, you won't build a manifest entry directly; instead,
+you will pass a package to @code{package->manifest-entry}, described
+below.  In some unusual cases though, you might want to create manifest
+entries for things that are @emph{not} packages, as in this example:
+
+@lisp
+;; Manually build a single manifest entry for a non-package object.
+(let ((hello (program-file "hello" #~(display "Hi!"))))
+  (manifest-entry
+    (name "foo")
+    (version "42")
+    (item
+     (computed-file "hello-directory"
+                     #~(let ((bin (string-append #$output "/bin")))
+                         (mkdir #$output) (mkdir bin)
+                          (symlink #$hello
+                                   (string-append bin "/hello")))))))
+@end lisp
+
+The available fields are the following:
+
+@table @asis
+@item @code{name}
+@itemx @code{version}
+Name and version string for this entry.
+
+@item @code{item}
+A package or other file-like object (@pxref{G-Expressions, file-like
+objects}).
+
+@item @code{output} (default: @code{"out"})
+Output of @code{item} to use, in case @code{item} has multiple outputs
+(@pxref{Packages with Multiple Outputs}).
+
+@item @code{dependencies} (default: @code{'()})
+List of manifest entries this entry depends on.  When building a
+profile, dependencies are added to the profile.
+
+Typically, the propagated inputs of a package (@pxref{package Reference,
+@code{propagated-inputs}}) end up having a corresponding manifest entry
+in among the dependencies of the package's own manifest entry.
+
+@item @code{search-paths} (default: @code{'()})
+The list of search path specifications honored by this entry
+(@pxref{Search Paths}).
+
+@item @code{properties} (default: @code{'()})
+List of symbol/value pairs.  When building a profile, those properties
+get serialized.
+
+This can be used to piggyback additional metadata---e.g., the
+transformations applied to a package (@pxref{Package Transformation
+Options}).
+
+@item @code{parent} (default: @code{(delay #f)})
+A promise pointing to the ``parent'' manifest entry.
+
+This is used as a hint to provide context when reporting an error
+related to a manifest entry coming from a @code{dependencies} field.
+@end table
+@end deftp
+
+@deffn {Scheme Procedure} concatenate-manifests @var{lst}
+Concatenate the manifests listed in @var{lst} and return the resulting
+manifest.
+@end deffn
+
+@c TODO: <manifest-pattern>, manifest-lookup, manifest-remove, etc.
+
+@deffn {Scheme Procedure} package->manifest-entry @var{package} @
+  [@var{output}] [#:properties]
+Return a manifest entry for the @var{output} of package @var{package},
+where @var{output} defaults to @code{"out"}, and with the given
+@var{properties}.  By default @var{properties} is the empty list or, if
+one or more package transformations were applied to @var{package}, it is
+an association list representing those transformations, suitable as an
+argument to @code{options->transformation} (@pxref{Defining Package
+Variants, @code{options->transformation}}).
+
+The code snippet below builds a manifest with an entry for the default
+output and the @code{send-email} output of the @code{git} package:
+
+@lisp
+(use-modules (gnu packages version-control))
+
+(manifest (list (package->manifest-entry git)
+                (package->manifest-entry git "send-email")))
+@end lisp
+@end deffn
+
+@deffn {Scheme Procedure} packages->manifest @var{packages}
+Return a list of manifest entries, one for each item listed in
+@var{packages}.  Elements of @var{packages} can be either package
+objects or package/string tuples denoting a specific output of a
+package.
+
+Using this procedure, the manifest above may be rewritten more
+concisely:
+
+@lisp
+(use-modules (gnu packages version-control))
+
+(packages->manifest (list git `(,git "send-email")))
+@end lisp
+@end deffn
+
+@anchor{package-development-manifest}
+@deffn {Scheme Procedure} package->development-manifest @var{package} @
+  [@var{system}] [#:target]
+Return a manifest for the @dfn{development inputs} of @var{package} for
+@var{system}, optionally when cross-compiling to @var{target}.
+Development inputs include both explicit and implicit inputs of
+@var{package}.
+
+Like the @option{-D} option of @command{guix shell}
+(@pxref{shell-development-option, @command{guix shell -D}}), the
+resulting manifest describes the environment in which one can develop
+@var{package}.  For example, suppose you're willing to set up a
+development environment for Inkscape, with the addition of Git for
+version control; you can describe that ``bill of materials'' with the
+following manifest:
+
+@lisp
+(use-modules (gnu packages inkscape)          ;for 'inkscape'
+             (gnu packages version-control))  ;for 'git'
+
+(concatenate-manifests
+ (list (package->development-manifest inkscape)
+       (packages->manifest (list git))))
+@end lisp
+
+In this example, the development manifest that
+@code{package->development-manifest} returns includes the compiler
+(GCC), the many supporting libraries (Boost, GLib, GTK, etc.), and a
+couple of additional development tools---these are the dependencies
+@command{guix show inkscape} lists.
+@end deffn
+
+@c TODO: Move (gnu packages) interface to a section of its own.
+
+Last, the @code{(gnu packages)} module provides higher-level facilities
+to build manifests.  In particular, it lets you look up packages by
+name---see below.
+
+@deffn {Scheme Procedure} specifications->manifest @var{specs}
+Given @var{specs}, a list of specifications such as @code{"emacs@@25.2"}
+or @code{"guile:debug"}, return a manifest.  Specs have the format that
+command-line tools such as @command{guix install} and @command{guix
+package} understand (@pxref{Invoking guix package}).
+
+As an example, it lets you rewrite the Git manifest that we saw earlier
+like this:
+
+@lisp
+(specifications->manifest '("git" "git:send-email"))
+@end lisp
+
+Notice that we do not need to worry about @code{use-modules}, importing
+the right set of modules, and referring to the right variables.
+Instead, we directly refer to packages in the same way as on the command
+line, which can often be more convenient.
+@end deffn
+
+@c TODO: specifications->package, etc.
+
 
 @node Build Systems
 @section Build Systems
@@ -8355,6 +8724,60 @@ only one of them.  This is equivalent to passing the @code{-p} argument to
 
 @end defvr
 
+@defvr {Scheme variable} elm-build-system
+This variable is exported by @code{(guix build-system elm)}.  It implements a
+build procedure for @url{https://elm-lang.org, Elm} packages similar to
+@samp{elm install}.
+
+The build system adds an Elm compiler package to the set of inputs.  The
+default compiler package (currently @code{elm-sans-reactor}) can be overridden
+using the @code{#:elm} argument.  Additionally, Elm packages needed by the
+build system itself are added as implicit inputs if they are not already
+present: to suppress this behavior, use the
+@code{#:implicit-elm-package-inputs?} argument, which is primarily useful for
+bootstrapping.
+
+The @code{"dependencies"} and @code{"test-dependencies"} in an Elm package's
+@file{elm.json} file correspond to @code{propagated-inputs} and @code{inputs},
+respectively.
+
+Elm requires a particular structure for package names: @pxref{Elm Packages}
+for more details, including utilities provided by @code{(guix build-system
+elm)}.
+
+There are currently a few noteworthy limitations to @code{elm-build-system}:
+
+@itemize
+@item
+The build system is focused on @dfn{packages} in the Elm sense of the word:
+Elm @dfn{projects} which declare @code{@{ "type": "package" @}} in their
+@file{elm.json} files.  Using @code{elm-build-system} to build Elm
+@dfn{applications} (which declare @code{@{ "type": "application" @}}) is
+possible, but requires ad-hoc modifications to the build phases.  For
+examples, see the definitions of the @code{elm-todomvc} example application and
+the @code{elm} package itself (because the front-end for the
+@samp{elm reactor} command is an Elm application).
+
+@item
+Elm supports multiple versions of a package coexisting simultaneously under
+@env{ELM_HOME}, but this does not yet work well with @code{elm-build-system}.
+This limitation primarily affects Elm applications, because they specify
+exact versions for their dependencies, whereas Elm packages specify supported
+version ranges.  As a workaround, the example applications mentioned above use
+the @code{patch-application-dependencies} procedure provided by
+@code{(guix build elm-build-system)} to rewrite their @file{elm.json} files to
+refer to the package versions actually present in the build environment.
+Alternatively, Guix package transformations (@pxref{Defining Package
+Variants}) could be used to rewrite an application's entire dependency graph.
+
+@item
+We are not yet able to run tests for Elm projects because neither
+@url{https://github.com/mpizenberg/elm-test-rs, @command{elm-test-rs}} nor the
+Node.js-based @url{https://github.com/rtfeldman/node-test-runner,
+@command{elm-test}} runner has been packaged for Guix yet.
+@end itemize
+@end defvr
+
 @defvr {Scheme Variable} go-build-system
 This variable is exported by @code{(guix build-system go)}.  It
 implements a build procedure for Go packages using the standard
@@ -9779,6 +10202,25 @@ Again, the libxml2 example shows a situation where this is needed.
 @end table
 @end deftp
 
+Some search paths are not tied by a single package but to many packages.
+To reduce duplications, some of them are pre-defined in @code{(guix
+search-paths)}.
+
+@defvr {Scheme Variable} $SSL_CERT_DIR
+@defvrx {Scheme Variable} $SSL_CERT_FILE
+These two search paths indicate where X.509 certificates can be found
+(@pxref{X.509 Certificates}).
+@end defvr
+
+These pre-defined search paths can be used as in the following example:
+
+@lisp
+(package
+  (name "curl")
+  ;; some fields omitted ...
+  (native-search-paths (list $SSL_CERT_DIR $SSL_CERT_FILE)))
+@end lisp
+
 How do you turn search path specifications on one hand and a bunch of
 directories on the other hand in a set of environment variable
 definitions?  That's the job of @code{evaluate-search-paths}.
@@ -11970,6 +12412,14 @@ Cross-build for @var{triplet}, which must be a valid GNU triplet, such
 as @code{"aarch64-linux-gnu"} (@pxref{Specifying Target Triplets, GNU
 configuration triplets,, autoconf, Autoconf}).
 
+@item --list-systems
+List all the supported systems, that can be passed as an argument to
+@option{--system}.
+
+@item --list-targets
+List all the supported targets, that can be passed as an argument to
+@option{--target}.
+
 @anchor{build-check}
 @item --check
 @cindex determinism, checking
@@ -12033,8 +12483,8 @@ If a log is unavailable locally, and unless @option{--no-substitutes} is
 passed, the command looks for a corresponding log on one of the
 substitute servers (as specified with @option{--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:
+So for instance, imagine you want to see the build log of GDB on
+@code{aarch64}, but you are actually on an @code{x86_64} machine:
 
 @example
 $ guix build --log-file gdb -s aarch64-linux
@@ -12733,6 +13183,31 @@ and generate package expressions for all those packages that are not yet
 in Guix.
 @end table
 
+@item elm
+@cindex elm
+Import metadata from the Elm package repository
+@uref{https://package.elm-lang.org, package.elm-lang.org}, as in this example:
+
+@example
+guix import elm elm-explorations/webgl
+@end example
+
+The Elm importer also allows you to specify a version string:
+
+@example
+guix import elm elm-explorations/webgl@@1.1.3
+@end example
+
+Additional options include:
+
+@table @code
+@item --recursive
+@itemx -r
+Traverse the dependency graph of the given upstream package recursively
+and generate package expressions for all those packages that are not yet
+in Guix.
+@end table
+
 @item opam
 @cindex OPAM
 @cindex OCaml
@@ -13991,6 +14466,11 @@ spawn an HTTP server on port 8080:
 guix publish
 @end example
 
+@cindex socket activation, for @command{guix publish}
+@command{guix publish} can also be started following the systemd
+``socket activation'' protocol (@pxref{Service De- and Constructors,
+@code{make-systemd-constructor},, shepherd, The GNU Shepherd Manual}).
+
 Once a publishing server has been authorized, the daemon may download
 substitutes from it.  @xref{Getting Substitutes from Other Servers}.
 
@@ -14746,6 +15226,168 @@ Session_PID: 4278
 @end table
 @end table
 
+@node Foreign Architectures
+@chapter Foreign Architectures
+
+You can target computers of different CPU architectures when producing
+packages (@pxref{Invoking guix package}), packs (@pxref{Invoking guix
+pack}) or full systems (@pxref{Invoking guix system}).
+
+GNU Guix supports two distinct mechanisms to target foreign
+architectures:
+
+@enumerate
+@item
+The traditional
+@uref{https://en.wikipedia.org/wiki/Cross_compiler,cross-compilation}
+mechanism.
+@item
+The native building mechanism which consists in building using the CPU
+instruction set of the foreign system you are targeting.  It often
+requires emulation, using the QEMU program for instance.
+@end enumerate
+
+@menu
+* Cross-Compilation::   Cross-compiling for another architecture.
+* Native Builds::       Targeting another architecture through native builds.
+@end menu
+
+@node Cross-Compilation
+@section Cross-Compilation
+
+@cindex foreign architectures
+The commands supporting cross-compilation are proposing the
+@option{--list-targets} and @option{--target} options.
+
+The @option{--list-targets} option lists all the supported targets that
+can be passed as an argument to @option{--target}.
+
+@example
+$ guix build --list-targets
+The available targets are:
+
+   - aarch64-linux-gnu
+   - arm-linux-gnueabihf
+   - i586-pc-gnu
+   - i686-linux-gnu
+   - i686-w64-mingw32
+   - mips64el-linux-gnu
+   - powerpc-linux-gnu
+   - powerpc64le-linux-gnu
+   - riscv64-linux-gnu
+   - x86_64-linux-gnu
+   - x86_64-w64-mingw32
+@end example
+
+Targets are specified as GNU triplets (@pxref{Specifying Target
+Triplets, GNU configuration triplets,, autoconf, Autoconf}).
+
+Those triplets are passed to GCC and the other underlying compilers
+possibly involved when building a package, a system image or any other
+GNU Guix output.
+
+@example
+$ guix build --target=aarch64-linux-gnu hello
+/gnu/store/9926by9qrxa91ijkhw9ndgwp4bn24g9h-hello-2.12
+
+$ file /gnu/store/9926by9qrxa91ijkhw9ndgwp4bn24g9h-hello-2.12/bin/hello
+/gnu/store/9926by9qrxa91ijkhw9ndgwp4bn24g9h-hello-2.12/bin/hello: ELF
+64-bit LSB executable, ARM aarch64 @dots{}
+@end example
+
+The major benefit of cross-compilation is that there are no performance
+penaly compared to emulation using QEMU.  There are however higher risks
+that some packages fail to cross-compile because few users are using
+this mechanism extensively.
+
+@node Native Builds
+@section Native Builds
+
+The commands that support impersonating a specific system have the
+@option{--list-systems} and @option{--system} options.
+
+The @option{--list-systems} option lists all the supported systems that
+can be passed as an argument to @option{--system}.
+
+@example
+$ guix build --list-systems
+The available systems are:
+
+   - x86_64-linux [current]
+   - aarch64-linux
+   - armhf-linux
+   - i586-gnu
+   - i686-linux
+   - mips64el-linux
+   - powerpc-linux
+   - powerpc64le-linux
+   - riscv64-linux
+
+$ guix build --system=i686-linux hello
+/gnu/store/cc0km35s8x2z4pmwkrqqjx46i8b1i3gm-hello-2.12
+
+$ file /gnu/store/cc0km35s8x2z4pmwkrqqjx46i8b1i3gm-hello-2.12/bin/hello
+/gnu/store/cc0km35s8x2z4pmwkrqqjx46i8b1i3gm-hello-2.12/bin/hello: ELF
+32-bit LSB executable, Intel 80386 @dots{}
+@end example
+
+In the above example, the current system is @var{x86_64-linux}.  The
+@var{hello} package is however built for the @var{i686-linux} system.
+
+This is possible because the @var{i686} CPU instruction set is a subset
+of the @var{x86_64}, hence @var{i686} targeting binaries can be run on
+@var{x86_64}.
+
+Still in the context of the previous example, if picking the
+@var{aarch64-linux} system and the @command{guix build
+--system=aarch64-linux hello} has to build some derivations, an extra
+step might be needed.
+
+The @var{aarch64-linux} targeting binaries cannot directly be run on a
+@var{x86_64-linux} system.  An emulation layer is requested.  The GNU
+Guix daemon can take advantage of the Linux kernel
+@uref{https://en.wikipedia.org/wiki/Binfmt_misc,binfmt_misc} mechanism
+for that.  In short, the Linux kernel can defer the execution of a
+binary targeting a foreign platform, here @var{aarch64-linux}, to a
+userspace program, usually an emulator.
+
+There is a service that registers QEMU as a backend for the
+@code{binfmt_misc} mechanism (@pxref{Virtualization Services,
+@code{qemu-binfmt-service-type}}).  On Debian based foreign
+distributions, the alternative would be the @code{qemu-user-static}
+package.
+
+If the @code{binfmt_misc} mechanism is not setup correctly, the building
+will fail this way:
+
+@example
+$ guix build --system=armhf-linux hello --check
+@dots{}
+@ unsupported-platform /gnu/store/jjn969pijv7hff62025yxpfmc8zy0aq0-hello-2.12.drv aarch64-linux
+while setting up the build environment: a `aarch64-linux' is required to
+build `/gnu/store/jjn969pijv7hff62025yxpfmc8zy0aq0-hello-2.12.drv', but
+I am a `x86_64-linux'@dots{}
+@end example
+
+whereas, with the @code{binfmt_misc} mechanism correctly linked with
+QEMU, one can expect to see:
+
+@example
+$ guix build --system=armhf-linux hello --check
+/gnu/store/13xz4nghg39wpymivlwghy08yzj97hlj-hello-2.12
+@end example
+
+The main advantage of native building compared to cross-compiling, is
+that more packages are likely to build correctly.  However it comes at a
+price: compilation backed by QEMU is @emph{way slower} than
+cross-compilation, because every instruction needs to be emulated.
+
+The availability of substitutes for the architecture targeted by the
+@code{--system} option can mitigate this problem.  An other way to work
+around it is to install GNU Guix on a machine which CPU is supporting
+the targeted instruction set, an set it up as an offload machine
+(@pxref{Daemon Offload Setup}).
+
 @node System Configuration
 @chapter System Configuration
 
@@ -17649,6 +18291,44 @@ The list of syslog-controlled files to be rotated.  By default it is:
 "/var/log/maillog")}.
 @end defvr
 
+Some log files just need to be deleted periodically once they are old,
+without any other criterion and without any archival step.  This is the
+case of build logs stored by @command{guix-daemon} under
+@file{/var/log/guix/drvs} (@pxref{Invoking guix-daemon}).  The
+@code{log-cleanup} service addresses this use case.  For example,
+@code{%base-services} (@pxref{Base Services}) includes the following:
+
+@lisp
+;; Periodically delete old build logs.
+(service log-cleanup-service-type
+         (log-cleanup-configuration
+          (directory "/var/log/guix/drvs")))
+@end lisp
+
+That ensures build logs do not accumulate endlessly.
+
+@defvr {Scheme Variable} log-cleanup-service-type
+This is the type of the service to delete old logs.  Its value must be a
+@code{log-cleanup-configuration} record as described below.
+@end defvr
+
+@deftp {Data Type} log-cleanup-configuration
+Data type representing the log cleanup configuration
+
+@table @asis
+@item @code{directory}
+Name of the directory containing log files.
+
+@item @code{expiry} (default: @code{(* 6 30 24 3600)})
+Age in seconds after which a file is subject to deletion (six months by
+default).
+
+@item @code{schedule} (default: @code{"30 12 01,08,15,22 * *"})
+String or gexp denoting the corresponding mcron job schedule
+(@pxref{Scheduled Job Execution}).
+@end table
+@end deftp
+
 @node Networking Setup
 @subsection Networking Setup
 
@@ -17989,20 +18669,6 @@ List of additional command-line arguments to pass to the daemon.
 @end table
 @end deftp
 
-@cindex wicd
-@cindex wireless
-@cindex WiFi
-@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.
-@end deffn
-
 @cindex ModemManager
 Some networking devices such as modems require special care, and this is
 what the services below focus on.
@@ -18874,6 +19540,12 @@ Name of the file where @command{sshd} writes its PID.
 @item @code{port-number} (default: @code{22})
 TCP port on which @command{sshd} listens for incoming connections.
 
+@item @code{max-connections} (default: @code{200})
+Hard limit on the maximum number of simultaneous client connections,
+enforced by the inetd-style Shepherd service (@pxref{Service De- and
+Constructors, @code{make-inetd-constructor},, shepherd, The GNU Shepherd
+Manual}).
+
 @item @code{permit-root-login} (default: @code{#f})
 This field determines whether and when to allow logins as root.  If
 @code{#f}, root logins are disallowed; if @code{#t}, they are allowed.
@@ -19393,19 +20065,12 @@ signing and encryption keys are defined in @file{/etc/yggdrasil-private.conf}
 @example
 # sample content for /etc/yggdrasil-private.conf
 @{
-  # Your public encryption key. Your peers may ask you for this to put
-  # into their AllowedEncryptionPublicKeys configuration.
-  EncryptionPublicKey: 378dc5...
-
-  # Your private encryption key. DO NOT share this with anyone!
-  EncryptionPrivateKey: 0777...
+  # Your public key. Your peers may ask you for this to put
+  # into their AllowedPublicKeys configuration.
+  PublicKey: 64277...
 
-  # Your public signing key. You should not ordinarily need to share
-  # this with anyone.
-  SigningPublicKey: e1664...
-
-  # Your private signing key. DO NOT share this with anyone!
-  SigningPrivateKey: 0589d...
+  # Your private key. DO NOT share this with anyone!
+  PrivateKey: 5c750...
 @}
 @end example
 @end defvr
@@ -19862,10 +20527,31 @@ The default SLiM theme and its name.
 @end defvr
 
 
+@cindex login manager
+@cindex X11 login
+@defvr {Scheme Variable} sddm-service-type
+This is the type of the service to run the
+@uref{https://github.com/sddm/sddm,SDDM display manager}.  Its value
+must be a @code{sddm-configuration} record (see below).
+
+Here's an example use:
+
+@lisp
+(service sddm-service-type
+         (sddm-configuration
+           (auto-login-user "alice")
+           (auto-login-session "xfce.desktop")))
+@end lisp
+@end defvr
+
 @deftp {Data Type} sddm-configuration
-This is the data type representing the SDDM service configuration.
+This data type represents the configuration of the SDDM login manager.
+The available fields are:
 
 @table @asis
+@item @code{sddm} (default: @code{sddm})
+The SDDM package to use.
+
 @item @code{display-server} (default: "x11")
 Select display server to use for the greeter.  Valid values are
 @samp{"x11"} or @samp{"wayland"}.
@@ -19941,10 +20627,11 @@ Directory to look for desktop files starting X sessions.
 Minimum VT to use.
 
 @item @code{auto-login-user} (default "")
-User to use for auto-login.
+User account that will be automatically logged in.
+Setting this to the empty string disables auto-login.
 
 @item @code{auto-login-session} (default "")
-Desktop file to use for auto-login.
+The @file{.desktop} file name to use as the auto-login session, or the empty string.
 
 @item @code{relogin?} (default #f)
 Relogin after logout.
@@ -19952,45 +20639,6 @@ Relogin after logout.
 @end table
 @end deftp
 
-@cindex login manager
-@cindex X11 login
-@defvr {Scheme Variable} sddm-service-type
-This is the type of the service to run the
-@uref{https://github.com/sddm/sddm,SDDM display manager}.  Its value
-must be a @code{sddm-configuration} record (see below).
-
-Here's an example use:
-
-@lisp
-(service sddm-service-type
-         (sddm-configuration
-           (auto-login-user "alice")
-           (auto-login-session "xfce.desktop")))
-@end lisp
-@end defvr
-
-@deftp {Data Type} sddm-configuration
-This data type represents the configuration of the SDDM login manager.
-The available fields are:
-
-@table @asis
-@item @code{sddm} (default: @code{sddm})
-The SDDM package to use.
-
-@item @code{display-server} (default: @code{"x11"})
-This must be either @code{"x11"} or @code{"wayland"}.
-
-@c FIXME: Add more fields.
-
-@item @code{auto-login-user} (default: @code{""})
-If non-empty, this is the user account under which to log in
-automatically.
-
-@item @code{auto-login-session} (default: @code{""})
-If non-empty, this is the @file{.desktop} file name to use as the
-auto-login session.
-@end table
-@end deftp
 
 @cindex Xorg, configuration
 @deftp {Data Type} xorg-configuration
@@ -21658,23 +22306,23 @@ LE scanning interval used for connection establishment.
 LE scanning window used for connection establishment.
 
 @item @code{min-connection-interval} (default: @code{#f})
-LE default minimum connection interval. This value is superceeded by any specific
+LE default minimum connection interval. This value is superseded by any specific
 value provided via the Load Connection Parameters interface.
 
 @item @code{max-connection-interval} (default: @code{#f})
-LE default maximum connection interval. This value is superceeded by any specific
+LE default maximum connection interval. This value is superseded by any specific
 value provided via the Load Connection Parameters interface.
 
 @item @code{connection-latency} (default: @code{#f})
-LE default connection latency. This value is superceeded by any specific
+LE default connection latency. This value is superseded by any specific
 value provided via the Load Connection Parameters interface.
 
 @item @code{connection-supervision-timeout} (default: @code{#f})
-LE default connection supervision timeout. This value is superceeded by any specific
+LE default connection supervision timeout. This value is superseded by any specific
 value provided via the Load Connection Parameters interface.
 
 @item @code{autoconnect-timeout} (default: @code{#f})
-LE default autoconnect timeout. This value is superceeded by any specific
+LE default autoconnect timeout. This value is superseded by any specific
 value provided via the Load Connection Parameters interface.
 
 @item @code{adv-mon-allowlist-scan-duration} (default: @code{300})
@@ -24951,21 +25599,21 @@ account fingerprint for a registered username.
 
 @end deftp
 
-@subsubheading Murmur (VoIP server)
+@subsubheading Mumble server
 
-@cindex Murmur (VoIP server)
+@cindex Mumble
+@cindex Murmur
 @cindex VoIP server
-This section describes how to set up and run a Murmur server.  Murmur is
-the server of the @uref{https://mumble.info, Mumble} voice-over-IP
-(VoIP) suite.
+This section describes how to set up and run a
+@uref{https://mumble.info, Mumble} server (formerly known as Murmur).
 
-@deftp {Data Type} murmur-configuration
-The service type for the Murmur server.  An example configuration can
+@deftp {Data Type} mumble-server-configuration
+The service type for the Mumble server.  An example configuration can
 look like this:
 
 @lisp
-(service murmur-service-type
-         (murmur-configuration
+(service mumble-server-service-type
+         (mumble-server-configuration
           (welcome-text
             "Welcome to this Mumble server running on Guix!")
           (cert-required? #t) ;disallow text password logins
@@ -24973,7 +25621,8 @@ look like this:
           (ssl-key "/etc/letsencrypt/live/mumble.example.com/privkey.pem")))
 @end lisp
 
-After reconfiguring your system, you can manually set the murmur @code{SuperUser}
+After reconfiguring your system, you can manually set the mumble-server
+@code{SuperUser}
 password with the command that is printed during the activation phase.
 
 It is recommended to register a normal Mumble user account
@@ -24985,17 +25634,17 @@ the @code{SuperUser} password that you set previously,
 and grant your newly registered mumble user administrator or moderator
 rights and create some channels.
 
-Available @code{murmur-configuration} fields are:
+Available @code{mumble-server-configuration} fields are:
 
 @table @asis
 @item @code{package} (default: @code{mumble})
-Package that contains @code{bin/murmurd}.
+Package that contains @code{bin/mumble-server}.
 
-@item @code{user} (default: @code{"murmur"})
-User who will run the Murmur server.
+@item @code{user} (default: @code{"mumble-server"})
+User who will run the Mumble-Server server.
 
-@item @code{group} (default: @code{"murmur"})
-Group of the user who will run the murmur server.
+@item @code{group} (default: @code{"mumble-server"})
+Group of the user who will run the mumble-server server.
 
 @item @code{port} (default: @code{64738})
 Port on which the server will listen.
@@ -25012,11 +25661,11 @@ Maximum of users that can be connected to the server at once.
 @item @code{max-user-bandwidth} (default: @code{#f})
 Maximum voice traffic a user can send per second.
 
-@item @code{database-file} (default: @code{"/var/lib/murmur/db.sqlite"})
+@item @code{database-file} (default: @code{"/var/lib/mumble-server/db.sqlite"})
 File name of the sqlite database.
 The service's user will become the owner of the directory.
 
-@item @code{log-file} (default: @code{"/var/log/murmur/murmur.log"})
+@item @code{log-file} (default: @code{"/var/log/mumble-server/mumble-server.log"})
 File name of the log file.
 The service's user will become the owner of the directory.
 
@@ -25055,8 +25704,9 @@ If it is set to @code{#t} clients that use weak password authentication
 will not be accepted.  Users must have completed the certificate wizard to join.
 
 @item @code{remember-channel?} (default: @code{#f})
-Should murmur remember the last channel each user was in when they disconnected
-and put them into the remembered channel when they rejoin.
+Should mumble-server remember the last channel each user was in when
+they disconnected and put them into the remembered channel when they
+rejoin.
 
 @item @code{allow-html?} (default: @code{#f})
 Should html be allowed in text messages, user comments, and channel descriptions.
@@ -25072,10 +25722,10 @@ Disabling this setting will prevent public listing of the server.
 Should the server advertise itself in the local network through the bonjour protocol.
 
 @item @code{send-version?} (default: @code{#f})
-Should the murmur server version be exposed in ping requests.
+Should the mumble-server server version be exposed in ping requests.
 
 @item @code{log-days} (default: @code{31})
-Murmur also stores logs in the database, which are accessible via RPC.
+Mumble also stores logs in the database, which are accessible via RPC.
 The default is 31 days of months, but you can set this setting to 0 to keep logs forever,
 or -1 to disable logging to the database.
 
@@ -25108,17 +25758,19 @@ This option is specified using
 @uref{https://www.openssl.org/docs/apps/ciphers.html#CIPHER-LIST-FORMAT,
 OpenSSL cipher list notation}.
 
-It is recommended that you try your cipher string using 'openssl ciphers <string>'
-before setting it here, to get a feel for which cipher suites you will get.
-After setting this option, it is recommend that you inspect your Murmur log
-to ensure that Murmur is using the cipher suites that you expected it to.
+It is recommended that you try your cipher string using
+'openssl ciphers <string>' before setting it here, to get a feel for
+which cipher suites you will get.
+After setting this option, it is recommend that you inspect your Mumble
+server log to ensure that Mumble is using the cipher suites that you
+expected it to.
 
 Note: Changing this option may impact the backwards compatibility of your
-Murmur server, and can remove the ability for older Mumble clients to be able
-to connect to it.
+Mumble-Server server, and can remove the ability for older Mumble clients to be able to connect to it.
 
 @item @code{public-registration} (default: @code{#f})
-Must be a @code{<murmur-public-registration-configuration>} record or @code{#f}.
+Must be a @code{<mumble-server-public-registration-configuration>}
+record or @code{#f}.
 
 You can optionally register your server in the public server list that the
 @code{mumble} client shows on startup.
@@ -25132,8 +25784,8 @@ Optional alternative override for this configuration.
 @end table
 @end deftp
 
-@deftp {Data Type} murmur-public-registration-configuration
-Configuration for public registration of a murmur service.
+@deftp {Data Type} mumble-server-public-registration-configuration
+Configuration for public registration of a mumble-server service.
 
 @table @asis
 @item @code{name}
@@ -25153,7 +25805,12 @@ If it is set your server will be linked by this host name instead.
 @end table
 @end deftp
 
-
+@quotation Deprecation notice
+Due to historical reasons, all of the above @code{mumble-server-}
+procedures are also exported with the @code{murmur-} prefix.
+It is recommended that you switch to using @code{mumble-server-}
+going forward.
+@end quotation
 
 @node File-Sharing Services
 @subsection File-Sharing Services
@@ -28921,6 +29578,14 @@ The file to read the IP address of the upstream nameservers from.
 @item @code{no-resolv?} (default: @code{#f})
 When true, don't read @var{resolv-file}.
 
+@item @code{forward-private-reverse-lookup?} (default: @code{#t})
+When false, all reverse lookups for private IP ranges are answered with
+"no such domain" rather than being forwarded upstream.
+
+@item @code{query-servers-in-order?} (default: @code{#f})
+When true, dnsmasq queries the servers in the same order as they appear
+in @var{servers}.
+
 @item @code{servers} (default: @code{'()})
 Specify IP address of upstream servers directly.
 
@@ -28950,6 +29615,10 @@ disables caching.
 @item @code{negative-cache?} (default: @code{#t})
 When false, disable negative caching.
 
+@item @code{cpe-id} (default: @code{#f})
+If set, add a CPE (Customer-Premises Equipment) identifier to DNS
+queries which are forwarded upstream.
+
 @item @code{tftp-enable?} (default: @code{#f})
 Whether to enable the built-in TFTP server.
 
@@ -34137,6 +34806,12 @@ derivations to build.
 The Guix Data Service instance from which to query to find out about
 derivations to build.
 
+@item @code{guix-data-service-build-server-id} (default: @code{#f})
+The Guix Data Service build server ID corresponding to the builds being
+submitted.  Providing this speeds up the submitting of builds as
+derivations that have already been submitted can be skipped before
+asking the coordinator to build them.
+
 @item @code{processed-commits-file} (default: @code{"/var/cache/guix-build-coordinator-queue-builds/processed-commits"})
 A file to record which commits have been processed, to avoid needlessly
 processing them again if the service is restarted.
@@ -34279,6 +34954,10 @@ time-to-live (TTL) of @emph{negative} lookups---missing store items, for
 which the HTTP 404 code is returned.  By default, no negative TTL is
 advertised.
 
+@item @code{log-level} (default: @code{'DEBUG})
+Log level to use, specify a log level like @code{'INFO} to stop logging
+individual requests.
+
 @end table
 @end deftp
 
@@ -35568,8 +36247,8 @@ The type of a bootloader configuration declaration.
 @cindex BIOS, bootloader
 The bootloader to use, as a @code{bootloader} object.  For now
 @code{grub-bootloader}, @code{grub-efi-bootloader},
-@code{grub-efi-netboot-bootloader}, @code{extlinux-bootloader} and
-@code{u-boot-bootloader} are supported.
+@code{grub-efi-netboot-bootloader}, @code{grub-efi-removable-bootloader},
+@code{extlinux-bootloader} and @code{u-boot-bootloader} are supported.
 
 @cindex ARM, bootloaders
 @cindex AArch64, bootloaders
@@ -35638,6 +36317,20 @@ NFS servers, you also need a properly configured DHCP server to make the booting
 over netboot possible.  For all this we can currently only recommend you to look
 for instructions about @acronym{PXE, Preboot eXecution Environment}.
 
+@vindex grub-efi-removable-bootloader
+@code{grub-efi-removable-bootloader} allows you to boot your system from
+removable media by writing the GRUB file to the UEFI-specification location of
+@file{/EFI/BOOT/BOOTX64.efi} of the boot directory, usually @file{/boot/efi}.
+This is also useful for some UEFI firmwares that ``forget'' their configuration
+from their non-volatile storage. Like @code{grub-efi-bootloader}, this can only
+be used if the @file{/sys/firmware/efi} directory is available.
+
+@quotation Note
+This @emph{will} overwrite the GRUB file from any other operating systems that
+also place their GRUB file in the UEFI-specification location; making them
+unbootable.
+@end quotation
+
 @item @code{targets}
 This is a list of strings denoting the targets onto which to install the
 bootloader.
@@ -35646,7 +36339,8 @@ The interpretation of targets depends on the bootloader in question.
 For @code{grub-bootloader}, for example, they should be device names
 understood by the bootloader @command{installer} command, such as
 @code{/dev/sda} or @code{(hd0)} (@pxref{Invoking grub-install,,, grub,
-GNU GRUB Manual}).  For @code{grub-efi-bootloader}, they should be mount
+GNU GRUB Manual}).  For @code{grub-efi-bootloader} and
+@code{grub-efi-removable-bootloader} they should be mount
 points of the EFI file system, usually @file{/boot/efi}.  For
 @code{grub-efi-netboot-bootloader}, @code{targets} should be the mount
 points corresponding to TFTP root directories served by your TFTP
@@ -35901,6 +36595,19 @@ As for @command{guix package --search}, the result is written in
 @code{recutils} format, which makes it easy to filter the output
 (@pxref{Top, GNU recutils databases,, recutils, GNU recutils manual}).
 
+@cindex service type definition, editing
+@cindex editing, service type definition
+@item edit
+Edit or view the definition of the given service types.
+
+For example, the command below opens your editor, as specified by the
+@env{EDITOR} environment variable, on the definition of the
+@code{openssh} service type:
+
+@example
+guix system edit openssh
+@end example
+
 @item reconfigure
 Build the operating system described in @var{file}, activate it, and
 switch to it@footnote{This action (and the related actions
@@ -38191,7 +38898,7 @@ variables.
       ("ENV_VAR2" . "value2"))
 @end lisp
 
-The easiest way to extend a service type, without defining new service
+The easiest way to extend a service type, without defining a new service
 type is to use the @code{simple-service} helper from @code{(gnu
 services)}.
 
@@ -38737,6 +39444,19 @@ guix home container config.scm -- herd status
 The command to run in the container must come after @code{--} (double
 hyphen).
 
+@cindex service type definition, editing
+@cindex editing, service type definition
+@item edit
+Edit or view the definition of the given Home service types.
+
+For example, the command below opens your editor, as specified by the
+@env{EDITOR} environment variable, on the definition of the
+@code{home-mcron} service type:
+
+@example
+guix home edit home-mcron
+@end example
+
 @item reconfigure
 Build the home environment described in @var{file}, and switch to it.
 Switching means that the activation script will be evaluated and (in
@@ -39233,7 +39953,7 @@ You can then pass it to any command with the @option{-m} option:
 guix shell -m manifest.scm -- pdflatex doc.tex
 @end example
 
-@xref{Invoking guix package, @option{--manifest}}, for more on
+@xref{Writing Manifests}, for more on
 manifests.  In the future, we plan to provide packages for @TeX{} Live
 @dfn{collections}---``meta-packages'' such as @code{fontsrecommended},
 @code{humanities}, or @code{langarabic} that provide the set of packages
@@ -39740,20 +40460,22 @@ one:
 guix build --target=armv5tel-linux-gnueabi bootstrap-tarballs
 @end example
 
-For this to work, the @code{glibc-dynamic-linker} procedure in
-@code{(gnu packages bootstrap)} must be augmented to return the right
-file name for libc's dynamic linker on that platform; likewise,
-@code{system->linux-architecture} in @code{(gnu packages linux)} must be
-taught about the new platform.
-
-Once these are built, the @code{(gnu packages bootstrap)} module needs
-to be updated to refer to these binaries on the target platform.  That
-is, the hashes and URLs of the bootstrap tarballs for the new platform
-must be added alongside those of the currently supported platforms.  The
-bootstrap Guile tarball is treated specially: it is expected to be
-available locally, and @file{gnu/local.mk} has rules to download it for
-the supported architectures; a rule for the new platform must be added
-as well.
+For this to work, it is first required to register a new platform as
+defined in the @code{(guix platform)} module.  A platform is making the
+connection between a GNU triplet (@pxref{Specifying Target Triplets, GNU
+configuration triplets,, autoconf, Autoconf}), the equivalent
+@var{system} in Nix notation, the name of the
+@var{glibc-dynamic-linker}, and the corresponding Linux architecture
+name if applicable.
+
+Once the bootstrap tarball are built, the @code{(gnu packages
+bootstrap)} module needs to be updated to refer to these binaries on the
+target platform.  That is, the hashes and URLs of the bootstrap tarballs
+for the new platform must be added alongside those of the currently
+supported platforms.  The bootstrap Guile tarball is treated specially:
+it is expected to be available locally, and @file{gnu/local.mk} has
+rules to download it for the supported architectures; a rule for the new
+platform must be added as well.
 
 In practice, there may be some complications.  First, it may be that the
 extended GNU triplet that specifies an ABI (like the @code{eabi} suffix