yadi-script: "das erste Mal"

[para]

Hallo Yadi-Team,
ich habe gerade euer Framework aus dem yadi CVS ausgechecked und versuche per "yadi" das CDK zu erstellen... Leider bricht make mit folgendem Fehler ab:

Code: Alles auswählen

make: *** No rule to make target `.deps/linuxdir'.  Stop.

Nach ein wenig suchen laß ich, dass ein "make depdir" im CDK Verzeichnis die fehlenden Einträge erstellt. Das dortige Makefile hat allerdings gar kein passendes target Ist das eine vorrübergehende Inkonsistenz im tuxbox CVS oder hat jemand nen Tipp für mich?

BTW, sind Threads dieser Art hier richtig? Ist zwar mehr nen CDK bzw. Dev. Topic allerdings eben nur für's Yadi-Team, oder...?

Danke, Para

PS: die Programmversionen stimmen alle (Debian/Sarge)

[para]

Nun, nachdem ich mein aclocale auch unter 1.7 laufen hatte (Mist!) lief das "make all" heute Nacht munter durch - so sieht's zumindest aus... Zur Zeit versuche ich mit yadi nen Image zu bauen, was z.Zt. (trotz MKLibs) noch mit diesem Fehler abbricht:

Code: Alles auswählen

FEHLER: make flash-lib abgebrochen!!

Ich forsche weiter Tipps sind trotzdem willkommen...

Para

[para]

Ich mache hier mal munter weiter - vielleicht hilfts ja anderen

So, das letzte Problem lag am mklibs was zu jenem Zeitpunkt noch nicht sauber im autogen/configure zu finden war... Das funktioniert nun! Allerdings bleibt der compile nun hier stehen:

Code: Alles auswählen

../include/lib/dvb/epgcache.h: In member function `void
   eUpgrade::flashImage(int)':
../include/lib/dvb/epgcache.h:283: error: `void eEPGCache::pauseEPG()' is
   private
upgrade.cpp:581: error: within this context
upgrade.cpp:585: error: `erase' undeclared (first use this function)
upgrade.cpp:585: error: (Each undeclared identifier is reported only once for
   each function it appears in.)
upgrade.cpp: At global scope:
upgrade.cpp:653: error: no `bool eUpgrade::erase(char*)' member function
   declared in class `eUpgrade'
upgrade.cpp:691: error: no `void eUpgrade::displayChangelog(eString, eString,
   eString)' member function declared in class `eUpgrade'
upgrade.cpp:691: error: `void eUpgrade::displayChangelog(eString, eString,
   eString)' and `void eUpgrade::displayChangelog(eString, eString, eString)'
   cannot be overloaded
make[3]: *** [upgrade.o] Error 1
...
FEHLER: make flash-enigma abgebrochen!!

Das scheint nun wirklich ein CVS Problem zu sein... Wie ist da jetzt das Vorgehen? Selber fixen/patchen? Kann ich das yadi-script auch nutzen ohne Enigma einzubinden? Ich brauch's eh nicht.

Ciao, Para

[essu]

...
make[3]: *** [upgrade.o] Error 1
...
FEHLER: make flash-enigma abgebrochen!!
[/code]

Das scheint nun wirklich ein CVS Problem zu sein... Wie ist da jetzt das Vorgehen? Selber fixen/patchen? Kann ich das yadi-script auch nutzen ohne Enigma einzubinden? Ich brauch's eh nicht.

Hab jett nicht soviel Zeit um nachzusehen, aber ich kann mich dunkel erinner, dass dieses Problem inzwischen gefixed ist. Hast du ein aktuelles Yadi_CVS/tarball?

Um Enigma nicht zu erstellen könntest du die entsprechenden Passagen in yadi einfach auskommentieren:

Code: Alles auswählen

...
#GUI="enigma"
#. $SCRIPTS/build_gui
#. $SCRIPTS/enigma_changes
#. $SCRIPTS/common_gui_changes
#. $SCRIPTS/cat_image
GUI="neutrino" #GUI="all"
. $SCRIPTS/squashfs_update
. $SCRIPTS/build_gui
. $SCRIPTS/neutrino_changes
#. $SCRIPTS/enigma_changes
. $SCRIPTS/common_gui_changes
. $SCRIPTS/squashfs_kernel
. $SCRIPTS/squashfs_move_files
. $SCRIPTS/squashfs_create_image
...

