Next: Tracking Bugs and Patches, Previous: Estilo de código, Up: Contribuindo [Contents][Index]
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 git format-patch
sent to the guix-patches@gnu.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 Configurando o 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 Patches). 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 Enviando uma série de patches).
Por favor, escreva os logs de commit no formato de ChangeLog (see Change Logs in GNU Coding Standards); você pode verificar o histórico de commit para exemplos.
Antes de enviar um patch que adicione ou modifique uma definição de pacote, execute esta lista de verificação:
gpg --verify
.
guix lint pacote
, sendo pacote o nome do pacote
novo ou modificado e corrija quaisquer erros que forem relatados
(see Invocando guix lint
).
guix style package
to format the new package definition
according to the project’s conventions (see Invoking guix style
).
guix
build pacote
.
qemu-binfmt-service-type
to emulate them. In
order to enable it, add the virtualization
service module and the
following service to the list of services in your operating-system
configuration:
(service qemu-binfmt-service-type
(qemu-binfmt-configuration
(platforms (lookup-qemu-platforms "arm" "aarch64"))))
Então, reconfigure seu sistema.
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,
respectively:
guix build --system=armhf-linux --rounds=2 hello guix build --system=aarch64-linux --rounds=2 hello
Às vezes, os pacotes incluem cópias do código-fonte de suas dependências como uma conveniência para os usuários. No entanto, como uma distribuição, queremos garantir que esses pacotes acabem usando a cópia que já temos na distribuição, se houver. Isso melhora o uso de recursos (a dependência é criada e armazenada apenas uma vez) e permite que a distribuição faça alterações transversais, como aplicar atualizações de segurança para um determinado pacote de software em um único local e fazê-las afetar todo o sistema – algo que cópias incluídas impedem.
guix size
(see Invocando 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 Pacotes com múltiplas saídas), and which optional
dependencies should be used. In particular, avoid adding texlive
as
a dependency: because of its extreme size, use the texlive-tiny
package or texlive-union
procedure instead.
guix refresh --list-dependent package
will help you do that (see Invocando guix refresh
).
Dependendo do número de pacotes dependentes e, portanto, da quantidade de recompilação induzida, os commits vão para diferentes ramos, ao longo das seguintes linhas:
Ramo master
(alterações não disruptivas).
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 staging
or core-updates
branches, they will be forked and renamed with the suffix -frozen
, at
which time only bug fixes may be pushed to the frozen branches. The
core-updates
and 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.
Uma maneira simples de fazer isso é compilar o mesmo pacote várias vezes
seguidas em sua máquina (see Invocando guix build
):
guix build --rounds=2 meu-pacote
Isso é suficiente para capturar uma classe de problemas comuns de não-determinismo, como registros de data e hora ou saída gerada aleatoriamente no resultado da compilação.
Another option is to use guix challenge
(see Invocando guix challenge
). You may run it once the package has been committed and built
by 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
run 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.
Exemplos de alterações não relacionadas incluem a adição de vários pacotes ou uma atualização de pacote juntamente com correções para esse pacote.
guix
style
script to do that automatically for you (see Formatação de código).
guix download
). Use URLs confiáveis, não os gerados. Por exemplo, os arquivos do
GitHub não são necessariamente idênticos de uma geração para a seguinte,
portanto, nesse caso, geralmente é melhor clonar o repositório. Não use o
campo name
no URL: não é muito útil e se o nome mudar, o URL
provavelmente estará errado.
guix pull
with:
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
master
, say core-updates
, specify it in the subject like
‘[PATCH core-updates] …’.
You may use your email client or the git send-email
command
(see Enviando uma série de patches). 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 guix-patches@gnu.org. 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_NUMBER-done@debbugs.gnu.org.
Next: Tracking Bugs and Patches, Previous: Estilo de código, Up: Contribuindo [Contents][Index]