Tracking and inspecting how Guix changes over time

[Christopher Baines]

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
[2].

1: https://git.cbaines.net/guix/data-service/
2: https://prototype-guix-data-service.cbaines.net/

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].

3: https://patchwork.cbaines.net/project/guix-patches/list/
4: https://laminar.cbaines.net/
5: https://git.cbaines.net/guix/patches/

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.

Issue:            https://issues.guix.info/issue/34385
Patchwork series: 
https://patchwork.cbaines.net/project/guix-patches/list/?series=535
Laminar job:      https://laminar.cbaines.net/jobs/patchwork-test-series/889
Git commits:      
https://git.cbaines.net/guix/patches/log/?h=series-535-version-1&qt=range&q=base-for-series-535-version-1..series-535-version-1
Comparison:       
https://prototype-guix-data-service.cbaines.net/compare?base_commit=6fd72f7094885dc3dbb10431996c445251094915&target_commit=7d70e05d7064f31a8de60b04d22ac16c1953b7a9

The following links relate to some printing changes in Gnome.

Issue:            https://issues.guix.info/issue/34240
Patchwork series: 
https://patchwork.cbaines.net/project/guix-patches/list/?series=482
Laminar job:      https://laminar.cbaines.net/jobs/patchwork-test-series/886
Git commits:      
https://git.cbaines.net/guix/patches/log/?h=series-482-version-1&qt=range&q=base-for-series-482-version-1..series-482-version-1
Comparison:       
https://prototype-guix-data-service.cbaines.net/compare?base_commit=bc041b3e264380bd49025515d3c5d11319aa3f50&target_commit=e396076117623efb6351b845ec61b4572457c3e0

The following links relate to some new Ruby packages.

Issue:            https://issues.guix.info/issue/34217
Patchwork series: 
https://patchwork.cbaines.net/project/guix-patches/list/?series=474
Laminar job:      https://laminar.cbaines.net/jobs/patchwork-test-series/887
Git commits:      
https://git.cbaines.net/guix/patches/log/?h=series-474-version-1&qt=range&q=base-for-series-474-version-1..series-474-version-1
Comparison:       
https://prototype-guix-data-service.cbaines.net/compare?base_commit=bc041b3e264380bd49025515d3c5d11319aa3f50&target_commit=0645e6beb8c1a8818c3764a42dcc8598c8711e7b


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...

6: https://laminar.cbaines.net/cfg/jobs/patchwork-test-series.run

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,

Thanks,

Chris

signature.asc
Description: PGP signature