1008 lines
43 KiB
Text
1008 lines
43 KiB
Text
@node Mitwirken
|
|
@chapter Mitwirken
|
|
|
|
Dieses Projekt basiert auf Kooperation, daher benötigen wir Ihre Hilfe, um
|
|
es wachsen zu lassen! Bitte kontaktieren Sie uns auf
|
|
@email{guix-devel@@gnu.org} und @code{#guix} im Freenode-IRC-Netzwerk. Wir
|
|
freuen uns auf Ihre Ideen, Fehlerberichte, Patches und alles, was hilfreich
|
|
für das Projekt sein könnte. Besonders willkommen ist Hilfe bei der
|
|
Erstellung von Paketen (@pxref{Paketrichtlinien}).
|
|
|
|
@cindex Verhaltensregeln, für Mitwirkende
|
|
@cindex Verhaltenskodex für Mitwirkende
|
|
Wir möchten eine angenehme, freundliche und von Belästigungen freie Umgebung
|
|
bereitstellen, so dass jeder Beiträge nach seinen Fähigkeiten leisten
|
|
kann. Zu diesem Zweck verwendet unser Projekt einen »Verhaltenskodex für
|
|
Mitwirkende«, der von @url{http://contributor-covenant.org/} übernommen
|
|
wurde. Eine übersetzte Fassung finden Sie auf
|
|
@url{https://www.contributor-covenant.org/de/version/1/4/code-of-conduct}
|
|
sowie eine mitgelieferte, englische Fassung in der Datei
|
|
@file{CODE-OF-CONDUCT} im Quellbaum.
|
|
|
|
Von Mitwirkenden wird nicht erwartet, dass sie in Patches oder in der
|
|
Online-Kommunikation ihre echten Namen preisgeben. Sie können einen
|
|
beliebigen Namen oder ein Pseudonym ihrer Wahl verwenden.
|
|
|
|
@menu
|
|
* Erstellung aus dem Git:: Das Neueste und Beste.
|
|
* Guix vor der Installation ausführen:: Hacker-Tricks.
|
|
* Perfekt eingerichtet:: Die richtigen Werkzeuge.
|
|
* Paketrichtlinien:: Die Distribution wachsen lassen.
|
|
* Code-Stil:: Wie Mitwirkende hygienisch arbeiten.
|
|
* Einreichen von Patches:: Teilen Sie Ihre Arbeit.
|
|
@end menu
|
|
|
|
@node Erstellung aus dem Git
|
|
@section Erstellung aus dem Git
|
|
|
|
Wenn Sie an Guix selbst hacken wollen, ist es empfehlenswert, dass Sie die
|
|
neueste Version aus dem Git-Softwarebestand verwenden:
|
|
|
|
@example
|
|
git clone https://git.savannah.gnu.org/git/guix.git
|
|
@end example
|
|
|
|
Wenn Sie Guix aus einem Checkout erstellen, sind außer den bereits in den
|
|
Installationsanweisungen genannten Paketen weitere nötig
|
|
(@pxref{Voraussetzungen}).
|
|
|
|
@itemize
|
|
@item @url{http://gnu.org/software/autoconf/, GNU Autoconf};
|
|
@item @url{http://gnu.org/software/automake/, GNU Automake};
|
|
@item @url{http://gnu.org/software/gettext/, GNU Gettext};
|
|
@item @url{http://gnu.org/software/texinfo/, GNU Texinfo};
|
|
@item @url{http://www.graphviz.org/, Graphviz};
|
|
@item @url{http://www.gnu.org/software/help2man/, GNU Help2man (optional)}.
|
|
@end itemize
|
|
|
|
Der einfachste Weg, eine Entwicklungsumgebung für Guix einzurichten, ist
|
|
natürlich, Guix zu benutzen! Der folgende Befehl startet eine neue Shell, in
|
|
der alle Abhängigkeiten und Umgebungsvariablen bereits eingerichtet sind, um
|
|
an Guix zu arbeiten:
|
|
|
|
@example
|
|
guix environment guix
|
|
@end example
|
|
|
|
In @xref{Aufruf von guix environment} finden Sie weitere Informationen zu
|
|
diesem Befehl. Zusätzliche Abhängigkeiten können mit @option{--ad-hoc}
|
|
hinzugefügt werden:
|
|
|
|
@example
|
|
guix environment guix --ad-hoc help2man git strace
|
|
@end example
|
|
|
|
Führen Sie @command{./bootstrap} aus, um die Infrastruktur des
|
|
Erstellungssystems mit Autoconf und Automake zu erstellen. Möglicherweise
|
|
erhalten Sie eine Fehlermeldung wie diese:
|
|
|
|
@example
|
|
configure.ac:46: error: possibly undefined macro: PKG_CHECK_MODULES
|
|
@end example
|
|
|
|
@noindent
|
|
Das bedeutet wahrscheinlich, dass Autoconf @file{pkg.m4} nicht finden
|
|
konnte, welches von pkg-config bereitgestellt wird. Stellen Sie sicher, dass
|
|
@file{pkg.m4} verfügbar ist. Gleiches gilt für den von Guile
|
|
bereitgestellten Makrosatz @file{guile.m4}. Wenn Sie beispielsweise Automake
|
|
in @file{/usr/local} installiert haben, würde in @file{/usr/share} nicht
|
|
nach @file{.m4}-Dateien geschaut. In einem solchen Fall müssen Sie folgenden
|
|
Befehl aufrufen:
|
|
|
|
@example
|
|
export ACLOCAL_PATH=/usr/share/aclocal
|
|
@end example
|
|
|
|
In @xref{Macro Search Path,,, automake, The GNU Automake Manual} finden Sie
|
|
weitere Informationen.
|
|
|
|
Dann führen Sie wie gewohnt @command{./configure} aus. Achten Sie darauf,
|
|
@code{--localstatedir=@var{Verzeichnis}} zu übergeben, wobei
|
|
@var{Verzeichnis} der von Ihrer aktuellen Installation verwendete
|
|
@code{localstatedir}-Wert ist (weitere Informationen auf @pxref{Der Store}).
|
|
|
|
Zum Schluss müssen Sie @code{make check} aufrufen, um die Tests auszuführen
|
|
(@pxref{Die Testsuite laufen lassen}). Falls etwas fehlschlägt, werfen Sie einen
|
|
Blick auf die Installationsanweisungen (@pxref{Installation}) oder senden
|
|
Sie eine E-Mail an die @email{guix-devel@@gnu.org, Mailingliste}.
|
|
|
|
|
|
@node Guix vor der Installation ausführen
|
|
@section Guix vor der Installation ausführen
|
|
|
|
Um eine gesunde Arbeitsumgebung zu erhalten, ist es hilfreich, die im
|
|
lokalen Quellbaum vorgenommenen Änderungen zunächst zu testen, ohne sie
|
|
tatsächlich zu installieren. So können Sie zwischen Ihrem
|
|
Endnutzer-»Straßenanzug« und Ihrem »Faschingskostüm« unterscheiden.
|
|
|
|
Zu diesem Zweck können alle Befehlszeilenwerkzeuge auch schon benutzt
|
|
werden, ohne dass Sie @code{make install} laufen lassen. Dazu müssen Sie
|
|
sich in einer Umgebung befinden, in der alle Abhängigkeiten von Guix
|
|
verfügbar sind (@pxref{Erstellung aus dem Git}) und darin einfach vor jeden
|
|
Befehl @command{./pre-inst-env} schreiben (das Skript @file{pre-inst-env}
|
|
befindet sich auf oberster Ebene im Verzeichnis, wo Guix erstellt wird, wo
|
|
es durch @command{./configure} erzeugt wird), zum Beispiel so@footnote{Die
|
|
Befehlszeilenoption @option{-E} von @command{sudo} stellt sicher, dass
|
|
@code{GUILE_LOAD_PATH} richtig gesetzt wird, damit @command{guix-daemon} und
|
|
die davon benutzten Werkzeuge die von ihnen benötigten Guile-Module finden
|
|
können.}:
|
|
|
|
@example
|
|
$ sudo -E ./pre-inst-env guix-daemon --build-users-group=guixbuild
|
|
$ ./pre-inst-env guix build hello
|
|
@end example
|
|
|
|
@noindent
|
|
Entsprechend, um eine Guile-Sitzung zu öffnen, die die Guix-Module benutzt:
|
|
|
|
@example
|
|
$ ./pre-inst-env guile -c '(use-modules (guix utils)) (pk (%current-system))'
|
|
|
|
;;; ("x86_64-linux")
|
|
@end example
|
|
|
|
@noindent
|
|
@cindex REPL
|
|
@cindex Lese-Auswerten-Schreiben-Schleife
|
|
@dots{} und auf einer REPL (@pxref{Using Guile Interactively,,, guile, Guile
|
|
Reference Manual}):
|
|
|
|
@example
|
|
$ ./pre-inst-env guile
|
|
scheme@@(guile-user)> ,use(guix)
|
|
scheme@@(guile-user)> ,use(gnu)
|
|
scheme@@(guile-user)> (define snakes
|
|
(fold-packages
|
|
(lambda (package lst)
|
|
(if (string-prefix? "python"
|
|
(package-name package))
|
|
(cons package lst)
|
|
lst))
|
|
'()))
|
|
scheme@@(guile-user)> (length snakes)
|
|
$1 = 361
|
|
@end example
|
|
|
|
Das @command{pre-inst-env}-Skript richtet alle Umgebungsvariablen ein, die
|
|
nötig sind, um dies zu ermöglichen, einschließlich @env{PATH} und
|
|
@env{GUILE_LOAD_PATH}.
|
|
|
|
Beachten Sie, dass @command{./pre-inst-env guix pull} den lokalen Quellbaum
|
|
@emph{nicht} aktualisiert; es aktualisiert lediglich die symbolische
|
|
Verknüpfung @file{~/.config/guix/current} (@pxref{Aufruf von guix pull}). Um
|
|
Ihren lokalen Quellbaum zu aktualisieren, müssen Sie stattdessen
|
|
@command{git pull} benutzen.
|
|
|
|
|
|
@node Perfekt eingerichtet
|
|
@section Perfekt eingerichtet
|
|
|
|
The Perfect Setup to hack on Guix is basically the perfect setup used for
|
|
Guile hacking (@pxref{Using Guile in Emacs,,, guile, Guile Reference
|
|
Manual}). First, you need more than an editor, you need
|
|
@url{http://www.gnu.org/software/emacs, Emacs}, empowered by the wonderful
|
|
@url{http://nongnu.org/geiser/, Geiser}. To set that up, run:
|
|
|
|
@example
|
|
guix package -i emacs guile emacs-geiser
|
|
@end example
|
|
|
|
Geiser ermöglicht interaktive und inkrementelle Entwicklung aus Emacs
|
|
heraus: Code kann in Puffern kompiliert und ausgewertet werden. Zugang zu
|
|
Online-Dokumentation (Docstrings) steht ebenso zur Verfügung wie
|
|
kontextabhängige Vervollständigung, @kbd{M-.} um zu einer Objektdefinition
|
|
zu springen, eine REPL, um Ihren Code auszuprobieren, und mehr
|
|
(@pxref{Einführung,,, geiser, Geiser User Manual}). Zur bequemen
|
|
Guix-Entwicklung sollten Sie Guiles Ladepfad so ergänzen, dass die
|
|
Quelldateien in Ihrem Checkout gefunden werden.
|
|
|
|
@lisp
|
|
;; @r{Angenommen das Guix-Checkout ist in ~/src/guix.}
|
|
(with-eval-after-load 'geiser-guile
|
|
(add-to-list 'geiser-guile-load-path "~/src/guix"))
|
|
@end lisp
|
|
|
|
Um den Code tatsächlich zu bearbeiten, bietet Emacs schon einen netten
|
|
Scheme-Modus. Aber Sie dürfen auch
|
|
@url{http://www.emacswiki.org/emacs/ParEdit, Paredit} nicht verpassen. Es
|
|
bietet Hilfsmittel, um direkt mit dem Syntaxbaum zu arbeiten, und kann so
|
|
zum Beispiel einen S-Ausdruck hochheben oder ihn umhüllen, ihn verschlucken
|
|
oder den nachfolgenden S-Ausdruck verwerfen, etc.
|
|
|
|
@cindex Code-Schnipsel
|
|
@cindex Vorlagen
|
|
@cindex Tipparbeit sparen
|
|
Wir bieten auch Vorlagen für häufige Git-Commit-Nachrichten und
|
|
Paketdefinitionen im Verzeichnis @file{etc/snippets}. Diese Vorlagen können
|
|
mit @url{http://joaotavora.github.io/yasnippet/, YASnippet} zusammen benutzt
|
|
werden, um kurze Auslöse-Zeichenketten zu interaktiven Textschnipseln
|
|
umzuschreiben. Vielleicht möchten Sie das Schnipselverzeichnis zu Ihrer
|
|
@var{yas-snippet-dirs}-Variablen in Emacs hinzufügen.
|
|
|
|
@lisp
|
|
;; @r{Angenommen das Guix-Checkout ist in ~/src/guix.}
|
|
(with-eval-after-load 'yasnippet
|
|
(add-to-list 'yas-snippet-dirs "~/src/guix/etc/snippets"))
|
|
@end lisp
|
|
|
|
Die Schnipsel für Commit-Nachrichten setzen @url{https://magit.vc/, Magit}
|
|
voraus, um zum Commit vorgemerkte Dateien anzuzeigen. Wenn Sie eine
|
|
Commit-Nachricht bearbeiten, können Sie @code{add} gefolgt von @kbd{TAB}
|
|
eintippen, um eine Commit-Nachrichten-Vorlage für das Hinzufügen eines
|
|
Pakets zu erhalten; tippen Sie @code{update} gefolgt von @kbd{TAB} ein, um
|
|
eine Vorlage zum Aktualisieren eines Pakets zu bekommen; tippen Sie
|
|
@code{https} gefolgt von @kbd{TAB} ein, um eine Vorlage zum Ändern der
|
|
Homepage-URI eines Pakets auf HTTPS einzufügen.
|
|
|
|
Das Hauptschnipsel für @code{scheme-mode} wird ausgelöst, indem Sie
|
|
@code{package...} gefolgt von @kbd{TAB} eintippen. Dieses Snippet fügt auch
|
|
die Auslöse-Zeichenkette @code{origin...} ein, die danach weiter
|
|
umgeschrieben werden kann. Das @code{origin}-Schnipsel kann wiederum andere
|
|
Auslöse-Zeichenketten einfügen, die alle auf @code{...} enden, was selbst
|
|
wieder weiter umgeschrieben werden kann.
|
|
|
|
|
|
@node Paketrichtlinien
|
|
@section Paketrichtlinien
|
|
|
|
@cindex packages, creating
|
|
The GNU distribution is nascent and may well lack some of your favorite
|
|
packages. This section describes how you can help make the distribution
|
|
grow.
|
|
|
|
Free software packages are usually distributed in the form of @dfn{source
|
|
code tarballs}---typically @file{tar.gz} files that contain all the source
|
|
files. Adding a package to the distribution means essentially two things:
|
|
adding a @dfn{recipe} that describes how to build the package, including a
|
|
list of other packages required to build it, and adding @dfn{package
|
|
metadata} along with that recipe, such as a description and licensing
|
|
information.
|
|
|
|
In Guix all this information is embodied in @dfn{package definitions}.
|
|
Package definitions provide a high-level view of the package. They are
|
|
written using the syntax of the Scheme programming language; in fact, for
|
|
each package we define a variable bound to the package definition, and
|
|
export that variable from a module (@pxref{Paketmodule}). However,
|
|
in-depth Scheme knowledge is @emph{not} a prerequisite for creating
|
|
packages. For more information on package definitions, @pxref{Pakete definieren}.
|
|
|
|
Once a package definition is in place, stored in a file in the Guix source
|
|
tree, it can be tested using the @command{guix build} command
|
|
(@pxref{Aufruf von guix build}). For example, assuming the new package is
|
|
called @code{gnew}, you may run this command from the Guix build tree
|
|
(@pxref{Guix vor der Installation ausführen}):
|
|
|
|
@example
|
|
./pre-inst-env guix build gnew --keep-failed
|
|
@end example
|
|
|
|
Using @code{--keep-failed} makes it easier to debug build failures since it
|
|
provides access to the failed build tree. Another useful command-line
|
|
option when debugging is @code{--log-file}, to access the build log.
|
|
|
|
If the package is unknown to the @command{guix} command, it may be that the
|
|
source file contains a syntax error, or lacks a @code{define-public} clause
|
|
to export the package variable. To figure it out, you may load the module
|
|
from Guile to get more information about the actual error:
|
|
|
|
@example
|
|
./pre-inst-env guile -c '(use-modules (gnu packages gnew))'
|
|
@end example
|
|
|
|
Once your package builds correctly, please send us a patch
|
|
(@pxref{Einreichen von Patches}). Well, if you need help, we will be happy to
|
|
help you too. Once the patch is committed in the Guix repository, the new
|
|
package automatically gets built on the supported platforms by
|
|
@url{http://hydra.gnu.org/jobset/gnu/master, our continuous integration
|
|
system}.
|
|
|
|
@cindex substituter
|
|
Users can obtain the new package definition simply by running @command{guix
|
|
pull} (@pxref{Aufruf von guix pull}). When @code{@value{SUBSTITUTE-SERVER}}
|
|
is done building the package, installing the package automatically downloads
|
|
binaries from there (@pxref{Substitute}). The only place where human
|
|
intervention is needed is to review and apply the patch.
|
|
|
|
|
|
@menu
|
|
* Software-Freiheit:: Was in die Distribution aufgenommen werden
|
|
darf.
|
|
* Paketbenennung:: Was macht einen Namen aus?
|
|
* Versionsnummern:: Wenn der Name noch nicht genug ist.
|
|
* Zusammenfassungen und Beschreibungen:: Den Nutzern helfen, das richtige
|
|
Paket zu finden.
|
|
* Python-Module:: Ein Touch britischer Comedy.
|
|
* Perl-Module:: Kleine Perlen.
|
|
* Java-Pakete:: Kaffeepause.
|
|
* Schriftarten:: Schriften verschriftlicht.
|
|
@end menu
|
|
|
|
@node Software-Freiheit
|
|
@subsection Software-Freiheit
|
|
|
|
@c ===========================================================================
|
|
@c
|
|
@c This file was generated with po4a. Translate the source file.
|
|
@c
|
|
@c ===========================================================================
|
|
@c Adapted from http://www.gnu.org/philosophy/philosophy.html.
|
|
@cindex free software
|
|
The GNU operating system has been developed so that users can have freedom
|
|
in their computing. GNU is @dfn{free software}, meaning that users have the
|
|
@url{http://www.gnu.org/philosophy/free-sw.html,four essential freedoms}: to
|
|
run the program, to study and change the program in source code form, to
|
|
redistribute exact copies, and to distribute modified versions. Packages
|
|
found in the GNU distribution provide only software that conveys these four
|
|
freedoms.
|
|
|
|
In addition, the GNU distribution follow the
|
|
@url{http://www.gnu.org/distros/free-system-distribution-guidelines.html,free
|
|
software distribution guidelines}. Among other things, these guidelines
|
|
reject non-free firmware, recommendations of non-free software, and discuss
|
|
ways to deal with trademarks and patents.
|
|
|
|
Some otherwise free upstream package sources contain a small and optional
|
|
subset that violates the above guidelines, for instance because this subset
|
|
is itself non-free code. When that happens, the offending items are removed
|
|
with appropriate patches or code snippets in the @code{origin} form of the
|
|
package (@pxref{Pakete definieren}). This way, @code{guix build --source}
|
|
returns the ``freed'' source rather than the unmodified upstream source.
|
|
|
|
|
|
@node Paketbenennung
|
|
@subsection Paketbenennung
|
|
|
|
@cindex package name
|
|
A package has actually two names associated with it: First, there is the
|
|
name of the @emph{Scheme variable}, the one following @code{define-public}.
|
|
By this name, the package can be made known in the Scheme code, for instance
|
|
as input to another package. Second, there is the string in the @code{name}
|
|
field of a package definition. This name is used by package management
|
|
commands such as @command{guix package} and @command{guix build}.
|
|
|
|
Both are usually the same and correspond to the lowercase conversion of the
|
|
project name chosen upstream, with underscores replaced with hyphens. For
|
|
instance, GNUnet is available as @code{gnunet}, and SDL_net as
|
|
@code{sdl-net}.
|
|
|
|
We do not add @code{lib} prefixes for library packages, unless these are
|
|
already part of the official project name. But @pxref{Python-Module} and
|
|
@ref{Perl-Module} for special rules concerning modules for the Python and
|
|
Perl languages.
|
|
|
|
Font package names are handled differently, @pxref{Schriftarten}.
|
|
|
|
|
|
@node Versionsnummern
|
|
@subsection Versionsnummern
|
|
|
|
@cindex package version
|
|
We usually package only the latest version of a given free software
|
|
project. But sometimes, for instance for incompatible library versions, two
|
|
(or more) versions of the same package are needed. These require different
|
|
Scheme variable names. We use the name as defined in @ref{Paketbenennung}
|
|
for the most recent version; previous versions use the same name, suffixed
|
|
by @code{-} and the smallest prefix of the version number that may
|
|
distinguish the two versions.
|
|
|
|
The name inside the package definition is the same for all versions of a
|
|
package and does not contain any version number.
|
|
|
|
Zum Beispiel können für GTK in den Versionen 2.24.20 und 3.9.12 Pakete wie
|
|
folgt geschrieben werden:
|
|
|
|
@example
|
|
(define-public gtk+
|
|
(package
|
|
(name "gtk+")
|
|
(version "3.9.12")
|
|
...))
|
|
(define-public gtk+-2
|
|
(package
|
|
(name "gtk+")
|
|
(version "2.24.20")
|
|
...))
|
|
@end example
|
|
Wenn wir auch GTK 3.8.2 wollten, würden wir das Paket schreiben als
|
|
@example
|
|
(define-public gtk+-3.8
|
|
(package
|
|
(name "gtk+")
|
|
(version "3.8.2")
|
|
...))
|
|
@end example
|
|
|
|
@c See <https://lists.gnu.org/archive/html/guix-devel/2016-01/msg00425.html>,
|
|
@c for a discussion of what follows.
|
|
@cindex version number, for VCS snapshots
|
|
Occasionally, we package snapshots of upstream's version control system
|
|
(VCS) instead of formal releases. This should remain exceptional, because
|
|
it is up to upstream developers to clarify what the stable release is. Yet,
|
|
it is sometimes necessary. So, what should we put in the @code{version}
|
|
field?
|
|
|
|
Clearly, we need to make the commit identifier of the VCS snapshot visible
|
|
in the version string, but we also need to make sure that the version string
|
|
is monotonically increasing so that @command{guix package --upgrade} can
|
|
determine which version is newer. Since commit identifiers, notably with
|
|
Git, are not monotonically increasing, we add a revision number that we
|
|
increase each time we upgrade to a newer snapshot. The resulting version
|
|
string looks like this:
|
|
|
|
@example
|
|
2.0.11-3.cabba9e
|
|
^ ^ ^
|
|
| | `-- upstream commit ID
|
|
| |
|
|
| `--- Guix package revision
|
|
|
|
|
latest upstream version
|
|
@end example
|
|
|
|
It is a good idea to strip commit identifiers in the @code{version} field
|
|
to, say, 7 digits. It avoids an aesthetic annoyance (assuming aesthetics
|
|
have a role to play here) as well as problems related to OS limits such as
|
|
the maximum shebang length (127 bytes for the Linux kernel.) It is best to
|
|
use the full commit identifiers in @code{origin}s, though, to avoid
|
|
ambiguities. A typical package definition may look like this:
|
|
|
|
@example
|
|
(define my-package
|
|
(let ((commit "c3f29bc928d5900971f65965feaae59e1272a3f7")
|
|
(revision "1")) ;Guix package revision
|
|
(package
|
|
(version (git-version "0.9" revision commit))
|
|
(source (origin
|
|
(method git-fetch)
|
|
(uri (git-reference
|
|
(url "git://example.org/my-package.git")
|
|
(commit commit)))
|
|
(sha256 (base32 "1mbikn@dots{}"))
|
|
(file-name (git-file-name name version))))
|
|
;; @dots{}
|
|
)))
|
|
@end example
|
|
|
|
@node Zusammenfassungen und Beschreibungen
|
|
@subsection Zusammenfassungen und Beschreibungen
|
|
|
|
@cindex package description
|
|
@cindex package synopsis
|
|
As we have seen before, each package in GNU@tie{}Guix includes a synopsis
|
|
and a description (@pxref{Pakete definieren}). Synopses and descriptions
|
|
are important: They are what @command{guix package --search} searches, and a
|
|
crucial piece of information to help users determine whether a given package
|
|
suits their needs. Consequently, packagers should pay attention to what
|
|
goes into them.
|
|
|
|
Synopses must start with a capital letter and must not end with a period.
|
|
They must not start with ``a'' or ``the'', which usually does not bring
|
|
anything; for instance, prefer ``File-frobbing tool'' over ``A tool that
|
|
frobs files''. The synopsis should say what the package is---e.g., ``Core
|
|
GNU utilities (file, text, shell)''---or what it is used for---e.g., the
|
|
synopsis for GNU@tie{}grep is ``Print lines matching a pattern''.
|
|
|
|
Keep in mind that the synopsis must be meaningful for a very wide audience.
|
|
For example, ``Manipulate alignments in the SAM format'' might make sense
|
|
for a seasoned bioinformatics researcher, but might be fairly unhelpful or
|
|
even misleading to a non-specialized audience. It is a good idea to come up
|
|
with a synopsis that gives an idea of the application domain of the
|
|
package. In this example, this might give something like ``Manipulate
|
|
nucleotide sequence alignments'', which hopefully gives the user a better
|
|
idea of whether this is what they are looking for.
|
|
|
|
Descriptions should take between five and ten lines. Use full sentences,
|
|
and avoid using acronyms without first introducing them. Please avoid
|
|
marketing phrases such as ``world-leading'', ``industrial-strength'', and
|
|
``next-generation'', and avoid superlatives like ``the most
|
|
advanced''---they are not helpful to users looking for a package and may
|
|
even sound suspicious. Instead, try to be factual, mentioning use cases and
|
|
features.
|
|
|
|
@cindex Texinfo markup, in package descriptions
|
|
Descriptions can include Texinfo markup, which is useful to introduce
|
|
ornaments such as @code{@@code} or @code{@@dfn}, bullet lists, or hyperlinks
|
|
(@pxref{Overview,,, texinfo, GNU Texinfo}). However you should be careful
|
|
when using some characters for example @samp{@@} and curly braces which are
|
|
the basic special characters in Texinfo (@pxref{Special Characters,,,
|
|
texinfo, GNU Texinfo}). User interfaces such as @command{guix package
|
|
--show} take care of rendering it appropriately.
|
|
|
|
Synopses and descriptions are translated by volunteers
|
|
@uref{http://translationproject.org/domain/guix-packages.html, at the
|
|
Translation Project} so that as many users as possible can read them in
|
|
their native language. User interfaces search them and display them in the
|
|
language specified by the current locale.
|
|
|
|
To allow @command{xgettext} to extract them as translatable strings,
|
|
synopses and descriptions @emph{must be literal strings}. This means that
|
|
you cannot use @code{string-append} or @code{format} to construct these
|
|
strings:
|
|
|
|
@lisp
|
|
(package
|
|
;; @dots{}
|
|
(synopsis "This is translatable")
|
|
(description (string-append "This is " "*not*" " translatable.")))
|
|
@end lisp
|
|
|
|
Translation is a lot of work so, as a packager, please pay even more
|
|
attention to your synopses and descriptions as every change may entail
|
|
additional work for translators. In order to help them, it is possible to
|
|
make recommendations or instructions visible to them by inserting special
|
|
comments like this (@pxref{xgettext Invocation,,, gettext, GNU Gettext}):
|
|
|
|
@example
|
|
;; TRANSLATORS: "X11 resize-and-rotate" should not be translated.
|
|
(description "ARandR is designed to provide a simple visual front end
|
|
for the X11 resize-and-rotate (RandR) extension. @dots{}")
|
|
@end example
|
|
|
|
|
|
@node Python-Module
|
|
@subsection Python-Module
|
|
|
|
@cindex python
|
|
We currently package Python 2 and Python 3, under the Scheme variable names
|
|
@code{python-2} and @code{python} as explained in @ref{Versionsnummern}. To
|
|
avoid confusion and naming clashes with other programming languages, it
|
|
seems desirable that the name of a package for a Python module contains the
|
|
word @code{python}.
|
|
|
|
Some modules are compatible with only one version of Python, others with
|
|
both. If the package Foo compiles only with Python 3, we name it
|
|
@code{python-foo}; if it compiles only with Python 2, we name it
|
|
@code{python2-foo}. If it is compatible with both versions, we create two
|
|
packages with the corresponding names.
|
|
|
|
If a project already contains the word @code{python}, we drop this; for
|
|
instance, the module python-dateutil is packaged under the names
|
|
@code{python-dateutil} and @code{python2-dateutil}. If the project name
|
|
starts with @code{py} (e.g.@: @code{pytz}), we keep it and prefix it as
|
|
described above.
|
|
|
|
@subsubsection Specifying Dependencies
|
|
@cindex inputs, for Python packages
|
|
|
|
Dependency information for Python packages is usually available in the
|
|
package source tree, with varying degrees of accuracy: in the
|
|
@file{setup.py} file, in @file{requirements.txt}, or in @file{tox.ini}.
|
|
|
|
Your mission, when writing a recipe for a Python package, is to map these
|
|
dependencies to the appropriate type of ``input'' (@pxref{»package«-Referenz,
|
|
inputs}). Although the @code{pypi} importer normally does a good job
|
|
(@pxref{Aufruf von guix import}), you may want to check the following check
|
|
list to determine which dependency goes where.
|
|
|
|
@itemize
|
|
|
|
@item
|
|
We currently package Python 2 with @code{setuptools} and @code{pip}
|
|
installed like Python 3.4 has per default. Thus you don't need to specify
|
|
either of these as an input. @command{guix lint} will warn you if you do.
|
|
|
|
@item
|
|
Python dependencies required at run time go into @code{propagated-inputs}.
|
|
They are typically defined with the @code{install_requires} keyword in
|
|
@file{setup.py}, or in the @file{requirements.txt} file.
|
|
|
|
@item
|
|
Python packages required only at build time---e.g., those listed with the
|
|
@code{setup_requires} keyword in @file{setup.py}---or only for
|
|
testing---e.g., those in @code{tests_require}---go into
|
|
@code{native-inputs}. The rationale is that (1) they do not need to be
|
|
propagated because they are not needed at run time, and (2) in a
|
|
cross-compilation context, it's the ``native'' input that we'd want.
|
|
|
|
Examples are the @code{pytest}, @code{mock}, and @code{nose} test
|
|
frameworks. Of course if any of these packages is also required at
|
|
run-time, it needs to go to @code{propagated-inputs}.
|
|
|
|
@item
|
|
Anything that does not fall in the previous categories goes to
|
|
@code{inputs}, for example programs or C libraries required for building
|
|
Python packages containing C extensions.
|
|
|
|
@item
|
|
If a Python package has optional dependencies (@code{extras_require}), it is
|
|
up to you to decide whether to add them or not, based on their
|
|
usefulness/overhead ratio (@pxref{Einreichen von Patches, @command{guix size}}).
|
|
|
|
@end itemize
|
|
|
|
|
|
@node Perl-Module
|
|
@subsection Perl-Module
|
|
|
|
@cindex perl
|
|
Perl programs standing for themselves are named as any other package, using
|
|
the lowercase upstream name. For Perl packages containing a single class,
|
|
we use the lowercase class name, replace all occurrences of @code{::} by
|
|
dashes and prepend the prefix @code{perl-}. So the class @code{XML::Parser}
|
|
becomes @code{perl-xml-parser}. Modules containing several classes keep
|
|
their lowercase upstream name and are also prepended by @code{perl-}. Such
|
|
modules tend to have the word @code{perl} somewhere in their name, which
|
|
gets dropped in favor of the prefix. For instance, @code{libwww-perl}
|
|
becomes @code{perl-libwww}.
|
|
|
|
|
|
@node Java-Pakete
|
|
@subsection Java-Pakete
|
|
|
|
@cindex java
|
|
Java programs standing for themselves are named as any other package, using
|
|
the lowercase upstream name.
|
|
|
|
To avoid confusion and naming clashes with other programming languages, it
|
|
is desirable that the name of a package for a Java package is prefixed with
|
|
@code{java-}. If a project already contains the word @code{java}, we drop
|
|
this; for instance, the package @code{ngsjava} is packaged under the name
|
|
@code{java-ngs}.
|
|
|
|
For Java packages containing a single class or a small class hierarchy, we
|
|
use the lowercase class name, replace all occurrences of @code{.} by dashes
|
|
and prepend the prefix @code{java-}. So the class @code{apache.commons.cli}
|
|
becomes package @code{java-apache-commons-cli}.
|
|
|
|
|
|
@node Schriftarten
|
|
@subsection Schriftarten
|
|
|
|
@cindex Schriftarten
|
|
For fonts that are in general not installed by a user for typesetting
|
|
purposes, or that are distributed as part of a larger software package, we
|
|
rely on the general packaging rules for software; for instance, this applies
|
|
to the fonts delivered as part of the X.Org system or fonts that are part of
|
|
TeX Live.
|
|
|
|
To make it easier for a user to search for fonts, names for other packages
|
|
containing only fonts are constructed as follows, independently of the
|
|
upstream package name.
|
|
|
|
The name of a package containing only one font family starts with
|
|
@code{font-}; it is followed by the foundry name and a dash @code{-} if the
|
|
foundry is known, and the font family name, in which spaces are replaced by
|
|
dashes (and as usual, all upper case letters are transformed to lower
|
|
case). For example, the Gentium font family by SIL is packaged under the
|
|
name @code{font-sil-gentium}.
|
|
|
|
For a package containing several font families, the name of the collection
|
|
is used in the place of the font family name. For instance, the Liberation
|
|
fonts consist of three families, Liberation Sans, Liberation Serif and
|
|
Liberation Mono. These could be packaged separately under the names
|
|
@code{font-liberation-sans} and so on; but as they are distributed together
|
|
under a common name, we prefer to package them together as
|
|
@code{font-liberation}.
|
|
|
|
In the case where several formats of the same font family or font collection
|
|
are packaged separately, a short form of the format, prepended by a dash, is
|
|
added to the package name. We use @code{-ttf} for TrueType fonts,
|
|
@code{-otf} for OpenType fonts and @code{-type1} for PostScript Type 1
|
|
fonts.
|
|
|
|
|
|
@node Code-Stil
|
|
@section Code-Stil
|
|
|
|
Im Allgemeinen folgt unser Code den GNU Coding Standards (@pxref{Top,,,
|
|
standards, GNU Coding Standards}). Da diese aber nicht viel über Scheme zu
|
|
sagen haben, folgen hier einige zusätzliche Regeln.
|
|
|
|
@menu
|
|
* Programmierparadigmen:: Wie Sie Ihre Elemente zusammenstellen.
|
|
* Module:: Wo Sie Ihren Code unterbringen.
|
|
* Datentypen und Mustervergleich:: Implementierung von Datenstrukturen.
|
|
* Formatierung von Code:: Schreibkonventionen.
|
|
@end menu
|
|
|
|
@node Programmierparadigmen
|
|
@subsection Programmierparadigmen
|
|
|
|
Scheme-Code wird in Guix auf rein funktionale Weise geschrieben. Eine
|
|
Ausnahme ist Code, der mit Ein- und Ausgabe zu tun hat, und Prozeduren, die
|
|
grundlegende Konzepte implementieren, wie zum Beispiel die Prozedur
|
|
@code{memoize}.
|
|
|
|
@node Module
|
|
@subsection Module
|
|
|
|
Guile-Module, die beim Erstellen nutzbar sein sollen, müssen im Namensraum
|
|
@code{(guix build @dots{})} leben. Sie dürfen auf keine anderen Guix- oder
|
|
GNU-Module Bezug nehmen. Jedoch ist es in Ordnung, wenn ein »wirtsseitiges«
|
|
Modul ein erstellungsseitiges Modul benutzt.
|
|
|
|
Module, die mit dem weiteren GNU-System zu tun haben, sollten im Namensraum
|
|
@code{(gnu @dots{})} und nicht in @code{(guix @dots{})} stehen.
|
|
|
|
@node Datentypen und Mustervergleich
|
|
@subsection Datentypen und Mustervergleich
|
|
|
|
Im klassischen Lisp gibt es die Tendenz, Listen zur Darstellung von allem zu
|
|
benutzen, und diese dann »händisch« zu durchlaufen mit @code{car},
|
|
@code{cdr}, @code{cadr} und so weiter. Dieser Stil ist aus verschiedenen
|
|
Gründen problematisch, insbesondere wegen der Tatsache, dass er schwer zu
|
|
lesen, schnell fehlerbehaftet und ein Hindernis beim Melden von Typfehlern
|
|
ist.
|
|
|
|
Guix-Code sollte angemessene Datentypen definieren (zum Beispiel mit
|
|
@code{define-record-type*}) statt Listen zu missbrauchen. Außerdem sollte er
|
|
das @code{(ice-9 match)}-Modul von Guile zum Mustervergleich benutzen,
|
|
besonders mit Listen.
|
|
|
|
@node Formatierung von Code
|
|
@subsection Formatierung von Code
|
|
|
|
@cindex Formatierung von Code
|
|
@cindex Code-Stil
|
|
Beim Schreiben von Scheme-Code halten wir uns an die üblichen
|
|
Gepflogenheiten unter Scheme-Programmierern. Im Allgemeinen bedeutet das,
|
|
dass wir uns an @url{http://mumble.net/~campbell/scheme/style.txt,
|
|
Riastradh's Lisp Style Rules} halten. Es hat sich ergeben, dass dieses
|
|
Dokument auch die Konventionen beschreibt, die im Code von Guile
|
|
hauptsächlich verwendet werden. Es ist gut durchdacht und schön geschrieben,
|
|
also lesen Sie es bitte.
|
|
|
|
Ein paar in Guix eingeführte Sonderformen, wie zum Beispiel das
|
|
@code{substitute*}-Makro, haben abweichende Regeln für die Einrückung. Diese
|
|
sind in der Datei @file{.dir-locals.el} definiert, die Emacs automatisch
|
|
benutzt. Beachten Sie auch, dass Emacs-Guix einen Modus namens
|
|
@code{guix-devel-mode} bereitstellt, der Guix-Code richtig einrückt und
|
|
hervorhebt (@pxref{Development,,, emacs-guix, The Emacs-Guix Reference
|
|
Manual}).
|
|
|
|
@cindex Einrückung, Code-
|
|
@cindex Formatierung, Code-
|
|
Falls Sie nicht Emacs verwenden, sollten Sie sicherstellen, dass Ihr Editor
|
|
diese Regeln kennt. Um eine Paketdefinition automatisch einzurücken, können
|
|
Sie auch Folgendes ausführen:
|
|
|
|
@example
|
|
./etc/indent-code.el gnu/packages/@var{Datei}.scm @var{Paket}
|
|
@end example
|
|
|
|
@noindent
|
|
Dadurch wird die Definition von @var{Paket} in
|
|
@file{gnu/packages/@var{Datei}.scm} automatisch eingerückt, indem Emacs im
|
|
Batch-Modus läuft. Um die Einrückung in einer gesamten Datei vorzunehmen,
|
|
lassen Sie das zweite Argument weg:
|
|
|
|
@example
|
|
./etc/indent-code.el gnu/services/@var{Datei}.scm
|
|
@end example
|
|
|
|
@cindex Vim, zum Editieren von Scheme-Code
|
|
Wenn Sie Code mit Vim bearbeiten, empfehlen wir, dass Sie @code{:set
|
|
autoindent} ausführen, damit Ihr Code automatisch eingerückt wird, während
|
|
Sie ihn schreiben. Außerdem könnte Ihnen
|
|
@uref{https://www.vim.org/scripts/script.php?script_id=3998,
|
|
@code{paredit.vim}} dabei helfen, mit all diesen Klammern fertigzuwerden.
|
|
|
|
Wir fordern von allen Prozeduren auf oberster Ebene, dass sie über einen
|
|
Docstring verfügen. Diese Voraussetzung kann jedoch bei einfachen, privaten
|
|
Prozeduren im Namensraum @code{(guix build @dots{})} aufgeweicht werden.
|
|
|
|
Prozeduren sollten nicht mehr als vier positionsbestimmte Parameter
|
|
haben. Benutzen Sie Schlüsselwort-Parameter für Prozeduren, die mehr als
|
|
vier Parameter entgegennehmen.
|
|
|
|
|
|
@node Einreichen von Patches
|
|
@section Einreichen von Patches
|
|
|
|
Die Entwicklung wird mit Hilfe des verteilten Versionskontrollsystems Git
|
|
durchgeführt. Daher ist eine ständige Verbindung zum Repository nicht
|
|
unbedingt erforderlich. Wir begrüßen Beiträge in Form von Patches, die
|
|
mittels @code{git format-patch} erstellt und an die Mailingliste
|
|
@email{guix-patches@@gnu.org} geschickt werden.
|
|
|
|
Diese Mailing-Liste setzt auf einer Debbugs-Instanz auf, die zugänglich ist
|
|
unter @uref{https://bugs.gnu.org/guix-patches}, wodurch wir den Überblick
|
|
über Eingereichtes behalten können. Jede an diese Mailing-Liste gesendete
|
|
Nachricht bekommt eine neue Folgenummer zugewiesen, so dass man eine
|
|
Folge-Email zur Einreichung an @code{@var{NNN}@@debbugs.gnu.org} senden
|
|
kann, wobei @var{NNN} für die Folgenummer steht (@pxref{Senden einer Patch-Reihe}).
|
|
|
|
Bitte schreiben Sie Commit-Logs im ChangeLog-Format (@pxref{Change Logs,,,
|
|
standards, GNU Coding Standards}); dazu finden Sie Beispiele unter den
|
|
bisherigen Commits.
|
|
|
|
Bevor Sie einen Patch einreichen, der eine Paketdefinition hinzufügt oder
|
|
verändert, gehen Sie bitte diese Prüfliste durch:
|
|
|
|
@enumerate
|
|
@item
|
|
Wenn die Autoren der verpackten Software eine kryptographische Signatur für
|
|
den Tarball der Veröffentlichung anbieten, so machen Sie sich bitte die
|
|
Mühe, die Echtheit des Archivs zu überprüfen. Für eine abgetrennte
|
|
GPG-Signaturdatei würden Sie das mit dem Befehl @code{gpg --verify} tun.
|
|
|
|
@item
|
|
Nehmen Sie sich die Zeit, eine passende Zusammenfassung und Beschreibung für
|
|
das Paket zu verfassen. Unter @xref{Zusammenfassungen und Beschreibungen} finden Sie
|
|
dazu einige Richtlinien.
|
|
|
|
@item
|
|
Verwenden Sie @code{guix lint @var{Paket}}, wobei @var{Paket} das neue oder
|
|
geänderte Paket bezeichnet, und beheben Sie alle gemeldeten Fehler
|
|
(@pxref{Aufruf von guix lint}).
|
|
|
|
@item
|
|
Stellen Sie sicher, dass das Paket auf Ihrer Plattform erstellt werden kann,
|
|
indem Sie @code{guix build @var{Paket}} ausführen.
|
|
|
|
@item
|
|
We recommend you also try building the package on other supported
|
|
platforms. As you may not have access to actual hardware platforms, we
|
|
recommend using the @code{qemu-binfmt-service-type} to emulate them. In
|
|
order to enable it, add the following service to the list of services in
|
|
your @code{operating-system} configuration:
|
|
|
|
@example
|
|
(service qemu-binfmt-service-type
|
|
(qemu-binfmt-configuration
|
|
(platforms (lookup-qemu-platforms "arm" "aarch64" "ppc" "mips64el"))
|
|
(guix-support? #t)))
|
|
@end example
|
|
|
|
Then reconfigure your system.
|
|
|
|
You can then build packages for different platforms by specifying the
|
|
@code{--system} option. For example, to build the "hello" package for the
|
|
armhf, aarch64, powerpc, or mips64 architectures, you would run the
|
|
following commands, respectively:
|
|
@example
|
|
guix build --system=armhf-linux --rounds=2 hello
|
|
guix build --system=aarch64-linux --rounds=2 hello
|
|
guix build --system=powerpc-linux --rounds=2 hello
|
|
guix build --system=mips64el-linux --rounds=2 hello
|
|
@end example
|
|
|
|
@item
|
|
@cindex gebündelt
|
|
Achten Sie darauf, dass im Paket keine Software gebündelt mitgeliefert wird,
|
|
die bereits in separaten Paketen zur Verfügung steht.
|
|
|
|
Manchmal enthalten Pakete Kopien des Quellcodes ihrer Abhängigkeiten, um
|
|
Nutzern die Installation zu erleichtern. Als eine Distribution wollen wir
|
|
jedoch sicherstellen, dass solche Pakete die schon in der Distribution
|
|
verfügbare Fassung benutzen, sofern es eine gibt. Dadurch wird sowohl der
|
|
Ressourcenverbrauch optimiert (die Abhängigkeit wird so nur einmal erstellt
|
|
und gespeichert) als auch der Distribution die Möglichkeit gegeben,
|
|
ergänzende Änderungen durchzuführen, um beispielsweise
|
|
Sicherheitsaktualisierungen für ein bestimmtes Paket an nur einem Ort
|
|
einzuspielen, die aber das gesamte System betreffen — gebündelt
|
|
mitgelieferte Kopien würden dies verhindern.
|
|
|
|
@item
|
|
Take a look at the profile reported by @command{guix size} (@pxref{Aufruf von guix size}). This will allow you to notice references to other packages
|
|
unwillingly retained. It may also help determine whether to split the
|
|
package (@pxref{Pakete mit mehreren Ausgaben.}), and which optional
|
|
dependencies should be used. In particular, avoid adding @code{texlive} as
|
|
a dependency: because of its extreme size, use @code{texlive-tiny} or
|
|
@code{texlive-union} instead.
|
|
|
|
@item
|
|
Achten Sie bei wichtigen Änderungen darauf, dass abhängige Pakete (falls
|
|
vorhanden) nicht von der Änderung beeinträchtigt werden; @code{guix refresh
|
|
--list-dependent @var{Paket}} hilft Ihnen dabei (@pxref{Aufruf von guix refresh}).
|
|
|
|
@c See <https://lists.gnu.org/archive/html/guix-devel/2016-10/msg00933.html>.
|
|
@cindex Branching-Strategie
|
|
@cindex Neuerstellungs-Zeitplan
|
|
Je nachdem, wieviele abhängige Pakete es gibt, und entsprechend wieviele
|
|
Neuerstellungen dadurch nötig würden, finden Commits auf anderen Branches
|
|
statt, nach ungefähr diesen Regeln:
|
|
|
|
@table @asis
|
|
@item 300 abhängige Pakete oder weniger
|
|
@code{master}-Branch (störfreie Änderungen).
|
|
|
|
@item zwischen 300 und 1200 abhängige Pakete
|
|
@code{staging}-Branch (störfreie Änderungen). Dieser Branch wird circa alle
|
|
3 Wochen in @code{master} gemerget. Themenbezogene Änderungen (z.B. eine
|
|
Aktualisierung der GNOME-Plattform) können stattdessen auch auf einem
|
|
eigenen Branch umgesetzt werden (wie @code{gnome-updates}).
|
|
|
|
@item mehr als 1200 abhängige Pakete
|
|
@code{core-updates}-Branch (kann auch größere und womöglich andere Software
|
|
beeinträchtigende Änderungen umfassen). Dieser Branch wird planmäßig in
|
|
@code{master} alle 2,5 Monate oder so gemerget.
|
|
@end table
|
|
|
|
All diese Branches werden kontinuierlich
|
|
@uref{https://hydra.gnu.org/project/gnu, auf unserer Build-Farm} erstellt
|
|
und in @code{master} gemerget, sobald alles erfolgreich erstellt worden
|
|
ist. Dadurch können wir Probleme beheben, bevor sie bei Nutzern auftreten,
|
|
und zudem das Zeitfenster, während dessen noch keine vorerstellten
|
|
Binärdateien verfügbar sind, verkürzen.
|
|
|
|
@c TODO: It would be good with badges on the website that tracks these
|
|
@c branches. Or maybe even a status page.
|
|
Im Allgemeinen werden Branches außer @code{master} als @emph{unveränderlich}
|
|
angesehen, wenn sie kürzlich ausgewertet wurden oder ein entsprechender
|
|
@code{-next}-Branch existiert. Bitte fragen Sie auf der Mailing-Liste oder
|
|
IRC, wenn Sie sich nicht sicher sind, wo ein Patch eingespielt werden
|
|
sollte.
|
|
|
|
@item
|
|
@cindex Determinismus, von Erstellungsprozessen
|
|
@cindex Reproduzierbare Erstellungen, Überprüfung
|
|
Überprüfen Sie, ob der Erstellungsprozess deterministisch ist. Dazu prüfen
|
|
Sie typischerweise, ob eine unabhängige Erstellung des Pakets genau dasselbe
|
|
Ergebnis wie Ihre Erstellung hat, Bit für Bit.
|
|
|
|
Dies können Sie leicht tun, indem Sie dasselbe Paket mehrere Male
|
|
hintereinander auf Ihrer Maschine erstellen (@pxref{Aufruf von guix build}):
|
|
|
|
@example
|
|
guix build --rounds=2 mein-paket
|
|
@end example
|
|
|
|
Dies reicht aus, um eine ganze Klasse häufiger Ursachen von
|
|
Nichtdeterminismus zu finden, wie zum Beispiel Zeitstempel oder
|
|
zufallsgenerierte Ausgaben im Ergebnis der Erstellung.
|
|
|
|
Another option is to use @command{guix challenge} (@pxref{Aufruf von guix challenge}). You may run it once the package has been committed and built
|
|
by @code{@value{SUBSTITUTE-SERVER}} to check whether it obtains the same
|
|
result as you did. Better yet: Find another machine that can build it and
|
|
run @command{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 @code{uname} or @file{/proc}
|
|
files.
|
|
|
|
@item
|
|
Beim Schreiben von Dokumentation achten Sie bitte auf eine
|
|
geschlechtsneutrale Wortwahl, wenn Sie sich auf Personen beziehen, wie
|
|
@uref{https://en.wikipedia.org/wiki/Singular_they, »they«@comma{}
|
|
»their«@comma{} »them« im Singular}, und so weiter.
|
|
|
|
@item
|
|
Stelllen Sie sicher, dass Ihr Patch nur einen Satz zusammengehöriger
|
|
Änderungen umfasst. Das Zusammenfassen nicht zusammengehöriger Änderungen
|
|
erschwert und bremst das Durchsehen Ihres Patches.
|
|
|
|
Beispiele für nicht zusammengehörige Änderungen sind das Hinzufügen mehrerer
|
|
Pakete auf einmal, oder das Aktualisieren eines Pakets auf eine neue Version
|
|
zusammen mit Fehlerbehebungen für das Paket.
|
|
|
|
@item
|
|
Bitte befolgen Sie unsere Richtlinien für die Code-Formatierung, womöglich
|
|
wollen Sie dies automatisch tun lassen durch das Skript
|
|
@command{etc/indent-code.el} (@pxref{Formatierung von Code}).
|
|
|
|
@item
|
|
Benutzen Sie, wenn möglich, Spiegelserver (Mirrors) in der Quell-URL
|
|
(@pxref{Aufruf von guix download}). Verwenden Sie verlässliche URLs, keine
|
|
automatisch generierten. Zum Beispiel sind Archive von GitHub nicht immer
|
|
identisch von einer Generation auf die nächste, daher ist es in diesem Fall
|
|
besser, als Quelle einen Klon des Repositorys zu verwenden. Benutzen Sie
|
|
@emph{nicht} das @command{name}-Feld beim Angeben der URL; er hilft nicht
|
|
wirklich und wenn sich der Name ändert, stimmt die URL nicht mehr.
|
|
|
|
@end enumerate
|
|
|
|
Bitte benutzen Sie @samp{[PATCH] @dots{}} als Betreff, wenn Sie einen Patch
|
|
an die Mailing-Liste schicken. Sie können dazu Ihr E-Mail-Programm oder den
|
|
Befehl @command{git send-email} benutzen (@pxref{Senden einer Patch-Reihe}). Wir bevorzugen es, Patches als reine Textnachrichten zu erhalten,
|
|
entweder eingebettet (inline) oder als MIME-Anhänge. Sie sind dazu
|
|
angehalten, zu überprüfen, ob Ihr Mail-Programm solche Dinge wie
|
|
Zeilenumbrüche oder die Einrückung verändert, wodurch die Patches womöglich
|
|
nicht mehr funktionieren.
|
|
|
|
Wenn dadurch ein Fehler behoben wurde, schließen Sie bitte den Thread, indem
|
|
Sie eine E-Mail an @email{@var{NNN}-done@@debbugs.gnu.org} senden.
|
|
|
|
@unnumberedsubsec Senden einer Patch-Reihe
|
|
@anchor{Senden einer Patch-Reihe}
|
|
@cindex Patch-Reihe
|
|
@cindex @code{git send-email}
|
|
@cindex @code{git-send-email}
|
|
|
|
@c Debbugs bug: https://debbugs.gnu.org/db/15/15361.html
|
|
Wenn Sie eine Patch-Reihe senden (z.B. mit @code{git send-email}), schicken
|
|
Sie bitte als Erstes eine Nachricht an @email{guix-patches@@gnu.org} und
|
|
dann nachfolgende Patches an @email{@var{NNN}@@debbugs.gnu.org}, um
|
|
sicherzustellen, dass sie zusammen bearbeitet werden. Siehe
|
|
@uref{https://debbugs.gnu.org/Advanced.html, die Debbugs-Dokumentation} für
|
|
weitere Informationen.
|