procps fehler seit derm letzten ändern im cvs

[mb405]

Code: Alles auswählen

cp -pa /home/mb405/image/dbox2/cdkroot/lib/libnss_dns-?.*.so /home/mb405/image/dbox2/cdkflash/root/lib
cp -pa /home/mb405/image/dbox2/cdkroot/lib/libnss_files-?.*.so /home/mb405/image/dbox2/cdkflash/root/lib
cp -d /home/mb405/image/dbox2/cdkroot/lib/libproc-*.so /home/mb405/image/dbox2/cdkflash/.flash/lib
cp: Zugriff auf „/home/mb405/image/dbox2/cdkflash/.flash/lib“: Ist kein Verzeichnis
make: [/home/mb405/image/dbox2/cdkflash/.lib] Fehler 1 (ignoriert)
chmod +w /home/mb405/image/dbox2/cdkflash/.flash/lib/libproc-*.so
chmod: Zugriff auf „/home/mb405/image/dbox2/cdkflash/.flash/lib/libproc-*.so“ nicht möglich: Ist kein Verzeichnis
make: [/home/mb405/image/dbox2/cdkflash/.lib] Fehler 1 (ignoriert)

[seife]

Nehmt doch einfach endlich alle newmake :-)

[Tommy]

Nehmt doch einfach endlich alle newmake

Vorsicht - der letzte "Reformator" wurde von Opportunisten vergrault - nich das es Dir genauso geht

[seife]

Du hast meinen Plan noch nicht durchschaut... :-)

Hint: meine checkins ins newmake sind normalerweise recht gut getestet :-))

Also ich versuche einfach, mit newmake einen erheblichen Mehrwert zu bieten :-)

[mb405]

Nehmt doch einfach endlich alle newmake

würde ich ja, nur hat der imagebau nie funktioniert. und bei den zig scripten blick ich net durch.

[dbt]

OT ON

Nehmt doch einfach endlich alle newmake

Das ist doch mal ein Wort. Wers noch nicht versucht hat, sollte es zumindest mal testen. Wer nicht gleich auf den Geschmack kommt, wird spätestens beim Versuch irgendwas einzubasteln dahinterkommen, dass man damit um einiges beweglicher ist, auch wenns einige nicht wahrhaben wollen. Ich fahr teilweise mehrgleisig, aber das nervt auf die Dauer und irgendwie tut Oldmake seinen Namen langsam alle Ehre!

würde ich ja, nur hat der imagebau nie funktioniert. und bei den zig scripten blick ich net durch.

Bei vielen wars wohl andersrum und dass es so aussieht als ob da viel mehr make scripte drin sind mag zwar rein rechnerisch richtig sein. Damit wirds aber eher strukturierter, da nicht alles auf einem Haufen untergebracht ist. Hätte es auch nicht gedacht, aber es macht was her. Die momentane Zweigleis-Situation wird auf Dauer wohl auch nicht halten, da wie es seife schon andeuten lässt, neue Züge nicht über alte Gleise rollen sollten. Es bedarf sicher noch einiges an Optimierung, aber wo ist das nicht der Fall...
@Tommy

Vorsicht - der letzte "Reformator" wurde von Opportunisten vergrault - nich das es Dir genauso geht

Die Diskussion von damals war schon irgendwie lächerlich, vorallem die Argumente "Es geht doch, warum was ändern..." usw. mag schon sein, aber einige sind da mit'm Brett vorm Kopf dagegen angetreten, dass es nicht mehr feierlich war. Sich deswegen von jemand vergraulen lassen, wäre schon übel, aber Gegenwettern dürfte jetzt nicht mehr so einfach sein wie damals.
OT OFF

[Tommy]

Nehmt doch einfach endlich alle newmake

würde ich ja, nur hat der imagebau nie funktioniert. und bei den zig scripten blick ich net durch.

