We are pleased to announce the release of GNU Guix version 1.4.0!

The release comes with ISO-9660 installation images, a virtual machine
image, and with tarballs to install the package manager on top of your
GNU/Linux distro, either from source or from binaries—check out the
download page. Guix users can
update by running guix pull.

It’s been 18 months since the previous
release.
That’s a lot of time, reflecting both the fact that, as a rolling
release, users continuously get new features and update by running
guix pull; but let’s face it, it also shows an area where we could and
should collectively improve our processes. During that time, Guix
received about 29,000 commits by 453 people, which includes important
new features as we’ll see; the project also changed
maintainers,
structured cooperation as
teams, and
celebrated its ten-year
anniversary!

Illustration by Luis Felipe, published under CC-BY-SA 4.0.

This post provides highlights for all the hard work that went into this
release—and yes, these are probably the longest release notes in Guix’s
history, so make yourself comfortable, relax, and enjoy.

Bonus! Here’s a
chiptune
(by Trevor Lentz, under
CC-BY-SA 3.0) our illustrator Luis Felipe recommends that you listen
to before going further.

Improved software environment management

One area where Guix shines is the management of software
environments. The guix environment command was designed for that
but it suffered from a clumsy interface. It is now superseded by guix shell,
though we are committed to keeping guix environment until at least May
1st, 2023. guix shell is a tool that’s interesting to developers, but
it’s also a useful tool when you’re willing to try out software without
committing it to your profile with guix install. Let’s say you want
to play SuperTuxKart but would rather not
have it in your profile because, hey, it’s a professional laptop; here’s
how you would launch it, fetching it first if necessary:

guix shell supertuxkart -- supertuxkart

In addition to providing a simpler interface, guix shell significantly
improves performance through caching. It also simplifies developer
workflows by automatically recognizing guix.scm and manifest.scm
files present in a directory: drop one of these in your project and
other developers can get started hacking just by running guix shell,
without arguments. Speaking of which: --export-manifest will get you
started by “converting� command-line arguments into a manifest. Read
more about guix shell in the
manual.

Another guix shell innovation is optional emulation of the
filesystem hierarchy standard (FHS). The
FHS specifies
locations for different file categories—/bin for essential command
binaries, /lib for libraries, and so on. Guix with its
store
does not adhere to the FHS, which prevents users from running programs
that assume FHS adherence. The new --emulate-fhs (or -F) flag of
guix shell, combined with --container (-C), instructs it to create
a container environment that follows the FHS. This is best illustrated
with this example, where the ls command of the coreutils package
appears right under /bin, as if we were on an FHS system like Debian:

$ guix shell -CF coreutils -- /bin/ls -1p /
bin/
dev/
etc/
gnu/
home/
lib/
lib64
proc/
sbin/
sys/
tmp/
usr/

Another big new feature is Guix Home. In a nutshell, Home brings
the declarative nature of Guix System to your home environment: it
lets you declare all the aspects of your home environments—“dot files�,
services, and packages—and can instantiate that environment, in your
actual $HOME or in a
container.

If you’re already maintaining your dot files under version control, or
if you would like to keep things under control so you don’t have to
spend days or weeks configuring again next time you switch laptops, this
is the tool you need. Check out this excellent
introduction
that David Wilson gave at the Ten Years celebration, and read more
about Guix Home in the
manual.

Package transformation
options
give users fine control over the way packages are built. The new
--tune option enables tuning of packages for a specific CPU
micro-architecture; this enables the use of the newest
single-instruction multiple-data (SIMD)
instructions,
such as AVX-512 on recent AMD/Intel CPUs, which can make a significant
difference for some workloads such as linear algebra computations.

Since the 1.3.0 release, the project started maintaining an
alternative build
farm
at https://bordeaux.guix.gnu.org. It’s independent from the build
farm at ci.guix.gnu.org (donated and hosted by the Max Delbrück Center
for Molecular Medicine in Berlin, Germany), which has two benefits: it
lets us challenge substitutes produced by each
system,
and it provides redundancy should one of these two build farms go down.
Guix is now configured by default to fetch substitutes from any of these
two build farms. In addition, a
bug was fixed, ensuring that Guix
gracefully switches to another substitute provider when one goes down.

Those who’ve come to enjoy declarative deployment of entire fleets of
machines will probably like the new --execute option of guix deploy.

Stronger distribution

The distribution itself has seen lots of changes. First, the Guix
System installer received a number of bug fixes and it now includes a
new mechanism that allows users to automatically report useful debugging
information in case of a crash. This will help developers address bugs
that occur with unusual configurations.

Application startup has been reduced thanks to a new
per-application dynamic linker
cache
that drastically reduces the number of stat and open calls due to
shared library lookup (we’re glad it
inspired
others).

