summaryrefslogtreecommitdiff
path: root/doc/contributing.de.texi
diff options
context:
space:
mode:
Diffstat (limited to 'doc/contributing.de.texi')
-rw-r--r--doc/contributing.de.texi590
1 files changed, 532 insertions, 58 deletions
diff --git a/doc/contributing.de.texi b/doc/contributing.de.texi
index 9997092a9e..259523aa6f 100644
--- a/doc/contributing.de.texi
+++ b/doc/contributing.de.texi
@@ -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
@@ -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 (@pxref{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
@@ -164,21 +167,25 @@ 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} (@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}.
+The Perfect Setup to hack on Guix is basically the perfect setup used for
+Guile hacking (@pxref{Using Guile in Emacs,,, guile, Guile Reference
+Manual}). First, you need more than an editor, you need
+@url{http://www.gnu.org/software/emacs, Emacs}, empowered by the wonderful
+@url{http://nongnu.org/geiser/, Geiser}. To set that up, run:
+
+@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
@@ -218,12 +225,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,6 +242,445 @@ Auslöse-Zeichenketten einfügen, die alle auf @code{...} enden, was selbst
wieder weiter umgeschrieben werden kann.
+@node Paketrichtlinien
+@section Paketrichtlinien
+
+@cindex packages, creating
+The GNU distribution is nascent and may well lack some of your favorite
+packages. This section describes how you can help make the distribution
+grow.
+
+Free software packages are usually distributed in the form of @dfn{source
+code tarballs}---typically @file{tar.gz} files that contain all the source
+files. Adding a package to the distribution means essentially two things:
+adding a @dfn{recipe} that describes how to build the package, including a
+list of other packages required to build it, and adding @dfn{package
+metadata} along with that recipe, such as a description and licensing
+information.
+
+In Guix all this information is embodied in @dfn{package definitions}.
+Package definitions provide a high-level view of the package. They are
+written using the syntax of the Scheme programming language; in fact, for
+each package we define a variable bound to the package definition, and
+export that variable from a module (@pxref{Paketmodule}). However,
+in-depth Scheme knowledge is @emph{not} a prerequisite for creating
+packages. For more information on package definitions, @pxref{Pakete definieren}.
+
+Once a package definition is in place, stored in a file in the Guix source
+tree, it can be tested using the @command{guix build} command
+(@pxref{Aufruf von guix build}). For example, assuming the new package is
+called @code{gnew}, you may run this command from the Guix build tree
+(@pxref{Guix vor der Installation ausführen}):
+
+@example
+./pre-inst-env guix build gnew --keep-failed
+@end example
+
+Using @code{--keep-failed} makes it easier to debug build failures since it
+provides access to the failed build tree. Another useful command-line
+option when debugging is @code{--log-file}, to access the build log.
+
+If the package is unknown to the @command{guix} command, it may be that the
+source file contains a syntax error, or lacks a @code{define-public} clause
+to export the package variable. To figure it out, you may load the module
+from Guile to get more information about the actual error:
+
+@example
+./pre-inst-env guile -c '(use-modules (gnu packages gnew))'
+@end example
+
+Once your package builds correctly, please send us a patch
+(@pxref{Einreichen von Patches}). Well, if you need help, we will be happy to
+help you too. Once the patch is committed in the Guix repository, the new
+package automatically gets built on the supported platforms by
+@url{http://hydra.gnu.org/jobset/gnu/master, our continuous integration
+system}.
+
+@cindex substituter
+Users can obtain the new package definition simply by running @command{guix
+pull} (@pxref{Aufruf von guix pull}). When @code{@value{SUBSTITUTE-SERVER}}
+is done building the package, installing the package automatically downloads
+binaries from there (@pxref{Substitute}). The only place where human
+intervention is needed is to review and apply the patch.
+
+
+@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 free software
+The GNU operating system has been developed so that users can have freedom
+in their computing. GNU is @dfn{free software}, meaning that users have the
+@url{http://www.gnu.org/philosophy/free-sw.html,four essential freedoms}: to
+run the program, to study and change the program in source code form, to
+redistribute exact copies, and to distribute modified versions. Packages
+found in the GNU distribution provide only software that conveys these four
+freedoms.
+
+In addition, the GNU distribution follow the
+@url{http://www.gnu.org/distros/free-system-distribution-guidelines.html,free
+software distribution guidelines}. Among other things, these guidelines
+reject non-free firmware, recommendations of non-free software, and discuss
+ways to deal with trademarks and patents.
+
+Some otherwise free upstream package sources contain a small and optional
+subset that violates the above guidelines, for instance because this subset
+is itself non-free code. When that happens, the offending items are removed
+with appropriate patches or code snippets in the @code{origin} form of the
+package (@pxref{Pakete definieren}). This way, @code{guix build --source}
+returns the ``freed'' source rather than the unmodified upstream source.
+
+
+@node Paketbenennung
+@subsection Paketbenennung
+
+@cindex package name
+A package has actually two names associated with it: First, there is the
+name of the @emph{Scheme variable}, the one following @code{define-public}.
+By this name, the package can be made known in the Scheme code, for instance
+as input to another package. Second, there is the string in the @code{name}
+field of a package definition. This name is used by package management
+commands such as @command{guix package} and @command{guix build}.
+
+Both are usually the same and correspond to the lowercase conversion of the
+project name chosen upstream, with underscores replaced with hyphens. For
+instance, GNUnet is available as @code{gnunet}, and SDL_net as
+@code{sdl-net}.
+
+We do not add @code{lib} prefixes for library packages, unless these are
+already part of the official project name. But @pxref{Python-Module} and
+@ref{Perl-Module} for special rules concerning modules for the Python and
+Perl languages.
+
+Font package names are handled differently, @pxref{Schriftarten}.
+
+
+@node Versionsnummern
+@subsection Versionsnummern
+
+@cindex package version
+We usually package only the latest version of a given free software
+project. But sometimes, for instance for incompatible library versions, two
+(or more) versions of the same package are needed. These require different
+Scheme variable names. We use the name as defined in @ref{Paketbenennung}
+for the most recent version; previous versions use the same name, suffixed
+by @code{-} and the smallest prefix of the version number that may
+distinguish the two versions.
+
+The name inside the package definition is the same for all versions of a
+package and does not contain any version number.
+
+Zum Beispiel können für GTK in den Versionen 2.24.20 und 3.9.12 Pakete wie
+folgt geschrieben werden:
+
+@example
+(define-public gtk+
+ (package
+ (name "gtk+")
+ (version "3.9.12")
+ ...))
+(define-public gtk+-2
+ (package
+ (name "gtk+")
+ (version "2.24.20")
+ ...))
+@end example
+Wenn wir auch GTK 3.8.2 wollten, würden wir das Paket schreiben als
+@example
+(define-public gtk+-3.8
+ (package
+ (name "gtk+")
+ (version "3.8.2")
+ ...))
+@end example
+
+@c See <https://lists.gnu.org/archive/html/guix-devel/2016-01/msg00425.html>,
+@c for a discussion of what follows.
+@cindex version number, for VCS snapshots
+Occasionally, we package snapshots of upstream's version control system
+(VCS) instead of formal releases. This should remain exceptional, because
+it is up to upstream developers to clarify what the stable release is. Yet,
+it is sometimes necessary. So, what should we put in the @code{version}
+field?
+
+Clearly, we need to make the commit identifier of the VCS snapshot visible
+in the version string, but we also need to make sure that the version string
+is monotonically increasing so that @command{guix package --upgrade} can
+determine which version is newer. Since commit identifiers, notably with
+Git, are not monotonically increasing, we add a revision number that we
+increase each time we upgrade to a newer snapshot. The resulting version
+string looks like this:
+
+@example
+2.0.11-3.cabba9e
+ ^ ^ ^
+ | | `-- upstream commit ID
+ | |
+ | `--- Guix package revision
+ |
+latest upstream version
+@end example
+
+It is a good idea to strip commit identifiers in the @code{version} field
+to, say, 7 digits. It avoids an aesthetic annoyance (assuming aesthetics
+have a role to play here) as well as problems related to OS limits such as
+the maximum shebang length (127 bytes for the Linux kernel.) It is best to
+use the full commit identifiers in @code{origin}s, though, to avoid
+ambiguities. A typical package definition may look like this:
+
+@example
+(define my-package
+ (let ((commit "c3f29bc928d5900971f65965feaae59e1272a3f7")
+ (revision "1")) ;Guix package revision
+ (package
+ (version (git-version "0.9" revision commit))
+ (source (origin
+ (method git-fetch)
+ (uri (git-reference
+ (url "git://example.org/my-package.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 package description
+@cindex package synopsis
+As we have seen before, each package in GNU@tie{}Guix includes a synopsis
+and a description (@pxref{Pakete definieren}). Synopses and descriptions
+are important: They are what @command{guix package --search} searches, and a
+crucial piece of information to help users determine whether a given package
+suits their needs. Consequently, packagers should pay attention to what
+goes into them.
+
+Synopses must start with a capital letter and must not end with a period.
+They must not start with ``a'' or ``the'', which usually does not bring
+anything; for instance, prefer ``File-frobbing tool'' over ``A tool that
+frobs files''. The synopsis should say what the package is---e.g., ``Core
+GNU utilities (file, text, shell)''---or what it is used for---e.g., the
+synopsis for GNU@tie{}grep is ``Print lines matching a pattern''.
+
+Keep in mind that the synopsis must be meaningful for a very wide audience.
+For example, ``Manipulate alignments in the SAM format'' might make sense
+for a seasoned bioinformatics researcher, but might be fairly unhelpful or
+even misleading to a non-specialized audience. It is a good idea to come up
+with a synopsis that gives an idea of the application domain of the
+package. In this example, this might give something like ``Manipulate
+nucleotide sequence alignments'', which hopefully gives the user a better
+idea of whether this is what they are looking for.
+
+Descriptions should take between five and ten lines. Use full sentences,
+and avoid using acronyms without first introducing them. Please avoid
+marketing phrases such as ``world-leading'', ``industrial-strength'', and
+``next-generation'', and avoid superlatives like ``the most
+advanced''---they are not helpful to users looking for a package and may
+even sound suspicious. Instead, try to be factual, mentioning use cases and
+features.
+
+@cindex Texinfo markup, in package descriptions
+Descriptions can include Texinfo markup, which is useful to introduce
+ornaments such as @code{@@code} or @code{@@dfn}, bullet lists, or hyperlinks
+(@pxref{Overview,,, texinfo, GNU Texinfo}). However you should be careful
+when using some characters for example @samp{@@} and curly braces which are
+the basic special characters in Texinfo (@pxref{Special Characters,,,
+texinfo, GNU Texinfo}). User interfaces such as @command{guix package
+--show} take care of rendering it appropriately.
+
+Synopses and descriptions are translated by volunteers
+@uref{http://translationproject.org/domain/guix-packages.html, at the
+Translation Project} so that as many users as possible can read them in
+their native language. User interfaces search them and display them in the
+language specified by the current locale.
+
+To allow @command{xgettext} to extract them as translatable strings,
+synopses and descriptions @emph{must be literal strings}. This means that
+you cannot use @code{string-append} or @code{format} to construct these
+strings:
+
+@lisp
+(package
+ ;; @dots{}
+ (synopsis "This is translatable")
+ (description (string-append "This is " "*not*" " translatable.")))
+@end lisp
+
+Translation is a lot of work so, as a packager, please pay even more
+attention to your synopses and descriptions as every change may entail
+additional work for translators. In order to help them, it is possible to
+make recommendations or instructions visible to them by inserting special
+comments like this (@pxref{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
+We currently package Python 2 and Python 3, under the Scheme variable names
+@code{python-2} and @code{python} as explained in @ref{Versionsnummern}. To
+avoid confusion and naming clashes with other programming languages, it
+seems desirable that the name of a package for a Python module contains the
+word @code{python}.
+
+Some modules are compatible with only one version of Python, others with
+both. If the package Foo compiles only with Python 3, we name it
+@code{python-foo}; if it compiles only with Python 2, we name it
+@code{python2-foo}. If it is compatible with both versions, we create two
+packages with the corresponding names.
+
+If a project already contains the word @code{python}, we drop this; for
+instance, the module python-dateutil is packaged under the names
+@code{python-dateutil} and @code{python2-dateutil}. If the project name
+starts with @code{py} (e.g.@: @code{pytz}), we keep it and prefix it as
+described above.
+
+@subsubsection Specifying Dependencies
+@cindex inputs, for Python packages
+
+Dependency information for Python packages is usually available in the
+package source tree, with varying degrees of accuracy: in the
+@file{setup.py} file, in @file{requirements.txt}, or in @file{tox.ini}.
+
+Your mission, when writing a recipe for a Python package, is to map these
+dependencies to the appropriate type of ``input'' (@pxref{»package«-Referenz,
+inputs}). Although the @code{pypi} importer normally does a good job
+(@pxref{Aufruf von guix import}), you may want to check the following check
+list to determine which dependency goes where.
+
+@itemize
+
+@item
+We currently package Python 2 with @code{setuptools} and @code{pip}
+installed like Python 3.4 has per default. Thus you don't need to specify
+either of these as an input. @command{guix lint} will warn you if you do.
+
+@item
+Python dependencies required at run time go into @code{propagated-inputs}.
+They are typically defined with the @code{install_requires} keyword in
+@file{setup.py}, or in the @file{requirements.txt} file.
+
+@item
+Python packages required only at build time---e.g., those listed with the
+@code{setup_requires} keyword in @file{setup.py}---or only for
+testing---e.g., those in @code{tests_require}---go into
+@code{native-inputs}. The rationale is that (1) they do not need to be
+propagated because they are not needed at run time, and (2) in a
+cross-compilation context, it's the ``native'' input that we'd want.
+
+Examples are the @code{pytest}, @code{mock}, and @code{nose} test
+frameworks. Of course if any of these packages is also required at
+run-time, it needs to go to @code{propagated-inputs}.
+
+@item
+Anything that does not fall in the previous categories goes to
+@code{inputs}, for example programs or C libraries required for building
+Python packages containing C extensions.
+
+@item
+If a Python package has optional dependencies (@code{extras_require}), it is
+up to you to decide whether to add them or not, based on their
+usefulness/overhead ratio (@pxref{Einreichen von Patches, @command{guix size}}).
+
+@end itemize
+
+
+@node Perl-Module
+@subsection Perl-Module
+
+@cindex perl
+Perl programs standing for themselves are named as any other package, using
+the lowercase upstream name. For Perl packages containing a single class,
+we use the lowercase class name, replace all occurrences of @code{::} by
+dashes and prepend the prefix @code{perl-}. So the class @code{XML::Parser}
+becomes @code{perl-xml-parser}. Modules containing several classes keep
+their lowercase upstream name and are also prepended by @code{perl-}. Such
+modules tend to have the word @code{perl} somewhere in their name, which
+gets dropped in favor of the prefix. For instance, @code{libwww-perl}
+becomes @code{perl-libwww}.
+
+
+@node Java-Pakete
+@subsection Java-Pakete
+
+@cindex java
+Java programs standing for themselves are named as any other package, using
+the lowercase upstream name.
+
+To avoid confusion and naming clashes with other programming languages, it
+is desirable that the name of a package for a Java package is prefixed with
+@code{java-}. If a project already contains the word @code{java}, we drop
+this; for instance, the package @code{ngsjava} is packaged under the name
+@code{java-ngs}.
+
+For Java packages containing a single class or a small class hierarchy, we
+use the lowercase class name, replace all occurrences of @code{.} by dashes
+and prepend the prefix @code{java-}. So the class @code{apache.commons.cli}
+becomes package @code{java-apache-commons-cli}.
+
+
+@node Schriftarten
+@subsection Schriftarten
+
+@cindex Schriftarten
+For fonts that are in general not installed by a user for typesetting
+purposes, or that are distributed as part of a larger software package, we
+rely on the general packaging rules for software; for instance, this applies
+to the fonts delivered as part of the X.Org system or fonts that are part of
+TeX Live.
+
+To make it easier for a user to search for fonts, names for other packages
+containing only fonts are constructed as follows, independently of the
+upstream package name.
+
+The name of a package containing only one font family starts with
+@code{font-}; it is followed by the foundry name and a dash @code{-} if the
+foundry is known, and the font family name, in which spaces are replaced by
+dashes (and as usual, all upper case letters are transformed to lower
+case). For example, the Gentium font family by SIL is packaged under the
+name @code{font-sil-gentium}.
+
+For a package containing several font families, the name of the collection
+is used in the place of the font family name. For instance, the Liberation
+fonts consist of three families, Liberation Sans, Liberation Serif and
+Liberation Mono. These could be packaged separately under the names
+@code{font-liberation-sans} and so on; but as they are distributed together
+under a common name, we prefer to package them together as
+@code{font-liberation}.
+
+In the case where several formats of the same font family or font collection
+are packaged separately, a short form of the format, prepended by a dash, is
+added to the package name. We use @code{-ttf} for TrueType fonts,
+@code{-otf} for OpenType fonts and @code{-type1} for PostScript Type 1
+fonts.
+
+
@node Code-Stil
@section Code-Stil
@@ -383,6 +831,33 @@ Stellen Sie sicher, dass das Paket auf Ihrer Plattform erstellt werden kann,
indem Sie @code{guix build @var{Paket}} ausführen.
@item
+We recommend you also try building the package on other supported
+platforms. As you may not have access to actual hardware platforms, we
+recommend using the @code{qemu-binfmt-service-type} to emulate them. In
+order to enable it, add the following service to the list of services in
+your @code{operating-system} configuration:
+
+@example
+(service qemu-binfmt-service-type
+ (qemu-binfmt-configuration
+ (platforms (lookup-qemu-platforms "arm" "aarch64" "ppc" "mips64el"))
+ (guix-support? #t)))
+@end example
+
+Then reconfigure your system.
+
+You can then build packages for different platforms by specifying the
+@code{--system} option. For example, to build the "hello" package for the
+armhf, aarch64, powerpc, or mips64 architectures, you would run the
+following commands, respectively:
+@example
+guix build --system=armhf-linux --rounds=2 hello
+guix build --system=aarch64-linux --rounds=2 hello
+guix build --system=powerpc-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.
@@ -399,22 +874,18 @@ 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.
+Take a look at the profile reported by @command{guix size} (@pxref{Aufruf von guix size}). This will allow you to notice references to other packages
+unwillingly retained. It may also help determine whether to split the
+package (@pxref{Pakete mit mehreren Ausgaben.}), and which optional
+dependencies should be used. In particular, avoid adding @code{texlive} as
+a dependency: because of its extreme size, use @code{texlive-tiny} or
+@code{texlive-union} instead.
@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
@@ -438,17 +909,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
@@ -468,16 +942,14 @@ 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.
+Another option is to use @command{guix challenge} (@pxref{Aufruf von guix challenge}). You may run it once the package has been committed and built
+by @code{@value{SUBSTITUTE-SERVER}} to check whether it obtains the same
+result as you did. Better yet: Find another machine that can build it and
+run @command{guix publish}. Since the remote build machine is likely
+different from yours, this can catch non-determinism issues related to the
+hardware---e.g., use of different instruction set extensions---or to the
+operating system kernel---e.g., reliance on @code{uname} or @file{/proc}
+files.
@item
Beim Schreiben von Dokumentation achten Sie bitte auf eine
@@ -500,11 +972,13 @@ 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.
+Benutzen Sie, wenn möglich, Spiegelserver (Mirrors) in der Quell-URL
+(@pxref{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