Hilfe zur Selbsthilfe – Erkenne die Probleme deines Lieblingspakets

Genug mit dem Blogurlaub. Bevor ich das Schreiben ganz verlerne, mache ich meine Antwort zu einer E-Mail kurzerhand öffentlich und versuche ein paar nützliche Links und Hilfsmittel anzuschneiden, mit denen ihr erkennen könnt, ob etwas mit eurem Lieblingspaket nicht stimmt und wie ihr vielleicht sogar dabei helfen könnt, damit sich die Lage wieder etwas aufhellt.
Vor kurzem erhielt ich per Mail die Anfrage, wie ich es mit Xarchiver halten würde. Vor einigen Jahren, einige erinnern sich sicherlich noch, war das immerhin das Standardprogramm von Xfce, wenn es um das Archivieren bzw. Komprimieren von Dateien und Verzeichnissen ging, auch wenn es eine Zeitlang mit Squeeze konkurrierte.
Beide Programme sind ein wenig in der Versenkung verschwunden, weil sie schon seit längerem von Xfce nicht mehr beworben werden. Xarchiver steckt seit 2009 in einer Art Winterschlaf und solange niemand die Entwicklung erneut aufnimmt, wird dies auch weiterhin so bleiben. Jedoch ist es im Grunde genommen gar nicht so schlecht um dieses Programm bestellt und es erfreut sich nach wie vor einer großen Anzahl von Nutzern.

Die Diagnose

Wie bei den meisten Programmen gibt es auch bei Xarchiver ein paar Bugs. Das stellt sich z.B. so dar, dass man mitunter eine böse Überraschung erlebt, wenn man versucht 7z-Archive zu öffnen und das Programm dabei abstürzt. Die Bugs #665642 und #551468 erzählen davon und auch auf Launchpad sammeln sich die Fehlerberichte.
In Ubuntu liefert die Paketübersicht den ersten Hinweis darauf, wie es um das Paket bestellt ist. Neben dem Link zu den Fehlerberichten ist vor allem interessant zu wissen, dass Xarchiver von den Ubuntu MOTU (Master of the Universe ;)) Entwicklern betreut wird, jedoch wie die meisten Ubuntu-Pakete ursprünglich vom Debian-Projekt stammt und dort einen Maintainer besitzt, der sich in der Regel auch darum kümmert.
Für Debian gibt es eine ganz ähnliche Paketübersicht wie bei Ubuntu, jedoch mit einem besonderen Bonus, Debians Package Tracking System (PTS). In dieser Übersicht erkennt man oft schon mit einem Blick wie es um das Paket bestellt ist.
Bei Xarchiver fällt auf, dass der letzte Upload vor mehr als drei Jahren stattfand, was man unter der Rubrik News schnell erkennen kann. Auf der linken Seite befinden sich die allgemeinen Angaben zum Paket, den Versionen und wer der aktuelle Betreuer ist. Rechts wiederum ist die Kurzübersicht zu den Fehlern unterteilt nach Schweregrad. Viele nützliche Links befinden sich darunter. Insbesondere der Bericht von Lintian über festgestellte Paketfehler macht oft deutlich wie es um die inneren Werte des Pakets steht.
Als Indikator für die Popularität des Pakets dient hingegen der sogenannte Popcon-Wert. Debian bietet hier gegenüber der Ubuntu-Variante ein paar nette Graphen, die Aufschluss über die Benutzerentwicklung geben. Der Trend bei Xarchiver zeigt klar nach oben und mit mehr als 6000 installierten Anwendungen, das sind immerhin 5% aller eingereichten Berichte, ist Xarchiver für eine optionale Anwendung ziemlich begehrt.
Wäre das Paket "verwaist" oder würde der Betreuer nach einem Nachfolger suchen, gäbe es unter Todo einen weiteren Link, der auf den entsprechenden Fehlerbericht zeigen würde. Da dies nicht der Fall ist, kann man nur zum Schluss kommen, dass das Paket aktuell nicht betreut wird, jedoch auch kein Nachfolger gesucht wird, Fehler aufweist, von denen sich einige beseitigen lassen und das ganze Paket ziemlich populär ist. Auf der anderen Seite stagniert die Entwicklung seit mehr als drei Jahren, weswegen der Paketbetreuer auf jeden Fall auf Mithilfe angewiesen ist, wenn er nicht gleich selbst der neue Entwickler von Xarchiver werden möchte.
In so einem Fall würde ich also den Patch für den 7z-Bug, den es tatsächlich schon gibt, an den Fehlerbericht anhängen und freundlich anfragen, ob das Paket weiterhin noch betreut wird. In der Regel sollte man danach:

  • Zwei Wochen warten, dann noch einmal nachfragen.
  • Nach einem Monat einen Blick auf diese Seite werfen und den Links zur Debian-Mailingliste für Qualitätssicherung und dem hauseigenen IRC-Channel folgen und das Problem dort ansprechen.

In der Regel wird das Paket spätestens dann für neue interessierte Betreuer freigegeben. Der Vorgang könnte meiner Meinung nach etwas einfacher sein und zur Zeit gibt es tatsächlich eine aktive Diskussion darüber diesen Prozess durch einen Fehlerbericht einzuleiten. Dieser kann dann von jedem Nutzer eingereicht werden, jedoch nur von Debianentwicklern bestätigt werden, wonach das Paket für einen Nachfolger freigegeben wird. Das Ganze ist noch nicht spruchreif, wird aber mit etwas Glück in den nächsten Monaten vorgestellt werden.

