[bitbake-devel] Random Bitbake build failures

[Christopher Larson]

On Tue, Jun 14, 2016 at 11:44 AM, Nair, Sandeep (Contractor) <
Sandeep_Nair2 at cable.comcast.com> wrote:

> Thanks for the details. Please find the additional details based on your
> feedback
>
>
>
> >>remote side? bitbake builds have never been supported on nfs.
>
>
>
> We mount remote folders and bitbake sees these as a regular folder. Since
> this can be treated as a regular folder, we may not need nfs support in
> bitbake.
>

That's not actually the case, because bitbake needs certain reliable
features of the filesystem, particularly locking, which are problematic on
nfs. It's not completely transparent. You can likely use nfs for
SSTATE_DIR/DL_DIR, though, just not the tmp dir where builds occur.

>> But yes, generally the real task runs if the setscene fails.
>
>
>
> We do the real task when sstate cache fetch fails and we are trying to
> identify the reason why bitbake returns 1 (which happens when error count
> != 0) even when real task succeeds.  We see that Bitbake returns 1 in this
> case which causes random build failure even when the real task was
> performed successfully.
>

If that's actually the case, I'd say it's a bug. sstate fetch failure
shouldn't show error messages, the user doesn't care. I had a bug open for
a similar case at https://bugzilla.yoctoproject.org/show_bug.cgi?id=4499.
I'd suggest setting ;downloadfilename=PATH on the replacement side of the
sstate mirrors (this is automatic in very recent yocto, but wasn't in the
past), as is mentioned in that issue.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/bitbake-devel/attachments/20160614/a6cb4ab2/attachment-0002.html>