**** BEGIN LOGGING AT Sat May 04 02:59:57 2019 **** ENDING LOGGING AT Sat May 04 03:52:26 2019 **** BEGIN LOGGING AT Sat May 04 12:23:13 2019 May 04 13:25:35 mmh doesn't work that well for second level dependencies like sdl2-opengles-test... May 04 16:58:20 JaMa: did you see my last attempt? May 04 17:34:00 sorry, not yet May 04 17:35:56 JaMa: I've been trying to put all the recipes that depends (in)directly on libhybris into a separate PACKAGE_ARCH May 04 17:36:35 but I only suceeded with direct depends (with the hack from the commit) May 04 17:38:43 It's a bit illogical that even when a package is "aarch64-halium", the ones that depends on it are just "aarch64" May 04 17:39:56 maybe I could ask openembedded's mailing list and see if someone has an idea May 04 19:45:54 you can ask, but I don't expect anything useful May 04 19:47:48 see QT_PACKAGES_ARCH in meta-qt5/recipes-qt/qt5/qt5.inc, that's similarly limited May 04 19:50:19 and classes/fsl-dynamic-packagearch.bbclass in meta-freescale is also interesting, but nothing which would solve the issue with the signature being different until the hash equivalence bitbake server becames more usable May 04 20:26:10 It's a bit sad that we're unable to retrieve recursively all the DEPENDS of a recipe May 04 20:51:52 on the other hand if everything which depends on one of virtual/*gl* needs separate PACKAGE_ARCH you won't share much with other TUNE_PKGARCH anyway May 04 20:52:09 even the cross toolchain will be reused between different TUNE_PKGARCH already May 04 20:52:49 so the whole complexity is just for relatively few recipes (which usually don't take too long to build) May 04 20:53:58 reusing busybox, zlib and similar recipes makes inappreciable difference when you're building images containing qtbase, qtdeclarative, qtwebengine, ... May 04 20:56:16 using well defined APIs and not leaking the ABI difference transitively to all users would + hash equivalence server actually comparing the build output -> this could eventually save significant portion of build time May 04 20:58:02 but it will be tricky as well, IIRC even qtwebengine itself links with *gl* providers (instead of calling just qtbase API which would be able to hide the *gl* providers difference), so you wouldn't be able to reuse qtwebengine again and we're back in square 1 May 04 21:39:08 yes, true... **** ENDING LOGGING AT Sun May 05 03:00:37 2019