[gelöst] image bau schlägt fehl

[sattest1]

Hallo flk,
ich wollte mir mal wieder ein neue image bauen. Das hat beim letzten mal, im Oktober 2020, auch alles super geklappt. Ich habe meiner Meinung nach alles so wie beim letzten mal auch gemacht. Aber nun bekomme ich immer diesen Fehler. (siehe Bild,) Woran kann das liegen ?
Ich habe auch einen Auszug der auf meinem angefügten Bild genannten:" log.do_rootfs.19670" Datei mit dem Error hier mal gepostet. Das sagt mir aber so erstmal nichts.

--------------------------------------------------------------------------------

-singlestep QEMU_SINGLESTEP run in singlestep mode
-strace QEMU_STRACE log system calls
-seed QEMU_RAND_SEED Seed for pseudo-random number generator
-trace QEMU_TRACE [[enable=]<pattern>][,events=<file>][,file=<file>]
-version QEMU_VERSION display version information and exit

Defaults:
QEMU_LD_PREFIX = /home/sattest1/yocto/poky/build-hd51/tmp/work/hd51-oe-linux-gnueabi/neutrino-image/1.0-r0/rootfs/linuxrootfs1
QEMU_STACK_SIZE = 8388608 byte

You can use -E and -U options or the QEMU_SET_ENV and
QEMU_UNSET_ENV environment variables to set and unset
environment variables for the target process.
It is possible to provide several variables by separating them
by commas in getsubopt(3) style. Additionally it is possible to
provide the -E and -U options multiple times.
The following lines are equivalent:
-E var1=val2 -E var2=val2 -U LD_PRELOAD -U LD_DEBUG
-E var1=val2,var2=val2 -U LD_PRELOAD,LD_DEBUG
QEMU_SET_ENV=var1=val2,var2=val2 QEMU_UNSET_ENV=LD_PRELOAD,LD_DEBUG
Note that if you provide several changes to a single variable
the last change will stay in effect.

See <https://qemu.org/contribute/report-a-bug> for how to report bugs.
More information on the QEMU project at <https://qemu.org>.

ERROR: The postinstall intercept hook 'update_font_cache' failed, details in /home/sattest1/yocto/poky/build-hd51/tmp/work/hd51-oe-linux-gnueabi/neutrino-image/1.0-r0/temp/log.do_rootfs
DEBUG: Python function do_rootfs finished
--------------------------------------------------------------------------------------------------------

Kannst du oder jemand mir da weiter helfen?

Gruß
Sattest1

[dbt]

Du könntest auch das hier verwenden, dann sieht man in der Ausgabe mehr.

Code: Alles auswählen

bitbake -v neutrino-image

Beim Bauen hat sich allerdings einiges geändert. Bitte sicherstellen, dass auch alle Meta-Layer aktuell sind.

Evtl. ist auch diese Build Variante interessant fürs bauen. Das ist zwar noch nicht offiziell, aber funktionieren müsste es generell schon:

Quick start image build

[sattest1]

hallo dbt,
danke für die info.
ich hatte beim ersten versuch erst nur git pull gemacht und dann gebaut. als das nicht klappte habe ich alles, allso die verzeichnisse yocto/poky mit rm gelöscht und dann komplett von vorne wie auf dem bild auch zu sehen angefangen. sollte denke ich also dann alles auf stand sein. der tipp mit bitbake neutrino-image-v zu bauen bringt dann folgendes am ende, ich hoffe das der auszug genügt:

--------------------------------------------------------------------
epends remove glibc-binary-localedata-de-de glibc-binary-localedata-cs-cz glibc-binary-localedata-es-es glibc-binary-localedata-en-us glibc-binary-localedata-fr-fr glibc-binary-localedata-pl-pl glibc-binary-localedata-ru-ru
NOTE: neutrino-image-1.0-r0 do_rootfs: Removing glibc-binary-localedata-de-de (2.32) from root...
Removing glibc-binary-localedata-cs-cz (2.32) from root...
Removing glibc-binary-localedata-es-es (2.32) from root...
Removing glibc-binary-localedata-en-us (2.32) from root...
Removing glibc-binary-localedata-fr-fr (2.32) from root...
Removing glibc-binary-localedata-pl-pl (2.32) from root...
Removing glibc-binary-localedata-ru-ru (2.32) from root...

