[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Hurd substitute availability (27.5%) and next steps?

From: Christopher Baines
Subject: Hurd substitute availability (27.5%) and next steps?
Date: Mon, 08 Mar 2021 21:57:20 +0000
User-agent: mu4e 1.4.15; emacs 27.1


So I finally got around to trying the Guix Build Coordinator agent on
the Hurd [1], and builds have been happening on the
build farm that I've been using to test the Guix Build Coordinator when
building things for substitutes.


The tooling I've got for looking at how far things have progressed isn't
great, but either there are blocking builds or some that have got stuck,
as the agents aren't particularly active currently. Anyway, currently
for one recent revision (1462a11dbb3d2256c8693e56a583cfd100e27609) I
tried, guix weather reports 27.5% of substitutes are available. [2]

  → guix weather --system=i586-gnu --substitute-urls= 
  computing 10,415 package derivations for i586-gnu...
  looking for 10,811 store items on
  updating substitutes from ''... 100.0%
    27.5% substitutes available (2,977 out of 10,811)
    4,589.5 MiB of nars (compressed)
    18,975.5 MiB on disk (uncompressed)
    0.214 seconds per request (2,313.6 seconds in total)
    4.7 requests per second
    (continuous integration information unavailable)

The Guix Build Coordinator does have a rudimentary feature to find
"blocking" builds, and it reports these as the top derivations that are
failing, and blocking the highest number of builds (in order from top to
bottom), there are more failures than this, but this is just the top


You can find details about packages and builds from this Guix Data
Service instance [2], the builds can be found on this page for example


The util-linux and tcl failures are both test related, and I believe
building without the tests works. With this data, given a package which
isn't build for the Hurd, say git as an example, it's possible to find
out which relevant builds are failing [4].


So, what are the next steps for Hurd stuff in Guix?

In terms of getting more packages building, and substitute availability,
personally I think it would be useful to disable tests for packages for
i586-gnu if that gets packages building. It's not ideal to not run the
tests, but it's also difficult to investigate the failures and develop
patches if you don't have substitutes for the software you need to do
that (like Git for example).

More generally, I also know of a few important Hurd related issues:

  guix gc support:
  chroot for builds:
  decisions around what's in the build environment:

I had a go at getting a childhurd with a swap partition, but didn't get
that far:

I have reliability issues with the childhurd VMs running Guix Build
Coordinator agents, often I'll be unable to SSH in, and I'm not quite
sure how to debug this. It would be nice to run childhurd VMs for the
guix-patches build coordinator, but ideally they would run reliably and
wouldn't get stuck.

I'm quite new to playing around with the Hurd stuff, but I think it's
quite cool, although I probably need to get back to working more on the
core Guix Data Service and Guix Build Coordinator features.

Have I missed something? It would be nice to be able to collect the bugs
related to the Hurd, I'm not sure how best to do that with debbugs

Any thoughts about next steps?



Attachment: signature.asc
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]