Xarchiver 1:0.5.2+20130119+dfsg-1 oder warum es (noch) keinen XZ-Support gibt

So, ich habe fertig. Nachdem ja nun MediathekView 3.1.0 schon seit zwei Wochen in Debian Unstable ist, kann ich nun auch vermelden, dass es Xarchiver in die sogenannte NEW-Warteschlange geschafft hat und somit auf dem Sprung ist nach Debian Unstable zu kommen. Dazwischen gab es noch einige weitere Erfolge zu vermelden, aber der Reihe nach.

Debianer hatte mich irgendwann so weit gebracht, dass ich Lust hatte mir Xarchiver näher anzuschauen und zuerst ein Paket mit geringen Änderungen, aber dem wichtigen Bugfix für den „7z-Crash“ erstellt hatte. Nur wenige Stunden später hatte ich auf der Mailingliste „debian-mentors“ einen Sponsor gefunden. (was leider nicht immer so schnell geht).

Es dauerte jedoch noch einen weiteren Monat und bedurfte einer weiteren E-Mail an das Debian-MIA-Team bis Xarchiver freigegeben wurde und ich es „adoptieren“ durfte. Frisch ans Werk gemacht und mir die Bugs angeschaut, die ich in diesem Artikel schon näher vorgestellt hatte.

Die gute Nachricht ist, dass das Paket nun „lintian clean“ ist, ein etwas geekiger Begriff, den man nur wirklich kennen muss, wenn man Pakete in das offizielle Archiv hochladen will. Da er sich auf das Innere eines Pakets bezieht, bekommt man als normaler Benutzer von einem nicht debiankonformen Paket selten direkt etwas mit. Die wichtigste Verbesserung in dieser Hinsicht: Das Paket ist nun gehärtet, was es einem Angreifer deutlich schwerer macht bestimmte Schwachstellen von C-Programmen auszunutzen.

Mehr ins Auge fallen dann Veränderungen wie diese hier:

Von links nach rechts: Anstatt eines leeren Flecks gibts nun wieder ein HTML-Symbol. Das alte musste entfernt werden, weil es angeblich unfrei war. Da mir der leere Fleck nicht gefiel, habe ich ein Symbol aus einem freiem Icon-Thema genommen und einfach eingebaut. Die Antwort auf die Frage, woher das Ding nun kommt, findet sich im Changelog.

Xarchiver ist von xfce.org nach sourceforge.net umgezogen. Der Link im zweiten Bild macht das deutlich.

Nr. 3: Der Autor von Xarchiver wollte Sponsoren eine Möglichkeit einräumen bei getaner Spende in Xarchiver mit einem Link verewigt zu werden. Dazu kam es scheinbar nie und der Spenden-Link blieb leer. Ich habe mir einen Patch von Fedora gekrallt und das verwaiste Menü herausgepatcht und durch einen simplen Menüpunkt „Donate“ ersetzt. Den habe ich noch so angepasst, dass er auch tatsächlich auf die neue Internetpräsenz führt und siehe da, so siehts nun aus. Durch einen Klick kommt man nun tatsächlich auf die Seite, wo man mit Geld oder Progammierleistungen das Projekt wieder ankurbeln kann.

Ok, das waren nun nicht die Änderungen, für die man tief in den Dukatenbeutel greifen würde. Interessanter, jedoch ebenso unsichtbar, ist die Neuerung, dass nun alle Arten von Tar-Archiven sich öffnen lassen, also auch Archive, die nicht im UStar-Format erstellt worden sind. Toll. Das wird den allerwenigsten je auffallen, da Debian nur Tar-Archive in UStar produziert.

Womit wir bei Patch Nr. 5 wären, (ja richtig, für jedes Problem, ein Patch 😉 ). Xarchiver hat Probleme mit Dateien oder Verzeichnissen, die Leerzeichen im Namen tragen. Siehe auch #697493 Im Grunde genommen hatte der Autor alles richtig gemacht, jedoch an zwei Stellen die gleiche Überprüfung auf Sonderzeichen gemacht, weswegen sich das dann praktisch ins Gegenteil verkehrt hatte.

