Tag: Entwicklung

Posted on

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.

Posted on

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

Posted on

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.

Posted on

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.

Posted on

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.

Posted on

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

Posted on

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.

Posted on

Reprepro: Das eigene Paketarchiv für Debian und Ubuntu

Archivbild von Politikaner Wikipedia.org
Ich bin in den letzten Wochen zum ersten Mal mit der Situation konfrontiert worden, ein Repositorium für meine eigenen Debianpakete erstellen zu wollen. Davor beschränkten sich meine Experimente z.B. auf das Erstellen eines Backports für den DWM-Fenstermanager oder ein schnell gebasteltes Paket für den Cube-Server-Lister. Mit Reprepro existiert die Möglichkeit ein eigenes Paketarchiv für Deb-Pakete aufzusetzen und sie lokal mit Hilfe von Apt zu installieren oder Freunden, Testern, der Firma oder schlicht der ganzen Welt zur Verfügung zu stellen. Und das geht so.

Vorbedingungen

Ihr benötigt:

  1. Einen gültigen GPG-Schlüssel
  2. Eigene Deb-Pakete
  3. Reprepro
  4. Einen Web- oder FTP-Server

Ein gültiger GPG-Schlüssel

Führt das folgende Kommando aus:
gpg --gen-key
Die folgenden Dialoge sind selbsterklärend und die Voreinstellungen sinnvoll. Wählt den RSA-Schlüssel (1) und mindestens 2048bit Schlüssellänge.
Die ID eures öffentlichen Schlüssels (pub) erfahrt ihr mit
gpg --list-keys
In meinem Fall wäre das 475C34B9. Mit dem GPG-Schlüssel werden später die Deb-Pakete und das Reprepro-Archiv signiert, so dass ihr anhand der Signatur die Authentizität der heruntergeladenen Pakete erkennen könnt. Damit jemand anders dies auf dem eigenen Rechner überprüfen kann, muss der öffentliche Schlüssel in den Schlüsselring von Debian oder Ubuntu importiert werden.
gpg --output gambaru_archiv.asc --armor --export 475C34B9
Mit diesem Befehl wird der öffentliche Schlüssel im ASCII-Format in die Datei gambaru_archiv.asc exportiert.
wget https://www.gambaru.de/blog/wp-content/uploads/2012/09/gambaru_archiv.asc
Nach dem Herunterladen wird er mit
sudo apt-key add gambaru_archiv.asc
in den Schlüsselring importiert und
sudo apt-key list
verrät, ob er tatsächlich im Schlüsselring angekommen ist.

Eigene Deb-Pakete

Dieser Abschnitt könnte leicht Bücherwände füllen. Für den Anfang tun es aber auch "Wie man Debian-Pakete aus den Quellen baut" oder ihr schaut euch am besten Pbuilder an, womit sich Pakete in einer "Reinraumumgebung" für unterschiedliche Architekturen und sowohl für Ubuntu und Debian bauen lassen und das vollkommen unabhängig von eurer Ubuntuversion. Es lohnt sich das Pbuilder-Howto auf ubuntu.com zu studieren.
Die fertigen Pakete können auch nachträglich mit
debsign Paketname.changes
debsign Paketname.dsc
dpkg-sig --sign builder mediathekview_3.0.0-1_all.deb
signiert werden.

Reprepro

Reprepro ist ein Werkzeug, mit dem sich ein eigenes lokales Repository anlegen lässt, das dem offiziellen Debian Archive Kit in kaum einer Beziehung nachsteht. Es gibt weitere Alternativen, jedoch überzeugt mich Reprepro nicht nur durch seinen großen Funktionsumfang, sondern es kommt auch ohne Datenbankserver aus und lässt sich schnell einrichten. Das Handbuch von Reprepro sowie man reprepro helfen bei der Inbetriebnahme weiter.

Schritt 1:

