@node Mitwirken @chapter Mitwirken Dieses Projekt basiert auf Kooperation, daher benötigen wir Ihre Hilfe, um es wachsen zu lassen! Bitte kontaktieren Sie uns auf @email{guix-devel@@gnu.org} und @code{#guix} im Freenode-IRC-Netzwerk. Wir freuen uns auf Ihre Ideen, Fehlerberichte, Patches und alles, was hilfreich für das Projekt sein könnte. Besonders willkommen ist Hilfe bei der Erstellung von Paketen (siehe @ref{Paketrichtlinien}). @cindex Verhaltensregeln, für Mitwirkende @cindex Verhaltenskodex für Mitwirkende Wir möchten eine angenehme, freundliche und von Belästigungen freie Umgebung bereitstellen, so dass jeder Beiträge nach seinen Fähigkeiten leisten kann. Zu diesem Zweck verwendet unser Projekt einen »Verhaltenskodex für Mitwirkende«, der von @url{http://contributor-covenant.org/} übernommen wurde. Eine übersetzte Fassung finden Sie auf @url{https://www.contributor-covenant.org/de/version/1/4/code-of-conduct} sowie eine mitgelieferte, englische Fassung in der Datei @file{CODE-OF-CONDUCT} im Quellbaum. Von Mitwirkenden wird nicht erwartet, dass sie in Patches oder in der Online-Kommunikation ihre echten Namen preisgeben. Sie können einen beliebigen Namen oder ein Pseudonym ihrer Wahl verwenden. @menu * Erstellung aus dem Git:: Das Neueste und Beste. * Guix vor der Installation ausführen:: Hacker-Tricks. * Perfekt eingerichtet:: Die richtigen Werkzeuge. * Paketrichtlinien:: Die Distribution wachsen lassen. * Code-Stil:: Wie Mitwirkende hygienisch arbeiten. * Einreichen von Patches:: Teilen Sie Ihre Arbeit. @end menu @node Erstellung aus dem Git @section Erstellung aus dem Git Wenn Sie an Guix selbst hacken wollen, ist es empfehlenswert, dass Sie die neueste Version aus dem Git-Softwarebestand verwenden: @example git clone https://git.savannah.gnu.org/git/guix.git @end example Wenn Sie Guix aus einem Checkout erstellen, sind außer den bereits in den Installationsanweisungen genannten Paketen weitere nötig (siehe @ref{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 @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: @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 erzeugen. 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 @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 siehe @ref{Der Store}). Zum Schluss müssen Sie @code{make check} aufrufen, um die Tests auszuführen (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 @section Guix vor der Installation ausführen Um eine gesunde Arbeitsumgebung zu erhalten, ist es hilfreich, die im lokalen Quellbaum vorgenommenen Änderungen zunächst zu testen, ohne sie tatsächlich zu installieren. So können Sie zwischen Ihrem Endnutzer-»Straßenanzug« und Ihrem »Faschingskostüm« unterscheiden. Zu diesem Zweck können alle Befehlszeilenwerkzeuge auch schon benutzt werden, ohne dass Sie @code{make install} laufen lassen. Dazu müssen Sie sich in einer Umgebung befinden, in der alle Abhängigkeiten von Guix verfügbar sind (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 $ ./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 (siehe @ref{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} (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 (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 (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. @lisp ;; @r{Angenommen das Guix-Checkout ist in ~/src/guix.} (with-eval-after-load 'geiser-guile (add-to-list 'geiser-guile-load-path "~/src/guix")) @end lisp Um den Code tatsächlich zu bearbeiten, bietet Emacs schon einen netten Scheme-Modus. Aber Sie dürfen auch @url{http://www.emacswiki.org/emacs/ParEdit, Paredit} nicht verpassen. Es bietet Hilfsmittel, um direkt mit dem Syntaxbaum zu arbeiten, und kann so zum Beispiel einen S-Ausdruck hochheben oder ihn umhüllen, ihn verschlucken oder den nachfolgenden S-Ausdruck verwerfen, etc. @cindex Code-Schnipsel @cindex Vorlagen @cindex Tipparbeit sparen Wir bieten auch Vorlagen für häufige Git-Commit-Nachrichten und Paketdefinitionen im Verzeichnis @file{etc/snippets}. Diese Vorlagen können mit @url{http://joaotavora.github.io/yasnippet/, YASnippet} zusammen benutzt werden, um kurze Auslöse-Zeichenketten zu interaktiven Textschnipseln umzuschreiben. Vielleicht möchten Sie das Schnipselverzeichnis zu Ihrer @var{yas-snippet-dirs}-Variablen in Emacs hinzufügen. @lisp ;; @r{Angenommen das Guix-Checkout ist in ~/src/guix.} (with-eval-after-load 'yasnippet (add-to-list 'yas-snippet-dirs "~/src/guix/etc/snippets")) @end lisp Die Schnipsel für Commit-Nachrichten setzen @url{https://magit.vc/, Magit} voraus, um zum Commit vorgemerkte Dateien anzuzeigen. Wenn Sie eine Commit-Nachricht bearbeiten, können Sie @code{add} gefolgt von @kbd{TAB} eintippen, um eine Commit-Nachrichten-Vorlage für das Hinzufügen eines Pakets zu erhalten; tippen Sie @code{update} gefolgt von @kbd{TAB} ein, um eine Vorlage zum Aktualisieren eines Pakets zu bekommen; tippen Sie @code{https} gefolgt von @kbd{TAB} ein, um eine Vorlage zum Ändern der Homepage-URI eines Pakets auf HTTPS einzufügen. Das Hauptschnipsel für @code{scheme-mode} wird ausgelöst, indem Sie @code{package...} gefolgt von @kbd{TAB} eintippen. Dieses Snippet fügt auch die Auslöse-Zeichenkette @code{origin...} ein, die danach weiter umgeschrieben werden kann. Das @code{origin}-Schnipsel kann wiederum andere Auslöse-Zeichenketten einfügen, die alle auf @code{...} enden, was selbst wieder weiter umgeschrieben werden kann. @node Paketrichtlinien @section Paketrichtlinien @cindex 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 (siehe @ref{Top,,, standards, GNU Coding Standards}). Da diese aber nicht viel über Scheme zu sagen haben, folgen hier einige zusätzliche Regeln. @menu * Programmierparadigmen:: Wie Sie Ihre Elemente zusammenstellen. * Module:: Wo Sie Ihren Code unterbringen. * Datentypen und Mustervergleich:: Implementierung von Datenstrukturen. * Formatierung von Code:: Schreibkonventionen. @end menu @node Programmierparadigmen @subsection Programmierparadigmen Scheme-Code wird in Guix auf rein funktionale Weise geschrieben. Eine Ausnahme ist Code, der mit Ein- und Ausgabe zu tun hat, und Prozeduren, die grundlegende Konzepte implementieren, wie zum Beispiel die Prozedur @code{memoize}. @node Module @subsection Module Guile-Module, die beim Erstellen nutzbar sein sollen, müssen im Namensraum @code{(guix build @dots{})} leben. Sie dürfen auf keine anderen Guix- oder GNU-Module Bezug nehmen. Jedoch ist es in Ordnung, wenn ein »wirtsseitiges« Modul ein erstellungsseitiges Modul benutzt. Module, die mit dem weiteren GNU-System zu tun haben, sollten im Namensraum @code{(gnu @dots{})} und nicht in @code{(guix @dots{})} stehen. @node Datentypen und Mustervergleich @subsection Datentypen und Mustervergleich Im klassischen Lisp gibt es die Tendenz, Listen zur Darstellung von allem zu benutzen, und diese dann »händisch« zu durchlaufen mit @code{car}, @code{cdr}, @code{cadr} und so weiter. Dieser Stil ist aus verschiedenen Gründen problematisch, insbesondere wegen der Tatsache, dass er schwer zu lesen, schnell fehlerbehaftet und ein Hindernis beim Melden von Typfehlern ist. Guix-Code sollte angemessene Datentypen definieren (zum Beispiel mit @code{define-record-type*}) statt Listen zu missbrauchen. Außerdem sollte er das @code{(ice-9 match)}-Modul von Guile zum Mustervergleich benutzen, besonders mit Listen. @node Formatierung von Code @subsection Formatierung von Code @cindex Formatierung von Code @cindex Code-Stil Beim Schreiben von Scheme-Code halten wir uns an die üblichen Gepflogenheiten unter Scheme-Programmierern. Im Allgemeinen bedeutet das, dass wir uns an @url{http://mumble.net/~campbell/scheme/style.txt, Riastradh's Lisp Style Rules} halten. Es hat sich ergeben, dass dieses Dokument auch die Konventionen beschreibt, die im Code von Guile hauptsächlich verwendet werden. Es ist gut durchdacht und schön geschrieben, also lesen Sie es bitte. Ein paar in Guix eingeführte Sonderformen, wie zum Beispiel das @code{substitute*}-Makro, haben abweichende Regeln für die Einrückung. Diese sind in der Datei @file{.dir-locals.el} definiert, die Emacs automatisch benutzt. Beachten Sie auch, dass Emacs-Guix einen Modus namens @code{guix-devel-mode} bereitstellt, der Guix-Code richtig einrückt und hervorhebt (siehe @ref{Entwicklung,,, emacs-guix, The Emacs-Guix Reference Manual}). @cindex Einrückung, Code- @cindex Formatierung, Code- Falls Sie nicht Emacs verwenden, sollten Sie sicherstellen, dass Ihr Editor diese Regeln kennt. Um eine Paketdefinition automatisch einzurücken, können Sie auch Folgendes ausführen: @example ./etc/indent-code.el gnu/packages/@var{Datei}.scm @var{Paket} @end example @noindent Dadurch wird die Definition von @var{Paket} in @file{gnu/packages/@var{Datei}.scm} automatisch eingerückt, indem Emacs im Batch-Modus läuft. Um die Einrückung in einer gesamten Datei vorzunehmen, lassen Sie das zweite Argument weg: @example ./etc/indent-code.el gnu/services/@var{Datei}.scm @end example @cindex Vim, zum Editieren von Scheme-Code Wenn Sie Code mit Vim bearbeiten, empfehlen wir, dass Sie @code{:set autoindent} ausführen, damit Ihr Code automatisch eingerückt wird, während Sie ihn schreiben. Außerdem könnte Ihnen @uref{https://www.vim.org/scripts/script.php?script_id=3998, @code{paredit.vim}} dabei helfen, mit all diesen Klammern fertigzuwerden. Wir fordern von allen Prozeduren auf oberster Ebene, dass sie über einen Docstring verfügen. Diese Voraussetzung kann jedoch bei einfachen, privaten Prozeduren im Namensraum @code{(guix build @dots{})} aufgeweicht werden. Prozeduren sollten nicht mehr als vier positionsbestimmte Parameter haben. Benutzen Sie Schlüsselwort-Parameter für Prozeduren, die mehr als vier Parameter entgegennehmen. @node Einreichen von Patches @section Einreichen von Patches Die Entwicklung wird mit Hilfe des verteilten Versionskontrollsystems Git durchgeführt. Daher ist eine ständige Verbindung zum Repository nicht unbedingt erforderlich. Wir begrüßen Beiträge in Form von Patches, die mittels @code{git format-patch} erstellt und an die Mailingliste @email{guix-patches@@gnu.org} geschickt werden. Diese Mailing-Liste setzt auf einer Debbugs-Instanz auf, die zugänglich ist unter @uref{https://bugs.gnu.org/guix-patches}, wodurch wir den Überblick über Eingereichtes behalten können. Jede an diese Mailing-Liste gesendete Nachricht bekommt eine neue Folgenummer zugewiesen, so dass man eine Folge-Email zur Einreichung an @code{@var{NNN}@@debbugs.gnu.org} senden kann, wobei @var{NNN} für die Folgenummer steht (siehe @ref{Senden einer Patch-Reihe}). 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 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 @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 (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, die bereits in separaten Paketen zur Verfügung steht. Manchmal enthalten Pakete Kopien des Quellcodes ihrer Abhängigkeiten, um Nutzern die Installation zu erleichtern. Als eine Distribution wollen wir jedoch sicherstellen, dass solche Pakete die schon in der Distribution verfügbare Fassung benutzen, sofern es eine gibt. Dadurch wird sowohl der Ressourcenverbrauch optimiert (die Abhängigkeit wird so nur einmal erstellt und gespeichert) als auch der Distribution die Möglichkeit gegeben, ergänzende Änderungen durchzuführen, um beispielsweise Sicherheitsaktualisierungen für ein bestimmtes Paket an nur einem Ort einzuspielen, die aber das gesamte System betreffen — gebündelt mitgelieferte Kopien würden dies verhindern. @item 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 (siehe @ref{Aufruf von guix refresh}). @c See . @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 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 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 (siehe @ref{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} (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. @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} (siehe @ref{Formatierung von Code}). @item 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 (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 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.