Planet Guix

A bit out of order, but things tangle, a problem I’m having on my Guix machine with Emacs.

Andrew Tropin (https://trop.in) introduces Emacs-Arei a modern, extensible IDE for Guile Scheme. Using the Nrepl protocol foundation of Guile Ares-rs, it provides a highly interactive developer experience for programming Guile or Guix.

Guix channels let communities develop and maintain their own package collection at their own pace. As users of Guix in high-performance computing (HPC) and computational sciences, we have been developing several such channels. Those channels live under the Guix-Science umbrella, which recently moved to Codeberg. Over the last couple of months, we’ve been using this migration as an opportunity to strengthen scientific channels, both socially—by welcoming more contributions—and technically—by setting up infrastructure to improve the contribution and maintenance workflows.

Today I had to setup a Nextcloud instance on a cloud server. A completely scripted approach (e.g. via Ansible or OpenTofu) felt a bit over-engineered in my particular case, so I went for a semi-manual installation.

I've been noodling on the possibility of managing a bunch of Guix machines with Goblins for a little while now. Spent a little time at a local coffee shop today thinking about how this might work...

I am using GitLab CI/CD pipelines for several upstream projects (libidn, libidn2, gsasl, inetutils, libtasn1, libntlm, …) and a long-time concern for these have been that there is too little testing on GNU Guix. Several attempts have been made, and earlier this year Ludo’ came really close to finish this. My earlier effort to idempotently rebuild Debian recently led me to think about re-bootstrapping Debian. Since Debian is a binary distribution, it re-use earlier binary packages when building new packages. The prospect of re-bootstrapping Debian in a reproducible way by rebuilding all of those packages going back to the beginning of time does not appeal to me. Instead, wouldn’t it be easier to build Debian trixie (or some future release of Debian) from Guix, by creating a small bootstrap sandbox that can start to build Debian packages, and then make sure that the particular Debian release can idempotently rebuild itself in a reproducible way? Then you will eventually end up with a reproducible and re-bootstrapped Debian, which pave the way for a trustworthy release of Trisquel. Fortunately, such an endeavour appears to offer many rabbit holes. Preparing Guix container images for use in GitLab pipelines is one that I jumped into in the last few days, and just came out of.

It is possible to contribute to improving #guix as the need for new functionalities, packages, fixes or upgrades arise. This is one of the strongest points in open communities: the possibility to participate on the development and continuous improvement of the tool. Let’s see how it goes when it comes to guix.
Guix is a huge project which follows closely the #freesoftware paradigm, and collaboration works in two directions. You take advantage of other developers contributions to guix, while you participate yourself to improving guix repositories with your fixes, updates or new features, once they have been tested. In a first approach, from my own experience, one may create a personal local repository of package definitions, for a personal use. As a second step, it is possible to create a public guix channel, in parallel to contributing upstream.
Contributing your code to guix comes to sending #email with your patches attached, it’s that simple. Don't be intimidated by the details (this is used by lots of open communities, after all). Once your patches are submitted, a review of your code follows, see details. Some tools, like mumi, are helpful to that purpose.

This is a painful post to write. It's about a choice one should never have to make, the choice between software freedom and security.

Remote #ci is the way to go in #modernhw digital design testing. In this #ciseries, let’s see how to implement it with detail using sourcehut and a real world example.
Sourcehut is a lightweight #gitforge where I host my #git repositories. Not only it is based on a paradigm perfectly adapted to #modernhw, but also its builds service includes support for guix (x86_64) images. This means that we will be able to execute all of our testing online inside guix profiles, shells or natively on top of the bare-bones image.

Remote #ci is the way to go in #modernhw digital design testing. In this #ciseries, let’s see how to implement it with detail using sourcehut and a real world example.
Sourcehut is a lightweight #gitforge where I host my #git repositories. Not only it is based on a paradigm perfectly adapted to #modernhw, but also its builds service includes support for guix (x86_64) images. This means that we will be able to execute all of our testing online inside guix profiles, shells or natively on top of the bare-bones image.