Duo4K - NI-Buildsystem

Benutzeravatar
Janus
NI - VIP
Beiträge: 1138
Registriert: Di 12. Apr 2016, 19:41
Box: HD1, Zee, Neo, Tank, HD51, Duo4K

Re: Duo4K - NI-Buildsystem

Beitrag von Janus »

Wie schon geschrieben, wenn ich das Backup auf ein anderes Medium (128GB USB-Flash oder die 2TB HDD) mache, gibt es keine Probleme.
Aber die Neutrino-Images sollten doch nicht so groß sein, dass sie nicht mehr nach /tmp passen ?!?

df sagt gerade hier:
rootfs benutzt: 207 MB (mein Selbstbau, noch ohne Platz-Optimierungen). Knapp 5 MB für den Kernel ??
tmp noch frei : 283 MB

Könnte natürlich sein, wenn im zweiten Durchgang nochmal ein komprimiertes "Doppel" angelegt wird.
Das Komplett-Backup (m2-imgbackup-duo4k_27.07.2020-10.42.tgz) lag damals als ich den Fehler festgestellt habe, bei knapp über 93 MB.
(auch das war noch nicht platzoptimiert)

Wie gesagt, ein Enigma-Image (606 MB) würde ich nach /tmp auch nicht aus einem Neutrino-Script einer anderen Partition heraus anstoßen.

Bin gerade dabei, aus einem Nightly von Gestern die Multiboot-Basis wieder aufzubauen.
Mein Selbstbau (mit den alten Treibern) ist wieder auf Bank 2 und durchläuft noch manuell meine Konfigurationsschritte um das für weitere Upgrades zu automatisieren.

Erst danach werde ich mich wieder mit bekannten Fehlern befassen.
Nach dem letzten Befassen mit (anderen) Fehlern wurde nämlich das o.g. Vorgehen mit der Multiboot-Basis wieder notwendig. So wird es halt nie langweilig... :blush:
Benutzeravatar
annie
NI - Team
Beiträge: 1010
Registriert: Di 5. Apr 2016, 18:46
Wohnort: zuhause
Box: 1x E4HD, 4x HD51,1x VuUno4K

Re: Duo4K - NI-Buildsystem

Beitrag von annie »

nur 283 MB Ram ist aber wenig

meine Vu+ Uno 4K SE hat da etwas mehr zur Verfügung

Code: Alles auswählen


[vuuno4kse] /var/root # free
              total        used        free      shared  buff/cache   available
Mem:         723692      175356      442156         336      106180      543756

Benutzeravatar
Gorcon
NI - VIP
Beiträge: 2724
Registriert: Mi 13. Apr 2016, 10:55
Box: E2HD, VU+ Uno4kSE, VU+ Ultimate4k
Has thanked: 8 times
Been thanked: 2 times

Re: Duo4K - NI-Buildsystem

Beitrag von Gorcon »

Ja, die Uno ist auch viel neuer. ;)
Benutzeravatar
Janus
NI - VIP
Beiträge: 1138
Registriert: Di 12. Apr 2016, 19:41
Box: HD1, Zee, Neo, Tank, HD51, Duo4K

Re: Duo4K - NI-Buildsystem

Beitrag von Janus »

Es liegt am Platzbedarf.
Ich habe mein "Gebrauchsimage" ausgehend von dem Standard-Image ziemlich weitgehend auf meinen Bedarf zusammengestrichen und/oder auf den USB-Flash ausgelagert. Bin damit noch nicht ganz fertig, aber probieren wollte ich doch schonmal.

Das rootfs begnügt sich hier aktuell mit 185824 1K-blocks
Die Umsetzung mit bzip2 ergibt dann knapp 80MB zusätzlich, sodass das insgesamt unterhalb der Gesamtkapazität von /tmp bleibt.

