Softwarepakete konvertieren mit alien oder tazpkg

Ein Problem bei kleineren Distributionen ist häufig, dass sie aus Zeit- und Ressourcengründen nicht genauso viele Binärpakete wie größere Distributionen anbieten können. Neue Pakete mit Hilfe der distributionseigenen Werkzeuge zu kompilieren, ist die gängigste Methode um den Softwareumfang zu vergrößern.

Möchte man sich nicht erst in die eher fortgeschrittene Thematik einarbeiten, gibt es zumindest bei Debian und Slitaz eine Alternativmethode. Irgendwann kam jemand auf die Idee, dass es bei manchen Paketen nur notwendig ist die Struktur der integrierten Dateien anzupassen und das Paket einer fremden Distribution in das eigene Format umzuwandeln.

Ich wollte unbedingt mein favorisiertes Musikprogramm cmus auch mit Slitaz benutzen, weswegen ich mir die neueste Version aus Debian Sid heruntergeladen habe und mit Hilfe von tazpkg das Paket dann umgewandelt habe. Der Weg ist schnell erklärt.

  1. Cmus als .deb Paket manuell oder mit apt herunterladen
  2. tazpkg convert „Paketname“

Das war es auch schon. Danach beginnt der Paketmanager das Paket in das Slitaz-Format umzuwandeln. Man sollte zumindest eine einigermaßen schnelle Kiste besitzen. Der Thinkpad 600 ist dafür ausreichend, bei einem Toshiba Satellite 220cs mit nur 16 MB RAM kann sich der Vorgang auch schon mal ein paar Stunden hinziehen. 🙄

Debian und Aliens

Debian hat für diese Art von Aufgabe ein vergleichbares Programm namens alien, mit dem sich z.B. Slackware- oder RPM-Pakete in das Deb-Format überführen lassen.

alien --to-deb /Pfad/zu/meinem/Paket.rpm

Die Methode muss nicht zwangsläufig bei jedem Paket funktionieren. Bei kleineren hatte ich aber bisher immer Erfolg. Die „saubere“ Methode bleibt auch weiterhin ein Stück Software direkt aus den Quellen zu kompilieren. Aus diesem Grund gibt es ein solches Werkzeug bei Arch Linux erst gar nicht.

Auf der Suche nach den Käfern

In den letzten Tagen beschäftigten mich gleich zwei Bugs mit Debian Sid auf dem Inspiron 4000. Ein Nachteil einer topaktuellen Rolling-Release-Distribution sind von Zeit zu Zeit auftretende Regressionen. Was vor ein paar Stunden noch wunderbar funktionierte, stellt einem nach einem Systemupgrade nur noch vor Rätsel.

Ich war nicht ganz überrascht und hatte auch bewusst Unstable auf dem Laptop gewählt um Fehler zu finden.

Was war passiert? Nun ich wollte wie immer meine E-Mails mit Claws-Mail abrufen. Das Programm startete und begann auch die Konten abzufragen, doch als die POP3-Accounts dran waren, beendete es sich einfach lautlos und ohne Kommentar.

In so einer Situation ist es oft am besten, die Anwendung aus einem Terminalfenster heraus noch einmal neu zu starten und dabei Statusmeldungen oder ungewöhnliche Fehlermeldungen zu beobachten. Möchte man sich diese später noch einmal anschauen, kann man die Nachrichten auch von STDOUT in eine Datei umleiten, z.B.

claws-mail --debug > fehlerbericht.txt

Nach dem Crash sah ich folgendes:

