7. Jenseits von Paketierung

Debian ist weit mehr als nur Software zu paketieren und diese Pakete zu verwalten. Dieses Kapitel enthält Informationen über Wege, oft wirklich kritische Wege, fernab von einfachem Erstellen und Verwalten von Paketen zu Debian beizutragen.

Als eine Organisation von Freiwilligen verlässt sich Debian auf das Ermessen der Auswahl seiner Mitglieder, woran sie arbeiten möchten und was aus deren Sicht die kritischste Sache ist, in die sie Zeit investieren.

7.1. Fehler berichten

Bitte reichen Sie Fehlerberichte ein, wenn Sie Fehler in Debian-Paketen finden. Tatsächlich bilden Debian-Entwickler oftmals die erste Reihe der Tester. Fehler in den Paketen anderer Entwickler zu finden und zu melden, erhöht die Qualität von Debian.

Lesen Sie die Anweisungen zum Melden von Fehlern in der Debian-Fehlerdatenbank.

Versuchen Sie, den Fehlerbericht von einem normalen Benutzerkonto zu senden, auf dem Sie wahrscheinlich E-Mails empfangen können, so dass Leute, die weitere Informationen über den Fehler benötigen, Sie erreichen können. Senden Sie keine Fehlerberichte als Root.

Sie können ein Werkzeug wie reportbug 1 benutzen, um Fehlerberichte zu senden. Es kann den Prozess automatisieren und generell erleichtern.

Prüfen Sie, dass der Fehlerbericht nicht bereits schon gegen das Paket eingereicht wurde. Jedes Paket hat eine Fehlerliste, die einfach unter https://bugs.debian.org/Paketname einsehbar ist. Hilfswerkzeuge wie querybts 1 können Sie ebenfalls mit diesen Informationen versorgen (und reportbug wird normalerweise auch vor dem Versenden querybts aufrufen).

Versuchen Sie, Ihre Fehlerberichte an die ordnungsgemäße Stelle zu lenken. Wenn Ihr Fehlerbericht zum Beispiel von einem Paket handelt, das Dateien eines anderen Pakets überschreibt, prüfen Sie die Fehlerliste beider Pakete, um das Einreichen doppelter Fehlerberichte zu vermeiden.

Um zusätzliche Anerkennung zu erhalten, vereinigen Sie Fehler, die mehr als einmal berichtet wurden oder kennzeichnen Sie Fehler als "fixed", die bereits behoben wurden. Beachten Sie, dass Sie den Fehlerbericht nicht tatsächlich schließen sollten wenn Sie weder der Absender des Fehlers noch der Betreuer des Pakets sind (es sei denn, Sie versichern sich der Erlaubnis des Betreuers).

Von Zeit zu Zeit möchten Sie vielleicht prüfen, was aus den Fehlerberichten geworden ist, die Sie versandt haben. Nutzen Sie diese Gelegenheit, um diejenigen zu schließen, die Sie nicht mehr reproduzieren können. Um herauszufinden, welche Fehlerberichte Sie versandt haben, besuchen Sie https://bugs.debian.org/from:Ihre-E-Mail-Adresse.

7.1.1. Viele Fehler auf einmal berichten (Masseneinreichung von Fehlern)

Das Berichten einer großen Anzahl von Fehlern für dasselbe Problem für eine große Zahl von Paketen — d.h. mehr als zehn — ist eine nicht erwünschte Vorgehensweise. Unternehmen Sie alle nötigen Schritte, um das massenhafte Versenden von Fehlerberichten tunlichst zu vermeiden. Prüfen Sie zum Beispiel, ob das Problem automatisiert werden kann, indem Sie eine neue Prüfung zu lintian hinzufügen, so dass eine Fehlermeldung oder Warnung ausgegeben wird.

Falls Sie mehr als zehn Fehler auf einmal zum gleichen Thema berichten, wird empfohlen, dass Sie eine E-Mail an debian-devel@lists.debian.org senden, in der Sie Ihre Absichten darlegen, bevor Sie den Bericht versenden und die Tatsache im Betreff Ihrer Mail erwähnen. Dies wird anderen Entwicklern ermöglichen zu prüfen, ob der Fehler ein echtes Problem darstellt. Zusätzlich wird es helfen, eine Situation zu vermeiden, in der mehrere Betreuer simultan beginnen, den gleichen Fehlerbericht einzureichen.

