Planet Guix

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.

Remote #ci is the way to go in #modernhw digital design testing. In this #ciseries, let’s see it in practice with some detail using two of the most popular forges out there.

How to seek, detect, be notified, analyze logs, understand and react to the different possible kind of issues one may encounter in a digital design is a vast topic of research, well beyond the scope of this modest post. But there are a couple of things we may state about here, though: automatizing issue detection is the way to go. Continuous integration (#ci) testing is a practice to adopt in #modernhw as a way to ensure that our design complies with its constraints. Let’s see this in more detail.

Creating something new from scratch implies a certain ratio of unpredictable issues (loosely defined in the scope of this post: new errors, regressions, warnings, ... any unexpected behavior one may encounter). Most important, a digital design developer needs to define somehow what he considers to be a project issue, before even thinking about how to react to it. Luckily, in #modernhw a few usual tools are available to ease the process as a whole. Let’s overview some of them.
Here on the electronics digital design side of life, we have mainly three #freesoftware fine tools (among many others) to perform code checking to a large extent: osvvm, cocotb and vunit. They are all compatible with the ghdl compiler, and they are all available from my own #guix electronics channel (cocotb and vunit will hopefully get merged on guix upstream at some point). Each departs from the rest, adopting a different paradigm about how digital design testing should be understood: verification, cosimulation and unit testing are master keywords here.
They are all complementary, so you’ll be able to combine them to test your designs. However, you’ll need to be careful and check twice what you’re doing, as some of their features overlap (random treatment, for example). You’ve been warned.

Guix reveals as a practical means of handling dependencies. However, the amount of information available to start using it may appear as a bit overwhelming for a beginner, letting the feeling of a tool reserved to a reduced community or experts. Far from that. Here you’ll find everything you need to get started with guix, with a light touch on using it for #modernhw.
We will concentrate in the use of #guix as an external package manager on top of a #linux distribution based on #systemd. We’ll let aside using and referring to #guixsystem as a full operating system by itself (which I never used anyway). This way, in the context of #modernhw, we may keep on using our favorite tools, environment and workflow. As an addition, we have everything that guix provides at our disposal, without affecting our local packages configuration: guix acts as an extra layer on top of our current OS, without any interference with it. You’ll have the possibility to install any guix software, remove it afterward or make use of the fancy features guix has to offer, without your host OS ever noticing what’s going on.
All what follows is roughly based on the guix reference manual and the guix cookbook, so refer to them for more on depth explanations. This article is strongly influenced by my personal experience as a daily driver, so next topics are necessarily biased towards my own needs.
There is much more to say about guix, but this is just an introductory crash course, right ?

A lot has happened with respect to the Hurd since our Childhurds and GNU/Hurd Substitutes post. As long as two years ago some of you have been asking for a progress update and although there have been rumours on a new blog post for over a year, we were kind of waiting for the rumoured x86_64 support.

In a previous post I mentioned the way I use Emacs Org code blocks and the so-called Noweb syntax as a templating mechanism. The idea is to have a template version of a document containing a certain number of placeholders and a separate file to store the placeholders' values. The template and the data file are then fed into a build process that recombines things and produces the final document.