All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bob Cochran <openembedded@mindchasers.com>
To: Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>
Cc: Kang Kai <Kai.Kang@windriver.com>
Subject: Re: cleanup-workdir
Date: Sat, 02 Jun 2012 11:37:08 -0400	[thread overview]
Message-ID: <4FCA3324.8050007@mindchasers.com> (raw)
In-Reply-To: <4F87F622.3070302@opendreambox.org>

On 04/13/2012 05:47 AM, Andreas Oberritter wrote:
> On 13.04.2012 03:49, Kang Kai wrote:
>> On 2012年04月13日 02:47, Andreas Oberritter wrote:
>>> Hello Kai,
>>>
>>> because I was low on disk space, I just tried scripts/cleanup-workdir
>>> for the first time. My observations:
>>
>> Hi Andreas,
>>
>>
>>> 1.) It deletes work directories that were built for other machines
>>> (archs) than the current one. I guess the list of architectures to
>>> handle should be queried from bitbake to avoid this.
>> Do you mean that you build for 2 archs under the same "build" directory?
>
> I have two build directories, one for each machine, sharing a single tmp
> directory.
>
> The basic layout looks roughly like this:
>
> $OE/build/machineA/conf/local.conf
> $OE/build/machineB/conf/local.conf
> $OE/tmp/work/
>
>> Even in this way the script only delete the packages' build dir for old
>> versions.
>
> That's right, but different machines may have different versions due to
> COMPATIBLE_MACHINE settings. In my setup, there's also a layer for each
> machine, which contains hardware drivers etc. Although every machine
> provides the same set of drivers (same ${PN}), the versions differ slightly.
>
>> Your requirement is that cleanup-workdir just clean the build dirs for
>> current arch, right?
>
> Yes. For each arch listed in PACKAGE_ARCHS (or
> ALL_MULTILIB_PACKAGE_ARCHS?) for the current machine.
>
>>> 2.) It doesn't delete work directories of previously deleted recipes.
>> Because when the recipe gone, I can NOT tell whether the directory is
>> left by bitbake or created by user.
>> I will list them and let user to choose delete them or not.
>
> It should be safe to assume that there are no directories created by the
> user, as tmp/work is known to be managed by OE. However, recipes don't
> disappear very often, so asking the user seems to be fine.



Yes, it ignored the following package directories from removed recipes: 
module-init-tools-3.16-r0 & module-init-tools-cross-3.16-r0.   My 
preference would be to have the tool delete them.

I also noticed that the regex filters missed "iputils-s20101006-r3", so 
a tweak to pick this up is probably warranted (or at least flag it at 
the bottom of the regex loop as not being matched by any of the filters).

Related question: why not add an option to the tool to have it go ahead 
and also delete the artifacts from the obsolete packages left in stamps 
and buildstats?




>
> Regards,
> Andreas
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core




      reply	other threads:[~2012-06-02 16:14 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-12 18:47 cleanup-workdir Andreas Oberritter
2012-04-13  1:49 ` cleanup-workdir Kang Kai
2012-04-13  9:47   ` cleanup-workdir Andreas Oberritter
2012-06-02 15:37     ` Bob Cochran [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=4FCA3324.8050007@mindchasers.com \
    --to=openembedded@mindchasers.com \
    --cc=Kai.Kang@windriver.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.