Bitte benutzen Sie das Programm dd-list und falls geeignet whodepends (aus dem Paket devscripts), um eine Liste aller betroffenen Pakete zu generieren und fügen sie die Ausgabe in Ihre Mail an debian-devel@lists.debian.org ein.

Beachten Sie, wenn Sie viele Fehlerberichte mit dem gleichen Betreff senden möchten, dass Sie den Fehlerbericht an maintonly@bugs.debian.org senden sollten, so dass der Fehlerbericht nicht an die Fehlerverteilungs-Maillingliste weitergeleitet wird.

Das Programm mass-bug (aus dem Paket devscripts) kann benutzt werden um Bugreports gegen eine Liste von Paketen zu öffnen.

7.1.1.1. Usertags

Vielleicht möchten Sie BTS-Usertags (benutzerdefinierte Kennzeichnungen) benutzen, wenn Sie Fehlerberichte an eine größere Anzahl Pakete senden. Diese Kennzeichnungen sind den normalen Kennzeichen wie "patch" oder "wishlist" ähnlich, unterscheiden sich aber darin, dass sie benutzerdefiniert sind und einen Namensraum belegen, der einzigartig für einen bestimmten Benutzer ist. Dies ermöglicht mehreren Gruppierungen von Entwicklern, den gleichen Fehler benutzerdefiniert auf unterschiedliche Arten zu kennzeichnen, ohne Konflikte zu verursachen.

Um beim Einreichen von Fehlerberichten Usertags hinzuzufügen, geben Sie die Pseudokopfzeilen User und Usertags an:

To: submit@bugs.debian.org
Subject: title-of-bug

Package: pkgname
[ ... ]
User: email-addr
Usertags: tag-name [ tag-name ... ]

description-of-bug ...

Beachten Sie, dass Kennzeichnungen durch Leerzeichen getrennt werden und keine Unterstriche enthalten dürfen. Falls Sie Fehlerberichte für eine spezielle Gruppe oder ein Team einreichen, wird empfohlen, dass Sie bei User eine passende Mailingliste eintragen, nachdem Sie Ihre Absicht dort geschildert haben.

Um Fehler mit einem bestimmten Usertag anzusehen, benutzen Sie https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=E-Mail-Adresse&tag=Kennzeichen.

7.2. Qualitätssicherungsbestreben

7.2.1. Tägliche Arbeit

Auch wenn es eine eigene Gruppe für Qualitätssicherung gibt, sind QS-Aufgaben nicht ausschließlich dieser Gruppe vorbehalten. Sie können sich an dieser Aufgabe beteiligen, indem Sie Ihre Pakete so fehlerfrei und lintian-rein (siehe lintian) wie möglich halten. Falls Sie finden, dies sei unmöglich, dann sollten Sie darüber nachdenken, einige Ihrer Pakete zu verwaisen (siehe Verwaisen von Paketen). Alternativ könnten Sie andere Leute um Hilfe bitten, um den Rückstand, den Sie bei den Fehlern haben, aufzuholen (Sie können auf debian-qa@lists.debian.org oder debian-devel@lists.debian.org nach Hilfe fragen). Gleichzeitig können Sie sich nach Mitbetreuern umsehen (siehe Gemeinschaftliche Verwaltung).

7.2.2. Treffen zur gemeinschaftlichen Behebung von Fehlern (Bug-Squashing-Partys)

Von Zeit zu Zeit organisiert die QS-Gruppe Bug-Squashing-Partys, um so viele Probleme wie möglich zu beseitigen. Sie werden auf debian-devel-announce@lists.debian.org angekündigt und in der Ankündigung wird erklärt, auf welchem Bereich der Fokus der Party liegt: Üblicherweise konzentriert man sich auf Release-kritische Fehler, aber es kann auch vorkommen, dass entschieden wird, bei der Fertigstellung eines Haupt-Upgrades zu helfen (wie einer neuen perl-Version, die ein Neukompilieren aller binären Module erfordert).

Die Regeln für Non-Maintainer-Uploads unterscheiden sich während der Parties, da die Ankündigung der Party als vorausgehende Ankündigung für den NMU angesehen wird. Falls Sie Pakete haben, die von der Party betroffen sind (da sie zum Beispiel Release-kritische Fehler enthalten), sollten Sie eine Aktualisierung zu jedem zugehörigen Fehler senden, um seinen aktuellen Status zu erklären und was Sie von der Party erwarten. Falls Sie keinen NMU möchten, nicht an einem Patch interessiert sind oder den Fehler selbst bewältigen möchten, erklären Sie dies bitte im BTS.

