bordeaux.guix.gnu.org

This is a substitute server for Guix.

Availability for x86_64-linux, i686-linux, aarch64-linux, armhf-linux and powerpc64le-linux should be good. i586-gnu substitutes are a work in progress.

Cross built packages from x86_64-linux to i586-pc-gnu, aarch64-linux-gnu and arm-linux-gnueabihf are also available.

Using these substitutes

bordeaux.guix.gnu.org is a default substitute server in recent versions of Guix, so no manual configuration should be necessary.

The URL to use to fetch substitutes is https://bordeaux.guix.gnu.org, and they're signed with the following key.

(public-key
 (ecc
  (curve Ed25519)
  (q #7D602902D3A2DBB83F8A0FB98602A754C5493B0B778C8D1DD4E0F41DE14DE34F#)
  )
 )

On a Guix System

With recent versions of Guix, the %default-substitute-urls and %default-authorized-guix-keys should include bordeaux.guix.gnu.org, so no extra configuration should be necessary.

Aim

The primary aim is to enable qa.guix.gnu.org both by building the Guix master branch as a baseline and also performing builds for other branches and patches.

As a secondary aim, the bordeaux build farm aims to be a good source of substitutes, providing a large number of nars at fast speeds.

Roadmap

• Automatic nar removal policy

  qa.guix.gnu.org submits builds for branches and patches, and some of these nars produced from those builds are never relevant to the master branch.

  The nar-herder is missing some features to enable this, and once they're in place, then a script will need running regularly to schedule removing the old and irrelevant nars. This should free at least a small amount of storage space.

• Hosting for data.guix.gnu.org

  data.guix.gnu.org is currently used to compute and provide derivations for builds, Chris rents the hosting from Hetzner but this isn't a viable long term approach.

• Monitoring and observability

  Currently Prometheus and Alertmanager are used, but this needs moving to proper hosting as well as getting packages and services in to Guix.

  There's also a need to improve the bffe to show more information about agents, for example recent build events.

• Build coordinator database backup

  The build coordinator SQLite database is stored on bayfront, but isn't currently backed up.

  Having backups would make it easier to restore the database to a recent state in the case of a problem (hardware or otherwise) that causes the database to be lost or corrupted.

• Computing the guix self derivations can require performing builds (#74942)

  This slows down the data service, requires it to use emulation to compute derivations for non x86_64-linux systems, and can cause it to fail to process revisions when builds take too long.

• bordeaux build logs storage and backup

  The build coordinator collects build logs and they're currently stored on bayfront in /var/lib/guix-build-coordinator/build-logs. There should be a log file for every build that's ever happened, so ~7,400,000 as of the start of 2025. There's not a plan currently about what to do with the logs long term.

  Assuming long term storage is the plan, as they're just stored on a single machine, having some additional redundancy would decrease the chance that any are lost.

• Build coordinator database maintenance

  The build coordinator SQLite database grew from 43.2GiB to 97.4GiB in 2024. Performance still seems to be OK.

  The database will continue to grow, so if performance does become and issue or there's just a need to save space, then the build coordinator will need some work to enable pruning the database.