@c how to join your own translation team and how to report issues with the
@c translation.
If you would like to translate this document in your native language, consider
-joining the @uref{https://translationproject.org/domain/guix-cookbook.html,
-Translation Project}.
+joining
+@uref{https://translate.fedoraproject.org/projects/guix/documentation-cookbook,
+Weblate}.
@menu
* Scheme tutorials:: Meet your new favorite language!
@item
Scheme syntax boils down to a tree of expressions (or @emph{s-expression} in
Lisp lingo). An expression can be a literal such as numbers and strings, or a
-compound which is a parenthesized list of compounds and literals. @code{#t}
-and @code{#f} stand for the Booleans ``true'' and ``false'', respectively.
+compound which is a parenthesized list of compounds and literals. @code{#true}
+and @code{#false} (abbreviated @code{#t} and @code{#f}) stand for the
+Booleans ``true'' and ``false'', respectively.
Examples of valid expressions:
@end lisp
@item
-The keyword syntax is @code{#:}; it is used to create unique identifiers.
-@pxref{Keywords,,, guile, GNU Guile Reference Manual}.
+@dfn{Keywords} are typically used to identify the named parameters of a
+procedure. They are prefixed by @code{#:} (hash, colon) followed by
+alphanumeric characters: @code{#:like-this}.
+@xref{Keywords,,, guile, GNU Guile Reference Manual}.
@item
The percentage @code{%} is typically used for read-only global variables in
(snippet '(begin
;; Remove bundled software.
(delete-file-recursively "deps")
- #t))))
+ #true))))
(build-system cmake-build-system)
(outputs '("out" "debug"))
(arguments
- `(#:tests? #t ; Run the test suite (this is the default)
+ `(#:tests? #true ; Run the test suite (this is the default)
#:configure-flags '("-DUSE_SHA1DC=ON") ; SHA-1 collision detection
#:phases
(modify-phases %standard-phases
(substitute* "tests/clar/fs.h"
(("/bin/cp") (which "cp"))
(("/bin/rm") (which "rm")))
- #t))
+ #true))
;; Run checks more verbosely.
(replace 'check
(lambda _ (invoke "./libgit2_clar" "-v" "-Q")))
(add-after 'unpack 'make-files-writable-for-tests
- (lambda _ (for-each make-file-writable (find-files "." ".*")))))))
+ (lambda _ (for-each make-file-writable (find-files "." ".*")))))))
(inputs
`(("libssh2" ,libssh2)
("http-parser" ,http-parser)
associated procedures.
For instance, as of this writing the definition of @code{unpack} for the GNU build
-system is
+system is:
@lisp
(define* (unpack #:key source #:allow-other-keys)
;; Preserve timestamps (set to the Epoch) on the copied tree so that
;; things work deterministically.
(copy-recursively source "."
- #:keep-mtime? #t))
+ #:keep-mtime? #true))
(begin
(if (string-suffix? ".zip" source)
(invoke "unzip" source)
(invoke "tar" "xvf" source))
(chdir (first-subdirectory "."))))
- #t)
+ #true)
@end lisp
Note the @code{chdir} call: it changes the working directory to where the source was
@itemize
@item
-@code{(add-before PHASE NEW-PHASE PROCEDURE)}: Run @code{PROCEDURE} named @code{NEW-PHASE} before @code{PHASE}.
+@code{(add-before @var{phase} @var{new-phase} @var{procedure})}: Run @var{procedure} named @var{new-phase} before @var{phase}.
@item
-@code{(add-after PHASE NEW-PHASE PROCEDURE)}: Same, but afterwards.
+@code{(add-after @var{phase} @var{new-phase} @var{procedure})}: Same, but afterwards.
@item
-@code{(replace PHASE PROCEDURE)}.
+@code{(replace @var{phase} @var{procedure})}.
@item
-@code{(delete PHASE)}.
+@code{(delete @var{phase})}.
@end itemize
-The @code{PROCEDURE} supports the keyword arguments @code{inputs} and @code{outputs}. Each
+The @var{procedure} supports the keyword arguments @code{inputs} and @code{outputs}. Each
input (whether @emph{native}, @emph{propagated} or not) and output directory is referenced
by their name in those variables. Thus @code{(assoc-ref outputs "out")} is the store
directory of the main output of the package. A phase procedure may look like
@lisp
(lambda* (#:key inputs outputs #:allow-other-keys)
- (let (((bash-directory (assoc-ref inputs "bash"))
- (output-directory (assoc-ref outputs "out"))
- (doc-directory (assoc-ref outputs "doc"))
- ; ...
- #t)
+ (let ((bash-directory (assoc-ref inputs "bash"))
+ (output-directory (assoc-ref outputs "out"))
+ (doc-directory (assoc-ref outputs "doc")))
+ ;; ...
+ #true))
@end lisp
-The procedure must return @code{#t} on success. It's brittle to rely on the return
+The procedure must return @code{#true} on success. It's brittle to rely on the return
value of the last expression used to tweak the phase because there is no
-guarantee it would be a @code{#t}. Hence the trailing @code{#t} to ensure the right value
+guarantee it would be a @code{#true}. Hence the trailing @code{#true} to ensure the right value
is returned on success.
@subsubsection Code staging
@samp{$GUIX_CHECKOUT/guix/guix/build/utils.scm}. Most of them mirror the behaviour
of the traditional Unix system commands:
-@table @asis
+@table @code
@item which
Like the @samp{which} system command.
@item find-files
A ``@command{sed}-like'' function.
@end table
+@xref{Build Utilities,,, guix, GNU Guix Reference Manual}, for more
+information on these utilities.
+
@subsubsection Module prefix
The license in our last example needs a prefix: this is because of how the
@menu
* Customizing the Kernel:: Creating and using a custom Linux kernel on Guix System.
+* Guix System Image API:: Customizing images to target specific platforms.
* Connecting to Wireguard VPN:: Connecting to a Wireguard VPN.
* Customizing a Window Manager:: Handle customization of a Window manager on Guix System.
* Running Guix on a Linode Server:: Running Guix on a Linode Server
* Setting up a bind mount:: Setting up a bind mount in the file-systems definition.
* Getting substitutes from Tor:: Configuring Guix daemon to get substitutes through Tor.
+* Setting up NGINX with Lua:: Configuring NGINX web-server to load Lua modules.
@end menu
@node Customizing the Kernel
#:key
;; A function that takes an arch and a variant.
;; See kernel-config for an example.
- (extra-version #f)
- (configuration-file #f)
+ (extra-version #false)
+ (configuration-file #false)
(defconfig "defconfig")
(extra-options %default-extra-linux-options)
(patches (list %boot-logo-patch)))
(begin
(copy-file config ".config")
(chmod ".config" #o666))
- (invoke "make" ,defconfig))
+ (invoke "make" ,defconfig)))
@end lisp
Below is a sample kernel package. The @code{linux-libre} package is nothing
@lisp
(define %default-extra-linux-options
`(;; https://lists.gnu.org/archive/html/guix-devel/2014-04/msg00039.html
- ("CONFIG_DEVPTS_MULTIPLE_INSTANCES" . #t)
+ ("CONFIG_DEVPTS_MULTIPLE_INSTANCES" . #true)
;; Modules required for initrd:
("CONFIG_NET_9P" . m)
("CONFIG_NET_9P_VIRTIO" . m)
(string-join (map (match-lambda
((option . 'm)
(string-append option "=m"))
- ((option . #t)
+ ((option . #true)
(string-append option "=y"))
- ((option . #f)
+ ((option . #false)
(string-append option "=n")))
options)
"\n"))
(display extra-configuration port)
(close-port port))
-(invoke "make" "oldconfig"))))
+(invoke "make" "oldconfig")
@end lisp
So by not providing a configuration-file the @file{.config} starts blank, and
kernel, since certain modules which are expected to be built may not be
available for inclusion into the initrd.
+@node Guix System Image API
+@section Guix System Image API
+
+Historically, Guix System is centered around an @code{operating-system}
+structure. This structure contains various fields ranging from the
+bootloader and kernel declaration to the services to install.
+
+Depending on the target machine, that can go from a standard
+@code{x86_64} machine to a small ARM single board computer such as the
+Pine64, the image constraints can vary a lot. The hardware
+manufacturers will impose different image formats with various partition
+sizes and offsets.
+
+To create images suitable for all those machines, a new abstraction is
+necessary: that's the goal of the @code{image} record. This record
+contains all the required information to be transformed into a
+standalone image, that can be directly booted on any target machine.
+
+@lisp
+(define-record-type* <image>
+ image make-image
+ image?
+ (name image-name ;symbol
+ (default #f))
+ (format image-format) ;symbol
+ (target image-target
+ (default #f))
+ (size image-size ;size in bytes as integer
+ (default 'guess))
+ (operating-system image-operating-system ;<operating-system>
+ (default #f))
+ (partitions image-partitions ;list of <partition>
+ (default '()))
+ (compression? image-compression? ;boolean
+ (default #t))
+ (volatile-root? image-volatile-root? ;boolean
+ (default #t))
+ (substitutable? image-substitutable? ;boolean
+ (default #t)))
+@end lisp
+
+This record contains the operating-system to instantiate. The
+@code{format} field defines the image type and can be @code{efi-raw},
+@code{qcow2} or @code{iso9660} for instance. In the future, it could be
+extended to @code{docker} or other image types.
+
+A new directory in the Guix sources is dedicated to images definition. For now
+there are four files:
+
+@itemize @bullet
+@item @file{gnu/system/images/hurd.scm}
+@item @file{gnu/system/images/pine64.scm}
+@item @file{gnu/system/images/novena.scm}
+@item @file{gnu/system/images/pinebook-pro.scm}
+@end itemize
+
+Let's have a look to @file{pine64.scm}. It contains the
+@code{pine64-barebones-os} variable which is a minimal definition of an
+operating-system dedicated to the @b{Pine A64 LTS} board.
+
+@lisp
+(define pine64-barebones-os
+ (operating-system
+ (host-name "vignemale")
+ (timezone "Europe/Paris")
+ (locale "en_US.utf8")
+ (bootloader (bootloader-configuration
+ (bootloader u-boot-pine64-lts-bootloader)
+ (target "/dev/vda")))
+ (initrd-modules '())
+ (kernel linux-libre-arm64-generic)
+ (file-systems (cons (file-system
+ (device (file-system-label "my-root"))
+ (mount-point "/")
+ (type "ext4"))
+ %base-file-systems))
+ (services (cons (service agetty-service-type
+ (agetty-configuration
+ (extra-options '("-L")) ; no carrier detect
+ (baud-rate "115200")
+ (term "vt100")
+ (tty "ttyS0")))
+ %base-services))))
+@end lisp
+
+The @code{kernel} and @code{bootloader} fields are pointing to packages
+dedicated to this board.
+
+Right below, the @code{pine64-image-type} variable is also defined.
+
+@lisp
+(define pine64-image-type
+ (image-type
+ (name 'pine64-raw)
+ (constructor (cut image-with-os arm64-disk-image <>))))
+@end lisp
+
+It's using a record we haven't talked about yet, the @code{image-type} record,
+defined this way:
+
+@lisp
+(define-record-type* <image-type>
+ image-type make-image-type
+ image-type?
+ (name image-type-name) ;symbol
+ (constructor image-type-constructor)) ;<operating-system> -> <image>
+@end lisp
+
+The main purpose of this record is to associate a name to a procedure
+transforming an @code{operating-system} to an image. To understand why
+it is necessary, let's have a look to the command producing an image
+from an @code{operating-system} configuration file:
+
+@example
+guix system image my-os.scm
+@end example
+
+This command expects an @code{operating-system} configuration but how
+should we indicate that we want an image targeting a Pine64 board? We
+need to provide an extra information, the @code{image-type}, by passing
+the @code{--image-type} or @code{-t} flag, this way:
+
+@example
+guix system image --image-type=pine64-raw my-os.scm
+@end example
+
+This @code{image-type} parameter points to the @code{pine64-image-type}
+defined above. Hence, the @code{operating-system} declared in
+@code{my-os.scm} will be applied the @code{(cut image-with-os
+arm64-disk-image <>)} procedure to turn it into an image.
+
+The resulting image looks like:
+
+@lisp
+(image
+ (format 'disk-image)
+ (target "aarch64-linux-gnu")
+ (operating-system my-os)
+ (partitions
+ (list (partition
+ (inherit root-partition)
+ (offset root-offset)))))
+@end lisp
+
+which is the aggregation of the @code{operating-system} defined in
+ @code{my-os.scm} to the @code{arm64-disk-image} record.
+
+But enough Scheme madness. What does this image API bring to the Guix user?
+
+One can run:
+
+@example
+mathieu@@cervin:~$ guix system --list-image-types
+The available image types are:
+
+ - pinebook-pro-raw
+ - pine64-raw
+ - novena-raw
+ - hurd-raw
+ - hurd-qcow2
+ - qcow2
+ - uncompressed-iso9660
+ - efi-raw
+ - arm64-raw
+ - arm32-raw
+ - iso9660
+@end example
+
+and by writing an @code{operating-system} file based on
+@code{pine64-barebones-os}, you can customize your image to your
+preferences in a file (@file{my-pine-os.scm}) like this:
+
+@lisp
+(use-modules (gnu services linux)
+ (gnu system images pine64))
+
+(let ((base-os pine64-barebones-os))
+ (operating-system
+ (inherit base-os)
+ (timezone "America/Indiana/Indianapolis")
+ (services
+ (cons
+ (service earlyoom-service-type
+ (earlyoom-configuration
+ (prefer-regexp "icecat|chromium")))
+ (operating-system-user-services base-os)))))
+@end lisp
+
+run:
+
+@example
+guix system image --image-type=pine64-raw my-pine-os.scm
+@end example
+
+or,
+
+@example
+guix system image --image-type=hurd-raw my-hurd-os.scm
+@end example
+
+to get an image that can be written directly to a hard drive and booted
+from.
+
+Without changing anything to @code{my-hurd-os.scm}, calling:
+
+@example
+guix system image --image-type=hurd-qcow2 my-hurd-os.scm
+@end example
+
+will instead produce a Hurd QEMU image.
+
@node Connecting to Wireguard VPN
@section Connecting to Wireguard VPN
(bootloader
(bootloader
(inherit grub-bootloader)
- (installer #~(const #t))))))
+ (installer #~(const #true))))))
(file-systems (cons (file-system
(device "/dev/sda")
(mount-point "/")
(service openssh-service-type
(openssh-configuration
(openssh openssh-sans-x)
- (password-authentication? #f)
+ (password-authentication? #false)
(authorized-keys
`(("janedoe" ,(local-file "janedoe_rsa.pub"))
("root" ,(local-file "janedoe_rsa.pub"))))))
guix build --substitute-urls=https://bp7o7ckwlewr4slm.onion …
@end example
+@node Setting up NGINX with Lua
+@section Setting up NGINX with Lua
+@cindex nginx, lua, openresty, resty
+
+NGINX could be extended with Lua scripts.
+
+Guix provides NGINX service with ability to load Lua module and specific
+Lua packages, and reply to requests by evaluating Lua scripts.
+
+The following example demonstrates system definition with configuration
+to evaluate @file{index.lua} Lua script on HTTP request to
+@uref{http://localhost/hello} endpoint:
+
+@example
+local shell = require "resty.shell"
+
+local stdin = ""
+local timeout = 1000 -- ms
+local max_size = 4096 -- byte
+
+local ok, stdout, stderr, reason, status =
+ shell.run([[/run/current-system/profile/bin/ls /tmp]], stdin, timeout, max_size)
+
+ngx.say(stdout)
+@end example
+
+@lisp
+(use-modules (gnu))
+(use-service-modules #;… web)
+(use-package-modules #;… lua)
+(operating-system
+ ;; …
+ (services
+ ;; …
+ (service nginx-service-type
+ (nginx-configuration
+ (modules
+ (list
+ (file-append nginx-lua-module "/etc/nginx/modules/ngx_http_lua_module.so")))
+ (lua-package-path (list lua-resty-core
+ lua-resty-lrucache
+ lua-resty-signal
+ lua-tablepool
+ lua-resty-shell))
+ (lua-package-cpath (list lua-resty-signal))
+ (server-blocks
+ (list (nginx-server-configuration
+ (server-name '("localhost"))
+ (listen '("80"))
+ (root "/etc")
+ (locations (list
+ (nginx-location-configuration
+ (uri "/hello")
+ (body (list #~(format #f "content_by_lua_file ~s;"
+ #$(local-file "index.lua"))))))))))))))
+@end lisp
+
@c *********************************************************************
@node Advanced package management
@chapter Advanced package management
@item
Easier upgrades and maintenance: Multiple profiles make it easy to keep
-package listings at hand and make upgrades completely friction-less.
+package listings at hand and make upgrades completely frictionless.
@end itemize
Concretely, here follows some typical profiles:
HCoop / jackhill / guix / guix.git / blobdiff