Fazit

Oft spielen wie immer mehrere Faktoren zusammen. Die Entwicklung des Programms ist eingeschlafen, der Paketbetreuer scheint in Urlaub zu sein und am eigenen PC fragt man sich nur, woran hängt es eigentlich. Das Paketverfolgungssystem von Debian bietet die wichtigsten Infos auf einen Blick und danach kann man dann entscheiden, ob man Zeit in die Fehlerbeseitigung investieren möchte oder doch lieber zu einer Alternative greift.

Du willst ein Spiel in Debian und Ubuntu sehen? So gehts!

Mich erreichte vor drei Wochen eine nette E-Mail und schnell kamen wir auf das Thema Freie Software und Spiele bei Debian zu sprechen. Unter anderem erhielt ich auch ein paar Vorschläge, welche Spiele es in die nächste Veröffentlichung von Debian schaffen sollten, was mich zu der Idee brachte diesen Artikel zu schreiben.

Du willst ein Spiel in Debian und Ubuntu sehen? So gehts!

FreeOrion

  • Gehe auf die Suche. Es gibt tatsächlich viele Spiele, die als Freie Software entwickelt werden, aber von denen noch kaum jemand gehört hat. Berusky2 in der Linuxversion gibt es zwar schon mehr als ein Jahr, von einem Paket in Ubuntu oder Debian fehlt jedoch noch jede Spur. FreeOrion ist ein rundenbasiertes, intergalaktisches Weltraumeroberungsspiel in der Tradition der Master-of-Orion-Serie. Lips of Suna ist ein ironisch gemeintes Action-Rollenspiel. Leider existiert für all diese Spiele noch kein Debianpaket. Weitere Ideen zu Linuxspielen findest du z.B. bei holarse-linuxgaming.de, der Linux Game Database, Penguspy, Linuxgames.com und bei vielen weiteren Links.
  • Mache sie bekannt. Es nützt nichts, wenn du die Einzige bist, die all diese Spiele kennt. Mache sie bekannt! Das Games Team von Debian pflegt ein paar Seiten im Debian-Wiki. Unter anderem sind das Games/Suggested und Games/Unsuitable. Erstellt euch einen Account für das Wiki und tragt eure Ideen unter "Suggested" ein. Haltet euch an die alphabetische Sortierung und beschreibt, um was es bei dem Spiel geht, unter welcher Lizenz man es verbreiten darf, in welcher Programmiersprache es geschrieben wurde und was euch ansonsten noch für Besonderheiten aufgefallen sind.
  • Erstellt einen RFP- oder ITP-Fehlerbericht. RFP steht für request for package und ITP für intent to package. Falls ihr das Spiel selbst nach Debian bringen wollt, ist ITP natürlich die erste Wahl, in den meisten Fällen genügt es jedoch schon Aufmerksamkeit zu erzeugen, indem ihr einen RFP-Fehlerbericht verfasst.
    Am einfachsten benutzt ihr reportbug.
    reportbug wnpp
    Mit diesem Befehl erstellt ihr einen Fehlerbericht gegen das sogenannte Pseudo-Paket "wnpp", Work-Needing-and-Prospective-Packages. Folgt ihr den Menüoptionen zum Thema RFP, könnt ihr ein Paket vorschlagen, welches ihr für geeignet haltet, um irgendwann in Debian oder Ubuntu zu erscheinen.
  • Nutzt das richtige Forum. Spieleentwicklung geschieht häufig auf bestimmten Mailinglisten, im IRC, aber auch Foren und jede andere Kommunikationsform sind denkbar. Debian hat eine eigene Mailingliste für die Entwicklung von Spielen, bei Ubuntu gibt es ebenfalls ein eigenes GamingTeam! Wenn ihr eine gute Idee habt, sprecht sie an, stellt sie vor, verwirklicht sie! Umso mehr Informationen ihr zur Verfügung stellt, desto besser können sich Interessierte eine Meinung darüber bilden, ob sie das Spiel als Paket einbringen wollen. Lasst euch jedoch auch von Rückschlägen nicht entmutigen.
  • Tu es selbst. Ihr habt euch die Mühe gemacht und alle Informationen zusammengetragen, sie öffentlich gemacht, aber so richtig will keiner anbeißen. Warum? Freie Software zu entwickeln ist für viele nur ein Nebenjob. Ihr erntet also nur Missmut und gar Unverständnis, wenn ihr erwartet, dass irgendjemand ein Spiel für euch paketieren soll. Macht es einfach selbst. Die Chancen steigen exponentiell, wenn ihr euch selbst als zukünftiger Paketverwalter anbietet.
    Wenn gute Gründe gegen die Karriere als Paketverwalterin sprechen, macht euch den Spaß und tragt so viele Informationen zusammen wie nur möglich, haltet sie am besten auf einer eigenen Wiki-Seite fest und stellt sie vor. Die meiste Arbeit bei der Erstellung eines Pakets ist nicht selten nur die reine Technik, sondern oft das Sichten der Lizenzen. Stimmt es tatsächlich, wenn die Entwickler ein reines "Open-Source-Spiel" versprechen? Oft offenbart z.B.
    grep -ri "All rights reserved" /Pfad-zum-Spiel
    die ein oder andere Überraschung. Ihr helft der zukünftigen Aufnahme des Spiels in Debian und Ubuntu ungemein, wenn ihr solche "Show-stopper" frühzeitig erkennt und problematische Dateien und Code öffentlich dokumentiert.

