Tag: Entwicklung

Posted on

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.

Posted on

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.

Posted on

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)

Posted on

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.

Posted on

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.

Posted on

Wie man Debian-Pakete aus den Quellen baut

Im folgenden möchte ich ein paar Wege aufzeigen, wie man ein Binärpaket mit Debian erzeugt. Das Ganze ist mehr als Merkzettel zu verstehen und ersetzt nicht die offizielle Dokumentation zur Erstellung von Binärpaketen mit Debian. Am Ende finden sich nützliche Links für alle, die sich mehr mit den technischen Details beschäftigen möchten. Außerdem finden sich dort auch Links zu Videos, die den Prozess ausführlich und nachvollziehbar erklären.
Die folgende Übersicht ist in Teilen eine Übersetzung des englischen Howto "How to build a package from source the smart way".

Der bessere Weg - Debianisierte Quellen kompilieren

Der allgemeine Weg ein Binärpaket aus den Quellpaketen zu erstellen läuft immer so ab:

  1. Zuerst muss der Paketmanager wissen, woher er die Quelldateien beziehen soll, wozu die Datei /etc/apt/sources.list modifiziert wird.
  2. Dann wird das Quellpaket als normaler Nutzer heruntergeladen.
  3. Dann wird dpkg-buildpackage ausgeführt, um ein .deb Paket zu erstellen.
  4. Und schließlich wird dpkg -i benutzt, um das .deb Paket zu installieren.

1. Folgende Zeile in die /etc/apt/sources.list eintragen, sofern man sid installiert hat.

deb-src http://ftp.de.debian.org/debian/ sid main

2. Die Paketabhängigkeiten zum erfolgreichen Kompilieren als root installieren

aptitude update
aptitude install build-essential fakeroot devscripts
aptitude build-dep Paketname

3. Quellen herunterladen und Binärpakete bauen (alle weiteren Befehle als normaler Nutzer ausführen)

mkdir /home/XXXX/tmp/
cd /home/XXXX/tmp/
apt-get source Paketname
cd Paketname-version/

Nun kann die Datei debian/rules oder weitere debianspezifische Dateien wie debian/control oder debain/changelog angepasst werden. Ein wichtiges Programm hierfür ist debchange welches sich im Paket devscripts befindet.
Nach der Konfiguration wird das .deb Paket erstellt.

dpkg-buildpackage -rfakeroot -us -uc

Mit -us -uc überspringt man den Schritt, bei dem üblicherweise Debian Pakete vom Paketersteller signiert werden.
4. Installieren

cd /home/XXXX/tmp/
dpkg -i Paketname_Version_Architektur.deb

Nicht debianisierte Quellpakete kompilieren

Obwohl Debian ein riesiges Paketarchiv hat, kann es vorkommen, dass es zu einem Paket noch keine angepasste Debianversion gibt. Hierzu muss also das Original-Tarball mit den Quellen von der Projektseite heruntergeladen werden und anschließend mit dem Debianprogramm dh_make in eine debianisierte Version umgewandelt werden. Die Abhängigkeiten des Pakets müssen dann manuell mit apt installiert werden.

aptitude install dh-make

Als normaler Nutzer wieder:

mkdir /home/XXXX/tmp/
cd /home/XXXX/tmp/
tar -xvf Paketname_Version.tar.gz
mv Paketname_Version/ paketname-version/
mv Paketname_Version.tar.gz paketname_version.orig.tar.gz

Die Benennung des Pakets und die Unterstriche sind wichtig, damit sie Debians Konventionen entsprechen. Anderenfalls wird dh_make eine Fehlermeldung ausgeben. Danach in das entpackte Verzeichnis wechseln und dh_make ausführen.

dh_make

dh_make wird eine Reihe von Fragen stellen und schließlich müssen die Felder für den Paketbetreuer ausgefüllt werden. (das was man mit aptitude show zu sehen bekommt)
Nachdem dies erledigt ist

dpkg-buildpackage -rfakeroot -us -uc
dpkg -i paketname_version_architektur.deb

Chroot Umgebung und pbuilder

Am besten führt man alle Schritte zum Kompilieren in einer speziellen chroot Umgebung durch, die vom restlichen System getrennt ist und die sich später sehr leicht auch wieder entfernen lässt. Ein weiterer wichtiger Vorteil ist, dass Pakete, die in dieser Umgebung richtig gebaut werden, auch auf anderen Rechnern erfolgreich übersetzt werden können. Der Prozess wird dadurch reproduzierbar.
Ich benutze entweder die debootstrap Methode oder das Programm pbuilder.
1. Pbuilder installieren

aptitude install pbuilder

2. Chroot Umgebung erstellen

pbuilder create --distribution squeeze

Standardmäßig wird ein auf sid basierendes chroot Image erstellt. Die Option --distribution ändert das.
3. Pbuilder aktualisieren

