Frage zum Imagebau

[tine1084]

Wenn ich ein Image mit „make flash-neutrino-squashfs-all“ gebaut hatte und danach noch Änderungen am Image vorgenommen habe, konnten ich danach immer mit „make flash-neutrino-squashfs-all“ das Image neu packen. Wenn ich das mit dem heutigen aktuellen CVS-Stand mache, fängt es jetzt immer wieder von vorn an das uboot und den kernel neu zu bauen. Ist das so gewollt oder ein Fehler?
Ich weiß aber jetzt nicht genau ab welchen CVS-Datum das so ist.

mfg tine1084

[rhabarber1848]

danach noch Änderungen am Image vorgenommen habe

Änderungen welcher Art?

Ich habe nur eine vage Vermutung, welcher Patch rückgängig zu machen ist:
http://article.gmane.org/gmane.comp.vid ... ox.scm/937
http://forum.tuxbox-cvs.sourceforge.net ... 07#p369307

Ich habe ihn bei mir lokal wieder rückgängig gemacht, da dadurch immer
mkfs.jffs2 neu gebaut wird, obwohl keine Änderungen daran vorgenommen
wurden. Der Patch schießt IMHO über das Ziel hinaus.
Da die Ursache des obigen Patches, der nichts mit Deinem Problem zu tun
haben muss, eine langwierige und unangenehme Diskussion war, werde ich
mich zu besagtem Patch nicht mehr äußern.

[tine1084]

Änderungen welcher Art?

Wenn ich zum Beispiel das "bad magic byte" Problem hatte, dann habe ich immer ein dummy-file nach /etc/init.d/ kopiert und dann das Image mit "make flash-neutrino-squashfs-all" neu gepackt. Wenn ich das aber jetzt mache, fängt es immer wieder beim uboot bauen an und kompiliert alles neu.

[tine1084]

Hab es gerade mal probiert und den patch

http://article.gmane.org/gmane.comp.vid ... ox.scm/937

bei mir rückgängig gemacht, und siehe da es geht wieder.
Danke @rhabarber1848 für den tip.

Wäre schön wenn man den patch im cvs wieder rückgängig machen würde.

[FlatTV]

Ist bei mir auch raus

cu FlatTV

[racker]

Hi,

bei dem oben genannten commit muss man wohl etwas weiter ausholen.

Normalerweise erkennt make Änderungen in Abhängigkeiten selbständig.
Vor dem commit lief einmal configure für hostapps durch und teilte make mit:
Das ist schon ok so.
Die Folge war, dass bei Änderungen in diesem Bereich Müll produziert wurde.
Wäre mit dem richtigen clean target auch ohne den commit leicht zu beheben gewesen.
Das hat aber einige CVS-user gestört ...

Bei mkfs.jffs2 geht make jetzt die Abhängigkeiten durch und baut im Bedarfsfall neu.
Dummerweise wird mkfs.jffs2 immer neu installiert,
egal ob neu gebaut wurde oder nicht.
Hier liegt auch der Fehler.
Verschärft wird das ganze dadurch, dass die hostapps nur ein gemeinsames configure haben.
Dadurch ändert sich auch mkflfs -> neues u-boot etc.

Zur Behebung gibt es 2 Möglichkeiten:

1. Ich reverte den commit. Damit habe ich kein Problem.
Allerdings sollte man dann aufhören das cdk enduser tauglich zu machen.
Sprich: nicht für jedes Feature eine configure-option wenn es auch
mit customization genauso geht. Nicht alle Abhängikeiten werden im
Detail geprüft.
Komfort kostet eben meistens Zeit.

2. Man fixt die Installation der hostapps.

Die cvs-nutzer sollten sich entscheiden:
Komfort und narrensichere Funtkion oder doch etwas mehr mit dem cvs beschäftigen.

... werde ich
mich zu besagtem Patch nicht mehr äußern.

