Mediathekview 3.0: Es ist angerichtet

Esst solange es heiß ist. Ich habe soeben Mediathekview 3.0 auf meinen FTP-Server hochgeladen.
Update 13.08.2012: Zusätzlich im Angebot nun auch Version 2.6.1, die letzte der 2er-Variante. Hier beschränken sich die Veränderungen nur auf das Notwendigste um Lintian-Fehler zu beseitigen und die Filmliste wieder funktionsfähig zu machen. Die Änderungen sind immer noch relativ groß, was es schwierig macht dafür eine Uploaderlaubnis nach Wheezy zu bekommen. Ich schicke den Patch auf jeden Fall an den Debian-Bugtracker und dann sehen wir einfach mal weiter.
Update 15.08.2012: Version 3.0 hat nun ein neues Menüicon, ein Changelog und die Kurzanleitung. So sieht das vorläufige neue Icon von W. Xaver, dem Entwickler von Mediathekview, aus.
Update 16.08.2012: Neue Anleitung.pdf für Version 3.0 und einige kosmetische Änderungen am Quellpaket.
Mediathekview 3 Icon
Update 22.08.2012: Wir nähern uns der finalen Version. Einen potentiellen Sponsor habe ich gefunden und es sieht so aus als ob ich auch der Paketverwalter von Mediathekview werde.
Update 28.09.2012: Fast geschafft. MediathekView 3.0 im September 2012.
Update 05.10.2012: Seit dem 03.10.2012 befindet sich Mediathekview in Debian Unstable. Von dort wird es “bald” auch nach Ubuntu gelangen. Deswegen entferne ich nun die hier zur Verfügung gestellten Pakete. Danke an alle Tester!

Was euch erwartet

Hoffentlich ein funktionsfähiges Paket. 😉 Ich habe es mit Lintian erfolgreich geprüft, es lässt sich installieren, deinstallieren und upgraden. Obwohl ich so sorgfältig wie möglich vorgegangen bin, gibt es wie immer keine Garantie. Wer Spaß an der Blutigen Kante/Schneide hat darf zugreifen. Ich will hier aber nicht lesen müssen, dass ihr eure über Jahrzehnte gesammelte Arbeit verloren habt, weil ihr Mediathekview 3.0 ausprobieren wolltet und das Backup ja eigentlich um Mitternacht angelaufen wäre. 😈
Angst? Gut.
Das Paket ist fast “fertig”, es fehlen aber noch folgende Dinge (und ein geübter Blick eines Debianentwicklers):

  • Changelog. Es hat sich viel verändert. Ich kann aber noch kein abschließendes Changelog erstellen, da ich nicht mal weiß, ob das Paket überhaupt akzeptiert wird. Ich erstelle nun noch eine weiteres Paket in Version 2.6.1, das vermutlich größere Chancen hat den gestern erwähnten RC-Bug zu fixen. Das Paket hier wäre dann regulär für Unstable gedacht.
  • Menüicon. Ist immer noch das Icon aus Version 2.4 und skaliert leider nicht sehr schön. Wer eine Idee für ein gutaussehendes Icon hat…immer her damit.
  • Dokumentation. Gibt es auf der offiziellen Mediathekview-Seite. Da ich seit kurzem über Quellcode und PDF-Dokument der Kurzanleitung verfüge, kommt diese später noch nach /usr/share/doc/mediathekview.
  • Geänderte Empfehlungen. Ich habe die Empfehlungen leicht geändert. Flvstreamer ist weiterhin empfohlen. Jedoch gibt es nun für VLC und den Mplayer eine ODER-Bedingung. Die alte Empfehlung für mplayer-nogui habe ich entfernt, da es dieses Paket für Debian gar nicht gibt. (wohl aber bei deb-multimedia.org)

Wer noch eine Knobelaufgabe sucht, hier ist sie:
Mit Mediathekview lassen sich sogenannte Programmsets einrichten. Ihr könnt also zum Abspielen und Speichern jeweils separate Videoabspieler festlegen. Gesucht ist ein Befehl, mit dem es möglich ist rtmp- und mms-Streams direkt über Mplayer abzuspielen ohne Zusatzprogramme. Ich bin mit dem momentanen Standardset für Linux nicht zufrieden. Praktischerweise lassen diese Sets sich aber als XML-Datei exportieren und über die Projektseite herunterladen.
Wenn ihr also ein cooles Programmset habt, dass es ermöglicht mit Flvstreamer, VLC und Mplayer alle Videos abzuspielen und zu speichern, ist die Wahrscheinlichkeit groß, dass dies das neue Standardset wird. Behaupte ich einfach mal. 😉

Mediathekview 3 und Gnome 3

Mediathekview und Gnome3

Mediathekview 3.0: Bugs, Patches und Lösungen

In den letzten Wochen und Tagen habe ich versucht etwas Nützliches für Debian zu tun. Im Juni konnte ich noch meine Fehlerberichte der letzten Wochen vorstellen, die sich hauptsächlich mit den Spielen für meinen Spieleserver beschäftigten. Eine nicht ganz unlogische Schlussfolgerung war, wenn man sich intensiver mit einem Stück Software befasst, entdeckt man zwangsläufig Fehler.

LXAppearance

Dieser Binsenweisheit folgend meldete ich dann einige Wochen später einen Bug mit LXAppearance. LXAppearance ist meine bevorzugte Anwendung, wenn es darum geht das Icon- oder GTK-Thema meiner Fenstermanager-Lösungen auszutauschen. Im Regelfall kopiere ich ein neues Thema nach ~/.themes und neue Icons nach ~/.icons und wähle sie dann mit LXAppearance aus.
Mehr als merkwürdig war die Tatsache, dass LXAppearance immer dann abstürzte, wenn ich ein neues Icon-Thema installieren wollte. Da ich nicht jeden Tag das Aussehen des Desktops ändere, hat mich das bisher kaum gestört vor allem, weil das Thema trotz Absturz installiert worden war. Also erstellte ich einen Backtrace mit GDB und schickte ihn zusammen mit dem Core-Dump als Fehlerbericht #683146 zum Debian-BTS.

