guix - Wojtek's customized Guix

diff options

Diffstat (limited to 'build-aux/update-NEWS.scm')

0 files changed, 0 insertions, 0 deletions

��2022 Tobias Geerinckx-Rice@* Copyright @copyright{} 2017 George Clemmer@* Copyright @copyright{} 2017 Andy Wingo@* Copyright @copyright{} 2017, 2018, 2019, 2020, 2023, 2024 Arun Isaac@* Copyright @copyright{} 2017 nee@* Copyright @copyright{} 2018 Rutger Helling@* Copyright @copyright{} 2018, 2021, 2023 Oleg Pykhalov@* Copyright @copyright{} 2018 Mike Gerwitz@* Copyright @copyright{} 2018 Pierre-Antoine Rouby@* Copyright @copyright{} 2018, 2019 Gábor Boskovits@* Copyright @copyright{} 2018, 2019, 2020, 2022, 2023, 2024 Florian Pelz@* Copyright @copyright{} 2018 Laura Lazzati@* Copyright @copyright{} 2018 Alex Vong@* Copyright @copyright{} 2019 Josh Holland@* Copyright @copyright{} 2019, 2020 Diego Nicola Barbato@* Copyright @copyright{} 2019 Ivan Petkov@* Copyright @copyright{} 2019 Jakob L. Kreuze@* Copyright @copyright{} 2019 Kyle Andrews@* Copyright @copyright{} 2019 Alex Griffin@* Copyright @copyright{} 2019, 2020, 2021, 2022 Guillaume Le Vaillant@* Copyright @copyright{} 2020 Liliana Marie Prikler@* Copyright @copyright{} 2019, 2020, 2021, 2022, 2023 Simon Tournier@* Copyright @copyright{} 2020 Wiktor Żelazny@* Copyright @copyright{} 2020 Damien Cassou@* Copyright @copyright{} 2020 Jakub Kądziołka@* Copyright @copyright{} 2020 Jack Hill@* Copyright @copyright{} 2020 Naga Malleswari@* Copyright @copyright{} 2020, 2021 Brice Waegeneire@* Copyright @copyright{} 2020 R Veera Kumar@* Copyright @copyright{} 2020, 2021, 2022 Pierre Langlois@* Copyright @copyright{} 2020 pinoaffe@* Copyright @copyright{} 2020, 2023 André Batista@* Copyright @copyright{} 2020, 2021 Alexandru-Sergiu Marton@* Copyright @copyright{} 2020 raingloom@* Copyright @copyright{} 2020 Daniel Brooks@* Copyright @copyright{} 2020 John Soo@* Copyright @copyright{} 2020 Jonathan Brielmaier@* Copyright @copyright{} 2020 Edgar Vincent@* Copyright @copyright{} 2021, 2022 Maxime Devos@* Copyright @copyright{} 2021 B. Wilson@* Copyright @copyright{} 2021 Xinglu Chen@* Copyright @copyright{} 2021 Raghav Gururajan@* Copyright @copyright{} 2021 Domagoj Stolfa@* Copyright @copyright{} 2021 Hui Lu@* Copyright @copyright{} 2021 pukkamustard@* Copyright @copyright{} 2021 Alice Brenon@* Copyright @copyright{} 2021-2023 Josselin Poiret@* Copyright @copyright{} 2021, 2023 muradm@* Copyright @copyright{} 2021, 2022 Andrew Tropin@* Copyright @copyright{} 2021 Sarah Morgensen@* 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@* Copyright @copyright{} 2022 Justin Veilleux@* Copyright @copyright{} 2022 Reily Siegel@* Copyright @copyright{} 2022 Simon Streit@* Copyright @copyright{} 2022 (@* Copyright @copyright{} 2022 John Kehayias@* Copyright @copyright{} 2022⁠–⁠2023 Bruno Victal@* Copyright @copyright{} 2022 Ivan Vilata-i-Balaguer@* Copyright @copyright{} 2023-2024 Giacomo Leidi@* Copyright @copyright{} 2022 Antero Mejr@* Copyright @copyright{} 2023 Karl Hallsby@* Copyright @copyright{} 2023 Nathaniel Nicandro@* Copyright @copyright{} 2023 Tanguy Le Carrour@* Copyright @copyright{} 2023, 2024 Zheng Junjie@* Copyright @copyright{} 2023 Brian Cully@* Copyright @copyright{} 2023 Felix Lechner@* Copyright @copyright{} 2023 Foundation Devices, Inc.@* Copyright @copyright{} 2023 Thomas Ieong@* Copyright @copyright{} 2023 Saku Laesvuori@* Copyright @copyright{} 2023 Graham James Addis@* Copyright @copyright{} 2023, 2024 Tomas Volf@* Copyright @copyright{} 2024 Herman Rimm@* Copyright @copyright{} 2024 Matthew Trzcinski@* Copyright @copyright{} 2024 Richard Sent@* Copyright @copyright{} 2024 Dariqq@* Copyright @copyright{} 2024 Denis 'GNUtoo' Carikli@* Copyright @copyright{} 2024 Fabio Natali@* Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled ``GNU Free Documentation License''. @end copying @dircategory System administration @direntry * Guix: (guix). Manage installed software and system configuration. * guix package: (guix)Invoking guix package. Installing, removing, and upgrading packages. * guix gc: (guix)Invoking guix gc. Reclaiming unused disk space. * guix pull: (guix)Invoking guix pull. Update the list of available packages. * guix system: (guix)Invoking guix system. Manage the operating system configuration. * guix deploy: (guix)Invoking guix deploy. Manage operating system configurations for remote hosts. @end direntry @dircategory Software development @direntry * guix shell: (guix)Invoking guix shell. Creating software environments. * guix environment: (guix)Invoking guix environment. Building development environments with Guix. * guix build: (guix)Invoking guix build. Building packages. * guix pack: (guix)Invoking guix pack. Creating binary bundles. @end direntry @titlepage @title GNU Guix Reference Manual @subtitle Using the GNU Guix Functional Package Manager @author The GNU Guix Developers @page @vskip 0pt plus 1filll Edition @value{EDITION} @* @value{UPDATED} @* @insertcopying @end titlepage @contents @c ********************************************************************* @node Top @top GNU Guix This document describes GNU Guix version @value{VERSION}, a functional package management tool written for the GNU system. @c TRANSLATORS: You can replace the following paragraph with information on @c how to join your own translation team and how to report issues with the @c translation. This manual is also available in Simplified Chinese (@pxref{Top,,, guix.zh_CN, GNU Guix参考手册}), French (@pxref{Top,,, guix.fr, Manuel de référence de GNU Guix}), German (@pxref{Top,,, guix.de, Referenzhandbuch zu GNU Guix}), Spanish (@pxref{Top,,, guix.es, Manual de referencia de GNU Guix}), Brazilian Portuguese (@pxref{Top,,, guix.pt_BR, Manual de referência do GNU Guix}), and Russian (@pxref{Top,,, guix.ru, Руководство GNU Guix}). If you would like to translate it in your native language, consider joining @uref{https://translate.fedoraproject.org/projects/guix/documentation-manual, Weblate} (@pxref{Translating Guix}). @menu * Introduction:: What is Guix about? * Installation:: Installing Guix. * System Installation:: Installing the whole operating system. * Getting Started:: Your first steps. * Package Management:: Package installation, upgrade, etc. * Channels:: Customizing the package collection. * 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. * System Troubleshooting Tips:: When things don't go as planned. * Home Configuration:: Configuring the home environment. * Documentation:: Browsing software user manuals. * Platforms:: Defining platforms. * System Images:: Creating system images. * Installing Debugging Files:: Feeding the debugger. * Using TeX and LaTeX:: Typesetting. * Security Updates:: Deploying security fixes quickly. * Bootstrapping:: GNU/Linux built from scratch. * Porting:: Targeting another platform or kernel. * Contributing:: Your help needed! * Acknowledgments:: Thanks! * GNU Free Documentation License:: The license of this manual. * Concept Index:: Concepts. * Programming Index:: Data types, functions, and variables. @detailmenu --- The Detailed Node Listing --- Introduction * Managing Software the Guix Way:: What's special. * GNU Distribution:: The packages and tools. Installation * Binary Installation:: Getting Guix running in no time! * Setting Up the Daemon:: Preparing the build daemon's environment. * Invoking guix-daemon:: Running the build daemon. * Application Setup:: Application-specific setup. * Upgrading Guix:: Upgrading Guix and its build daemon. Setting Up the Daemon * Build Environment Setup:: Preparing the isolated build environment. * Daemon Offload Setup:: Offloading builds to remote machines. * SELinux Support:: Using an SELinux policy for the daemon. System Installation * Limitations:: What you can expect. * Hardware Considerations:: Supported hardware. * USB Stick and DVD Installation:: Preparing the installation medium. * Preparing for Installation:: Networking, partitioning, etc. * Guided Graphical Installation:: Easy graphical installation. * Manual Installation:: Manual installation for wizards. * After System Installation:: When installation succeeded. * Installing Guix in a VM:: Guix System playground. * Building the Installation Image:: How this comes to be. Manual Installation * Keyboard Layout and Networking and Partitioning:: Initial setup. * Proceeding with the Installation:: Installing. Package Management * Features:: How Guix will make your life brighter. * Invoking guix package:: Package installation, removal, etc. * Substitutes:: Downloading pre-built binaries. * Packages with Multiple Outputs:: Single source package, multiple outputs. * Invoking guix locate:: Locating packages that provide a file. * Invoking guix gc:: Running the garbage collector. * Invoking guix pull:: Fetching the latest Guix and distribution. * Invoking guix time-machine:: Running an older revision of Guix. * Inferiors:: Interacting with another revision of Guix. * Invoking guix describe:: Display information about your Guix revision. * Invoking guix archive:: Exporting and importing store files. Substitutes * Official Substitute Servers:: One particular source of substitutes. * Substitute Server Authorization:: How to enable or disable substitutes. * Getting Substitutes from Other Servers:: Substitute diversity. * Substitute Authentication:: How Guix verifies substitutes. * Proxy Settings:: How to get substitutes via proxy. * Substitution Failure:: What happens when substitution fails. * On Trusting Binaries:: How can you trust that binary blob? Channels * Specifying Additional Channels:: Extending the package collection. * Using a Custom Guix Channel:: Using a customized Guix. * Replicating Guix:: Running the @emph{exact same} Guix. * Channel Authentication:: How Guix verifies what it fetches. * Channels with Substitutes:: Using channels with available substitutes. * Creating a Channel:: How to write your custom channel. * Package Modules in a Sub-directory:: Specifying the channel's package modules location. * Declaring Channel Dependencies:: How to depend on other channels. * Specifying Channel Authorizations:: Defining channel authors authorizations. * Primary URL:: Distinguishing mirror to original. * Writing Channel News:: Communicating information to channel's users. Development * Invoking guix shell:: Spawning one-off software environments. * Invoking guix environment:: Setting up development environments. * Invoking guix pack:: Creating software bundles. * The GCC toolchain:: Working with languages supported by GCC. * Invoking guix git authenticate:: Authenticating Git repositories. 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. * Search Paths:: Declaring search path environment variables. * The Store:: Manipulating the package store. * Derivations:: Low-level interface to package derivations. * The Store Monad:: Purely functional interface to the store. * G-Expressions:: Manipulating build expressions. * Invoking guix repl:: Programming Guix in Guile * Using Guix Interactively:: Fine-grain interaction at the REPL. Defining Packages * package Reference:: The package data type. * origin Reference:: The origin data type. Utilities * Invoking guix build:: Building packages from the command line. * Invoking guix edit:: Editing package definitions. * Invoking guix download:: Downloading a file and printing its hash. * Invoking guix hash:: Computing the cryptographic hash of a file. * Invoking guix import:: Importing package definitions. * Invoking guix refresh:: Updating package definitions. * Invoking guix style:: Styling package definitions. * Invoking guix lint:: Finding errors in package definitions. * Invoking guix size:: Profiling disk usage. * Invoking guix graph:: Visualizing the graph of packages. * Invoking guix publish:: Sharing substitutes. * Invoking guix challenge:: Challenging substitute servers. * Invoking guix copy:: Copying to and from a remote store. * Invoking guix container:: Process isolation. * Invoking guix weather:: Assessing substitute availability. * Invoking guix processes:: Listing client processes. Invoking @command{guix build} * Common Build Options:: Build options for most commands. * Package Transformation Options:: Creating variants of packages. * Additional Build Options:: Options specific to 'guix build'. * 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 * Getting Started with the System:: Your first steps. * Using the Configuration System:: Customizing your GNU system. * operating-system Reference:: Detail of operating-system declarations. * File Systems:: Configuring file system mounts. * Mapped Devices:: Block device extra processing. * Swap Space:: Backing RAM with disk space. * User Accounts:: Specifying user accounts. * Keyboard Layout:: How the system interprets key strokes. * Locales:: Language and cultural convention settings. * Services:: Specifying system services. * Privileged Programs:: Programs running with elevated privileges. * X.509 Certificates:: Authenticating HTTPS servers. * Name Service Switch:: Configuring libc's name service switch. * Initial RAM Disk:: Linux-Libre bootstrapping. * Bootloader Configuration:: Configuring the boot loader. * Invoking guix system:: Instantiating a system configuration. * Invoking guix deploy:: Deploying a system configuration to a remote host. * Running Guix in a VM:: How to run Guix System in a virtual machine. * Defining Services:: Adding new service definitions. File Systems * Btrfs file system:: Services * Base Services:: Essential system services. * Scheduled Job Execution:: The mcron service. * Log Rotation:: The rottlog service. * Networking Setup:: Setting up network interfaces. * Networking Services:: Firewall, SSH daemon, etc. * Unattended Upgrades:: Automated system upgrades. * X Window:: Graphical display. * Printing Services:: Local and remote printer support. * Desktop Services:: D-Bus and desktop services. * Sound Services:: ALSA and Pulseaudio services. * File Search Services:: Tools to search for files. * Database Services:: SQL databases, key-value stores, etc. * Mail Services:: IMAP, POP3, SMTP, and all that. * Messaging Services:: Messaging services. * Telephony Services:: Telephony services. * File-Sharing Services:: File-sharing services. * Monitoring Services:: Monitoring services. * Kerberos Services:: Kerberos services. * LDAP Services:: LDAP services. * Web Services:: Web servers. * Certificate Services:: TLS certificates via Let's Encrypt. * DNS Services:: DNS daemons. * VNC Services:: VNC daemons. * VPN Services:: VPN daemons. * Network File System:: NFS related services. * Samba Services:: Samba services. * Continuous Integration:: Cuirass and Laminar services. * Power Management Services:: Extending battery life. * Audio Services:: The MPD. * Virtualization Services:: Virtualization services. * Version Control Services:: Providing remote access to Git repositories. * Game Services:: Game servers. * PAM Mount Service:: Service to mount volumes when logging in. * Guix Services:: Services relating specifically to Guix. * Linux Services:: Services tied to the Linux kernel. * Hurd Services:: Services specific for a Hurd System. * Miscellaneous Services:: Other services. Defining Services * Service Composition:: The model for composing services. * Service Types and Services:: Types and services. * Service Reference:: API reference. * Shepherd Services:: A particular type of service. * Complex Configurations:: Defining bindings for complex configurations. System Troubleshooting Tips * Chrooting into an existing system:: Home Configuration * Declaring the Home Environment:: Customizing your Home. * Configuring the Shell:: Enabling home environment. * Home Services:: Specifying home services. * Invoking guix home:: Instantiating a home configuration. Home Services * Essential Home Services:: Environment variables, packages, on-* scripts. * Shells: Shells Home Services. POSIX shells, Bash, Zsh. * Mcron: Mcron Home Service. Scheduled User's Job Execution. * Power Management: Power Management Home Services. Services for battery power. * Shepherd: Shepherd Home Service. Managing User's Daemons. * SSH: Secure Shell. Setting up the secure shell client. * GPG: GNU Privacy Guard. Setting up GPG and related tools. * Desktop: Desktop Home Services. Services for graphical environments. * Guix: Guix Home Services. Services for Guix. * Fonts: Fonts Home Services. Services for managing User's fonts. * Sound: Sound Home Services. Dealing with audio. * Mail: Mail Home Services. Services for managing mail. * Messaging: Messaging Home Services. Services for managing messaging. * Media: Media Home Services. Services for managing media. * Networking: Networking Home Services. Networking services. * Miscellaneous: Miscellaneous Home Services. More services. Platforms * platform Reference:: Detail of platform declarations. * Supported Platforms:: Description of the supported platforms. Creating System Images * image Reference:: Detail of image declarations. * Instantiate an Image:: How to instantiate an image record. * image-type Reference:: Detail of image types declaration. * Image Modules:: Definition of image modules. @code{image} Reference * partition Reference:: Installing Debugging Files * Separate Debug Info:: Installing 'debug' outputs. * Rebuilding Debug Info:: Building missing debug info. Bootstrapping * Full-Source Bootstrap:: A Bootstrap worthy of GNU. * Preparing to Use the Bootstrap Binaries:: Building that what matters most. @end detailmenu @end menu @c ********************************************************************* @node Introduction @chapter Introduction @cindex purpose GNU Guix@footnote{``Guix'' is pronounced like ``geeks'', or ``ɡiːks'' using the international phonetic alphabet (IPA).} is a package management tool for and distribution of the GNU system. Guix makes it easy for unprivileged users to install, upgrade, or remove software packages, to roll back to a previous package set, to build packages from source, and generally assists with the creation and maintenance of software environments. @cindex Guix System @cindex GuixSD, now Guix System @cindex Guix System Distribution, now Guix System You can install GNU@tie{}Guix on top of an existing GNU/Linux system where it complements the available tools without interference (@pxref{Installation}), or you can use it as a standalone operating system distribution, @dfn{Guix@tie{}System}@footnote{We used to refer to Guix System as ``Guix System Distribution'' or ``GuixSD''. We now consider it makes more sense to group everything under the ``Guix'' banner since, after all, Guix System is readily available through the @command{guix system} command, even if you're using a different distro underneath!}. @xref{GNU Distribution}. @menu * Managing Software the Guix Way:: What's special. * GNU Distribution:: The packages and tools. @end menu @node Managing Software the Guix Way @section Managing Software the Guix Way @cindex user interfaces Guix provides a command-line package management interface (@pxref{Package Management}), tools to help with software development (@pxref{Development}), command-line utilities for more advanced usage (@pxref{Utilities}), as well as Scheme programming interfaces (@pxref{Programming Interface}). @cindex build daemon Its @dfn{build daemon} is responsible for building packages on behalf of users (@pxref{Setting Up the Daemon}) and for downloading pre-built binaries from authorized sources (@pxref{Substitutes}). @cindex extensibility of the distribution @cindex customization, of packages Guix includes package definitions for many GNU and non-GNU packages, all of which @uref{https://www.gnu.org/philosophy/free-sw.html, respect the user's computing freedom}. It is @emph{extensible}: users can write their own package definitions (@pxref{Defining Packages}) and make them available as independent package modules (@pxref{Package Modules}). It is also @emph{customizable}: users can @emph{derive} specialized package definitions from existing ones, including from the command line (@pxref{Package Transformation Options}). @cindex functional package management @cindex isolation Under the hood, Guix implements the @dfn{functional package management} discipline pioneered by Nix (@pxref{Acknowledgments}). In Guix, the package build and installation process is seen as a @emph{function}, in the mathematical sense. That function takes inputs, such as build scripts, a compiler, and libraries, and returns an installed package. As a pure function, its result depends solely on its inputs---for instance, it cannot refer to software or scripts that were not explicitly passed as inputs. A build function always produces the same result when passed a given set of inputs. It cannot alter the environment of the running system in any way; for instance, it cannot create, modify, or delete files outside of its build and installation directories. This is achieved by running build processes in isolated environments (or @dfn{containers}), where only their explicit inputs are visible. @cindex store The result of package build functions is @dfn{cached} in the file system, in a special directory called @dfn{the store} (@pxref{The Store}). Each package is installed in a directory of its own in the store---by default under @file{/gnu/store}. The directory name contains a hash of all the inputs used to build that package; thus, changing an input yields a different directory name. This approach is the foundation for the salient features of Guix: support for transactional package upgrade and rollback, per-user installation, and garbage collection of packages (@pxref{Features}). @node GNU Distribution @section GNU Distribution @cindex Guix System Guix comes with a distribution of the GNU system consisting entirely of free software@footnote{The term ``free'' here refers to the @url{https://www.gnu.org/philosophy/free-sw.html,freedom provided to users of that software}.}. The distribution can be installed on its own (@pxref{System Installation}), but it is also possible to install Guix as a package manager on top of an installed GNU/Linux system (@pxref{Installation}). When we need to distinguish between the two, we refer to the standalone distribution as Guix@tie{}System. The distribution provides core GNU packages such as GNU libc, GCC, and Binutils, as well as many GNU and non-GNU applications. The complete list of available packages can be browsed @url{https://www.gnu.org/software/guix/packages,on-line} or by running @command{guix package} (@pxref{Invoking guix package}): @example guix package --list-available @end example Our goal is to provide a practical 100% free software distribution of Linux-based and other variants of GNU, with a focus on the promotion and tight integration of GNU components, and an emphasis on programs and tools that help users exert that freedom. Packages are currently available on the following platforms: @table @code @item x86_64-linux Intel/AMD @code{x86_64} architecture, Linux-Libre kernel. @item i686-linux Intel 32-bit architecture (IA32), Linux-Libre kernel. @item armhf-linux ARMv7-A architecture with hard float, Thumb-2 and NEON, using the EABI hard-float application binary interface (ABI), and Linux-Libre kernel. @item aarch64-linux little-endian 64-bit ARMv8-A processors, Linux-Libre kernel. @item i586-gnu @uref{https://hurd.gnu.org, GNU/Hurd} on the Intel 32-bit architecture (IA32). This configuration is experimental and under development. The easiest way for you to give it a try is by setting up an instance of @code{hurd-vm-service-type} on your GNU/Linux machine (@pxref{transparent-emulation-qemu, @code{hurd-vm-service-type}}). @xref{Contributing}, on how to help! @item mips64el-linux (unsupported) little-endian 64-bit MIPS processors, specifically the Loongson series, n32 ABI, and Linux-Libre kernel. This configuration is no longer fully supported; in particular, there is no ongoing work to ensure that this architecture still works. Should someone decide they wish to revive this architecture then the code is still available. @item powerpc-linux (unsupported) big-endian 32-bit PowerPC processors, specifically the PowerPC G4 with AltiVec support, and Linux-Libre kernel. This configuration is not fully supported and there is no ongoing work to ensure this architecture works. @item powerpc64le-linux little-endian 64-bit Power ISA processors, Linux-Libre kernel. This includes POWER9 systems such as the @uref{https://www.fsf.org/news/talos-ii-mainboard-and-talos-ii-lite-mainboard-now-fsf-certified-to-respect-your-freedom, RYF Talos II mainboard}. This platform is available as a "technology preview": although it is supported, substitutes are not yet available from the build farm (@pxref{Substitutes}), and some packages may fail to build (@pxref{Tracking Bugs and Changes}). That said, the Guix community is actively working on improving this support, and now is a great time to try it and get involved! @item riscv64-linux little-endian 64-bit RISC-V processors, specifically RV64GC, and Linux-Libre kernel. This platform is available as a "technology preview": although it is supported, substitutes are not yet available from the build farm (@pxref{Substitutes}), and some packages may fail to build (@pxref{Tracking Bugs and Changes}). That said, the Guix community is actively working on improving this support, and now is a great time to try it and get involved! @end table With Guix@tie{}System, you @emph{declare} all aspects of the operating system configuration and Guix takes care of instantiating the configuration in a transactional, reproducible, and stateless fashion (@pxref{System Configuration}). Guix System uses the Linux-libre kernel, the Shepherd initialization system (@pxref{Introduction,,, shepherd, The GNU Shepherd Manual}), the well-known GNU utilities and tool chain, as well as the graphical environment or system services of your choice. Guix System is available on all the above platforms except @code{mips64el-linux}, @code{powerpc-linux}, @code{powerpc64le-linux} and @code{riscv64-linux}. @noindent For information on porting to other architectures or kernels, @pxref{Porting}. Building this distribution is a cooperative effort, and you are invited to join! @xref{Contributing}, for information about how you can help. @c ********************************************************************* @node Installation @chapter Installation @cindex installing Guix @cindex foreign distro @cindex Guix System You can install the package management tool Guix on top of an existing GNU/Linux or GNU/Hurd system@footnote{Hurd support is currently limited.}, referred to as a @dfn{foreign distro}. If, instead, you want to install the complete, standalone GNU system distribution, @dfn{Guix@tie{}System}, @pxref{System Installation}. This section is concerned only with the installation of Guix on a foreign distro. @quotation Important This section only applies to systems without Guix. Following it for existing Guix installations will overwrite important system files. @end quotation @cindex directories related to foreign distro When installed on a foreign distro, GNU@tie{}Guix complements the available tools without interference. Its data lives exclusively in two directories, usually @file{/gnu/store} and @file{/var/guix}; other files on your system, such as @file{/etc}, are left untouched. Once installed, Guix can be updated by running @command{guix pull} (@pxref{Invoking guix pull}). @menu * Binary Installation:: Getting Guix running in no time! * Setting Up the Daemon:: Preparing the build daemon's environment. * Invoking guix-daemon:: Running the build daemon. * Application Setup:: Application-specific setup. * Upgrading Guix:: Upgrading Guix and its build daemon. @end menu @node Binary Installation @section Binary Installation @cindex installing Guix from binaries @cindex installer script This section describes how to install Guix from a self-contained tarball providing binaries for Guix and for all its dependencies. This is often quicker than installing from source, described later (@pxref{Building from Git}). @quotation Important This section only applies to systems without Guix. Following it for existing Guix installations will overwrite important system files. @end quotation Some GNU/Linux distributions, such as Debian, Ubuntu, and openSUSE provide Guix through their own package managers. The version of Guix may be older than @value{VERSION} but you can update it afterwards by running @samp{guix pull}. We advise system administrators who install Guix, both from the installation script or @i{via} the native package manager of their foreign distribution, to also regularly read and follow security notices, as shown by @command{guix pull}. For Debian or derivatives such as Ubuntu or Trisquel, call: @example sudo apt install guix @end example Likewise, on openSUSE: @example sudo zypper install guix @end example If you are running Parabola, after enabling the pcr (Parabola Community Repo) repository, you can install Guix with: @example sudo pacman -S guix @end example The Guix project also provides a shell script, @file{guix-install.sh}, which automates the binary installation process without use of a foreign distro package manager@footnote{@uref{https://git.savannah.gnu.org/cgit/guix.git/plain/etc/guix-install.sh}}. Use of @file{guix-install.sh} requires Bash, GnuPG, GNU@tie{}tar, wget, and Xz. The script guides you through the following: @itemize @item Downloading and extracting the binary tarball @item Setting up the build daemon @item Making the ‘guix’ command available to non-root users @item Configuring substitute servers @end itemize As root, run: @example # cd /tmp # wget https://git.savannah.gnu.org/cgit/guix.git/plain/etc/guix-install.sh # chmod +x guix-install.sh # ./guix-install.sh @end example The script to install Guix is also packaged in Parabola (in the pcr repository). You can install and run it with: @example sudo pacman -S guix-installer sudo guix-install.sh @end example @quotation Note By default, @file{guix-install.sh} will configure Guix to download pre-built package binaries, called @dfn{substitutes} (@pxref{Substitutes}), from the project's build farms. If you choose not to permit this, Guix will build @emph{everything} from source, making each installation and upgrade very expensive. @xref{On Trusting Binaries} for a discussion of why you may want to build packages from source. @cindex substitutes, authorization thereof To use substitutes from @code{@value{SUBSTITUTE-SERVER-1}}, @code{@value{SUBSTITUTE-SERVER-2}} or a mirror, you must authorize them. For example, @example # guix archive --authorize < \ ~root/.config/guix/current/share/guix/@value{SUBSTITUTE-SERVER-1}.pub # guix archive --authorize < \ ~root/.config/guix/current/share/guix/@value{SUBSTITUTE-SERVER-2}.pub @end example @end quotation When you're done installing Guix, @pxref{Application Setup} for extra configuration you might need, and @ref{Getting Started} for your first steps! @quotation Note The binary installation tarball can be (re)produced and verified simply by running the following command in the Guix source tree: @example make guix-binary.@var{system}.tar.xz @end example @noindent ...@: which, in turn, runs: @example guix pack -s @var{system} --localstatedir \ --profile-name=current-guix guix @end example @xref{Invoking guix pack}, for more info on this handy tool. @end quotation @cindex uninstalling Guix @cindex uninstallation, of Guix Should you eventually want to uninstall Guix, run the same script with the @option{--uninstall} flag: @example ./guix-install.sh --uninstall @end example With @option{--uninstall}, the script irreversibly deletes all the Guix files, configuration, and services. @node Setting Up the Daemon @section Setting Up the Daemon @cindex daemon During installation, the @dfn{build daemon} that must be running to use Guix has already been set up and you can run @command{guix} commands in your terminal program, @pxref{Getting Started}: @example guix build hello @end example If this runs through without error, feel free to skip this section. You should continue with the following section, @ref{Application Setup}. However, now would be a good time to replace outdated daemon versions, tweak it, perform builds on other machines (@pxref{Daemon Offload Setup}), or start it manually in special environments like ``chroots'' (@pxref{Chrooting into an existing system}) or WSL (not needed for WSL images created with Guix, @pxref{System Images, @code{wsl2-image-type}}). If you want to know more or optimize your system, this section is worth reading. Operations such as building a package or running the garbage collector are all performed by a specialized process, the build daemon, on behalf of clients. Only the daemon may access the store and its associated database. Thus, any operation that manipulates the store goes through the daemon. For instance, command-line tools such as @command{guix package} and @command{guix build} communicate with the daemon (@i{via} remote procedure calls) to instruct it what to do. The following sections explain how to prepare the build daemon's environment. @xref{Substitutes} for how to allow the daemon to download pre-built binaries. @menu * Build Environment Setup:: Preparing the isolated build environment. * Daemon Offload Setup:: Offloading builds to remote machines. * SELinux Support:: Using an SELinux policy for the daemon. @end menu @node Build Environment Setup @subsection Build Environment Setup @cindex build environment In a standard multi-user setup, Guix and its daemon---the @command{guix-daemon} program---are installed by the system administrator; @file{/gnu/store} is owned by @code{root} and @command{guix-daemon} runs as @code{root}. Unprivileged users may use Guix tools to build packages or otherwise access the store, and the daemon will do it on their behalf, ensuring that the store is kept in a consistent state, and allowing built packages to be shared among users. @cindex build users When @command{guix-daemon} runs as @code{root}, you may not want package build processes themselves to run as @code{root} too, for obvious security reasons. To avoid that, a special pool of @dfn{build users} should be created for use by build processes started by the daemon. These build users need not have a shell and a home directory: they will just be used when the daemon drops @code{root} privileges in build processes. Having several such users allows the daemon to launch distinct build processes under separate UIDs, which guarantees that they do not interfere with each other---an essential feature since builds are regarded as pure functions (@pxref{Introduction}). On a GNU/Linux system, a build user pool may be created like this (using Bash syntax and the @code{shadow} commands): @c See https://lists.gnu.org/archive/html/bug-guix/2013-01/msg00239.html @c for why `-G' is needed. @example # groupadd --system guixbuild # for i in $(seq -w 1 10); do useradd -g guixbuild -G guixbuild \ -d /var/empty -s $(which nologin) \ -c "Guix build user $i" --system \ guixbuilder$i; done @end example @noindent The number of build users determines how many build jobs may run in parallel, as specified by the @option{--max-jobs} option (@pxref{Invoking guix-daemon, @option{--max-jobs}}). To use @command{guix system vm} and related commands, you may need to add the build users to the @code{kvm} group so they can access @file{/dev/kvm}, using @code{-G guixbuild,kvm} instead of @code{-G guixbuild} (@pxref{Invoking guix system}). The @code{guix-daemon} program may then be run as @code{root} with the following command@footnote{If your machine uses the systemd init system, copying the @file{@var{prefix}/lib/systemd/system/guix-daemon.service} file to @file{/etc/systemd/system} will ensure that @command{guix-daemon} is automatically started. Similarly, if your machine uses the Upstart init system, copy the @file{@var{prefix}/lib/upstart/system/guix-daemon.conf} file to @file{/etc/init}.}: @example # guix-daemon --build-users-group=guixbuild @end example @cindex chroot @noindent This way, the daemon starts build processes in a chroot, under one of the @code{guixbuilder} users. On GNU/Linux, by default, the chroot environment contains nothing but: @c Keep this list in sync with libstore/build.cc! ----------------------- @itemize @item a minimal @code{/dev} directory, created mostly independently from the host @code{/dev}@footnote{``Mostly'', because while the set of files that appear in the chroot's @code{/dev} is fixed, most of these files can only be created if the host has them.}; @item the @code{/proc} directory; it only shows the processes of the container since a separate PID name space is used; @item @file{/etc/passwd} with an entry for the current user and an entry for user @file{nobody}; @item @file{/etc/group} with an entry for the user's group; @item @file{/etc/hosts} with an entry that maps @code{localhost} to @code{127.0.0.1}; @item a writable @file{/tmp} directory. @end itemize The chroot does not contain a @file{/home} directory, and the @env{HOME} environment variable is set to the non-existent @file{/homeless-shelter}. This helps to highlight inappropriate uses of @env{HOME} in the build scripts of packages. All this usually enough to ensure details of the environment do not influence build processes. In some exceptional cases where more control is needed---typically over the date, kernel, or CPU---you can resort to a virtual build machine (@pxref{build-vm, virtual build machines}). You can influence the directory where the daemon stores build trees @i{via} the @env{TMPDIR} environment variable. However, the build tree within the chroot is always called @file{/tmp/guix-build-@var{name}.drv-0}, where @var{name} is the derivation name---e.g., @code{coreutils-8.24}. This way, the value of @env{TMPDIR} does not leak inside build environments, which avoids discrepancies in cases where build processes capture the name of their build tree. @vindex http_proxy @vindex https_proxy The daemon also honors the @env{http_proxy} and @env{https_proxy} environment variables for HTTP and HTTPS downloads it performs, be it for fixed-output derivations (@pxref{Derivations}) or for substitutes (@pxref{Substitutes}). If you are installing Guix as an unprivileged user, it is still possible to run @command{guix-daemon} provided you pass @option{--disable-chroot}. However, build processes will not be isolated from one another, and not from the rest of the system. Thus, build processes may interfere with each other, and may access programs, libraries, and other files available on the system---making it much harder to view them as @emph{pure} functions. @node Daemon Offload Setup @subsection Using the Offload Facility @cindex offloading @cindex build hook When desired, the build daemon can @dfn{offload} derivation builds to other machines running Guix, using the @code{offload} @dfn{build hook}@footnote{This feature is available only when @uref{https://github.com/artyom-poptsov/guile-ssh, Guile-SSH} is present.}. When that feature is enabled, a list of user-specified build machines is read from @file{/etc/guix/machines.scm}; every time a build is requested, for instance via @code{guix build}, the daemon attempts to offload it to one of the machines that satisfy the constraints of the derivation, in particular its system types---e.g., @code{x86_64-linux}. A single machine can have multiple system types, either because its architecture natively supports it, via emulation (@pxref{transparent-emulation-qemu, Transparent Emulation with QEMU}), or both. Missing prerequisites for the build are copied over SSH to the target machine, which then proceeds with the build; upon success the output(s) of the build are copied back to the initial machine. The offload facility comes with a basic scheduler that attempts to select the best machine. The best machine is chosen among the available machines based on criteria such as: @enumerate @item The availability of a build slot. A build machine can have as many build slots (connections) as the value of the @code{parallel-builds} field of its @code{build-machine} object. @item Its relative speed, as defined via the @code{speed} field of its @code{build-machine} object. @item Its load. The normalized machine load must be lower than a threshold value, configurable via the @code{overload-threshold} field of its @code{build-machine} object. @item Disk space availability. More than a 100 MiB must be available. @end enumerate The @file{/etc/guix/machines.scm} file typically looks like this: @lisp (list (build-machine (name "eightysix.example.org") (systems (list "x86_64-linux" "i686-linux")) (host-key "ssh-ed25519 AAAAC3Nza@dots{}") (user "bob") (speed 2.)) ;incredibly fast! (build-machine (name "armeight.example.org") (systems (list "aarch64-linux")) (host-key "ssh-rsa AAAAB3Nza@dots{}") (user "alice") ;; Remember 'guix offload' is spawned by ;; 'guix-daemon' as root. (private-key "/root/.ssh/identity-for-guix"))) @end lisp @noindent In the example above we specify a list of two build machines, one for the @code{x86_64} and @code{i686} architectures and one for the @code{aarch64} architecture. In fact, this file is---not surprisingly!---a Scheme file that is evaluated when the @code{offload} hook is started. Its return value must be a list of @code{build-machine} objects. While this example shows a fixed list of build machines, one could imagine, say, using DNS-SD to return a list of potential build machines discovered in the local network (@pxref{Introduction, Guile-Avahi,, guile-avahi, Using Avahi in Guile Scheme Programs}). The @code{build-machine} data type is detailed below. @deftp {Data Type} build-machine This data type represents build machines to which the daemon may offload builds. The important fields are: @table @code @item name The host name of the remote machine. @item systems The system types the remote machine supports---e.g., @code{(list "x86_64-linux" "i686-linux")}. @item user The user account on the remote machine to use when connecting over SSH. Note that the SSH key pair must @emph{not} be passphrase-protected, to allow non-interactive logins. @item host-key This must be the machine's SSH @dfn{public host key} in OpenSSH format. This is used to authenticate the machine when we connect to it. It is a long string that looks like this: @example ssh-ed25519 AAAAC3NzaC@dots{}mde+UhL hint@@example.org @end example If the machine is running the OpenSSH daemon, @command{sshd}, the host key can be found in a file such as @file{/etc/ssh/ssh_host_ed25519_key.pub}. If the machine is running the SSH daemon of GNU@tie{}lsh, @command{lshd}, the host key is in @file{/etc/lsh/host-key.pub} or a similar file. It can be converted to the OpenSSH format using @command{lsh-export-key} (@pxref{Converting keys,,, lsh, LSH Manual}): @example $ lsh-export-key --openssh < /etc/lsh/host-key.pub ssh-rsa AAAAB3NzaC1yc2EAAAAEOp8FoQAAAQEAs1eB46LV@dots{} @end example @end table A number of optional fields may be specified: @table @asis @item @code{port} (default: @code{22}) Port number of SSH server on the machine. @item @code{private-key} (default: @file{~root/.ssh/id_rsa}) The SSH private key file to use when connecting to the machine, in OpenSSH format. This key must not be protected with a passphrase. Note that the default value is the private key @emph{of the root account}. Make sure it exists if you use the default. @item @code{compression} (default: @code{"zlib@@openssh.com,zlib"}) @itemx @code{compression-level} (default: @code{3}) The SSH-level compression methods and compression level requested. Note that offloading relies on SSH compression to reduce bandwidth usage when transferring files to and from build machines. @item @code{daemon-socket} (default: @code{"/var/guix/daemon-socket/socket"}) File name of the Unix-domain socket @command{guix-daemon} is listening to on that machine. @item @code{overload-threshold} (default: @code{0.8}) The load threshold above which a potential offload machine is disregarded by the offload scheduler. The value roughly translates to the total processor usage of the build machine, ranging from 0.0 (0%) to 1.0 (100%). It can also be disabled by setting @code{overload-threshold} to @code{#f}. @item @code{parallel-builds} (default: @code{1}) The number of builds that may run in parallel on the machine. @item @code{speed} (default: @code{1.0}) A ``relative speed factor''. The offload scheduler will tend to prefer machines with a higher speed factor. @item @code{features} (default: @code{'()}) A list of strings denoting specific features supported by the machine. An example is @code{"kvm"} for machines that have the KVM Linux modules and corresponding hardware support. Derivations can request features by name, and they will be scheduled on matching build machines. @end table @end deftp @quotation Note On Guix System, instead of managing @file{/etc/guix/machines.scm} independently, you can choose to specify build machines directly in the @code{operating-system} declaration, in the @code{build-machines} field of @code{guix-configuration}. @xref{guix-configuration-build-machines, @code{build-machines} field of @code{guix-configuration}}. @end quotation The @command{guix} command must be in the search path on the build machines. You can check whether this is the case by running: @example ssh build-machine guix repl --version @end example There is one last thing to do once @file{machines.scm} is in place. As explained above, when offloading, files are transferred back and forth between the machine stores. For this to work, you first need to generate a key pair on each machine to allow the daemon to export signed archives of files from the store (@pxref{Invoking guix archive}): @example # guix archive --generate-key @end example @quotation Note This key pair is not related to the SSH key pair that was previously mentioned in the description of the @code{build-machine} data type. @end quotation @noindent Each build machine must authorize the key of the master machine so that it accepts store items it receives from the master: @example # guix archive --authorize < master-public-key.txt @end example @noindent Likewise, the master machine must authorize the key of each build machine. All the fuss with keys is here to express pairwise mutual trust relations between the master and the build machines. Concretely, when the master receives files from a build machine (and @i{vice versa}), its build daemon can make sure they are genuine, have not been tampered with, and that they are signed by an authorized key. @cindex offload test To test whether your setup is operational, run this command on the master node: @example # guix offload test @end example This will attempt to connect to each of the build machines specified in @file{/etc/guix/machines.scm}, make sure Guix is available on each machine, attempt to export to the machine and import from it, and report any error in the process. If you want to test a different machine file, just specify it on the command line: @example # guix offload test machines-qualif.scm @end example Last, you can test the subset of the machines whose name matches a regular expression like this: @example # guix offload test machines.scm '\.gnu\.org$' @end example @cindex offload status To display the current load of all build hosts, run this command on the main node: @example # guix offload status @end example @node SELinux Support @subsection SELinux Support @cindex SELinux, daemon policy @cindex mandatory access control, SELinux @cindex security, guix-daemon Guix includes an SELinux policy file at @file{etc/guix-daemon.cil} that can be installed on a system where SELinux is enabled, in order to label Guix files and to specify the expected behavior of the daemon. Since Guix System does not provide an SELinux base policy, the daemon policy cannot be used on Guix System. @subsubsection Installing the SELinux policy @cindex SELinux, policy installation @quotation Note The @code{guix-install.sh} binary installation script offers to perform the steps below for you (@pxref{Binary Installation}). @end quotation To install the policy run this command as root: @example semodule -i /var/guix/profiles/per-user/root/current-guix/share/selinux/guix-daemon.cil @end example Then, as root, relabel the file system, possibly after making it writable: @example mount -o remount,rw /gnu/store restorecon -R /gnu /var/guix @end example At this point you can start or restart @command{guix-daemon}; on a distribution that uses systemd as its service manager, you can do that with: @example systemctl restart guix-daemon @end example Once the policy is installed, the file system has been relabeled, and the daemon has been restarted, it should be running in the @code{guix_daemon_t} context. You can confirm this with the following command: @example ps -Zax | grep guix-daemon @end example Monitor the SELinux log files as you run a command like @code{guix build hello} to convince yourself that SELinux permits all necessary operations. @subsubsection Limitations @cindex SELinux, limitations This policy is not perfect. Here is a list of limitations or quirks that should be considered when deploying the provided SELinux policy for the Guix daemon. @enumerate @item @code{guix_daemon_socket_t} isn’t actually used. None of the socket operations involve contexts that have anything to do with @code{guix_daemon_socket_t}. It doesn’t hurt to have this unused label, but it would be preferable to define socket rules for only this label. @item @code{guix gc} cannot access arbitrary links to profiles. By design, the file label of the destination of a symlink is independent of the file label of the link itself. Although all profiles under @file{$localstatedir} are labelled, the links to these profiles inherit the label of the directory they are in. For links in the user’s home directory this will be @code{user_home_t}. But for links from the root user’s home directory, or @file{/tmp}, or the HTTP server’s working directory, etc, this won’t work. @code{guix gc} would be prevented from reading and following these links. @item The daemon’s feature to listen for TCP connections might no longer work. This might require extra rules, because SELinux treats network sockets differently from files. @item Currently all files with a name matching the regular expression @code{/gnu/store/.+-(guix-.+|profile)/bin/guix-daemon} are assigned the label @code{guix_daemon_exec_t}; this means that @emph{any} file with that name in any profile would be permitted to run in the @code{guix_daemon_t} domain. This is not ideal. An attacker could build a package that provides this executable and convince a user to install and run it, which lifts it into the @code{guix_daemon_t} domain. At that point SELinux could not prevent it from accessing files that are allowed for processes in that domain. You will need to relabel the store directory after all upgrades to @file{guix-daemon}, such as after running @code{guix pull}. Assuming the store is in @file{/gnu}, you can do this with @code{restorecon -vR /gnu}, or by other means provided by your operating system. We could generate a much more restrictive policy at installation time, so that only the @emph{exact} file name of the currently installed @code{guix-daemon} executable would be labelled with @code{guix_daemon_exec_t}, instead of using a broad regular expression. The downside is that root would have to install or upgrade the policy at installation time whenever the Guix package that provides the effectively running @code{guix-daemon} executable is upgraded. @end enumerate @node Invoking guix-daemon @section Invoking @command{guix-daemon} @cindex @command{guix-daemon} The @command{guix-daemon} program implements all the functionality to access the store. This includes launching build processes, running the garbage collector, querying the availability of a build result, etc. It is normally run as @code{root} like this: @example # guix-daemon --build-users-group=guixbuild @end example @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 @cindex container, build environment @cindex build environment @cindex reproducible builds By default, @command{guix-daemon} launches build processes under different UIDs, taken from the build group specified with @option{--build-users-group}. In addition, each build process is run in a chroot environment that only contains the subset of the store that the build process depends on, as specified by its derivation (@pxref{Programming Interface, derivation}), plus a set of specific system directories. By default, the latter contains @file{/dev} and @file{/dev/pts}. Furthermore, on GNU/Linux, the build environment is a @dfn{container}: in addition to having its own file system tree, it has a separate mount name space, its own PID name space, network name space, etc. This helps achieve reproducible builds (@pxref{Features}). When the daemon performs a build on behalf of the user, it creates a build directory under @file{/tmp} or under the directory specified by its @env{TMPDIR} environment variable. This directory is shared with the container for the duration of the build, though within the container, the build tree is always called @file{/tmp/guix-build-@var{name}.drv-0}. The build directory is automatically deleted upon completion, unless the build failed and the client specified @option{--keep-failed} (@pxref{Common Build Options, @option{--keep-failed}}). The daemon listens for connections and spawns one sub-process for each session started by a client (one of the @command{guix} sub-commands). The @command{guix processes} command allows you to get an overview of the activity on your system by viewing each of the active sessions and clients. @xref{Invoking guix processes}, for more information. The following command-line options are supported: @table @code @item --build-users-group=@var{group} Take users from @var{group} to run build processes (@pxref{Setting Up the Daemon, build users}). @item --no-substitutes @cindex substitutes Do not use substitutes for build products. That is, always build things locally instead of allowing downloads of pre-built binaries (@pxref{Substitutes}). When the daemon runs with @option{--no-substitutes}, clients can still explicitly enable substitution @i{via} the @code{set-build-options} remote procedure call (@pxref{The Store}). @anchor{daemon-substitute-urls} @item --substitute-urls=@var{urls} Consider @var{urls} the default whitespace-separated list of substitute source URLs. When this option is omitted, @indicateurl{@value{SUBSTITUTE-URLS}} is used. This means that substitutes may be downloaded from @var{urls}, as long as they are signed by a trusted signature (@pxref{Substitutes}). @xref{Getting Substitutes from Other Servers}, for more information on how to configure the daemon to get substitutes from other servers. @cindex offloading @item --no-offload Do not use offload builds to other machines (@pxref{Daemon Offload Setup}). That is, always build things locally instead of offloading builds to remote machines. @item --cache-failures Cache build failures. By default, only successful builds are cached. When this option is used, @command{guix gc --list-failures} can be used to query the set of store items marked as failed; @command{guix gc --clear-failures} removes store items from the set of cached failures. @xref{Invoking guix gc}. @item --cores=@var{n} @itemx -c @var{n} Use @var{n} CPU cores to build each derivation; @code{0} means as many as available. The default value is @code{0}, but it may be overridden by clients, such as the @option{--cores} option of @command{guix build} (@pxref{Invoking guix build}). The effect is to define the @env{NIX_BUILD_CORES} environment variable in the build process, which can then use it to exploit internal parallelism---for instance, by running @code{make -j$NIX_BUILD_CORES}. @item --max-jobs=@var{n} @itemx -M @var{n} Allow at most @var{n} build jobs in parallel. The default value is @code{1}. Setting it to @code{0} means that no builds will be performed locally; instead, the daemon will offload builds (@pxref{Daemon Offload Setup}), or simply fail. @item --max-silent-time=@var{seconds} When the build or substitution process remains silent for more than @var{seconds}, terminate it and report a build failure. The default value is @code{3600} (one hour). The value specified here can be overridden by clients (@pxref{Common Build Options, @option{--max-silent-time}}). @item --timeout=@var{seconds} Likewise, when the build or substitution process lasts for more than @var{seconds}, terminate it and report a build failure. The default value is 24 hours. The value specified here can be overridden by clients (@pxref{Common Build Options, @option{--timeout}}). @item --rounds=@var{N} Build each derivation @var{n} times in a row, and raise an error if consecutive build results are not bit-for-bit identical. Note that this setting can be overridden by clients such as @command{guix build} (@pxref{Invoking guix build}). When used in conjunction with @option{--keep-failed}, the differing output is kept in the store, under @file{/gnu/store/@dots{}-check}. This makes it easy to look for differences between the two results. @item --debug Produce debugging output. This is useful to debug daemon start-up issues, but then it may be overridden by clients, for example the @option{--verbosity} option of @command{guix build} (@pxref{Invoking guix build}). @item --chroot-directory=@var{dir} Add @var{dir} to the build chroot. Doing this may change the result of build processes---for instance if they use optional dependencies found in @var{dir} when it is available, and not otherwise. For that reason, it is not recommended to do so. Instead, make sure that each derivation declares all the inputs that it needs. @item --disable-chroot Disable chroot builds. Using this option is not recommended since, again, it would allow build processes to gain access to undeclared dependencies. It is necessary, though, when @command{guix-daemon} is running under an unprivileged user account. @item --log-compression=@var{type} Compress build logs according to @var{type}, one of @code{gzip}, @code{bzip2}, or @code{none}. Unless @option{--lose-logs} is used, all the build logs are kept in the @var{localstatedir}. To save space, the daemon automatically compresses them with gzip by default. @item --discover[=yes|no] Whether to discover substitute servers on the local network using mDNS and DNS-SD. This feature is still experimental. However, here are a few considerations. @enumerate @item It might b


context:
space:
mode: