meta-stlinux

[dbt]

Hat mir jetzt keine Ruhe gelassen und das Downloadarchiv mit dem was neutrino zu tun hat gelöscht:

Code: Alles auswählen

git2> sudo rm -rf *github*neutrino*

Die lokalen Änderungen am Repo rückgängig gemacht, dann nochmal versucht alles zu ziehen.

Code: Alles auswählen

bitbake -c fetchall neutrino-image

und geht

Was da jetzt kaputt war, würde ich gerne wissen wollen, aber es scheint erstmal alles gut zu sein. Das muss erstmal reichen. Sorry falls ich Verwirrung gestiftet habe.

[doc]

Ich hätte ja nicht gedacht das Debian mal zu neu ist aber es dauerte eine Weil bis ich herausgefunden hatte das der html5lib Kram im krogroth Branch auf eine ältere Version setzt. Anyway.

Bei mir klappt der Download der Archive nicht so ganz, giflib-5.0.5-r3 gibt es tatsächlich nicht auf Sourceforge.

Code: Alles auswählen

ERROR: lirc-0.9.0-r4.4 do_fetch: Fetcher failure: Fetch command failed with exit code 8, output:
20 redirections exceeded.

ERROR: lirc-0.9.0-r4.4 do_fetch: Function failed: Fetcher failure for URL: 'https://prdownloads.sourceforge.net/lirc/lirc-0.9.0.tar.bz2'. Unable to fetch URL from any source.
ERROR: Logfile of failure stored in: /data/yocto/yocto-poky-stl/build-stl/tmp/work/spark-poky-linux/lirc/0.9.0-r4.4/temp/log.do_fetch.32657
ERROR: Task 102 (/data/yocto/yocto-poky-stl/meta-stlinux/recipes-extended/lirc/lirc_0.9.0.bb, do_fetch) failed with exit code '1'
ERROR: giflib-5.0.5-r3 do_fetch: Fetcher failure: Fetch command failed with exit code 8, output:
20 redirections exceeded.

ERROR: giflib-5.0.5-r3 do_fetch: Function failed: Fetcher failure for URL: 'http://downloads.sourceforge.net/giflib/giflib-5.0.5.tar.bz2'. Unable to fetch URL from any source.
ERROR: Logfile of failure stored in: /data/yocto/yocto-poky-stl/build-stl/tmp/work/sh4-poky-linux/giflib/5.0.5-r3/temp/log.do_fetch.32658
ERROR: Task 73 (/data/yocto/yocto-poky-stl/meta-neutrino-mp/recipes-local/giflib/giflib_5.0.5.bb, do_fetch) failed with exit code '1'

Kann es sein das die gewünschten Versionen schon wieder zu alt für Sourceforge & Co sind?
giflib ist bei 5.1.4, lircd ist bei 0.9.4

[dbt]

Bei giflib scheint es das gleiche Problem zu sein, wie ich es bei lirc die Tage hatte. Die haben bei Sourceforge alles auf https umgeleitet. Das scheint bei mir nicht aufgefallen zu sein, weil ich das Paket schon in meinem Downloadarchiv drin hatte, aber das Lircpaket noch nicht. Es liegt nahe, dass man die Protokolle generell bei allen SF Downloads anpassen müsste.

[seife]

Also bei mir geht es ohne https. Das muss irgendwas mit dem host-system / internetprovider / whatever zu tun haben.

Der fetcher verwendet z.B. wget vom Host. Vielleicht könnt ihr ja mal versuchen ob ihr die Links mittels wget runterladen könnt?

Ansonsten ist es prinzipiell fast jede downloadquelle besser als sourceforge , also vor wir alles auf https umstellen ohne zu wissen warum, sollten wir vielleicht andere archive suchen.

@doc: html5lib? Bahnhof?

Edit: gerade noch mal probiert:

Code: Alles auswählen