Aptitude

Es gibt Anwendungen, die man tagtäglich benutzt, aber von denen man dennoch gar nichts weiß. Ich probiere gerne neue Programme aus und so war es eines Tages an der Zeit mir Gnome-Packagekit näher anzuschauen. Ich bin mir sicher, dass die meisten Leser eher zu Konsolenwerkzeugen greifen und grafische Installationsprogramme verpönt sind. Gnome-Packagekit ist die Antwort der Gnome-Entwickler auf die Suche nach einer simplen, grafischen Anwendung, die Linuxpakete mit ein paar Mausklicks installieren und entfernen kann. Keine wirklich schlechte Sache, wenn man weniger technikaffinen Menschen Linux schmackhaft machen möchte.
Da ich wegen meines libcairo2-Problems (das übrigens nun gelöst ist, juhu) besagte Bibliothek mit Aptitude auf “hold” gesetzt hatte, wunderte ich mich sehr, dass Gnome-Packagekit dennoch ein vollständiges Upgrade vornahm. Schon kurze Zeit später war der Fehlerbericht #683099 verfasst. Was ich dabei nicht bedacht hatte war, auch Aptitude konnte Schuld sein.
Tatsächlich benutzt Aptitude derzeit noch einen anderen Mechanismus, um Pakete auf “hold” zu setzen, den apt-get nicht benutzen kann und umgekehrt. Da Gnome-Packagekit sich aber an Apt orientiert, führt das zu dem beschriebenen Fehler. Ich beneide den oder die derzeitigen Paketverwalter von Aptitude nicht. In der Vergangenheit wurden so viele Fehlerberichte gegen Aptitude verfasst, dass ich Probleme habe überhaupt noch die Übersicht zu behalten. Wäre ich der Maintainer von Aptitude, würde ich vermutlich zuerst einmal alle Fehlerberichte löschen und von Null anfangen. 😉

Mediathekview

Obwohl alle Fehlerberichte ihre Berechtigung hatten und ich versucht habe, so präzise wie möglich das Problem zu beschreiben, führte das nur in den wenigsten Fällen auch direkt zur Beseitigung des Problems.
Ich ging es also nun anders an. Anstatt Fehler zu melden, wollte ich jetzt nur noch Fehler lösen. Ihr denkt euer System sei fehlerfrei und nicht von schwerwiegenden Fehlern, sogenannten RC-Bugs, betroffen? Dann macht mal Folgendes:
aptitude install devscripts
rc-alert
Auf diese Art und Weise habe ich schließlich entdeckt, dass Mediathekview in einem kritischen Zustand ist. Ich habe noch nie einen Hehl daraus gemacht, dass ich von dem jetzigen Zustand des deutschen Fernsehens maßlos enttäuscht bin. Auf der anderen Seite bedeutet das nicht, dass ich Filme im Allgemeinen verabscheuen würde. Ganz im Gegenteil. Ich liebe Filme. Ich genieße Blair Witch Project genauso wie Frühstück bei Tiffany und Sieben, insbesondere wenn es gerade regnet, wenn man aus dem Kino kommt. 🙂
Mittlerweile substituiere ich die Zeit vor der Glotze mit Dingen wie Bloggen, was immer das auch sein mag.
Mediathekview war bisher mein Hilfsmittel, um nicht ganz den Anschluss an das aktuelle Fernsehprogramm zu verlieren. Natürlich gibt es Reportagen und Sendungen, die sehenswert sind und um das Auffinden dieser zu erleichtern gab und gibt es eben diese in Java geschriebene Anwendung.
Ich schaute mir also Fehlerbericht #681680 näher an. Scheinbar hinkt das Paket mittlerweile zwei Hauptveröffentlichungen hinterher. Der Fehlerbericht ist absolut zutreffend und würde dazu führen, dass Mediathekview aus Wheezy entfernt wird. Da ich also Interesse an dem Paket hatte, sah ich den Augenblick gekommen um an einem Patch zu arbeiten.
Sofort taten sich folgende Fragestellungen auf: Wie sollte ich das Problem angehen? Konnte ein kleiner Patch das bestehende Paket wieder funktionsfähig machen oder musste es ein vollständiges Upgrade auf die aktuelle Version 3.0 sein? Was war mit dem Paketverwalter los? Und wie gelangte der Patch schließlich in das offizielle Debian-Archiv?
Ich beschloss zuerst das Quellpaket herunterzuladen:
apt-get source mediathekview
Danach lernte ich Git und klonte das Mediathekview-3-Repo.
Nach vielen Fehlschlägen und vor allem viel Lesen, baute ich schließlich erfolgreich Version 3.0 mit Debian Sid.
Mediathekview3 mit Debian und VLC
Fortgeschrittene erkennen an dem Screenshot den neusten Fenstermanager, mit dem ich mich derzeit beschäftige. 🙂
Im Moment bin ich mit der Feinarbeit beschäftigt. Die Man-Seite auf den aktuellen Stand bringen, debian/control und debian/rules anpassen, Testen und viele weitere Kleinigkeiten verändern. Die Entwickler von Mediakthekview haben sogar einen Patch veröffentlicht, der es mit Version 2.6.1 ermöglicht, wieder automatisch Filmlisten herunterladen zu können. Nun muss ich ein Paket bauen, das möglichst wenig Veränderungen zur aktuellen Version aufweist, aber dennoch alle Bugs zufriedenstellend löst, damit es noch eine Chance hat in Debian Wheezy akzeptiert zu werden. Mehr dazu und anderen Unwichtigkeiten, bald ™. 😉

