@BARF wegen deinen neuen Rules ;-)

[racker]

Dann nehme ich an, dass du ein update durchgeführt hast.
Dann steht in deinem Makefile noch die alte busybox.
Starte noch einmal autogen.sh und configure.

[yada]

Habe ich gemacht / mache ich immer...

[Tommy]

habe bei mir gerade mal ein make flash-semiclean gemacht - danach baut er die ganze busybox neu

[yada]

Das Makefile wird nicht upgedated und ich hab keinen Schimmer warum...

[Tommy]

ich habe eben mal bewußt durchlaufenlassen ohne mksquashfs und mkfs.jffs auf dem system. Newmake erstellt die binaries nicht und bricht beim kompilieren der o.g. ab weil irgendeine libh fehlt. Kopiert man die beiden binaries (von der yadi seite) nach /$flashprefix/cdk/bin/ und gibt ausführrechte dann löppts. Irgendwie ists diesbezügl. noch nicht rund

[racker]

@yada
Dann lösche mal cdk/Makefile und danach autogen.sh etc. ausführen

[yada]

Hab ich gestern schon gemacht und muss meine Aussage korrigieren.
Das Makefile wird zwar neu erstellt, aber mit dem alten Busybox. Kann mir keinen Reim machen, wieso... *Kopfkratz*

[saruman]

Ich habe ein einwas unschön fix anstatt in neutrino.mk implementiert. Besser wäre natürlich ...

Kann ich leider erst heute Abend testen - gesetzt den Fall ich darf an meine Box.

Die furchterliche Wahrheit ist dass z.Z. keine saubere Lösung existiert. Die vorgeschlagene Lösung fordert dass du z.B. eine make distclean dazwischem machst, und den Compiler und glibc neu zu baust. Einige wesentliche Dateien werden beim glibc-installation in cdkroot installiert.

Hmmm, okay, denn könnte ich aber auch gleich zwei CDKs in verschiedenen Verzeichnissen bauen und in dem einen Baum "make yadd-neutrino" und im anderen "make yadd-enigma" starten.

Fürchterlich ist das in meinen Augen allerdings nicht.

Ich habe mich überlegt, falls mann "wirkliche" yadd-targets implementieren sollte, die etwas wie dietmarws yadds bauen, z.B. durch rüberkopieren von cdkroot. Die existiernde yadd-* Targets könnte mann dann in cdk-* umbenennen? Klar was ich meine?

Ich bin mir nicht sicher ob ich Dich hier richtig verstehe. Meinst Du, dass man vor der Integration von Neutrino/Enigma in das Yadd das cdkroot wegkopiert, dann in das bestehende cdkroot Neutrino merged, anschliessend das Neutrino-yadd irgendwie umbenennen, das alte cdkroot wieder hinschiebt und dann Enigma reinmerged?

Wie sieht das dann mit den Bootpfaden aus, werden die irgendwie mit ins u-boot reinkompiliert oder kommen die ausschliesslich vom bootp/dhcp-Server? Sprich: Kann ich ein fertiges cdkroot irgendwo in mein Filesystem legen wenn ich nur dem tftpd und dem dhcpd sage, von wo die Box booten soll? Oder ist das (um bei Deinem Beispiel zu bleiben) dann immer zwingend /tuxbox/cdkroot?

Irgendwie läuft bei mir der Build durch, auch wenn @CURL_LIBS@ nicht expandiert wird. Fix.

Hatte den Fix gestern noch ausprobieren können (make yadd-all lief während Lost so nebenbei sauber durch, habe die Yadd aber dann nicht mehr auf das Fontproblem oben testen können).

Danke schon mal für ausführliche Antwort und schnellen Fix.

[Barf]

ich habe eben mal bewußt durchlaufenlassen ohne mksquashfs und mkfs.jffs auf dem system. Newmake erstellt die binaries nicht und bricht beim kompilieren der o.g. ab weil irgendeine libh fehlt.

Das Thema hat sein eigenen Thread, http://forum.tuxbox.org/forum/viewtopic.php?t=40392. "Irgendeine libh" ist zlib, die für das Kompilieren notwendig ist, siehe meine erste Posting in genannten Thread (am Ende). configure (in hostapps) detektiert das Fehlen der zlib, und gibt eine Warnung aus (Fehler wäre falsch, weil ist möglich, dass ein Kompilierung dieser Teilen nicht erforderlich ist.)

