9.7 Invoking guix lint

The 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 checkers include (see --list-checkers for a complete list):

synopsis

description

Validate certain typographical and stylistic rules about package descriptions and synopses.

inputs-should-be-native

Identify inputs that should most likely be native inputs.

source

home-page

mirror-url

github-url

source-file-name

Probe home-page and source URLs and report those that are invalid. Suggest a mirror:// URL when applicable. If the 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 file-name (see origin Reference).

source-unstable-tarball

Parse the 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.

derivation

Check that the derivation of the given packages can be successfully computed for all the supported systems (see Derivations).

profile-collisions

Check whether installing the given packages in a profile would lead to collisions. Collisions occur when several packages with the same name but a different version or a different store file name are propagated. See propagated-inputs, for more information on propagated inputs.

archival

Checks whether the package’s source code is archived at Software Heritage.

When the source code that is not archived comes from a version-control system (VCS)—e.g., it’s obtained with 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 viewed on-line.

When source code is a tarball obtained with 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 limits the request rate per IP address. When the limit is reached, guix lint prints a message and the archival checker stops doing anything until that limit has been reset.

cve

Report known vulnerabilities found in the Common Vulnerabilities and Exposures (CVE) databases of the current and past year published by the US NIST.

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

• ‘https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-YYYY-ABCD’
• ‘https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-YYYY-ABCD’

where CVE-YYYY-ABCD is the CVE identifier—e.g., CVE-2015-7554.

Package developers can specify in package recipes the 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:

(package
  (name "grub")
  ;; …
  ;; CPE calls this package "grub2".
  (properties '((cpe-name . "grub2")
                (cpe-version . "2.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:

(package
  (name "t1lib")
  ;; …
  ;; 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")))))

formatting

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

The general syntax is:

guix lint options package…

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

--list-checkers

-l

List and describe all the available checkers that will be run on packages and exit.

--checkers

-c

Only enable the checkers specified in a comma-separated list using the names returned by --list-checkers.

--exclude

-x

Only disable the checkers specified in a comma-separated list using the names returned by --list-checkers.

--no-network

-n

Only enable the checkers that do not depend on Internet access.

--load-path=directory

-L directory

Add directory to the front of the package module search path (see Package Modules).

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