NOTE: neutrino-image-1.0-r0 do_rootfs: Running intercept scripts:
NOTE: neutrino-image-1.0-r0 do_rootfs: > Executing update_font_cache intercept ...
NOTE: neutrino-image-1.0-r0 do_rootfs: Exit code 1. Output:
+ [ True = False -a qemuwrapper-cross != nativesdk-qemuwrapper-cross ]
+ qemu-arm -r 3.2.0 -E LD_LIBRARY_PATH=/home/sattest1/yocto/poky/build-hd51/tmp/work/hd51-oe-linux-gnueabi/neutrino-image/1.0-r0/rootfs/linuxrootfs1/usr/lib:/home/sattest1/yocto/poky/build-hd51/tmp/work/hd51-oe-linux-gnueabi/neutrino-image/1.0-r0/rootfs/linuxrootfs1/lib -L /home/sattest1/yocto/poky/build-hd51/tmp/work/hd51-oe-linux-gnueabi/neutrino-image/1.0-r0/rootfs/linuxrootfs1 -E /home/sattest1/yocto/poky/build-hd51/tmp/work/hd51-oe-linux-gnueabi/neutrino-image/1.0-r0/rootfs/linuxrootfs1/usr/libexec/fc-cache --sysroot=/home/sattest1/yocto/poky/build-hd51/tmp/work/hd51-oe-linux-gnueabi/neutrino-image/1.0-r0/rootfs/linuxrootfs1 --system-only
usage: qemu-arm [options] program [arguments...]
Linux CPU emulator (compiled for arm emulation)

Options and associated environment variables:

Argument Env-variable Description
-h print this help
-help
-g port QEMU_GDB wait gdb connection to 'port'
-L path QEMU_LD_PREFIX set the elf interpreter prefix to 'path'
-s size QEMU_STACK_SIZE set the stack size to 'size' bytes
-cpu model QEMU_CPU select CPU (-cpu help for list)
-E var=value QEMU_SET_ENV sets targets environment variable (see below)
-U var QEMU_UNSET_ENV unsets targets environment variable (see below)
-0 argv0 QEMU_ARGV0 forces target process argv[0] to be 'argv0'
-r uname QEMU_UNAME set qemu uname release string to 'uname'
-B address QEMU_GUEST_BASE set guest_base address to 'address'
-R size QEMU_RESERVED_VA reserve 'size' bytes for guest virtual address space
-d item[,...] QEMU_LOG enable logging of specified items (use '-d help' for a list of items)
-dfilter range[,...] QEMU_DFILTER filter logging based on address range
-D logfile QEMU_LOG_FILENAME write logs to 'logfile' (default stderr)
-p pagesize QEMU_PAGESIZE set the host page size to 'pagesize'
-singlestep QEMU_SINGLESTEP run in singlestep mode
-strace QEMU_STRACE log system calls
-seed QEMU_RAND_SEED Seed for pseudo-random number generator
-trace QEMU_TRACE [[enable=]<pattern>][,events=<file>][,file=<file>]
-version QEMU_VERSION display version information and exit

Defaults:
QEMU_LD_PREFIX = /home/sattest1/yocto/poky/build-hd51/tmp/work/hd51-oe-linux-gnueabi/neutrino-image/1.0-r0/rootfs/linuxrootfs1
QEMU_STACK_SIZE = 8388608 byte

