weird task: covered with sstate attempt

weird task: covered with sstate attempt

[Barros Pena, Belen]

[-- Attachment #1: Type: text/plain, Size: 999 bytes --]

While poking at the build data (as I do from time to time) I came across a
strange thing in the linux-yocto do_shared_workdir task. It is reported by
Toaster as 'covered' (which means that its output is already provided by
another task in the build, in this case do_package_qa and do_build), but
also as attempting to use shared state. Toaster said it attempted to find
the file 

/home/yocto/master/build/sstate-cache/7d/sstate:linux-yocto:qemux86-poky-li
nux:4.1.15+gitAUTOINC+46bb64d605_788dfc9859:r0:qemux86:3:7de3949f0c0bb15e7c
8f920de3354cd7_shared_workdir.tgz


But didn't. You can see how the task information looks like in Toaster in
the attached file. 

This is quite unusual: I'd never seen a covered task that attempted to
access a shared state artifact. If the output is already provided by
another task, why attempting to use shared state at all?

Is this expected from this task? Or is this indeed strange and something
we should look into?

Thanks!

Belén


[-- Attachment #2: weird-task.png --]
[-- Type: image/png, Size: 177299 bytes --]

Re: weird task: covered with sstate attempt

[Richard Purdie]

On Wed, 2016-01-06 at 10:51 +0000, Barros Pena, Belen wrote:
> While poking at the build data (as I do from time to time) I came
> across a
> strange thing in the linux-yocto do_shared_workdir task. It is
> reported by
> Toaster as 'covered' (which means that its output is already provided
> by
> another task in the build, in this case do_package_qa and do_build),
> but
> also as attempting to use shared state. Toaster said it attempted to
> find
> the file 
> 
> /home/yocto/master/build/sstate-cache/7d/sstate:linux-yocto:qemux86
> -poky-li
> nux:4.1.15+gitAUTOINC+46bb64d605_788dfc9859:r0:qemux86:3:7de3949f0c0b
> b15e7c
> 8f920de3354cd7_shared_workdir.tgz
> 
> 
> But didn't. You can see how the task information looks like in
> Toaster in
> the attached file. 
> 
> This is quite unusual: I'd never seen a covered task that attempted
> to
> access a shared state artifact. If the output is already provided by
> another task, why attempting to use shared state at all?
> 
> Is this expected from this task? Or is this indeed strange and
> something
> we should look into?
> 
> Thanks!

At some point I would like to discuss "covered" as I still think that
its a misleading way of showing things in the UI, and that more
generally, what is being shown isn't entirely helpful to the user.

I think what that screen is trying to show is that do_package_qa came
from sstate which meant that do_shared_work wasn't needed for it,
however there was something else (e.g. do_deploy) which probably meant
it did need to run do_shared_workdir, which it went on to run.

FWIW, do_shared_workdir isn't an sstate task so it would never have an
sstate object that represents it.

In case the above is hard to comprehend, for the kernel, the sstate
tasks are:

$ bitbake virtual/kernel -e | grep SSTATETASKS=
SSTATETASKS="do_package_write_ipk do_package_write_deb do_populate_lic do_package_write_rpm do_package_qa do_populate_sysroot do_packagedata do_deploy do_package"

and if package_qa was ok from sstate, the other do_package_* ones
probably are too. Why they're not showing in the UI? I can only guess
that image doesn't use any kernel packages? That is why I'd suspect
do_deploy triggered the rebuild. I have to wonder why do_populate_lic
didn't show up though as it probably should have.

Cheers,

Richard

Re: weird task: covered with sstate attempt

[Barros Pena, Belen]

On 06/01/2016 11:18, "Richard Purdie" <richard.purdie@linuxfoundation.org>
wrote:

>FWIW, do_shared_workdir isn't an sstate task so it would never have an
>sstate object that represents it.

If this is the case, we have some kind of bug. Toaster should not be
making up shared state objects :/

I'll open up something in Bugzilla if I am able to replicate the problem.

Cheers

Belén

>
>In case the above is hard to comprehend, for the kernel, the sstate
>tasks are:
>
>$ bitbake virtual/kernel -e | grep SSTATETASKS=
>SSTATETASKS="do_package_write_ipk do_package_write_deb do_populate_lic
>do_package_write_rpm do_package_qa do_populate_sysroot do_packagedata
>do_deploy do_package"