HowTo - Vom Auschecken bis zum Image

Vorwort

Worum geht es hier?

Es geht darum, sich eine eigene Linux-Firmware für seinen Receiver zu bauen. Dabei sind einige Hürden zu überwinden. Viele Leute geben bereits an dieser Stelle auf, da ihnen die Hürden einfach zu hoch sind. Selbst bei hundertprozentiger Einhaltung diverser Kurzanleitungen, treten oft dennoch Fehler, oder irgendwelche unvorhersehbaren Situationen auf, bei denen die meisten Anleitungen nicht weiterhelfen. Und somit wird das simple Erstellen einer eigenen Firmware zum Höllentrip durch den unglaublich grossen Cyberspace, auf der Suche nach der richtigen Antwort zum entsprechenden Problem. Dieses HowTo ist darauf ausgelegt, dass (möglichst) alle Fragen vor-, während- und nach dem Firmware-Selbstbau beantwortet werden.

Das Projekt "Tuxbox" (Linux auf einem DVB-Receiver) basiert auf einem Open-Source-Projekt, bei dem es darum ging, DVB-Dienste unter Linux zum Laufen zu bringen. Pionierarbeit leisteten (u.a.) die Metzler-Brüder mit ihren API-Treibern. Irgendwann 2001/2002 schraubte ein User (tmbinc, ein Pionier beim Tuxbox-Projekt, und späterer Initiator von enigma) an seiner DBox2 herum, und brachte sie in den sogenannten Debugmodus. Der Bootloader von Betaresearch selber konnte bis heute noch nicht gehackt, und demnach auch nicht ausgetauscht werden, aber der BR-Bootloader sprang auf diverse Standard-Protokolle an, die auch Linux beherrscht. Darauf baute dann Stück- für Stück "Tuxbox" auf. Die DBox2, welche von 3 verschiedenen Herstellern angeboten wurde, wurde plötzlich zum äussert beliebten Objekt vieler Hobby-Liebhaber, da sie (gegenüber der Betanova-Firmware - nun durch Linux aufgemotzt) wesentlich schneller, und vor Allem auch selbst-gestaltbar wurde. Sie wird mittlerweile nicht mehr hergestellt. Einige Receiver-Hersteller waren bereits zuvor am Linux-Projekt interessiert, doch als das Projekt Tuxbox so langsam erwachsen wurde, setzten einige Firmen auf Tuxbox.

Prima, denn mittlerweile kann man (mithilfe von Tuxbox) seine eigene Firmware für mehrere Receiver selber erstellen. Zb. für die Dreambox, Triple-Dragon, Reelbox, usw. Einige Treiber von einigen Herstellern sind nicht Open-Source (sondern Copyrighted). Es müssen die Original-Treiber der Hersteller implemetiert werden, was aber auch keine grosse Hürde darstellt. In diesem HowTo wird also nicht nur die DBox2 angesprochen, sondern auch andere Receiver. Nähres dazu ist hier zu lesen!

Allgemeines zu Tuxbox CVS

Was ist eigentlich CVS?

Concurrent Version System! So ähnlich wie in diesem WIKI, können mehrere Autoren an diversen Source (hier Text)-Versionen rum-doktor'n. Hat sich ein Autor vertan, erzählt Unsinn, oder hat falsch geklickt, so kann man die vorige Version zurückholen. Denn vorige Verionen werden archiviert. Ist eine Änderung korrekt, und sinnvoll, bleibt sie solange im sogenannten Head bestehen, bis ein anderer seine neusten Änderungen uploaded.

Der Head ist bei der DBox2 vorzuziehen. Aber neben dem Head gibts auch noch Verzweigungen, namens Branch. Wer zB. für die Dreambox ein Image erstellen will, checkt den CVS-Stand des Dreambox-Branches aus. Hier vereinen sich Dreambox-spezifische Sourcen, mit denen vom aktuellen Head.

Was ist eigentlich CDK?

