Kapitel 7. Jenseits der Paketierung

Inhaltsverzeichnis

7.1. Fehler berichten
7.1.1. Viele Fehler auf einmal berichten (Masseneinreichung von Fehlern)
7.1.1.1. Usertags
7.2. Qualitätssicherungsbestreben
7.2.1. Tägliche Arbeit
7.2.2. Treffen zur gemeinschaftlichen Behebung von Fehlern (Bug-Squashing-Parties)
7.3. Andere Paketbetreuer kontaktieren
7.4. Sich mit inaktiven und/oder nicht erreichbaren Paketbetreuern beschäftigen
7.5. Zusammenwirken mit zukünftigen Debian-Entwicklern
7.5.1. Pakete sponsern
7.5.1.1. Ein neues Paket sponsern
7.5.1.2. Eine Aktualisierung eines existierenden Pakets sponsern
7.5.2. Neue Entwickler befürworten
7.5.3. Handhabung von Bewerbungen neuer Betreuer

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 seiner Mitglieder, die auswählen, woran sie arbeiten möchten und was die kritischste Sache ist, in die sie Zeit investieren.

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 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.

Stellen Sie sicher, dass der Fehler nicht bereits 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 wenn Sie weder der Absender des Fehlers noch der Betreuer des Pakets sind, den Fehlerbericht nicht tatsächlich schließen sollten (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.

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 missbilligte 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 Nachricht an senden, in der Sie Ihre Absicht darlegen, ehe 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 ein.

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

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 Abschnitt A.2.1, „lintian) wie möglich halten. Falls Sie finden, dies sei unmöglich, dann sollten Sie darüber nachdenken, einige Ihrer Pakete zu verwaisen (siehe Abschnitt 5.9.4, „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 oder nach Hilfe fragen). Gleichzeitig können Sie sich nach Mitbetreuern umsehen (siehe Abschnitt 5.12, „Gemeinschaftliche Verwaltung“).

From time to time the QA group organizes bug squashing parties to get rid of as many problems as possible. They are announced on and the announcement explains which area will be the focus of the party: usually they focus on release critical bugs but it may happen that they decide to help finish a major upgrade (like a new perl version that requires recompilation of all the binary modules).

The rules for non-maintainer uploads differ during the parties because the announcement of the party is considered prior notice for NMU. If you have packages that may be affected by the party (because they have release critical bugs for example), you should send an update to each of the corresponding bug to explain their current status and what you expect from the party. If you don't want an NMU, or if you're only interested in a patch, or if you will deal with the bug yourself, please explain that in the BTS.

People participating in the party have special rules for NMU; they can NMU without prior notice if they upload their NMU to DELAYED/3-day at least. All other NMU rules apply as usual; they should send the patch of the NMU to the BTS (to one of the open bugs fixed by the NMU, or to a new bug, tagged fixed). They should also respect any particular wishes of the maintainer.

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.

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 Abschnitt 4.10, „Das Debian-Paketverfolgungssystem“ abonniert haben. Sie können dazu die E-Mail-Adresse Paket@packages.qa.debian.org benutzen.

If you notice that a package is lacking maintenance, you should make sure that the maintainer is active and will continue to work on their packages. It is possible that they are not active anymore, but haven't registered out of the system, so to speak. On the other hand, it is also possible that they just need a reminder.

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.

A non-functional e-mail address is a violation of Debian Policy . If an e-mail "bounces", please file a bug against the package and submit this information to the MIA database.

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 verteilt wurden.) Denken Sie außerdem daran zu prüfen, ob der Betreuer in der Datenbank als im Urlaub befindlich markiert ist.

  • die Zahl 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, die er sponserte.

Es ist außerdem erlaubt, eine Anfrage an 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 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, 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!

On the other hand, although we are volunteers, a package maintainer has made a commitment and therefore has a responsibility to maintain the package. So you can stress the importance of the greater good — if a maintainer does not have the time or interest anymore, they should let go and give the package to someone with more time and/or interest.

If you are interested in working on the MIA team, please have a look at the README file in /org/qa.debian.org/mia on qa.debian.org, where the technical details and the MIA procedures are documented, and contact .

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