War also kein "Fehler", sondern schlicht ein unerwartetes und nicht abgefangenes Platzproblem, was wohl nur in /tmp auftritt. (Wenn auf USB oder HDD ausreichend Platz ist)
Die Enigma-Experten lösen das wie gewohnt voll elegant: Grundsätzlich kein Full-Backup über /tmp zulassen.

Für das Standard-Nightly auf der Duo wäre das mit 206 MB (bei 3 Satpositionen und einem Kabelanbieter) schon zu groß für /tmp.


Also /tmp vergrößern, wenn's geht,
oder Teil-Ergebnisse woanders zwischenspeichern, (RAM ? sind hier gerade 457 von 555 MB frei)
oder mögliche Probleme abfangen und auf zusätzliche Speichermedien verweisen.

Oder ebenfalls /tmp ganz blocken und auf anderen Speichermedien einen Speicherplatz-Check vorschieben.
Benutzeravatar
BPanther
NI - VIP
Beiträge: 745
Registriert: So 29. Sep 2019, 18:37
Kontaktdaten:

Re: Duo4K - NI-Buildsystem

Beitrag von BPanther »

Übergangsweise wird der doppelte Platz benötigt, denn erst wird das tar geschrieben, dann "umkopiert" nach bz2 und danach verschwindet das tar (das macht bzip2 selbst so).

Habe mal mit NI das Full-Backup nach /tmp getestet. NI kann nicht in /tmp passen, da viel zu groß mit rund 201 MB, /tmp hat aber nur rund 277 MB. Da der doppelte Platz benötigt wird, käme man auf rund 402 MB + Kernel, das wird bei /tmp mit rund 277 MB natürlich nichts. Mein Image allerdings muß funktionieren (siehe Bild), da es nur rund 108 MB (incl. Senderlogos und anderen Kleinkram) hat.
bkp-duo4k-shot.png
Leider bekommt man (derzeit) nicht mehr RAM frei, keine Ahnung wo das verbraten wird, denn die anderen Boxen haben mehr als 1GB frei - was auch bei der Duo4K eigentlich kein Problem wäre. Müsste man mal mit den Werten spielen beim Kernelstart...


EDIT: Neue Version 1.21 kommt in den nächsten Tagen. Da ist das dann abgefangen, d.h. ist der Platz im Ziel nicht ausreichend, wird abgebrochen. Es werden auch die Größen von Root (Größe x2) und Ziel angezeigt zum Vergleich.

OK
bkp121-duo4k-shot.png
FEHLER
bkp121err-duo4k-shot.png
Bild
Benutzeravatar
BPanther
NI - VIP
Beiträge: 745
Registriert: So 29. Sep 2019, 18:37
Kontaktdaten:

Re: Duo4K - NI-Buildsystem

Beitrag von BPanther »

annie hat geschrieben: Fr 31. Jul 2020, 17:42nur 283 MB Ram ist aber wenig
Ist ja nicht wirklich der gesamte RAM. Der beträgt bei den VU4K Boxen 2 GB - außer bei der Ultimo4K, die hat 3 GB.
tmpfs ist normalerweise immer die hälfte des dem System zur Verfügung stehenden RAM, im Fall der Uno4KSE also 723692 / 2 = 361846 (~353 MB). Bei der Ultimo4K sind es rund 1.6 GB, somit dann rund 790 MB für tmpfs. Teile des RAM gehen u.a. auch für die Grafik drauf, daher kann man nicht die kompletten 2 GB bzw. 3 GB direkt benutzen.
Bild
Benutzeravatar
Janus
NI - VIP
Beiträge: 1138
Registriert: Di 12. Apr 2016, 19:41
Box: HD1, Zee, Neo, Tank, HD51, Duo4K

Re: Duo4K - NI-Buildsystem

Beitrag von Janus »