Ich erwähnte es sicherlich schon an der ein oder anderen Stelle. Freie Software bietet einem alle Freiheiten, ist manchmal auch anstrengend, macht jedoch auch immer wieder Spaß.
Mach mit!

Mehr als ein Feiertag: Mediathekview 3.0.0 ist in Debian Sid

MediathekView
Vorgestern war in zweifacher Hinsicht ein besonderer Tag. Es war Tag der Deutschen Einheit und mein erstes "richtiges" Debianpaket, MediathekView, wurde in das offizielle Archiv hochgeladen und befindet sich nun in Debian Unstable alias Sid. Wer meine MediathekView-Pakete bisher von diesem Blog aus bezogen hat, braucht sich nicht groß umstellen, bis auf ein paar interne Details hat sich zur Version 3.0.0 nicht viel geändert.
Ich werde nun einen sogenannten "Unblock"-Fehlerbericht verfassen, damit MediathekView 3.0.0 noch die Chance hat nach Wheezy zu migrieren und die nächste bzw. erste stabile Version in Debian wird. Die Chancen stehen leider nicht besonders gut, da sich gegenüber der alten Version viel verändert hat. Wenn das Release-Team den Daumen senkt, gibt es eben keine Version für Debian Wheezy. Liegt leider außerhalb meines Machtbereichs. Sorry.
Ansonsten wurden noch meine drei "RC-NMUs" (Abkürzungen sind toll) ebenfalls gestern hochgeladen. Die Sache mit der invaliden E-Mail-Adresse. Zugegeben das waren triviale Änderungen, aber ein Debianentwickler dachte sich scheinbar: "Egal. Es fixt drei veröffentlichungskritische Bugs". Also wer immer schon mal Lust hatte Debian oder Freier Software im Allgemeinen zu helfen, dann zögert nicht und beseitigt RC-Bugs!
Der Vollständigkeit halber muss ich noch erwähnen, dass Bart Martens, ebenfalls Debian-Entwickler, die Sache leicht anders gesehen hat. Seine Aussage: Wenn ein Paketverwalter es nicht einmal für nötig halte seine Kontaktdaten aktuell zu halten, solle man das Paket gleich verwaisen lassen - sprich einen neuen Maintainer suchen.
Bart hat Recht. Ich denke, es ist vollkommen normal, wenn man irgendwann an einen Punkt gelangt und keine Zeit oder Lust mehr für Debian hat und weiterziehen möchte. Fairerweise sollte man jedoch das auch öffentlich machen und Leute dazu auffordern die eigenen Pakete zu übernehmen. Viele verschwinden jedoch und zurück bleibt Software, die keiner mehr betreut. Aus falscher Rücksichtnahme auf den Maintainer passiert dann auch schon einmal Monate lang gar nichts.
Ich denke hier hilft einfach gesunder Menschenverstand weiter. Wenn ein Paket tatsächlich in einem miserablen Zustand ist, erstellt einfach einen Patch oder ein neues, besseres Paket. Mit Sicherheit wird sich dann jemand finden, der es in Debian einstellt.

Unschlagbare Kombination: Cowbuilder, Eatmydata und ccache

Ich hatte gerade einen fürchterlichen Einleitungssatz mit Kühen und Essen im Kopf, deshalb versuche ich es im zweiten Anlauf mit diesem Klassiker.
Mit welcher Formel kann man das Volumen einer Pizza mit dem Radius z und der Dicke a beschreiben?
Pi * z * z * a
Wer auch nur ein bißchen geschmunzelt hat, sollte sich Kalkofe und die "Jean Pütz"-Folge anhören oder Debian-Entwickler werden, die so etwas in ihren Signaturen stehen haben. 😉
Nachdem ich in den vergangenen Wochen mich mehr und mehr mit den ganzen Geek-Werkzeugen zur Debian-Entwicklung auseinandergesetzt hatte, wollte ich an dieser Stelle kurz drei sehr nützliche Programme vorstellen, die man als Paketbauer für Debian gut gebrauchen kann. Nach und nach hat sich herausgestellt, dass diese drei ausreichend sind, um ein Paket sauber, reproduzierbar und schnell erstellen zu können.
Mein Frage war, wie ich das Kompilieren von Debian-Paketen innerhalb einer Chroot-Umgebung beschleunigen kann, die mit Hilfe von Pbuilder oder besser noch Cowbuilder erstellt werden und schließlich wurde ich im Pbuilder-Howto von Ubuntu.com fündig. Pbuilder funktionierte schon letztes Jahr beim Kompilieren von DWM sehr gut und mit diesen zwei Skripten könnt ihr sofort loslegen.
Zum Optimieren des Vorgangs benötigt ihr Cowbuilder, einen Wrapper um Pbuilder, der das Anlegen der Chroot-Umgebung beschleunigt, indem Hardlinks auf schon bestehende Daten verweisen. Der zeitraubendste Prozess beim Bauen in einer Chroot-Umgebung ist jedoch das Installieren der Abhängigkeiten. Apt oder besser dpkg synchronisiert jeden Schreibzugriff auf der Festplatte und wartet bis das System erfolgreich zurückmeldet, dass das Paket auch tatsächlich ordnungsgemäß installiert wurde. Für eine normale Ubuntu- oder Debianinstallation ist das sinnvoll.
Jedoch bei einer Chroot-Umgebung, die nach jedem (hoffentlich) erfolgreichen Bauen des Pakets wieder zerstört wird, kann man auf diese Verzögerung verzichten. Signalisieren wir dem System einfach, dass der Schreibvorgang immer erfolgreich ist.
Hier kommt Eatmydata ins Spiel. Der Name ist Programm. In der .pbuilderrc muss folgendes eingetragen werden.