Zuerst muss ein beliebiges Basisverzeichnis angelegt werden.
mkdir -p ~/reprepro/debian
Im Debian-Verzeichnis wird danach ein Unterordner namens conf angelegt und in diesem die Dateien distributions und options.

Schritt 2:

Der Inhalt von distributions.

Origin: gambaru.de
Codename: experimental
Architectures: i386 amd64 source
Components: main
Description: Private Debian-Pakete von http://gambaru.de
SignWith: yes
Origin: gambaru.de
Codename: wheezy
Architectures: i386 amd64 source
Components: main
Description: Private Debian-Pakete von http://gambaru.de
SignWith: yes

Diese Datei ist als einzige wirklich notwendig. In ihr werden die Distributionen definiert, für die die selbsterstellten Pakete gedacht sind. Ich habe sowohl eine für Experimental als auch Wheezy angelegt. Für Ubuntu lässt sich Wheezy auch durch Precise oder Quantal ersetzen oder ihr könnt euch einen komplett eigenen Codenamen ausdenken. Tatsächlich benötigt ihr nur die Felder Codename, Components und Architecture. Meine Pakete sind DFSG-frei und landen deswegen in Main. Ich stelle sie für die Architekturen i386 und amd64 und natürlich als Quellpakete zur Verfügung. Die Option SignWith: yes führt dazu, dass das gesamte Archiv mit dem zuerst gefundenen GPG-Schlüssel signiert wird. Anstelle von yes kann hier auch die Key-ID stehen.
Der Inhalt der Datei options.

verbose
ask-passphrase

Wenn diese Datei existiert wird jede Zeile als zusätzliches Argument beim Aufruf von Reprepro übergeben, wobei Parameter, die manuell per Kommandozeile übergeben werden, Vorrang genießen. Verbose sorgt für gesprächigere Statusmeldungen und bei ask-passphrase erwartet Reprepro die Eingabe des Passworts für den GPG-Schlüssel, um das Archiv zu signieren.
Nur der Vollständigkeit halber: Es existieren noch die Konfigurationsdateien updates, pulls und incoming, die man für weitergehende Studien im Hinterkopf behalten sollte, hier aber nicht gebraucht werden.

Beispiele

Fügt das Paket mediathekview_3.0.0-1_all.deb dem Archiv experimental hinzu, welches sich im Basisverzeichnis ~/reprepro/debian befindet.
reprepro -b ~/reprepro/debian includedeb experimental /var/cache/pbuilder/sid-amd64/result/mediathekview_3.0.0-1_all.deb
Fügt das Quellpaket mediathekview_3.0.0-1.dsc dem Archiv experimental hinzu, welches sich im Basisverzeichnis ~/reprepro/debian befindet.
reprepro -b ~/reprepro/debian includedsc experimental /var/cache/pbuilder/sid-amd64/result/mediathekview_3.0.0-1.dsc
Allgemein:
reprepro -b [Basisverzeichnis] includedeb|includedsc ARCHIV [Pfad zum Deb-Paket]
Die Eingabe des Basisverzeichnisses kann man weglassen, wenn man eine Umgebungsvariable exportiert oder die nachfolgende Zeile in seine .zshrc einträgt. Z.B.
export REPREPRO_BASE_DIR='/home/apo/reprepro/debian'
Danach lassen sich Pakete mit
reprepro includeb experimental Mein-Paket.deb
von überall hinzufügen.
Entfernen lassen sich Pakete aus dem Archiv mit:
reprepro remove experimental Mein-Paket
Und mehr müsst ihr nicht wissen. Ein Tipp noch am Rande: Damit ihr das GPG-Passwort nicht permanent neu eingeben müsst, solltet ihr Programme wie Gnome-Keyring oder Keychain und gnupg-agent installiert haben, womit das Passwort zwischengespeichert wird.

Das eigene Deb-Archiv lokal verfügbar machen

Am einfachsten ist es nun auf das lokal erstellte Paketarchiv zuzugreifen, wozu lediglich diese Einträge der /etc/apt/sources.list hinzugefügt werden müssen.