Bahh - das nenn ich mal Ausrede Es gibt exakt ein Script für jeden Folder in cdkflash welches auch noch genauso heist. Das jeweilige script wird ausgeführt wenn das Folder in cdkflash fertig gebaut ist. Zusätzlich gibts noch eine Handvoll für Versionserstellung und zum wegspeichern der Images/ Updates. Wenn die scripte einmal fertig sind (z.B. für Erstellung der mountpoints) fäßt man die nie wieder an. Beispiele für diese Scripts habe ich mal in einem Thread von Barf damals gepostet. Das ganze ist wesentlich übersichtlicher als so ein oldmake allinwonderscript.

just my 2cent

[geko37]

Also ich habe auch meine Probs mit newmake ! Ich blicke da auch nicht durch ! Eventuell liegts aber auch darann das man schon lange mit Oldmake arbeitet und die umstellung einiges an Zeit bedarf ! Die ganzen customize bla teile also ehrlich ! Naja was solls ! Jedem das seine !

[dbt]

Die ganzen customize bla teile also ehrlich !

Lasst Euch doch davon nicht verwirren oder abschrecken. Die braucht man doch nur wenn man sie will.
Bauts doch erst mal ohne die "Teile". Wenn die nicht da sind bauts doch default. Wie das dann mit dem customize zurechtgestutzt wird, kann man doch nach und nach "erkunden". So gut wie das dokumentiert ist, wird einem schon früh ein Licht aufgehen!

Eventuell liegts aber auch darann das man schon lange mit Oldmake arbeitet

Genau, und grade weil da die Oldmake-Dokus nur so lala sind und man sich sehr viel anfressen musste und man die "Eigenene Arbeitsweise" lieb gewonnen hat, fällt es natürlich schwer sich umzustellen (Das haben damals auch einige deutlich durch die Blume raushängen lassen und ihre Argumente darauf aufgebaut), obwohl es wahnsinnig einfach wäre, wenn man es nur mal versucht.

[seife]

Ist doch wurst. Neue Features baue ich einfach nur noch im newmake ein :-) Damit das besser funktioniert machen wir in die CFLAGS noch ein "-DNEWMAKE" rein, dann können wir die wirkungsvoll ausblenden. Sollen die doch sehen wo sie bleiben, die ewig gestrigen!

P.S.: ;-) :-) 8-) :-P

[dietmarw]

lol

[wittinobi]

ohje.

[dbt]

Ist doch wurst. Neue Features baue ich einfach nur noch im newmake ein Damit das besser funktioniert machen wir in die CFLAGS noch ein "-DNEWMAKE" rein, dann können wir die wirkungsvoll ausblenden. Sollen die doch sehen wo sie bleiben, die ewig gestrigen!

P.S.: ;-)

Wie immer, sehr erfrischend.

[mohousch]

würde ich ja, nur hat der imagebau nie funktioniert. und bei den zig scripten blick ich net durch.

es ist nicht mehr als das oldmake makefile in einigen gespilittet ;-)

[Tommy]

Ist doch wurst. Neue Features baue ich einfach nur noch im newmake ein Damit das besser funktioniert machen wir in die CFLAGS noch ein "-DNEWMAKE" rein, dann können wir die wirkungsvoll ausblenden. Sollen die doch sehen wo sie bleiben, die ewig gestrigen!

P.S.: ;-)

Wenn Du die dadurch freiwerdende Zeit in codezeilen im sectionsd oder MP umsetzt -GERNE

Ich denke mal aus Sicht des Projektes ist seifes Zeit besser IM Code eingesetzt als drumherum. Wenn die Leute, die Images bauen Ihn dadurch unterstützen Ihm die Arbeit zu erleichtern wäre das dringend angebracht. Das newmake Klasse funktioniert sieht man ja an dietmarw's Images. Ich glaube nicht, dass er mit denen viel Aufwand betreibt.

Vieleicht ließe sich ja auch Barf zurückgewinnen - denn auch newmake kann sicher noch verbessert werden bzw. muß gepflegt werden (Stichwort m4)

[dbt]

es ist nicht mehr als das oldmake makefile in einigen gespilittet ;-)

