Flashtargets in Makefile umgeschrieben
-
- Developer
- Beiträge: 1475
- Registriert: Dienstag 4. Februar 2003, 22:02
Flashtargets in Makefile umgeschrieben
Ich habe ein neues Versuch gemacht, das Imagebuilden im CDK aufzuräumen, Dazu habe ich die Flashtargets fast völlig umstrukturiert. Die "public" Targets heissen jetzt flash-$gui-$filesys-$chips, wobei $gui ist neutrino oder enigma, $filesys ist jffs2fs, cramfs oder squashfs, $chips ist 1x oder 2x. Ausserdem kann man "all" angeben statt $gui, $filesys oder $chips. Funktionell neu ist das automatische builden von jffs2fs-only images. Filenamen habe ich versucht, konsequent zu gestalten, siehe die Kommentare im Makefile(.am). Dokumentation (erste Version) hier.
Ich möche das ganze in CVS einchecken falls keine (hinreichend wichtige ) Protesten auftreten.
Ich bitte deswegen um Testen, insbesonderes vom Imagebastlern wie das YADI-Team. Zum Testen braucht mann die diff vom .../cdk/Makefile.am,
configure.ac, sowie die Files linux-drivers-mtd-maps-dbox2-flash-jffs2fs.c.diff
und linux-drivers-mtd-maps-dbox2-flash-squashfs.c.diff, die beide im .../cdk/Patches gehen, und u-boot.jffs2.dbox2.h in Directory ---/boot/u-boot-config. Sowie (eventuell) die oben genannte Dokumentationsfile in .../cdk/doc. Dazu ein Direktory .../cdk/defaultlogos mit inhalt logo-fb und logo-lcd.
(Hoffe war das alles).
Insgesamt ist es eine Menge mehr oder wenig große Änderungen. Es wird sicherlich alte Imagebau-skripte kaputtmachen, aber, von der andere Seite, sollte sie auch hoffentlich überflüssig machen. Bitte teile alle Probleme mit.
Noch eine freundliche Bitte: Bitte diese Thread nur zu Diskussion dieser Verbesserungen benutzen. Anfängenfragen irgendwo anderes.
Ich möche das ganze in CVS einchecken falls keine (hinreichend wichtige ) Protesten auftreten.
Ich bitte deswegen um Testen, insbesonderes vom Imagebastlern wie das YADI-Team. Zum Testen braucht mann die diff vom .../cdk/Makefile.am,
configure.ac, sowie die Files linux-drivers-mtd-maps-dbox2-flash-jffs2fs.c.diff
und linux-drivers-mtd-maps-dbox2-flash-squashfs.c.diff, die beide im .../cdk/Patches gehen, und u-boot.jffs2.dbox2.h in Directory ---/boot/u-boot-config. Sowie (eventuell) die oben genannte Dokumentationsfile in .../cdk/doc. Dazu ein Direktory .../cdk/defaultlogos mit inhalt logo-fb und logo-lcd.
(Hoffe war das alles).
Insgesamt ist es eine Menge mehr oder wenig große Änderungen. Es wird sicherlich alte Imagebau-skripte kaputtmachen, aber, von der andere Seite, sollte sie auch hoffentlich überflüssig machen. Bitte teile alle Probleme mit.
Noch eine freundliche Bitte: Bitte diese Thread nur zu Diskussion dieser Verbesserungen benutzen. Anfängenfragen irgendwo anderes.
-
- Contributor
- Beiträge: 1833
- Registriert: Mittwoch 10. April 2002, 15:39
edit:
...patches nochmal an die richtige stelle kopiert..
nun läuft es erstmal an..
edit2:
ungetestete ergebnisse von "make flash-all-jffs2fs-all"
hier http://tuxbox.trale.de/
...patches nochmal an die richtige stelle kopiert..
nun läuft es erstmal an..
edit2:
ungetestete ergebnisse von "make flash-all-jffs2fs-all"
hier http://tuxbox.trale.de/
Zuletzt geändert von dietmarw am Donnerstag 21. Juli 2005, 18:30, insgesamt 2-mal geändert.
-
- Developer
- Beiträge: 196
- Registriert: Dienstag 16. Oktober 2001, 00:00
Hi,
Gute Idee, Barf! Bis jetzt nur ein Fehler, bei: make flash-enigma-squashfs-all bricht das compilen bei folgender Stelle ab:
für was steht denn das "c"? Im Original Makefile.am sah die Zeile so aus:
Das -p sollte in der Tat überflüssig sein, da in -a die entsprechende Option enthalten ist.
cu
Gute Idee, Barf! Bis jetzt nur ein Fehler, bei: make flash-enigma-squashfs-all bricht das compilen bei folgender Stelle ab:
Code: Alles auswählen
echo "version=0200`date +%Y%m%d%H%M`" > /home/tux/tuxbox-cvs.barf/root/cdkflash/root/.version
echo "comment=Created by `id -un`" >> /home/tux/tuxbox-cvs.barf/root/cdkflash/root/.version
/usr/bin/install -c /home/tux/tuxbox-cvs.barf/root/cdkroot/bin/busybox /home/tux/tuxbox-cvs.barf/root/cdkflash/root/bin
for i in `find /home/tux/tuxbox-cvs.barf/root/cdkroot/bin/ -lname "*busybox"` ;do cp -rc $i /home/tux/tuxbox-cvs.barf/root/cdkflash/root/bin/ ; done
cp: invalid option -- c
,,cp --help" gibt weitere Informationen.
Code: Alles auswählen
for i in `find $(targetprefix)/bin/ -lname "*busybox"` ; do cp -ap $$i $(flashprefix)/root/bin/ ; done
Code: Alles auswählen
coronas@asus ~]$ cp --help
Aufruf: cp [OPTION]... QUELLE ZIEL
oder: cp [OPTION]... QUELLE... VERZEICHNIS
oder: cp [OPTION]... --target-directory=VERZEICHNIS QUELLE...
Kopieren von QUELLE nach ZIEL, oder mehrere QUELLE(n) in VERZEICHNIS
Erforderliche Argumente für lange Optionen sind auch für kurze erforderlich.
-a, --archive genau wie -dpR
-
- Developer
- Beiträge: 1475
- Registriert: Dienstag 4. Februar 2003, 22:02
Danke für das Testen.
Ich habe ganz definitiv cp -rd gemeint wo es cp -rc steht. Mein cp hat ein -c option, und hat deswegen nicht gemeckert Deswegen extra Danke.
Es ist meine Meinung, dass man in Makefiles cp ohne -p Option benutzen soll. Wir schaffen ja was neues, was deswegen creation-time JETZT haben soll, wir machen ja nichte ein Backup-Kopie von irgendetwas Altes (wobei mann die creation-time nicht umsetzen will). Deswegen habe ich grundsätzlich alle -p-Optionen zu cp entfernt. Ist jemand andere Meinung?
Noch eine Sache motiviert aus
Ich habe ganz definitiv cp -rd gemeint wo es cp -rc steht. Mein cp hat ein -c option, und hat deswegen nicht gemeckert Deswegen extra Danke.
Es ist meine Meinung, dass man in Makefiles cp ohne -p Option benutzen soll. Wir schaffen ja was neues, was deswegen creation-time JETZT haben soll, wir machen ja nichte ein Backup-Kopie von irgendetwas Altes (wobei mann die creation-time nicht umsetzen will). Deswegen habe ich grundsätzlich alle -p-Optionen zu cp entfernt. Ist jemand andere Meinung?
Noch eine Sache motiviert aus
Das checkImage-Program wird angestossen für jede erzeugte Image. Falls das Program (was ich selbst nicht ganz verstehe ) sagt dass die Image schlecht ist wird sie in *.bad umbenannt. Meine tests zeigt das flashen von cramfs und squashfs die als bad gekennzeichent auch zu "No system" führen. Dagegen schein ein jffs2fs-image zu laufen, auch wenn checkImage gemotzt hat!
-
- Contributor
- Beiträge: 1833
- Registriert: Mittwoch 10. April 2002, 15:39
was viel lustiger is..
von den im zweiten test erzeugten jffs2 images ist statt 3 nur eins "angeblich" def.
sie beruhen aber def. auf dem SELBEN source
irgendwas ist da mit dem testen noch nicht wirklich sauber..?
(oder ist da beim "füllen" irgendwo ein zufallsprinzip drin? eigentlich ja nicht)
ungetestete ergebnisse von "make flash-all-all-all"
hier http://tuxbox.trale.de/
teste meine zwar nicht ständig, aber mir ist noch kein nicht startendes untergekommen..
wenn, dann waren es cvs probleme..
von den im zweiten test erzeugten jffs2 images ist statt 3 nur eins "angeblich" def.
sie beruhen aber def. auf dem SELBEN source
irgendwas ist da mit dem testen noch nicht wirklich sauber..?
(oder ist da beim "füllen" irgendwo ein zufallsprinzip drin? eigentlich ja nicht)
ungetestete ergebnisse von "make flash-all-all-all"
hier http://tuxbox.trale.de/
das kann ich nur bestätigen..Dagegen schein ein jffs2fs-image zu laufen, auch wenn checkImage gemotzt hat!
teste meine zwar nicht ständig, aber mir ist noch kein nicht startendes untergekommen..
wenn, dann waren es cvs probleme..
-
- Contributor
- Beiträge: 1833
- Registriert: Mittwoch 10. April 2002, 15:39
-
- Developer
- Beiträge: 196
- Registriert: Dienstag 16. Oktober 2001, 00:00
-
- Developer
- Beiträge: 1475
- Registriert: Dienstag 4. Februar 2003, 22:02
Danke Coronas und dietmarw für eure Feedback.
Ich habe die Dinge committed. (Werden deswegen von meiner Website entfernt.) Dazu die Verbessserungen von Coronas und dietmarw. Nur bei cramfs und squashfs (also nicht jffs2fs-images) wird der Imagen in .bad umbenannt. Grundsätzlich ist es eine Sache des Benutzers, die Ergebnisse von checkImage zu bewerten.
Mal sehen, falls jemand in die Luft geht ...
Ich habe die Dinge committed. (Werden deswegen von meiner Website entfernt.) Dazu die Verbessserungen von Coronas und dietmarw. Nur bei cramfs und squashfs (also nicht jffs2fs-images) wird der Imagen in .bad umbenannt. Grundsätzlich ist es eine Sache des Benutzers, die Ergebnisse von checkImage zu bewerten.
Mal sehen, falls jemand in die Luft geht ...
-
- Image-Team
- Beiträge: 1015
- Registriert: Freitag 7. Februar 2003, 18:37
Also ich finde das Teileweise als mega Rückschritt, zumindestz das man nicht mehr nur einzelne Teile bauen kann, ich habe bis jetzt immer make rebuild-flash benutzt für meine Snapshots und eben make flash-neutrino-all & enigma-all mit einigen anpassungen fürs JTG-Image.
Jetzt wird da jedesmal u-boot gebaut und sonstwas, da ist auch noch ein Bug weil anscheind mkflfs nicht ausführ bar ist...
Hab den Kram erstma wieder zurückgebaut in meinem CVS bis ich Zeit hab alles anzupassen...
ALso rebuild-flash ist meiner Meinung nach einer der wichtigsten Flash-Punkte gewesen für updates...
Riker
Jetzt wird da jedesmal u-boot gebaut und sonstwas, da ist auch noch ein Bug weil anscheind mkflfs nicht ausführ bar ist...
Hab den Kram erstma wieder zurückgebaut in meinem CVS bis ich Zeit hab alles anzupassen...
ALso rebuild-flash ist meiner Meinung nach einer der wichtigsten Flash-Punkte gewesen für updates...
Riker
-
- Developer
- Beiträge: 1475
- Registriert: Dienstag 4. Februar 2003, 22:02
Ich habe am 20. Juli die Änderungen zum Testen freigegeben. Ziel war, eventuelle Inkompatibilitäten mit z.B. Imagebauern auszuloten. In diese Zeit hat sich JtG-Riker nicht gemeldet. Es ist nicht wahrschenlich, dass eine längere Testperiode etwas daran geändert hätte.
Eine Makefile baut Produkte (Targets) von Prerequisites. Falls am mindestens ein Prerequisite neuer als ein Produkt ist, wird das Produkt neu gebaut, sonst nicht. Deswegen hat Targets wie rebuild-flash nicht in einem richtig entworfene Makefile nichts zu suchen, weil Make sowieso weiss (idealerweise) was rebuild-ed werden soll. Leider ist die Makefile(.am) des Tuxboxprojekts (insbesonderes bevor meine Änderungen) nicht wirklich Makefile-ish.
Ich habe versucht, die Targets so zu gestalten. Deswegen soll auch rebuild-flash nicht notwendig sein, sondern nur make flash-$gui-$fs-$chips. Dadurch werden alle notwendige (und idealerweise nur die) Komponente neugebaut. Falls mann die Makefile nicht vertraut, kann make flash-clean oder make-developerclean benutzt werden
Konstruktive Vorschläge, sowohl in technische Fragen als auch bzgl. "Changemanagement" sind willkommen.
Eine Makefile baut Produkte (Targets) von Prerequisites. Falls am mindestens ein Prerequisite neuer als ein Produkt ist, wird das Produkt neu gebaut, sonst nicht. Deswegen hat Targets wie rebuild-flash nicht in einem richtig entworfene Makefile nichts zu suchen, weil Make sowieso weiss (idealerweise) was rebuild-ed werden soll. Leider ist die Makefile(.am) des Tuxboxprojekts (insbesonderes bevor meine Änderungen) nicht wirklich Makefile-ish.
Ich habe versucht, die Targets so zu gestalten. Deswegen soll auch rebuild-flash nicht notwendig sein, sondern nur make flash-$gui-$fs-$chips. Dadurch werden alle notwendige (und idealerweise nur die) Komponente neugebaut. Falls mann die Makefile nicht vertraut, kann make flash-clean oder make-developerclean benutzt werden
es ist genau umgekehrt. Jetzt wird nicht u-boots gebaut, falls ein passende und aktuelle $filesys.flfs*x schon existieret.Jetzt wird da jedesmal u-boot gebaut
klingt mehr als schlechte Laune als ein Bugbericht. Ich kann kein Bug aus diese Beschreibung extrahieren.und sonstwas, da ist auch noch ein Bug weil anscheind mkflfs nicht ausführ bar ist...
Konstruktive Vorschläge, sowohl in technische Fragen als auch bzgl. "Changemanagement" sind willkommen.
-
- Image-Team
- Beiträge: 1015
- Registriert: Freitag 7. Februar 2003, 18:37
Und wie kann man denn in den neuen flashrules nur z.b. den cramfs Bereich neu bauen als aktuellen Snapshot als update ? Das die Funktion nicht mehr geht find ich den Rückschritt, villeicht kannst du mich des besseren belehren.
Also wenn das nicht mehr geht find ich es nicht gut, ich hab auch die Tage keine Zeit gehabt den Kram zu testen, man hätte solch große änderungen event in einen eigenen Branch legen sollen.
Wie gesagt hab ich den Kram bei mir reverted, weil ich keine alternative zu make flash-neutrino-all und flash-enigma-all und rebuild-flash gefunden habe.
Also wenn das nicht mehr geht find ich es nicht gut, ich hab auch die Tage keine Zeit gehabt den Kram zu testen, man hätte solch große änderungen event in einen eigenen Branch legen sollen.
Wie gesagt hab ich den Kram bei mir reverted, weil ich keine alternative zu make flash-neutrino-all und flash-enigma-all und rebuild-flash gefunden habe.
-
- Erleuchteter
- Beiträge: 450
- Registriert: Sonntag 28. Juli 2002, 01:18
-
- Developer
- Beiträge: 1475
- Registriert: Dienstag 4. Februar 2003, 22:02
Das gesuchte Flashtarget heisst (z.B.) $(flashprefix)/root-neutrino.cramfs.JtG-Riker hat geschrieben:Und wie kann man denn in den neuen flashrules nur z.b. den cramfs Bereich neu bauen als aktuellen Snapshot als update ? Das die Funktion nicht mehr geht find ich den Rückschritt, villeicht kannst du mich des besseren belehren.
Auch "Möchte deine Änderungen testen. Bitte gib mir eine Woche" hätte es getan.Also wenn das nicht mehr geht find ich es nicht gut, ich hab auch die Tage keine Zeit gehabt den Kram zu testen,
Ist ja ein Vorschlag. Ich glaube kaum, dass es etwas bewirkt hätte. Erstmals ist "branced development" problematisch als solches, zweitens erlaube ich mich zu bezweifeln, dass dadurch sich mehr qualifizierte Testers gemeldet hätte.man hätte solch große änderungen event in einen eigenen Branch legen sollen.
deswegen benutzen wir ja CVSWie gesagt hab ich den Kram bei mir reverted,
Die alternative heissen flash-neutrino-all-all und flash-enigma-all-all. Falls es Bugs gibt, kann deine Hilfe diese zu finden und auszubügeln wertvoll sein.weil ich keine alternative zu make flash-neutrino-all und flash-enigma-all und rebuild-flash gefunden habe.
-
- Developer
- Beiträge: 1475
- Registriert: Dienstag 4. Februar 2003, 22:02
falls dein/ein Skript "make rebuild-flash" aufruft wirst du es natürlich "vermissen". Du wirst aber die Funktionalität aber nicht vermissen (siehe frühere Beiträge).AudioSlyer hat geschrieben:make rebuild-flash vermisse ich aber auch
Erlich, genau WEIL die Makefiles der Vergangenheit so schlecht war, hat sich alle diese Imagebastel-skripte eintwickelt.
-
- Semiprofi
- Beiträge: 1287
- Registriert: Montag 30. Dezember 2002, 08:02
Also ich glaube nicht das man verlangen kann, dass sich alle Imagebauer solch weittragenden Änderungen innerhalb einer Woche ansehen. Also ich hatte bis dato keine Zeit dazu. Man hat ja auch nebenbei noch Familie und einen Beruf.Barf hat geschrieben:Auch "Möchte deine Änderungen testen. Bitte gib mir eine Woche" hätte es getan.Also wenn das nicht mehr geht find ich es nicht gut, ich hab auch die Tage keine Zeit gehabt den Kram zu testen,
Also ich finde die Methode schon recht heftig. Nur weil du meinst das so mehr Leute testen, wird grad mal der komplette Build Prozess umgestrickt. Mit dem Ergebniss das bei allen erst mal nichts geht. Ein eigener Branch ist hier wohl mehr als angebracht.Barf hat geschrieben:Ist ja ein Vorschlag. Ich glaube kaum, dass es etwas bewirkt hätte. Erstmals ist "branced development" problematisch als solches, zweitens erlaube ich mich zu bezweifeln, dass dadurch sich mehr qualifizierte Testers gemeldet hätte.man hätte solch große änderungen event in einen eigenen Branch legen sollen.
Ich würde vorschlagen, Du revertest das im CVS und checkst es als Barfs Branch neu ein. Somit haben alle, die möchten, Gelegenheit das ausführlich zu testen und ggf noch Änderungen vorzunehmen. So wie es jetzt ist kann es IMHO nicht bleiben.Barf hat geschrieben:deswegen benutzen wir ja CVSWie gesagt hab ich den Kram bei mir reverted,
Gruß
mogway
-
- Image-Team
- Beiträge: 1015
- Registriert: Freitag 7. Februar 2003, 18:37
Full ack, finde auch erstma in nen eigenen branch, das sollte doch kein Problem sein, alexH hat sich ja neulich erst die Mühe gemacht und die ganzen rules umgebaut, allerdings soweit abwärtskompatibel.mogway hat geschrieben:
Ich würde vorschlagen, Du revertest das im CVS und checkst es als Barfs Branch neu ein. Somit haben alle, die möchten, Gelegenheit das ausführlich zu testen und ggf noch Änderungen vorzunehmen. So wie es jetzt ist kann es IMHO nicht bleiben.
Gruß
mogway
Riker
-
- Tuxboxer
- Beiträge: 2331
- Registriert: Donnerstag 24. März 2005, 21:52
-
- Contributor
- Beiträge: 1833
- Registriert: Mittwoch 10. April 2002, 15:39
-
- Developer
- Beiträge: 196
- Registriert: Dienstag 16. Oktober 2001, 00:00
Mal abgesehen vom timing - Ich finde, dass das neue Makefile eine wesentlich bessere Basis ist als das alte. Auf jeden Fall klappt jetzt schon wesentlich mehr: man gibt einen Befehl ein, und hinten kommt ein Image raus. Ohne zusätzliche Skripte (die allerdings von alleine berücksichtigt werden, wenn vorhanden).
Ist das nicht immer gewollt worden?
Ist das nicht immer gewollt worden?
-
- Einsteiger
- Beiträge: 281
- Registriert: Mittwoch 8. Dezember 2004, 21:45
Tach Ihrs,
schade fände ich es, wenn nun barf's versuch ein bissl im keim erstickt wird.
Innu
Ich habe ein neues Versuch gemacht, das Imagebuilden im CDK aufzuräumen
ich fand den ansatz prima, auch wenn ich riker & co zustimme, daß nach 4 tagen einen "versuch" einchecken nicht wirklich ein testen ermöglicht.Modified: . Makefile.am configure.ac
Log:
Changes reverted
schade fände ich es, wenn nun barf's versuch ein bissl im keim erstickt wird.
Innu
-
- Image-Team
- Beiträge: 1015
- Registriert: Freitag 7. Februar 2003, 18:37
Am Ansatz hab ich auch nix auszusetzen, finde es aber nicht gut das alle rules komplett umgebaut/benannt werden, wenigstens die Funktionen der einzelnen Packete sollten bleiben, das ist seit Jahren so und hat doch auch immer funktioniert, alexH hat sich doch Anfang des Jahres erst die Arbeit gemacht und das alles erweitert so das man doch ein ganzes Image bauen kann damit, das könnte man ja noch um die fehlenden Sachen erweitern.
Zumindest sollten die alten :
make flash-neutrino/enigma/lcars-all
make rebuild-flash
usw bleiben.
Riker
Zumindest sollten die alten :
make flash-neutrino/enigma/lcars-all
make rebuild-flash
usw bleiben.
Riker
-
- Developer
- Beiträge: 279
- Registriert: Mittwoch 26. Juni 2002, 22:19
-
- Developer
- Beiträge: 279
- Registriert: Mittwoch 26. Juni 2002, 22:19
Hab grad noch nen kleinen Fehler in der u-boot.jffs2.dbox2.h gefunden.
Außerdem hab ich mit der uboot aus dem cvs immer eine Bad CRC Meldung.
Das protect off muss bei 10020000 anfangen, da sonst die FLFS Partition nicht mehr aus Neutrino heraus oder per Telnet geflasht werden kann.#defineCONFIG_BOOTCOMMAND \
"protect off 10040000 107fffff; " \
"fsload; setenv bootargs root=/dev/mtdblock2 rw console=$(console); " \
"bootm"
Außerdem hab ich mit der uboot aus dem cvs immer eine Bad CRC Meldung.
Weiß jemand warum? Das Image läuft ganz normal.U-Boot 1.1.2 (Tuxbox) (Jul 25 2005 - 17:48:19)
CPU: PPC823ZTnnB2 at 67.100 MHz: 2 kB I-Cache 1 kB D-Cache
Board: DBOX2, Nokia, BMon V1.2
Watchdog enabled
I2C: ready
DRAM: 32 MB
FLASH: 8 MB
*** Warning - bad CRC, using default environment
FB: ready
LCD: ready
In: serial
Out: serial
Err: serial
Net: SCC ETHERNET
Scanning JFFS2 FS: ....... .
Gruß
Der Papst
Der Papst
-
- Contributor
- Beiträge: 1833
- Registriert: Mittwoch 10. April 2002, 15:39
@yadi+jtg+audioslyer
is da denn nun außer dem "make rebuild-flash" noch irgendetwas gravierendes was euch stört??
oder ist da jetzt nur ein wenig starrsinn wegen dem "schnellschuss" im spiel?
die meisten anderen meinungen waren eigentlich eher positiv..
und für den *allejubeljahremaleinimageersteller* ist das ganze doch ne super sache.
is da denn nun außer dem "make rebuild-flash" noch irgendetwas gravierendes was euch stört??
oder ist da jetzt nur ein wenig starrsinn wegen dem "schnellschuss" im spiel?
die meisten anderen meinungen waren eigentlich eher positiv..
und für den *allejubeljahremaleinimageersteller* ist das ganze doch ne super sache.
-
- Image-Team
- Beiträge: 1015
- Registriert: Freitag 7. Februar 2003, 18:37
Leider hat sich Barf ja noch nicht zu Wort gemeldet, hoffe nicht das er sauer ist jetzt ?dietmarw hat geschrieben:@yadi+jtg+audioslyer
is da denn nun außer dem "make rebuild-flash" noch irgendetwas gravierendes was euch stört??
oder ist da jetzt nur ein wenig starrsinn wegen dem "schnellschuss" im spiel?
die meisten anderen meinungen waren eigentlich eher positiv..
und für den *allejubeljahremaleinimageersteller* ist das ganze doch ne super sache.
Also mogway und ich hatten schonmal die Idee das er den kram einfach "unter" die alten rules einchecken ins makefile, da ja alles umgeschrieben wurde könnte man dann beides nehmen, obs geht müsste man nochmal gucken.
Ich möchte auf jedenfall weiter die alten rules nutzen, da es mit den neuen nicht möglich ist einen schnellen snapshot zu machen wie bis jetzt und auch nicht möglich ist "nur mal schnell" einzelne packete zu updaten usw, für komplett-Images sind die neuen rules sicher besser, aber fürs teilupdaten einfach nicht zu gebrauchen. Das gleiche ist bei Yadi, das komplette Script wird aus den Angeln gehoben und funktioniert nicht mehr.
Weiterhin sind die "make flash-part " Dinge seit jahren so im CVS - wieso man die komplett über den Haufen werfen muss verstehe ich immer noch nicht, man muss bedenken das sicherlich 1000sende User dranhängen.
Ich habs fürs Jtg Image einen "make-flash-jtg" hinzugefügt was meine
ganzen JTG-spezifischen Dinge erledigt, so das ich sonst kein riesen Skript mehr habe um einen Snapshot oder ein Image zu machen.
Ich wär auf jedenfall dafür sie in einen eigenenen Branch einzuchecken, dafür ist sowas ja da, dann kann man sich ma in ruhe damit befassen.
Hoffe Barf meldet sich mal zu Wort.