die Größen von Root (Größe x2)
Das ist sehr pessimistisch gerechnet. Die zweite "Portion" ist ja gepackt und daher entsprechend kleiner. Vielleicht gibt es ja bei den Packer-Doks eine "mittlere Packrate", die man mit zusätzlicher Sicherheit (falls Jemand schon gepackte Dateien auf der Box speichert) dann ansetzt.

Vielleicht kann man auch generell zum Schluss ein "Verhältnis" zwischen Platz im ersten Schritt und Platz im zweiten Schritt ausgeben ==> 1 + [fertiges Backup]/(rootfs+kernel) = 1,xx und das Ergebnis irgendwie weiterverarbeiten.

Zum Beispiel als Mittelwert fortschreiben und in der Konfiguration mit der Zahl der Durchläufe ablegen:

Anzahl = 3
Mittelwert = 1,68
Und im aktuellen Durchgang berechnet: 1,72

Danach zu speichern:
neuer Mittelwert = (Anzahl * Mittelwert + 1,72)/(Anzahl++)
neue Anzahl = Anzahl++

Oder den gewünschten Wert dem Anwender editierbar zur Verfügung stellen.

Und dann anwenderfreundlich gleich zu Beginn des nächsten Backups nur noch die Stellen zur Auswahl anbietet, die ausreichend Platz - (kernel+rootfs)*Mittelwert - zur Verfügung stellen. Das wäre ein Hauch von KI. :sunglasses:
Benutzeravatar
BPanther
NI - VIP
Beiträge: 745
Registriert: So 29. Sep 2019, 18:37
Kontaktdaten:

Re: Duo4K - NI-Buildsystem

Beitrag von BPanther »

Mag sein, daß das recht hoch gegriffen ist als Reserve, aber so ist man auf der sicheren Seite. Zudem kann man nicht global einfach so sagen, daß sich z.B. ein 200 MB Image auf 100 MB packen läßt, da es immer auch auf den Inhalt ankommt. Mal packt es sich besser, mal auch wieder nicht. Beispiele, OATV-E2 (6.4):
Ultimo4K Partition belegt: 640 MB, gepackt als tgz 175 MB, Inhalt des tgz: 185 MB
HD51 Partition belegt: 430 MB, gepackt als tgz 111 MB, Inhalt des tgz: 116 MB

In der Rechnung fehlt aber noch die erste Stufe von bzip2, nämlich das tar. Die ist nirgends berücksichtigt, da die tar-Datei nur kurzzeitig da ist wenn es von tar nach bz2 geht. Aber diese tar ist dabei die größte Datei.
Schauen wir mal als Beispiel bei der Ultimo4K und E2 bei mir: Die tar ist 490 MB. Demnach brauchen wir übergangsweise: 5 MB (Kernel) + 490 MB (Root, tar) + 180 MB (root, bz2) = 675 MB. Im Verhältnis dann zu den eigentlichen 640 MB könnte man durchaus meinen, daß ein Faktor von 1.06 ausreichen würde. Aber das ist nur ein Beispiel und kann sich je nach Imageinhalt und dessen Kompressionsmöglichkeit durchaus ändern. Daher würde ich zumindest auf mindestens 1.5 setzen. Allerdings liegt der bei Dir schon höher wenn 212 MB (root+kernel) zu 283 MB (/tmp) schon nicht reichen mit rund 1.4. Allerdings verstehe ich jetzt nicht wirklich das Problem mit dem Faktor 2. Warum muß immer alles so knapp bemessen werden? Eine HDD oder auch Stick hat doch heutzutage jeder angeschlossen und somit sollten da noch rund 2 GB frei sein - zumal man sicherlich auch mal was aufnehmen will. Und: /tmp (bzw. ein tmpfs) zuzuschaufeln bis aufs letzte Byte ist keine gute Idee.
Janus hat geschrieben: Sa 1. Aug 2020, 10:06Und dann anwenderfreundlich gleich zu Beginn des nächsten Backups nur noch die Stellen zur Auswahl anbietet, die ausreichend Platz - (kernel+rootfs)*Mittelwert - zur Verfügung stellen. Das wäre ein Hauch von KI. :sunglasses:
Ähmm, Du willst allen ernstes erst einen großen Scan machen, was wo frei ist und dann das anzeigen lassen?! Sorry, aber so viel Zeit habe ich nicht. :)
Zudem kann man nicht sagen, daß nur weil z.B. /mnt keinen Platz hat, nicht /mnt/usb doch Platz hat. Da kann man sich leicht vorstellen, wie lange so ein Scan dauern würde aufgrund der Unterverzeichnisse. Wenn Du sowas willst, dann mußt Du das selbst entsprechend einbauen.
Ich für meinen Teil sehe das so: Wer ein Backup macht, sollte schon wissen, wohin er es packen will. Ist dort kein Platz, wird das entsprechend abgefangen - das sollte reichen.