Ganz so ist es auch nicht. Da wurde schon einiges an der Struktur geschraubt. Ansonsten könnte man ja immer jede Änderung 1:1 portieren. Dem ist aber nicht immer so. Deswegen ist das "Gebranche" eher lästig. So notwendig Branches bei gewissen Sachen notwendig sein mögen (siehe Dream, K2.6), sind sie m.M. nach beim Builden unangebracht.

[mb405]

wenn mal einer auf deutsch nen dummi beschreibt wie ybuild script funktioniert dann würde ich das auch nutzen, aber wenn ich in das script reinschau seh ich net durch.
mir sagen die ganzen dateien und was da drinsteht nicht viel.
es hängt schon da haussen, das ich nicht weis, wie ich damit den fritzboxcallmon reinstrippen kann, damit der dann auch funktioniert.
ich hab ehrlich gesagt keine lust 200seiten zu dem newmake build durchzuarbeiten, und nachher nichts zu verstehen, weil jeder da anders vorgeht.
also am besten man einigt sich auf ein script, und das wird einmal richtig beschrieben, damit das auch jeder versteht, dann würden auch die letzen "oldmaker" mit sicherheit newmake nutzen.

[Tommy]

Schade das das WIKI noch nicht geht - wäre ein schöner Platz mal yBuild zu erklären.
Im Prinzip ist es simpel - einfach von oben nach unten durcharbeiten.
1. Pfade für Umgebung festlegen
2. Configure Optionen festlegen
3. make Optionen festlegen
4. bauen

Betr. fritzboxcallmon - wie machst Du das jetzt? Wenn es ein make prozess ist kannst Du den z.B. in /<customizationpath>/root-local.sh einleiten. (IMO erstes customization script was ausgeführt wird) So haben wir es auch damals mit dem automounter gemacht. Wenn es nur ein binary in /var einzukopieren gilt machst Du es in /<customizationpath>/var-neutrino-local.sh

Tante EDIT sagt Du sollst mal hier http://www.yjogol.com/development/index.php vorbeischauen

[mb405]

nein das fritzboxcallmaon ist ja ein binary, das muss vor dem rebuild-flash rein nac /bin und hinterher wieder raus. nur das der die libs nicht rausstrippt.
var-neutrino-local.sh hab ich net gefunden in ybuild ??
ich will ja das ding begreifen

[Tommy]

bezügl. der Scripts kann ich Dir helfen:

Zitat http://www.bengt-martensson.de/dbox2/fl ... tomization

Viele der wichtigeren Targets rufen ein Customization-Script auf, falls vorhanden und ausführbar. Der Name des Customization Scriptes wird als das Nicht-Verzeichnis Teil der Regel genommen, mit -local.sh angefügt. Der Script soll im customizationsdir liegen. Dies ist mit der configure-Option --with-customizationsdir auswählbar. Default ist das cdk-Verzeichnis. Das Script wird zwei Argumente übergeben: Für Imagetargets sind diese $(flashprefix) und $(buildprefix); für Yaddtargets sind diese $(targetprefix) und $(buildprefix).

...heißt also jedes verzeichnis welches du in $(flashprefix) findest (dbox2/cdkflash) wird bei vorhandensein das gleichnamige script mit der endung -local.sh ausgeführt. Im Falle von Verzeichnis $(flashprefix)/var-neutrino ist das also var-neutrino-local.sh

Bezügl. deines fbcallmons bin ich leider überfragt. Es geht aber mit Sicherheit

[yjogol]

Schade das das WIKI noch nicht geht - wäre ein schöner Platz mal yBuild zu erklären.
Im Prinzip ist es simpel - einfach von oben nach unten durcharbeiten.
1. Pfade für Umgebung festlegen
2. Configure Optionen festlegen
3. make Optionen festlegen
4. bauen

Betr. fritzboxcallmon - wie machst Du das jetzt? Wenn es ein make prozess ist kannst Du den z.B. in /<customizationpath>/root-local.sh einleiten. (IMO erstes customization script was ausgeführt wird) So haben wir es auch damals mit dem automounter gemacht. Wenn es nur ein binary in /var einzukopieren gilt machst Du es in /<customizationpath>/var-neutrino-local.sh

Tante EDIT sagt Du sollst mal hier http://www.yjogol.com/development/index.php vorbeischauen

