X-Git-Url: https://git.hcoop.net/jackhill/guix/guix.git/blobdiff_plain/99f63f011df2aab38e98d7ee4608a8c70bf74c4d..de712e5286137c297de8270d3396b8daa9a93c66:/doc/contributing.de.texi diff --git a/doc/contributing.de.texi b/doc/contributing.de.texi index 9997092a9e..6a999baece 100644 --- a/doc/contributing.de.texi +++ b/doc/contributing.de.texi @@ -6,7 +6,7 @@ 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}). +Erstellung von Paketen (siehe @ref{Paketrichtlinien}). @cindex Verhaltensregeln, für Mitwirkende @cindex Verhaltenskodex für Mitwirkende @@ -27,6 +27,7 @@ beliebigen Namen oder ein Pseudonym ihrer Wahl verwenden. * 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 @@ -42,8 +43,8 @@ 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}). +Installationsanweisungen genannten Paketen weitere nötig (siehe +@ref{Voraussetzungen}). @itemize @item @url{http://gnu.org/software/autoconf/, GNU Autoconf}; @@ -63,7 +64,7 @@ an Guix zu arbeiten: 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: @@ -72,7 +73,7 @@ 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 +Erstellungssystems mit Autoconf und Automake zu erzeugen. Möglicherweise erhalten Sie eine Fehlermeldung wie diese: @example @@ -92,18 +93,18 @@ Befehl aufrufen: 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 @@ -114,15 +115,17 @@ 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; 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 @@ -141,8 +144,8 @@ $ ./pre-inst-env guile -c '(use-modules (guix utils)) (pk (%current-system))' @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 @@ -164,28 +167,33 @@ 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}. -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. @@ -218,12 +226,14 @@ umzuschreiben. Vielleicht möchten Sie das Schnipselverzeichnis zu Ihrer (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 @@ -233,10 +243,491 @@ Auslöse-Zeichenketten einfügen, die alle auf @code{...} enden, was selbst 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 , +@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. @@ -299,7 +790,7 @@ Ein paar in Guix eingeführte Sonderformen, wie zum Beispiel das 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- @@ -352,36 +843,64 @@ 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}). +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, @@ -399,22 +918,19 @@ einzuspielen, die aber 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. +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 . @cindex Branching-Strategie @cindex Neuerstellungs-Zeitplan @@ -428,9 +944,9 @@ statt, nach ungefähr diesen Regeln: @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 @@ -438,17 +954,20 @@ beeinträchtigende Änderungen umfassen). Dieser Branch wird planmäßig in @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 @@ -458,7 +977,7 @@ 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}): +hintereinander auf Ihrer Maschine erstellen (siehe @ref{Aufruf von guix build}): @example guix build --rounds=2 mein-paket @@ -468,13 +987,13 @@ 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 +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. @@ -483,7 +1002,7 @@ Betriebssystem-Kernel — zum Beispiel, indem @code{uname} oder 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 @@ -497,20 +1016,22 @@ 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}). +@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 @@ -526,9 +1047,9 @@ Sie eine E-Mail an @email{@var{NNN}-done@@debbugs.gnu.org} senden. @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.