You can use -E and -U options or the QEMU_SET_ENV and
QEMU_UNSET_ENV environment variables to set and unset
environment variables for the target process.
It is possible to provide several variables by separating them
by commas in getsubopt(3) style. Additionally it is possible to
provide the -E and -U options multiple times.
The following lines are equivalent:
-E var1=val2 -E var2=val2 -U LD_PRELOAD -U LD_DEBUG
-E var1=val2,var2=val2 -U LD_PRELOAD,LD_DEBUG
QEMU_SET_ENV=var1=val2,var2=val2 QEMU_UNSET_ENV=LD_PRELOAD,LD_DEBUG
Note that if you provide several changes to a single variable
the last change will stay in effect.

See <https://qemu.org/contribute/report-a-bug> for how to report bugs.
More information on the QEMU project at <https://qemu.org>.

ERROR: neutrino-image-1.0-r0 do_rootfs: The postinstall intercept hook 'update_font_cache' failed, details in /home/sattest1/yocto/poky/build-hd51/tmp/work/hd51-oe-linux-gnueabi/neutrino-image/1.0-r0/temp/log.do_rootfs
ERROR: Logfile of failure stored in: /home/sattest1/yocto/poky/build-hd51/tmp/work/hd51-oe-linux-gnueabi/neutrino-image/1.0-r0/temp/log.do_rootfs.18253
ERROR: Task (/home/sattest1/yocto/poky/meta-neutrino/recipes-images/images/neutrino-image.bb:do_rootfs) failed with exit code '1'
NOTE: Tasks Summary: Attempted 4673 tasks of which 4672 didn't need to be rerun and 1 failed.

Summary: 1 task failed:
/home/sattest1/yocto/poky/meta-neutrino/recipes-images/images/neutrino-image.bb:do_rootfs
Summary: There was 1 WARNING message shown.
Summary: There was 1 ERROR message shown, returning a non-zero exit code.
--------------------------------------------------------

scheinbar passt da was mit " qemu " nicht richtig. kenn mich aber damit nicht aus.

ich versuche jetzt auch mal den link von dir mit dem how to do, aber vielleicht kann man mit dieser neuen info ja auch was anfangen um das problem zu erkennen bzw. zu lösen.
werde dann auch berichten wie es mit dem neuen how to do dann gelaufen ist, aber das dauert ja immer ne weile

[sattest1]

hallo dbt,

ich habe nun alles nochmal komplett von anfang an gemacht.
ich habe dafür dann zu sicherheit auch die in dem link angebotene tuxuser debian10.vmdk genommen und dann das how to do abgearbeitet. aber leider kommt dann auch der "do_rootfs" fehler

was ist denn da bloss falsch ?
hast du oder jemand eine idee / lösung ?!

gruß
sattest1

[dbt]

Code: Alles auswählen

 gdk-pixbuf-query-loaders: not found

Das grenzt die Sache schon mal ein. Aber zumindest ist bei dir eigentlich so weit alles gebaut. Nur das Image wird nicht zusammengebacken. Kannst du bitte mal die Logdatei posten? Zu finden ist der Pfad in der zweiten ERROR Meldung log.do_rootfs.4491.

Es könnte daran liegen, dass mit sstate-cache Mirror eine Abhängigkeit eingeschleppt wurde, die hier aufschlägt. Bin mir da aber nicht sicher. Hast du die Konfiguration so belassen oder etwas geändert?

[sattest1]

hallo dbt, bitte sehr.
da steht was von: ..../gdk-pixbuf-2.0/gdk-pixbuf-query-loaders: not found.... drin wenn ich das richtig verstehe. was fehlt denn da?

zur frage ob ich was geändert hatte, ja "flavor: tango". aber auch ohne also mit den default einstellungen war / ist der fehler da.

gruß
sattest1

[dbt]

Seltsam ist das schon. Auf dem System müsste das eigentlich drauf sein. Da bin ich etwas ratlos. Hast du ein apt update und upgrade gemacht? Ansonsten hat evtl. flk noch eine Idee. Könnte auch sein, dass im poky selbst dieses Paket fehlt, aber so wie ich das einschätze, müsste das da auch drin sein. Ich lass momentan alles selbst noch durch bauen, aber bisher keine Probleme gehabt.