Cross Developement Kit! Wozu braucht man das? Tja, man besitzt idR. einen x86-PC. Aber die Prozessoren in den Receivern besitzen meist einen PowerPC (ppc). Die "normale" Compiler-Umgebung bietet keine Möglichkeit, Programme zu compileren, die auf dem ppc laufen. Das CDK baut dafür einen Crosscompiler (Kreuzübersetzer für C und C++ zwischen x86 und ppc). Alles was dann durch diesen Compiler gejagt wird, kann der ppc ausführen (sofern keine Fehler drin waren *g*)

Das CDK baut auch einen Crosscompiler für Assembler; und den Stripper, der die sich ständig wiederholenden Tags aus den Binaries zieht, damit sie abschliessendend kleiner werden. Der Stripper kann auch Libs verkleinern. Das CDK beherbergt aber auch noch andere, nette Features.

Das CDK ist also das Herzstück, bzw. der Schlüssel zur eigenen Firmware auf dem eigenen Receiver.

Vorbereitungen auf dem PC

Um sich das CDK (und letztendlich ein Image) zu erstellen, benötigt man bestimmte Tools in bestimmten Versionen.

root oder user ?

Antwort: User! Und zwar immer!

Ausnahme: Genau jetzt! Denn Tools- bzw. allgemein für-alle-User-geltende Software kann nur der root installieren. Für andere Dinge braucht man den root eigentlich nicht.

Wie werde ich root?

Es gibt mindestens vier Möglichkeiten

1. Beim Einloggen in das Betriebssystem als root anmelden
2. Als User die root-shell öffnen
3. Normale shell öffnen und sudo su, sudo oder su - (das "-" ist für die Umgebungsvariablen von "root") eingeben.
4. Root und User gleichzeitig und parallel sein.......

...... da es unter Linux mehrere virtuelle Konsolen, bzw. Desktops gibt, kann man auch gleichzeitig als user, wie als root angemeldet sein.

Unter einer grafischen Desktop-Umgebung, kann man mit der Tastenkombination

STRG+[F-Taste]

zwischen (meist) mindestens 4 grafischen Desktops F[1-4] umherschalten.

Mit der Tastenkombination

STRG+ALT+[F-Taste] 