Jessie ist der neue Codename für Debian 8.0

Vor wenigen Stunden hat Adam D. Barrat auf der Mailingliste debian-devel-announce diese Ankündigung öffentlich gemacht.
Wie viele sicher wissen besteht in Debian die Tradition, die Codenamen für die nächste stabile Veröffentlichung von Charakteren aus dem Film “Toy Story” abzuleiten.
Das hier ist Jessie.
Jessie aus dem Film Toy Story
Neben Bo ist sie der zweite weibliche Charakter, der aus dem Film als Codename für Debian verwendet wird. In Wikipedia wird sie als mutig, athletisch aber auch leicht reizbar beschrieben. Wie der Name für Debian 9.0 heißen könnte, lässt sich durch ein Lesen dieser Liste erfahren.
Ich bin schon jetzt gespannt, welche Ziele sich Debian für die übernächste Veröffentlichung der Distribution setzen wird. Doch bevor es soweit ist, müssen noch für Wheezy eine ganze Menge Bugs gefixt werden. Da ich mich persönlich mehr und mehr für die Entwicklung von Debian interessiere, sind hier mal ein paar Links wie und wo man helfen kann, damit Wheezy so schnell wie möglich veröffentlicht werden kann.

Sauerbraten: Cube Server Lister für Debian und Ubuntu kompilieren

Für Cube2: Sauerbraten gibt es ein nettes, grafisches Programm, mit dem sich Sauerbraten-Server überwachen lassen. Es existiert eine Übersicht sowohl über die Anzahl der Spieler, den Serverstatus, diverse Variablen und auch eine Mapvorschau gibt es. Mit einem simplen Mausklick kann man sich mit dem Server verbinden.

Kleiner Haken. Der Cube Server Lister wurde schon länger nicht mehr aktualisiert und es gibt keine offiziellen Debian- und Ubuntu-Pakete. Als Alternativen bieten sich zum einen die Trunk-Version oder ein Projekt auf GitHub an, welches CSL so gepatcht hat, dass es mit der aktuellen Justice-Version von Sauerbraten funktioniert.
Wenn man von dort die Quellen heruntergeladen hat, muss man nur noch der Anleitung auf ogros.org folgen, dort wo der Cube Server Lister auch von “WahnFred” entwickelt worden ist.

Die Kurzfassung

  1. aptitude install automake libtool libglib2.0-dev intltool g++ libwxgtk2.8-dev
  2. svn co http://cubelister.svn.sourceforge.net/svnroot/cubelister/trunk csl-svn
  3. In das csl-svn-Verzeichnis wechseln.
  4. make -f Makefile.cvs (bei der GitHub-Version nicht notwendig)
    ./configure
    make
    sudo make install

The Debian Way

Besser ist es natürlich direkt Deb-Pakete zu erstellen. Zuvor müssen die Quellen debianisiert werden.
Ihr müsst nur den Schritten in dem alten Beitrag folgen und das Quellverzeichnis richtig umbenennen (z.B. csl-0.81 und csl_0.81.orig.tar.gz) und das .orig.tar.gz-Archiv erstellen. Anschließend wechselt ihr in das Verzeichnis und führt dh_make aus. (Paket dh-make muss installiert sein. )
Das Paket lässt sich dann mit
dpkg-buildpackage -rfakeroot -us -uc
bauen und mit
dpkg -i csl_0.81-1_i386.deb
installieren.
Anmerkung:
Ich musste noch zwei Zeilen in /po/POTFILES.in nachtragen, bevor sich das Debian-Paket kompilieren ließ.

./src/engine/CslCharEncoding.cpp
./src/engine/CslCharEncoding.h

Es erwarten euch noch eine Reihe von Aufgaben, bevor ihr tatsächlich dieses Paket in die offiziellen Repos hochladen dürft. Für eine lokale und private Version reichen diese Schritte aber aus.
Der Cube Server Lister lässt sich schließlich mit csl starten. Unter Einstellungen müsst ihr noch den Pfad zur ausführbaren Sauerbraten-Datei setzen (/usr/games). Um ein Update vom Masterserver zu bekommen, einfach F5 drücken.

QStat ist Quakestat und ist ein Muss für jeden Spieleserver

Es gibt ein paar Programme von denen man praktisch gar nichts hört, wenn man nicht tief in der speziellen Materie drinsteckt. Kommt man mit Spieleservern in Kontakt, stößt man zwangsläufig auf Qstat, mit dem sich auf der Konsole der Status des Servers abfragen lässt.
Da QStat auch der Name eines POSIX-Kommandos ist, heißt QStat bei Debian und Co. Quakestat und macht deutlich, wo die Wurzeln dieses Programms liegen. Die Anfänge reichen zurück in die 90iger Jahre und seit 2002 befindet sich QStat auch auf Sourceforge. Obwohl die Entwicklung mit den Jahren sich verlangsamt hat, gibt es immer noch Verbesserungen und Neuheiten, die vor allem in der Entwicklerversion sichtbar werden. Da aber die letzte Veröffentlichung schon wieder zwei Jahre her ist, gab es bis dato auch noch nichts Neueres in Debian.
Ich habe mich deshalb daran gemacht und die aktuellste SVN-Version “ausgecheckt” und mir ein aktualisiertes Debianpaket gebaut. Zu meiner Freude kann ich sagen, dass es funktioniert und ich mit der neuen Version nun auch Teeworlds und Cube2:Sauerbraten-Server abfragen kann. Das Ergebnis habe ich mit Munin auf der Statistikseite dargestellt.
Mein Ziel ist es dieses Paket noch weiter zu verbessern und die Richtlinien für Debianpakete zu erfüllen. In den nächsten Wochen werde ich einen Wishlist-Bug für das Paket abschicken, mit der Bitte noch vor dem Freeze von Wheezy das aktuelle QStat-2.11 zu aktualisieren. Vielleicht habe ich auch Glück und es gibt in den nächsten Monaten tatsächlich noch ein “echtes” Release.
Die groben Schritte zum Bauen von Qstat-2.12 waren.

  1. Aus Subversion auschecken.

    svn co https://qstat.svn.sourceforge.net/svnroot/qstat qstat

  2. Offizielle QStat-Quelldateien von Debian herunterladen.
    apt-get source qstat
  3. Den Debian-Ordner einfach in das neue QStat-SVN-Verzeichnis kopieren. Quilt3.0-Format sei Dank.
  4. Teeworlds mit Hilfe von Quilt patchen. Den Patch gibt es hier. Lesenswerte Dokumentation zu Quilt findet sich im Debian Wiki und bei Quilt for Debian Maintainers.
  5. Abhängigkeiten installieren.
    aptitude install build-essential autoconf automake autotools-dev
  6. Autogen.sh-Skript im Quellordner ausführen, Quellpaket neu bauen und anschließend mit einer der Debian-Methoden wie z.B. dpkg-buildpackage übersetzen.

