[Top][All Lists]

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

April update on (Guix Data Service)

From: Christopher Baines
Subject: April update on (Guix Data Service)
Date: Thu, 07 May 2020 21:35:48 +0100
User-agent: mu4e 1.2.0; emacs 26.3


This follows on from the email I send at the end of March [1].


Some notable and exciting things have happened in April, so I wanted to
send out another update.

Firstly, there's now commits from 3 people in the Git repository, up
from 2 last month. Thanks Vincent for sending in a patch :)

Probably the most significant thing that happened recently is that
Danjela was accepted for the Outreach internship related to the Guix
Data Service and internationalization support [2]. Outreachy internships
last ~3 months, and for the May 2020 period they formally start on the
19th of May (so a week and a bit from the sending of this
email). Danjela has already made some good improvements to the Guix Data
Service, so I'm sure there's more to come over the next few months.


Some of the things Danjela worked on over the last month include making
it possible to filter by locale on the lint warnings page [3], adding a
JSON representation for the jobs page [4], and a plain text
representation of the log for a job [5].


One small change I made in relation to the excellent work happening
around the GNU Hurd is to add i586-gnu as a system you can filter
by. This will come in useful once core-updates is merged.

In relation to the work I've been doing on the new Guix Build
Coordinator [6], I did some work on the package derivations page for a
revision. You can now avoid getting the data about builds which makes
the page load a lot faster [7], and get the data in JSON. There's a
script [8] in the guix-build-coordinator Git repository that can query
this page and enqueue builds for the derivations.


Thinking about substitute availability, I added some filters to the not
so visible package derivation outputs page [9]. These allow you to
filter for substitute availability, including or excluding outputs based
on whether they're available or not from different substitute servers.


This page is linked to from a new page I worked on [10], which shows
substitute availability in a similar style to the package
reproducibility page. This is still very much a work in progress, so
don't take the data on that page too seriously. It's probably more a
representation of how up to date the information the Guix Data Service
has regarding substitutes is.


I worked a bit on some strange packages, mostly because the data was
causing issues with the package reproducibility page. dev86 is a good
example of this strange behaviour, if you ask Guix for a derivation for
dev86, it doesn't matter what system you ask for, you'll always get a
derivation for i686-linux. The Guix Data Service now double checks that
when it asked for a derivation for a particular system, that was
actually what was generated. If you search the logs (like [11]) for
recent revisions for "produced a derivation for system", you'll see
which derivations are not being ignored. As well as fixing this going
forward, I also removed the strange data from the database.


There were some strange errors relating to handling of the log data,
which I added some guards against. I also fixed up some issues
processing old Guix revisions. There's still ~600 revisions [12] queued
up for processing from early 2019.


In terms of operations for, I wanted to track the disk
space usage, so I did some work on Prometheus [13] and I also setup
Grafana [14]. This has already proved useful in terms of spotting
potential problems with disk space usage before things break, and I hope
to setup some alerting at some point so that I don't even have to look
at the data regularly. The setup seems to be reasonably stable at the
moment, but I am going to need to do some work to allow the database to
grow further some point within the next month or two. My plan currently
is to add an additional volume to the virtual machine, and using the
tablespaces feature of PostgreSQL, move a few of the larger tables over.


As always, if you have any questions or comments, just let me know :)


Attachment: signature.asc
Description: PGP signature

reply via email to

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