Teilnehmer der Party haben besondere Regeln für NMUs. Sie können NMUs ohne vorherige Ankündigung durchführen, falls sie mindestens nach DELAYED/3-day hochladen. Alle anderen NMU-Regeln gelten wie üblich; sie sollten den Patch des NMUs an das BTS senden (an einen der offenen Fehler, der durch den NMU behoben wird oder an einen neuen Fehler, der als "fixed" gekennzeichnet wird). Sie sollten außerdem die besonderen Wünsche des Betreuers respektieren.

Falls Sie sich nicht sicher fühlen, einen NMU durchzuführen, senden Sie nur einen Patch an das BTS. Das ist weitaus besser als ein beschädigter NMU.

7.3. Andere Paketbetreuer kontaktieren

Während Ihres Lebens innerhalb von Debian werden Sie aus verschiedenen Gründen Kontakt zu anderen Betreuern haben. Sie möchten vielleicht neue Wege der Kooperation zwischen einer Zusammenstellung verwandter Pakete diskutieren oder einfach jemanden daran erinnern, dass eine neue Originalversion verfügbar ist, die Sie benötigen.

Die E-Mail-Adresse eines Paketbetreuers heraussuchen zu müssen, kann störend sein. Glücklicherweise gibt es einen einfachen E-Mail-Alias, Paket@packages.debian.org, der eine Möglichkeit bietet, dem Betreuer eine Mail zu schicken, ganz gleich wie seine E-Mail-Adresse (oder Adressen) auch sein mag. Ersetzen Sie Paket durch den Namen eines Quell- oder Binärpakets.

Möglicherweise sind Sie außerdem daran interessiert, Personen zu kontaktieren, die ein bestimmtes Quellpaket mittels Das Debian-Paketverfolgungssystem abonniert haben. Sie können dazu die E-Mail-Adresse Paket@packages.qa.debian.org benutzen.

7.4. Sich mit inaktiven und/oder nicht erreichbaren Paketbetreuern beschäftigen

Falls Sie bemerken, dass es einem Paket an Pflege mangelt, sollten Sie prüfen, dass der Betreuer aktiv ist und weiter an seinen Paketen arbeitet. Es ist möglich, dass er nicht mehr aktiv ist, sich aber nicht aus dem System abgemeldet hat. Andererseits ist es auch möglich, dass er nur eine Erinnerung braucht.

Es gibt ein einfaches System (die MIA-Datenbank), in der Informationen über Paketbetreuer aufgezeichnet werden, die als "Missing In Action" (vermisst) gelten. Wenn ein Mitglied der QS-Gruppe einen inaktiven Betreuer kontaktiert oder weitere Informationen über ihn findet, wird dies in der MIA-Datenbank aufgezeichnet. Das System ist unter /org/qa.debian.org/mia auf dem Rechner qa.debian.org verfügbar und kann mit dem Werkzeug mia-query abgefragt werden. Benutzen Sie mia-query --help, um zu erfahren, wie Sie Abfragen an die Datenbank richten. Falls Sie der Meinung sind, dass noch keine Informationen über einen inaktiven Betreuer aufgezeichnet wurde oder dass Sie weitere Informationen hinzufügen können, sollten Sie im Allgemeinen wie folgt verfahren.

Im ersten Schritt kontaktieren Sie den Betreuer höflich und warten eine angemessene Zeit auf eine Antwort. Es ist ziemlich schwer zu definieren, was eine angemessene Zeit ist, aber es ist wichtig zu berücksichtigen, dass das wahre Leben manchmal sehr hektisch ist. Eine Möglichkeit damit umzugehen wäre es, nach zwei Wochen eine Erinnerung zu senden.

Eine nicht funktionierende E-Mail-Adresse ist eine Verletzung der Debian Richtlinien. Falls eine E-Mail nicht zustellbar ist, melden Sie dies bitte als einen Fehler gegen das Paket, und informieren Sie das MIA-Team.

