Hey there, now that Guix 1.0 is out I think it’s a good time to improve our tools to allow us to better identify problems with package builds and to better respond to bug reports and patch submissions.
1) Mumi We are using Debbugs for bug reports (bug-g...@gnu.org) and patches (guix-patc...@gnu.org), and one of the interfaces to the bug tracker is the web interface at https://issues.guix.info. This is backed by a little Guile tool called “Mumi”. The code is hosted here: https://git.elephly.net/software/mumi.git Mumi uses guile-email and guile-debbugs to talk to the Debbugs SOAP API (that’s a verbose XML API) and render the results as a web page. Currently, the search isn’t really working so well due to limitations on the Debbugs side, and things are a little slower than they should be. Also, the interface only provides read access — you cannot comment on issues with a web browser. I’d like us to change these two things. Instead of using the Debbugs API for searching I’d like Mumi to keep a local append-only database of email messages and a mutable table of issue meta data (such as the issue status, the submitter, the owner, etc). For write access I’d like us to offer a form that allows people to submit comments right there. We’d need to think about ways to prevent SPAM, obviously. (Options are: spam assassin, user logins, GPG signed text that’s checked against a keyring, etc…) If you’d like to work on this with me, please get in touch! 2) Cuirass Cuirass has a web interface: https://ci.guix.gnu.org/ Unfortunately, it doesn’t yet enable us to answer questions like: - What packages are currently failing to build on aarch64? - What is the history of icecat builds on i686? - Can you show me all builds matching “rust” across all architectures? - What builds are blocked because of this one failing build? Implementing features that would allow us to better see the build status for all of our supported architectures would be very welcome. It would be even better if we could also see an overview of our build nodes and what they are currently doing – how many build slots are still available? Why is only one of the nodes doing any work? We have the freedom to integrate Cuirass more closely with the rest of Guix and the offloading framework, so this seems like a good target. If you find this kind of project interesting please get in touch! You don’t need to know how to do any of these tasks as long as you are motivated to discuss this and help us find solutions together. Let’s do this! -- Ricardo