Also wenn jemand helfen möchte yBuild zu dokumentieren und/oder zu erweitern fänd ich das sehr gut. Z.Z. bin ich mit yWeb 2.7 beschäftigt, so dass ich bei yBuild pausiere.
Ich kann Schreibrechte auf meiner Website vergeben, dann können dort Artikel wie im Wiki geschrieben werden.

nein das fritzboxcallmaon ist ja ein binary, das muss vor dem rebuild-flash rein nac /bin und hinterher wieder raus. nur das der die libs nicht rausstrippt.
var-neutrino-local.sh hab ich net gefunden in ybuild ??
ich will ja das ding begreifen

Das Einbinden von Binaries zum strippen ist möglich.

Code: Alles auswählen

#==============================================================================
# root-neutrino-local.sh
# will be executed before libary reduction
#==============================================================================
#show_variables
#set -x

#------------------------------------------------------------------------------
# Get yBuild pathes and variables
#------------------------------------------------------------------------------
yb_home=$HOME/tuxbox/ybuild
. $yb_home/yb_globals.conf
. $yb_home/include/_yb_library.inc.sh
init_variables

#------------------------------------------------------------------------------
# init specific pathes and variables
#------------------------------------------------------------------------------
flashprefix=$1
buildprefix=$2
myfiles=$MYFILESDIR
newvar=$flashprefix/root-neutrino
cdkroot=$DBOX_PREFIX/cdkroot

#------------------------------------------------------------------------------
# lets start
#------------------------------------------------------------------------------
echo "================================================================================"
echo "LOCAL: $0"
echo "flashprefix=$1 and buildprefix=$2"
echo "================================================================================"

