<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 14, 2016 at 11:44 AM, Nair, Sandeep (Contractor) <span dir="ltr"><<a href="mailto:Sandeep_Nair2@cable.comcast.com" target="_blank">Sandeep_Nair2@cable.comcast.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Thanks for the details. Please find the additional details based on your feedback<u></u><u></u></span></p><span class="">
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">>>remote side? bitbake builds have never been supported on nfs.<span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">
<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
</span><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">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.</span></p></blockquote><div><br></div><div>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. </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span class="">
<p class="MsoNormal">>> But yes, generally the real task runs if the setscene fails.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
</span><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">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.</span></p></blockquote></div><br>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 <a href="https://bugzilla.yoctoproject.org/show_bug.cgi?id=4499">https://bugzilla.yoctoproject.org/show_bug.cgi?id=4499</a>. I'd suggest setting ;<span style="color:rgb(0,0,0);white-space:pre-wrap">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.</span><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Christopher Larson<br>clarson at kergoth dot com<br>Founder - BitBake, OpenEmbedded, OpenZaurus<br>Maintainer - Tslib<br>Senior Software Engineer, Mentor Graphics</div>
</div></div>