doc: Add German translation.
* doc/contributing.de.texi: New file. * doc/guix.de.texi: New file * doc/local.mk (TRANSLATED_INFO): Add them. (info_TEXINFOS): Add guix.de.texi. * po/doc/guix-manual.de.po: New file. * po/doc/local.mk (EXTRA_DIST): Add it. * doc/guix.texi: Document the German translation.
This commit is contained in:
Julien Lepiller
parent
d7ca1899aa
commit
1e40e70bfe
|
|
@ -0,0 +1,537 @@
|
|||
@node Mitwirken
|
||||
@chapter Mitwirken
|
||||
|
||||
Dieses Projekt basiert auf Kooperation, daher benötigen wir Ihre Hilfe, um
|
||||
es wachsen zu lassen! Bitte kontaktieren Sie uns auf
|
||||
@email{guix-devel@@gnu.org} und @code{#guix} im Freenode-IRC-Netzwerk. Wir
|
||||
freuen uns auf Ihre Ideen, Fehlerberichte, Patches und alles, was hilfreich
|
||||
für das Projekt ist. Besonders willkommen ist Hilfe bei der Erstellung von
|
||||
Paketen (@pxref{Paketrichtlinien}).
|
||||
|
||||
@cindex Verhaltensregeln, für Mitwirkende
|
||||
@cindex Verhaltenskodex für Mitwirkende
|
||||
Wir möchten eine angenehme, freundliche und von Belästigungen freie Umgebung
|
||||
bereitstellen, so dass jeder Beiträge nach seinen Fähigkeiten leisten
|
||||
kann. Zu diesem Zweck verwendet unser Projekt einen »Verhaltenskodex für
|
||||
Mitwirkende«, der von @url{http://contributor-covenant.org/} übernommen
|
||||
wurde. Eine übersetzte Fassung finden Sie auf
|
||||
@url{https://www.contributor-covenant.org/de/version/1/4/code-of-conduct}
|
||||
sowie eine mitgelieferte, englische Fassung in der Datei
|
||||
@file{CODE-OF-CONDUCT} im Quellbaum.
|
||||
|
||||
Von Mitwirkenden wird nicht erwartet, dass sie in Patches oder in der
|
||||
Online-Kommunikation ihre echten Namen preisgeben. Sie können einen
|
||||
beliebigen Namen oder ein Pseudonym ihrer Wahl verwenden.
|
||||
|
||||
@menu
|
||||
* Erstellung aus dem Git:: Das Neueste und Beste.
|
||||
* Guix vor der Installation ausführen:: Hacker-Tricks.
|
||||
* Perfekt eingerichtet:: Die richtigen Werkzeuge.
|
||||
* Code-Stil:: Wie Mitwirkende hygienisch arbeiten.
|
||||
* Einreichen von Patches:: Teilen Sie Ihre Arbeit.
|
||||
@end menu
|
||||
|
||||
@node Erstellung aus dem Git
|
||||
@section Erstellung aus dem Git
|
||||
|
||||
Wenn Sie an Guix selbst hacken wollen, ist es empfehlenswert, dass Sie die
|
||||
neueste Version aus dem Git-Softwarebestand verwenden:
|
||||
|
||||
@example
|
||||
git clone https://git.savannah.gnu.org/git/guix.git
|
||||
@end example
|
||||
|
||||
Wenn Sie Guix aus einem Checkout erstellen, sind außer den bereits in den
|
||||
Installationsanweisungen genannten Paketen weitere nötig
|
||||
(@pxref{Voraussetzungen}).
|
||||
|
||||
@itemize
|
||||
@item @url{http://gnu.org/software/autoconf/, GNU Autoconf};
|
||||
@item @url{http://gnu.org/software/automake/, GNU Automake};
|
||||
@item @url{http://gnu.org/software/gettext/, GNU Gettext};
|
||||
@item @url{http://gnu.org/software/texinfo/, GNU Texinfo};
|
||||
@item @url{http://www.graphviz.org/, Graphviz};
|
||||
@item @url{http://www.gnu.org/software/help2man/, GNU Help2man (optional)}.
|
||||
@end itemize
|
||||
|
||||
Der einfachste Weg, eine Entwicklungsumgebung für Guix einzurichten, ist
|
||||
natürlich, Guix zu benutzen! Der folgende Befehl startet eine neue Shell, in
|
||||
der alle Abhängigkeiten und Umgebungsvariablen bereits eingerichtet sind, um
|
||||
an Guix zu arbeiten:
|
||||
|
||||
@example
|
||||
guix environment guix
|
||||
@end example
|
||||
|
||||
In @xref{Aufruf von guix environment} finden Sie weitere Informationen zu
|
||||
diesem Befehl. Zusätzliche Abhängigkeiten können mit @option{--ad-hoc}
|
||||
hinzugefügt werden:
|
||||
|
||||
@example
|
||||
guix environment guix --ad-hoc help2man git strace
|
||||
@end example
|
||||
|
||||
Führen Sie @command{./bootstrap} aus, um die Infrastruktur des
|
||||
Erstellungssystems mit Autoconf und Automake zu erstellen. Möglicherweise
|
||||
erhalten Sie eine Fehlermeldung wie diese:
|
||||
|
||||
@example
|
||||
configure.ac:46: error: possibly undefined macro: PKG_CHECK_MODULES
|
||||
@end example
|
||||
|
||||
@noindent
|
||||
Das bedeutet wahrscheinlich, dass Autoconf @file{pkg.m4} nicht finden
|
||||
konnte, welches von pkg-config bereitgestellt wird. Stellen Sie sicher, dass
|
||||
@file{pkg.m4} verfügbar ist. Gleiches gilt für den von Guile
|
||||
bereitgestellten Makrosatz @file{guile.m4}. Wenn Sie beispielsweise Automake
|
||||
in @file{/usr/local} installiert haben, würde in @file{/usr/share} nicht
|
||||
nach @file{.m4}-Dateien geschaut. In einem solchen Fall müssen Sie folgenden
|
||||
Befehl aufrufen:
|
||||
|
||||
@example
|
||||
export ACLOCAL_PATH=/usr/share/aclocal
|
||||
@end example
|
||||
|
||||
In @xref{Macro Search Path,,, automake, The GNU Automake Manual} finden Sie
|
||||
weitere Informationen.
|
||||
|
||||
Dann führen Sie wie gewohnt @command{./configure} aus. Achten Sie darauf,
|
||||
@code{--localstatedir=@var{Verzeichnis}} zu übergeben, wobei
|
||||
@var{Verzeichnis} der von Ihrer aktuellen Installation verwendete
|
||||
@code{localstatedir}-Wert ist (weitere Informationen auf @pxref{Der Store}).
|
||||
|
||||
Zum Schluss müssen Sie @code{make check} aufrufen, um die Tests auszuführen
|
||||
(@pxref{Die Testsuite laufen lassen}). Falls etwas fehlschlägt, werfen Sie einen
|
||||
Blick auf die Installationsanweisungen (@pxref{Installation}) oder senden
|
||||
Sie eine E-Mail an @email{guix-devel@@gnu.org, Mailingliste}.
|
||||
|
||||
|
||||
@node Guix vor der Installation ausführen
|
||||
@section Guix vor der Installation ausführen
|
||||
|
||||
Um eine gesunde Arbeitsumgebung zu behalten, ist es hilfreich, die im
|
||||
lokalen Quellbaum vorgenommenen Änderungen zunächst zu testen, ohne sie
|
||||
tatsächlich zu installieren. So können Sie zwischen Ihrem
|
||||
Endnutzer-»Straßenanzug« und Ihrem »Faschingskostüm« unterscheiden.
|
||||
|
||||
To that end, all the command-line tools can be used even if you have not run
|
||||
@code{make install}. To do that, you first need to have an environment with
|
||||
all the dependencies available (@pxref{Erstellung aus dem Git}), and then simply
|
||||
prefix each command with @command{./pre-inst-env} (the @file{pre-inst-env}
|
||||
script lives in the top build tree of Guix), as in@footnote{The @option{-E}
|
||||
flag to @command{sudo} guarantees that @code{GUILE_LOAD_PATH} is correctly
|
||||
set such that @command{guix-daemon} and the tools it uses can find the Guile
|
||||
modules they need.}:
|
||||
|
||||
@example
|
||||
$ sudo -E ./pre-inst-env guix-daemon --build-users-group=guixbuild
|
||||
$ ./pre-inst-env guix build hello
|
||||
@end example
|
||||
|
||||
@noindent
|
||||
Entsprechend, um eine Guile-Sitzung zu öffnen, die die Guix-Module benutzt:
|
||||
|
||||
@example
|
||||
$ ./pre-inst-env guile -c '(use-modules (guix utils)) (pk (%current-system))'
|
||||
|
||||
;;; ("x86_64-linux")
|
||||
@end example
|
||||
|
||||
@noindent
|
||||
@cindex REPL
|
||||
@cindex Lese-Auswerten-Schreiben-Schleife
|
||||
@dots{} und auf einer REPL (@pxref{Using Guile Interactively,,, guile, Guile
|
||||
Reference Manual}):
|
||||
|
||||
@example
|
||||
$ ./pre-inst-env guile
|
||||
scheme@@(guile-user)> ,use(guix)
|
||||
scheme@@(guile-user)> ,use(gnu)
|
||||
scheme@@(guile-user)> (define snakes
|
||||
(fold-packages
|
||||
(lambda (package lst)
|
||||
(if (string-prefix? "python"
|
||||
(package-name package))
|
||||
(cons package lst)
|
||||
lst))
|
||||
'()))
|
||||
scheme@@(guile-user)> (length snakes)
|
||||
$1 = 361
|
||||
@end example
|
||||
|
||||
Das @command{pre-inst-env}-Skript richtet alle Umgebungsvariablen ein, die
|
||||
nötig sind, um dies zu ermöglichen, einschließlich @env{PATH} und
|
||||
@env{GUILE_LOAD_PATH}.
|
||||
|
||||
Beachten Sie, dass @command{./pre-inst-env guix pull} den lokalen Quellbaum
|
||||
@emph{nicht} aktualisiert; es aktualisiert lediglich die symbolische
|
||||
Verknüpfung @file{~/.config/guix/current} (@pxref{Aufruf von guix pull}). Um
|
||||
Ihren lokalen Quellbaum zu aktualisieren, müssen Sie stattdessen
|
||||
@command{git pull} benutzen.
|
||||
|
||||
|
||||
@node Perfekt eingerichtet
|
||||
@section Perfekt eingerichtet
|
||||
|
||||
Um perfekt für das Hacken an Guix eingerichtet zu sein, brauchen Sie an sich
|
||||
dasselbe wie um perfekt für das Hacken mit Guile (@pxref{Using Guile in
|
||||
Emacs,,, guile, Guile Reference Manual}). Zunächst brauchen Sie mehr als
|
||||
ein Textverarbeitungsprogramm, Sie brauchen
|
||||
@url{http://www.gnu.org/software/emacs, Emacs}, ermächtigt vom wunderbaren
|
||||
@url{http://nongnu.org/geiser/, Geiser}.
|
||||
|
||||
Geiser ermöglicht interaktive und inkrementelle Entwicklung aus Emacs
|
||||
heraus: Code kann in Puffern kompiliert und ausgewertet werden. Zugang zu
|
||||
Online-Dokumentation (Docstrings) steht ebenso zur Verfügung wie
|
||||
kontextabhängige Vervollständigung, @kbd{M-.} um zu einer Objektdefinition
|
||||
zu springen, eine REPL, um Ihren Code auszuprobieren, und mehr
|
||||
(@pxref{Einführung,,, geiser, Geiser User Manual}). Zur bequemen
|
||||
Guix-Entwicklung sollten Sie Guiles Ladepfad so ergänzen, dass die
|
||||
Quelldateien in Ihrem Checkout gefunden werden.
|
||||
|
||||
@lisp
|
||||
;; @r{Angenommen das Guix-Checkout ist in ~/src/guix.}
|
||||
(with-eval-after-load 'geiser-guile
|
||||
(add-to-list 'geiser-guile-load-path "~/src/guix"))
|
||||
@end lisp
|
||||
|
||||
Um den Code tatsächlich zu bearbeiten, bietet Emacs schon einen netten
|
||||
Scheme-Modus. Aber Sie dürfen auch
|
||||
@url{http://www.emacswiki.org/emacs/ParEdit, Paredit} nicht verpassen. Es
|
||||
bietet Hilfsmittel, um direkt mit dem Syntaxbaum zu arbeiten, und kann so
|
||||
zum Beispiel einen S-Ausdruck hochheben oder ihn umhüllen, ihn verschlucken
|
||||
oder den nachfolgenden S-Ausdruck verwerfen, etc.
|
||||
|
||||
@cindex Code-Schnipsel
|
||||
@cindex Vorlagen
|
||||
@cindex Tipparbeit sparen
|
||||
Wir bieten auch Vorlagen für häufige Git-Commit-Nachrichten und
|
||||
Paketdefinitionen im Verzeichnis @file{etc/snippets}. Diese Vorlagen können
|
||||
mit @url{http://joaotavora.github.io/yasnippet/, YASnippet} zusammen benutzt
|
||||
werden, um kurze Auslöse-Zeichenketten zu interaktiven Textschnipseln
|
||||
umzuschreiben. Vielleicht möchten Sie das Schnipselverzeichnis zu Ihrer
|
||||
@var{yas-snippet-dirs}-Variablen in Emacs hinzufügen.
|
||||
|
||||
@lisp
|
||||
;; @r{Angenommen das Guix-Checkout ist in ~/src/guix.}
|
||||
(with-eval-after-load 'yasnippet
|
||||
(add-to-list 'yas-snippet-dirs "~/src/guix/etc/snippets"))
|
||||
@end lisp
|
||||
|
||||
The commit message snippets depend on @url{https://magit.vc/, Magit} to
|
||||
display staged files. When editing a commit message type @code{add}
|
||||
followed by @kbd{TAB} to insert a commit message template for adding a
|
||||
package; type @code{update} followed by @kbd{TAB} to insert a template for
|
||||
updating a package; type @code{https} followed by @kbd{TAB} to insert a
|
||||
template for changing the home page URI of a package to HTTPS.
|
||||
|
||||
Das Hauptschnipsel für @code{scheme-mode} wird ausgelöst, indem Sie
|
||||
@code{package...} gefolgt von @kbd{TAB} eintippen. Dieses Snippet fügt auch
|
||||
die Auslöse-Zeichenkette @code{origin...} ein, die danach weiter
|
||||
umgeschrieben werden kann. Das @code{origin}-Schnipsel kann wiederum andere
|
||||
Auslöse-Zeichenketten einfügen, die alle auf @code{...} enden, was selbst
|
||||
wieder weiter umgeschrieben werden kann.
|
||||
|
||||
|
||||
@node Code-Stil
|
||||
@section Code-Stil
|
||||
|
||||
Im Allgemeinen folgt unser Code den GNU Coding Standards (@pxref{Top,,,
|
||||
standards, GNU Coding Standards}). Da diese aber nicht viel über Scheme zu
|
||||
sagen haben, folgen hier einige zusätzliche Regeln.
|
||||
|
||||
@menu
|
||||
* Programmierparadigmen:: Wie Sie Ihre Elemente zusammenstellen.
|
||||
* Module:: Wo Sie Ihren Code unterbringen.
|
||||
* Datentypen und Mustervergleich:: Implementierung von Datenstrukturen.
|
||||
* Formatierung von Code:: Schreibkonventionen.
|
||||
@end menu
|
||||
|
||||
@node Programmierparadigmen
|
||||
@subsection Programmierparadigmen
|
||||
|
||||
Scheme-Code wird in Guix auf rein funktionale Weise geschrieben. Eine
|
||||
Ausnahme ist Code, der mit Ein- und Ausgabe zu tun hat, und Prozeduren, die
|
||||
grundlegende Konzepte implementieren, wie zum Beispiel die Prozedur
|
||||
@code{memoize}.
|
||||
|
||||
@node Module
|
||||
@subsection Module
|
||||
|
||||
Guile-Module, die beim Erstellen nutzbar sein sollen, müssen im Namensraum
|
||||
@code{(guix build @dots{})} leben. Sie dürfen auf keine anderen Guix- oder
|
||||
GNU-Modules Bezug nehmen. Jedoch ist es in Ordnung, wenn ein »wirtsseitiges«
|
||||
Modul ein erstellungsseitiges Modul benutzt.
|
||||
|
||||
Module, die mit dem weiteren GNU-System zu tun haben, sollten im Namensraum
|
||||
@code{(gnu @dots{})} und nicht in @code{(guix @dots{})} stehen.
|
||||
|
||||
@node Datentypen und Mustervergleich
|
||||
@subsection Datentypen und Mustervergleich
|
||||
|
||||
Im klassischen Lisp gibt es die Tendenz, Listen zur Darstellung von allem zu
|
||||
benutzen, und diese dann »händisch« zu durchlaufen mit @code{car},
|
||||
@code{cdr}, @code{cadr} und so weiter. Dieser Stil ist aus verschiedenen
|
||||
Gründen problematisch, insbesondere wegen der Tatsache, dass er schwer zu
|
||||
lesen, schnell fehlerbehaftet und ein Hindernis beim Melden von Typfehlern
|
||||
ist.
|
||||
|
||||
Guix-Code sollte angemessene Datentypen definieren (zum Beispiel mit
|
||||
@code{define-record-type*}) statt Listen zu missbrauchen. Außerdem sollte er
|
||||
das @code{(ice-9 match)}-Modul von Guile zum Mustervergleich benutzen,
|
||||
besonders mit Listen.
|
||||
|
||||
@node Formatierung von Code
|
||||
@subsection Formatierung von Code
|
||||
|
||||
@cindex Formatierung von Code
|
||||
@cindex Code-Stil
|
||||
Beim Schreiben von Scheme-Code halten wir uns an die üblichen
|
||||
Gepflogenheiten unter Scheme-Programmierern. Im Allgemeinen bedeutet das,
|
||||
dass wir uns an @url{http://mumble.net/~campbell/scheme/style.txt,
|
||||
Riastradh's Lisp Style Rules} halten. Es hat sich ergeben, dass dieses
|
||||
Dokument auch die Konventionen beschreibt, die im Code von Guile
|
||||
hauptsächlich verwendet werden. Es ist gut durchdacht und schön geschrieben,
|
||||
also lesen Sie es bitte.
|
||||
|
||||
Ein paar in Guix eingeführte Sonderformen, wie zum Beispiel das
|
||||
@code{substitute*}-Makro, haben abweichende Regeln für die Einrückung. Diese
|
||||
sind in der Datei @file{.dir-locals.el} definiert, die Emacs automatisch
|
||||
benutzt. Beachten Sie auch, dass Emacs-Guix einen Modus namens
|
||||
@code{guix-devel-mode} bereitstellt, der Guix-Code richtig einrückt und
|
||||
hervorhebt (@pxref{Development,,, emacs-guix, The Emacs-Guix Reference
|
||||
Manual}).
|
||||
|
||||
@cindex Einrückung, Code-
|
||||
@cindex Formatierung, Code-
|
||||
Falls Sie nicht Emacs verwenden, sollten Sie sicherstellen, dass Ihr Editor
|
||||
diese Regeln kennt. Um eine Paketdefinition automatisch einzurücken, können
|
||||
Sie auch Folgendes ausführen:
|
||||
|
||||
@example
|
||||
./etc/indent-code.el gnu/packages/@var{Datei}.scm @var{Paket}
|
||||
@end example
|
||||
|
||||
@noindent
|
||||
Dadurch wird die Definition von @var{Paket} in
|
||||
@file{gnu/packages/@var{Datei}.scm} automatisch eingerückt, indem Emacs im
|
||||
Batch-Modus läuft. Um die Einrückung in einer gesamten Datei vorzunehmen,
|
||||
lassen Sie das zweite Argument weg:
|
||||
|
||||
@example
|
||||
./etc/indent-code.el gnu/services/@var{Datei}.scm
|
||||
@end example
|
||||
|
||||
@cindex Vim, zum Editieren von Scheme-Code
|
||||
Wenn Sie mit Code mit Vim bearbeiten, empfehlen wir, dass Sie @code{:set
|
||||
autoindent} ausführen, damit Ihr Code automatisch eingerückt wird, während
|
||||
Sie ihn schreiben. Außerdem könnte Ihnen
|
||||
@uref{https://www.vim.org/scripts/script.php?script_id=3998,
|
||||
@code{paredit.vim}} dabei helfen, mit all diesen Klammern fertigzuwerden.
|
||||
|
||||
Wir fordern von allen Prozeduren auf oberster Ebene, dass sie über einen
|
||||
Docstring verfügen. Diese Voraussetzung kann jedoch bei einfachen, privaten
|
||||
Prozeduren im Namensraum @code{(guix build @dots{})} aufgeweicht werden.
|
||||
|
||||
Prozeduren sollten nicht mehr als vier positionsbestimmte Parameter
|
||||
haben. Benutzen Sie Schlüsselwort-Parameter für Prozeduren, die mehr als
|
||||
vier Parameter entgegennehmen.
|
||||
|
||||
|
||||
@node Einreichen von Patches
|
||||
@section Einreichen von Patches
|
||||
|
||||
Die Entwicklung wird mit Hilfe des verteilten Versionskontrollsystems Git
|
||||
durchgeführt. Daher ist eine ständige Verbindung zum Repository nicht
|
||||
unbedingt erforderlich. Wir begrüßen Beiträge in Form von Patches, die
|
||||
mittels @code{git format-patch} erstellt und an die Mailingliste
|
||||
@email{guix-patches@@gnu.org} geschickt werden.
|
||||
|
||||
Diese Mailing-Liste setzt auf einer Debbugs-Instanz auf, die zugänglich ist
|
||||
unter @uref{https://bugs.gnu.org/guix-patches}, wodurch wir den Überblick
|
||||
über Eingereichtes behalten können. Jede an diese Mailing-Liste gesendete
|
||||
Nachricht bekommt eine neue Folgenummer zugewiesen, so dass man eine
|
||||
Folge-Email zur Einreichung an @code{@var{NNN}@@debbugs.gnu.org} senden
|
||||
kann, wobei @var{NNN} für die Folgenummer steht (@pxref{Senden einer Patch-Reihe}).
|
||||
|
||||
Bitte schreiben Sie Commit-Logs im ChangeLog-Format (@pxref{Change Logs,,,
|
||||
standards, GNU Coding Standards}); dazu finden Sie Beispiele unter den
|
||||
bisherigen Commits.
|
||||
|
||||
Bevor Sie einen Patch einreichen, der eine Paketdefinition hinzufügt oder
|
||||
verändert, gehen Sie bitte diese Prüfliste:
|
||||
|
||||
@enumerate
|
||||
@item
|
||||
Wenn die Autoren der verpackten Software eine kryptographische Signatur für
|
||||
den Tarball der Veröffentlichung anbieten, so machen Sie sich bitte die
|
||||
Mühe, die Echtheit des Archivs zu überprüfen. Für eine abgetrennte
|
||||
GPG-Signaturdatei würden Sie das mit dem Befehl @code{gpg --verify} tun.
|
||||
|
||||
@item
|
||||
Nehmen Sie sich die Zeit, eine passende Zusammenfassung und Beschreibung für
|
||||
das Paket zu verfassen. Unter @xref{Zusammenfassungen und Beschreibungen} finden Sie
|
||||
dazu einige Richtlinien.
|
||||
|
||||
@item
|
||||
Verwenden Sie @code{guix lint @var{Paket}}, wobei @var{Paket} das neue oder
|
||||
geänderte Paket bezeichnet, und beheben Sie alle gemeldeten Fehler
|
||||
(@pxref{Aufruf von guix lint}).
|
||||
|
||||
@item
|
||||
Stellen Sie sicher, dass das Paket auf Ihrer Plattform erstellt werden kann,
|
||||
indem Sie @code{guix build @var{Paket}} ausführen.
|
||||
|
||||
@item
|
||||
@cindex gebündelt
|
||||
Achten Sie darauf, dass im Paket keine Software gebündelt mitgeliefert wird,
|
||||
die bereits in separaten Paketen zur Verfügung steht.
|
||||
|
||||
Manchmal enthalten Pakete Kopien des Quellcodes ihrer Abhängigkeiten, um
|
||||
Nutzern die Installation zu erleichtern. Als eine Distribution wollen wir
|
||||
jedoch sicherstellen, dass für solche Pakete die schon in der Distribution
|
||||
verfügbare Fassung benutzen, sofern es eine gibt. Dadurch wird sowohl der
|
||||
Ressourcenverbrauch optimiert (die Abhängigkeit wird so nur einmal erstellt
|
||||
und gespeichert) als auch der Distribution die Möglichkeit gegeben,
|
||||
ergänzende Änderungen durchzuführen, um beispielsweise
|
||||
Sicherheitsaktualisierungen für ein bestimmtes Paket an nur einem Ort
|
||||
einzuspielen, die das gesamte System betreffen — gebündelt mitgelieferte
|
||||
Kopien würden dies verhindern.
|
||||
|
||||
@item
|
||||
Schauen Sie sich das von @command{guix size} ausgegebene Profil an
|
||||
(@pxref{Aufruf von guix size}). Dadurch können Sie Referenzen auf andere
|
||||
Pakete finden, die ungewollt vorhanden sind. Dies kann auch dabei helfen, zu
|
||||
entscheiden, ob das Paket aufgespalten werden sollte (@pxref{Pakete mit mehreren Ausgaben.}) und welche optionalen Abhängigkeiten verwendet werden
|
||||
sollten.
|
||||
|
||||
@item
|
||||
Achten Sie bei wichtigen Änderungen darauf, dass abhängige Pakete (falls
|
||||
vorhanden) nicht von der Änderung beeinträchtigt werden; @code{guix refresh
|
||||
--list-dependent @var{Paket}} hilft Ihnen dabei (@pxref{Aufruf von guix refresh}).
|
||||
|
||||
@c ===========================================================================
|
||||
@c
|
||||
@c This file was generated with po4a. Translate the source file.
|
||||
@c
|
||||
@c ===========================================================================
|
||||
@c See <https://lists.gnu.org/archive/html/guix-devel/2016-10/msg00933.html>.
|
||||
@cindex Branching-Strategie
|
||||
@cindex Neuerstellungs-Zeitplan
|
||||
Je nachdem, wieviele abhängige Pakete es gibt, und entsprechend wieviele
|
||||
Neuerstellungen dadurch nötig würden, finden Commits auf anderen Branches
|
||||
statt, nach ungefähr diesen Regeln:
|
||||
|
||||
@table @asis
|
||||
@item 300 abhängige Pakete oder weniger
|
||||
@code{master}-Branch (störfreie Änderungen).
|
||||
|
||||
@item zwischen 300 und 1200 abhängige Pakete
|
||||
@code{staging}-Branch (störfreie Änderungen). Dieser Branch wird circa alle
|
||||
3 Wochen in @code{master} gemerget. Themenbezogene Änderungen (z.B. eine
|
||||
Aktualisierung der GNOME-Plattform) können stattdessen auch auf einem
|
||||
eigenen Branch umgesetzt werden (wie @code{gnome-updates}).
|
||||
|
||||
@item mehr als 1200 abhängige Pakete
|
||||
@code{core-updates}-Branch (kann auch größere und womöglich andere Software
|
||||
beeinträchtigende Änderungen umfassen). Dieser Branch wird planmäßig in
|
||||
@code{master} alle 2,5 Monate oder so gemerget.
|
||||
@end table
|
||||
|
||||
All diese Branches werden kontinuierlich
|
||||
@uref{https://hydra.gnu.org/project/gnu, auf unserer Build-Farm} erstellt
|
||||
und in @code{master} gemerget, sobald alles erfolgreich erstellt worden
|
||||
ist. Dadurch können wir Probleme beheben, bevor sie bei Nutzern auftreten,
|
||||
und zudem das Zeitfenster, während dessen noch keine vorerstellten
|
||||
Binärdateien verfügbar sind, verkürzen.
|
||||
|
||||
@c TODO: It would be good with badges on the website that tracks these
|
||||
@c branches. Or maybe even a status page.
|
||||
Im Allgemeinen werden Branches außer @code{master} als @emph{unveränderlich}
|
||||
angesehen, wenn sie kürzlich ausgewertet wurden oder ein entsprechender
|
||||
@code{-next}-Branch existiert. Bitte fragen Sie auf der Mailing-Liste oder
|
||||
IRC, wenn Sie sich nicht sicher sind, wo ein Patch eingespielt werden
|
||||
sollte.
|
||||
|
||||
@item
|
||||
@cindex Determinismus, von Erstellungsprozessen
|
||||
@cindex Reproduzierbare Erstellungen, Überprüfung
|
||||
Überprüfen Sie, ob der Erstellungsprozess deterministisch ist. Dazu prüfen
|
||||
Sie typischerweise, ob eine unabhängige Erstellung des Pakets genau dasselbe
|
||||
Ergebnis wie Ihre Erstellung hat, Bit für Bit.
|
||||
|
||||
Dies können Sie leicht tun, indem Sie dasselbe Paket mehrere Male
|
||||
hintereinander auf Ihrer Maschine erstellen (@pxref{Aufruf von guix build}):
|
||||
|
||||
@example
|
||||
guix build --rounds=2 mein-paket
|
||||
@end example
|
||||
|
||||
Dies reicht aus, um eine ganze Klasse häufiger Ursachen von
|
||||
Nichtdeterminismus zu finden, wie zum Beispiel Zeitstempel oder
|
||||
zufallsgenerierte Ausgaben im Ergebnis der Erstellung.
|
||||
|
||||
Eine weitere Möglichkeit ist, @command{guix challenge} (@pxref{Aufruf von guix challenge}) zu benutzen. Sie können es ausführen, sobald ein Paket commitet
|
||||
und von @code{hydra.gnu.org} erstellt wurde, um zu sehen, ob dort dasselbe
|
||||
Ergebnis wie bei Ihnen geliefert wurde. Noch besser: Finden Sie eine andere
|
||||
Maschine, die das Paket erstellen kann, und führen Sie @command{guix
|
||||
publish} aus. Da sich die entfernte Erstellungsmaschine wahrscheinlich von
|
||||
Ihrer unterscheidet, können Sie auf diese Weise Probleme durch
|
||||
Nichtdeterminismus erkennen, die mit der Hardware zu tun haben — zum
|
||||
Beispiel die Nutzung anderer Befehlssatzerweiterungen — oder mit dem
|
||||
Betriebssystem-Kernel — zum Beispiel, indem @code{uname} oder
|
||||
@file{/proc}-Dateien verwendet werden.
|
||||
|
||||
@item
|
||||
Beim Schreiben von Dokumentation achten Sie bitte auf eine
|
||||
geschlechtsneutrale Wortwahl, wenn Sie sich auf Personen beziehen, wie
|
||||
@uref{https://en.wikipedia.org/wiki/Singular_they, »they«@comma{}
|
||||
»their«@comma{} »them« im Singular}, und so weiter.
|
||||
|
||||
@item
|
||||
Stelllen Sie sicher, dass Ihr Patch nur einen Satz zusammengehöriger
|
||||
Änderungen umfasst. Das Zusammenfassen nicht zusammengehöriger Änderungen
|
||||
erschwert und bremst das Durchsehen Ihres Patches.
|
||||
|
||||
Beispiele für nicht zusammengehörige Änderungen sind das Hinzufügen mehrerer
|
||||
Pakete auf einmal, oder das Aktualisieren eines Pakets auf eine neue Version
|
||||
zusammen mit Fehlerbehebungen für das Paket.
|
||||
|
||||
@item
|
||||
Bitte befolgen Sie unsere Richtlinien für die Code-Formatierung, womöglich
|
||||
wollen Sie dies automatisch tun lassen durch das Skript
|
||||
@command{etc/indent-code.el} (@pxref{Formatierung von Code}).
|
||||
|
||||
@item
|
||||
When possible, use mirrors in the source URL (@pxref{Aufruf von guix download}). Use reliable URLs, not generated ones. For instance, GitHub
|
||||
archives are not necessarily identical from one generation to the next, so
|
||||
in this case it's often better to clone the repository. Don't use the
|
||||
@command{name} field in the URL: it is not very useful and if the name
|
||||
changes, the URL will probably be wrong.
|
||||
|
||||
@end enumerate
|
||||
|
||||
Bitte benutzen Sie @samp{[PATCH] @dots{}} als Betreff, wenn Sie einen Patch
|
||||
an die Mailing-Liste schicken. Sie können dazu Ihr E-mail-Programm oder den
|
||||
Befehl @command{git send-email} benutzen (@pxref{Senden einer Patch-Reihe}). Wir bevorzugen es, Patches als reine Textnachrichten zu erhalten,
|
||||
entweder eingebettet (inline) oder als MIME-Anhänge. Sie sind dazu
|
||||
angehalten, zu überprüfen, ob Ihr Mail-Programm solche Dinge wie
|
||||
Zeilenumbrüche oder die Einrückung verändert, wodurch die Patches womöglich
|
||||
nicht mehr funktionieren.
|
||||
|
||||
Wenn dadurch ein Fehler behoben wurde, schließen Sie bitte den Thread, indem
|
||||
Sie eine E-mail an @email{@var{NNN}-done@@debbugs.gnu.org} senden.
|
||||
|
||||
@unnumberedsubsec Senden einer Patch-Reihe
|
||||
@anchor{Senden einer Patch-Reihe}
|
||||
@cindex Patch-Reihe
|
||||
@cindex @code{git send-email}
|
||||
@cindex @code{git-send-email}
|
||||
|
||||
@c Debbugs bug: https://debbugs.gnu.org/db/15/15361.html
|
||||
Wenn Sie eine Patch-Reihe senden (z.B. mit @code{git send-email}), schicken
|
||||
Sie bitte als Erstes eine Nachricht an @email{guix-patches@@gnu.org} und
|
||||
dann nachfolgende Patches an @email{@var{NNN}@@debbugs.gnu.org}, um
|
||||
sicherzustellen, dass sie zusammen bearbeitet werden. Siehe
|
||||
@uref{https://debbugs.gnu.org/Advanced.html, die Debbugs-Dokumentation} für
|
||||
weitere Informationen.
|
||||
File diff suppressed because it is too large
Load Diff
|
|
@ -102,8 +102,9 @@ package management tool written for the GNU system.
|
|||
@c how to join your own translation team and how to report issues with the
|
||||
@c translation.
|
||||
This manual is also available in French (@pxref{Top,,, guix.fr, Manuel de
|
||||
référence de GNU Guix}). If you would like to translate it in your native
|
||||
language, consider joining the
|
||||
référence de GNU Guix}) and German (@pxref{Top,,, guix.de, Referenzhandbuch
|
||||
zu GNU Guix}). If you would like to translate it in your native language,
|
||||
consider joining the
|
||||
@uref{https://translationproject.org/domain/guix-manual.html, Translation
|
||||
Project}.
|
||||
|
||||
|
|
|
|||
|
|
@ -22,7 +22,8 @@
|
|||
# along with GNU Guix. If not, see <http://www.gnu.org/licenses/>.
|
||||
|
||||
info_TEXINFOS = %D%/guix.texi \
|
||||
%D%/guix.fr.texi
|
||||
%D%/guix.fr.texi \
|
||||
%D%/guix.de.texi
|
||||
|
||||
%C%_guix_TEXINFOS = \
|
||||
%D%/contributing.texi \
|
||||
|
|
@ -54,7 +55,9 @@ OS_CONFIG_EXAMPLES_TEXI = \
|
|||
%D%/os-config-lightweight-desktop.texi
|
||||
|
||||
TRANSLATED_INFO = \
|
||||
%D%/guix.de.texi \
|
||||
%D%/guix.fr.texi \
|
||||
%D%/contributing.de.texi \
|
||||
%D%/contributing.fr.texi
|
||||
|
||||
# Bundle this file so that makeinfo finds it in out-of-source-tree builds.
|
||||
|
|
|
|||
File diff suppressed because it is too large
Load Diff
|
|
@ -18,6 +18,7 @@
|
|||
|
||||
EXTRA_DIST = \
|
||||
%D%/guix-manual.pot \
|
||||
%D%/guix-manual.de.po \
|
||||
%D%/guix-manual.fr.po
|
||||
|
||||
POT_OPTIONS = --package-name "guix" --package-version "$(VERSION)" \
|
||||
|
|
|
|||
Loading…
Reference in New Issue