TuxBoxWIKI - Benutzerbeiträge [de]

Development:GDB Remote einrichten

2011-06-14T18:30:26Z

Rhabarber1848:

[[Category:Register]]
[[Category:Development]]
[[Category:CDK]]
{{Development_sidebar}}

__TOC__

=Build Konfiguration=
cdk/configure
damit alle Debugsymbole vorhanden sind
--enable-debug

make yadd-neutrino gdb gdb-remote

=Modifikation der Startscripte=
In cdkroot/etc/init.d/start_neutrino vor die Zeile
Code:
until neutrino -f -u ; do

folgendes einfügen:
Code:
exit 0

=Anwenden=
weil wir Neutrino manuell starten werden.
Yadd booten.

Per Telnet auf die Dbox einloggen, dann:
Code:
gdbserver :5555 neutrino

gdb wartet dann auf den connect eines clients:
Zitat:
Process neutrino created; pid = 189
Listening on port 5555

Auf dem Client ins Verzeichnis
$prefix/cdk/bin
wechseln und
Code:
./powerpc-tuxbox-linux-gnu-gdb ../../cdkroot/bin/neutrino

Dann geht es los:
Code:
target remote dboxIP:5555
continue

Wenn Neutrino abgestürzt ist, kann, wie gehabt, mit
Code:
bt full

ein backtrace erzeugt werden.

=Weblinks=
http://forum.tuxbox.org/forum/viewtopic.php?p=366575#p366575

Erstellen eines VMWare-Images

2011-05-28T13:16:41Z

Rhabarber1848: /* Tuxbox-CDK einrichten */

[[Category:Register]]
[[Category:Development]]
[[Category:CDK]]
{{Development_sidebar}}

__TOC__

=Allgemein=
Als sehr nützlich für die Erstellung einer Entwicklungsumgebung hat sich das Aufsetzen einer Virtualisierung erwiesen, wenn man nicht unbedingt ein komplettes Linuxsystem einrichten möchte oder kann. Dank gestiegener Hardwareleistung, insbesondere bei Mehrkernsystemen, ist der Umgang mit solch einer Lösung fast gleichwertig und eine sehr gute Alternative zu einem echtem Linuxsystem. Vor allem Neulinge auf diesem Gebiet, bietet diese Alternative einen optimalen Einstieg.
Dank vorgefertigter und zum Teil für bestimmte Verwendungszwecke zugeschnittene Images, sind solche Systeme relativ schnell eingerichtet.

=Voraussetzungen=
Es wird davon ausgegangen, dass eine Windowsinstallation (>=WindowsXP) vorhanden ist und die enstprechende Hardware mit möglichst ordentlicher CPU, am besten Mehrkern-CPU's, vorhanden ist.
Natürlich sollte [[VMware]] installiert sein. Eine Lösung über andere Virtualisierungs-Plattformen wie sie z.B. von Sun's [[VirtualBox]] besteht,
ist im wesentlichen auch möglich. Andere sollten auch möglich sein, aber hierfür sind momentan keine weiteren Informationen bekannt.

=Debian Squeeze=
==Installation==
Es wird ein fertiges Image benötigt. Dafür diese Datei herunterladen:

http://cdimage.debian.org/debian-cd/6.0.1a/i386/iso-cd/debian-6.0.1a-i386-netinst.iso

===VMWare vorbereiten===
Einmaliger Prozess zum Erstellen des VMWare-Images:

*Menü File, New, Virtual Machine, Weiter, Typical, Linux - Ubuntu,
*Speicherort auswählen, Use bridged networking, 8GB -

Rest nicht verändern, Fertig stellen

*Menü VM, Settings, CD-ROM - Use ISO Image
obiges ISO auswählen

*Virtuelle Maschine starten
*Install,''' ''Enter'''''
*German,''' ''Enter'''''
*Deutschland,''' ''Enter'''''
*Deutsch,''' ''Enter'''''
(evtl. muss das Netzwerk konfiguriert werden)
*Rechnername tuxbox
*Geführt - verwende vollständige Festplatte,''' ''Enter'''''
'''''*Enter'''''
*Alle Dateien auf eine Partition,''' ''Enter'''''
*Partitionierung beenden und Änderungen übernehmen, ''Enter''
*Änderungen auf die Festplatten schreiben? Ja,''' ''Enter'''''

...Grundsystem wird installiert

*Root-Passwort vergeben
*Neuer Benutzer, Name:''' ''tuxbox'''''
*Benutzername:''' ''tuxbox'''''
Passwort vergeben
*Debian-Archiv-Spiegelserver Deutschland
*Server auswählen
*Paketverwendungserfassung nein,''' ''Enter'''''
*Keine Software-Sammlung auswählen

alle Sterne entfernen,''' ''Enter'''''

*Grub in Master Boot Record - Ja,''' ''Enter'''''

Nach Beendigung der Installation, virtuelle Maschine neustarten!

===Lenny einrichten===
Einmaliger Prozess zum Einrichten von Debian und Installieren der notwendigen Pakete:

Innerhalb der virtuellen Maschine anmelden als User '''root'''
apt-get update
apt-get upgrade
apt-get install --no-install-recommends sudo openssh-server
echo "tuxbox ALL=(ALL) ALL" >> /etc/sudoers
ifconfig (die IP-Adresse von eth0 merken)
logout

'''''STRG+ALT'',''' um das VMWare-Fenster wieder zu verlassen

per SSH ('''auf Windows ist [http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html Putty] zu empfehlen!''') zur virtuellen Maschine unter o.g. IP verbinden als User '''tuxbox''' einloggen
sudo apt-get install --no-install-recommends cvs libtool autoconf automake gettext autopoint make g++ flex bison patch bzip2 pkg-config zlib1g-dev python

für die Freunde des Midnight-Commanders:
sudo apt-get install --no-install-recommends mc

danach aufräumen:
sudo apt-get clean