Wer mein selbst gebautes QStat-2.12 gebrauchen kann, darf mich gerne anschreiben oder hier eine Nachricht hinterlassen, ich schicke es gerne zu.
Die Bedienung von QStat ist ziemlich einfach. In der neueren Version genügt folgender Befehl, um meinen OpenArena-Server abzufragen.
quakestat -openarenas 134.0.24.218:27961
In der aktuellen Version 2.11 müsst ihr in die /etc/qstat.cfg noch folgendes eintragen.

gametype OA081S new extend Q3S
name = Openarena Server 081
template var = OA081S
game rule = gamename
end
gametype OA081M new extend Q3M
name = Openarena Master
default port = 27950
master for gametype = OA081S
master protocol = 71
end

Der Server meldet den Status dann mit
quakestat -oa081s 134.0.24.218:27961
Als Ergebnis erscheint z.B. so eine Zeile.

ADDRESS PLAYERS MAP RESPONSE TIME NAME
134.0.24.218:27961 4/16 0/0 kaos2 21 / 0 Einherjer Europe Public FFA

Der “Trick” ist es mit einem Munin-Plugin die Zahlenwerte für die Spieler regelmäßig abzugreifen, womit sich dann ein Graph mit der Anzahl der Spieler erstellen lässt. Thema für einen anderen Beitrag.

ConnochaetOS: Neue Software mit PKGBUILD selbst kompilieren

Ein Nachteil bei kleineren Linuxdistributionen ist, dass sie oftmals auf nur wenige Entwickler zurückgreifen können. Außerdem sind Webspace, Traffic und Zeit begrenzt und es fehlt einfach an Ressourcen, um jede verfügbare Software in einem Binärformat bereitstellen zu können.
Man kann dieses Problem in der Regel umgehen, indem man Werkzeuge wie Debians Alien oder Slitaz tazpkg benutzt, um Pakete fremder Distributionen in das eigene Format umzuwandeln. Das klappt bei kleineren Paketen oft sehr gut, man darf aber aber auch keine Wunder von so einer Transformation erwarten.
Bei Arch Linux und damit auch ConnochaetOS macht es keinen Sinn fremde Pakete umzuwandeln. Benutzer von Arch Linux werden mir sicher zustimmen, dass das Erstellen eigener Archpakete mit Hilfe von makepkg und dem Arch Build System(ABS) eine unkomplizierte Sache ist.
Um Pakete für ConnochaetOS zu bauen, empfand ich es am einfachsten mir das ABS zu installieren und die dort bereitgestellten PKGBUILDs an meine Bedürfnisse anzupassen.
pacman -S abs
pacman -S base-devel
Führt man danach als Benutzer root abs in einem Terminal aus, wird das Verzeichnis /var/abs mit den PKGBUILDs der verschiedenen Repos core, extra und community gefüllt. Die PKGBUILDs der Software befinden sich im namensgleichen Verzeichnis, welches nur noch auf den Rechner mit ConnochaetOS kopiert werden muss oder auch gleich an Ort und Stelle benutzt werden kann.
In meinem Fall wollte ich drei meiner Favoriten mtPaint, Irssi und C* Music Player für die i586 Architektur und ConnochaetOS übersetzen. Dazu genügt es, das sogenannte ARCH-Feld um den Eintrag ‘i586’ zu erweitern.
Für Irssi war das schon der einzige Trick. Mit
makepkg -s
im Verzeichnis, wo auch das PKGBUILD liegt, konnte ich dann das Paket kompilieren und mit
pacman -U Name_des_Pakets.tar.xz
installieren.
Beim C* Music Player alias cmus brauchte ich hingegen noch die Bibliothek libao und musste libpulse und libmpg als Abhängigkeiten streichen. Auf dem Thinkpad 600 benutze ich sowieso ausschließlich ALSA.
Für mtPaint wurde noch die Bibliothek lcms2 benötigt, die ich zum erfolgreichen Kompilieren zuerst übersetzen und installieren musste. Kurz zusammengefasst muss man also lediglich Pakete für i586 kompilieren und ggf. Abhängigkeiten entfernen, die man sowieso nicht gebrauchen kann. Zum Schluss kann man dann jedes beliebige Programm auch mit ConnochaetOS benutzen. Einziger Nachteil: Man muss sich in Zukunft um die Updates selbst kümmern.