WARNING: libpcre-8.38-r0 do_fetch: Failed to fetch URL ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/pcre-8.38.tar.bz2, attempting MIRRORS if available
WARNING: zlib-1.2.8-r0 do_fetch: Failed to fetch URL http://www.zlib.net/zlib-1.2.8.tar.xz, attempting MIRRORS if available
NOTE: Tasks Summary: Attempted 196 tasks of which 0 didn't need to be rerun and all succeeded.

Das war das runme.sh im docker-container (dieses mal mit 42.2 basis, aber gestern mit 13.2 gings auch)

[doc]

In der Tat funktioniert der Download wenn man http only per wget benutzt. Nur am dem T-Company Business Anschluss wo ich gerade sitzt funktioniert eben auch https. Damit dürfte Sourceforge dann raus sein als Übeltäter. Aber gut, dazu redet man ja miteinander um heraus zu finden woran es nun liegt.

@dbt
giflib wurde laut Log nicht auf https umgeleitet, aber das wäre jetzt alles Spekulation. Kann ich erst später heute prüfen wenn ich wieder an der Kiste zu Hause sitze.

@seife
Poky benutzt das Python Modul html5lib, der krogoth Branch importiert Klassen die aber eine Version kleiner 0.999999999 voraussetzen (auf so Versionsnummern können nur Webentwickler kommen). Da ich Debian testing benutze bin ich in dieses Problem gerutscht was mich als nicht Python Wissenden einige Zeit gekostet hat die Fehlermeldung zu interpretieren und den Fix zu finden. Habe dazu einen Hinweis im Wiki hinterlassen.

Hinweis html5lib in Debian Testing
sed Einzeiler zum Anpassen

[dbt]

Mal nur mit wget vom Host runtergeladen geht hier auch beides. Alles über Suse13.2 auf VM. Habe T-Com Zugang über Fritzbox. Evtl. Ist da ja ein Filter drin von dem ich nix weiß.
Das war zuerst mit der momentan installierten Version 1.16, habe aber gerade auf 1.18 aktualisiert, da ging das auch.

[seife]

die python-html5lib einfach deinstallieren hätte wohl auch geholfen -- die ist bei mir nirgends installiert

Ich werde die Dockerfiles mal irgenwo veröffentlichen, dann kannst du dir in wenigen Minuten einen Container bauen mit dem es bekanntermassen funktioniert und musst dich nicht mit dem debian rumärgern .

[doc]

Keine Ahnung welche der Abhängigkeiten das python-html5lib gezogen hatte, aber egal, klappt trotzdem noch nicht.

Nun hängt es beim Bauen von meta-stlinux/recipes-devtools/gcc-stlinux/gcc-cross_4.8.bb. Ich vermute mal das es mit dem Host GCC zusammenhängt, testing hat einen GCC 6.2.1 aktuell. Ich hänge mal den Log an.

Code: Alles auswählen

