Guix package contribution workflow

GNU Guix, like most GNU projects, are mainly done in collaboration through email. Here's the very basics of what you should do when getting the groove into contributing to the project.

Getting started

• Basically, you have to create the build environment for the Guix source code. You may want to always keep the GNU Guix manual on the side. TL;DR: get the source, ./bootstrap, ./configure --localstatedir=/var, make check, and you're mostly done!

• GNU projects have a global issue tracker with each project requiring different steps and locations. As of 2021-04-21, GNU Guix has mainly two channels for their issue tracker: bug-guix where bug reports go and guix-patches where contributions are streamed.

  • Both of the channels are essentially mailing lists, only an email address is required to subscribe.

  • There is a more legible frontend combining both the channels of the bug report and patches.

• The Guix community has a build farm running its own CI software. Pretty useful to track the status of several channels that is happening within the package set. You could also stay tuned with its RSS feed.

Adding or updating a package

• Once you want to define a package, you can either edit it by hand or create a template from an importer. Nonetheless, referring to the programming interface and the package reference is a good idea.

• If your name is not added yet into the copyright header, add it to the file where the package is defined. You're essentially declaring you have copyright over the piece of code you're contributing.

• One of the common starting tasks when declaring a package is checking the hash of the source objects. In Guix, guix hash and guix download are handy tools.

• With each package has different requirements, one of the biggest differences is how they're built. Thus, you'll be paying a lot of attention to build systems. Each build system has different parameters so be sure to visit it often.

• When declaring dependencies, it's a good idea to see how other packages have done in similar build systems. Otherwise, it should be done on a case-by-case basis. Just keep a reference to the package object on the side and it will be almost smooth sailing.

• Keep in mind that they also have a guideline for writing synopsis and description.

  • Synopsis shouldn't start with an uppercase letter, a common article (e.g., "a", "an", "the"), and doesn't end with a punctuation.

  • Descriptions should be five to ten sentences long formatted in Texinfo without writing like a marketing sale pitch.

• Just for future reference, the popular MIT license is referred to as the Expat license.

Testing your package

• guix build

• You can test to build in other architectures with the QEMU binaries service.

Creating a patch