Newmake goes Head [ab 06.01.2009]

[dbt]

Auch wenn's ein nicht all zu neues Thema ist und auch auf die Gefahr hin, in ein Wespennest zu greifen, müsste man aber aus gegebenen Anlaß zumindest darüber reden.
Damit meine ich, dass newmake einen recht robusten Stand hat. Ganz davon abgesehen, dass es den Branch schon Jahre gibt, ausgiebig dokumentiert ist und sogar mit yBulid ein Quasi-Frontendlösung existiert.
Ein Vorschlag wäre Newmake auf Head umzustellen aber Oldmake als Branch weiter laufen zu lassen und somit von dem der es will auch weiter gepflegt werden kann.
Wie wärs, mal Nägel mit Köpfen zu machen?
Ich meine ja nur, aber wenn man das ließt, könnte man schon mal an sowas denken:

...Mal im Ernst: ich glaube keiner will hier wirklich oldmake-support machen für die neuen sachen.
Wer das neue Zeug (uclibc, links, ...) haben will: einfach newmake nehmen, da ist es getestet und funktioniert dann auch .

[seife]

Ich fände es sehr angenehm, insbesondere, da der newmake-branch ja sehr "seltsam" gebranched ist (nur einige Files) und es mir deswegen nicht gelungen ist, das tuxbox-CVS automatisiert nach GIT zu konvertieren

Allerdings kenne ich mich zuwenig mit CVS aus um beurteilen zu können, ob und wie man das ohne Verluste machen kann.

Wenn nun wieder alle Wespen kommen und rumstechen, dann ist es mir auch egal, wenn es bleibt wie es ist, allerdings werde _ich_ wirklich keine Rücksicht mehr auf oldmake nehmen, das ist einfach zuviel Arbeit. Sprich: wenn es nicht funktioniert, interessiert mich das relativ wenig.

[rhabarber1848]

+1 für "Newmake goes Head"

allerdings werde _ich_ wirklich keine Rücksicht mehr auf oldmake nehmen

Ich habe oldmake noch nie benutzt und werde es auch nicht tun.

[Striper]

Dafür!

[dietmarw]

woher kenne ich dieses thema nur..

[mash4077]

woher kenne ich dieses thema nur..

Ja, und wer wird dieses mal wohl "geopfert"...

Gruß
mash

[Houdini]

wegen mir

[dbluelle]

Wenn es irgendjemand schafft, auch Unterstützung für die Dreambox in Newmake einzubauen,
dann bin ich auch dafür.
(sonst ist es mir egal )

[dbt]

Ja, und wer wird dieses mal wohl "geopfert"...

Gruß
mash

Ich glaube die, die es betreffen könnte, sind inzwischen pelzig genug und die Leute, die damals alle möglichen Geschütze aufgefahren haben, sind scheinbar auch etwas stiller geworden (kann mich auch täuschen).
Die Ehre, den Part zu übernehmen, das Werk zu vollenden, gebührt eigentlich barf, sofern er das will, sollte er sich mal melden. Er hatte ja schon gewisse Sachen auf Lager gehabt, was den Übergang angeht.
Wie heißt es so schön:

Jetzt mal Butter bei die Fische?

[dietmarw]

...sofern er sich ausdrücklich "NICHT" dazu bereit erklärt...

oder

...sofern er sich nicht ausdrücklich "NICHT" dazu bereit erklärt...


...nie-nich-nie..

[rhabarber1848]

und die Leute, die damals alle möglichen Geschütze aufgefahren haben, sind scheinbar auch etwas stiller geworden

Ich glaube, Du meinst diese Diskussion aus 2006, oder?
http://forum.tuxbox-cvs.sourceforge.net ... 92#p294392

Hier Kritik vom Yadi-Team, April 2006:
http://forum.tuxbox-cvs.sourceforge.net ... 81#p296981

Da wir hier im moment ohne mogway ziemlich einsam für Yadi arbeiten äussere ich mich mal.
Ich wäre dafür newmake erstmal in einem eigenen Branch laufen zu lassen.
Es wäre für uns ein immenser Aufwand unsere Scripte usw. umzustellen um sie an das newmake anzupassen.
Das ist im moment fast unmöglich. Was heisst die Yadi Images würden auf unbestimmte Zeit von der Bildfläche verschwinden.
Diejenigen die newmake gut finden kommen sicher auch mit einem eigenen Branch aus.

Da das letzte Yadi-Update vom März 2008 ist und genügend andere aktuelle Images
(JTG, dietmarw) existieren, haben die o.g. Argumente imho an Kraft verloren.

[Tommy]