Eatmydata

EXTRAPACKAGES="eatmydata ccache"
if [ -z "$LD_PRELOAD" ]; then
  LD_PRELOAD=/usr/lib/libeatmydata/libeatmydata.so
else
  LD_PRELOAD="$LD_PRELOAD":/usr/lib/libeatmydata/libeatmydata.so
fi
export LD_PRELOAD

In die Chroot-Umgebung lässt sich auch manuell wechseln und eatmydata installieren.
DIST=sid ARCH=amd64 cowbuilder --login --save
apt-get install eatmydata

ccache

Ccache speichert die Ergebnisse des Kompilierens zwischen. Das Ergebnis spürt man, wenn man das gleiche Paket mehrmals hintereinander neu erstellen möchte, weil Veränderungen notwendig waren.
In der .pbuilderrc steht wiederum:

sudo mkdir -p /var/cache/pbuilder/ccache
sudo chmod a+w /var/cache/pbuilder/ccache
export CCACHE_DIR="/var/cache/pbuilder/ccache"
export PATH="/usr/lib/ccache:${PATH}"
BINDMOUNTS="${CCACHE_DIR}"

Ein Cowbuilder-Chroot erstellt ihr dann mit
DIST=sid ARCH=amd64 cowbuilder --create
Pakete werden mit
DIST=sid ARCH=amd64 cowbuilder --build meinPaket.dsc
gebaut. Kombiniert das ganze mit dem gestern vorgestellten Schroot und ihr habt die perfekte Ausgangsbasis um Pakete sauber und ohne Ballast für euer normales Produktivsystem zu erstellen.

Schroot(e) dein Linux: Debian in Ubuntu installieren Teil 2

Letztes Jahr hatte ich mir zu Testzwecken ein Debian-System innerhalb von Ubuntu 10.10 mit Hilfe von Debootstrap installiert, um in diesem abgeschotteten Bereich einen Linuxkernel zu kompilieren. Damit das funktionierte griff ich auf eine typische Linuxfunktion, chroot, zurück.
Der Nachteil des Ganzen war, dass nur Root in so eine Chroot-Umgebung wechseln durfte und ich manuell /proc und /dev hinein mounten musste. Das alles geht einfacher und zwar mit Schroot.
Schroot nimmt einem die ganze Arbeit ab. Ab sofort kann man als normaler Benutzer in die Chroot-Umgebung wechseln und das manuelle Einbinden von Partitionen und Dateisystemen entfällt. Benutze ich einen kachelnden Fenstermanager befindet sich meine Entwicklungsumgebung (Debian Sid) im Terminalfenster auf der linken Seite und Debian Stable oder Testing auf der rechten. Ich kann Pakete innerhalb von Schroot kompilieren und das Experimentelle von meinem stabilen System trennen, muss mich aber nicht verrenken, um Dateien zwischen beiden auszutauschen, denn das beste von allem ist, sowohl die Schroot-Umgebung als auch die reguläre Arbeitsumgebung greifen auf das gleiche Home-Verzeichnis zurück.

Schritte um Schroot einzurichten

  1. aptitude install debootstrap schroot
  2. mkdir -p /home/chroot/sid-amd64
  3. cd /home/chroot/
  4. debootstrap --include=zsh --arch amd64 sid sid-amd64 http://ftp.de.debian.org/debian
  5. Kaffee holen.
  6. vim /etc/schroot/schroot.conf
    [sid]
    description=Debian sid (unstable)
    directory=/home/chroot/sid-amd64
    type=directory
    root-users=apo
    groups=sbuild
    root-groups=root,sbuild
    aliases=unstable,default
    
  7. schroot -c sid

