doc: Add German translation.

* doc/contributing.de.texi: New file.
* doc/guix.de.texi: New file
* doc/local.mk (TRANSLATED_INFO): Add them.
(info_TEXINFOS): Add guix.de.texi.
* po/doc/guix-manual.de.po: New file.
* po/doc/local.mk (EXTRA_DIST): Add it.
* doc/guix.texi: Document the German translation.

1 files changed, 537 insertions, 0 deletions

diff --git a/doc/contributing.de.texi b/doc/contributing.de.texi
new file mode 100644
index 0000000000..6c302ad70d
--- /dev/null
+++ b/doc/contributing.de.texi
@@ -0,0 +1,537 @@
+@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 ist. 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.
+* 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 @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 behalten, 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.
+
+To that end, all the command-line tools can be used even if you have not run
+@code{make install}.  To do that, you first need to have an environment with
+all the dependencies available (@pxref{Erstellung aus dem Git}), and then simply
+prefix each command with @command{./pre-inst-env} (the @file{pre-inst-env}
+script lives in the top build tree of Guix), as in@footnote{The @option{-E}
+flag to @command{sudo} guarantees that @code{GUILE_LOAD_PATH} is correctly
+set such that @command{guix-daemon} and the tools it uses can find the Guile
+modules they need.}:
+
+@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
+
+Um perfekt für das Hacken an Guix eingerichtet zu sein, brauchen Sie an sich
+dasselbe wie um perfekt für das Hacken mit Guile (@pxref{Using Guile in
+Emacs,,, guile, Guile Reference Manual}).  Zunächst brauchen Sie mehr als
+ein Textverarbeitungsprogramm, Sie brauchen
+@url{http://www.gnu.org/software/emacs, Emacs}, ermächtigt vom wunderbaren
+@url{http://nongnu.org/geiser/, Geiser}.
+
+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
+
+The commit message snippets depend on @url{https://magit.vc/, Magit} to
+display staged files.  When editing a commit message type @code{add}
+followed by @kbd{TAB} to insert a commit message template for adding a
+package; type @code{update} followed by @kbd{TAB} to insert a template for
+updating a package; type @code{https} followed by @kbd{TAB} to insert a
+template for changing the home page URI of a package to HTTPS.
+
+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 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-Modules 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 mit 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:
+
+@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
+@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 für 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 das gesamte System betreffen — gebündelt mitgelieferte
+Kopien würden dies verhindern.
+
+@item
+Schauen Sie sich das von @command{guix size} ausgegebene Profil an
+(@pxref{Aufruf von guix size}). Dadurch können Sie Referenzen auf andere
+Pakete finden, die ungewollt vorhanden sind. Dies kann auch dabei helfen, zu
+entscheiden, ob das Paket aufgespalten werden sollte (@pxref{Pakete mit mehreren Ausgaben.}) und welche optionalen Abhängigkeiten verwendet werden
+sollten.
+
+@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 ===========================================================================
+@c
+@c This file was generated with po4a. Translate the source file.
+@c
+@c ===========================================================================
+@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.
+
+Eine weitere Möglichkeit ist, @command{guix challenge} (@pxref{Aufruf von guix challenge}) zu benutzen. Sie können es ausführen, sobald ein Paket commitet
+und von @code{hydra.gnu.org} erstellt wurde, um zu sehen, ob dort dasselbe
+Ergebnis wie bei Ihnen geliefert wurde. Noch besser: Finden Sie eine andere
+Maschine, die das Paket erstellen kann, und führen Sie @command{guix
+publish} aus. Da sich die entfernte Erstellungsmaschine wahrscheinlich von
+Ihrer unterscheidet, können Sie auf diese Weise Probleme durch
+Nichtdeterminismus erkennen, die mit der Hardware zu tun haben — zum
+Beispiel die Nutzung anderer Befehlssatzerweiterungen — oder mit dem
+Betriebssystem-Kernel — zum Beispiel, indem @code{uname} oder
+@file{/proc}-Dateien verwendet werden.
+
+@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
+When possible, use mirrors in the source URL (@pxref{Aufruf von 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
+@command{name} field in the URL: it is not very useful and if the name
+changes, the URL will probably be wrong.
+
+@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.