Warum nicht?
Wenn man seine Meinung nicht äußert wird sich nichts ändern
und damit auch nichts verbessern.

Gruß

[rhabarber1848]

... werde ich
mich zu besagtem Patch nicht mehr äußern.

Warum nicht?

http://freenode.net/channel_guidelines.shtml

When you try to answer every question, regardless of difficulty, you set yourself up for support burnout.
[...]
Support burnout is nearly always accompanied by the feeling that you're losing control of your time, that the people you've set out to help are making unreasonable demands. (Das betrifft schnulli.) The problem is that you're taking on too much responsibility; but it begins to appear instead that the problem is the end user who's asking for help.
[...]
You can't answer every question, and you shouldn't try. Be gentle, be courteous, be flexible and be as patient and helpful as you can---but let someone else try to answer questions that you find too frustrating (genau das ist hier der Fall gewesen). Don't try to be a superhuman support machine.

Der Ton in besagtem Thread wurde mir zuviel, deshalb habe ich
mich dort ausgeklingt, ganz im Sinne des oben zitierten Textes.

Im übrigen hatte die Änderung bei mkfs.jffs2, nämlich die optionale
Fähigkeit, JFFS2-Partitionen nun auch mit LZMA packen zu können,
nichts mit neuen cdk/configure-Optionen zu tun.

Gegen verbesserte clean targets habe ich nichts, nur werden Patches
dazu nicht von mir kommen, da ich nicht mit clean targets arbeite,
sondern immer einen CVS checkout in ein leeres Verzeichnis zum
Kompilieren kopiere.

[dbt]

Gegen verbesserte clean targets habe ich nichts, nur werden Patches
dazu nicht von mir kommen, da ich nicht mit clean targets arbeite,
sondern immer einen CVS checkout in ein leeres Verzeichnis zum
Kompilieren kopiere.

Das könnte auf Dauer nicht wirklich sinnvoll sein. Eigentlich gilt: wer A sagt muß auch B sagen, was heißen soll, dass das einfach mit dazu gehört, wenn das schon mal da ist Meine Meinung.

[rhabarber1848]

Wenn ich das richtig sehe, hätte ein simples "make distclean" genügt,
um $prefix/cdk/bin/mkfs.jffs2 zu löschen und eine Neukompilierung
zu erzwingen.

[seife]

Ich sage meine Meinung mal vorsichtig so:

* ich habe es noch jedes Mal geschafft, nach einem "cvs up" _ohne_ "make $CLEANTARGETS" wieder alles ordentlich gebaut zu bekommen. Den Fehler analysieren, dann ein (z.b.) "rm $HOSTPREFIX/bin/mkfs.jffs2", das neu bauen und gut war.
* manchmal wäre ich mit einem "make distclean" oder neu auschecken schneller gewesen, aber man will ja was lernen
* Für "Anfänger" sollte es ok sein, ab und zu mal "make distclean" zu machen.
* Wir sollten nicht unnötig viel Aufwand hineinstecken, das ohne "make distclean" hinzubekommen.
* Wenn es nach "make distclean" immer noch nicht funktioniert, ist das ein Bug, dem es sich nachzugehen lohnt.

Meine Meinung, und das (make distclean fixen) wo ich auch bereit bin, Arbeit reinzustecken.

Die Kür ist, wenn schon "make clean" reicht. Sprich: ein cleantarget, was die Toolchain lässt, aber alles andere wegräumt. Weil die Toolchain sollte man eigentlich nie neu bauen müssen.

So, nun zerfleischt mich

[rhabarber1848]

* Wir sollten nicht unnötig viel Aufwand hineinstecken, das ohne "make distclean" hinzubekommen.
* Wenn es nach "make distclean" immer noch nicht funktioniert, ist das ein Bug, dem es sich nachzugehen lohnt.

Meine Meinung, und das (make distclean fixen) wo ich auch bereit bin, Arbeit reinzustecken.

+1

[tine1084]