deb file:///home/apo/reprepro/debian/ experimental main
deb-src file:///home/apo/reprepro/debian/ experimental main

Zur Sicherheit solltet ihr die Pin-Priorität dieser Pakete absenken, indem ihr einen Eintrag zur Datei /etc/apt/preferences hinzufügt. Im Regelfall muss sie zuerst angelegt werden. Mit ihr lässt sich präzise das Mischen von mehreren Paketquellen steuern. (Stichwort Apt-Pinning, siehe auch man apt_preferences.)

Package: *
Pin: release o=gambaru.de
Pin-Priority: 1

Da es sich bei meinen Paketen um experimentelle Pakete handelt, ist es am besten die Priorität auf 1, einen sehr niedrigen Wert, zu setzen. Ihr könnt das Ergebnis vorher und nachher mit
apt-cache policy
überprüfen.
Danach genügt wie immer
aptitude update
aptitude -t experimental mediathekview
um das eigene Paket via Apt mit allen Abhängigkeiten zu installieren.

Reprepro: Repository weltweit freigeben

Mit Hilfe eines Web- oder FTP-Servers lässt sich das eigene Archiv auch weltweit und nicht nur lokal verteilen. Die Konfiguration eines Webservers wie Lighttpd war mir schon einen eigenen Beitrag wert. Reprepro funktioniert natürlich auch mit Nginx und Apache.
Ich habe mich jedoch für einen FTP-Server entschieden. Hierzu benutze ich vsftpd. Die Anleitung für die Konfiguration im Zusammenspiel mit OpenArena lässt sich ganz einfach auch auf Reprepro übertragen.
In diesem Fall betreibt ihr den FTP-Server ausschließlich anonym ohne Schreibrechte. Ich habe den kompletten Debian-Ordner des Basisverzeichnisses von Reprepro mittels SCP hochgeladen und die Unterordner db und conf aus Sicherheitsgründen entfernt. Um die Paketquellen von gambaru.de einzubinden, müsstet ihr folgendes in der /etc/apt/sources.list eintragen und den gambaru_archiv-Schlüssel eurem Schlüsselring hinzugefügt haben.

deb ftp://46.182.19.209/debian experimental main
deb-src ftp://46.182.19.209/debian experimental main

Fazit

PPAs waren gestern, heute baut man sich sein eigenes Paketarchiv. 😉 Es gibt noch viele weitere Optionen von Reprepro zu entdecken. Unter anderem ist die automatische Verarbeitung von "incoming queues" möglich und das Spiegeln des kompletten Debian- und Ubuntu-Archivs! Wenn ihr häufig Deb-Pakete herunterladet und Bandbreite sparen wollt, hilft eventuell auch Apt-Cacher-NG, ein Proxy-Server, weiter.
Jeder, der bis hierhin gelesen hat, hat sich automatisch als Tester für zwei Pakete qualifiziert, an denen ich gerade arbeite und hoffe sie als Paketverwalter weiterpflegen zu dürfen. Bitte Bugs direkt hier oder in den alten Posts zu Mediathekview und Wbar melden. 🙂

Posted on

Wbar: Wie nennt man eine Schnellstartleiste ohne Icons?

