On Mon, 2023-08-07 at 16:15 +0200, Peter Suti wrote: > On Mon, Aug 7, 2023 at 2:55 PM Richard Purdie > <[email protected]> wrote: > > > > On Mon, 2023-08-07 at 13:19 +0200, Peter Suti wrote: > > > 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. > > > > I tried: > > > > bitbake libfm; bitbake -c cleansstate cairo; bitbake -c > > prepare_recipe_sysroot -f libfm > > > > with cairo marked as externalsrc and everything built just fine. Can > > you confirm which release of the project you're using please? I tested > > with master. > > > > I have just tried with 058a44165ce375f405063e73a9fcd1b2757ef8da and I > could reproduce it. > I did not notice before but on the first try the issue is not > triggered, but running the following two commands it eventually > breaks: > 1) bitbake -c cleansstate cairo > 2) bitbake -c prepare_recipe_sysroot -f libfm > > It did not happen on the first 2 runs for me, but it did happen on the 3rd > one. > > Could you check if running this a few times reproduces the issue? > `bitbake -c cleansstate cairo; bitbake -c prepare_recipe_sysroot -f libfm` > > Because eventually cairo is not built, just skipped entirely.
Thanks, with this tip I was able to reproduce the issue locally. I've spent some time looking at what was happening and why. I also dug into the history to find out who added the deltask and when (me back in 2012 it seems when externalsrc was created). After all of that I'm starting to think your patch or something similar might be the right thing to do to resolve the issues here. The main issue is that runqueue has stopped seeing populate_sysroot as an sstate task as the setscene task is missing. The options come down to either teaching bitbake a new way of recognising sstate tasks even when setscene isn't there, or putting the setscene tasks back and disabling them some other way which your patch does. Meanwhile we probably should put it through wider testing and see how that looks. Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#185650): https://lists.openembedded.org/g/openembedded-core/message/185650 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]] -=-=-=-=-=-=-=-=-=-=-=-