[sattest1]

hallo dbt, ja dann bin ich ja mal gespannt. hoffendlich mit dem selben problem währe sonst schon sehr komisch

du baust zum testen dann auch mit dem tuxbox bilder debian vmdk image aus dem forum um die gleichen vorassetzungen zu haben oder?
was flk betrifft, er hat das scheinbar noch nicht mitbekommen, ich hoffe das er es dann lösen kann.

[sattest1]

hi dbt,
hast du schon ein ergebnis. hat der build bei dir auch fehler ?
gruß
sattest1

[dbt]

Also auf meinem nativen System, auch mit Buster und dieser Methode, hat das ohne Probleme durchgebaut. Auch mit FLAVOUR="tango" , als einzige Änderung in der Konfiguration, welche in "local.conf.common.inc" vorzunehmen wäre. Ich hoffe du hast das auch dort gemacht, also nicht in ../hd51/conf/local.conf

Man muss da auch nicht zwingend die VM nehmen. Das müsste so genauso gut gehen, ist ja im Prinzip auch nichts anderes, baut auch normalerweise schneller. Die Images auf dem Server werden auch auf diese Art gebaut, nur eben anders konfiguriert.

Was du noch probieren könntest, wäre in deinem build-Ordner unter ../hd51 mal den tmp Ordner umzubennen oder zu löschen, das gleiche mit dem sstate-cache Ordner. In der Konfigurationsdatei "local.conf.common.inc" kommentierst du mal den sstate-Mirroreintrag aus, also die Zeilen 231-233 aus:

Code: Alles auswählen

SSTATE_MIRRORS = "\
     file://.* https://sstate.tuxbox-upload.de/all/sstate-cache/PATH;downloadfilename=PATH \n \
"

machst du das:

Code: Alles auswählen

#SSTATE_MIRRORS = "\
#     file://.* https://sstate.tuxbox-upload.de/all/sstate-cache/PATH;downloadfilename=PATH \n \
#"

Nur zur Sicherheit damit nichts eingeschleppt wird. Das Bauen dürfte dann zwar länger dauern, aber damit wird das Buildsystem gezwungen alles selbst zu bauen und holt sich nichts von Ausserhalb.

[sattest1]

Hallo dbt,
ich habe den Test mit der Anpassung in der conf Datei wie du es beschreibst, jetzt auch einmal versucht aber leider schlägt der Build damit auch fehl.
Da scheinbar gerade ziemlich wenige selber was basteln habe ich mal einen Bekannten gebeten sich Oracle VirtualBox zu installieren und auch mal zu versuchen das Build mit der hier bereitgestellten vmdk nach dem "how to" do zu bauen und gleiches Probelm !!
Nun läuft dort zwar gerade noch der 2te versuch mit der Änderung in der conf Datei ( läuft ja immer ewig und auf dem „I5“ noch läääännngggeeerr ) , aber ich lehne mich mal aus dem Fenster und sag mal das der Build auch nicht geht.
Das einzige was auch dort, zusätzlich zu dem im how to do beschriebenen Ablauf noch gemacht werden musste, ist einmal ab dem „Build Verzeichnis“ die rechte mit chmod -R 777 umzustellen. Ohne das geht es mit dem "TuxUser" nicht, aber das sollte ja nichts negativ beeinflussen, oder ?
Hattest du bei deinem Test denn auch mit der dem vmdk Image geprüft ?

Ps. Könntest du mir ggf. das „TANGO“ Build hochladen falls es keine Idee mehr bzw. Lösung zu diesem Problem in Sicht ist. Würde aber gerne selber wieder was bauen können.

Gruß
sattest1

[dbt]

Habe dir eine PM geschickt, schau mal, ob du damit zurechtkommst.

Das Problem müsste aber lösbar sein. Ich versuchs auch weiter.

[sattest1]

Danke für die Info.