Wenn ich ein Image mit "make flash-neutrino-squashfs-all" gebaut hatte und danach noch Änderungen am Image vorgenommen habe, konnten ich danach immer mit "make flash-neutrino-squashfs-all" das Image neu packen. Wenn ich das mit dem heutigen aktuellen CVS-Stand mache, fängt es jetzt immer wieder von vorn an das uboot und den kernel neu zu bauen. Ist das so gewollt oder ein Fehler?
Ich weiß aber jetzt nicht genau ab welchen CVS-Datum das so ist.

mfg tine1084

Dieses problem habe ich jetzt wieder. Der Ordner "root-neutrino-squashfs" wird bei jedem "make flash-neutrino-squashfs-all" neu erstellt. Eigene änderungen gehen dabei immer verloren. Ist das jetzt so gewollt?

[tine1084]

Mit ist gerade aufgefallen das es nur auftritt wenn ich mit "enable-drive-gui" kompiliere.

[tine1084]

Wenn ich ein Image mit "make flash-neutrino-squashfs-all" gebaut hatte und danach noch Änderungen am Image vorgenommen habe, konnten ich danach immer mit "make flash-neutrino-squashfs-all" das Image neu packen. Wenn ich das mit dem heutigen aktuellen CVS-Stand mache, fängt es jetzt immer wieder von vorn an das uboot und den kernel neu zu bauen. Ist das so gewollt oder ein Fehler?
Ich weiß aber jetzt nicht genau ab welchen CVS-Datum das so ist.

mfg tine1084

Dieses problem habe ich jetzt wieder. Der Ordner "root-neutrino-squashfs" wird bei jedem "make flash-neutrino-squashfs-all" neu erstellt. Eigene änderungen gehen dabei immer verloren. Ist das jetzt so gewollt?

Weiß denn niemand woran das liegt?
Das ist nur so wenn ich mit "--enable-drive-gui" baue.
Hat denn sonst niemand das problem?

[cs4711]

Hi, erst mal frohes Fest.
Machs doch mit mit --with-customizationsdir dann dauerts halt länger weil uboot mitgebaut wird, aber die Änderungen im cdkflash sind dann drin.
Wäre aber schön wenn das jemand fixen könnte, weils halt nur mit --enable-drive-gui auftritt.

[rhabarber1848]

Das ist nur so wenn ich mit "--enable-drive-gui" baue.

Ich habe jetzt nicht probiert, das Problem zu reproduzieren,
könnte mir aber vorstellen, dass dieser Patch das Problem
lösen könnte: http://www.tuxbox-cvs.sourceforge.net/f ... 64#p373764

[tine1084]

Das ist nur so wenn ich mit "--enable-drive-gui" baue.

Ich habe jetzt nicht probiert, das Problem zu reproduzieren,
könnte mir aber vorstellen, dass dieser Patch das Problem
lösen könnte: http://www.tuxbox-cvs.sourceforge.net/f ... 64#p373764

@rhabarber1848,

hast recht mit diesem patch funktioniert es wieder.

[rhabarber1848]

FTR: In cdk/make/neutrino.mk wird das hier gepatcht:

Code: Alles auswählen

-if TARGETRULESET_FLASH
-FDISK = \
-        flash-fdisk
-endif

-$(flashprefix)/root-neutrino: $(appsdir)/tuxbox/neutrino/config.status $(FDISK)
+$(flashprefix)/root-neutrino: $(appsdir)/tuxbox/neutrino/config.status

mit $(FDISK) sind die Abhängigkeiten unklar und deshalb tritt das von tine1084
beobachtete Problem auf. Ich lasse fdisk nun innerhalb des o.g. targets bauen:

Code: Alles auswählen

+if ENABLE_FDISK_STANDALONE
+        $(MAKE) flash-fdisk
+endif

[rhabarber1848]

hast recht mit diesem patch funktioniert es wieder.

Der Patch ist im CVS.