Falls der Betreuer nicht innerhalb von vier Wochen (einem Monat) antwortet, kann davon ausgegangen werden, dass wahrscheinlich keine Antwort mehr kommt. Falls dies geschieht, sollten Sie weiter nachforschen und versuchen so viele nützliche Informationen wie möglich über den betreffenden Betreuer zu sammeln. Dies beinhaltet:

  • Die echelon-Informationen, die über debian.org Developers LDAP Search verfügbar sind. Sie geben an, wann der Entwickler zum letzten Mal an eine Debian-Mailingliste geschrieben hat. (Dies umfasst auch Mails über Uploads, die über die Liste debian-devel-changes@lists.debian.org verteilt wurden.) Denken Sie außerdem daran zu prüfen, ob der Betreuer in der Datenbank als im Urlaub befindlich markiert ist.

  • Die Anzahll der Pakete, für die dieser Betreuer verantwortlich ist und den Zustand dieser Pakete. Hauptsächlich, ob es Release-kritische Fehler gibt, die seit Jahren offen sind. Ferner wie viele Fehler es im Allgemeinen sind. Ein weiterer wichtiger Teil der Informationen ist, ob für die Pakete NMUs durchgeführt werden und wenn von wem.

  • Gibt es irgendeine Aktivität des Betreuers außerhalb von Debian? Er könnte zum Beispiel aktuell etwas an eine Nicht-Debian-Mailingliste oder an Newsgroups geschrieben haben.

Ein ziemliches Problem sind Pakete, die gesponsert wurden — der Betreuer ist kein offizieller Debian-Entwickler. Die echelon-Informationen sind nicht für gesponserte Leute verfügbar, so dass Sie beispielsweise den Debian-Entwickler finden und kontaktieren müssen, der das Paket tatsächlich hochgeladen hat. Angenommen, das Paket wurde signiert, dann ist er dennoch für das Paket verantwortlich und weiß wahrscheinlich, wie es mit der Person aussieht, für die er das Paket sponserte.

Es ist außerdem erlaubt, eine Anfrage an debian-devel@lists.debian.org zu senden und zu fragen, ob jemand etwas über den Verbleib des vermissten Betreuers weiß. Bitte senden Sie der Person, um die es geht, per Cc: eine Kopie.

Sobald Sie all dies gesammelt haben, können Sie mia@qa.debian.org kontaktieren. Die Leute hinter diesem Alias werden die von Ihnen bereitgestellten Informationen nutzen, um zu entscheiden, wie verfahren wird. Beispielsweise könnten sie eines oder alle Pakete des Betreuers verwaisen. Falls für ein Paket ein NMU durchgeführt wurde, könnten sie es vorziehen, vor dem Verwaisen des Pakets denjenigen zu kontaktieren, von dem der NMU durchgeführt wurde — vielleicht ist diese Person daran interessiert, das Paket zu übernehmen.

Eine abschließende Bemerkung: Bitte denken Sie daran immer höflich zu bleiben. Alle hier sind Freiwillige und können nicht sämtliche Zeit Debian widmen. Außerdem wissen Sie nichts über die Situation der beteiligten Person. Vielleicht ist sie ernsthaft erkrankt oder sogar verstorben — Sie wissen nicht, wer auf der Empfängerseite ist. Stellen Sie sich vor, wie sich ein Verwandter fühlt, wenn er die E-Mail des Verstorbenen liest und eine sehr unhöfliche, böse oder vorwurfsvolle Nachricht findet!

Andererseits, trotz dass wir alle Freiwillige sind, geht ein Paketbetreuer auch eine Verpflichtung ein und hat deshalb auch eine Verantwortung, das Paket zu pflegen. So können Sie die Wichtigkeit eines übergeordneten Wohls betonen — falls die Betreuer keine Zeit oder kein Interesse mehr haben, sollten sie loslassen und das Paket jemandem mit mehr Zeit übergeben.

