On Wed, 2023-08-02 at 11:26 +0200, Peter Suti wrote: > On Mon, Jul 31, 2023 at 2:33 PM Richard Purdie > <richard.pur...@linuxfoundation.org> wrote: > > > > I did look at the bug and it sounds like if you clean a recipe, builds > > of other recipes which depend upon it then fail? > > Well not just in this case specifically, it is reproducible when doing > a clean build. > But this is the easiest most convenient way to reproduce because most > of the sstate can be reused.
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. > > We need to understand what is happening with both the sstate manifests > > and the stamp files to fully understand this bug. > > > > do_prepare_recipe_sysroot of this recipe that depends on the > > externalsrc one should trigger it's do_populate_sysroot. The question > > is whether the do_clean removed the do_populate_sysroot stamp file for > > that recipe or not? It sounds like it did remove the sstate manifest. > > I have checked the manifest and stamp creation and as far as I can > tell that part is correct. > > > The more I look at this, the more I think changing the deltask is just > > masking the issue and there is some other problem at play here which we > > need to address directly. > > I agree, I have dug a bit further and the issue seems to come from > runqueue.py. > It seems that the current implementation depends heavily on the > presence of _setscene tasks to build the dependency graph. Altering > this behavior would indeed require significant effort and potentially > lead to unforeseen consequences. > > > Unfortunately it took me half an hour just to be able to read through > > the pieces of this and get far enough I could write a coherent answer > > to your question. It is a struggle to reply to everything in this level > > of detail, much as I'd like to :/. > > 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. Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#185524): https://lists.openembedded.org/g/openembedded-core/message/185524 Mute This Topic: https://lists.openembedded.org/mt/100458147/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