Ich glaube die JTG'ler waren auch dagegen

[Houdini]

jo, waren sie,
aber ich denke wir werden denen schon bei der Umstellung helfen oder?
zumal Riker gerne mal ein uClibc Image bauen würde...

[JtG-Riker]

Ich werd mich solange ich auch irgendwie noch den jetzigen HEAD auschecken kann nicht dagegen stellen, sollte das aber nicht gehen müsste ich halt erstmal sehen das ich das irgendwie so gebaut bekomme das ich auch das Image weiterhin bauen kann.

Würde mir aber wünschen das XFS mit uclibc geht - ist das irgendwie machbar ?

Gruß Riker

[rhabarber1848]

Würde mir aber wünschen das XFS mit uclibc geht - ist das irgendwie machbar ?

In uClibc fehlt aio.h
http://forum.tuxbox-cvs.sourceforge.net ... 37#p360937

- xfsprogs kompiliert nicht: "FATAL ERROR: could not find a valid <aio.h> header."

Ich habe leider keinen Weg gefunden, das in uClibc nachzurüsten.

[dbt]

jo, waren sie,
aber ich denke wir werden denen schon bei der Umstellung helfen oder?
zumal Riker gerne mal ein uClibc Image bauen würde...

Dürfte selbstverständlich sein.

dietmarw:

...nie-nich-nie..

...ja, ist nicht so einfach, wenn man es doppelt nimmt, schon garnicht wenn man mit Negationen um sich haut. Aber ich denke, es müsste klar sein, was ich meine

Ich werd mich solange ich auch irgendwie noch den jetzigen HEAD auschecken kann nicht dagegen stellen, sollte das aber nicht gehen müsste ich halt erstmal sehen das ich das irgendwie so gebaut bekomme das ich auch das Image weiterhin bauen kann.

Darauf würde ja mein Vorschlag hinauslaufen. Oldmake würde ja dann noch als Branch bestehen bleiben. Nur Backports könnten mit der Zeit rar werden, sofern sich dann keiner mehr dafür einsetzt, aber ich denke das wird sich zeigen.

[dbt]

Habe mir mal über die Umsetzung Gedanken gemacht und das Ganze auf meinen eigenen CVS-Server gepackt. Soweit läuft das. Nur hier schlägts auf:

Code: Alles auswählen

...
mv /home/dbt/dbox2/cdkflash/root-neutrino-squashfs/etc/init.d/rcS.insmod /home/dbt/dbox2/cdkflash/root-neutrino-squashfs/etc/init.d/rcS
mv: Aufruf von stat für „/home/dbt/dbox2/cdkflash/root-neutrino-squashfs/etc/init.d/rcS.insmod“ nicht möglich: Datei oder Verzeichnis nicht gefunden
make: *** [/home/dbt/dbox2/cdkflash/root-neutrino-squashfs] Fehler 1

Da bin ich etwas verwirrt, da ich dachte die beiden:
rcS.insmod und rcS werden garnicht gebraucht. OK die sind dann nicht mehr drin, kann man also streichen, nur das kommt ja vom Makefile:

Code: Alles auswählen

if !KERNEL26
	mv $@/etc/init.d/rcS.insmod $@/etc/init.d/rcS
endif

Also bleiben die drin wenn man für K26 baut Ist das korrekt? Dachte das Zünden der Kernelsachen wird in rcS.m4 geregelt woraus ja dann die rcS gebaut wird? Kann jemand mal kurz Klarheit schaffen warum das so ist?

[seife]

Die werden beide aus der rcS.m4 erzeugt, und bei kernel 2.4 wird halt die rcS.insmod benutzt, bei 2.6 die rcS
Das passiert in cdk/root/etc/init.d/Makefile.am, aus irgendeinem Grund wurde root/etc/init.d nicht ge-"make"-d.

[dbt]

Ok, machen wir die Sache mal fest. Zeit war lange genug, sich darauf einzustellen. Damit dürfte das Wann klar sein.
Über das Wie könnte man noch etwas sprechen, aber nach einer kleinen internen Beratung dürfte das soweit auch inzwischen klar sein.
Es wird wohl dann einen entsprechenden Oldmake-Branch geben, ähnlich handzuhaben wie der bisherige Newmake-Branch. Das Verfahren hat sich recht gut bewährt. Dieser Branch lässt sich dann wie der bisherige newmake-Zweig auch weiterhin pflegen, wobei sich mir der Sinn nach wie vor nicht ganz erschließt, mit Gewalt Oldmake am leben zu halten, aber sei's drum. Die Pflege ist dann den jenigen überlassen, die das für notwendig erachten und der Rest ergibt sich dann von selbst.
Ich würde auch ausdrücklich darum bitten, dass, falls es wieder irgendwelche Leute gibt, die sich nicht bremsen können und wie vor etwa 2 Jahren schlechtes Wetter machen wollen, den Ball flach zu spielen. Die damalige Umfrage von DietmarW hat ein deutliches ja hervor gebracht und es war wirklich Zeit genug sich ein Bild davon zu machen, wie man mit newmake arbeitet. Wer's bis jetzt noch nicht weiß, dem wird hier auch, wie es Houdini treffend gesagt hat, schon geholfen werden. Auch die ohnehin ausführliche Dokumentation zu Newmake wird dabei gute Dienste leisten.

