Development is done using the Git distributed version control system.
Thus, access to the repository is not strictly necessary. We welcome
contributions in the form of patches as produced by
format-patch sent to the firstname.lastname@example.org mailing list
(see Submitting patches to a project in Git User Manual).
Contributors are encouraged to take a moment to set some Git repository
options (see Configuring Git) first, which can improve the
readability of patches. Seasoned Guix developers may also want to look
at the section on commit access (see Commit Access).
This mailing list is backed by a Debbugs instance, which allows us to
keep track of submissions (see Tracking Bugs and Changes).
Each message sent to that mailing list gets a new tracking number
assigned; people can then follow up on the submission by sending email
ISSUE_NUMBER@debbugs.gnu.org, where ISSUE_NUMBER
is the tracking number (see Sending a Patch Series).
Please write commit logs in the ChangeLog format (see Change Logs in GNU Coding Standards); you can check the commit history for examples.
You can help make the review process more efficient, and increase the chance that your patch will be reviewed quickly, by describing the context of your patch and the impact you expect it to have. For example, if your patch is fixing something that is broken, describe the problem and how your patch fixes it. Tell us how you have tested your patch. Will users of the code changed by your patch have to adjust their workflow at all? If so, tell us how. In general, try to imagine what questions a reviewer will ask, and answer those questions in advance.
Before submitting a patch that adds or modifies a package definition, please run through this check list:
guix lint package, where package is the name of the new or modified package, and fix any errors it reports (see Invoking
guix style packageto format the new package definition according to the project’s conventions (see Invoking
guix build package.
qemu-binfmt-service-typeto emulate them. In order to enable it, add the
virtualizationservice module and the following service to the list of services in your
(service qemu-binfmt-service-type (qemu-binfmt-configuration (platforms (lookup-qemu-platforms "arm" "aarch64"))))
Then reconfigure your system.
You can then build packages for different platforms by specifying the
--system option. For example, to build the "hello" package for
the armhf or aarch64 architectures, you would run the following
guix build --system=armhf-linux --rounds=2 hello guix build --system=aarch64-linux --rounds=2 hello
Sometimes, packages include copies of the source code of their dependencies as a convenience for users. However, as a distribution, we want to make sure that such packages end up using the copy we already have in the distribution, if there is one. This improves resource usage (the dependency is built and stored only once), and allows the distribution to make transverse changes such as applying security updates for a given software package in a single place and have them affect the whole system—something that bundled copies prevent.
guix size(see Invoking
guix size). This will allow you to notice references to other packages unwillingly retained. It may also help determine whether to split the package (see Packages with Multiple Outputs), and which optional dependencies should be used. In particular, avoid adding
texliveas a dependency: because of its extreme size, use
guix refresh --list-dependent packagewill help you do that (see Invoking
A simple way to do that is by building the same package several times in
a row on your machine (see Invoking
guix build --rounds=2 my-package
This is enough to catch a class of common non-determinism issues, such as timestamps or randomly-generated output in the build result.
Another option is to use
guix challenge (see Invoking
guix challenge). You may run it once the package has been committed and
ci.guix.gnu.org to check whether it obtains the same
result as you did. Better yet: Find another machine that can build it
guix publish. Since the remote build machine is
likely different from yours, this can catch non-determinism issues
related to the hardware—e.g., use of different instruction set
extensions—or to the operating system kernel—e.g., reliance on
uname or /proc files.
Examples of unrelated changes include the addition of several packages, or a package update along with fixes to that package.
guix stylescript to do that automatically for you (see Formatting Code).
guix download). Use reliable URLs, not generated ones. For instance, GitHub archives are not necessarily identical from one generation to the next, so in this case it’s often better to clone the repository. Don’t use the
namefield in the URL: it is not very useful and if the name changes, the URL will probably be wrong.
guix pull --url=/path/to/your/checkout --profile=/tmp/guix.master
When posting a patch to the mailing list, use ‘[PATCH] …’ as
a subject, if your patch is to be applied on a branch other than
core-updates, specify it in the subject like
‘[PATCH core-updates] …’.
You may use your email client or the
git send-email command
(see Sending a Patch Series). We prefer to get patches in plain
text messages, either inline or as MIME attachments. You are advised to
pay attention if your email client changes anything like line breaks or
indentation which could potentially break the patches.
Expect some delay when you submit your very first patch to email@example.com. You have to wait until you get an acknowledgement with the assigned tracking number. Future acknowledgements should not be delayed.
When a bug is resolved, please close the thread by sending an email to ISSUE_NUMBERfirstname.lastname@example.org.