| In file included from ./tm.h:75:0,
|                  from ../../../../../../../work-shared/gcc-4.8.4-r1/gcc-4.8.4/gcc/cp/except.c:27:
| ././defaults.h:127:24: warning: invalid suffix on literal; C++11 requires a space between literal and string macro [-Wliteral-suffix]
|        fprintf ((FILE), ","HOST_WIDE_INT_PRINT_UNSIGNED",%u\n",  \
|                         ^
| In file included from ../../../../../../../work-shared/gcc-4.8.4-r1/gcc-4.8.4/gcc/cp/except.c:1008:0:
| cfns.gperf: In function 'const char* libc_name_p(const char*, unsigned int)':
| cfns.gperf:101:1: error: 'const char* libc_name_p(const char*, unsigned int)' redeclared inline with 'gnu_inline' attribute
| cfns.gperf:26:14: note: 'const char* libc_name_p(const char*, unsigned int)' previously declared here
| cfns.gperf: At global scope:
| cfns.gperf:26:14: warning: inline function 'const char* libc_name_p(const char*, unsigned int)' used but never defined
| Makefile:1059: recipe for target 'cp/except.o' failed

[seife]

könnte sowas sein:
https://patchwork.openembedded.org/patch/122457/

(der entsprechende code sieht in gcc 4.8 ähnlich aus wie in 4.9)

Edit: sollte jetzt gehen, es hat noch nicht ganz durchgebaut, aber die kritische stelle ist glaube ich überschritten.

[doc]

Das sieht gut aus! Danke!

Ich hatte zuerst den ccache im Verdacht aber nachdem der Fehler exakt gleich ohne einkonfigurierten ccache auch aufgetreten war ...

Nun hängt es zum Schluss noch etwas beim zusammen dengeln des Images, nur heute habe ich da keinen Nerv mehr zu weiter zu schauen.

Code: Alles auswählen

ERROR: neutrino-image-1.0-r0 do_rootfs: Cannot get the installed packages list. Command '/data/yocto/yocto-poky-stl/build-stl/tmp/sysroots/x86_64-linux/usr/bin/opkg -f /data/yocto/yocto-poky-stl/build-stl/tmp/work/spark-poky-linux/neutrino-image/1.0-r0/opkg.conf -o /data/yocto/yocto-poky-stl/build-stl/tmp/work/spark-poky-linux/neutrino-image/1.0-r0/rootfs  --force_postinstall --prefer-arch-to-version   status' returned 0 and stderr:
No real function for mknod: /data/yocto/yocto-poky-stl/build-stl/tmp/sysroots/x86_64-linux/usr/bin/../lib/pseudo/lib64/libpseudo.so: undefined symbol: mknod
No real function for mknodat: /data/yocto/yocto-poky-stl/build-stl/tmp/sysroots/x86_64-linux/usr/bin/../lib/pseudo/lib64/libpseudo.so: undefined symbol: mknodat
No real function for mknod: /data/yocto/yocto-poky-stl/build-stl/tmp/sysroots/x86_64-linux/usr/bin/../lib/pseudo/lib64/libpseudo.so: undefined symbol: mknod
No real function for mknodat: /data/yocto/yocto-poky-stl/build-stl/tmp/sysroots/x86_64-linux/usr/bin/../lib/pseudo/lib64/libpseudo.so: undefined symbol: mknodat

ERROR: neutrino-image-1.0-r0 do_rootfs: Function failed: do_rootfs
ERROR: Logfile of failure stored in: /data/yocto/yocto-poky-stl/build-stl/tmp/work/spark-poky-linux/neutrino-image/1.0-r0/temp/log.do_rootfs.22349
ERROR: Task 9 (/data/yocto/yocto-poky-stl/meta-neutrino-mp/recipes-images/images/neutrino-image.bb, do_rootfs) failed with exit code '1'
NOTE: Tasks Summary: Attempted 2120 tasks of which 887 didn't need to be rerun and 1 failed.
No currently running tasks (2120 of 2127)

Summary: 1 task failed:
  /data/yocto/yocto-poky-stl/meta-neutrino-mp/recipes-images/images/neutrino-image.bb, do_rootfs

[seife]

Herr Doktor, selber googeln bitte!

Diesen commit (morty, bestimmt auch irgendwo im master mal gewesen) zurückportieren:
e090775f7e3b4af2345e835bbebcd5d4a580798b

Dann gehts auch.
Am besten upstream-openembedded oder yocto dazu bringen, das noch nach krogoth zu importieren.

Wenn das mit einem debian release nicht geht, dann ist das ja schon ein major bug. Mit openSUSE releases gehts, nur mit tumbleweed nicht.

Edit: habe es grad nachgelesen, "debian testing" ist ja so wie "openSUSE Tumbleweed ohne openqa", also wesentlich instabiler -- "it builds - let's ship it". Da wirst du immer Schmerzen haben. Ich empfehle dir einen docker container (oder ein einfaches chroot) mit einer nich-rolling release zum OE bauen, sonst musst du dauernd irgendwelche "bugs" finden / fixen, die mit dem eigentlichen Problem nix zu tun haben. Nicht umsonst teste ich normalerweise auch nicht mehr auf dem Tumbleweed-Notebook

[doc]

Ich bin da schon bei Dir, aber am 5.2. ist Komplettfreeze vom derzeitigen Testing Release genannten Zweig Debians. Heißt, da wird sich ab dann nichts mehr an Versionen oder Paketen ändern. Und schon jetzt sind gibt es faktisch keine bedeutenden Änderungen mehr an Versionen weil das schon eingefroren ist. Und ich denke es macht schon Sinn sich mit dem kommenden stabilen Release jetzt zu beschäftigen. Danke für den Hinweis, versuche das mal zusammen zu setzen.

PS: Ich bin Dir sehr dankbar das Du das alles pflegst und benutzbar hältst. Mir fehlt dazu in letzter Zeit immer mehr die nötige Zeit und auch Lust sich im Detail damit zu beschäftigen.

[dbt]

Wieder kleiner Fehler mit bitbake neutrino-image:

Code: Alles auswählen

Configuring e2fsprogs-mkCollected errors:
 * satisfy_dependencies_for: Cannot satisfy the following dependencies for packagegroup-core-boot:
 *      libasound2 (>= 1.1.0) * 
 * opkg_install: Cannot install package packagegroup-core-boot.
e2fs.
Configuring neutrino-feed-config.
Configuring udev-extraconf.

ERROR: neutrino-image-1.0-r0 do_rootfs: Function failed: do_rootfs
ERROR: Logfile of failure stored in: /home/dbt/devel/yocto/poky-stl/build-stl/tmp/work/spark-poky-linux/neutrino-image/1.0-r0/temp/log.do_rootfs.2098
ERROR: Task 9 (/home/dbt/devel/yocto/poky-stl/meta-neutrino-mp/recipes-images/images/neutrino-image.bb, do_rootfs) failed with exit code '1'
NOTE: Tasks Summary: Attempted 2851 tasks of which 2850 didn't need to be rerun and 1 failed.
No currently running tasks (2420 of 2858)

Summary: 1 task failed:
  /home/dbt/devel/yocto/poky-stl/meta-neutrino-mp/recipes-images/images/neutrino-image.bb, do_rootfs
Summary: There was 1 WARNING message shown.
Summary: There were 2 ERROR messages shown, returning a non-zero exit code.
dbt@linux-11-3:~/devel/yocto/poky-stl/build-stl> 

run.do_rootfs.2098.txt

Dass da opkg wegen Abhängigkeiten manchmal rumzickt, ist aber nicht das erste mal.

[seife]

bei mir gehts.
Dein Output sieht seltsam aus.
Die Informationen um das zu beurteilen fehlen.

Schau halt, warum libasound nicht da ist.
Aber daß lirc überhaupt auf alsa depended ist schon mal seltsam...

[seife]

lirc sollte jetzt nicht mehr gegen alsa bauen, auch wenn es da ist.

[dbt]

Das hat schon mal was gebracht, aber gerade gebaut da hängts hier:

Code: Alles auswählen

...                                                                                                                                                                                                   
Configuring opkg.                                                                                                                                                                                                                                                             
Configuring kernel-module-snd-usb-audio.                                                                                                                                                                                                                                      
Configuring libcom-err2.                                                                                                                                                                                                                                                      
Configuring busybox-telnetd.                                                                                                                                                                                                                                                  
busybox-telnetd.postinst returned 1, marking as unpacked only, configuration required on target.                                                                                                                                                                              
Configuring busybox-udhcpc.                                                                                                                                                                                                                                                   
Configuring busybox-inetd.                                                                                                                                                                                                                                                    
Configuring busybox.                                                                                                                                                                                                                                                          
Configuring kernel-module-uinput.                                                                                                                                                                                                                                             
Configuring lirc.                                                                                                                                                                                                                                                             
Configuring lirc-exec.                                                                                                                                                                                                                                                        
Configuring mtd-utils-misc.                                                                                                                                                                                                                                                   
Configuring strace.                                                                                                                                                                                                                                                           
Configuring modutils-initscripts.                                                                                                                                                                                                                                             
Configuring initscripts-functions.                                                                                                                                                                                                                                            
Configuring kernel-module-snd-hwdep.                                                                                                                                                                                                                                          
Configuring kernel-module-ftdi-sio.
Configuring kernel-module-autofs4.
Configuring kernel-module-zd1201.
Configuring kernel-module-snd-usb-lib.
Configuring kernel-module-snd-rawmidi.
Configuring kernel-module-usbserial.
Configuring kernel-module-scsi-wait-scan.
Configuring kernel-modules.
Configuring libuuid1.
Configuring base-files.
Configuring sysvinit-inittab.
Configuring liblzo2-2.
Configuring mtd-utils-jffs2.
Configuring initscripts.
Configuring libtinfo5.
Configuring image-config.
Configuring libblkid1.
Configuring stlinux24-sh4-stmfb-firmware-spark.
Configuring mtd-utils.
Configuring fp-control.
Configuring ustslave.
Configuring tdt-driver.
Configuring libmmeimage0.
Configuring libkmod2.
Configuring udev-cache.
Configuring eudev.
Configuring base-passwd.
Configuring busybox-hwclock.
Configuring libe2p2.
Configuring libext2fs2.
Configuring e2fsprogs-e2fsck.
Configuring stslave-fw.
Configuring stfbcontrol.
Configuring sysvinit-pidof.
Configuring sysvinit.
Configuring netbase.
Configuring init-ifupdown.
Configuring packagegroup-core-boot.
Configuring libncurses5.
Configuring procps.
Configuring autofs.
Configuring util-linux-blkid.
Configuring e2fsprogs-tune2fs.
Configuring e2fsprogs-mke2fs.
Configuring neutrino-feed-config.
Configuring udev-extraconf.

ERROR: neutrino-image-1.0-r0 do_rootfs: Function failed: do_rootfs
ERROR: Logfile of failure stored in: /home/dbt/devel/yocto/poky-stl/build-stl/tmp/work/spark-poky-linux/neutrino-image/1.0-r0/temp/log.do_rootfs.16436
ERROR: Task 9 (/home/dbt/devel/yocto/poky-stl/meta-neutrino-mp/recipes-images/images/neutrino-image.bb, do_rootfs) failed with exit code '1'
NOTE: Tasks Summary: Attempted 2851 tasks of which 2834 didn't need to be rerun and 1 failed.
No currently running tasks (2851 of 2858)

Summary: 1 task failed:
  /home/dbt/devel/yocto/poky-stl/meta-neutrino-mp/recipes-images/images/neutrino-image.bb, do_rootfs
Summary: There were 10 WARNING messages shown.
Summary: There were 2 ERROR messages shown, returning a non-zero exit code.
dbt@linux-11-3:~/devel/yocto/poky-stl/build-stl> 

ein nachträgliches

Code: Alles auswählen

bitbake  harfbuzz

schaffte Abhilfe. Kann sein dass sowas nicht passiert wenn man komplett alles neu aufsetzt und neu baut, aber war halt bequemer. ;-)

