guix.texi

Supported formats: @code{nix-base32}, @code{base32}, @code{base16}
(@code{hex} and @code{hexadecimal} can be used as well).

If the @option{--format} option is not specified, @command{guix hash}
will output the hash in @code{nix-base32}.  This representation is used
in the definitions of packages.

@item --recursive
@itemx -r
Compute the hash on @var{file} recursively.

In this case, the hash is computed on an archive containing @var{file},
including its children if it is a directory.  Some of the metadata of
@var{file} is part of the archive; for instance, when @var{file} is a
regular file, the hash is different depending on whether @var{file} is
executable or not.  Metadata such as time stamps has no impact on the
hash (@pxref{Invoking guix archive}).
@c FIXME: Replace xref above with xref to an ``Archive'' section when
@c it exists.

@item --exclude-vcs
@itemx -x
When combined with @option{--recursive}, exclude version control system
directories (@file{.bzr}, @file{.git}, @file{.hg}, etc.)

@vindex git-fetch
As an example, here is how you would compute the hash of a Git checkout,
which is useful when using the @code{git-fetch} method (@pxref{origin
Reference}):

@example
$ git clone http://example.org/foo.git
$ cd foo
$ guix hash -rx .
@end example
@end table

@node Invoking guix import
@section Invoking @command{guix import}

@cindex importing packages
@cindex package import
@cindex package conversion
@cindex Invoking @command{guix import}
The @command{guix import} command is useful for people who would like to
add a package to the distribution with as little work as
possible---a legitimate demand.  The command knows of a few
repositories from which it can ``import'' package metadata.  The result
is a package definition, or a template thereof, in the format we know
(@pxref{Defining Packages}).

The general syntax is:

@example
guix import @var{importer} @var{options}@dots{}
@end example

@var{importer} specifies the source from which to import package
metadata, and @var{options} specifies a package identifier and other
options specific to @var{importer}.

Some of the importers rely on the ability to run the @command{gpgv} command.
For these, GnuPG must be installed and in @code{$PATH}; run @code{guix install
gnupg} if needed.

Currently, the available ``importers'' are:

@table @code
@item gnu
Import metadata for the given GNU package.  This provides a template
for the latest version of that GNU package, including the hash of its
source tarball, and its canonical synopsis and description.

Additional information such as the package dependencies and its
license needs to be figured out manually.

For example, the following command returns a package definition for
GNU@tie{}Hello:

@example
guix import gnu hello
@end example

Specific command-line options are:

@table @code
@item --key-download=@var{policy}
As for @command{guix refresh}, specify the policy to handle missing
OpenPGP keys when verifying the package signature.  @xref{Invoking guix
refresh, @option{--key-download}}.
@end table

@item pypi
@cindex pypi
Import metadata from the @uref{https://pypi.python.org/, Python Package
Index}.  Information is taken from the JSON-formatted description
available at @code{pypi.python.org} and usually includes all the relevant
information, including package dependencies.  For maximum efficiency, it
is recommended to install the @command{unzip} utility, so that the
importer can unzip Python wheels and gather data from them.

The command below imports metadata for the @code{itsdangerous} Python
package:

@example
guix import pypi itsdangerous
@end example