Guix System is now using version 0.9 of the
GNU Shepherd, which addresses
shortcomings, improves logging, and adds features such as systemd-style
service activation and inetd-style service startup. Speaking of
services, the new guix system edit
sub-command
provides an additional way for users to inspect services, completing
guix system search and guix system extension-graph.

There are 15 new system
services to
choose from, including
Jami,
Samba,
fail2ban,
and
Gitile,
to name a few.

A new interface is available to declare swap
space
in operating system configurations. This interface is more expressive
and more flexible than what was available before.

Similarly, the interface to declare static networking
configuration
has been overhauled. On GNU/Linux, it lets you do roughly the same as
the ip command, only in a declarative fashion and with static checks
to prevent you from deploying obviously broken configurations.

More than 5,300 packages were added for a total of almost 22,000
packages, making Guix one of the top-ten biggest distros according to
Repology. Among the many noteworthy package
upgrades and addition, GNOME 42 is now available. KDE is not there
yet but tens of KDE packages have been added so we’re getting closer;
Qt 6 is also available. The distribution also comes with GCC 12.2.0,
GNU libc 2.33, Xfce 4.16, Linux-libre 6.0.10, LibreOffice 7.4.3.2, and
Emacs 28.2 (with just-in-time compilation support!).

In other news, motivated by the fact that Python 2 officially reached
“end of life� in 2020, more than 500 Python 2 packages were
removed—those whose name starts with python2-. This includes “big
onesâ€� like python2-numpy and python2-scipy. Those who still need
these have two options: using guix time-machine
to jump to an older commit that contains the packages they need, or
using the Guix-Past
channel to build some of those old packages in today’s
environments—scientific computing is one area where this may come in
handy.

On top of that, the Web site features a new package
browser—at last! Among other things,
the package browse provides stable package URLs like
https://packages.guix.gnu.org/packages/PACKAGE.

The NEWS
file
lists additional noteworthy changes and bug fixes you may be
interested in.

More documentation

As with past releases, we have worked on documentation to make Guix more
approachable. “How-to� kind of sections have been written or improved,
such as:

• “Writing
  Manifests�
• “Replicating
  Guix�
• “Using TeX and
  LaTeX�
• “System Troubleshooting
  Tips�
• “Foreign
  Architectures�
• “Using Guix
  Interactively�

The Cookbook likewise
keeps receiving how-to entries, check it out!

The Guix reference manual is fully translated into
French and
German; 70% is available in
Spanish, and there are
preliminary
translations
in Russian,
Chinese, and other
languages. Guix itself is fully translated in French, with almost
complete translations in Brazilian Portuguese, German, Slovak, and
Spanish, and partial translations in almost twenty other
languages.
Check out the manual on how to
help
or this guided tour by translator in chief Julien
Lepiller!

Supporting long-term reproducibility

A salient feature of Guix is its support for reproducible software
deployment. There are several aspects to that, one of which is being
able to retrieve source code from the Software Heritage
archive.
While Guix was already able to fetch the source code of packages from
Software Heritage as a fallback, with version 1.4.0 the source code of
Guix channels is automatically fetched from Software Heritage if its
original URL has become unreachable.

In addition, Guix is now able to retrieve and restore source code
tarballs such as tar.gz files. Software Heritage archives the
contents of tarballs, but not tarball themselves. This created an
impedance mismatch for Guix, where the majority of package
definitions
refer to tarballs and expect to be able to verify the content hash of
the tarball itself. To bridge this gap, Timothy Sample developed
Disarchive, a tool that
can (1) extract tarball metadata, and (2) assemble
previously-extracted metadata and actual files to reconstruct a tarball,
as shown in the diagram below.

The Guix project has set up a continuous
integration job to build a
Disarchive database, which is available at
disarchive.gnu.org. The database
includes metadata for all the tarballs packages refer to. When a source
code tarball disappears, Guix now transparently retrieves tarball
metadata from Disarchive database, fetches file contents from Software
Heritage, and reconstructs the original tarball. As of the
“Preservation of Guix Report�
published in January 2022, almost 75% of the .tar.gz files packages
refer to are now fully archived with Disarchive and Software Heritage.
Running guix lint -c archival PKG will tell you about the archival
status of PKG.
You can read more in the annual report of
Guix-HPC.

This is a significant step forward to provide, for the first time, a
tool that can redeploy past software environments while maintaining the
connection between source code and binaries.

Application bundles and system images

The guix pack
command
to create “application bundles�—standalone application images—has
been extended: guix pack -f deb creates a standalone .deb package
that can be installed on Debian and derivative distros; the new
--symlink flag makes it create symlinks within the image.

