Re: weird task: covered with sstate attempt

[Richard Purdie <richard.purdie@linuxfoundation.org>]

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