EDIT: Ab sofort auch im GIT. Dann kannst Du 1.72 oder was auch immer statt 2 nehmen wenn es denn soviel ausmacht...
Bild
Benutzeravatar
Janus
NI - VIP
Beiträge: 1138
Registriert: Di 12. Apr 2016, 19:41
Box: HD1, Zee, Neo, Tank, HD51, Duo4K

Re: Duo4K - NI-Buildsystem

Beitrag von Janus »

Manchmal wird bei meiner Duo4K durch einen Start (Neustart oder Kaltstart) die Frontend-Konfiguration auf den "Urzustand" gesetzt.

Ich denke, ich habe den "Schuldigen" gefunden: source/ni-neutrino/data/control/migration.sh

Die Sequenz

Code: Alles auswählen

if [ -e zapit/frontend.conf ]; then
	# uni_qrg was renamed to uni_freq
	sed -i "s|_uni_qrg=|_uni_freq=|g" /var/tuxbox/config/zapit/frontend.conf
fi
geht davon aus, dass frontend.conf in /var/tuxbox/zapit liegt.

Wenn nicht, wird wohl irgendwo eine 'neue' (leere) generiert, die dann gemäß der in femanager.h definierten Konstante FECONFIGFILE gespeichert wird.

Ich habe dieses Angebot der 'Globalisierung' per FECONFIGFILE angenommen und hier bei mir frontend.conf bei allen Linux-Boxen (richtigerweise) in /var/tuxbox/config untergebracht, Die Frontendkonfiguration hat mE Nichts mit Settings sondern mit der am Anschluß vorhandenen Empfangseinrichtung zu tun. Wie satellites.xml, cables.xml usw.
Wer trotzdem unterschiedliche Frontend-Konfigkonfigurationen am gleichen Anschluss braucht, kann ja /var/tuxbox/frontend.conf als Symlink auf zapit/ oder sonstwohin formulieren. (Mache ich für die Tests von Scanfehlern manchmal auch)

Der eigentliche Fehler liegt wohl darin, dass die Definition von FECONFIGFILE nicht mit den anderen Globalisierungskonstanten an der neutrinokompatiblen Stelle - settings.h - sondern (cst_like = sicher abwärtskompatibel) im FEManager gemacht wurde.

Korrekter Fix wäre es wohl, die Definition nach settings.h zu verlegen und das Migration-Script entsprechend anzupassen.
Ich werde hier erstmal in meinen lokalen Branches die if-Sequenz anpassen.
Mal sehen, ob der Folge-Fehler mit der leeren frontend.conf dann weg ist...
Benutzeravatar
Janus
NI - VIP
Beiträge: 1138
Registriert: Di 12. Apr 2016, 19:41
Box: HD1, Zee, Neo, Tank, HD51, Duo4K

Re: Duo4K - NI-Buildsystem

Beitrag von Janus »

Duo4K, 'make update' kurz vor Mittag:

bei 'make personalized-image':
GEN gio-public-headers.txt
CC gvdb/libgio_2_0_la-gvdb-reader.lo
CCLD glib-compile-schemas
CCLD libgio-2.0.la
CCLD gio-querymodules
CCLD glib-compile-resources
CCLD gsettings
CCLD gdbus
CCLD gapplication
CCLD gresource
CCLD gio
/home/janus/development/ni/duo4k/cross/arm-linux-4.1.45-1.17/bin/../lib/gcc/arm-cortex-linux-gnueabihf/6.5.0/../../../../arm-cortex-linux-gnueabihf/bin/ld: warning: libgmodule-2.0.so.0, needed by ./.libs/libgio-2.0.so, not found (try using -rpath or -rpath-link)
/home/janus/development/ni/duo4k/cross/arm-linux-4.1.45-1.17/bin/../lib/gcc/arm-cortex-linux-gnueabihf/6.5.0/../../../../arm-cortex-linux-gnueabihf/bin/ld: ./.libs/libgio-2.0.so: undefined reference to `g_module_close'
/home/janus/development/ni/duo4k/cross/arm-linux-4.1.45-1.17/bin/../lib/gcc/arm-cortex-linux-gnueabihf/6.5.0/../../../../arm-cortex-linux-gnueabihf/bin/ld: ./.libs/libgio-2.0.so: undefined reference to `g_module_symbol'
/home/janus/development/ni/duo4k/cross/arm-linux-4.1.45-1.17/bin/../lib/gcc/arm-cortex-linux-gnueabihf/6.5.0/../../../../arm-cortex-linux-gnueabihf/bin/ld: ./.libs/libgio-2.0.so: undefined reference to `g_module_supported'
/home/janus/development/ni/duo4k/cross/arm-linux-4.1.45-1.17/bin/../lib/gcc/arm-cortex-linux-gnueabihf/6.5.0/../../../../arm-cortex-linux-gnueabihf/bin/ld: ./.libs/libgio-2.0.so: undefined reference to `g_module_open'
/home/janus/development/ni/duo4k/cross/arm-linux-4.1.45-1.17/bin/../lib/gcc/arm-cortex-linux-gnueabihf/6.5.0/../../../../arm-cortex-linux-gnueabihf/bin/ld: ./.libs/libgio-2.0.so: undefined reference to `g_module_error'
collect2: error: ld returned 1 exit status
make[7]: *** [Makefile:2567: gio] Fehler 1
make[6]: *** [Makefile:4724: all-recursive] Fehler 1
make[5]: *** [Makefile:2296: all] Fehler 2
make[4]: *** [Makefile:1280: all-recursive] Fehler 1
make[3]: *** [Makefile:901: all] Fehler 2
make[2]: *** [make/target-libs.mk:1252: glib2] Fehler 2
make[1]: *** [make/ni.mk:60: image] Fehler 2
make: *** [make/ni.mk:24: personalized-image] Fehler 2
janus@vmBuster:~/development/ni/duo4k$
Ich hatte beim Start der VM noch die BusterVM selbst aktualisiert. (apt update & apt upgrade > reboot)
Benutzeravatar
vanhofen
Administrator
Beiträge: 2924
Registriert: Di 5. Apr 2016, 00:05
Has thanked: 2 times
Been thanked: 10 times

Re: Duo4K - NI-Buildsystem

Beitrag von vanhofen »

Der Fehler ist bekannt. Dazu hatte ich von Tangos Buildsystem schon einen Patch geklaut geborgt, der aber bei einem der viele "git --rebase" irgendwie abhanden gekommen ist. :)
Morgen wird das wieder passen.
Benutzeravatar
Janus
NI - VIP
Beiträge: 1138
Registriert: Di 12. Apr 2016, 19:41
Box: HD1, Zee, Neo, Tank, HD51, Duo4K

Re: Duo4K - NI-Buildsystem

Beitrag von Janus »

Da passt noch was nicht:
janus@vmBuster:~/development/ni/duo4k$ ../bs/checkout.script

checkout master BuildSystem
Bereits auf 'master'
Ihr Branch ist auf demselben Stand wie 'origin/master'.
devel
* master
mine

checkout master ni-neutrino
Bereits auf 'master'
Ihr Branch ist auf demselben Stand wie 'origin/master'.
devel
* master
mine
test

checkout master ni-libstb-hal
Bereits auf 'master'
Ihr Branch ist auf demselben Stand wie 'origin/master'.
devel
* master
reset config.local to branch master

janus@vmBuster:~/development/ni/duo4k$ make all-clean
make: support/gnuconfig/config.guess: Kommando nicht gefunden
Makefile:23: support/misc/utils.mk: Datei oder Verzeichnis nicht gefunden
make: *** Keine Regel, um „support/misc/utils.mk“ zu erstellen. Schluss.

janus@vmBuster:~/development/ni/duo4k$ make rebuild-clean
make: support/gnuconfig/config.guess: Kommando nicht gefunden
Makefile:23: support/misc/utils.mk: Datei oder Verzeichnis nicht gefunden
make: *** Keine Regel, um „support/misc/utils.mk“ zu erstellen. Schluss.

janus@vmBuster:~/development/ni/duo4k$ make clean
make: support/gnuconfig/config.guess: Kommando nicht gefunden
Makefile:23: support/misc/utils.mk: Datei oder Verzeichnis nicht gefunden
make: *** Keine Regel, um „support/misc/utils.mk“ zu erstellen. Schluss.

janus@vmBuster:~/development/ni/duo4k$
Benutzeravatar
vanhofen
Administrator
Beiträge: 2924
Registriert: Di 5. Apr 2016, 00:05
Has thanked: 2 times
Been thanked: 10 times

Re: Duo4K - NI-Buildsystem

Beitrag von vanhofen »

Sowohl am Server als auch lokal hab ich gestern einen Probebau gemacht. Da lief alles glatt.
Stehst du auch im Grundverzeichnis des Bildsystems, wenn du die Befehle eingibst?
Benutzeravatar
Janus
NI - VIP
Beiträge: 1138
Registriert: Di 12. Apr 2016, 19:41
Box: HD1, Zee, Neo, Tank, HD51, Duo4K

Re: Duo4K - NI-Buildsystem

Beitrag von Janus »

Stehst du auch im Grundverzeichnis des Bildsystems
Nein!

Ich habe für jede Plattform ein eigenes Verzeichnis in dem die erforderlichen Verzeichnisse ins Grundverzechnis verlinkt sind.

Ich gehe nur ins Grundverzeichnis, um die Updates von BS und den Sourcen durchzuführen.
Das hat auch bis Vorgestern geklappt.

Könnte natürlich sein, dass ich ein paar Änderungen an Struktur und Bezeichnern übersehen habe.
Aber selbst der Gestern durchgeführte Fehlerbuild ist nach diesem Schema abgelaufen.
Benutzeravatar
vanhofen
Administrator
Beiträge: 2924
Registriert: Di 5. Apr 2016, 00:05
Has thanked: 2 times
Been thanked: 10 times

Re: Duo4K - NI-Buildsystem

Beitrag von vanhofen »

OK, dann stelle ich das wieder von relativen auf absolute Pfade um. Dann kannst du deinen Workflow beibehalten.
Benutzeravatar
vanhofen
Administrator
Beiträge: 2924
Registriert: Di 5. Apr 2016, 00:05
Has thanked: 2 times
Been thanked: 10 times

Re: Duo4K - NI-Buildsystem

Beitrag von vanhofen »

Janus hat geschrieben: Mi 24. Feb 2021, 13:33 Ich habe für jede Plattform ein eigenes Verzeichnis in dem die erforderlichen Verzeichnisse ins Grundverzechnis verlinkt sind.
Dann solltest du das neue Verzeichnis "support" auch verlinken. :) Dann klappt das auch mit deinem Konstrukt, ohne dass ich ran muss.
"patches" und "helpers" sind übrigens weggefallen.
Benutzeravatar
Janus
NI - VIP
Beiträge: 1138
Registriert: Di 12. Apr 2016, 19:41
Box: HD1, Zee, Neo, Tank, HD51, Duo4K

Re: Duo4K - NI-Buildsystem

Beitrag von Janus »

Ich hatte das wohl gesehen, aber erstmal die falschen (garkeine) Schlüsse gezogen.
Nach der Anpassung der verkürzten NEUTRINO_BRANCH - Zuweisung lief das ja erstmal an.
Hatte daher erwartet, dass support/ auch erst während des Builds dynamisch (im Plattform-Verzeichnis) angelegt würde.
Sorry, nicht lange genug nachgedacht.

Ich habe jetzt das Verzeichnis manuell verlinkt und mein Script - für spätere Verwendung bei weiteren Plattformen - aktualisiert. Im Moment läuft der Build aber erstmal.
Benutzeravatar
Janus
NI - VIP
Beiträge: 1138
Registriert: Di 12. Apr 2016, 19:41
Box: HD1, Zee, Neo, Tank, HD51, Duo4K

Re: Duo4K - NI-Buildsystem

Beitrag von Janus »

Da scheint mit der Versions-Minderung von dparted in Bezug auf die Duo4K was nicht zu passen:
Dateianhänge
make_clean.log.tar.gz
(6.11 KiB) 155-mal heruntergeladen
Benutzeravatar
max_10
NI - VIP
Beiträge: 162
Registriert: Di 12. Apr 2016, 13:06

Re: Duo4K - NI-Buildsystem

Beitrag von max_10 »

@Janus meine Antwort war nicht richtig, daher gelöscht ;-}
Benutzeravatar
Janus
NI - VIP
Beiträge: 1138
Registriert: Di 12. Apr 2016, 19:41
Box: HD1, Zee, Neo, Tank, HD51, Duo4K

Re: Duo4K - NI-Buildsystem

Beitrag von Janus »

Ich hab den Commit von 28.02. gesehen und nach "make update" nochmal für die Duo4K versucht, u.A. auch ohne meine personalisierte Struktur, also nur in development/ni/bs .
Gleiches Ergebnis!

Ein Gegentest für die HD51 (in der personalisierten Struktur) fliegt nach make 'all-clean' bei 'make clean' an gleicher Stelle raus:
Type 'make' to compile parted.
CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/sh /home/janus/development/ni/hd51/build_tmp/parted-3.2/build-aux/missing aclocal-1.14 -I m4
/home/janus/development/ni/hd51/build_tmp/parted-3.2/build-aux/missing: line 81: aclocal-1.14: command not found
WARNING: 'aclocal-1.14' is missing on your system.
You should only need it if you modified 'acinclude.m4' or
'configure.ac' or m4 files included by 'configure.ac'.
The 'aclocal' program is part of the GNU Automake package:
<http://www.gnu.org/software/automake>
It also requires GNU Autoconf, GNU m4 and Perl in order to run:
<http://www.gnu.org/software/autoconf>
<http://www.gnu.org/software/m4/>
<http://www.perl.org/>
make[1]: *** [Makefile:1223: aclocal.m4] Fehler 127
make: *** [make/host-tools.mk:173: host-parted] Fehler 2
janus@vmBuster:~/development/ni/hd51$
Ist immer noch da...

Da ich vor dem Duo4K-Build auch in development/ni/duo4k mal fast das ganze buildsystem-clean.mk durchge'make'd habe, kann es eigentlich nicht an meiner 'speziellen' Buildumgebung liegen. Das Einzige was ich mir bisher erspart habe, wäre die Crosstools neu zu erzeugen ?!?
Antworten

Zurück zu „Entwicklung“