developers-reference - en to de translation catalogue (478 entries)

en: Managing Packages
de: Pakete verwalten

en: This chapter contains information related to creating, uploading, maintaining, and porting packages.
de: Dieses Kapitel enthält Informationen, die sich auf das Erstellen, Hochladen, Verwalten und Portieren von Paketen beziehen.

en: New packages
de: Neue Pakete

en: If you want to create a new package for the Debian distribution, you should first check the `Work-Needing and Prospective Packages (WNPP) <https://www.debian.org/devel/wnpp/>`__ list. Checking the WNPP list ensures that no one is already working on packaging that software, and that effort is not duplicated. Read the `WNPP web pages <https://www.debian.org/devel/wnpp/>`__ for more information.
de: Falls Sie ein neues Paket für die Debian-Distribution erstellen möchten, sollten Sie zuerst die Liste der `Arbeit-bedürfenden und voraussichtlichen Pakete (WNPP) <https://www.debian.org/devel/wnpp/>`__ prüfen. Die Prüfung der WNPP-Liste stellt sicher, dass nicht bereits jemand an der Paketierung dieser Software arbeitet und kein doppelter Aufwand betrieben wird. Weitere Informationen finden Sie auf den `WNPP-Web-Seiten <https://www.debian.org/devel/wnpp/>`__.

en: Assuming no one else is already working on your prospective package, you must then submit a bug report (:ref:`submit-bug`) against the pseudo-package ``wnpp`` describing your plan to create a new package, including, but not limiting yourself to, the description of the package (so that others can review it), the license of the prospective package, and the current URL where it can be downloaded from.
de: Ausgehend von der Annahme, dass noch niemand an Ihrem zukünftigen Paket arbeitet, müssen Sie einen Fehlerbericht (:ref:`submit-bug`) gegen das Pseudopaket ``wnpp`` einreichen, in dem Sie Ihr Vorhaben vorstellen. Der Fehlerbericht muss mindestens eine Beschreibung des neuen Pakets enthalten (sodass andere es überprüfen können), die Lizenz angeben die dem Paket zugedacht werden soll, sowie die derzeitige URL, von der es heruntergeladen werden kann.

