Virtuelle Yadd / Development Maschine?

[det-box]

@yjogol
ausser obiger Anpassung füge ich noch folgendes ein:

Code: Alles auswählen

# Clean Directoty Structure
clean_dirs()
{
	rm -frdv $CVSDIR/*
	rm -frdv $DBOX_PREFIX/cdk
	rm -frdv $DBOX_PREFIX/cdkflash
	rm -frdv $DBOX_PREFIX/cdkroot
	#rm -f $LOGFILE
}

im Menü:

Code: Alles auswählen

	echo "0  - Basis Configuration"
	echo "ca - Clean All - remove $DBOX_PREFIX/*, $CVSDIR/* and"
	echo "                 set link $CVSDIR/cdk/Archive -> co First time"

im Main Menu:

Code: Alles auswählen

		ca)
			clean_dirs
    			build_dirs
			#do_make clean
			echo "Ready .... press Enter"
			read dummy
			;;

das Build Menü passe ich mir wie folgt an (include\_yb_buildflash.inc.sh):
(da ich 2er und 1er Boxen habe steht es auf all)

Code: Alles auswählen

			2)	buildflash_editvariable $cBuildCHIPS "chips: 1-1x, 2-2x, 3-all"
				case "$buildflash_editvalue" in
					1) cBuildCHIPS="1x" ;;
					2) cBuildCHIPS="2x" ;;
					3) cBuildCHIPS="all" ;;

Det

[yjogol]

sagt mal, hier gehts rund. Find ich ja gut.
Habt ihr alle CVS write-access? Dann könnte ich unter CVS/hostapps einen Ordner für die Skripte anlegen und wir hätten sie zentral.

Gruß
yjogol

[det-box]

Habt ihr alle CVS write-access? .

Gruß
yjogol

ich nicht

wäre aber trotzdem super wenn die Scripte da liegen würden.

Det

[StevenSch]

Ich habe auch keinen cvs-write access. Ich traue mir das ehrlich gesagt auch nicht zu.

Habe mir nochmal das Archive Problem angeschaut, der SymLink zum $ARCHIVEDIR soll ja bei beiden configure Vorgängen erstellt werden - wenn er nicht schon existiert. Das funktioniert aber zumindest bei mir nicht.
Deshalb hab ich die Prüfung mal auskommentiert und siehe da es geht.

(@Yjogol: Hatte die Abfrage irgendeinen wichtigen/praktischen Hintergrund?)
Meiner Meinung sollte man den Link zum ArchivPfad sowieso vorgeben müssen. Damit könnte dann auch die Abfrage, ob das Verzeichniss existiert oder nicht entfallen.
Also Änderung des Codes sowohl bei "do_configure" und bei "do_configure_yadd()":

if [ "$yesno" != "n" ]
then
cd "$CVSDIR/cdk"
#if ! [ -e $ARCHIVEDIR ] ; then
/bin/ln -sf $ARCHIVEDIR $CVSDIR/cdk/Archive
#fi
./autogen.sh

Damit kann dann auch Befehl zur Verlinkung der Archive unter:

# Build Directoty Structure if not exists
build_dirs()
{
mkdir -p $DBOX_PREFIX
mkdir -p $CVSDIR
mkdir -p $CVSDIR/cdk
mkdir -p $LOGOSDIR
mkdir -p $UCODESDIR
mkdir -p $ARCHIVEDIR
# ln -sf $ARCHIVEDIR $CVSDIR/cdk/Archive
}

wieder auskommentiert werden oder komplett entfallen, da das automatisch bei jedem configure passiert.

Im Menü würde korrekterweise ausreichen wenn da steht:

echo "0 - Basis Configuration"
echo "ca - Clean All - remove $DBOX_PREFIX/*, $CVSDIR/*"
echo "co - Checkout - First time / complete"

[StevenSch]

So ich habe mal alle bisherigen Änderungen von det-box an Yjogols-Script und 2-3 kleiner Anpassungen von mir eingebaut. Das Script kann über den untern stehenden Link heruntergeladen werden.

!! Die Privat Verzeichnisse nennen sich bei mir custom also erst über die Basisconfiguration alles anpassen. !!

Änderungen stehen im Changelog.

http://www.dorf-disko.de/pub/yBuild.zip

[Günther]

Also checke ich alles von HEAD aus und es wird mit HEAD geTAGed. Dann hole ich mir die newmake-Dateiliste und checke alle newmake-Dateien aus und nur diese bekommen ein newmake-TAG.
Und die Welt ist in Ordnung.

AHHHHHHH, diese Geschichte hat mich schon fast in den Wahnsinn getrieben . Ich habe das bisher in eclipse immer per Hand vor dem einchecken gemacht (oder eben vergessen ), aber so ist es ja viel genialer - und so einfach :):) .
Die Welt ist wieder in Ordnung

[dietmarw]

das einzige problem dabei ist, das die files liste dann immer 100% stimmen muss

[fran]

wenn ich ein File hinzufüge, wie bestimme ich dann bei dieser Vorgehensweise, ob es zu head oder newmake kommt?

[yjogol]

das einzige problem dabei ist, das die files liste dann immer 100% stimmen muss

Ich habe bisher keine andere Möglichkeit gefunden. Wenn man ein checkout oder update mit -r durchfürht, wird implizit -P Purge ausgeführt und alle Dateien, die nicht im TAG sind gelöscht.

wenn ich ein File hinzufüge, wie bestimme ich dann bei dieser Vorgehensweise, ob es zu head oder newmake kommt?

Das hängt jetzt natürlich vom benutzen Programm ab.
cvs add [-k kflag] [-m 'message'] files...
erstellt einen neuen Fileeintrag (Datei ist aber noch nicht hochgeladen)

cvs commit [-f file] -rnewmake
schiebt alle uncomitteten Files nach newmake. oder -f nutzen um die files anzugeben.

Man kann sich auch anschauen, wie cvs reagieren würden - zum testen
z.B.
cvs -z3 -n -t -d "$CVSNAME@cvs.tuxbox-cvs.sourceforge.net:/cvs/tuxbox" co -P
-n : keine Dateien ändern
-t : trace zeigt an was gemacht würde

Gruß
yjogol

[yjogol]

Also folgende Dateien sind zur Zeit im newmake:

Code: Alles auswählen

./apps:
acinclude.m4

./apps/tuxbox/plugins:
acinclude.m4
configure.ac
Makefile.am
pluginx

./apps/tuxbox/plugins/fx2/tetris:
Makefile.am

./apps/tuxbox/plugins/pluginx:
Makefile.am
pluginx.c

./apps/tuxbox/tools/misc:
Makefile.am

./boot/u-boot-config:
u-boot.dbox2.h.m4

cdk:
acinclude.m4
autogen.sh
configure.ac
customization
Makefile.am
newmake.files

./cdk/doc:
BUILD.changes
README-installflash.en

./cdk/make:
automount.mk
bluetooth.mk
bootstrap.mk
buildenv.mk
busybox.mk
cleantargets.mk
contrib-apps.mk
contrib-libs.mk
cramfs.urls.mk
CVS
defaultlocale.mk
defaultvalues.mk
development-tools.mk
distribution-lists.mk
disttargets.mk
dvb-apps.mk
dvb-config.mk
dvbsnoop.mk
dvb_tools.mk
enigma.mk
etc.mk
flashable-dirs.mk
flash-expand-targets.mk
flashroot-fs.mk
flashroot.mk
flash-streampes.mk
ftpd.mk
fullimages.mk
fun.mk
funstuff.mk
high-level-yadd.mk
hostapps.mk
java-stuff.mk
lcars.mk
lcd.mk
libdvb++.mk
libdvbsi++.mk
libtuxbox.mk
linuxkernel.mk
misc_libs.mk
misc_tools.mk
neutrino.mk
nfsserver.mk
partition-images.mk
phony.mk
plugins.mk
precious.mk
radiobox.mk
reduce-libs.mk
rootutils.mk
sambaserver.mk
serversupport.mk
tags.mk
tuxbox_libs.mk
tuxbox_tools.mk
u-boot.mk
ucodes.mk
upnp.mk
version.mk
zapit.mk

./cdk/Patches:
busybox.config.m4
dbox2-flash.c.m4
libpng.diff
linux-2.4.32-dbox2.config
linux-2.4.32-dbox2.config-flash
linux-2.4.33.3-dbox2.config-flash
linux-2.4.34-dbox2.config-flash

./cdk/root:
Makefile.inc

./cdk/root/etc:
exports
init.d
Makefile.am

./cdk/root/etc/init.d:
initialize
Makefile.am
rcS.m4

./cdk/root/share/udhcpc:
Makefile.am

Gruß
yjogol

[fran]

@yjogol: Vielen Dank.

[det-box]

So ich habe mal alle bisherigen Änderungen von det-box an Yjogols-Script und 2-3 kleiner Anpassungen von mir eingebaut. Das Script kann über den untern stehenden Link heruntergeladen werden.

!! Die Privat Verzeichnisse nennen sich bei mir custom also erst über die Basisconfiguration alles anpassen. !!

Änderungen stehen im Changelog.

http://www.dorf-disko.de/pub/yBuild.zip

Danke, supersache.
ich würde die ROOTPARTSIZE mit in das Configure-Menü (ac),
(datei _yb_configure.inc.sh) nehmen, dadurch sind alle configure-optionen auf einen Blick sichtbar.

Det

[StevenSch]

Das macht Sinn.


Änderungen 09.01.2007- Config für RootPartSize von BasisConfig nach ConfigureConfig verlegt
- fix anonymes checkout: wenn CVSNAME anoncvs ist wird nach cvs Befehl in Barfs HowTo ausgecheckt, sonst nach Yjogols Art
Wer hier eine elegantere Lösung hat bitte posten.
- in CustomDIR/locals kann ein neues Script custom-patches.local angelegt werden.
Abschnitt clean wird vor dem Checkout ausgeführt, Prepare vor dem configure.
Beispiel liegt im zip

Änderungen 08.01.2007
- vorhandene rcS und rcS.insmod nach Checkout löschen
- Menüpunkt "Clear all" eingefügt
- Buildoptionen für 1x,2x,All erweitert
- erstellen Symlink zur Archive Directory gefixt
- das ArchiveDir ist über Basis Configuration editierbar
- Option RootPartitionSize zum flash-configure hinzugefügt
- der Wert der RootPartitionSize ist über Basis Configuration editierbar
- ein paar kometische Änderungen

http://www.dorf-disko.de/pub/yBuild.zip

Kann die folgenden Bugs noch jemand nachvollziehen?
Wenn nach dem configure in ein Config-Menü aufgerufen wird werden die Custom-Scripts in locals nicht mehr korrekt ausgeführt
Als "Anoncvs" (wie ich) bricht der cvs checkout Newmake files mit permission denied ab, Head vorher funktioniert

[yjogol]

Das macht Sinn.


Änderungen 09.01.2007- Config für RootPartSize von BasisConfig nach ConfigureConfig verlegt
- fix anonymes checkout: wenn CVSNAME anoncvs ist wird nach cvs Befehl in Barfs HowTo ausgecheckt, sonst nach Yjogols Art
Wer hier eine elegantere Lösung hat bitte posten.
- in CustomDIR/locals kann ein neues Script custom-patches.local angelegt werden.
Abschnitt clean wird vor dem Checkout ausgeführt, Prepare vor dem configure.
Beispiel liegt im zip

Änderungen 08.01.2007
- vorhandene rcS und rcS.insmod nach Checkout löschen
- Menüpunkt "Clear all" eingefügt
- Buildoptionen für 1x,2x,All erweitert
- erstellen Symlink zur Archive Directory gefixt
- das ArchiveDir ist über Basis Configuration editierbar
- Option RootPartitionSize zum flash-configure hinzugefügt
- der Wert der RootPartitionSize ist über Basis Configuration editierbar
- ein paar kometische Änderungen

http://www.dorf-disko.de/pub/yBuild.zip

prima!

Kann die folgenden Bugs noch jemand nachvollziehen?
Wenn nach dem configure in ein Config-Menü aufgerufen wird werden die Custom-Scripts in locals nicht mehr korrekt ausgeführt
Als "Anoncvs" (wie ich) bricht der cvs checkout Newmake files mit permission denied ab, Head vorher funktioniert

Das habe ich noch nicht verstanden. Poste mal den Fehler.

[yjogol]

THREAD TRENNEN

Hallo zusammen,
ich habe bzgl. der yBuild-Skripte hier einen neuen Thread gestartet: http://forum.tuxbox-cvs.sourceforge.net ... hp?t=43987

Wir sollten hier nur das VMWare Image besprechen.
Gruß
yjogol

[Tommy]

Ich hab mal noch ein Problem mit der VM:

wenn ich die VM reboote sind meine Auflösungseinstellungen weg. Hat jemand einen Tipp?

[yjogol]

Ich hab mal noch ein Problem mit der VM:

wenn ich die VM reboote sind meine Auflösungseinstellungen weg. Hat jemand einen Tipp?

Wie hier beschrieben http://forum.tuxbox-cvs.sourceforge.net ... 331#319331
umstellen. Neu booten und dann in KUbuntu umstellen.

[Tommy]

Hat jemand schonmal unter VM Ware eine DVD/CD gebrannt? Wenn Das geht - welches ist das beste Brennprogramm für Kubuntu?

[yjogol]

Hi,
für den Einsatz von VMWare unter Vista muß die VMWare Workstation 6 Beta genutzt werden. Einmal Kubuntu neu starten und es läuft.

Gruß
yjogol

[just_me]

Hi,

das VMWare Image läuft auch unter QEMU. Zumindest bis auf die graphische Oberfläche:)

QEMU ist ein freier (GPL) Emulator. http://fabrice.bellard.free.fr/qemu/

Auf dem Weg bis zur Textconsole lagen zwei Klippen (Das Umstellen der root partition von /dev/sda1 auf /dev/hda1 und das Schicken von ctrl-alt-f1 and das Gast Kubuntu system ohne dass sich das Host System angesprochen fühlt).

Im einzelnen:

Konfiguration:
QEMU version 0.8.2 (mit oder ohne kqemu 1.3.0pre9 ) auf OpenSUSE 10.0

Code: Alles auswählen

> qemu Ubuntu-000007-cl1-000002-cl1.vmdk

ESC Taste innerhalb von 2 Sekunden drücken.
e Taste             (zum Editieren)
Cursor down         (auf Zeile in der root=/dev/sda1 steht)
e Taste             (zum Editieren)
Ändern von root=/dev/sda1 in root=/dev/hda1
Return
b                   (zum Booten)

Warten und den Kubuntu Meldungen zuschauen. Nach einer Weile tut sich nichts mehr und die CPU Last auf dem Host geht wieder zurück. Kubuntu scheint nun zu hängen weil der X Server nicht gestartet werden kann.
Nun geht es darum, auf die Textconsole zu kommen. Dies geht normalerweise mit CTRL-ALT-F1 aber leider fühlt sich dabei (bei mir - vielleicht ist es anders, wenn QEMU auf Windows läuft) der Host (OpenSuSE 10.0) angesprochen und man landet deswegen auf der ersten Textconsole des Hosts. Deswegen:

Code: Alles auswählen

ctrl alt 2                 (auf Qemu's Debug Konsole schalten, und dort)
sendkey ctrl-alt-f1        (eingeben. Dies sendet ctrl-alt-f1 an Kubuntu. Nun)
ctrl alt 1

Und, bingo, man steht im "y-desktop login:". (login als root mit passwort a). Ab jetzt sollte alles laufen, was auch sonst von Textconsole aus möglich ist.

Z.B. lassen sich die Ausgaben des X servers mit "less /var/log/Xorg.0.log" anschauen. Dort sieht man dann, dass versucht wurde, als device ein "VMWare Inc [VMWare SVGA II] PCI Display Adapter" zu laden, was vermutlich unter QEMU nicht wirklich weiterhilft... (Qemu emuliert eine Cirrus Logic GD5446 Video card). Vielleicht kann jemand noch diese letzte Klippe umschiffen?

Grüße

Frieder

[OppTupacShakur]

liegt das vmware image noch irgendwo zum dl?

[Tommy]

Vllt kan ja mal einer mit ner dicken Leitung das Teil ins ULC hieven. (Vorausgesetzt der Platz im ULC gibts her)

[CarstenW]

@Tommy,
nicht uploaden, habe nur eine bestimmte Größe freigegeben (der Upload bricht dann einfach ab)
@All,
wer es hat sag mir mal bescheid, Platz und Traffic ist z.Z. kein Problem.
Leider ist es nicht mehr bei openftp zu finden?!

Cartsen

[dbt]

Ich hätte ja noch Platz auf meiner Seite, aber dann müsste ich das komplette Image erst mal haben. Ein Upload/Download wäre unbegrenzt auf Dauer möglich. Interesse?

[det-box]

ich habe das orginal (PublicTuxboxKUbuntu.rar/888.489.487) noch hier.

Det