Es kann ziemlich viel Spaß machen für ein Debianpaket selbst verantwortlich zu sein. Fairerweise muss ich dazu sagen, dass Wbar nicht das komplexeste Paket ist und es da noch ein paar Steigerungsmöglichkeiten gibt bis man schließlich Paketverwalter des Apache- oder X-Servers ist oder gar das Linuxkernel-Paket betreut.
Nachdem ich damit begonnen hatte ein aktuelles Paket für Wbar auf Basis der Version 2.3.0 aus dem SVN-Repo zu bauen, schrieb ich ein paar Patches, die ein paar Rechtschreib- und Grammatikfehler und den Originalautor korrigierten, die Desktop-Datei modifizierten und die standardmäßige Symbolgröße auf 64 erhöhten. Schon zwei Tage später hatte Rodolfo Granata alle Patches berücksichtigt und eine neue Version 2.3.1 veröffentlicht, die nun keine unfreien Symbole mehr enthält.
Leider enthielt diese Version nun gar keine Icons mehr, was mich vor ein Problem stellte. Wie sollte ich eine Schnellstartleiste ohne Icons als "cool eye-candy" vermarkten? 😯
Debian besitzt einige Pakete, die ausschließlich aus Icons bestehen und die Themen für Desktopumgebungen wie LXDE, Gnome und KDE liefern. Der alte Paketverwalter von Wbar hatte noch auf die gnome-extra-icons zurückgegriffen. Diese sehen aber nach mehr als 10 Jahren im Archiv etwas altbacken aus. Außerdem liegen sie nur in einer geringen Auflösung vor, wodurch man beim Skalieren jeden Pixel sehen kann.
Danach habe ich mir noch kde-icons-crystal, kde-icons-nuvola und schließlich gnome-colors-common angesehen. Dabei fiel mir auf, dass in diesem Paket nahezu alle Icons aus der alten Wbar-Version 2.3.0 enthalten waren. Hier kamen sie also her.
Ich denke es war richtig die Icons zuvor zu entfernen, solange man ihre Lizenz nicht kennt. Da ich nun weiß, dass sie alle unter der GPL2 verfügbar sind, die gleiche Lizenz, die übrigens auch Wbar benutzt, sollte die Aufnahme in das Paket kein Problem darstellen. Ich dachte auch zuerst daran es einfach beim Installieren zu empfehlen, jedoch liegen die hochauflösenden Symbole als SVG-Dateien vor, die Wbar nicht darstellen kann.
Im Prinzip muss ich also jetzt die Copyright-Datei von Debian auf den neusten Stand bringen und die Autoren von gnome-colors-common ordentlich darin aufführen. Als Schrift werde ich fonts-liberation empfehlen, womit Wbar aus dem Stand funktionieren sollte.
Persönlich könnte ich auch ohne vorinstallierte Icons leben, denn mit wbar-config geht das Hinzufügen neuer Symbole im Handumdrehen. Auf der anderen Seite ist der erste Eindruck entscheidend und erfahrene Anwender installieren Wbar sowieso mit
aptitude install wbar -R
Jetzt muss ich nur noch den Entwickler überzeugen die alten Icons wieder in Wbar aufzunehmen. 🙄
P.S.: Ich warte immer noch darauf, dass jemand den ITP für das faenza-icon-theme durchzieht. Also wer sich berufen fühlt... 😉

Posted on

Wbar: Bericht von der Entwicklung einer neuen Debian-Version der leichten Schnellstartleiste

