<div dir="ltr">My 2 cents -<div><br></div><div>In managed mode, this bug is not a issue for Toaster as we start and stop the bitbake server separately for each build, for unrelated reasons. This only appears for the "interactive" model, when toaster logs commands ran from the CLI.</div><div><br></div><div>Details below.</div><div><br></div><div>Cheers,</div><div>Alex</div><div><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 23, 2015 at 10:33 AM, Paul Eggleton <span dir="ltr"><<a href="mailto:paul.eggleton@linux.intel.com" target="_blank">paul.eggleton@linux.intel.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Richard,<br>
<span class=""><br>
On Thursday 22 January 2015 14:57:19 Richard Purdie wrote:<br>
> Looking at and thinking about:<br>
><br>
> <a href="https://bugzilla.yoctoproject.org/show_bug.cgi?id=5187" target="_blank">https://bugzilla.yoctoproject.org/show_bug.cgi?id=5187</a><br>
><br>
> We have several issues. Firstly, DATE and TIME are locked in stone when<br>
> the base configuration is parsed. This may cause images to overwrite<br>
> previous versions for example if DATE and TIME are not re-evaluated. We<br>
> could fix this by specifically setting DATE and TIME in bitbake at<br>
> BuildStart?<br>
<br>
</span>We could certainly do this. Another mechanism I did think about was to have<br>
some way of indicating to BitBake that on buildstart the value should be reset<br>
to the immediate evaluation of an expression; perhaps a varflag. At least that<br>
way we could handle other such variables, although it's conceivable that<br>
having built-in DATE and TIME in BitBake wouldn't be the worst thing in the<br>
world.<br></blockquote><div><br></div><div>I think this would be the most elegant solution; however I think there is a catch-22 here, as the build will not start until the datastore is parsed and evaluated, and we need to parse and evaluate the entire datastore as a variable as wildly used as DATE and TIME (and maybe others) change at the start of the build .</div><div><br>I'm not seeing a clean get-away from this ...</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> Secondly, there is one cooker log file opened for the duration of the<br>
> cooker lifecycle. This is a cooker log, not a log of each build so that<br>
> is perhaps not surprising (and is the core problem in the above bug).<br>
> There is no overwriting of the log file, it just keeps growing with each<br>
> build.<br>
><br>
> We could trigger knotty to write out build specific log files based on<br>
> the BuildStart/Finish events?<br>
<br>
</span>Yes I think we should do this.<br></blockquote><div><br></div><div>This is not very helpful for Toaster; Toaster relies on the server-side written cooker log file to have information above what the event system is exposing, and thus it provides the cookerlog file as an optional downloadable item for the user's benefit. </div><div><br>If we drop the cooker log we'll have a bit of the gap in the information we provide to the user. </div><div><br></div><div>Multiple builds per cooker is not a problem, since, in managed mode, Toaster will stop the server after each build for unrelated reasons.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Cheers,<br>
Paul<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
<br>
Paul Eggleton<br>
Intel Open Source Technology Centre<br>
--<br>
_______________________________________________<br>
bitbake-devel mailing list<br>
<a href="mailto:bitbake-devel@lists.openembedded.org">bitbake-devel@lists.openembedded.org</a><br>
<a href="http://lists.openembedded.org/mailman/listinfo/bitbake-devel" target="_blank">http://lists.openembedded.org/mailman/listinfo/bitbake-devel</a><br>
</font></span></blockquote></div><br></div></div></div>