[seife]

Was hat denn geklemmt? Irgendwie mußt du ja auf harfbuzz gekommen sein.
Bei mir ist nämlich soweit ich erkennen kann kein harfbuzz gebaut worden aber es funktioniert trotzdem.

[dbt]

Wenn ich das wüsste, ich habe lediglich bitbake neutrino-image angeschubst, aber ist erstmal kein Problem, hat ja durchgebaut. Andere Frage: funktioniert überhaupt neben der ipk-Erstellung auch rpm? Unabhängig davon ob das überhaupt benötigt wird. Ipk ist ja ausreichend.

[seife]

Wie bist du auf die idee gekommen "bitbake harfbuzz" zu machen? Das würde mir jetzt ohne Kontext nicht einfallen.

Früher haben RPMs mal funktioniert. Wenn nicht => lhttps://www.yoctoproject.org/tools-resources/co ... ling-lists ;-)
Ich habe das dann nicht mehr gemacht (dauert ja doch ein wenig) nachdem ich gelernt hatte, wie man mit dpkg in so ein ipk reinschauen kann...

[dbt]

Code: Alles auswählen

Wie bist du auf die idee gekommen "bitbake harfbuzz" zu machen? Das würde mir jetzt ohne Kontext nicht einfallen.

Weil mit bitbake neutrino-image irgendwann do_root irgendwann libharfbuzz wegen fehlender Abhängikeiten angmeckert hat. Bitbake libharfbuzz hat mich dann über 5 Ecken drauf gebracht, es mit bitbake harfbuzz zu versuchen und es hat geholfen

