@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}).
+Erstellung von Paketen (siehe @ref{Paketrichtlinien}).
@cindex Verhaltensregeln, für Mitwirkende
@cindex Verhaltenskodex für Mitwirkende
* 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
@end example
Wenn Sie Guix aus einem Checkout erstellen, sind außer den bereits in den
-Installationsanweisungen genannten Paketen weitere nötig
-(@pxref{Voraussetzungen}).
+Installationsanweisungen genannten Paketen weitere nötig (siehe
+@ref{Voraussetzungen}).
@itemize
@item @url{http://gnu.org/software/autoconf/, GNU Autoconf};
guix environment guix
@end example
-In @xref{Aufruf von guix environment} finden Sie weitere Informationen zu
+In @ref{Aufruf von guix environment} finden Sie weitere Informationen zu
diesem Befehl. Zusätzliche Abhängigkeiten können mit @option{--ad-hoc}
hinzugefügt werden:
@end example
Führen Sie @command{./bootstrap} aus, um die Infrastruktur des
-Erstellungssystems mit Autoconf und Automake zu erstellen. Möglicherweise
+Erstellungssystems mit Autoconf und Automake zu erzeugen. Möglicherweise
erhalten Sie eine Fehlermeldung wie diese:
@example
export ACLOCAL_PATH=/usr/share/aclocal
@end example
-In @xref{Macro Search Path,,, automake, The GNU Automake Manual} finden Sie
+In @ref{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}).
+@code{localstatedir}-Wert ist (weitere Informationen siehe @ref{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}.
+(siehe @ref{Den Testkatalog laufen lassen}). Falls etwas fehlschlägt, werfen Sie
+einen Blick auf die Installationsanweisungen (siehe @ref{Installation}) oder
+senden Sie eine E-Mail an die @email{guix-devel@@gnu.org, Mailingliste}.
@node Guix vor der Installation ausführen
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; it is generated by
-@command{./configure}), 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.}:
+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 (siehe @ref{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
@noindent
@cindex REPL
@cindex Lese-Auswerten-Schreiben-Schleife
-@dots{} und auf einer REPL (@pxref{Using Guile Interactively,,, guile, Guile
-Reference Manual}):
+@dots{} und auf einer REPL (siehe @ref{Using Guile Interactively,,, guile,
+Guile Reference Manual}):
@example
$ ./pre-inst-env guile
nötig sind, um dies zu ermöglichen, einschließlich @env{PATH} und
@env{GUILE_LOAD_PATH}.
-Note that @command{./pre-inst-env guix pull} does @emph{not} upgrade the
-local source tree; it simply updates the @file{~/.config/guix/current}
-symlink (@pxref{Aufruf von guix pull}). Run @command{git pull} instead if you
-want to upgrade your local source tree.
+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} (siehe @ref{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}.
+dasselbe wie um perfekt für das Hacken mit Guile (siehe @ref{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} zusammen mit den vom
+wunderbaren @url{http://nongnu.org/geiser/, Geiser} verliehenen Kräften. Um
+diese zu installieren, können Sie Folgendes ausführen:
+
+@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
+zu springen, eine REPL, um Ihren Code auszuprobieren, und mehr (siehe
+@ref{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.
(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.
+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
wieder weiter umgeschrieben werden kann.
+@node Paketrichtlinien
+@section Paketrichtlinien
+
+@cindex Pakete definieren
+Die GNU-Distribution ist noch sehr jung und einige Ihrer Lieblingspakete
+könnten noch fehlen. Dieser Abschnitt beschreibt, wie Sie dabei helfen
+können, die Distribution wachsen zu lassen.
+
+Pakete mit freier Software werden normalerweise in Form von @dfn{Tarballs
+mit dem Quellcode} angeboten — typischerweise in
+@file{tar.gz}-Archivdateien, in denen alle Quelldateien enthalten sind. Ein
+Paket zur Distribution hinzuzufügen, bedeutet also zweierlei Dinge: Zum
+einen fügt man ein @dfn{Rezept} ein, das beschreibt, wie das Paket erstellt
+werden kann, einschließlich einer Liste von anderen Paketen, die für diese
+Erstellung gebraucht werden, zum anderen fügt man @dfn{Paketmetadaten} zum
+Rezept hinzu, wie zum Beispiel eine Beschreibung und Lizenzinformationen.
+
+In Guix sind all diese Informationen ein Teil der
+@dfn{Paketdefinitionen}. In Paketdefinitionen hat man eine abstrahierte,
+hochsprachliche Sicht auf das Paket. Sie werden in der Syntax der
+Scheme-Programmiersprache verfasst; tatsächlich definieren wir für jedes
+Paket eine Variable und binden diese an dessen Definition, um die Variable
+anschließend aus einem Modul heraus zu exportieren (siehe @ref{Paketmodule}). Allerdings ist @emph{kein} tiefgehendes Wissen über Scheme
+erforderlich, um Pakete zu erstellen. Mehr Informationen über
+Paketdefinitionen finden Sie im Abschnitt @ref{Pakete definieren}.
+
+Eine fertige Paketdefinition kann, nachdem sie in eine Datei im
+Quell-Verzeichnisbaum von Guix eingesetzt wurde, mit Hilfe des Befehls
+@command{guix build} getestet werden (siehe @ref{Aufruf von guix build}). Wenn
+das Paket zum Beispiel den Namen @code{gnew} trägt, können Sie folgenden
+Befehl aus dem Erstellungs-Verzeichnisbaum von Guix heraus ausführen (siehe
+@ref{Guix vor der Installation ausführen}):
+
+@example
+./pre-inst-env guix build gnew --keep-failed
+@end example
+
+Wenn Sie @code{--keep-failed} benutzen, ist es leichter, fehlgeschlagene
+Erstellungen zu untersuchen, weil dann der Verzeichnisbaum der
+fehlgeschlagenen Erstellung zugänglich bleibt. Eine andere nützliche
+Befehlszeilenoption bei der Fehlersuche ist @code{--log-file}, womit das
+Erstellungsprotokoll eingesehen werden kann.
+
+Wenn der @command{guix}-Befehl das Paket nicht erkennt, kann es daran
+liegen, dass die Quelldatei einen Syntaxfehler hat oder ihr eine
+@code{define-public}-Klausel fehlt, die die Paketvariable exportiert. Um das
+herauszufinden, können Sie das Modul aus Guile heraus laden, um mehr
+Informationen über den tatsächlichen Fehler zu bekommen:
+
+@example
+./pre-inst-env guile -c '(use-modules (gnu packages gnew))'
+@end example
+
+Sobald Ihr Paket erfolgreich erstellt werden kann, schicken Sie uns bitte
+einen Patch (siehe @ref{Einreichen von Patches}). Wenn Sie dabei Hilfe brauchen
+sollten, helfen wir gerne. Ab dem Zeitpunkt, zu dem der Patch als Commit ins
+Guix-Repository eingepflegt wurde, wird das neue Paket automatisch durch
+@url{http://hydra.gnu.org/jobset/gnu/master, unser System zur
+Kontinuierlichen Integration} auf allen unterstützten Plattformen erstellt.
+
+@cindex Substituierer
+Benutzern steht die neue Paketdefinition zur Verfügung, nachdem sie das
+nächste Mal @command{guix pull} ausgeführt haben (siehe @ref{Aufruf von guix pull}). Wenn @code{@value{SUBSTITUTE-SERVER}} selbst damit fertig ist, das
+Paket zu erstellen, werden bei der Installation automatisch Binärdateien von
+dort heruntergeladen (siehe @ref{Substitute}). Menschliches Eingreifen muss
+nur stattfinden, um den Patch zu überprüfen und anzuwenden.
+
+
+@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 freie Software
+Das GNU-Betriebssystem wurde entwickelt, um Menschen Freiheit bei der
+Nutzung ihrer Rechengeräte zu ermöglichen. GNU ist @dfn{freie Software}, was
+bedeutet, dass Benutzer die
+@url{http://www.gnu.org/philosophy/free-sw.de.html,vier wesentlichen
+Freiheiten} haben: das Programm auszuführen, es zu untersuchen, das Programm
+in Form seines Quellcodes anzupassen und exakte Kopien ebenso wie
+modifizierte Versionen davon an andere weiterzugeben. Die Pakete, die Sie in
+der GNU-Distribution finden, stellen ausschließlich solche Software zur
+Verfügung, die Ihnen diese vier Freiheiten gewährt.
+
+Außerdem befolgt die GNU-Distribution die
+@url{http://www.gnu.org/distros/free-system-distribution-guidelines.de.html,Richtlinien
+für freie Systemverteilungen}. Unter anderem werden unfreie Firmware sowie
+Empfehlungen von unfreier Software abgelehnt und Möglichkeiten zum Umgang
+mit Markenzeichen und Patenten werden diskutiert.
+
+Ansonsten freier Paketquellcode von manchen Anbietern enthält einen kleinen
+und optionalen Teil, der diese Richtlinien verletzt. Zum Beispiel kann
+dieser Teil selbst unfreier Code sein. Wenn das vorkommt, wird der sie
+verletzende Teil mit angemessenen Patches oder Code-Schnipseln innerhalb der
+@code{origin}-Form des Pakets entfernt (siehe @ref{Pakete definieren}). Dadurch liefert Ihnen @code{guix build --source} nur den
+»befreiten« Quellcode und nicht den unmodifizierten Quellcode des Anbieters.
+
+
+@node Paketbenennung
+@subsection Paketbenennung
+
+@cindex Paketname
+Tatsächlich sind mit jedem Paket zwei Namen assoziiert: Zum einen gibt es
+den Namen der @emph{Scheme-Variablen}, der direkt nach @code{define-public}
+im Code steht. Mit diesem Namen kann das Paket im Scheme-Code nutzbar
+gemacht und zum Beispiel als Eingabe eines anderen Pakets benannt
+werden. Zum anderen gibt es die Zeichenkette im @code{name}-Feld einer
+Paketdefinition. Dieser Name wird von Paketverwaltungsbefehlen wie
+@command{guix package} und @command{guix build} benutzt.
+
+Meistens sind die beiden identisch und ergeben sich aus einer Umwandlung des
+vom Anbieter verwendeten Projektnamens in Kleinbuchstaben, bei der
+Unterstriche durch Bindestriche ersetzt werden. Zum Beispiel wird GNUnet
+unter dem Paketnamen @code{gnunet} angeboten und SDL_net als @code{sdl-net}.
+
+An Bibliothekspakete hängen wir vorne kein @code{lib} als Präfix an, solange
+es nicht Teil des offiziellen Projektnamens ist. Beachten Sie aber die
+Abschnitte @ref{Python-Module} und @ref{Perl-Module}, in denen
+Sonderregeln für Module der Programmiersprachen Python und Perl beschrieben
+sind.
+
+Auch Pakete mit Schriftarten werden anders behandelt, siehe @ref{Schriftarten}.
+
+
+@node Versionsnummern
+@subsection Versionsnummern
+
+@cindex Paketversion
+Normalerweise stellen wir nur für die neueste Version eines
+Freie-Software-Projekts ein Paket bereit. Manchmal gibt es allerdings Fälle
+wie zum Beispiel untereinander inkompatible Bibliotheksversionen, so dass
+zwei (oder mehr) Versionen desselben Pakets angeboten werden müssen. In
+diesem Fall müssen wir verschiedene Scheme-Variablennamen benutzen. Wir
+benutzen dann für die neueste Version den Namen, wie er im Abschnitt
+@ref{Paketbenennung} festgelegt wird, und geben vorherigen Versionen
+denselben Namen mit einem zusätzlichen Suffix aus @code{-} gefolgt vom
+kürzesten Präfix der Versionsnummer, mit dem noch immer zwei Versionen
+unterschieden werden können.
+
+Der Name innerhalb der Paketdefinition ist hingegen derselbe für alle
+Versionen eines Pakets und enthält keine Versionsnummer.
+
+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 Versionsnummer, bei Snapshots aus Versionskontrolle
+Gelegentlich fügen wir auch Pakete für Snapshots aus dem
+Versionskontrollsystem des Anbieters statt formaler Veröffentlichungen zur
+Distribution hinzu. Das sollte die Ausnahme bleiben, weil die Entwickler
+selbst klarstellen sollten, welche Version als die stabile Veröffentlichung
+gelten sollte, ab und zu ist es jedoch notwendig. Was also sollten wir dann
+im @code{version}-Feld eintragen?
+
+Offensichtlich muss der Bezeichner des Commits, den wir als Snapshot aus dem
+Versionskontrollsystem nehmen, in der Versionszeichenkette zu erkennen sein,
+aber wir müssen auch sicherstellen, dass die Version monoton steigend ist,
+damit @command{guix package --upgrade} feststellen kann, welche Version die
+neuere ist. Weil Commit-Bezeichner, insbesondere bei Git, nicht monoton
+steigen, müssen wir eine Revisionsnummer hinzufügen, die wir jedes Mal
+erhöhen, wenn wir das Paket auf einen neueren Snapshot aktualisieren. Die
+sich ergebende Versionszeichenkette sieht dann so aus:
+
+@example
+2.0.11-3.cabba9e
+ ^ ^ ^
+ | | `-- Commit-ID beim Anbieter
+ | |
+ | `--- Revisionsnummer des Guix-Pakets
+ |
+die neueste Version, die der Anbieter veröffentlicht hat
+@end example
+
+Es ist eine gute Idee, die Commit-Bezeichner im @code{version}-Feld auf,
+sagen wir, 7 Ziffern zu beschränken. Das sieht besser aus (angenommen, das
+sollte hier eine Rolle spielen) und vermeidet Probleme, die mit der
+maximalen Länge von Shebangs zu tun haben (127 Bytes beim Linux-Kernel). Am
+besten benutzt man jedoch den vollständigen Commit-Bezeichner in
+@code{origin}s, um Mehrdeutigkeiten zu vermeiden. Eine typische
+Paketdefinition könnte so aussehen:
+
+@example
+(define mein-paket
+ (let ((commit "c3f29bc928d5900971f65965feaae59e1272a3f7")
+ (revision "1")) ;Guix-Paketrevision
+ (package
+ (version (git-version "0.9" revision commit))
+ (source (origin
+ (method git-fetch)
+ (uri (git-reference
+ (url "git://example.org/mein-paket.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 Paketbeschreibung
+@cindex Paketzusammenfassung
+Wie wir bereits gesehen haben, enthält jedes Paket in GNU@tie{}Guix eine (im
+Code englischsprachige) Zusammenfassung (englisch: Synopsis) und eine
+Beschreibung (englisch: Description; siehe @ref{Pakete definieren}). Zusammenfassungen und Beschreibungen sind wichtig: Sie werden
+mit @command{guix package --search} durchsucht und stellen eine
+entscheidende Informationsquelle für Nutzer dar, die entscheiden wollen, ob
+das Paket Ihren Bedürfnissen entspricht, daher sollten Paketentwickler Acht
+geben, was sie dort eintragen.
+
+Zusammenfassungen müssen mit einem Großbuchstaben beginnen und dürfen nicht
+mit einem Punkt enden. Sie dürfen nicht mit den Artikeln »a« oder »the«
+beginnen, die meistens ohnehin nichts zum Verständnis beitragen. Zum
+Beispiel sollte »File-frobbing tool« gegenüber »A tool that frobs files«
+vorgezogen werden. Die Zusammenfassung sollte aussagen, um was es sich beim
+Paket handelt — z.B.@: »Core GNU utilities (file, text, shell)« —, oder
+aussagen, wofür es benutzt wird — z.B.@: ist die Zusammenfassung für
+GNU@tie{}grep »Print lines matching a pattern«.
+
+Beachten Sie, dass die Zusammenfassung für eine sehr große Leserschaft einen
+Sinn ergeben muss. Zum Beispiel würde »Manipulate alignments in the SAM
+format« vielleicht von einem erfahrenen Forscher in der Bioinformatik
+verstanden, könnte für die Nicht-Spezialisten in Guix’ Zielgruppe aber wenig
+hilfreich sein oder würde diesen sogar eine falsche Vorstellung geben. Es
+ist eine gute Idee, sich eine Zusammenfassung zu überlegen, die eine
+Vorstellung von der Anwendungsdomäne des Pakets vermittelt. Im Beispiel hier
+würden sich die Nutzer mit »Manipulate nucleotide sequence alignments«
+hoffentlich ein besseres Bild davon machen können, ob das Paket ist, wonach
+sie suchen.
+
+Beschreibungen sollten zwischen fünf und zehn Zeilen lang sein. Benutzen Sie
+vollständige Sätze und vermeiden Sie Abkürzungen, die Sie nicht zuvor
+eingeführt haben. Vermeiden Sie bitte Marketing-Phrasen wie »world-leading«
+(»weltweit führend«), »industrial-strength« (»industrietauglich«) und
+»next-generation« (»der nächsten Generation«) ebenso wie Superlative wie
+»the most advanced« (»das fortgeschrittenste«) — davon haben Nutzer nichts,
+wenn sie ein Paket suchen, und es könnte sogar verdächtig klingen. Versuchen
+Sie stattdessen, bei den Fakten zu bleiben und dabei Anwendungszwecke und
+Funktionalitäten zu erwähnen.
+
+@cindex Texinfo-Auszeichnungen, in Paketbeschreibungen
+Beschreibungen können wie bei Texinfo ausgezeichneten Text enthalten. Das
+bedeutet, Text kann Verzierungen wie @code{@@code} oder @code{@@dfn},
+Auflistungen oder Hyperlinks enthalten (siehe @ref{Overview,,, texinfo, GNU
+Texinfo}). Sie sollten allerdings vorsichtig sein, wenn Sie bestimmte
+Zeichen wie @samp{@@} und geschweifte Klammern schreiben, weil es sich dabei
+um die grundlegenden Sonderzeichen in Texinfo handelt (siehe @ref{Special
+Characters,,, texinfo, GNU Texinfo}). Benutzungsschnittstellen wie
+@command{guix package --show} kümmern sich darum, solche Auszeichnungen
+angemessen darzustellen.
+
+Zusammenfassungen und Beschreibungen werden von Freiwilligen
+@uref{http://translationproject.org/domain/guix-packages.html, beim
+Translation Project} übersetzt, damit so viele Nutzer wie möglich sie in
+ihrer Muttersprache lesen können. Mit Schnittstellen für Benutzer können sie
+in der von der aktuell eingestellten Locale festgelegten Sprache durchsucht
+und angezeigt werden.
+
+Damit @command{xgettext} sie als übersetzbare Zeichenketten extrahieren
+kann, @emph{müssen} Zusammenfassungen und Beschreibungen einfache
+Zeichenketten-Literale sein. Das bedeutet, dass Sie diese Zeichenketten
+nicht mit Prozeduren wie @code{string-append} oder @code{format}
+konstruieren können:
+
+@lisp
+(package
+ ;; @dots{}
+ (synopsis "This is translatable")
+ (description (string-append "This is " "*not*" " translatable.")))
+@end lisp
+
+Übersetzen ist viel Arbeit, also passen Sie als Paketentwickler bitte umso
+mehr auf, wenn Sie Ihre Zusammenfassungen und Beschreibungen formulieren,
+weil jede Änderung zusätzliche Arbeit für Übersetzer bedeutet. Um den
+Übersetzern zu helfen, können Sie Empfehlungen und Anweisungen für diese
+sichtbar machen, indem Sie spezielle Kommentare wie in diesem Beispiel
+einfügen (siehe @ref{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
+Zur Zeit stellen wir ein Paket für Python 2 und eines für Python 3 jeweils
+über die Scheme-Variablen mit den Namen @code{python-2} und @code{python}
+zur Verfügung, entsprechend der Erklärungen im Abschnitt @ref{Versionsnummern}. Um Verwirrungen und Namenskollisionen mit anderen
+Programmiersprachen zu vermeiden, erscheint es als wünschenswert, dass der
+Name eines Pakets für ein Python-Modul auch das Wort @code{python} enthält.
+
+Manche Module sind nur mit einer Version von Python kompatibel, andere mit
+beiden. Wenn das Paket Foo nur mit Python 3 kompiliert werden kann, geben
+wir ihm den Namen @code{python-foo}, wenn es nur mit Python 2 kompilierbar
+ist, wählen wir den Namen @code{python2-foo}. Ist es mit beiden Versionen
+kompatibel, erstellen wir zwei Pakete jeweils mit dem entsprechenden Namen.
+
+Wenn ein Projekt bereits das Wort @code{python} im Namen hat, lassen wir es
+weg; zum Beispiel ist das Modul python-dateutil unter den Namen
+@code{python-dateutil} und @code{python2-dateutil} verfügbar. Wenn der
+Projektname mit @code{py} beginnt (z.B.@: @code{pytz}), behalten wir ihn bei
+und stellen das oben beschriebene Präfix voran.
+
+@subsubsection Abhängigkeiten angeben
+@cindex Eingaben, für Python-Pakete
+
+Informationen über Abhängigkeiten von Python-Paketen, welche mal mehr und
+mal weniger stimmen, finden sich normalerweise im Verzeichnisbaum des
+Paketquellcodes: in der Datei @file{setup.py}, in @file{requirements.txt}
+oder in @file{tox.ini}.
+
+Wenn Sie ein Rezept für ein Python-Paket schreiben, lautet Ihr Auftrag,
+diese Abhängigkeiten auf angemessene Arten von »Eingaben« abzubilden (siehe
+@ref{»package«-Referenz, inputs}). Obwohl der @code{pypi}-Importer hier
+normalerweise eine gute Arbeit leistet (siehe @ref{Aufruf von guix import}),
+könnten Sie die folgende Prüfliste durchgehen wollen, um zu bestimmen, wo
+welche Abhängigkeit eingeordnet werden sollte.
+
+@itemize
+
+@item
+Derzeit ist unser Python-2-Paket so geschrieben, dass es @code{setuptools}
+und @code{pip} installiert, wie es auch in den Vorgaben zu Python 3.4
+gemacht wird. Sie müssen also keines der beiden als Eingabe angeben. Wenn
+Sie es doch tun, wird @command{guix lint} Sie darauf mit einer Warnung
+aufmerksam machen.
+
+@item
+Python-Abhängigkeiten, die zur Laufzeit gebraucht werden, stehen im
+@code{propagated-inputs}-Feld. Solche werden typischerweise mit dem
+Schlüsselwort @code{install_requires} in @file{setup.py} oder in der Datei
+@file{requirements.txt} definiert.
+
+@item
+Python-Pakete, die nur zur Erstellungszeit gebraucht werden — z.B.@: jene,
+die mit dem Schlüsselwort @code{setup_requires} in @file{setup.py}
+aufgeführt sind — oder die nur zum Testen gebraucht werden — also die in
+@code{tests_require} —, stehen in @code{native-inputs}. Die Begründung ist,
+dass (1) sie nicht propagiert werden müssen, weil sie zur Laufzeit nicht
+gebraucht werden, und (2) wir beim Cross-Kompilieren die »native« Eingabe
+des Wirtssystems wollen.
+
+Beispiele sind die Testrahmen @code{pytest}, @code{mock} und
+@code{nose}. Wenn natürlich irgendeines dieser Pakete auch zur Laufzeit
+benötigt wird, muss es doch in @code{propagated-inputs} stehen.
+
+@item
+Alles, was nicht in die bisher genannten Kategorien fällt, steht in
+@code{inputs}, zum Beispiel Programme oder C-Bibliotheken, die zur
+Erstellung von Python-Paketen mit enthaltenen C-Erweiterungen gebraucht
+werden.
+
+@item
+Wenn ein Python-Paket optionale Abhängigkeiten hat (@code{extras_require}),
+ist es Ihnen überlassen, sie hinzuzufügen oder nicht hinzuzufügen, je
+nachdem wie es um deren Verhältnis von Nützlichkeit zu anderen Nachteilen
+steht (siehe @ref{Einreichen von Patches, @command{guix size}}).
+
+@end itemize
+
+
+@node Perl-Module
+@subsection Perl-Module
+
+@cindex perl
+Eigenständige Perl-Programme bekommen einen Namen wie jedes andere Paket,
+unter Nutzung des Namens beim Anbieter in Kleinbuchstaben. Für Perl-Pakete,
+die eine einzelne Klasse enthalten, ersetzen wir alle Vorkommen von
+@code{::} durch Striche und hängen davor das Präfix @code{perl-} an. Die
+Klasse @code{XML::Parser} wird also zu @code{perl-xml-parser}. Module, die
+mehrere Klassen beinhalten, behalten ihren Namen beim Anbieter, in
+Kleinbuchstaben gesetzt, und auch an sie wird vorne das Präfix @code{perl-}
+angehängt. Es gibt die Tendenz, solche Module mit dem Wort @code{perl}
+irgendwo im Namen zu versehen, das wird zu Gunsten des Präfixes
+weggelassen. Zum Beispiel wird aus @code{libwww-perl} bei uns
+@code{perl-libwww}.
+
+
+@node Java-Pakete
+@subsection Java-Pakete
+
+@cindex java
+Eigenständige Java-Programme werden wie jedes andere Paket benannt, d.h.@:
+mit ihrem in Kleinbuchstaben geschriebenen Namen beim Anbieter.
+
+Um Verwirrungen und Namenskollisionen mit anderen Programmiersprachen zu
+vermeiden, ist es wünschenswert, dass dem Namem eines Pakets zu einem
+Java-Paket das Präfix @code{java-} vorangestellt wird. Wenn ein Projekt
+bereits das Wort @code{java} im Namen trägt, lassen wir es weg; zum Beispiel
+befindet sich das Java-Paket @code{ngsjava} in einem Paket namens
+@code{java-ngs}.
+
+Bei Java-Paketen, die eine einzelne Klasse oder eine kleine
+Klassenhierarchie enthalten, benutzen wir den Klassennamen in
+Kleinbuchstaben und ersetzen dabei alle Vorkommen von @code{.} durch Striche
+und setzen das Präfix @code{java-} davor. Die Klasse
+@code{apache.commons.cli} wird also zum Paket
+@code{java-apache-commons-cli}.
+
+
+@node Schriftarten
+@subsection Schriftarten
+
+@cindex Schriftarten
+Wenn Schriftarten in der Regel nicht von Nutzern zur Textbearbeitung
+installiert werden oder als Teil eines größeren Software-Pakets mitgeliefert
+werden, gelten dafür die allgemeinen Paketrichtlinien für Software. Zum
+Beispiel trifft das auf als Teil des X.Org-Systems ausgelieferte
+Schriftarten zu, oder auf Schriftarten, die ein Teil von TeX Live sind.
+
+Damit es Nutzer leichter haben, nach Schriftarten zu suchen, konstruieren
+wir die Namen von anderen Paketen, die nur Schriftarten enthalten, nach dem
+folgenden Schema, egal was der Paketname beim Anbieter ist.
+
+Der Name eines Pakets, das nur eine Schriftfamilie enthält, beginnt mit
+@code{font-}. Darauf folgt der Name des Schriftenherstellers und ein Strich
+@code{-}, sofern bekannt ist, wer der Schriftenhersteller ist, und dann der
+Name der Schriftfamilie, in dem Leerzeichen durch Striche ersetzt werden
+(und wie immer mit Großbuchstaben statt Kleinbuchstaben). Zum Beispiel
+befindet sich die von SIL hergestellte Gentium-Schriftfamilie im Paket mit
+dem Namen @code{font-sil-gentium}.
+
+Wenn ein Paket mehrere Schriftfamilien enthält, wird der Name der Sammlung
+anstelle des Schriftfamiliennamens benutzt. Zum Beispiel umfassen die
+Liberation-Schriftarten drei Familien: Liberation Sans, Liberation Serif und
+Liberation Mono. Man könnte sie getrennt voneinander mit den Namen
+@code{font-liberation-sans} und so weiter in Pakete einteilen, da sie aber
+unter einem gemeinsamen Namen angeboten werden, packen wir sie lieber
+zusammen in ein Paket mit dem Namen @code{font-liberation}.
+
+Für den Fall, dass mehrere Formate derselben Schriftfamilie oder
+Schriftartensammlung in separate Pakete kommen, wird ein Kurzname für das
+Format mit einem Strich vorne zum Paketnamen hinzugefügt. Wir benutzen
+@code{-ttf} für TrueType-Schriftarten, @code{-otf} für OpenType-Schriftarten
+und @code{-type1} für PostScript-Typ-1-Schriftarten.
+
+
@node Code-Stil
@section Code-Stil
-Im Allgemeinen folgt unser Code den GNU Coding Standards (@pxref{Top,,,
+Im Allgemeinen folgt unser Code den GNU Coding Standards (siehe @ref{Top,,,
standards, GNU Coding Standards}). Da diese aber nicht viel über Scheme zu
sagen haben, folgen hier einige zusätzliche Regeln.
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
+hervorhebt (siehe @ref{Entwicklung,,, emacs-guix, The Emacs-Guix Reference
Manual}).
@cindex Einrückung, Code-
ü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}).
+kann, wobei @var{NNN} für die Folgenummer steht (siehe @ref{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.
+Bitte schreiben Sie Commit-Logs im ChangeLog-Format (siehe @ref{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.
+Wenn die Autoren der verpackten Software eine kryptografische Signatur
+bzw. Beglaubigung 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
+das Paket zu verfassen. Unter @ref{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}).
+geänderte Paket bezeichnet, und beheben Sie alle gemeldeten Fehler (siehe
+@ref{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
+Wir empfehlen, dass Sie auch versuchen, das Paket auf anderen unterstützten
+Plattformen zu erstellen. Da Sie vielleicht keinen Zugang zu echter Hardware
+für diese Plattformen haben, empfehlen wir, den
+@code{qemu-binfmt-service-type} zu benutzen, um sie zu emulieren. Um ihn zu
+aktivieren, fügen Sie den folgenden Dienst in die Liste der Dienste
+(»services«) in Ihrer @code{operating-system}-Konfiguration ein:
+
+@example
+(service qemu-binfmt-service-type
+ (qemu-binfmt-configuration
+ (platforms (lookup-qemu-platforms "arm" "aarch64" "mips64el"))
+ (guix-support? #t)))
+@end example
+
+Rekonfigurieren Sie anschließend Ihr System.
+
+Sie können Pakete für andere Plattformen erstellen lassen, indem Sie die
+Befehlszeilenoption @code{--system} angeben. Um zum Beispiel das Paket
+»hello« für die Architekturen armhf, aarch64 oder mips64 erstellen zu
+lassen, würden Sie jeweils die folgenden Befehle angeben:
+@example
+guix build --system=armhf-linux --rounds=2 hello
+guix build --system=aarch64-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,
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.
+Schauen Sie sich das von @command{guix size} ausgegebene Profil an (siehe
+@ref{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 (siehe @ref{Pakete mit mehreren Ausgaben.}) und welche optionalen Abhängigkeiten verwendet
+werden sollten. Dabei sollten Sie es wegen seiner enormen Größe insbesondere
+vermeiden, @code{texlive} als eine Abhängigkeit hinzuzufügen; benutzen Sie
+stattdessen @code{texlive-tiny} oder @code{texlive-union}.
@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}).
+--list-dependent @var{Paket}} hilft Ihnen dabei (siehe @ref{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
@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}).
+3 Wochen mit @code{master} zusammengeführt. 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
@code{master} alle 2,5 Monate oder so gemerget.
@end table
-All these branches are @uref{https://hydra.gnu.org/project/gnu, tracked by
-our build farm} and merged into @code{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.
+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.
-Generally, branches other than @code{master} are considered @emph{frozen} if
-there has been a recent evaluation, or there is a corresponding @code{-next}
-branch. Please ask on the mailing list or IRC if unsure where to place a
-patch.
+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
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}):
+hintereinander auf Ihrer Maschine erstellen (siehe @ref{Aufruf von guix build}):
@example
guix build --rounds=2 mein-paket
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
+Eine weitere Möglichkeit ist, @command{guix challenge} (siehe @ref{Aufruf von guix challenge}) zu benutzen. Sie können es ausführen, sobald ein Paket
+commitet und von @code{@value{SUBSTITUTE-SERVER}} 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.
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.
+»their«@comma{} »them« im Singular} und so weiter.
@item
Stelllen Sie sicher, dass Ihr Patch nur einen Satz zusammengehöriger
@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}).
+@command{etc/indent-code.el} (siehe @ref{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.
+Benutzen Sie, wenn möglich, Spiegelserver (Mirrors) in der Quell-URL (siehe
+@ref{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,
+Befehl @command{git send-email} benutzen (siehe @ref{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
@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.
+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.
HCoop / jackhill / guix / guix.git / blobdiff