Irgendwie hat mich in den letzten Wochen die Lust am Paketeerstellen für Debian gepackt. Während MediathekView gut vorankommt und ich noch auf das Feedback eines Debianentwicklers warte, der sich das Paket gerade ansieht, sitze ich hier an Version 2.3.0. der "Warlock Bar", auch kurz Wbar genannt.
Die Frage, die man sich nicht nur bei Debian manchmal stellt: "Wie findet man den richtigen Einstieg?". Ich wendete mich schnell der FAQ der Debian-Mentoren zu. Entgegen allen Gerüchten ist Debian gar kein ganz so elitärer Haufen, der sich gerne gegenüber der Außenwelt abschottet. Für Newbies im Paketeerstellen gibt es Freiwillige, die sich den Fragen angehender Paketverwalter stellen, sei es auf der Mailingliste debian-mentors oder im gleichnamigen IRC-Channel #debian-mentors im OFTC.net.
Von dort gelangte ich auf die Übersichtsseite der Arbeit-bedürfenden und voraussichtlichen Pakete, in Englisch kurz wnpp genannt.
Schnell sieht man hier, dass ca. 600 Pakete auf einen Nachfolger als Paketverwalter warten und die Mehrzahl davon sogar verwaist ist. Hier kümmert sich außer dem QA-Team niemand mehr darum. Irgendwann blieb mein Blick dann an wbar kleben, da mir der Name bekannt vorkam. Im Jahr 2009 bin ich zum ersten Mal auf diese leichtgewichtige Anwendung gestoßen und habe sie dann 2010 als Schnellstartleiste für Fluxbox auf dem Toshiba Portégé 3110CT installiert.
Wieder zwei Jahre später schließt sich der Kreis. Denn genau diese Version, die ich damals benutzt habe, ist auch heute noch die aktuellste. Leider. Zum einen gab es erst wieder 2011 ein paar Neuerungen des neuen Entwicklers zu vermelden, der das Projekt übernommen hatte und schließlich fehlte dem Paketverwalter die Zeit, um das Paket weiter zu betreuen. Wir schreiben Juni 2012 und wbar wird als "verwaist" markiert.
Also dachte ich, wäre es eine coole Idee ein leichtgewichtiges Programm zu betreuen, dass immer noch auf einem der älteren Laptops läuft, aber von niemandem mehr gewartet wird!

Wbar 2.3.0 - Neuigkeiten aus dem Changelog

Da Details zur Paketerstellung erfahrungsgemäß keine Begeisterungsstürme unter den Lesern dieses Blogs entfachen, fasse ich mich kurz, verweise auf das Changelog im Quellpaket, dass ich gleich verlinke und lasse später einfach Bilder sprechen.

  1. Es gibt eine neue Veröffentlichung! Version 2.3.0 ausgecheckt aus dem Subversion-Repo am 16.08.2012 ist meine aktuelle Arbeitsversion.
  2. Die Konfiguration findet nun ordnungsgemäß global unter /etc statt und nicht mehr unter /usr/share/wbar. Die Bearbeitung von ~/.wbar ist weiterhin für den lokalen Benutzer möglich.
  3. Es gibt ein neues grafisches Programm namens wbar-config, das die Konfiguration und Gestaltung von wbar sehr vereinfacht, aber vollkommen optional ist.
  4. Das Paket wird mit LDFLAGS=Wl, --as-needed gebaut, wodurch überflüssige Abhängigkeiten wegfallen, was sicher nicht nur Fans von leichtgewichtigen Desktops freuen dürfte.
  5. Das Paket ist gehärtet.
  6. Alle empfohlenen Abhängigkeiten sind jetzt nur noch vorgeschlagen. Auch das hält den Rechner schlank. Ob es dabei bleibt, hängt aber von einer Lizenzfrage ab.
  7. Des Weiteren habe ich noch einige Tippfehler und Sprachunebenheiten ausgebessert (und mich dabei hoffentlich nicht selbst in die Nesseln gesetzt *schluck*).