Kopiert man die beiden binaries (von der yadi seite) nach /$flashprefix/cdk/bin/ und gibt ausführrechte dann löppts.

Z.B. /usr/local/bin wäre sicherlich die saubere Lösung.

Irgendwie ists diesbezügl. noch nicht rund

Ich habe es, wie oben beschrieben, versucht es "nach den Regeln" zu implementieren. Die Warnung "zlib.h missing, cannot compile mkfs.jffs2" ist ausgegeben, aber ignoriert worden. Ganz daneben ist es also nicht. Verbesserungsvorschläge sind natürlich willkommen.

@yada: Wahrscheinlich hast du nicht die aktuelle Version von rules-archive und rules-make (version 1.318 und 1.341)

Falls mann configure-iert mit --enable-maintainer-mode hängt z.B Makefile von (u.A.) rules-archive ab, und wird also automatisch neu gemacht falls Makefile älter als rules-archive ist. (Der Name ist also leicht irreführend, "etwas nur für maintainers".)

[Barf]

Fürchterlich ist das in meinen Augen allerdings nicht.

Die Entwicklungsumgebung neu bauen zu müssen weil ein neuen Target hergestellt sein soll, ist in meine Augen "fürchterlich".

Ich habe mich überlegt, falls mann "wirkliche" yadd-targets implementieren sollte, die etwas wie dietmarws yadds bauen, z.B. durch rüberkopieren von cdkroot. Die existiernde yadd-* Targets könnte mann dann in cdk-* umbenennen? Klar was ich meine?

Ich bin mir nicht sicher ob ich Dich hier richtig verstehe. Meinst Du, dass man vor der Integration von Neutrino/Enigma in das Yadd das cdkroot wegkopiert, dann in das bestehende cdkroot Neutrino merged, anschliessend das Neutrino-yadd irgendwie umbenennen, das alte cdkroot wieder hinschiebt und dann Enigma reinmerged?

Vielleicht. (Bedeutet: lass uns Konzepte diskutieren, nicht Implementierungen.) Das Wichtige wäre also yadd als target != cdk. cdkroot spielt z.Z. die Doppelrolle als scratchpad für diverse Maketargets, als auch root directory.

Wie sieht das dann mit den Bootpfaden aus, werden die irgendwie mit ins u-boot reinkompiliert oder kommen die ausschliesslich vom bootp/dhcp-Server? Sprich: Kann ich ein fertiges cdkroot irgendwo in mein Filesystem legen wenn ich nur dem tftpd und dem dhcpd sage, von wo die Box booten soll?

Ja. Am mindestens für dhcpd-Benutzer. (Korrekte exports-Einträge vorausgesetzt, vgl der newmake-target serversupport.)

[yada]

@Barf: Kannst du mal bitte checken wegen busybox?
Ich habe make distclean gemacht, neu ausgecheckt. Autogen und configure und trozdem baut er immer noch das alte busybox 1.01. Bin im Moment ziemlich ratlos, woran das liegen könnte.

[Barf]

@yada: was soll ich checken?

Falls es dir hilft:

Code: Alles auswählen

[1017]$ cvs -z3 status rules-make rules-archive Patches/busybox.config.m4
===================================================================
File: rules-make        Status: Up-to-date

   Working revision:    1.341
   Repository revision: 1.341   /cvs/tuxbox/cdk/rules-make,v
   Sticky Tag:          (none)
   Sticky Date:         (none)
   Sticky Options:      (none)

===================================================================
File: rules-archive     Status: Up-to-date

   Working revision:    1.318
   Repository revision: 1.318   /cvs/tuxbox/cdk/rules-archive,v
   Sticky Tag:          (none)
   Sticky Date:         (none)
   Sticky Options:      (none)

===================================================================
File: busybox.config.m4 Status: Up-to-date

   Working revision:    1.1.2.5
   Repository revision: 1.1.2.5 /cvs/tuxbox/cdk/Patches/Attic/busybox.config.m4,v
   Sticky Tag:          newmake (branch: 1.1.2)
   Sticky Date:         (none)
   Sticky Options:      (none)

[1018]$ grep busybox rules-make rules-archive
rules-make:busybox;1.1.0;busybox-1.1.0;busybox-1.1.0.tar.bz2;extract:busybox-1.1.0.tar.bz2;patch:busybox.diff
rules-archive:busybox-1.1.0.tar.bz2;http://www.busybox.net/downloads