kann man zwischen weiteren Text-Modus-Konsolen umherschalten. Meist ist F7 zurück in den grafischen Modus. Mithilfe dieser Text-Modus-Konsolen kann man auch diverse, grafische Oberflächen gleichzeitig starten. Denn es gibt ja noch andere, als nur KDE. Die Anzahl der Konsolen ist von der Distribution abhängig. (In der HowTo_-_Vom_Auschecken_bis_zum_Image#Streamboard VMWare Beta-Buildumgebung wechselt man die Konsolen mit ALT + F[1-6])

Zurück zum Geschäft:

Wenn die Tools installiert sind, beendet man sein root-Dasein wieder, und loggt sich wieder als User ein, oder wechselt eben wieder auf seine User-Ebene/Konsole/Oberfläche zurück. In unserem Fall sollte alle weiteren USER Aktionen unter dem USER "sb" passieren. Aber zunächst mal zu den Tools, und wie man sie als root installiert.....

Tools (Prerequisiten)

Prerequisiten? Was'n das? Man stelle sich vor, man will einen Starwars-Film drehen, und kein Schauspieler hat ein Laserschwert zur Verfügung. Damit der Film rockt, braucht jeder Starwars-Schauspieler auch die Requisite "Laserschwert".

So ähnlich ist es auch mit den Prerequisiten, die für Tuxbox benötigt werden. Fehlt dem eigenen Linux-System auf dem PC ein Tool, dann klappt das nicht mit dem Firmware-Selbstbau.

Laut http://cvs.tuxbox.org/cgi-bin/viewcvs.cgi/tuxbox/cdk/doc/INSTALL.en?rev=HEAD muss man folgende Prerequisten an Bord haben:

• cvs
• autoconf >= 2.57a
• automake >= 1.8
• libtool >= 1.4.2
• gettext >= 0.12.1
• make >= 3.79
• makeinfo (texinfo)
• tar
• bunzip2 (bzip2)
• gunzip (gzip)
• patch
• infocmp (ncurses-bin / ncurses-devel)
• gcc 2.95 or >= 3.0
• g++ 2.95 or >= 3.0
• flex
• bison
• pkg-config
• wget
• libpng2 or libpng3 (DirectFB)

Es gibt im Tuxbox-cvs den toolchecker (bashskript), welcher genau diese Versionsstände ermittelt. Man lädt sich das Skript auf den lokalen Rechner, ändert die Rechte auf ausführbar (chmod +x toolchecker.sh) und startet es. Dann vergleicht man einfach die ermittelten Versionen mit den hier gelisteten. Ist eine Prerequisite nicht vorhanden, oder hat eine kleinere Versionsnummer, muss man diese noch nachinstallieren/updaten. Wird keine Version angegeben: Nicht schlimm. Nur vorhanden sein muss es. Wer bereits das CVS ausgecheckt hat, hat den toolchecker bereits auf seinem PC

sb@build:# /tuxbox-cvs/hostapps/toolchecker/toolchecker.sh 

Debian

Unter debian http://www.debian.de gibt das Toolset apt-* zur Verwalltung von Programmen. Mit apt-cache search kann ich zB nach Programmen suchen, mit apt-get install Programme installieren.

apt-setup

Als erstes konfigurieren wir den Internetzugang und Protokoll für das Updaten der einzellnen Softwarepakete. Man kann unterscheiden zwischen cdrom, ftp, http oder einem Dateisystem auswählen. Wenn man eine Internetanbindung (xDSL) hat, sollte man sich entweder für ftp oder http entscheiden. Als nächstes wählt man das Land, in dem man sich befindet. Dadurch wird im nächsten Schritt dann ein Server aus deiner Nähe ausgewählt. Am Ende wird von diesem Server die aktuelle Paketliste geladen und lokal abgespeichert. Ev kann man noch zusätzliche Quellen angeben.

apt-update

Da sich bei den Softwarepaketen immer wieder was verändert und Neuerungen/Bugfixes hinzukommen, ändert sich auch die Version der einzellnen Pakete. durch ein

root@build:~# apt-get update

wird von dem oben eingestellten Server die aktuelle Paketliste geladen. Diese wird dann im nächsten Schritt benötigt.

apt-upgrade

!!ACHTUNG!! Hier ist Vorsicht geboten. Dieser Befehl zieht alle installierten Pakete auf die aktuelle Version. Dies ist jedoch nicht immer gewünscht. Man wird jedoch gefragt, ob man dies wirklich machen möchte. Seht euch die Pakete an, die upgedatet werden, ihr könnt mit CTRL-C immer noch abbrechen.

SuSE

Unter SuSE koennt ihr mit rpm -q <paketname> anhand o.a. Liste auch ohne toolchecker vergleichen welche Version des Pakets ihr installiert habt.

Yast

Ist ein Paket nicht installiert, am besten erstmal mit Yast schaun ob es ueberhaupt in der Distribution ist und ggf. nachinstallieren.

rpm

Mit rpm -i <paketname> koennt ihr ggf. aus dem Internet heruntergeladene pakete nachinstallieren

Andere Linux-Distributionen

Knoppix

KNOPPIX ist eine komplett von CD oder DVD lauffähige Zusammenstellung von GNU/Linux-Software mit automatischer Hardwareerkennung und Unterstützung für viele Grafikkarten, Soundkarten, SCSI- und USB-Geräte und sonstige Peripherie. KNOPPIX kann als produktives Linux-System for den Desktop, Schulungs-CD, Rescue-System oder als Plattform für kommerzielle Software-Produktdemos angepasst und eingesetzt werden. (Quelle: Knoppix-Homepage) Download auf der Knoppix-Homepage

Wie bekomme ich Knoppix auf meine Festplatte?

• Knoppix von CD/DVD starten
• Shell öffnen

sb@build:# sudo knoppix-installer

oder

sb@build:# knoppix-installer

eingeben und mit [Enter] bestätigen

• den Anweisungen folgen

Hier mal ein Hd Install HowTo aus dem Knoppix-Wiki (leider nur in english) Hier noch ein Video zur HD-Istallation (auch english)

Was ist typischerweise für Knoppix zu ändern um mit dem Compilieren loslegen zu können?

Man benötigt noch folgende Software die noch nicht in Knoppix5 enthalten ist:

• bison
• libpng2 or libpng3 (DirectFB)
• libtool >= 1.4.2
• makeinfo (texinfo)
• pkg-config
• flex

eventuell noch:

• mksquashfs
• mkfs.jffs2

Streamboard VMWare Beta-Buildumgebung

Es steht testweise eine Buildumgebung für VMWare bereit.

http://streamboard.gmc.to/wbb2/tut-pics/StreamboardVMware251020061933.exe (70MB)  

Diese basiert auf einem minimalen Debian-System und sollte bereits alle nötigen Pakete beinhalten. Es ist keine GUI installiert um die Downloadgröße gering zu halten. Diese kann aber mittels aptitude bzw. apt-get sehr einfach installiert werden.

Die Installation unter Windows erfolgt sehr einfach:

1. Download und Installation des VMWare-Players (Freeware) oder VMWare Workstation (benötigt nach 30 Tagen eine Lizenz)
2. Entpacken der StreamboardVMware251020061933.exe in ein beliebiges Verzeichnis (auf ausreichend Speicherplatz achten! Später wird das Ganze ca. 2-3GB groß)
3. Mit einem Doppelklick auf die entpackte VMX-Datei sollte der VMWare-Player bzw. Workstation starten und die Buildumgebung öffnen.
4. Nach dem Start von Debian kann man sich mittels dem Usernamen "sb" und Passwort "kalibo" einloggen. Das Passwort für den root-Zugang (nötig für die Installation weiterer Software) lautet "Streamboard". Diese Informationen werden auch beim Starten angezeigt.

Im Anschluss daran kann man mit dem Imagebau laut diesem Howto beginnen.

In der Buildumgebung läuft bereits ein fertig eingerichteter SSH-Server (für einfacheres Copy-and-Paste zwischen eurem Windows-System und der Buildumgebung) sowie auch ein FTP-Server zum Datenaustausch. Zum Verbinden werden hierzu die normalen Benutzerdaten (siehe oben!) verwendet. Die IP wird dynamisch vergeben und beim Starten angezeigt; ihr erhaltet sie aber auch später indem ihr entweder

sb@build:~# sudo ifconfig

bzw. als root-User einfach nur

root@build:~# ifconfig

eingebt. Hierbei seht ihr auch schön die Funktion des Befehls "sudo": Wenn ihr diesen vor ein Kommando stellt, so wird dieser Befehl als root ausgeführt. Ihr braucht euch also nicht umständlich erst als root anmelden bzw. mittels dem Befehl "su" zum root-Account wechseln falls hier im Wiki manche Befehle root-Rechte benötigen!

Unter Umständen ist es noch nötig, mittels "Manage Virtual Networks" (im Startmenü von VMWare enthalten) im Reiter "NAT" für das Netzwerkinterface ein entsprechendes Portforwarding einzurichten sowie "Aktives FTP" zu aktivieren. Im Allgemeinen ist dies allerdings nicht notwendig!

Das Streamboard-Team würde sich über Rückmeldungen im Forum sehr freuen! Es können durchaus noch Bugs enthalten sein, da das Paket noch nicht ausreichend getestet werden konnte.

(optionale) VMWare Tools installieren

VMWare bietet unter dem Namen VMWare Tools für viele gängige Betriebssysteme spezielle Treiber an. Diese verbessern die Performance (z.B. des Netzwerks) oder bringen zusätzliche Features. Sie sind für den Betrieb nicht notwendig aber grundsätzlich ist die Installation empfehlenswert.

Zur Installation müssen zunächst die sogenannten "Kernel-Header" mittels folgendem Befehl installiert werden:

root@build:~# cd /usr/src
root@build:~# apt-get install kernel-headers-2.4.27-3-386

Anschließend benötigt ihr noch das eigentliche Treiberpaket. Hierfür gibt es 2 Möglichkeiten:

1. Ihr ladet unter Datei:VMwareTools.exe das Archiv herunter und extrahiert die TAR-Datei. Mit einem FTP Client könnt ihr diese dann in die Buildumgebung nach /usr/src hineinkopieren. Anschließend führt ihr folgende Befehle aus um die Dateien zu entpacken

root@build:~#  tar -zxf VMwareTools*.tar  

2. Ihr nutzt den in VMWare-Workstation integrierten Button unter dem Menüpunkt VM. Die Tools werden dann als virtuelle CD-Rom ins System eingebunden. Über folgende Befehle kann man diese dann entpacken:

root@build:~# mount /cdrom
root@build:~# tar -zxf /cdrom/VMWareTools*.tar.gz

Anschließend geht es an die eigentliche Installation.

root@build:~# cd vmware-tools-distrib
root@build:~# ./vmware-install.pl

Die entsprechenden Meldungen sind allesamt einfach nur mit [ENTER] zu bestätigen bis die Frage nach den "C header files" gestellt wird. Hier muss dann /usr/src/kernel-headers-2.4.27-3-386/include angegeben werden. Der Rest sollte dann problemlos durchlaufen und spätestens nach einem Neustart sind VMWare Tools aktiv.

Mausunterstützung in der Konsole

Um auch in der Konsole mit Mausunterstützung arbeiten zu können, müßt ihr euch das Tool gpm installieren.

sb@build:# apt-get install gpm

Bei den meisten Sytemen schaut die Konfigdatei so aus.

#  /etc/gpm.conf - configuration file for gpm(1)
device=/dev/psaux
responsiveness=
repeat_type=none
type=imps2
append=
sample_rate=

Nun kann man innerhalb der Konsole recht einfach mittels copy/paste arbeiten.

Vorbereitungen zum Compilieren

Falls nicht schon geschehen, jetzt als User einloggen.

Anmerkung: Dieser Username erscheint auch später in Eurem Image

Ein paar Verzeichnisse anlegen ( tuxbox-cvs, dbox2, etc)

sb@build:# mkdir /tuxbox-cvs
sb@build:# mkdir /dbox2

Auschecken und Konfigurieren

solltet ihr einen proxy vorgeschaltet haben ist folgendes in eurer Shell einzugeben:

mit vorgeschaltetem Proxy:

sb@build:# export http_proxy="eure_proxy_ip_:_port"

Bei einigen Distributionen wie z.B. SuSE braucht man den Proxy nicht extra anzugeben, wenn er unter Yast schon angegeben wurde.

ohne vorgeschaltetem Proxy:

sb@build:# export CVS_RSH=ssh
sb@build:# cd /tuxbox-cvs
sb@build:# cvs -d anoncvs@cvs.tuxbox.org:/cvs/tuxbox -z3 co -P .

Hier währe die günstige Gelegenheit, gleich ein "Backup" vom CVS zu machen, siehe nächsten Punkt (Tarball erstellen)

Hier fehlt jetzt noch:

sb@build:# cd cdk
sb@build:# ./autogen.sh
sb@build:# ./configure --prefix=/dbox2 --with-cvsdir=/tuxbox-cvs --enable-maintainer-mode --with-targetruleset=flash

Tarball erstellen

Bevor man jetzt irgendwas anderes tut, sollt man sich erstmal einen Tarball von den ganzen runtergeladenen Daten erstellen. Warum ? Falls man beim Editieren irgendwelcher Dateien Mist gebaut hat, muss man dann nicht mehr neu auschecken.

sb@build:# cd /
sb@build:# tar -cvf tuxbox-cvs_backup.tar ./tuxbox-cvs ./dbox2

Das "./" sollte man jeweils mit eingeben, damit man den Tarball später an einem anderen Ort/Rechner problemlos entpacken kann. Der Dateiname des .tar-Files kann frei gewählt werden. Es ist zu empfehlen, im Dateiname noch das Datum mit hinzuzufügen. ZB. tuxbox-cvs_backup_200600912.tar

Tarball wiederherstellen

Damit werden die bestehenden Dateien wieder überschrieben.

sb@build:# cd /

oder

sb@build:# cd /wohin/auch/immer

sb@build:# tar xvf tuxbox-cvs_backup.tar

Letzte Chance noch manuell ins Geschehen einzugreifen

Vor-Überlegung: Welche(s) FileSystem(e) nehmen?

Das, was alles später ins Image soll, ist bis zu 20MB gross. Aber wir haben nur 8MB zur Verfügung. Deshalb gibt es Komprimierung. Die Filesysteme, die sich am stärksten komprimieren lassen, sind leider nicht beschreibbar.

Wo liegen die Vor- und Nachteile der Filesysteme?

Die beiden am-besten-komprimierbaren Filesysteme sind CRamFS und SquashFS.

• SquashFS mit LZMA-Unterstützung ist der Platzhirsch im wahrsten Sinne des Wortes. Aber nur-lesbar. LZMA gibts aber nicht im Tuxbox-cvs. Das muss man sich selber reinpatchen. Weiterer Nachteil: Die DBox2 bootet langsamer, und alles wirkt etwas "hakelig", da der kleine Prozessor viel zu ackern hat, die Daten zu entkomprimieren. Auf der Dreambox, Triple-Dragon, usw. merkt man es nicht.
• SquashFS ist das gängigste FS. Der Betrieb unter der DBox2 ist dann auch akzeptabel. Aber nur-lesbar.
• CramFS war früher das gängigste FS, und wird auch heute noch viel für die Dreambox benutzt. Aber nur-lesbar.
• JFFS2 ist das Filesystem, welches auch beschreibbar ist. Somit ist es der Gewinner unter allen Filesystemen, und man kann sich auch ein JFFS2-Only-Image bauen. Aber obwohl es zusätzlich noch eine Realtime-Compress-Engine besitzt, komprimiert es am schlechtesten. So ca. 14MB bekommt man ins JFFS2-Only rein.

Am besten ist also ein Mischsystem. Eine Partition für die "grossen Brocken", die man eh nie ändert, und eine Partition mit JFFS2. Wenn man vor dem partitionieren noch eine Menge nicht-unbedingt-benötigter Sachen rausschmeisst (Spiele, ungenutzte Skins, Hintergrundbilder, usw.), kann man (zB.) die SquashFS-Partition kleiner ausfallen lassen. Dadurch kann man ein grösseres JFFS2 als zweite Partition anhängen.

Wenn man meint, ein gutes Gleichgewicht zwischen beiden Partitionen gefunden zu haben, muss dazu der Kernel, und das U-Boot angepasst werden. Da kommt man auf keinen Fall drumrum. Es sei denn, man ist mit Default-Einstellungen im CVS zufrieden.

Auf der Fehlersuche

Zuvor erstellten Tarball nutzen, um was ver-sau-beuteltes nochmal neu zu starten

(Sourcen überkopieren; Datums/Zeit-Problematik bei Files)

siehe HowTo_-_Vom_Auschecken_bis_zum_Image#Tarball_wiederherstellen

Ich will nachträglich was im Source ändern, und zB. Neutrino neu compilieren

Einfach im Source rumtippen. Anschliessen zurück zu /tuxbox-cvs/cdk wechseln, und zB. make neutrino eingeben. Aber evtl. hat man ja nicht nur die Neutrino-Sourcen geändert. Dann könnte man auch make all eintippen. Ein make all ist aber nur zu empfehlen, wenn man ganz zu Anfang (nach dem auschecken und dem autogen und dem configure) auch make all angebenen hatte. Wenn nicht, dann wird der ganze Rest des CVS-Standes compiliert, der bis dato noch nicht compiliert wurde, und der in den makefiles der ersten Ebene enthalten ist.

Doch was ist da los? Es tut sich nichts. Im Log steht, es gäbe nichts zu tun. Tja, es muss noch das .dep-File gelöscht werden.

Was ist ein .dep-File?

Ein depfile ist ein Indikator, der dem CDK vermittelt, das eine bestimmte Sache erledigt ist. Ist es vorhanden, denkt das CDK, es gäbe nichts zu tun, auch wenn inzwischen Sourcen geändert wurden.

HEAD:

Im obigen Beispiel liegt das .dep-File von Neutrino unter /home/tuxbox-verzeichnis/cdk/.deps/ Entweder man wechselt in das Verzeichnis hinein, tippt rm neutrino ein, wechselt wieder mit cd .. zurück, und gibt seine make Anweisung erneut ein, oder man tippt gleich rm -f .deps/neutrino ein, gefolgt von der make Anweisung.

Dreambox-Branch:

Wenn man für die Dreambox ausgecheckt hat, findet man das .deps Verzeichnis nicht. Die .deps liegen direkt im /home/tuxbox-verzeichnis/cdk/ Verzeichnis, und haben den Punkt vorne am Dateinamen. Hier wäre vor der make Anweisung rm -f .neutrino einzugeben.

Was ist ein diff ?

Zunächst einmal zur Abkürzung: diff steht für difference, also Unterschied. Ein diff-File ist also eine Unterschieds-Datei. Will man eine Source editieren, empfiehlt es sich immer ein Backup zu machen. Wer zB. an der enigma_main.cpp editiert, tippt zuvor noch ein:

sb@build:# cp enigma_main.cpp enigma_main_orig.cpp

Somit ist der Originalzustand gesichert, und es kann angstfrei editiert werden.

Wenn man fertig ist, möchte man evtl. noch nur die Änderungen zwischen dem neuen- und dem alten Stand der Source sehen. Dazu gibt man ein:

sb@build:# diff -Naur enigma_main_orig.cpp enigma_main.cpp > enigma_main.cpp.diff

Fertig ist das diff-File.

Was ist ein Patch ?

Genau das Gegenteil vom diffen. Zuvor haben wir gedifft. Jetzt wollen wir patchen. Nehmen wir an, es wurde gerade ganz frisch das CVS neu ausgecheckt, und die Datei enigma_main.cpp ist noch im Originalzustand. Nun kopiert man das enigma_main.cpp.diff in dasselbe Verzeichnis, und tippt ein:

sb@build:# patch -p0 -b enigma_main.cpp enigma_main.cpp.diff

Der Parameter -b gibt an, dass noch ein Backup erstellt werden soll.

Datums/Uhrzeit-Problematik von Sourcen

Zum Zweck, falls man eine Source versehentlich kaputtrepariert hat, haben wir uns ja zuvor ein Backupfile angelegt. Dieses besitzt grundsätzlich ein älteres Datum. Wir wollen den Originalzustand wiederhaben, und denken wir sind schlau, überschreiben enigma_main.cpp mit dem Originalfile, und compilieren nochmal. Dann stellen wir fest, dass der kaputtreparierte Stand compiliert wurde. Wieso das?

Der Compiler denkt, dass die Source nix neues zu bieten hat, weil sie älteren Datums ist. In diesem Fall einfach

touch enigma_main.cpp

und die Datei hat ein neues Datum bekommen.

Links

Tuxbox-Plattform: http://tuxbox.org/
CVS-Server: http://cvs.tuxbox.org/
Mailing-List: http://cvs.tuxbox.org/lists/
TuxboxWIKI: http://wiki.tuxbox.org/Hauptseite

Credits

Admin
horsti666
limette
martie
Nessus
...und ein paar Unbekannte, die nicht den Anmelden-Knopf gefunden haben

Viel Spass beim Image-Bau