[seife]

Des weiteren sind Image-Ersteller IMHO ausdrücklich aufgerufen, ihren "Wunschzettel" hier zu posten.
Für die eine oder andere Anforderung wird die Antwort wohl sein "Mach's mit customization-Skript, und zwar so...", aber andere Sachen werden vermutlich zu allgemein nützlichen Änderungen im CVS führen.

dbt: es gibt auch noch ein paar newmake-Dateien ausserhalb cdk/ (pluginx z.B.). Das war zwar eine löbliche Idee von Barf, das aufzuräumen, ich würde allerdings müssen wir da aufpassen, dass wir es nicht für die dreambox-Jünger kaputt machen, denn die nutzen ein oldmake-ähnliches Konstrukt zum Bauen, insofern sollte man da evtl. einfach die oldmake-Versionen benutzen.

[dbt]

Es sollte, glaube ich, schon so sein, dass auch kurzfristig die Dreamboxsachen einbezogen werden. Ich würde es mir daher wünschen, dass barf, der die Sache wohl am genauesten kennt hier auch eingreift.

[seife]

Ich glaube nicht, dass du die Dream-Jünger auf ein neues Buildsystem umstellen wirst, aber solange wir die Änderungen auf cdk/ beschränken, sollte das auch egal sein (der dreambox-Branch besteht fast nur aus cdk/, apps/ wird per "make checkout" auf HEAD updated).

Ansonsten fixe ich hinterher den dreamboxbranch, sollte auch nicht so schwierig sein.

[yjogol]

Na wenn das so ist, dann sehe ich mal zu, dass yBuild V3 bald fertig ist.
http://www.yjogol.com/development/ybuild-v3-news.html

Gruß
yjogol

[dbt]

Ich glaube nicht, dass du die Dream-Jünger auf ein neues Buildsystem umstellen wirst, aber solange wir die Änderungen auf cdk/ beschränken, sollte das auch egal sein (der dreambox-Branch besteht fast nur aus cdk/, apps/ wird per "make checkout" auf HEAD updated)...

Wenn es irgendjemand schafft, auch Unterstützung für die Dreambox in Newmake einzubauen,...

Klar, kurzfristig sicher nicht, das nehm ich zurück und kaputt gehen soll ja nix, aber dann eben längerfristig wird sich das sicher von selbst ergeben. Die Newmake-Struktur gibt das jedenfalls her. Macht aber schon deutlich mehr Arbeit. Da bin ich aber schon mal raus, hab ja keine Dreambox, um daran nachhaltig zu basteln. Es hat aber was, wenn man make flash-neutrino-dreambox700 oder so eingibt und hinten kommt ein Dreambox-Image raus. Und überhaupt dürfte die Frage nach Portierbarkeit auf andere Plattformen in Zukunft eine Rolle spielen. Die dBox ist schließlich nicht mehr die Jüngste.

Des weiteren sind Image-Ersteller IMHO ausdrücklich aufgerufen, ihren "Wunschzettel" hier zu posten.
Für die eine oder andere Anforderung wird die Antwort wohl sein "Mach's mit customization-Skript, und zwar so...", aber andere Sachen werden vermutlich zu allgemein nützlichen Änderungen im CVS führen.

rhabarber1848 hat da dieses Neutrigmadings am laufen und bastelt an Filesystem-Targets. Das wäre schon mal was. Da ich grad GUI-technisch mit dem IDE/HDD/MMC Kram am schrauben bin und rhabarber1848's fs-Targets doch etwas Einfluß darauf haben könnten, ist das auch in gewisser Weise davon abhängig. Aber da muß man mal schauen.

[dietmarw]

betrifft newmake zwar eigentlich nicht,
aber wenn evtl. eh größere umbauarbeiten am cvs vorgenommen werden wäre mein vorschlag:

die hostapps (von denen div. auch veraltet sind) in einen extra branch legen.