... oder auch: immer schön sauber bleiben
Vorwort
Wer Debian einsetzt, tut dies, weil er das Paketsystem und die Updatepolitik für das Beste hält, was es unter Linux gibt. Warum also beim VDR darauf verzichten und das System durch selbstübersetzte Pakete verunreinigen?
Deshalb habe ich nach einem Weg gesucht, selbst Pakete übersetzen zu können, ohne die geniale Paketverwaltung von Debian umgehen zu müssen. Ganz klar – ein Entwicklungssystem braucht nur, wer auch am VDR entwickeln will – also z.B. ein Plugin bauen oder anpassen. Wer das nicht vorhat, braucht überhaupt nichts zu übersetzen.
Mit etwas Sinn für Ordnung lässt sich so ein Entwicklungssystem relativ einfach aufsetzen und warten. Andererseits ist der Paketbau unter Debian alles andere als trivial. Deshalb habe ich an einigen Stellen Zugeständnisse an die 2-Gleisigkeit des VDR, sowie an mein fehlendes Wissen gemacht.
Diese Beschreibung soll dabei helfen, ein sauberes Entwicklungssystem und ein schlankes Produktivsystem synchron pflegen zu können.
Sie ist eine Mischung aus Kilroys Howto, Auszügen aus dem Wiki, den Beschreibungen von wbreu, Tips von hummingbird_de und natürlich eigenen Erfahrungen - das Ganze ausprobiert und in die richtige Reihenfolge gebracht. Selbstverständlich bedanke ich mich auch bei allen, die geholfen haben und die ich jetzt vergaß zu erwähnen!
Hinweise zu Hintergrundinformationen finden sich am Ende der Beschreibung.
Wer allerdings den Computer-Desktop auf den Fernsehr bringen will, wird vermutlich von dieser Beschriebung enttäuscht. Hier geht es - NUR - darum, HD-Fernsehen und HD-Aufnahmen zu ermöglichen. Der Rest soll am Computer bleiben.
Viele Miniboards haben keinen Anschluss mehr für Floppy oder PATA-Laufwerke – da bietet sich ein USB-Stick als Installationsmedium geradezu an. Mit unetbootin (http://unetbootin.sourceforge.net) lässt sich ein bootbarer USB-Stick einrichten. Bei Debian stable gibt es unetbootin noch nicht als Paket, aber es lässt sich recht einfach bauen: http://sourceforge.net/apps/trac/unetbootin/wiki/compile
Wer viel mit USB-Stick Installationen experimentiert, dem wird es sicher auch mal passieren, dass grub auf dem Stick anstatt auf der Festplatte installiert wird. Danach wird es unentspannt mit dem Stick zu booten – denn er wird vom BIOS bereits als Festplatte erkannt und eingebunden. Da hilft nur ein beherztes
(/dev/sdx gegen das Device des Sticks austauschen). Danach wird der Stick wieder als Bootmedium akzeptiert.
Noch ein Hinweis zu den Skripten, die nebenbei erzeugt werden. Wenn in einem Skript Variablen verwendet werden (Text bei dem $ der erste Buchstabe ist), werden die gelöscht oder ersetzt, wenn per copy/paste in der Befehlszeile gearbeitet wird.
Wird statt dessen der vi mit dem Dateinamen geöffnet und mit i der Eingabemodus aktiviert, kann das Skript per copy/paste per Umschalt+Einfügetaste übernommen werden.
Grundinstallation (für Produktiv-VDR und Entwicklungssystem gleichermaßen)
Zum Zeitpunkt des Schreibens gab es keine Installationsmedien für Debian-Sid, weshalb die Installation mit Stable-Netinst erfolgt und später auf Sid gewechselt wird.
Also mit Netinst booten und dem Installer folgen (Sprachauswahl, etc.). Als Benutzer wird ein persönlicher Benutzer verwendet, nicht vdr (der wird später angelegt!).
Bei Softwareauswahl wird alles abgewählt (also Vorgabe von Desktop und Standard entfernen). Nach Abschluss der Installation grub installieren lassen und neu booten.
Rechner zugänglich machen
Ich arbeite am liebsten an „meinem“ Desktop, d.h. als erstes sorgen wir dafür, dass der Rechner per Fernwartung bedient werden kann. Um halbwegs sicher zu sein, verwenden wir ssh.
Wer Produktiv und Entwicklungssystem auf einem Rechner mit verschiedenen Partitionen betreibt, mag vielleicht mit statischen IP-Adressen arbeiten, wobei Produktiv- und Entwicklungssystem unterschiedliche Adressen bekommen. Danach kann die Konsole mit exit geschlossen werden. Den Rest erledigen wir aus der Ferne, von unserem Desktop aus.
Versionswechsel
Per ssh verbinden wir uns jetzt mit dem Rechner. Wer mag, kann gleich die .bashrc an seine Vorlieben, bzw. seinen Geschmack anpassen. Bei mir gibt es folgende Einträge:
Zuerst aktiviere ich die Farbausgabe für ls:
Dann gibt es ein paar Kürzel für nützliche ls-Varianten (ll – für die Langform, la für die Langform mit versteckten Dateien und ltr für die zeitlich sortierte Langform):
Jetzt folgen ac für die Debian-Paketsuche, ai zum Installieren, ii für die Prüfung, ob ein Paket bereits installiert ist und pi für die Paketinfo.
alias c='clear'
alias ac='apt-cache -n search'
alias ai='apt-get install'
alias ii='dpkg -l | grep -i'
alias pi='apt-cache show'
alias dist-upgrade='apt-get update && apt-get dist-upgrade'
Aktiviert werden die neuen Einstellungen über
Danach widmen wir uns wieder der Grundinstallation:
Dazu werden in der Datei /etc/apt/sources.list alle Vorkommnisse von lenny gegen sid ausgetauscht. Die Einträge von security.debian.org und [/font]volatile.debian.org[/font] werden auskommentiert, bzw. gelöscht, da die nur für stable existieren. Somit sieht die neue sources.list etwa so aus:
deb http://ftp.de.debian.org/debian/ sid main non-free contrib
deb-src http://ftp.de.debian.org/debian/ sid main non-free contrib
Mit einem
starten wir den Versionswechsel. Wenn der durchgelaufen ist, kann mit
auf den neuen Bootmanager gewechselt werden. Wer mag, kann vorher noch booten, um zu sehen, ob's auch klappt.
Firmware für r8169
Beim Versionswechsel kommt die Warnung, dass die Firmware für r1869 fehlen würde. Der Kernel wird gerade aufgeräumt, sodass einige Firmware nach non-free musste. Laut Aussage der Debian-ML funktioniert ein Treiber auch weiterhin, der bisher getan hat.
Bei mir traf das zu – ich musste keine Firmware nachinstallieren.
Benutzer anlegen
zuerst die Gruppe vdr anlegen:
Das -system bewirkt, dass die Gruppe die Nummer < 1000 erhält. Anschließend wird noch der Benutzer vdr angelegt:
Basispakete installieren
Ich habe jetzt verschiedene Konstellationen durchgespielt und es sieht so aus, als wäre die Kombination aus nodm und fluxbox schlank und zuverlässig – deshalb für mich die erste Wahl. Vi ist meine Hausmarke, wer es nicht mag, kann ja seinen Lieblingseditor eintragen.
cat > basePkgs.list << EOF
less
alsa-utils
bzip2
xterm
xorg
nodm
x11-xserver-utils
ffmpeg
fluxbox
mc
vim
nfs-common
nfs-kernel-server
pciutils
EOF
apt-get install $( < basePkgs.list )
Alles anzeigen
Ballast abwerfen
Einige Pakete werden bei einem „normalen“ VDR nicht unbedingt benötigt. Manche Pakete werden auf dem Entwicklungssystem später wieder mit installiert, aber das ist ok so. Liste bitte überprüfen und nach eigenem Geschmack anpassen.
cat > pkgs.2remove << EOF
aptitude
dictionaries-common
ding
doc-linux-de
ghostscript
ghostscript-x
gs-common
gsfonts
info
ingerman
ispell
javascript-common
man-db
manpages
manpages-de
manpages-dev
mime-support
nano
radeontool
trans-de-en
vim-tiny
wngerman
wwwconfig-common
EOF
apt-get purge $( < pkgs.2remove )
apt-get autoremove
Alles anzeigen
Paketrepository um e-tobi und multimedia erweitern
Schlüssel für e-tobi holen und einbinden.
wget --quiet http://e-tobi.net/vdr-experimental/pool-lenny/binary/base/e-tobi-keyring_2008.03.08_all.deb
dpkg -i e-tobi-keyring_2008.03.08_all.deb
Da wir selbst bauen, kommentieren wir die deb-Zeilen aus und verwenden nur die deb-src Zeilen:
cat > /etc/apt/sources.list.d/vdr.list << EOF
# release = vdr-experimental | vdr-testing
# dist = etch | lenny | sid
# section = base | backports | addons | vdr-standard | vdr-extensions |vdr-multipatch
# wir sind nur an Quältexten interessiert ...
#deb http://e-tobi.net/vdpau-xine1.1-vdrdevel sid base vdr-multipatch
#deb http://e-tobi.net/vdpau-xine1.1 sid base vdr-multipatch
deb-src http://e-tobi.net/vdpau-xine1.1-vdrdevel sid base vdr-multipatch
deb-src http://e-tobi.net/vdpau-xine1.1 sid base vdr-multipatch
# keine amd64-Pakete
#deb http://e-tobi.net/vdrdevel-experimental lenny base vdr-multipatch
#deb http://e-tobi.net/vdr-experimental lenny addons
deb-src http://e-tobi.net/vdrdevel-experimental lenny base vdr-multipatch
deb-src http://e-tobi.net/vdr-experimental lenny base addons vdr-multipatch
EOF
Alles anzeigen
e-tobis vdr Pakete haben Priorität vor Debian Paketen ...
cat > /etc/apt/preferences.d/etobi.prefs << EOF
Package: *
Pin: release o=e-tobi.net
Pin-Priority: 1001
EOF
Schlüssel für Debian-multimedia.org holen ...
wget --quiet http://www.debian-multimedia.org/pool/main/d/debian-multimedia-keyring/debian-multimedia-keyring_2008.10.16_all.deb
dpkg -i debian-multimedia-keyring_2008.10.16_all.deb
Debian-multimedia.org einrichten
cat > /etc/apt/sources.list.d/debian-multimedia.org.list << EOF
deb http://www.debian-multimedia.org sid main
deb-src http://www.debian-multimedia.org sid main
EOF
aufräumen ...
Ab hier trennen sich die Installationswege von Entwicklungssystem und Produktivsystem. Da unser Produktivsystem von den Ergebnissen unseres Entwicklungssystems abhängt, beschäftigen wir uns zuerst mit dem Entwicklungssystem und dem Bau der eigenen Pakete.
Beim Produktivsystem wird noch ein weiteres Repository hinzugefügt, doch dazu später mehr.
Entwicklungssystem
Ein HD-Vdr ist ein komplexes Client-Server Gebilde, bei dem quasi 2 VDR Instanzen vorkommen. Bei der Entwicklung trennen wir auch auf zwischen dem Backend, also der VDR-Instanz, die die DVB-Daten empfängt, oder Aufnahmen zum Abspielen aufbereitet und dem Frontend, welches Bild und Ton ausgibt und Tastatureingaben entgegen nimmt und an das VDR-Backend weiterleitet. Front- und Backend können auf einem Rechner oder auf verschiedenen Rechnern laufen. Wenn beide Teile auf dem gleichen Rechner laufen sollen, muss dies z.B. beim Kernelbau etc. berücksichtigt werden. Ansonsten kann man jede Schiene für sich bauen.
Basispakete für die Entwicklung
cat > devBase.list << EOF
autoconf
automake
automake1.9
build-essential
ccache
checkinstall
cvs
devscripts
doxygen
gettext
git-core
git-buildpackage
kernel-package
libopenjpeg-dev
libtool
libx11-dev
libncurses-dev
mercurial
pkg-config
pristine-tar
subversion
texi2html
yasm
EOF
apt-get install $( < devBase.list )
Alles anzeigen
Backend
Das Backend braucht die DVB-S2-Treiber für den Empfang und somit einen selbstgebauten Kernel.
Kernelbau für Backend
Wir verwenden jeweils den neuesten Kernel von www.kernel.org – im Augenblick ist 2.6.32.2 aktuell.
cd /usr/src
wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.32.2.tar.bz2
tar -jxf linux-2.6.32.2.tar.bz2
cd linux-2.6.32.2
Wer neu ist im Kernelbau, fängt am Besten mit der Konfiguration des laufenden Systems an:
Dabei alle Vorgaben, bei denen man es nicht besser weiß, einfach so akzeptieren, wie sie angeboten werden. Wer mag kann die entstandene .config sichern, sodass man für die spätere Entschlackung des Kernels eine funktionierende Ausgangsbasis hat. Bei einem make mrproper (make clean für den Kernel) wird die .config gelöscht.
Jetzt wieder für alle – wir starten die Menüauswahl des Kernels und deaktivieren den kompletten Bereich „multimedia support“ unter „device drivers“.
Denn der multimedia-Bereich wird später von dem DVB-S2-Treiber abgedeckt, den wir auch selbst bauen wollen. Wenn wir den Bereich im Kernel nicht deaktivieren, kommt es später zu Konflikten.
Der Kernelbau ist eine sehr langwierige Geschichte – wer's also etwas flotter mag, kann make die Anzahl der CPUs mitteilen:
Wer vorhat regelmäßig den Kernel zu bauen, baut die Zeile am besten ins System ein:
Den Kernelbau starten wir mit:
Danach installieren wir den neuen Kernel und das Headers-Paket auch gleich mit:
Vor dem Booten kontrollieren wir, ob auch ein initrd.img-2.6.32.2-vdr angelegt wurde. An der Ecke scheint es gerade etwas zu klemmen, sodass evtl ein
nachgeschoben werden muss. Anschließend booten wir, um den Kernel zu aktivieren.
Eigenes Repository aufsetzen
Die Pakete, die wir auf dem Entwicklungssystem bauen, sollen ja wie normale Debianpakete auf dem Produktivsystem installiert werden können. Dazu packen wir alle *.deb-Dateien in eine Verzeichnis-Struktur, die von apt-get akzeptiert wird.
Ein Repository kann per ftp[1][2], http[3] oder per Dateiprotokoll veröffentlicht werden. Wenn man Entwicklungssystem und Produktivsystem auf einem Rechner (z.B. auf 2 verschiedenen Festplatten oder Partitionen) aufbaut, ist das Dateiprotokoll die einfachste Möglichkeit. Letzteres verwende ich.
Bei Debian liegen Daten, die anderen Rechnern über Dienste zur Verfügung gestellt werden unter /srv – deshalb leben wir unsere Paketquelle auch dort an. Da die Anzahl unserer selbstgebauten Pakete überschaubar bleibt, legen wir nur ein gemeinsames Pool-Verzeichnis an:
Fehlt noch eine Beschreibung für unsere Paketquelle:
cat > /srv/debian/dists/sid/Release << EOF
Origin: myself
Label: the freshest sauces around
Suite: unstable
Codename: sid
Date: Fri, 19 Dec 2009 06:00:00 UTC
Archtectures: amd64
Components: main
Description: my own vdr packages – not released
EOF
Anschließend veröffentlichen wir den Pfad unserer Paketquelle für div. Tools:
Jetzt legen wir uns noch ein script an, mit dem wir unsere Paketquelle aktualisieren können:
Den folgenden Skript-Inhalt in den Editor einfügen und mit :wq speichern.
#!/bin/sh
arch=amd64
release=sid
if [ „x$APT_REPOSITORY“ == „x“ ]; then
echo „no repository root defined! Please set APT_REPOSITORY“
exit -1
fi
echo „gonna refresh apt-repository: $APT_REPOSITORY“
cd $APT_REPOSITORY
dpkg-scanpackages pool /dev/null | gzip -9c > dists/$release/main/binary-$arch/Packages.gz
dpkg-scanpackages pool /dev/null | bzip2 > dists/$release/main/binary-$arch/Packages.bz2
Alles anzeigen
Anschließend das Skript noch ausführbar machen
Jetzt können wir es gleich ausprobieren:
export APT_REPOSITORY='/srv/debian'
cd /usr/src
mv linux-*.deb $APT_REPOSITORY/pool
update-repository
Dabei sollte der Hinweis kommen, dass 2 Pakete in Ausgabedatei geschrieben wurden.
DVB-S2-Treiber
Hier müssen wir zuerst die „alte“ Firmware rausschmeißen, sonst bricht nachher die Installation mit einem Fehler ab:
Dann bauen wir die neuen Treiber mit:
cd /usr/local/src
hg clone http://mercurial.intuxication.org/hg/s2-liplianin/
cd s2-liplianin
cd linux/include/linux
ln -s /usr/src/linux-headers-`uname -r`/include/linux/compiler.h .
cd ../../..
make -j 4
Wer eine abweichende Anzahl von CPUs hat, sollte die Ziffer nach -j daran anpassen.
Jetzt kommt die erste Änderung, die unsere eigene Paketquelle betrifft. Anstatt make install auszuführen, fangen wir alle Ausgaben ab und bauen davon ein Debianpaket. Glücklicherweise gibt es bei Debian das Hilfsmittel dazu bereits frei Haus:
checkinstall bietet die Möglichkeit, mittels --review-control sich die erzeugte control-Datei anzuschauen, da aber die Paketerstellung scheitert, wenn man die control-Datei zu diesem Zeitpunkt noch ändert, lasse ich den Parameter lieber weg. Sämtliche Einträge lassen sich über das Menü von checkinstall bearbeiten ...
Zuerst gibt es den Hinweis, dass es bei dem Paket noch keine Dokumentation gibt, verbunden mit der Frage, ob die Vorgabedoku erstellt werden soll. Hier ist y eine gute Antwort. Anschließend kann man eine Beschreibung für das zu erstellende Paket eingeben.
Wir geben hier DVB S2-Treiber vom <Datum der Erstellung> ein. Eine leere Zeile beendet die Beschreibung. Auch dieses Paket kommt in unsere Paketquelle:
Aufräumen vor dem Neubau aller Pakete
Wenn die Pakete neu gebaut werden sollen (weil sich was geändert hat oder ein Fehler auftrat), muss vorher etwas aufgeräumt werden. Bei debian-spezifischen Bau der Pakete werden Änderungen protokolliert und es werden noch weitere Dateien unter /usr/local/src erstellt. Falls ein Fehler die Ursache für den Neubau ist, könnten diese Zwischendateien für Probleme sorgen.
Deshalb setzen wir vor dem (Neu-)bau der Pakete folgenden Befehl ab:
Wichtig dabei, dass rm keinerlei Optionen erhält, insbesondere kein -r denn wir wollen ja die Verzeichnisse unterhalb von /usr/local/src behalten.
VDR für Backend bauen
Wer beim Frontend libxine-1.2 einsetzen will, sollte den Bau von xine vorziehen, denn das Plugin xineliboutput hat eine Abhängkeit auf libxine-dev. Wenn wir jetzt eine libxine-dev installieren und später beim Frontend die libxine selbst bauen – gibt es Probleme.
Da bei Quelltext-Paketen nicht zwischen den Versionen 1.6x und 1.7x unterschieden wird, schreiben wir die Pakete als vdr-Pakete und nicht als vdrdevel-Pakete – auch wenn wir letzteres wollen. Liste der Plugins bitte an eigenen Geschmack anpassen.
cat > backendPlugins.list << EOF
vdr-plugin-dvd
vdr-plugin-dvdselect
vdr-plugin-epgsearch
vdr-plugin-markad
vdr-plugin-skinelchi
vdr-plugin-xineliboutput
EOF
Damit können wir die Quelltexte ausfassen:
Gleich noch die Abhängigkeiten für den Bau der Pakete auflösen.
Beim Bau der aktuellen VDR-Pakete werden die Quältexte beim Bau verändert. Dafür benötigen wir das Skript make-special-vdr:
apt-get source make-special-vdr
cp make-special-vdr-1.4/make-special-vdr /usr/local/bin
chmod +x /usr/local/bin/make-special-vdr
Der Bau von vdr und Plugins ist ne Menge Tipparbeit – zumindest die Debian-Variante. Um Tippfehler o.ä. zu vermeiden und auch hier wiederholbare Ergebnisse zu bekommen, legen wir uns wieder ein Skript an:
Danach wieder den Skript-Inhalt in den Editor einfügen und mit :wq beenden.
#!/bin/bash
# set -x
vdr_package=`ls -l | grep ^d | awk '{ print $9; }' | grep "^vdr-1"`
vdr_plugins=`ls -l | grep ^d | awk '{ print $9; }' | grep "^vdr-plugin"`
vdr_src_dir='/usr/local/src'
debug=1
if [ "x$1" != "x" ]; then
debug=0
fi
if [ "x$APT_REPOSITORY" == "x" ]; then
echo "no repository root defined! Please set APT_REPOSITORY"
exit -1
fi
echo "gonna build $vdr_package"
if [ "x$debug" != "x1" ]; then
pkgdir="$vdr_src_dir/$vdr_package"
cd $pkgdir
PATCHVARIANT=multipatch SPECIAL_VDR_SUFFIX=devel fakeroot dpkg-buildpackage -b -uc -tc -Rmake-special-vdr
# need to install vdr immediatelly, as all plugins rely on it
cd ..
dpkg -i vdrdevel_1.7.*.deb
dpkg -i vdrdevel-dev_1.7.*.deb
fi
echo "build plugins for: $vdr_package"
for vdrpkg in ${vdr_plugins}; do
echo "gonna build $vdrpkg"
if [ "x$debug" != "x1" ]; then
pkgdir="$vdr_src_dir/$vdrpkg"
cd $pkgdir
PATCHVARIANT=multipatch SPECIAL_VDR_SUFFIX=devel fakeroot dpkg-buildpackage -b -uc -tc -Rmake-special-vdr
fi
done
if [ "x$debug" != "x1" ]; then
echo "buid done - gonna update repository ..."
cd /usr/local/src
cp *.deb $APT_REPOSITORY/pool
update-repository
fi
echo "done."
Alles anzeigen
Fehlt noch das Skript ausführbar zu machen:
Wenn das Script kontrolliert und ausführbar gemacht wurde, können wir es erst testen und dann den Bau starten:
Das Skript baut alle Pakete, kopiert sie in unsere Paketquelle und aktualisiert diese. Bei mir kommt die Meldung, dass 15 Pakete in die Ausgabedatei geschrieben wurden. Bei abweichenden Plugins ist die Zahl natürlich eine andere.
Hilfsmittel für die Kanalsuche bauen
Die Kanallisten kann man sich von irgendjemand aus dem Netz besorgen, oder man lässt den Rechner selbst rausfinden, welche Kanäle verfügbar sind. Dazu brauchen wir das Hilfsmittel von Wirbel:
cd /usr/local/src
wget http://wirbel.htpc-forum.de/w_scan/w_scan-20091118.tar.bz2
tar -jxf w_scan-20091118.tar.bz2
cd w_scan-20091118
./configure
make
Danach bauen wir uns wieder ein Päckchen:
Frontend
Das Frontend braucht z.B. die VDPAU-Treiber und ein xine-System, welches diese Treiber verwendet.
Hilfsmittel für die Kanalsuche bauen
Der Nvidia-Treiber benötigt „nur“ die Kerneldeklarationen, d.h. falls das Frontend auf einem separaten Rechner laufen soll, ist kein Kernelbau notwendig. Es genügt ein
Kernelversion ggf. an den verwendeten Kernel anpassen.
NVIDIA-Treiber installieren
Wer den Treiber nicht selbst übersetzen (lassen) will, kann den von e-tobi nehmen:
Bei wem das nicht funktioniert (Abhängkeitsproblem), oder wer den neuesten Treiber von NVidia nehmen möchte (auf Datum achten, da Nummerierung zwischen stable und unstable verschieden ist) installiert wie folgt (z.Z. ist 190.53 der aktuellste Treiber):
cd /usr/local/src
mkdir nvidia
cd nvidia
wget ftp://download.nvidia.com/XFree86/Linux-x86_64/190.53/NVIDIA-Linux-x86_64-190.53-pkg2.run
sh NVIDIA-Linux-x86_64-190.53-pkg2.run
Nach der Installation kann man über man nvidia-xconfig Informationen über die Konfigurationsmöglichkeiten des XServers erhalten. Ob der Treiber geladen und aktiv ist, kann man so rausfinden:
grep NVIDIA /var/log/syslog
... NVRM: loading NVIDIA UNIX x86_64 Kernel Module 190.53 Wed Dec 9 15:29:46 PST 2009
XServer aktivieren
Um nodm zu aktivieren, muss die Datei /etc/default/nodm angepasst werden:
Bevor wir den Xserver starten kontrollieren wir noch die /etc/X11/xorg.conf – im Abschnitt „Device“ sollte nvidia als Driver eingetragen sein. Im Abschnitt Monitor sollten die Werte von HorizSync und VertRefresh den Werten des angeschlossenen Monitors (siehe Handbuch des Monitors) entsprechen! Dann sollte noch das Composite abgeschaltet werden:
cat >> /etc/X11/xorg.conf << EOF
Section "Extensions"
Option "Composite" "Disable"
EndSection
EOF
Anschließend ein /etc/init.d/nodm start oder rebooten, je nach Gusto.
vdpinfo bauen
Wir wollen ja nicht nur Pakete übersetzen, sondern auch prüfen, ob der Bau einen Wert hatte ...
vdpinfo ist dafür da, die Installation des Nvidia-Treibers zu überprüfen.
cd /usr/local/src
wget http://www.cs.rug.nl/~wladimir/vdpinfo/vdpinfo-0.0.5.tar.gz
tar -zxf vdpinfo-0.0.5.tar.gz
cd vdpinfo
make
cp vdpinfo /usr/local/bin
Vor dem Test müssen wir noch den Xserver bekannt machen
Danach können wir den Test starten mit vdpinfo
Wenn die Fähigkeiten der Grafikkarte angezeigt werden, sollte der Nvidia-Treiber funktionieren.
VDR für Frontend bauen
Wer xine von Debian nehmen kann und mag, braucht nicht viel zu bauen.
Für das Frontend scheint es keine Unterschiede zwischen 1.6x und 1.7x zu geben. Demzufolge bauen wir ein Frontend für 1.6:
cd /usr/local/src/vdr-plugin-xineliboutput-1.0.4+cvs20091215.2049
PATCHVARIANT=multipatch fakeroot dpkg-buildpackage -b -uc -tc
cp xine*.deb $APT_REPOSITORY/pool
update-repository
Da die Ergebnisse nicht gerade berauschend waren, entschloss ich mich die xinelib1.2 auch selbst zu bauen. Dafür gibt es aber noch keine VDR-Anpassung für Debian, sodass etwas Handarbeit notwendig ist.
Bau von ffmpeg
Das Herz der meisten Videoanwendungen heißt ffmpeg und dessen Entwicklung schreitet viel schneller voran, als die ganzer Betriebssysteme. Deshalb macht es Sinn, diese Entwickelung aufzugreifen und zu integrieren. Seit ich ffmpeg selbst gebaut habe, laufen zumindest die „normalen“ Sender zufriendenstellend. Wir holen die Quellen mit
X264 ist der wichtigste Codec für HD-Video und der wird von ffmpeg verwendet. Also müssen wir den zuerst bauen. Dazu klauen wir uns die Bauanleitung vom offiziellen Debian-Paket:
apt-get source libx264
rm x264*
git clone git://git.videolan.org/x264.git
cp -a x264-0.svn20091125/debian x264/debian
rm -rf x264-0.svn*
cd x264
Anschließend laden wir die Datei debian/rules in den Editor und erweitern confflags (Zeile 30) um:
Die extra-cflags exportieren wir ins Environment und bauen das Paket:
export CFLAGS=“-mtune=native -march=native -mfpmath=sse -O4 -pipe"
fakeroot dpkg-buildpackage -uc -tc
cd ..
dpkg -i libx264-dev_0.svn20091125-0.1_amd64.deb
dpkg -i libx264-79_0.svn20091125-0.1_amd64.deb
dpkg -i x264_0.svn20091125-0.1_amd64.deb
mv {lib,}x264*.deb $APT_REPOSITORY/pool
update-repository
Genauso verfahren wir mit dem ffmpeg-Paket. Wir nehmen die Quellen von svn und klauen uns die Bauanleitung vom offiziellen Paket:
cd /usr/local/src
svn checkout svn://svn.mplayerhq.hu/ffmpeg/trunk ffmpeg.svn
cp -a ffmpeg-dmo*/debian ffmpeg.svn/debian
rm ffmpeg*
rm -rf ffmpeg-dmo*
cd ffmpeg.svn
export CFLAGS="-mtune=native -march=native -mfpmath=sse -O4 -pipe"
fakeroot dpkg-buildpackage -uc -tc
cd ..
cp *.deb $APT_REPOSITORY
update-repository
ls -tr *.deb > ~/ffmpeg.pkg.list
ls -ltr
Alles anzeigen
Wir laden die so erzeugte Liste in den Editor und entfernen alles, was nicht beim Bau von ffmpeg entstand:
Anschließend installieren wir alle erzeugten Pakete:
Bau der xinelib-1.2
Der Autor der xinelib-1.2 hat ganze Arbeit geleistet und seiner Lib bereits ein debian-Verzeichnis spendiert. Trotzdem ist das Bauen der Xine-Pakete recht komplex insbesondere im VDR-Kontext. xinelib1.2 ist noch nicht offiziell in Debian integriert, deshalb ist etwas Handarbeit notwendig.
Das Ausfassen und Patchen der Quellen ist nur das erste Mal notwendig.
cd /usr/local/src/
hg clone http://hg.debian.org/hg/xine-lib/xine-lib-1.2 xine-lib-1.2
wget http://www.jusst.de/vdpau/files/xine-lib-1.2/xine-lib-1.2-vdpau-r286.diff.bz2
bzip2 -d xine-lib-1.2-vdpau-r286.diff.bz2
wget http://durchflieger.dachsweb.de/vdpau-extensions/v11/xine-lib-1.2-vdpau-r286-extensions-v11.diff.gz
gunzip xine-lib-1.2-vdpau-r286-extensions-v11.diff.gz
cd xine-lib-1.2
patch -p1 < ../xine-lib-1.2-vdpau-r286.diff
patch -p1 < ../xine-lib-1.2-vdpau-r286-extensions-v11.diff
Vor dem Bau müssen noch die abhängigen Pakete für den Bau installiert werden. Mit
erhält man eine Liste der abhängigen Pakete. Die Ausgabe in eine Paketliste für apt-get umzuwandeln ist etwas lästig, deshalb habe ich die Liste hier aufgeführt:
cat > ~/xine.depends << EOF
libxcb-xv0-dev
libxcb-shm0-dev
libxcb-shape0-dev
libxinerama-dev
libxv-dev
libxvmc-dev
libxt-dev
libasound2-dev
libaa1-dev
libcaca-dev
libmodplug-dev
libjack-dev
libpulse-dev
libartsc0-dev
libmagick9-dev
libpng12-dev
libfreetype6-dev
libogg-dev
libvorbis-dev
libtheora-dev
libesd0-dev
libgnomevfs2-dev
liblircclient-dev
libdirectfb-dev
libgtk2.0-dev
libflac-dev
libsdl1.2-dev
libwavpack-dev
libsmbclient-dev
libspeex-dev
libmng-dev
libmad0-dev
libmpcdec-dev
libcdio-dev
libvcdinfo-dev
zlib1g-dev
w3m
xmlto
librsvg2-bin
EOF
apt-get install $( < ~/xine.depends )
dpkg-checkbuilddeps
Alles anzeigen
sollte keine Pakete mehr aufführen. Damit VDPAU auch wirklich verwendet wird, ändern wir die Datei debian/rules – dort gibt es einen Bereich CONFIGURE_FLAGS := \ bei den darauf folgenden Zeilen fügen wir eine noch hinzu (aufpassen, dass kein Leerzeichen nach dem \ am Zeilenende kommt):
Danach können wir endlich den Bau starten mit
Anschließend installieren wir die erstellten Pakete gleich und kopieren sie in unseren Paketpool:
cd /usr/local/src
for i in libxine*.deb; do dpkg -i $i; done
mv libxine*.deb $APT_REPOSITORY/pool
update-repository
VDR-Frontend für xinelib-1.2
Ein Blick in die control-Datei der neu gebauten xinelib-1.2 verrät uns, dass die lib als libxine2 firmiert. Also müssen wir unser Plugin daran anpassen. Für das Backend haben wir das xineliboutput-Plugin bereits übersetzt. Es hängt nur von libxine-dev ab, deshalb brauchen wir es jetzt nicht nochmal bauen.
Für den Bau des Frontends müssen wir allerdings die Steuerungsdatei patchen. Die Datei debian/rules laden wir in den Editor, suchen „xine:Depends“ und ersetzen libxine1 mit libxine2. Ferner ändern wir auch bei XINEPLUGINDIR das libxine1 gegen libxine2.
Die Frontends werden nur gebaut, wenn wir das Paket für vdr-1.6 bauen. Dann stimmt aber die Abhängigkeit der lib nicht, deshalb müssen wir selbst patchen. Wir sichern (nur beim ersten Mal!) die Steuerungsdatei doppelt:
cd /usr/local/src/vdr-plugin-xineliboutput-1.0.4+cvs20091215.2049
cp debian/control ~/control.xlop.backend
cp debian/control ~/control.xlop.frontend
Erste Sicherung ist dafür, falls wir das Backend nochmal bauen wollen/müssen. Die zweite laden wir jetzt in einen Editor und ändern bei der Beschreibung von libxineliboutput-sxfe in der Depends-Zeile vdr-plugin-xineliboutput (= ${binary:Version}) gegen vdrdevel-plugin-xineliboutput (>= ${binary:Version}) – gleiches machen wir für libxineliboutput-fbfe.
Anschließend ändern wir alle Vorkommnisse von xine1 in xine2:
Jetzt müssen noch die Installationsanweisungen angepasst werden:
Danach aktivieren wir unsere Änderungen mit:
Fehlt noch der Bau der Pakete:
und auch diese Pakete installieren wir umgehend
cd ..
dpkg -i libxine2-xvdr*.deb
dpkg -i libxineliboutput-sxfe*.deb
dpkg -i xineliboutput-sxfe*.deb
Zur Kontrolle schauen wir uns an, was alles von Xine installiert ist:
Es darf kein libxine1 in der Liste auftauchen! Sonst ist beim Bau was schief geganen. Die Ausgabe sollte eher so aussehen:
ii libxine-dev 1.2.0~hg-0
ii libxine2 1.2.0~hg-0
ii libxine2-dbg 1.2.0~hg-0
ii libxine2-doc 1.2.0~hg-0
ii libxine2-xvdr 1.0.4+cvs20091215.2049-2
ii libxineliboutput-sxfe 1.0.4+cvs20091215.2049-2
ii libxinerama-dev 2:1.0.3-2
ii libxinerama1 2:1.0.3-2
ii vdrdevel-plugin-xineliboutput 1.0.4+cvs20091215.2049-2
ii x11proto-xinerama-dev 1.1.2-5
ii xineliboutput-sxfe 1.0.4+cvs20091215.2049-2
Alles anzeigen
Falls doch ein libxine1 auftraucht, für jedes Paket, welches mit libxine1 anfängt ein apt-get purge absetzen und nochmal ab dem Bau der xinelib1.2 anfangen. Wer das Plugin erneut übersetzen muss/will, sollte vorher alle Dateien aus /usr/local/src die mit vdr-plugin-xine anfangen löschen.
Die eigenen Pakete testen
Bevor wir uns daran machen, das Produktivsystem hoch zu ziehen, können wir bereits am Entwicklungssystem ausprobieren, ob die gebauten Pakete funktionieren. Dafür sollte eine Budgetkarte im Entwicklungssystem vorhanden sein.
Wenn alle Pakete das erste Mal erstellt wurden, ist es nicht verkehrt, vor dem Test einmal kräftig durch zu booten
Dann prüfen wir, ob auch alle Pakete korrekt gebaut wurde und ihre Abhängigkeiten aufgelöst wurden:
cd
ls $APT_REPOSITORY/pool | grep -v linux | grep -v vdr-plugin > mystuff.list
cd $APT_REPOSITORY/pool
for i in $( < ~/mystuff.list ); do dpkg -i $i; done
Dabei sollte es keine Fehler über nicht aufgelöste Abhängigkeiten geben. Ein anschließendes
schafft Klarheit. Wenn jetzt irgendwelche Pakete installiert oder entfernt werden sollen, dann passen die Pakete noch nicht.
Gehen wir davon aus, dass alle Pakete passen ...
Dann schauen wir, ob die Budgetkarte erkannt wurde.
Die Ausgabe sollte ungefär so aussehen:
crw-rw----+ 1 root video 212, 4 22. Dez 06:00 ca0
crw-rw----+ 1 root video 212, 0 22. Dez 06:00 demux0
crw-rw----+ 1 root video 212, 1 22. Dez 06:00 dvr0
crw-rw----+ 1 root video 212, 3 22. Dez 06:00 frontend0
crw-rw----+ 1 root video 212, 2 22. Dez 06:00 net0
Daraus folgt, dass der Benutzer vdr auf jeden Fall der Gruppe video zugeordnet werden muss. Wir nehmen audio und cdrom gleich mit dazu:
Falls der vdr bereits angestartet wurde (überprüfen mit ps -ef | grep vdr), beenden wir ihn (sonst wird die DVB-Karte blockiert und die Kanalsuche scheitert):
Anschließend lassen wir uns eine Kanalliste[6] erzeugen. Vorher stellen wir sicher, dass wir uns in unserem Home-Verzeichnis befinden:
oder z.B. für Kabel Deutschland:
Da kommen schnell ein paar Hundert Kanäle zusammen. Um auch hier den Überblick zu behalten, gibt es wieder ein kleines Skript, das Ordnung schafft (sortChannels.pl). Schließlich hat jeder einen anderen Geschmack, so auch bei der Reihenfolge der Sender. Dafür kann dem Skript eine Vorgabeliste mitgegeben werden – bitte nach eigenem Geschmack anpassen.
cat > channels.preset << EOF
Das Erste
ZDF
SWR Fernsehen BW
ZDFtheaterkanal
SAT 1
RTL Television
ProSieben
kabel eins
3sat
arte
...
BAYERN 4 KLASSIK
hr2
WDR 2 Klassik
SWR 3
DELUXE LOUNGE
DELUXE RADIO
FREQUENCE JAZZ
Swiss Jazz
sunshine live
EOF
Alles anzeigen
Bei der Sortierung wird jedem Sender aus der Vorgabeliste die Zeilennummer als Wunschkanal zugeordnet. Ansonsten sortiert das Skript nach folgender Reihenfolge:
HD =>> TV =>> Radio =>> TV verschlüsselt =>> Radio verschlüsselt
Die Sender aus der Vorgabeliste bleiben in ihrer Kategorie, werden dort aber entsprechend bevorzugt eingeordnet.
Jetzt wieder den Inhalt in den Editor übernehmen und mit :wq speichern.
#!/usr/bin/perl
# This script takes a channels.conf generated from w_scan and sorts
# the channels. A preset file with channel names may be specified to
# override sort order.
# Sections: HD -> TV -> Radio -> TV crypted -> Radio crypted
# Channels of each section will be sorted by name. Entries from preset
# will be sorted respecting above sections, but overriding the sort order
# by name.
#
use strict;
use IO::File;
my $debug = 0;
my $presetFN = '/etc/vdr/channels.preset';
my (%preset, @sorted, @channels);
sub loadPreset {
my $psfn = shift;
my $fh = new IO::File;
my $line;
my $i=1;
if ($fh->open("< $psfn")) {
while ($line = <$fh>) {
chomp $line;
print('gonna process >'.$line."<\n") if $debug;
$preset{$line} = $i++;
}
$fh->close();
}
}
sub fetchChannels {
my $cfn = shift;
my $fh = new IO::File;
my $i=0;
if ($fh->open("< $cfn")) {
while (my $line = <$fh>) {
chomp $line;
my @parts = split(/:/, $line);
my ($name, $bouquet) = split(/;/, $parts[0], 2);
my $crypted = 'Y';
my $radio = 'N';
my $hd = 'N';
my $level = 999;
$crypted = 'N' if $parts[8] == 0;
$radio = 'Y' if $parts[5] == 0;
$hd = 'Y' if $name =~ /HD/;
$level = $preset{$name} if defined($preset{$name});
$level = 0 if $name =~ /HD/;
my $entry = { 'name' => $name,
'bouquet' => $bouquet,
'hd' => $hd,
'crypted' => $crypted,
'level' => $level,
'radio' => $radio,
'line' => $line };
push(@channels, $entry);
}
$fh->close();
}
}
sub tellChannels {
my $i=0;
for my $cEntry (@sorted) {
if ($debug) {
print('chn ('.$i++.') - name: '.$cEntry->{'name'}
.', bouquet: '.$cEntry->{'bouquet'}
.', crypted: '.$cEntry->{'crypted'}
.', hd: '.$cEntry->{'hd'}
.', radio: '.$cEntry->{'radio'}
."\n");
} else {
print($cEntry->{'line'}."\n");
}
}
}
sub byKeys {
$a->{'crypted'} cmp $b->{'crypted'} ||
$a->{'radio'} cmp $b->{'radio'} ||
$b->{'hd'} cmp $a->{'hd'} ||
$a->{'level'} <=> $b->{'level'} ||
uc($a->{'name'}) cmp uc($b->{'name'});
}
my $channelFile = shift;
die 'please give me a channels.conf file to sort!'."\n" if $channelFile =~ /^\s*$/;
print('have to sort '.$channelFile."\n") if $debug;
my $tmp = shift || $presetFN;
print('load preset from '.$tmp."\n") if $debug;
loadPreset($tmp);
fetchChannels($channelFile);
@sorted = sort byKeys @channels;
tellChannels();
Alles anzeigen
Auch dieses Script wird ausführbar gemacht mit
Wer die Sortier-Reihenfolge ändern will, sollte sich die Funktion byKeys anschauen (Zeile 85ff) – schon allein durch Vertauschen der Zeilen kann die Sortierung verändert werden.
Wer mag, kann die preset-Datei in /etc/vdr speichern. Dann wird sie automatisch verwendet. Ansonsten kann die preset-Datei auch als Parameter angegeben werden:
Wenn wir mit der Sichtprüfung einverstanden sind, kann die Datei dem VDR übergeben werden. Dazu prüfen wir zuerst, welche Datei vom VDR verwendet wird:
liefert bei mir: /etc/vdrdevel/channels.conf -> /var/lib/vdrdevel/channels.conf
Jetzt öffnen wir eine zweite Befehlszeile zum Entwicklungssystem und starten dort
denn der VDR, wie auch das xinelibout-Frontend schreiben ihre Meldungen in den syslog. So gewapnet starten wir den vdr mit:
Im syslog sollten wir jetzt sehen, dass alle Plugins geladen werden. Dort erfahren wir auch, dass das xineliboutput-Plugin 127.0.0.1 als Adresse verwendet und über den Port 37890 erreichbar ist.
Dann kommt ein Fehler, dass /dev/lircd nicht existiert – Kunststück, wo wir das noch garnicht installiert haben. Ansonsten sehen die Ausgaben nicht schlecht aus, sodass wir uns dem Frontend widmen können.
Wir erstellen einen eigenen XServer nur für den VDR:
cd /etc/init.d
wget http://www.gerloni.net/LinuxVDR/LinuxVDRconfig/etc/init.d/X4VDR
chmod +x /
update-rc.d X4VDR start 19 2 3 4 5 . stop 21 0 1 6 .
cat > /etc/vdrdevel/plugins/plugin.xineliboutput.conf << EOF
# Command line parameters for vdrdevel-plugin-xineliboutput
#
# For more details see:
# - /usr/share/doc/vdrdevel-plugin-xineliboutput/README.Debian
# - vdrdevel --help -Pxineliboutput
# - /usr/share/doc/vdrdevel-plugin-xineliboutput/README
#
--local=sxfe
--fullscreen
--display=:1.0
--remote=127.0.0.1:37890
EOF
Alles anzeigen
Die Datei /var/lib/vdrdevel/setup.conf wird um folgende Einträge erweitert:
Für rudimentäre Tastatur-Unterstützund beim Frontend erzeugen wir uns eine remote.conf:
cat > /var/lib/vdrdevel/remote.conf << EOF
KBD.Up 00000000001B5B41
KBD.Down 00000000001B5B42
KBD.Menu 000000000000006D
KBD.Ok 000000000000000D
KBD.Back 000000000000007F
KBD.Left 00000000001B5B44
KBD.Right 00000000001B5B43
KBD.Red 000000001B5B5B41
KBD.Green 000000001B5B5B42
KBD.Yellow 000000001B5B5B43
KBD.Blue 000000001B5B5B44
KBD.0 0000000000000030
KBD.1 0000000000000031
KBD.2 0000000000000032
KBD.3 0000000000000033
KBD.4 0000000000000034
KBD.5 0000000000000035
KBD.6 0000000000000036
KBD.7 0000000000000037
KBD.8 0000000000000038
KBD.9 0000000000000039
KBD.Info 0000000000000069
KBD.FastFwd 0000001B5B31377E
KBD.FastRew 000000001B5B5B45
KBD.Power 0000000000000070
KBD.Volume+ 0000001B5B32347E
KBD.Volume- 0000001B5B32337E
KBD.Mute 0000001B5B32317E
KBD.User7 0000001B5B31387E
KBD.User8 0000001B5B31397E
KBD.User9 0000001B5B32307E
XKeySym.Up Up
XKeySym.Down Down
XKeySym.Menu m
XKeySym.Ok Return
XKeySym.Back BackSpace
XKeySym.Left Left
XKeySym.Right Right
XKeySym.Red F1
XKeySym.Green F2
XKeySym.Yellow F3
XKeySym.Blue F4
XKeySym.0 0
XKeySym.1 1
XKeySym.2 2
XKeySym.3 3
XKeySym.4 4
XKeySym.5 5
XKeySym.6 6
XKeySym.7 7
XKeySym.8 8
XKeySym.9 9
XKeySym.Info i
XKeySym.Pause space
XKeySym.FastFwd F6
XKeySym.FastRew F5
XKeySym.Power p
XKeySym.Volume+ F12
XKeySym.Volume- F11
XKeySym.Mute F10
XKeySym.User7 F7
XKeySym.User8 F8
XKeySym.User9 F9
EOF
Alles anzeigen
Wenn wir jetzt den VDR stoppen und neu starten, sollte auf Konsole Nr. 8 das Bild erscheinen.
Wenn wir mit dem Ergebnis zufrieden sind, können wir uns an die Einrichtung des Produktivsystems machen.
Ein Vorteil dürfte bereits im Entwicklungssystem klar geworden sein:
Wir haben außerhalb von /usr/local keine Dateien im System, die nicht über das Debian-Paktesystem installiert wurden und somit jederzeit wieder entfernt werden können.
Einzige Ausnahme ist der Nvidia-Kernel, aber damit kann ich gut leben. Der muss eben nach jeder Kernelaktualisierung erneut installiert werden. Weiterhin haben wir ein System, in dem es NUR vdrdevel-Pakete gibt. Kein Mischmasch oder sonstige Unsicherheiten. Ich denke, das rechtfertigt den Mehraufwand allemal.
Produktivsystem einrichten
Im Augenblick kämpfe ich noch mit der Einrichtung/Konfiguration des VDR. Sobald die in trockenen Tüchern ist, werden die Abschnitte ausgefüllt.
eigenes Repository einbinden
Installation
Rechner mit VDR-Backend (DVB-Karte, Festplatte für Aufnahmen)
Rechner mit VDR-Frontend (VDPAU)
XServer aktivieren
Weiterführender Stoff zum Lesen
- Eine kompakte Beschreibung zum Aufsetzen eines Ftp-Servers gibt es unter http://www.pc-howto.com/server/ftp-server-mit-vsftp
- Die offizielle Beschreibung zum Einrichten eines Ftp-Servers gibt es hier: http://debiananwenderhandbuch.de/ftpserver.html
- Die Einrichtung eines Webservers wird beschrieben unter http://debiananwenderhandbuch.de/server.html#apache
- Hintergrundinformationen zu VDPAU mit umfangreichen Tips http://wbreu.htpc-forum.de/index.php
- allgemeine Informationen rund um den VDR http://www.vdr-wiki.de/wiki
- Kanäle suchen lassen: http://www.vdr-wiki.de/wiki/index.php/W_scan