pbuilder update

Falls man längere Zeit nichts mehr kompiliert hat, sollte die chroot Umgebung aktualisiert werden.
4. Quellpaket herunterladen

apt-get source Paket

5. In das Quellverzeichnis wechseln und debianisiertes Quellpaket in chroot Umgebung bauen

pbuilder build Paket_Version.dsc

Die fertigen Binärpakete befinden sich danach in /var/cache/pbuilder/result.

Der herkömmliche Weg - autoconf und automake

In den meisten Quellpaketen befindet sich ein sogenanntes configure Skript, welches automatisch von dem GNU Programm autoconf generiert wird. In der Regel muss man in das Quellverzeichnis wechseln und folgende Befehle ausführen, um ein Binärpaket zu erstellen. Zuvor müssen Abhängigkeiten manuell oder mit aptitude build-dep installiert werden.
Als Ziel für die Installation wird /usr/local gewählt, /opt ist ebenfalls eine gute Alternative.

./configure --prefix=/usr/local --beliebige Optionen zur Konfiguration

Danach genügt es mit make die Quellen zu übersetzen und mit make install die Binärpakete in das gewählte Zielverzeichnis zu installieren.

make
make install

Für Debian ist es dabei besser make install durch checkinstall zu ersetzen. Checkinstall erstellt ein .deb Paket und merkt sich wohin die Pakete installiert werden. Der Nachteil ist, dass es weder die Quelldateien debianisiert noch Paketabhängigkeiten berücksichtigen kann.

su -c "checkinstall -D make install"

Ein Beispiel für diese Methode war meine Dillo2 Kompilierung auf dem Toshiba Portege.

Links

Basics of the Debian package management system
Debian New Maintainers' Guide
Ubuntu - Packaging Guide Complete
Videos von der MiniDebConf 2010 in Berlin in Deutsch
Die .ogv Dateien zu Packaging und Advanced Packaging zeigen einen Vortrag zum Thema Paketerstellung mit Debian.
Nach der Lektüre und den Videos sollte man in der Thematik fit sein. 😉

Posted on

Wine einmal selbst kompilieren

Ungewöhnliche Probleme erfordern ungewöhnliche Maßnahmen...oder so ähnlich. Der Bug mit den Zeratul-Missionen bei Starcraft II beschäftigte mich seit einer Weile, weswegen ich noch einmal im Netz nachschaute, ob jemand nicht doch mit den gleichen Problemen zu kämpfen hatte.
In der Wine-Anwendungsdatenbank stieß ich dann endlich auf einen Kommentar, der exakt das gleiche Problem beschrieb. Ich erinnerte mich wieder daran, dass ich schon erfolgreich die ersten beiden Zeratul-Missionen mit Wine 1.2 gespielt hatte. Vielleicht half hier ja ein Versionswechsel?
In Sachen Wine hinkt Debian aus mir unbekannten Gründen mit der aktuellen Version weit hinterher. (Debian Sid z.Z. 1.1.42). Damit lässt sich zwar auch Starcraft 2 spielen, das Zeratul Problem bleibt aber bestehen. Als Alternative gibt es aber auf der WineHQ-Seite zumindest die Möglichkeit die aktuellen Entwicklungsversionen des Wine 1.3 Zweiges als vorgefertigte .deb Pakete herunterzuladen, die mir aber auch nicht weiterhelfen konnten.
Alles in allem blieb nur die Möglichkeit Wine aus den Quellen selbst zu kompilieren. Ich schaute zuerst nach, welchen Weg die Entwickler vorschlugen und installierte danach zuerst einmal die für die Kompilierung notwendigen Pakete.
Welcher Weg der Sinnvollste zur Kompilierung eines Debian Binärpakets ist, scheint wirklich davon abzuhängen, welche Webseite man gerade liest. Interessanterweise konnte man praktisch überall etwas anderes lesen. Zur eigenen Dokumentation gehe ich später noch einmal auf die verschiedenen Optionen ein. Prinzipiell bietet Debian viele Werkzeuge an, die den Prozess stark vereinfachen und für alle, die öfter Pakete mit Debian erstellen, mit Sicherheit auch der beste Weg sind.
Hier ist nun aber der althergebrachte Weg mit Linux ein Quellpaket zu übersetzen und der auch vom Wine-Wiki vorgeschlagen wird. Zum Ausprobieren habe ich mir erneut eine minimale chroot Umgebung mit debootstrap erstellt.

  1. Quellpakete herunterladen z.B. auf der offiziellen Sourceforge Seite von Wine oder hier.
  2. Abhängigkeiten installieren

    apt-get build-dep wine

    oder indem die oben erwähnten Pakete manuell mit apt installiert werden.

  3. Quellpaket entpacken z.B. in ~/tmp mit

    tar -xvf wine-1.2.tar.bz2

  4. Kompilieren: In das neue Wine-Verzeichnis in ~/tmp wechseln und

    ./configure
    make

    ausführen.