vllt hab ich was vergessen...

[AreaScout]

Kann ich bestätigen, habe selbes Problem, gleicher fehler beim compilieren wie oben schon erwähnt.

Auskommentieren hilft mit ./yadi -qc nichts

Gruß

[para]

Hallo essu,
also das Yadi-CVS ist von heute (yadi -rm ?)... Ich hab mal inzwischen reingeschaut und einige Inkonsistenzen (fehlender prototype, falsche Deklaration, private statt public usw.) in setup_extra.cpp und upgrade.cpp/h gefunden.
Lustig, ich hab "enigma" vorhin auskommentiert (man sucht ja erstmal selber), aber den "neutrino" Teil dringelassen statt nur "all" zu nehmen Egal, nu geht's ohne Enigma!

Build finished!

Eine Frage, lassen sich cdkroot und tftpboot unter dbox eigentlich direkt als yadd nutzen...? Habe allerdings nicht als yadd (sondern cdk) compiliert. Ein Tausch der u-boot aus Homar's yadd hat nicht's gebracht (invalid signature)...

Dank dir, Para

[gmo18t]

Hi,

para schrieb:

Eine Frage, lassen sich cdkroot und tftpboot unter dbox eigentlich direkt als yadd nutzen...? Habe allerdings nicht als yadd
(sondern cdk) compiliert.

Bei Verwendung vom yadi-script eignen sich sowohl "cdkroot" als auch "cdkflash/root" prinzipiell zum remote booten (=yadd)
Allerdings haben einige Dateien im "cdkroot" (z.B. /etc/init.d/start_neutrino) nicht den gleichen (gepatchten) Stand
wie das erzeugte yadi image bzw. "cdkflash/root". Es sollte aber grundsätzlich booten.
Will man "cdkflash/root" verwenden, sollte man erst ein paar Dateien anpassen, die speziell fuers booten via flash
eingestellt sind (z.B. etc/fstab, aber sind nicht so viele)...

Beim Kernel im "tftpboot" ist - soweit ich mich nicht täusche - kein "nfs zum mounten als root filesystem usw." vorhanden,
so daß dieser nicht "yadd fähig" ist. Ich hab mir deshalb die yadi-cvs/patches/head_changed/Configs/linux_config.squashfs
abgeändert, so daß yadi dann den kernel für's remote booten erzeugt (der ist dann allerdings nicht für's flash brauchbar).

Genauere Details dazu hab ich jetzt nicht mehr im Kopf, da ich das vor längerer Zeit in ein "Tool" gegossen habe,
mit dem ich Original (oder selbsterzeugte) yadi squashfs images zu yadds umwanden kann ...
und zum booten hab ich einen geeigneten Kernel, den ich solange nicht neu bauen muß, bis sich CVS seitig etwas in
der Richtung tun würde (ist ja eh selten).


- GMo -

[AreaScout]

Hi para

Kannst du mir deine diffs von den sourcen senden, erase und so, sind nicht deklariert, habe ich gemacht aber ich laufe dauernd in andere probleme, scheint !noch! nicht meins zu sein.

Danke im vorraus

[alfonxs]

[...]
Genauere Details dazu hab ich jetzt nicht mehr im Kopf, da ich das vor längerer Zeit in ein "Tool" gegossen habe, mit dem ich Original (oder selbsterzeugte) yadi squashfs images zu yadds umwanden kann ...
und zum booten hab ich einen geeigneten Kernel, den ich solange nicht neu bauen muß, bis sich CVS seitig etwas in der Richtung tun würde (ist ja eh selten).

Hi,

würdest du dein "Tool" und den yadd-Kernel zur Verfügung stellen? Leider habe ich momentan nicht die Zeit mir sowas selber zu basteln, würde aber trotzdem gerne meine aktuellen yadis per yadd booten können... danke im voraus!

Gruß
alfonxs

[gmo18t]

Hi,

hier das Tool (bitte README.mkyadi lesen):
http://lvempeg.sourceforge.net/test/mkyadi.tgz

Ist nicht super komfortabel, aber wer sich ein wenig mit linux auskennt, sollte es hinbekommen ...

- GMo -