Offene Baustellen sind momentan keine technischen Probleme, sondern ausschließlich Lizenzfragen. Aufmerksamen Menschen fällt der Zusatz "+dfsg2" am offiziellen Debianpaket auf. Das bedeutet, dass das Quellpaket der Entwickler schon zwei Mal "umgepackt" werden musste, um den Richtlinien für Debian und für Freie Software zu genügen. Konkret geht es darum, dass damals offensichtlich Icons aus dem bekannten MacOS-Dock für Wbar benutzt worden sind. Da diese aber unfrei sind, können sie mit Debian nicht vertrieben werden.
Ich stehe nun vor ähnlichen Problem. Zum einen liegt dem Quellpaket eine COPYRIGHT-Datei bei, worin die GPL-3-Lizenz enthalten ist. Die Projektseite genauso wie das alte Paket stellen jedoch klar, dass der Code unter GPL-2 steht. Im Prinzip kein Problem, da es maximal zwei Entwickler gibt, die frei entscheiden können, ob sie neuere Versionen nun unter GPL-3 oder weiterhin GPL-2 verfügbar machen. Welche von beiden es aber ist bleibt unklar.
Die zweite Sache sind die Icons. Das alte Verzeichnis mit den "Mac"-Icons gibt es mittlerweile nur noch im SVN. Neu hinzugekommen sind die Icons im "pixmaps"-Ordner. Eine gute Gelegenheit mal ein Bildschirmfoto von der aktuellen wbar-Version zu zeigen, so wie sie auf meinem angepassten Lubuntu läuft.
wbar 2.3.0
Mal von links nach rechts betrachtet: Das erste Symbol ist für wbar-config gedacht und ich ordne es optimistischerweise den Entwicklern zu. Dann kommt Pidgin und Anjuta. Anjuta steht unter der GPL-2, Pidgin ist ebenfalls ein freies Programm. Das nächste Symbol sieht lustig aus, ist aber nicht das offizielle Logo von Bluefish, dem Editor. Woher kommt es? Ok, den Gimp hat sicherlich jeder erkannt. OpenOffice, oha. "Bitte beachten Sie, dass das Logo nicht unter einer freien Lizenz steht. Und zum Schluss stehen da noch Synaptic und ein typisches Terminal-Symbol. Keine Ahnung, wer sie erstellt hat.
Also wenn es gut läuft, kann ich bis auf zwei Symbole alle zuordnen und die passende Lizenz finden und den ursprünglichen Rechteinhaber ausfindig machen. Da die Entwickler aber jederzeit diese Symbole auch wieder ersetzen können, fahre ich fast besser damit, einfach wieder das Paket gnome-extra-icons zu empfehlen, dass nachweislich nur freie Symbole enthält.
Beim Schreiben des Artikels ist mir dieser alte Screenshot von 2009 aufgefallen. Hier sieht man noch die Version von Wbar mit den unfreien Symbolen, bevor diese vom damaligen Paketverwalter entfernt worden sind. Das ist übrigens Fluxbox und Conky.


Das zweite Bild zeigt wiederum die aktuellen Symbole in der Version 1.3.3 von Wbar.

Fluxbox und Wbar
Ich habe die Entwickler angeschrieben und bin mal gespannt, ob es eine Antwort geben wird. Wie gesagt, es gibt Alternativen bei dem Lizenzproblem und technisch scheint das Paket gut zu funktionieren. Wer es ausprobieren will....ihr kennt den Spruch.
Update 28.09.2012:
- Neue Version 2.3.4 online
Update 10.01.2013
Ein offizieller Upload scheint nicht mehr weit entfernt. Die Downloadlinks werden deshalb in nächster Zeit ins Leere führen. Bitte benutzt dann die offizielle Version.

Quellpaket 2.3.4

dget -x ftp://46.182.19.209/debian/pool/main/w/wbar/wbar_2.3.4-1.dsc

Binärpaket wbar-2.3.4

i386
wget ftp://46.182.19.209/debian/pool/main/w/wbar/wbar_2.3.4-1_i386.deb
amd64
wget ftp://46.182.19.209/debian/pool/main/w/wbar/wbar_2.3.4-1_amd64.deb

Binärpaket wbar-config-2.3.4

i386
wget ftp://46.182.19.209/debian/pool/main/w/wbar/wbar-config_2.3.4-1_i386.deb
amd64
wget ftp://46.182.19.209/debian/pool/main/w/wbar/wbar-config_2.3.4-1_amd64.deb
Hier ist der aktuelle ITA-Bug von Wbar, #678865, der den aktuellen Stand dokumentiert.
Und noch ein erster Eindruck von wbar-config.

wbar-config 2.3.0
Die Rätselfrage wie gewohnt zum Schluss: Welche Schriftdatei ist standardmäßig in jeder Debianinstallation enthalten, damit ich von Wbar darauf verweisen kann, ohne Gefahr laufen zu müssen, dass sie doch nicht existiert? 😉