{"id":9186,"date":"2012-09-19T23:48:17","date_gmt":"2012-09-19T21:48:17","guid":{"rendered":"https:\/\/www.gambaru.de\/blog\/?p=9186"},"modified":"2012-09-19T23:48:17","modified_gmt":"2012-09-19T21:48:17","slug":"wie-man-veroffentlichungskritische-bugs-in-debian-beseitigt","status":"publish","type":"post","link":"https:\/\/gambaru.de\/blog\/2012\/09\/19\/wie-man-veroffentlichungskritische-bugs-in-debian-beseitigt\/","title":{"rendered":"Wie man ver\u00f6ffentlichungskritische Bugs in Debian beseitigt"},"content":{"rendered":"

Es h\u00e4lt sich hartn\u00e4ckig das Ger\u00fccht, dass es so etwas wie einen Konkurrenzkampf zwischen Debian und Ubuntu gebe. Tats\u00e4chlich ermutigt Ubuntu jedoch neue Software<\/a> \u00fcber Debian einzubringen. Im Umkehrschluss hei\u00dft das auch, dass jeder Beitrag zu Debian<\/a> auch ein Beitrag zu Ubuntu ist.
\nIn diesem Artikel geht es darum, dass auch ein kleiner Beitrag der gesamten Distribution weiterhelfen kann und dass das Beseitigen von Bugs, Modifizieren von Quelltext und die Neuerstellung des Pakets kein Hexenwerk sein muss. Besonders hilfreich ist das Beseitigen von sogenannten ver\u00f6ffentlichungskritischen Bugs, kurz RC-Bugs genannt.<\/p>\n

Der grobe Ablauf<\/h2>\n
    \n
  1. Finde einen RC-Bug, der dich interessiert.<\/li>\n
  2. Erstelle einen Patch f\u00fcr das Problem.<\/li>\n
  3. Schicke die L\u00f6sung an die Fehlerdatenbank<\/a> von Debian.<\/li>\n
  4. Finde jemanden, der das Paket hochladen kann.<\/li>\n<\/ol>\n

    Finde einen RC-Bug<\/h2>\n

    Erster Anlaufpunkt um einen RC-Bug zu finden ist die Ultimative Debian Datenbank<\/a> (UDD). Hier l\u00e4sst sich mit Hilfe verschiedener Filteroptionen die Suche exakt einschr\u00e4nken. F\u00fcr den angehenden Kammerj\u00e4ger ist diese Ansicht<\/a> die zur Zeit beste. Wichtig ist, dass man alle schon mit Patch markierten Bugs und alle die neuer als 7 Tage sind ignorieren kann, da es bei ersteren eine L\u00f6sung gibt und bei letzteren dem Paketverwalter zumindest eine Chance einger\u00e4umt werden sollte, das Problem selbst zu l\u00f6sen.
    \nEin hilfreiches Werkzeug ist das Programm rc-alert<\/code>, welches sich im Paket     devscripts<\/a> befindet und anzeigt, welche Software auf dem eigenen Rechner kritische Fehler aufweist. Ein Bonus von rc-alert ist, dass es nach Debtags filtern kann.
    \nMit dem nachfolgenden Befehl werden nur Debian Testing und Unstable nach Bugs durchsucht und geflickte und kurz vor dem Upload stehende Pakete ausgelassen. Zus\u00e4tzlich wird nur jene Software aufgelistet, die in Perl oder Python implementiert worden ist.
    \nrc-alert --include-dists TU --exclude-tags P+ --debtags implemented-in::perl,implemented-in::python<\/code>
    \n\"Multi<\/p>\n

    Erstelle einen Patch<\/h2>\n

    In vielen F\u00e4llen ben\u00f6tigt man nicht einmal Kenntnisse in einer Programmiersprache, sondern es gen\u00fcgt mit einem Texteditor umgehen zu k\u00f6nnen. In Bug #675220<\/a>, #685959<\/a> und #685958<\/a> geht es schlicht darum, dass die E-Mail-Adresse des Paketverwalters ung\u00fcltig ist, was gegen die Paketrichtlinien<\/a> von Debian verst\u00f6\u00dft. Genauso gut kann aber auch eine Abh\u00e4ngigkeit falsch sein, wodurch das Paket sich nicht mehr kompilieren l\u00e4sst. Diese Art von Fehler haben zwar ernste Auswirkungen, lassen sich jedoch in der Regel leicht beheben.
    \nZum Arbeiten mit Quellpaketen solltet ihr euch das Paket     build-essential<\/a> oder, wenn ihr Gefallen an der Sache gefunden habt, packaging-dev<\/a> installieren.
    \napt-get source textedit.app<\/code>
    \nMit Hilfe von dpkg-dev wird automatisch das Quellpaket entpackt. Nachdem man in das entpackte Quellverzeichniss gewechselt ist, sollte man zuerst einen neuen Changelog-Eintrag anlegen und deutlich machen, dass man hier eine \u00c4nderung als Nicht-Paketverwalterin vornimmt.
    \ndch --nmu<\/code>
    \nHierdurch wird automatisch das Changelog mit dem richtigen Eintrag ge\u00f6ffnet. Da der Patch f\u00fcr Unstable gedacht ist (der Regelfall) sollte das UNRELEASED dementsprechend in unstable umge\u00e4ndert werden. Noch eine kurze Beschreibung, was ihr ge\u00e4ndert habt und ein wichtiger Schritt f\u00fcr einen Non-Maintainer-Upload (NMU) ist getan.<\/p>\n

    \ntextedit.app (4.0+20061029-3.4) unstable; urgency=low\n  * Non-maintainer upload.\n  * Fix invalid maintainer email address. (Closes: #675220)\n<\/pre>\n
    Der wichtigste Anlaufpunkt im Quellpaket ist das Debian-Verzeichnis. In debian\/control<\/a> lassen sich z.B. allgemeine Paketinformationen wie die E-Mail-Adresse des Maintainers, Abh\u00e4ngigkeiten oder auch die empfohlenen Pakete in einer einfachen Textdatei definieren. Der \"Fix\" f\u00fcr die vorher erw\u00e4hnten Bugs war es, das Maintainer-Feld zu aktualisieren. G\u00e4be es noch weitere \u00c4nderungen zu machen, k\u00f6nnte man mit
    \ndch -a<\/code>
    \nweitere Eintr\u00e4ge zum Changelog hinzuf\u00fcgen und die entsprechende Textdateien innerhalb des Debian-Verzeichnisses \u00e4ndern.<\/p>\n
    Einen Patch mit Quilt erstellen<\/h3>\n
    M\u00fcsst ihr hingegen den Quellcode selbst patchen und entspricht das Paket dem neuen Format 3.0 (quilt), k\u00f6nnt ihr quilt<\/a> zum Patchen benutzen. Ob ein Paket dies unterst\u00fctzt findet ihr heraus, indem ihr einen Blick in die Datei debian\/source\/format<\/em> werft. Rapha\u00ebl Hertzog hat die Bedienung von quilt<\/a> in einem sehr guten Artikel auf den Punkt gebracht.
    \nDer grobe Ablauf ist, dass ihr innerhalb des Debian-Verzeichnisses einen Ordner patches erstellen m\u00fcsst, falls er nicht vorhanden ist und dann nach diesem Schema Patches erzeugt.<\/p>\n