Complex end-to-end tests in development repositories involving packages written in several languages are a chore to describe and maintain. Often, the only recourse is to pull in pre-built binaries or haul around heavy Docker images. Could there be a better way? Could it be Guix (spoiler alert: yes!)?
In the last few months, I have installed and upgraded my second preferred GNU/Linux system, GNU Guix, on multiple boxes. Regarding that system, I have already written a few introductory posts in the recent past. This is an update about my experiences as a user and developer. I still think Guix is a giant step forward in packaging and management, in comparison with Debian and other distributions, for elegance and inner coherence.
A security issue, CVE-2025-59378 , has been identified in guix-daemon , which allows for a local user to gain the privileges of any of the build users and subsequently use this to manipulate the output of any build. In the case of the rootless daemon, this also means gaining the privileges of guix-daemon . All systems are affected, whether or not guix-daemon is running with root privileges. You are strongly advised to upgrade your daemon now (see instructions below). The only requirements to exploit this are the ability to create and build an arbitrary derivation that has …
What is the ubiquitous with-imported-modules in G-expressions? Why do you need it when you already have use-modules?
Indent generated G-expression scripts with this trick to aid in debugging!
One of the oft-cited reasons people give for not switching to Guix is that their favourite software is too outdated, and a look at Repology shows that they are not wrong. Now the number of active committers in the Guix project is amazingly small, and even counting all contributors I am impressed by what these few people actually achieve. Nevertheless I wondered how I could improve the situation at least a little bit for packages I am interested in, that is, for the science team; and the first step is to get an account of what actually builds and what does not. So I decided to set up my own little build farm, limited to the packages in the scope of the science team, using the same technology that powers the bordeaux build farm. I call it the Tiny Build Farm for Guix, or TBFG for short, and this post is the first one in (hopefully) a series of blog posts about the topic; at the time of starting this series, the TBFG does not actually exist yet, so wish me luck.
Mes 0.27.1 is a bug-fix release. It represents 53 commits by four people over one year. This release resurrects supports development builds with gcc-14 and adds support for using NYACC versions 0.99.0 through 2.02.2.
Recently I changed my ISP, and the new one uses
Carrier-grade NAT,
or CGNAT, by default. While this sounds fancy and professional, it is in
fact even worse than conventional NAT: Not only do all my devices share the
same IPv4, but I share one IPv4 with several other customers!
Apparently I am only assigned a few out of the 65535 ports, and this
assignment may change from day to day, which implies that I cannot connect
from the outside to any of my home devices.
However, I do have a separate IPv4 of my own for a
virtual
machine
at Aquilenet, and it should be
possible to use this as a trampoline to access my home through a virtual
private network.
We are already employing
WireGuard
for one of the
Guix build farms, so it felt like
a natural choice.
Guix provides the wireguard-service-type, which is
documented
with all its options in the manual; but without an explanation of the
general concepts behind the service it is a bit difficult to set up.
The Guix Cookbook
has an
entry
on WireGuard, but it is concerned with kernel modules and connecting to an
existing WireGuard VPN, while my goal was to set one up in the first place.
This turned out to be surprisingly easy.
Using Guix with Container Toolbox on an atomic Fedora distrbution.
Two security issues, known as CVE-2025-46415 and CVE-2025-46416 , have been identified in guix-daemon , which allow for a local user to gain the privileges of any of the build users and subsequently use this to manipulate the output of any build, as well as to subsequently gain the privileges of the daemon user. You are strongly advised to upgrade your daemon now (see instructions below), especially on multi-user systems. Both exploits require the ability to start a derivation build. CVE-2025-46415 requires the ability to create files in /tmp in the…