en: You should set the subject of the bug to ``ITP:`` *foo* ``--`` *short description*, substituting the name of the new package for *foo*. The severity of the bug report must be set to ``wishlist``. Please send a copy to ``debian-devel@lists.debian.org`` by using the X-Debbugs-CC header (don't use CC:, because that way the message's subject won't indicate the bug number). If you are packaging so many new packages (>10) that notifying the mailing list in separate messages is too disruptive, send a summary after filing the bugs to the debian-devel list instead. This will inform the other developers about upcoming packages and will allow a review of your description and package name.
de: Sie sollten den Betreff des Fehlers auf ``ITP:``\ *Paketname*\ ``--``\ *kurze Beschreibung* setzen, wobei Sie *Paketname* durch den Namen Ihres Pakets ersetzen. Der Schweregrad des Fehlerberichts muss auf ``wishlist`` gesetzt werden. Bitte senden Sie mit der Kopfzeile X-Debbugs-CC eine Kopie an ``debian-devel@lists.debian.org`` (benutzen Sie nicht CC:, da in diesem Fall der Betreff der Nachricht die Fehlernummer nicht angibt). Falls Sie so viele (mehr als zehn) neue Pakete paketieren, dass die Benachrichtigung auf der Liste als störend empfunden würde, senden Sie stattdessen nach dem Einreichen des Fehlers eine Zusammenfassung an die Liste "debian-devel". Dies wird andere Entwickler über die bevorstehenden Pakete informieren und eine Überprüfung Ihrer Beschreibung und Ihres Paketnamens ermöglichen.

en: Please include a ``Closes: #``\ *nnnnn* entry in the changelog of the new package in order for the bug report to be automatically closed once the new package is installed in the archive (see :ref:`upload-bugfix`).
de: Bitte fügen Sie im Änderungsprotokoll des neuen Pakets den Eintrag ``Closes: #``\ *nnnnn* hinzu, um den Fehlerbericht automatisch zu schließen, sobald das neue Paket im Archiv installiert wird (siehe :ref:`upload-bugfix`).

en: If you think your package needs some explanations for the administrators of the NEW package queue, include them in your changelog, send to ``ftpmaster@debian.org`` a reply to the email you receive as a maintainer after your upload, or reply to the rejection email in case you are already re-uploading.
de: Falls Sie der Ansicht sind Ihr Paket bedürfe einiger Erklärungen für die Administratoren der Paketwarteschlange NEW, so fügen Sie diese dem Änderungsprotokoll hinzu, senden Sie die E-Mail die Sie als Betreuer nach dem Upload zurückbekommen haben an ``ftpmaster@debian.org`` oder antworten Sie auf die ablehnende E-Mail für den Fall, dass Sie bereits erneut hochladen.

en: When closing security bugs include CVE numbers as well as the ``Closes: #``\ *nnnnn*. This is useful for the security team to track vulnerabilities. If an upload is made to fix the bug before the advisory ID is known, it is encouraged to modify the historical changelog entry with the next upload. Even in this case, please include all available pointers to background information in the original changelog entry.
de: Wenn sicherheitskritische Fehler geschlossen werden, fügen Sie die CVE-Nummern sowie ``Closes: #``\ *nnnnn* bei. Dies ist nützlich zur Verfolgung von Schwachstellen durch das Sicherheits-Team. Falls etwas hochgeladen wird, bevor die ID der Sicherheitsankündigung bekannt ist, sollte beim nächsten Upload der historische Änderungsprotokolleintrag geändert werden. Bitte fügen Sie sogar in diesem Fall dem Original-Änderungsprotokolleintrag alle verfügbaren Hinweise auf Hintergrundinformationen hinzu.

en: There are a number of reasons why we ask maintainers to announce their intentions:
de: Es gibt eine Vielzahl von Gründen weshalb Paketbetreuer um die Ankündigung ihrer Absichten gebeten werden:

en: It helps the (potentially new) maintainer to tap into the experience of people on the list, and lets them know if anyone else is working on it already.
de: Es hilft dem (möglicherweise neuen) Betreuer, die Erfahrung der Leute auf der Liste anzuzapfen und teilt ihm mit, ob jemand anderes bereits daran arbeitet.

en: It lets other people thinking about working on the package know that there already is a volunteer, so efforts may be shared.
de: Es zeigt anderen Leuten, die darüber nachdenken am Paket zu arbeiten, dass es bereits einen Freiwilligen gibt, so dass der Aufwand verteilt werden kann.

en: It lets the rest of the maintainers know more about the package than the one line description and the usual changelog entry ``Initial release`` that gets posted to ``debian-devel-changes@lists.debian.org``.
de: Es sagt den übrigen Betreuern mehr über das Paket, als nur aus Beschreibungszeile erkennbar und der übliche Eintrag im Änderungsprotokoll "Initial release", der an ``debian-devel-changes@lists.debian.org`` gesandt wird.

en: It is helpful to the people who live off ``unstable`` (and form our first line of testers). We should encourage these people.
de: Es ist hilfreich für Leute, die die Veröffentlichung ``Unstable`` für die tägliche Arbeit benutzen (und die die vorderste Frontlinie von Testern bilden). Diese Leute sollten ermutigt werden.

en: The announcements give maintainers and other interested parties a better feel of what is going on, and what is new, in the project.
de: Die Ankündigungen geben Betreuern und anderen interessierten Parteien ein besseres Gefühl dafür, was gerade geschieht und was im Projekt neu ist.

en: Please see https://ftp-master.debian.org/REJECT-FAQ.html\  for common rejection reasons for a new package.
de: Bitte lesen Sie unter https://ftp-master.debian.org/REJECT-FAQ.html\  die häufigsten Gründe für die Ablehnung neuer Pakete.

en: Recording changes in the package
de: Änderungen im Paket aufzeichnen

en: Changes that you make to the package need to be recorded in the ``debian/changelog`` file, for human users to read and comprehend. These changes should provide a concise description of what was changed, why (if it's in doubt), and note if any bugs were closed. They also record when the packaging was completed. This file will be installed in ``/usr/share/doc/``\ *package*\ ``/changelog.Debian.gz``, or ``/usr/share/doc/``\ *package*\ ``/changelog.gz`` for native packages.
de: Von Ihnen vorgenommene Änderungen müssen in ``debian/changelog`` in einer Form aufgezeichnet werden, so dass andere Personen die Änderungen nachvollziehen uns verstehen können. Diese Änderungen sollten eine kurzgefasste Beschreibung bereitstellen, was geändert wurde, warum (falls dies zweifelhaft ist) und vermerken, ob irgendwelche Fehler geschlossen wurden. Sie zeichnen außerdem auf, wenn das Paket vervollständigt wurde. Diese Datei wird in ``/usr/share/doc/``\ *Paket*\ ``/changelog.Debian.gz`` (oder ``/usr/share/doc/``\ *Paket*\ ``/changelog.gz`` für native Pakete) installiert.

en: The ``debian/changelog`` file conforms to a certain structure, with a number of different fields. One field of note, the ``distribution``, is described in :ref:`distribution`. More information about the structure of this file can be found in the Debian Policy section titled ``debian/changelog``.
de: Die Datei ``debian/changelog`` hat eine bestimmte Struktur mit einer Anzahl unterschiedlicher Felder. Ein bedeutendes Feld, die ``distribution``, wird in :ref:`distribution` beschrieben. Weitere Informationen über die Struktur dieser Datei sind im Abschnitt ``debian/changelog`` der Debian-Richtlinien zu finden.

en: Changelog entries can be used to automatically close Debian bugs when the package is installed into the archive. See :ref:`upload-bugfix`.
de: Wenn das Paket im Archiv installiert ist, können Einträge im Änderungsprotokoll benutzt werden, um Debian-Fehler automatisch zu schließen. Siehe :ref:`upload-bugfix`.

en: It is conventional that the changelog entry of a package that contains a new upstream version of the software looks like this:
de: Es ist üblich, dass der Änderungsprotokolleintrag eines Pakets, der eine neue Originalversion der Software enthält, wie folgt aussieht:

en: See also :ref:`bpp-debian-changelog`.
de: Siehe auch :ref:`bpp-debian-changelog`.

en: Testing the package
de: Das Paket testen

en: Before you upload your package, you should do basic testing on it. At a minimum, you should try the following activities (you'll need to have an older version of the same Debian package around):
de: Bevor Sie Ihr Paket hochladen, sollten Sie es grundlegenden Tests unterziehen. Zumindest sollten Sie die folgenden Dinge ausprobieren (Sie sollten eine ältere Version des gleichen Debian-Pakets zur Hand haben):

en: Run ``lintian`` over the package. You can run ``lintian`` as follows: ``lintian -v`` *package-version*\ ``.changes``. This will check the source package as well as the binary package. If you don't understand the output that ``lintian`` generates, try adding the ``-i`` switch, which will cause ``lintian`` to output a very verbose description of the problem.
de: Führen Sie für das Paket ``lintian`` aus. Sie können ``lintian`` wie folgt ausführen: ``lintian -v``\ *Paket-Version*\ ``.changes``. Falls Sie die von ``lintian`` erzeugte Ausgabe nicht verstehen, versuchen Sie den Schalter ``-i`` hinzuzufügen. Er veranlasst ``lintian`` eine viel detailliertere Beschreibung des Problems auszugeben.

en: Normally, a package should *not* be uploaded if it causes ``lintian`` to emit errors (they will start with ``E``).
de: Normalerweise sollte ein Paket *nicht* hochgeladen werden, wenn es ``lintian``-Fehler (diese beginnen mit ``E``) verursacht.

en: For more information on ``lintian``, see :ref:`lintian`.
de: Weitere Informationen über ``lintian`` finden Sie unter :ref:`lintian`.

en: Optionally run ``debdiff`` (see :ref:`debdiff`) to analyze changes from an older version, if one exists.
de: Führen Sie wahlweise ``debdiff`` (siehe :ref:`debdiff`) aus, um Änderungen von einer älteren Version zu analysieren, falls es eine solche gibt.

en: Install the package and make sure the software works in an up-to-date ``unstable`` system.
de: Installieren Sie das Paket und prüfen die korrekte Funktion dessen in einem tagesaktuellem ``Unstable`` System.

en: Upgrade the package from an older version to your new version.
de: Aktualisieren Sie das Paket von einer vorherigen Version auf Ihre neu erstellte Version.

en: Remove the package, then reinstall it.
de: Entfernen Sie das Paket und installieren Sie es erneut.

en: Installing, upgrading and removal of packages can either be tested manually or by using the ``piuparts`` tool.
de: Die Installation, eine Aktualisierung oder auch ein komplettes Entfernen des Paketes können manuell oder auch durch das ``piuparts`` Werkzeug getestet werden.

en: Copy the source package in a different directory and try unpacking it and rebuilding it. This tests if the package relies on existing files outside of it, or if it relies on permissions being preserved on the files shipped inside the ``.diff.gz`` file.
de: Kopieren Sie das Quellpaket in ein anderes Verzeichnis und versuchen Sie es zu entpacken und neu zu erstellen. Dies testet, ob das Paket bestehende Dateien von außerhalb des Tarballs benötigt oder ob es auf Benutzerrechten beruht, die in den Dateien konserviert sind, die innerhalb der ``.diff.gz``-Datei mitgeliefert wurden.

en: Layout of the source package
de: Layout des Quellpakets

en: There are two types of Debian source packages:
de: Es gibt zwei Typen von Debian-Quellpaketen:

en: the so-called ``native`` packages, where there is no distinction between the original sources and the patches applied for Debian
de: Die sogenannten ``native``-Pakete, bei denen es keine Unterschiede zwischen dem Originalquellcode und den auf Debian angewandten Patches gibt.

en: the (more common) packages where there's an original source tarball file accompanied by another file that contains the changes made by Debian
de: Die (häufigeren) Pakete, bei denen der originale Quellcode-Tarball mit einer anderen Datei mitgeliefert wird, die die von Debian vorgenommenen Änderungen enthält.

en: For the native packages, the source package includes a Debian source control file (``.dsc``) and the source tarball (``.tar.{gz,bz2,xz}``). A source package of a non-native package includes a Debian source control file, the original source tarball (``.orig.tar.{gz,bz2,xz}``) and the Debian changes (``.diff.gz`` for the source format “1.0” or ``.debian.tar.{gz,bz2,xz}`` for the source format “3.0 (quilt)”).
de: Bei nativen Paketen enthält der Quell-Tarball eine Steuerungsdatei für Debian-Quellen (``.dsc``) und einen Quell-Tarball (``.tar.{gz,bz2,xz}``). Ein Quellpaket eines nicht nativen Paketes enthält eine Steuerungsdatei für Debian-Quellen, den Original-Quellcode-Tarball (``.orig.tar.{gz,bz2,xz}``) und die Debian-Änderungen (``.diff.gz`` für das Quellformat "1.0" oder ``.debian.tar.{gz,bz2,xz}`` für das Quellformat "3.0 (quilt)").

en: With source format “1.0”, whether a package is native or not was determined by ``dpkg-source`` at build time. Nowadays it is recommended to be explicit about the desired source format by putting either “3.0 (quilt)” or “3.0 (native)” in ``debian/source/format``. The rest of this section relates only to non-native packages.
de: Mit dem Quellformat "1.0" wurde zur Zeit des Erstellens durch ``dpkg-source`` festgelegt, ob ein Paket nativ ist oder nicht. Heutzutage wird empfohlen, das gewünschte Quellformat explizit durch Angabe von "3.0 (quilt)" oder "3.0 (native)" in ``debian/source/format`` festzulegen. Der Rest dieses Abschnitts bezieht sich auf nicht native Pakete.

en: The first time a version is uploaded that corresponds to a particular upstream version, the original source tar file must be uploaded and included in the ``.changes`` file. Subsequently, this very same tar file should be used to build the new diffs and ``.dsc`` files, and will not need to be re-uploaded.
de: Anfangs, wenn eine Version hochgeladen wird, die einer bestimmten Version des Ursprungsquellcodes entspricht, muss die Original-Tar-Quelldatei hochgeladen und in die ``.changes``-Datei eingefügt werden. Nachfolgend sollte eben diese Tar-Datei benutzt werden, um neue .diff- und ``.dsc``-Dateien zu erstellen ohne die Notwendigkeit, diese erneut hochzuladen.

en: By default, ``dpkg-genchanges`` and ``dpkg-buildpackage`` will include the original source tar file if and only if the current changelog entry has a different upstream version from the preceding entry. This behavior may be modified by using ``-sa`` to always include it or ``-sd`` to always leave it out.
de: Standardmäßig werden ``dpkg-genchanges`` und ``dpkg-buildpackage`` die Original-Tar-Quelldatei nur dann einbeziehen, falls der aktuelle Änderungsprotokolleintrag eine andere Originalversion des vorhergehenden Eintrags hat. Dieses Verhalten kann durch die Benutzung der Option ``-sa`` geändert werden, um es immer einzubeziehen oder ``-sd``, um es immer wegzulassen.

en: If no original source is included in the upload, the original source tar-file used by ``dpkg-source`` when constructing the ``.dsc`` file and diff to be uploaded *must* be byte-for-byte identical with the one already in the archive.
de: Falls im Upload kein Originalquellcode enthalten ist, *muss* die Original-Tar-Quelldatei, die von ``dpkg-source`` benutzt wurde, um die ``.dsc``-Datei und die hochzuladene Diff-Datei zu erzeugen, Byte für Byte identisch mit der sein, die bereits im Archiv ist.

en: Please notice that, in non-native packages, permissions on files that are not present in the ``*.orig.tar.{gz,bz2,xz}`` will not be preserved, as diff does not store file permissions in the patch. However, when using source format “3.0 (quilt)”, permissions of files inside the ``debian`` directory are preserved since they are stored in a tar archive.
de: Bitte beachten Sie, dass in nicht nativen Paketen Zugriffsrechte von Dateien, die nicht in den ``*.orig.tar.{gz,bz2,xz}``-Dateien enthalten sind, nicht aufbewahrt werden, da das Diff die Dateizugriffsrechte nicht im Patch speichert. Wenn Sie jedoch das Format "3.0 (quilt)" benutzen, werden Zugriffsrechte von Dateien innerhalb des ``debian``-Verzeichnisses aufbewahrt, da sie in einem Tar-Archiv gespeichert werden.

en: Picking a distribution
de: Eine Distribution auswählen

en: Each upload needs to specify which distribution the package is intended for. The package build process extracts this information from the first line of the ``debian/changelog`` file and places it in the ``Distribution`` field of the ``.changes`` file.
de: Bei jedem Upload muss angegeben werden, für welche Distribution das Paket gedacht ist. Der Prozess der Paketerstellung extrahiert diese Information aus der ersten Zeile der Datei ``debian/changelog`` und platziert sie im Feld ``Distribution`` der ``.changes``-Datei.

en: Packages are normally uploaded into ``unstable``. Uploads to ``unstable`` or ``experimental`` should use these suite names in the changelog entry; uploads for other supported suites should use the suite codenames, as they avoid any ambiguity.
de: Normalerweise werden Pakete nach ``Unstable`` hochgeladen. Beim Hochladen nach ``Unstable`` oder ``Experimental`` sollte diese Suite-Namen im Änderungsprotokolleintrag verwendet werden. Beim Hochladen für andere unterstützte Suites sollten die Suite-Codenamen benutzt werden, um Mehrdeutigkeiten zu vermeiden.

en: Actually, there are other possible distributions: |codename-security|, but read :ref:`bug-security` for more information on those.
de: Außerdem gibt es auch noch andere mögliche Distributionen: |codename-security|, aber lesen Sie :ref:`bug-security`, um weitere Informationen darüber zu erhalten.

en: It is not possible to upload a package into several distributions at the same time.
de: Es ist nicht möglich ein Paket gleichzeitig in mehrere Distributionen hochzuladen.

en: Special case: uploads to the ``stable`` and ``oldstable`` distributions
de: Sonderfall Uploads in die Distributionen ``Stable`` und ``Oldstable``

en: Uploading to ``stable`` means that the package will be transferred to the ``proposed-updates-new`` queue for review by the stable release managers, and if approved will be installed in the ``stable-proposed-updates`` directory of the Debian archive. From there, it will be included in ``stable`` with the next point release.
de: Hochladen nach ``Stable`` bedeutet, dass das Paket in die Warteschlange ``proposed-updates-new`` übertragen wird, damit es von den Veröffentlichungsverwaltern überprüft werden kann. Falls es zugelassen wird, wird es in das Verzeichnis ``stable-proposed-updates`` des Debian-Archivs installiert. Von dort wird es zum nächsten Veröffentlichungszeitpunkt in ``Stable`` eingefügt.

en: If you are confident that the upload will be accepted without changes, please feel free to upload at the same time as filing the ``release.debian.org`` bug. However if you are new to the process, we would recommend getting approval before uploading so you get a chance to see if your expectations align with ours.
de: Wenn Sie sicher sind, dass der Upload ohne Änderungen akzeptiert werden wird, können Sie ihn gleichzeitig mit dem Einreichen des Fehlerreports gegen ``release.debian.org`` hochladen. Wenn Sie mit dem Prozess noch nicht vertraut sind, empfehlen wir Ihnen, vor dem Hochladen eine Genehmigung einzuholen, damit Sie sehen können, ob Ihre Erwartungen mit denen des Veröffentlichungsteam übereinstimmen.

en: Either way, there must be an accompanying bug for tracking, and your upload must comply with these acceptance criteria defined by the the stable release managers. These criteria are designed to help the process be as smooth and frustration-free as possible.
de: In beiden Fällen muss ein Fehlerreport zur Nachverfolgung vorliegen, und Ihr Upload muss den festgelegten Akzeptanzkriterien vom Veröffentlichungsteam entsprechen. Diese Kriterien sollen dazu beitragen, dass der Prozess so reibungslos und frustrationsfrei wie möglich verläuft.

en: The bug you want to fix in ``stable`` must be fixed in ``unstable`` already (and not waiting in NEW or the delayed queue).
de: Der Fehler, den Sie in ``Stable`` beheben möchten, muss bereits in ``Unstable`` behoben sein (und das Paket mit der korrigierten Version darf nicht in NEW oder der Delayed-Queue liegen).

en: The bug should be of severity "important" or higher.
de: Der Fehlerreport muss die Dringlichkeit "Important" oder höher besitzen.

en: Bug meta-data - particularly affected versions - must be up to date.
de: Die Metadaten des Fehlerreports - im Speziellen die betroffenen Versionen - müssen aktuell sein.

en: Fixes must be minimal and relevant and include a sufficiently detailed changelog entry.
de: Fehlerbehebungen müssen so klein als möglich aber auch relevant sein und und einen ausreichend detaillierten Änderungsprotokolleintrag enthalten.

en: A source debdiff of the proposed change must be included in your request (not just the raw patches or "a debdiff can be found at $URL").
de: Ein Quell-Debdiff der vorgeschlagenen Änderung muss in Ihrer Anfrage enthalten sein (nicht nur die nackten Patches oder "Ein Debdiff kann unter $URL gefunden werden").

en: The update must be built in an ``stable`` environment or chroot (or ``oldstable`` if you target that).
de: Das Update muss in einer ``Stable`` Umgebung oder Chroot erstellt worden sein (oder ``Oldstable`` wenn dies die Zielveröffentlichung ist).

en: Fixes for security issues should be co-ordinated with the security team, unless they have explicitly stated that they will not issue an ``DSA`` for the bug (e.g. via a "no-dsa" marker in the :ref:`bug-security-tracker`).
de: Korrekturen für Sicherheitsprobleme sollten mit dem Sicherheitsteam abgestimmt werden, es sei denn, Sie haben ausdrücklich angegeben, dass das Sicherheitsteam keinen ``DSA`` für den Fehler erstellt hat (z. B. über einen "no-dsa"-Marker im :ref:`bug-security-tracker`).

en: Do not close ``release.debian.org`` bugs in debian/changelog. They will be closed by the release team once the package has reached the respective point release.
de: Sie sollten ``release.debian.org`` Fehler in debian/changelog nicht selber schließen. Die Fehler werden vom Release Team geschlossen, wenn das Paket die jeweilige Zwischenveröffentlichung erreicht hat.

en: It is recommended to use ``reportbug`` as it eases the creation of bugs with correct meta-data. The release team makes extensive use of usertags to sort and manage requests and incorrectly tagged reports may take longer to be noticed and processed.
de: Es wird empfohlen, ``reportbug`` zu verwenden, da dies die Erstellung von Fehlern mit korrekten Metadaten erleichtert. Das Veröffentlichungsteam verwendet in großem Umfang Usertags, um Anforderungen zu sortieren und zu verwalten. Falsch gekennzeichnete Berichte können länger dauern, bis sie bemerkt und verarbeitet werden.

en: Uploads to the ``oldstable`` distributions are possible as long as it hasn't been archived. The same rules as for ``stable`` apply.
de: Uploads nach ``Oldstable``-Distributionen sind möglich, solange diese nicht archiviert sind. Es gelten die gleichen Regeln wie für ``Stable``.

en: In the past, uploads to ``stable`` were used to address security problems as well. However, this practice is deprecated, as uploads used for Debian security advisories (``DSA``) are automatically copied to the appropriate ``proposed-updates`` archive when the advisory is released. See :ref:`bug-security` for detailed information on handling security problems. If the security team deems the problem to be too benign to be fixed through a ``DSA``, the stable release managers are usually willing to include your fix nonetheless in a regular upload to ``stable``.
de: Früher wurden Uploads nach ``Stable`` benutzt, um auch Sicherheitsprobleme anzugehen. Diese Praxis ist jedoch missbilligt, da Uploads für Debian-Sicherheitsankündigungen (DSAs) automatisch in das entsprechende Archiv ``proposed-updates`` kopiert werden, wenn die Ankündigung veröffentlicht wird. Weitere detailliertere Informationen über die Handhabung von Sicherheitsproblemen finden Sie unter :ref:`bug-security`. Falls das Sicherheits-Team das Problem als zu harmlos erachtet, um es durch ein ``DSA`` zu beheben, sind die Veröffentlichungsverwalter normalerweise trotzdem bereit, Ihre Fehlerbehebung bei einem regulären Upload nach ``Stable`` einzufügen.

en: Special case: the ``stable-updates`` suite
de: Sonderfall ``stable-updates`` Suite

en: Sometimes the stable release managers will decide that an update to stable should be made available to users sooner than the next scheduled point release. In such cases, they can copy the update to the ``stable-updates`` suite, use of which is enabled by the installer by default.
de: Manchmal entscheiden die Veröffentlichungsmanager, dass ein Update für ``Stable`` den Benutzern früher als zur nächsten geplanten Point-Release zur Verfügung gestellt werden soll. In solchen Fällen können Sie das Update in die Suite ``stable-updates`` kopieren, die Verwendung dieser Suite wird standardmäßig vom Installationsprogramm aktiviert.

en: Initially, the process described in :ref:`upload-stable`. should be followed as usual. If you think that the upload should be released via ``stable-updates``, mention this in your request. Examples of circumstances in which the upload may qualify for such treatment are:
de: Der Prozess hierzu ist der Gleiche wie in :ref:`upload-stable`. Wenn Sie der Meinung sind, dass Ihr Pakte über ``stable-updates`` veröffentlicht werden soll, erwähnen Sie dies in Ihrer Anfrage an das Veröffentlichungsteam. Beispiele für Umstände, unter denen sich der Upload für eine solche Behandlung qualifizieren kann, sind:

en: The update is urgent and not of a security nature.  Security updates will continue to be pushed through the security archive.  Examples include packages broken by the flow of time (c.f. ``spamassassin`` and the year 2010 problem) and fixes for bugs introduced by point releases.
de: Das Update ist dringend jedoch nicht sicherheitsrelevant. Beispiele hierfür sind Pakete, die durch den Zeitfluss unterbrochen wurden (vgl. ``spamassassin`` und das Problem des Jahres 2010) und Korrekturen für Fehler, die durch Point-Releases verursacht wurden (z.B. Regressions). Sicherheitsupdates werden weiterhin unabhängig hiervon durch das Sicherheitsarchiv getätigt.

en: The package in question is a data package and the data must be updated in a timely manner (e.g. ``tzdata``).
de: Das fragliche Paket ist einen Datenpaket und muss zeitnah aktualisiert werden (z.B. ``tzdata``).

en: Fixes to leaf packages that were broken by external changes (e.g. video downloading tools and ``tor``).
de: Korrekturen an mehrschichtigen Paketen, die durch externe Änderungen disfunktional wurden (z. B. Tools zum Herunterladen von Videos und ``tor``).

en: Packages that need to be current to be useful (e.g. ``clamav``).
de: Pakete, die aktuell sein müssen, um nützlich zu sein (z. B. ``clamav``).

en: Once the upload has been accepted to ``proposed-updates`` and is ready for release, the stable release managers will then copy it to the ``stable-updates`` suite and issue a Stable Update Announcement (``SUA``) via the ``debian-stable-announce`` mailing list.
de: Sobald der Upload für ``proposed-updates`` akzeptiert wurde und zur Veröffentlichung bereit steht, kopieren die Veröffentlichungsmanager diesen in die Suite ``stable-updates`` und geben über die Mailingliste ``debian-stable-announce`` ein Stable Update Announcement (``SUA``) heraus.

en: Any updates released via ``stable-updates`` will be included in ``stable`` with the next point release as usual.
de: Alle Aktualisierungen in ``stable-updates`` werden auch in der nächsten Point-Release von ``Stable`` enthalten sein.

en: Special case: uploads to ``testing/testing-proposed-updates``
de: Sonderfall Uploads nach ``testing/testing-proposed-updates``

en: Please see the information in the :ref:`t-p-u` for details.
de: Bitte lesen Sie die Informationen im :ref:`t-p-u`, um weitere Einzelheiten zu erfahren.

en: Uploading a package
de: Ein Paket hochladen

en: Source and binary uploads
de: Source und Binär Uploads

en: Each upload to Debian consists of a signed ``.changes`` file describing the requested change to the archive, plus the source and binary package files that are referenced by the ``.changes`` file.
de: Jeder Upload in Debian beinhaltet eine signierte Datei ``.changes`` in der die angeforderten Änderungen am Archive beschrieben sind, plus ebenfalls das Source und Binärpaket welche durch die Datei ``.changes`` referenziert werden.

en: If possible, the version of a package that is uploaded should be a source-only changes file. These are typically named ``*_source.changes``, and reference the source package, but no binary ``.deb`` or ``.udeb`` packages. All of the corresponding architecture-dependent and architecture-independent binary packages, for all architectures, will be built automatically by the build daemons in a controlled and predictable environment (see :ref:`wanna-build` for more details). However, there are several situations where this is not possible.
de: Wenn möglich sollte die Version des Uploads für das Paket ein source-only changes Datei sein. Diese sind typischerweise nach dem Muster ``*_source.changes`` benannt und referenzieren das Source Paket, aber nicht binäre ``.deb`` or ``.udeb`` Pakete. Alle entsprechenden architekturabhängigen und architekturunabhängigen Binärpakete für alle Architekturen werden von den Build-Daemons automatisch in einer kontrollierten und vorhersehbaren Umgebung erstellt (Siehe :ref:`wanna-build` für mehr Details). Aber, es gibt natürlich einige Situationen wo dies in der Form so nicht möglich ist.

en: The first upload of a new source package (see :ref:`newpackage`) must include binary packages, so that they can be reviewed by the archive administrators before they are added to Debian.
de: Das erste Hochladen eines neuen Source Paketes (see :ref:`newpackage`) muss die Binärpakte enthalten. Diese werden im Review Prozess der Debian-Archivbetreuer benötigt bevor diese zu Debian hinzugefügt werden können.

en: If new binary packages are added to an existing source package, then the first upload that lists the new binary packages in ``debian/control`` must include binary packages, again so that they can be reviewed by the archive administrators before they are added to Debian. It is preferred for these uploads to be done via the ``experimental`` suite.
de: Wenn neue Binärpakte zu vorhandenen Source Paketen hinzugefügt werden dann muss das erste Hochladen was die neuen Binärpakte in ``debian/control`` enthält ebenfalls die Binärpkate enthalten. Der Grund hierfür ist wieder der Gleiche wie beim Einführen eines neuen Source Paketes, der Review Prozess der Debian-Archivbetreuer erfordert dies. Wünschenswert ist das Benutzen der Suite ``experimental`` für derartige Uploads.

en: Uploads that will be held for review in other queues, such as packages being added to the ``*-backports`` suites, might also require inclusion of binary packages.
de: Uploads, die zur Überprüfung in anderen Queues durchgeführt werden, zum Beispiel für Pakete die zu den Suites ``*-backports`` hinzugefügt werden sollen, können es ebenfalls erfordern, dass Binärpakte hochgeladen werden müssen.

en: The build daemons will automatically attempt to build any ``main`` or ``contrib`` package for which the build-dependencies are available. Packages in ``non-free`` and ``non-free-firmware`` will not be built by the build daemons unless the package has been marked as suitable for auto-building (see :ref:`non-free-buildd`).
de: Die Buildd Daemons starten den Bau aller Pakete aus `main`` oder ``contrib`` sofern die hierzu nötigen Paketabhängigkeiten erfüllt werden können. Pakete in ``non-free`` und ``non-free-firmware`` werden nur automatisch gebaut sofern diese Pakete als geeignet markiert worden sind für das automatische Bauen (Siehe :ref:`non-free-buildd`).

en: The build daemons only install build-dependencies from the ``main`` archive area. This means that if a source package has build-dependencies that are in the ``contrib``, ``non-free`` or ``non-free-firmware`` archive areas, then uploads of that package need to include prebuilt binary packages for every architecture that will be supported. By definition this can only be the case for source packages that are themselves in the ``contrib``, ``non-free`` or ``non-free-firmware`` archive areas.
de: Die Build Daemons installieren nur zum Bau benötigte Pakete aus dem Bereich des ``main`` Archivs. Dies bedeutet, wenn ein Source Paket abhängige Pakete zum Bauen aus den Archivbereichen ``contrib``, ``non-free`` oder ``non-free-firmware`` benötigt, dann müssen Uploads dieses Pakets vorgefertigte Binärpakete für alle unterstützen Architekturen enthalten. Definitionsbedingt kann dies nur der Fall sein wenn das Source Paket selbst in einem der Archivbereiche ``contrib``, ``non-free`` oder ``non-free-firmware`` liegt.

en: Bootstrapping a new architecture, or a new version of a package with circular dependencies (such as a self-hosting compiler), will sometimes also require an upload that includes binary packages.
de: Beim Bootstrapping einer neuen Architektur, oder einer neuen Version eines Paketes mit zirkularen Abhängigkeiten (wie z.B. ein Self Hosting Compiler) ist es auch manchmal notwendig dass das Hochladen mit den erstellten Binärpaketen erfolgen muss.

en: Binary packages in the ``main`` archive area that were not built by Debian's official build daemons will not usually be allowed to migrate from ``unstable`` to ``testing``, so an upload that contains binary packages built by the package's maintainer must usually be followed by a source-only upload after the binary upload has been accepted. This restriction does not apply to ``contrib``, ``non-free`` or ``non-free-firmware`` packages.
de: Binärpakete im ``main`` Archiv, die nicht durch die offiziellen Debian Build Daemons erstellt worden sind, werden nicht, wo sonst üblich, automatisch von ``unstable`` nach ``testing`` migrieren. Dadurch muss nach ein Upload, der nur Binärpakete enthalten hat, ein weiteres Hochladen als source-only Upload erfolgen nachdem der vorherige Upload mit den Binärpaketen akzeptiert worden ist. Diese Bestimmung gilt nicht für Pakete aus ``contrib``, ``non-free`` oder ``non-free-firmware``.

en: Uploading to ``ftp-master``
de: Hochladen nach ``ftp-master``

en: To upload a package, you should upload the files (including the signed changes and dsc file) with anonymous ftp to ``ftp.upload.debian.org`` in the directory `/pub/UploadQueue/ <ftp://ftp.upload.debian.org/pub/UploadQueue/>`__. To get the files processed there, they need to be signed with a key in the Debian Developers keyring or the Debian Maintainers keyring (see https://wiki.debian.org/DebianMaintainer\ ).
de: Um ein Paket hochzuladen, sollten Sie die Dateien (einschließlich der signierten Änderungen an der dsc-Datei) mit anonymem FTP nach ``ftp.upload.debian.org`` in das Verzeichnis `/pub/UploadQueue/ <ftp://ftp.upload.debian.org/pub/UploadQueue/>`__ hochladen. Damit die Dateien dort verarbeitet werden, müssen sie mit einem Schlüssel aus dem Debian-Entwickler-Schlüsselbund signiert sein (siehe https://wiki.debian.org/DebianMaintainer\ ).

en: Please note that you should transfer the changes file last. Otherwise, your upload may be rejected because the archive maintenance software will parse the changes file and see that not all files have been uploaded.
de: Bitte beachten Sie, dass Sie die Datei "changes" zuletzt übertragen sollten. Andernfalls könnte Ihr Upload abgelehnt werden, da die Archivverwaltungs-Software die "changes"-Datei auswertet und feststellt, dass nicht alle Dateien hochgeladen wurden.

en: You may also find the Debian packages :ref:`dupload` or :ref:`dput` useful when uploading packages.These handy programs help automate the process of uploading packages into Debian.
de: Vielleicht finden Sie auch die Debian-Pakete :ref:`dupload` oder :ref:`dput` nützlich, um Pakete hochzuladen. Diese praktischen Programme helfen den Prozess des Hochladens von Paketen nach Debian zu automatisieren.

en: For removing packages or cancelling an upload, please see ftp://ftp.upload.debian.org/pub/UploadQueue/README\  and the Debian package :ref:`dcut`.
de: Um Pakete aus der Upload Queue zu entfernen sehen Sie sich bitte ftp://ftp.upload.debian.org/pub/UploadQueue/README\  und das Debian-Paket :ref:`dcut` an.

en: Finally, you should think about the status of your package with relation to ``testing`` before uploading to ``unstable``. If you have a version in ``unstable`` waiting to migrate then it is generally a good idea to let it migrate before uploading another new version. You should also check the :ref:`pkg-tracker` for transition warnings to avoid making uploads that disrupt ongoing transitions.
de: Sie sollten aber auch über den Status Ihres Paket in ``Testing`` nachdenken bevor Sie eine neue Version nach ``Unstable`` laden. Wenn Sie eine Version in ``Unstable`` haben die auf die Migration nach ``Testing`` wartet, ist es im Allgemeinen eine gute Idee, diese zunächst migrieren zu lassen, bevor Sie eine andere neue Version hochladen. Sie sollten auch :ref:`pkg-tracker` auf Warnungen überprüfen, um Uploads zu vermeiden, die laufende Übergänge stören.

en: Delayed uploads
de: Verzögerte Uploads

en: It is sometimes useful to upload a package immediately, but to want this package to arrive in the archive only a few days later. For example, when preparing a :ref:`nmu`, you might want to give the maintainer a few days to react.
de: Manchmal ist es nützlich, ein Paket sofort hochzuladen, aber gleichzeitig festzulegen, dass dieses Paket das Archiv erst ein paar Tage später erreicht. Sie könnten, wenn Sie beispielsweise einen :ref:`nmu` vorbereiten, dem Betreuer ein paar Tage Zeit geben wollen, damit er reagieren kann.

en: An upload to the delayed directory keeps the package in `the deferred uploads queue <https://ftp-master.debian.org/deferred.html>`__. When the specified waiting time is over, the package is moved into the regular incoming directory for processing. This is done through automatic uploading to ``ftp.upload.debian.org`` in upload-directory ``DELAYED/``\ *X*\ ``-day`` (*X* between 0 and 15). 0-day is uploaded multiple times per day to ``ftp.upload.debian.org``.
de: Bei einem Upload des Pakets in das Verzögerungsverzeichnis wird es in der `deferred uploads queue <https://ftp-master.debian.org/deferred.html>`__ gehalten. Wenn die angegebene Wartezeit vorüber ist, wird das Paket zur Verarbeitung in das reguläre Eingangsverzeichnis verschoben. Dies wird erledigt durch automatisches Hochladen nach ``ftp.upload.debian.org`` in das Upload-Verzeichnis ``DELAYED/``\ *X*\ ``-day`` (*X* ist eine Zahl zwischen 0 und 15). 0-day wird mehrmals täglich nach ``ftp.upload.debian.org`` hochgeladen.

en: With dput, you can use the ``--delayed`` *DELAY* parameter to put the package into one of the queues.
de: Mit dput können Sie den Parameter ``--delayed`` *VERZÖGERUNG* benutzen, um das Paket in eine der Warteschlangen einzureihen.

en: Security uploads
de: Sicherheits-Uploads

en: Do **NOT** upload a package to the security upload queue (on ``*.security.upload.debian.org``) without prior authorization from the security team. If the package does not exactly meet the team's requirements, it will cause many problems and delays in dealing with the unwanted upload. For details, please see :ref:`bug-security`.
de: Laden Sie **KEIN** Paket in die Sicherheits-Upload-Warteschlange (auf ``security-master.debian.org`` hoch, ohne vorher eine Erlaubnis vom Sicherheits-Team erhalten zu haben. Falls das Paket nicht exakt den Anforderungen des Teams entspricht, wird es viele Probleme und Verzögerungen in der Behandlung des unerwünschten Uploads verursachen. Um Einzelheiten zu erhalten, lesen Sie :ref:`bug-security`.

en: Other upload queues
de: Andere Upload-Warteschlangen

en: There is an alternative upload queue in Europe at ftp://ftp.eu.upload.debian.org/pub/UploadQueue/\ . It operates in the same way as ``ftp.upload.debian.org``, but should be faster for European developers.
de: Es gibt in Europa eine alternative Upload-Warteschlange unter ftp://ftp.eu.upload.debian.org/pub/UploadQueue/\ . Sie arbeitet auf die gleiche Weise wie ``ftp.upload.debian.org``, sollte aber für europäische Entwickler schneller sein.

en: Packages can also be uploaded via ssh to ``ssh.upload.debian.org``; files should be put ``/srv/upload.debian.org/UploadQueue``. This queue does not support :ref:`delayed-incoming`.
de: Pakete können auch per SSH nach ``ssh.upload.debian.org`` hochgeladen werden. Dateien sollten in ``/srv/upload.debian.org/UploadQueue`` abgelegt werden. Diese Warteschlange unterstützt keine :ref:`delayed-incoming`.

en: Notifications
de: Benachrichtigungen

en: The Debian archive maintainers are responsible for handling package uploads. For the most part, uploads are automatically handled on a daily basis by the archive maintenance tools, ``dak process-upload``. Specifically, updates to existing packages to the ``unstable`` distribution are handled automatically. In other cases, notably new packages, placing the uploaded package into the distribution is handled manually. When uploads are handled manually, the change to the archive may take some time to occur. Please be patient.
de: Die Debian-Archivbetreuer sind für die Behandlung der Paket-Uploads verantwortlich. Zum größten Teil werden Uploads automatisch täglich durch das Archiv-Verwaltungswerkzeug ``dak process-upload`` verarbeitet. Im Besonderen werden Aktualisierungen zu existierenden Paketen in der Distribution ``Unstable`` automatisch eingepflegt. In anderen Fällen, insbesondere bei neuen Paketen, wird das hochgeladene Paket manuell in die Distribution platziert. Wenn Uploads manuell behandelt werden, kann es einige Zeit dauern, bis die Änderung im Archiv erscheint. Bitte haben Sie Geduld.

en: In any case, you will receive an email notification indicating that the package has been added to the archive, which also indicates which bugs will be closed by the upload. Please examine this notification carefully, checking if any bugs you meant to close didn't get triggered.
de: Auf jeden Fall werden Sie eine E-Mail-Benachrichtigung erhalten, die anzeigt, dass das Paket dem Archiv hinzugefügt wurde und welche Fehler durch den Upload geschlossen werden. Bitte lesen Sie diese Benachrichtigung sorgfältig und prüfen Sie, ob irgendwelche Fehler, die Sie schließen wollten, nicht berücksichtigt wurden.

en: The installation notification also includes information on what section the package was inserted into. If there is a disparity, you will receive a separate email notifying you of that. Read on below.
de: Die Installationsbenachrichtigung enthält außerdem die Information, in welchen Abschnitt das Paket eingefügt wird. Falls es dort eine Ungleichheit gibt, werden Sie eine separate E-Mail-Benachrichtigung darüber erhalten. Lesen Sie das Folgende.

en: Note that if you upload via queues, the queue daemon software will also send you a notification by email.
de: Beachten Sie, dass, falls Sie mittels Warteschlangen hochladen, die Warteschlangen-Daemon-Software Ihnen auch per E-Mail Benachrichtigungen sendet.

en: Also note that new uploads are announced on the :ref:`irc-channels` channel ``#debian-devel-changes``. If your upload fails silently, it could be that your package is improperly signed, in which case you can find more explanations on ``ssh.upload.debian.org:/srv/upload.debian.org/queued/run/log``.
de: Beachten Sie außerdem, dass neue Uploads im :ref:`irc-channels`-Kanal ``#debian-devel-changes`` publiziert werden. Falls der Upload ohne Benachrichtigung fehlgeschlagen ist, kann es sein, dass Ihr Paket keine gültige Signatur hatte. In diesem Fall finden Sie weitere Erläuterungen in ``ssh.upload.debian.org:/srv/upload.debian.org/queued/run/log``.

en: Specifying the package section, subsection and priority
de: Angabe des Paketbereichs, des Unterbereichs und der Priorität

en: The ``debian/control`` file's ``Section`` and ``Priority`` fields do not actually specify where the file will be placed in the archive, nor its priority. In order to retain the overall integrity of the archive, it is the archive maintainers who have control over these fields. The values in the ``debian/control`` file are actually just hints.
de: Die Felder ``Section`` und ``Priority`` der Datei ``debian/control`` geben weder an, wo die Datei im Archiv tatsächlich platziert wird noch deren Priorität. Um die gesamte Integrität des Archivs zu wahren, haben die Archivbetreuer die Kontrolle über diese Felder. Die Werte in der Datei ``debian/control`` sind letztlich nur Hinweise.

en: The archive maintainers keep track of the canonical sections and priorities for packages in the ``override file``. If there is a disparity between the ``override file`` and the package's fields as indicated in ``debian/control``, then you will receive an email noting the divergence when the package is installed into the archive. You can either correct your ``debian/control`` file for your next upload, or else you may wish to make a change in the ``override file``.
de: Die Archivbetreuer behalten den Überblick über die vorschriftsmäßigen Bereiche und Prioritäten für Pakete im ``override file``. Falls es dort einen Unterschied zwischen dem ``override file`` und den Paketfeldern, die in ``debian/control`` angezeigt werden, gibt, werden Sie eine E-Mail-Benachrichtigung über die Abweichung erhalten, wenn das Paket in das Archiv installiert wird. Sie können entweder Ihre ``debian/control``-Datei für Ihren nächsten Upload ändern oder eine Änderung am ``override file`` vorschlagen.

en: To alter the actual section that a package is put in, you need to first make sure that the ``debian/control`` file in your package is accurate. Next, submit a bug against ``ftp.debian.org`` requesting that the section or priority for your package be changed from the old section or priority to the new one. Use a Subject like ``override: PACKAGE1:section/priority, [...], PACKAGEX:section/priority``, and include the justification for the change in the body of the bug report.
de: Um den tatsächlichen Bereich abzuändern, in den Ihr Paket abgelegt wird, müssen Sie zuerst sicherstellen, dass die Datei ``debian/control`` in Ihrem Paket fehlerfrei ist. Als nächstes versenden Sie einen Fehlerbericht gegen ``ftp.debian.org`` mit der Bitte, den Bereich oder die Priorität für Ihr Paket von dem alten auf den neuen Bereich oder die neue Priorität zu ändern. Benutzen Sie einen Betreff wie ``override: PACKAGE1:section/priority, [...], PACKAGEX:section/priority`` und fügen Sie die Begründung der Änderung in den Nachrichtentext des Fehlerberichts ein.

en: For more information about ``override files``, see dpkg-scanpackages 1 and https://www.debian.org/Bugs/Developer#maintincorrect\ .
de: Weitere Informationen über ``override files`` finden Sie unter dpkg-scanpackages 1 und https://www.debian.org/Bugs/Developer#maintincorrect\ .

en: Note that the ``Section`` field describes both the section as well as the subsection, which are described in :ref:`archive-sections`. If the section is main, it should be omitted. The list of allowable subsections can be found in https://www.debian.org/doc/debian-policy/ch-archive.html#s-subsections\ .
de: Beachten Sie, dass das Feld ``Section`` sowohl den Bereich als auch den Unterbereich beschreibt, die in :ref:`archive-sections` erläutert werden. Falls der Bereich "main" ist, sollte er weggelassen werden. Die Liste der erlaubten Unterbereiche finden Sie unter https://www.debian.org/doc/debian-policy/ch-archive.html#s-subsections\ .

en: Handling bugs
de: Fehlerbehandlung

en: Every developer has to be able to work with the Debian `bug tracking system <https://www.debian.org/Bugs/>`__. This includes knowing how to file bug reports properly (see :ref:`submit-bug`), how to update them and reorder them, and how to process and close them.
de: Jeder Entwickler muss in der Lage sein, mit der Debian-\ `Fehlerdatenbank <https://www.debian.org/Bugs/>`__ zu arbeiten. Dies umfasst das Wissen, wie Fehlerberichte richtig eingeordnet werden (siehe :ref:`submit-bug`), wie sie aktualisiert und neu geordnet werden und wie sie verarbeitet und geschlossen werden.

en: The bug tracking system's features are described in the `BTS documentation for developers <https://www.debian.org/Bugs/Developer>`__. This includes closing bugs, sending followup messages, assigning severities and tags, marking bugs as forwarded, and other issues.
de: Die Funktionen des Fehlerverfolgungssystems sind in unter `Fehlerverwaltungssystem für Paket-Betreuer <https://www.debian.org/Bugs/Developer>`__ beschrieben. Dies umfasst das Schließen von Fehlern, Followup-Nachrichten, Zuweisen von Schweregraden, Markieren von Fehlern als weitergeleitet und andere Themen.

en: Operations such as reassigning bugs to other packages, merging separate bug reports about the same issue, or reopening bugs when they are prematurely closed, are handled using the so-called control mail server. All of the commands available on this server are described in the `BTS control server documentation <https://www.debian.org/Bugs/server-control>`__.
de: Operationen wie das erneute Zuweisen von Fehlern an andere Pakete, das Zusammenführen separater Fehlerberichte zum gleichen Thema oder das Wiedereröffnen von Fehlern, wenn diese voreilig geschlossen wurden, werden vom sogenannten Steuermailserver verarbeitet. Alle Befehle, die auf diesem Server verfügbar sind, werden in der `Einführung in den E-Mail-Server für die Kontrolle und Manipulation <https://www.debian.org/Bugs/server-control>`__ beschrieben.

en: Monitoring bugs
de: Fehlerüberwachung

en: If you want to be a good maintainer, you should periodically check the `Debian bug tracking system (BTS) <https://www.debian.org/Bugs/>`__ for your packages. The BTS contains all the open bugs against your packages. You can check them by browsing this page: ``https://bugs.debian.org/``\ *yourlogin*\ ``@debian.org``.
de: Falls Sie ein guter Paketbetreuer sein möchten, sollten Sie regelmäßig die `Debian-Fehlerdatenbank (BTS) <https://www.debian.org/Bugs/>`__ für Ihre Pakete überprüfen. Das BTS enthält alle offenen Fehler Ihrer Pakete. Sie können sie prüfen, indem Sie diese Seite durchstöbern: ``https://bugs.debian.org/``\ *nickname*\ ``@debian.org``.

en: Maintainers interact with the BTS via email addresses at ``bugs.debian.org``. Documentation on available commands can be found at https://www.debian.org/Bugs/\ , or, if you have installed the ``doc-debian`` package, you can look at the local files ``/usr/share/doc/debian/bug-*``.
de: Paketbetreuer interagieren mit dem BTS über E-Mail-Adressen auf ``bugs.debian.org``. Dokumentationen über verfügbare Befehle können Sie unter https://www.debian.org/Bugs/\  finden oder, falls Sie das Paket ``doc-debian`` installiert haben, schauen Sie in die lokalen Dateien ``/usr/share/doc/debian/bug-*``.

en: Some find it useful to get periodic reports on open bugs. You can add a cron job such as the following if you want to get a weekly email outlining all the open bugs against your packages:
de: Einige finden es nützlich, regelmäßig Berichte über offene Fehler zu erhalten. Sie können einen Cron-Job wie den folgenden hinzufügen, falls Sie wöchentlich eine E-Mail erhalten möchten, die alle Fehler Ihrer Pakete zusammenfasst:

en: Replace *address* with your official Debian maintainer address.
de: Ersetzen Sie *address* durch Ihre offizielle Debian-Betreueradresse.

en: Responding to bugs
de: Auf Fehler antworten

en: When responding to bugs, make sure that any discussion you have about bugs is sent to the original submitter of the bug, the bug itself and (if you are not the maintainer of the package) the maintainer. Sending an email to *123*\ ``@bugs.debian.org`` will send the mail to the maintainer of the package and record your email with the bug log. If you don't remember the submitter email address, you can use *123*\ ``-submitter@bugs.debian.org`` to also contact the submitter of the bug. The latter address also records the email with the bug log, so if you are the maintainer of the package in question, it is enough to send the reply to *123*\ ``-submitter@bugs.debian.org``. Otherwise you should include *123*\ ``@bugs.debian.org`` so that you also reach the package maintainer.
de: Stellen Sie bei der Reaktion auf Fehler sicher, dass alle Diskussionen über Fehler an den ursprünglichen Übermittler des Fehlers aber auch an den Fehlerreport selbst und (wenn Sie nicht der Betreuer des Pakets sind) den Betreuer gesendet werden. Wenn Sie eine E-Mail an *123*\ ``@bugs.debian.org`` senden, wird die E-Mail an den Betreuer des Pakets gesendet und Ihre E-Mail mit im Fehlerprotokoll aufgezeichnet. Wenn Sie sich nicht an die E-Mail-Adresse des Absenders erinnern, können Sie mit *123*\ ``-submitter@bugs.debian.org`` auch den Absender des Fehlers kontaktieren. Letztere Adresse zeichnet auch die E-Mail-Korrespondenz mit im Fehlerprotokoll auf. Wenn Sie also der Betreuer des betreffenden Pakets sind, reicht es aus, die Antwort an *123*\ ``-submitter@bugs.debian.org`` zu senden. Andernfalls sollten Sie *123*\ ``@bugs.debian.org`` benutzen, damit Sie auch den Paketbetreuer erreichen.

en: If you get a bug which mentions FTBFS, this means Fails to build from source. Porters frequently use this acronym.
de: Falls Sie einen Fehlerbericht erhalten, der FTBFS erwähnt, so bedeutet dies "Fails to build from source" (Kann nicht aus dem Quellcode erstellt werden). Portierer benutzen diese Abkürzung öfter.

en: Once you've dealt with a bug report (e.g. fixed it), mark it as ``done`` (close it) by sending an explanation message to *123*\ ``-done@bugs.debian.org``. If you're fixing a bug by changing and uploading the package, you can automate bug closing as described in :ref:`upload-bugfix`.
de: Sobald Sie einen Fehlerbericht erledigt (z.B. den Fehler behoben) haben, markieren Sie ihn als ``done`` (dies schließt ihn), indem Sie eine Erklärung an *123*\ ``-done@bugs.debian.org`` senden. Falls Sie einen Fehler durch Ändern und Hochladen des Pakets schließen, können Sie das Schließen von Fehlern, wie in :ref:`upload-bugfix` beschrieben, automatisieren.

en: You should *never* close bugs via the bug server ``close`` command sent to ``control@bugs.debian.org``. If you do so, the original submitter will not receive any information about why the bug was closed.
de: Sie sollten Fehler *niemals* durch Senden des Befehls ``close`` an ``control@bugs.debian.org`` schließen. Falls Sie dies tun, wird der ursprüngliche Absender keine Informationen darüber erhalten, warum der Fehler geschlossen wurde.

en: Bug housekeeping
de: Verwaltung von Fehlerberichten

en: As a package maintainer, you will often find bugs in other packages or have bugs reported against your packages which are actually bugs in other packages. The bug tracking system's features are described in the `BTS documentation for Debian developers <https://www.debian.org/Bugs/Developer>`__. Operations such as reassigning, merging, and tagging bug reports are described in the `BTS control server documentation <https://www.debian.org/Bugs/server-control>`__. This section contains some guidelines for managing your own bugs, based on the collective Debian developer experience.
de: Als Paketbetreuer werden Sie öfter Fehler in anderen Paketen finden oder Fehlerberichte gegen Ihre Pakete erhalten, die tatsächlich Fehler in anderen Paketen sind. Die Funktionen der Fehlerdatenbank werden in den `Informationen über das Fehlerverwaltungssystem für Paket-Betreuer <https://www.debian.org/Bugs/Developer>`__ beschrieben. Operationen wie erneutes Zuweisen, Zusammenführen und Markieren von Fehlerberichten werden in der `Einführung in den E-Mail-Server für die Kontrolle und Manipulation <https://www.debian.org/Bugs/server-control>`__ beschrieben. Dieser Abschnitt enthält einige Regeln für die Verwaltung Ihrer eigenen Fehler, die auf der gesammelten Erfahrung der Debian-Entwickler basieren.

en: Filing bugs for problems that you find in other packages is one of the civic obligations of maintainership, see :ref:`submit-bug` for details. However, handling the bugs in your own packages is even more important.
de: Fehler für Probleme einzureichen, die Sie in anderen Paketen finden, ist eine der bürgerlichen Pflichten des Betreuerdaseins. Einzelheiten finden Sie unter :ref:`submit-bug`. Es ist jedoch wichtiger, die Fehler in den eigenen Paketen zu behandeln.

en: Here's a list of steps that you may follow to handle a bug report:
de: Hier ist eine kurze Liste der Schritte, denen Sie zu Handhabung eines Fehlerberichts folgen können:

en: Decide whether the report corresponds to a real bug or not. Sometimes users are just calling a program in the wrong way because they haven't read the documentation. If you diagnose this, just close the bug with enough information to let the user correct their problem (give pointers to the good documentation and so on). If the same report comes up again and again you may ask yourself if the documentation is good enough or if the program shouldn't detect its misuse in order to give an informative error message. This is an issue that may need to be brought up with the upstream author.
de: Entscheiden Sie, ob der Bericht einem echten Fehler entspricht oder nicht. Manchmal rufen Anwender ein Programm nur auf die falsche Art auf, da Sie die Dokumentation nicht gelesen haben. Falls Sie dies diagnostizieren, schließen Sie den Fehler einfach und stellen Sie Informationen bereit, damit der Anwender sein Problem lösen kann (verweisen Sie auf die gute Dokumentation und so weiter). Falls der gleiche Bericht immer wieder kommt, sollten Sie sich fragen, ob die Dokumentation ausreicht oder ob das Programm den falschen Gebrauch feststellen kann, um eine aussagekräftige Fehlermeldung auszugeben. Dies ist ein Thema, das Sie mit dem Originalautor angehen sollten.

en: If the bug submitter disagrees with your decision to close the bug, they may reopen it until you find an agreement on how to handle it. If you don't find any, you may want to tag the bug ``wontfix`` to let people know that the bug exists but that it won't be corrected. Please make sure that the bug submitter understands the reasons for your decision by adding an explanation to the message that adds the ``wontfix`` tag.
de: Wenn der Fehlerübermittler mit Ihrer Entscheidung, den Fehler zu schließen nicht einverstanden ist, wird er möglicherweise erneut geöffnet, bis Sie eine Vereinbarung zur Behandlung des Fehlers gefunden haben. Wenn Sie keine Übereinkunft finden, möchten Sie möglicherweise den Fehler "wontfix" markieren, um die Leute wissen zu lassen, dass der Fehler vorhanden ist, aber nicht behoben wird. Stellen Sie sicher, dass der Fehlerübermittler die Gründe für Ihre Entscheidung versteht, indem Sie der Nachricht, in der das Tag ``wontfix`` hinzugefügt wird, eine Erklärung hinzufügen.

en: If this situation is unacceptable, you (or the submitter) may want to require a decision of the technical committee by filing a new bug against the ``tech-ctte`` pseudo-package with a summary of the situation. Before doing so, please read the `recommended procedure <https://www.debian.org/devel/tech-ctte>`__.
de: Wenn diese Situation nicht akzeptabel ist, möchten Sie (oder der Einreicher) möglicherweise eine Entscheidung des technischen Komitees verlangen, indem Sie einen neuen Fehler gegen das Pseudopaket "tech-ctte" mit einer Zusammenfassung der Situation einreichen. Bevor Sie dies tun, lesen Sie bitte das `hierzu empfohlene Verfahren <https://www.debian.org/devel/tech-ctte>`__.

en: If the bug is real but it's caused by another package, just reassign the bug to the right package. If you don't know which package it should be reassigned to, you should ask for help on :ref:`irc-channels` or on ``debian-devel@lists.debian.org``. Please inform the maintainer(s) of the package you reassign the bug to, for example by Cc:ing the message that does the reassign to *packagename*\ ``@packages.debian.org`` and explaining your reasons in that mail. Please note that a simple reassignment is *not* e-mailed to the maintainers of the package being reassigned to, so they won't know about it until they look at a bug overview for their packages.
de: Falls der Fehler zwar echt ist, jedoch ein anderes Paket betrifft, weisen Sie ihn einfach dem richtigen Paket zu. Falls Sie nicht wissen, an welches Paket er zugewiesen werden soll, sollten Sie im :ref:`irc-channels` oder auf ``debian-devel@lists.debian.org`` nach Hilfe fragen. Bitte informieren Sie den/die Paketbetreuer des Pakets, dem Sie den Fehler zuweisen, zum Beispiel indem Sie eine Kopie der E-Mail senden, die das erneute Zuweisen an *Paketname*\ ``@packages.debian.org`` vornimmt und erläutern Sie Ihre Beweggründe. Bitte beachten Sie, dass beim einfachen Zuweisen des Fehlers an ein anderes Paket der Betreuer dieses Pakets *keine* Nachricht davon erhält, so dass er nichts davon erfährt, bis er in die Fehlerübersicht seiner Pakete schaut.

en: If the bug affects the operation of your package, please consider cloning the bug and reassigning the clone to the package that really causes the behavior. Otherwise, the bug will not be shown in your package's bug list, possibly causing users to report the same bug over and over again. You should block "your" bug with the reassigned, cloned bug to document the relationship.
de: Falls der Fehler die Arbeit Ihres Pakets beeinflusst, denken Sie bitte daran, den Fehler zu klonen und den Klon dem Paket zuzuweisen, das das Verhalten tatsächlich verursacht. Andernfalls wird der Fehler nicht in Ihrer Liste der Paketfehler aufgeführt, was Anwender dazu veranlasst, den gleichen Fehler immer wieder zu melden. Sie sollten "Ihren" Fehler mit dem neu zugewiesenen, geklonten Fehler blockieren, um die Beziehung zu dokumentieren.

en: Sometimes you also have to adjust the severity of the bug so that it matches our definition of the severity. That's because people tend to inflate the severity of bugs to make sure their bugs are fixed quickly. Some bugs may even be dropped to wishlist severity when the requested change is just cosmetic.
de: Manchmal müssen Sie außerdem den Schweregrad des Fehlers anpassen, so dass er der Debian-Definition entspricht. Dies geschieht deshalb, weil Leute die Dringlichkeit der Fehler erhöhen, um sicherzustellen, dass ihre Fehler rasch behoben werden. Einige Fehler können sogar auf den Schweregrad "wishlist" abgesenkt werden, wenn die angefragte Änderung nur kosmetischer Natur ist.

en: If the bug is real but the same problem has already been reported by someone else, then the two relevant bug reports should be merged into one using the merge command of the BTS. In this way, when the bug is fixed, all of the submitters will be informed of this. (Note, however, that emails sent to one bug report's submitter won't automatically be sent to the other report's submitter.) For more details on the technicalities of the merge command and its relative, the unmerge command, see the BTS control server documentation.
de: Falls der Fehler echt ist, das gleiche Problem aber bereits von jemand anderem gemeldet wurde, dann sollten die beiden relevanten Fehler mit dem Befehl "merge" des BTS zu einem zusammengeführt werden. Auf diese Art werden alle Absender des Fehlers informiert, wenn er behoben wurde. (Beachten Sie jedoch, dass E-Mails, die an den Absender eines Fehlerberichts gesandt werden, nicht automatisch an die Absender der anderen Berichte geschickt werden.) Weitere Details über die Form des "merge"-Befehls und des verwandten Befehls "unmerge" finden Sie in der Dokumentation des BTS-Steuerungs-Servers.

en: The bug submitter may have forgotten to provide some information, in which case you have to ask them for the required information. You may use the ``moreinfo`` tag to mark the bug as such. Moreover if you can't reproduce the bug, you tag it ``unreproducible``. Anyone who can reproduce the bug is then invited to provide more information on how to reproduce it. After a few months, if this information has not been sent by someone, the bug may be closed.
de: Der Absender des Fehlerberichts könnte vergessen haben, einige Informationen bereitzustellen. In diesem Fall müssen Sie die benötigten Informationen bei ihm erfragen. Sie könnten die Kennzeichnung ``moreinfo`` benutzen, um den Fehler entsprechend zu markieren. Außerdem können Sie den Fehler, falls sie ihn nicht reproduzieren können, als ``unreproducible`` kennzeichnen. Jeder, der den Fehler reproduzieren kann, ist dann eingeladen, weitere Informationen bereitzustellen, wie er reproduziert werden kann. Nach ein paar Monaten kann der Fehler geschlossen werden, falls diese Information von niemandem gesandt wird.

en: If the bug is related to the packaging, you just fix it. If you are not able to fix it yourself, then tag the bug as ``help``. You can also ask for help on ``debian-devel@lists.debian.org`` or ``debian-qa@lists.debian.org``. If it's an upstream problem, you have to forward it to the upstream author. Forwarding a bug is not enough, you have to check at each release if the bug has been fixed or not. If it has, you just close it, otherwise you have to remind the author about it. If you have the required skills you can prepare a patch that fixes the bug and send it to the author at the same time. Make sure to send the patch to the BTS and to tag the bug as ``patch``.
de: Falls sich der Fehler auf die Paketierung bezieht, beheben Sie ihn einfach. Falls Sie ihn nicht selbst beheben können, kennzeichnen Sie den Fehler mit ``help``. Sie können außerdem auf ``debian-devel@lists.debian.org`` oder ``debian-qa@lists.debian.org`` um Hilfe ersuchen. Falls es ein Problem der Originalautoren ist, müssen Sie es an die Originalautoren weiterleiten. Es reicht nicht aus, den Fehler nur weiterzuleiten, Sie müssen bei jeder Veröffentlichung prüfen, ob der Fehler behoben wurde oder nicht. Falls dies der Fall ist, schließen Sie ihn, andernfalls müssen Sie den Autor später daran erinnern. Falls Sie über die erforderlichen Fähigkeiten verfügen, können Sie einen Patch vorbereiten, der den Fehler behebt und ihn dem Autor mitschicken. Stellen Sie sicher, dass Sie den Patch an das BTS senden und den Fehler mit ``patch`` kennzeichnen.

en: If you have fixed a bug in your local copy, or if a fix has been committed to the VCS repository, you may tag the bug as ``pending`` to let people know that the bug is corrected and that it will be closed with the next upload (add the ``closes:`` in the ``changelog``). This is particularly useful if you are several developers working on the same package.
de: Falls Sie einen Fehler in Ihrer lokalen Kopie behoben haben oder eine Fehlerbehebung in das VCS-Repository übertragen wird, können Sie den Fehler als ``pending`` kennzeichnen, um die Leute wissen zu lassen, dass der Fehler behoben ist und mit dem nächsten Upload geschlossen wird (fügen Sie ``closes:`` dem ``changelog`` hinzu). Dies ist besonders nützlich, falls Sie zusammen mit mehreren Entwicklern am Paket arbeiten.

en: Once a corrected package is available in the archive, the bug should be closed indicating the version in which it was fixed. This can be done automatically; read :ref:`upload-bugfix`.
de: Sobald ein korrigiertes Paket im Archiv verfügbar ist, sollte der Fehler geschlossen und die Version, in der er behoben wurde, angegeben werden. Dies kann automatisch geschehen – lesen Sie :ref:`upload-bugfix`.

en: When bugs are closed by new uploads
de: Wann Fehler durch neue Uploads geschlossen werden

en: As bugs and problems are fixed in your packages, it is your responsibility as the package maintainer to close these bugs. However, you should not close a bug until the package which fixes the bug has been accepted into the Debian archive. Therefore, once you get notification that your updated package has been installed into the archive, you can and should close the bug in the BTS. Also, the bug should be closed with the correct version.
de: Sobald Fehler und Probleme in Ihren Paketen behoben werden, liegt es in Ihrer Verantwortung als Paketbetreuer, diese Fehler zu schließen. Sie sollten jedoch keinen Fehler schließen, bis das Paket, das den Fehler schließt, im Debian-Archiv akzeptiert wurde. Daher können und sollen Sie, sobald Sie die Benachrichtigung erhalten, dass Ihr aktualisiertes Paket in das Archiv installiert wurde, den Fehler im BTS schließen. Außerdem sollte der Fehler mit der korrekten Version geschlossen werden.

en: However, it's possible to avoid having to manually close bugs after the upload — just list the fixed bugs in your ``debian/changelog`` file, following a certain syntax, and the archive maintenance software will close the bugs for you. For example:
de: Es ist jedoch möglich, das manuelle Schließen von Fehlern nach dem Upload zu vermeiden – führen Sie die behobenen Fehler in Ihrer ``debian/changelog``-Datei auf. Folgen Sie dabei einer bestimmten Syntax, dann wird die Verwaltungssoftware die Fehler für Sie schließen. Zum Beispiel:

en: Technically speaking, the following Perl regular expression describes how bug closing changelogs are identified:
de: Technisch gesehen beschreibt der folgende reguläre Perl-Ausdruck, wie das Schließen von Fehlern in Änderungsprotokollen identifiziert wird:

en: We prefer the ``closes: #``\ *XXX* syntax, as it is the most concise entry and the easiest to integrate with the text of the ``changelog``. Unless specified differently by the ``-v``-switch to ``dpkg-buildpackage``, only the bugs closed in the most recent changelog entry are closed (basically, exactly the bugs mentioned in the changelog-part in the ``.changes`` file are closed).
de: Die Syntax ``closes: #``\ *XXX* wird bevorzugt, da sie die kürzeste Art des Eintrags ist und am einfachsten in dem Text von ``changelog`` integriert werden kann. Falls nicht durch den Schalter ``-v`` von ``dpkg-buildpackage`` etwas anderes angegeben wurde, werden nur die Fehler im aktuellsten Eintrag des Änderungsprotokolls geschlossen (grundsätzlich werden exakt die Fehler geschlossen, die in der Datei ``.changes`` im "changelog"-Teil genannt werden).

en: Historically, uploads identified as :ref:`nmu` were tagged ``fixed`` instead of being closed, but that practice was ceased with the advent of version-tracking. The same applied to the tag ``fixed-in-experimental``.
de: Früher wurden Uploads, die als :ref:`nmu` erkannt wurden, als ``fixed`` statt als "closed" gekennzeichnet, aber diese Praxis wurde mit dem Beginn der Versionsverfolgung eingestellt. Das gleiche geschah mit der Markierung ``fixed-in-experimental``.

en: If you happen to mistype a bug number or forget a bug in the changelog entries, don't hesitate to undo any damage the error caused. To reopen wrongly closed bugs, send a ``reopen`` *XXX* command to the bug tracking system's control address, ``control@bugs.debian.org``. To close any remaining bugs that were fixed by your upload, email the ``.changes`` file to *XXX*\ ``-done@bugs.debian.org``, where *XXX* is the bug number, and put Version: *YYY* and an empty line as the first two lines of the body of the email, where *YYY* is the first version where the bug has been fixed.
de: Sollte es passiert sein, dass Sie eine falsche Bugnummer benutzt oder einen Bugreport in der Changelog Datei vergessen haben dann zögern Sie nicht diesen Fehler rückgängig zu machen. Um falsch geschlossene Bugreports wieder zu öffnen, senden Sie das Kommando ``reopen`` *XXX* an die BTS-Kontrolladresse ``control@bugs.debian.org``. Um noch ausstehende Bugreports, die durch Ihren Upload gefixt worden sind, zu schließen, senden Sie die ``.changes`` Datei an *XXX*\ ``-done@bugs.debian.org``, wobei *XXX* der Bugnummer entspricht. Fügen Sie Version: *YYY* in die erste Zeile gefolgt von einer Leerzeile (also insgesamt zwei Zeilen) in den Body der E-Mail, *YYY* entspricht der ersten Paketversion in der der gemeldete Fehler gefixt worden ist.

en: Bear in mind that it is not obligatory to close bugs using the changelog as described above. If you simply want to close bugs that don't have anything to do with an upload you made, do it by emailing an explanation to *XXX*\ ``-done@bugs.debian.org``. Do **not** close bugs in the changelog entry of a version if the changes in that version of the package don't have any bearing on the bug.
de: Behalten Sie im Gedächnis, dass es nicht verpflichend ist, Fehler unter Benutzung des Änderungsprotokolls zu schließen, wie oben beschrieben. Falls Sie nur einfach einen Fehler schließen möchten, der mit dem von Ihnen getätigten Upload nichts zu tun hat, können Sie dies durch Mailen einer Erläuterung an *XXX*\ ``-done@bugs.debian.org`` erledigen. Schließen Sie **keine** Fehler im Änderungsprotokolleintrag einer Version, wenn die Änderungen in dieser Version des Pakets keine Bedeutung für den Fehler haben.

en: For general information on how to write your changelog entries, see :ref:`bpp-debian-changelog`.
de: Allgemeine Informationen über das Verfassen von Änderungsprotokolleinträgen finden Sie unter :ref:`bpp-debian-changelog`.

en: Handling security-related bugs
de: Handhabung von sicherheitsrelevanten Fehlern

en: Due to their sensitive nature, security-related bugs must be handled carefully. The Debian Security Team exists to coordinate this activity, keeping track of outstanding security problems, helping maintainers with security problems or fixing them themselves, sending security advisories, and maintaining ``security.debian.org``.
de: Aufgrund ihrer sensiblen Natur müssen sicherheitsrelevante Fehler vorsichtig gehandhabt werden. Das Debian-Sicherheits-Team existiert, um diese Aktivitäten zu koordinieren, ausstehende Sicherheitsprobleme zu verfolgen, Paketbetreuern bei Sicherheitsproblemen zu helfen oder sie selbst zu beheben, Sicherheitsankündigungen zu versenden und ``security.debian.org`` zu verwalten.

en: When you become aware of a security-related bug in a Debian package, whether or not you are the maintainer, collect pertinent information about the problem, and promptly contact the security team by emailing ``team@security.debian.org``. If desired, email can be encrypted with the Debian Security Contact key, see https://www.debian.org/security/faq#contact\  for details. **DO NOT UPLOAD** any packages for ``stable`` without contacting the team. Useful information includes, for example:
de: Wenn Sie einen sicherheitsrelevanten Fehler in einem Debian-Paket bemerken - auch wenn Sie nicht der Betreuer sind - sammeln Sie sachdienliche Informationen über das Problem und kontaktieren Sie umgehend das Sicherheits-Team per E-Mail an ``team@security.debian.org``. Sie können die E-Mail, falls gewünscht, mit dem Debian-Security-Contact-Schlüssel chiffrieren. Einzelheiten finden Sie unter https://www.debian.org/security/faq#contact\ . LADEN SIE **KEINE** Pakete für ``Stable`` hoch, ohne das Team zu kontaktieren. Nützliche Informationen sind beispielsweise:

en: Whether or not the bug is already public.
de: Ob der Fehler bereits öffentlich ist oder nicht.

en: Which versions of the package are known to be affected by the bug. Check each version that is present in a supported Debian release, as well as ``testing`` and ``unstable``.
de: Von welchen Versionen des Pakets bekannt ist, dass sie vom Fehler betroffen sind. Prüfen Sie jede Version, die es in einem unterstützten Debian-Release gibt, ebenso wie ``Testing`` und ``Unstable``.

en: The nature of the fix, if any is available (patches are especially helpful)
de: Die Art der Fehlerbehebung, falls verfügbar (Patches sind besonders hilfreich).

en: Any fixed packages that you have prepared yourself (send the resulting debdiff or alternatively only the ``.diff.gz`` and ``.dsc`` files and read :ref:`bug-security-building` first)
de: Jedes korrigierte Paket das Sie für sich selbst vorbereitet haben (senden Sie das resultierende Debdiff oder alternativ nur die Dateien ``.diff.gz`` und ``.dsc`` und lesen Sie zuerst :ref:`bug-security-building`).

en: Any assistance you can provide to help with testing (exploits, regression testing, etc.)
de: Jede Unterstützung die Sie zur Hilfe beim Testen anbieten können (Exploits, Regressionstests etc.).

en: Any information needed for the advisory (see :ref:`bug-security-advisories`)
de: Jede Information die für die Ankündigung nötig ist (siehe :ref:`bug-security-advisories`).

en: As the maintainer of the package, you have the responsibility to maintain it, even in the stable release. You are in the best position to evaluate patches and test updated packages, so please see the sections below on how to prepare packages for the Security Team to handle.
de: Als Betreuer des Pakets sind sie verantwortlich für dessen Verwaltung, sogar im Stable-Release. Sie sind in der besten Position, um Patches zu beurteilen und aktualisierte Pakete zu testen, sehen Sie daher bitte in die folgenden Abschnitte, wie Pakete vorbereitet werden, damit sie vom Sicherheits-Team bearbeitet werden können.

en: The security team maintains a central database, the `Debian Security Tracker <https://security-tracker.debian.org/>`__. This contains all public information that is known about security issues: which packages and versions are affected or fixed, and thus whether stable, testing and/or unstable are vulnerable. Information that is still confidential is not added to the tracker.
de: Das Sicherheits-Team verwaltet eine zentrale Datenbank, den `Debian Security Tracker <https://security-tracker.debian.org/>`__. Diese enthält alle öffentlich verfügbaren Informationen, die über Sicherheitsthemen verfügbar sind: welche Pakete und Versionen betroffen oder korrigiert sind und ob daher Stable, Testing und/oder Unstable angreifbar sind. Informationen, die immer noch vertraulich sind, werden nicht zur Datenbank hinzugefügt.

en: You can search it for a specific issue, but also on package name. Look for your package to see which issues are still open. If you can, please provide more information about those issues, or help to address them in your package. Instructions are on the tracker web pages.
de: Sie können diese nach einem bestimmten Thema durchsuchen, aber auch nach einem Paketnamen. Schauen Sie nach Ihrem Paket, um zu sehen, welche Themen noch offen sind. Bitte stellen Sie, falls Sie können, weitere Informationen über diese Themen bereit oder helfen Sie, diese in Ihrem Paket zu behandeln. Anweisungen finden Sie auf den Webseiten des Security Trackers.

en: Confidentiality
de: Vertraulichkeit

en: Unlike most other activities within Debian, information about security issues must sometimes be kept private for a time. This allows software distributors to coordinate their disclosure in order to minimize their users' exposure. Whether this is the case depends on the nature of the problem and corresponding fix, and whether it is already a matter of public knowledge.
de: Anders als bei den meisten anderen Aktivitäten innerhalb von Debian werden Informationen über Sicherheitsthemen eine Zeit lang geheim gehalten. Dies erlaubt es Software-Vertreibern, ihre Offenlegung zu koordinieren, um die Belastung ihrer Anwender zu minimieren. Ob dies der Fall ist, hängt von der Natur des Problems und der zugehörigen Fehlerbehebung ab, und ob die Angelegenheit bereits an die Öffentlichkeit durchgesickert ist.

en: There are several ways developers can learn of a security problem:
de: Es gibt mehrere Möglichkeiten, wie Entwickler von einem Sicherheitsproblem erfahren:

en: they notice it on a public forum (mailing list, web site, etc.)
de: sie bemerken es in einem öffentlichen Forum (Maillingliste, Website etc.)

en: someone files a bug report
de: jemand verfasst einen Fehlerbericht

en: someone informs them via private email
de: jemand informiert sie per privater E-Mail

en: In the first two cases, the information is public and it is important to have a fix as soon as possible. In the last case, however, it might not be public information. In that case there are a few possible options for dealing with the problem:
de: In den ersten beiden Fällen ist die Information öffentlich und es ist wichtig, so schnell wie möglich eine Fehlerbehebung zu haben. Im letzen Fall könnte die Information nicht öffentlich sein, In diesem Fall gibt es ein paar mögliche Optionen, mit dem Problem umzugehen:

en: If the security exposure is minor, there is sometimes no need to keep the problem a secret and a fix should be made and released.
de: Falls die Offenlegung der Sicherheit gering ist, ist es manchmal nicht nötig, das Problem geheim zu halten und es sollte eine Fehlerbehebung erstellt und veröffentlicht werden.

en: If the problem is severe, it is preferable to share the information with other vendors and coordinate a release. The security team keeps in contact with the various organizations and individuals and can take care of that.
de: Falls das Problem ernst ist, sollte diese Information vorzugsweise mit anderen Anbietern geteilt werden, um eine Veröffentlichung zu koordinieren. Das Sicherheits-Team hält Kontakt zu verschiedenen Organisationen und Einzelpersonen, die sich darum kümmern.

en: In all cases if the person who reports the problem asks that it not be disclosed, such requests should be honored, with the obvious exception of informing the security team in order that a fix may be produced for a stable release of Debian. When sending confidential information to the security team, be sure to mention this fact.
de: Wenn die Person, die das Problem meldet, darum bittet, dass es nicht offengelegt wird, sollte dieser Anfrage in jedem Fall Rechnung getragen werden, mit der einleuchtenden Ausnahme, das Sicherheits-Team zu informieren, damit für ein Debian-Stable-Release eine Fehlerbehebung vorbereitet werden kann. Vergessen Sie nicht, diese Tatsache zu erwähnen, wenn vertrauliche Informationen zum Sicherheits-Team gesandt werden.

en: Please note that if secrecy is needed you may not upload a fix to ``unstable`` (or anywhere else, such as a public VCS repository). It is not sufficient to obfuscate the details of the change, as the code itself is public, and can (and will) be examined by the general public.
de: Bitte beachten Sie, dass Sie keine Fehlerbehebung nach ``Unstable`` (oder an eine andere Stelle, wie ein öffentliches VCS-Repository) senden können, wenn Geheimhaltung nötig ist. Es reicht nicht aus, die Einzelheiten der Änderung zu verschleiern, da der Code selbst öffentlich ist und von der Allgemeinheit untersucht werden kann (und soll).

en: There are two reasons for releasing information even though secrecy is requested: the problem has been known for a while, or the problem or exploit has become public.
de: Es gibt zwei Gründe, Informationen sogar dann zu veröffentlichen, wenn um Geheimhaltung gebeten wurde: Das Problem ist bereits seit einer Weile bekannt oder es wurde ein Exploit veröffentlicht.

en: The Security Team has a PGP-key to enable encrypted communication about sensitive issues. See the `Security Team FAQ <https://www.debian.org/security/faq#contact>`__ for details.
de: Das Sicherheits-Team hat einen PGP-Schlüssel, um verschlüsselte Kommunikation über sensible Themen zu ermöglichen. Einzelheiten finden Sie in der `Debian Sicherheits-FAQ <https://www.debian.org/security/faq#contact>`__.

en: Security Advisories
de: Sicherheitsankündigungen

en: Security advisories are only issued for the current, released stable distribution, and *not* for ``testing`` or ``unstable``. When released, advisories are sent to the ``debian-security-announce@lists.debian.org`` mailing list and posted on `the security web page <https://www.debian.org/security/>`__. Security advisories are written and posted by the security team. However they certainly do not mind if a maintainer can supply some of the information for them, or write part of the text. Information that should be in an advisory includes:
de: Sicherheitsankündigungen werden nur für die aktuelle, veröffentlichte Stable-Distribution ausgegeben und *nicht* für ``Testing`` oder ``Unstable``. Wenn Sie veröffentlicht werden, werden sie an die Mailingliste ``debian-security-announce@lists.debian.org`` geschickt und auf der Website für `Sicherheits-Informationen <https://www.debian.org/security/>`__ veröffentlicht. Sicherheitsankündigungen werden vom Sicherheits-Team verfasst und verschickt. Es ist natürlich nicht von Nachteil, wenn ein Paketbetreuer einige Informationen dazu bereitstellen kann oder einen Teil des Textes verfasst. Informationen, die in einer Ankündigung enthalten sein sollten:

en: A description of the problem and its scope, including:
de: Eine Beschreibung des Problems und seines Geltungsbereichs, einschließlich:

en: The type of problem (privilege escalation, denial of service, etc.)
de: Dem Typ des Problems (Rechteausweitung, Dienstverweigerung etc.)

en: What privileges may be gained, and by whom (if any)
de: Welche Privilegien können erlangt werden und durch wen (falls zutreffend)?

en: How it can be exploited
de: Wie kann dies ausgenutzt werden?

en: Whether it is remotely or locally exploitable
de: Ist es aus der Ferne oder lokal ausnutzbar?

en: How the problem was fixed
de: Wie wurde das Problem gelöst?

en: This information allows users to assess the threat to their systems.
de: Diese Informationen ermöglichen es Anwendern, die Bedrohung ihrer Systeme zu beurteilen.

en: Version numbers of affected packages
de: Versionsnummern betroffener Pakete

en: Version numbers of fixed packages
de: Versionsnummern korrigierter Pakete

en: Information on where to obtain the updated packages (usually from the Debian security archive)
de: Informationen, woher man die aktualisierten Pakete bekommen kann (üblicherweise aus dem Debian-Sicherheitsarchiv)

en: References to upstream advisories, `CVE <https://cve.mitre.org>`__ identifiers, and any other information useful in cross-referencing the vulnerability
de: Referenzen zu Ankündigungen der Originalautoren, `CVE <https://cve.mitre.org>`__-Bezeichner und jede andere nützliche Information in Querverweisen zur Schwachstelle

en: Preparing packages to address security issues
de: Pakete vorbereiten, um Sicherheitsthemen anzugehen

en: One way that you can assist the security team in their duties is to provide them with fixed packages suitable for a security advisory for the stable Debian release.
de: Eine Möglichkeit, dem Sicherheits-Team bei seinen Aufgaben zu helfen, besteht darin, es mit korrigierten Paketen zu versorgen, die für eine Sicherheitsankündigung für das Stable-Release geeignet sind.

en: When an update is made to the stable release, care must be taken to avoid changing system behavior or introducing new bugs. In order to do this, make as few changes as possible to fix the bug. Users and administrators rely on the exact behavior of a release once it is made, so any change that is made might break someone's system. This is especially true of libraries: make sure you never change the API (Application Program Interface) or ABI (Application Binary Interface), no matter how small the change.
de: Wenn eine Aktualisierung am Stable-Release vorgenommen wird, muss dabei behutsam vorgegangen werden, damit eine Änderung des Systemverhaltens vermieden wird und keine neuen Fehler eingeschleppt werden. Um dies zu erreichen, ändern Sie so wenig wie möglich, wenn Sie Fehler beheben. Anwender und Administratoren verlassen sich auf das exakte Verhalten des Releases, nachdem es veröffentlicht wurde, so dass jegliche vorgenommene Änderung das System von jemandem stören könnte. Dies trifft im Besonderen auf Bibliotheken zu: Stellen Sie sicher, dass Sie nie das API (Application Program Interface) oder das ABI (Application Binary Interface) ändern, egal wie klein die Änderung auch sein mag.

en: This means that moving to a new upstream version is not a good solution. Instead, the relevant changes should be back-ported to the version present in the current stable Debian release. Generally, upstream maintainers are willing to help if needed. If not, the Debian security team may be able to help.
de: Dies bedeutet, dass das Umschwenken auf eine neue Originalversion keine gute Lösung ist. Stattdessen sollten die passenden Änderungen auf die Versionen im aktuellen Debian-Stable-Release zurückportiert werden. Generell sind Original-Paketbetreuer bereit zu helfen, wenn nötig. Falls nicht, könnte das Debian-Sicherheits-Team in der Lage sein zu helfen.

en: In some cases, it is not possible to back-port a security fix, for example when large amounts of source code need to be modified or rewritten. If this happens, it may be necessary to move to a new upstream version. However, this is only done in extreme situations, and you must always coordinate that with the security team beforehand.
de: In manchen Fällen ist es unmöglich, eine Sicherheitskorrektur zurück zu portieren, zum Beispiel, wenn große Teile des Quellcodes geändert oder überschrieben werden müssten. Falls dies der Fall ist, könnte es nötig sein, zu einer neuen Originalversion zu wechseln. Dies wird jedoch nur in extremen Situationen getan und Sie müssen dies immer vorab mit dem Sicherheits-Team abstimmen.

en: Related to this is another important guideline: always test your changes. If you have an exploit available, try it and see if it indeed succeeds on the unpatched package and fails on the fixed package. Test other, normal actions as well, as sometimes a security fix can break seemingly unrelated features in subtle ways.
de: Darauf bezieht sich eine weitere wichtige Regel: Testen Sie immer Ihre Änderungen. Falls Sie über ein Exploit verfügen, probieren Sie es aus und kontrollieren Sie, ob es wirklich beim nicht korrigierten Paket erfolgreich ist und am korrigierten Paket scheitert. Testen Sie auch andere normale Aktionen, da eine Sicherheitskorrektur manchmal scheinbar nicht betroffene Funktionen auf subtile Weise stört.

en: Do **NOT** include any changes in your package which are not directly related to fixing the vulnerability. These will only need to be reverted, and this wastes time. If there are other bugs in your package that you would like to fix, make an upload to proposed-updates in the usual way, after the security advisory is issued. The security update mechanism is not a means for introducing changes to your package which would otherwise be rejected from the stable release, so please do not attempt to do this.
de: Nehmen Sie **KEINE** Änderungen in Ihr Paket auf, die sich nicht direkt auf die Behebung der Schwachstelle beziehen. Diese müssten rückgängig gemacht werden, was Zeit kostet. Falls es in Ihrem Paket andere Fehler gibt, die Sie gerne beheben würden, machen Sie auf dem üblichen Weg ein Upload nach "proposed-updates", nachdem die Sicherheitsankündigung veröffentlicht wurde. Der Sicherheits-Aktualisierungsmechanismus ist kein Mittel, um Änderungen an Ihrem Paket einzuführen, die andernfalls vom Stable-Release abgelehnt worden wären, unterlassen sie dies also.

en: Review and test your changes as much as possible. Check the differences from the previous version repeatedly (``interdiff`` from the ``patchutils`` package and ``debdiff`` from ``devscripts`` are useful tools for this, see :ref:`debdiff`).
de: Überprüfen und testen Sie Ihre Änderungen so ausgiebig wie möglich. Prüfen Sie die Unterschiede zur vorherigen Version mehrmals (``interdiff`` aus dem Paket ``patchutils`` und ``debdiff`` aus ``devscripts`` sind nützliche Werkzeuge dafür, siehe :ref:`debdiff`).

en: Be sure to verify the following items:
de: Überprüfen Sie unbedingt folgende Elemente:

en: **Target the right distribution** in your ``debian/changelog``: |codename-security| (e.g. |codename-stable-security|). Do not target *distribution*\ ``-proposed-updates`` or ``stable``!
de: **Geben Sie die richtige Distribution als Ziel** in Ihrem ``debian/changelog`` an: |codename-security| (z.B. |codename-stable-security|). Geben Sie nicht *Distribution*\ ``-proposed-updates`` oder ``Stable`` als Ziel an!

en: Make descriptive, meaningful changelog entries. Others will rely on them to determine whether a particular bug was fixed. Add ``closes:`` statements for any **Debian bugs** filed. Always include an external reference, preferably a **CVE identifier**, so that it can be cross-referenced. However, if a CVE identifier has not yet been assigned, do not wait for it but continue the process. The identifier can be cross-referenced later.
de: Verfassen Sie anschauliche, aussagekräftige Änderungsprotokolleinträge. Andere werden sich darauf verlassen, um zu bestimmen, ob ein bestimmter Fehler behoben wurde. Fügen Sie für alle eingereichten **Debian-Fehler** ``closes:``-Angaben hinzu. Beziehen Sie immer einen externen Bezug ein, vorzugsweise einen **CVE-Bezeichner**, so dass Querverweise darauf möglich sind. Wenn ein CVE-Bezeichner jedoch noch nicht zugewiesen wurde, warten Sie nicht darauf, sondern fahren Sie mit dem Prozess fort. Ein späterer Querverweis auf den Bezeichner ist möglich.

en: Make sure the **version number** is proper. It must be greater than the current package, but less than package versions in later distributions. If in doubt, test it with ``dpkg --compare-versions``. Be careful not to re-use a version number that you have already used for a previous upload, or one that conflicts with a binNMU. The convention is to append ``+deb``\ *X*\ ``u1`` (where *X* is the major release number), e.g. |version1-revision-deb-version-stable-u1|, of course increasing 1 for any subsequent uploads.
de: Stellen Sie sicher, dass die **Versionsnummer** angemessen ist. Sie muss größer als die des aktuellen Pakets, aber kleiner als die von Paketversionen in neueren Distributionen sein. Falls es Zweifel gibt, prüfen Sie es mit ``dpkg --compare-versions``. Seien Sie vorsichtig, dass Sie keine Versionsnummer wiederverwenden, die Sie für ein vorheriges Hochladen benutzt haben, oder eine, die Konflikte mit einem binNMU auslöst. Es ist Brauch, ``+deb``\ *X*\ ``u1`` anzuhängen (wobei *X* die Major-Release-Nummer ist), z.B. |version1-revision-deb-version-stable-u1| und natürlich muss dies bei jedem nachfolgendem Hochladen um eins zu erhöht werden.

en: Unless the upstream source has been uploaded to ``security.debian.org`` before (by a previous security update), build the upload **with full upstream source** (``dpkg-buildpackage -sa``). If there has been a previous upload to ``security.debian.org`` with the same upstream version, you may upload without upstream source (``dpkg-buildpackage -sd``).
de: Sofern der Originalquellcode nicht vorher nach ``security.debian.org`` hochgeladen wurde (durch eine vorhergehende Sicherheitsaktualisierung), erstellen Sie den Upload **aus vollständigen Originalquellen** (``dpkg-buildpackage -sa``). Falls es einen vorhergehenden Upload nach ``security.debian.org`` mit der gleichen Originalversion gab, könnten Sie ohne den Originalquellcode hochladen (``dpkg-buildpackage -sd``).

en: Be sure to use the **exact same ``*.orig.tar.{gz,bz2,xz}``** as used in the normal archive, otherwise it is not possible to move the security fix into the main archives later.
de: Tragen Sie Sorge, dass die **exakt gleiche *.orig.tar.{gz,bz2,xz}**-Datei wie im normalen Archiv benutzt wird. Andernfalls ist es nicht möglich, die Sicherheitskorrektur später in die Hauptarchive zu verschieben.

en: Build the package on a **clean system** which only has packages installed from the distribution you are building for. If you do not have such a system yourself, you can use a debian.org machine (see :ref:`server-machines`) or setup a chroot (see :ref:`pbuilder` and :ref:`debootstrap`).
de: Erstellen Sie das Paket auf einem **sauberen System**, auf dem nur Pakete der Distribution installiert sind, für die Sie das Paket erstellen. Falls Sie selbst nicht über ein solches System verfügen, können Sie eine debian.org-Maschine verwenden (siehe :ref:`server-machines`) oder richten Sie ein Chroot ein (siehe :ref:`pbuilder` und :ref:`debootstrap`).

en: Uploading the fixed package
de: Hochladen eines korrigierten Pakets

en: Do **NOT** upload a package to the security upload queue (on ``*.security.upload.debian.org``) without prior authorization from the security team. If the package does not exactly meet the team's requirements, it will cause many problems and delays in dealing with the unwanted upload.
de: Laden Sie **KEIN** Paket in die Sicherheits-Upload-Warteschlange (auf ``security-master.debian.org``) ohne vorherige Genehmigung des Sicherheits-Teams. Falls das Paket nicht exakt den Anforderungen des Teams entspricht, wird es viele Probleme und Verzögerungen im Umgang mit dem unerwünschten Upload verursachen.

en: Do **NOT** upload your fix to ``proposed-updates`` without coordinating with the security team. Packages from ``security.debian.org`` will be copied into the ``proposed-updates`` directory automatically. If a package with the same or a higher version number is already installed into the archive, the security update will be rejected by the archive system. That way, the stable distribution will end up without a security update for this package instead.
de: Laden Sie ihre Fehlerbehebung **NICHT** nach ``proposed-updates`` ohne Abstimmung mit dem Sicherheits-Team hoch. Pakete von ``security.debian.org`` werden automatisch direkt in das Verzeichnis ``proposed-updates`` kopiert. Falls bereits ein Paket mit der gleichen oder einer höheren Versionsnummer im Archiv installiert ist, wird die Sicherheitsaktualisierung durch das Archivsystem abgelehnt. Stattdessen endet auf diese Weise die Distribution Stable ohne eine Sicherheitsaktualisierung für dieses Paket.

en: Once you have created and tested the new package and it has been approved by the security team, it needs to be uploaded so that it can be installed in the archives. For security uploads, the place to upload to is ``ftp://ftp.security.upload.debian.org/pub/SecurityUploadQueue/``.
de: Sobald Sie das neue Paket erstellt und getestet haben und es vom Sicherheits-Team zugelassen wurde, muss es hochgeladen werden, so dass es in den Archiven installiert werden kann. Sicherheits-Uploads werden dabei nach ``ftp://security-master.debian.org/pub/SecurityUploadQueue/`` hochgeladen.

en: Once an upload to the security queue has been accepted, the package will automatically be built for all architectures and stored for verification by the security team.
de: Sobald ein Upload in die Sicherheitheitswarteschlange akzeptiert wurde, wird das Paket automatisch für alle Architekturen erstellt und zur Überprüfung durch das Sicherheits-Team gespeichert.

en: Uploads that are waiting for acceptance or verification are only accessible by the security team. This is necessary since there might be fixes for security problems that cannot be disclosed yet.
de: Auf Uploads, die auf Zustimmung oder Prüfung warten, kann nur das Sicherheits-Team zugreifen. Dies ist nötig, da es sich um Fehlerbehebungen für Sicherheitsprobleme handeln könnte, die noch nicht offengelegt werden dürfen.

en: If a member of the security team accepts a package, it will be installed on ``security.debian.org`` as well as proposed for the proper *distribution*\ ``-proposed-updates`` on ``ftp-master.debian.org``.
de: Falls ein Mitglied des Sicherheits-Teams ein Paket akzeptiert, wird es auf ``security.debian.org`` installiert. Ebenso wird es für das passende *Distribution*\ ``-proposed-updates`` auf ``ftp-master.debian.org`` vorgeschlagen.

en: Moving, removing, renaming, orphaning, adopting, and reintroducing packages
de: Verschieben, Entfernen, Verwaisen, Adoptieren und Wiedereinführen von Paketen

en: Some archive manipulation operations are not automated in the Debian upload process. These procedures should be manually followed by maintainers. This chapter gives guidelines on what to do in these cases.
de: Einige Operationen zum Manipulieren von Archiven sind im Debian-Upload-Prozess nicht automatisiert. Diese Prozeduren sollten manuell durch Paketbetreuer abgewickelt werden. Dieses Kapitel gibt einen Leitfaden, was in diesen Fällen zu tun ist.

en: Moving packages
de: Pakete verschieben

en: Sometimes a package will change its section. For instance, a package from the ``non-free`` section might be GPL'd in a later version, in which case the package should be moved to ``main`` or ``contrib``. [1]_
de: Manchmal ändert ein Paket seinen Bereich. Ein Paket aus dem Bereich ``non-free`` könnte zum Beispiel in einer neueren Version unter der GPL erscheinen. In diesem Fall sollte es nach "main" oder "contrib" verschoben werden. [1]_

en: If you need to change the section for one of your packages, change the package control information to place the package in the desired section, and re-upload the package (see the `Debian Policy Manual <https://www.debian.org/doc/debian-policy/>`__ for details). You must ensure that you include the ``.orig.tar.{gz,bz2,xz}`` in your upload (even if you are not uploading a new upstream version), or it will not appear in the new section together with the rest of the package. If your new section is valid, it will be moved automatically. If it does not, then contact the ftpmasters in order to understand what happened.
de: Falls Sie für eines Ihrer Pakete den Bereich ändern müssen, ändern Sie die control-Information des Pakets, um es in den gewünschten Bereich zu platzieren und laden Sie das Paket erneut hoch (Einzelheiten finden Sie im `Debian Policy Manual <https://www.debian.org/doc/debian-policy/>`__). Sie müssen sicherstellen, dass Sie Ihrem Upload die ``.orig.tar.{gz,bz2,xz}``-Datei beifügen (sogar, wenn Sie keine neue Originalversion hochladen), sonst wird es nicht zusammen mit dem Rest des Pakets in dem neuen Bereich erscheinen. Falls Ihr neuer Bereich gültig ist, wird es automatisch verschoben. Falls dies nicht geschieht, wenden Sie sich an die Ftpmasters, damit Sie verstehen, was geschehen ist.

en: If, on the other hand, you need to change the ``subsection`` of one of your packages (e.g., ``devel``, ``admin``), the procedure is slightly different. Correct the subsection as found in the control file of the package, and re-upload that. Also, you'll need to get the override file updated, as described in :ref:`override-file`.
de: Falls Sie andererseits die ``subsection`` eines Ihrer Pakete ändern müssen (z.B. "devel", "admin"), ist die Prozedur etwas anders. Korrigieren Sie den in der control-Datei enthaltenen Unterbereich des Pakets und laden Sie es erneut hoch. Außerdem müssen Sie die Datei "override" aktualisieren, wie es in :ref:`override-file` beschrieben wird.

en: Removing packages
de: Pakete entfernen

en: If for some reason you want to completely remove a package (say, if it is an old compatibility library which is no longer required), you need to file a bug against ``ftp.debian.org`` asking that the package be removed; as with all bugs, this bug should normally have normal severity. The bug title should be in the form ``RM:`` *package [architecture list]* ``--`` *reason*, where *package* is the package to be removed and *reason* is a short summary of the reason for the removal request. *[architecture list]* is optional and only needed if the removal request only applies to some architectures, not all. Note that the ``reportbug`` will create a title conforming to these rules when you use it to report a bug against the ``ftp.debian.org`` pseudo-package.
de: Falls Sie aus irgendeinem Grund ein Paket vollständig entfernen möchten (etwa, weil es eine alte Kompatibilitätsbibliothek ist, die nicht länger erforderlich ist), müssen Sie einen Fehler gegen ``ftp.debian.org`` einreichen, in dem Sie darum bitten, das Paket zu entfernen. Wie alle Fehler sollte auch dieser standardmäßig den Schweregrad "normal" haben. Der Fehlertitel sollte die Form ``RM:`` *Paket[Architekturenliste]* ``--`` *Grund* haben, wobei *Paket* der Name des zu entfernenden Pakets und *Grund* eine kurze Zusammenfassung sein sollte, aus welchem Grund um Entfernen gebeten wird. *[Architekturenliste]* ist optional und wird nur benötigt, wenn das Entfernen lediglich einige Architekturen betrifft, aber nicht alle. Beachten Sie, dass ``reportbug`` einen Titel erstellt, der diesen Regeln entspricht, wenn Sie es benutzen, um einen Fehler des Pseudo-Pakets ``ftp.debian.org`` zu melden.

en: If you want to remove a package you maintain, you should note this in the bug title by prepending ``ROM`` (Request Of Maintainer). There are several other standard acronyms used in the reasoning for a package removal; see https://ftp-master.debian.org/removals.html\  for a complete list. That page also provides a convenient overview of pending removal requests.
de: Falls Sie ein von Ihnen betreutes Paket entfernen wollen, sollten Sie dies im Titel des Fehlerberichts durch Voranstellen von ``ROM`` (Request Of Maintainer) anmerken. Es gibt mehrere andere Standardabkürzungen, die als Grund für das Entfernen von Paketen benutzt werden. Eine komplette Liste finden Sie unter https://ftp-master.debian.org/removals.html\ . Diese Seite stellt außerdem einen praktischen Überblick über ausstehende Anfragen zum Entfernen bereit.

en: Note that removals can only be done for the ``unstable``, ``experimental`` and ``stable`` distributions. Packages are not removed from ``testing`` directly. Rather, they will be removed automatically after the package has been removed from ``unstable`` and no package in ``testing`` depends on it. (Removals from ``testing`` are possible though by filing a removal bug report against the ``release.debian.org`` pseudo-package. See :ref:`removals`.)
de: Beachten Sie, dass Pakete nur aus den Distributionen ``Unstable``, ``Experimental`` und ``Stable`` entfernt werden können. Pakete werden nicht direkt aus ``Testing`` entfernt. Sie werden vielmehr automatisch entfernt, nachdem das Paket aus ``Unstable`` entfernt wurde und in ``Testing`` kein Paket davon abhängt. (Etwas aus ``Testing`` zu entfernen, ist durch Einreichen eines Fehlerberichts an das Pseudopaket ``release.debian.org`` möglich, siehe :ref:`removals`.)

en: There is one exception when an explicit removal request is not necessary: If a (source or binary) package is no longer built from source, it will be removed semi-automatically. For a binary-package, this means if there is no longer any source package producing this binary package; if the binary package is just no longer produced on some architectures, a removal request is still necessary. For a source-package, this means that all binary packages it refers to have been taken over by another source package.
de: Es gibt eine Ausnahme, bei der eine explizite Anfrage zum Entfernen nicht nötig ist: Falls ein (Quell- oder Binär-) Paket nicht länger aus dem Quellcode erstellt wird, wird es halbautomatisch entfernt. Bei einem Binärpaket ist dies der Fall, wenn kein Quellpaket dieses Binärpaket weiterhin erzeugt. Falls das Binärpaket nur auf einigen Architekturen nicht länger erstellt wird, ist eine Anfrage zum Entfernen weiterhin nötig. Für ein Quell-Paket bedeutet dies, dass alle Binärpakete, die sich darauf beziehen, von einem anderen Quellpaket übernommen werden müssen.

en: In your removal request, you have to detail the reasons justifying the request. This is to avoid unwanted removals and to keep a trace of why a package has been removed. For example, you can provide the name of the package that supersedes the one to be removed.
de: In Ihrer Bitte um Entfernung müssen Sie detaillierte Gründe angeben, die das Entfernen rechtfertigen. Dies muss so sein, um unerwünschtes Entfernen zu vermeiden und um eine Chronik aufzubewahren, weshalb das Paket entfernt wurde. Sie können zum Beispiel den Namen des Pakets bereitstellen, dass das Entfernte ersetzt.

en: Usually you only ask for the removal of a package maintained by yourself. If you want to remove another package, you have to get the approval of its maintainer. Should the package be orphaned and thus have no maintainer, you should first discuss the removal request on ``debian-qa@lists.debian.org``. If there is a consensus that the package should be removed, you should reassign and retitle the ``O:`` bug filed against the ``wnpp`` package instead of filing a new bug as removal request.
de: Üblicherweise bitten Sie nur darum, ein Paket zu entfernen, das Sie selbst betreuen. Falls Sie ein anderes Paket entfernen möchten, müssen Sie die Genehmigung seines Betreuers einholen. Sollte das Paket verwaist sein und daher keinen Betreuer haben, sollten Sie die Bitte um Entfernung zuerst auf ``debian-qa@lists.debian.org`` diskutieren. Falls es dort eine Übereinkunft gibt, dass das Paket entfernt werden soll, sollten Sie den bestehenden ``O:``-Fehlerreport gegen das ``wnpp``-Paket umbenennen und entsprechend zuweisen, anstatt einen neuen Fehlerbericht mit Bitte um Entfernen einzureichen.

en: Further information relating to these and other package removal related topics may be found at https://wiki.debian.org/ftpmaster_Removals\ and https://qa.debian.org/howto-remove.html\ .
de: Weitere Informationen über diese oder andere Themen, die sich auf das Entfernen von Paketen beziehen, finden Sie unter https://wiki.debian.org/ftpmaster_Removals\  und https://qa.debian.org/howto-remove.html\ .

en: If in doubt concerning whether a package is disposable, email ``debian-devel@lists.debian.org`` asking for opinions. Also of interest is the ``apt-cache`` program from the ``apt`` package. When invoked as ``apt-cache showpkg`` *package*, the program will show details for *package*, including reverse depends. Other useful programs include ``apt-cache rdepends``, ``apt-rdepends``, ``build-rdeps`` (in the ``devscripts`` package) and ``grep-dctrl``. Removal of orphaned packages is discussed on ``debian-qa@lists.debian.org``.
de: Wenn Zweifel bestehen ob ein Paket verworfen werden kann, fragen Sie per E-Mail an ``debian-devel@lists.debian.org`` nach Meinungen. Außerdem ist das Programm ``apt-cache`` aus dem Paket ``apt`` von Interesse. Wenn es mit ``apt-cache showpkg`` *Paket* aufgerufen wird, zeigt es Einzelheiten über das *Paket*, einschließlich umgekehrter Abhängigkeiten. Andere nützliche Programme umfassen ``apt-cache rdepends``, ``apt-rdepends``, ``build-rdeps`` (aus dem Paket ``devscripts``) und ``grep-dctrl``. Das Entfernen von verwaisten Paketen wird auf ``debian-qa@lists.debian.org`` diskutiert.

en: Once the package has been removed, the package's bugs should be handled. They should either be reassigned to another package in the case where the actual code has evolved into another package (e.g. ``libfoo12`` was removed because ``libfoo13`` supersedes it) or closed if the software is simply no longer part of Debian. When closing the bugs, to avoid marking the bugs as fixed in versions of the packages in previous Debian releases, they should be marked as fixed in the version ``<most-recent-version-ever-in-Debian>+rm``.
de: Sobald das Paket entfernt wurde, sollten die Fehler des Pakets behandelt werden. Sie sollten entweder im Fall, dass der tatsächliche Code in ein anderes Paket übergegangen ist, entsprechend zugewiesen werden (z.B. ``libfoo12`` wurde entfernt, weil ``libfoo13`` es ersetzt) oder geschlossen werden, falls die Software einfach nicht länger Teil von Debian ist. Wenn die Fehler geschlossen werden, sollten sie in der Version ``<most-recent-version-ever-in-Debian>+rm`` als behoben gekennzeichnet werden, um zu verhindern, dass sie in vorherigen Debian-Releases als behoben gekennzeichnet werden.

en: Removing packages from ``Incoming``
de: Entfernen von Paketen aus ``Incoming``

en: In the past, it was possible to remove packages from ``incoming``. However, with the introduction of the new incoming system, this is no longer possible. [4]_ Instead, you have to upload a new revision of your package with a higher version than the package you want to replace. Both versions will be installed in the archive but only the higher version will actually be available in ``unstable`` since the previous version will immediately be replaced by the higher. However, if you do proper testing of your packages, the need to replace a package should not occur too often anyway.
de: Früher war es möglich, Pakete aus ``incoming`` zu entfernen. Mit der Einführung des neuen Incoming-Systems ist dies jedoch nicht mehr möglich. [4]_ Stattdessen müssen Sie eine neue Überarbeitung Ihres Pakets mit einer höheren Versionsnummer als der des zu ersetzenden Pakets hochladen. Beide Versionen werden im Archiv installiert, aber nur die höhere Version wird tatsächlich in ``Unstable`` verfügbar sein, da die vorherige sofort durch die höhere ersetzt wird. Falls Sie jedoch Ihr Paket ordnungsgemäß testen, sollte es ohnehin nicht allzu oft vorkommen, dass Sie ein Paket ersetzen.

en: Replacing or renaming packages
de: Umbenennen oder Ersetzen von Paketen

en: When the upstream maintainers for one of your packages chose to rename their software (or you made a mistake naming your package), you should follow a two-step process to rename it. In the first step, change the ``debian/control`` file to reflect the new name and to replace, provide and conflict with the obsolete package name (see the `Debian Policy Manual <https://www.debian.org/doc/debian-policy/>`__ for details). Please note that you should only add a ``Provides`` relation if all packages depending on the obsolete package name continue to work after the renaming. Once you've uploaded the package and the package has moved into the archive, file a bug against ``ftp.debian.org`` asking to remove the package with the obsolete name (see :ref:`removing-pkgs`). Do not forget to properly reassign the package's bugs at the same time.
de: Wenn sich die Originalautoren eines Ihrer Pakete entscheiden, ihre Software umzubenennen (oder Ihnen beim Benennen Ihres Pakets ein Fehler unterlaufen ist), sollten Sie einen zweistufigen Prozess durchlaufen, um es umzubenennen. Im ersten Schritt ändern Sie die Datei ``debian/control``, um den neuen Namen wiederzugeben, der den veralteten ersetzt, dessen Funktionalität wieder bereitstellt und zu ihm in Konflikt tritt (Einzelheiten finden Sie im `Debian Policy Manual <https://www.debian.org/doc/debian-policy/>`__). Bitte beachten Sie, dass Sie nur dann eine ``Provides``-Beziehung hinzufügen sollten, wenn alle Pakete, die von dem veralteten Paketnamen abhängen, nach dem Umbenennen weiter funktionieren. Sobald Sie das Paket hochgeladen haben und das Paket in das Archiv verschoben wurde, reichen Sie einen Fehler gegen ``ftp.debian.org`` ein, in dem Sie um das Entfernen des veralteten Namens ersuchen (siehe :ref:`removing-pkgs`). Vergessen Sie nicht, gleichzeitig die Fehler passend zuzuweisen.

en: At other times, you may make a mistake in constructing your package and wish to replace it. The only way to do this is to increase the version number and upload a new version. The old version will be expired in the usual manner. Note that this applies to each part of your package, including the sources: if you wish to replace the upstream source tarball of your package, you will need to upload it with a different version. An easy possibility is to replace ``foo_1.00.orig.tar.gz`` with ``foo_1.00+0.orig.tar.gz`` or ``foo_1.00.orig.tar.bz2``. This restriction gives each file on the ftp site a unique name, which helps to ensure consistency across the mirror network.
de: Eine andere Situation wäre, dass Sie einen Fehler beim Konstruieren Ihres Pakets begangen haben und wünschen, es zu ersetzen. Die einzige Möglichkeit, dies zu tun, besteht im Erhöhen der Versionsnummer und dem Hochladen dieser neuen Version. Die alte Version verliert wie üblich ihre Gültigkeit. Beachten Sie, dass dies auf jeden Teil Ihres Pakets zutrifft, einschließlich dem Quellcode: Falls Sie den Originalquell-Tarball Ihres Pakets ersetzen möchten, müssen Sie ihn mit einer veränderten Version hochladen. Eine einfache Möglichkeit ist es, ``foo_1.00.orig.tar.gz`` durch ``foo_1.00+0.orig.tar.gz`` oder ``foo_1.00.orig.tar.bz2`` zu ersetzen. Diese Einschränkung gibt jeder Datei auf der FTP-Seite einen einzigartigen Namen, der dabei hilft, die Einheitlichkeit über ein Netzwerk von Spiegelservern sicherzustellen.

en: Orphaning a package
de: Verwaisen von Paketen

en: If you can no longer maintain a package, you need to inform others, and see that the package is marked as orphaned. You should set the package maintainer to ``Debian QA Group <packages@qa.debian.org>`` and submit a bug report against the pseudo package ``wnpp``. The bug report should be titled ``O:`` *package* ``--`` *short description* indicating that the package is now orphaned. The severity of the bug should be set to ``normal``; if the package has a priority of standard or higher, it should be set to important. If you feel it's necessary, send a copy to ``debian-devel@lists.debian.org`` by putting the address in the X-Debbugs-CC: header of the message (no, don't use CC:, because that way the message's subject won't indicate the bug number).
de: Falls Sie ein Paket nicht länger betreuen können, müssen Sie andere darüber informieren und dafür sorgen, dass das Paket als verwaist gekennzeichnet wird. Sie sollten den Paketbetreuer auf ``Debian QA Group <packages@qa.debian.org>`` setzen und einen Fehlerbericht gegen das Pseudopaket ``wnpp`` senden. Der Fehlerbericht sollte im Betreff ``O:`` *Paket* ``--`` *kurze Beschreibung* enthalten um so anzuzeigen, dass das Paket nun verwaist ist. Der Schweregrad des Fehlers sollte auf ``normal`` gesetzt werden falls das Paket die Priorität "standard" oder höher hat, sollte der Schweregrad auf "important" gesetzt werden. Wenn Sie es für nötig halten, senden Sie eine Kopie an ``debian-devel@lists.debian.org``, indem Sie die Adresse in die Kopfzeile X-Debbugs-CC: der Nachricht einfügen (nein, benutzen Sie nicht CC:, da auf diese Art der Betreff der Nachricht die Fehlernummer nicht angibt).

en: If you just intend to give the package away, but you can keep maintainership for the moment, then you should instead submit a bug against ``wnpp`` and title it ``RFA:`` *package* ``--`` *short description*. ``RFA`` stands for ``Request For Adoption``.
de: Falls Sie nur die Absicht haben, das Paket abzugeben, aber im Moment noch Betreuer bleiben können, dann sollten Sie stattdessen einen Fehlerbericht gegen ``wnpp`` mit dem Betreff ``RFA:``\ *Paket*\ ``--`` *kurze Beschreibung* senden. ``RFA`` steht für ``Request For Adoption`` (Bitte um Adoption).

en: More information is on the `WNPP web pages <https://www.debian.org/devel/wnpp/>`__.
de: Weitere Informationen finden Sie auf den `WNPP-Web-Seiten <https://www.debian.org/devel/wnpp/>`__.

en: Adopting a package
de: Adoption eines Pakets

en: A list of packages in need of a new maintainer is available in the `Work-Needing and Prospective Packages list (WNPP) <https://www.debian.org/devel/wnpp/>`__. If you wish to take over maintenance of any of the packages listed in the WNPP, please take a look at the aforementioned page for information and procedures.
de: Eine Liste von Paketen, die einen neuen Betreuer suchen, ist unter `Arbeit-bedürfende und voraussichtliche Pakete (WNPP) <https://www.debian.org/devel/wnpp/>`__ verfügbar. Falls Sie die Verwaltung von einigen Paketen übernehmen möchten, die auf WNPP aufgeführt sind, lesen Sie bitte besagte Seite, um Informationen zu erhalten und etwas über die Prozeduren zu erfahren.

en: It is not OK to simply take over a package without assent of the current maintainer — that would be package hijacking. You can, of course, contact the current maintainer and ask them for permission to take over the package.
de: Es ist nicht in Ordnung, einfach ein Paket ohne Zustimmung des derzeitigen Betreuers zu übernehmen – das wäre Paketentführung. Sie können natürlich den aktuellen Betreuer kontaktieren und ihn fragen, ob Sie das Paket übernehmen dürfen.

en: However, when a package has been neglected by the maintainer, you might be able to take over package maintainership by following the package salvaging process as described in :ref:`package-salvaging`. If you have reason to believe a maintainer is no longer active at all, see :ref:`mia-qa`.
de: Wenn ein Paket vom Betreuer jedoch vernachlässigt wurde, können Sie möglicherweise die Paketbetreuung übernehmen, indem Sie dem in :ref:`package-salvaging` beschriebenen Paket-Bergungsprozess folgen. Wenn Sie Grund zur Annahme haben, dass ein Betreuer überhaupt nicht mehr aktiv ist, lesen Sie :ref:`mia-qa`.

en: Complaints about maintainers should be brought up on the developers' mailing list. If the discussion doesn't end with a positive conclusion, and the issue is of a technical nature, consider bringing it to the attention of the technical committee (see the `technical committee web page <https://www.debian.org/devel/tech-ctte>`__ for more information).
de: Beschwerden über Betreuer sollten auf der Entwickler-Mailingliste vorgebracht werden. Falls die Diskussion mit keinem positiven Fazit endet und das Thema technischer Natur ist, erwägen Sie, den Technischen Ausschuss darauf aufmerksam zu machen. Weitere Informationen finden Sie unter `Debians Technischer Ausschuss <https://www.debian.org/devel/tech-ctte>`__.

en: If you take over an old package, you probably want to be listed as the package's official maintainer in the bug system. This will happen automatically once you upload a new version with an updated ``Maintainer`` field, although it can take a few hours after the upload is done. If you do not expect to upload a new version for a while, you can use :ref:`pkg-tracker` to get the bug reports. However, make sure that the old maintainer has no problem with the fact that they will continue to receive the bugs during that time.
de: Wenn Sie ein altes Paket übernehmen, möchten Sie wahrscheinlich als offizieller Betreuer in der Fehlerdatenbank aufgeführt werden. Dies geschieht automatisch, sobald Sie eine neue Version mit einem aktualisierten ``Maintainer``-Feld hochladen, obwohl dies nach dem Hochladen ein paar Tage dauern kann. Falls Sie für eine Weile nicht planen, eine neue Version hochzuladen, können Sie :ref:`pkg-tracker` benutzen, um Fehlerberichte zu erhalten. Stellen Sie jedoch sicher, dass der alte Betreuer kein Problem damit hat, dass er während dieser Zeit weiterhin die Fehlerberichte erhalten wird.

en: Reintroducing packages
de: Wiedereinführen vom Paketen

en: Packages are often removed due to release-critical bugs, absent maintainers, too few users or poor quality in general. While the process of reintroduction is similar to the initial packaging process, you can avoid some pitfalls by doing some historical research first.
de: Pakete werden oft aufgrund veröffentlichungskritischer Fehler, fehlender Paketbetreuer, zu weniger Benutzer oder allgemein schlechter Qualität entfernt. Obwohl der Prozess der Wiedereinführung dem anfänglichen Paketierungsprozess ähnlich ist, können Sie einige Tücken umgehen, indem Sie zuerst etwas historische Recherche betreiben.

en: You should check why the package was removed in the first place. This information can be found in the removal item in the news section of the PTS page for the package or by browsing the log of `removals <https://ftp-master.debian.org/#removed>`__. The removal bug will tell you why the package was removed and will give some indication of what you will need to work on in order to reintroduce the package. It may indicate that the best way forward is to switch to some other piece of software instead of reintroducing the package.
de: An erster Stelle sollten Sie prüfen, weshalb das Paket entfernt wurde. Diese Information können Sie unter dem Punkt Remove im News-Bereich auf der PTS-Seite des Pakets finden oder durch Durchstöbern des Protokolls unter `Removed packages <https://ftp-master.debian.org/#removed>`__. Der Fehlerbericht für das Entfernen wird Ihnen sagen, weshalb das Paket entfernt wurde und einen Hinweis darauf geben, woran Sie arbeiten müssen, um das Paket wieder einzuführen. Möglicherweise gibt er auch an, dass Sie am Besten mit einer anderen Software weitermachen, anstatt das Paket wieder einzuführen.

en: It may be appropriate to contact the former maintainers to find out if they are working on reintroducing the package, interested in co-maintaining the package or interested in sponsoring the package if needed.
de: Es ist vielleicht angebracht, die früheren Paketbetreuer zu kontaktieren, um herauszufinden, ob sie an der Wiedereinführung des Pakets arbeiten, ob sie es mitbetreuen möchten oder ob sie interessiert sind, das Paket, falls nötig, zu sponsern.

en: You should do all the things required before introducing new packages (:ref:`newpackage`).
de: Sie sollten all die Dinge tun, die erforderlich sind, um neue Pakete einführen (:ref:`newpackage`).

en: You should base your work on the latest packaging available that is suitable. That might be the latest version from ``unstable``, which will still be present in the `snapshot archive <https://snapshot.debian.org/>`__.
de: Sie sollten auf Basis der letzten verfügbaren Paketierung arbeiten, die sich eignet. Dies kann die letzte Version aus ``Unstable`` sein, die immer noch im `Snapshot-Archiv <https://snapshot.debian.org>`__ vorhanden ist.

en: The version control system used by the previous maintainer might contain useful changes, so it might be a good idea to have a look there. Check if the ``control`` file of the previous package contained any headers linking to the version control system for the package and if it still exists.
de: Das vom letzten Paketbetreuer benutzte Versionskontrollsystem kann nützliche Änderungen enthalten, daher ist es vermutlich eine gute Idee, dort nachzusehen. Prüfen Sie, ob die Datei ``control`` des vorherigen Paket irgendwelche Kopfzeilen enthält, die auf das Versionskontrollsystem des Pakets verweisen und ob es noch existiert.

en: Package removals from ``unstable`` (not ``testing``, ``stable`` or ``oldstable``) trigger the closing of all bugs related to the package. You should look through all the closed bugs (including archived bugs) and unarchive and reopen any that were closed in a version ending in ``+rm`` and still apply. Any that no longer apply should be marked as fixed in the correct version if that is known.
de: Entfernen von Paketen aus ``Unstable`` (nicht ``Testing``, ``Stable`` oder ``Oldstable``) löst das Schließen aller Fehler aus, die sich auf das Paket beziehen. Sie sollten alle geschlossenen Fehler durchsehen (einschließlich archivierter Fehler) und diejenigen aus dem Archiv nehmen und wieder öffnen, die mit einer Version geschlossen wurden, die auf ``+rm`` endet und die immer noch zutreffen.

en: Package removals from unstable also trigger marking the package as removed in the :ref:`bug-security-tracker`. Debian members should `mark removed issues as unfixed <https://security-team.debian.org/security_tracker.html#removed-packages>`__ in the security tracker repository and all others should contact the security team to `report reintroduced packages <https://security-tracker.debian.org/tracker/data/report>`__.
de: Das Entfernen von Paketen aus "Unstable" löst auch das Markieren des Pakets als entfernt im :ref:`bug-security-tracker` aus. Debian-Mitglieder sollten entfernte Pakete als `nicht Fehler behoben im Security Tracker-Repository <https://security-team.debian.org/security_tracker.html#removed-packages>`__ markieren. Alle anderen sollten sich an das Sicherheitsteam wenden, um `wieder eingeführte Pakete <https://security-tracker.debian.org/tracker/data/report>`__ zu melden.

en: Porting and being ported
de: Portieren und portiert werden

en: Debian supports an ever-increasing number of architectures. Even if you are not a porter, and you don't use any architecture but one, it is part of your duty as a maintainer to be aware of issues of portability. Therefore, even if you are not a porter, you should read most of this chapter.
de: Debian unterstützt eine immer größer werdende Anzahl von Architekturen. Sogar wenn Sie kein Portierer sind und nur eine einzige Architektur nutzen, gehört es zu Ihren Pflichten als Betreuer, die Fragen der Portierbarkeit zu kennen. Daher sollten Sie, sogar wenn Sie kein Portierer sind, das meiste in diesem Kapitel lesen.

en: Porting is the act of building Debian packages for architectures that are different from the original architecture of the package maintainer's binary package. It is a unique and essential activity. In fact, porters do most of the actual compiling of Debian packages. For instance, when a maintainer uploads a (portable) source package with binaries for the ``i386`` architecture, it will be built for each of the other architectures, amounting to |number-of-arches| more builds.
de: Portieren ist das Erstellen von Debian-Paketen für Architekturen, die sich von der Originalarchitektur des Binärpakets des Paketbetreuers unterscheiden. Es ist eine einzigartige und notwendige Aktivität. Tatsächlich sind Portierer diejenigen, die die meisten Debian-Pakete kompilieren. Wenn zum Beispiel ein Paketbetreuer ein (portierbares) Quellpaket mit Binärdateien für die Architektur ``i386`` hochlädt, wird es für jede andere Architektur erstellt, was auf |number-of-arches| weitere Builds hinausläuft.

en: Being kind to porters
de: Seien Sie freundlich zu Portierern

en: Porters have a difficult and unique task, since they are required to deal with a large volume of packages. Ideally, every source package should build right out of the box. Unfortunately, this is often not the case. This section contains a checklist of *gotchas* often committed by Debian maintainers — common problems which often stymie porters, and make their jobs unnecessarily difficult.
de: Portierer haben schwere und ungewöhnliche Aufgaben, da sie mit einer großen Zahl von Paketen umgehen müssen. Idealerweise sollte jedes Quellpaket direkt aus dem Stand korrekt erstellt werden. Unglücklicherweise ist das oft nicht der Fall. Dieser Abschnitt enthält eine Prüfliste von "Patzern", die öfter von Debian-Betreuern begangen werden – übliche Probleme, die Portierer oft in Schwierigkeiten bringen und ihre Arbeit unnötig erschweren.

en: The first and most important thing is to respond quickly to bugs or issues raised by porters. Please treat porters with courtesy, as if they were in fact co-maintainers of your package (which, in a way, they are). Please be tolerant of succinct or even unclear bug reports; do your best to hunt down whatever the problem is.
de: Die Erste und Wichtigste ist, schnell auf einen Fehler oder ein Problem zu antworten, das ein Portierer aufgedeckt hat. Behandeln Sie Portierer höflich, als wären Sie quasi Mitbetreuer Ihres Pakets (was sie gewissermaßen sind). Bitte seien Sie tolerant bei knappen oder sogar unklaren Fehlerberichten. Tun Sie Ihr Bestes, um Jagd auf das Problem zu machen, was immer es auch ist.

en: By far, most of the problems encountered by porters are caused by *packaging bugs* in the source packages. Here is a checklist of things you should check or be aware of.
de: Die mit Abstand meisten Probleme, die von Portierern gefunden werden, werden durch *Paketierungsfehler* in den Quellpaketen verursacht. Hier ist eine Liste der Dinge, die Sie prüfen oder wissen sollten.

en: Make sure that your ``Build-Depends`` and ``Build-Depends-Indep`` settings in ``debian/control`` are set properly. The best way to validate this is to use the ``debootstrap`` package to create an ``unstable`` chroot environment (see :ref:`debootstrap`). Within that chrooted environment, install the ``build-essential`` package and any package dependencies mentioned in ``Build-Depends`` and/or ``Build-Depends-Indep``. Finally, try building your package within that chrooted environment. These steps can be automated by the use of the ``pbuilder`` program, which is provided by the package of the same name (see :ref:`pbuilder`).
de: Stellen Sie sicher, dass Ihre ``Build-Depends``- und ``Build-Depends-Indep``-Einstellungen in der Datei ``debian/control`` richtig gesetzt sind. Die beste Methode, dies zu überprüfen, ist die Benutzung des Pakets ``debootstrap``, um eine ``Unstable``-Chroot-Umgebung zu erstellen (siehe :ref:`debootstrap`). Innerhalb der Chroot-Umgebung installieren Sie das Paket ``build-essential`` und/oder ``Build-Depends-Indep``. Am Ende versuchen Sie, Ihr Paket innerhalb der Chroot-Umgebung zu erstellen. Diese Schritte können mit dem Programm ``pbuilder`` automatisiert werden, das vom Paket mit dem gleichen Namen bereitgestellt wird (siehe :ref:`pbuilder`).

en: If you can't set up a proper chroot, ``dpkg-depcheck`` may be of assistance (see :ref:`dpkg-depcheck`).
de: Falls Sie kein ordnungsgemäßes Chroot einrichten können, könnte Ihnen ``dpkg-depcheck`` behilflich sein (siehe :ref:`dpkg-depcheck`).

en: See the `Debian Policy Manual <https://www.debian.org/doc/debian-policy/>`__ for instructions on setting build dependencies.
de: Anweisungen zur Einrichtung von Build-Abhängigkeiten finden Sie im `Debian Policy Manual <https://www.debian.org/doc/debian-policy/>`__.

en: Don't set architecture to a value other than ``all`` or ``any`` unless you really mean it. In too many cases, maintainers don't follow the instructions in the `Debian Policy Manual <https://www.debian.org/doc/debian-policy/>`__. Setting your architecture to only one architecture (such as ``i386`` or ``amd64``) is usually incorrect.
de: Setzen Sie "architecture" auf keinen anderen Wert als ``all`` oder ``any``, außer wenn Sie das wirklich beabsichtigen. In zu vielen Fällen folgen Paketbetreuer nicht den Anweisungen im `Debian Policy Manual <https://www.debian.org/doc/debian-policy/>`__. Wenn Sie Ihre "architecture" nur auf eine Architektur (wie ``i386`` oder ``amd64``) setzen, ist dies normalerweise falsch.

en: Make sure your source package is correct. Do ``dpkg-source -x`` *package*\ ``.dsc`` to make sure your source package unpacks properly. Then, in there, try building your package from scratch with ``dpkg-buildpackage``.
de: Stellen Sie sicher, dass das Quellpaket korrekt ist. Führen Sie ``dpkg-source -x`` *Paket*\ ``.dsc`` aus, um sicherzustellen, dass Ihr Quellpaket ordnungsgemäß entpackt wird. Dann versuchen Sie, dort Ihr Paket von Grund auf mit ``dpkg-buildpackage`` neu zu erstellen.

en: Make sure you don't ship your source package with the ``debian/files`` or ``debian/substvars`` files. They should be removed by the ``clean`` target of ``debian/rules``.
de: Stellen Sie sicher, dass Sie Ihr Quellpaket nicht mit den Dateien ``debian/files`` oder ``debian/substvars`` ausliefern. Sie sollten durch das Target ``clean`` von ``debian/rules`` entfernt werden.

en: Make sure you don't rely on locally installed or hacked configurations or programs. For instance, you should never be calling programs in ``/usr/local/bin`` or the like. Try not to rely on programs being set up in a special way. Try building your package on another machine, even if it's the same architecture.
de: Stellen Sie sicher, dass Sie sich nicht auf lokal installierte Pakete oder gehackte Konfigurationen oder Programme verlassen. Sie sollten zum Beispiel niemals Programme in ``/usr/local/bin`` oder dergleichen aufrufen. Versuchen Sie, Ihr Paket auf einem anderen Rechner zu erstellen, auch wenn dieser die gleiche Architektur hat.

en: Don't depend on the package you're building being installed already (a sub-case of the above issue). There are, of course, exceptions to this rule, but be aware that any case like this needs manual bootstrapping and cannot be done by automated package builders.
de: Verlassen Sie sich nicht darauf, dass das Paket, das Sie erstellen, bereits installiert ist (ein Teilaspekt des vorherigen Problems). Es gibt natürlich Ausnahmen von dieser Regel, aber seien Sie sich bewusst, dass dies auf jeden Fall manuelles Bootstrapping erfordert und nicht durch automatisierte Paket-Builder erledigt werden kann.

en: Don't rely on the compiler being a certain version, if possible. If not, then make sure your build dependencies reflect the restrictions, although you are probably asking for trouble, since different architectures sometimes standardize on different compilers.
de: Verlassen Sie sich, wenn möglich, nicht auf eine bestimmte Version des Compilers. Falls doch, dann stellen Sie sicher, dass Ihre Build-Abhängigkeiten diese Einschränkungen widerspiegeln, obwohl Sie sich wahrscheinlich Ärger einhandeln, da verschiedene Architekturen manchmal unterschiedliche Compiler vorgeben.

en: Make sure your ``debian/rules`` contains separate ``binary-arch`` and ``binary-indep`` targets, as the Debian Policy Manual requires. Make sure that both targets work independently, that is, that you can call the target without having called the other before. To test this, try to run ``dpkg-buildpackage -B``.
de: Sorgen Sie dafür, dass Ihre ``debian/rules``-Datei separate ``binary-arch``- und ``binary-indep``-Targets enthält, wie es das Debian Policy Manual fordert. Stellen Sie sicher, dass beide Targets unabhängig voneinander funktionieren, damit Sie ein Target aufrufen können, ohne dass Sie vorher das andere aufgerufen haben müssen. Um dies zu prüfen, führen Sie ``dpkg-buildpackage -B`` aus.

en: When you can't support your package on a particular architecture, you shouldn't use the Architecture field to reflect that (it's also a pain to maintain correctly). If the package fails to build from source, you can just let it be and interested people can take a look at the build logs. If the package would actually build, the trick is to add a ``Build-Depends`` on ``unsupported-architecture [!the-not-supported-arch]``. The buildds will not build the package as the build dependencies are not fullfiled on that arch. To prevent building on 32-bits architectures, the ``architecture-is-64bit`` build dependency can be used, as ``architecture-is-little-endian`` can be used to prevent building on big endian systems.
de: Wenn Ihr Paket auf bestimmten Architekturen nicht unterstützt wird, sollten Sie nicht das Feld ``Architecture`` verwenden, um das widerzuspiegeln (es ist schwierig, das Feld richtig zu pflegen). Wenn das Paket nicht aus den Quellen gebaut werden kann, können Sie es einfach so lassen und interessierte Leute können sich die Build-Protokolle anschauen. Wenn das Paket bauen würde, sollte der Trick angewendet werden ``Build-Depends`` auf ``unsupported-architecture [!the-not-supported-arch]`` zu setzen. Die Buildds werden das Paket nicht bauen, da die Build-Abhängigkeiten nicht für diese Architektur erfüllt sind. Um zu verhindern, dass für 32-Bit-Architekturen gebaut wird, kann die Build-Abhängigkeit ``architecture-is-64-bit`` verwendet werden. Ebenso kann ``architecture-is-litte-endian`` verwendet werden, um zu verhindern, dass auf Big-Endian-Systemen gebaut wird.

en: Guidelines for porter uploads
de: Leitlinien für Uploads von Portierern

en: If the package builds out of the box for the architecture to be ported to, you are in luck and your job is easy. This section applies to that case; it describes how to build and upload your binary package so that it is properly installed into the archive. If you do have to patch the package in order to get it to compile for the other architecture, you are actually doing a source NMU, so consult :ref:`nmu-guidelines` instead.
de: Wenn das Paket aus dem Stand für die Architektur erstellt werden kann, auf die es portiert werden soll, haben Sie Glück und Ihre Arbeit ist einfach. Dieser Abschnitt befasst sich mit diesem Fall; er beschreibt, wie Ihr Binärpaket erstellt und hochgeladen wird, so dass es ordnungsgemäß im Archiv installiert werden kann. Falls Sie das Paket patchen müssen, um es für eine andere Architektur kompilieren zu können, führen Sie in Wirklichkeit ein Quell-NMU durch, ziehen Sie daher stattdessen :ref:`nmu-guidelines` zu Rate.

en: For a porter upload, no changes are being made to the source. You do not need to touch any of the files in the source package. This includes ``debian/changelog``.
de: Für einen Upload eines Portierers werden keine Änderungen am Quellcode vorgenommen. Sie müssen keine Dateien im Quellpaket anfassen. Dies schließt ``debian/changelog`` ein.

en: The way to invoke ``dpkg-buildpackage`` is as ``dpkg-buildpackage -B -m`` *porter-email*. Of course, set *porter-email* to your email address. This will do a binary-only build of only the architecture-dependent portions of the package, using the ``binary-arch`` target in ``debian/rules``.
de: Die Vorgehensweise, ``dpkg-buildpackage`` aufzurufen, ist wie folgt: ``dpkg-buildpackage -B -m`` *E-Mail des Portierers*. Natürlich setzen Sie *E-Mail des Portierers* auf Ihre E-Mail-Adresse. Dies wird zu einem rein binären Build von nur den Paketteilen führen, die architekturabhängig sind. Dabei wird in ``debian/rules`` das Target ``binary-arch`` benutzt.

en: If you are working on a Debian machine for your porting efforts and you need to sign your upload locally for its acceptance in the archive, you can run ``debsign`` on your ``.changes`` file to have it signed conveniently, or use the remote signing mode of ``dpkg-sig``.
de: Falls Sie für Ihr Portierungs-Bestreben auf einer Debian-Maschine arbeiten und Ihren Upload lokal signieren müssen, damit er im Archiv akzeptiert wird, können Sie ``debsign`` für Ihre ``.changes``-Datei ausführen, um sie bequem zu signieren, oder benutzen Sie den Signierungsmodus aus der Ferne von ``dpkg-sig``.

en: Recompilation or binary-only NMU
de: Neu kompilieren oder rein binärer NMU

en: Sometimes the initial porter upload is problematic because the environment in which the package was built was not good enough (outdated or obsolete library, bad compiler, etc.). Then you may just need to recompile it in an updated environment. However, you have to bump the version number in this case, so that the old bad package can be replaced in the Debian archive (``dak`` refuses to install new packages if they don't have a version number greater than the currently available one).
de: Manchmal ist der erste Upload einer Portierung problematisch, da die Umgebung, in der das Paket erstellt wurde, nicht gut genug war (veraltete oder hinfällige Bibliotheken, falsche Compiler etc.). Dann könnte es nötig sein, dass Sie es nur neu in einer aktualisierten Umgebung kompilieren müssen. In diesem Fall müssen Sie jedoch die Versionsnummer ändern, so dass das alte, falsche Paket im Debian-Archiv ersetzt werden kann (``dak`` lehnt die Installation neuer Pakete ab, falls Sie keine höheren Versionsnummern als das aktuell verfügbare haben).

en: You have to make sure that your binary-only NMU doesn't render the package uninstallable. This could happen when a source package generates arch-dependent and arch-independent packages that have inter-dependencies generated using dpkg's substitution variable ``$(Source-Version)``.
de: Sie müssen sicherstellen, dass Ihr rein binärer NMU das Paket nicht uninstallierbar macht. Dies könnte geschehen, wenn ein Quellpaket architekturabhängige und architekturunabhängige Pakete generiert, die unter Benutzung der ersetzbaren Dpkg-Variable ``$(Source-Version)`` wechselseitige Abhängigkeiten erzeugen.

en: Despite the required modification of the changelog, these are called binary-only NMUs — there is no need in this case to trigger all other architectures to consider themselves out of date or requiring recompilation.
de: Ungeachtet der nötigen Modifikation des Änderungsprotokolls werden diese Uploads als rein binäre NMUs bezeichnet – es ist nicht nötig, in diesem Fall dafür zu sorgen, dass alle anderen Architekturen sich selbst als veraltet oder eines erneuten Kompilierens bedürfig betrachten.

en: Such recompilations require special *magic* version numbering, so that the archive maintenance tools recognize that, even though there is a new Debian version, there is no corresponding source update. If you get this wrong, the archive maintainers will reject your upload (due to lack of corresponding source code).
de: Solche Neu-Kompilierungen benötigen eine spezielle "magische" Versionsnummerierung, so dass die Archiv-Verwaltungswerkzeuge dies erkennen; selbst wenn es eine neue Debian-Version ist, gibt es dort keine zugehörige Aktualisierung des Quellcodes. Falls Sie dabei einen Fehler machen, werden die Archivbetreuer Ihre Aktualisierung ablehnen (aus Mangel an entsprechendem Quellcode).

en: The *magic* for a recompilation-only NMU is triggered by using a suffix appended to the package version number, following the form ``b``\ *number*. For instance, if the latest version you are recompiling against was version ``2.9-3``, your binary-only NMU should carry a version of ``2.9-3+b1``. If the latest version was ``3.4+b1`` (i.e, a native package with a previous recompilation NMU), your binary-only NMU should have a version number of ``3.4+b2``. [2]_
de: Die "Magie" für ein reines Neu-Kompilierungs-NMU wird durch eine Endung ausgelöst, die an die Paketversionsnummer angehängt wird und die Form ``b``\ *Zahl* hat. Wenn etwa die letzte Version, die Sie kompilierten, ``2.9-3`` war, sollte Ihr rein binärer NMU die Versionsnummer ``2.9-3+b1`` tragen. Falls die letzte Version ``3.4+b1`` war (d.h. ein natives Paket mit einem vorhergehenden Neu-Kompilierungs-NMU), sollte Ihr rein binärer NMU die Versionsnummer ``3.4+b2``. [2]_ haben.

en: Similar to initial porter uploads, the correct way of invoking ``dpkg-buildpackage`` is ``dpkg-buildpackage -B`` to only build the architecture-dependent parts of the package.
de: Ähnlich wie bei ersten Portierungs-Uploads ist der korrekte Weg, ``dpkg-buildpackage`` aufzurufen, ``dpkg-buildpackage -B``, um nur die architekturabhängigen Teile des Pakets zu erstellen.

en: When to do a source NMU if you are a porter
de: Wann Sie als Portierer ein Quell-NMU durchführen sollten

en: Porters doing a source NMU generally follow the guidelines found in :ref:`nmu`, just like non-porters. However, it is expected that the wait cycle for a porter's source NMU is smaller than for a non-porter, since porters have to cope with a large quantity of packages. Again, the situation varies depending on the distribution they are uploading to. It also varies whether the architecture is a candidate for inclusion into the next stable release; the release managers decide and announce which architectures are candidates.
de: Portierer, die einen Quell-NMU durchführen, folgen generell den Leitlinien, die unter :ref:`nmu` aufgeführt sind, genau wie nicht-Portierer. Es wird jedoch erwartet, dass der Wartezyklus für den Quell-NMU eines Portierers kleiner ist, als der von nicht-Portierern, da Portierer mit einer großen Zahl von Paketen zurechtkommen müssen. Die Situation variiert wiederum abhängig von der Distribution, in die hochgeladen wird. Sie variiert außerdem in Abhängigkeit davon, ob die Architektur ein Kandidat für die Integration in das nächste Stable-Release ist. Die Veröffentlichungsverwalter entscheiden, welche Architekturen Kandidaten sind und kündigen dies an.

en: If you are a porter doing an NMU for ``unstable``, the above guidelines for porting should be followed, with two variations. Firstly, the acceptable waiting period — the time between when the bug is submitted to the BTS and when it is OK to do an NMU — is seven days for porters working on the ``unstable`` distribution. This period can be shortened if the problem is critical and imposes hardship on the porting effort, at the discretion of the porter group. (Remember, none of this is Policy, just mutually agreed upon guidelines.) For uploads to ``stable`` or ``testing``, please coordinate with the appropriate release team first.
de: Falls Sie als Portierer einen NMU für ``Unstable`` durchführen, sollten die vorher genannten Regeln der Portierung mit zwei Abwandlungen befolgt werden. Erstens ist die akzeptable Wartezeit – die Zeit zwischen dem Absenden des Fehlerberichts an das BTS und der Zeit, wenn es in Ordnung ist, einen NMU durchzuführen – sieben Tage für Portierer, die an der Distribution ``Unstable`` arbeiten. Diese Zeitspanne kann verkürzt werden, falls das Problem kritisch ist und eine Notlage für die Portierungsanstrengung nach Ermessen der Gruppe der Portierer besteht. (Bedenken Sie, dass nichts davon in den Debian-Richtlinien steht, die Entwickler haben sich lediglich auf gewisse Regeln diesbezüglich geeinigt.) Für Uploads nach ``Stable`` oder ``Testing`` stimmen Sie sich bitte zuerst mit dem Release-Team ab.

en: Secondly, porters doing source NMUs should make sure that the bug they submit to the BTS should be of severity ``serious`` or greater. This ensures that a single source package can be used to compile every supported Debian architecture by release time. It is very important that we have one version of the binary and source package for all architectures in order to comply with many licenses.
de: Zweitens sollten Portierer, die ein Quell-NMU durchführen, sicherstellen, dass der Fehler, den Sie an das BTS senden, den Schweregrad ``serious`` oder höher aufweist. Dies garantiert, dass ein einzelnes Quellpaket benutzt werden kann, um jede unterstützte Debian-Architektur zum Veröffentlichungszeitpunkt zu kompilieren. Es ist sehr wichtig, dass es eine Version des Quell- und Binärpakets für alle Architekturen gibt, um vielen Lizenzen zu entsprechen.

en: Porters should try to avoid patches which simply kludge around bugs in the current version of the compile environment, kernel, or libc. Sometimes such kludges can't be helped. If you have to kludge around compiler bugs and the like, make sure you ``#ifdef`` your work properly; also, document your kludge so that people know to remove it once the external problems have been fixed.
de: Portierer sollten versuchen, Patches zu vermeiden, die einfache Bastellösungen für Fehler in der aktuellen Version der Compiler-Umgebung, des Kernels oder der Libc enthalten. Bisweilen sind solche Bastellösungen nicht hilfreich. Falls Sie an Compiler-Fehlern und dergleichen herumbasteln müssen, stellen Sie sicher, dass Sie Ihre Arbeit ordnungsgemäß in ``#ifdef`` einschließen. Dokumentieren Sie außerdem Ihren Murks, damit die Leute wissen, dass er entfernt werden muss, sobald die externen Probleme behoben wurden.

en: Porters may also have an unofficial location where they can put the results of their work during the waiting period. This helps others running the port have the benefit of the porter's work, even during the waiting period. Of course, such locations have no official blessing or status, so buyer beware.
de: Portierer könnten außerdem einen inoffiziellen Ort haben, an dem sie die Ergebnisse Ihrer Arbeit während der Wartezeit ablegen. Dies hilft anderen, die an der Portierung arbeiten, sogar während der Wartezeit aus der Arbeit des Portierers Nutzen zu ziehen. Natürlich haben solche Orte keinen offiziellen Segen oder Status, daher nehme sich der Käufer in Acht.

en: Porting infrastructure and automation
de: Portierungs-Infrastruktur und -Automatisierung

en: There is infrastructure and several tools to help automate package porting. This section contains a brief overview of this automation and porting to these tools; see the package documentation or references for full information.
de: Es gibt eine Infrastruktur und mehrere Werkzeuge, die das Portieren von Paketen automatisieren. Dieser Abschnitt enthält einen kurzen Überblick dieser Automatisierung und Portierung mit diesen Werkzeugen. Lesen Sie die Paketdokumentation oder die Referenzen, um umfassende Informationen zu erhalten.

en: Mailing lists and web pages
de: Mailinglisten und Web-Seiten

en: Web pages containing the status of each port can be found at https://www.debian.org/ports/\ .
de: Web-Seiten, die den Status jeder Portierung enthalten, finden Sie unter https://www.debian.org/ports/\ .

en: Each port of Debian has a mailing list. The list of porting mailing lists can be found at https://lists.debian.org/ports.html\ . These lists are used to coordinate porters, and to connect the users of a given port with the porters.
de: Jede Portierung von Debian hat eine Mailingliste. Die Liste der Portierungs-Mailinglisten sind unter https://lists.debian.org/ports.html\  zu finden. Diese Listen werden benutzt, um die Arbeit der Portierer zu koordinieren und um eine Verbindungsschnittstelle der Anwender der Portierung zu den Portierern herzustellen.

en: Porter tools
de: Werkzeuge der Portierer

en: Descriptions of several porting tools can be found in :ref:`tools-porting`.
de: Beschreibungen von vielen Werkzeugen für die Portierung finden Sie unter :ref:`tools-porting`.

en: The ``wanna-build`` system is used as a distributed, client-server build distribution system. It is usually used in conjunction with build daemons running the ``buildd`` program. ``Build daemons`` are ``slave`` hosts, which contact the central ``wanna-build`` system to receive a list of packages that need to be built.
de: Das System ``wanna-build`` wird als verteiltes Client-/Server-Build-Verteilungssystem eingesetzt. Es wird üblicherweise zusammen mit Build-Daemons benutzt, die das Programm ``buildd`` ausführen. ``Build daemons`` sind "Slave"-Rechner, die das zentrale ``wanna-build``-System kontaktieren, um eine Liste der Pakete zu beziehen, die erstellt werden müssen.

en: ``wanna-build`` is not yet available as a package; however, all Debian porting efforts are using it for automated package building. The tool used to do the actual package builds, ``sbuild``, is available as a package; see its description in :ref:`sbuild`. Please note that the packaged version is not the same as the one used on build daemons, but it is close enough to reproduce problems.
de: ``wanna-build`` ist noch nicht als Paket verfügbar. Alle Debian-Portierungsbestrebungen benutzen es jedoch zur automatisierten Paketerstellung. Das Werkzeug ``sbuild``, das für die tatsächlichen Paket-Builds benutzt wird, ist allerdings als Paket verfügbar. Lesen Sie dessen Beschreibung unter :ref:`sbuild`. Bitte beachten Sie, dass sich die Paketversion auf den Build-Daemons unterscheidet, aber sie sind ähnlich genug, um Probleme nachvollziehen zu können.

en: Most of the data produced by ``wanna-build`` that is generally useful to porters is available on the web at https://buildd.debian.org/\ . This data includes nightly updated statistics, queueing information and logs for build attempts.
de: ``wanna-build`` ist generell für Portierer nützlich. Die meisten davon erzeugten Daten sind im Web unter https://buildd.debian.org/\ verfügbar. Diese Daten enthalten nächtlich aktualisierte Statistiken, Warteschlangeninformationen und Protokolle von Build-Versuchen.

en: We are quite proud of this system, since it has so many possible uses. Independent development groups can use the system for different sub-flavors of Debian, which may or may not really be of general interest (for instance, a flavor of Debian built with ``gcc`` bounds checking). It will also enable Debian to recompile entire distributions quickly.
de: Debian ist ziemlich stolz auf dieses System, da es so viele Verwendungsmöglichkeiten gibt. Unabhängige Entwicklergruppen können das System benutzen, um unterschiedliche Geschmacksrichtungen von Debian, die von allgemeinem Interesse sein können oder auch nicht (zum Beispiel eine Debian-Geschmacksrichtung, die mit "bounds checking" vom ``gcc`` erstellt wurde) zu erstellen. Dadurch wird Debian auch in die Lage versetzt, ganze Distributionen schnell neu zu kompilieren.

en: The wanna-build team, in charge of the buildds, can be reached at ``debian-wb-team@lists.debian.org``. To determine who (wanna-build team, release team) and how (mail, BTS) to contact, refer to https://lists.debian.org/debian-project/2009/03/msg00096.html\ .
de: Das Wanna-Build-Team, das für Buildds verantwortlich ist, ist unter ``debian-wb-team@lists.debian.org`` erreichbar. Um festzustellen, wen Sie kontaktieren sollten (Wanna-Build-Team, Release-Team) und wie (per E-Mail, BTS), sei auf https://lists.debian.org/debian-project/2009/03/msg00096.html verwiesen.

en: When requesting binNMUs or give-backs (retries after a failed build), please use the format described at https://release.debian.org/wanna-build.txt\ .
de: Wenn Sie um BinNMUs oder Give-Backs (erneute Versuche nach gescheitertem Build) ersuchen, benutzen Sie bitte das unter https://release.debian.org/wanna-build.txt\  beschriebene Format.

en: When your package is *not* portable
de: Wenn Ihr Paket *nicht* portierbar ist

en: Some packages still have issues with building and/or working on some of the architectures supported by Debian, and cannot be ported at all, or not within a reasonable amount of time. An example is a package that is SVGA-specific (only available for ``i386`` and ``amd64``), or uses other hardware-specific features not supported on all architectures.
de: Einige Pakete haben immer noch Probleme mit der Erstellung und/oder Ihrer Funktion auf einigen der von Debian unterstützten Architekturen und können überhaupt nicht oder nicht in einem akzeptablen Zeitraum portiert werden. Ein Beispiel ist ein Paket, das SVGA-spezifisch ist (nur auf ``i386`` und ``amd64`` verfügbar) oder andere Hardware-spezifische Funktionen benutzt, die nicht von allen Architekturen unterstützt werden.

en: In order to prevent broken packages from being uploaded to the archive, and wasting buildd time, you need to do a few things:
de: Um zu verhindern, dass beschädigte Pakete in das Archiv hochgeladen werden und Buildd-Zeit vergeuden, müssen Sie ein paar Dinge tun:

en: First, make sure your package *does* fail to build on architectures that it cannot support. There are a few ways to achieve this. The preferred way is to have a small testsuite during build time that will test the functionality, and fail if it doesn't work. This is a good idea anyway, as this will prevent (some) broken uploads on all architectures, and also will allow the package to build as soon as the required functionality is available.
de: Stellen Sie zuerst sicher, dass das Erstellen Ihres Pakets auf Architekturen, die es nicht unterstützt *fehlschlägt*. Es gibt mehrere Möglichkeiten dies zu bewirken. Der bevorzugte Weg ist es, während des Erstellens eine kleine Test-Suite zu verwenden, die die Funktionalität prüft und fehlschlägt, wenn es nicht funktioniert. Dies ist sowieso eine gute Idee, da es (einige) schadhafte Uploads auf allen Architekturen verhindert und außerdem ermöglicht, das Paket zu erstellen, sobald die benötigte Funktionalität verfügbar ist.

en: Additionally, if you believe the list of supported architectures is pretty constant, you should change ``any`` to a list of supported architectures in ``debian/control``. This way, the build will fail also, and indicate this to a human reader without actually trying.
de: Zusätzlich sollten Sie in ``debian/control`` den architecture-Wert ``any`` in eine Liste der unterstützten Architekturen ändern, falls Sie glauben, die Liste der unterstützten Architekturen sei ziemlich gleichbleibend. Auf diese Art wird das Erstellen ebenfalls fehlschlagen und dies einem menschlichen Leser ohne tatsächliche Versuche angezeigt.

en: In order to prevent autobuilders from needlessly trying to build your package, it must be included in ``Packages-arch-specific``, a list used by the ``wanna-build`` script. The current version is available as https://wiki.debian.org/PackagesArchSpecific\ ; please see the top of the file for whom to contact for changes.
de: Um zu verhindern, dass Autobuilder unnötig versuchen, Ihr Paket zu erstellen, muss es in ``Packages-arch-specific`` enthalten sein, einer Liste, die vom ``wanna-build``-Skript benutzt wird. Die aktuelle Version ist unter https://wiki.debian.org/PackagesArchSpecific\  verfügbar. Bitte lesen Sie den Anfang der Datei, wer wegen eventueller Änderungen kontaktiert werden sollte.

en: Please note that it is insufficient to only add your package to ``Packages-arch-specific`` without making it fail to build on unsupported architectures: A porter or any other person trying to build your package might accidentally upload it without noticing it doesn't work. If in the past some binary packages were uploaded on unsupported architectures, request their removal by filing a bug against ``ftp.debian.org``.
de: Bitte beachten Sie, dass es nicht ausreicht, Ihr Paket nur zu ``Packages-arch-specific`` hinzuzufügen, ohne dafür zu sorgen, dass das Erstellen auf nicht unterstützten Architekturen fehlschlägt: Ein Portierer oder jemand anderes, der versucht, Ihr Paket zu erstellen, könnte Ihr Paket fälschlicherweise hochladen, ohne zu bemerken, dass es nicht funktioniert. Wenn in der Vergangenheit Binärpakete für nicht unterstützte Architekturen hochgeladen wurden, bitten Sie um deren Entfernung, indem Sie einen Fehlerbericht gegen ``ftp.debian.org`` einreichen.

en: Marking non-free packages as auto-buildable
de: Unfreie Pakete als automatisch erstellbar kennzeichnen

en: By default packages from the ``non-free`` and ``non-free-firmware`` sections are not built by the autobuilder network (mostly because the license of the packages could disapprove). To enable a package to be built, you need to perform the following steps:
de: Standardmäßig werden Pakete aus dem Bereich ``non-free`` und ``non-free-firmware`` nicht durch das Autobuilder-Netzwerk gebaut (meistens, weil die Lizenz der Pakete dem entgegen stehen könnte). Damit dort ein solches Paket dennoch gebaut wird, müssen Sie die folgenden Schritte durchführen:

en: Check whether it is legally allowed and technically possible to auto-build the package;
de: Prüfen, ob es rechtlich erlaubt und technisch möglich ist, das Paket automatisch zu bauen;

en: Add ``XS-Autobuild: yes`` into the header part of ``debian/control``;
de: ``XS-Autobuild: yes`` zu den Kopfzeilen von ``debian/control`` hinzufügen;

en: Send an email to ``non-free@buildd.debian.org`` and explain why the package can legitimately and technically be auto-built.
de: Eine E-Mail an ``non-free@release.debian.org`` senden und erklären, warum das Paket rechtlich und technisch automatisch gebaut werden kann.

en: Every package has one or more maintainers. Normally, these are the people who work on and upload new versions of the package. In some situations, it is useful that other developers can upload a new version as well, for example if they want to fix a bug in a package they don't maintain, when the maintainer needs help to respond to issues. Such uploads are called *Non-Maintainer Uploads (NMU)*.
de: Jedes Paket hat einen oder mehrere Betreuer. Normalerweise sind das Leute, die daran arbeiten und neue Versionen des Pakets hochladen. In einigen Situationen ist es nützlich, dass auch andere Entwickler neue Versionen hochladen können. Zum Beispiel, falls sie einen Fehler in einem Paket beheben möchten, das sie nicht betreuen, oder wenn der Betreuer Hilfe benötigt, um auf Probleme zu antworten. Solche Uploads werden *Non-Maintainer Uploads (NMU)* genannt.

en: When and how to do an NMU
de: Wann und wie ein NMU durchgeführt wird

en: Before doing an NMU, consider the following questions:
de: Beachten Sie die folgenden Fragen, bevor Sie einen NMU durchführen:

en: Have you geared the NMU towards helping the maintainer? As there might be disagreement on the notion of whether the maintainer actually needs help or not, the DELAYED queue exists to give time to the maintainer to react and has the beneficial side-effect of allowing for independent reviews of the NMU diff.
de: Haben Sie den NMU darauf abgestimmt, dass es dem Paketbetreuer hilft? Da es Meinungsverschiedenheiten darüber geben könnte, bei was der Paketbetreuer tatsächlich Hilfe benötigt und wobei nicht, existiert die DELAYED-Warteschlange. Sie gibt dem Paketbetreuer Zeit, um zu reagieren und hat den positiven Nebeneffekt, dass unabhängige Überprüfungen des NMU-Diffs möglich sind.

en: Did you give enough time to the maintainer? When was the bug reported to the BTS? Being busy for a week or two isn't unusual. Is the bug so severe that it needs to be fixed right now, or can it wait a few more days?
de: Haben Sie dem Paketbetreuer genug Zeit gegeben? Wann wurde der Fehler an das BTS gemeldet? Es ist nicht unüblich, für eine oder zwei Wochen beschäftigt zu sein. Ist der Fehler so schwer, dass er jetzt sofort behoben werden muss oder kann er noch ein paar Tage warten?

en: How confident are you about your changes? Please remember the Hippocratic Oath: "Above all, do no harm." It is better to leave a package with an open grave bug than applying a non-functional patch, or one that hides the bug instead of resolving it. If you are not 100% sure of what you did, it might be a good idea to seek advice from others. Remember that if you break something in your NMU, many people will be very unhappy about it.
de: Wie überzeugt sind Sie von Ihren Änderungen? Bitte erinnern Sie sich an den hippokratischen Eid: "Verursachen Sie vor allem keinen Schaden". Es ist besser, ein Paket mit einem offenen schweren Fehler zu belassen, als einen nicht funktionierenden Patch darauf anzuwenden oder einen, das den Fehler versteckt, anstatt Ihn zu beheben. Falls Sie nicht 100% sicher sind, was Sie getan haben, könnte es eine gute Idee sein, den Rat anderer zu suchen. Vergessen Sie nicht, das viele Leute sauer sind, wenn Ihr NMU etwas kaputt macht.

en: Have you clearly expressed your intention to NMU, at least in the BTS? If that didn't generate any feedback, it might also be a good idea to try to contact the maintainer by other means (email to the maintainer addresses or private email, IRC).
de: Haben Sie Ihre Absicht, einen NMU durchzuführen, zumindest im BTS klar ausgedrückt? Falls dies zu keinen Rückmeldungen führte, ist es außerdem ratsam, zu versuchen, den Paketbetreuer auf andere Arten zu kontaktieren (private E-Mail, IRC).

en: If the maintainer is usually active and responsive, have you tried to contact them? In general it should be considered preferable that maintainers take care of an issue themselves and that they are given the chance to review and correct your patch, because they can be expected to be more aware of potential issues which an NMUer might miss. It is often a better use of everyone's time if the maintainer is given an opportunity to upload a fix on their own.
de: Haben Sie versucht, den Betreuer zu kontaktieren, falls er normalerweise aktiv und zugänglich ist? Im Allgemeinen sollte es als wünschenswert erachtet werden, dass sich Betreuer selbst um ein Problem kümmern und dass sie die Möglichkeit haben, Ihren Patch zu überprüfen und zu korrigieren, da sie potentielle Probleme kennen sollten, die demjenigen fehlen könnten, der ein NMU durchführt. Die Zeit wird meist besser investiert, wenn dem Betreuer die Gelegenheit gegeben wird, eine Fehlerbehebung selbst hochzuladen.

en: When doing an NMU, you must first make sure that your intention to NMU is clear. Then, you must send a patch with the differences between the current package and your proposed NMU to the BTS. The ``nmudiff`` script in the ``devscripts`` package might be helpful.
de: Wenn Sie einen NMU durchführen, sollten Sie zuerst dafür sorgen, dass Ihre Absicht klar ist, einen NMU durchzuführen. Dann müssen Sie einen Patch mit den Unterschieden zwischen dem aktuellen Paket und dem geplanten NMU an das BTS senden. Das Skript ``nmudiff`` im Paket ``devscripts`` könnte hilfreich sein.

en: While preparing the patch, you had better be aware of any package-specific practices that the maintainer might be using. Taking them into account reduces the burden of integrating your changes into the normal package workflow and thus increases the chances that integration will happen. A good place to look for possible package-specific practices is |debian/README.source|_.
de: Während Sie den Patch vorbereiten, sollten Sie sich über die paketspezifischen Verfahren bewusst sein, die der Betreuer möglicherweise benutzt. Diese einzubeziehen verringert dessen Aufwand, Ihre Änderungen im normalen Arbeitsablauf des Pakets zu integrieren und erhöht daher die Wahrscheinlichkeit, dass dies auch geschieht. Paket spezifische Methoden sind in |debian/README.source|_ beschrieben.

en: Unless you have an excellent reason not to do so, you must then give some time to the maintainer to react (for example, by uploading to the ``DELAYED`` queue). Here are some recommended values to use for delays:
de: Sofern Sie keinen wichtigen Grund haben, dies nicht zu tun, müssen Sie dem Paketbetreuer Zeit zum Reagieren geben (zum Beispiel durch Hochladen in die ``DELAYED``-Warteschlange). Hier sind einige empfohlene Werte für solche Wartezeiten:

en: Upload fixing only release-critical bugs older than 7 days, with no maintainer activity on the bug for 7 days and no indication that a fix is in progress: 0 days
de: Der Upload behebt nur veröffentlichungskritische Fehler, die älter als sieben Tage sind, ohne Betreueraktivität beim Fehler für sieben Tage und ohne Hinweis, dass eine Fehlerbehebung im Gang ist: 0 Tage

en: Upload fixing only release-critical bugs older than 7 days: 2 days
de: Upload, der nur veröffentlichungskritische Fehler behebt, die älter als sieben Tage sind: zwei Tage

en: Upload fixing only release-critical and important bugs: 5 days
de: Upload, der nur veröffentlichungskritische Fehler und Fehler mit Schweregrad "important" behebt: fünf Tage

en: Those delays are only examples. In some cases, such as uploads fixing security issues, or fixes for trivial bugs that block a transition, it is desirable that the fixed package reaches ``unstable`` sooner.
de: Diese Verzögerungen sind nur Beispiele. In manchen Fällen, wie bei Uploads, die Sicherheitsprobleme beheben, oder bei der Behebung belangloser Fehler, die einen Übergang blockieren, ist es wünschenswert, dass ein korrigiertes Paket ``Unstable`` eher erreicht.

en: Sometimes, release managers decide to encourage NMUs with shorter delays for a subset of bugs (e.g release-critical bugs older than 7 days). Also, some maintainers list themselves in the `Low Threshold NMU list <https://wiki.debian.org/LowThresholdNmu>`__, and accept that NMUs are uploaded without delay. But even in those cases, it's still a good idea to give the maintainer a few days to react before you upload, especially if the patch wasn't available in the BTS before, or if you know that the maintainer is generally active.
de: Manchmal entscheiden Veröffentlichungsverwalter, NMUs mit kürzeren Verzögerungen für eine Untermenge von Fehlern zu erlauben (z.B. veröffentlichungskritische Fehler, die älter als sieben Tage sind). Außerdem führen manche Paketbetreuer sich selbst in der Liste `LowThresholdNmu <https://wiki.debian.org/LowThresholdNmu>`__ (niedrige Schwellwerte für NMUs) auf und akzeptieren, dass NMUs ohne Verzögerung hochgeladen werden. Aber sogar in diesen Fällen ist es immer noch ratsam, dem Betreuer ein paar Tage Zeit zum Reagieren zu geben, bevor Sie etwas hochladen, insbesondere wenn der Patch vorher nicht im BTS verfügbar war oder falls Sie wissen, dass der Paketbetreuer allgemein aktiv ist.

en: After you upload an NMU, you are responsible for the possible problems that you might have introduced. You must keep an eye on the package (subscribing to the package on the PTS is a good way to achieve this).
de: Nachdem Sie einen NMU hochgeladen haben, sind Sie für mögliche Probleme verantwortlich, die Sie möglicherweise eingeleitet haben. Sie müssen das Paket im Auge behalten (ein gute Möglichkeit dafür ist, das Paket im PTS zu abonnieren ).

en: This is not a license to perform NMUs thoughtlessly. If you NMU when it is clear that the maintainers are active and would have acknowledged a patch in a timely manner, or if you ignore the recommendations of this document, your upload might be a cause of conflict with the maintainer. You should always be prepared to defend the wisdom of any NMU you perform on its own merits.
de: Dies ist keine Lizenz, rücksichtslos NMUs durchzuführen. Falls Sie einen NMU auf den Weg bringen, während klar ist, dass die Betreuer aktiv sind und einen Patch zeitnah anerkennen würden oder falls Sie die Empfehlungen dieses Dokuments ignorieren, könnte Ihr Upload zu einem Konflikt mit dem Betreuer führen. Sie sollten immer darauf vorbereitet sein, im Nachhinein für den von Ihnen durchgeführten NMU aus eigener Kraft einstehen zu können.

en: NMUs and ``debian/changelog``
de: NMUs und ``debian/changelog``

en: Just like any other (source) upload, NMUs must add an entry to ``debian/changelog``, telling what has changed with this upload. The first line of this entry must explicitly mention that this upload is an NMU, e.g.:
de: Genauso wie bei jedem anderen (Quell-) Upload muss bei NMUs ein Eintrag in ``debian/changelog`` hinzufügt werden, der mitteilt, was mit diesem Upload geändert wurde. Die erste Zeile muss explizit erwähnen, dass dieser Upload ein NMU ist, z.B:

en: The way to version NMUs differs for native and non-native packages.
de: Die Möglichkeiten der Versionsvergabe für NMUs unterscheidet sich bei nativen und nicht nativen Paketen.

en: If the package is a native package (without a Debian revision in the version number), the version must be the version of the last maintainer upload, plus ``+nmu``\ *X*, where *X* is a counter starting at ``1``. If the last upload was also an NMU, the counter should be increased. For example, if the current version is ``1.5``, then an NMU would get version ``1.5+nmu1``.
de: Falls es sich um ein natives Paket (ohne Debian-Revision in der Versionsnummer) handelt, muss die Versionsnummer die des letzten Betreuer-Uploads plus ``+nmu``\ *X* sein, wobei *X* ein Zähler ist, der bei ``1`` beginnt. Falls der letzte Upload auch ein NMU war, wird der Zähler erhöht. Wenn beispielsweise die aktuelle Version ``1.5`` ist, dann hätte der NMU die Version ``1.5+nmu1``.

en: If the package is not a native package, you should add a minor version number to the Debian revision part of the version number (the portion after the last hyphen). This extra number must start at ``1``. For example, if the current version is ``1.5-2``, then an NMU would get version ``1.5-2.1``. If a new upstream version is packaged in the NMU, the Debian revision is set to ``0``, for example ``1.6-0.1``.
de: Falls es sich um kein natives Paket handelt, sollten Sie eine untergeordnete Versionsnummer zum Debian-Revisionsteil der Versionsnummer hinzufügen (der Teil nach dem letzten Bindestrich). Diese zusätzliche Zahl muss bei ``1`` anfangen. Wenn zum Beispiel die aktuelle Version ``1.5-2`` ist, dann würde ein NMU die Version ``1.5-2.1`` erhalten. Falls eine neue Originalversion im NMU paketiert wird, wird die Debian-Revision auf ``0`` gesetzt, zum Beispiel ``1.6-0.1``.

en: In both cases, if the last upload was also an NMU, the counter should be increased. For example, if the current version is ``1.5+nmu3`` (a native package which has already been NMUed), the NMU would get version ``1.5+nmu4``.
de: In beiden Fällen sollte der Zähler erhöht werden, falls der letzte Upload auch ein NMU war. Wenn zum Beispiel die letzte Version ``1.5+nmu3`` war (ein natives Paket, für das bereits ein NMU durchgeführt wurde), würde der NMU die Version ``1.5+nmu4`` erhalten.

en: A special versioning scheme is needed to avoid disrupting the maintainer's work, since using an integer for the Debian revision will potentially conflict with a maintainer upload already in preparation at the time of an NMU, or even one sitting in the ftp NEW queue. It also has the benefit of making it visually clear that a package in the archive was not made by the official maintainer.
de: Es wird ein spezielles Schema der Versionsvergabe benötigt, um zu verhindern, dass die Arbeit des Betreuers unterbrochen wird, da die Benutzung einer Ganzzahl für die Debian-Revision einen potentiellen Konflikt mit einem Betreuer-Upload hervorruft, der bereits zur Zeit des NMUs vorbereitet wird oder sogar in der Ftp-Warteschlange NEW ist. Es hat außerdem den Vorteil, dass es optisch klar erkennbar ist, wenn ein Paket im Archiv nicht vom offiziellen Betreuer stammt.

en: If you upload a package to testing or stable, you sometimes need to "fork" the version number tree. This is the case for security uploads, for example. For this, a version of the form ``+deb``\ *X*\ ``u``\ *Y* should be used, where *X* is the major release number, and *Y* is a counter starting at ``1``. For example, while |codename-stable| (Debian |version-stable|) is stable, a security NMU to stable for a package at version ``1.5-3`` would have version |version2-revision-deb-version-stable-u1|, whereas a security upload to |codename-testing| would get version |version2-revision-deb-version-testing-u1|.
de: Falls Sie ein Paket nach Testing oder Stable hochladen, müssen Sie manchmal den Versionsnummernbaum "verzweigen". Dies ist zum Beispiel der Fall beim Hochladen von Sicherheitsaktualisierungen. Dazu sollte eine Version der Form ``+deb``\ *X*\ ``u``\ *Y* benutzt werden, wobei *X* die Major-Release-Nummer und *Y* eine fortlaufende, bei ``1`` beginnende Nummer ist. Während zum Beispiel |codename-stable| (Debian |version-stable|) Stable ist, hätte ein Sicherheits-NMU für Stable für ein Paket mit der Version ``1.5-3`` die Version |version2-revision-deb-version-stable-u1|, während ein Sicherheits-NMU für |codename-testing| die Version |version2-revision-deb-version-testing-u1| erhalten würde.

en: Using the ``DELAYED/`` queue
de: Benutzung der Warteschlange ``DELAYED/``

en: Having to wait for a response after you request permission to NMU is inefficient, because it costs the NMUer a context switch to come back to the issue. The ``DELAYED`` queue (see :ref:`delayed-incoming`) allows the developer doing the NMU to perform all the necessary tasks at the same time. For instance, instead of telling the maintainer that you will upload the updated package in 7 days, you should upload the package to ``DELAYED/7`` and tell the maintainer that they have 7 days to react. During this time, the maintainer can ask you to delay the upload some more, or cancel your upload.
de: Nachdem Sie um Erlaubnis ersucht haben, einen NMU durchzuführen, ist es ineffizient, auf eine Antwort zu warten, da es für denjenigen, der den NMU durchführt, einen Kontextwechsel zurück zu diesem Thema erfordert. Die Warteschlange ``DELAYED`` (siehe :ref:`delayed-incoming`) ermöglicht es einem Entwickler, einen NMU und alle nötigen Aufgaben gleichzeitig durchzuführen. Anstatt zum Beispiel dem Betreuer mitzuteilen, dass Sie das aktualisierte Paket in sieben Tagen hochladen werden, sollten Sie das Paket nach ``DELAYED/7`` hochladen und dem Betreuer mitteilen, dass er sieben Tage Zeit hat, um zu reagieren. Während dieser Zeit kann der Betreuer Sie bitten, den Upload etwas länger aufzuschieben oder Ihren Upload abzubrechen.

en: You can cancel your upload using :ref:`dcut`. In case you uploaded ``foo_1.2-1.1_all.changes`` to a ``DELAYED`` queue, you can run ``dcut cancel foo_1.2-1.1_all.changes`` to cancel your upload. The ``.changes`` file does not need to be present locally as you instruct :ref:`dcut` to upload a command file removing a remote filename. The ``.changes`` file name is the same that you used when uploading.
de: Ein Upload kann durch :ref:`dcut` abgebrochen werden. Falls Sie ``foo_1.2-1.1_all.changes`` zu einer ``DELAYED``-Queue hochgeladen haben, dann können Sie ``dcut cancel foo_1.2-1.1_all.changes`` verwenden, um den Upload abzubrechen. Die ``.changes``-Datei muss hierzu nicht mehr lokal vorliegen, da Sie :ref:`dcut` angewiesen haben, eine Kommandodatei hochzuladen, durch die eine entfernt liegende Datei gelöscht werden soll. Der Name der ``.changes``-Datei ist derselbe, der auch beim Upload gesendet worden ist.

en: The ``DELAYED`` queue should not be used to put additional pressure on the maintainer. In particular, it's important that you are available to cancel or delay the upload before the delay expires since the maintainer cannot cancel the upload themselves.
de: Die Warteschlange ``DELAYED`` sollte nicht benutzt werden, um zusätzlichen Druck auf den Paketbetreuer auszuüben. Es ist besonders wichtig, dass Sie erreichbar sind, um die Verzögerung des Uploads abzubrechen, bevor die Zeit abläuft, da der Betreuer den Upload nicht selbst abbrechen kann.

en: If you make an NMU to ``DELAYED`` and the maintainer updates the package before the delay expires, your upload will be rejected because a newer version is already available in the archive. Ideally, the maintainer will take care to include your proposed changes (or at least a solution for the problems they address) in that upload.
de: Falls Sie einen NMU nach ``DELAYED`` durchführen und der Betreuer das Paket vor Ablauf der Verzögerung aktualisiert, wird Ihr Upload abgelehnt, da bereits eine neuere Version im Archiv verfügbar ist. Idealerweise achtet der Betreuer darauf, dass er die von Ihnen vorgeschlagenen Änderungen (oder zumindest eine Lösung für die Probleme, die sie behandeln) in diesen Upload einfließen lässt.

en: NMUs from the maintainer's point of view
de: NMUs aus Sicht des Paketbetreuers

en: When someone NMUs your package, this means they want to help you to keep it in good shape. This gives users fixed packages faster. You can consider asking the NMUer to become a co-maintainer of the package. Receiving an NMU on a package is not a bad thing; it just means that the package is interesting enough for other people to work on it.
de: Wenn jemand einen NMU Ihres Pakets durchführt, bedeutet dies, dass er Ihnen helfen möchte, es in einem guten Zustand zu halten. Dies beschert den Anwendern schneller korrigierte Pakete. Sie könnten überlegen, ob Sie denjenigen, der den NMU durchführte, fragen möchten ob er Mitbetreuer des Pakets werden will. Der Erhalt eines NMUs für ein Paket ist keine schlechte Sache, es bedeutet nur, dass das Paket interessant genug ist, dass andere Leute daran arbeiten.

en: To acknowledge an NMU, include its changes and changelog entry in your next maintainer upload. If you do not acknowledge the NMU by including the NMU changelog entry in your changelog, the bugs will remain closed in the BTS but will be listed as affecting your maintainer version of the package.
de: Um einen NMU anzuerkennen, schließen Sie dessen Änderungen und Änderungsprotokolleinträge in Ihren nächsten Upload ein. Falls Sie den NMU nicht anerkennen, schließen Sie den Änderungsprotokolleintrag des NMUs in Ihr Änderungsprotokoll ein, die Fehler bleiben im BTS geschlossen, werden aber als Ihre Betreuerversion des Pakets betreffend aufgeführt.

en: Note that if you ever need to revert a NMU that packages a new upstream version, it is recommended to use a fake upstream version like *CURRENT*\ ``+really``\ *FORMER* until one can upload the latest version again. More information can be found in https://www.debian.org/doc/debian-policy/ch-controlfields.html#epochs-should-be-used-sparingly\ .
de: Wenn Sie jemals einen NMU zurücksetzen müssen, der eine neuere Upstreamversion paketiert hat, dann sollten Sie eine "Fake" Upstreamversion wie *AKTUELL*\ ``+really``\ *VORHERIGE* benutzen bis die neueste Version erneut hochgeladen werden kann. Weitere Informationen finden Sie unter https://www.debian.org/doc/debian-policy/ch-controlfields.html#epochs-should-be-used-sparingly\ .

en: Source NMUs vs Binary-only NMUs (binNMUs)
de: Quell-NMUs gegenüber rein binären NMUs (binNMUs)

en: The full name of an NMU is *source NMU*. There is also another type, namely the *binary-only NMU*, or *binNMU*. A binNMU is also a package upload by someone other than the package's maintainer. However, it is a binary-only upload.
de: Der vollständige Name eines NMUs ist *Quell-NMU*. Es gibt auch einen anderen Typ, der *rein binärer NMU* oder *binNMU* genannt wird. Ein binNMU ist ebenfalls ein Paket-Upload durch jemand anderes als den Paketbetreuer. Er ist jedoch rein binär.

en: When a library (or other dependency) is updated, the packages using it may need to be rebuilt. Since no changes to the source are needed, the same source package is used.
de: Wenn eine Bibliothek (oder andere Abhängigkeit) aktualisiert wird, könnte es notwendig sein, das Paket neu zu erstellen. Da keine Änderungen am Quellcode nötig sind, wird das gleiche Quellpaket benutzt.

en: BinNMUs are usually triggered on the buildds by wanna-build. An entry is added to ``debian/changelog``, explaining why the upload was needed and increasing the version number as described in :ref:`binary-only-nmu`. This entry should not be included in the next upload.
de: BinNMUs werden üblicherweise auf Buildds durch Wanna-Build ausgelöst. ``debian/changelog`` wird ein Eintrag hinzugefügt, der erklärt warum der Upload nötig war und die Versionsnummer wird, wie in :ref:`binary-only-nmu` beschrieben, erhöht. Dieser Eintrag sollte nicht im nächsten Upload enthalten sein.

en: Buildds upload packages for their architecture to the archive as binary-only uploads. Strictly speaking, these are binNMUs. However, they are not normally called NMU, and they don't add an entry to ``debian/changelog``.
de: Buildds laden Pakete für ihre Architektur als rein binäre Uploads in das Archiv hoch. Genaugenomen sind dies die binNMUs. Sie werden jedoch normalerweise nicht als NMU bezeichnet und fügen ``debian/changelog`` keinen Eintrag hinzu.

en: NMUs vs QA uploads
de: NMUs gegenüber QS-Uploads

en: NMUs are uploads of packages by somebody other than their assigned maintainer. There is another type of upload where the uploaded package is not yours: QA uploads. QA uploads are uploads of orphaned packages.
de: NMUs sind Uploads von Paketen durch jemand anderes als den ihnen zugewiesenen Betreuer. Es gibt noch einen anderen Upload-Typ bei dem das hochgeladene Paket nicht dem Uploader gehört: QA-Uploads. QA-Uploads sind Uploads für verwaiste Pakete.

en: QA uploads are very much like normal maintainer uploads: they may fix anything, even minor issues; the version numbering is normal, and there is no need to use a delayed upload. The difference is that you are not listed as the ``Maintainer`` or ``Uploader`` for the package. Also, the changelog entry of a QA upload has a special first line:
de: QS-Uploads sind normalen Betreuer-Uploads sehr ähnlich: Diese können alles korrigieren, sogar kleine Probleme. Die Versionsnummerierung ist normal und es sind keine verzögerten Uploads nötig. Der Unterschied besteht darin, dass Sie nicht als ``Maintainer`` oder ``Uploader`` des Pakets aufgeführt werden. Außerdem hat der Änderungsprotokolleintrag eines QS-Uploads eine spezielle erste Zeile:

en: If you want to do an NMU, and it seems that the maintainer is not active, it is wise to check if the package is orphaned (this information is displayed on the package's Package Tracking System page). When doing the first QA upload to an orphaned package, the maintainer should be set to ``Debian QA Group <packages@qa.debian.org>``. Orphaned packages which did not yet have a QA upload still have their old maintainer set. There is a list of them at https://qa.debian.org/orphaned.html\ .
de: Falls Sie einen NMU durchführen möchten und es so aussieht, als sei der Betreuer nicht aktiv, ist es vernünftig zu prüfen, ob das Paket verwaist ist (diese Information wird auf der Seite des Pakets im Paketverfolgungssystem "PTS" angezeigt). Beim ersten QS-Upload zu einem verwaisten Paket sollte der Betreuer auf ``Debian QA Group <packages@qa.debian.org>`` gesetzt werden. Bei verwaisten Paketen, für die noch kein QS-Upload durchgeführt wurde, ist immer noch der alte Betreuer gesetzt. Eine Liste dieser Pakete finden Sie unter https://qa.debian.org/orphaned.html\ .

en: Instead of doing a QA upload, you can also consider adopting the package by making yourself the maintainer. You don't need permission from anybody to adopt an orphaned package; you can just set yourself as maintainer and upload the new version (see :ref:`adopting`).
de: Anstatt einen QS-Upload durchzuführen, können Sie auch erwägen, das Paket zu adoptieren, indem Sie sich selbst zum Betreuer machen. Sie benötigen von niemandem eine Erlaubnis, um ein verwaistes Paket zu adoptieren, Sie müssen sich nur selbst als Betreuer einsetzen und die neue Version hochladen (siehe :ref:`adopting`).

en: NMUs vs team uploads
de: NMUs gegenüber Team-Uploads

en: Sometimes you are fixing and/or updating a package because you are member of a packaging team (which uses a mailing list as ``Maintainer`` or ``Uploader``; see :ref:`collaborative-maint`) but you don't want to add yourself to ``Uploaders`` because you do not plan to contribute regularly to this specific package. If it conforms with your team's policy, you can perform a normal upload without being listed directly as ``Maintainer`` or ``Uploader``. In that case, you should start your changelog entry with the following line:
de: Manchmal korrigieren und/oder aktualisieren Sie ein Paket, weil Sie Mitglied des Paketierungs-Teams sind (das als ``Maintainer`` oder ``Uploader`` eine Mailingliste benutzt, siehe :ref:`collaborative-maint`), aber Sie möchten sich selbst nicht zu den ``Uploaders`` hinzufügen, da Sie nicht planen, regulär an diesem speziellen Paket mitzuarbeiten. Falls dies mit den Leitlinien Ihres Teams in Einklang steht, können Sie einen normalen Upload durchführen, ohne direkt als ``Maintainer`` oder ``Uploader`` aufgeführt zu werden. In diesem Fall sollten Sie Ihren Änderungsprotokolleintrag mit der folgenden Zeile beginnen:

en: Package Salvaging
de: Pakete bergen

en: Package salvaging is the process by which one attempts to save a package that, while not officially orphaned, appears poorly maintained or completely unmaintained. This is a weaker and faster procedure than orphaning a package officially through the powers of the MIA team. Salvaging a package is not meant to replace MIA handling, and differs in that it does not imply anything about the overall activity of a maintainer. Instead, it handles a package maintainership transition for a single package only, leaving any other package or Debian membership or upload rights (when applicable) untouched.
de: "Pakete bergen" (package salvaging) ist der Prozess, mit dem man versucht, ein Paket zu retten, das zwar offiziell nicht verwaist ist, jedoch schlecht oder gar nicht gepflegt wird. Dies ist ein schwächeres und schnelleres Verfahren, als ein Paket offiziell durch die Befugnisse des MIA-Teams zu verwaisen. Das Bergen eines Pakets ist nicht als Ersatz für das MIA-Handling gedacht und unterscheidet sich insofern, als es nichts über die generelle Aktivität eines Betreuers aussagt. Stattdessen sorgt es nur für die Übertragung des Betreuerstatus eines einzelnen Pakets, wobei alle anderen Paket-, Debian-Mitgliedschafts- oder Upload-Rechte (sofern zutreffend) unberührt bleiben.

en: Note that the process is only intended for actively taking over maintainership. Do not start a package salvaging process when you do not intend to maintain the package for a prolonged time. If you only want to fix certain things, but not take over the package, you must use the NMU process, even if the package would be eligible for salvaging. The NMU process is explained in :ref:`nmu`.
de: Beachten Sie, dass der Prozess nur für die aktive Übernahme der Paketbetreuung gedacht ist. Starten Sie keine Paketbergung, wenn Sie nicht beabsichtigen, das Paket für längere Zeit zu betreuen. Wenn Sie nur bestimmte Dinge reparieren wollen, aber das Paket nicht übernehmen möchten, müssen Sie den NMU-Prozess verwenden, selbst wenn das Paket für eine Bergung berechtigt wäre. Der NMU-Prozess wird in :ref:`nmu` erläutert.

en: Another important thing to remember: It is not acceptable to hijack others' packages. If followed, this salvaging process will help you to ensure that your endeavour is not a hijack but a (legal) salvaging procedure, and you can counter any allegations of hijacking with a reference to this process. Thanks to this process, new contributors should no longer be afraid to take over packages that have been neglected or entirely forgotten.
de: Vergessen Sie nicht: Es ist inakzeptabel, Pakete anderer zu entführen. Wenn Sie sich an diesen Bergungsprozess halten, wird er Ihnen helfen sicherzustellen, dass Ihr Vorhaben keine Entführung ist, sondern eine (legale) Bergung, und Sie können dann allen Vorwürfen der Entführung mit einer Bezugnahme auf diesen Prozess entgegentreten. Dank dieses Prozesses sollten neue Beitragende keine Angst mehr haben, Pakete zu übernehmen, die vernachlässigt oder völlig vergessen wurden.

en: The process is split into two phases: In the first phase you determine whether the package in question is *eligible* for the salvaging process. Only when the eligibility has been determined you may enter the second phase, the *actual* package salvaging.
de: Der Prozess ist in zwei Phasen unterteilt: In der ersten Phase stellen Sie fest, ob das fragliche Paket für den Bergungsprozess *berechtigt* ist. Nur wenn die Berechtigung festgestellt wurde, können Sie in die zweite Phase, das *eigentliche* Paketbergen, eintreten.

en: For additional information, rationales and FAQs on package salvaging, please visit the `Salvaging Packages <https://wiki.debian.org/PackageSalvaging>`__ page on the Debian wiki.
de: Für weitere Informationen, Begründungen und FAQs zur Paketbergung besuchen Sie bitte die Seite `Pakete bergen <https://wiki.debian.org/PackageSalvaging>`__ im Debian-Wiki.

en: When a package is eligible for package salvaging
de: Wann es berechtigt ist, ein Paket zu bergen

en: A package becomes eligible for salvaging when it has been neglected by the current maintainer. To determine that a package has really been neglected by the maintainer, the following indicators give a rough idea what to look for:
de: Ein Paket darf geborgen werden, wenn es vom aktuellen Betreuer vernachlässigt wurde. Um festzustellen, ob ein Paket vom Betreuer wirklich vernachlässigt wurde, können die folgenden Indikatoren Hinweise darauf geben:

en: NMUs, especially if there has been more than one NMU in a row.
de: NMUs, insbesondere wenn es mehrere aufeinanderfolgende NMUs gegeben hat.

en: Bugs filed against the package do not have answers from the maintainer.
de: Gegen das Paket eingereichte Fehlerberichte haben keine Antwort vom Betreuer.

en: Upstream has released several versions, but despite there being a bug entry asking for it, it has not been packaged.
de: Die Originalautoren haben mehrere neue Versionen veröffentlicht, aber trotz dass es einen Fehlerbericht gibt, der darum bittet, die Version zu paketieren, ist dies nicht geschehen.

en: There are QA issues with the package.
de: Das Paket hat Qualitätssicherungsprobleme.

en: You will have to use your judgement as to whether a given combination factors constitutes neglect; in case the maintainer disagrees they have only to say so (see below). If you're not sure about your judgement or simply want to be on the safe side, there is a more precise (and conservative) set of conditions in the `Package Salvaging <https://wiki.debian.org/PackageSalvaging>`__ wiki page. These conditions represent a current Debian consensus on salvaging criteria. In any case you should explain your reasons for thinking the package is neglected when you file an Intent to Salvage bug later.
de: Sie müssen sich selbst ein Urteil darüber bilden, ob die Kombination aus den gegebenen Faktoren eine Vernachlässigung darstellt. Wenn der Betreuer anderer Meinung ist, reicht es aus, wenn er es sagt (siehe unten). Wenn Sie sich über Ihr Urteil nicht sicher sind oder einfach auf der sicheren Seite sein wollen, gibt es einen präziseren (und konservativeren) Satz von Bedingungen auf der `Paket-Bergungs <https://wiki.debian.org/PackageSalvaging>`__-Wiki-Seite. Diese Bedingungen repräsentieren einen aktuellen Debian-Konsens bezüglich der Bergungskriterien. In jedem Fall sollten Sie Ihre Gründe erläutern, warum sie meinen, dass das Paket vernachlässigt ist, wenn Sie später den "Intent to Salvage" Fehlerbericht einreichen.

en: How to salvage a package
de: Wie man Pakete birgt

en: If and *only* if a package has been determined to be eligible for package salvaging, any prospective maintainer may start the following package salvaging procedure.
de: Wenn und *nur* wenn eine Paketbergung als gerechtfertigt festgestellt wurde, kann jeder potenzielle Betreuer das folgende Paketbergungsverfahren starten.

en: Open a bug with the severity "important" against the package in question, expressing the intent to take over maintainership of the package. For this, the title of the bug should start with ``ITS: package-name``\  [3]_. You may alternatively offer to only take co-maintenance of the package. When you file the bug, you must inform all maintainers, uploaders and if applicable the packaging team explicitly by adding them to ``X-Debbugs-CC``. Additionally, if the maintainer(s) seem(s) to be generally inactive, please inform the MIA team by adding ``mia@qa.debian.org`` to ``X-Debbugs-CC`` as well. As well as the explicit expression of the intent to salvage, please also take the time to document your assessment of the eligibility in the bug report, for example by listing the criteria you've applied and adding some data to make it easier for others to assess the situation.
de: Öffnen Sie einen Fehler mit dem Schweregrad "important" gegen das fragliche Paket und drücken Sie in diesem Ihre Absicht aus, das Paket zu übernehmen. Dazu sollte der Titel des Fehlers mit ``ITS: Paketname``\  [3]_ beginnen. Sie können alternativ anbieten, nur Mitbetreuer des Pakets zu werden. Wenn Sie den Fehler melden, müssen Sie alle Maintainer, Uploader und ggf. das Paketierungsteam explizit informieren, indem Sie sie zu ``X-Debbugs-CC`` hinzufügen. Falls der (die) Betreuer generell inaktiv zu sein scheinen, informieren Sie bitte das MIA-Team, indem Sie zusätzlich ``mia@qa.debian.org`` zu ``X-Debbugs-CC`` hinzufügen. Neben dem ausdrücklichen Erwähnen Ihrer Absicht zur Bergung des Paketes nehmen Sie sich bitte auch die Zeit, Ihre Einschätzung zu der Zulässigkeit des Bergens im Fehlerbericht zu dokumentieren, indem Sie beispielsweise die von Ihnen angewendeten Kriterien und zugehörige Daten anführen, um es anderen leichter zu machen, die Situation nachzuvollziehen.

en: In this step you need to wait in case any objections to the salvaging are raised; the maintainer, any current uploader or any member of the associated packaging team of the package in question may object publicly in response to the bug you've filed within ``21 days``, and this terminates the salvaging process.
de: In diesem Schritt müssen Sie warten, ob Einwände gegen die Bergung erhoben werden. Der Betreuer, jeder Mitbetreuer oder ein Mitglied des zugehörigen Paketierungsteams des betroffenen Pakets kann innerhalb von ``21 Tagen`` mittels einer Antwort in dem Fehlerbericht öffentlich widersprechen, wodurch der Bergungsprozess beendet wird.

en: The current maintainers may also agree to your intent to salvage by filing a (signed) public response to the the bug. They might propose that you become a co-maintainer instead of the sole maintainer. On team maintained packages, a member of the associated team can accept your salvaging proposal by sending out a signed agreement notice to the ITS bug, alternatively inviting you to become a new co-maintainer of the package. The team may require you to keep the package under the team's umbrella, but then may ask or invite you to join the team. In any of these cases where you have received the OK to proceed, you can upload the new package immediately as the new (co-)maintainer, without the need to utilise the ``DELAYED`` queue as described in the next step.
de: Die derzeitigen Betreuer können Ihrer Absicht zur Bergung auch zustimmen, indem sie eine entsprechende öffentliche (signierte) Antwort an den Fehlerbericht senden. Sie können vorschlagen, dass Sie Mitbetreuer anstatt alleiniger Betreuers werden. Bei Team-gepflegten Paketen kann ein Mitglied des zugehörigen Teams Ihren Bergungs-Vorschlag akzeptieren, indem er eine signierte Bestätigung an den ITS-Fehlerbericht sendet. Alternativ können die bisherigen Betreuer Sie wiederum bitten, stattdessen neuer Mitbetreuer des Pakets zu werden. Das Team kann verlangen, dass Sie das Paket im Team belassen, Sie aber fragen oder Sie einladen, dem Team beizutreten. In all diesen Fällen, in denen Sie ein OK erhalten haben, fortzufahren, können Sie das neue Paket sofort als neuer (Mit-)Betreuer hochladen, ohne die ``DELAYED``-Warteschlange, wie im nächsten Abschnitt beschrieben, verwenden zu müssen.

en: After the 21 days delay, if no answer has been sent to the bug from the maintainer, one of the uploaders or team, you may upload the new release of the package into the ``DELAYED`` queue with a minimum delay of ``seven days``. You should close the salvage bug in the changelog and you must also send an nmudiff to the bug ensuring that copies are sent to the maintainer and any uploaders (including teams) of the package by ``CC'ing`` them in the mail to the BTS.
de: Wenn nach den 21 Tagen keine Antwort vom Betreuer, einem der Mitbetreuer oder dem Team an den Fehlerbericht gesendet wurde, können Sie die neue Version des Pakets mit einer minimalen Verzögerung von ``sieben Tagen`` in die ``DELAYED``-Warteschlange hochladen. Sie sollten den ITS-Fehlerbericht über einen Eintrag im Changelog schließen. Sie müssen auch einen nmudiff an den Fehler senden, und dabei sicherzustellen, dass Kopien an den Betreuer und alle Mitbetreuer (einschließlich des Teams) des Pakets gesendet werden, indem Sie sie in der Mail an den Fehlerbericht unter ``CC`` eintragen.

en: During the waiting time of the ``DELAYED`` queue, the maintainer can accept the salvaging, do an upload themselves or (ask to) cancel the upload. The latter two of these will also stop the salvaging process, but the maintainer must reply to the salvaging bug with more information about their action.
de: Während der Wartezeit in ``DELAYED`` kann der Betreuer die Bergung akzeptieren, selbst hochladen oder darum bitten, den Upload abzubrechen bzw. ihn selbst abbrechen. Die letzten beiden Fälle stoppen den Bergungsprozess, jedoch muss der Betreuer dann in dem ITS Fehlereintrag seine Aktionen begründen.

en: Collaborative maintenance
de: Gemeinschaftliche Verwaltung

en: Collaborative maintenance is a term describing the sharing of Debian package maintenance duties by several people. This collaboration is almost always a good idea, since it generally results in higher quality and faster bug fix turnaround times. It is strongly recommended that packages with a priority of ``standard`` or which are part of the base set have co-maintainers.
de: Gemeinschaftliche Verwaltung ist ein Begriff, der die gemeinsamen Verwaltungspflichten von Debian-Paketen durch mehrere Leute beschreibt. Diese Zusammenarbeit ist fast immer eine gute Idee, da sie generell in einer höheren Qualität und einer schnelleren Fehlerbehebungszeit resultiert. Es wird dringend empfohlen, dass Pakete, die die Priorität ``standard`` haben, oder Teil vom Basis-Paketsatz sind, Mitbetreuer haben.

en: Generally there is a primary maintainer and one or more co-maintainers. The primary maintainer is the person whose name is listed in the ``Maintainer`` field of the ``debian/control`` file. Co-maintainers are all the other maintainers, usually listed in the ``Uploaders`` field of the ``debian/control`` file.
de: Generell gibt es einen Hauptbetreuer und einen oder mehrere Mitbetreuer. Der Hauptbetreuer ist die Person, deren Name im Feld ``Maintainer`` der Datei ``debian/control`` steht. Mitbetreuer sind alle anderen Betreuer. Sie werden normalerweise in der Datei ``debian/control`` im Feld ``Uploaders`` aufgeführt.

en: In its most basic form, the process of adding a new co-maintainer is quite easy:
de: In seiner grundlegendsten Form ist der Prozess, neue Mitbetreuer hinzuzufügen ziemlich einfach:

en: Set up the co-maintainer with access to the sources you build the package from. Generally this implies you are using a network-capable version control system, such as ``Git``. Salsa (see :ref:`salsa-debian-org`) provides Git repositories, amongst other collaborative tools.
de: Richten Sie den Co-Maintainer mit Zugriff auf die Quellen ein, aus denen Sie das Paket erstellen. Im Allgemeinen bedeutet dies, dass Sie ein netzwerkfähiges Versionskontrollsystem wie ``Git`` verwenden. Salsa (siehe :ref:`salsa-debian-org`) bietet unter anderem Git-Repositories und andere kollaborative Werkzeuge.

en: Add the co-maintainer's correct maintainer name and address to the ``Uploaders`` field in the first paragraph of the ``debian/control`` file.
de: Fügen Sie im Feld ``Uploaders`` im ersten Absatz der Datei ``debian/control`` den korrekten Namen und die Adresse des Mitbetreuers ein.

en: Using the PTS (:ref:`pkg-tracker`), the co-maintainers should subscribe themselves to the appropriate source package.
de: Wird das PTS (:ref:`pkg-tracker`) benutzt, sollten sich die Mitbetreuer selbst für das entsprechende Quellpaket einschreiben.

en: Another form of collaborative maintenance is team maintenance, which is recommended if you maintain several packages with the same group of developers. In that case, the ``Maintainer`` and ``Uploaders`` field of each package must be managed with care. It is recommended to choose between one of the two following schemes:
de: Eine andere Form der gemeinschaftlichen Verwaltung stellt die Team-Verwaltung dar. Diese wird empfohlen, falls Sie mehrere Pakete mit der gleichen Entwicklergruppe verwalten. In diesem Fall müssen die Felder ``Maintainer`` und ``Uploaders`` jedes Pakets mit Vorsicht verwaltet werden. Es wird empfohlen, eines der beiden folgenden Schemen auszuwählen:

en: Put the team member mainly responsible for the package in the ``Maintainer`` field. In the ``Uploaders``, put the mailing list address, and the team members who care for the package.
de: Setzen Sie den Hauptverantwortlichen für das Paket in das Feld ``Maintainer`` ein. In ``Uploaders`` werden die Adresse der Mailingliste und die Team-Mitglieder, die sich um das Paket kümmern, eingetragen.

en: Put the mailing list address in the ``Maintainer`` field. In the ``Uploaders`` field, put the team members who care for the package. In this case, you must make sure the mailing list accepts bug reports without any human interaction (like moderation for non-subscribers).
de: Setzen Sie die Adresse der Mailingliste in das Feld ``Maintainer`` ein. Im Feld ``Uploaders`` werden die Team-Mitglieder eingetragen, die sich um das Paket kümmern. In diesem Fall müssen Sie sicherstellen, dass die Mailingliste Fehlerberichte ohne menschliches Eingreifen akzeptiert (wie Moderation für Nicht-Abonnenten).

en: In any case, it is a bad idea to automatically put all team members in the ``Uploaders`` field. It clutters the Developer's Package Overview listing (see :ref:`ddpo`) with packages one doesn't really care for, and creates a false sense of good maintenance. For the same reason, team members do not need to add themselves to the ``Uploaders`` field just because they are uploading the package once, they can do a “Team upload” (see :ref:`nmu-team-upload`). Conversely, it is a bad idea to keep a package with only the mailing list address as a ``Maintainer`` and no ``Uploaders``.
de: Es ist auf jeden Fall eine schlechte Idee, automatisch alle Team-Mitglieder in das Feld ``Uploaders`` einzutragen. Es überfüllt die Paketübersicht des Entwicklers (siehe :ref:`ddpo`) mit Paketen, um die sich nicht wirklich jemand kümmert und erweckt den falschen Eindruck einer guten Betreuung. Aus dem gleichen Grund müssen sich Team-Mitglieder nicht selbst im Feld ``Uploaders`` hinzufügen, nur weil sie das Paket einmal hochgeladen haben. Sie können einen Team-Upload durchführen (siehe :ref:`nmu-team-upload`). Im umgekehrten Fall ist es eine schlechte Idee, ein Paket nur mit der Adresse der Mailingliste im Feld ``Maintainer`` und ohne einen Eintrag in ``Uploaders`` zu belassen.

en: The testing distribution
de: Die Distribution Testing

en: Basics
de: Grundlagen

en: Packages are usually installed into the ``testing`` distribution after they have undergone some degree of testing in ``unstable``.
de: Pakete werden üblicherweise in der Distribution ``Testing`` installiert, nachdem sie in ``Unstable`` gewissen Tests unterzogen wurden.

en: They must be in sync on all architectures and mustn't have dependencies that make them uninstallable; they also have to have generally no known release-critical bugs at the time they're installed into ``testing``. This way, ``testing`` should always be close to being a release candidate. Please see below for details.
de: Sie müssen auf allen Architekturen synchron sein und dürfen keine Abhängigkeiten haben, die sie nicht installierbar machen. Außerdem dürfen sie zum Zeitpunkt, an dem sie in ``Testing`` installiert werden, keine bekannten veröffentlichungskritischen Fehler haben. Auf diese Art sollte ``Testing`` immer ein potentieller Veröffentlichungskandidat sein. Bitte lesen Sie das Folgende, um weitere Einzelheiten zu erfahren.

en: Updates from unstable
de: Aktualisierungen von Unstable

en: The scripts that update the ``testing`` distribution are run twice each day, right after the installation of the updated packages; these scripts are called ``britney``. They generate the ``Packages`` files for the ``testing`` distribution, but they do so in an intelligent manner; they try to avoid any inconsistency and to use only non-buggy packages.
de: Die Skripte, die die Distribution ``Testing`` aktualisieren, werden zweimal täglich ausgeführt, gleich nach der Installation der aktualisierten Pakete. Diese Skripte werden ``britney`` genannt. Sie generieren die ``Packages``-Dateien für die Distribution ``Testing``, aber dabei versuchen diese entsprechend clever zu agieren, sie versuchen jede Unstimmigkeit zu vermeiden und nur fehlerfreie Pakete zu benutzen.

en: The inclusion of a package from ``unstable`` is conditional on the following:
de: Die Aufnahme eines Pakets von ``Unstable`` ist von folgendem abhängig:

en: The package must have been available in ``unstable`` for a certain number of days, see :ref:`bpp-changelog-urgency`. Please note that the urgency is sticky, meaning that the highest urgency uploaded since the previous ``testing`` transition is taken into account;
de: Das Paket muss in ``unstable`` für eine bestimmte Anzahl an Tagen verfügbar sein (Siehe :ref:`bpp-changelog-urgency`). Bitte beachten Sie, dass die Dringlichkeit „sticky“ ist, was bedeutet, dass die höchste Dringlichkeitsstufe, die seit dem vorherigen Übergang zu `testing`` hochgeladen wurde, berücksichtigt wird.

en: It must not have new release-critical bugs (RC bugs affecting the version available in ``unstable``, but not affecting the version in ``testing``);
de: Es darf keine veröffentlichungskritischen Fehler haben (veröffentlichungskritische Fehler betreffend die in ``Unstable`` verfügbare Version, aber nicht die in ``Testing``).

en: It must be available on all architectures on which it has previously been built in ``unstable``. :ref:`dak-ls` may be of interest to check that information;
de: Es muss auf allen Architekturen verfügbar sein auf denen es vorher in ``Unstable`` erstellt wurde. Um diese Information zu prüfen, könnte :ref:`dak-ls` von Interesse sein.

en: It must not break any dependency of a package which is already available in ``testing``;
de: Es darf keine Abhängigkeiten von Paketen zerstören, die bereits in ``Testing`` verfügbar sind.

en: The packages on which it depends must either be available in ``testing`` or they must be accepted into ``testing`` at the same time (and they will be if they fulfill all the necessary criteria);
de: Die Pakete, von denen es abhängt, müssen entweder in ``Testing`` verfügbar sein oder sie müssen zur gleichen Zeit in ``Testing`` akzeptiert werden (und das werden sie, falls sie alle nötigen Kriterien erfüllen).

en: The phase of the project. I.e. automatic transitions are turned off during the *freeze* of the ``testing`` distribution.
de: Die aktuelle Phase des Projekts, d.h. zum Beispiel, dass automatische Übergänge während des *Freeze* der Distribution ``Testing`` ausgesetzt werden.

en: To find out whether a package is progressing into ``testing`` or not, see the ``testing`` script output on the `web page of the testing distribution <https://www.debian.org/devel/testing>`__, or use the program ``grep-excuses`` which is in the ``devscripts`` package. This utility can easily be used in a crontab 5 to keep yourself informed of the progression of your packages into ``testing``.
de: Um herauszufinden ob ein Paket den Übergang nach ``Testing`` erfolgreich durchläuft oder nicht, schauen Sie in die Ausgabe des ``Testing``-Skripts auf der Web-Seite `Debian "Testing"-Distribution <https://www.debian.org/devel/testing>`__ oder benutzen Sie das Programm ``grep-excuses`` aus dem Paket ``devscripts``. Dieses Hilfswerkzeug kann einfach in einer crontab 5 benutzt werden, um sich selbst auf dem aktuellen Stand über den Fortschritt des Pakets nach ``Testing`` zu informieren.

en: The ``update_excuses`` file does not always give the precise reason why the package is refused; you may have to find it on your own by looking for what would break with the inclusion of the package. The `testing web page <https://www.debian.org/devel/testing>`__ gives some more information about the usual problems which may be causing such troubles.
de: Die Datei ``update_excuses`` gibt nicht immer den genauen Grund an, warum ein Paket abgelehnt wurde. Sie können es selbst herausfinden, indem Sie schauen, was durch die Aufnahme des Pakets zerstört werden würde. Die Web-Seite `Debian "Testing"-Distribution <https://www.debian.org/devel/testing>`__ stellt einige weitere Informationen über die üblichen Probleme bereit, die derartigen Ärger verursachen.

en: Sometimes, some packages never enter ``testing`` because the set of interrelationship is too complicated and cannot be sorted out by the scripts. See below for details.
de: Manchmal errreichen einige Pakete ``Testing`` niemals, da die Zusammensetzung wechselseitiger Beziehungen zu kompliziert ist und durch das Skript nicht aufgelöst werden können. Im Folgenden finden Sie Einzelheiten.

en: Some further dependency analysis is shown on https://release.debian.org/migration/\  — but be warned: this page also shows build dependencies that are not considered by britney.
de: Einige weitere Abhängigkeitsanalysen werden unter https://release.debian.org/migration/\  dargestellt — aber seien Sie gewarnt, diese Seite zeigt auch Build-Abhängigkeiten, die von Britney nicht berücksichtigt werden.

en: Out-of-date
de: Veraltet

en: For the ``testing`` migration script, outdated means: There are different versions in ``unstable`` for the release architectures (except for the architectures in outofsync_arches; outofsync_arches is a list of architectures that don't keep up (in ``britney.py``), but currently, it's empty). Outdated has nothing whatsoever to do with the architectures this package has in ``testing``.
de: Für das ``Testing`` Migrationsskript bedeutet veraltet: Es gibt verschiedene Versionen in``Unstable`` für die Release-Architekturen (mit Ausnahme der Architekturen in outofsync_arches, outofsync_arches ist eine Liste von Architekturen, die nicht mithalten ist (in ``britney.py``), derzeit aber leer ist). Veraltet hat überhaupt nichts mit den Architekturen zu tun, die dieses Paket in ``Testing`` hat.

en: Consider this example:
de: Sehen Sie sich dieses Beispiel an:

en: The package is out of date on ``alpha`` in ``unstable``, and will not go to ``testing``. Removing the package would not help at all; the package is still out of date on ``alpha``, and will not propagate to ``testing``.
de: Das Paket ist auf ``alpha`` in ``Unstable`` veraltet und wird nicht nach ``Testing`` gelangen. Das Paket zu entfernen würde überhaupt nicht helfen. Das Paket ist immer noch auf ``alpha`` veraltet und wird nicht nach ``Testing`` gelangen.

en: However, if ftp-master removes a package in ``unstable`` (here on ``arm``):
de: Falls FTP-Master jedoch ein Paket in ``Unstable`` entfernt (hier auf ``arm``):

en: In this case, the package is up to date on all release architectures in ``unstable`` (and the extra ``hurd-i386`` doesn't matter, as it's not a release architecture).
de: In diesem Fall ist das Paket auf allen Architekturen in ``Unstable`` aktuell (und das zusätzliche ``hurd-i386`` tut nichts zur Sache, da es keine Release-Architektur ist).

en: Sometimes, the question is raised if it is possible to allow packages in that are not yet built on all architectures: No. Just plainly no. (Except if you maintain glibc or so.)
de: Manchmal kommt die Frage auf, ob es möglich ist, Pakete aufzunehmen, die noch nicht auf allen Architekturen erstellt wurden: Nein. Einfach nur nein. (Außer Sie betreuen glibc oder ähnlich).

en: Removals from testing
de: Entfernen aus Testing

en: Sometimes, a package is removed to allow another package in: This happens only to allow *another* package to go in if it's ready in every other sense. Suppose e.g. that ``a`` cannot be installed with the new version of ``b``; then ``a`` may be removed to allow ``b`` in.
de: Manchmal wird ein Paket entfernt, um einem anderen Paket die Aufnahme zu gewähren. Dies geschieht nur, um einem *anderen* Paket die Aufnahme zu gewähren, falls dies sinnvoll ist. Angenommen, ``a`` könnte z.B. nicht mit der neuen Version von ``b`` installiert werden, dann könnte ``a`` entfernt werden, um ``b`` die Aufnahme zu ermöglichen.

en: Of course, there is another reason to remove a package from ``testing``: it's just too buggy (and having a single RC-bug is enough to be in this state).
de: Natürlich gibt es einen anderen Grund, ein Paket aus ``Testing`` zu entfernen. Es ist einfach zu fehlerhaft (und ein einfacher veröffentlichungskritischer Fehler reicht dafür aus).

en: Furthermore, if a package has been removed from ``unstable``, and no package in ``testing`` depends on it any more, then it will automatically be removed.
de: Wenn ein Paket außerdem aus ``Unstable`` entfernt wurde und kein Paket in ``Testing`` mehr davon abhängt, dann wird es automatisch entfernt.

en: Circular dependencies
de: Zirkulare Abhängigkeiten

en: A situation which is not handled very well by britney is if package ``a`` depends on the new version of package ``b``, and vice versa.
de: Eine Situation mit der Britney nicht gut klar kommt ist, wenn Paket ``a`` von einer neuen Version des Pakets ``b`` abhängt und umgekehrt.

en: An example of this is:
de: Ein Beispiel hierfür:

en: Neither package ``a`` nor package ``b`` is considered for update.
de: Weder Paket ``a`` noch Paket ``b`` wird für die Aktualisierung berücksichtigt.

en: Currently, this requires some manual hinting from the release team. Please contact them by sending mail to ``debian-release@lists.debian.org`` if this happens to one of your packages.
de: Aktuell erfordert dies einige manuelle Eingriffe des Release-Teams. Bitte kontaktieren Sie es per E-Mail an ``debian-release@lists.debian.org``, falls dies bei einem Ihrer Pakete auftritt.

en: Influence of package in testing
de: Beeinflussen eines Pakets in Testing

en: Generally, there is nothing that the status of a package in ``testing`` means for transition of the next version from ``unstable`` to ``testing``, with two exceptions: If the RC-bugginess of the package goes down, it may go in even if it is still RC-buggy. The second exception is if the version of the package in ``testing`` is out of sync on the different arches: Then any arch might just upgrade to the version of the source package; however, this can happen only if the package was previously forced through, the arch is in outofsync_arches, or there was no binary package of that arch present in ``unstable`` at all during the ``testing`` migration.
de: Im Allgemeinen gibt es nichts, was vom aktuellen Status eines Pakets in ``Testing`` von Bedeutung für den Übergang der nächsten Version von ``Unstable`` zu ``Testing`` ist, mit zwei Ausnahmen: Wenn die Anzahl der Menge an RC-Fehlern des Pakets verkleinert wird, kann das Paket migrieren auch wenn es noch veröffentlichungskritische Fehler hat. Die zweite Ausnahme ist die wenn die Version des Pakets in ``Testing`` auf den verschiedenen Architekturen nicht synchron ist. Dann kann jede Architektur auf die Version des Quellpakets aktualisiert werden. Dies kann jedoch nur geschehen, wenn das Paket zuvor zwangsmäßig migriert wurden ist, die Architektur in der Datei outofsync_arches befindet oder während der Migration nach ``Testing`` überhaupt kein Binärpaket dieser Architektur in ``Unstable`` vorhanden war.

en: In summary this means: The only influence that a package being in ``testing`` has on a new version of the same package is that the new version might go in easier.
de: Zusammengefasst heißt das: Der einzige Einfluss eines Pakets, das sich in ``Testing`` befindet, auf eine neue Version des gleichen Pakets besteht darin, dass die neue Version leichter aufgenommen werden kann.

en: Details
de: Einzelheiten

en: If you are interested in details, this is how britney works:
de: Falls Sie die Einzelheiten interessieren, hier ein paar Erklärungen wie Britney funktioniert:

en: The packages are looked at to determine whether they are valid candidates. This gives the update excuses. The most common reasons why a package is not considered are too young, RC-bugginess, and out of date on some arches. For this part of britney, the release managers have hammers of various sizes, called hints (see below), to force britney to consider a package.
de: Die Pakete werden betrachtet, um festzulegen, ob Sie gültige Kandidaten sind. Daraus werden die update excuses (Gründe für eine Nicht-Aktualisierung) erzeugt. Die häufigsten Gründe warum ein Paket nicht berücksichtigt wird lauten: zu neu, zu viele veröffentlichungskritische Fehler oder auf einigen Architekturen veraltet. Für diesen Teil von Britney verfügen die Veröffentlichungsverwalter über Druckmittel verschiedener Stärke (Hinweise genannt, siehe unten), um eine Berücksichtigung des Pakets durch Britney zu erzwingen.

en: Now, the more complex part happens: Britney tries to update ``testing`` with the valid candidates. For that, britney tries to add each valid candidate to the testing distribution. If the number of uninstallable packages in ``testing`` doesn't increase, the package is accepted. From that point on, the accepted package is considered to be part of ``testing``, such that all subsequent installability tests include this package. Hints from the release team are processed before or after this main run, depending on the exact type.
de: Nun kommt der komplexere Teil: Britney versucht, ``Testing`` mit den gültigen Kandidaten zu aktualisieren. Dazu versucht Britney jeden gültigen Kandidaten zur Distribution ``Testing`` hinzuzufügen. Falls die Zahl nicht installierbarer Pakete in ``Testing`` sich nicht erhöht, wird das Paket akzeptiert. Ab diesem Zeitpunkt wird das Paket als Teil von ``Testing`` betrachtet, so dass alle anschließenden Tests zur  Installierbarkeit dieses Paket einbeziehen. Hinweise des Release-Teams werden, abhängig vom genauen Typ, vor diesem Hauptdurchlauf verarbeitet.

en: If you want to see more details, you can look it up on https://release.debian.org/britney/update_output/\ .
de: Falls Sie weitere Einzelheiten suchen, können Sie unter https://release.debian.org/britney/update_output/ nachsehen.

en: The hints are available via https://release.debian.org/britney/hints/\ , where you can find the `description <https://release.debian.org/doc/britney/hints.html>`__ as well. With the hints, the Debian Release team can block or unblock packages, ease or force packages into ``testing``, remove packages from ``testing``, approve uploads to :ref:`t-p-u` or override the urgency.
de: Die Hinweise sind unter https://release.debian.org/britney/hints/ verfügbar. Dort finden Sie auch die `Beschreibung <https://release.debian.org/doc/britney/hints.html>`__ dazu. Mit den Hinweisen kann das Debian Release-Team Pakete blockieren oder entsperren, Paketmigration nach ``Testing`` vereinfachen oder auch erzwingen, Pakete aus ``Testing`` entfernen, Uploads genehmigen für :ref:`t-p-u` oder die Dringlichkeit überschreiben.

en: Direct updates to testing
de: Direkte Aktualisierungen für Testing

en: The ``testing`` distribution is fed with packages from ``unstable`` according to the rules explained above. However, in some cases, it is necessary to upload packages built only for ``testing``. For that, you may want to upload to ``testing-proposed-updates``.
de: Die Distribution ``Testing`` wird, den genannten Regeln folgend, mit Paketen aus ``Unstable`` gespeist. In einigen Fällen ist es jedoch nötig, Pakete hochzuladen, die nur für ``Testing`` erstellt wurden. Dafür empfiehlt es sich, nach ``testing-proposed-updates`` hochzuladen.

en: Keep in mind that packages uploaded there are not automatically processed; they have to go through the hands of the release manager. So you'd better have a good reason to upload there. In order to know what a good reason is in the release managers' eyes, you should read the instructions that they regularly give on ``debian-devel-announce@lists.debian.org``.
de: Merken Sie sich, dass dorthin hochgeladene Pakete nicht automatisch verarbeitet werden, sie müssen erst durch die Hand des Veröffentlichungsverwalters gehen. Daher sollten sie besser über einen triftigen Grund verfügen, dorthin hochzuladen. Um zu erfahren, was in den Augen der Veröffentlichungsverwalter ein triftiger Grund ist, sollten sie die Anweisungen lesen, die diese reglemäßig auf ``debian-devel-announce@lists.debian.org`` verteilen.

en: You should not upload to ``testing-proposed-updates`` when you can update your packages through ``unstable``. If you can't (for example because you have a newer development version in ``unstable``), you may use this facility. Even if a package is frozen, updates through ``unstable`` are possible, if the upload via ``unstable`` does not pull in any new dependencies.
de: Sie sollten nicht auf ``testing-proposed-updates`` hochladen, wenn Sie Ihre Pakete über ``Unstable`` aktualisieren können. Wenn Sie dies nicht können (z. B. weil Sie eine neuere Entwicklungsversion in ``Unstable`` haben), dann können Sie diese Option verwenden. Selbst wenn ein Paket eingefroren ist, sind Aktualisierungen über ``Unstable`` möglich, wenn beim Hochladen über ``Unstable`` keine neuen Abhängigkeiten entstehen.

en: Version numbers are usually selected by appending ``+deb``\ *X*\ ``uY``, where *X* is the major release number of Debian and *Y* is a counter starting at ``1``. e.g. |version1-revision-deb-version-stable-u1|.
de: Versionsnummern werden üblicherweise durch Anhängen von ``+deb``\ *X*\ ``uY`` ausgewählt, wobei *X* die Major-Release-Nummer von Debian und *Y* eine bei ``1`` beginnende Nummer ist, die hochgezählt wird, z.B. |version1-revision-deb-version-stable-u1|.

en: Please make sure you didn't miss any of these items in your upload:
de: Bitte stellen Sie sicher, dass Sie alle folgenden Punkte für Ihrem Upload beachtet haben:

en: Make sure that your package really needs to go through ``testing-proposed-updates``, and can't go through ``unstable``;
de: Vergewissern Sie sich, dass Ihr Paket wirklich ``testing-proposed-updates`` durchlaufen muss und nicht über ``Unstable`` gehen kann.

en: Make sure that you included only the minimal amount of changes;
de: Achten Sie darauf, dass Sie nur die kleinstmögliche Menge von Änderungen eingefügt haben.

en: Make sure that you included an appropriate explanation in the changelog;
de: Sorgen Sie dafür, dass das Änderungsprotokoll eine entsprechende Erklärung enthält.

en: Make sure that you've written the testing :ref:`codenames` (e.g. |codename-testing|) into your target distribution;
de: Überzeugen Sie sich, dass Sie den :ref:`codenames` von Testing (z.B. |codename-testing|) als Zieldistribution eingetragen haben.

en: Make sure that you've built and tested your package in ``testing``, not in ``unstable``;
de: Prüfen Sie nach, ob Sie Ihr Paket in ``Testing`` und nicht in ``Unstable`` getestet haben.

en: Make sure that your version number is higher than the version in ``testing`` and ``testing-proposed-updates``, and lower than in ``unstable``;
de: Gehen sie sicher, dass Ihre Versionsnummer höher als die Version in ``Testing`` und ``testing-proposed-updates`` ist und niedriger als in ``Unstable``.

en: Ask for authorization for uploading from the release managers.
de: Fragen Sie im Vorfeld die Veröffentlichungsmanager nach einer Erlaubnis.

en: After uploading and successful build on all platforms, contact the release team at ``debian-release@lists.debian.org`` and ask them to approve your upload.
de: Nach dem Hochladen und erfolgreichen Erstellen auf allen Plattformen kontaktieren Sie das Release-Team unter ``debian-release@lists.debian.org`` und ersuchen Sie es um Genehmigung Ihres Uploads.

en: Frequently asked questions
de: Häufig gestellte Fragen

en: What are release-critical bugs, and how do they get counted?
de: Was sind veröffentlichungskritische Fehler und wie werden diese gezählt?

en: All bugs of some higher severities are by default considered release-critical; currently, these are ``critical``, ``grave`` and ``serious`` bugs.
de: Alle Fehler mit einem höheren Schweregrad werden standardmäßig als veröffentlichungskritisch angesehen. Aktuell sind dies Fehler der Schweregrade ``critical``, ``grave`` und ``serious``.

en: Such bugs are presumed to have an impact on the chances that the package will be released with the ``stable`` release of Debian: in general, if a package has open release-critical bugs filed on it, it won't get into ``testing``, and consequently won't be released in ``stable``.
de: Von solchen Fehlern wird angenommen, dass sie einen Einfluss darauf haben, ob das Paket mit dem ``Stable``-Release von Debian veröffentlicht wird: Im Allgemeinen würde ein Paket, das offene veröffentlichungskritische Fehler hat, nicht nach ``Testing`` gelangen und demzufolge nicht in ``Stable`` veröffentlicht werden.

en: The ``unstable`` bug count comprises all release-critical bugs that are marked to apply to *package*/*version* combinations available in ``unstable`` for a release architecture. The ``testing`` bug count is defined analogously.
de: Als ``Unstable``-Fehleranzahl werden alle veröffentlichungskritischen Fehler gezählt, die für eine *Paket-*/*Versions-*\ Kombination markiert sind, welche in ``Unstable`` für eine Release-Architektur verfügbar ist. Die Fehleranzahl in ``Testing`` ist analog dazu definiert.

en: How could installing a package into ``testing`` possibly break other packages?
de: Wie kann das Installieren eines Pakets in ``Testing`` andere Pakete möglicherweise beschädigen?

en: The structure of the distribution archives is such that they can only contain one version of a package; a package is defined by its name. So when the source package ``acmefoo`` is installed into ``testing``, along with its binary packages ``acme-foo-bin``, ``acme-bar-bin``, ``libacme-foo1`` and ``libacme-foo-dev``, the old version is removed.
de: Die Struktur der Distributionsarchive ist so aufgebaut, dass Sie nur eine Version eines Pakets enthalten kann. Ein Paket wird durch seinen Namen definiert. Wenn also das Quellpaket ``acmefoo`` zusammen mit seinen Binärpaketen ``acme-foo-bin``, ``acme-bar-bin``, ``libacme-foo1`` und ``libacme-foo-dev`` nach ``Testing`` installiert wird, wird die alte Version entfernt.

en: However, the old version may have provided a binary package with an old soname of a library, such as ``libacme-foo0``. Removing the old ``acmefoo`` will remove ``libacme-foo0``, which will break any packages that depend on it.
de: Die alte Version könnte jedoch ein Binärpaket mit einem alten Soname einer Bibliothek bereitstellen, wie ``libacme-foo0``. Das Entfernen der alten ``acmefoo`` wird ``libacme-foo0`` entfernen, was alle Pakete beschädigt, die davon abhängen.

en: Evidently, this mainly affects packages that provide changing sets of binary packages in different versions (in turn, mainly libraries). However, it will also affect packages upon which versioned dependencies have been declared of the ==, <=, or << varieties.
de: Offenbar betrifft dies hauptsächlich Pakete, die sich ändernde Zusammenstellungen von Binärpaketen in unterschiedlichen Versionen bereitstellen (wiederum hauptsächlich Bibliotheken). Es wird jedoch außerdem Pakete betreffen, deren Versionsabhängigkeiten über die Varianten ==, <= oder << deklariert wurden.

en: When the set of binary packages provided by a source package changes in this way, all the packages that depended on the old binaries will have to be updated to depend on the new binaries instead. Because installing such a source package into ``testing`` breaks all the packages that depended on it in ``testing``, some care has to be taken now: all the depending packages must be updated and ready to be installed themselves so that they won't be broken, and, once everything is ready, manual intervention by the release manager or an assistant is normally required.
de: Wenn sich die Zusammenstellung von Binärpaketen, die von einem Quellpaket bereitgestellt werden, auf diese Weise ändert, müssen alle Pakete, die von den alten Programmen abhängen, aktualisiert werden, damit sie stattdessen von den neuen Programmen abhängen. Da das Installieren eines solchen Quellpakets in ``Testing`` alle Pakete beschädigt, die in ``Testing`` davon abhängen, ist nun auf Folgendes zu achten: All die abhängigen Pakete müssen aktualisiert werden und selbst bereit zur Installation sein, so dass sie nicht beschädigt werden. Sobald alles bereit ist, ist normalerweise ein manuelles Eingreifen des Veröffentlichungsverwalters oder eines Assistenten nötig.

en: If you are having problems with complicated groups of packages like this, contact ``debian-devel@lists.debian.org`` or ``debian-release@lists.debian.org`` for help.
de: Falls Sie Probleme mit wie hier dargestellten komplizierten Gruppen von Paketen haben, kontaktieren Sie ``debian-devel@lists.debian.org`` oder ``debian-release@lists.debian.org``, um Hilfe zu erhalten.

en: See the `Debian Policy Manual <https://www.debian.org/doc/debian-policy/>`__ for guidelines on what section a package belongs in.
de: Einen Leitfaden, in welchen Bereich ein Paket gehört, finden Sie im `Debian Policy Manual <https://www.debian.org/doc/debian-policy/>`__.

en: In the past, such NMUs used the third-level number on the Debian part of the revision to denote their recompilation-only status; however, this syntax was ambiguous with native packages and did not allow proper ordering of recompile-only NMUs, source NMUs, and security NMUs on the same package, and has therefore been abandoned in favor of this new syntax.
de: In der Vergangenheit benutzten solche NMUs die dritte Stufe im Debian-Teil der Revisionsnummer, um ihren Status als reine Neu-Kompilierung anzuzeigen. Diese Syntax war jedoch bei nativen Paketen mehrdeutig und erlaubte keine ordnungsgemäße Einordnung von reinen Neu-Kompilierungs-NMUs, Quell-NMUs und Sicherheits-NMUs im gleichen Paket. Daher wurden sie verworfen und diese neue Syntax bevorzugt.

en: ITS is shorthand for *"Intend to Salvage"*
de: ITS it eine Abkürzung für *"Intend to Salvage"*, sinngemäß für "Absichtserklärung für das Bergen"

en: Though, if a package still is in the upload queue and hasn't been moved to Incoming yet, it can be removed. (see :ref:`upload-ftp-master`)
de: Wenn sich ein Paket jedoch noch in der Upload-Queue befindet und noch nicht nach Incomming verschoben wurde, kann es entfernt werden. (Siehe :ref:`upload-ftp-master`)

en: The Stable backports archive
de: Das Archive von Stable Backports

en: Once a package reaches the ``testing`` distribution, it is possible for anyone with upload rights in Debian (see below about this) to build and upload a backport of that package to ``stable-backports``, to allow easy installation of the version from ``testing`` onto a system that is tracking the ``stable`` distribution.
de: Wenn ein Paket die Distribution ``testing`` erreicht hat dann ist es für jede Person in Debian mit Upload Berechtigungen (Siehe nachstehende Infos) möglich einen Backport dieses Paketes zu bauen und nach ``stable-backports`` hoch zu laden, dies ermöglicht eine einfache Installation eines Paketes aus ``testing`` auf einem System was der ``stable`` Distribution folgt.

en: One should not upload a version of a package to ``stable-backports`` until the matching version has already reached the ``testing`` archive.
de: Man sollte eine Version eines Pakets erst dann nach ``stable-backports`` hochladen, wenn die passende Version bereits das ``testing`` Archiv erreicht hat.

en: Exception to the testing-first rule
de: Ausnahmen von der erst-testing Regel

en: The only exception to the above rule, is when there's an important security fix that deserves a quick upload: in such a case, there is no need to delay an upload of the security fix to the ``stable-backports`` archive. However, it is strongly advised that the package is first fixed in ``unstable`` before uploading a fix to the ``stable-backports`` archive.
de: Die einzige Ausnahme von der oben genannten Regel besteht, wenn es einen wichtigen Sicherheitsfix gibt, der einen schnellen Upload rechtfertigt: In einem solchen Fall besteht keine Notwendigkeit, den Upload des Sicherheitsfixes in das ``stable-backports`` Archiv zu verzögern. Es wird jedoch dringend empfohlen, das Paket zunächst in „unstable“ zu reparieren, bevor ein Fix in das ``stable-backports`` Archiv hochgeladen wird.

en: Who can maintain packages in the stable-backports archive?
de: Wer kann Pakete im Stable-Backports Archiv verwalten?

en: It is not necessarily up to the original package maintainer to maintain the ``stable-backports`` version of the package. Anyone can do it, and one doesn't even need approval from the original maintainer to do so. It is however good practice to first get in touch with the original maintainer of the package before attempting to start the maintenance of a package in ``stable-backports``. The maintainer can, if they wish, decide to maintain the backport themselves, or help you doing so. It is not uncommon, for example, to apply a patch to the unstable version of a package, to facilitate its backporting.
de: Es ist nicht unbedingt Aufgabe des ursprünglichen Paketbetreuers, die ``stable-backports`` Version des Pakets zu pflegen. An sich kann dies jeder tun und man braucht dazu nicht einmal die Genehmigung des ursprünglichen Paketbetreuers. Es empfiehlt sich jedoch, sich zunächst mit dem ursprünglichen Betreuer des Pakets in Verbindung zu setzen, bevor Sie versuchen, mit der Portierung eines Pakets in ``stable-backports`` zu beginnen. Der Paketbetreuer kann den Wunsch haben selbst den Backport selbst zu tätigen, oder Ihnen helfen den Backport zu erstellen. Es ist beispielsweise nicht ungewöhnlich, einen Patch auf die instabile Version eines Pakets anzuwenden, um dessen Rückportierung zu erleichtern.

en: When can one start uploading to stable-backports?
de: Wann kann man damit beginnen Pakete nach stable-backports hoch zu laden?

en: The new ``stable-backports`` is created before the freeze of the next ``stable`` suite. However, it is not allowed to upload there until the very end of the freeze cycle. The ``stable-backports`` archive is usually opened a few weeks before the final release of the next ``stable`` suite, but it doesn't make sense to upload until the release has actually happened.
de: Ein neues ``stable-backports`` wird vor dem Freeze der nächsten ``stable`` Suite erstellt. Allerdings ist ein Hochladen dorthin bis zum Ende des Freeze-Zyklus nicht gestattet. Das ``stable-backports`` Archiv wird normalerweise einige Wochen vor der endgültigen Veröffentlichung der nächsten ``stable`` Suite geöffnet, es macht jedoch keinen Sinn etwas hoch zu laden, bis die Veröffentlichung tatsächlich erfolgt ist.

en: How long must a package be maintained when uploaded to stable-backports?
de: Wie lange muss ein Paket betreut werden wenn es nach stable-backports geladen worden ist?

en: The ``stable-backports`` archive is maintained for bugs and security issues during the whole life-cycle of the Debian ``stable`` suite. Therefore, an upload to ``stable-backports``, implies a willingness to maintain the backported package for the duration of the ``stable`` suite, which can be expected to be about 3 years from its initial release.
de: Das ``stable-backports`` Archiv wird während des gesamten Lebenszyklus der Debian ``stable`` Suite zur Pflege von Fehler- und Sicherheitsprobleme betreut. Daher impliziert ein Upload auf ``stable-backports`` die Bereitschaft, das zurückportierte Paket für die Dauer der ``stable`` Suite zu betreuen, was voraussichtlich etwa drei Jahre nach der ersten Veröffentlichung sind.

en: The person uploading to backports is also supposed to maintain the backported packages for security during the lifetime of ``stable``.
de: Die Person, die nach Backports hochlädt, sollte sich auch für Security Fixes der zurückportierten Pakete während der Lebensdauer von „stable“ verantwortlich sehen.

en: It is to be noted that the ``stable-backports`` isn't part of the LTS or ELTS effort. The ``stable-backports`` FTP masters will close the ``stable-backports`` repositories for uploads once ``stable`` reaches end-of-life (ie: when ``stable`` becomes maintained by the LTS team only). Therefore there won't be any maintenance of packages from ``stable-backports`` after the official end of life of the ``stable`` suite, as uploads will not be accepted.
de: Es ist zu beachten, dass ``stable-backports`` nicht Teil der LTS oder ELTA Initiative ist. Die FTP-Master von ``stable-backports`` werden das Repository ``stable-backports`` für Uploads schließen sobald ``stable`` das Ende das Lebenszyklus (EOF) erreicht hat (Z.B. wenn ``stable`` nur noch durch das LTS-Team verwaltet wird). Dadurch erfolgt keine weitere Bearbeitung von Paketen in ``stable-backports`` nach dem offiziellen Ende das Lebenszykluses der Suite ``stable`` da keine neueren Uploads mehr akzeptiert werden.

en: How often shall one upload to stable-backports?
de: Wie oft sollte man ein Paket nach stable-backport hochladen?

en: The packages in backports are supposed to follow the developments that are happening in Testing. Therefore, it is expected that any significant update in ``testing`` should trigger an upload into ``stable-backports``, until the new ``stable`` is released. However, please do not backport minor version changes without user visible changes or bugfixes.
de: Die Pakete in Backports sollen den Entwicklungen im Testing folgen. Daher wird erwartet, dass jede bedeutende Aktualisierung in „testing“ einen Upload in „stable-backports“ auslöst, bis das neue „stable“ Release veröffentlicht wird. Bitte portieren Sie kleinere Versionsänderungen jedoch nicht ohne für den Benutzer sichtbare Änderungen oder Fehlerbehebungen nach Backports.

en: How can one learn more about backporting?
de: Wie kann man mehr über das Zurückportieren erfahren?

en: You can learn more about `how to contribute <https://backports.debian.org/Contribute/>`__ directly on the backport web site.
de: Auf der Webseite `Wie man beitragen kann <https://backports.debian.org/Contribute/>`__ können Sie mehr zu dieser Frage erfahren.

en: It is also recommended to read the `Frequently Asked Questions (FAQ) <https://backports.debian.org/FAQ/>`__.
de: Es wird auch empfohlen die `Frequently Asked Questions (FAQ) <https://backports.debian.org/FAQ/>`__ zu lesen.
