<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Nov 26, 2017 at 11:52 PM, Bruce Ashfield <span dir="ltr">&lt;<a href="mailto:bruce.ashfield@gmail.com" target="_blank">bruce.ashfield@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="gmail-">On Sun, Nov 26, 2017 at 5:44 PM, Saul Wold <span dir="ltr">&lt;<a href="mailto:sgw@linux.intel.com" target="_blank">sgw@linux.intel.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span>On Wed, 2017-11-22 at 15:51 -0500, Bruce Ashfield wrote:<br>
&gt; On 2017-11-22 1:47 PM, Saul Wold wrote:<br>
&gt; &gt; Ensure we have a clean and empty STAGING_KERNEL_BUILDDIR (kernel-<br>
&gt; &gt; build-artifacts)<br>
&gt; &gt; before creating it, otherwise there might be older artifacts from a<br>
&gt; &gt; prior<br>
&gt; &gt; kernel build.<br>
&gt; &gt;<br>
&gt;<br>
&gt; What&#39;s the actual error that this triggers ? It would be nice to<br>
&gt; log it here in the commit message .. or at least a description<br>
&gt; of the symptoms.<br>
&gt;<br>
</span>As refered to in the bug, there is not an actual error occurs, but<br>
there are multiple older and non-appropriate (read older) artifacts<br>
remaining in the kernel-build-artifacts directory, just as the commit<br>
message describes.<br></blockquote><div><br></div></span><div>Quoting a bug isn&#39;t useful .. everything that someone needs to know </div><div>*must* be in a commit message. I&#39;m not clicking through later on</div><div>when doing a &#39;git whatchanged&#39;, and I may not even be online at</div><div>that time .. so that bug reference just isn&#39;t useful.</div><div><br></div><div>So the old artifacts remain .. is it a disk usage question ? Is it a possible</div><div>confusion when inspecting a build ? .. All that the message does is</div><div>describe the change, not the why.</div><div><br></div></div></div></div></blockquote><div><br></div><div>I should have highlighted my real question, change log semantics and</div><div>nitpicking are just noise :D See below in the double quoted reply.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div>Bruce</div><div><div class="gmail-h5"><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Sau!<br>
<div class="gmail-m_-3479085542083491279HOEnZb"><div class="gmail-m_-3479085542083491279h5"><br>
&gt; &gt; [YOCTO #11880]<br>
&gt; &gt;<br>
&gt; &gt; Signed-off-by: Saul Wold &lt;<a href="mailto:sgw@linux.intel.com" target="_blank">sgw@linux.intel.com</a>&gt;<br>
&gt; &gt; ---<br>
&gt; &gt;   meta/classes/kernel.bbclass | 3 +--<br>
&gt; &gt;   1 file changed, 1 insertion(+), 2 deletions(-)<br>
&gt; &gt;<br>
&gt; &gt; diff --git a/meta/classes/kernel.bbclass<br>
&gt; &gt; b/meta/classes/kernel.bbclass<br>
&gt; &gt; index 756707a3c25..2a0a7707a14 100644<br>
&gt; &gt; --- a/meta/classes/kernel.bbclass<br>
&gt; &gt; +++ b/meta/classes/kernel.bbclass<br>
&gt; &gt; @@ -400,6 +400,7 @@ emit_depmod_pkgdata() {<br>
&gt; &gt;<br>
&gt; &gt;   PACKAGEFUNCS += &quot;emit_depmod_pkgdata&quot;<br>
&gt; &gt;<br>
&gt; &gt; +do_shared_workdir[cleandirs] += &quot; ${STAGING_KERNEL_BUILDDIR}&quot;<br>
&gt; &gt;   do_shared_workdir () {<br>
&gt; &gt;     cd ${B}<br>
&gt; &gt;<br>
&gt; &gt; @@ -655,8 +656,6 @@ kernel_do_deploy() {<br>
&gt; &gt;             fi<br>
&gt; &gt;     done<br>
&gt; &gt;   }<br>
&gt; &gt; -do_deploy[cleandirs] = &quot;${DEPLOYDIR}&quot;<br>
&gt; &gt; -do_deploy[dirs] = &quot;${DEPLOYDIR} ${B}&quot;<br>
&gt;<br>
&gt; This isn&#39;t clear to me. Why does cleaning the STAGING_KERNEL_BUILDDIR<br>
&gt; as part of the do_shared_workdir mean that we no longer need the<br>
&gt; clean before the deploy (as well as the deploy dir).<br>
&gt;<br></div></div></blockquote></div></div></div></div></div></blockquote><div><br></div><div><br></div><div>It was this that was the real part of the question. The removal of these cleandirs</div><div>didn&#39;t seem to be directly replaced by the new method. Is it that the DEPLOYDIR</div><div>and STAGING_KERNEL_BUILDDIR are the same thing ?</div><div><br></div><div>Bruce</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div class="gmail-h5"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail-m_-3479085542083491279HOEnZb"><div class="gmail-m_-3479085542083491279h5">
&gt; Bruce<br>
&gt;<br>
&gt; &gt;   do_deploy[prefuncs] += &quot;package_get_auto_pr&quot;<br>
&gt; &gt;<br>
&gt; &gt;   addtask deploy after do_populate_sysroot do_packagedata<br>
&gt; &gt;<br>
&gt;<br>
&gt;<br>
--<br>
______________________________<wbr>_________________<br>
Openembedded-core mailing list<br>
<a href="mailto:Openembedded-core@lists.openembedded.org" target="_blank">Openembedded-core@lists.openem<wbr>bedded.org</a><br>
<a href="http://lists.openembedded.org/mailman/listinfo/openembedded-core" rel="noreferrer" target="_blank">http://lists.openembedded.org/<wbr>mailman/listinfo/openembedded-<wbr>core</a><br>
</div></div></blockquote></div></div></div><span class="gmail-HOEnZb"><font color="#888888"><br><br clear="all"><div><br></div>-- <br><div class="gmail-m_-3479085542083491279gmail_signature">&quot;Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end&quot;</div>
</font></span></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">&quot;Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end&quot;</div>
</div></div>