Wine lässt sich dann direkt aus dieser Umgebung benutzen oder danach auch mit dem Kommando make install in den Pfad des Nutzers installieren.
Sollten Probleme beim Ausführen von ./configure auftreten, fehlen einige Pakete als Abhängigkeiten, die manuell nachinstalliert werden müssen. Das war es im Prinzip schon. War das Ganze nun ein Erfolg?
Ich konnte danach Starcraft II zwar starten und benutzen. Das Spiel stürzte trotzdem nach Klick auf den Kristall im Labor ab, mit dem die Zeratul Missionen gestartet werden. Auch eine weitere Wine Version 1.2.1. brachte das gleiche Ergebnis. 🙁
Das Problem scheint also woanders zu liegen. In Sachen Kompilierung ist die oben beschriebene Methode praktisch auf jeder Linuxdistribution zu verwenden, ist aber gerade bei Debian eine etwas "unsaubere" Lösung, da der Paketmanager und die von Debian zur Verfügung gestellten Werkzeuge nicht zum Einsatz kommen. Mehr Möglichkeiten zum Erstellen von Binärpaketen mit Debian habe ich hier beschrieben. 🙂

Posted on

Den eigenen Debian-Kernel bauen

Es kommt nicht oft vor, dass ich den Linuxkernel selbst übersetzen muss. In der Regel bietet der generische Debian- oder Ubuntukernel alle Treiber, die man braucht und da die Module nur dann geladen werden, wenn sie tatsächlich benötigt werden, ist der Performancegewinn eines eigenen Kernel für mich auf neuer Hardware kaum spürbar.
Natürlich gibt es aber auch gute Gründe, warum ein eigener Kernel sinnvoll sein kann. Sei es nur um das letzte bisschen Leistung herauszukitzeln, ein neues Kernelfeature zu aktivieren oder unnötige zu deaktivieren.
Der Standardkernel 2.6.32 von Squeeze und auch der 2.6.26 von Lenny funktionieren beide nicht auf meinem Toshiba Satellite 220cs Laptop. Bei nur 16 MB RAM regt sich nach GRUB für gewöhnlich nichts mehr. Meine Versuche mit Slitaz hingegen waren sehr erfolgreich. Sowohl das Betriebssystem als auch der Kernel sind so angepasst, dass selbst 16 Jahre alte Hardware mit aktueller Software funktioniert.
Als Debian-Fan wollte ich unbedingt den Kernel anpassen, um auszuprobieren wie sich Debian auf dem alten Laptop schlägt. Natürlich stand ich wieder mal vor dem Problem, wie ging das eigentlich bei Debian mit dem Kernelkompilieren.
Debians Kernel Handbook zeigt schon die wichtigsten Schritte auf, doch am einfachsten und nachvollziehbarsten werden sie auf www.adminlife.net beschrieben.
Debian bringt nämlich schon ein Werkzeug mit, welches alle wichtigen Schritte der Kernelkompilierung übernimmt und den angepassten Kernel auch gleich in ein .deb Paket umwandelt, welches sich über Debians Apt dann problemlos verwalten lässt.
Die wichtigsten Schritte sind:

  • Notwendige Programme zum Kompilieren installieren
    aptitude install kernel-package build-essential
  • Gewünschte Kernel Quellen installieren. Entweder die Debian Kernel Sourcen nehmen oder direkt von www.kernel.org herunterladen und in /usr/src entpacken. Z.B.
    aptitude install linux-source-2.6.30
  • Symlink anlegen
    ln -s /usr/src/linux-2.6.30 /usr/src/linux
  • Kernelconfig kopieren. Für den Anfang genügt es die aktuelle config aus /boot zu nehmen. Allgemein geht auch zcat /proc/config.gz > kernel.cfg
    cp /boot/config-`uname -r` /usr/src/linux/.config
  • Kernel an die eigenen Bedürfnisse anpassen
    cd /usr/src/linux
make oldconfig
make menuconfig
  • Den Kernel kompilieren und ein .deb Paket erstellen
    make-kpkg kernel_image --revision 20110217 --initrd