claws-mail: /build/buildd-cairo_1.10.2-6.1-i386-UoYIV1/cairo-1.10.2/src/cairo-surface.c:1287: cairo_surface_set_device_offset: Assertion `status == CAIRO_STATUS_SUCCESS‘ failed.
Aborted

Bei einer Suche in Debians Fehlerdatenbank fand ich dann einen anderen Fehlerbericht, der mein Problem zu beschreiben schien. Mir fiel nur auf, dass wir beide POP3 mit SSL benutzten, weshalb ich auf die Idee kam und die Konfigurationsdatei von Claws-Mail in ~/.claws-mail/accountrc editierte und SSL für alle meine POP3-Accounts deaktivierte.

Tatsächlich startete Claws daraufhin wieder fehlerfrei und E-Mails ließen sich erneut empfangen und versenden.

Den zweiten Bug fand ich in meinem Webkit Browser Midori. Als ich HTTPS-Webseiten aufrufen wollte, beendete sich die Anwendung ebenfalls ohne Vorwarnung von selbst. Zwei verschiedene Fehler, die beide etwas mit SSL zu tun haben sollten? Das schien mehr als Zufall zu sein.

Um herauszufinden welches Paket sich hier quer gestellt hat, hilft oft ein Blick auf die Paketabhängigkeiten der betroffenen Programme. Als ich mir die Liste angeschaut und mit den erneuerten Paketen abgeglichen hatte, kam nur eine Bibliothek in Frage, die sowohl von Claws als auch von Midori benutzt wird – libgcrypt11. Welche Pakete durch ein Upgrade ersetzt wurden lässt sich übrigens nachträglich auch noch einmal in /var/log/aptitude nachlesen.

Lange Rede kurzer Sinn, ich machte nach einem Hinweis des Paketverwalters von Midori einen Downgrade von libgcrypt11. Am einfachsten geht das, indem man sich das Paket entweder manuell von der Debian Webseite herunterlädt oder wenn man wie ich noch ein Debian Testing hat, womit ein

aptitude download libgcrypt11 genügt.

Im Anschluss kopierte ich das Paket einfach auf den Laptop und installierte es mit dpkg -i. Tatsächlich lösten sich dadurch alle meine Probleme auf. Um nicht beim nächsten Upgrade erneut die neuere Version der Bibliothek herunterzuladen, kann man Debians Paketmanager dazu veranlassen, das Paket nicht mehr zu aktualisieren.

aptitude hold libgcrypt11

Im Moment scheinen meine Probleme damit gelöst zu sein. Die Frage bleibt aber, ob es tatsächlich nur an libgcrypt11 liegt. Die Eingangs erwähnte Fehlermeldung deutete z.B. auch auf libcairo2 hin.

Wie meldet man einen Bug bei Debian

Einen manuellen Fehlerbericht per E-Mail zu verschicken ist nur dann eine gute Idee, wenn man zu einem bestehenden Problem weitere Informationen liefern möchte. In allen anderen Fällen hat Debian schon ein Hilfsprogramm geschaffen, welches immer wiederkehrende Abläufe besser automatisiert.

Reportbug

Reportbug gibt es als Kommandozeilenprogramm und in einer GUI Version. Die Bedienung der Textversion ist simpel. Der Fehlerbericht muss aber in Englisch geschrieben werden, weswegen es auch keine deutsche Übersetzung dazu gibt.

Einen Fehler meldet man z.B. so:

reportbug midori

Danach wird die Fehlerdatenbank abgefragt und bestehende Fehlerberichte angezeigt. Befindet sich das Problem schon darunter, kann man durch Eingabe der entsprechenden Fehlernummer eine Ergänzung zu dem Bug schreiben. Ansonsten sind die Voreinstellungen sinnvoll. Man sollte lediglich dem Fehlerbericht einen aussagekräftigen Titel geben.

Wie man einen guten Fehlerbericht verfasst und viele weitere nützliche Informationen zum Thema Käfer finden, gibt es wie immer auf debian.org.

Paketerstellung mit Debian: Weitere nützliche Quellen

Es ist mitunter gar nicht so einfach den besten Weg zum Erstellen eines Debianpakets zu finden, da über die Jahre die Werkzeuge zur Paketerstellung immer ausgefeilter und zahlreicher in Debian geworden sind.

Wenn man aber sieht, dass tausende von Freiwilligen ihren Beitrag zu Debian und Ubuntu leisten, kann es nicht anders sein, als dass es Standards und Prozeduren gibt, um die Qualität des gesamten Projekts zu gewährleisten.

Lucas Nussbaum hat z.B. ein Packaging Tutorial erstellt, was eine gute Übersicht über den gesamten Paketerstellungsprozess bietet. Es lässt sich unter dem angegebenen Link direkt als PDF-Dokument herunterladen und befindet sich auch als Deb-Paket in Unstable.

aptitude install packaging-tutorial

Dort gibt es zusätzlich zu dem PDF-Dokument drei Praxisbeispiele aus dem Entwickleralltag, die sich Schritt für Schritt nachvollziehen lassen.

Vor ein paar Wochen hatte ich ein paar Methoden vorgestellt, wie man seine eigenen Debian Pakete erstellen kann. Nimmt man diesen Merkzettel, das Packaging Tutorial und folgt den Links zur offiziellen Dokumentation, sollte einer Karriere als Debianentwickler nichts mehr entgegen stehen.

Es kann sicher nichts schaden, deshalb hier noch einmal die Linkliste zur offiziellen Dokumentation.

Offizielle Dokumentation

Extras

Gutes Video Tutorial zum Paketbau in Deutsch (AdvPackaging.ogv)

Finde den besten WebKit-Browser oder programmiere ihn einfach in 20 Minuten selbst

Ich glaube Linux bietet bei kaum etwas anderem mehr Auswahl und Vielfalt als bei Webbrowsern. Spätestens seit Google das Chromium-Projekt gestartet hat, ist auch dem Letzten die zentrale Bedeutung, das wahre Herzstück, des modernen Desktops ins Bewusstsein gerückt worden. Jeder namhafte Hersteller von Betriebssystemen und Global Superplayer strebt heutzutage die Vorherrschaft im Kampf um den Webbrowser der Zukunft an …oder lässt nach einem Jahrzehnt zumindest alte Schrecklichkeiten endlich sterben. Vom Browserkrieg war gar schon oft die Rede.

Dabei sollte gerade in Bezug auf Webbrowser weniger das Kriegerische als das Verbindende hervorgehoben werden. Nehmen wir doch als Beispiel mal das WebKit-Projekt. Alles begann einmal als Weiterentwicklung eines anderen Open-Source-Projektes namens KHTML, was noch heute die Grundlage für Konqueror bildet, der wohl bekanntesten Applikation des KDE Desktops. Irgendwann hat dann Apple die Technologie verbessert und als WebKit-Engine zur Grundlage des eigenen Safari-Browsers gemacht. Andere bekannte Größen wie Nokia oder Google sprangen auf den gleichen Zug auf und so entwickelte letzteres Unternehmen schließlich den Chromium-Browser, der sich schnell als dritte Größe zwischen dem Internet Explorer und Firefox etablieren konnte.

Da behaupte noch einer es ginge immer nur gegeneinander. WebKit ist ein Paradebeispiel, warum Open Source und Freie Software so wichtig und auch so erfolgreich sein kann. Irgendwo beginnt eine Idee zu wachsen, ein anderer greift den Gedanken auf und verwirklicht ihn schließlich. Dank des offenen und frei verfügbaren Quellcodes gesellen sich immer weitere Akteure dazu und machen die Idee besser. Man hat ausdrücklich die Möglichkeit voneinander zu lernen und Wissen wird nicht wie in einer mittelalterlichen Gilde im Geheimen verborgen gehalten. Nur so gelingen Innovationen und Fortschritt schneller.

Wähle deinen Browser

Im letzten Post scherzte ich noch, dass rekonq der gefühlt 23. Webkit Browser sei. Ich lag damit gar nicht so falsch! Webkit.org listet auf der eigenen Webseite zumindest 22 auf Webkit basierende Browser auf, wobei rekonq in der Auflistung sogar fehlt. Doch bevor ich damit begann meine übersinnlichen Fähigkeiten zu preisen, fiel mir auf, dass zumindest sowohl xxxterm als auch uzbl in der Liste fehlten und wer weiß wie viele andere noch.

Die Auswahl bei WebKit-Browsern ist also verblüffend groß. Da ich gerne Browser auf älterer Hardware ausprobiere, befinden sich auf meinem Inspiron 4000 neben Iceweasel 5, Chromium 12, Opera 11.5 auch Midori und surf.

Die letzten beiden sind, wie sollte es auch anders sein, ebenfalls WebKit-Browser. Genauer gesagt basieren sie auf WebKit/GTK. Zwar ist der universelle Browser immer noch elinks für mich, aber es mag Zeiten geben, wo ich mir eine Webseite auch mal hübsch gerendert und mit etwas Javascript anschaue. Dabei leistet surf, entwickelt übrigens von suckless, das uns den großartigen Fenstermanager dwm bescherte , auf einer alten Kiste Erstaunliches.

Das ist surf. Nein, hier ist nichts versteckt oder irgendwelche Funktionen deaktiviert worden. Surf stellt nur die Webseite dar und kann auch Links folgen. Keine Werkzeugleisten, Lesezeichen und Addons. Surf konzentriert sich nur auf das Wesentliche – Browsen. Die Darstellung von Webseiten ist dank WebKit hervorragend. Bedienen lässt sich dieser minimalistische Traum mit ein paar Tastenkombinationen. Die in urxvt geöffnete man-Seite zeigt wie es geht. Um zu einer Seite zu gelangen, einfach STRG+g drücken und Adresse eingeben oder surf direkt von der Kommandozeile mit surf www.meinetolleinternetseite.de starten.

Surf kann keine Tabs, zumindest solange man nicht tabbed installiert hat oder schon die Vorzüge von kachelnden Fenstermanagern wie z.B. dwm oder Awesome kennt. Ich persönlich kann surf einiges abgewinnen.

Oder programmiere ihn selbst

Ich habe mich lange Zeit gefragt, welchen Grund es gibt, dass WebKit-Browser so verbreitet sind. Eine Open-Source-Engine wie WebKit ist eine Sache, aber einen Browser zu programmieren, das stellte ich mir als fortgeschrittene und vor allem zeitintensive Aufgabe vor. Doch dann fand ich dieses geniale 20 minütige Videotutorial zur Programmierung eines WebKit-Browsers mit Python und GTK in Englisch. Danach war mir schlagartig klar, warum es so viele WebKit-Browser gibt. Es macht einfach unheimlich viel Spass einen solchen zu programmieren. Das Tutorial ist aber auch erste Sahne und sehr empfehlenswert. 🙂

Wer sich die Mühe nicht selbst machen will ein paar Zeilen abzutippen, kann auch gleich hinüber zu K.Mandla navigieren und sein 1,5 KB großes Pythonskript kopieren und dann damit anfangen im Netz zu surfen.

Was bleibt als Fazit? WebKit-Browser machen Spass und der IE 6 ist endlich Geschichte. Es darf gefeiert werden.

Mplayer nur für den Framebuffer

Die ganzen gestrigen Ausführungen, wie man mit Debian Binärpakete aus dem Quellcode baut, dienten eigentlich nur einem Zweck. Ich wollte K.Mandlas „Mplayer for the framebuffer only“ Tipps einmal ausprobieren.

Wie macht man Mplayer noch schneller und ressourcenschonender? Man entschlackt ihn, indem man beim Kompilieren verschiedene Feature deaktiviert. Zum Übersetzen habe ich die gestern vorgestellte pbuilder Methode genutzt.

Ziel war es, die Unterstützung für Videoausgabe ausschließlich auf das Framebuffer Device fbdev zu beschränken. In debian/rules mussten die CONFIGURE_FLAGS und der Code zum Bauen der Mplayer GUI und der nicht grafischen Version angepasst werden.

Welche Optionen es gibt, erfährt man durch ./configure --help. Mit dem Befehl debchange -nmu changelog im debian Verzeichnis des Quellpakets kann das changelog angepasst werden.

Nach jeder Veränderung in debian/rules musste ich das Quellpaket mit dpkg-source -b Name_des_Verzeichnisses neu bauen, damit die gemachten Änderungen von pbuilder auch erkannt wurden. Wer Tipps und Hintergrundinformationen dazu hat und ob es auch andere Möglichkeiten gibt, kann mich gerne darauf stoßen.

Unter den CONFIGURE_FLAGS werden noch verschiedene if-Abfragen ausgeführt. Dabei sollte man vor allem das Bauen der Mplayer GUI Version deaktivieren, wir brauchen nur den Framebuffer, und Mencoder kann auch aus debian/rules verschwinden.

CONFIGURE_FLAGS = 
              --prefix=/usr 
              --confdir=/etc/mplayer 
              --disable-x11 
              --enable-xvmc 
              --enable-menu 
              --disable-arts 
              --enable-largefiles 
              --language=de 
              --disable-libdvdcss-internal 
              --disable-dvdread-internal 
              --disable-libavutil_a 
              --disable-libavcodec_a 
              --disable-libavformat_a 
              --disable-libpostproc_a 
              --disable-libswscale_a 
              --disable-openal 
              --disable-sdl 
              --disable-aa 
              --disable-esd 
              --disable-jack 
              --disable-tv-v4l1 
              --disable-tv-v4l2 
              --disable-runtime-cpudetection 
              --disable-mga 
              --disable-smb 
              --disable-gui 
              --disable-lirc 
              --disable-lircc 
              --disable-liblzo 
              --disable-fribidi 
              --disable-libdv 
              --disable-musepack 
              --disable-speex 
              --disable-cdparanoia 
              --disable-dvdnav 
              --disable-libamr_nb 
              --disable-live 
              --disable-mad 
              --disable-mencoder 
              --disable-gl 
              --disable-pulse 
              --enable-fbdev 
              --disable-3dfx 

Alles in allem hat das bei mir dazu geführt, dass das mplayer .deb Paket von 3 MB auf 1,7 MB geschrumpft ist. Zum Testen gelangte es dann auf den Toshiba Portégé 3110 CT, wo ich Youtube Videos mit Elinks und Mplayer angeschaut habe.

Auch mit einer angepassten Mplayer Version lassen sich h264 Videos nicht ruckelfrei in Vollbild auf einem PII 300 MHZ 64 MB RAM Laptop anschauen. Dennoch mit einer kleinen Modifikation des youtube-dl Skripts, ließen sich zumindest manche h263 Videos mit niedrigster Auflösung betrachten, wozu ich einfach die Option -f 5 anstelle von -f 34 übergeben habe.

Wichtig sind auch die kleinen Mplayer Tweaks und die Tipps in der MPlayer FAQ.

Zu einem Screenshot mit fbgrab reichte es aber, auch wenn dadurch der Laptop kurzzeitig ausgelastet war.

Gibt man dem alten Rechner eine Chance mit mpeg1/2 Videos und nutzt nicht gerade den CPU lastigen h264 Codec, sieht das Ganze besser aus. Über das Abspielen auf dem zwei Jahre jüngeren Dell Inspiron 4000 brauche ich nicht viele Worte verlieren. Das klappte auch schon vorher problemlos.

Als Fazit lässt sich sagen das selbst maßgeschneiderte Software nicht immer das Unmögliche schaffen kann, aber angesichts des zwölf Jahre alten Laptops noch brauchbare Ergebnisse liefert. Selber Kompilieren ist auf jeden Fall lehrreich. Debians Mplayer Binärpaket ist aber nicht fühlbar schlechter.

Auf jeden Fall gewinnt ihr ein paar Geek Punkte bei dem bleichen Geek von nebenan hinzu und vom Rest gibt es immerhin Augenrollen 🙄 , Kopfschütteln und sanftes Klopfen auf die Schulter.

Das Leben ist nicht immer fair.