[para]

@gmo18t: danke für die Infos... Ich denke ich werde einfach mal den symlink in /tuxbox-cvs/boot/u-boot-config auf yadd legen. Flashen will ich meine ersten Versuche wohl eh nicht

@AreaScout: ich habe erstmal keine diffs erstellt. Zum einen benötige ich Enigma nicht, also hab ich's beim compile weggelassen. Zum anderen erstelle ich ungern hotfixes, ohne inhaltlich im Code zu stecken. Es war zwar nicht schwer die einzelnen Probs funktional weitestgehend zu beheben, aber die globalen Auswirkungen kann ich nicht abschätzen... Z.B. ist es eher unklug, eine private Methode public zu machen, nur weil sie an anderer Stelle falsch referenziert wird Den Aufruf abzuändern schließt aber die Kenntnis der Objekthierarchie voraus und das wollte ich mir um die Uhrzeit nicht mehr antun.

Para

[essu]

@para:
Zu dem Problem oben lies mal folgenden thread: http://forum.tuxbox-cvs.sourceforge.net ... hp?t=30871

Ich vermute, dass du mit veralteten yadi-scripten arbeitest. Das update des yadi-cvs ist in den yadi-scripten (noch) nicht enthalten, nur das update des tuxbox-cvs. Da heisst es, manuell händisch von Hand Hand anlegen.

[para]

Nu guck, genau mein hotfix und derselbe Grund wieso ich's nicht gemacht habe
Ich werde mir einfach nochmal euer CVS neu ziehen, obwohl's erst von vorgestern ist...
Sagt mal, wäre ein YADI "Subforum" unter "Development / Entwicklung" nicht sinnvoll, oder ist das schon zuviel des guten?

Ciao, Para

Update (cvs sagt):

M patches/head_changed/.image_version.enigma
M patches/head_changed/.image_version.neutrino
M patches/head_changed/.version
M scripts/allin1.sh
M scripts/yadi
M scripts/yadi.conf

In den letzten drei Files habe ich nur den root-Pfad angepasst bzw. gestern den Enigma compile auskommentiert... Alles andere differiert nicht. Und nu?

[essu]

1. Ich werde mir einfach nochmal euer CVS neu ziehen, obwohl's erst von vorgestern ist...
2. Sagt mal, wäre ein YADI "Subforum" unter "Development / Entwicklung" nicht sinnvoll, oder ist das schon zuviel des guten?

1. Wir haben (*schäm*) momentan kein funktionierendes public cvs, der tarball (siehe link im anderen thread) ist aktueller

2. Naja, die hardcore-DEVs lachen doch nur über uns Script-Kiddies und 'Warmdusch'-Compiler, die wir ein script zur Imageerstellung benutzen und nicht mal locker 10 - 30 commands per Hand eingeben, zwischendurch on the fly noch ein paar patches einpflegen (natürlich aus dem Kopf!).
Du hast ja vllt die bösen Reaktionen im zitierten thread gesehen...

[para]

1.) Ah, das erklärt's natürlich... Muss mich da erstmal reinfinden.
2.) Naja, ich denke das die Devs das nicht so missgünstig sehen, sonst wären sie keine professionellen Entwickler. Neben dem Development ist auch ein gewisses Releasemanagement gefordert! Wenn sich ein Team (erfolgreich) um die Distributionserstellung (bzw. Packaging) kümmert, sollte man es nicht "verniedlichen" sondern schätzen. Wenn das dann auch noch mit einem brauchbaren und sogar supporteten Skriptset passiert, umso besser! Ich verstehe ja, das hier nicht jede Imagetruppe ihr eigenes Forum bekommen kann, aber soviele nennenswerte neben yadi und jtg gibt's doch z.Zt. eh nicht, oder? Ich hatte eben nur die Idee, diese Image-Release und Image-Dev threads nicht unbedingt zu mischen - der Übersicht wegen...

Para

PS: Was soll ich mit nem Kernel oder Apps ohne ein Debian, Redhat oder Suse? LFS ist nicht jedermann's Sache, und "l33t" musste ich noch nie sein um zu überleben

[AreaScout]

@para

Kann dir nur voll zustimmen

btw. hab gestern mit den script vom 1606 erfolgreich compiliert ( komplett )

Gruß