[Top][All Lists]

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

Tracking and inspecting how Guix changes over time

From: Christopher Baines
Subject: Tracking and inspecting how Guix changes over time
Date: Fri, 08 Feb 2019 13:20:39 +0000
User-agent: mu4e 1.0; emacs 26.1

In summary, I've started playing around with a new service, I'm
currently calling it the "Guix Data Service". The code is here [1], it's
based off of Ricardo's excellent Mumi, and at the moment only does one
thing, a basic comparison of two different versions (commits) of Guix
for the few commits it has data for. I've got it up and running here


This follows on from the work around reviewing patches for Guix, at the
moment, I've setup Patchwork [3] to gather up patches sent to
guix-patches, Laminar [4] to apply those patches to the Guix master
branch and then push the resulting changes to a git repository [5].


To get to the point where as part of some automated review process,
packages affected by patch series can be built, and then the results of
this compared with the previous state in Guix, it's necessary to
understand if the packages currently build successfully, and then you
need to check if those same packages build with the patches applied.

This is what I'm attempting to work towards with this new service. You
give it a commit and a repository URL. It then fetches that revision of
Guix using the same mechanism as guix pull, and extracts the information
about packages through the Guix inferiors code. This information about
packages is then stored in the database.

For querying, you provide two commits, and the comparison is generated
from the information stored in the database. It displays new packages,
removed packages, packages where the available versions have changed,
and then "Other changed packages" which are ones where the metadata
(synopsis, description, home-page, ...) or derivation has changed.

I've hooked this up to Patchwork and Laminar, so you can see some
initial data in the following 3 examples.

The following links relate to a couple of patches affecting the Ruby
build system.

Patchwork series:
Laminar job:
Git commits:

The following links relate to some printing changes in Gnome.

Patchwork series:
Laminar job:
Git commits:

The following links relate to some new Ruby packages.

Patchwork series:
Laminar job:
Git commits:

So, in terms of reviewing patches, I don't think this isn't actually
that helpful, yet. I would guess that it's still more useful to look at
the actual patches.

However, I think this kind of information could be useful in the future,
for example checking that patches that shouldn't affect any derivations
indeed don't, or providing a more general way of assessing the number of
rebuilds that a patch series would cause.

I've also gone with this very general approach of a service to handle
data relating to Guix, as I think it could be useful for purposes other
than reviewing patches, assessing security issues for example.

In terms of building the packages that correspond to patches, one way
forward that I have in mind is to somehow get a Cuirass instance to
build the branch corresponding to a patch series. Then, work out what
packages have been affected by querying the "Guix Data Service". Then
query Cuirass to work out if those affected packages built before the
changes, and also if they build with the patches applied.

Going back to this new service though, I've hooked it up to the
patchwork-test-series [6] job in Laminar. It enqueues a job to load the
data for the "base" commit, the one the patches are being applied to,
and then echo's the URL to use to compare the two
commits. Unfortunately, this URL won't work for the following reason...


Currently, I'm only enqueuing the base commit, as I'm a little concerned
about the security implications of effectively running guix pull on Guix
with the patches applied. For the examples above, I've manually enqueued
the commit resulting from the patches being applied.

As far as I can see, guix pull/the channels code directly evaluates some
Guile code from the source repository. It would be great if this could
somehow be isolated to guard against any malicious patches that try to
attack the machine running the Guix Data Service, I haven't thought much
about how yet.

Similarly, using the inferiors approach to extract out information from
Guix requires running a REPL from the target Guix. This could also pose
security issues. I was wondering if it was possible to run the REPL
within a container, to at least isolate it a bit from the system.

One other point is that while I've gone with the "web service" approach
here, I think it would be very useful to have a "guix compare" command
that did something similar.

Anyway, this email has got far too long. Any thoughts, just let me know,



Attachment: signature.asc
Description: PGP signature

reply via email to

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