Normalerweise würde ich sagen, wer Dateien mit Leerzeichen anlegt, verdient es nicht besser, aber natürlich kann ich so etwas nicht in einen Fehlerbericht schreiben. 😛

Spaß beiseite, das war natürlich ein berechtigter Fehlerbericht und ich hoffe mit der neuen Version ist das nun behoben. Der Patch dazu stammte übrigens vom OpenSuSe-Projekt.

XZ-Support hat es leider nicht in die nächste Veröffentlichung geschafft, weil der kursierende Patch meiner Meinung nach noch viel zu buggy ist. Da war der nächste berechtigte Fehlerbericht schon vorprogrammiert. Ich hatte zwar die Möglichkeit Dateien in Xarchiver umzubenennen oder zu löschen herausgepatcht, jedoch waren diverse Optionen für die Kommandozeile auch noch nicht fit für XZ, weswegen ich es dann erst einmal aufgegeben habe.

Das ist der momentane Patch. Verbesserungen erwünscht!: add-xz-support.patch

Ich vermute, dass Xarchiver noch ein paar Wochen in der Warteschlange verbringen wird, worin es überhaupt nur gelandet ist, weil ich mich dafür entschieden habe ein Debug-Paket bereit zu stellen. Da die Entwicklung von Xarchiver ziemlich eingeschlafen ist, kann es gut sein, dass ich dieses Paket in Zukunft zur Fehlersuche noch öfter brauchen werde.

Wenn du nicht bloggst, was machst du dann?

Dann arbeite ich z.B. an einem Debianpaket. Ich habe in den vergangenen drei Monaten großen Spaß daran gefunden mich noch detaillierter mit Paketbau zu beschäftigen und das ein oder andere Debianpaket wieder in Schuss zu bringen. Darunter hat kurzfristig sichtbar der Ausstoß an Blogartikeln gelitten, langfristig, so hoffe ich zumindest, wird das jedoch dazu führen, dass ich neue und alte Software (wieder)entdecke und sie hier vorstelle, ein paar Kniffe weitergebe und ich mir und allen dir hier immer wieder vorbeischaun neue Einblicke zu Debian und Freier Software im Allgemeinen bieten kann.

So viel zum Plan. Wer genauer wissen möchte, mit welchen Paketen ich mich in der letzten Zeit näher beschäftigt habe, darf gerne einen Blick auf meine QA-Seite bei Debian werfen, wo es eine Übersicht gibt, welche Pakete schon nach Debian hochgeladen worden sind und welche es hoffentlich irgendwann noch werden.

Meine Paketübersicht

Nachdem ich beschlossen hatte mich an MediathekView zu versuchen, ging es direkt danach weiter mit Wbar. In der Zwischenzeit erhielt ich schon die erste Supportanfrage, ob ich MediathekView auf einem Mac wieder zum Laufen bekommen könnte. Verwechselt dieses Blog bitte nicht mit der offiziellen Homepage von MediathekView und mich nicht mit dem eigentlichen Entwickler von MediathekView. Ich friemel wirklich nur an dem Paket für Debian. 🙂

Letzte Woche erhielt ich dann die freundliche Anfrage, ob ich Interesse daran hätte Maintainer für Wbar bei Siduction zu sein. Das ist die Distribution, die ein fortlaufend aktuelles Debian auf Basis von Sid anbietet und viele Mitglieder aus dem deutschsprachigen Bereich hat. Ich bin mir zwar nicht sicher, was es bedeutet Paketbetreuer bei Siduction zu sein, aber so lange Wbar 2.3.4. noch nicht offiziell bei Debian im Archiv gelandet ist, geht das sicher in Ordnung.

Ansonsten habe ich mir folgende Ziele gesetzt. Ich möchte nicht blindlings Pakete betreuen, sondern vornehmlich diejenigen, über die ich auch in diesem Blog schreibe, also ressourcenschonende Software und alles was ich selbst hier benutze und natürlich auch Spiele. Für letztere bin ich dem Debian Games Team beigetreten und versuche mich dort nun längerfristig einzubringen. Ob mir das tatsächlich gelingt, sehen wir dann in ein paar Monaten. 😉

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.