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