Ihr könnt alle PKGBUILDs und auch noch ein paar zusätzliche von KMandla mit Hilfe des folgenden Links herunterladen.
ConnochaetOS_PKGBUILDs.tar
Hier ist noch ein PKGBUILD-Beispiel mit Irssi:

# $Id: PKGBUILD 125226 2011-05-25 19:11:10Z foutrelis $
# Maintainer: Giovanni Scafora <giovanni@archlinux.org>
# Contributor: Dan McGee <dan@archlinux.org>
pkgname=irssi
pkgver=0.8.15
pkgrel=5
pkgdesc="Modular text mode IRC client with Perl scripting"
arch=('i586')
url="http://irssi.org/"
license=('GPL')
depends=('glib2' 'openssl' 'perl')
optdepends=('perl-libwww: for the scriptassist script')
backup=(etc/irssi.conf)
source=(http://irssi.org/files/${pkgname}-${pkgver}.tar.bz2)
options=('!libtool')
md5sums=('1dcb3f511b88df94b0c996f36668c7da')
build() {
  cd "${srcdir}/${pkgname}-${pkgver}"
  ./configure --prefix=/usr
              --enable-ipv6
	      --with-proxy
	      --sysconfdir=/etc
	      --with-perl-lib=vendor
  make
  make DESTDIR="${pkgdir}" install
}

Mehrere Pbuilder und Hooks: rxvt-unicode-256color von Debian Sid nach Squeeze backporten

Mit Pbuilder wollte ich noch den Terminalemulator rxvt-unicode-256color von Debian Sid nach Debian Squeeze zurückporten. Dabei sind ein paar Probleme aufgetreten und die Lösungen zum Nachschlagen habe ich hier verewigt.
Wie ich hierhin gekommen bin, habe ich in den Artikeln zum Paketbau mit Debian, Mplayer für den Framebuffer, einen Backportversuch mit Pbuilder und den Beitrag zum maßgeschneiderten DWM-Fenstermanager niedergeschrieben. Du kannst dich natürlich auch sofort in die Details stürzen.
Nachdem ich DWM und Surf erfolgreich mit pbuilder kompiliert und in ein Deb-Paket verschnürt hatte, machte ich guten Mutes mit rxvt-unicode-256color weiter. Das Paket ließ sich ebenfalls problemlos übersetzen, doch als ich es auf dem Thinkpad mit Debian Squeeze installieren wollte, fehlte mir eine aktuellere Abhängigkeit von ncurses-term.
Um aber ncurses-term erfolgreich zu bauen, brauchte ich wiederum die aktuelle Version von debhelper aus dem offiziellen Backports-Archiv.

Wie man einen Backport von rxvt-unicode-256color erstellt

apt-get source rxvt-unicode-256color
apt-get source ncurses-term

Randbemerkung: Beim Verändern meiner Tastaturbelegung mit xmodmap habe ich einen 5 Jahre alten Debian Bug ausgegraben. Scheinbar löst die Tastenkombination Strg+Shift ein ISO14755 Feature aus und ein nicht zu übersehendes Rechteck wird auf dem Bildschirm angezeigt. Der Bug ist wohl in rxvt-unicode-lite behoben, in 256color aber absichtlich nicht.
Das Verhalten lässt sich ausschalten, indem man die Option –enable-iso14755 in debian/rules auf –disable-iso14755 setzt. Quellpaket danach mit dpkg -b source aktualisieren!

Kopiert man dann die unten beschriebenen Skripte bzw. Konfigurationsdatei an die richtige Stelle lassen sich DEB-Pakete für i386 und Squeeze mit dem folgenden Befehl bauen. Beim ersten Mal noch --override-config anhängen, damit die geänderte config eingelesen wird!
ARCH=i386 DIST=squeeze pbuilder build ncurses_5.9-4.dsc
ARCH=i386 DIST=squeeze pbuilder build rxvt-unicode_9.12-1.dsc
Die fertigen Pakete befinden sich danach in /var/cache/pbuilder/squeeze-i386/result
Die folgenden Skripte und Konfigurationen wurden mit geringen Änderungen aus dem Pbuilder Howto auf ubuntu.com übernommen. Empfehlenswert zum Nachlesen! Außerdem hilft man pbuilder weiter.
Hat man Pbuilder einmal so eingerichtet, lassen sich damit auch von einem Debiansystem Pakete für Ubuntu und umgekehrt erstellen, womit man ab sofort Software für 2/3 aller Linuxdistributionen leicht selbst übersetzen kann. 😉

Hooks

apt-preferences

Mit sogenannten Hooks lässt sich Pbuilder dazu bewegen, gewisse Prozesse und Abläufe mit Hilfe von Skripten automatisch während des Paketbaus oder davor und danach auszuführen. Mein Hook-Verzeichnis ist /var/cache/pbuilder/hook.d
Mit dem folgenden ausführbaren Skript E01apt-preferences wird den Paketen debhelper und lintian aus dem offiziellen Backport-Archiv eine höhere Pin-Priorität zugewiesen als den regulären Squeeze-Paketen. Damit werden beide Pakete automatisch aus Backports installiert, falls diese angefordert werden. Apt-Pinning hatte ich schon einmal allgemein vorgestellt, diese Methode hier demonstriert das Anpinnen von zwei spezifischen Paketen in /etc/apt/preferences innerhalb der Build-Umgebung von Pbuilder.

#!/bin/sh
set -e
STABLE_VERSION_REGEX='^6.0.[0-9]+$'
if $(cat "/etc/debian_version" | grep -q -e "$STABLE_VERSION_REGEX"); then
cat > "/etc/apt/preferences" << EOF
Package: debhelper
Pin: release a=squeeze-backports
Pin-Priority: 999
Package: lintian
Pin: release a=squeeze-backports
Pin-Priority: 999
EOF
fi

Es wird empfohlen das Verwenden von Backports auf das absolut notwendige Minimum zu begrenzen und so weit es geht auf die reinen Squeeze-Pakete zurückzugreifen.

Eine Shell ausführen, wenn das Bauen fehlschlägt

Das Skript wird als C10Shell in /var/cache/pbuilder/hook.d abgespeichert. Laut Pbuilder-Howto soll es für alle ausführbar sein (a+x). Ich muss hier in Zukunft einmal genauer nachforschen, ob das tatsächlich immer notwendig ist und ob man Pbuilder auch problemlos im User Mode Linux (UML) betreiben kann.

#!/bin/sh
# Shell aufrufen, wenn das Bauen fehlschlägt
apt-get install -y --force-yes vim less bash
cd /tmp/buildd/*/debian/..
/bin/bash < /dev/tty > /dev/tty 2> /dev/tty

Multiple Pbuilder und Archive: Konfiguration für pbuilderrc

HOOKDIR="/var/cache/pbuilder/hook.d/"
OTHERMIRROR="deb http://backports.debian.org/debian-backports squeeze-backports main"
# Codenamen für die verschiedenen Debian Versionen.
# Einfach editieren, falls die Codenamen sich in Zukunft ändern
UNSTABLE_CODENAME="sid"
TESTING_CODENAME="wheezy"
STABLE_CODENAME="squeeze"
STABLE_BACKPORTS_SUITE="$STABLE_CODENAME-backports"
# Liste der Debian Versionen.
DEBIAN_SUITES=($UNSTABLE_CODENAME $TESTING_CODENAME $STABLE_CODENAME
    "unstable" "testing" "stable")
# Liste der Ubuntu Versionen.
UBUNTU_SUITES=("natty" "maverick" "lucid" "karmic" "jaunty" "intrepid" "oneiric")
# Debian-Spiegel
DEBIAN_MIRROR="ftp.de.debian.org"
UBUNTU_MIRROR="mirrors.kernel.org"
# Falls die Version nicht zu ermitteln ist, durchsuche das Changelog nach Hinweisen
if [ -z "${DIST}" ] && [ -r "debian/changelog" ]; then
    DIST=$(dpkg-parsechangelog | awk '/^Distribution: / {print $2}')
    # Benutze die Unstable Version für bestimmte Versions Werte
    if $(echo "experimental UNRELEASED" | grep -q $DIST); then
        DIST="$UNSTABLE_CODENAME"
    fi
    # Benutze die Stable Version für Backports.
    if $(echo "$STABLE_BACKPORTS_SUITE" | grep -q $DIST); then
        DIST="$STABLE"
    fi
fi
# Optional: Standard Distribution/Version angeben
# z.B (${DIST:="unstable"}).
: ${DIST:="$(lsb_release --short --codename)"}
# Optional: Debians generische Namen(stable, testing, unstable) in die jeweiligen Codenamen umändern
case "$DIST" in
    unstable)
        DIST="$UNSTABLE_CODENAME"
        ;;
    testing)
        DIST="$TESTING_CODENAME"
        ;;
    stable)
        DIST="$STABLE_CODENAME"
        ;;
esac
# Optional: Die Standardarchitektur angeben. Z.B. (${ARCH:="i386"}).
: ${ARCH:="$(dpkg --print-architecture)"}
NAME="$DIST"
if [ -n "${ARCH}" ]; then
    NAME="$NAME-$ARCH"
    DEBOOTSTRAPOPTS=("--arch" "$ARCH" "${DEBOOTSTRAPOPTS[@]}")
fi
BASETGZ="/var/cache/pbuilder/$NAME-base.tgz"
# Optional: BASEPATH (und nicht BASETGZ) setzen, wenn man cowbuilder benutzt
# BASEPATH="/var/cache/pbuilder/$NAME/base.cow/"
DISTRIBUTION="$DIST"
BUILDRESULT="/var/cache/pbuilder/$NAME/result/"
APTCACHE="/var/cache/pbuilder/$NAME/aptcache/"
BUILDPLACE="/var/cache/pbuilder/build/"
BINDMOUNTS="/var/cache/archive"
if $(echo ${DEBIAN_SUITES[@]} | grep -q $DIST); then
    # Debian configuration
    MIRRORSITE="http://$DEBIAN_MIRROR/debian/"
    COMPONENTS="main contrib non-free"
    DEBOOTSTRAPOPTS=("${DEBOOTSTRAPOPTS[@]}" "--keyring=/usr/share/keyrings/debian-archive-keyring.gpg")
    #OTHERMIRROR="deb file:///var/cache/archive $DIST/"
elif $(echo ${UBUNTU_SUITES[@]} | grep -q $DIST); then
    # Ubuntu configuration
    MIRRORSITE="http://$UBUNTU_MIRROR/ubuntu/"
    COMPONENTS="main restricted universe multiverse"
    DEBOOTSTRAPOPTS=("${DEBOOTSTRAPOPTS[@]}" "--keyring=/usr/share/keyrings/ubuntu-archive-keyring.gpg")
   #OTHERMIRROR="deb file:///var/cache/archive $DIST/"
else
    echo "Unknown distribution: $DIST"
    exit 1
fi

Einen maßgeschneiderten dwm-Fenstermanager von sid nach squeeze backporten

Obwohl ich denke, dass der Fenstermanager dwm in der Standardkonfiguration schnell zu erlernen und außerdem schlicht und ressourcensparend ist, wollte ich dennoch 2-3 Dinge verändern. Da Veränderungen bei dwm nur durch eine Neukompilierung möglich sind, habe ich die Gelegenheit genutzt und mich wieder etwas mehr mit der Erstellung eigener Debianpakete beschäftigt.
Ich hatte in dem Beitrag “Wie man Debian Pakete aus den Quellen baut” mehrere Methoden vorgestellt, wie man eigene Software speziell für Debian kompilieren kann. Die Pbuilder-Methode gefiel mir davon am besten. Erfolgreich wurde damit ein Mplayer nur für den Framebuffer und auch schon ein paar kleinere Backports erstellt.
Bevor ich meinen Weg zum Kompilieren und Anpassen von dwm vorstelle, wollte ich noch auf eine Alternative hinweisen. Im englischen Forum auf forums.debian.net gibt es schon eine sehr ausführliche Anleitung zum Kompilieren und Konfigurieren von dwm, die den Standardweg mit make und den Debian-Weg mit dpkg-buildpackage zeigt. Wie auch immer, ich denke Pbuilder ist noch einfacher.

Der elegante Weg mit pbuilder

Vorbereitung

aptitude install pbuilder
pbuilder create --distribution squeeze
oder wenn man z.B. i386-Pakete mit seinem AMD64-System bauen möchte
pbuilder create --distribution squeeze --debootstrapopts --arch --debootstrapopts i386

Quellen freischalten

deb-src http://ftp.de.debian.org/debian/ sid main in /etc/apt/sources.list hinzufügen.
Als normaler Benutzer das Quellpaket herunterladen und in das Quellverzeichnis wechseln.
apt-get source dwm
cd dwm-5.9/

Zwei Möglichkeiten

Möglichkeit 1

cp config.def.h config.h
vim config.h

Möglichkeit 2

cp config.def.h debian/local/config.apo.h
vim config.apo.h
Das Debian-Quellpaket bietet zum einen die Möglichkeit die Konfigurationsdatei wie gewohnt im Hauptverzeichnis editieren zu können oder aber im Debian-Verzeichnis. Der Paketverwalter von dwm hat hierzu einige Regeln angepasst, so dass beim Kompilieren auch alle Dateien im Verzeichnis debian/local in der Form config.*.h berücksichtigt werden.
Das hat später den enormen Vorteil, dass man gleichzeitig verschiedene Versionen von dwm übersetzen und später mit Debians update-alternatives Mechanismus auswählen kann.

Konfiguration

Ich habe die zweite Möglichkeit gewählt und die config Datei in debian/local namens config.apo.h modifiziert und folgende Dinge geändert.

  1. Farbe von hellblau auf dunkelgrau ändern
    static const char selbordercolor[] = "#333333";
    static const char selbgcolor[] = "#333333"; 
  2. Anzahl der Tags von 9 auf 6 verringern
    static const char *tags[] = { "1", "2", "3", "4", "5", "6", };
    
  3. Anstelle der ALT-Taste die Super/Windows-Taste benutzen
    #define MODKEY Mod4Mask
  4. rxvt-unicode anstatt xterm benutzen
    static const char *termcmd[] = { "urxvtc", NULL };

Das war es auch schon. Mir war insbesondere der Wechsel von xterm zu rxvt-unicode und von ALT zu Mod4 wichtig, da es einige Programme gibt, bei denen die voreingestellte ALT-Taste zu Problemen führen kann.

Kompilieren

Das Quellpaket aktualisieren

dpkg-source -b dwm-5.9/

Als Benutzer root ausführen

pbuilder build dwm_5.9-1.dsc
Das fertige I386-Squeeze-Paket fällt in /var/cache/pbuilder/result heraus und muss danach nur noch auf dem Zielrechner mit dpkg -i dwm_5.9-1_i386.deb installiert werden.
Mit dem Befehl update-alternatives --config dwm lässt sich danach zwischen der Standardversion, der dwm.web und der dwm.apo Version umschalten.

Fazit

Ich denke die Pbuilder-Methode sollte man sich aus mehreren Gründen beim Bauen von Debianpaketen merken. Zum einen lässt sich damit in einer “Reinraum-Umgebung” ein Paket sauber kompilieren. Man kann auf einer AMD64-Maschine mit Debian Unstable I386-Pakete für Debian Stable bauen und darüber hinaus sogar mehrere Pbuilder-Umgebungen parallel installieren, in denen Pakete für Testing, Unstable oder auch Ubuntu gebaut werden können!
Beachten sollte man aber, dass dieser Backport noch nicht den offiziellen Ansprüchen genügt. Insbesondere wurde das Paket nicht richtig umbenannt, das Changelog nicht geändert oder persönlich mit GnuPG signiert. Aber für den privaten Hausgebrauch sollte es reichen. 😉
Als optionale Ziele hatte ich mir noch vorgenommen surf, den minimalistischen Webkit-Browser aus der Suckless-Familie, und rxvt-unicode-256color “backzuporten”, da es für beide keine Version in Squeeze gibt.
Kurz gesagt: Surf lässt sich genauso einfach von Sid nach Squeeze backporten, er funktioniert auch, es gibt aber einen schweren Bug beim Aufruf von Https-Seiten, der so mit Debian Unstable nicht auftritt. Backports sind also unter Umständen gar nicht so schwierig, man sollte aber immer auch im Hinterkopf behalten, das Probleme nicht nur beim Übersetzen auftreten können. Mehr Details zu rxvt-unicode-256color und dwm demnächst auf diesem Kanal.

Automatischer Paketbau mit dem Build Service von OpenSUSE

Wer keine Lust hat eine vollständige Entwicklungsumgebung aufzusetzen, aber dennoch gerne eigene Softwarepakete erstellen möchte, kann auf einen Dienst der Linuxdistribution OpenSUSE zurückgreifen. Mit diesem ist es möglich Pakete für verschiedene RPM-basierte Distributionen und auch für Debian oder Ubuntu zu erstellen.
Es genügt, wenn man sich auf https://build.opensuse.org mit Nick und E-Mail registriert. Anschließend hat man Zugriff auf ein eigenes Konto, mit welchem sich eigene Projekte realisieren lassen. Das webgestützte Interface hat mir auf Anhieb gut gefallen. Nachdem man sich für sein neues Paket einen Namen und eine Beschreibung ausgedacht hat, kommt man auch schon sofort zum wesentlichen Teil.
Auf der “Sources”-Seite müssen alle notwendigen Dateien zum Bauen eines eigenen Debianpakets hochgeladen werden. Im Grunde genommen sind das die wichtigen Steuerungs- und Kontrolldateien aus dem mit dh-make erstellten Debian-Ordner innerhalb des Quellpakets. Diese müssen, um vom Buildservice verarbeitet werden zu können, zuerst wie folgt umbenannt werden.

debian.changelog
debian.compat
debian.control
debian.rules
debian.install

Ebenfalls möglich ist es, Dateien direkt aus dem Internet herunterladen zu lassen oder ein Tar-Paket in ein anderes Format zu komprimieren. Sind diese Vorbereitungen getroffen, fehlt nur noch die DSC-Datei und das eigentliche Quellpaket im gepackten Tar-Format. Als Alternative lässt sich auch das komplette Paket-Version-debian.tar.gz mit Quellverzeichnis und der DSC-Datei laut der offiziellen Anleitung hochladen. Letztere Methode hat den Vorteil, dass man auf ein debianisiertes Quellpaket zurückgreifen kann und somit nur noch diese Dateien zum Buildservice hinzufügen muss, was ziemlich praktisch ist.

Wie der Screenshot zeigt, habe ich mich an dem kleinen Texteditor Nano wieder einmal probiert. Eine gute Wahl, wenn man sich in die Materie vortasten will. Nachdem die drei Dateien hochgeladen waren, begann die Virtuelle Maschine, eine XEN Lösung übrigens, automatisch mit der Erstellung der Build-Umgebung, Auflösen der Abhängigkeiten und dem anschließenden Kompilieren. Ich musste danach nur noch die fertigen Deb-Pakete herunterladen.
Praktisch an dem Build Service ist, dass man parallel für unterschiedliche Distributionen und Architekturen Pakete bauen kann. Außer Webzugang und einem Konto gibt es keine weiteren Voraussetzungen. Das gesamte Angebot eignet sich besonders für Entwickler, die ihre Software auf mehreren Plattformen testen wollen, ohne dabei privat mehrere verschiedene Entwicklungsumgebungen installieren zu wollen. Für mich als Nicht-Entwickler ist es dagegen einfach eine bequeme Möglichkeit zum Experimentieren und Dazulernen. Abgesehen davon, dass das zugrundeliegende Rahmenwerk für den Build Service Freie Software ist, zeigt es auch, dass sich verschiedene Linuxdistributionen mit ihrer Infrastruktur gegenseitig ergänzen können.
Von wegen immer: Mein Linux ist besser als deins. 😛

Ein Versuch: Debian-Pakete mit pbuilder backporten

Wie schwierig konnte es schon sein ein Debian-Paket von Sid nach Squeeze zu “backporten“. Ich kramte mal wieder Debians Netzinstallation hervor und installierte mir ein 64 bit Debian. Anschließend machte ich ein Upgrade auf Sid und wollte nun i386-Pakete für Squeeze bauen.
Ich habe mich für die “Pbuilder”-Methode entschieden. Mit Pbuilder lässt sich eine komplette Entwicklungsumgebung in eine spezielle Chroot-Umgebung einschließen und jeder Paketbau läuft unter kontrollierten Bedingungen ab.
pbuilder create --distribution squeeze --debootstrapopts --arch --debootstrapopts i386
Mit dem oben stehenden Kommando wird Pbuilder angewiesen eine Umgebung auf Basis von Squeeze und der i386-Architektur zu erstellen. Die weiteren Optionen, die in der offiziellen Doku zu Pbuilder stehen, brauchte ich nicht.
Anschließend kann man sich mit dem normalen Benutzer die Quellpakete, die man übersetzen möchte, herunterladen.
apt-get source nano cmus
Mit root Rechten wechselt man daraufhin zu den heruntergeladenen Quellpaketen und weist Pbuilder an das Paket in der Chroot-Umgebung zu bauen.
pbuilder build Paketname.dsc
Das Ergebnis viel unterschiedlich aus. Relativ kleine Pakete mit wenig Abhängigkeiten wie Nano oder slurm ließen sich problemlos übersetzen. Hier hatte ich am Ende tatsächlich ein fertiges Paket, welches ich auf jedem Debian Squeeze installieren konnte.
Problematisch wird es nur bei Software, die viele Abhängigkeiten mit anderen Paketen hat. In Squeeze entsprechen natürlich viele Pakete nicht mehr dem aktuellen Stand. Hier muss man also zuerst alle Abhängigkeiten übersetzen, bevor man anfängt das eigentliche Paket zu kompilieren.
Mit Hilfe eines “Local Repository” wird beim Bauen der Pakete dann nicht mehr nur auf die offiziellen Debianpakete verwiesen, sondern man kann lokal Abhängigkeiten bauen, auf die pbuilder Rücksicht nehmen wird. Mit diesem kleinen “Trick” lassen sich auch komplexere Pakete backporten.
Ich stehe hier zwar selbst noch am Anfang, weiß aber nun, wo ich suchen muss, wenn ich tatsächlich mal unbedingt ein brandaktuelles Softwarepaket nach Debian Stable bringen möchte. Immerhin ist mir nun klarer geworden, wo die Schwierigkeiten bei Backports liegen und was Raphael Hertzog mit dem Satz meinte: “Gnome 3 in Squeeze? – No sorry“.