Hier mal kurz weitere Infos vom 2ten System.
Was ich schon befürchtet habe ist nun auch dort passiert.
Ich habe da mal versucht den Ablauf etwas zu dokumentieren, hoffe das ist soweit selbst erklärend siehe Bild:

[dbt]

Ich kann auf den Bildern leider optisch nicht viel erkennen. Text würde sich da besser machen.

Habe übrigens gestern die VM nochmal frisch initialisiert, also ./init.sh ausgeführt, dann als einzige Anpassung an der Konfiguration die Parallel Makes, Threads angepasst und FLAVOUR="tango" umgestellt. Alles ohne Probleme durchgebaut.

local.conf.common.inc.zip

Was bei Dir schiefläuft, verstehe ich nicht wirklich. Jetzt eben nochmal ein Build angeschubst, alles OK.
tuxbox@tuxbox-builder:~$ cd build
tuxbox@tuxbox-builder:~/build$ cd poky-3.2
tuxbox@tuxbox-builder:~/build/poky-3.2$ . ./oe-init-build-env hd51

### Shell environment set up for builds. ###

You can now run 'bitbake <target>'

Common targets are:
core-image-minimal
core-image-sato
meta-toolchain
meta-ide-support

You can also run generated qemu images with a command like 'runqemu qemux86'

Other commonly useful commands are:
- 'devtool' and 'recipetool' handle common recipe tasks
- 'bitbake-layers' handles common layer tasks
- 'oe-pkgdata-util' handles common target package tasks
tuxbox@tuxbox-builder:~/build/poky-3.2/hd51$ bitbake neutrino-image
NOTE: Started PRServer with DBfile: /home/tuxbox/build/poky-3.2/hd51/cache/prserv.sqlite3, IP: 127.0.0.1, PORT: 34403, PID: 2093
Loading cache: 100% |###########################################################################################################################################################################################################################################| Time: 0:00:03
Loaded 2944 entries from dependency cache.
Parsing recipes: 100% |#########################################################################################################################################################################################################################################| Time: 0:00:10
Parsing of 1967 .bb files complete (1725 cached, 242 parsed). 3192 targets, 197 skipped, 0 masked, 0 errors.
WARNING: No recipes in default available for:
/home/tuxbox/build/poky-3.2/meta-hd51/recipes-qt/qt5/qtbase_git.bbappend
/home/tuxbox/build/poky-3.2/meta-neutrino/recipes-qt/qt5/qtdeclarative_git.bbappend
/home/tuxbox/build/poky-3.2/meta-neutrino/recipes-qt/qt5/qtgraphicaleffects_git.bbappend
/home/tuxbox/build/poky-3.2/meta-neutrino/recipes-qt/qt5/qtlocation_git.bbappend
/home/tuxbox/build/poky-3.2/meta-neutrino/recipes-qt/qt5/qtquickcontrols2_git.bbappend
/home/tuxbox/build/poky-3.2/meta-neutrino/recipes-qt/qt5/qtquickcontrols_git.bbappend
/home/tuxbox/build/poky-3.2/meta-neutrino/recipes-qt/qt5/qtsensors_git.bbappend
/home/tuxbox/build/poky-3.2/meta-neutrino/recipes-qt/qt5/qtsvg_git.bbappend
/home/tuxbox/build/poky-3.2/meta-neutrino/recipes-qt/qt5/qtvirtualkeyboard_git.bbappend
/home/tuxbox/build/poky-3.2/meta-neutrino/recipes-qt/qt5/qtwebchannel_git.bbappend
/home/tuxbox/build/poky-3.2/meta-neutrino/recipes-qt/qt5/qtwebengine_git.bbappend
/home/tuxbox/build/poky-3.2/meta-neutrino/recipes-qt/qt5/qtxmlpatterns_git.bbappend
Removing 1 recipes from the cortexa15hf-neon-vfpv4 sysroot: 100% |##############################################################################################################################################################################################| Time: 0:00:02
Removing 1 recipes from the hd51 sysroot: 100% |################################################################################################################################################################################################################| Time: 0:00:00
NOTE: Resolving any missing task queue dependencies

