●About
●About LibrePlanet
●Mission Statement
●Founding documents
●Support this Community
●Code of Conduct
●Anti-harassment policy
●Teams
●Activists
●Wiki Helpers
●LibrePlanet Artists
●FSF Community Team
●Local & Student Teams
●Conferences
●LibrePlanet Conference
●Non-official
●Get involved
●Participate
●Discussion channels
●Events
●Login
We run regular online Guix Social sessions as a place for everyone to come along and learn about Guix, share their passion for all things reproducible and chat about anything in the Guix, Scheme and Linux world!
Sometimes we also do patch review sessions. The goal of reviewing patches is to help Guix project accept contributions while maintaining our quality standards.
For each session please join through the Meetup link next to each event to get updates. If you don't want to join through Meetup the session is run on Jitsi at https://meet.jit.si/london-guix-meetup
These are the sessions we're planning on running - click Expand to check the topic, and register using the Meetup link next to each one:
Tuesday, 22nd April 2025 - Patch Review and Hacking session - Register on Meetup
Guix social, patch review if there's no talk.
Thursday, 22nd May 2025 - Register on Meetup
Guix social.
Wednesday, 18th June 2025 - Register on Meetup
Guix social
Tuesday, 15th July 2025 - Register on Meetup
Guix social.
Wednesday, 14th August 2025 - Register on Meetup
Guix social.
This session will run at:
18:00 UTC, 18:00 GMT (London), 19:00 CET (Paris), 13:00 EST (New York)
--
The purpose of a patch review is to make it easier for committer to accept the contribution. This means checking that it follows the generally accepted standards of the project and working with the contributor to help them if possible. Not everyone is a seasoned Guix developer, so think of reviews as having a couple of levels:
Debbugs has some clever capabilities for handling issue reporting and tagging them. Due to the shared configuration we're a bit limited in what we can do, but usertags give us some clear ways set-up reports
The states I've used:
Tools that are useful are:
As an alternative to playing the mailing list git-pw (not in guix) talks directly to patchworks. If you'd rather deal directly with git then patman lets you keep notes about patches and reviewers in a git commit note.
git config user.name "Your Name" git config user.email "your@email" git config b4.attestation-policy off git config b4.midmask https://yhetil.org/guix-patches/%s # search mask is used when you look for updated trailers git config b4.searchmask 'https://yhetil.org/guix-patches/?x=m&t=1&q=%s'
Patch review is fun and a great way to learn about various parts of the system. However, it's quite difficult for people to send patches and sometimes it's boring seeing the same "mistakes" multiple times. Try to be nice and polite to contributors!
Use QA and Debbugs to find patches to review. There's plenty of unloved patches in the system:
Check that no-one else has set themselves as the owner by looking at the bug:
export DEBEMAIL=your-email@domain.com bts --bts-server https://debbugs.gnu.org/ --mbox show NNNN
Make yourself the owner:
export DEBEMAIL=your-email@domain.com bts --bts-server https://debbugs.gnu.org --mutt owner NNNN !
If you are doing it by email:
to: control@debbugs.gnu.org subject: setting owner on NNNN owner NNNN ! quit
The subject doesn't really matter (debbugs will ignore it); the owner can be anyone, the exclamation mark is a shorthand for your own email address
Set a user-tag of under-review:
bts --bts-server https://debbugs.gnu.org --mutt user guix@debbugs.gnu.org , usertag NNNN + under-review
A bit annoyingly you will have to edit the 'user' part of the email to be 'user guix' without the rest of the email. The comma between the user and the usertag is important as it tells debbugs to format it as two messages.
If you don't want to use Mutt or bts then you can also send a plain text email:
to: control@debbugs.gnu.org subject: <doesn't matter> user guix usertag NNN + under-review quit
The plus sign between the usertag and the usertag itself (under-review in this example) is important.
To check that your bug is now tagged correctly see this Debbugs under-review report. The alternative is:
export BROWSER=w3m bts --bts-server=https://debbugs.gnu.org bugs usertag:under-review users=guix status=open
Use a worktree or a branch to use with this patch and review. This is just one way to do it:
# update the local repository cd workspace/guix-packages/guix git checkout master git pull
# create the worktree: <location it will be> -b <branch> <origin to track> --track git worktree add $HOME/user/guix-packages/worktrees/issue-NNNN -b issue-NNNN origin/master --track
Initialise StackedGit on the worktree - I find this easiest because it shows a 'stack of patches'.
cd $HOME/user/workspace/guix-packages/worktrees/issue-NNNN stg init stg branch --describe "Patch review for NNNN"
Start a separate build split to build guix:
$ guix shell --container --nesting --development guix [env]$ make clean && make clean-go [env]$ ./bootstrap [env]$ ./configure [env]$ make [env] exit
Find the patch and download it to the local system so we can apply it.
Open up the bug with bts and read it in Mutt: what's really nice is that we can see the whole thread and use the bug number to find everything. We could save the patch using Mutt, but it's actually really easy to save the whole thread using 'b4'. ::
export DEBEMAIL=your-email@domain.com bts --bts-server https://debbugs.gnu.org/ --mbox show NNNN
In Mutt find the cover letter and hit 'h' to show headers and copy the 'Message-ID'. The easiest way to download the patch with the correct settings is to use b4
b4 am --check-newer-revisions <Message-ID> b4 am -c -t <blah>
What's really nice here is that it downloads the cover-letter separately from the patches in an mbox which makes it easy to go back and re-read the cover (mutt -f xx) if you need a reminder.
NOTE the whole thing could be done in one command bts --bts-server http://debbugs.gnu. org --mbox show 67257 | b4 shazam
If it's been successfully processed it can be grabbed from:
https://git.guix-patches.cbaines.net/guix-patches/refs/heads
If it was not processed then we have to get it from the system. If it wasn't then you have to grab the email from the public-inbox mailing list `b4 shazam` will be the easiest way.
We have the patch (or the msg-id) so we can now apply it to the local tree:
b4 shazam <msg-id>
# if you downloaded it already use --use-local-mbox b4 shazam --use-local-mbox <cover.mbx> <msg-id>
If you're using StackedGit you then need to 'suck' the commits that were just done into the the 'Stack'
# tell it the number to pull in stg uncommit --number=N
# check it sees the whole stack correctly stg series --reverse --indices
Start a separate build environment and build the patch that's been applied.
guix shell --development guix --container --network --nesting coreutils ./pre-inst-env guix build <package@version>
Open a separate terminal or Tmux split to create a test environment:
guix shell --development guix --container --nesting coreutils nss-certs
./pre-inst-env guix package --install <package>
<try the package out>
This tests that the build is deterministic. Switch back into the **build split** (or terminal):
./pre-inst-env guix build --no-grafts --no-substitutes --check --source <package>
./pre-inst-env guix build --no-grafts --no-substitutes --check <package>
Now it's time to check the patch for commit format, spelling and so forth:
stg edit
Check the code itself:
vim <gnu/packages/whatever.scm> stg refresh <gnu/packages/whatever.scm>
You can run the styler, but a lot of the code isn't similarly formatted so use carefully:
./pre-inst-env guix style --dry-run <package> ./pre-ins-env guix style --styling=arguments <package>
Check that guix lint doesn't have a problem:
./pre-inst-env guix lint <package>
Add a 'Reviewed-by' patch trailer that goes above the `Change-Id` trailer that's automatically provided:
stg edit
Reviewed-by: Jane Smith <jsmith@smith.com>
At this point go back to the start to review the next patch in the series. If you're using Stacked Git this should be:
stg series --reverse --indices stg goto N
At this point there are some patches with local edits, and at a minimum a changed 'Reviewed-by' Trailer. We need to generate a new cover-letter, reroll the patches and send them off.
First get the Message-ID of the original 'cover-letter' that was sent, so our patches are sent as 'replies' to that one:
export DEBEMAIL=user@userplace.com bts --bts-server https://debbugs.gnu.org/ --mbox show NNNN
This brings up the emails in your email client (in Mutt hit h for to see the headers).
We're now ready to export our updated patches:
$ cd <worktree location> $ guix shell --development guix git:send-email [env]$ keychain --agents ssh,gpg # remove any old patch exports previously done $ rm ../stg-out/*
$ stg email format --output-directory ../stg-out --numbered --base=auto \
--to xxx@debbugs.gnu.org --in-reply-to <cover-letter-Message-ID> --thread=shallow \
--cover-letter \
--reroll-count=2 \
--all
The ``--thread=shallow`` option means that all emails will be a shallow thread against the message in ``--in-reply-to`` - so just one indent. It's a reroll as we've added the trailers, and particularly if there are any other changes. Emailing to the bug seems to automatically reflect it to guix-patches
Now edit the cover letter and provide your comments from the review:
vim ../stg-out/v2-000-cover-letter.patch
Describe any changes that were made:
Review:
* submission: checked commit format, synopsis and description
* submission: license, patch applies cleanly
* functionality: test installed, guix lint is clean
* code: checked style to packages around it
* added: Reviewed-by commit trailer
* re-roll to trigger QA build
* Question for committer: XXX
When ready send the email to the bug:
git send-email --to=xxx@debbugs.gnu.org --cc=guix-patches@gnu.org \
--no-thread --dry-run --no-chain-reply-to ../stg-out/*
It automatically adds the original person and the Reviewed-by people.
Due to the re-roll the QA system will pick it up, you should also change the state so that others know what to do:
It's currently got the usertag 'under-review' - this can be removed if you've finished.
Three possible options:
1. If there were questions to the developer and it can't move forward -> 'waiting-on-contributor'
2. If there are serious questions that you want other eyes on -> 'escalated-review-request'
3. If it's ready to go forward 'reviewed-looks-good'
Using bts you would do:
# remove your under-review tag export DEBEMAIL=your-email@domain.com bts --bts-server https://debbugs.gnu.org --mutt user guix@debbugs.gnu.org , usertag NNNN - under-review
# add either waiting-on-contributor, escalated-review-request # or reviewed-looks-good bts --bts-server https://debbugs.gnu.org --mutt user guix@debbugs.gnu.org , usertag NNNN + reviewed-looks-good
Otherwise, send email:
to: control <at> debbugs.gnu.org subject: reviewed usertag bug#NNNN user guix usertag NNNN - under-review usertag NNNN + reviewed-looks-good quit
Check that the bug has had the under-review usertag removed.
Confirm that it's got the waiting-on-contributor, escalated-review-requestorreviewed-looks-good usertags.
Congratulations you've done the review - there may be some further conversation and eventually it should be applied - time to look at the next one!
[link to the guix emacs package]
Upterm is a pair programming capability. We can use it to watch someone doing a demo (read-only) or to work together on a patch (read-write).
If you are the 'leader' this is what you do:
ssh user@host
# upterm and tmux have already been configured to start a session q
# to show the details for other users to SSH into do upterm session current
All other users connect by:
ssh <details show from upterm session current>
To leave a session that is read-write do NOT use 'quit' - or you will quite it for everyone. To leave shut the SSH session:
~ .
What do do if you get an odd error message - create a default SSH key:
ssh-keygen -t ed25519 -q -a 50 -f ~/.ssh/id_ed25519 -N ""
This page was a featured resource in March 2025.
The Free Software Foundation (FSF) is a nonprofit with a worldwide mission to promote computer user freedom.
We defend the rights of all software users. (Read more)