Re: [PATCH 0/2] Avoid build failures due to setscene errors

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

On Wed, 2017-08-30 at 06:44 +0000, Peter Kjellerstedt wrote:
> > I have left this code as an error deliberately as this kind of
> > thing should not happen and if it does, there is really something
> > wrong which you need to figure out. It means that at one point
> > bitbake thinks the sstate is present and valid, then later it
> > isn't.
>
> True, but since the operations of checking if an sstate file exists
> and retrieving it is not an atomic operation, there are always
> problems that can occur. Some may be fixable, some may not. However,
> using a build failure to detect these kind of problems is a bit harsh
> on the developers who only sees their builds complete only to get an
> error for something that is not their fault. We have better ways to
> detect these kinds of problems, e.g., through log monitoring, without
> having to cause unnecessary grief amongst the developers.

Files are randomly disappearing from your sstate source. So far you've
been lucky and these are not causing corruption, but they could.

Please figure out and fix your sstate infrastructure, not hack the code
to avoid the errors.

I do appreciate its painful, we did once see this issue on the
autobuilder. There was a real error in the sstate cleanup scripts and
we fixed that but it took some work to find it.

Also, with changes like this you can end up in a state where sstate can
completely stop working and the only way you'd tell is by increased
build time.

> > I'm not convinced patching out the errors is the right solution
> > here...
> How about I make it conditional by adding an IGNORE_SETSCENE_ERRORS? 
> That way it can default to "0", but we can set it to "1" to
> prioritize the production builds.

I'm still not convinced, sorry.

[The reason being complexity. I don't like having multiple ways of
doing things if we can help it, particularly when one of them is a
workaround for a problem elsewhere. One of the codepaths in a case like
this is unlikely to get well tested.]

Cheers,

Richard