All of lore.kernel.org
 help / color / mirror / Atom feed
From: Saul Wold <sgw@linux.intel.com>
To: Bruce Ashfield <bruce.ashfield@gmail.com>
Cc: Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH] kernel.bbclass: Add cleandirs for do_shared_workdir
Date: Mon, 27 Nov 2017 10:38:33 -0800	[thread overview]
Message-ID: <1511807913.2714.6.camel@linux.intel.com> (raw)
In-Reply-To: <CADkTA4PgddGafbwcYYd=KyVyra8UMD91tFWCtRc3KNUZ_9=Gzg@mail.gmail.com>

On Mon, 2017-11-27 at 08:35 -0500, Bruce Ashfield wrote:
> 
> 
> On Sun, Nov 26, 2017 at 11:52 PM, Bruce Ashfield <bruce.ashfield@gmai
> l.com> wrote:
> > 
> > On Sun, Nov 26, 2017 at 5:44 PM, Saul Wold <sgw@linux.intel.com>
> > wrote:
> > > On Wed, 2017-11-22 at 15:51 -0500, Bruce Ashfield wrote:
> > > > On 2017-11-22 1:47 PM, Saul Wold wrote:
> > > > > Ensure we have a clean and empty STAGING_KERNEL_BUILDDIR
> > > (kernel-
> > > > > build-artifacts)
> > > > > before creating it, otherwise there might be older artifacts
> > > from a
> > > > > prior
> > > > > kernel build.
> > > > >
> > > >
> > > > What's the actual error that this triggers ? It would be nice
> > > to
> > > > log it here in the commit message .. or at least a description
> > > > of the symptoms.
> > > >
> > > As refered to in the bug, there is not an actual error occurs,
> > > but
> > > there are multiple older and non-appropriate (read older)
> > > artifacts
> > > remaining in the kernel-build-artifacts directory, just as the
> > > commit
> > > message describes.
> > 
> > Quoting a bug isn't useful .. everything that someone needs to
> > know 
> > *must* be in a commit message. I'm not clicking through later on
> > when doing a 'git whatchanged', and I may not even be online at
> > that time .. so that bug reference just isn't useful.
> > 
> > So the old artifacts remain .. is it a disk usage question ? Is it
> > a possible
> > confusion when inspecting a build ? .. All that the message does is
> > describe the change, not the why.
> > 
> > 
> 
> I should have highlighted my real question, change log semantics and
> nitpicking are just noise :D See below in the double quoted reply.
>  
Sorry, I missed the real question!


> > Bruce
> > 
> >  
> > > Sau!
> > > 
> > > > > [YOCTO #11880]
> > > > >
> > > > > Signed-off-by: Saul Wold <sgw@linux.intel.com>
> > > > > ---
> > > > >   meta/classes/kernel.bbclass | 3 +--
> > > > >   1 file changed, 1 insertion(+), 2 deletions(-)
> > > > >
> > > > > diff --git a/meta/classes/kernel.bbclass
> > > > > b/meta/classes/kernel.bbclass
> > > > > index 756707a3c25..2a0a7707a14 100644
> > > > > --- a/meta/classes/kernel.bbclass
> > > > > +++ b/meta/classes/kernel.bbclass
> > > > > @@ -400,6 +400,7 @@ emit_depmod_pkgdata() {
> > > > >
> > > > >   PACKAGEFUNCS += "emit_depmod_pkgdata"
> > > > >
> > > > > +do_shared_workdir[cleandirs] += "
> > > ${STAGING_KERNEL_BUILDDIR}"
> > > > >   do_shared_workdir () {
> > > > >     cd ${B}
> > > > >
> > > > > @@ -655,8 +656,6 @@ kernel_do_deploy() {
> > > > >             fi
> > > > >     done
> > > > >   }
> > > > > -do_deploy[cleandirs] = "${DEPLOYDIR}"
> > > > > -do_deploy[dirs] = "${DEPLOYDIR} ${B}"
> > > >
> > > > This isn't clear to me. Why does cleaning the
> > > STAGING_KERNEL_BUILDDIR
> > > > as part of the do_shared_workdir mean that we no longer need
> > > the
> > > > clean before the deploy (as well as the deploy dir).
> > > >
> 
> 
> It was this that was the real part of the question. The removal of
> these cleandirs
> didn't seem to be directly replaced by the new method. Is it that the
> DEPLOYDIR
> and STAGING_KERNEL_BUILDDIR are the same thing ?
> 
Yeah, oops, those where not meant to be removed, not sure what happened
or why I missed it on review.

Sau!

> Bruce
>  
> > > > Bruce
> > > >
> > > > >   do_deploy[prefuncs] += "package_get_auto_pr"
> > > > >
> > > > >   addtask deploy after do_populate_sysroot do_packagedata
> > > > >
> > > >
> > > >
> > > --
> > > _______________________________________________
> > > Openembedded-core mailing list
> > > Openembedded-core@lists.openembedded.org
> > > http://lists.openembedded.org/mailman/listinfo/openembedded-core
> > 
> > 
> > 
> > -- 
> > "Thou shalt not follow the NULL pointer, for chaos and madness
> > await thee at its end"
> 
> 
> 


      reply	other threads:[~2017-11-27 18:38 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-22 18:47 [PATCH] kernel.bbclass: Add cleandirs for do_shared_workdir Saul Wold
2017-11-22 20:51 ` Bruce Ashfield
2017-11-26 22:44   ` Saul Wold
2017-11-27  4:52     ` Bruce Ashfield
2017-11-27 13:35       ` Bruce Ashfield
2017-11-27 18:38         ` Saul Wold [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1511807913.2714.6.camel@linux.intel.com \
    --to=sgw@linux.intel.com \
    --cc=bruce.ashfield@gmail.com \
    --cc=openembedded-core@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.