At the system level, the new guix system image
command
supersedes previously existing guix system sub-commands, providing a
single entry point to build images of all types: raw disk images, QCOW2
virtual machine images, ISO8660 CD/DVD images, Docker images, and even
images for Microsoft’s Windows Subsystem for Linux
(WSL2). This
comes with a high-level
interface
that lets you declare the type of image you want: the storage format,
partitions, and of course the operating system for that image. To
facilitate its use, predefined image types are provided:

$ guix system image --list-image-types
The available image types are:

   - rock64-raw
   - pinebook-pro-raw
   - pine64-raw
   - novena-raw
   - hurd-qcow2
   - hurd-raw
   - raw-with-offset
   - iso9660
   - efi32-raw
   - wsl2
   - uncompressed-iso9660
   - efi-raw
   - docker
   - qcow2
   - tarball

That includes for
example
an image type for the Pine64 machines and for the GNU/Hurd operating
system. For example, this is how you’d create an QCOW2 virtual machine
image suitable for QEMU:

guix system image -t qcow2 my-operating-system.scm

… where my-operating-system.scm contains an operating system
declaration.

Likewise, here’s how you’d create, on your x86_64 machine, an image for
your Pine64 board, ready to be transferred to an SD card or similar
storage device that the board will boot from:

guix system image -t pine64-raw my-operating-system.scm

The pine64-raw image type specifies that software in the image is
actually cross-compiled to aarch64-linux-gnu—that is, GNU/Linux on
an AArch64 CPU, with the appropriate U-Boot
variant as
its bootloader. Sky’s the limit!

Nicer packaging experience

A significant change that packagers will immediately notice is
package
simplification,
introduced shortly after 1.3.0. The most visible effect is that package
definitions now look clearer:

(package
  ;; …
  (inputs (list pkg-config guile-3.0)))  ;�

… instead of the old baroque style with “input labels�:

(package
  ;; …
  (inputs `(("pkg-config" ,pkg-config)   ;�
            ("guile" ,guile-3.0))))

The new guix style
command
can automatically convert from the “old� style to the “new� style of
package inputs. It can also reformat whole Scheme files following the
stylistic canons du jour, which is particularly handy when getting
started with the language.

That’s just the tip of the iceberg: the new modify-inputs
macro
makes package input manipulation easier and clearer, and one can use
G-expressions
for instance in package phases. Read our earlier
announcement for
more info. On top of that, the new field sanitizer mechanism is used
to validate some fields; for instance, the license field is now
type-checked and the Texinfo syntax of description and synopsis is
validated, all without any run-time overhead in common cases. We hope
these changes will make it easier to get started with packaging.

The guix build command has new flags, --list-systems and
--list-targets, to list supported system types (which may be
passed to --system) and cross-compilation target triplets (for use
with --target). Under the hood, the new (guix platform) module lets
developers define “platforms�—a combination of CPU architecture and
operating system—in an abstract way, unifying various bits of
information previously scattered around.

In addition, packagers can now mark as
“tunable�
packages that would benefit from CPU micro-architecture
optimizations, enabled with --tune.

Python packaging has seen important changes. First, the python
package now honors the GUIX_PYTHONPATH environment variable rather
than PYTHONPATH. That ensures that Python won’t unwillingly pick up
packages not provided by Guix. Second, the new
pyproject-build-system
implements PEP 517. It complements
the existing python-build-system, and both may eventually be merged
together.

What’s great with packaging is when it comes for free. The guix import
command
gained support for several upstream package repositories: minetest
(extensions of the Minetest game), elm (the Elm programming language),
egg (for CHICKEN Scheme), and hexpm (for Erlang and Elixir
packages). Existing importers have seen various improvements. The
guix refresh
command
to automatically update package definitions has a new generic-git
updater.

Try it!

There are several ways to get started using Guix:

1. The installation script lets you
   quickly install Guix on top of another GNU/Linux
   distribution.

2. The Guix System virtual machine
   image
   can be used with QEMU and is a simple way to discover Guix System
   without touching your system.

3. You can install Guix System as a standalone
   distribution.
   The
   installer
   will guide you through the initial configuration steps.

To review all the installation options at your disposal, consult the
download page and don’t hesitate
to get in touch with us.

Enjoy!

About GNU Guix

GNU Guix is a transactional package manager and
an advanced distribution of the GNU system that respects user
freedom.
Guix can be used on top of any system running the Hurd or the Linux
kernel, or it can be used as a standalone operating system distribution
for i686, x86_64, ARMv7, AArch64, and POWER9 machines.

In addition to standard package management features, Guix supports
transactional upgrades and roll-backs, unprivileged package management,
per-user profiles, and garbage collection. When used as a standalone
GNU/Linux distribution, Guix offers a declarative, stateless approach to
operating system configuration management. Guix is highly customizable
and hackable through Guile
programming interfaces and extensions to the
Scheme language.