In der schroot.conf lassen sich nach diesem Schema weitere Umgebungen definieren, z.B. für Ubuntu! oder ein i386-System. Da ich [sid] mit dem Alias default versehen habe, kann ich auch direkt nur mit dem Befehl schroot in die Umgebung gelangen. Ich verwende ZSH als Shell und habe mir dieses Paket schon bei der Installation mit Debootstrap hinzugefügt. Ob ihr Gruppen für euren Benutzer oder gar mehrere anlegt ist Geschmackssache. Zur Zeit experimentiere ich ein wenig damit.
Die Sid-Umgebung lässt sich genauso konfigurieren, wie ihr das von eurem normalen System auch gewohnt seid. Das liegt vor allem daran, dass Schroot die ganze Arbeit erledigt und die Konfiguration in /etc/schroot/default bei diesem Setup abarbeitet. Mein Home-Verzeichnis wird ebenfalls direkt in diesen eigenständigen Bereich eingebunden, so dass ich mich nicht lange mit Kleinarbeit aufhalten muss.
Schroot bietet noch viele weitere interessante Optionen und Möglichkeiten. Siehe auch man schroot und man schroot.conf. Ich muss noch herausfinden, wie ich X-Anwendungen an mein normales System weiterleiten kann. Zum Kompilieren von Paketen ist diese (S)chroot-Umgebung aber schon jetzt eine sehr praktische und auch performante Erleichterung, die eine virtuelle Maschine für die gleiche Aufgabe ersetzen kann.

MediathekView 3.0 und Wbar 2.3.4 auf dem Weg nach Debian!?