@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 gem
@cindex gem
Import metadata from @uref{https://rubygems.org/, RubyGems}.  Information
is taken from the JSON-formatted description available at
@code{rubygems.org} and includes most relevant information, including
runtime dependencies.  There are some caveats, however.  The metadata
doesn't distinguish between synopses and descriptions, so the same string
is used for both fields.  Additionally, the details of non-Ruby
dependencies required to build native extensions is unavailable and left
as an exercise to the packager.

The command below imports metadata for the @code{rails} Ruby package:

@example
guix import gem rails
@end example

@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 cpan
@cindex CPAN
Import metadata from @uref{https://www.metacpan.org/, MetaCPAN}.
Information is taken from the JSON-formatted metadata provided through
@uref{https://fastapi.metacpan.org/, MetaCPAN's API} and includes most
relevant information, such as module dependencies.  License information
should be checked closely.  If Perl is available in the store, then the
@code{corelist} utility will be used to filter core modules out of the
list of dependencies.

The command command below imports metadata for the @code{Acme::Boolean}
Perl module:

@example
guix import cpan Acme::Boolean
@end example

@item cran
@cindex CRAN
@cindex Bioconductor
Import metadata from @uref{https://cran.r-project.org/, CRAN}, the
central repository for the @uref{https://r-project.org, GNU@tie{}R
statistical and graphical environment}.

Information is extracted from the @file{DESCRIPTION} file of the package.

The command command below imports metadata for the Cairo R package:

@example
guix import cran Cairo
@end example

When @option{--recursive} is added, the importer will traverse the
dependency graph of the given upstream package recursively and generate
package expressions for all those packages that are not yet in Guix.

When @option{--archive=bioconductor} is added, metadata is imported from
@uref{https://www.bioconductor.org/, Bioconductor}, a repository of R
packages for for the analysis and comprehension of high-throughput
genomic data in bioinformatics.

Information is extracted from the @file{DESCRIPTION} file contained in the
package archive.

The command below imports metadata for the GenomicRanges R package:

@example
guix import cran --archive=bioconductor GenomicRanges
@end example

Finally, you can also import R packages that have not yet been published on
CRAN or Bioconductor as long as they are in a git repository.  Use
@option{--archive=git} followed by the URL of the git repository:

@example
guix import cran --archive=git https://github.com/immunogenomics/harmony
@end example

@item texlive
@cindex TeX Live
@cindex CTAN
Import metadata from @uref{https://www.ctan.org/, CTAN}, the
comprehensive TeX archive network for TeX packages that are part of the
@uref{https://www.tug.org/texlive/, TeX Live distribution}.

Information about the package is obtained through the XML API provided
by CTAN, while the source code is downloaded from the SVN repository of
the Tex Live project.  This is done because the CTAN does not keep
versioned archives.

The command command below imports metadata for the @code{fontspec}
TeX package:

@example
guix import texlive fontspec
@end example

When @option{--archive=@var{directory}} is added, the source code is
downloaded not from the @file{latex} sub-directory of the
@file{texmf-dist/source} tree in the TeX Live SVN repository, but from
the specified sibling @var{directory} under the same root.

The command below imports metadata for the @code{ifxetex} package from
CTAN while fetching the sources from the directory
@file{texmf/source/generic}:

@example
guix import texlive --archive=generic ifxetex
@end example

@item json
@cindex JSON, import
Import package metadata from a local JSON file.  Consider the following
example package definition in JSON format:

@example
@{
  "name": "hello",
  "version": "2.10",
  "source": "mirror://gnu/hello/hello-2.10.tar.gz",
  "build-system": "gnu",
  "home-page": "https://www.gnu.org/software/hello/",
  "synopsis": "Hello, GNU world: An example GNU package",
  "description": "GNU Hello prints a greeting.",
  "license": "GPL-3.0+",
  "native-inputs": ["gettext"]
@}
@end example

The field names are the same as for the @code{<package>} record
(@xref{Defining Packages}).  References to other packages are provided
as JSON lists of quoted package specification strings such as
@code{guile} or @code{guile@@2.0}.

The importer also supports a more explicit source definition using the
common fields for @code{<origin>} records:

@example
@{
  @dots{}
  "source": @{
    "method": "url-fetch",
    "uri": "mirror://gnu/hello/hello-2.10.tar.gz",
    "sha256": @{
      "base32": "0ssi1wpaf7plaswqqjwigppsg5fyh99vdlb9kzl7c9lng89ndq1i"
    @}
  @}
  @dots{}
@}
@end example

The command below reads metadata from the JSON file @code{hello.json}
and outputs a package expression:

@example
guix import json hello.json
@end example

@item nix
Import metadata from a local copy of the source of the
@uref{https://nixos.org/nixpkgs/, Nixpkgs distribution}@footnote{This
relies on the @command{nix-instantiate} command of
@uref{https://nixos.org/nix/, Nix}.}.  Package definitions in Nixpkgs are
typically written in a mixture of Nix-language and Bash code.  This
command only imports the high-level package structure that is written in
the Nix language.  It normally includes all the basic fields of a
package definition.

When importing a GNU package, the synopsis and descriptions are replaced
by their canonical upstream variant.

Usually, you will first need to do:

@example
export NIX_REMOTE=daemon
@end example

@noindent
so that @command{nix-instantiate} does not try to open the Nix database.

As an example, the command below imports the package definition of
LibreOffice (more precisely, it imports the definition of the package
bound to the @code{libreoffice} top-level attribute):

@example
guix import nix ~/path/to/nixpkgs libreoffice
@end example

@item hackage
@cindex hackage
Import metadata from the Haskell community's central package archive
@uref{https://hackage.haskell.org/, Hackage}.  Information is taken from
Cabal files and includes all the relevant information, including package
dependencies.

Specific command-line options are:

@table @code
@item --stdin
@itemx -s
Read a Cabal file from standard input.
@item --no-test-dependencies
@itemx -t
Do not include dependencies required only by the test suites.
@item --cabal-environment=@var{alist}
@itemx -e @var{alist}
@var{alist} is a Scheme alist defining the environment in which the
Cabal conditionals are evaluated.  The accepted keys are: @code{os},
@code{arch}, @code{impl} and a string representing the name of a flag.
The value associated with a flag has to be either the symbol
@code{true} or @code{false}.  The value associated with other keys
has to conform to the Cabal file format definition.  The default value
associated with the keys @code{os}, @code{arch} and @code{impl} is
@samp{linux}, @samp{x86_64} and @samp{ghc}, respectively.
@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

The command below imports metadata for the latest version of the
@code{HTTP} Haskell package without including test dependencies and
specifying the value of the flag @samp{network-uri} as @code{false}:

@example
guix import hackage -t -e "'((\"network-uri\" . false))" HTTP
@end example

A specific package version may optionally be specified by following the
package name by an at-sign and a version number as in the following example:

@example
guix import hackage mtl@@2.1.3.1
@end example

@item stackage
@cindex stackage
The @code{stackage} importer is a wrapper around the @code{hackage} one.
It takes a package name, looks up the package version included in a
long-term support (LTS) @uref{https://www.stackage.org, Stackage}
release and uses the @code{hackage} importer to retrieve its metadata.
Note that it is up to you to select an LTS release compatible with the
GHC compiler used by Guix.

Specific command-line options are:

@table @code
@item --no-test-dependencies
@itemx -t
Do not include dependencies required only by the test suites.
@item --lts-version=@var{version}
@itemx -l @var{version}
@var{version} is the desired LTS release version.  If omitted the latest
release is used.
@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

The command below imports metadata for the @code{HTTP} Haskell package
included in the LTS Stackage release version 7.18:

@example
guix import stackage --lts-version=7.18 HTTP
@end example

@item elpa
@cindex elpa
Import metadata from an Emacs Lisp Package Archive (ELPA) package
repository (@pxref{Packages,,, emacs, The GNU Emacs Manual}).

Specific command-line options are:

@table @code
@item --archive=@var{repo}
@itemx -a @var{repo}
@var{repo} identifies the archive repository from which to retrieve the
information.  Currently the supported repositories and their identifiers
are:
@itemize -
@item
@uref{https://elpa.gnu.org/packages, GNU}, selected by the @code{gnu}
identifier.  This is the default.

Packages from @code{elpa.gnu.org} are signed with one of the keys
contained in the GnuPG keyring at
@file{share/emacs/25.1/etc/package-keyring.gpg} (or similar) in the
@code{emacs} package (@pxref{Package Installation, ELPA package
signatures,, emacs, The GNU Emacs Manual}).

@item
@uref{https://stable.melpa.org/packages, MELPA-Stable}, selected by the
@code{melpa-stable} identifier.

@item
@uref{https://melpa.org/packages, MELPA}, selected by the @code{melpa}
identifier.
@end itemize

@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 crate
@cindex crate
Import metadata from the crates.io Rust package repository
@uref{https://crates.io, crates.io}, as in this example:

@example
guix import crate blake2-rfc
@end example

The crate importer also allows you to specify a version string:

@example
guix import crate constant-time-eq@@0.1.0
@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
Import metadata from the @uref{https://opam.ocaml.org/, OPAM} package
repository used by the OCaml community.
@end table

The structure of the @command{guix import} code is modular.  It would be
useful to have more importers for other package formats, and your help
is welcome here (@pxref{Contributing}).

@node Invoking guix refresh
@section Invoking @command{guix refresh}

@cindex @command {guix refresh}
The primary audience of the @command{guix refresh} command is developers
of the GNU software distribution.  By default, it reports any packages
provided by the distribution that are outdated compared to the latest
upstream version, like this:

@example
$ guix refresh
gnu/packages/gettext.scm:29:13: gettext would be upgraded from 0.18.1.1 to 0.18.2.1
gnu/packages/glib.scm:77:12: glib would be upgraded from 2.34.3 to 2.37.0
@end example

Alternately, one can specify packages to consider, in which case a
warning is emitted for packages that lack an updater:

@example
$ guix refresh coreutils guile guile-ssh
gnu/packages/ssh.scm:205:2: warning: no updater for guile-ssh
gnu/packages/guile.scm:136:12: guile would be upgraded from 2.0.12 to 2.0.13
@end example

@command{guix refresh} browses the upstream repository of each package and determines
the highest version number of the releases therein.  The command
knows how to update specific types of packages: GNU packages, ELPA
packages, etc.---see the documentation for @option{--type} below.  There
are many packages, though, for which it lacks a method to determine
whether a new upstream release is available.  However, the mechanism is
extensible, so feel free to get in touch with us to add a new method!

@table @code

@item --recursive
Consider the packages specified, and all the packages upon which they depend.

@example
$ guix refresh --recursive coreutils
gnu/packages/acl.scm:35:2: warning: no updater for acl
gnu/packages/m4.scm:30:12: info: 1.4.18 is already the latest version of m4
gnu/packages/xml.scm:68:2: warning: no updater for expat
gnu/packages/multiprecision.scm:40:12: info: 6.1.2 is already the latest version of gmp
@dots{}
@end example

@end table

Sometimes the upstream name differs from the package name used in Guix,
and @command{guix refresh} needs a little help.  Most updaters honor the
@code{upstream-name} property in package definitions, which can be used
to that effect:

@lisp
(define-public network-manager
  (package
    (name "network-manager")
    ;; @dots{}
    (properties '((upstream-name . "NetworkManager")))))
@end lisp

When passed @option{--update}, it modifies distribution source files to
update the version numbers and source tarball hashes of those package
recipes (@pxref{Defining Packages}).  This is achieved by downloading
each package's latest source tarball and its associated OpenPGP
signature, authenticating the downloaded tarball against its signature
using @command{gpgv}, and finally computing its hash---note that GnuPG must be
installed and in @code{$PATH}; run @code{guix install gnupg} if needed.

When the public
key used to sign the tarball is missing from the user's keyring, an
attempt is made to automatically retrieve it from a public key server;
when this is successful, the key is added to the user's keyring; otherwise,
@command{guix refresh} reports an error.

The following options are supported:

@table @code

@item --expression=@var{expr}
@itemx -e @var{expr}
Consider the package @var{expr} evaluates to.

This is useful to precisely refer to a package, as in this example:

@example
guix refresh -l -e '(@@@@ (gnu packages commencement) glibc-final)'
@end example

This command lists the dependents of the ``final'' libc (essentially all
the packages.)

@item --update
@itemx -u
Update distribution source files (package recipes) in place.  This is
usually run from a checkout of the Guix source tree (@pxref{Running
Guix Before It Is Installed}):

@example
$ ./pre-inst-env guix refresh -s non-core -u
@end example

@xref{Defining Packages}, for more information on package definitions.

@item --select=[@var{subset}]
@itemx -s @var{subset}
Select all the packages in @var{subset}, one of @code{core} or
@code{non-core}.

The @code{core} subset refers to all the packages at the core of the
distribution---i.e., packages that are used to build ``everything
else''.  This includes GCC, libc, Binutils, Bash, etc.  Usually,
changing one of these packages in the distribution entails a rebuild of
all the others.  Thus, such updates are an inconvenience to users in
terms of build time or bandwidth used to achieve the upgrade.

The @code{non-core} subset refers to the remaining packages.  It is
typically useful in cases where an update of the core packages would be
inconvenient.

@item --manifest=@var{file}
@itemx -m @var{file}
Select all the packages from the manifest in @var{file}. This is useful to
check if any packages of the user manifest can be updated.

@item --type=@var{updater}
@itemx -t @var{updater}
Select only packages handled by @var{updater} (may be a comma-separated
list of updaters).  Currently, @var{updater} may be one of:

@table @code
@item gnu
the updater for GNU packages;
@item gnome
the updater for GNOME packages;
@item kde
the updater for KDE packages;
@item xorg
the updater for X.org packages;
@item kernel.org
the updater for packages hosted on kernel.org;
@item elpa
the updater for @uref{https://elpa.gnu.org/, ELPA} packages;
@item cran
the updater for @uref{https://cran.r-project.org/, CRAN} packages;
@item bioconductor
the updater for @uref{https://www.bioconductor.org/, Bioconductor} R packages;
@item cpan
the updater for @uref{https://www.cpan.org/, CPAN} packages;
@item pypi
the updater for @uref{https://pypi.python.org, PyPI} packages.
@item gem
the updater for @uref{https://rubygems.org, RubyGems} packages.
@item github
the updater for @uref{https://github.com, GitHub} packages.
@item hackage
the updater for @uref{https://hackage.haskell.org, Hackage} packages.
@item stackage
the updater for @uref{https://www.stackage.org, Stackage} packages.
@item crate
the updater for @uref{https://crates.io, Crates} packages.
@item launchpad
the updater for @uref{https://launchpad.net, Launchpad} packages.
@end table

For instance, the following command only checks for updates of Emacs
packages hosted at @code{elpa.gnu.org} and for updates of CRAN packages:

@example
$ guix refresh --type=elpa,cran
gnu/packages/statistics.scm:819:13: r-testthat would be upgraded from 0.10.0 to 0.11.0
gnu/packages/emacs.scm:856:13: emacs-auctex would be upgraded from 11.88.6 to 11.88.9
@end example

@end table

In addition, @command{guix refresh} can be passed one or more package
names, as in this example:

@example
$ ./pre-inst-env guix refresh -u emacs idutils gcc@@4.8
@end example

@noindent
The command above specifically updates the @code{emacs} and
@code{idutils} packages.  The @option{--select} option would have no
effect in this case.

When considering whether to upgrade a package, it is sometimes
convenient to know which packages would be affected by the upgrade and
should be checked for compatibility.  For this the following option may
be used when passing @command{guix refresh} one or more package names:

@table @code

@item --list-updaters
@itemx -L
List available updaters and exit (see @option{--type} above.)

For each updater, display the fraction of packages it covers; at the
end, display the fraction of packages covered by all these updaters.

@item --list-dependent
@itemx -l
List top-level dependent packages that would need to be rebuilt as a
result of upgrading one or more packages.

@xref{Invoking guix graph, the @code{reverse-package} type of
@command{guix graph}}, for information on how to visualize the list of
dependents of a package.

@end table

Be aware that the @option{--list-dependent} option only
@emph{approximates} the rebuilds that would be required as a result of
an upgrade.  More rebuilds might be required under some circumstances.

@example
$ guix refresh --list-dependent flex
Building the following 120 packages would ensure 213 dependent packages are rebuilt:
hop@@2.4.0 geiser@@0.4 notmuch@@0.18 mu@@0.9.9.5 cflow@@1.4 idutils@@4.6 @dots{}
@end example

The command above lists a set of packages that could be built to check
for compatibility with an upgraded @code{flex} package.

@table @code

@item --list-transitive
List all the packages which one or more packages depend upon.

@example
$ guix refresh --list-transitive flex
flex@@2.6.4 depends on the following 25 packages: perl@@5.28.0 help2man@@1.47.6
bison@@3.0.5 indent@@2.2.10 tar@@1.30 gzip@@1.9 bzip2@@1.0.6 xz@@5.2.4 file@@5.33 @dots{}
@end example

@end table

The command above lists a set of packages which, when changed, would cause
@code{flex} to be rebuilt.

The following options can be used to customize GnuPG operation:

@table @code

@item --gpg=@var{command}
Use @var{command} as the GnuPG 2.x command.  @var{command} is searched
for in @code{$PATH}.

@item --keyring=@var{file}
Use @var{file} as the keyring for upstream keys.  @var{file} must be in the
@dfn{keybox format}.  Keybox files usually have a name ending in @file{.kbx}
and the GNU@tie{}Privacy Guard (GPG) can manipulate these files
(@pxref{kbxutil, @command{kbxutil},, gnupg, Using the GNU Privacy Guard}, for
information on a tool to manipulate keybox files).

When this option is omitted, @command{guix refresh} uses
@file{~/.config/guix/upstream/trustedkeys.kbx} as the keyring for upstream
signing keys.  OpenPGP signatures are checked against keys from this keyring;
missing keys are downloaded to this keyring as well (see
@option{--key-download} below.)

You can export keys from your default GPG keyring into a keybox file using
commands like this one:

@example
gpg --export rms@@gnu.org | kbxutil --import-openpgp >> mykeyring.kbx
@end example

Likewise, you can fetch keys to a specific keybox file like this:

@example
gpg --no-default-keyring --keyring mykeyring.kbx \
  --recv-keys @value{OPENPGP-SIGNING-KEY-ID}
@end example

@ref{GPG Configuration Options, @option{--keyring},, gnupg, Using the GNU
Privacy Guard}, for more information on GPG's @option{--keyring} option.

@item --key-download=@var{policy}
Handle missing OpenPGP keys according to @var{policy}, which may be one
of:

@table @code
@item always
Always download missing OpenPGP keys from the key server, and add them
to the user's GnuPG keyring.

@item never
Never try to download missing OpenPGP keys.  Instead just bail out.

@item interactive
When a package signed with an unknown OpenPGP key is encountered, ask
the user whether to download it or not.  This is the default behavior.
@end table

@item --key-server=@var{host}
Use @var{host} as the OpenPGP key server when importing a public key.

@item --load-path=@var{directory}
Add @var{directory} to the front of the package module search path
(@pxref{Package Modules}).

This allows users to define their own packages and make them visible to
the command-line tools.

@end table

The @code{github} updater uses the
@uref{https://developer.github.com/v3/, GitHub API} to query for new
releases.  When used repeatedly e.g.@: when refreshing all packages,
GitHub will eventually refuse to answer any further API requests.  By
default 60 API requests per hour are allowed, and a full refresh on all
GitHub packages in Guix requires more than this.  Authentication with
GitHub through the use of an API token alleviates these limits.  To use
an API token, set the environment variable @env{GUIX_GITHUB_TOKEN} to a
token procured from @uref{https://github.com/settings/tokens} or
otherwise.


@node Invoking guix lint
@section Invoking @command{guix lint}

@cindex @command{guix lint}
@cindex package, checking for errors
The @command{guix lint} command is meant to help package developers avoid
common errors and use a consistent style.  It runs a number of checks on
a given set of packages in order to find common mistakes in their
definitions.  Available @dfn{checkers} include (see
@option{--list-checkers} for a complete list):

@table @code
@item synopsis
@itemx description
Validate certain typographical and stylistic rules about package
descriptions and synopses.

@item inputs-should-be-native
Identify inputs that should most likely be native inputs.

@item source
@itemx home-page
@itemx mirror-url
@itemx github-url
@itemx source-file-name
Probe @code{home-page} and @code{source} URLs and report those that are
invalid.  Suggest a @code{mirror://} URL when applicable.  If the
@code{source} URL redirects to a GitHub URL, recommend usage of the GitHub
URL.  Check that the source file name is meaningful, e.g.@: is not just a
version number or ``git-checkout'', without a declared @code{file-name}
(@pxref{origin Reference}).

@item source-unstable-tarball
Parse the @code{source} URL to determine if a tarball from GitHub is
autogenerated or if it is a release tarball.  Unfortunately GitHub's
autogenerated tarballs are sometimes regenerated.

@item archival
@cindex Software Heritage, source code archive
@cindex archival of source code, Software Heritage
Checks whether the package's source code is archived at
@uref{https://www.softwareheritage.org, Software Heritage}.

When the source code that is not archived comes from a version-control system
(VCS)---e.g., it's obtained with @code{git-fetch}, send Software Heritage a
``save'' request so that it eventually archives it.  This ensures that the
source will remain available in the long term, and that Guix can fall back to
Software Heritage should the source code disappear from its original host.
The status of recent ``save'' requests can be
@uref{https://archive.softwareheritage.org/save/#requests, viewed on-line}.

When source code is a tarball obtained with @code{url-fetch}, simply print a
message when it is not archived.  As of this writing, Software Heritage does
not allow requests to save arbitrary tarballs; we are working on ways to
ensure that non-VCS source code is also archived.

Software Heritage
@uref{https://archive.softwareheritage.org/api/#rate-limiting, limits the
request rate per IP address}.  When the limit is reached, @command{guix lint}
prints a message and the @code{archival} checker stops doing anything until
that limit has been reset.

@item cve
@cindex security vulnerabilities
@cindex CVE, Common Vulnerabilities and Exposures
Report known vulnerabilities found in the Common Vulnerabilities and
Exposures (CVE) databases of the current and past year
@uref{https://nvd.nist.gov/vuln/data-feeds, published by the US
NIST}.

To view information about a particular vulnerability, visit pages such as:

@itemize
@item
@indicateurl{https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-YYYY-ABCD}
@item
@indicateurl{https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-YYYY-ABCD}
@end itemize

@noindent
where @code{CVE-YYYY-ABCD} is the CVE identifier---e.g.,
@code{CVE-2015-7554}.

Package developers can specify in package recipes the
@uref{https://nvd.nist.gov/products/cpe,Common Platform Enumeration (CPE)}
name and version of the package when they differ from the name or version
that Guix uses, as in this example:

@lisp
(package
  (name "grub")
  ;; @dots{}
  ;; CPE calls this package "grub2".
  (properties '((cpe-name . "grub2")
                (cpe-version . "2.3"))))
@end lisp

@c See <https://www.openwall.com/lists/oss-security/2017/03/15/3>.
Some entries in the CVE database do not specify which version of a
package they apply to, and would thus ``stick around'' forever.  Package
developers who found CVE alerts and verified they can be ignored can
declare them as in this example:

@lisp
(package
  (name "t1lib")
  ;; @dots{}
  ;; These CVEs no longer apply and can be safely ignored.
  (properties `((lint-hidden-cve . ("CVE-2011-0433"
                                    "CVE-2011-1553"
                                    "CVE-2011-1554"
                                    "CVE-2011-5244")))))
@end lisp

@item formatting
Warn about obvious source code formatting issues: trailing white space,
use of tabulations, etc.
@end table

The general syntax is:

@example
guix lint @var{options} @var{package}@dots{}
@end example

If no package is given on the command line, then all packages are checked.
The @var{options} may be zero or more of the following:

@table @code
@item --list-checkers
@itemx -l
List and describe all the available checkers that will be run on packages
and exit.

@item --checkers
@itemx -c
Only enable the checkers specified in a comma-separated list using the
names returned by @option{--list-checkers}.

@item --load-path=@var{directory}
@itemx -L @var{directory}
Add @var{directory} to the front of the package module search path
(@pxref{Package Modules}).

This allows users to define their own packages and make them visible to
the command-line tools.

@end table

@node Invoking guix size
@section Invoking @command{guix size}

@cindex size
@cindex package size
@cindex closure
@cindex @command{guix size}
The @command{guix size} command helps package developers profile the
disk usage of packages.  It is easy to overlook the impact of an
additional dependency added to a package, or the impact of using a
single output for a package that could easily be split (@pxref{Packages
with Multiple Outputs}).  Such are the typical issues that
@command{guix size} can highlight.

The command can be passed one or more package specifications
such as @code{gcc@@4.8}
or @code{guile:debug}, or a file name in the store.  Consider this
example:

@example
$ guix size coreutils
store item                               total    self
/gnu/store/@dots{}-gcc-5.5.0-lib           60.4    30.1  38.1%
/gnu/store/@dots{}-glibc-2.27              30.3    28.8  36.6%
/gnu/store/@dots{}-coreutils-8.28          78.9    15.0  19.0%
/gnu/store/@dots{}-gmp-6.1.2               63.1     2.7   3.4%
/gnu/store/@dots{}-bash-static-4.4.12       1.5     1.5   1.9%
/gnu/store/@dots{}-acl-2.2.52              61.1     0.4   0.5%
/gnu/store/@dots{}-attr-2.4.47             60.6     0.2   0.3%
/gnu/store/@dots{}-libcap-2.25             60.5     0.2   0.2%
total: 78.9 MiB
@end example

@cindex closure
The store items listed here constitute the @dfn{transitive closure} of
Coreutils---i.e., Coreutils and all its dependencies, recursively---as
would be returned by:

@example
$ guix gc -R /gnu/store/@dots{}-coreutils-8.23
@end example

Here the output shows three columns next to store items.  The first column,
labeled ``total'', shows the size in mebibytes (MiB) of the closure of
the store item---that is, its own size plus the size of all its
dependencies.  The next column, labeled ``self'', shows the size of the
item itself.  The last column shows the ratio of the size of the item
itself to the space occupied by all the items listed here.

In this example, we see that the closure of Coreutils weighs in at
79@tie{}MiB, most of which is taken by libc and GCC's run-time support
libraries.  (That libc and GCC's libraries represent a large fraction of
the closure is not a problem @i{per se} because they are always available
on the system anyway.)

When the package(s) passed to @command{guix size} are available in the
store@footnote{More precisely, @command{guix size} looks for the
@emph{ungrafted} variant of the given package(s), as returned by
@code{guix build @var{package} --no-grafts}.  @xref{Security Updates},
for information on grafts.}, @command{guix size} queries the daemon to determine its
dependencies, and measures its size in the store, similar to @command{du
-ms --apparent-size} (@pxref{du invocation,,, coreutils, GNU
Coreutils}).