Fixing some audio package dependency over the weekend (hands-free edition)
A normal Friday night as a GNU Guix team member (and committer)

Then I run guix home reconfigure c/home-configuration.scm to upgrade the software I (as a normal, unprivileged user) run on a (somewhat) regular basis.

Package dssi fails to build. Touched only 3 times (2017, 2021, 2023), only the first (addition) is a real change. Not sure why I need that, probably due to dependency in my not-so-lean home configuration (some audio plugin, i suppose).

Why did it break? guix build dssi outputs:

make[2]: Entering directory '/tmp/guix-build-dssi-1.1.1.drv-0/dssi-1.1.1/tests'
gcc -DHAVE_CONFIG_H -I. -I..    -Wall -Werror -I../dssi  -g -O2 -Wall -MT controller-controller.o -MD -MP -MF .deps/controller-controller.Tpo -c -o controller-controller.o `test -f 'controller.c' || echo './'`controller.c
In file included from ../dssi/dssi.h:28,
                 from controller.c:18:
/gnu/store/cbg2jnl6m0j14gvq68myawpfkljmrh4m-alsa-lib-1.2.16/include/alsa/seq_event.h:30:2: error: #warning "use #include <alsa/asoundlib.h>, <alsa/seq_event.h> should not be used directly" [-Werror=cpp]
   30 | #warning "use #include <alsa/asoundlib.h>, <alsa/seq_event.h> should not be used directly"
      |  ^~~~~~~
cc1: all warnings being treated as errors

The -Wall GCC option converts warnings into errors. But that did not really change lately, did it? We could certainly omit that flag in the compiler invocation, but that wouldn't make much sense.

I query the website of our dedicated continuous integration Cuirass instance with this search string dssi system:x86_64-linux spec:master status:success, which yields the last two successful build (only one this year).

Click on the ID, on the next page on the "Evaluation" ID field. This produces a git commit. This is the last known (to me) git commit to successfully build dssi.

Let's do a git bisect:

git bisect start
git bisect good 92c1e44eb8c7a307b5825b5ec8fef3e7d29b2856
git bisect bad HEAD
git bisect run ./pre-inst-env guix build dssi

hoping to find the culprit of breaking my home configuration.

I let it marinate for a while and live-code some breakbeats (following this splendid video) for fun in the meantime.

Mere minutes later git reports:

/gnu/store/awkbh7w06bg45kfgcwys89fjgp5z0i6v-dssi-1.1.1
efbd6bd790fca599dbd24f29ce0eb4a2eab968f3 is the first bad commit
commit efbd6bd790fca599dbd24f29ce0eb4a2eab968f3
Author: coopi <coopi@XXXX.org>
Date:   Thu Apr 16 11:10:03 2026 +0400

    gnu: alsa-lib: Update to 1.2.16.

    * gnu/packages/linux.scm (alsa-lib) [version]: Update to 1.2.16.
    [source]: Switch to 'git-fetch'.
    [description]: Reword.

    Change-Id: I72675f37cfc35d80d3c4e58514a125cfc9d07996
    Signed-off-by: Gabriel Wicki <gabriel@XXXX.ch>

 gnu/packages/linux.scm | 37 +++++++++++++++++++++++++------------
 1 file changed, 25 insertions(+), 12 deletions(-)
bisect found first bad commit

(Note the Signed-off-by: header) So… this is all… my own fault? No scapegoat (other than myself), no obvious, simple or easy fix that just comes to mind (and could lead me to simply crank my keyboard and provide that upstream fix)… This is rather unsatisfying.

But what had happened? Is there a quick fix? Can I finish my update/upgrade processes before leaving for the Free Silicon Conference? Can we prevent such problems in the future?

In every live system there are magic numbers. These numbers, of course yield no magic upon those who say them, neither do they provide magical insight or other magical properties. Magical numbers are simply dubbed magical, because "hard-coded", "just came-to-be", "don't ask" or other, probably more adequate nomenclature would fail to raise any eyebrows. One of these numbers is 300. Somewhat hidden in the vast treasure of the GNU Guix Reference Manual in Chapter 22.10.2 Managing Branches and Patches we can read the following sentence:

Changes which affect more than 300 dependent packages (see Invoking guix refresh) should first be pushed to a topic branch other than master

In the audio team in Guix we have the following kinds of packages. Many are simple leaf-packages (i.e. packages that no other packages depend upon): audio synthesizers, music notation applications, effect plugins, etc. There are a number of rather specific libraries for one sub-domain or another within the realm of sound. And then there are the bare essentials in (Linux-driven) audio for modern computing stacks.

ALSA (and its tools and libraries) belong to that last group.

$ guix refresh --list-dependent alsa-lib
Building the following 2047 packages would ensure 4452 dependent packages are rebuilt: xjackfreak@1.0 guitarix-lv2@0.44.1 guitarix@0.44.1 spectacle-analyzer@2.0 geonkick@3.6.2 x42-plugins@20230701 shiru-lv2@0.0-1.08853f9 setbfree@0.8.13 foo-yc20@1.3.0 vl1-emulator@1.1.0.0 gxtuner@3.0 non-timeline@1.9.5-5.257ec59 non-sequencer@1.9.5-5.257ec59 patchmatrix@0.16.0 non-mixer@1.9.5-5.257ec59 ninjas2@0.2.0 wolf-spectrum@1.0.0 dragonfly-reverb@3.2.10 wolf-shaper@1.0.2 klick@0.12.2 bluez-alsa@4.3.1 python-pyalsaaudio@0.11.0 alsa-midi-latency-test@0.0.5-0.07e43f8 [...]

Since either of these numbers clearly exceeds 300 (and since we had some other audio-related packages with similar impact in the upgrade queue) we pushed the patch above on a dedicated `audio-team` branch.

Once that branch is ready, we open a special issue on the old, now mostly (except, I think, for this very application) deprecated issue tracker and wait for the QA system to work the branches that are in front of our branch in the queue.

I remember being somewhat stressed during that time frame, with my expectation (being able to inspect QA's results) not matching the reality, unfortunately.

Ideally (note to my future self), we would have some exhaustive audio package manifest ready, somewhere, which we could try to open a guix shell in an updated guix time-machine environment in. This could suffice as a test for a QA mechanism to provide the answer: should we push to master and indicate where more fixing is needed.

It is late-ish, already night. I am tired, although excited for my trip to Ljubljana. I try an obligatory quick but easy fix: More often than not, a simple package update takes care of such issues, since significant changes upstream get fixed in the dependent packages.

Sadly, running guix refresh -u dssi does not provide. So I do the least I can: I open an issue on the Guix Codeberg project, so efforts to resolve the issue can be taken up and discussed collectively.

Fortunately (yes, community efforts are awesome!), long-time user and community member rekado manages to fix the package just three days later.

As a part of the audio-team in GNU Guix I get any and all messages with that label into my email inbox, so I am able to see, review, push to master and close both the Pull Request and the Issue swiftly.