On Fri, Aug 4, 2023 at 4:47 PM Richard Purdie <[email protected]> wrote: > > Do you have a way to reproduce this using recipes in OE-Core? > > For example, I tried adding this to the cairo recipe: > > EXTERNALSRC = "/xxx/cairo-1.16.0" > inherit externalsrc > > and then building cairo, cleaning cairo, building pango (which depends > on cairo). I couldn't see any failure. >
To reproduce you need a transitive dependency on a recipe using externalsrc and run populate_sysroot. I can trigger it with the following sequence: 1) make cairo inherit externalsrc just like you described above. 2) build a package that depends on pango, for example libfm: bitbake libfm 3) clean cairo sstate: bitbake -c cleansstate cairo 4) rerun prepare_recipe_sysroot for libfm: bitbake -c prepare_recipe_sysroot -f libfm This produces the following error for me: ERROR: libfm-1.3.2-r0 do_prepare_recipe_sysroot: The sstate manifest for task 'cairo:populate_sysroot' (multilib variant '') could not be found. The pkgarchs considered were: armv8a-crc, armv8a, aarch64, allarch, x86_64_x86_64-nativesdk. But none of these manifests exists: /home/yocto/.build-yocto/tmp/sstate-control/manifest-armv8a-crc-cairo.populate_sysroot /home/yocto/.build-yocto/tmp/sstate-control/manifest-armv8a-cairo.populate_sysroot /home/yocto/.build-yocto/tmp/sstate-control/manifest-aarch64-cairo.populate_sysroot /home/yocto/.build-yocto/tmp/sstate-control/manifest-allarch-cairo.populate_sysroot /home/yocto/.build-yocto/tmp/sstate-control/manifest-x86_64_x86_64-nativesdk-cairo.populate_sysroot ERROR: Logfile of failure stored in: /home/yocto/.build-yocto/tmp/work/armv8a-poky-linux/libfm/1.3.2-r0/temp/log.do_prepare_recipe_sysroot.3102616 ERROR: Task (/home/yocto/poky/meta/recipes-support/libfm/libfm_1.3.2.bb:do_prepare_recipe_sysroot) failed with exit code '1' > > I'd like to thank you for the time you have invested in this issue! I > > appreciate the help. > > I understand that my proposed solution might not be ideal, but fixing > > the underlying issue in runqueue would be a real challenge. > > If upstream is not interested in this patch, I can also understand that. > > It isn't that we're not interested, we just need to make sure something > else doesn't break. A test case to reproduce the issue you're seeing > would help a lot. Ultimately we should perhaps add something to the > tests in meta/lib/oeqa/ to cover the issue. I agree that a test would be valuable for this. I'll try to look into how such a testcase could be constructed.
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#185593): https://lists.openembedded.org/g/openembedded-core/message/185593 Mute This Topic: https://lists.openembedded.org/mt/100458147/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