#------------------------------------------------------------------------------
# move files to take attention while stripping libs
#------------------------------------------------------------------------------
cp -r $myfiles/lib/* $newvar/lib

#---------------------------------------------------------------------------------
echo "================================================================================"
echo "END LOCAL: $0"
echo "================================================================================"

PS: Von mir aus können wir yBuild auch komplett eindeutschen.
Gruß
yjogol

[flasher]

Hi

Ich muss das procps Problem nocheinmal aufgreifen.
Ich habe jetzt 2x vergeblich versucht ein Image mit veränderter ROOTSIZE zu erstellen.
Ich bekomme beim compilen immer folgenden Fehler:

Code: Alles auswählen

cp: Aufruf von stat für „/home/frank/work/dbox2/cdkroot/lib/libproc-*.so“ nicht möglich: No such file or directory
make[1]: [/home/frank/work/dbox2/cdkflash/root-neutrino-squashfs/lib/ld.so.1] Fehler 1 (ignoriert)
chmod: Zugriff auf „/home/frank/work/dbox2/cdkflash/root-neutrino-squashfs/lib/libproc-*.so“ nicht möglich: No such file or directory
make[1]: [/home/frank/work/dbox2/cdkflash/root-neutrino-squashfs/lib/ld.so.1] Fehler 1 (ignoriert)
make[1]: *** [/home/frank/work/dbox2/cdkflash/root-neutrino-squashfs/lib/ld.so.1] Fehler 1
make: *** [/home/frank/work/dbox2/cdkflash/root-neutrino-squashfs] Fehler 2

Nach diesem Fehler bricht auch sofort die Verarbeitung des Customscript: root-neutrino-squashfs-local.sh ab. Das fällt aber wohl nur dennen auf die nicht die default Rootsize benutzen.
Wenn ich das jetzt richtig verfolgt habe, dann wird procps garnicht gebaut. Zumindest nicht bei make flash-neutrino-squashfs-all...

Wenn man von Hand make .deps/procps macht, dann gehts...

Ich habe jetzt mal direkt im Makefile folgendes geändert:
Hinter : $(MAKE) flash-tuxtxt
Das: $(MAKE) $(DEPDIR)/procps

Damit werden die libs zumindest schon gebaut aber der Build bricht wieder ab. Diesmal mit:

Code: Alles auswählen

make[1]: *** [/home/frank/work/dbox2/cdkflash/root-neutrino-squashfs/lib/ld.so.1] Fehler 1
make: *** [/home/frank/work/dbox2/cdkflash/root-neutrino-squashfs] Fehler 2

Das dürfte im Makefile hier sein:

Code: Alles auswählen

	$(MKLIBS) --target $(target) --ldlib ld.so.1 --libc-extras-dir \
		$(targetprefix)/lib/libc_pic \
		-d $</lib \
		-D -L $(mklibs_librarypath) \
		--root $< \
		`find $</bin/ -path "*bin/?*"` \
		`find $</lib/ -name "libnss_*"` \
		`find $</lib/ -name "*.so" -type f` \
		`find $</sbin/ -path "*sbin/?*"`

Wäre schön wenn sich das mal jemand anschaut der mehr von Makefile versteht als ich.

Gruß

[seife]

Das ist irgendein anderer Fehler. Das cp und das chmod vom procps stehen extra mit "-" davor im Makefile, damit wird ignoriert, wenn die Fehlschlagen, was ja auch bei dir und bei mir im Log steht:

Code: Alles auswählen

cp -d /local/seife/src/tuxbox-newmake-26/root//cdkroot/lib/libnss_files-?.*.so /local/seife/src/tuxbox-newmake-26/root//cdkflash/root-neutrino-squashfs/lib
cp -d /local/seife/src/tuxbox-newmake-26/root//cdkroot/lib/libproc-*.so /local/seife/src/tuxbox-newmake-26/root//cdkflash/root-neutrino-squashfs/lib
cp: cannot stat `/local/seife/src/tuxbox-newmake-26/root//cdkroot/lib/libproc-*.so': No such file or directory
make[1]: [/local/seife/src/tuxbox-newmake-26/root//cdkflash/root-neutrino-squashfs/lib/ld.so.1] Error 1 (ignored)
chmod +w /local/seife/src/tuxbox-newmake-26/root//cdkflash/root-neutrino-squashfs/lib/libproc-*.so
chmod: cannot access `/local/seife/src/tuxbox-newmake-26/root//cdkflash/root-neutrino-squashfs/lib/libproc-*.so': No such file or directory
make[1]: [/local/seife/src/tuxbox-newmake-26/root//cdkflash/root-neutrino-squashfs/lib/ld.so.1] Error 1 (ignored)
/local/seife/src/tuxbox-newmake-26/hostapps/mklibs/mklibs.py --target powerpc-tuxbox-linux-gnu --ldlib ld.so.1 --libc-extras-dir \

Nur daß es bei mir danach weitermacht, und bei dir nicht.
Um ganz sicherzugehen, daß es das nicht ist, mach mal das im make/reduce-libs.mk:

Code: Alles auswählen

%/lib/ld.so.1: %
        find $</lib -maxdepth 1 -type f -o -type l | xargs rm -f
        cp -d $(targetprefix)/lib/libnss_dns-?.*.so $</lib
        cp -d $(targetprefix)/lib/libnss_files-?.*.so $</lib
        -cp -d $(targetprefix)/lib/libproc-*.so $</lib || true
        -chmod +w $</lib/libproc-*.so || true
        $(MKLIBS) --target $(target) --ldlib ld.so.1 --libc-extras-dir \

Also "|| true" hinter die beiden Befehle.
Damit "merkt" make gar nicht, daß die beiden Befehle fehlschlagen.

EDIT: ich orakle mal, daß er entweder dein mklibs nicht findet (oder die Variable leer ist), oder kein ld.so.1 da ist (dann würde ich aber eine Fehlermeldung vom mklibs.py erwarten)

[flasher]

Hi

Also das mit dem || true hat auch nicht geholfen. Die Fehlermeldung besteht weiterhin.
Aber es läuft jetzt wieder durch.

Der Fehler war, dass in /bin ein undefiniertes Binary lag welches nicht erkannt wurde. (Name: y0ufsde )
Die Meldung war irgendwas mit: cant recognized file type oder so.
Danach brach das Script komplett ab.

Komischerweise wurde die Datei jetzt nicht mehr erstellt und alles lief problemlos durch.

Gruß