Build Configuration:
BB_VERSION = "1.48.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING = "universal"
TARGET_SYS = "arm-oe-linux-gnueabi"
MACHINE = "hd51"
DISTRO = "tuxbox"
DISTRO_VERSION = "gatesgarth"
TUNE_FEATURES = "arm vfp cortexa15 neon vfpv4 callconvention-hard"
TARGET_FPU = "hard"
meta
meta-poky
meta-yocto-bsp = "heads/3.2:9de9e2e3194525c8eea57ebc3c7396b4695549a7"
meta-neutrino = "gatesgarth:92f280ce06413dab79fc9672ff8674977f052a01"
meta-hd51 = "gatesgarth:bf52a415fb2d40ebddae11cd7b5b98b8203eaa86"
meta-python2 = "3.2:b8b61fce1e91dc0767339d0ee9088cfba84d5684"

Initialising tasks: 100% |######################################################################################################################################################################################################################################| Time: 0:00:04
Sstate summary: Wanted 40 Found 7 Missed 33 Current 1689 (17% match, 98% complete)
NOTE: Executing Tasks
NOTE: Tasks Summary: Attempted 4681 tasks of which 4636 didn't need to be rerun and all succeeded.

Summary: There was 1 WARNING message shown.
tuxbox@tuxbox-builder:~/build/poky-3.2/hd51$

[sattest1]

Hallo dbt, kapier ich nicht.
Hier mal kurz noch einmal mein Ablauf:

- Unter Oracle VirtualBox auf meinem Win 10 Notebook die hier bereitgestellte Debian VMDK Maschine gestartet
- Dann mit dem TuxBox User angemeldet
- Das how to do vom hier durchgearbeitet
- Wie schon geschrieben einmal ab dem Build Verzeichnis chmod -R 777 damit es überhaupt geht
- In der „local.conf.common.inc“ nur auf Tango umgestellt sonst nichts weiter
- Gestartet, dann kommen die, zugegeben auf den Bildern recht schlecht zu erkennenden einige Warnungen und der Build läuft

Es dauert auf meinem System dann ca. 10 - 11 Std. bis dann der Fehler bei 99% kommt.
Meine Umgebung auf der ich das mache:
Logische Maschine in der VirtualBox mit 4 GB RAM auf Win 10 mit einem I7, 8 GB RAM und einer SSD

Was könnte denn dann da falsch sein ?! Ich mache heute mit deiner "local.conf.common.inc" einen neuen Versuch.

Ps. Image aus der PM läuft Thx dafür. Würde aber gerne das Thema hier in den Griff kriegen für spätere Bulids

[sattest1]

Hallo dbt,
danke für deine genaue Beschreibung.
Ich habe mir nun meine Ausgaben nochmal "ganz genau" angesehen und mit deiner verglichen.
Bei mir kamen beim ". ./oe-init-build-env hd51" im Unterschied zu deiner allerdings die 2 von mir hier jetzt mal farblich abgesetzten "WARING" Infos. Die sind in der Ausgabe leider nicht farblich, fielen mir also nicht wirklich auf da ja die anderen WARNING Meldungen immer in Farbe kommen und viele auch nur als INFO und quasi ignoriert werden können, gedacht sind. Vielleicht kann man das ja einheitlich gestalten und alle WARNIG Meldungen farblich machen.
Beim erstellen des " oe-init-build-env", wo es ja besonders wichtig, vielleicht auch direkt als ERROR und dann Stop, dann kommt man eher drauf wo ein Fehler liegen kann.

-------------------------------------------------------------------------------------------
tuxbox@tuxbox-builder:~/build____/poky-3.2$ . ./oe-init-build-env hd51
WARNING: unable to chmod /home/tuxbox/build____/poky-3.2/hd51
WARNING: unable to chmod /home/tuxbox/build____/poky-3.2/hd51/conf