=Tuxbox-CDK einrichten=
Als Bespiel soll hier eine allgemeine Vorgehensweise gezeigt werden, wie man sofort loslegen könnte. Detailierte Informationen zu Bauvorgang, Optionen usw. findet man unter [[Images und Yadd's erstellen]].

mkdir $HOME/cvs $HOME/archive $HOME/customization

Herunterladen/Aktualisieren des Tuxbox-CVS:
cd $HOME/cvs
CVS_RSH=ssh cvs -d anoncvs@cvs.tuxbox.org:/cvs/tuxbox -z3 co -P .
(beim ersten Mal die Frage nach RSA key fingerprint mit yes beantworten)

Kompilieren eines Images, dafür immer ein leeres Verzeichnis nehmen:

cd $HOME
rm -rf compile image
cp -r cvs compile
wenn Patches eingespielt werden sollen:
cd $HOME/compile
patch -p0 -E -i /home/tuxbox/datei.diff
weiter:
cd $HOME/compile/cdk
./autogen.sh

Für eine Übersicht aller Konfigurationsoptionen:
./configure --help

./configure --prefix=$HOME/image --with-cvsdir=$HOME/compile --with-archivedir=$HOME/archive

optional:

--with-[http://wiki.tuxbox.org/wiki/index.php/Images_und_Yadd%27s_erstellen#--with-rootpartitionsize.3D.5BSIZE.5D rootpartitionsize]=0x460000

--with-[http://wiki.tuxbox.org/wiki/index.php/Images_und_Yadd%27s_erstellen#--with-customizationsdir.3DDIR customizationsdir]=$HOME/customization

Nun können Images kompiliert werden:

make flash-neutrino-squashfs-all
make flash-enigma-squashfs-all
make flash-enigma+neutrino-squashfs-all

Das fertige Image liegt in

tuxbox@tuxbox:~$ ls -la $HOME/image/cdkflash/*img*
-rw-r--r-- 1 tuxbox tuxbox 8257536 3. Feb 16:31 /home/tuxbox/image/cdkflash/neutrino-squashfs.img1x
-rw-r--r-- 1 tuxbox tuxbox 8257536 3. Feb 16:31 /home/tuxbox/image/cdkflash/neutrino-squashfs.img2x

=Yadd-Setup=
Allgemeine Infos zum Thema [[Images und Yadd's erstellen]]

Hier nun die Setup-Anleitung für das VMWare-Image:

Setup einer Yadd-Umgebung, bestehend aus DHCP/bootp/NFS-Server.

Installieren und Konfigurieren des NFS-Servers:

su - root
Passwort für root eingeben, Enter
apt-get install --no-install-recommends nfs-kernel-server dhcp3-server tftpd
apt-get clean
sed -i "s/\/srv\/tftp/\/home\/tuxbox\/image\/tftpboot/" /etc/inetd.conf
echo "/home/tuxbox/image/cdkroot *(rw,sync,no_root_squash,no_subtree_check)" >> /etc/exports
logout

Von der Dbox wird die MAC-Adresse der Netzwerkkarte benötigt,
dazu muss bereits ein Linux-Image auf der Box laufen. Per Telnet
(geht auch mit Putty) eine Verbindung zur Dbox aufbauen,
Username root, dann
ifconfig eth0
eingeben und den Wert hinter HWaddr ermitteln, dieser muss
später in die Konfigurationsdatei des DHCP-Servers eingetragen
werden, Beispiel:
eth0 Link encap:Ethernet HWaddr 12:34:56:78:9A:BC
inet addr:192.168.1.4 Bcast:192.168.1.255 Mask:255.255.255.0
In diesem Fall ist die MAC-Adresse 12:34:56:78:9A:BC

Nun beginnt das Setup des DHCP-Servers innerhalb der VMWare-Sitzung.

Dieser wird benötigt, um Yadd zu booten. Wenn im Netzwerk bereits ein DHCP-Server aktiv ist, muss dessen Bootp-Unterstützung für die oben ermittelte MAC-Adresse deaktiviert werden. Da es viele unterschiedliche DHCP-Server gibt, kann ich hier nur ein Beispiel liefern:
host dbox
{
deny bootp;
hardware ethernet 12:34:56:78:9A:BC;
fixed-address 192.168.1.4;
}

Entscheidend ist hier die Zeile "deny bootp;".
Die Dbox hat die IP-Adresse 192.168.1.4, diese IP muss auch im DHCP-Server der VMWare-Sitzung für die Dbox verwendet werden.

Nun wird der DHCP-Server der VMWare-Sitzung konfiguriert, dazu wird der vorhandene Editor Nano genutzt, hier die [http://mintaka.sdsu.edu/reu/nano.html Tastenübersicht].

Am einfachsten ist es, folgende Konfiguration zu übernehmen und die mit Dollarzeichen ($$$Beschreibung$$$) markierten Einträge zu bearbeiten.

sudo rm /etc/dhcp3/dhcpd.conf
sudo nano /etc/dhcp3/dhcpd.conf

Folgenden Text in den Editor kopieren:
ddns-update-style none;
allow bootp;

option domain-name "$$$Domainname des Netzwerks$$$";
option domain-name-servers $$$IP des DNS-Servers$$$;
option routers $$$IP des DNS-Servers$$$;

default-lease-time 600;
max-lease-time 7200;

subnet $$$IP des DNS-Servers, endend auf Null$$$ netmask 255.255.255.0 {
}

host dbox {
fixed-address [b]$$$IP der Dbox$$$[/b];
hardware ethernet [b]$$$MAC-Adresse der Dbox$$$[/b];
server-name "[b]$$$IP der VMWare-Sitzung$$$[/b]";
next-server [b]$$$IP der VMWare-Sitzung$$$[/b];
option root-path "/home/tuxbox/image/cdkroot";
if exists vendor-class-identifier {
filename "/home/tuxbox/image/tftpboot/kernel-cdk";
} else {
filename "/home/tuxbox/image/tftpboot/u-boot";
}
}
STRG+X, J, Enter zum Speichern der Änderungen

sudo invoke-rc.d dhcp3-server restart
sudo invoke-rc.d nfs-kernel-server restart
sudo invoke-rc.d openbsd-inetd restart

Ein Yadd-Image eignet sich perfekt zum Debuggen.

Zum Kompilieren einer Yadd-Umgebung:
make yadd-neutrino
make yadd-enigma

Wenn Neutrino und Enigma gleichzeitig gewünscht sind:
make yadd-neutrino yadd-enigma

Nach dem Kompilieren die Dbox2 in den deep-standby fahren,
die o.g. Dienste aktivieren, ein serielles Log öffnen zum
Überwachen des Bootprozesses und die Dbox2 einschalten.

=Weblinks=
[http://forum.tuxbox.org/forum/viewtopic.php?f=13&t=48503 Ursprungsthread zu diesem Howto im Tuxbox-Forum]

Erstellen eines VMWare-Images

2011-05-21T11:33:15Z

Rhabarber1848: Update Debian Squeeze

[[Category:Register]]
[[Category:Development]]
[[Category:CDK]]
{{Development_sidebar}}

__TOC__

=Allgemein=
Als sehr nützlich für die Erstellung einer Entwicklungsumgebung hat sich das Aufsetzen einer Virtualisierung erwiesen, wenn man nicht unbedingt ein komplettes Linuxsystem einrichten möchte oder kann. Dank gestiegener Hardwareleistung, insbesondere bei Mehrkernsystemen, ist der Umgang mit solch einer Lösung fast gleichwertig und eine sehr gute Alternative zu einem echtem Linuxsystem. Vor allem Neulinge auf diesem Gebiet, bietet diese Alternative einen optimalen Einstieg.
Dank vorgefertigter und zum Teil für bestimmte Verwendungszwecke zugeschnittene Images, sind solche Systeme relativ schnell eingerichtet.

=Voraussetzungen=
Es wird davon ausgegangen, dass eine Windowsinstallation (>=WindowsXP) vorhanden ist und die enstprechende Hardware mit möglichst ordentlicher CPU, am besten Mehrkern-CPU's, vorhanden ist.
Natürlich sollte [[VMware]] installiert sein. Eine Lösung über andere Virtualisierungs-Plattformen wie sie z.B. von Sun's [[VirtualBox]] besteht,
ist im wesentlichen auch möglich. Andere sollten auch möglich sein, aber hierfür sind momentan keine weiteren Informationen bekannt.

=Debian Squeeze=
==Installation==
Es wird ein fertiges Image benötigt. Dafür diese Datei herunterladen:

http://cdimage.debian.org/debian-cd/6.0.1a/i386/iso-cd/debian-6.0.1a-i386-netinst.iso

===VMWare vorbereiten===
Einmaliger Prozess zum Erstellen des VMWare-Images:

*Menü File, New, Virtual Machine, Weiter, Typical, Linux - Ubuntu,
*Speicherort auswählen, Use bridged networking, 8GB -

Rest nicht verändern, Fertig stellen

*Menü VM, Settings, CD-ROM - Use ISO Image
obiges ISO auswählen

*Virtuelle Maschine starten
*Install,''' ''Enter'''''
*German,''' ''Enter'''''
*Deutschland,''' ''Enter'''''
*Deutsch,''' ''Enter'''''
(evtl. muss das Netzwerk konfiguriert werden)
*Rechnername tuxbox
*Geführt - verwende vollständige Festplatte,''' ''Enter'''''
'''''*Enter'''''
*Alle Dateien auf eine Partition,''' ''Enter'''''
*Partitionierung beenden und Änderungen übernehmen, ''Enter''
*Änderungen auf die Festplatten schreiben? Ja,''' ''Enter'''''

...Grundsystem wird installiert

*Root-Passwort vergeben
*Neuer Benutzer, Name:''' ''tuxbox'''''
*Benutzername:''' ''tuxbox'''''
Passwort vergeben
*Debian-Archiv-Spiegelserver Deutschland
*Server auswählen
*Paketverwendungserfassung nein,''' ''Enter'''''
*Keine Software-Sammlung auswählen

alle Sterne entfernen,''' ''Enter'''''

*Grub in Master Boot Record - Ja,''' ''Enter'''''

Nach Beendigung der Installation, virtuelle Maschine neustarten!

===Lenny einrichten===
Einmaliger Prozess zum Einrichten von Debian und Installieren der notwendigen Pakete:

Innerhalb der virtuellen Maschine anmelden als User '''root'''
apt-get update
apt-get upgrade
apt-get install --no-install-recommends sudo openssh-server
echo "tuxbox ALL=(ALL) ALL" >> /etc/sudoers
ifconfig (die IP-Adresse von eth0 merken)
logout

'''''STRG+ALT'',''' um das VMWare-Fenster wieder zu verlassen

per SSH ('''auf Windows ist [http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html Putty] zu empfehlen!''') zur virtuellen Maschine unter o.g. IP verbinden als User '''tuxbox''' einloggen
sudo apt-get install --no-install-recommends cvs libtool autoconf automake gettext autopoint make g++ flex bison patch bzip2 pkg-config zlib1g-dev python

für die Freunde des Midnight-Commanders:
sudo apt-get install --no-install-recommends mc

danach aufräumen:
sudo apt-get clean

=Tuxbox-CDK einrichten=
Als Bespiel soll hier eine allgemeine Vorgehensweise gezeigt werden, wie man sofort loslegen könnte. Detailierte Informationen zu Bauvorgang, Optionen usw. findet man unter [[Images und Yadd's erstellen]].

mkdir $HOME/cvs $HOME/archive $HOME/customization $HOME/archive

Herunterladen/Aktualisieren des Tuxbox-CVS:
cd $HOME/cvs
CVS_RSH=ssh cvs -d anoncvs@cvs.tuxbox.org:/cvs/tuxbox -z3 co -P .
(beim ersten Mal die Frage nach RSA key fingerprint mit yes beantworten)

Kompilieren eines Images, dafür immer ein leeres Verzeichnis nehmen:

cd $HOME
rm -rf compile image
cp -r cvs compile
wenn Patches eingespielt werden sollen:
cd $HOME/compile
patch -p0 -E -i /home/tuxbox/datei.diff
weiter:
cd $HOME/compile/cdk
./autogen.sh

Für eine Übersicht aller Konfigurationsoptionen:
./configure --help

./configure --prefix=$HOME/image --with-cvsdir=$HOME/compile --with-archivedir=$HOME/archive

optional:

--with-[http://wiki.tuxbox.org/wiki/index.php/Images_und_Yadd%27s_erstellen#--with-rootpartitionsize.3D.5BSIZE.5D rootpartitionsize]=0x460000

--with-[http://wiki.tuxbox.org/wiki/index.php/Images_und_Yadd%27s_erstellen#--with-customizationsdir.3DDIR customizationsdir]=$HOME/customization

Nun können Images kompiliert werden:

make flash-neutrino-squashfs-all
make flash-enigma-squashfs-all
make flash-enigma+neutrino-squashfs-all

Das fertige Image liegt in

tuxbox@tuxbox:~$ ls -la $HOME/image/cdkflash/*img*
-rw-r--r-- 1 tuxbox tuxbox 8257536 3. Feb 16:31 /home/tuxbox/image/cdkflash/neutrino-squashfs.img1x
-rw-r--r-- 1 tuxbox tuxbox 8257536 3. Feb 16:31 /home/tuxbox/image/cdkflash/neutrino-squashfs.img2x

=Yadd-Setup=
Allgemeine Infos zum Thema [[Images und Yadd's erstellen]]

Hier nun die Setup-Anleitung für das VMWare-Image:

Setup einer Yadd-Umgebung, bestehend aus DHCP/bootp/NFS-Server.

Installieren und Konfigurieren des NFS-Servers:

su - root
Passwort für root eingeben, Enter
apt-get install --no-install-recommends nfs-kernel-server dhcp3-server tftpd
apt-get clean
sed -i "s/\/srv\/tftp/\/home\/tuxbox\/image\/tftpboot/" /etc/inetd.conf
echo "/home/tuxbox/image/cdkroot *(rw,sync,no_root_squash,no_subtree_check)" >> /etc/exports
logout

Von der Dbox wird die MAC-Adresse der Netzwerkkarte benötigt,
dazu muss bereits ein Linux-Image auf der Box laufen. Per Telnet
(geht auch mit Putty) eine Verbindung zur Dbox aufbauen,
Username root, dann
ifconfig eth0
eingeben und den Wert hinter HWaddr ermitteln, dieser muss
später in die Konfigurationsdatei des DHCP-Servers eingetragen
werden, Beispiel:
eth0 Link encap:Ethernet HWaddr 12:34:56:78:9A:BC
inet addr:192.168.1.4 Bcast:192.168.1.255 Mask:255.255.255.0
In diesem Fall ist die MAC-Adresse 12:34:56:78:9A:BC

Nun beginnt das Setup des DHCP-Servers innerhalb der VMWare-Sitzung.

Dieser wird benötigt, um Yadd zu booten. Wenn im Netzwerk bereits ein DHCP-Server aktiv ist, muss dessen Bootp-Unterstützung für die oben ermittelte MAC-Adresse deaktiviert werden. Da es viele unterschiedliche DHCP-Server gibt, kann ich hier nur ein Beispiel liefern:
host dbox
{
deny bootp;
hardware ethernet 12:34:56:78:9A:BC;
fixed-address 192.168.1.4;
}

Entscheidend ist hier die Zeile "deny bootp;".
Die Dbox hat die IP-Adresse 192.168.1.4, diese IP muss auch im DHCP-Server der VMWare-Sitzung für die Dbox verwendet werden.

Nun wird der DHCP-Server der VMWare-Sitzung konfiguriert, dazu wird der vorhandene Editor Nano genutzt, hier die [http://mintaka.sdsu.edu/reu/nano.html Tastenübersicht].

Am einfachsten ist es, folgende Konfiguration zu übernehmen und die mit Dollarzeichen ($$$Beschreibung$$$) markierten Einträge zu bearbeiten.

sudo rm /etc/dhcp3/dhcpd.conf
sudo nano /etc/dhcp3/dhcpd.conf

Folgenden Text in den Editor kopieren:
ddns-update-style none;
allow bootp;

option domain-name "$$$Domainname des Netzwerks$$$";
option domain-name-servers $$$IP des DNS-Servers$$$;
option routers $$$IP des DNS-Servers$$$;

default-lease-time 600;
max-lease-time 7200;

subnet $$$IP des DNS-Servers, endend auf Null$$$ netmask 255.255.255.0 {
}

host dbox {
fixed-address [b]$$$IP der Dbox$$$[/b];
hardware ethernet [b]$$$MAC-Adresse der Dbox$$$[/b];
server-name "[b]$$$IP der VMWare-Sitzung$$$[/b]";
next-server [b]$$$IP der VMWare-Sitzung$$$[/b];
option root-path "/home/tuxbox/image/cdkroot";
if exists vendor-class-identifier {
filename "/home/tuxbox/image/tftpboot/kernel-cdk";
} else {
filename "/home/tuxbox/image/tftpboot/u-boot";
}
}
STRG+X, J, Enter zum Speichern der Änderungen

sudo invoke-rc.d dhcp3-server restart
sudo invoke-rc.d nfs-kernel-server restart
sudo invoke-rc.d openbsd-inetd restart

Ein Yadd-Image eignet sich perfekt zum Debuggen.

Zum Kompilieren einer Yadd-Umgebung:
make yadd-neutrino
make yadd-enigma

Wenn Neutrino und Enigma gleichzeitig gewünscht sind:
make yadd-neutrino yadd-enigma

Nach dem Kompilieren die Dbox2 in den deep-standby fahren,
die o.g. Dienste aktivieren, ein serielles Log öffnen zum
Überwachen des Bootprozesses und die Dbox2 einschalten.

=Weblinks=
[http://forum.tuxbox.org/forum/viewtopic.php?f=13&t=48503 Ursprungsthread zu diesem Howto im Tuxbox-Forum]

Erstellen eines VMWare-Images

2011-02-27T12:35:42Z

Rhabarber1848: /* Lenny einrichten */

[[Category:Register]]
[[Category:Development]]
[[Category:CDK]]
{{Development_sidebar}}

__TOC__

=Allgemein=
Als sehr nützlich für die Erstellung einer Entwicklungsumgebung hat sich das Aufsetzen einer Virtualisierung erwiesen, wenn man nicht unbedingt ein komplettes Linuxsystem einrichten möchte oder kann. Dank gestiegener Hardwareleistung, insbesondere bei Mehrkernsystemen, ist der Umgang mit solch einer Lösung fast gleichwertig und eine sehr gute Alternative zu einem echtem Linuxsystem. Vor allem Neulinge auf diesem Gebiet, bietet diese Alternative einen optimalen Einstieg.
Dank vorgefertigter und zum Teil für bestimmte Verwendungszwecke zugeschnittene Images, sind solche Systeme relativ schnell eingerichtet.

=Voraussetzungen=
Es wird davon ausgegangen, dass eine Windowsinstallation (>=WindowsXP) vorhanden ist und die enstprechende Hardware mit möglichst ordentlicher CPU, am besten Mehrkern-CPU's, vorhanden ist.
Natürlich sollte [[VMware]] installiert sein. Eine Lösung über andere Virtualisierungs-Plattformen wie sie z.B. von Sun's [[VirtualBox]] besteht,
ist im wesentlichen auch möglich. Andere sollten auch möglich sein, aber hierfür sind momentan keine weiteren Informationen bekannt.

=Debian Lenny=
==Installation==
Es wird ein fertiges Image benötigt. Dafür diese Datei herunterladen:

http://cdimage.debian.org/debian-cd/current/i386/iso-cd/debian-506-i386-netinst.iso

===VMWare vorbereiten===
Einmaliger Prozess zum Erstellen des VMWare-Images:

*Menü File, New, Virtual Machine, Weiter, Typical, Linux - Ubuntu,
*Speicherort auswählen, Use bridged networking, 8GB -

Rest nicht verändern, Fertig stellen

*Menü VM, Settings, CD-ROM - Use ISO Image
obiges ISO auswählen

*Virtuelle Maschine starten
*Install,''' ''Enter'''''
*German,''' ''Enter'''''
*Deutschland,''' ''Enter'''''
*Deutsch,''' ''Enter'''''
(evtl. muss das Netzwerk konfiguriert werden)
*Rechnername tuxbox
*Geführt - verwende vollständige Festplatte,''' ''Enter'''''
'''''*Enter'''''
*Alle Dateien auf eine Partition,''' ''Enter'''''
*Partitionierung beenden und Änderungen übernehmen, ''Enter''
*Änderungen auf die Festplatten schreiben? Ja,''' ''Enter'''''

...Grundsystem wird installiert

*Root-Passwort vergeben
*Neuer Benutzer, Name:''' ''tuxbox'''''
*Benutzername:''' ''tuxbox'''''
Passwort vergeben
*Debian-Archiv-Spiegelserver Deutschland
*Server auswählen
*Paketverwendungserfassung nein,''' ''Enter'''''
*Keine Software-Sammlung auswählen

alle Sterne entfernen,''' ''Enter'''''

*Grub in Master Boot Record - Ja,''' ''Enter'''''

Nach Beendigung der Installation, virtuelle Maschine neustarten!

===Lenny einrichten===
Einmaliger Prozess zum Einrichten von Debian und Installieren der notwendigen Pakete:

Innerhalb der virtuellen Maschine anmelden als User '''root'''
apt-get update
apt-get upgrade
apt-get install --no-install-recommends sudo openssh-server
echo "tuxbox ALL=(ALL) ALL" >> /etc/sudoers
ifconfig (die IP-Adresse von eth0 merken)
logout

'''''STRG+ALT'',''' um das VMWare-Fenster wieder zu verlassen

per SSH ('''auf Windows ist [http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html Putty] zu empfehlen!''') zur virtuellen Maschine unter o.g. IP verbinden als User '''tuxbox''' einloggen
sudo apt-get install --no-install-recommends cvs libtool autoconf automake gettext autopoint make g++ flex bison patch bzip2 pkg-config zlib1g-dev python

für die Freunde des Midnight-Commanders:
sudo apt-get install --no-install-recommends mc

danach aufräumen:
sudo apt-get clean

=Tuxbox-CDK einrichten=
Als Bespiel soll hier eine allgemeine Vorgehensweise gezeigt werden, wie man sofort loslegen könnte. Detailierte Informationen zu Bauvorgang, Optionen usw. findet man unter [[Images und Yadd's erstellen]].

mkdir $HOME/cvs $HOME/archive $HOME/customization $HOME/archive

Herunterladen/Aktualisieren des Tuxbox-CVS:
cd $HOME/cvs
CVS_RSH=ssh cvs -d anoncvs@cvs.tuxbox.org:/cvs/tuxbox -z3 co -P .
(beim ersten Mal die Frage nach RSA key fingerprint mit yes beantworten)

Kompilieren eines Images, dafür immer ein leeres Verzeichnis nehmen:

cd $HOME
rm -rf compile image
cp -r cvs compile
wenn Patches eingespielt werden sollen:
cd $HOME/compile
patch -p0 -E -i /home/tuxbox/datei.diff
weiter:
cd $HOME/compile/cdk
./autogen.sh

Für eine Übersicht aller Konfigurationsoptionen:
./configure --help

./configure --prefix=$HOME/image --with-cvsdir=$HOME/compile --with-archivedir=$HOME/archive

optional:

--with-[http://wiki.tuxbox.org/wiki/index.php/Images_und_Yadd%27s_erstellen#--with-rootpartitionsize.3D.5BSIZE.5D rootpartitionsize]=0x460000

--with-[http://wiki.tuxbox.org/wiki/index.php/Images_und_Yadd%27s_erstellen#--with-customizationsdir.3DDIR customizationsdir]=$HOME/customization

Nun können Images kompiliert werden:

make flash-neutrino-squashfs-all
make flash-enigma-squashfs-all
make flash-enigma+neutrino-squashfs-all

Das fertige Image liegt in

tuxbox@tuxbox:~$ ls -la $HOME/image/cdkflash/*img*
-rw-r--r-- 1 tuxbox tuxbox 8257536 3. Feb 16:31 /home/tuxbox/image/cdkflash/neutrino-squashfs.img1x
-rw-r--r-- 1 tuxbox tuxbox 8257536 3. Feb 16:31 /home/tuxbox/image/cdkflash/neutrino-squashfs.img2x

=Yadd-Setup=
Allgemeine Infos zum Thema [[Images und Yadd's erstellen]]

Hier nun die Setup-Anleitung für das VMWare-Image:

Setup einer Yadd-Umgebung, bestehend aus DHCP/bootp/NFS-Server.

Installieren und Konfigurieren des NFS-Servers:

su - root
Passwort für root eingeben, Enter
apt-get install --no-install-recommends nfs-kernel-server dhcp3-server tftpd
apt-get clean
sed -i "s/\/srv\/tftp/\/home\/tuxbox\/image\/tftpboot/" /etc/inetd.conf
echo "/home/tuxbox/image/cdkroot *(rw,sync,no_root_squash,no_subtree_check)" >> /etc/exports
logout

Von der Dbox wird die MAC-Adresse der Netzwerkkarte benötigt,
dazu muss bereits ein Linux-Image auf der Box laufen. Per Telnet
(geht auch mit Putty) eine Verbindung zur Dbox aufbauen,
Username root, dann
ifconfig eth0
eingeben und den Wert hinter HWaddr ermitteln, dieser muss
später in die Konfigurationsdatei des DHCP-Servers eingetragen
werden, Beispiel:
eth0 Link encap:Ethernet HWaddr 12:34:56:78:9A:BC
inet addr:192.168.1.4 Bcast:192.168.1.255 Mask:255.255.255.0
In diesem Fall ist die MAC-Adresse 12:34:56:78:9A:BC

Nun beginnt das Setup des DHCP-Servers innerhalb der VMWare-Sitzung.

Dieser wird benötigt, um Yadd zu booten. Wenn im Netzwerk bereits ein DHCP-Server aktiv ist, muss dessen Bootp-Unterstützung für die oben ermittelte MAC-Adresse deaktiviert werden. Da es viele unterschiedliche DHCP-Server gibt, kann ich hier nur ein Beispiel liefern:
host dbox
{
deny bootp;
hardware ethernet 12:34:56:78:9A:BC;
fixed-address 192.168.1.4;
}

Entscheidend ist hier die Zeile "deny bootp;".
Die Dbox hat die IP-Adresse 192.168.1.4, diese IP muss auch im DHCP-Server der VMWare-Sitzung für die Dbox verwendet werden.

Nun wird der DHCP-Server der VMWare-Sitzung konfiguriert, dazu wird der vorhandene Editor Nano genutzt, hier die [http://mintaka.sdsu.edu/reu/nano.html Tastenübersicht].

Am einfachsten ist es, folgende Konfiguration zu übernehmen und die mit Dollarzeichen ($$$Beschreibung$$$) markierten Einträge zu bearbeiten.

sudo rm /etc/dhcp3/dhcpd.conf
sudo nano /etc/dhcp3/dhcpd.conf

Folgenden Text in den Editor kopieren:
ddns-update-style none;
allow bootp;

option domain-name "$$$Domainname des Netzwerks$$$";
option domain-name-servers $$$IP des DNS-Servers$$$;
option routers $$$IP des DNS-Servers$$$;

default-lease-time 600;
max-lease-time 7200;

subnet $$$IP des DNS-Servers, endend auf Null$$$ netmask 255.255.255.0 {
}

host dbox {
fixed-address [b]$$$IP der Dbox$$$[/b];
hardware ethernet [b]$$$MAC-Adresse der Dbox$$$[/b];
server-name "[b]$$$IP der VMWare-Sitzung$$$[/b]";
next-server [b]$$$IP der VMWare-Sitzung$$$[/b];
option root-path "/home/tuxbox/image/cdkroot";
if exists vendor-class-identifier {
filename "/home/tuxbox/image/tftpboot/kernel-cdk";
} else {
filename "/home/tuxbox/image/tftpboot/u-boot";
}
}
STRG+X, J, Enter zum Speichern der Änderungen

sudo invoke-rc.d dhcp3-server restart
sudo invoke-rc.d nfs-kernel-server restart
sudo invoke-rc.d openbsd-inetd restart

Ein Yadd-Image eignet sich perfekt zum Debuggen.

Zum Kompilieren einer Yadd-Umgebung:
make yadd-neutrino
make yadd-enigma

Wenn Neutrino und Enigma gleichzeitig gewünscht sind:
make yadd-neutrino yadd-enigma

Nach dem Kompilieren die Dbox2 in den deep-standby fahren,
die o.g. Dienste aktivieren, ein serielles Log öffnen zum
Überwachen des Bootprozesses und die Dbox2 einschalten.

=Weblinks=
[http://forum.tuxbox.org/forum/viewtopic.php?f=13&t=48503 Ursprungsthread zu diesem Howto im Tuxbox-Forum]

Erstellen eines VMWare-Images

2010-11-21T09:14:52Z

Rhabarber1848: /* Allgemein */

[[Category:Register]]
[[Category:Development]]
[[Category:CDK]]
{{Development_sidebar}}

__TOC__

=Allgemein=
Als sehr nützlich für die Erstellung einer Entwicklungsumgebung hat sich das Aufsetzen einer Virtualisierung erwiesen, wenn man nicht unbedingt ein komplettes Linuxsystem einrichten möchte oder kann. Dank gestiegener Hardwareleistung, insbesondere bei Mehrkernsystemen, ist der Umgang mit solch einer Lösung fast gleichwertig und eine sehr gute Alternative zu einem echtem Linuxsystem. Vor allem Neulinge auf diesem Gebiet, bietet diese Alternative einen optimalen Einstieg.
Dank vorgefertigter und zum Teil für bestimmte Verwendungszwecke zugeschnittene Images, sind solche Systeme relativ schnell eingerichtet.

=Voraussetzungen=
Es wird davon ausgegangen, dass eine Windowsinstallation (>=WindowsXP) vorhanden ist und die enstprechende Hardware mit möglichst ordentlicher CPU, am besten Mehrkern-CPU's, vorhanden ist.
Natürlich sollte [[VMware]] installiert sein. Eine Lösung über andere Virtualisierungs-Plattformen wie sie z.B. von Sun's [[VirtualBox]] besteht,
ist im wesentlichen auch möglich. Andere sollten auch möglich sein, aber hierfür sind momentan keine weiteren Informationen bekannt.

=Debian Lenny=
==Installation==
Es wird ein fertiges Image benötigt. Dafür diese Datei herunterladen:

http://cdimage.debian.org/debian-cd/current/i386/iso-cd/debian-506-i386-netinst.iso

===VMWare vorbereiten===
Einmaliger Prozess zum Erstellen des VMWare-Images:

*Menü File, New, Virtual Machine, Weiter, Typical, Linux - Ubuntu,
*Speicherort auswählen, Use bridged networking, 8GB -

Rest nicht verändern, Fertig stellen

*Menü VM, Settings, CD-ROM - Use ISO Image
obiges ISO auswählen

*Virtuelle Maschine starten
*Install,''' ''Enter'''''
*German,''' ''Enter'''''
*Deutschland,''' ''Enter'''''
*Deutsch,''' ''Enter'''''
(evtl. muss das Netzwerk konfiguriert werden)
*Rechnername tuxbox
*Geführt - verwende vollständige Festplatte,''' ''Enter'''''
'''''*Enter'''''
*Alle Dateien auf eine Partition,''' ''Enter'''''
*Partitionierung beenden und Änderungen übernehmen, ''Enter''
*Änderungen auf die Festplatten schreiben? Ja,''' ''Enter'''''

...Grundsystem wird installiert

*Root-Passwort vergeben
*Neuer Benutzer, Name:''' ''tuxbox'''''
*Benutzername:''' ''tuxbox'''''
Passwort vergeben
*Debian-Archiv-Spiegelserver Deutschland
*Server auswählen
*Paketverwendungserfassung nein,''' ''Enter'''''
*Keine Software-Sammlung auswählen

alle Sterne entfernen,''' ''Enter'''''

*Grub in Master Boot Record - Ja,''' ''Enter'''''

Nach Beendigung der Installation, virtuelle Maschine neustarten!

===Lenny einrichten===
Einmaliger Prozess zum Einrichten von Debian und Installieren der notwendigen Pakete:

Innerhalb der virtuellen Maschine anmelden als User '''root'''
apt-get update
apt-get upgrade
apt-get install --no-install-recommends sudo openssh-server
echo "tuxbox ALL=(ALL) ALL" >> /etc/sudoers
ifconfig (die IP-Adresse von eth0 merken)
logout

'''''STRG+ALT'',''' um das VMWare-Fenster wieder zu verlassen

per SSH ('''auf Windows ist [http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html Putty] zu empfehlen!''') zur virtuellen Maschine unter o.g. IP verbinden als User '''tuxbox''' einloggen
sudo apt-get install --no-install-recommends cvs libtool autoconf automake gettext make g++ flex bison patch bzip2 pkg-config zlib1g-dev python

für die Freunde des Midnight-Commanders:
sudo apt-get install --no-install-recommends mc

danach aufräumen:
sudo apt-get clean

=Tuxbox-CDK einrichten=
Als Bespiel soll hier eine allgemeine Vorgehensweise gezeigt werden, wie man sofort loslegen könnte. Detailierte Informationen zu Bauvorgang, Optionen usw. findet man unter [[Images und Yadd's erstellen]].

mkdir $HOME/cvs $HOME/archive $HOME/customization $HOME/archive

Herunterladen/Aktualisieren des Tuxbox-CVS:
cd $HOME/cvs
CVS_RSH=ssh cvs -d anoncvs@cvs.tuxbox.org:/cvs/tuxbox -z3 co -P .
(beim ersten Mal die Frage nach RSA key fingerprint mit yes beantworten)

Kompilieren eines Images, dafür immer ein leeres Verzeichnis nehmen:

cd $HOME
rm -rf compile image
cp -r cvs compile
wenn Patches eingespielt werden sollen:
cd $HOME/compile
patch -p0 -E -i /home/tuxbox/datei.diff
weiter:
cd $HOME/compile/cdk
./autogen.sh

Für eine Übersicht aller Konfigurationsoptionen:
./configure --help

./configure --prefix=$HOME/image --with-cvsdir=$HOME/compile --with-archivedir=$HOME/archive

optional:

--with-[http://wiki.tuxbox.org/wiki/index.php/Images_und_Yadd%27s_erstellen#--with-rootpartitionsize.3D.5BSIZE.5D rootpartitionsize]=0x460000

--with-[http://wiki.tuxbox.org/wiki/index.php/Images_und_Yadd%27s_erstellen#--with-customizationsdir.3DDIR customizationsdir]=$HOME/customization

Nun können Images kompiliert werden:

make flash-neutrino-squashfs-all
make flash-enigma-squashfs-all
make flash-enigma+neutrino-squashfs-all

Das fertige Image liegt in

tuxbox@tuxbox:~$ ls -la $HOME/image/cdkflash/*img*
-rw-r--r-- 1 tuxbox tuxbox 8257536 3. Feb 16:31 /home/tuxbox/image/cdkflash/neutrino-squashfs.img1x
-rw-r--r-- 1 tuxbox tuxbox 8257536 3. Feb 16:31 /home/tuxbox/image/cdkflash/neutrino-squashfs.img2x

=Yadd-Setup=
Allgemeine Infos zum Thema [[Images und Yadd's erstellen]]

Hier nun die Setup-Anleitung für das VMWare-Image:

Setup einer Yadd-Umgebung, bestehend aus DHCP/bootp/NFS-Server.

Installieren und Konfigurieren des NFS-Servers:

su - root
Passwort für root eingeben, Enter
apt-get install --no-install-recommends nfs-kernel-server dhcp3-server tftpd
apt-get clean
sed -i "s/\/srv\/tftp/\/home\/tuxbox\/image\/tftpboot/" /etc/inetd.conf
echo "/home/tuxbox/image/cdkroot *(rw,sync,no_root_squash,no_subtree_check)" >> /etc/exports
logout

Von der Dbox wird die MAC-Adresse der Netzwerkkarte benötigt,
dazu muss bereits ein Linux-Image auf der Box laufen. Per Telnet
(geht auch mit Putty) eine Verbindung zur Dbox aufbauen,
Username root, dann
ifconfig eth0
eingeben und den Wert hinter HWaddr ermitteln, dieser muss
später in die Konfigurationsdatei des DHCP-Servers eingetragen
werden, Beispiel:
eth0 Link encap:Ethernet HWaddr 12:34:56:78:9A:BC
inet addr:192.168.1.4 Bcast:192.168.1.255 Mask:255.255.255.0
In diesem Fall ist die MAC-Adresse 12:34:56:78:9A:BC

Nun beginnt das Setup des DHCP-Servers innerhalb der VMWare-Sitzung.

Dieser wird benötigt, um Yadd zu booten. Wenn im Netzwerk bereits ein DHCP-Server aktiv ist, muss dessen Bootp-Unterstützung für die oben ermittelte MAC-Adresse deaktiviert werden. Da es viele unterschiedliche DHCP-Server gibt, kann ich hier nur ein Beispiel liefern:
host dbox
{
deny bootp;
hardware ethernet 12:34:56:78:9A:BC;
fixed-address 192.168.1.4;
}

Entscheidend ist hier die Zeile "deny bootp;".
Die Dbox hat die IP-Adresse 192.168.1.4, diese IP muss auch im DHCP-Server der VMWare-Sitzung für die Dbox verwendet werden.

Nun wird der DHCP-Server der VMWare-Sitzung konfiguriert, dazu wird der vorhandene Editor Nano genutzt, hier die [http://mintaka.sdsu.edu/reu/nano.html Tastenübersicht].

Am einfachsten ist es, folgende Konfiguration zu übernehmen und die mit Dollarzeichen ($$$Beschreibung$$$) markierten Einträge zu bearbeiten.

sudo rm /etc/dhcp3/dhcpd.conf
sudo nano /etc/dhcp3/dhcpd.conf

Folgenden Text in den Editor kopieren:
ddns-update-style none;
allow bootp;

option domain-name "$$$Domainname des Netzwerks$$$";
option domain-name-servers $$$IP des DNS-Servers$$$;
option routers $$$IP des DNS-Servers$$$;

default-lease-time 600;
max-lease-time 7200;

subnet $$$IP des DNS-Servers, endend auf Null$$$ netmask 255.255.255.0 {
}

host dbox {
fixed-address [b]$$$IP der Dbox$$$[/b];
hardware ethernet [b]$$$MAC-Adresse der Dbox$$$[/b];
server-name "[b]$$$IP der VMWare-Sitzung$$$[/b]";
next-server [b]$$$IP der VMWare-Sitzung$$$[/b];
option root-path "/home/tuxbox/image/cdkroot";
if exists vendor-class-identifier {
filename "/home/tuxbox/image/tftpboot/kernel-cdk";
} else {
filename "/home/tuxbox/image/tftpboot/u-boot";
}
}
STRG+X, J, Enter zum Speichern der Änderungen

sudo invoke-rc.d dhcp3-server restart
sudo invoke-rc.d nfs-kernel-server restart
sudo invoke-rc.d openbsd-inetd restart

Ein Yadd-Image eignet sich perfekt zum Debuggen.

Zum Kompilieren einer Yadd-Umgebung:
make yadd-neutrino
make yadd-enigma

Wenn Neutrino und Enigma gleichzeitig gewünscht sind:
make yadd-neutrino yadd-enigma

Nach dem Kompilieren die Dbox2 in den deep-standby fahren,
die o.g. Dienste aktivieren, ein serielles Log öffnen zum
Überwachen des Bootprozesses und die Dbox2 einschalten.

=Weblinks=
[http://forum.tuxbox.org/forum/viewtopic.php?f=13&t=48503 Ursprungsthread zu diesem Howto im Tuxbox-Forum]

Erstellen eines VMWare-Images

2010-11-21T09:12:27Z

Rhabarber1848: /* Weitere Informationen */

[[Category:Register]]
[[Category:Development]]
[[Category:CDK]]
{{Development_sidebar}}

__TOC__

=Allgemein=
Als sehr nützlich für die Erstellung einer Entwicklungsumgebung hat sich das Aufsetzen einer Virtualisierung erwiesen, wenn man nicht unbedingt ein komplettes Linuxsystem einrichten möchte oder kann. Dank gestiegener Hardwareleistung, insbesondere bei Mehrkernsystemen, ist der Umgang mit solch einer Lösung fast gleichwertig und eine sehr gute Alternative zu einem echtem Linuxsystem. Vorallem Neulinge auf diesem Gebiet, bietet diese Alternative einen optimalen Einstieg.
Dank vorgefertigter und zum Teil für bestimmte Verwendungszwecke zugeschnittene Images, sind solche Systeme relativ schnell eingerichtet.

=Voraussetzungen=
Es wird davon ausgegangen, dass eine Windowsinstallation (>=WindowsXP) vorhanden ist und die enstprechende Hardware mit möglichst ordentlicher CPU, am besten Mehrkern-CPU's, vorhanden ist.
Natürlich sollte [[VMware]] installiert sein. Eine Lösung über andere Virtualisierungs-Plattformen wie sie z.B. von Sun's [[VirtualBox]] besteht,
ist im wesentlichen auch möglich. Andere sollten auch möglich sein, aber hierfür sind momentan keine weiteren Informationen bekannt.

=Debian Lenny=
==Installation==
Es wird ein fertiges Image benötigt. Dafür diese Datei herunterladen:

http://cdimage.debian.org/debian-cd/current/i386/iso-cd/debian-506-i386-netinst.iso

===VMWare vorbereiten===
Einmaliger Prozess zum Erstellen des VMWare-Images:

*Menü File, New, Virtual Machine, Weiter, Typical, Linux - Ubuntu,
*Speicherort auswählen, Use bridged networking, 8GB -

Rest nicht verändern, Fertig stellen

*Menü VM, Settings, CD-ROM - Use ISO Image
obiges ISO auswählen

*Virtuelle Maschine starten
*Install,''' ''Enter'''''
*German,''' ''Enter'''''
*Deutschland,''' ''Enter'''''
*Deutsch,''' ''Enter'''''
(evtl. muss das Netzwerk konfiguriert werden)
*Rechnername tuxbox
*Geführt - verwende vollständige Festplatte,''' ''Enter'''''
'''''*Enter'''''
*Alle Dateien auf eine Partition,''' ''Enter'''''
*Partitionierung beenden und Änderungen übernehmen, ''Enter''
*Änderungen auf die Festplatten schreiben? Ja,''' ''Enter'''''

...Grundsystem wird installiert

*Root-Passwort vergeben
*Neuer Benutzer, Name:''' ''tuxbox'''''
*Benutzername:''' ''tuxbox'''''
Passwort vergeben
*Debian-Archiv-Spiegelserver Deutschland
*Server auswählen
*Paketverwendungserfassung nein,''' ''Enter'''''
*Keine Software-Sammlung auswählen

alle Sterne entfernen,''' ''Enter'''''

*Grub in Master Boot Record - Ja,''' ''Enter'''''

Nach Beendigung der Installation, virtuelle Maschine neustarten!

===Lenny einrichten===
Einmaliger Prozess zum Einrichten von Debian und Installieren der notwendigen Pakete:

Innerhalb der virtuellen Maschine anmelden als User '''root'''
apt-get update
apt-get upgrade
apt-get install --no-install-recommends sudo openssh-server
echo "tuxbox ALL=(ALL) ALL" >> /etc/sudoers
ifconfig (die IP-Adresse von eth0 merken)
logout

'''''STRG+ALT'',''' um das VMWare-Fenster wieder zu verlassen

per SSH ('''auf Windows ist [http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html Putty] zu empfehlen!''') zur virtuellen Maschine unter o.g. IP verbinden als User '''tuxbox''' einloggen
sudo apt-get install --no-install-recommends cvs libtool autoconf automake gettext make g++ flex bison patch bzip2 pkg-config zlib1g-dev python

für die Freunde des Midnight-Commanders:
sudo apt-get install --no-install-recommends mc

danach aufräumen:
sudo apt-get clean

=Tuxbox-CDK einrichten=
Als Bespiel soll hier eine allgemeine Vorgehensweise gezeigt werden, wie man sofort loslegen könnte. Detailierte Informationen zu Bauvorgang, Optionen usw. findet man unter [[Images und Yadd's erstellen]].

mkdir $HOME/cvs $HOME/archive $HOME/customization $HOME/archive

Herunterladen/Aktualisieren des Tuxbox-CVS:
cd $HOME/cvs
CVS_RSH=ssh cvs -d anoncvs@cvs.tuxbox.org:/cvs/tuxbox -z3 co -P .
(beim ersten Mal die Frage nach RSA key fingerprint mit yes beantworten)

Kompilieren eines Images, dafür immer ein leeres Verzeichnis nehmen:

cd $HOME
rm -rf compile image
cp -r cvs compile
wenn Patches eingespielt werden sollen:
cd $HOME/compile
patch -p0 -E -i /home/tuxbox/datei.diff
weiter:
cd $HOME/compile/cdk
./autogen.sh

Für eine Übersicht aller Konfigurationsoptionen:
./configure --help

./configure --prefix=$HOME/image --with-cvsdir=$HOME/compile --with-archivedir=$HOME/archive

optional:

--with-[http://wiki.tuxbox.org/wiki/index.php/Images_und_Yadd%27s_erstellen#--with-rootpartitionsize.3D.5BSIZE.5D rootpartitionsize]=0x460000

--with-[http://wiki.tuxbox.org/wiki/index.php/Images_und_Yadd%27s_erstellen#--with-customizationsdir.3DDIR customizationsdir]=$HOME/customization

Nun können Images kompiliert werden:

make flash-neutrino-squashfs-all
make flash-enigma-squashfs-all
make flash-enigma+neutrino-squashfs-all

Das fertige Image liegt in

tuxbox@tuxbox:~$ ls -la $HOME/image/cdkflash/*img*
-rw-r--r-- 1 tuxbox tuxbox 8257536 3. Feb 16:31 /home/tuxbox/image/cdkflash/neutrino-squashfs.img1x
-rw-r--r-- 1 tuxbox tuxbox 8257536 3. Feb 16:31 /home/tuxbox/image/cdkflash/neutrino-squashfs.img2x

=Yadd-Setup=
Allgemeine Infos zum Thema [[Images und Yadd's erstellen]]

Hier nun die Setup-Anleitung für das VMWare-Image:

Setup einer Yadd-Umgebung, bestehend aus DHCP/bootp/NFS-Server.

Installieren und Konfigurieren des NFS-Servers:

su - root
Passwort für root eingeben, Enter
apt-get install --no-install-recommends nfs-kernel-server dhcp3-server tftpd
apt-get clean
sed -i "s/\/srv\/tftp/\/home\/tuxbox\/image\/tftpboot/" /etc/inetd.conf
echo "/home/tuxbox/image/cdkroot *(rw,sync,no_root_squash,no_subtree_check)" >> /etc/exports
logout

Von der Dbox wird die MAC-Adresse der Netzwerkkarte benötigt,
dazu muss bereits ein Linux-Image auf der Box laufen. Per Telnet
(geht auch mit Putty) eine Verbindung zur Dbox aufbauen,
Username root, dann
ifconfig eth0
eingeben und den Wert hinter HWaddr ermitteln, dieser muss
später in die Konfigurationsdatei des DHCP-Servers eingetragen
werden, Beispiel:
eth0 Link encap:Ethernet HWaddr 12:34:56:78:9A:BC
inet addr:192.168.1.4 Bcast:192.168.1.255 Mask:255.255.255.0
In diesem Fall ist die MAC-Adresse 12:34:56:78:9A:BC

Nun beginnt das Setup des DHCP-Servers innerhalb der VMWare-Sitzung.

Dieser wird benötigt, um Yadd zu booten. Wenn im Netzwerk bereits ein DHCP-Server aktiv ist, muss dessen Bootp-Unterstützung für die oben ermittelte MAC-Adresse deaktiviert werden. Da es viele unterschiedliche DHCP-Server gibt, kann ich hier nur ein Beispiel liefern:
host dbox
{
deny bootp;
hardware ethernet 12:34:56:78:9A:BC;
fixed-address 192.168.1.4;
}

Entscheidend ist hier die Zeile "deny bootp;".
Die Dbox hat die IP-Adresse 192.168.1.4, diese IP muss auch im DHCP-Server der VMWare-Sitzung für die Dbox verwendet werden.

Nun wird der DHCP-Server der VMWare-Sitzung konfiguriert, dazu wird der vorhandene Editor Nano genutzt, hier die [http://mintaka.sdsu.edu/reu/nano.html Tastenübersicht].

Am einfachsten ist es, folgende Konfiguration zu übernehmen und die mit Dollarzeichen ($$$Beschreibung$$$) markierten Einträge zu bearbeiten.

sudo rm /etc/dhcp3/dhcpd.conf
sudo nano /etc/dhcp3/dhcpd.conf

Folgenden Text in den Editor kopieren:
ddns-update-style none;
allow bootp;

option domain-name "$$$Domainname des Netzwerks$$$";
option domain-name-servers $$$IP des DNS-Servers$$$;
option routers $$$IP des DNS-Servers$$$;

default-lease-time 600;
max-lease-time 7200;

subnet $$$IP des DNS-Servers, endend auf Null$$$ netmask 255.255.255.0 {
}

host dbox {
fixed-address [b]$$$IP der Dbox$$$[/b];
hardware ethernet [b]$$$MAC-Adresse der Dbox$$$[/b];
server-name "[b]$$$IP der VMWare-Sitzung$$$[/b]";
next-server [b]$$$IP der VMWare-Sitzung$$$[/b];
option root-path "/home/tuxbox/image/cdkroot";
if exists vendor-class-identifier {
filename "/home/tuxbox/image/tftpboot/kernel-cdk";
} else {
filename "/home/tuxbox/image/tftpboot/u-boot";
}
}
STRG+X, J, Enter zum Speichern der Änderungen

sudo invoke-rc.d dhcp3-server restart
sudo invoke-rc.d nfs-kernel-server restart
sudo invoke-rc.d openbsd-inetd restart

Ein Yadd-Image eignet sich perfekt zum Debuggen.

Zum Kompilieren einer Yadd-Umgebung:
make yadd-neutrino
make yadd-enigma

Wenn Neutrino und Enigma gleichzeitig gewünscht sind:
make yadd-neutrino yadd-enigma

Nach dem Kompilieren die Dbox2 in den deep-standby fahren,
die o.g. Dienste aktivieren, ein serielles Log öffnen zum
Überwachen des Bootprozesses und die Dbox2 einschalten.

=Weblinks=
[http://forum.tuxbox.org/forum/viewtopic.php?f=13&t=48503 Ursprungsthread zu diesem Howto im Tuxbox-Forum]

Erstellen eines VMWare-Images

2010-11-21T09:03:23Z

Rhabarber1848: /* Tuxbox-CDK einrichten */

Erstellen eines VMWare-Images

2010-11-21T08:57:34Z

Rhabarber1848: /* Tuxbox-CDK einrichten */

Erstellen eines VMWare-Images

2010-11-21T08:56:28Z

Rhabarber1848: /* Lenny einrichten */

Erstellen eines VMWare-Images

2010-11-21T08:55:33Z

Rhabarber1848: /* Lenny einrichten */

Erstellen eines VMWare-Images

2010-11-21T08:54:42Z

Rhabarber1848: /* Installation */

Erstellen eines VMWare-Images

2010-04-05T19:34:35Z

Rhabarber1848: /* Installation */

Dbox2 Entwicklungsumgebung

2009-12-27T11:20:31Z

Rhabarber1848:

[[Category:Register]]
[[Category:Development]]
[[Category:CDK]]
{{Development_sidebar}}

__TOC__
{{Review}}
=Allgemeines=
Die Erstellung von [[Images]] und [[Yadd]]s erfolgt durch einen neuen bzw. überarbeiteten "[[Make|make]]" Prozesses, bisher auch als "Newmake" bekannt. Der inzwischen auch als [[Image erstellen|Oldmake]] bezeichnete Bulidvorgang wurde komplett abgelöst. Dieser existiert allerdings weiterhin als eigenständiger Zweig (Branch) im Tuxbox-CVS und kann auch weiter verwendet und gepflegt werden. Die entsprechenden Artikel, die Oldmake betreffen, kann man unter [[Development |Development (Oldmake)]] finden.

Neben einer strukturierteren Basis, hat man jetzt den Vorteil, dass es auch ohne ohne großes Verständnis für den Buildprozess gelingen kann, [[Images|Flashimages]] und [[yadd|YADDs]] unter [[Linux|Linux]] zu erstellen.
Es gibt inzwischen auch eine auf Konsole basierende Frontendlösung, mit der sich [[Images|Flashimages]] oder [[yadd|YADDs]] benutzerdefiniert erstellen lassen, das sogenannte [[yBuild]].

Dieser Artikel basiert zum größtem Teil auf die deutsche Version von [http://bengt-martensson.de/dbox2/ Barfs Newmake-Dokumentation], die er uns freundlicherweise zur Verfügung gestellt hat.
Eine detaillierte Beschreibung (auch der [[Make|make]] targets) unter anderem auch in englischer Sprache befindet sich auf [http://bengt-martensson.de/dbox2/ Barf's Homepage]. 

Dieser Artikel behandelt die [[Image]]- u. [[yadd|YADD]]-Herstellung sowie einfache Beipiele für Benutzeranpassungen ("[[Customization]]"). 

==Zur Geschichte==
Vor einigen Jahren war die Imageherstellung für die [[Tuxbox|Tuxbox]] so etwas wie [[Wikipedia:Schwarze Kunst|"Schwarze Kunst"]].
Die Makefile-Unterstützung war, insbesondere für andere [[Images]] als [[cramfs]]-[[Images]], ziemlich lückenhaft. Die [[CVS]] Werkzeuge waren schlecht oder unvollständig. Noch schlimmer, einige Teile wurden absichtlich geheim gehalten. Vorallem das Werkzeug, jetzt als [[mkflfs]] bekannt, welches inzwischen aber im [[CVS|CVS]]-Verzeichnis ''.../hostapps/[[Mkflfs|mkflfs]]'' zu finden ist, wurde zurückgehalten.

Laut eines Forumsbeitrags aus dieser Zeit, waren die meisten Entwickler nicht in der Lage, eigene [[Images]] herzustellen. Die "Gilde der Imagehersteller" wurde geboren. Aus dieser Zeit dürften die "[[AlexW-Images]]" ein Begriff sein.
Hauptsächlich bestanden diese aus reinen [[CVS|CVS]]-Sources mit einigen mehr-oder-weniger geheim gehaltenen "Fixes", (vermutlich) notwendig für das Herstellen eines funktionierenden [[Images]] aus dem [[CVS|CVS]]-Quellcode.

Im August 2003, wurde es für das [[DBox2 Software Projekt|GNU DBox2 Software-Projekt]] in zunehmendem Maße peinlich, [[mkflfs]] geheim zu halten und der Quellcode für [[mkflfs]] wurde ins [[CVS]] eingecheckt. Auch die Funktionalität der [[Makefiles]] wurde stufenweise verbessert. Noch war viel zu wünschen übrig: Funktionalität, Pflegbarkeit, gesundes [[Software|Software]]-Design... Ein [[Image]] aus reinen [[CVS|CVS]]-Dateien zu bauen, war nicht wirklich möglich.

2004 wurde das [[YADI]] ("'''Y'''et '''A'''nother '''D'''Box '''I'''mage") Projekt geboren. 
Sein Ziel war es, das "Imagebauen" zu automatisieren und zu vereinfachen. Zu diesem Zweck wurden eine Anzahl von [[Wikipedia:Skripte|Scripten]] und [[Wikipedia:Patches|Patches]] gesammelt und/oder geschrieben. Zusätzlich wurden flashfertige [[Images]] zur Verfügung gestellt.
[[YADI]] war ein grosser Erfolg. Das Ziel wurde erreicht. [[Images]] wurden zur Verfügung gestellt, die (fast) vollständig auf freier [[Software|Software]] basierten, sowohl inhaltlich als auch bezüglich der benötigten Werkzeuge, in einer Weise, die für den Benutzer durchaus nachvollziehbar war.

Mit dem [[YADI]]-[[Skript|Skript]] war das automatische Imagebuilden zwar möglich, jedoch statt grundlegende Schwächen im [[CDK|CDK]]-Imagebau-Prozeß zu beseitigen, stellte man [[Skripte]] zum Imagebauen zur Verfügung. Es wurde kein übliches Buildsystem zur Verfügung gestellt, wie dies beispielsweise von [[Make]], oder ein neuerer Nachfolger wie [[Ant]],[[Cmake]] oder [[Maven]] könnten.

Newmake, bis Ende 2008 verfügbar als alternativer [[Branch]] und seit 2009 als HEAD im [[CVS|CVS]], versucht diese Schwächen zu beseitigen.
Ein spezieller Dank an jeden, der Bugreports und Feedback geliefert hat. Insbesonderes gilt dies für dietmarw, der Newmake benutzt, um die [[Images#DietmarW-Images|dietmarW-Images]] zu erzeugen.

=Ziel=
Das Ziel des vorliegenden Artikels ist es, dem Leser grundlegendes Know-How zu vermitteln. Es ist nicht das Ziel, eine idiotensichere Schritt-für-Schritt Anweisung bereitzustellen, wie das bei sogenannten HOWTO's der Fall wäre.
Kenntnisse im Umgang mit [[Wikipedia:Skriptsprache|Shellskripten]] wird für viele Teile, insbesondere für das [[Customization]]-Kapitel, aber nicht für [[Image]]/[[yadd|YADD]]-Herstellung in seiner einfachsten Art und Weise vorausgesetzt.

Der vorliegende Artikel versucht nicht die innere Funktion der [[Makefiles]] und des Makeprozesses zu beschreiben. Hierfür wird der Leser auf diverse Quellen, und zu relevanten Threads im [[CDK]]-Forum des [[Tuxbox|Tuxbox]]-Forums hingewiesen. Alle Optionen für ''configure'' werden auch nicht beschrieben, nur die Allgemeinsten und Wichtigsten.

= Wie schwierig ist es? =
Die Antwort könnte lauten: ''Es ist so schwerig wie man diesen Artikel zu lesen versteht.'' Für den Leser, der ohne Probleme den Inhalt dieses Artikels versteht, sollte es kein Probleme sein. Leser, für die das Meiste nur Kauderwelsch ist, sollten vielleicht besser bei fertigen [[Images|Images]] bleiben.

= [[Images|Images]] und [[Yadd|YADD]]'s bauen=
== Targets ==
Es gibt neben zahlreichen untergeordneten Zielen (Targets), zwei hauptrangige Targets, um [[Images]] oder [[Yadd]]'s zu bauen. Diese wären logischerweise entweder
*[[YADD]]
oder
*[[Image]].
Ein [[YADD]] besteht aus einigen Dateien, die die DBox anstatt aus dem [[Flash]] über den [[TFTP]]-Service lädt, sowie ein [[Filesystem|Filesystem]], das über einen [[NFS-Server]] der dBox zur Verfügung gestellt wird.
Diese Daten befinden sich in der Regel in
*.../tftpboot
*.../cdkroot ''oder'' .../yaddroot
Diese Betriebsart hat insbesondere während der Softwareentwicklung oder beim Erlernen des Systems viele Vorteile.

''Der Name "[[YADD]]" bedeutet übrigens "'''Y'''et '''A'''nother '''D'''Box '''D'''istribution" ("noch eine dBox Verteilung").''

=== Erste Schritte und Überlegungen ===
Eine Empfehlung für den angehenden "[[Image|Image]]/[[Yadd|YADD]]-Lehrling" wäre: 
Baue zuerst ein [[YADD]] mit Deiner Lieblings-[[GUI]], und lerne damit umzugehen. 
Nächster Schritt wäre dann, ein [[jffs2]]-[[Image|Image]] mit der Lieblings-[[GUI]] zu erstellen.

Meistens möchte man die folgenden Schritte kombinieren und/oder automatisieren.

In diesem Artikel bezeichnet "[[GUI]]" entweder
*[[Neutrino]]
*[[Enigma]]
*[[Lcars]]
*[[Radiobox]].

Das "[[Filesystem]]" im Kontext eines kompletten [[Images]] bezeichnet das [[Dateisystem]], in dem das root-Verzeichnis liegt.

Dies wären:
*[[squashfs]] (komprimiertes read-only-[[Dateisystem|Dateisystem]] (wird allgemnein leistungsfähiger als [[cramfs]] angesehen)
oder
*[[jffs2]] (ein "journalled" Read-Write-[[Filesystem|Filesystem]]).

'''Hinweis:'''
''[[Cramfs]]-Images, (komprimiertes, Read-only [[Filesystem|filesystem]] für embedded Systeme) werden vom Buildprozess mit CVS-Stand ab 26.07.2009 nicht mehr untertützt.''

Ein "'''[[Squashfs|Squashfs]] Komplett-[[Image|Image]]'''" besteht aus einem Root-[[Dateisystem|Dateisystem]] mit dem [[squashfs]] [[Dateisystem|Dateisystem]] und einem kleineren [[jffs2]]-[[Filesystem|Filesystem]], das nach '''/var''', dem schreibbaren Bereich eines [[Images]], gemounted wird.
 
Ein "'''[[Jffs2|jffs2]] Komplett-[[Image|Image]]'''" enthält dagegen kein separates ''/var-[[Dateisystem|Dateisystem]]'', weil [[Jffs2|jffs2]] bereits beschreibbar ist.
Welches Dateisystem man verwendet, hängt im Wesentlichem davon ab, was und wieviel man in das Image packen möchte.

Zusätzlich enthalten die Komplett-[[Images|Images]] eine weitere [[Partition|Partition]], die den [[u-boot]]-[[Bootloader]] enthalten. Diese [[Partition|Partition]] ist zwischen dBoxen mit einen und zwei [[Flash]]chips unterschiedlich. Dieses wird durch "'''1x'''" und "'''2x'''" angezeigt. Ein komplettes [[Image|Image]] würde demnach so benannt werden:

[GUI]-[Filesystem].img[1, 2]x
z.B. als fertiges [[Image|Image]]:
[[Neutrino|neutrino]]-[[Jffs2|jffs2]].img2x

== Buildsystem Voraussetzungen ==
Neben einem modernen [[Unix|Unix]]/[[Linux|Linux]] System ist '''ordentlich''' freier Speicherplatz zu empfehlen. Mit Speicherplatz sollte man deshalb nicht geizen, da beispielsweise bei Verwendung von [[ccache]] einiges an Daten zwischengelagert wird und je öfter man kompiliert, es dann doch eng werden könnte.

Das [[DBox2 Software Projekt|Tuxbox Projekt]] hat keine favorisierte Buildumgebung. Fragen wie "geht es mit Redhat x.y?" lassen sich nicht genau beantworten. Gewisse Anforderungen werden dagegen für Versionen der Werkzeuge, wie [[WP:autoconf|autoconf]], [[WP:automake|automake]], [[make]] usw. formuliert. Die meisten davon sind in den gängigsten Distributionen bereits enthalten bzw. können nachinstalliert werden. Die momentan erforderlichen Toolversionen sind in folgendender Tabelle zusammengefasst:

{{Vorlage:GNU_Tools}}

Der Buildprozess überprüft zu Beginn automatisch einige dieser Anforderungen. Wenn eines dieser Werkzeuge fehlt, oder wenn die Version zu alt zu sein scheint, ist es in der Regel einfacher, die erforderliche Version nachträglich zu installieren, entweder als kompiliertes Paket, z.B. im [[rpm]]-Format vom jeweiligem Distributor, oder sich direkt die Quellen zu besorgen, zu kompilieren und zu installieren, als zu versuchen oder herauszufinden, ob die oben genannten Anforderungen wirklich notwendig sind.

'''''Hinweis''':

''In anderen Anleitungen zum Buildvorgang wird gefordert, dass Werkzeuge wie [[fakeroot]],
[[mksquashfs]], [[mkcramfs]], [[mkjffs2fs]] (oder [[mkfs.jffs2]]), vielleicht auch [[mklibs]]
oder [[ccache]], auf Ihrem System installiert sein müssen. In dieser Umgebung ist dies nicht
erforderlich, da einige entweder überhaupt nicht benötigt werden bzw. die Installation im
Makeprozess selbst vorgenommen wird!''

Das Bauen auf einem [[Unix|Unix]]-non-[[Linux|Linux]] System sollte vermutlich auch möglich sein, so weit die erforderlichen [[GNU]] Werkzeuge vorhanden sind. Mit einem anderen [[make]] als [[GNU]] wird es fast sicher nicht funktionieren, da die [[GNU|GNU]]-Spezifikationen uneingeschränkt verwendet werden.

Es wird davon abgeraten, eine Umbegebung z.B. mit [[Cygwin]] aufzubauen, da es mit Sicherheit nicht funktionieren wird. In dieser Richtung wurde zwar Einiges für den Makeprozess eingebaut, jedoch wurde der [[Cygwin]]-Support inzwischen entfernt, da der bisherige Entwicklungsstand nicht den Anforderungen entsprach, um aktuell auch damit arbeiten zu können. Dafür gibt es inzwischen wesentlich bessere Alternativen.
Empfehlenswert ist aber eine Buildumgebung mittels [[VMWare]] aufzubauen. Hierfür gibt es auch eine "konfektionierte" Lösung von yiogol, der hierfür ein passendes [http://www.dbox2-tuning.net/ulc/index.php?PHPSESSID=ecf28f3ddf88fa340678898f1636942c&direction=0&order=&directory=Kubuntu%20VMWare-Tuxbox%20CDK%20Image VMWare-Image] erstellt hat, dass im Prinzip alle notwendigen Zutaten enthält. Eine weitere Alternative wäre die Verwendung von [[VirtualBox]], eine OpenSource-Alternative zu [[VMWare]]. Für die Herstellung eines solchen Images gibt es auch Forenbeiträge (siehe [[#Weblinks|Weblinks]]).

== Auschecken ==
{{Auschecken}}

Nachdem die Daten ausgecheckt wurden, könnte kann man jetzt einige Patches auf die Quellen anwenden.
Wenn man zum ersten Mal kompiliert, ist es aber ratsam, vorerst keine Veränderungen vorzunehmen. Wenn Probleme auftreten, ist es viel einfacher (technisch sowohl als auch für jeden selbst) jemand zu helfen, der die "unveränderten [[CVS|CVS]] Quellen" verwendet.

== Konfiguration ==
Nach dem Auschecken bzw. Updaten müssen nun einge Zwischenschritte erledigt werden, damit der Buildprozess auch erkennt, was und vorallem wie er es machen soll.

Man wechselt nun in das [[CDK|CDK]]-Unterverzeichnis
cd [[CDK|cdk]]
und gibt diesen Befehl ein (ohne Argumente).
./autogen.sh

Dieser erzeugt unter anderem ein [[Shellskript]] namens '''configure'''.

Wird ''autogen.sh'' ausgeführt, wird dabei eine Anzahl von Optionen übergeben, um das System für das Builden eines [[Images|Images]], [[Yadd|YADD]] oder aller anderen gewünschten Ziele entsprechend den Benutzerwünschen vorzubereiten.

=== Optionen ===

Für uns sind vorerst nur wenige Optionen interessant. Die Standardvorgaben reichen vorerst völlig aus.
{{Newmake_Build_Optionen}}
Eine typische Anwendung (Konfiguration), der mit z.B. den Pfadnamen oben kompatibel wäre, könnte so eingestellt werden:

./configure --with-cvsdir="/[[Tuxbox|tuxbox]]-[[CVS|cvs]]" --prefix="/[[Dbox2|dbox2]]" --enable-maintainer-mode

*''--with-cvsdir''
sagt wo die Quellen zu finden sind, (darin sollte auch ein Unterverzeichnis ''.../[[CDK|cdk]]'' besitzen). In der Regel ist dies das Verzeichnis in das die Quelldaten gerade ausgecheckt wurden, während
*''--prefix''
bedeutet, dass eine Anzahl von wichtigen Verzeichnissen als Unterverzeichnisse des besagten Verzeichnisses erstellt werden sollen. Ihre Position kann durch andere Konfigurationsoptionen weiter beeinflußt werden.
*''--enable-maintainer-mode''
ist, auch für Nichtmaintainers praktisch, da er den hergestellten [[Makefiles|Makefiles]] ermöglicht, sich automatisch neu zu erzeugen, sobald die Notwendigkeit entsteht, zum Beispiel nach einem [[Software|Software]]-[[Update|Update]].

Es gibt sicher noch andere nützliche Optionen. Einige werden weiter unten aufgelistet.

=== Fehlerausgaben ===
Überprüfe bitte die Ausgaben von ''autogen'' auf Fehler ("Error") und Warnungen.

Hierbei können diese Warnungen ignoriert werden:

/usr/local/share/aclocal/pkg.m4:5: warning: underquoted definition of PKG_CHECK_MODULES from autogen.sh

ebenso folgende Warnungen von configure:

...
configure: WARNING: using [[Tuxbox|tuxbox]] [[Mklibs|mklibs]]
checking for mkjffs2... no
checking for [[Mkfs.jffs2|mkfs.jffs2]]... no
configure: WARNING: using [[Tuxbox|tuxbox]] [[Mkfs.jffs2|mkfs.jffs2]]
checking for mksquashfs... no
configure: WARNING: using [[Tuxbox|tuxbox]] [[Squashfs|squashfs]]
...

Dies sind nur Hinweise darauf, dass hier projekteigene Versionen einiger [[Tools|Tools]] verwendet werden.

'''''Beachte!'''
Wenn man diesen Artikel mit älteren Beschreibungen (Oldmake) vergleicht,
bemerkt man, dass die Option '''--with-targetruleset=[standard,flash]''' nicht mehr
vorhanden ist. Bisher war es notwendig, bei der Konfiguration sich entweder auf Builds von [[YADDs]]
oder [[Images]] einzuschränken. Bei Newmake ist dieses nicht mehr notwendig.''

[[Bild:Stop hand.png]]
<div style="margin: 0; margin-top:10px; margin-right:0px; border: 3px solid #FF0000; padding: 0px 10px 1px 10px; background-color:#DEB0B0; align:right; ">
'''
Versuche niemals, als root zu bauen!'''
</div>

== Kompilieren ==
Die high-level [[Make|make]] Targets, die für das Builden von Komplett-[[Images|Images]] relevant sind, lauten:
*<pre><nowiki>flash-[neutrino, enigma, all]</nowiki></pre>
*<pre><nowiki>flash-[squashfs, jffs2, all]</nowiki></pre>
*<pre><nowiki>[1x, 2x, alle]</nowiki></pre>
Für [[Yadd|YADD]]-Builds, sind diese:
*<pre><nowiki>yadd-[neutrino, enigma, all]</nowiki></pre>
'''Beispiele:'''

[[Make|make]] [[Flash|flash]]-[[Neutrino|neutrino]]-[[Jffs2|jffs2]]-all

erzeugt flashbare [[Jffs2|jffs2]]-only [[Images|Images]] mit [[Neutrino|Neutrino]], für 1x-Boxen und für 2x-Boxen (Dateinamen ''[[Neutrino|neutrino]]-[[Jffs2|jffs2]].img1x'' und ''[[Neutrino|neutrino]]-[[Jffs2|jffs2]].img2x'').

'''der Befehl:'''

make [[Yadd|yadd]]-[[Enigma|enigma]]

erzeugt ein [[Yadd|YADD]], das [[Enigma|Enigma]] enthält.

make flash-enigma+neutrino-squashfs-all

diese Kombination erzeugt ein [[Squashfs]] [[Flash-Image]], welche [[Enigma]] und [[Neutrino]] gleichzeitig enthält.

flash-neutrino-squashfs_nolzma-all

diese Kombination erzeugt ein [[Neutrino]]-[[Squashfs]] [[Flash-Image]], ohne LZMA-Kompression.

'''Hinweis:''' ''Die configure-Optionen --enable-lzma bzw. --disable-lzma haben keine Gültigkeit mehr, stattdessen wird dies im Targetnamen angegeben''

=== Zeitaufwand ===
Das Kompilieren kann bei so einem Projekt und je nach Konfiguration und Rechnerleistung schon einige Zeit in Anspruch nehmen.
Auf einem Athlon XP 1800 dauert ein Befehl wie '''[[Make|make]] [[Yadd|yadd]]-[[Neutrino|neutrino]]''' mit leeren Verzeichnissen etwa 1 und 1,5 Stunden.

==== Verwendung von [[Ccache|ccache]] ====
Um den Vorgang insbesondere bei wiederholten Kompilieren und besonders auf langsameren Rechnern zu beschleunigen, steht die Option
* --enable-[[Ccache|ccache]]
zur Verfügung, welche man mit in die Konfiguration einbinden kann. Erfahrungsgemäß wird so durchschnittlich ca. 1-2 Drittel der Zeit eingespart.

Durch die Option '''--enable-[[Ccache|ccache]]''' wird erreicht, sollte das Tool bereits in deiner Distribution installiert sein, dass [[ccache]] automatisch erkannt wird und in das [[Tuxbox|Tuxbox]]-[[CDK|CDK]] eingebunden wird. Ist es nicht installiert, wird dies auch von configure angezeigt:
----------------------------------------
...
ccache is not yet installed, but installation starts on first build of cdk environment or you can run make ccache
----------------------------------------
...
Falls [[Ccache]] nicht auf dem Host-System installiert ist, wird es beim ersten Bauvorgang automatisch eingebunden bzw. passend zum CDK installiert. Nachtraglich kann das Tool auch mit dem Target
[[Make|make]] [[Ccache|ccache]]
in das [[CDK|CDK]] eingebaut werden. Ein Configure des CDK sollte dem möglichst vorausgegangen sein.

'''Hinweis'''
 
''Die Wirkung von [[Ccache]] macht sich logischrweise erst bemerkbar, nachdem der Buildvorgang mindestens einmal durchgelaufen ist!''

Die Option ''--enable-[[Ccache|ccache]]'' ist normalerweise völlig ausreichend. Es stehen aber noch weitere untergeordnete Sub-Optionen zur Verfügung, die in Ausnahmefällen verwendet werden können:
*--with-maxcachesize=SIZE maximal
Hier gibt man an, wieviel Speicher [[ccache]] verwenden darf in GB z.B: für 2GB
--with-maxcachesize=2

*--with-maxcachefiles=COUNT
Hier kann man angeben, wieviele Dateien [[ccache]] cachen darf.
--with-maxcachefiles=20000
Hier würden es logischeweise 20000 sein.

Die Wirksamkeit von [[ccache]] lässt sich mit dem Befehl
[[Ccache|ccache]] -s
prüfen. Als Ergebnis werden einige Statistiken ü[[BER|ber]] das Cache-Verhalten von [[Ccache|ccache]] ausgegeben:
cache directory /home/<USER>/.[[Ccache|ccache]]
cache hit 4
cache miss 191
called for [[Link|link]] 17
multiple source files 4
compile failed 17
preprocessor error 2
not a C/C++ file 5
autoconf compile/[[Link|link]] 178
no input file 15
files in cache 382
cache size 7.1 Mbytes
max cache size 976.6 Mbytes

'''Tipp'''
 
Um die benötigte Zeit genau zu ermitteln, kann man den Befehl '''time''' einbauen.
time [[Make|make]] [[Yadd|yadd]]-[[Neutrino|neutrino]]
Am Ende des Bauvorganges werden damit die entsprechenden Zeitinformationen ausgegeben.

==== Verwendung von [[Make]]-Optionen ====
Aktuell besteht auch die Möglichkeit den Bauvorgang mit der Makeoption '''-j''' zu beschleunigen. Hierbei können von [[Make]] gleichzeitig mehrere '''J'''obs erledigt werden, sofern diese keine Abhängigkeiten untereinander haben. Die Wirkungen sind durchaus auch von der verwendeten Hardware abhängig. Ein Rechner mit Mehrkern-Prozessor hat hier sicher die besseren Karten. Die Übergabe dieser Option erfolgt in dieser Form:

make J=[n] [target]

'''n''' ist die Anzahl der Jobs, '''Target''' das jeweilige Ziel.

=== Beispiele ===
Hier einige Beispiele mit denen man [[Images|Images]], Yadds oder einzelne Targets bauen kann. Diese Beispiele sollten so wie sie hier vorgegeben sind ohne Veränderung auf jedem [[Linux|Linux]]-System mit den bisher beschriebenen Voraussetzungen laufen. Da die Systeme trotzdem [[Unterschiede|Unterschiede]] aufweisen können, kann man das aber nicht garantieren.

==== [[Neutrino|neutrino]]-[[Jffs2|jffs2]]-[[Image|Image]] ====
#! /bin/bash
# beispiel.sh
# Diese Script baut [[Neutrino|neutrino]]-[[Jffs2|jffs2]] [[Images|Images]], jeweils 1x und 2x
#----------------------------------------------
USERDIR=/home/$(whoami)
#----------------------------------------------
LOGODIR=$USERDIR/Logos
CP=$USERDIR/[[Tuxbox|tuxbox]]-[[CVS|cvs]]
DB=$USERDIR/[[Dbox2|dbox2]]
ARCHIVEDIR=$USERDIR/Archive
export CVS_RSH=[[SSH|ssh]]
#-----------------------------------------------
cd "$CP"
[[CVS|cvs]] -d anoncvs@[[CVS|cvs]].[[Tuxbox|tuxbox]].org:/[[CVS|cvs]]/[[Tuxbox|tuxbox]] -z3 co -P .
cd [[CDK|cdk]]
/bin/ln -sf $ARCHIVEDIR/ Archive
./autogen.sh
./configure --prefix="$DB" --with-cvsdir="$CP" --enable-flashrules --enable-[[Ccache|ccache]] --with-[[CheckImage|checkImage]]=rename --with-logosdir="$LOGODIR"
[[Make|make]] [[Flash|flash]]-[[Neutrino|neutrino]]-[[Jffs2|jffs2]]-all

==== Neutrigma-[[squashfs]]-[[Image|Image]] ====
#! /bin/bash
# beispiel.sh
# Diese Script baut ein kombiniertes Enigma, Neutrino (Neutrigma)-Squashfs-Image, jeweils 1x und 2x
#----------------------------------------------
USERDIR=/home/$(whoami)
#----------------------------------------------
LOGODIR=$USERDIR/Logos
CP=$USERDIR/[[Tuxbox|tuxbox]]-[[CVS|cvs]]
DB=$USERDIR/[[Dbox2|dbox2]]
ARCHIVEDIR=$USERDIR/Archive
export CVS_RSH=[[SSH|ssh]]
#-----------------------------------------------
cd "$CP"
[[CVS|cvs]] -d anoncvs@[[CVS|cvs]].[[Tuxbox|tuxbox]].org:/[[CVS|cvs]]/[[Tuxbox|tuxbox]] -z3 co -P .
cd [[CDK|cdk]]
/bin/ln -sf $ARCHIVEDIR/ Archive
./autogen.sh
./configure --prefix="$DB" --with-cvsdir="$CP" --enable-flashrules --enable-[[Ccache|ccache]] --with-[[CheckImage|checkImage]]=rename --with-logosdir="$LOGODIR"
[[Make|make]] flash-enigma+neutrino-squashfs-all

==== [[Neutrino|Neutrino]] [[Yadd|YADD]] ====
#! /bin/bash
# beispiel.sh
# Diese Script baut ein [[Neutrino|Neutrino]] [[Yadd|Yadd]]
#----------------------------------------------
USERDIR=/home/$(whoami)
#----------------------------------------------
LOGODIR=/Logos
CP=$USERDIR/[[Tuxbox|tuxbox]]-[[CVS|cvs]]
DB=$USERDIR/[[Dbox2|dbox2]]
ARCHIVEDIR=$USERDIR/Archive
export CVS_RSH=[[SSH|ssh]]
#-----------------------------------------------
cd "$CP"
[[CVS|cvs]] -d anoncvs@[[CVS|cvs]].[[Tuxbox|tuxbox]].org:/[[CVS|cvs]]/[[Tuxbox|tuxbox]] -z3 co -P .
cd [[CDK|cdk]]
/bin/ln -sf $ARCHIVEDIR/ Archive
./autogen.sh
./configure --prefix="$DB" --with-cvsdir="$CP" --with-logosdir="$LOGODIR" --enable-[[Ccache|ccache]]
[[Make|make]] [[Yadd|yadd]]-[[Neutrino|neutrino]]

= Kernel 2.6.x =

{{Bulid_kernel_26}}

= Was kommt dann...? =
== Booten von [[Yadd|YADD]] ==
Wenn ein [[Yadd|YADD]] frisch erzeugt wurde, kann damit auch die Box booten. Näheres dazu auch im Artikel [[CDK booten]]. 
Newmake hält auch ein [[Make|Make]]-Target für den serversupport bereit.
[[Make|make]] serversupport
Dieses erzeugt einige Konfigurationsdateien für den [[Server|Server]] der das [[Yadd|YADD]]-Build nahtlos an das [[Server|Server]]-Setup anknüpft.

== [[Flashen|Flashen]] des [[Images|Images]] ==
Wenn ein [[Image|Image]] gebaut wurde, ist der logische nächste Schritt das Einspielen des [[Images|Images]] in den [[Flash|Flash]] der Box. Hierfür ist entweder, das interaktive [[Flashen|Flashen]] innerhalb der [[GUI|GUI]] mit den [[Installation:Neutrino|Expertenfunktionen]] zu benutzen, oder der ''dboxflasher'' zu verwenden. Der ''dboxflasher'' wird durch das [[Make|Make]]-Target
[[Make|make]] serversupport
erzeugt. 
Siehe auch [[Installation]].

== Inkrementelle Builds ==
Im allgemeinen ist man nicht an einem einmaligen Build der [[Software|Software]] interessiert. Verbesserungen an den Quellen werden in das [[CVS|CVS]] täglich eingecheckt. Oft möchte man die [[Software|Software]] durch eigene Programmierung verbessern oder Patches anwenden. Es ist dabei wünschenswert, dass genau nur die Teile neu erzeugt wird, die neu erzeugt werden sollen, nicht mehr und nicht weniger. Newmake geht einen direkten Weg in diese Richtung.
 
Um ein Target neu zu bauen, benutze den Befehl
[[Make|make]] [target]
und [[Make|make]] wird es, falls notwendig, neu erzeugen.

Es kann auch passieren, dass [[Make|make]] zusätzlich einen vollständig anderen Bestandteil neu erzeugt! Dies ist dann der Fall, wenn das jeweilige Target von anderen Teilen abhängt, die sich geändert haben.
 
In einige Situationen kann es auch wünschenswert sein, ein erneutes Bauen einer Komponente zu erzwingen. Einige Komponenten werden in einem Distributionsfile zum Verzeichnis [[CDK|cdk]]/Archive heruntergeladen, und wenn das Build stattfindet, ausgepackt, evtl. Patches angewendet, konfiguriert, kompiliert, installiert und die Quellen dann wieder gelöscht. 
Alles findet automatisch statt. Die [[Installation|Installation]] eines bestimmten Pakets wird durch das Anlegen einer Markerdatei im Verzeichnis ''[[CDK|cdk]]/.deps'' vermerkt.
 
Falls gewünscht, kann solch eine Markiererdatei entfernt werden, um das Neuerzeugen der entsprechenden Komponetne zu erzwingen. Es gibt hierfür auch entsprechende Targets, die "''Cleaning Targets''".

== Cleaning targets ==
Es gibt mehrere unterschiedliche Aufräum-Targets:
 
[[Make|make]] distclean
Das drastischste Reinigungs-Target, (fast) alles löschend, was nicht vom [[CVS|CVS]] ausgecheckt wurde.
Dieses ist eher selten notwendig.
 
[[Make|make]] mostlyclean
Ein intelligenteres Target ist ''mostlyclean''. Es säubert die Verzeichnisse, die Tuxboxquellen enthalten, lässt aber die Kompilationsumgebung und alle ''Auspacken-kompilieren-installieren-löschen-Komponente'' unberührt.
 
Auch das cdkroot Verzeichnis, (d.h. die [[Yadd|Yadd]]-[[Installation|Installation]]), sowie die [[Tftp|TFTP]]-Files ([[Kernel|Kernel]] und [[U-boot|u-boot]]) werden nicht angefasst.
 
[[Make|make]] depsclean
Löscht alle Markerdateien im /[[CDK|cdk]]/.deps Verzeichnis und zwingt so zum Neukompliieren aller [[Auspacken-kompilieren-installieren-löschen-Komponenten]].
 
Dies ist selten sinnvoll: Diese hängen von ihren Quellen und vielleicht von einem Patchfile ab, und der Makefile kennt diese Abhängigkeiten.
 
[[Make|make]] clean
Kombiniert ''mostlyclean'', ''depsclean'', und ''[[Flash|flash]]-clean''. Versucht auch soviel wie möglich im cdkroot-Verzeichnis zu löschen, das nicht während des Bootstrapdurchlaufes installiert war. So wird
versucht, die Umgebung in einem Zustand zu bringen, wo die Buildumgebung gerade kompiliert worden ist, z.B. mit ''[[Make|make]] bootstrap''.
 
[[Make|make]] [[Flash|flash]]-semiclean
Dieses Target löscht die meisten Verzeichnisse in $(flashprefix), mit Ausnahme der Boot-Partitionen und der Kernelbauverzeichnisse. 
Dieses ist oft sinnvoll, da diese Bestandteile verhältnismässig sich selten ändern.
 
[[Make|make]] [[Flash|flash]]-mostlyclean
Zusätzlich zum ''[[Flash|flash]]-semiclean'' löscht dieses Target auch Bootfiles und die Kernbauverzeichnisse. Vollimages werden unberührt gelassen.
 
[[Make|make]] [[Flash|flash]]-clean
Dieses Target löscht Alles in $(flashprefix).
 
Einige Quellverzeichnisse können mit einem Befehl wie
[[Make|make]] -C /[[Tuxbox|tuxbox]]-[[CVS|cvs]]/apps/[[Tuxbox|tuxbox]]/[[Neutrino|neutrino]] clean
gesäubert werden.

== Aktualisierung des [[CVS|CVS]]-Quellcodes ==
Um die Quellen mit neueren Checkins zu aktualisieren, verwende diesen Befehl für das toplevel [[CVS|CVS]] Verzeichnis (oder von einem anderen Verzeichnis, wenn Ihr wisst, was ihr tut;-). Mögliche Fehler werden in das logfile [[CVS|cvs]].log geschrieben.

cvs up -r HEAD > cvs.log 2>&1

'''Tipp'''
 
Um mit dem [[CVS|CVS]] arbeiten zu können nimmt man für gewöhnlich die Konsole für Eingaben. Es gibt aber auch verschiedene Frontendwerkzeuge wie z.B. [http://www.crossvc.com CrossVC] oder [http://cervisia.kde.org/ Cervisia] um nur einige zu nennen, die einen recht komfortablen Umgang mit den [[CVS|CVS]]-Daten ermöglichen. [[Bild:Crossvc.jpg|CrossVC als CVS Frontendlösung]] [[Bild:Cervisia.jpg|Cervisia als CVS Frontendlösung]] 
Auch einige [[IDE|IDE]]'s wie z.B. [[WP:Anjuta|Anjuta]] [[Bild:anjuta.jpg|Anjuta als IDE mit CVS-Anbindung]] bieten solche [[CVS|CVS]]-Schnittstellen an.

== [[Customization|Customization]] ==
Ein "Schreckgespenst" für viele "[[Oldmake]]rs" ist anscheinend die so genannte [[Customization|Customization]]. Dies kann man immer wieder aus diversen Meinungen und Forumsbeiträgen diverser "Oldmaker" herauslesen. Ein Grund dafür dürfte wohl die scheinbare "gefühlte" Unmenge an Scripten sein, die damit in Verbindung gebracht wird.
Grundsätzlich ist es aber so, dass man zuerst einmal ein [[Image]] und/oder [[Yadd]] bauen sollte, ganz ohne Zusätze, um zumindest erst einmal zu sehen, was dabei herauskommt. Dies sind, also nichts weiter als beispielsweise völlig normale Images. Die flasht man sich auf die Box und kann man zweckentsprechend verwenden. Mehr erstmal nicht. Dies dürfte auch völlig ausreichend sein, aber wir sind ja Bastler und wollen ja mehr...und daraus ergibt sich der Bedarf an der Nutzung dieser [[Customization|Customization]].

Will man z.B. ein Image für den Hausgebrauch bauen, mit dem man nach dem flashen sofort fernsehen will, kann man sich z.B. alle benötigten Firmawaredateien (Ucodes), Senderlisten usw. an Ort und Stelle im Image platzieren lassen, ohne dass es Änderungen an irgendeinem Makefile bedarf. Das gleiche gilt auch, wenn man bespielsweise ein [[IDE-Interface]] betreiben möchte. Da das Tuxbox-Projekt hierfür enstprechende Möglichkeiten bereit hält, gibt es dafür auch entsprechende fertige Konfigurations-Optionen, die die entsprechende Funktionalität herstellen.

=== Konfigurationsoptionen ===
Hier sollen zunächst einige verschiedene Möglichkeiten für die Konfigurations-Optionen vorgestellt werden.
Eine Komplettübersicht aller Optionen lässt sich mit
./configure --help
abrufen

====--with-ucodesdir=[DIR]====
Hiermit kann ein Verzeichniss angegeben werden, welches die [[Ucodes|Ucodes (Firmaredateien]] enthält, die im [[Image|Image]] enthalten sein sollen.
'''Hinweis:''' 
Ein [[Image|Image]], dass [[Ucodes|ucodes]] enthält, darf
nicht verbreitet werden! 

====--with-logosdir=[DIR]====
Legt ein Verzeichniss fest, das boot-logos (logo-[[LCD|lcd]] und logo-fb) enthält, die im [[Image|Image]] enthalten sein sollen.

====--with-defaultlocale=[LOCALE]====
sorgt dafür, dass die gewünschte Sprache schon beim bauen eingestellt wird.

====--with-rootpartitionsize=[SIZE]====
Legt die Rootpartitionsgröße für [[Squashfs|squashfs]] [[Images|Images]] fest.

Die Größe der var-[[Partition|Partition]] wird automatisch berechnet, wobei man den restlichen Flashspeicher nutzt, der nicht durch die anderen Partitionen benutzt wird. Die Standardgröße ist 0x660000.
Diese Zahl sollte eine Multiple der Erasesize, momentan 0x20000 sein. Dies wird allerdings ignoriert falls es wie bei der [[Jffs2|jffs2]]-Imageerstellung unsinnig wäre.

====--with-updatehttpprefix=[URL]====
Nützlich für das Verteilen von Onlineupdates oder auch nur um im eigenen Heimnetzwerk mit Hilfe eines Servers seine Boxen up-to-date zu halten, ist die Angabe einer Updateadresse (Update-URL).

Die Adresse wird in dieser Form angegeben:
--with-updatehttpprefix=<nowiki>http://www.deine-updateseite.de</nowiki>

Diese Adresse erscheint beispielsweise in der Versionsdatei ''(.version)'', in den [[Neutrino:Service:Image_Informationen|Image-Informationen]] von [[Neutrino]] und sorgt dafür, dass Online-Updates über das [[Netzwerk]] abgerufen werden können (siehe: [[Neutrino:Service:Software-Aktualisierung]]).
Serverseitig muss natürlich auch eine entsprechende Informationsquelle für die entsprechenden Updates vorhandene sein. Dies übernehmen die sogenannten ''*.list''-Files, dessen Adresse in die Datei
/etc/update.urls (siehe [[Neutrino:Service:Software-Aktualisierung#Experten-Funktionen|Experten-Funktionen]])
eingetragen werden muss.
Je nachdem was für ein Update abgerufen werden soll, werden dafür verschiedene ''*.list''-Files benötigt.
*img.list für Komplettimages
*squashfs.list für Root-squashfs Updates
Diese ''*.list''-Files enthalten alle Informationen die für das Online-Update benötigt werden. Das Format sollte so aussehen:
[URL zum Update-file] [md5-Prüfsumme] [Image-Versions-String] [Name für das Image]
Beispiel:
<nowiki>http://www.deine-homepage.de/downloads/Image-v2.0_neutrino_squashfs_1200200808281200_1x.img 06c30a36329d990194f249d3a3648aec 1200200808281200 Image-v2.0_1x</nowiki>

Die Einträge in die ''*.list''-Files und ''update.urls'' lassen sich mit Hilfe von [[Newmake#Customization-Scripte|Customization-Scripte]]n erzeugen und anschließend ins Image einfügen (siehe auch: [[Newmake#.2F.version_anpassen|.version_anpassen]]). Die ''*.list''-Files können mit diversen Werkzeugen (z.B. ''ncftpput'') auf einen Server geladen werden.
Zu beachten wäre noch, das beim Update selbst zur Neutrino-Laufzeit eine Prüfung des Release-Zyklus erfolgt. Bei Neutrino ist derzeit 2.0 aktuell und sollte eingehalten werden. Ändern kann man dies in ''[[update.cpp]]'', zu finden im [[Neutrino]] CVS-Quellcode unter
./apps/tuxbox/neutrino/src/gui/[[update.cpp]]

====--with-targetprefix=DIR====
* standard: ''PREFIX/cdkroot''
Gibt an, wohin alle Targets gebaut werden sollen. Ein Target mit Namen ''make busybox'' baut also standardmäßig [[busybox]] genau dorthin.
*''PREFIX/cdkroot/bin''

====--with-flashprefix=DIR====
* standard: ''PREFIX/cdkflash''.
Gibt an, wohin alle Flash-Targets gebaut werden sollen. Also ein Target mit Namen ''make flash-busybox'' baut also standardmäßig [[busybox]] genau dorthin:
*''PREFIX/cdkflash/root/bin''
Da beispielsweise das Flash-Target make ''flash-neutrino-squashfs'' gewisse Abhängigkeiten hat, die auch [[busybox]] betreffen, wird [[busybox]] auch hier hin gbaut.
*''PREFIX/cdkflash/root-neutrino-squashfs/bin''

====--with-hostprefix=DIR====
* standard: *''PREFIX/cdk''
Gibt an wohin die Binaries für das [[Tuxbox-CDK]] optional gebaut werden

====--with-bootprefix=DIR====
*standard: *''PREFIX/tftpboot''
Gibt optional an wohin die Bootfiles ([[Kernel]], [[U-boot]]) für das [[CDK]] bzw. [[Yadd]] gebaut werden

====--with-serversupport=DIR====
* standard: *''PREFIX/serversupport''
Hier werden die Vorlagen der Konfigurationsdateien optional abgelegt, die für die Einrichtung eines bootfähigen [[CDK]] erstellt werden.

====--with-customizationsdir=DIR====
* standard: *''cvsdir/cdk''
Hier werden optional die Customization-Scripte abgelegt, um vom Makeprozess dort abgerufen werden zu können.

====--with-checkImage=[none,rename,warn]====
Gibt an, wie die Prüfung von Imaages erfolgen soll
*''none''=nichts
*''rename''=umbenennen (Image erhält die Endung -bad)
*''warn''=selbstredend

====--with-cvsdir=DIR====
Gibt an, wo sich optional das CVS-Verzeichnis befindet

====--with-appsdir=DIR====
* standard: ./cvsdir/apps
Gibt an, wo sich optional das apps-Quellcodeverzeichnis befindet.
Nützlich um auch andere Repositories als die aus dem Tuxbox-CVS einzubinden. Eine Möglichkeit wäre es z.B. ein geklontes git-Repository einzubinden, die derzeit von einigen Tuxboxentwicklern parallel betreut werden.
siehe: http://gitorious.org/projects/tuxbox-apps

====--with-bootdir=DIR====
* standard: ./cvsdir/boot
Gibt an wo sich optional das boot-Quellcodeverzeichnis befindet

====--with-driverdir=DIR====
* standard: ./cvsdir/driver
Gibt an wo sich optional das driver-Quellcodeverzeichnis befindet

====--with-hostappsdir=DIR====
* standard: ./cvsdir/hostapps
Gibt an wo sich optional das hostapps-Quellcodeverzeichnis befindet

====--with-gnuserver=ADDRESS====
Optionale Serveradresse für GNU-Sourcen (ohne ftp://)

====--with-defaultserver=ADDRESS====
Serveradresse die genommen wird falls ein Server nicht verfügbar ist (ohne http://)

====--with-busybox-conf=M4-File====
* standard: ./cvsdir/cdk/Patches/busybox.config.m4
Hier kann optional eine eigene M4-Macro-Konfigurationsdatei angegeben werden

====--with-yadd-kernel-conf=FILE --with-flash-kernel-conf=FILE====
* standard: ./cvsdir/cdk/Patches
Hier kann optional eine Konfigurationsdatei jeweils für Flash oder Yadd angegeben werden

====--with-filesystems=comma seperated list of filesystems====
Hier können durch Komma getrennte Filesysteme angegeben werden. (siehe --enable-xfs, --disable-ext3)
--with-filesystems=extfs,xfs,nfs,cifs,vfat,smbfs,lufs
''extfs'' stellt ein Alias für ''ext2'' und ''ext3'' dar, kann aber auch einzeln verwendet werden.
Der erste Eintrag wird als Standard verwendet und in der ''/etc/[[fstab]]'' verwendet

====--with-filesystem-tools= comma seperated list of filesystem tools to be used====
Hier können durch Komma getrennte Dateisystemtools angegeben werden. 
Zugelassene Werte: e2fsprogs, reiserfsprogs, dosfstools, xfsprogs, fdisk (standalone) 
Als Standard sind die passenden Tools aktiviert, die zu den aktivierten Dateisystemen gehören: 
ext2/ext3: e2fsprogs 
xfs: xfsprogs 
reiserfs: reiserfsprogs 
vfat: dosfstools 
Diese Option ist dazu gedacht, nicht benötigte Tools nicht zu kompilieren. 
Wer in einem ext2/vfat-Image nur e2fsprogs haben möchte, nutzt also --with-filesystem-tools=e2fsprogs 
Wer keine Dateisystemtools im Image haben möchte, nutzt also --with-filesystem-tools="" 
Dateisystemtools deaktivierter Dateisysteme sind nicht aktivierbar. 
Der Parameter "fdisk" deaktiviert das fdisk-applet von busybox und installiert stattdessen fdisk aus dem utillinux-Paket. Diese Option ist standardmäßig aktiviert, wenn --enable-drive-gui genutzt wird. 

====--enable-uclibc====
Aktviert Makerules für uClibc verlinkte Targets (derzeit noch experimentell) '''Erfahrungswerte erwünscht'''!

====--enable-maintainer-mode====
Ermöglicht den hergestellten [[Makefiles|Makefiles]], sich automatisch neu zu erzeugen, sobald die Notwendigkeit entsteht, zum Beispiel nach einem [[Software|Software]]-[[Update|Update]].

====--enable-kernel26====
Es wird statt des üblichen 2.4.xer Kernel ein 2.6.xer Kernel gebaut (derzeit noch experimentell) '''Erfahrungswerte erwünscht'''!
'''Hinweis:''' ''Hierfür ist es notwendig die entsprechenden Treiber im Kernel2.6er CVS-Branch auszuchecken!'' Siehe auch: [[Images_und_Yadd%27s_mit_Kernel_2.6|Images_und_Yadd's_mit_Kernel_2.6]]

====--enable-flashrules====
Targets für das bauen von [[Flash]]-[[Images]] werden aktiviert.

====--enable-lirc====
Erzeugt Images/Yadds mit [[Lirc]]-Support

====--enable-cdkVcInfo====
Das Tool [[cdkVcInfo]] wird automatisch mitgebaut. Diese Tool ist wie einige Andere auch ein Zusatz.

====--enable-german-keymaps====
Tastatursupport

====--enable-ide====
Ermöglicht das Bauen von Images/Yadds mit support für [[IDE-Interface]]s. Es werden hierfür die passenden Treiber und Kernel-Module gebaut.

====--enable-mmc====
Ermöglicht das Bauen von Images/Yadds mit support für [[MMC]]s. Es werden hierfür die passenden Treiber und Kernel-Module gebaut.

====--enable-sqlite====
Aktiviert SQL-Lite Support

====--disable-ext3====
Deaktiviert Treiber für ext2/ext3 Dateisysteme (siehe --with-filesystems=)
Diese Option ist weiterhin gültig, kann aber weggelassen werden, wenn --with-filesystems aktiviert ist und wird nicht berücksichtigt, wenn --with-filesystems angegeben ist.

====--enable-xfs====
Aktiviert Treiber für XFS und baut xfsprogs (siehe --with-filesystems="xfs")
Diese Option ist weiterhin gültig, kann aber weggelassen werden, wenn --with-filesystems aktiviert ist und wird nicht berücksichtigt, wenn --with-filesystems angegeben ist.

====--enable-nfsserver====
Ermöglicht das Bauen eines NFS-Servers

====--enable-sambaserver====
Ermöglicht das Bauen eines Samba-Servers

====--enable-dosfstools====
Es werden dos Filesystem Werkzeuge gebaut

====--enable-upnp====
Es wird Unterstützung fur upnp eingebaut, ermöglicht die Box als upnp-Client zu benutzen

====--enable-flac====
Support für flac-Files im Audioplayer

====--enable-ccache====
Aktiviert [[Kompiler]]-Unterstützung durch [[ccache]]

====--enable-movieplayer2====
Aktiviert den MP2 für Neutrino (derzeit noch experimentell) '''Erfahrungswerte erwünscht'''!

=== Variablen ===
==== Pfade ====
Es sind noch weitere Benutzeranpassungen möglich. Dafür ist es aber notwendig, etwas [[Wissen|Wissen]] ü[[BER|ber]] die innere Funktionsweise der [[Makefiles|Makefiles]] zu haben.

In der Folge bezeichnet
$(flashprefix)
den Wert der Makefile Variablen '''flashprefix''' (mit Konfiguration wie oben '''/[[Dbox2|dbox2]]/cdkflash''')
$(targetprefix)
bezeichnet den Wert der Makefile Variablen '''targetprefix''' (mit Konfiguration wie oben '''/[[Dbox2|dbox2]]/cdkroot'''), und
$(buildprefix)
bezeichnet den Wert der Makefile Variablen '''buildprefix''' (mit der Konfiguration oben '''/[[Tuxbox|tuxbox]]-[[CVS|cvs]]/[[CDK|cdk]]''').

Um z.B. ein '''[[Neutrino|neutrino]]-[[Squashfs|squashfs]].img2x''' zu erzeugen, werden die folgenden Verzeichnisse erstellt: 
*'''$(flashprefix)/root''' (enthält [[Filesystem|Filesystem]]- und [[GUI|GUI]]-unabhängige Bestandteile)
*'''$(flashprefix)/root-[[Squashfs|squashfs]]''' (enthält den [[Kernel|Kernel]], für Root-[[Filesystem|Filesystem]] auf [[Squashfs|squashfs]] konfiguriert, zusammen mit seinen Treibern) und
*'''$(flashprefix)/root-[[Neutrino|neutrino]]''' (enthält die Neutrinoinstallation).

Aus diesen drei Verzeichnissen, werden das Rootfilesystemverzeichniss
*'''$(flashprefix)/root-[[Neutrino|neutrino]]-[[Squashfs|squashfs]]''' und das
var-filesystemverzeichnis
*'''$(flashprefix)/var-[[Neutrino|neutrino]]''' gebaut.

Hiermit ist es möglich, einen Befehl wie
[[Make|make]] $(flashprefix)/root-[[Neutrino|neutrino]]-[[Jffs2|jffs2]]
bzw. wenn man sich im Verzeichnis ''./[[Tuxbox|tuxbox]]-[[CVS|cvs]]/[[CDK|cdk]]'' befindet, den Befehl
[[Make|make]] root-[[Neutrino|neutrino]]-[[Jffs2|jffs2]]
einzugeben, wobei man bei erster VAriante natürlich '''$(flashprefix)''' selbst durch den realen Pfad ersetzen muss, da '''$(flashprefix)''' nur eine [[Make|make]]-Variable ist, welche in unserem Beispiel den Pfad zu '''./[[Dbox2|dbox2]]/cdkflash''' darstellt. 
Man kann so manuell gewünschten Änderungen an '''$(flashprefix)/root-[[Neutrino|neutrino]]-[[Jffs2|jffs2]]''' vornehmen, und dann, mit dem Befehl
[[Make|make]] [[Flash|flash]]-[[Neutrino|neutrino]]-[[Jffs2|jffs2]]-2x
den Imagebau abschließen, um ein [[Image|Image]] zu erstellen, das diese manuellen Änderungen enthält.

Dieses kann zwar für den einmaligen Imagebau sinnvoll sein, jedoch in vielen Fällen dürfte eine automatisierte und systematischere Methode erforderlich sein.

=== [[Customization|Customization]]-Scripte ===
Sofern diese Scripte vorhanden und ausführbar sind, werden innerhalb der wichtigsten Targets diese sogenannten ''[[Customization|Customization]]-Scripte'' automatisch aufgerufen bzw. ausgeführt.
Zum aktivieren der Scripte müssen diese lediglich in ein dafür vorgesehenes Verzeichnis abgelegt werden und ausführbar sein. Dieses Verzeichnis ist standardmäßig der '''*/[[CDK|cdk]]'''-Ordner.
Bei Bedarf kann mit der Option
--with-customizationsdir=[DIR]
ein alternatives Verzeichnis für [[Customization|Customization]]-Scripte festgelegt werden.

Auf diese Scripte werden zwei Argumente zur Laufzeit übergeben:

Für Imagetargets sind dies
*$(flashprefix)
und
*$(buildprefix)
für Yaddtargets sind diese
*$(targetprefix)
und
*$(buildprefix)

Die Bezeichnung "Script" ist etwas irreführend, da sie eigentlich wie normale Programme mit zwei Argumenten ausgeführt werden. Anstelle eines [[Shell|Shell]]-Scripts könnte dies z.B. ein kompiliertes C Programme, oder ein [[Perl|Perl]]-Script sein. 
Der Name eines [[Customization|Customization]] Scriptes besteht in der Regel aus dem Namen eines Targetverzeichnisses bzw. einem Target und dem angefügtem *'''-local.sh'''.

==== Für [[Flash|Flash]]-Targets ====
Der Name der [[Customization|Customization]] Scripte für [[Images|Images]] besteht aus den wie oben benannten Verzeichnissen (in diesem Fall Targets) in ''flashprefix'',
*root

dem Namen der jeweilige Benutzeroberfläche, als "[[GUI]]" in Klammern bezeichnet, also
*[[Neutrino|neutrino]]
*[[Enigma|enigma]]
*[[Lcars|lcars]]
*[[Radiobox|radiobox]]

"[[FS]]" zeigt an welches [[Filesystem|Filesystem]] gemeint ist.
*[[Squashfs|squashfs]]
*[[Jffs2|jffs2]]

so wäre die Bezeichnung der jeweiligen Scripte wie folgt aufgebaut:
*root-local.sh
*root-[GUI]-local.sh
*root-[GUI]-[FS]-local.sh
*root-[FS]-local.sh
*var-[GUI]-local.sh

'''Beispiele:'''
root-local.sh
root-[[Neutrino|neutrino]]-local.sh
root-[[Neutrino|neutrino]]-[[Squashfs|squashfs]]-local.sh
root-[[Squashfs|squashfs]]-local.sh
var-[[Neutrino|neutrino]]-local.sh

==== Für [[Yadd|Yadd]]-Targets ====
Für Yadds ist das Prinzip ähnlich, nur dass es hier quasi nur einen Ordner gibt. Dafür stellvertretend steht dann
*[[Yadd|yadd]].

Das "[[GUI]]" in Klammern bezeichnet auch hier die jeweilig betroffene Benutzeroberflche, also
*[[Neutrino|neutrino]]
*[[Enigma|enigma]]
*[[Lcars|lcars]]
*[[Radiobox|radiobox]]

so wäre die Bezeichnung der jeweiligen Scripte so aufgebaut.
*[[Yadd|yadd]]-[GUI]-local.sh
'''Beispiel:'''
[[Yadd|yadd]]-[[Neutrino|neutrino]]-local.sh

==== für andere Targets ====
Die bisher benannten [[Customization|Customization]] Scripte für [[Flash|Flash]]- u. [[Yadd|Yadd]]-Targets sind die Gebräuchlichsten. Diese werden allerdings gewissermaßen nur an die der bestehenden Targets angehängt, anders als es bei den anderen, von denen es in Newmake noch jede Menge mehr gibt, bei denen diese als Ersatz der eigentlichen Targets dienen. 
Im Prinzip ginge dies auf so gut wie alle Targets anzuwenden. Möchte man z.B. ein Contrib-Tool "customizen", etwa [[hdparm]], kann man ein Script erstellen:
*hdparm-local.sh
Führt man dann das Target:
[[Make|make]] hdparm
aus, wird beim Bauen das ausgeführt was im [[Customization|Customization]]-Script angelgt wurde. Die Aktionen im Original-Makefile werden übersprungen.

===== Beispiel: version-local.sh =====
Diese Funktion ist recht interessant und dürfte recht oft Anwendung finden (siehe auch [[Newmake#.2F.version_anpassen|Anpassung .version-File]]): 
Während des [[Make|make]]-Durchlaufs werden einige Targets ausgeführt, welche die '''/.version'''-Files bei [[YADD]]
*'''version'''
bzw.
*'''[[Flash|flash]]-version'''
im [[Image]] erstellt.
 
Sofern eines dieser Scripte;
*'''version-local.sh'''
*'''[[Flash|flash]]-version-local.sh'''
vorhanden und ausführbar ist, wird es als Ersatz statt des originalen Targets ausgeführt, welches mit
[[Make|make]] version
bzw.
[[Make|make]] [[Flash|flash]]-version
angestoßen wird.

==== Beispiele für Customization ====
Das Customizationscripting soll hier durch einige Beispiele noch mehr veranschaulicht werden.

'''Warnung'''
''Auch falls die Beispiele in einigen Fällen benutzbar sind, werden die Scripte als Beispiele, nicht als Lösungen zu den realen Problemen gezeigt. Aus diesem Grund sind die Beispiele hier als Codefragmente, nicht als downloadbare Dateien, veröffentlicht. Bitte nicht verwenden, es sei denn es ist ungefährlich und Ihr versteht, wie sie funktionieren. Es ist grundlegende Script-Erfahrung erfordelich.''

===== Lirc Komponenten einbauen =====
In einem [[Jffs2|jffs2]]-[[Image|Image]] wird dies gewünscht:

1. Eigene /etc/hosts benutzen,
2. Eigene [[Neutrino|neutrino]].conf, [[Bouquets|bouquets]].[[XML|xml]], services.[[XML|xml]] benutzen
3. einschließlich [[Lirc|lirc]]-Komponenten, zusammen mit eigenen [[Lirc|lirc]] Konfigurations-Dateien.

1. und 3. sind [[Erweiterungen|Erweiterungen]], die nach '''$(flashprefix)/root''' kommen sollten, während 2. [[Neutrino|Neutrino]]-regeln sind, welche nach sollten '''$(flashprefix)/root-[[Neutrino|neutrino]]-[[Jffs2|jffs2]]''' gehöhren. 
Um 1. und 3. zu erreichen, wird das Script '''root-local.sh''' erstellt, z.B.:

#!/bin/sh
# root-local.sh
flashprefix=$1
buildprefix=$2
newroot=$flashprefix/root
myfiles=/home/somewhere/dbox/myfiles
cp -f $myfiles/etc/hosts $newroot/etc
[[Make|make]] flashlirc
cp -fr $myfiles/var/[[Tuxbox|tuxbox]]/config/[[Lirc|lirc]] $newroot/var/[[Tuxbox|tuxbox]]/config

Das Script für 2. heist '''root-[[Neutrino|neutrino]]-local.sh''', was dem verherigen sehr ähnlich ist:

#!/bin/sh
# root-[[Neutrino|neutrino]]-local.sh
flashprefix=$1
buildprefix=$2
newroot=$flashprefix/root-[[Neutrino|neutrino]]
myfiles=/home/somewhere/dbox/myfiles
cp $myfiles/var/[[Tuxbox|tuxbox]]/config/[[Neutrino|neutrino]].conf $newroot/var/[[Tuxbox|tuxbox]]/config
cp $myfiles/var/[[Tuxbox|tuxbox]]/config/[[Zapit|zapit]]/[[Bouquets|bouquets]].[[XML|xml]] $newroot/var/[[Tuxbox|tuxbox]]/config/[[Zapit|zapit]]
cp $myfiles/var/[[Tuxbox|tuxbox]]/config/[[Zapit|zapit]]/services.[[XML|xml]] $newroot/var/[[Tuxbox|tuxbox]]/config/[[Zapit|zapit]]

===== procps-Varianten von ps und top einbauen =====
Im Image werden die procps-Varianten von [[WP:Ps_%28Unix%29|ps]] und [[WP:Unix-Kommando#Prozessmanagement|top]] anstelle der [[WP:busybox|Busybox]]-Version gewünscht.

In root-local.sh

make procps

hinzufügen.

In root-neutrino-local.sh

for i in top ps; do
cp -va $flashprefix/../cdkroot/bin/$i $flashprefix/root-neutrino/bin/
rm -v $flashprefix/root/bin/$i
done

===== Games und Languages nuker =====
Dieses Script löscht alle [[Spiele|Spiele]] (definiert als [[Plugins|plugins]] mit type=1 in ihrer Konfigurationsdatei), sowie unerwünschte Sprachfiles ([[Neutrino|Neutrino]] angenommen). Das File sollte von '''root-[[Neutrino|neutrino]]-$[[Filesystem|filesystem]]-local.sh''' aufgerufen werden.

#!/bin/sh
# Nukes all game [[Plugins|plugins]], as well as all [[Locale|locale]] files not listed in LANGUAGES
newroot=$1/root-[[Neutrino|neutrino]]-[[Jffs2|jffs2]]
LANGUAGES="deutsch english"
for f in $newroot/lib/[[Tuxbox|tuxbox]]/[[Plugins|plugins]]/*.cfg; do
grep 'type=1' $f>/dev/null && rm -f $newroot/lib/[[Tuxbox|tuxbox]]/[[Plugins|plugins]]/`basename $f .cfg`.*
done
for f in $newroot/share/[[Tuxbox|tuxbox]]/[[Neutrino|neutrino]]/[[Locale|locale]]/*; do
(echo $LANGUAGES | grep -v `basename $f .[[Locale|locale]]` >/dev/null) && rm -f $f
done

===== /.version anpassen =====

{{edit_version_file}}

Eine eigene ''/.version''-File herzustellen (angezeigt von [[Neutrino|Neutrino]] durch dBox -> Services -> [[Image|Image]]-Version und [[cdkVcInfo]] beim Booten) ist daher sicher ein allgemeiner Wunsch.

*[[Flash|flash]]-version-local.sh

#/bin/sh
USER=$(whoami)
if [ $0 = $CDIR/flash-version-local.sh ] ; then
outfile=$FLASHDIR/root/.version
type="[[Image|Image]]"
else
outfile=$TARGETDIR/.version
type="[[Yadd|Yadd]]"
fi;
echo Creating $outfile ...
echo "version=`./mkversion -[[Snapshot|snapshot]] -version 200`" > $outfile
echo "creator=$USER" >> $outfile
echo "imagename=$USER-$type" >> $outfile
echo "homepage=[[HTTP|http]]://www.your-website.de" >> $outfile

===== mkversion =====
Das benannte Script ''mkversion'' erzeugt die etwas kryptische Versionszeichenkette:

#!/bin/sh
releasetype=3
versionnumber=000
year=`date +%Y`
month=`date +%m`
day=`date +%d`
hour=`date +%H`
minute=`date +%M`
while expr $# > 0 ; do
case "$1" in
-[[Release|release]])
releasetype=0
;;
-[[Snapshot|snapshot]])
releasetype=1
;;
-internal)
releasetype=2
;;
-version)
versionnumber=$2
shift
;;
esac
shift
done
echo $releasetype$versionnumber$year$month$day$hour$minute

===== Archivierung der [[Images|Images]] =====
Es ist eigentlich die Aufgabe des Buildprozesses, flashbare [[Images|Images]] zu erzeugen, und nicht sie zu archivieren. Jedoch kann die [[Customization|Customization]] leicht dazu "missbraucht" werden, um irgendeine Art der Archivierung zu ermöglichen, wie das folgende Beispiel zeigt:

#!/bin/sh
flashprefix=$1
imagefile=`basename $0|sed -e s/-local.sh//`
imagefilebase=`echo $imagefile|sed -e s/\.img.x//`
extension=`echo $imagefile|sed -e s/[-a-z0-9]*\.//`
newfilename="barf-"$imagefilebase-`date --iso-8601`.$extension
echo Copying $flashprefix/$imagefile to $flashprefix/$newfilename...
cp $flashprefix/$imagefile $flashprefix/$newfilename

Das Script sollte einen oder mehr der Namen
[neutrino, enigma]-[squashfs, jffs2].[img1x, img2x]
haben. Es benennt die Files entsprechend dem Tagesdatum um.

= Einige "best practices" =
In diesem Abschnitt befinden sich einige Richtlinien, die zwar nicht zwingend "notwendig" sind, um korrekte Ergebnisse zu erzeilen, jedoch werden sie langfristig helfen, bessere, zuverlässigere und pflegbare [[Software|Software]] zu erstellen. Dies betrifft Customizations, sowie zukünftige Änderungen am Makefile und deren Bestandteile selbst.
 
Wenn man diese Richtlinien nicht mag, kann man sie ignorieren, zumindest wenn man [[Customization|Customization]] Scripte für den eigenen Bedarf schreibt.

== Idempotens ==
Es ist fast immer eine gute Idee zu versuchen, ein Installationsscript [[Wikipedia:Idempotent|idempotent]] zu schreiben. Dies bedeutet, dass das mehrmalige Ausführen den gleichen Effekt hat wie das einmalige Ausführen.
Benutze "[[Make|make]] install".
 
In der Vergangenheit hat das [[Tuxbox|Tuxbox]] Makefile die Komponenten zuerst in ''$(targetprefix)'' installiert, und dann die Imageverzeichnisse durch Kopieren der einzelnen Files aus der ''$(targetprefix)'' Hierarchie erstellt. Dieses ist keine sehr gute Softwaretechnik.
 
Zuerst gehört das Know-How bzgl. [[Installation|Installation]] des Paketes in das Makefile des Pakets, und soll nicht in einem einzigem großen Makefile sitzen, das einfach einzelne Files rüberkopiert. Wenn dieses Paket sich ändert, z.B. man ein Konfigurations-File hinzufügt oder löscht, wird es auch notwendig, das globale Makefile zu ändern.
 
 
Es ist häufig der Fall, dass das Makefile, das zu einem Paket gehört, include-Files, (statische) Bibliotheken, Info-Files etc. installiert, die nicht auf einem enbedded System mit beschränktem Speicher erwünscht sind. Die korrekte Lösung zu diesem (wirklichen!) Problem wäre, das Makefile des betreffenden Pakets zu ändern, entweder, um ein flashinstall-Target zu schreiben, oder das Makefile mit einem Parameter wie ''installsize=[full,flash]'' zu versehen.
 
Wenn dies nicht durchführbar ist, ist es durchaus sinnvoller, daß nach [[Make|make]] -C ... install das Löschen unerwünschter Files besser ist, als das kopieren einzelner Files.
 
Zu erwähnen ist auch, daß in dem Schritt, der die Verzeichnisse ''$(flashprefix)/root-[[GUI|gui]]-[[Filesystem|filesystem]]'' erzeugt, das include-verzeichnis, sowie alle statischen Bibliotheken gelöscht werden und dynamische Bibliotheken von unbenutzten Symbolen gestrippt werden.

== Antworten auf einige Fragen ==
=== Falls das Build nicht gelingt ===
Es gibt kein Standardverfahren was zu tun wäre, wenn das Build misslingt. Es wird versucht, hier einige Richtlinien zu geben und diese zu lesen bevor man im Forum postet.
 
Zuerst, überprüft man den Output der ersten zwei Schritte, '''autogen.sh''' und '''configure''' auf Fehler und Warnungen. Jede Warnung oder Fehler, außer den fünf Warnungen, die oben genannt wurden, zeigen ein Problem an, dass ein Build wahrscheinlich unmöglich macht.
 
Wenn ein Build abbricht, kann es die Umgebung in einem [[Wikipedia:Inkonsistent|inkonsistenten]] Zustand versetzen. Dies gilt insbesondere für die Verzeichnisse in '''$(flashprefix)'''. Wenn der Bau solch eines [[Make|Make]]-Targets abbricht, besteht das Verzeichnis, ist entsprechend seiner Änderungszeit aktuell, und ein folgender [[Make|make]] Befehl behandelt ihn wie fertig und okay.
 
Selbstverständlich wird ein fehlerhaftes Build das Ergebniss sein. Wenn ein Build eines Unterverzeichnisses von '''$(flashprefix)''' in die [[BR|Br]]üche geht, '''dann lösche man es''', bevor ein anderer [[Make|Make]] Befehl ausgeführt wird.
 
Bei "es funktionierte gestern"-Problemen, ist vermutlich die Umgebung in solch einem Zustand. Ein mehr-oder-weniger drastischer Reinigungsbefehl (siehe oben) ist hierbei oft schneller als eine Problemsuche.
 
Wenn man [[Hilfe|Hilfe]] benötigt, siehe unten!.

=== Nach dem [[Flashen|Flashen]]: "Kein System" auf dem [[LCD|LCD]]/Was ist diese "bad magic byte" Zeugs? ===
Diese Frage kommt hoffentlich nicht... Die kurze Antwort ist: Man weiß es nicht. Wir [[Wissen|wissen]] es nicht. Aber, wenn Ihr diesen Artikel so weit gelesen habt, erwartet bitte keine "kurze Antworten", sondern "gute Antworten". O.K. Das Thema ist ausführlich hier besprochen worden. 
Kurz gesagt, das [[Image|Image]] "ist" in Ordnung, es ist nur dass irgendwelche [[Firmware|Firmware]] in der dBox es zurückweisen wird, weil es einige "schlechte magische Bytes" auf bestimmten Adressen finden wird.
 
Das Programm [[checkImage]] aus dem [[CVS|CVS]], zu finden im Verzeichnis '''./hostapps/[[CheckImage|checkImage]]''' ermittelt diese "schlechten Bytes", aber ändert nichts daran, um diese zu beheben. Die Erfahrung zeigt, daß [[Images|Images]], die [[checkImage]] für gut findet, wirklich laufen. [[Squashfs|squashfs]] [[Images|Images]], worüber sich [[CheckImage|checkImage]] beschwert, laufen im allgemeinen nicht, in einigen Ausnahmefällen laufen sie aber doch.
 
Auch bei [[Jffs2|jffs2]]-[[Images|Images]] ist es manchmal der Fall, dass sich [[checkImage]] beschwert, die [[Images|Images]] laufen, aber eben nicht immer. Mit diesen empirischen Beobachtungen ist man nun sich selbst überlassen.
 
Der Buildprozess weiß, wie dieses Programm aufgerufen werden kann, um die erzeugenden [[Images|Images]] automatisch zu überprüfen. Die Konfigurationsoption
--with-[[CheckImage|checkImage]]=[none,rename,warn]
wird hierfür verwendet. Falls '''warn''' gewählt ist, wird für jedes [[Image|Image]], das den Test nicht besteht, eine leere Datei erzeugt, am Namen wird ''"_bad"'' angehängt. Wenn '''rename''' gewählt wird, wird das fragliche Imagefile nur umbenannt indem ''"_bad"'' angehängt wird.
 
Es muss noch erwähnt werden, daß die "schlechten magischen Bytes" in einem (oder mehreren!) der Partitionsteile sitzen, und werden nicht durch den abschließenden Schritt erzeugt, welche die endgültigen *.img1x und/oder *.img2x Files zusammenstellen. Es ist auch möglich, [[CheckImage|checkImage]] auf die einzelnen Partitionsfiles anzuwenden *.[[Jffs2|jffs2]] oder *.[[Squashfs|squashfs]], *.flfs1x, *.flfs2x.
Schließlich besitzt [[CheckImage|checkImage]] eine Debugoption, die nützlich sein kann.

== Ich habe ein Fehler gefunden! ==
Bugs, Unklarheiten, Verbesserungsvorschläge, etc. der [[Software|Software]] sollten vorzugsweise im [http://tuxbox-forum.dreambox-fan.de/forum/viewforum.php?f=7 Cross Development Kit - Forum] des [[Tuxbox|Tuxbox]]-Boards gepostet werden.

== Ich benötige [[Hilfe|Hilfe]]! ==
Supportanfragen können im [http://tuxbox-forum.dreambox-fan.de/forum/viewforum.php?f=7 Cross Development Kit - Forum] des [[Tuxbox|Tuxbox]]-Boards gepostet werden. Postings in deutsch oder englisch sind willkommen. Bitte nicht vergessen, die benutzten Konfigurationsoptionen zu erwähnen.

=Weblinks=
*[http://www.gnu.org/software/make/manual/make.html GNU Make manual]
*[http://www.gnu.org/software/autoconf/manual/ Autoconf manual]
*[http://www.gnu.org/software/automake/manual/ Automake manual]
*[http://sources.redhat.com/autobook/ GNU Autoconf, Automake, and Libtool]
*[http://www.gnu.org/prep/standards/ GNU Coding standards]
*[http://cvsbook.red-bean.com/ Open Source Development with CVS, 3rd Edition]
*Barf's Homepage: [http://bengt-martensson.de/dbox2/ Barfs ][[Newmake]]-Dokumentation
*[http://www.dreambox-fan.de/forum/viewtopic.php?f=13&t=48503&start=0&hilit=VMWare Herstellung eines VMWare-Images]
*http://linux.bytesex.org/

{{review}}

{{body}}

Development:GDB Remote einrichten

2009-10-30T08:13:41Z

Rhabarber1848:

[[Category:Register]]
[[Category:Development]]
[[Category:CDK]]
{{Development_sidebar}}

__TOC__

=Build Konfiguration=
cdk/configure
damit alle Debugsymbole vorhanden sind
--disable-flashrules

make yadd-neutrino gdb gdb-remote

=Modifikation der Startscripte=
In cdkroot/etc/init.d/start_neutrino hinter die Zeile
Code:
nhttpd

folgendes einfügen:
Code:
exit 0

=Anwenden=
weil wir Neutrino manuell starten werden.
Yadd booten.

Per Telnet auf die Dbox einloggen, dann:
Code:
gdbserver :5555 neutrino

gdb wartet dann auf den connect eines clients:
Zitat:
Process neutrino created; pid = 189
Listening on port 5555

Auf dem Client ins Verzeichnis
$prefix/cdk/bin
wechseln und
Code:
./powerpc-tuxbox-linux-gnu-gdb ../../cdkroot/bin/neutrino

Dann geht es los:
Code:
target remote dbox:5555
continue

Wenn Neutrino abgestürzt ist, kann, wie gehabt, mit
Code:
bt full

ein backtrace erzeugt werden.

=Weblinks=
http://forum.tuxbox.org/forum/viewtopic.php?p=366575#p366575

Neutrino:Esound Soundserver

2009-05-02T20:24:31Z

Rhabarber1848: /* Voraussetzungen */

[[Category:Register]]
[[Category:Neutrino]]
{{Neutrino_sidebar}}
__TOC__

=Allgemeines=

Mit [[Esound]] werden Sounddateien, die z.B.mit einem Player-Programm auf einem Laptop abgespielt werden, über LAN oder WLAN zu einem zweiten PC übertragen und sind dort hörbar. In unserem Fall hier ist die [[dBox2]] der zweite PC. Zu beachten ist, dass Esound auf der Dbox ohne Support für das Laden und die spätere Wiedergabe von Samples kompiliert wurde, um auf libaudiofile.so (> 100kb im Flash) verzichten zu können.

Was ist der Vorteil gegenüber der sonst üblichen Dateifreigabe? Nun, ich sitze am Laptop mit seinen lächerlichen Boxen, starte z.B. eine mp3 und aus meiner Stereoanlage, an die die [[dBox2]] angeschlossen ist, ertönen kräftige Laute. Und so geht es:

=Voraussetzungen=
Erforderlich ist ein aktuelles (Stand ab April 2009) [[Image]] mit dem "'''[[Esound|Esound Soundserver]]'''", welches im [[Neutrino:Hauptmenü|Neutrino Hauptmenü]] ausgewählt wird.
In den Personalisierungseinstellungen ist dieser Menüpunkt, wie das Internetradio, deaktiviert und muss vor der ersten Benutzung erst sichtbar gemacht werden.
[[Bild:Menue-esound.png|none|thumb|300px]]
Wird dieser gestartet, belauscht die Box standardmäßig den Port 16001. Dies kann in der Datei

/var/etc/init.d/start_esound
mit dem Parameter
-port xxx

geändert werden.

Alternativ zum Neutrino-Menüpunkt kann der Esound-Soundserver auch über yweb, Boxcontrol, Control gestartet und beendet werden.

Nach dem Aufrufen von [[Esound]] erscheint eine kurze Meldung am Bildschirm.
[[Bild:Esound-end.png|none|thumb|300px]]
Während der Laufzeit des Esound-Soundservers funktioniert die Lautstärkeregelung der Dbox weiterhin.

Wird der Server nicht mehr benötigt, kann mit der ''home''-Taste in den Normalbetrieb zurückgeschaltet werden.

Nun braucht man nur noch einen PC, der die Sounddatei (das kann auch der Ton eines Filmes sein) zur D-Box schiebt. Das geht mit verschiedenen Medienplayern.

=Grundprogramme für den PC=

sudo apt-get install esound
sudo apt-get install esound-clients

Mit

esd -port 16001 -tcp -public &

kann jetzt ein Soundserver getartet werden. D.h. andere PC's senden ihre Sounddaten hier hin.

Wenn die Dbox alleiniger Soundserver sein soll, ist das Paket esound und das Starten des Soundservers auf dem Client nicht erforderlich.

=Windows=
Unter Windows eignet sich [[Winamp]] mit dem [http://home.in.tum.de/~pustka/WL-500g_as_wireless_soundcard.html Esound-plugin] out_esd.dll. Dazu unter Host die IP oder den Namen (hier "dbox2") und den Port eintragen.

''Ganz wichtig:'' Wenn die Verbindung zwischen Winamp und der Dbox2 nicht funktioniert, kann es aufgrund spezifischer Netzwerkkonfigurationen erforderlich sein, unter system32\drivers\etc\hosts die Zeile "192.168.0.5 dbox2" einzufügen, die IP-Adresse und der Hostname müssen dabei den lokalen Gegebenheiten angepasst werden.

Ein Windows Rechner kann aber auch empfangen. Am einfachsten esound.zip runterladen und im DOS-Fenster mit
esd.exe -tcp -port 16001 -public
starten.

=Linux=

Einen Linux PC bewegt man so zum Senden:

==MPlayer==

sudo apt-get install mplayer
export ESPEAKER=192.168.0.5:16001 && gmplayer

bei Preferences Audio ''esd'' wählen

==Player auf xine Basis==

hier muß noch ein esd plugin geladen werden

sudo apt-get install libxine1-gnome

==amarok==

export ESPEAKER=192.168.0.5:16001 && amarokapp

bei Audio Ausgabe ''esd'' wählen

==KMPlayer==

sudo apt-get install kmplayer

export ESPEAKER=192.168.0.5:16001 && kmplayer

bei KMPlayer einrichten Ausgabe auf ''esd'' stellen

==kaffeine==

sudo apt-get install kaffeine

export ESPEAKER=192.168.0.5:16001 && kaffeine

bei xine-Parameter ''esd'' wählen

==mpg123==

sudo apt-get install mpg123-esd

ESPEAKER=192.168.0.5:16001 mpg123-esd datei.mp3

'''Bitte beachten,'''
''die Player benötigen alle libxine1-gnome.''

Wer Lust hat, kann ja bitte noch weitere Player testen.

liab

=Weblinks=
*esd Winamp Plugin http://www.linuxfan.dk/download/readme-ESD.txt
*Winamp-Player http://www.winamp.com/

Esound

2009-04-17T09:03:57Z

Rhabarber1848:

Der '''Enlightened Sound Daemon''', kurz '''EsounD''' oder '''esd''', ist ein Sound[[server]], der normalerweise von den [[WP:Fenstermanager|Fenstermanager]]n [[WP:Enlightenment|Enlightenment]] und [[WP:GNOME|Gnome]] verwendet wird.

Zweck eines Soundservers ist es, dafür zu sorgen, dass mehrere [[Anwendungsprogramm|Anwendungen]] gleichzeitig Audiosignale ausgeben können. Dazu greifen die Anwendungen selbst nicht mehr direkt auf das Audiogerät beziehungsweise deren Treiber zu, sondern senden stattdessen den wiederzugebenden Audiostrom an den Soundserver. Dieser mischt die Ströme und spielt das Ergebnis dann über das Audiogerät ab.

EsounD verfügt auch über einfache [[WP:Sequenzer (Musik)|Sequenzer]]fähigkeiten; so können [[WP:Computersample|Samples]] geladen und später wiedergegeben werden, auf der Dbox2 ist diese Funktion aus Platzgründen nicht implementiert. Weiterhin ist EsounD [[WP:Netzwerktransparenz|netzwerktransparent]] - ein Programm muss also nicht auf demselben [[WP:Host (Informationstechnik)|Host]] wie der Soundserver laufen, um Audioströme an diesen zu senden.

== Weblinks ==
* [http://www.tux.org/~ricdude/EsounD.html EsounD Website] (englisch)
* [ftp://ftp.gnome.org/pub/GNOME/sources/esound/0.2/ FTP-Server mit neuen Releases]

Neutrino:Esound Soundserver

2009-04-17T09:03:09Z

Rhabarber1848: /* Allgemeines */

[[Category:Register]]
[[Category:Neutrino]]
{{Neutrino_sidebar}}
__TOC__

=Allgemeines=

Mit [[Esound]] werden Sounddateien, die z.B.mit einem Player-Programm auf einem Laptop abgespielt werden, über LAN oder WLAN zu einem zweiten PC übertragen und sind dort hörbar. In unserem Fall hier ist die [[dBox2]] der zweite PC. Zu beachten ist, dass Esound auf der Dbox ohne Support für das Laden und die spätere Wiedergabe von Samples kompiliert wurde, um auf libaudiofile.so (> 100kb im Flash) verzichten zu können.

Was ist der Vorteil gegenüber der sonst üblichen Dateifreigabe? Nun, ich sitze am Laptop mit seinen lächerlichen Boxen, starte z.B. eine mp3 und aus meiner Stereoanlage, an die die [[dBox2]] angeschlossen ist, ertönen kräftige Laute. Und so geht es:

=Voraussetzungen=
Erforderlich ist ein aktuelles (Stand ab April 2009) [[Image]] mit dem "'''[[Esound|Esound Soundserver]]'''", welches im [[Neutrino:Hauptmenü|Neutrino Hauptmenü]] ausgewählt wird.
In den Personalisierungseinstellungen ist dieser Menüpunkt, wie das Internetradio, deaktiviert und muss vor der ersten Benutzung erst sichtbar gemacht werden.
[[Bild:Menue-esound.png|none|thumb|300px]]
Wird dieser gestartet, belauscht die Box standardmäßig den Port 16001. Dies kann in der Datei

/var/etc/init.d/start_esound
mit dem Parameter
-port xxx

geändert werden.

Nach dem Aufrufen von [[Esound]] erscheint eine kurze Meldung am Bildschirm.
[[Bild:Esound-end.png|none|thumb|300px]]
Während der Laufzeit des Esound-Soundservers funktioniert die Lautstärkeregelung der Dbox weiterhin.

Wird der Server nicht mehr benötigt, kann mit der ''home''-Taste in den Normalbetrieb zurückgeschaltet werden.

Nun braucht man nur noch einen PC, der die Sounddatei (das kann auch der Ton eines Filmes sein) zur D-Box schiebt. Das geht mit verschiedenen Medienplayern.

=Grundprogramme für den PC=

sudo apt-get install esound
sudo apt-get install esound-clients

Mit

esd -port 16001 -tcp -public &

kann jetzt ein Soundserver getartet werden. D.h. andere PC's senden ihre Sounddaten hier hin.

Wenn die Dbox alleiniger Soundserver sein soll, ist das Paket esound und das Starten des Soundservers auf dem Client nicht erforderlich.

=Windows=
Unter Windows eignet sich [[Winamp]] mit dem [http://home.in.tum.de/~pustka/WL-500g_as_wireless_soundcard.html Esound-plugin] out_esd.dll. Dazu unter Host die IP oder den Namen (hier "dbox2") und den Port eintragen.

''Ganz wichtig:'' Wenn die Verbindung zwischen Winamp und der Dbox2 nicht funktioniert, kann es aufgrund spezifischer Netzwerkkonfigurationen erforderlich sein, unter system32\drivers\etc\hosts die Zeile "192.168.0.5 dbox2" einzufügen, die IP-Adresse und der Hostname müssen dabei den lokalen Gegebenheiten angepasst werden.

Ein Windows Rechner kann aber auch empfangen. Am einfachsten esound.zip runterladen und im DOS-Fenster mit
esd.exe -tcp -port 16001 -public
starten.

=Linux=

Einen Linux PC bewegt man so zum Senden:

==MPlayer==

sudo apt-get install mplayer
export ESPEAKER=192.168.0.5:16001 && gmplayer

bei Preferences Audio ''esd'' wählen

==Player auf xine Basis==

hier muß noch ein esd plugin geladen werden

sudo apt-get install libxine1-gnome

==amarok==

export ESPEAKER=192.168.0.5:16001 && amarokapp

bei Audio Ausgabe ''esd'' wählen

==KMPlayer==

sudo apt-get install kmplayer

export ESPEAKER=192.168.0.5:16001 && kmplayer

bei KMPlayer einrichten Ausgabe auf ''esd'' stellen

==kaffeine==

sudo apt-get install kaffeine

export ESPEAKER=192.168.0.5:16001 && kaffeine

bei xine-Parameter ''esd'' wählen

==mpg123==

sudo apt-get install mpg123-esd

ESPEAKER=192.168.0.5:16001 mpg123-esd datei.mp3

'''Bitte beachten,'''
''die Player benötigen alle libxine1-gnome.''

Wer Lust hat, kann ja bitte noch weitere Player testen.

liab

=Weblinks=
*esd Winamp Plugin http://www.linuxfan.dk/download/readme-ESD.txt
*Winamp-Player http://www.winamp.com/

Neutrino:Esound Soundserver

2009-04-15T21:42:27Z

Rhabarber1848: /* Windows */

[[Category:Register]]
[[Category:Neutrino]]
{{Neutrino_sidebar}}
__TOC__

=Allgemeines=

Mit [[Esound]] werden Sounddateien, die z.B.mit einem Player-Programm auf einem Laptop abgespielt werden, über LAN oder WLAN zu einem zweiten PC übertragen und sind dort hörbar. In unserem Fall hier ist die [[dBox2]] der zweite PC.

Was ist der Vorteil gegenüber der sonst üblichen Dateifreigabe? Nun, ich sitze am Laptop mit seinen lächerlichen Boxen, starte z.B. eine mp3 und aus meiner Stereoanlage, an die die [[dBox2]] angeschlossen ist, ertönen kräftige Laute. Und so geht es:

=Voraussetzungen=
Erforderlich ist ein aktuelles (Stand ab April 2009) [[Image]] mit dem "'''[[Esound|Esound Soundserver]]'''", welches im [[Neutrino:Hauptmenü|Neutrino Hauptmenü]] ausgewählt wird.
In den Personalisierungseinstellungen ist dieser Menüpunkt, wie das Internetradio, deaktiviert und muss vor der ersten Benutzung erst sichtbar gemacht werden.
[[Bild:Menue-esound.png|none|thumb|300px]]
Wird dieser gestartet, belauscht die Box standardmäßig den Port 16001. Dies kann in der Datei

/var/etc/init.d/start_esound
mit dem Parameter
-port xxx

geändert werden.

Nach dem Aufrufen von [[Esound]] erscheint eine kurze Meldung am Bildschirm.
[[Bild:Esound-end.png|none|thumb|300px]]
Während der Laufzeit des Esound-Soundservers funktioniert die Lautstärkeregelung der Dbox weiterhin.

Wird der Server nicht mehr benötigt, kann mit der ''home''-Taste in den Normalbetrieb zurückgeschaltet werden.

Nun braucht man nur noch einen PC, der die Sounddatei (das kann auch der Ton eines Filmes sein) zur D-Box schiebt. Das geht mit verschiedenen Medienplayern.

=Grundprogramme für den PC=

sudo apt-get install esound
sudo apt-get install esound-clients

Mit

esd -port 16001 -tcp -public &

kann jetzt ein Soundserver getartet werden. D.h. andere PC's senden ihre Sounddaten hier hin.

Wenn die Dbox alleiniger Soundserver sein soll, ist das Paket esound und das Starten des Soundservers auf dem Client nicht erforderlich.

=Windows=
Unter Windows eignet sich [[Winamp]] mit dem [http://home.in.tum.de/~pustka/WL-500g_as_wireless_soundcard.html Esound-plugin] out_esd.dll. Dazu unter Host die IP oder den Namen (hier "dbox2") und den Port eintragen.

''Ganz wichtig:'' Wenn die Verbindung zwischen Winamp und der Dbox2 nicht funktioniert, kann es aufgrund spezifischer Netzwerkkonfigurationen erforderlich sein, unter system32\drivers\etc\hosts die Zeile "192.168.0.5 dbox2" einzufügen, die IP-Adresse und der Hostname müssen dabei den lokalen Gegebenheiten angepasst werden.

Ein Windows Rechner kann aber auch empfangen. Am einfachsten esound.zip runterladen und im DOS-Fenster mit
esd.exe -tcp -port 16001 -public
starten.

=Linux=

Einen Linux PC bewegt man so zum Senden:

==MPlayer==

sudo apt-get install mplayer
export ESPEAKER=192.168.0.5:16001 && gmplayer

bei Preferences Audio ''esd'' wählen

==Player auf xine Basis==

hier muß noch ein esd plugin geladen werden

sudo apt-get install libxine1-gnome

==amarok==

export ESPEAKER=192.168.0.5:16001 && amarokapp

bei Audio Ausgabe ''esd'' wählen

==KMPlayer==

sudo apt-get install kmplayer

export ESPEAKER=192.168.0.5:16001 && kmplayer

bei KMPlayer einrichten Ausgabe auf ''esd'' stellen

==kaffeine==

sudo apt-get install kaffeine

export ESPEAKER=192.168.0.5:16001 && kaffeine

bei xine-Parameter ''esd'' wählen

==mpg123==

sudo apt-get install mpg123-esd

ESPEAKER=192.168.0.5:16001 mpg123-esd datei.mp3

'''Bitte beachten,'''
''die Player benötigen alle libxine1-gnome.''

Wer Lust hat, kann ja bitte noch weitere Player testen.

liab

=Weblinks=
*esd Winamp Plugin http://www.linuxfan.dk/download/readme-ESD.txt
*Winamp-Player http://www.winamp.com/

Neutrino:Esound Soundserver

2009-04-15T21:38:21Z

Rhabarber1848: /* Grundprogramme für den PC */

[[Category:Register]]
[[Category:Neutrino]]
{{Neutrino_sidebar}}
__TOC__

=Allgemeines=

Mit [[Esound]] werden Sounddateien, die z.B.mit einem Player-Programm auf einem Laptop abgespielt werden, über LAN oder WLAN zu einem zweiten PC übertragen und sind dort hörbar. In unserem Fall hier ist die [[dBox2]] der zweite PC.

Was ist der Vorteil gegenüber der sonst üblichen Dateifreigabe? Nun, ich sitze am Laptop mit seinen lächerlichen Boxen, starte z.B. eine mp3 und aus meiner Stereoanlage, an die die [[dBox2]] angeschlossen ist, ertönen kräftige Laute. Und so geht es:

=Voraussetzungen=
Erforderlich ist ein aktuelles (Stand ab April 2009) [[Image]] mit dem "'''[[Esound|Esound Soundserver]]'''", welches im [[Neutrino:Hauptmenü|Neutrino Hauptmenü]] ausgewählt wird.
In den Personalisierungseinstellungen ist dieser Menüpunkt, wie das Internetradio, deaktiviert und muss vor der ersten Benutzung erst sichtbar gemacht werden.
[[Bild:Menue-esound.png|none|thumb|300px]]
Wird dieser gestartet, belauscht die Box standardmäßig den Port 16001. Dies kann in der Datei

/var/etc/init.d/start_esound
mit dem Parameter
-port xxx

geändert werden.

Nach dem Aufrufen von [[Esound]] erscheint eine kurze Meldung am Bildschirm.
[[Bild:Esound-end.png|none|thumb|300px]]
Während der Laufzeit des Esound-Soundservers funktioniert die Lautstärkeregelung der Dbox weiterhin.

Wird der Server nicht mehr benötigt, kann mit der ''home''-Taste in den Normalbetrieb zurückgeschaltet werden.

Nun braucht man nur noch einen PC, der die Sounddatei (das kann auch der Ton eines Filmes sein) zur D-Box schiebt. Das geht mit verschiedenen Medienplayern.

=Grundprogramme für den PC=

sudo apt-get install esound
sudo apt-get install esound-clients

Mit

esd -port 16001 -tcp -public &

kann jetzt ein Soundserver getartet werden. D.h. andere PC's senden ihre Sounddaten hier hin.

Wenn die Dbox alleiniger Soundserver sein soll, ist das Paket esound und das Starten des Soundservers auf dem Client nicht erforderlich.

=Windows=
Bei windows eignet sich [[Winamp]] mit dem [[Esound]] [[Link-Text]]plugin (die Datei heißt out_esd.dll). Dazu unter Host die IP oder den Namen (hier "dbox2") und den Port eintragen.

''Ganz wichtig:'' Unter system32\drivers\etc\hosts die Zeile "192.168.0.5 dbox2" einfügen. Vergißt man das, funktioniert es je nach Netzwerkkonfiguration nicht!

Ein Windows Rechner kann aber auch empfangen. Am einfachsten esound.zip runterladen und im DOS-Fenster mit
esd.exe -tcp -port 16001 -public
starten.

=Linux=

Einen Linux PC bewegt man so zum Senden:

==MPlayer==

sudo apt-get install mplayer
export ESPEAKER=192.168.0.5:16001 && gmplayer

bei Preferences Audio ''esd'' wählen

==Player auf xine Basis==

hier muß noch ein esd plugin geladen werden

sudo apt-get install libxine1-gnome

==amarok==

export ESPEAKER=192.168.0.5:16001 && amarokapp

bei Audio Ausgabe ''esd'' wählen

==KMPlayer==

sudo apt-get install kmplayer

export ESPEAKER=192.168.0.5:16001 && kmplayer

bei KMPlayer einrichten Ausgabe auf ''esd'' stellen

==kaffeine==

sudo apt-get install kaffeine

export ESPEAKER=192.168.0.5:16001 && kaffeine

bei xine-Parameter ''esd'' wählen

==mpg123==

sudo apt-get install mpg123-esd

ESPEAKER=192.168.0.5:16001 mpg123-esd datei.mp3

'''Bitte beachten,'''
''die Player benötigen alle libxine1-gnome.''

Wer Lust hat, kann ja bitte noch weitere Player testen.

liab

=Weblinks=
*esd Winamp Plugin http://www.linuxfan.dk/download/readme-ESD.txt
*Winamp-Player http://www.winamp.com/

Neutrino:Esound Soundserver

2009-04-15T21:37:50Z

Rhabarber1848: /* Voraussetzungen */

[[Category:Register]]
[[Category:Neutrino]]
{{Neutrino_sidebar}}
__TOC__

=Allgemeines=

Mit [[Esound]] werden Sounddateien, die z.B.mit einem Player-Programm auf einem Laptop abgespielt werden, über LAN oder WLAN zu einem zweiten PC übertragen und sind dort hörbar. In unserem Fall hier ist die [[dBox2]] der zweite PC.

Was ist der Vorteil gegenüber der sonst üblichen Dateifreigabe? Nun, ich sitze am Laptop mit seinen lächerlichen Boxen, starte z.B. eine mp3 und aus meiner Stereoanlage, an die die [[dBox2]] angeschlossen ist, ertönen kräftige Laute. Und so geht es:

=Voraussetzungen=
Erforderlich ist ein aktuelles (Stand ab April 2009) [[Image]] mit dem "'''[[Esound|Esound Soundserver]]'''", welches im [[Neutrino:Hauptmenü|Neutrino Hauptmenü]] ausgewählt wird.
In den Personalisierungseinstellungen ist dieser Menüpunkt, wie das Internetradio, deaktiviert und muss vor der ersten Benutzung erst sichtbar gemacht werden.
[[Bild:Menue-esound.png|none|thumb|300px]]
Wird dieser gestartet, belauscht die Box standardmäßig den Port 16001. Dies kann in der Datei

/var/etc/init.d/start_esound
mit dem Parameter
-port xxx

geändert werden.

Nach dem Aufrufen von [[Esound]] erscheint eine kurze Meldung am Bildschirm.
[[Bild:Esound-end.png|none|thumb|300px]]
Während der Laufzeit des Esound-Soundservers funktioniert die Lautstärkeregelung der Dbox weiterhin.

Wird der Server nicht mehr benötigt, kann mit der ''home''-Taste in den Normalbetrieb zurückgeschaltet werden.

Nun braucht man nur noch einen PC, der die Sounddatei (das kann auch der Ton eines Filmes sein) zur D-Box schiebt. Das geht mit verschiedenen Medienplayern.

=Grundprogramme für den PC=

sudo apt-get install esound
sudo apt-get install esound-clients

Mit

esd -port 16001 -tcp -public &

kann jetzt ein Soundserver getartet werden. D.h. andere PC's senden ihre Sounddaten hier hin.

Wenn die Dbox alleiniger Soundserver sein soll, ist das Paket esound auf dem Client nicht erforderlich.

=Windows=
Bei windows eignet sich [[Winamp]] mit dem [[Esound]] [[Link-Text]]plugin (die Datei heißt out_esd.dll). Dazu unter Host die IP oder den Namen (hier "dbox2") und den Port eintragen.

''Ganz wichtig:'' Unter system32\drivers\etc\hosts die Zeile "192.168.0.5 dbox2" einfügen. Vergißt man das, funktioniert es je nach Netzwerkkonfiguration nicht!

Ein Windows Rechner kann aber auch empfangen. Am einfachsten esound.zip runterladen und im DOS-Fenster mit
esd.exe -tcp -port 16001 -public
starten.

=Linux=

Einen Linux PC bewegt man so zum Senden:

==MPlayer==

sudo apt-get install mplayer
export ESPEAKER=192.168.0.5:16001 && gmplayer

bei Preferences Audio ''esd'' wählen

==Player auf xine Basis==

hier muß noch ein esd plugin geladen werden

sudo apt-get install libxine1-gnome

==amarok==

export ESPEAKER=192.168.0.5:16001 && amarokapp

bei Audio Ausgabe ''esd'' wählen

==KMPlayer==

sudo apt-get install kmplayer

export ESPEAKER=192.168.0.5:16001 && kmplayer

bei KMPlayer einrichten Ausgabe auf ''esd'' stellen

==kaffeine==

sudo apt-get install kaffeine

export ESPEAKER=192.168.0.5:16001 && kaffeine

bei xine-Parameter ''esd'' wählen

==mpg123==

sudo apt-get install mpg123-esd

ESPEAKER=192.168.0.5:16001 mpg123-esd datei.mp3

'''Bitte beachten,'''
''die Player benötigen alle libxine1-gnome.''

Wer Lust hat, kann ja bitte noch weitere Player testen.

liab

=Weblinks=
*esd Winamp Plugin http://www.linuxfan.dk/download/readme-ESD.txt
*Winamp-Player http://www.winamp.com/

Neutrino:Esound Soundserver

2009-04-15T21:36:48Z

Rhabarber1848: /* Voraussetzungen */

[[Category:Register]]
[[Category:Neutrino]]
{{Neutrino_sidebar}}
__TOC__

=Allgemeines=

Mit [[Esound]] werden Sounddateien, die z.B.mit einem Player-Programm auf einem Laptop abgespielt werden, über LAN oder WLAN zu einem zweiten PC übertragen und sind dort hörbar. In unserem Fall hier ist die [[dBox2]] der zweite PC.

Was ist der Vorteil gegenüber der sonst üblichen Dateifreigabe? Nun, ich sitze am Laptop mit seinen lächerlichen Boxen, starte z.B. eine mp3 und aus meiner Stereoanlage, an die die [[dBox2]] angeschlossen ist, ertönen kräftige Laute. Und so geht es:

=Voraussetzungen=
Erforderlich ist ein aktuelles (Stand ab April 2009) [[Image]] mit dem "'''[[Esound|Esound Soundserver]]'''", welches im [[Neutrino:Hauptmenü|Neutrino Hauptmenü]] ausgewählt wird.
In den Personalisierungseinstellungen ist dieser Menüpunkt, wie das Internetradio, deaktiviert und muss vor der ersten Benutzung erst sichtbar gemacht werden.
[[Bild:Menue-esound.png|none|thumb|300px]]
Wird dieser gestartet, belauscht die Box standardmäßig den Port 16001. Dies kann in der Datei

/var/etc/init.d/start_esound
mit dem Parameter
-port xxx

geändert werden.

Nach dem Aufrufen von [[Esound]] erscheint eine kurze Meldung am Bildschirm.
[[Bild:Esound-end.png|none|thumb|300px]]
Wird der Server nicht mehr benötigt, kann mit der ''home''-Taste in den Normalbetrieb zurückgeschaltet werden.

Nun braucht man nur noch einen PC, der die Sounddatei (das kann auch der Ton eines Filmes sein) zur D-Box schiebt. Das geht mit verschiedenen Medienplayern.

=Grundprogramme für den PC=

sudo apt-get install esound
sudo apt-get install esound-clients

Mit

esd -port 16001 -tcp -public &

kann jetzt ein Soundserver getartet werden. D.h. andere PC's senden ihre Sounddaten hier hin.

Wenn die Dbox alleiniger Soundserver sein soll, ist das Paket esound auf dem Client nicht erforderlich.

=Windows=
Bei windows eignet sich [[Winamp]] mit dem [[Esound]] [[Link-Text]]plugin (die Datei heißt out_esd.dll). Dazu unter Host die IP oder den Namen (hier "dbox2") und den Port eintragen.

''Ganz wichtig:'' Unter system32\drivers\etc\hosts die Zeile "192.168.0.5 dbox2" einfügen. Vergißt man das, funktioniert es je nach Netzwerkkonfiguration nicht!

Ein Windows Rechner kann aber auch empfangen. Am einfachsten esound.zip runterladen und im DOS-Fenster mit
esd.exe -tcp -port 16001 -public
starten.

=Linux=

Einen Linux PC bewegt man so zum Senden:

==MPlayer==

sudo apt-get install mplayer
export ESPEAKER=192.168.0.5:16001 && gmplayer

bei Preferences Audio ''esd'' wählen

==Player auf xine Basis==

hier muß noch ein esd plugin geladen werden

sudo apt-get install libxine1-gnome

==amarok==

export ESPEAKER=192.168.0.5:16001 && amarokapp

bei Audio Ausgabe ''esd'' wählen

==KMPlayer==

sudo apt-get install kmplayer

export ESPEAKER=192.168.0.5:16001 && kmplayer

bei KMPlayer einrichten Ausgabe auf ''esd'' stellen

==kaffeine==

sudo apt-get install kaffeine

export ESPEAKER=192.168.0.5:16001 && kaffeine

bei xine-Parameter ''esd'' wählen

==mpg123==

sudo apt-get install mpg123-esd

ESPEAKER=192.168.0.5:16001 mpg123-esd datei.mp3

'''Bitte beachten,'''
''die Player benötigen alle libxine1-gnome.''

Wer Lust hat, kann ja bitte noch weitere Player testen.

liab

=Weblinks=
*esd Winamp Plugin http://www.linuxfan.dk/download/readme-ESD.txt
*Winamp-Player http://www.winamp.com/

Neutrino:Esound Soundserver

2009-04-15T21:35:29Z

Rhabarber1848: /* Linux */

[[Category:Register]]
[[Category:Neutrino]]
{{Neutrino_sidebar}}
__TOC__

=Allgemeines=

Mit [[Esound]] werden Sounddateien, die z.B.mit einem Player-Programm auf einem Laptop abgespielt werden, über LAN oder WLAN zu einem zweiten PC übertragen und sind dort hörbar. In unserem Fall hier ist die [[dBox2]] der zweite PC.

Was ist der Vorteil gegenüber der sonst üblichen Dateifreigabe? Nun, ich sitze am Laptop mit seinen lächerlichen Boxen, starte z.B. eine mp3 und aus meiner Stereoanlage, an die die [[dBox2]] angeschlossen ist, ertönen kräftige Laute. Und so geht es:

=Voraussetzungen=
Erforderlich ist ein aktuelles (Stand ab April 2009) [[Image]] mit dem "'''[[Esound|Esound Soundserver]]'''", welches im [[Neutrino:Hauptmenü|Neutrino Hauptmenü]] ausgewählt wird.
[[Bild:Menue-esound.png|none|thumb|300px]]
Wird dieser gestartet, belauscht die Box standardmäßig den Port 16001. Dies kann in der Datei

/var/etc/init.d/start_esound
mit dem Parameter
-port xxx

geändert werden.

Nach dem Aufrufen von [[Esound]] erscheint eine kurze Meldung am Bildschirm.
[[Bild:Esound-end.png|none|thumb|300px]]
Wird der Server nicht mehr benötigt, kann mit der ''home''-Taste in den Normalbetrieb zurückgeschaltet werden.

Nun braucht man nur noch einen PC, der die Sounddatei (das kann auch der Ton eines Filmes sein) zur D-Box schiebt. Das geht mit verschiedenen Medienplayern.

=Grundprogramme für den PC=

sudo apt-get install esound
sudo apt-get install esound-clients

Mit

esd -port 16001 -tcp -public &

kann jetzt ein Soundserver getartet werden. D.h. andere PC's senden ihre Sounddaten hier hin.

Wenn die Dbox alleiniger Soundserver sein soll, ist das Paket esound auf dem Client nicht erforderlich.

=Windows=
Bei windows eignet sich [[Winamp]] mit dem [[Esound]] [[Link-Text]]plugin (die Datei heißt out_esd.dll). Dazu unter Host die IP oder den Namen (hier "dbox2") und den Port eintragen.

''Ganz wichtig:'' Unter system32\drivers\etc\hosts die Zeile "192.168.0.5 dbox2" einfügen. Vergißt man das, funktioniert es je nach Netzwerkkonfiguration nicht!

Ein Windows Rechner kann aber auch empfangen. Am einfachsten esound.zip runterladen und im DOS-Fenster mit
esd.exe -tcp -port 16001 -public
starten.

=Linux=

Einen Linux PC bewegt man so zum Senden:

==MPlayer==

sudo apt-get install mplayer
export ESPEAKER=192.168.0.5:16001 && gmplayer

bei Preferences Audio ''esd'' wählen

==Player auf xine Basis==

hier muß noch ein esd plugin geladen werden

sudo apt-get install libxine1-gnome

==amarok==

export ESPEAKER=192.168.0.5:16001 && amarokapp

bei Audio Ausgabe ''esd'' wählen

==KMPlayer==

sudo apt-get install kmplayer

export ESPEAKER=192.168.0.5:16001 && kmplayer

bei KMPlayer einrichten Ausgabe auf ''esd'' stellen

==kaffeine==

sudo apt-get install kaffeine

export ESPEAKER=192.168.0.5:16001 && kaffeine

bei xine-Parameter ''esd'' wählen

==mpg123==

sudo apt-get install mpg123-esd

ESPEAKER=192.168.0.5:16001 mpg123-esd datei.mp3

'''Bitte beachten,'''
''die Player benötigen alle libxine1-gnome.''

Wer Lust hat, kann ja bitte noch weitere Player testen.

liab

=Weblinks=
*esd Winamp Plugin http://www.linuxfan.dk/download/readme-ESD.txt
*Winamp-Player http://www.winamp.com/

Neutrino:Esound Soundserver

2009-04-15T21:33:49Z

Rhabarber1848: /* Grundprogramme für den PC */

[[Category:Register]]
[[Category:Neutrino]]
{{Neutrino_sidebar}}
__TOC__

=Allgemeines=

Mit [[Esound]] werden Sounddateien, die z.B.mit einem Player-Programm auf einem Laptop abgespielt werden, über LAN oder WLAN zu einem zweiten PC übertragen und sind dort hörbar. In unserem Fall hier ist die [[dBox2]] der zweite PC.

Was ist der Vorteil gegenüber der sonst üblichen Dateifreigabe? Nun, ich sitze am Laptop mit seinen lächerlichen Boxen, starte z.B. eine mp3 und aus meiner Stereoanlage, an die die [[dBox2]] angeschlossen ist, ertönen kräftige Laute. Und so geht es:

=Voraussetzungen=
Erforderlich ist ein aktuelles (Stand ab April 2009) [[Image]] mit dem "'''[[Esound|Esound Soundserver]]'''", welches im [[Neutrino:Hauptmenü|Neutrino Hauptmenü]] ausgewählt wird.
[[Bild:Menue-esound.png|none|thumb|300px]]
Wird dieser gestartet, belauscht die Box standardmäßig den Port 16001. Dies kann in der Datei

/var/etc/init.d/start_esound
mit dem Parameter
-port xxx

geändert werden.

Nach dem Aufrufen von [[Esound]] erscheint eine kurze Meldung am Bildschirm.
[[Bild:Esound-end.png|none|thumb|300px]]
Wird der Server nicht mehr benötigt, kann mit der ''home''-Taste in den Normalbetrieb zurückgeschaltet werden.

Nun braucht man nur noch einen PC, der die Sounddatei (das kann auch der Ton eines Filmes sein) zur D-Box schiebt. Das geht mit verschiedenen Medienplayern.

=Grundprogramme für den PC=

sudo apt-get install esound
sudo apt-get install esound-clients

Mit

esd -port 16001 -tcp -public &

kann jetzt ein Soundserver getartet werden. D.h. andere PC's senden ihre Sounddaten hier hin.

Wenn die Dbox alleiniger Soundserver sein soll, ist das Paket esound auf dem Client nicht erforderlich.

=Windows=
Bei windows eignet sich [[Winamp]] mit dem [[Esound]] [[Link-Text]]plugin (die Datei heißt out_esd.dll). Dazu unter Host die IP oder den Namen (hier "dbox2") und den Port eintragen.

''Ganz wichtig:'' Unter system32\drivers\etc\hosts die Zeile "192.168.0.5 dbox2" einfügen. Vergißt man das, funktioniert es je nach Netzwerkkonfiguration nicht!

Ein Windows Rechner kann aber auch empfangen. Am einfachsten esound.zip runterladen und im DOS-Fenster mit
esd.exe -tcp -port 16001 -public
starten.

=Linux=

Einen Linux PC bewegt man so zum Senden:

==MPlayer==

sudo apt-get install mplayer
export ESPEAKER=192.168.0.5:16001 && gmplayer

bei Preferences Audio ''esd'' wählen

==Player auf xine Basis==

hier muß noch ein esd plugin geladen werden

sudo apt-get install libxine1-gnome

==amarok==

export ESPEAKER=192.168.0.5:16001 && amarokapp

bei Audio Ausgabe ''esd'' wählen

==KMPlayer==

sudo apt-get install kmplayer

export ESPEAKER=192.168.0.5:16001 && kmplayer

bei KMPlayer einrichten Ausgabe auf ''esd'' stellen

==kaffeine==

sudo apt-get install kaffeine

export ESPEAKER=192.168.0.5:16001 && kaffeine

bei xine-Parameter ''esd'' wählen

'''Bitte beachten,'''
''die Player benötigen alle libxine1-gnome.''

Wer Lust hat, kann ja bitte noch weitere Player testen.

liab

=Weblinks=
*esd Winamp Plugin http://www.linuxfan.dk/download/readme-ESD.txt
*Winamp-Player http://www.winamp.com/

Dbox2 Entwicklungsumgebung

2008-07-07T07:47:21Z

Rhabarber1848:

[[Category:Register]]
[[Category:Development]]
[[Category:CDK]]
{{Development_sidebar}}

__TOC__
{{Review}}
=Allgemeines=
Newmake ist eine Überarbeitung des alten "[[Make|make]]" Prozesses, inzwischen auch als [[Image erstellen|Oldmake]] bezeichnet, und wurde durch Barf ins Leben gerufen.
Neben einer deutlich strukturierteren Basis, bietet es unter anderem auch den Vorteil, dass es auch ohne ohne großes Verständnis für den Buildprozess gelingen kann, [[Images|Flashimages]] und [[yadd|YADDs]] unter [[Linux|Linux]] zu erstellen.
Basierend auf Newmake gibt es inzwischen auch eine auf Scripts basierende Quasi-Frontendlösung, mit der sich [[Images|Flashimages]] oder [[yadd|YADDs]] benutzerdefiniert erstellen lassen, das sogenannte [[yBuild]]. 
Dieser Artikel basiert zum größtem Teil auf die deutsche Version von [http://bengt-martensson.de/dbox2/ Barfs Newmake-Dokumentation], die er uns freundlicheweise zur Verfügung gestellt hat.
Eine detaillierte Beschreibung (auch der [[Make|make]] targets) unter anderem auch in englischer Sprache befindet sich auf [http://bengt-martensson.de/dbox2/ Barf's Homepage]. 

Dieser Artikel behandelt Newmake aus Sicht des Benutzers (nicht Entwickler). Es behandelt die [[Image]]- u. [[yadd|YADD]]-Herstellung sowie einfache Beipiele für Benutzeranpassungen ("[[Customization]]"). 

==Zur Geschichte==
Vor einigen Jahren war die Imageherstellung für die [[Tuxbox|Tuxbox]] so etwas wie [[Wikipedia:Schwarze Kunst|"Schwarze Kunst"]].
Die Makefile-Unterstützung war, insbesondere für andere [[Images]] als [[cramfs]]-[[Images]], ziehmlich lückenhaft. Die [[CVS]] Werkzeuge waren schlecht, oder unvollständig. Noch schlimmer, einige Teile wurden absichtlich geheim gehalten. Vorallem das Werkzeug, jetzt als [[mkflfs]] bekannt, welches inzwischen aber im [[CVS|CVS]]-Verzeichnis ''.../hostapps/[[Mkflfs|mkflfs]]'' zu finden ist, wurde zurückgehalten.

Laut eines Forumsbeitrags aus dieser Zeit, waren die meisten Entwickler nicht in der Lage, eigene [[Images]] herzustellen. Die "Gilde der Imagehersteller" wurde geboren. Aus dieser Zeit dürften die "[[AlexW-Images]]" ein Begriff sein.
Hauptsächlich bestanden diese aus reinen [[CVS|CVS]]-Sources mit einigen mehr-oder-weniger geheim gehaltenen "Fixes", (vermutlich) notwendig für das Herstellen eines funktionierenden [[Images]] aus dem [[CVS|CVS]]-Quellcode.
 
 
Im August 2003, wurde es für das [[DBox2 Software Projekt|GNU DBox2 Software-Projekt]] in zunehmendem Maße peinlich, [[mkflfs]] geheim zu halten und der Quellcode für [[mkflfs]] wurde ins [[CVS]] eingecheckt. Auch die Funktionalität der [[Makefiles]] wurde stufenweise verbessert. Noch war viel zu wünschen übrig: Funktionalität, Pflegbarkeit, gesundes [[Software|Software]]-Design... 
Ein [[Image]] aus reinen [[CVS|CVS]]-Dateien zu bauen, war nicht wirklich möglich.
 
 
2004 wurde das [[YADI]] ("'''Y'''et '''A'''nother '''D'''Box '''I'''mage") Projekt geboren. 
Sein Ziel war es, das "Imagebauen" zu automatisieren und zu vereinfachen. Zu diesem Zweck wurden eine Anzahl von [[Wikipedia:Skripte|Scripten]] und [[Wikipedia:Patches|Patches]] gesammelt und/oder geschrieben. Zusätzlich wurden flashfertige [[Images]] zur Verfügung gestellt.
 
 
[[YADI]] war ein grosser Erfolg. Das Ziel wurde erreicht. [[Images]] wurden zur Verfügung gestellt, die (fast) vollständig auf freier [[Software|Software]] basierten, sowohl inhaltlich als auch bezüglich der benötigten Werkzeuge, in einer Weise, die für den Benutzer durchaus nachvollziehbar war.
 
Mit dem [[YADI]]-[[Skript|Skript]] war das automatische Imagebuilden zwar möglich, jedoch statt grundlegende Schwächen im [[CDK|CDK]]-Imagebau-Prozeß zu beseitigen, stellte man [[Skripte]] zum Imagebauen zur Verfügung. Es wurde kein übliches Buildsystem zur Verfügung gestellt, wie dies beispielsweise von [[Make]], oder ein neuerer Nachfolger wie [[Ant]],[[Cmake]] oder [[Maven]] könnten. 
Newmake, verfügbar als alternativer [[Branch]] im [[CVS|CVS]], versucht diese Schwächen zu beseitigen. 
 
Ein spezieller Dank an jedem, der Bugreports und Feedback geliefert hat. Insbesonderes gilt dies für dietmarw, der Newmake benutzt, um die [[images|dietmarW-Images]] zu erzeugen.

=Ziel=
Das Ziel des vorliegenden Artikels ist es, dem Leser grundlegendes Know-How zu vermitteln. Es ist nicht das Ziel, eine idiotensichere Schritt-für-Schritt Anweisung bereitzustellen, wie das bei sogenannten HOWTO's der Fall wäre. 
Kenntnisse im Umgang mit [[Wikipedia:Skriptsprache|Shellskripten]] wird für viele Teile, insbesondere für das [[Customization]]-Kapitel, aber nicht für [[Image]]/[[yadd|YADD]]-Herstellung in seiner einfachsten Art und Weise vorausgesetzt.
 
 
Der vorliegende Artikel versucht nicht die innere Funktion der [[Makefiles]] und des Makeprozesses zu beschreiben. Hierfür wird der Leser auf diverse Quellen, und zu relevanten Threads im [[CDK]]-Forum des [[Tuxbox|Tuxbox]]-Forums hingewiesen. Alle Optionen für ''configure'' werden auch nicht beschrieben, nur die Allgemeinsten und Wichtigsten.

= Wie schwierig ist es? =
Die Antwort könnte lauten: ''Es ist so schwerig wie man diesen Artikel zu lesen versteht.'' Für den Leser, der ohne Probleme den Inhalt dieses Artikels versteht, sollte es kein Probleme sein. Leser, für die das Meiste nur Kauderwelsch ist, sollten vielleicht besser bei fertigen [[Images|Images]] bleiben.

= [[Images|Images]] und [[Yadd|YADD]]'s bauen=
== Targets ==
Es gibt neben zahlreichen untergeordneten Zielen (Targets), zwei hauptrangige Targets. Diese wären entweder
*[[YADD]]
oder
*[[Image]].
Ein [[YADD]] besteht aus einigen Dateien, die die DBox anstatt aus dem [[Flash]] ü[[BER|ber]] den [[TFTP]]-Service lädt, sowie ein [[Filesystem|Filesystem]], das ü[[BER|ber]] einen [[NFS-Server]] der dBox zur Verfügung gestellt wird.
 
Diese Betriebsart hat insbesondere während der Softwareentwicklung oder beim Erlernen des Systems viele Vorteile. 
Der Name "[[YADD]]" bedeutet übrigens "'''Y'''et '''A'''nother '''D'''Box '''D'''istribution" ("noch eine dBox Verteilung").

=== Erste Schritte und Überlegungen ===
Eine Empfehlung für den angehenden "[[Image|Image]]/[[Yadd|YADD]]-Lehrling" wäre: 
Baue zuerst ein [[YADD]] mit Deiner Lieblings-[[GUI]], und lerne damit umzugehen. 
Nächster Schritt wäre dann, ein [[jffs2]]-[[Image|Image]] mit der Lieblings-[[GUI]] zu erstellen.

Meistens möchte man die folgenden Schritte kombinieren und/oder automatisieren.
 
In diesem Artikel bezeichnet "[[GUI]]" entweder
*[[Neutrino]] oder
*[[Enigma]]
*[[Lcars]]
*[[Radiobox]].
 
Das "[[Filesystem]]" im Kontext eines kompletten [[Images]] bezeichnet das [[Dateisystem]], in dem das root-Verzeichnis liegt. Diese kann ein
*[[cramfs]] (ein komprimiertes, Read-only [[Filesystem|filesystem]] für embedded Systeme) sein,
*[[squashfs]] (ein weiterd komprimiertes read-only-[[Dateisystem|Dateisystem]], was leistungsfähiger als [[cramfs]] betrachtet wird)
oder
*[[jffs2]] (ein "journalled" Read-Write-[[Filesystem|Filesystem]]).
Ein "[[Cramfs|cramfs]] Komplett-[[Image|Image]]" besteht aus einem Root-[[Dateisystem|Dateisystem]] mit dem [[cramfs]] [[Dateisystem|Dateisystem]] und einem kleineren [[jffs2]]-[[Filesystem|Filesystem]], das nach '''/var''' gemounted wird.
 
Analog gilt dies auch für "'''[[Squashfs|squashfs]] Komplett-[[Images|Images]]'''", während ein "'''[[Jffs2|jffs2]] Komplett-[[Image|Image]]'''" kein separates ''/var-[[Dateisystem|Dateisystem]]'' enthält, weil [[Jffs2|jffs2]] an sich beschreibbar (var) ist.
 
Zusätzlich enthalten die Komplett-[[Images|Images]] eine weitere [[Partition|Partition]], die den [[u-boot]]-[[Bootloader]] enthalten. Diese [[Partition|Partition]] ist zwischen dBoxen mit einen und zwei Flashchips unterschiedlich. Dieses wird durch "'''1x'''" und "'''2x'''" angezeigt. Ein komplettes [[Image|Image]] würde demnach so benannt werden:

[neutrino, enigma]-[cramfs, squashfs, jffs2].img[1, 2]x,
z.B. als fertiges [[Image|Image]]:
[[Neutrino|neutrino]]-[[Jffs2|jffs2]].img2x.

== Buildsystem Voraussetzungen ==
Die Voraussetzungen auf dem Buildhost können in etwa so zusammengefasst werden:
 
Ein modernes [[Unix|Unix]]/[[Linux|Linux]] System mit ca. 2 GB freiem Speicherplatz. Epfehlenswert ist es aber mehr Speicherplatz einzuplanen, da beispielsweise bei Verwendung von [[ccache]] einiges an Daten zwischengelagert wird und je öfter man kompiliert, es dann doch eng werden könnte.

Das [[DBox2 Software Projekt|Tuxbox Projekt]] hat keine favorisierte Buildumgebung. Fragen wie "geht es mit Redhat x.y?" lassen sich nicht genau beantworten. Der Grund hierfür ist, dass niemand sich wirklich dafür interessiert, die Eigenschaften der bestimmten Distributionen zu erkunden. Gewisse Anforderungen werden dagegen für Versionen der Werkzeuge, wie [[WP:autoconf|autoconf]], [[WP:automake|automake]], [[make]] usw. formuliert. Die meisten davon sind in den gängigsten Distributionen bereits enthalten bzw. können nachinstalliert werden. Die momentan erfordelichen Toolversionen sind in folgendender Tabelle zusammengefasst:
 
{{Vorlage:GNU_Tools}}
 
Der Buildprozess überprüft zu Beginn automatisch einige dieser Anforderungen. Wenn eines dieser [[Tools|Tools]] fehlt, oder wenn die Version zu alt zu sein scheint, ist es in der Regel einfacher, die erforderliche Version nachträglich zu installieren, entweder als kompiliertes Paket, z.B. im [[rpm]]-Format vom jeweiligem Distributor, oder sich direkt die Quellen zu besorgen, zu kompilieren und zu installieren, als zu versuchen oder herauszufinden, ob die oben genannten Anforderungen wirklich notwendig sind.
 
'''''Hinweis''': 
In anderen [[Anleitungen|Anleitungen]] zum Buildvorgang wird gefordert, dass [[Tools|Tools]] wie [[fakeroot]],
[[mksquashfs]], [[mkcramfs]], [[mkjffs2fs]] (oder [[mkfs.jffs2]]), vielleicht auch [[mklibs]]
oder [[ccache]], auf Ihrem System installiert sein müssen. In dieser Umgebung ist dies nicht
erfordelich, da einige entweder überhaupt nicht benötigt werden bzw. die [[Installation|Installation]] im
Makeprozess selbst vorgenommen wird!
 ''
Builden auf einem [[Unix|Unix]]-non-[[Linux|Linux]] System sollte vermutlich auch möglich sein, so weit die erforderlichen [[GNU]] Werkzeuge vorhanden sind. Mit einem anderen [[make]] als [[GNU]] wird es fast sicher nicht funktionieren, da die [[GNU|GNU]]-[[Erweiterungen|Erweiterungen]] uneingeschränkt verwendet werden.
 
Es wird daher davon abgeraten eine Umbegebung z.B. mit [[Cygwin]] aufzubauen, da es höchstwahrscheinlich nicht funktionieren wird. In dieser Richtung wurde zwar Einiges für den Makeprozess eingebaut, jedoch dürfte der gegenwärtige Entwicklungsstand nicht den gegenwärtigen Anforderungen entsprechen, um aktuell auch damit arbeiten zu können.
 
Empfehlenswert ist allerdings eine Buildumgebung mittels [[VMWare]] aufzubauen. Hierfür gibt es auch eine "konfektionierte" Lösung von yiogol, der hierfür ein passendes [[VMWare-Image]] erstellt hat, dass im Prinzip alle notwendigen Zutaten enthält.

== Auschecken ==
Die [[Tuxbox|Tuxbox]] Quellen werden durch den [[Tuxbox|Tuxbox]] [[CVS-Server]] bereitgestellt. 
Regelmäßige Quellreleases sind niemals gemacht worden, und sind auch nicht für die Zukünft geplant. Für unsere Zwecke werden die Quellen anonym "ausgecheckt", was bedeutet, dass diese auf die eigene Festplatte kopiert werden, indem man zuerst auf einer (lokalen) Festplatte mit "ordentlich" freiem Platz ein leeres Verzeichnis erstellt, z.B. ''/[[Tuxbox|tuxbox]]-[[CVS|cvs]]'' und in diesen Ordner wechselt, und diesen Befehl ausführt.

[[CVS|cvs]] -d anoncvs@[[CVS|cvs]].[[Tuxbox|tuxbox]].org:/[[CVS|cvs]]/[[Tuxbox|tuxbox]] -z3 co -f -r newmake -P .

Dieser Befehl checkt die Newmake Files aus. In Fällen, in denen keine Newmake Version vorhanden ist, wird die HEAD-Version ausgecheckt.
 
'''Hinweis:'''
''Im HEAD gibt es zwei Files:''
*[[CDK|cdk]]/root/etc/init.d/rcS
''und''
*[[CDK|cdk]]/root/etc/init.d/rcS.insmod
''Im [[Newmake]] werden diese nicht benötigt da sie mittels''
[[CDK|cdk]]/root/etc/init.d/rcS.m4
''erzeugt werden.''
''Um auf der sicheren Seite zu sein, ist es ratsam, diese beiden zu löschen''.
 
Nachdem die Daten ausgecheckt wurden, könnte kann man jetzt einige Patches auf die Quellen anwenden. 
Wenn man aber zum ersten Mal kompiliert, ist es ratsam, vorerst keine Patches anzuwenden. Wenn Probleme auftreten, ist es viel einfacher (technisch sowohl als auch für jeden selbst) jemand zu helfen, der die "unveränderten [[CVS|CVS]] Quellen" verwendet.

== Konfiguration ==
Jetzt müssen einge Zwischenschritte erledigt werden, damit der Buildprozess auch erkennt, was und vorallem wie er es machen soll.
 
Man wechselt nun in das [[CDK|CDK]]-Unterverzeichnis
cd [[CDK|cdk]]
und gibt diesen Befehl ein (ohne Argumente).
./autogen.sh

Dieser erzeugt unter anderem ein [[Shellskript]] namens '''configure'''.
 
Wird ''autogen.sh'' ausgeführt, wird dabei eine Anzahl von Optionen übergeben, um das System für das Builden eines [[Images|Images]], [[Yadd|YADD]] oder aller anderen gewünschten Ziele entsprechend den Benutzerwünschen vorzubereiten.

=== Optionen ===
{{Newmake_Build_Optionen}}

Für uns sind vorerst nur wenige Optionen interessant. Die Standardvorgaben reichen vorerst völlig aus. 
Eine typische Anwendung (Konfiguration), der mit z.B. den Pfadnamen oben kompatibel wäre, könnte so eingestellt werden:

./configure --with-cvsdir="/[[Tuxbox|tuxbox]]-[[CVS|cvs]]" --prefix="/[[Dbox2|dbox2]]" --enable-maintainer-mode

*''--with-cvsdir''
sagt wo die Quellen zu finden sind, (darin sollte auch ein Unterverzeichnis ''.../[[CDK|cdk]]'' besitzen). In der Regel ist dies das Verzeichnis in das die Quelldaten gerade ausgecheckt wurden, während
*''--prefix''
bedeutet, dass eine Anzahl von wichtigen Verzeichnissen als Unterverzeichnisse des besagten Verzeichnisses erstellt werden sollen. Ihre Position kann durch andere Konfigurationsoptionen weiter beeinflußt werden.
*''--enable-maintainer-mode''
ist, auch für Nichtmaintainers praktisch, da er den hergestellten [[Makefiles|Makefiles]] ermöglicht, sich automatisch neu zu erzeugen, sobald die Notwendigkeit entsteht, zum Beispiel nach einem [[Software|Software]]-[[Update|Update]].

Es gibt sicher noch andere nützliche Optionen. Einige werden später noch besprochen.

=== Fehlerausgaben ===
Überprüfe bitte die Ausgaben von ''autogen'' auf Fehler ("Error") und Warnungen. 
Hierbei können diese Warnungen ignoriert werden:

/usr/local/share/aclocal/pkg.m4:5: warning: underquoted definition of PKG_CHECK_MODULES from autogen.sh

ebenso folgende Warnungen von configure:

...
configure: WARNING: using [[Tuxbox|tuxbox]] [[Mklibs|mklibs]]
checking for mkcramfs... no
configure: WARNING: using [[Tuxbox|tuxbox]] [[Cramfs|cramfs]]
checking for mkjffs2... no
checking for [[Mkfs.jffs2|mkfs.jffs2]]... no
configure: WARNING: using [[Tuxbox|tuxbox]] [[Mkfs.jffs2|mkfs.jffs2]]
checking for mksquashfs... no
configure: WARNING: using [[Tuxbox|tuxbox]] [[Squashfs|squashfs]]
...

Dies sind nur Hinweise darauf, dass hier projekteigene Versionen einiger [[Tools|Tools]] verwendet werden.

'''''Beachte!'''
Wenn man diesen Artikel mit ähnlichen Beschreibungen aus vergangenen Zeiten
vergleicht, bemerkt man, dass die Option '''--with-targetruleset=[standard,flash]''' nicht mehr
vorhanden ist. Bisher war es notwendig, bei der Konfiguration sich entweder auf Builds von [[YADDs]]
oder [[Images]] einzuschränken. Bei Newmake ist dieses nicht mehr notwendig.
 ''
 
[[Bild:Stop hand.png]]
<div style="margin: 0; margin-top:10px; margin-right:0px; border: 3px solid #FF0000; padding: 0px 10px 1px 10px; background-color:#DEB0B0; align:right; ">
'''
Versuche niemals, als root zu bauen!'''
</div>

== Kompilieren ==
Die high-level [[Make|make]] Targets, die für das Builden von Komplett-[[Images|Images]] relevant sind, lauten:
*<pre><nowiki>flash-</nowiki>[neutrino, enigma, all]</nowiki></pre>
*<pre><nowiki>flash-</nowiki>[cramfs, squashfs, jffs2, all]</nowiki></pre>
*<pre><nowiki></nowiki>[1x, 2x, alle]</nowiki></pre>
Für [[Yadd|YADD]]-Builds, sind diese:
*<pre><nowiki>yadd-</nowiki>[neutrino, enigma, all]</nowiki></pre>
'''Beispiele:'''

[[Make|make]] [[Flash|flash]]-[[Neutrino|neutrino]]-[[Jffs2|jffs2]]-all

erzeugt flashbare [[Jffs2|jffs2]]-only [[Images|Images]] mit [[Neutrino|Neutrino]], für 1x-Boxen und für 2x-Boxen (Dateinamen ''[[Neutrino|neutrino]]-[[Jffs2|jffs2]].img1x'' und ''[[Neutrino|neutrino]]-[[Jffs2|jffs2]].img2x'').

'''der Befehl:'''

[[Make|make]] [[Yadd|yadd]]-[[Enigma|enigma]]

erzeugt ein [[Yadd|YADD]], das [[Enigma|Enigma]] enthält.

=== Zeitaufwand ===
Das Kompilieren kann bei so einem Projekt und je nach Konfiguration und Rechnerleistung schon einige Zeit in Anspruch nehmen. 
Auf einem Athlon XP 1800 dauert ein Befehl wie '''[[Make|make]] [[Yadd|yadd]]-[[Neutrino|neutrino]]''' mit leeren Verzeichnissen etwa 1 und 1,5 Stunden.

==== Verwendung von [[Ccache|ccache]] ====
Um den Vorgang insbesondere bei wiederholten Kompilieren und besonders auf langsameren Rechnern zu beschleunigen, steht die Option
* --enable-[[Ccache|ccache]]
zur Verfügung, welche man mit in die Konfiguration einbinden kann. Erfahrungsgemäß wird so durchschnittlich ca. 1-2 Drittel der Zeit eingespart.

Durch die Option '''--enable-[[Ccache|ccache]]''' wird erreicht, sollte das Tool bereits in deiner Distribution installiert sein, dass [[ccache]] automatisch erkannt wird und in das [[Tuxbox|Tuxbox]]-[[CDK|CDK]] eingebunden wird. Ist es nicht installiert, wird dies auch von configure angezeigt:
...
----------------------------------------
[[Ccache|ccache]] support: no
[[Ccache|ccache]] installdir:
[[Ccache|ccache]] is not installed please run [[Make|make]] [[Ccache|ccache]] or install it and configure again
----------------------------------------
...
Dann sollte man das Tool nachinstallieren oder mit dem Target
[[Make|make]] [[Ccache|ccache]]
in das [[CDK|CDK]] einbauen und configure wiederholen.

'''Hinweis'''
 
''[[Ccache]] macht sich erst bemerkbar, nachdem der Buildvorgang mindestens einmal durchgelaufen ist!''

Die Option ''--enable-[[Ccache|ccache]]'' ist normalerweise völlig ausreichend. Es stehen aber noch weitere untergeordnete Sub-Optionen zur Verfügung, die in Ausnahmefällen verwendet werden können:
*--with-ccachedir=DIR
Diese Option kann man verwenden, wenn man [[ccache]] beispielsweise nur als Binary abgelegt hat und den Pfad dazu bestimmen möchte.
 
'''Hinweis'''
 
''Die Option '''--with-ccachedir''' bewirkt auch das die mit '''[[Make|make]] [[Ccache|ccache]]''' installierte Version im [[CDK|CDK]] und/oder auch die evtl. im System installierte Version ignoriert wird!''

*--with-maxcachesize=SIZE maximal
Hier gibt man an, wieviel Speicher [[ccache]] verwenden darf in GB z.B: für 2GB
--with-maxcachesize=2

*--with-maxcachefiles=COUNT
Hier kann man angeben, wieviele Dateien [[ccache]] cachen darf.
--with-maxcachefiles=20000
Hier würden es logischeweise 20000 sein.

Die Wirksamkeit von [[ccache]] lässt sich mit dem Befehl
[[Ccache|ccache]] -s
prüfen. Als Ergebnis werden einige Statistiken ü[[BER|ber]] das Cache-Verhalten von [[Ccache|ccache]] ausgegeben:
cache directory /home/<USER>/.[[Ccache|ccache]]
cache hit 4
cache miss 191
called for [[Link|link]] 17
multiple source files 4
compile failed 17
preprocessor error 2
not a C/C++ file 5
autoconf compile/[[Link|link]] 178
no input file 15
files in cache 382
cache size 7.1 Mbytes
max cache size 976.6 Mbytes

'''Tipp'''
 
Um die benötigte Zeit genau zu ermitteln, kann man den Befehl '''time''' einbauen.
time [[Make|make]] [[Yadd|yadd]]-[[Neutrino|neutrino]]
Am Ende des Bauvorganges werden damit die entsprechenden Zeitinformationen ausgegeben.

=== Beispiele ===
Hier einige Beispiele mit denen man [[Images|Images]], Yadds oder einzelne Targets bauen kann. Diese Beispiele sollten so wie sie hier vorgegeben sind ohne Veränderung auf jedem [[Linux|Linux]]-System mit den bisher beschriebenen Voraussetzungen laufen. Da die Systeme trotzdem [[Unterschiede|Unterschiede]] aufweisen können, kann man das aber nicht garantieren.

==== [[Neutrino|neutrino]]-[[Jffs2|jffs2]]-[[Image|Image]] ====
#! /bin/bash
# beispiel.sh
# Diese Script baut [[Neutrino|neutrino]]-[[Jffs2|jffs2]] [[Images|Images]], jeweils 1x und 2x
#----------------------------------------------
USERDIR=/home/$(whoami)
#----------------------------------------------
LOGODIR=$USERDIR/Logos
CP=$USERDIR/[[Tuxbox|tuxbox]]-[[CVS|cvs]]
DB=$USERDIR/[[Dbox2|dbox2]]
ARCHIVEDIR=$USERDIR/Archive
export CVS_RSH=[[SSH|ssh]]
#-----------------------------------------------
cd "$CP"
[[CVS|cvs]] -d anoncvs@[[CVS|cvs]].[[Tuxbox|tuxbox]].org:/[[CVS|cvs]]/[[Tuxbox|tuxbox]] -z3 co -f -r newmake -P .
cd [[CDK|cdk]]
/bin/ln -sf $ARCHIVEDIR/ Archive
./autogen.sh
./configure --prefix="$DB" --with-cvsdir="$CP" --enable-flashrules --enable-[[Ccache|ccache]] --with-[[CheckImage|checkImage]]=rename --with-logosdir="$LOGODIR"
[[Make|make]] [[Flash|flash]]-[[Neutrino|neutrino]]-[[Jffs2|jffs2]]-all

==== [[Neutrino|Neutrino]] [[Yadd|YADD]] ====
#! /bin/bash
# beispiel.sh
# Diese Script baut ein [[Neutrino|Neutrino]] [[Yadd|Yadd]]
#----------------------------------------------
USERDIR=/home/$(whoami)
#----------------------------------------------
LOGODIR=/Logos
CP=$USERDIR/[[Tuxbox|tuxbox]]-[[CVS|cvs]]
DB=$USERDIR/[[Dbox2|dbox2]]
ARCHIVEDIR=$USERDIR/Archive
export CVS_RSH=[[SSH|ssh]]
#-----------------------------------------------
cd "$CP"
[[CVS|cvs]] -d anoncvs@[[CVS|cvs]].[[Tuxbox|tuxbox]].org:/[[CVS|cvs]]/[[Tuxbox|tuxbox]] -z3 co -f -r newmake -P .
cd [[CDK|cdk]]
/bin/ln -sf $ARCHIVEDIR/ Archive
./autogen.sh
./configure --prefix="$DB" --with-cvsdir="$CP" --with-logosdir="$LOGODIR" --enable-[[Ccache|ccache]]
[[Make|make]] [[Yadd|yadd]]-[[Neutrino|neutrino]]

= Was kommt dann...? =
== Booten von [[Yadd|YADD]] ==
Wenn ein [[Yadd|YADD]] frisch erzeugt wurde, kann damit auch die Box booten. Näheres dazu auch im Artikel [[CDK booten]]. 
Newmake hält auch ein [[Make|Make]]-Target für den serversupport bereit.
[[Make|make]] serversupport
Dieses erzeugt einige Konfigurationsdateien für den [[Server|Server]] der das [[Yadd|YADD]]-Build nahtlos an das [[Server|Server]]-Setup anknüpft.

== [[Flashen|Flashen]] des [[Images|Images]] ==
Wenn ein [[Image|Image]] gebaut wurde, ist der logische nächste Schritt das Einspielen des [[Images|Images]] in den [[Flash|Flash]] der Box. Hierfür ist entweder, das interaktive [[Flashen|Flashen]] innerhalb der [[GUI|GUI]] mit den [[Installation:Neutrino|Expertenfunktionen]] zu benutzen, oder der ''dboxflasher'' zu verwenden. Der ''dboxflasher'' wird durch das [[Make|Make]]-Target
[[Make|make]] serversupport
erzeugt. 
Siehe auch [[Installation]].

== Inkrementelle Builds ==
Im allgemeinen ist man nicht an einem einmaligen Build der [[Software|Software]] interessiert. Verbesserungen an den Quellen werden in das [[CVS|CVS]] täglich eingecheckt. Oft möchte man die [[Software|Software]] durch eigene Programmierung verbessern oder Patches anwenden. Es ist dabei wünschenswert, dass genau nur die Teile neu erzeugt wird, die neu erzeugt werden sollen, nicht mehr und nicht weniger. Newmake geht einen direkten Weg in diese Richtung.
 
Um ein Target neu zu bauen, benutze den Befehl
[[Make|make]] [target]
und [[Make|make]] wird es, falls notwendig, neu erzeugen.

Es kann auch passieren, dass [[Make|make]] zusätzlich einen vollständig anderen Bestandteil neu erzeugt! Dies ist dann der Fall, wenn das jeweilige Target von anderen Teilen abhängt, die sich geändert haben.
 
In einige Situationen kann es auch wünschenswert sein, ein erneutes Bauen einer Komponente zu erzwingen. Einige Komponenten werden in einem Distributionsfile zum Verzeichnis [[CDK|cdk]]/Archive heruntergeladen, und wenn das Build stattfindet, ausgepackt, evtl. Patches angewendet, konfiguriert, kompiliert, installiert und die Quellen dann wieder gelöscht. 
Alles findet automatisch statt. Die [[Installation|Installation]] eines bestimmten Pakets wird durch das Anlegen einer Markerdatei im Verzeichnis ''[[CDK|cdk]]/.deps'' vermerkt.
 
Falls gewünscht, kann solch eine Markiererdatei entfernt werden, um das Neuerzeugen der entsprechenden Komponetne zu erzwingen. Es gibt hierfür auch entsprechende Targets, die "''Cleaning Targets''".

== Cleaning targets ==
Es gibt mehrere unterschiedliche Aufräum-Targets:
 
[[Make|make]] distclean
Das drastischste Reinigungs-Target, (fast) alles löschend, was nicht vom [[CVS|CVS]] ausgecheckt wurde.
Dieses ist eher selten notwendig.
 
[[Make|make]] mostlyclean
Ein intelligenteres Target ist ''mostlyclean''. Es säubert die Verzeichnisse, die Tuxboxquellen enthalten, lässt aber die Kompilationsumgebung und alle ''Auspacken-kompilieren-installieren-löschen-Komponente'' unberührt.
 
Auch das cdkroot Verzeichnis, (d.h. die [[Yadd|Yadd]]-[[Installation|Installation]]), sowie die [[Tftp|TFTP]]-Files ([[Kernel|Kernel]] und [[U-boot|u-boot]]) werden nicht angefasst.
 
[[Make|make]] depsclean
Löscht alle Markerdateien im /[[CDK|cdk]]/.deps Verzeichnis und zwingt so zum Neukompliieren aller [[Auspacken-kompilieren-installieren-löschen-Komponenten]].
 
Dies ist selten sinnvoll: Diese hängen von ihren Quellen und vielleicht von einem Patchfile ab, und der Makefile kennt diese Abhängigkeiten.
 
[[Make|make]] clean
Kombiniert ''mostlyclean'', ''depsclean'', und ''[[Flash|flash]]-clean''. Versucht auch soviel wie möglich im cdkroot-Verzeichnis zu löschen, das nicht während des Bootstrapdurchlaufes installiert war. So wird
versucht, die Umgebung in einem Zustand zu bringen, wo die Buildumgebung gerade kompiliert worden ist, z.B. mit ''[[Make|make]] bootstrap''.
 
[[Make|make]] [[Flash|flash]]-semiclean
Dieses Target löscht die meisten Verzeichnisse in $(flashprefix), mit Ausnahme der Boot-Partitionen und der Kernelbauverzeichnisse. 
Dieses ist oft sinnvoll, da diese Bestandteile verhältnismässig sich selten ändern.
 
[[Make|make]] [[Flash|flash]]-mostlyclean
Zusätzlich zum ''[[Flash|flash]]-semiclean'' löscht dieses Target auch Bootfiles und die Kernbauverzeichnisse. Vollimages werden unberührt gelassen.
 
[[Make|make]] [[Flash|flash]]-clean
Dieses Target löscht Alles in $(flashprefix).
 
Einige Quellverzeichnisse können mit einem Befehl wie
[[Make|make]] -C /[[Tuxbox|tuxbox]]-[[CVS|cvs]]/apps/[[Tuxbox|tuxbox]]/[[Neutrino|neutrino]] clean
gesäubert werden.

== Aktualisierung des [[CVS|CVS]]-Quellcodes ==
Um die Quellen mit neueren Checkins zu aktualisieren, verwende diesen Befehl für das toplevel [[CVS|CVS]] Verzeichnis (oder von einem anderen Verzeichnis, wenn Ihr wisst, was ihr tut;-). Mögliche Fehler werden in das logfile [[CVS|cvs]].log geschrieben.

[[CVS|cvs]] up -f -r Newmake -dP > [[CVS|cvs]].log 2>&1

'''Tipp'''
 
Um mit dem [[CVS|CVS]] arbeiten zu können nimmt man für gewöhnlich die Konsole für Eingaben. Es gibt aber auch verschiedene Frontendwerkzeuge wie z.B. [http://www.crossvc.com CrossVC] oder [http://cervisia.kde.org/ Cervisia] um nur einige zu nennen, die einen recht komfortablen Umgang mit den [[CVS|CVS]]-Daten ermöglichen. [[Bild:Crossvc.jpg|CrossVC als CVS Frontendlösung]] [[Bild:Cervisia.jpg|Cervisia als CVS Frontendlösung]] 
Auch einige [[IDE|IDE]]'s wie z.B. [[WP:Anjuta|Anjuta]] [[Bild:anjuta.jpg|Anjuta als IDE mit CVS-Anbindung]] bieten solche [[CVS|CVS]]-Schnittstellen an.

== [[Customization|Customization]] ==
Bisher lief immer alles darauf hinaus [[Images|Images]] oder Yadds zu bauen, die aus unveränderten [[CVS|CVS]]-Quellen gebaut wurden. 
[[Images|Images]] und die Yadds können aber auch angepasst ("customized") werden, ohne die [[Makefiles|Makefiles]] zu ändern.
 
Hier gibt es verschiedene Möglichkeiten.

=== Konfigurationsoptionen ===
hier einige nützliche Optionen: 
Hiermit kann ein Verzeichniss angegeben werden, welches die [[Ucodes|Ucodes]] enthält, die im [[Image|Image]] enthalten sein sollen.
--with-ucodesdir=[DIR]
'''Hinweis:''' 
Ein [[Image|Image]], dass [[Ucodes|ucodes]] enthält, darf
nicht verbreitet werden! 
 
 
Mit der Option
--with-logosdir=[DIR]
kann ein Verzeichniss angegeben werden, das boot-logos (logo-[[LCD|lcd]] und logo-fb) enthält, die im [[Image|Image]] enthalten sein sollen.
 
 
Diese Option
--with-defaultlocale=[LOCALE]
sorgt dafür, dass die gewünschte Sprache schon beim bauen eingestellt wird.

=== Ändern der Partitionierung ===
Die Rootpartitionsgröße für [[Cramfs|cramfs]] und [[Squashfs|squashfs]] [[Images|Images]] kann mit der Configure-Option
--with-rootpartitionsize=[SIZE]
angegeben werden.
 
Die Größe der var-[[Partition|Partition]] wird automatisch berechnet, wobei man den restlichen Flashspeicher nutzt, der nicht durch die anderen Partitionen benutzt wird. Die Standardgröße ist 0x660000.
Diese Zahl sollte eine Multiple der Erasesize, momentan 0x20000 sein. Dies wird allerdings ignoriert falls es wie bei der [[Jffs2|jffs2]]-Imageerstellung unsinnig wäre.

=== Variablen ===
==== Pfade ====
Es sind noch weitere Benutzeranpassungen möglich. Dafür ist es aber notwendig, etwas [[Wissen|Wissen]] ü[[BER|ber]] die innere Funktionsweise der [[Makefiles|Makefiles]] zu haben. 
In der Folge bezeichnet
$(flashprefix)
den Wert der Makefile Variablen '''flashprefix''' (mit Konfiguration wie oben '''/[[Dbox2|dbox2]]/cdkflash''')
$(targetprefix)
bezeichnet den Wert der Makefile Variablen '''targetprefix''' (mit Konfiguration wie oben '''/[[Dbox2|dbox2]]/cdkroot'''), und
$(buildprefix)
bezeichnet den Wert der Makefile Variablen '''buildprefix''' (mit der Konfiguration oben '''/[[Tuxbox|tuxbox]]-[[CVS|cvs]]/[[CDK|cdk]]''').
 
 
Um z.B. ein '''[[Neutrino|neutrino]]-[[Cramfs|cramfs]].img2x''' zu erzeugen, werden die folgenden Verzeichnisse erstellt: 
*'''$(flashprefix)/root''' (enthält [[Filesystem|Filesystem]]- und [[GUI|GUI]]-unabhängige Bestandteile)
*'''$(flashprefix)/root-[[Cramfs|cramfs]]''' (enthält den [[Kernel|Kernel]], für Root-[[Filesystem|Filesystem]] auf [[Cramfs|cramfs]] konfiguriert, zusammen mit seinen Treibern) und
*'''$(flashprefix)/root-[[Neutrino|neutrino]]''' (enthält die Neutrinoinstallation).
 
Aus diesen drei Verzeichnissen, werden das Rootfilesystemverzeichniss
*'''$(flashprefix)/root-[[Neutrino|neutrino]]-[[Cramfs|cramfs]]''' und das
var-filesystemverzeichnis
*'''$(flashprefix)/var-[[Neutrino|neutrino]]''' gebaut.
 
Hiermit ist es möglich, einen Befehl wie
[[Make|make]] $(flashprefix)/root-[[Neutrino|neutrino]]-[[Jffs2|jffs2]]
bzw. wenn man sich im Verzeichnis ''./[[Tuxbox|tuxbox]]-[[CVS|cvs]]/[[CDK|cdk]]'' befindet, den Befehl
[[Make|make]] root-[[Neutrino|neutrino]]-[[Jffs2|jffs2]]
einzugeben, wobei man bei erster VAriante natürlich '''$(flashprefix)''' selbst durch den realen Pfad ersetzen muss, da '''$(flashprefix)''' nur eine [[Make|make]]-Variable ist, welche in unserem Beispiel den Pfad zu '''./[[Dbox2|dbox2]]/cdkflash''' darstellt. 
Man kann so manuell gewünschten Änderungen an '''$(flashprefix)/root-[[Neutrino|neutrino]]-[[Jffs2|jffs2]]''' vornehmen, und dann, mit dem Befehl
[[Make|make]] [[Flash|flash]]-[[Neutrino|neutrino]]-[[Jffs2|jffs2]]-2x
den Imagebau abschließen, um ein [[Image|Image]] zu erstellen, das diese manuellen Änderungen enthält.
 
Dieses kann zwar für den einmaligen Imagebau sinnvoll sein, jedoch in vielen Fällen dürfte eine automatisierte und systematischere Methode erforderlich sein.

=== [[Customization|Customization]]-Scripte ===
Sofern diese Scripte vorhanden und ausführbar sind, werden innerhalb der wichtigsten Targets diese sogenannten ''[[Customization|Customization]]-Scripte'' automatisch aufgerufen bzw. ausgeführt.
Zum aktivieren der Scripte müssen diese lediglich in ein dafür vorgesehenes Verzeichnis abgelegt werden und ausführbar sein. Dieses Verzeichnis ist standardmäßig der '''*/[[CDK|cdk]]'''-Ordner.
Bei Bedarf kann mit der Option
--with-customizationsdir=[DIR]
ein alternatives Verzeichnis für [[Customization|Customization]]-Scripte festgelegt werden.
 
Auf diese Scripte werden zwei Argumente zur Laufzeit übergeben:
 
Für Imagetargets sind dies
*$(flashprefix)
und
*$(buildprefix)
für Yaddtargets sind diese
*$(targetprefix)
und
*$(buildprefix)
 
 
Die Bezeichnung "Script" ist etwas irreführend, da sie eigentlich wie normale Programme mit zwei Argumenten ausgeführt werden. Anstelle eines [[Shell|Shell]]-Scripts könnte dies z.B. ein kompiliertes C Programme, oder ein [[Perl|Perl]]-Script sein. 
Der Name eines [[Customization|Customization]] Scriptes besteht in der Regel aus dem Namen eines Targetverzeichnisses bzw. einem Target und dem angefügtem *'''-local.sh'''. 

==== Für [[Flash|Flash]]-Targets ====
Der Name der [[Customization|Customization]] Scripte für [[Images|Images]] besteht aus den wie oben benannten Verzeichnissen (in diesem Fall Targets) in ''flashprefix'',
*root
 
dem Namen der jeweilige Benutzeroberfläche, als "[[GUI]]" in Klammern bezeichnet, also
*[[Neutrino|neutrino]]
*[[Enigma|enigma]]
*[[Lcars|lcars]]
*[[Radiobox|radiobox]]
 
"[[FS]]" zeigt an welches [[Filesystem|Filesystem]] gemeint ist.
*[[Cramfs|cramfs]]
*[[Squashfs|squashfs]]
*[[Jffs2|jffs2]]
 
so wäre die Bezeichnung der jeweiligen Scripte wie folgt aufgebaut:
*root-local.sh
*root-[GUI]-local.sh
*root-[GUI]-[FS]-local.sh
*root-[FS]-local.sh
*var-[GUI]-local.sh
 
'''Beispiele:'''
root-local.sh
root-[[Neutrino|neutrino]]-local.sh
root-[[Neutrino|neutrino]]-[[Squashfs|squashfs]]-local.sh
root-[[Squashfs|squashfs]]-local.sh
var-[[Neutrino|neutrino]]-local.sh

==== Für [[Yadd|Yadd]]-Targets ====
Für Yadds ist das Prinzip ähnlich, nur dass es hier quasi nur einen Ordner gibt. Dafür stellvertretend steht dann
*[[Yadd|yadd]]. 
Das "[[GUI]]" in Klammern bezeichnet auch hier die jeweilig betroffene Benutzeroberflche, also
*[[Neutrino|neutrino]]
*[[Enigma|enigma]]
*[[Lcars|lcars]]
*[[Radiobox|radiobox]]
 
so wäre die Bezeichnung der jeweiligen Scripte so aufgebaut.
*[[Yadd|yadd]]-[GUI]-local.sh
'''Beispiel:'''
[[Yadd|yadd]]-[[Neutrino|neutrino]]-local.sh

==== Andere [[Customization|Customization]] Scripte ====
Die bisher benannten [[Customization|Customization]] Scripte für [[Flash|Flash]]- u. [[Yadd|Yadd]]-Targets sind die Gebräuchlichsten. Diese werden allerdings gewissermaßen nur an die der bestehenden Targets angehängt, anders als es bei den anderen, von denen es in Newmake noch jede Menge mehr gibt, bei denen diese als Ersatz der eigentlichen Targets dienen. 
Im Prinzip ginge dies auf so gut wie alle Targets anzuwenden. Möchte man z.B. ein Contrib-Tool "customizen", etwa [[hdparm]], kann man ein Script erstellen:
*hdparm-local.sh
Führt man dann das Target:
[[Make|make]] hdparm
aus, wird beim Bauen das ausgeführt was im [[Customization|Customization]]-Script angelgt wurde. Die Aktionen im Original-Makefile werden übersprungen.
 
===== Beispiel: version-local.sh =====
Diese Funktion ist recht interessant und dürfte recht oft Anwendung finden: 
Während des [[Make|make]]-Durchlaufs werden einige Targets ausgeführt, welche die '''/.version'''-Files bei [[YADD]]
*'''version'''
bzw.
*'''[[Flash|flash]]-version'''
im [[Image]] erstellt.
 
Sofern eines dieser Scripte;
*'''version-local.sh'''
*'''[[Flash|flash]]-version-local.sh'''
vorhanden und ausführbar ist, wird es als Ersatz statt des originalen Targets ausgeführt, welches mit
[[Make|make]] version
bzw.
[[Make|make]] [[Flash|flash]]-version
angestoßen wird.

==== weitere Beispiele für Custiomization ====
Das Customizationscripting soll durch das folgende Beispiel noch mehr veranschaulicht werden.
Beispiel:

In einem [[Jffs2|jffs2]]-[[Image|Image]] wird dies gewünscht:

1. Eigene /etc/hosts benutzen,
2. Eigene [[Neutrino|neutrino]].conf, [[Bouquets|bouquets]].[[XML|xml]], services.[[XML|xml]] benutzen
3. einschließlich [[Lirc|lirc]]-Komponenten, zusammen mit eigenen [[Lirc|lirc]] Konfigurations-Dateien.

1. und 3. sind [[Erweiterungen|Erweiterungen]], die nach '''$(flashprefix)/root''' kommen sollten, während 2. [[Neutrino|Neutrino]]-regeln sind, welche nach sollten '''$(flashprefix)/root-[[Neutrino|neutrino]]-[[Jffs2|jffs2]]''' gehöhren. 
Um 1. und 3. zu erreichen, wird das Script '''root-local.sh''' erstellt, z.B.:

#!/bin/sh
# root-local.sh
flashprefix=$1
buildprefix=$2
newroot=$flashprefix/root
myfiles=/home/somewhere/dbox/myfiles
cp -f $myfiles/etc/hosts $newroot/etc
[[Make|make]] flashlirc
cp -fr $myfiles/var/[[Tuxbox|tuxbox]]/config/[[Lirc|lirc]] $newroot/var/[[Tuxbox|tuxbox]]/config

Das Script für 2. heist '''root-[[Neutrino|neutrino]]-local.sh''', was dem verherigen sehr ähnlich ist:

#!/bin/sh
# root-[[Neutrino|neutrino]]-local.sh
flashprefix=$1
buildprefix=$2
newroot=$flashprefix/root-[[Neutrino|neutrino]]
myfiles=/home/somewhere/dbox/myfiles
cp $myfiles/var/[[Tuxbox|tuxbox]]/config/[[Neutrino|neutrino]].conf $newroot/var/[[Tuxbox|tuxbox]]/config
cp $myfiles/var/[[Tuxbox|tuxbox]]/config/[[Zapit|zapit]]/[[Bouquets|bouquets]].[[XML|xml]] $newroot/var/[[Tuxbox|tuxbox]]/config/[[Zapit|zapit]]
cp $myfiles/var/[[Tuxbox|tuxbox]]/config/[[Zapit|zapit]]/services.[[XML|xml]] $newroot/var/[[Tuxbox|tuxbox]]/config/[[Zapit|zapit]]

Ein weiteres Beispiel:

Im Image werden die procps-Varianten von ps und top anstelle der busybox-Version gewünscht.

In root-local.sh

make procps

hinzufügen.

In root-neutrino-local.sh

for i in top ps; do
cp -va $flashprefix/../cdkroot/bin/$i $flashprefix/root-neutrino/bin/
rm -v $flashprefix/root/bin/$i
done

'''Bitte beachten:'''
Diese Scripte sollen als Beispiele dienen und können vermutlich nicht ohne Anpassung verwendet werden.

= Einige "best practices" =
In diesem Abschnitt befinden sich einige Richtlinien, die zwar nicht zwingend "notwendig" sind, um korrekte Ergebnisse zu erzeilen, jedoch werden sie langfristig helfen, bessere, zuverlässigere und pflegbare [[Software|Software]] zu erstellen. Dies betrifft Customizations, sowie zukünftige Änderungen am Makefile und deren Bestandteile selbst.
 
Wenn man diese Richtlinien nicht mag, kann man sie ignorieren, zumindest wenn man [[Customization|Customization]] Scripte für den eigenen Bedarf schreibt.

== Idempotens ==
Es ist fast immer eine gute Idee zu versuchen, ein Installationsscript [[Wikipedia:Idempotent|idempotent]] zu schreiben. Dies bedeutet, dass das mehrmalige Ausführen den gleichen Effekt hat wie das einmalige Ausführen.
Benutze "[[Make|make]] install".
 
In der Vergangenheit hat das [[Tuxbox|Tuxbox]] Makefile die Komponenten zuerst in ''$(targetprefix)'' installiert, und dann die Imageverzeichnisse durch Kopieren der einzelnen Files aus der ''$(targetprefix)'' Hierarchie erstellt. Dieses ist keine sehr gute Softwaretechnik.
 
Zuerst gehört das Know-How bzgl. [[Installation|Installation]] des Paketes in das Makefile des Pakets, und soll nicht in einem einzigem großen Makefile sitzen, das einfach einzelne Files rüberkopiert. Wenn dieses Paket sich ändert, z.B. man ein Konfigurations-File hinzufügt oder löscht, wird es auch notwendig, das globale Makefile zu ändern.
 
 
Es ist häufig der Fall, dass das Makefile, das zu einem Paket gehört, include-Files, (statische) Bibliotheken, Info-Files etc. installiert, die nicht auf einem enbedded System mit beschränktem Speicher erwünscht sind. Die korrekte Lösung zu diesem (wirklichen!) Problem wäre, das Makefile des betreffenden Pakets zu ändern, entweder, um ein flashinstall-Target zu schreiben, oder das Makefile mit einem Parameter wie ''installsize=[full,flash]'' zu versehen.
 
Wenn dies nicht durchführbar ist, ist es durchaus sinnvoller, daß nach [[Make|make]] -C ... install das Löschen unerwünschter Files besser ist, als das kopieren einzelner Files.
 
Zu erwähnen ist auch, daß in dem Schritt, der die Verzeichnisse ''$(flashprefix)/root-[[GUI|gui]]-[[Filesystem|filesystem]]'' erzeugt, das include-verzeichnis, sowie alle statischen Bibliotheken gelöscht werden und dynamische Bibliotheken von unbenutzten Symbolen gestrippt werden.

== Antworten auf einige Fragen ==
=== Falls das Build nicht gelingt ===
Es gibt kein Standardverfahren was zu tun wäre, wenn das Build misslingt. Es wird versucht, hier einige Richtlinien zu geben und diese zu lesen bevor man im Forum postet.
 
Zuerst, überprüft man den Output der ersten zwei Schritte, '''autogen.sh''' und '''configure''' auf Fehler und Warnungen. Jede Warnung oder Fehler, außer den fünf Warnungen, die oben genannt wurden, zeigen ein Problem an, dass ein Build wahrscheinlich unmöglich macht.
 
Wenn ein Build abbricht, kann es die Umgebung in einem [[Wikipedia:Inkonsistent|inkonsistenten]] Zustand versetzen. Dies gilt insbesondere für die Verzeichnisse in '''$(flashprefix)'''. Wenn der Bau solch eines [[Make|Make]]-Targets abbricht, besteht das Verzeichnis, ist entsprechend seiner Änderungszeit aktuell, und ein folgender [[Make|make]] Befehl behandelt ihn wie fertig und okay.
 
Selbstverständlich wird ein fehlerhaftes Build das Ergebniss sein. Wenn ein Build eines Unterverzeichnisses von '''$(flashprefix)''' in die [[BR|Br]]üche geht, '''dann lösche man es''', bevor ein anderer [[Make|Make]] Befehl ausgeführt wird.
 
Bei "es funktionierte gestern"-Problemen, ist vermutlich die Umgebung in solch einem Zustand. Ein mehr-oder-weniger drastischer Reinigungsbefehl (siehe oben) ist hierbei oft schneller als eine Problemsuche.
 
Wenn man [[Hilfe|Hilfe]] benötigt, siehe unten!.

=== Nach dem [[Flashen|Flashen]]: "Kein System" auf dem [[LCD|LCD]]/Was ist diese "bad magic byte" Zeugs? ===
Diese Frage kommt hoffentlich nicht... Die kurze Antwort ist: Man weiß es nicht. Wir [[Wissen|wissen]] es nicht. Aber, wenn Ihr diesen Artikel so weit gelesen habt, erwartet bitte keine "kurze Antworten", sondern "gute Antworten". O.K. Das Thema ist ausführlich hier besprochen worden. 
Kurz gesagt, das [[Image|Image]] "ist" in Ordnung, es ist nur dass irgendwelche [[Firmware|Firmware]] in der dBox es zurückweisen wird, weil es einige "schlechte magische Bytes" auf bestimmten Adressen finden wird.
 
Das Programm [[checkImage]] aus dem [[CVS|CVS]], zu finden im Verzeichnis '''./hostapps/[[CheckImage|checkImage]]''' ermittelt diese "schlechten Bytes", aber ändert nichts daran, um diese zu beheben. Die Erfahrung zeigt, daß [[Images|Images]], die [[checkImage]] für gut findet, wirklich laufen. [[Cramfs|Cramfs]]-, oder [[Squashfs|squashfs]] [[Images|Images]], worü[[BER|ber]] sich [[CheckImage|checkImage]] beschwert, laufen im allgemeinen nicht, in einigen Ausnahmefällen läufen sie aber doch.
 
Auch bei [[Jffs2|jffs2]]-[[Images|Images]] ist dies manchmal der Fall, dass sich [[checkImage]] beschwert, die [[Images|Images]] laufen, aber eben nicht immer. Mit diesen empirischen Beobachtungen ist man nun sich selbst überlassen.
 
Newmake weiß, wie dieses Programm aufgerufen werden kann, um die erzeugten [[Images|Images]] automatisch zu überprüfen. Die Konfigurationsoption
--with-[[CheckImage|checkImage]]=[none,rename,warn]
wird hierfür verwendet. Falls '''warn''' gewählt ist, wird für jedes [[Image|Image]], das den Test nicht besteht, eine leere Datei erzeugt, am Namen wird ''"_bad"'' angehängt. Wenn '''rename''' gewählt wird, wird das fragliche Imagefile nur umbenannt indem ''"_bad"'' angehängt wird.
 
Es muss erwähnt werden, daß die "schlechten magischen Bytes" in einem (oder mehreren!) der Partitionsteile sitzt, und werden nicht durch den abschließenden Schritt erzeugt (die *.img1x und/oder *.img2x Files bauen). Es ist auch möglich, [[CheckImage|checkImage]] auf die Partitionsfiles anzuwenden *.[[Jffs2|jffs2]], *.[[Cramfs|cramfs]]
*.[[Squashfs|squashfs]]
*.flfs1x
*.flfs2x
Schließlich hat [[CheckImage|checkImage]] eine Debugoption, die nützlich sein kann.

== Ich habe ein Fehler gefunden! ==
Bugs, Unklarheiten, Verbesserungsvorschläge, etc. der [[Software|Software]] sollten vorzugsweise im [http://tuxbox-forum.dreambox-fan.de/forum/viewforum.php?f=7 Cross Development Kit - Forum] des [[Tuxbox|Tuxbox]]-Boards gepostet werden.

== Ich benötige [[Hilfe|Hilfe]]! ==
Supportanfragen können im [http://tuxbox-forum.dreambox-fan.de/forum/viewforum.php?f=7 Cross Development Kit - Forum] des [[Tuxbox|Tuxbox]]-Boards gepostet werden. Postings in deutsch oder englisch sind willkommen. Bitte nicht vergessen, die benutzten Konfigurationsoptionen zu erwähnen.

=Anhang=
==Einige nützliche [[Customization|Customization]] Script Snippets==
In diesem Anhang werden einige nützliche [[Customization|Customization]] Scripte gezeigt. Zwei Scripte sind bereits oben gezeigt worden.
 

'''Warnung'''
Auch falls die Beispiele in einigen Fällen benutzbar sind, werden die Scripte als Beispiele, nicht als Lösungen zu den realen Problemen gezeigt. Aus diesem Grund sind die Beispiele hier als Codefragmente, nicht als downloadbare Dateien, veröffentlicht. Bitte nicht verwenden, es sei denn es ist ungefährlich und Ihr versteht, wie sie funktionieren. Es ist grundlegende Script-Erfahrung erfordelich.

===Games und Languages nuker===
Dieses Script löscht alle [[Spiele|Spiele]] (definiert als [[Plugins|plugins]] mit type=1 in ihrer Konfigurationsdatei), sowie unerwünschte Sprachfiles ([[Neutrino|Neutrino]] angenommen). Das File sollte von '''root-[[Neutrino|neutrino]]-$[[Filesystem|filesystem]]-local.sh''' aufgerufen werden.

#!/bin/sh
# Nukes all game [[Plugins|plugins]], as well as all [[Locale|locale]] files not listed in LANGUAGES
newroot=$1/root-[[Neutrino|neutrino]]-[[Jffs2|jffs2]]
LANGUAGES="deutsch english"
for f in $newroot/lib/[[Tuxbox|tuxbox]]/[[Plugins|plugins]]/*.cfg; do
grep 'type=1' $f>/dev/null && rm -f $newroot/lib/[[Tuxbox|tuxbox]]/[[Plugins|plugins]]/`basename $f .cfg`.*
done
for f in $newroot/share/[[Tuxbox|tuxbox]]/[[Neutrino|neutrino]]/[[Locale|locale]]/*; do
(echo $LANGUAGES | grep -v `basename $f .[[Locale|locale]]` >/dev/null) && rm -f $f
done

=== /.version anpassen ===
Euere eigene ''/.version''-File herzustellen (anggezeigt von [[Neutrino|Neutrino]] durch dBox -> Services -> [[Image|Image]]-Version und cdkVcInfo beim Booten) ist sicher ein allgemeiner Wunsch.

*[[Flash|flash]]-version-local.sh

#/bin/sh
USER=$(whoami)
if [ $0 = $CDIR/flash-version-local.sh ] ; then
outfile=$FLASHDIR/root/.version
type="[[Image|Image]]"
else
outfile=$TARGETDIR/.version
type="[[Yadd|Yadd]]"
fi;
echo Creating $outfile ...
echo "version=`./mkversion -[[Snapshot|snapshot]] -version 200`" > $outfile
echo "creator=$USER" >> $outfile
echo "imagename=$USER-$type" >> $outfile
echo "homepage=[[HTTP|http]]://www.your-website.de" >> $outfile

=== mkversion ===
Das benannte Script ''mkversion'' erzeugt die etwas kryptische Versionszeichenkette:

#!/bin/sh
releasetype=3
versionnumber=000
year=`date +%Y`
month=`date +%m`
day=`date +%d`
hour=`date +%H`
minute=`date +%M`
while expr $# > 0 ; do
case "$1" in
-[[Release|release]])
releasetype=0
;;
-[[Snapshot|snapshot]])
releasetype=1
;;
-internal)
releasetype=2
;;
-version)
versionnumber=$2
shift
;;
esac
shift
done
echo $releasetype$versionnumber$year$month$day$hour$minute

=== Archivierung der [[Images|Images]] ===
Es ist eigentlich die Aufgabe des Buildprozesses, flashbare [[Images|Images]] zu erzeugen, und nicht sie zu archivieren. Jedoch kann die [[Customization|Customization]] leicht dazu "missbraucht" werden, um irgendeine Art der Archivierung zu ermöglichen, wie das folgende Beispiel zeigt:

#!/bin/sh
flashprefix=$1
imagefile=`basename $0|sed -e s/-local.sh//`
imagefilebase=`echo $imagefile|sed -e s/\.img.x//`
extension=`echo $imagefile|sed -e s/[-a-z0-9]*\.//`
newfilename="barf-"$imagefilebase-`date --iso-8601`.$extension
echo Copying $flashprefix/$imagefile to $flashprefix/$newfilename...
cp $flashprefix/$imagefile $flashprefix/$newfilename

Das Script sollte einen oder mehr der Namen
[neutrino, enigma]-[cramfs, squashfs,jffs2].[img1x, img2x]
haben. Es benennt die Files entsprechend dem Tagesdatum um.

=Links=
*[http://www.gnu.org/software/make/manual/make.html GNU Make manual]
*[http://www.gnu.org/software/autoconf/manual/ Autoconf manual]
*[http://www.gnu.org/software/automake/manual/ Automake manual]
*[http://sources.redhat.com/autobook/ GNU Autoconf, Automake, and Libtool]
*[http://www.gnu.org/prep/standards/ GNU Coding standards]
*[http://cvsbook.red-bean.com/ Open Source Development with CVS, 3rd Edition]
*Barf's Homepage: [http://bengt-martensson.de/dbox2/ Barfs ][[Newmake]]-Dokumentation]

{{review}}

{{body}}