Merge branch 'staging' into core-updates

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