[dietmarw]

also mit einem jungfräulichen "make everything" baut er ...1.1.0

edit: ooops das war uboot mit dem "scheinbar 1.1.4"

[yada]

AHA:

Code: Alles auswählen

===================================================================
File: rules-make        Status: Entry Invalid

   Working revision:    1.338
   Repository revision: No revision control file
   Sticky Tag:          newmake - MISSING from RCS file!
   Sticky Date:         (none)
   Sticky Options:      (none)

===================================================================
File: rules-archive     Status: Entry Invalid

   Working revision:    1.315
   Repository revision: No revision control file
   Sticky Tag:          newmake - MISSING from RCS file!
   Sticky Date:         (none)
   Sticky Options:      (none)

===================================================================
File: busybox.config.m4 Status: Locally Modified

   Working revision:    1.1.2.5
   Repository revision: 1.1.2.5 /cvs/tuxbox/cdk/Patches/Attic/busybox.config.m4,v
   Sticky Tag:          newmake (branch: 1.1.2)
   Sticky Date:         (none)
   Sticky Options:      (none)

[saruman]

Vielleicht. (Bedeutet: lass uns Konzepte diskutieren, nicht Implementierungen.) Das Wichtige wäre also yadd als target != cdk. cdkroot spielt z.Z. die Doppelrolle als scratchpad für diverse Maketargets, als auch root directory.

Okay, dann meinten wir wahrscheinlich dasselbe, allerdings bin ich sicher der Falsche um make-Konzepte zu diskutieren. Ich kann geil UNIX administrieren, aber Softwareentwicklung lag leider immer brach bei mir...

[saruman]

Code: Alles auswählen

TuxMail <Font "/share/fonts/pakenham.ttf" failed>
TuxMail <FTC_Manager_Lookup_Face failed with Errorcode 0x01>
[CPlugins] exec done...

Eigentlich sollte die Makefile für tuxmail dafür sorgen, dass die notwendige Fonts installiert sind/wird, entweder durch Prerequisites, oder durch tatsächlich Installation. Dies ist nicht der Fall.

Ich habe ein einwas unschön fix anstatt in neutrino.mk implementiert. Besser wäre natürlich ...

Gestern getestet, funktioniert. Aber ich verstehe was Du mit unschön meinst. Evtl. müsste man hier mal robspr1 antriggern? *rüberschiel*

[robspr1]

Code: Alles auswählen

TuxMail <Font "/share/fonts/pakenham.ttf" failed>
TuxMail <FTC_Manager_Lookup_Face failed with Errorcode 0x01>
[CPlugins] exec done...

Trifft das nicht alle Plugins die den Framebuffer verwenden?

Da ich makefiles lieber anwende als schreibe, wie wäre es wenn Barf eine Lösung macht die sauber ist und funktioniert (für neutrino, enigma und auch auf der Dreambox)

[saruman]

Trifft das nicht alle Plugins die den Framebuffer verwenden?

Das kann natürlich sein. Ich hatte neulich noch ein oder zwei Plugins mehr ausprobiert, die sind einfach abgeschmiert - hatte nur zu der Zeit keine Konsole an der Box und kann daher auch nicht sagen warum die sich auf die Klappe gelegt haben. Wird aber wohl das gleiche Problem gewesen sein. Tuxmail war dann halt nur ein Beispiel.

Da ich makefiles lieber anwende als schreibe, wie wäre es wenn Barf eine Lösung macht die sauber ist und funktioniert (für neutrino, enigma und auch auf der Dreambox)

Muss Barf entscheiden. Auf jeden Fall müssten die Fonts dann wohl sowohl für Neutrino- als auch für Enigma-Plugins in die entsprechenden Makefiles, denke ich? Denn manche Plugins laufen ja auch unter Enigma und brauchen dort auch den entsprechenden Font, oder sind die bei Enigma schon gleich mit dabei?

[Barf]

Ich glaube, die/eine saubere Lösung wäre, dass mann alle Fonts, die jetzt in $(appsdir)/tuxbox/[neutrino,enigma,lcars]/data/fonts rumgeistern in $(fontdir) (was jetzt nicht existiert) rüberschieben. Dann installiert neutrino, enigma, plugins die erforderlichen Fonts mit (in Makefile.am/install-data-local?) mit sowas wie:

install $(fontdir)/pakenham.xyz $(FONTDIR)

[saruman]

Mal ne doofe Frage weil ich da letzte Woche in einer freien Minute drüber nachgedacht habe:

Wäre es nicht sowieso sinnvoll die Rules (und damit das Customizing) noch ein wenig zu erweitern? Z.B. möchte man sich ja mal die alternative camd2 in die Yadd legen. Momentan gäbe es dafür nur das yadd-{all|enigma|neutrino|...}-local.sh. Aber an sich betrifft das doch alle gebauten Yadds? Da wäre irgendwas wie yadd-cdkroot-local.sh sicher sinnvoll (bei mir heisst das nun zufällig cdk-local. sh und wird aus den yadd-{all|enigma|neutrino|...}-local.sh aufgerufen. Da stehen bei mir dann auch so Sachen drin wie rcS.local anlegen, tuxmaild starten, alte/neue Fernbedienung im rcS konfigurierbar machen, resolv.conf anlegen, ...

Alle Dinge halt, die eine Yadd - unabhängig von der später drauf laufenden Oberfläche (vereinfacht gesagt) - so braucht. Zur Verdeutlichung hier mal mein yadd-neutrino-local.sh:

Code: Alles auswählen

#/bin/sh

echo "========================================================================"
echo "$0 $*"
echo "========================================================================"

TARGETPREFIX=$1
BUILDPREFIX=$2

MYFILES=$BUILDPREFIX/../../additional
SCRIPTDIR=$MYFILES/scripts

[ $0 = ./yadd-neutrino-local.sh ] && $SCRIPTDIR/cdk-local.sh $*

cp -v $MYFILES/custom/neutrino/standby.o* $TARGETPREFIX/var/tuxbox/config
if [ $? -eq 0 ] ; then
    chmod -v 755 $TARGETPREFIX/var/tuxbox/config/standby.o*
fi

sed -i -f $SCRIPTDIR/yadd-neutrino-local.sed $TARGETPREFIX/etc/init.d/start_neutrino

und mein cdk-local.sh:

Code: Alles auswählen

#/bin/sh

echo "========================================================================"
echo "$0 $*"
echo "========================================================================"

TARGETPREFIX=$1
BUILDPREFIX=$2

MYFILES=$BUILDPREFIX/../../additional
SCRIPTDIR=$MYFILES/scripts

mkdir $TARGETPREFIX/mnt/bilder $TARGETPREFIX/mnt/filme $TARGETPREFIX/mnt/musik

sed -i -f $SCRIPTDIR/cdk-local.sed $TARGETPREFIX/etc/init.d/rcS

cp -v $MYFILES/custom/tuxmail.conf $TARGETPREFIX/var/tuxbox/config/tuxmail
cat - <<- EOF > $TARGETPREFIX/etc/init.d/rcS.local
#!/bin/sh

if [ -e /var/etc/.tuxmaild ]; then
 if [ -e /var/bin/tuxmaild ]; then
  [ ! -x /var/bin/tuxmaild ] && chmod 755 /var/bin/tuxmaild
  /var/bin/tuxmaild
 else
  /bin/tuxmaild
 fi
fi

if [ -e /var/tuxbox/config/tuxcal/reminder ]; them
#### [ ! -x /var/tuxbox/config/tuxcal/reminder ] && chmod 755 /var/tuxbox/config/tuxcal/reminder
 /bin/sh /var/tuxbox/config/tuxcal/reminder
fi
EOF
chmod -v 755 $TARGETPREFIX/etc/init.d/rcS.local
touch $TARGETPREFIX/var/etc/.tuxmaild

cat - <<- EOF > $TARGETPREFIX/etc/resolv.conf
nameserver 10.20.30.1
EOF

cp $MYFILES/custom/camd2 $TARGETPREFIX/var/bin

Bei Bedarf reiche ich die sed-Scripte gerne noch nach, allerdings passiert da nichts gewaltiges drin.

Spätestens jetzt fällt mir auch auf, dass man die Start- und Stop-Scripte sowieso mal überarbeiten sollte. Die camd z.B. gehört m.E. sowieso eher in der rcS oder der rcS.local gestartet, da sie Enigma-/Neutrino-unabhängig ist.

Wollte ich ja schon immer mal gemacht haben (war damals auch der Grund warum ich den CVS-Account beantragt hatte), aber der innere Schweinehund... Ich glaube jetzt wäre der richtige Moment für mich...

[Barf]

@saruman: Danke für deine Vorschläge. Dein Vorstellung über "doofe Fragen" weich von meinem ab...

Wäre es nicht sowieso sinnvoll die Rules (und damit das Customizing) noch ein wenig zu erweitern? Z.B. möchte man sich ja mal die alternative camd2 in die Yadd legen. Momentan gäbe es dafür nur das yadd-{all|enigma|neutrino|...}-local.sh. Aber an sich betrifft das doch alle gebauten Yadds? Da wäre irgendwas wie yadd-cdkroot-local.sh sicher sinnvoll

Eigentlich ja. Es gibt aber kaum mehr als die Regeln bare-os (nur das aller notwendigste) und yadd-none (dazu einiges mehr, abei kein GUI) wo ein Customizationhook sinnvoll wäre. In jede fall sollen wir dies machen.

Ein Problem ist eigentlich auch z.B. yadd-neutrino nicht wirklich ein yadd mit neutrino macht, es schaufelt diverse Komponenten in .../cdkroot. Wirkliche yadd-targets haben wir (noch) nicht.

Spätestens jetzt fällt mir auch auf, dass man die Start- und Stop-Scripte sowieso mal überarbeiten sollte. Die camd z.B. gehört m.E. sowieso eher in der rcS oder der rcS.local gestartet, da sie Enigma-/Neutrino-unabhängig ist.

Soisses.

Wollte ich ja schon immer mal gemacht haben (war damals auch der Grund warum ich den CVS-Account beantragt hatte), aber der innere Schweinehund... Ich glaube jetzt wäre der richtige Moment für mich...

Viel erfolg!

[saruman]

Eigentlich ja. Es gibt aber kaum mehr als die Regeln bare-os (nur das aller notwendigste) und yadd-none (dazu einiges mehr, abei kein GUI) wo ein Customizationhook sinnvoll wäre. In jede fall sollen wir dies machen.

Ja, ich habe eben gesehen dass Du die schon eingecheckt hast. Wollte sowieso heute mal neu auschecken, dann passe ich mal meine Scripte an.

Ein Problem ist eigentlich auch z.B. yadd-neutrino nicht wirklich ein yadd mit neutrino macht, es schaufelt diverse Komponenten in .../cdkroot. Wirkliche yadd-targets haben wir (noch) nicht.

Bisher aber wirkungsvoll. Ja, wir sprachen ja schon mal über die yadd-Targets. Arbeitest Du da eigentlich schon dran? Versteh mich nicht falsch, ich will nicht drängeln oder so, es interessiert mich nur wohin Deine Gedanken bei dem Thema hier momentan gehen.

Viel erfolg!

Ich geb mir Mühe. Wenn Du nix dagegen hast würde ich die Ergebnisse dann auch gleich in den newmake-Branch einchecken?

[Barf]

[Dies ist eigentlich ein Supportthrerad; der Konzeptthread ist dieser].

... die yadd-Targets. Arbeitest Du da eigentlich schon dran?

Z.Z. nicht. Aber gurgels/dboxbaers IDE-Interface kann jeden Tag kommen, und es wäre sicherlich sinnvoll sowas zu unterstützen. Ein yadd und ein IDE-"image" unterschieden sich eigentlich sehr wenig (yadd hat CONFIG_ROOT_NFS, ide hat einige Drivers mehr, und (wahrscheinlich) ein NFS-Server).

Sonst steht ein check der clean-Targets ganz oben auf mein TODO-liste.

Wenn Du nix dagegen hast würde ich die Ergebnisse dann auch gleich in den newmake-Branch einchecken?

Falls ich das "rumfummeln" unterbinden möchte, hätte ich nicht in CVS eingecheckt.

[saruman]

[Dies ist eigentlich ein Supportthrerad; der Konzeptthread ist dieser].

Alles klar, dann schwenke ich bei der nächsten Anmerkung rüber.

Falls ich das "rumfummeln" unterbinden möchte, hätte ich nicht in CVS eingecheckt.

Naja, ich wollt wenigstens gefragt haben, bevor ich Deine Arbeit komplett "zerstöre".

[racker]

@saruman

camd2 now started in rcS

Hast du dir das auch genau überlegt?