Sponsoring a package means uploading a package for a maintainer who is not able to do it on their own. It's not a trivial matter; the sponsor must verify the packaging and ensure that it is of the high level of quality that Debian strives to have.

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 es irgendwo online ab (wie auf mentors.debian.net) oder stellt, was noch besser ist, einen Verweis zu einem öffentlichen VCS-Depot (siehe Abschnitt 4.4.5, „Die VCS-Server“) bereit, wo das Paket verwaltet wird.

  2. The sponsor downloads (or checks out) the source package.

  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.

Before delving into the details of how to sponsor a package, you should ask yourself whether adding the proposed package is beneficial to Debian.

There's no simple rule to answer this question; it can depend on many factors: is the upstream codebase mature and not full of security holes? Are there pre-existing packages that can do the same task and how do they compare to this new package? Has the new package been requested by users and how large is the user base? How active are the upstream developers?

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 außerdem eine gute Idee zu wissen, wie er Debian gegenübersteht: Stimmt er der Debian-Philosophie zu und beabsichtigt er, Debian beizutreten? Angesichts dessen, wie einfach es ist, ein Debian-Betreuer zu werden, möchten Sie vielleicht nur Leute sponsoren, die planen beizutreten. Auf diese Art wissen Sie von Beginn an, dass Sie nicht auf unbestimmte Zeit als Sponsor agieren müssen.

New maintainers usually have certain difficulties creating Debian packages — this is quite understandable. They will make mistakes. That's why sponsoring a brand new package into Debian requires a thorough review of the Debian packaging. Sometimes several iterations will be needed until the package is good enough to be uploaded to Debian. Thus being a sponsor implies being a mentor.

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. [7]

  • 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).

  • Run lintian (see Abschnitt A.2.1, „lintian). It will catch many common problems. Be sure to verify that any lintian overrides set up by the maintainer are fully justified.

  • Führen Sie licensecheck aus (Teil von Abschnitt A.6.1, „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 Abschnitt A.4.3, „pbuilder), um sicherzustellen, dass die Build-Abhängigkeiten vollständig sind.

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

  • Lesen Sie debian/rules Korrektur: Folgt es den optimalen Vorgehensweisen (siehe Abschnitt 6.1, „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 Kapitel 6, Optimale Vorgehensweise beim Paketieren)?

  • Build the packages, install them and try the software. Ensure that you can remove and purge the packages. Maybe test them with piuparts.

If the audit did not reveal any problems, you can build the package and upload it to Debian. Remember that even if you're not the maintainer, as a sponsor you are still responsible for what you upload to Debian. That's why you're encouraged to keep up with the package through Abschnitt 4.10, „Das Debian-Paketverfolgungssystem“.

Note that you should not need to modify the source package to put your name in the changelog or in the control file. The Maintainer field of the control file and the changelog should list the person who did the packaging, i.e. the sponsee. That way they will get all the BTS mail.

Instead, you should instruct dpkg-buildpackage to use your key for the signature. You do that with the -k option:

dpkg-buildpackage -kSCHLÜSSEL-ID

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

DEBSIGN_KEYID=SCHLÜSSEL-ID

You will usually assume that the package has already gone through a full review. So instead of doing it again, you will carefully analyze the difference between the current version and the new version prepared by the maintainer. If you have not done the initial review yourself, you might still want to have a deeper look just in case the initial reviewer was sloppy.

To be able to analyze the difference, you need both versions. Download the current version of the source package (with apt-get source) and rebuild it (or download the current binary packages with aptitude download). Download the source package to sponsor (usually with dget).

Read the new changelog entry; it should tell you what to expect during the review. The main tool you will use is debdiff (provided by the devscripts package); you can run it with two source packages (.dsc files), or two binary packages, or two .changes files (it will then compare all the binary packages listed in the .changes).

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.

If everything is fine, build the package and compare the binary packages to verify that the changes on the source package have no unexpected consequences (some files dropped by mistake, missing dependencies, etc.).

You might want to check out the Package Tracking System (see Abschnitt 4.10, „Das Debian-Paketverfolgungssystem“) to verify if the maintainer has not missed something important. Maybe there are translation updates sitting in the BTS that could have been integrated. Maybe the package has been NMUed and the maintainer forgot to integrate the changes from the NMU into their package. Maybe there's a release critical bug that they have left unhandled and that's blocking migration to testing. If you find something that they could have done (better), it's time to tell them so that they can improve for next time, and so that they have a better understanding of their responsibilities.

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] You can find more checks in the wiki, where several developers share their own sponsorship checklists.