[seife]

ok, da müsstet du jetzt rausfinden, welches paket da gegen libharfbuzz gebaut war.

Das Problem ist (so wie zuvor mit lirc/ALSA), daß manche pakete beim Bauen schauen "was gibts denn hier?" und dann entsprechend features einkompilieren. Das führt dann wiederum zu runtime dependencies.

Wenn da jetzt ein paket früher, als -- warum auch immer -- libharfbuzz schon mal gebaut war gebaut wurde, du zwischendurch aber auf- / um- / weggeräumt hast, dann kann das jetzt nicht mehr installiert werden.

Beim lirc habe ich es dadurch gelöst (https://github.com/seife/meta-stlinux/c ... ecbb13db28), daß ich eben dafür sorge, daß es nicht gegen ALSA gebaut wird.
Da könnte man jetzt in deinem Fall das Paket was libharfbuzz haben will mal genauer anschaut und explizie ein configure ohne harfbuzz erzwingt.

Soweit ich gelesen habe, ist das in neueren yocto-versionen besser, daß da für jedes Paket eine noch sauberere buildumgebung gebaut wird, aber mit dem antiken Kernel wird es wohl schwer mit neueren yocto releases, flk könnte da mehr wissen, ich schau mir das immer nur an, wenn mal was schief geht.

Installier dein image doch mal und mach dann "opkg list-installed | grep harfb".
Dann versuche mal, die dort gefundenen pakete mit "opkg remove $paket" zu deinstallieren. Das sagt dir dann, wer harfbuzz haben will.

Auf meinem Desktop ist es:

Code: Alles auswählen

susi:~ # rpm -e libharfbuzz0
error: Failed dependencies:
	libharfbuzz.so.0()(64bit) is needed by (installed) libpango-1_0-0-1.40.3-1.1.x86_64
	libharfbuzz.so.0()(64bit) is needed by (installed) libQt5Gui5-5.7.1-1.1.x86_64
	libharfbuzz.so.0()(64bit) is needed by (installed) libwebkitgtk-1_0-0-2.4.11-3.4.x86_64
	libharfbuzz.so.0()(64bit) is needed by (installed) libwebkitgtk-3_0-0-2.4.11-3.4.x86_64
	libharfbuzz.so.0()(64bit) is needed by (installed) ft2demos-2.7.1-1.1.x86_64
	libharfbuzz.so.0()(64bit) is needed by (installed) libharfbuzz-icu0-1.4.2-1.1.x86_64
	libharfbuzz.so.0()(64bit) is needed by (installed) texlive-xetex-bin-2016.20160523.svn41091-35.3.x86_64
	libharfbuzz.so.0()(64bit) is needed by (installed) chromium-56.0.2924.87-1.2.x86_64
	libharfbuzz.so.0()(64bit) is needed by (installed) gtk3-devel-3.22.8-1.1.x86_64
	libharfbuzz.so.0()(64bit) is needed by (installed) libwebkit2gtk-4_0-37-2.14.5-1.2.x86_64
	libharfbuzz.so.0()(64bit) is needed by (installed) libreoffice-5.3.0.3-3.1.x86_64
	libharfbuzz.so.0()(64bit) is needed by (installed) libass9-0.13.6-1.1.x86_64
	libharfbuzz.so.0()(64bit) is needed by (installed) libqt5-qtwebengine-5.7.1-1.6.x86_64
	libharfbuzz0 = 1.4.2 is needed by (installed) harfbuzz-devel-1.4.2-1.1.x86_64

Das einzige was davon auf einem neutrino-image rumfliegt ist soweit ich sehe libass.

[flk]

Soweit ich gelesen habe, ist das in neueren yocto-versionen besser, daß da für jedes Paket eine noch sauberere buildumgebung gebaut wird, aber mit dem antiken Kernel wird es wohl schwer mit neueren yocto releases, flk könnte da mehr wissen, ich schau mir das immer nur an, wenn mal was schief geht.

ja, das ist so. Ab dem nächsten yocto Release liegt die Buildumgebung für jedes Paket mit im work Ordner.
e.g. ~/yocto/poky/build-zee2/tmp-uclibc/work/cortexa9hf-vfp-oe-linux-uclibceabi
Wenn man rm_work deaktiviert hat, kann man da gut nachschauen. Dort befinden sich die Ordner:

build - hier landen die gebauten binaries
deploy_ipk - die fertigen ipk Pakete
image - alle Dateien, die im Image landen ( incl. Verzeichnisstruktur)
license-destdir - die Lizenz des Pakets
${PN} eg. git - der Source Code
package - alles was in ipk gepackt wird
package-split - was in welchem Paketen landet (dev,debug,doc,locale .... )
pkgdata - Paketinfos
pseudo - log, pid und co. von pseudo (ähnlich wie fakeroot, wird von bitbake zum Bau verwendet)
temp - die log Dateien
recipe-sysroot, recipe-sysroot-native ... die nötige Buildumgebung
sysroot-destdir ... was das Paket zum sysroot beiträgt

Einfache Lösung wäre auch, harfbuzz unter DEPENDS im libass Recipe einzutragen. Dann bricht das normalerweise nicht mehr ab.

[seife]

Die (meiner Meinung nach ) bessere Lösung war, harfbuzz explizit zu disablen: https://github.com/seife/meta-neutrino- ... 2d9090bf61

Ich bin mir sowieso nicht sicher, ob das ASS zeug überhaupt benötigt wird oder gar funktioniert, Untertitel habe ich in der libspark glaube ich nie implementiert.

Bis zu welchem Release kann ich mit unseren alten Kerneln denn noch updaten? Oder ist bei Krogoth schon ende der Fahnenstange?

[flk]

Ich bin da immer eher freizügig, was Abhängigkeiten angeht. Denke mir immer, wer weiß, wozu man das nochmal brauchen kann. Und die aktuellen Receiver haben ja wirklich mehr Platz als nötig. Aber harfbuzz zieht bestimmt noch cairo mit in den Build

Für mich war da bei Krogoth Schluss, weil ich ab Morty angefangen habe, systemd zu nutzen und da geht mit 2.6 nichts mehr. Ab Morty wird die glibc 2.24 verwendet, die soweit ich weiß minimal Kernel 3.2 benötigt. Die glibc-2.25, die in pyro enthalten sein wird hat aber einen Workaround für 2.6.32 ... evtl war der bei 2.24 auch schon implementiert:

--enable-kernel=2.6.32

[flk]

Im master war aber erst Feature Freeze für pyro, wenn dann also lieber gleich morty überspringen. Das Parsen der Recipes dauert aber im master viel länger. Da sind vermutlich eine Menge Tests aktiv, die erst zum Release abgeschaltet werden

Da wird dann beim Bauen auch jede Menge angemäkelt und im Zweifelsfall erfülle ich dann immer lieber die Abhängigkeiten, wenn ich sie gebaut bekomme