On Mon, 2023-07-31 at 14:08 +0200, Peter Suti wrote: > On Mon, Jul 31, 2023 at 1:06 PM Richard Purdie > <[email protected]> wrote: > > > > On Mon, 2023-07-31 at 12:43 +0200, Peter Suti wrote: > > > On Mon, Jul 31, 2023 at 12:15 PM Richard Purdie > > > <[email protected]> wrote: > > > > > > > > On Mon, 2023-07-31 at 11:34 +0200, Peter Suti wrote: > > > > > Fixes [YOCTO #15164] > > > > > > > > > > Instead of deleting setscene tasks, now SSTATE_SKIP_CREATION is set > > > > > instead. > > > > > > > > > > This seems to fix the compile issues where the populate_sysroot task > > > > > was > > > > > not run when an externalsrc recipe was built as a dependency. > > > > > > > > > > Signed-off-by: Peter Suti <[email protected]> > > > > > --- > > > > > meta/classes/externalsrc.bbclass | 7 +++---- > > > > > 1 file changed, 3 insertions(+), 4 deletions(-) > > > > > > > > I think this is going to swap one set of issues for another. > > > > > > > > Setting the skip creation option will stop sstate from being generated > > > > but it won't stop bitbake reusing existing sstate. In the case of > > > > externalsrc, we need to stop it using sstate at all so this patch won't > > > > always have the effect we need :( > > > > > > > > Cheers, > > > > > > > > Richard > > > > > > > > > > Thank you for taking the time to think about this patch! > > > > > > I see your point, but wouldn't inheriting EXTERNALSRC cause enough > > > changes that the hash of the old sstate would no longer match? > > > > > > This should in my opinion ensure that sstate is never used because: > > > A) old sstate would not be reused because of not matching hash > > > B) sstate with matching hash would never be created. > > > > > > Please correct me if I missed something and this logic is wrong. > > > > For some cases, yes, this is definitely true. > > > > Sstate applies to intermediate tasks and you have to keep in mind hash > > equivalence though. For example it would be possible for the package > > task to generate the same output and hence the sstate hashes of the > > package_write_ipk/rpm/deb tasks to be mapped as equivalent so sstate > > would then start to match. > > > > For those tasks I mention above in the example it probably doesn't > > matter too much in the context of externalsrc but I'm not sure the same > > can be said for all tasks which is one of my worries with this. > > Thank you very much for this explanation. For us this patch seems to > do the job and we did not notice any side effects so far. As we can > reproduce the bug easily, we would be happy to try to implement a > better solution instead of this patch. Unfortunately we do not have > enough knowledge to do it without any help. Can you please maybe > provide us some guidance on how to fix the [YOCTO #15164] in a way > that would be acceptable for upstream? >
Firstly, commit messages which just refer to bug reports without an explanation of the issue are a challenge. Commit messages should be self standing, i.e. not needing to rely on the external source for information. A link to more information is however very much a good thing. 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? 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. 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. 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 :/. Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#185141): https://lists.openembedded.org/g/openembedded-core/message/185141 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]] -=-=-=-=-=-=-=-=-=-=-=-
