| Message ID | 20230731093415.261532-1-peter.suti@streamunlimited.com |
|---|---|
| State | Accepted, archived |
| Commit | ee4667a24ccdd8c9d547e73aecf661e6a1283890 |
| Headers | show |
| Series | externalsrc: fix dependency chain issues | expand |
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 <peter.suti@streamunlimited.com> > --- > 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 > > diff --git a/meta/classes/externalsrc.bbclass b/meta/classes/externalsrc.bbclass > index a649bcdff8..12f2718850 100644 > --- a/meta/classes/externalsrc.bbclass > +++ b/meta/classes/externalsrc.bbclass > @@ -76,6 +76,8 @@ python () { > > # Dummy value because the default function can't be called with blank SRC_URI > d.setVar('SRCPV', '999') > + # sstate is never going to work for external source trees, disable it > + d.setVar('SSTATE_SKIP_CREATION', '1') > > if d.getVar('CONFIGUREOPT_DEPTRACK') == '--disable-dependency-tracking': > d.setVar('CONFIGUREOPT_DEPTRACK', '') > @@ -83,10 +85,7 @@ python () { > tasks = filter(lambda k: d.getVarFlag(k, "task"), d.keys()) > > for task in tasks: > - if task.endswith("_setscene"): > - # sstate is never going to work for external source trees, disable it > - bb.build.deltask(task, d) > - elif os.path.realpath(d.getVar('S')) == os.path.realpath(d.getVar('B')): > + if os.path.realpath(d.getVar('S')) == os.path.realpath(d.getVar('B')): > # Since configure will likely touch ${S}, ensure only we lock so one task has access at a time > d.appendVarFlag(task, "lockfiles", " ${S}/singletask.lock") > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#185127): https://lists.openembedded.org/g/openembedded-core/message/185127 > Mute This Topic: https://lists.openembedded.org/mt/100458147/1686473 > Group Owner: openembedded-core+owner@lists.openembedded.org > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [richard.purdie@linuxfoundation.org] > -=-=-=-=-=-=-=-=-=-=-=- >
On Mon, Jul 31, 2023 at 12:15 PM Richard Purdie <richard.purdie@linuxfoundation.org> 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 <peter.suti@streamunlimited.com> > > --- > > 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. > > > > > diff --git a/meta/classes/externalsrc.bbclass b/meta/classes/externalsrc.bbclass > > index a649bcdff8..12f2718850 100644 > > --- a/meta/classes/externalsrc.bbclass > > +++ b/meta/classes/externalsrc.bbclass > > @@ -76,6 +76,8 @@ python () { > > > > # Dummy value because the default function can't be called with blank SRC_URI > > d.setVar('SRCPV', '999') > > + # sstate is never going to work for external source trees, disable it > > + d.setVar('SSTATE_SKIP_CREATION', '1') > > > > if d.getVar('CONFIGUREOPT_DEPTRACK') == '--disable-dependency-tracking': > > d.setVar('CONFIGUREOPT_DEPTRACK', '') > > @@ -83,10 +85,7 @@ python () { > > tasks = filter(lambda k: d.getVarFlag(k, "task"), d.keys()) > > > > for task in tasks: > > - if task.endswith("_setscene"): > > - # sstate is never going to work for external source trees, disable it > > - bb.build.deltask(task, d) > > - elif os.path.realpath(d.getVar('S')) == os.path.realpath(d.getVar('B')): > > + if os.path.realpath(d.getVar('S')) == os.path.realpath(d.getVar('B')): > > # Since configure will likely touch ${S}, ensure only we lock so one task has access at a time > > d.appendVarFlag(task, "lockfiles", " ${S}/singletask.lock") > > > > -=-=-=-=-=-=-=-=-=-=-=- > > Links: You receive all messages sent to this group. > > View/Reply Online (#185127): https://lists.openembedded.org/g/openembedded-core/message/185127 > > Mute This Topic: https://lists.openembedded.org/mt/100458147/1686473 > > Group Owner: openembedded-core+owner@lists.openembedded.org > > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [richard.purdie@linuxfoundation.org] > > -=-=-=-=-=-=-=-=-=-=-=- > > >
On Mon, 2023-07-31 at 12:43 +0200, Peter Suti wrote: > On Mon, Jul 31, 2023 at 12:15 PM Richard Purdie > <richard.purdie@linuxfoundation.org> 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 <peter.suti@streamunlimited.com> > > > --- > > > 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. Cheers, Richard
On Mon, Jul 31, 2023 at 1:06 PM Richard Purdie <richard.purdie@linuxfoundation.org> wrote: > > On Mon, 2023-07-31 at 12:43 +0200, Peter Suti wrote: > > On Mon, Jul 31, 2023 at 12:15 PM Richard Purdie > > <richard.purdie@linuxfoundation.org> 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 <peter.suti@streamunlimited.com> > > > > --- > > > > 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. > > Cheers, > > Richard > > 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? > >
On Mon, 2023-07-31 at 14:08 +0200, Peter Suti wrote: > On Mon, Jul 31, 2023 at 1:06 PM Richard Purdie > <richard.purdie@linuxfoundation.org> wrote: > > > > On Mon, 2023-07-31 at 12:43 +0200, Peter Suti wrote: > > > On Mon, Jul 31, 2023 at 12:15 PM Richard Purdie > > > <richard.purdie@linuxfoundation.org> 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 <peter.suti@streamunlimited.com> > > > > > --- > > > > > 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
On Mon, Jul 31, 2023 at 2:33 PM Richard Purdie <richard.purdie@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. > 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.
On Wed, 2023-08-02 at 11:26 +0200, Peter Suti wrote: > On Mon, Jul 31, 2023 at 2:33 PM Richard Purdie > <richard.purdie@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
On Fri, Aug 4, 2023 at 4:47 PM Richard Purdie <richard.purdie@linuxfoundation.org> 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.
On Mon, 2023-08-07 at 13:19 +0200, Peter Suti wrote: > On Fri, Aug 4, 2023 at 4:47 PM Richard Purdie > <richard.purdie@linuxfoundation.org> 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. Cheers, Richard
On Mon, Aug 7, 2023 at 2:55 PM Richard Purdie <richard.purdie@linuxfoundation.org> wrote: > > On Mon, 2023-08-07 at 13:19 +0200, Peter Suti wrote: > > On Fri, Aug 4, 2023 at 4:47 PM Richard Purdie > > <richard.purdie@linuxfoundation.org> 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.
On Mon, 2023-08-07 at 16:15 +0200, Peter Suti wrote: > On Mon, Aug 7, 2023 at 2:55 PM Richard Purdie > <richard.purdie@linuxfoundation.org> wrote: > > > > On Mon, 2023-08-07 at 13:19 +0200, Peter Suti wrote: > > > On Fri, Aug 4, 2023 at 4:47 PM Richard Purdie > > > <richard.purdie@linuxfoundation.org> 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
diff --git a/meta/classes/externalsrc.bbclass b/meta/classes/externalsrc.bbclass index a649bcdff8..12f2718850 100644 --- a/meta/classes/externalsrc.bbclass +++ b/meta/classes/externalsrc.bbclass @@ -76,6 +76,8 @@ python () { # Dummy value because the default function can't be called with blank SRC_URI d.setVar('SRCPV', '999') + # sstate is never going to work for external source trees, disable it + d.setVar('SSTATE_SKIP_CREATION', '1') if d.getVar('CONFIGUREOPT_DEPTRACK') == '--disable-dependency-tracking': d.setVar('CONFIGUREOPT_DEPTRACK', '') @@ -83,10 +85,7 @@ python () { tasks = filter(lambda k: d.getVarFlag(k, "task"), d.keys()) for task in tasks: - if task.endswith("_setscene"): - # sstate is never going to work for external source trees, disable it - bb.build.deltask(task, d) - elif os.path.realpath(d.getVar('S')) == os.path.realpath(d.getVar('B')): + if os.path.realpath(d.getVar('S')) == os.path.realpath(d.getVar('B')): # Since configure will likely touch ${S}, ensure only we lock so one task has access at a time d.appendVarFlag(task, "lockfiles", " ${S}/singletask.lock")
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 <peter.suti@streamunlimited.com> --- meta/classes/externalsrc.bbclass | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-)