Next: Tracking Bugs and Changes, Previous: Estilo de codificación, Up: Contribuir [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 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 Acceso al repositorio).
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 to
ISSUE_NUMBER@debbugs.gnu.org
, where ISSUE_NUMBER is the
tracking number (see Envío de una serie de parches).
Le rogamos que escriba los mensajes de revisiones en formato ChangeLog (see Change Logs in GNU Coding Standards); puede comprobar la historia de revisiones en busca de ejemplos.
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.
Antes de enviar un parche que añade o modifica una definición de un paquete, por favor recorra esta lista de comprobaciones:
gpg --verify
.
guix lint paquete
, donde paquete es el nombre
del paquete nuevo o modificado, y corrija cualquier error del que informe
(see Invocación de guix lint
).
guix style package
to format the new package definition
according to the project’s conventions (see Invoking guix style
).
guix
build package
.
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"))))
Una vez hecho esto, reconfigure su 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
A veces, paquetes incluyen copias embebidas del código fuente de sus dependencias para conveniencia de las usuarias. No obstante, como distribución, queremos asegurar que dichos paquetes efectivamente usan la copia que ya tenemos en la distribución si hay ya una. Esto mejora el uso de recursos (la dependencia es construida y almacenada una sola vez), y permite a la distribución hacer cambios transversales como aplicar actualizaciones de seguridad para un software dado en un único lugar y que afecte a todo el sistema—algo que esas copias embebidas impiden.
guix size
(see Invocación de 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 Paquetes con múltiples salidas), and which optional
dependencies should be used. In particular, avoid adding texlive
as
a dependency: because of its extreme size, use texlive-updmap.cfg
procedure instead.
guix refresh --list-dependent package
will help you
do that (see Invocación de guix refresh
).
Una forma simple de hacerlo es construyendo el mismo paquete varias veces
seguidas en su máquina (see Invocación de guix build
):
guix build --rounds=2 mi-paquete
Esto es suficiente una clase común de problemas de no-determinismo, como las marcas de tiempo o salida generada aleatoriamente en el resultado de la construcción.
Otra opción es el uso de guix challenge
(see Invocación de guix challenge
). Puede ejecutarse una vez la revisión del paquete haya sido
publicada y construida por bordeaux.guix.gnu.org
para comprobar
si obtuvo el mismo resultado que usted. Mejor aún: encuentre otra máquina
que pueda construirla y ejecute guix publish
. Ya que la máquina
remota es probablemente diferente a la suya, puede encontrar problemas de
no-determinismo relacionados con el hardware—por ejemplo, el uso de un
conjunto de instrucciones extendido diferente—o con el núcleo del sistema
operativo—por ejemplo, dependencias en uname
o archivos
/proc.
Ejemplos de cambios sin relación incluyen la adición de varios paquetes, o una actualización de un paquete junto a correcciones a ese paquete.
guix
style
script to do that automatically for you (see Formato del código).
guix download
). Use URL fiables, no generadas. Por ejemplo, los archivos de
GitHub no son necesariamente idénticos de una generación a la siguiente, así
que en este caso es normalmente mejor clonar el repositorio. No use el campo
name
en la URL: no es muy útil y si el nombre cambia, la URL
probablemente estará mal.
guix pull
con:
guix pull --url=/ruta/a/su/copia --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, the git send-email
command
(see Envío de una serie de parches) or the mumi send-email
command
(see Debbugs User Interfaces). 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.
NdT: En esta traducción se ha optado por usar el femenino para referirse a personas, ya que es el género gramatical de dicha palabra. Aunque las construcciones impersonales pueden adoptarse en la mayoría de casos, también pueden llegar a ser muy artificiales en otros usos del castellano; en ocasiones son directamente imposibles. Algunas construcciones que proponen la neutralidad de género dificultan la lectura automática (-x), o bien dificultan la corrección automática (-e), o bien aumentan significativamente la redundancia y reducen del mismo modo la velocidad en la lectura (-as/os, -as y -os). No obstante, la adopción del genero neutro heredado del latín, el que en castellano se ha unido con el masculino, como construcción neutral de género se considera inaceptable, ya que sería equivalente al “it” en inglés, nada más lejos de la intención de las autoras originales del texto.
Next: Tracking Bugs and Changes, Previous: Estilo de codificación, Up: Contribuir [Contents][Index]