Wenn Sie Interesse daran haben im MIA Team mitzuarbeiten dann schauen Sie bitte in die Datei README` in /org/qa.debian.org/mia auf qa.debian.org. In dieser Datei sind die technischen Details als auch der MIA Prozess dokumentiert. Zur Kontaktaufnahme mit dem MIA Team schreiben Sie bitte an E-Mail an mia@qa.debian.org.

7.5. Zusammenwirken mit zukünftigen Debian-Entwicklern

Debians Erfolg hängt von der Fähigkeit ab, neue und talentierte Entwickler für das Projekt zu gewinnen und auch zu halten. Wenn Sie ein erfahrener Entwickler sind, wird Ihnen empfohlen, sich am Prozess neue Entwickler heranzuziehen zu beteiligen.

7.5.1. Pakete sponsern

Sponsern eines Pakets bedeutet, ein Paket für einen Betreuer hochzuladen, der nicht in der Lage ist, dies selbst zu tun. Es ist keine belanglose Angelegenheit, der Sponsor muss die Paketierung überprüfen und dafür sorgen, dass sie der hohen Qualität entspricht, die Debian anstrebt.

Debian-Entwickler können Pakete sponsoren. Debian-Betreuer können dies nicht.

Der Prozess, ein Paket zu sponsern ist:

  1. Der Betreuer bereitet ein Quellpaket (.dsc) vor und legt dies Online ab (z.B. auf mentors.debian.net) oder besser, er verweist auf ein öffentlich zugängliches VCS Repository (siehe salsa.debian.org: Git Repositorys und kollaborative Entwicklungsplattform) in dem das Paket verwaltet wird.

  2. Der Sponsor lädt das Quellpaket herunter (oder führt einen Checkout durch).

  3. Der Sponsor prüft das Quellpaket. Falls er Probleme entdeckt, informiert er den Betreuer und bittet ihn, eine korrigierte Version bereitzustellen (der Prozess beginnt von vorn mit dem ersten Schritt).

  4. Der Sponsor konnte kein verbliebenes Problem finden. Er erstellt das Paket, signiert es und lädt es nach Debian hoch.

Bevor Sie die Einzelheiten erforschen, wie ein Paket gesponsert wird, sollten Sie sich selbst fragen, ob das vorgeschlagene Paket einen Mehrwert für Debian und dessen Nutzer bringt.

Es gibt keine einfache Regel, um diese Frage zu beantworten, sie kann von vielen Faktoren abhängen: Ist die Code-Basis der Originalautoren ausgereift und nicht voller Sicherheitslücken? Gibt es bereits existierende Pakete, die die gleiche Aufgabe erledigen können und wie sind diese im Vergleich zu diesem neuen Paket? Gab es für dieses neue Paket eine Nachfrage durch Anwender und wie groß ist die Benutzerbasis? Wie aktiv sind die Entwickler des Originalsoftware?

Sie sollten außerdem sicherstellen, dass der zukünftige Betreuer ein guter Betreuer sein wird. Hat er bereits etwas Erfahrung mit anderen Paketen? Falls ja, leistet er bei ihnen gute Arbeit (überprüfen Sie einige Fehlerberichte)? Ist er vertraut mit dem Paket und dessen Programmiersprache? Verfügt er über die für dieses Paket nötigen Fähigkeiten? Falls nicht: ist er in der Lage, sie zu erlernen?

Es ist auch eine gute Idee zu wissen, wo der neue Betreuer im Bezug zu Debian steht: Stimmt er Debians Philosophie zu und beabsichtigt sich der Debian Gemeinschaft anzuschließen? Angesichts der Tatsache, wie einfach es ist, Debian-Mitglied zu werden, möchten Sie möglicherweise nur Personen sponsern, die eine Mitgliedschaft planen. Auf diese Weise wissen Sie von Anfang an, dass Sie nicht auf unbestimmte Zeit als Sponsor auftreten müssen.

7.5.1.1. Ein neues Paket sponsern

Neue Betreuer haben gewöhnlich bestimmte Schwierigkeiten bei der Erstellung von Debian-Paketen — dies ist ziemlich verständlich. Sie werden nicht immer alles richtig machen. Das ist der Grund, weshalb das Sponsern eines brandneuen Pakets in Debian eine sorgfältige Überprüfung notwendig macht. Manchmal sind mehrere Wiederholungen nötig, bis das Paket gut genug ist, um ins Debian Archive geladen werden zu können. Daher impliziert ein Sponsor zu sein ebenfalls auch ein Mentor zu sein.

Sponsern Sie ein Paket nie, ohne es zu überprüfen. Die Überprüfung eines neuen Pakets, die von den Ftpmasters vorgenommen wird, stellt nur sicher, dass die Software wirklich frei ist. Natürlich kommt es vor, dass sie über Paketierungsprobleme stolpern, aber das sollte wirklich nicht passieren. Es ist Ihre Aufgabe, dafür zu sorgen, dass das hochgeladene Paket mit Debians Richtlinien für freie Software übereinstimmt und von guter Qualität ist.

Das Erstellen des Pakets und Prüfen der Software ist Teil der Überprüfung, aber es reicht nicht aus. Der Rest dieses Abschnitts enthält eine unvollständige Liste von Punkten, die Sie bei Ihrer Überprüfung testen sollten. [1]

  • Prüfen Sie, ob der bereitgestellte Original-Tarball derselbe ist wie der, den der Originalautor verteilt (wenn die Quellen neu für Debian gepackt wurden, erstellen Sie selbst den geänderten Tarball).

  • Führen Sie lintian aus (siehe lintian). Sie werden so gängige Probleme finden. Verifizieren Sie, dass jegliche lintian-overrides des Betreuers vollständig gerechtfertigt sind.

  • Führen Sie licensecheck aus (Teil von devscripts) und überprüfen Sie, ob debian/copyright korrekt und komplett zu sein scheint. Suchen Sie nach Lizenzproblemen (wie Dateien mit "All rights reserved"-Kopfzeilen oder nicht DFSG-konformen Lizenzen). Bei dieser Aufgabe ist grep -ri Ihr Freund.

  • Erstellen Sie das Paket mit pbuilder (oder einem ähnlichen Werkzeug, siehe pbuilder), um sicherzustellen, dass die Build-Abhängigkeiten vollständig sind.

  • Lesen Sie debian/control Korrektur: Folgt es den optimalen Vorgehensweisen (siehe Optimale Vorgehensweisen für debian/control)? Sind die Abhängigkeiten vollständig?

  • Lesen Sie debian/rules Korrektur: Folgt es den optimalen Vorgehensweisen (siehe Optimale Vorgehensweisen für debian/rules)? Sehen Sie mögliche Verbesserungen?

  • Lesen Sie die Betreuerskripte (preinst, postinst, prerm, postrm, config) Korrektur: Werden preinst/postrm funktionieren, wenn die Abhängigkeiten nicht installiert sind? Sind alle Skripte idempotent (d.h. können sie ohne Konsequenzen mehrmals ausführt werden)?

  • Überprüfen Sie jede Änderung an Originaldateien (entweder in .diff.gz, in debian/patches/ oder direkt in den Tarball debian für Binärdateien eingebettet). Sind sie gerechtfertigt? Sind sie ordentlich dokumentiert (mit DEP-3 für Patches)?

  • Fragen Sie sich für jede Datei, warum diese Datei dort ist und ob dies der richtige Weg ist, das gewünschte Ergebnis zu erzielen. Folgt der Betreuer den optimalen Vorgehensweisen beim Paketieren (siehe Optimale Vorgehensweise beim Paketieren)?

  • Erstellen Sie die Pakete, installieren Sie sie und probieren Sie die Software aus. Stellen Sie sicher, dass Sie die Pakete entfernen und vollständig entfernen können. Testen Sie sie eventuell mit piuparts.

Falls die Kontrolle keine Probleme offenbarte, können Sie das Paket erstellen und nach Debian hochladen. Denken Sie daran, dass, obwohl Sie nicht der Betreuer sind, Sie als Sponsor trotzdem auch für das verantwortlich sind, was Sie nach Debian hochladen. Daher sollten Sie das Paket durch das Das Debian-Paketverfolgungssystem im Auge zu behalten.

Beachten Sie, dass Sie das Quellpaket nicht verändern sollten, um Ihren Namen in die Datei changelog oder control einzutragen. Das Feld Maintainer der Dateien control und changelog sollte die Person aufführen, die das Paket erstellte, d.h. den Gesponserten. Auf diese Art wird er die gesamten Nachrichten vom BTS erhalten.

Stattdessen sollten Sie dpkg-buildpackage anweisen, Ihren Schlüssel für die Signatur zu benutzen. Sie erreichen dies mit der Option -k:

dpkg-buildpackage -kKEY-ID

Falls Sie debuild und debsign benutzen, können sie das sogar permanent in ~/.devscripts konfigurieren:

DEBSIGN_KEYID=KEY-ID

7.5.1.2. Eine Aktualisierung eines existierenden Pakets sponsern

Sie werden normalerweise davon ausgehen, dass das Paket bereits eine vollständige Überprüfung durchlief. Daher werden Sie, anstatt dies nochmals erneut zu tun, nur die Unterschiede zwischen der aktuellen und der neu vom Betreuer vorbereiteten Version sorgsam analysieren. Falls Sie die anfängliche Überprüfung nicht selbst durchgeführt haben, könnten Sie auch noch einen genaueren Blick darauf werfen, nur für den Fall, dass der erste Prüfer nachlässig war.

Damit Sie die Unterschiede untersuchen können, benötigen Sie beide Versionen. Laden Sie die aktuelle Version des Quellpakets herunter (mit apt-get source) und erstellen Sie es (oder laden Sie die aktuellen Binärpakete mit aptitude download herunter). Laden Sie das Quellpaket zum Sponsern (üblicherweise mit dget).

Lesen Sie das Änderungsprotokoll, damit Sie wissen, was Sie während der Überprüfung erwartet. Das Hauptwerkzeug, das Sie benutzen werden, ist debdiff (bereitgestellt vom Paket devscripts). Sie können es mit zwei Quellpaketen (.dsc-Dateien), zwei Binärpaketen oder zwei .changes-Dateien (dann wird es alle Binärpakete vergleichen, die in .changes aufgeführt sind) ausführen.

Falls Sie die Quellpakete vergleichen (ausschließlich der Originaldateien im Fall einer neuen Originalversion, zum Beispiel durch Filtern der Ausgabe von debdiff mit filterdiff -i '*/debian/*'), müssen Sie alle Änderungen verstehen und sie sollten ordentlich im Debian-Änderungsprotokoll dokumentiert sein.

Falls alles in Ordnung ist, erstellen Sie das Paket und vergleichen Sie die Binärpakete, um zu prüfen, ob die Änderungen am Quellpaket keine unerwarteten Folgen haben (wie einige versehentlich entfallenen Dateien, fehlende Abhängigkeiten etc.)

Sie möchten möglicherweise das Package-Tracking-System nutzen (siehe Das Debian-Paketverfolgungssystem), um zu überprüfen, ob der Betreuer nichts wichtiges versäumt hat. Möglicherweise gibt es Übersetzungsaktualisierungen, die im BTS liegen und hätten integriert werden können. Möglicherweise wurde ein NMU des Pakets durchgeführt und der Betreuer vergaß, die Änderungen des NMUs in sein Paket einzubauen. Vielleicht ist ein Release-kritischer Fehler unbehandelt geblieben und dies blockiert die Migration nach Testing. Falls Sie etwas finden, was (besser) erledigt werden könnte, ist es an der Zeit, ihm dies mitzuteilen, so dass er es dies das nächste Mal besser machen kann und dass er seine Verantwortlichkeiten besser versteht.

Falls Sie kein bedeutendes Problem gefunden haben, laden Sie die neue Version hoch. Andernfalls bitten Sie den Betreuer, Ihnen eine korrigierte Version zur Verfügung zu stellen.

7.5.2. Einrichten von Uploadberechtigungen für DM

Ein Debian Developer kann Uploadberechtigungen an einem spezifischen Paket für einen Debian Maintainer einrichten sobald der Schlüssel des Debian Maintainers in den Debian Maintainer Schlüsselring aufgenommen worden ist. Dazu muss der Developer ein signiertes DAK-Kommando an ftp.upload.debian.org schicken wie in der FTP-Master Ankündigung an Debian-Devel beschrieben worden ist.

Dieser Prozess kann durch die Hilfe vom dcut Kommando aus dem Paket dput-ng vereinfacht werden. Hinweis, das funktioniert nicht mit dem dcut Kommando aus dem Paket dput!

Zum Beispiel:

dcut dm --uid 0xfedcba9876543210 --allow nano --deny bash

Wenn sich der Schlüssel des DM noch nicht im Paket vom Schlüsselring, aber im lokalen Schlüsselbund des DD befindet, verwenden Sie die Option „--force“ und den Fingerabdruck, ohne Leerzeichen und in diesem speziellen Fall ohne das Präfix 0x und ausschließlich in Großbuchstaben:

dcut --force dm --uid FEDCBA9876543210FEDCBA9876543210 --allow nano

7.5.3. Neue Entwickler befürworten

Lesen Sie die Seite Einen zukünftigen Entwickler befürworten auf der Debian-Website.

7.5.4. Handhabung von Bewerbungen neuer Betreuer

Lesen Sie bitte die Checkliste für Bewerbungsleiter auf der Debian-Website.