Ich musste auf meinem im letzten Post vorgestellten Debian-Minimalsystem mit debootstrap noch das Paket lzma installieren, damit das Kompilieren erfolgreich war.
Als Kernelconfig hatte ich die Slitaz 2.6.30-loram config ausgewählt. Beim Übersetzen wurde zuerst ein Fehler mit dem Kernelmodul lguest gemeldet, dass ich danach aus der config gestrichen habe.
Erfreulicherweise lief danach die Kernelkompilierung erfolgreich durch. Das entstandene .deb Paket lässt sich bequem mit dpkg -i installieren.
Mit diesem Kernel ließ sich wie erhofft problemlos sowohl ein Squeeze als auch ein Lenny in Qemu booten. Möglichkeiten zum Optimieren gibt es noch einige. Z.B. benötige ich nicht wirklich das ReiserFS-Dateisystem und gefühlte 100 weitere Module auch nicht.
Vielleicht werde ich deswegen auch in Zukunft die Kernelconfig soweit anpassen, dass tatsächlich nur noch die absolut notwendigen Pakete übrig bleiben. Für den Anfang ist "the Debian way ™" und ein Minidebian in Ubuntu eine bequeme Möglichkeit um weiter herum zu experimentieren.
Wie sich der neue Kernel auf dem Toshiba 220cs geschlagen hat, dazu demnächst mehr.

Posted on

Dillo2 mit Debian Squeeze kompilieren

Scheinbar hat es Dillo2 nicht mehr in Squeeze geschafft. Seit dem 06. August 2010 ist die kommende stabile Debian Version "Squeeze" eingefroren, d.h. es kommen keine neuen Pakete mehr hinzu und nur noch Fehler werden beseitigt. Da Dillo2 selbst in sid nicht auftaucht, wird noch eine Weile vergehen bis man diesen leichtgewichtigen Browser in Debian wiederfinden kann. Passend dazu kann man auf der Fehlerreport Seite von Debian nachlesen, dass auch die alte Version von Dillo aus dem Debianarchiv gelöscht wurde, weil Dillo von veralteten Bibliotheken abhängig war und Fehler seit Monaten nicht mehr ausgebessert werden, was die Entwickler auch zugeben.
Ich habe mich mal hingesetzt und Dillo2 mit der neuen FLTK2 Bibliothek auf meinem Toshiba Portégé 3110CT mit Debian Squeeze kompiliert. Es gibt dazu eine Anleitung auf der offiziellen Dillo Homepage. Leider geht die README.unix Datei nur ungenau darauf ein wie die Pakete heißen, welche für ein erfolgreiches Kompilieren notwendig sind und man muss zuerst einmal die richtigen X, jpeg und mesa Pakete finden.
Als erstes muss die FLTK2 Bibliothek übersetzt werden. Die Quelldateien gibt es hier. Ich habe Version 2.0.x-r7680 benutzt. Für Debian Squeeze müssen dann zuerst folgende Pakete installiert werden.

aptitude install

  • build-essential
  • xserver-xorg-dev
  • libx11-dev
  • libxi-dev
  • libjpeg-dev
  • libglu1-mesa-dev
  • libpng12-dev
  • libxcursor-dev
  • libglut3-dev
  • zlib1g-dev (für Dillo2)

Danach einfach die Datei mit tar jxvf fltk-2.0.x-r7680.tar.bz2 z.B. in /tmp entpacken, in das Verzeichnis wechseln, make ausführen, Root werden oder ein Programm wie fakeroot nutzen und FLTK2 mit make install installieren

cd fltk-2.0.x-r7680
make
su
make install

Die neueste Dillo2 Entwicklerversion herunterladen. In das Dillo Verzeichnis wechseln und Dillo2 kompilieren.

./configure
make
su
make install-strip

dillo auf der Konsole eingeben und loslegen!
Es hilft, wenn man den ./configure Dialog bei FLTK2 und Dillo2 beobachtet. Sollten dort zu viele Tests fehlschlagen, kann es entweder sein, dass man ohne das Installieren von zusätzlichen Paketen Dillo2 gar nicht übersetzen kann oder wie bei mir nach dem ersten Übersetzen ohne PNG Unterstützung dasteht. Die oben aufgelisteten Pakete waren dann aber beim zweiten Mal ausreichend, um Dillo2 zum Laufen zu bekommen.
Hier noch ein kurzer Vergleich zwischen Dillo2 und Links2. Ich habe jeweils Screenshots von bbc.co.uk, dillo.org und gambaru.de aufgenommen. Rechts ist dillo2 zu sehen und links links2. Die dillo.org Seite sah identisch bei beiden aus.


Dillo2 startet in zwei Sekunden auf dem älteren Laptop und bietet nun auch ausreichende CSS Unterstützung. Mit float Anweisungen scheinen beide Browser nicht perfekt umgehen zu können. Zu einem kurzen Blick auf Webseiten reichen beide aus. Die Nachteile gegenüber modernen Alternativen sind aber auch unverkennbar. Besonders beachten sollte man, dass Dillo2 https nicht vollständig unterstützt und deshalb für sicheres Surfen nicht zu empfehlen ist.
Für mich sind beide Browser dennoch nützliche Programme auf einem altersschwachen Rechner, wenn es nur darauf ankommt schnell eine Information zu finden.