Bevor es hier gleich mit einem anderen Zwischenfazit weitergeht, wie steht es um MediathekView und Wbar?
Entwicklung braucht Zeit. Einen Sponsor zu finden, der die Sache ins Archiv hochlädt, ist ein Geduldsspiel. Es gibt an die 30000 Pakete in Debian aber nur ca. 1000 Debian-Entwickler, die die Berechtigung besitzen Pakete überhaupt in das Archiv zu befördern, wo die FTP-Master mit Argusaugen über jeden Neuzugang wachen.
Tausend Leute, das klingt eigentlich gar nicht so schlecht. Manche davon kümmern sich jedoch um 100 verschiedene Pakete gleichzeitig und Debian ist nicht nur Softwareentwicklung. Es gibt Teams, die sich um die Übersetzung der Software und die Gestaltung und Aufrechterhaltung der Webpräsenz und von Mailinglisten kümmern. Und dann soll man auch noch die Verantwortung für unbekannte Neuentwickler übernehmen, sie anleiten und deren Pakete auf Korrektheit überprüfen? Wenn so ein Neuer Schaden anrichtet und man hat es vorher nicht gesehen...
Klingt nicht nach der dankbarsten Aufgabe, aber es gibt Freiwillige, die sich darum kümmern. Vor wenigen Tagen habe ich nach genau so einem Sponsor oder Mentor für Wbar gesucht (#688310). Mittlerweile ist sogar Version 2.3.4. erschienen und meine eingesandten Patches wurden freundlicherweise berücksichtigt. Etwas überrascht war ich dann doch als Bart Martens, seines Zeichens Debian-Entwickler und sehr aktiv bei den Mentoren Bug #575087 auf Schweregrad "Grave" hochgesetzt hat und mich gebeten hat diesen für Wheezy zu fixen.
Nun würde Version 2.3.4 von Wbar das Problem lösen, aber aus der kurzen Nachricht von Bart konnte ich nur entnehmen, dass ich wohl einen gezielten Fix für das aktuelle Paket in Wheezy einspielen soll. Wer sich nun fragt, warum Wbar plötzlich unbrauchbar wurde, der findet die Lösung vielleicht, wenn er versucht Wbar ohne empfohlene Pakete zu installieren. Die Schnellstartleiste verweigert ihren Dienst, weil der Pfad zu den Icons und/oder der Schrift dann den Rückgabewert NULL liefert. Kurzum das Ding startet nicht.
Also meine bescheidene Meinung ist: Wer Schellstartleisten ohne den korrekten Pfad zu den Symbolen startet, muss mindestens zweimal von e^(i*pi)+1 bis Unendlich zählen. Jedoch ganz abwegig ist der Fehlerbericht natürlich nicht und ja in Version 2.3.4. darf man auch den falschen Pfad zu seinen Symbolen und der Schrift angeben und das (transparente) Hintergrundbild von Wbar ist trotzdem zu sehen. 🙂
Ich denke jedoch, dass das kein veröffentlichungskritischer Fehler ist und werde das so auch noch einmal in den Fehlerbericht schreiben. Ist natürlich ein doofer Einstieg in Debian, wenn man erst einmal anderer Meinung als der Debianentwickler ist. 😐
MediathekView ist meiner Meinung nach in einem vorzeigbaren Zustand und wartet darauf einmal gründlich analysiert zu werden. Mittlerweile haben sogar zwei DDs Interesse daran bekundet. Der Witz daran ist, dass es bisher dabei geblieben ist. Die ganze Geschichte lässt sich in Fehlerbericht #681680 nachlesen. Ich bin aber weiterhin guter Hoffnung und ja 2.6.1 wurde aufgegeben, entweder schafft es 3.0.0 nach Wheezy oder gar nichts.
Ich habe die Downloadlinks von Mediathekview und Wbar aktualisiert. Wer also die Zeit verkürzen möchte, findet dort die entsprechenden Debianpakete. Danke auch an das bisherige Feedback zu MediathekView. Ich habe den Pfad zum flv.sh-Skript angepasst. Auch die Idee mit dem Shellskript halte ich weiterhin für gut. Vielleicht lässt sich damit in der Zukunft tatsächlich die Mediathek komplett ohne den Umweg über Java auf die Konsole holen. 😉

ganbatte kudasai: Das Open-Source-Blog-Netzwerk

Open-Source-Blog-Netzwerk
Seit letzter Woche bin ich Mitglied im Open-Source-Blog-Netzwerk (OSBN). Mit einem dezenten Button auf der rechten Seite, habe ich das seit heute auch deutlicher gemacht. In was für eine Sekte hat es ihn nun verschlagen? Nun das Ganze muss man sich als einen losen Zusammenschluss von Weblogs vorstellen, die hautpsächlich über das Thema Open Source und Freie Software bloggen und deren Feeds an einer zentralen Stelle aggregiert werden. Also genau das, was z.B. der Planet von ubuntuusers.de auch macht. Wo liegt also der große Unterschied?
Zum einen macht es ein loser und unabhängiger Bund etwas einfacher eigene Schwerpunkte zu setzen. Manche fühlen sich vielleicht auch weniger durch Vorgaben wie beim Planeten eingeschränkt, wobei mich die Regeln dort in keinster Weise stören. Grundsätzlich sind dort Themen über Freie Software sehr willkommen, ohne dass jeder Artikel speziell Ubuntu thematisieren müsste. Und mal ganz ehrlich: Mich würde es auch stören, wenn jemand nur über seinen Hamster oder die politischen Weltanschauungen schreiben würde.
Ich sehe das OSBN daher mehr wie eine zusätzliche Ergänzung, ein Experiment und etwas, was man weiterentwickeln kann, ohne dass einer der Teilnehmer hier irgendwelchen Zwängen unterworfen wäre. Zugegeben die Aufrechterhaltung der Infrastruktur, die Pflege der Startseite und des Forums machen Arbeit. Der Grundgedanke ist, dass eine Plattform geschaffen wird, wo sich Blogger und Leser gleichermaßen austauschen können und man neue interessante Artikel, Informationen und Menschen finden kann, z.B. wenn man den OSBN-Feed liest.
OSBN wurde durch Valentin von picomol.de ins Leben gerufen. Das Open-Source-Blog-Netzwerk ist dabei eine Art Weiterentwicklung seines weiteren Projekts ubuntunews.de, das Newsfeeds aus der Ubuntu-verwandten Sphäre zusammenführt. Mich persönlich interessiert auch die dahinter steckende Technik. Alles ist mit PHP, HTML5, CSS und Simple Pie verwirklicht worden.
Die Hoffnungen für das Netzwerk gehen dahin, dass es Leser einfacher haben interessante Themen und Artikel zu entdecken und wir Blogger, nun ja, Leser gewinnen, die unsere bedruckten T-Shirts und Kaffeetassen kaufen. Außerdem mag ich kleine und unbekannte Netzwerke, die (noch) niemand kennt.
Warum ich bei OSBN bin und nicht einmal einen Button für Facebook, Twitter und Google+ in meinem Blog untergebracht habe? Der Grund ist,...kommt noch. 🙂

Wie man veröffentlichungskritische Bugs in Debian beseitigt

Es hält sich hartnäckig das Gerücht, dass es so etwas wie einen Konkurrenzkampf zwischen Debian und Ubuntu gebe. Tatsächlich ermutigt Ubuntu jedoch neue Software über Debian einzubringen. Im Umkehrschluss heißt das auch, dass jeder Beitrag zu Debian auch ein Beitrag zu Ubuntu ist.
In 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öffentlichungskritischen Bugs, kurz RC-Bugs genannt.

Der grobe Ablauf

  1. Finde einen RC-Bug, der dich interessiert.
  2. Erstelle einen Patch für das Problem.
  3. Schicke die Lösung an die Fehlerdatenbank von Debian.
  4. Finde jemanden, der das Paket hochladen kann.

Finde einen RC-Bug

Erster Anlaufpunkt um einen RC-Bug zu finden ist die Ultimative Debian Datenbank (UDD). Hier lässt sich mit Hilfe verschiedener Filteroptionen die Suche exakt einschränken. Für den angehenden Kammerjäger ist diese Ansicht 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ösung gibt und bei letzteren dem Paketverwalter zumindest eine Chance eingeräumt werden sollte, das Problem selbst zu lösen.
Ein hilfreiches Werkzeug ist das Programm rc-alert, welches sich im Paket devscripts befindet und anzeigt, welche Software auf dem eigenen Rechner kritische Fehler aufweist. Ein Bonus von rc-alert ist, dass es nach Debtags filtern kann.
Mit dem nachfolgenden Befehl werden nur Debian Testing und Unstable nach Bugs durchsucht und geflickte und kurz vor dem Upload stehende Pakete ausgelassen. Zusätzlich wird nur jene Software aufgelistet, die in Perl oder Python implementiert worden ist.
rc-alert --include-dists TU --exclude-tags P+ --debtags implemented-in::perl,implemented-in::python
Multi Disk Error

Erstelle einen Patch

In vielen Fällen benötigt man nicht einmal Kenntnisse in einer Programmiersprache, sondern es genügt mit einem Texteditor umgehen zu können. In Bug #675220, #685959 und #685958 geht es schlicht darum, dass die E-Mail-Adresse des Paketverwalters ungültig ist, was gegen die Paketrichtlinien von Debian verstößt. Genauso gut kann aber auch eine Abhängigkeit falsch sein, wodurch das Paket sich nicht mehr kompilieren lässt. Diese Art von Fehler haben zwar ernste Auswirkungen, lassen sich jedoch in der Regel leicht beheben.
Zum Arbeiten mit Quellpaketen solltet ihr euch das Paket build-essential oder, wenn ihr Gefallen an der Sache gefunden habt, packaging-dev installieren.
apt-get source textedit.app
Mit 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 Änderung als Nicht-Paketverwalterin vornimmt.
dch --nmu
Hierdurch wird automatisch das Changelog mit dem richtigen Eintrag geöffnet. Da der Patch für Unstable gedacht ist (der Regelfall) sollte das UNRELEASED dementsprechend in unstable umgeändert werden. Noch eine kurze Beschreibung, was ihr geändert habt und ein wichtiger Schritt für einen Non-Maintainer-Upload (NMU) ist getan.

textedit.app (4.0+20061029-3.4) unstable; urgency=low
  * Non-maintainer upload.
  * Fix invalid maintainer email address. (Closes: #675220)

Der wichtigste Anlaufpunkt im Quellpaket ist das Debian-Verzeichnis. In debian/control lassen sich z.B. allgemeine Paketinformationen wie die E-Mail-Adresse des Maintainers, Abhängigkeiten oder auch die empfohlenen Pakete in einer einfachen Textdatei definieren. Der "Fix" für die vorher erwähnten Bugs war es, das Maintainer-Feld zu aktualisieren. Gäbe es noch weitere Änderungen zu machen, könnte man mit
dch -a
weitere Einträge zum Changelog hinzufügen und die entsprechende Textdateien innerhalb des Debian-Verzeichnisses ändern.

Einen Patch mit Quilt erstellen

Müsst ihr hingegen den Quellcode selbst patchen und entspricht das Paket dem neuen Format 3.0 (quilt), könnt ihr quilt zum Patchen benutzen. Ob ein Paket dies unterstützt findet ihr heraus, indem ihr einen Blick in die Datei debian/source/format werft. Raphaël Hertzog hat die Bedienung von quilt in einem sehr guten Artikel auf den Punkt gebracht.
Der grobe Ablauf ist, dass ihr innerhalb des Debian-Verzeichnisses einen Ordner patches erstellen müsst, falls er nicht vorhanden ist und dann nach diesem Schema Patches erzeugt.

  • Erstellt einen neuen Patch
    quilt new NamedesPatches
  • Verändert eine oder mehrere Dateien nach Belieben
    quilt edit Datei
  • Wendet den Patch auf die Originaldatei an
    quilt push
  • Erneuert den Patch, wenn er schon existiert.
    quilt refresh

Einen Patch importieren

quilt import -P NamedesPatches /Pfad-zum-Patch.patch
quilt push
Häufig kommt es auch vor, dass schon jemand einen Patch hinterlassen hat und man ihn selbst ausprobieren oder testen möchte.

Schicke den Patch an die Fehlerdatenbank

Ist man der Meinung alles erledigt zu haben, sollte man zuerst alle Patches wieder zurücksetzen und das Quellpaket neu bauen.
Innerhalb des Quellverzeichnisses:
quilt pop -a
Dann

cd ..
dpkg-source -b textedit.app-4.0+20061029

Wenn ihr alles richtig gemacht habt, müsste nun eine weitere .dsc-Datei entstanden sein. Mit Hilfe von debdiff, dass sich auch im Paket devscripts befindet, lassen sich nun alle gemachten Unterschiede als Diff in eine neue Datei ausgeben, der Patch.
Allgemein:

debdiff altesPaket.dsc neuesPaket.dsc > Paket.debdiff

Im Speziellen:

debdiff textedit.app_4.0+20061029-3.3.dsc textedit.app_4.0+20061029-3.4.dsc > textedit.app.debdiff

Diese Datei muss jetzt nur noch per Mail an den Fehlerbericht geschickt werden und dieser mit dem passenden Tag patch markiert werden. Die Anleitung zur Bedienung der Fehlerdatenbank verrät alle Details. Zum Markieren als Patch genügt eine Mail an control@bugs.debian.org mit folgendem Inhalt, wobei nnnnnn für die Fehlernummer steht

tags nnnnnn patch
thanks

Einen Sponsor finden

Im Regelfall sollte das Anhängen des Patches an den Fehlerbericht mehr als ausreichend sein. Es besteht jedoch auch die Möglichkeit das Paket direkt zu mentors.debian.net hochzuladen, wo ihr Hilfe von Debianentwicklern erhalten könnt. Vorher müsst ihr noch wissen, wie man Debianpakete aus den Quellen baut, was auch zum Testen des Patches nützlich ist.
Habt ihr einen Account bei den Mentoren erstellt und seid ihr den Regeln für einen Non-Maintainer-Upload gefolgt, sind die Aussichten gut dort jemanden zu finden, der das gepatchte Paket in das Archiv hochladen kann. Vorausgesetzt natürlich, es löst tatsächlich das Problem.

Lesenswerte und inspirierende Links

Ein Blick in den Abgrund

Ein ziemlich Aufmerksamkeit erheischender Titel, jedoch stammt er nicht von mir, sondern aus Benjamin Ottes Blog und wurde dort als "staring into the abyss" veröffentlicht. Anhand der Kommentare zum Artikel kann man erkennen, dass der Beitrag sicherlich durch einige prominente Newsseiten gewandert ist. Beinahe typisch für mich, stieß ich beim Durchstöbern der verwaisten Debianpakete auf ein Programm namens Byzanz, das eben von jenem Benjamin Otte entwickelt worden ist.
Schon wenig später entdeckte ich bei der Suche nach Informationen hierzu diesen Blogeintrag, der mich ein wenig zum Nachdenken brachte.
Das ist nicht der typische "Ich-sehe-alles-Schwarz-Post" irgendeines Bloggers, sondern er kommt immerhin von einem der Core-Entwickler von Gnome. Er kritisiert zum einen, dass Gnome unterbesetzt sei und hauptsächlich durch Entwickler von Red Hat getragen werde. Seine wichtigsten Kritikpunkte sind aber, dass es dem gesamten Gnome-Projekt an einem Ziel oder einer Vision mangele und dass wichtige Distributionen oder Anwendungen sich von Gnome abwenden oder abspalten (Unity und Cinnamon) anstatt mit Gnome zusammenzuarbeiten.
Mein Highlight aus diesem Post war jedoch die Aussage, dass Benjamin Otte der einzige Vollzeit-Entwickler für GTK ist. Also immerhin die Bibliothek, die für die Darstellung aller Anwendungen bei Gnome, Cinnamon und Unity verantwortlich ist.
In Zahlen: 1
Aber genau diese Tatsache, dass GTK ein Teil von Gnome ist und andere Projekte trägt, geht in seinem Post auch ein wenig unter. Wann ist der Punkt erreicht, wenn andere Projekte hier aushelfen werden und wie viele Freiwillige leisten zwar nur einen kleinen, jedoch entscheidenden Beitrag.
Der Artikel sollte auf jeden Fall aufrütteln und auch ein wenig Dampf ablassen. Man kann nicht bestreiten, dass seit der Veröffentlichung von Gnome 3 ein Bruch im ohnehin winzigen Markt des Linuxdesktops eingetreten ist. Wie können wir es uns eigentlich bei einer so kleinen Community leisten mit Gnome 3, KDE, Xfce, LXDE, Cinnamon und Unity sechs verschiedene Desktopumgebungen anzubieten? MATE und über vierzig verschiedene Fenstermanager nicht mitgezählt.
Fakt ist auch, dass man Vollzeit-Entwickler bezahlen muss, wenn man qualitativ hochwertige Software unterhalten möchte. Freie Software ist nicht kostenlos. Es macht einen Unterschied, ob ich den zwanzigsten Musikplayer oder grundlegende Systembibliotheken zu Standardanwendungen entwickle.
Ich denke, wir tun uns keinen Gefallen, wenn wir versuchen jedes Benutzerszenario immer und überall erfüllen zu wollen. Jedoch glaube ich auch fest daran, dass sich das System von selbst reguliert. Sowohl Ubuntu als auch Linux Mint profitieren von Gnome-Technologien. Sollte also Gnome eines fernen Tages abgewickelt werden, stehen besagte Distributionen ziemlich im Regen. Ist das ein realistisches Szenario? Eher nein.
Auch im September 2012 hat sich bei Debian nicht viel geändert. Spannend bleibt höchstens ob Gnome 3.4 oder Xfce der neue Standarddesktop wird. Es gab aber schon größere Probleme.
Cinnamon wartet immer noch auf seine Aufnahme. Von MATE ist weit und breit nichts zu sehen. Möglicherweise wird aber Fedora 18 MATE in die Distribution aufnehmen.
Ein Blick in den Abgrund, Gnome 3 strauchelt. Möglicherweise ist es jedoch gar nicht so schlimm, es verfehlt die spitzen Speere und wird von DWM gefressen. 😈

Wbar 2.3.1 mit lxde-icon-theme und fonts-liberation

Ich bin einen großen Schritt weitergekommen und das Einzige was mich davon abhält, Wbar einem Sponsor für Debian anzutragen, ist die fehlende Veröffentlichung von Version 2.3.2. Zur Zeit sind die Veränderungen nur in Subversion sichtbar, aber zum ersten Mal seit drei Jahren sind Code und Inhalt wieder mit Debians Gesellschaftsvertrag kompatibel.
Das Problem mit den Icons habe ich durch das Empfehlen des Pakets lxde-icon-theme gelöst. Als Standardschrift verwende ich fonts-liberation. Sowohl Icons als auch Schrift lassen sich beliebig ersetzen.
Zwar hatte ich in der Zwischenzeit herausgefunden, dass viele der alten Pixmaps unter der GPL2-Lizenz standen, dennoch war es einfacher und langfristig wohl auch sinnvoller sich unabhängig von einem spezifischen Set von Icons zu machen.
Wbar 2.3.1
Die Leiste macht einen guten Eindruck unter Lubuntu und Wbar ist generell eine gute Alternative für Fenstermanger. Nur bei älteren Rechnern wie dem Toshiba Portégé 3110CT, sollte man damit rechnen, dass die CPU bei der Animation der Icons ins Schwitzen gerät. Meist hilft hier aber schon eine geringere Auflösung bei den verwendeten Symbolen.
Einen Downloadlink gibt es weiterhin im alten Beitrag zur Entwicklung von WBar.