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
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 配置Git) first, which can improve the readability of patches. Seasoned Guix
developers may also want to look at the section on commit access
This mailing list is backed by a Debbugs instance, which allows us to keep
track of submissions (see 跟踪程序漏洞和补丁). Each message sent
to that mailing list gets a new tracking number assigned; people can then
follow up on the submission by sending email to
ISSUE_NUMBER@debbugs.gnu.org, where ISSUE_NUMBER is the
tracking number (see 发送补丁系列).
请以ChangeLog格式（see Change Logs in GNU代码规范）写commit日志；你可以浏览commit历史里的例子。
guix lint 软件包，软件包是新添加的或修改过的软件包的名字，修复它报告的错误（see Invoking
guix style packageto format the new package definition according to the project’s conventions (see Invoking
guix build 软件包命令确保这个软件包可以在你的平台上构建。
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"))))
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 commands,
guix build --system=armhf-linux --rounds=2 hello guix build --system=aarch64-linux --rounds=2 hello
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 有多个输出的软件包), and which optional dependencies should be used. In particular, avoid adding
texliveas a dependency: because of its extreme size, use the
guix refresh --list-dependent packagewill help you do that (see Invoking
staging branch (non-disruptive changes). This branch is intended to
be merged in
master every 6 weeks or so. Topical changes (e.g., an
update of the GNOME stack) can instead go to a specific branch (say,
gnome-updates). This branch is not expected to be buildable or
usable until late in its development process.
core-updates branch (may include major and potentially disruptive
changes). This branch is intended to be merged in
master every 6
months or so. This branch is not expected to be buildable or usable until
late in its development process.
All these branches are tracked by
our build farm and merged into
master once everything has been
successfully built. This allows us to fix issues before they hit users, and
to reduce the window during which pre-built binaries are not available.
When we decide to start building the
branches, they will be forked and renamed with the suffix
which time only bug fixes may be pushed to the frozen branches. The
staging branches will remain open to accept
patches for the next cycle. Please ask on the mailing list or IRC if unsure
where to place a patch.
guix build --rounds=2 <我的软件包>
Another option is to use
guix challenge (see Invoking
guix challenge). You may run it once the package has been committed and built
ci.guix.gnu.org to check whether it obtains the same
result as you did. Better yet: Find another machine that can build it and
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
guix stylescript to do that automatically for you (see 格式化代码).
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 发送补丁系列). 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.