### Shell environment set up for builds. ###

You can now run 'bitbake <target>'

Common targets are:
core-image-minimal
core-image-sato
meta-toolchain
meta-ide-support

You can also run generated qemu images with a command like 'runqemu qemux86'

Other commonly useful commands are:
- 'devtool' and 'recipetool' handle common recipe tasks
- 'bitbake-layers' handles common layer tasks
- 'oe-pkgdata-util' handles common target package tasks
tuxbox@tuxbox-builder:~/build____/poky-3.2/hd51$
----------------------------------------------------------------------------------------------

Also habe ich mal geprüft wieso das bei mir kommt und was soll ich sagen, der "chmod" wie ich ja im meinem post beschrieben hatte hat es verursacht !!
Habe also alles noch mal ohne den vorbereitet die WARNING Meldung kam nicht mehr und er baute ohne Fehle durch.
Was mich nur wundert, das hab ich früher immer machen müssen sonst hat es gar nicht funktioniert. Und wieso ein "chmod 777" das verursachen kann ist mir jetzt auch nicht klar. "777" bedeutet doch eigentlich nur "feuer frei" ums mal platt zu formulieren. Vielleicht kannst du mir das ja erklären, aber wichtiger der Fehler ist gefunden und es läuft!
Danke nochmal

[dbt]

Warum chmod da notwendig sein sollte, erschließt sich mir nicht. Die Initialisierung sollte eigentlich davon unabhängig die Ordner und Dateien passend anlegen. Jedenfalls hatte ich dieses Problem bisher nicht. Egal ob man das auf der VM oder auf einem nativen System macht. Aber egal. Sehr schön, dass es jetzt bei dir baut. Ich wollte es nur nochmal betonen: Die VM ist nicht zwingend, aber für Windows Nutzer sicher eine Idee mal da reinzuschnuppern.

Nur am Rande. Man hadert immer gerne damit, dass der Bauvorgang mit Yocto sooo lange dauert. Ohne gewisse Maßnahmen ist das in der Regel zumindest beim ersten Mal immer so, aber wenn Du deine zukünftigen Bauvorgänge beschleunigen willst, dann recycle einfach deinen cache, indem Du den sstate-Ordner an einen "sicheren" Ort verschiebst und den als sstate-Mirror verwendest und das in der Konfiguration einträgst. Man muss nur den Eintrag anpassen, den ich dir neulich schon mal gezeigt hatte.
Also aus dem Eintrag:

Code: Alles auswählen

SSTATE_MIRRORS = "\
     file://.* https://sstate.tuxbox-upload.de/all/sstate-cache/PATH;downloadfilename=PATH \n \
"

das machen:

Code: Alles auswählen

SSTATE_MIRRORS = "\
     file://.* file:///<Pfad/zu/deinem/sstate-cache>/PATH;downloadfilename=PATH \n \
     file://.* https://sstate.tuxbox-upload.de/all/sstate-cache/PATH;downloadfilename=PATH \n \
"

Angenommen du würdest in deinem Build Ordner /tmp und /sstate-cache gelöscht haben und quasi bei Null anfangen,
würde es im Optimalfall bei 100% nutzbarem Cache nur wenige Minuten dauern. Bei der Vorgabe in der Standardkonfiguration, welche an den sstate-cache vom Server angebunden ist, könnten es so um die 20-50% sein. Naturgemäß hat man damit aber wohl kaum 100% aber die Wirkung ist allemal zu spüren. Ohne Bambusleitung natürlich Es gibt da noch so einige Kniffe. Da ergibt sich sicherlich noch die eine oder andere Gelegenheit, da mal drauf einzugehen.

[sattest1]

kilngt supper, werde das bei mir für die nächsten builds dann so machen, denn so ist es für einen "schnellen test mal gerade" (über 10 Stunden ja echt .... )
danke erst mal und ja die nächste Frage kommt bestimmt