Patchwork [0/1] A script to clean obsolete sstate cache files

login
register
mail settings
Submitter Robert Yang
Date Feb. 22, 2012, 1:27 p.m.
Message ID <cover.1329916583.git.liezhi.yang@windriver.com>
Download mbox
Permalink /patch/21577/
State New
Headers show

Pull-request

git://git.pokylinux.org/poky-contrib robert/remove-sstate

Comments

Robert Yang - Feb. 22, 2012, 1:27 p.m.
Here is the testing result:

$ ./poky/scripts/sstate-cache-management.sh --cache-dir=sstate-cache.bak/ --remove-duplicated
Figuring out the archs in the sstate cache dir ...
The following archs have been found in the sstate cache dir:
i586 ppc603e x86_64 qemux86 qemuppc
Removing the sstate-xxx_deploy-rpm.tgz ... (3034 files)
Removing the sstate-xxx_deploy-ipk.tgz ... (0 files)
Removing the sstate-xxx_deploy-deb.tgz ... (0 files)
Removing the sstate-xxx_deploy.tgz ... (8 files)
Removing the sstate-xxx_package.tgz ... (3282 files)
Removing the sstate-xxx_populate-lic.tgz ... (2482 files)
Removing the sstate-xxx_populate-sysroot.tgz ... (3282 files)
12088 files have been removed

// Robert

The following changes since commit 87e32edb88c30ac116fa396148ac26357051f93a:

  iputils: Add base_libdir to VPATH in order to find the crypto library (2012-02-21 17:59:40 +0000)

are available in the git repository at:
  git://git.pokylinux.org/poky-contrib robert/remove-sstate
  http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=robert/remove-sstate

Robert Yang (1):
  A script to clean obsolete sstate cache files

 scripts/sstate-cache-management.sh |  135 ++++++++++++++++++++++++++++++++++++
 1 files changed, 135 insertions(+), 0 deletions(-)
 create mode 100755 scripts/sstate-cache-management.sh
Koen Kooi - Feb. 22, 2012, 1:42 p.m.
Op 22 feb. 2012, om 14:27 heeft Robert Yang het volgende geschreven:

> Here is the testing result:
> 
> $ ./poky/scripts/sstate-cache-management.sh --cache-dir=sstate-cache.bak/ --remove-duplicated
> Figuring out the archs in the sstate cache dir ...
> The following archs have been found in the sstate cache dir:
> i586 ppc603e x86_64 qemux86 qemuppc
> Removing the sstate-xxx_deploy-rpm.tgz ... (3034 files)
> Removing the sstate-xxx_deploy-ipk.tgz ... (0 files)
> Removing the sstate-xxx_deploy-deb.tgz ... (0 files)
> Removing the sstate-xxx_deploy.tgz ... (8 files)
> Removing the sstate-xxx_package.tgz ... (3282 files)
> Removing the sstate-xxx_populate-lic.tgz ... (2482 files)
> Removing the sstate-xxx_populate-sysroot.tgz ... (3282 files)
> 12088 files have been removed
> 
> // Robert
> 
> The following changes since commit 87e32edb88c30ac116fa396148ac26357051f93a:
> 
>  iputils: Add base_libdir to VPATH in order to find the crypto library (2012-02-21 17:59:40 +0000)
> 
> are available in the git repository at:
>  git://git.pokylinux.org/poky-contrib robert/remove-sstate
>  http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=robert/remove-sstate

Do you have a patch against oe-core instead of poky??!?
Richard Purdie - Feb. 22, 2012, 2:15 p.m.
On Wed, 2012-02-22 at 14:42 +0100, Koen Kooi wrote:
> Op 22 feb. 2012, om 14:27 heeft Robert Yang het volgende geschreven:
> 
> > Here is the testing result:
> > 
> > $ ./poky/scripts/sstate-cache-management.sh --cache-dir=sstate-cache.bak/ --remove-duplicated
> > Figuring out the archs in the sstate cache dir ...
> > The following archs have been found in the sstate cache dir:
> > i586 ppc603e x86_64 qemux86 qemuppc
> > Removing the sstate-xxx_deploy-rpm.tgz ... (3034 files)
> > Removing the sstate-xxx_deploy-ipk.tgz ... (0 files)
> > Removing the sstate-xxx_deploy-deb.tgz ... (0 files)
> > Removing the sstate-xxx_deploy.tgz ... (8 files)
> > Removing the sstate-xxx_package.tgz ... (3282 files)
> > Removing the sstate-xxx_populate-lic.tgz ... (2482 files)
> > Removing the sstate-xxx_populate-sysroot.tgz ... (3282 files)
> > 12088 files have been removed
> > 
> > // Robert
> > 
> > The following changes since commit 87e32edb88c30ac116fa396148ac26357051f93a:
> > 
> >  iputils: Add base_libdir to VPATH in order to find the crypto library (2012-02-21 17:59:40 +0000)
> > 
> > are available in the git repository at:
> >  git://git.pokylinux.org/poky-contrib robert/remove-sstate
> >  http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=robert/remove-sstate
> 
> Do you have a patch against oe-core instead of poky??!?

Does this really need as many question and exclamation marks???!!!!????!

;-)

Its not hard to manipulate the patches around from one tree to the
other.

Cheers,

Richard
Koen Kooi - Feb. 22, 2012, 2:32 p.m.
Op 22 feb. 2012, om 15:15 heeft Richard Purdie het volgende geschreven:

> On Wed, 2012-02-22 at 14:42 +0100, Koen Kooi wrote:
>> Op 22 feb. 2012, om 14:27 heeft Robert Yang het volgende geschreven:
>> 
>>> Here is the testing result:
>>> 
>>> $ ./poky/scripts/sstate-cache-management.sh --cache-dir=sstate-cache.bak/ --remove-duplicated
>>> Figuring out the archs in the sstate cache dir ...
>>> The following archs have been found in the sstate cache dir:
>>> i586 ppc603e x86_64 qemux86 qemuppc
>>> Removing the sstate-xxx_deploy-rpm.tgz ... (3034 files)
>>> Removing the sstate-xxx_deploy-ipk.tgz ... (0 files)
>>> Removing the sstate-xxx_deploy-deb.tgz ... (0 files)
>>> Removing the sstate-xxx_deploy.tgz ... (8 files)
>>> Removing the sstate-xxx_package.tgz ... (3282 files)
>>> Removing the sstate-xxx_populate-lic.tgz ... (2482 files)
>>> Removing the sstate-xxx_populate-sysroot.tgz ... (3282 files)
>>> 12088 files have been removed
>>> 
>>> // Robert
>>> 
>>> The following changes since commit 87e32edb88c30ac116fa396148ac26357051f93a:
>>> 
>>> iputils: Add base_libdir to VPATH in order to find the crypto library (2012-02-21 17:59:40 +0000)
>>> 
>>> are available in the git repository at:
>>> git://git.pokylinux.org/poky-contrib robert/remove-sstate
>>> http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=robert/remove-sstate
>> 
>> Do you have a patch against oe-core instead of poky??!?
> 
> Does this really need as many question and exclamation marks???!!!!????!
> 
> ;-)
> 
> Its not hard to manipulate the patches around from one tree to the
> other.

That's good to know, so why wasn't it manipulated to work on oe-core when being sent to the oe-core list?
Otavio Salvador - Feb. 22, 2012, 2:48 p.m.
On Wed, Feb 22, 2012 at 11:27, Robert Yang <liezhi.yang@windriver.com>wrote:

> $ ./poky/scripts/sstate-cache-management.sh --cache-dir=sstate-cache.bak/
> --remove-duplicated
> Figuring out the archs in the sstate cache dir ...
> The following archs have been found in the sstate cache dir:
> i586 ppc603e x86_64 qemux86 qemuppc
> Removing the sstate-xxx_deploy-rpm.tgz ... (3034 files)
> Removing the sstate-xxx_deploy-ipk.tgz ... (0 files)
> Removing the sstate-xxx_deploy-deb.tgz ... (0 files)
> Removing the sstate-xxx_deploy.tgz ... (8 files)
> Removing the sstate-xxx_package.tgz ... (3282 files)
> Removing the sstate-xxx_populate-lic.tgz ... (2482 files)
> Removing the sstate-xxx_populate-sysroot.tgz ... (3282 files)
> 12088 files have been removed
>

That's awesome. I was looking for a script for this.

Can you please resend it based on oe-core? I'll give it a good test.
Richard Purdie - Feb. 22, 2012, 3:06 p.m.
On Wed, 2012-02-22 at 15:32 +0100, Koen Kooi wrote:
> Op 22 feb. 2012, om 15:15 heeft Richard Purdie het volgende geschreven:
> 
> > On Wed, 2012-02-22 at 14:42 +0100, Koen Kooi wrote:
> >> Op 22 feb. 2012, om 14:27 heeft Robert Yang het volgende geschreven:
> >> 
> >>> Here is the testing result:
> >>> 
> >>> $ ./poky/scripts/sstate-cache-management.sh --cache-dir=sstate-cache.bak/ --remove-duplicated
> >>> Figuring out the archs in the sstate cache dir ...
> >>> The following archs have been found in the sstate cache dir:
> >>> i586 ppc603e x86_64 qemux86 qemuppc
> >>> Removing the sstate-xxx_deploy-rpm.tgz ... (3034 files)
> >>> Removing the sstate-xxx_deploy-ipk.tgz ... (0 files)
> >>> Removing the sstate-xxx_deploy-deb.tgz ... (0 files)
> >>> Removing the sstate-xxx_deploy.tgz ... (8 files)
> >>> Removing the sstate-xxx_package.tgz ... (3282 files)
> >>> Removing the sstate-xxx_populate-lic.tgz ... (2482 files)
> >>> Removing the sstate-xxx_populate-sysroot.tgz ... (3282 files)
> >>> 12088 files have been removed
> >>> 
> >>> // Robert
> >>> 
> >>> The following changes since commit 87e32edb88c30ac116fa396148ac26357051f93a:
> >>> 
> >>> iputils: Add base_libdir to VPATH in order to find the crypto library (2012-02-21 17:59:40 +0000)
> >>> 
> >>> are available in the git repository at:
> >>> git://git.pokylinux.org/poky-contrib robert/remove-sstate
> >>> http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=robert/remove-sstate
> >> 
> >> Do you have a patch against oe-core instead of poky??!?
> > 
> > Does this really need as many question and exclamation marks???!!!!????!
> > 
> > ;-)
> > 
> > Its not hard to manipulate the patches around from one tree to the
> > other.
> 
> That's good to know, so why wasn't it manipulated to work on oe-core when being sent to the oe-core list?

Or why can't people just cherry-pick the patch in, or apply the patch
manually? The latter is no different to people who just supply the
patches manually the the list with no corresponding git tree after all.

Cheers,

Richard
Koen Kooi - Feb. 22, 2012, 3:11 p.m.
Op 22 feb. 2012, om 16:06 heeft Richard Purdie het volgende geschreven:

> On Wed, 2012-02-22 at 15:32 +0100, Koen Kooi wrote:
>> Op 22 feb. 2012, om 15:15 heeft Richard Purdie het volgende geschreven:
>> 
>>> On Wed, 2012-02-22 at 14:42 +0100, Koen Kooi wrote:
>>>> Op 22 feb. 2012, om 14:27 heeft Robert Yang het volgende geschreven:
>>>> 
>>>>> Here is the testing result:
>>>>> 
>>>>> $ ./poky/scripts/sstate-cache-management.sh --cache-dir=sstate-cache.bak/ --remove-duplicated
>>>>> Figuring out the archs in the sstate cache dir ...
>>>>> The following archs have been found in the sstate cache dir:
>>>>> i586 ppc603e x86_64 qemux86 qemuppc
>>>>> Removing the sstate-xxx_deploy-rpm.tgz ... (3034 files)
>>>>> Removing the sstate-xxx_deploy-ipk.tgz ... (0 files)
>>>>> Removing the sstate-xxx_deploy-deb.tgz ... (0 files)
>>>>> Removing the sstate-xxx_deploy.tgz ... (8 files)
>>>>> Removing the sstate-xxx_package.tgz ... (3282 files)
>>>>> Removing the sstate-xxx_populate-lic.tgz ... (2482 files)
>>>>> Removing the sstate-xxx_populate-sysroot.tgz ... (3282 files)
>>>>> 12088 files have been removed
>>>>> 
>>>>> // Robert
>>>>> 
>>>>> The following changes since commit 87e32edb88c30ac116fa396148ac26357051f93a:
>>>>> 
>>>>> iputils: Add base_libdir to VPATH in order to find the crypto library (2012-02-21 17:59:40 +0000)
>>>>> 
>>>>> are available in the git repository at:
>>>>> git://git.pokylinux.org/poky-contrib robert/remove-sstate
>>>>> http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=robert/remove-sstate
>>>> 
>>>> Do you have a patch against oe-core instead of poky??!?
>>> 
>>> Does this really need as many question and exclamation marks???!!!!????!
>>> 
>>> ;-)
>>> 
>>> Its not hard to manipulate the patches around from one tree to the
>>> other.
>> 
>> That's good to know, so why wasn't it manipulated to work on oe-core when being sent to the oe-core list?
> 
> Or why can't people just cherry-pick the patch in, or apply the patch
> manually? 

Personally, I'm too lazy for that. If someone sends a pull request to oe-core I kinda assume it's for oe-core. I tried to pull it in for testing and it blew up.
Otavio Salvador - Feb. 22, 2012, 3:47 p.m.
On Wed, Feb 22, 2012 at 13:06, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> Or why can't people just cherry-pick the patch in, or apply the patch
> manually? The latter is no different to people who just supply the
> patches manually the the list with no corresponding git tree after all.

Because this mean to have and maintain a full clone of the repository
and I don't want and I won't do that.

OE-Core is the base, the mailing list is based on it so it is expected
of it being based on OE-Core.
Paul Eggleton - Feb. 22, 2012, 3:53 p.m.
On Wednesday 22 February 2012 13:47:45 Otavio Salvador wrote:
> On Wed, Feb 22, 2012 at 13:06, Richard Purdie
> 
> <richard.purdie@linuxfoundation.org> wrote:
> > Or why can't people just cherry-pick the patch in, or apply the patch
> > manually? The latter is no different to people who just supply the
> > patches manually the the list with no corresponding git tree after all.
> 
> Because this mean to have and maintain a full clone of the repository
> and I don't want and I won't do that.

Except here we are talking about a single patch that adds a single file, which 
is easily downloadable from the web interface. If it were more complicated I 
could understand the fuss, but right now this is almost ridiculous.

Cheers,
Paul
Otavio Salvador - Feb. 22, 2012, 3:56 p.m.
On Wed, Feb 22, 2012 at 13:53, Paul Eggleton
<paul.eggleton@linux.intel.com> wrote:
> Except here we are talking about a single patch that adds a single file, which
> is easily downloadable from the web interface. If it were more complicated I
> could understand the fuss, but right now this is almost ridiculous.

It doesn't seem that easy; it seems Koen tried to apply it and it has failed.

Besides, Robert didn't complain about people asking it to be resend.
Who is complaining is Richard and I am just justifying the reasoning
why it is more the logical to expect it to be done based on OE-Core.
Phil Blundell - Feb. 22, 2012, 4 p.m.
On Wed, 2012-02-22 at 13:47 -0200, Otavio Salvador wrote:
> On Wed, Feb 22, 2012 at 13:06, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> > Or why can't people just cherry-pick the patch in, or apply the patch
> > manually? The latter is no different to people who just supply the
> > patches manually the the list with no corresponding git tree after all.
> 
> Because this mean to have and maintain a full clone of the repository
> and I don't want and I won't do that.

Applying the patch manually (either with "git am" or directly with
"patch") doesn't require you to have a copy of poky on hand.  That
doesn't seem like such a hardship, particularly given that the patch in
question here is just creating a single new file and doesn't touch any
existing content at all.

p.
Richard Purdie - Feb. 22, 2012, 4:05 p.m.
On Wed, 2012-02-22 at 16:11 +0100, Koen Kooi wrote:
> Op 22 feb. 2012, om 16:06 heeft Richard Purdie het volgende geschreven:
> 
> > On Wed, 2012-02-22 at 15:32 +0100, Koen Kooi wrote:
> >> Op 22 feb. 2012, om 15:15 heeft Richard Purdie het volgende geschreven:
> >> 
> >>> On Wed, 2012-02-22 at 14:42 +0100, Koen Kooi wrote:
> >>>> Op 22 feb. 2012, om 14:27 heeft Robert Yang het volgende geschreven:
> >>>> 
> >>>>> Here is the testing result:
> >>>>> 
> >>>>> $ ./poky/scripts/sstate-cache-management.sh --cache-dir=sstate-cache.bak/ --remove-duplicated
> >>>>> Figuring out the archs in the sstate cache dir ...
> >>>>> The following archs have been found in the sstate cache dir:
> >>>>> i586 ppc603e x86_64 qemux86 qemuppc
> >>>>> Removing the sstate-xxx_deploy-rpm.tgz ... (3034 files)
> >>>>> Removing the sstate-xxx_deploy-ipk.tgz ... (0 files)
> >>>>> Removing the sstate-xxx_deploy-deb.tgz ... (0 files)
> >>>>> Removing the sstate-xxx_deploy.tgz ... (8 files)
> >>>>> Removing the sstate-xxx_package.tgz ... (3282 files)
> >>>>> Removing the sstate-xxx_populate-lic.tgz ... (2482 files)
> >>>>> Removing the sstate-xxx_populate-sysroot.tgz ... (3282 files)
> >>>>> 12088 files have been removed
> >>>>> 
> >>>>> // Robert
> >>>>> 
> >>>>> The following changes since commit 87e32edb88c30ac116fa396148ac26357051f93a:
> >>>>> 
> >>>>> iputils: Add base_libdir to VPATH in order to find the crypto library (2012-02-21 17:59:40 +0000)
> >>>>> 
> >>>>> are available in the git repository at:
> >>>>> git://git.pokylinux.org/poky-contrib robert/remove-sstate
> >>>>> http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=robert/remove-sstate
> >>>> 
> >>>> Do you have a patch against oe-core instead of poky??!?
> >>> 
> >>> Does this really need as many question and exclamation marks???!!!!????!
> >>> 
> >>> ;-)
> >>> 
> >>> Its not hard to manipulate the patches around from one tree to the
> >>> other.
> >> 
> >> That's good to know, so why wasn't it manipulated to work on oe-core when being sent to the oe-core list?
> > 
> > Or why can't people just cherry-pick the patch in, or apply the patch
> > manually? 
> 
> Personally, I'm too lazy for that. If someone sends a pull request to
> oe-core I kinda assume it's for oe-core. I tried to pull it in for
> testing and it blew up.

So I think its reasonable for people to indicate which tree the pull
request is based off and I'll suggest people do this in future.

If its not indicated, oe-core is a reasonable assumption but providing a
poky tree for convenience shouldn't cause quite as much friction as it
does since it is better than no tree at all and some of us can manage
them fine.

Cheers,

Richard
Otavio Salvador - Feb. 22, 2012, 4:08 p.m.
On Wed, Feb 22, 2012 at 14:05, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> If its not indicated, oe-core is a reasonable assumption but providing a
> poky tree for convenience shouldn't cause quite as much friction as it
> does since it is better than no tree at all and some of us can manage
> them fine.

I fully disagree.

This is an OE-Core mailing list so it is expected to have patches here
based on OE-Core mailing list.

Mistakes are also expected to happen, as just did, and it is just a
matter of resending it to fix it. Relaxing it will make the whole
testing cycle a nightmare for all people involved in OE-Core.
Richard Purdie - Feb. 22, 2012, 4:09 p.m.
On Wed, 2012-02-22 at 13:56 -0200, Otavio Salvador wrote:
> On Wed, Feb 22, 2012 at 13:53, Paul Eggleton
> <paul.eggleton@linux.intel.com> wrote:
> > Except here we are talking about a single patch that adds a single file, which
> > is easily downloadable from the web interface. If it were more complicated I
> > could understand the fuss, but right now this is almost ridiculous.
> 
> It doesn't seem that easy; it seems Koen tried to apply it and it has failed.
> 
> Besides, Robert didn't complain about people asking it to be resend.
> Who is complaining is Richard and I am just justifying the reasoning
> why it is more the logical to expect it to be done based on OE-Core.

In this case, Richard is presenting the viewpoint he's heard expressed
by a number of people in private but who don't want to rock the boat on
the mailing list. I'd like to see the mailing list be a friendly place
where people don't get flamed for posting patches. Some of the recent
responses are less than friendly and I think its reasonable to try and
resolve this.

I'm going to propose that if trees are poky based, the pull request
should indicate this. People can then act accordingly. No indication
means its oe-core derived.

Cheers,

Richard
Otavio Salvador - Feb. 22, 2012, 4:16 p.m.
On Wed, Feb 22, 2012 at 14:09, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> On Wed, 2012-02-22 at 13:56 -0200, Otavio Salvador wrote:
>> On Wed, Feb 22, 2012 at 13:53, Paul Eggleton
>> <paul.eggleton@linux.intel.com> wrote:
>> > Except here we are talking about a single patch that adds a single file, which
>> > is easily downloadable from the web interface. If it were more complicated I
>> > could understand the fuss, but right now this is almost ridiculous.
>>
>> It doesn't seem that easy; it seems Koen tried to apply it and it has failed.
>>
>> Besides, Robert didn't complain about people asking it to be resend.
>> Who is complaining is Richard and I am just justifying the reasoning
>> why it is more the logical to expect it to be done based on OE-Core.
>
> In this case, Richard is presenting the viewpoint he's heard expressed
> by a number of people in private but who don't want to rock the boat on
> the mailing list. I'd like to see the mailing list be a friendly place
> where people don't get flamed for posting patches. Some of the recent
> responses are less than friendly and I think its reasonable to try and
> resolve this.
>
> I'm going to propose that if trees are poky based, the pull request
> should indicate this. People can then act accordingly. No indication
> means its oe-core derived.

If you look at *my* first reply to this thread I just asked him to
resend it based on OE-Core - as he already did - so I could give it a
test. This seemed quite friendly from my POV and he didn't complain.

If people dislike it, it is better if they show up and don't hide behind you.
Richard Purdie - Feb. 22, 2012, 4:43 p.m.
On Wed, 2012-02-22 at 14:16 -0200, Otavio Salvador wrote:
> If you look at *my* first reply to this thread I just asked him to
> resend it based on OE-Core - as he already did - so I could give it a
> test. This seemed quite friendly from my POV and he didn't complain.

You'll also notice I directed my comments to Koen's reply, not yours.

Since we're on the subject though, I do believe there is marginal value
in asking someone to rebase a single patch you could have just as easily
downloaded and applied yourself. I am respectful and protective of
people's time and in this case I think there are better ways things
could have been handled.

Overall though my main objective was to avoid these "Please rebase on
OE-Core????!!!!?" type messages and I think we've figured out a way to
do that.

> If people dislike it, it is better if they show up and don't hide behind you.

We have many different people involved with the project with different
personalities and cultural backgrounds. Open source projects should be
as open, inclusive and friendly as possible in my view. We do have some
participants who get put off by the form of some of the replies on list
and would prefer not to get involved in what could potentially become
"flame war" type discussions. I'd even personally like to avoid them to
as they kill my productivity but sadly my role means I cannot.

I am happy to listen to people's concerns and do what I can to improve
things where I see opportunities. I only received comments from one
other person about this specific thread and they have responded on list.
I have received many different comments on the general topic from
previous similar threads though so I do have an idea of some people's
feelings on this topic. I happen to have chosen this moment in time to
try and resolve the issue. I don't see an problem in any of these
things.

Cheers,

Richard
Saul Wold - Feb. 24, 2012, 4:13 a.m.
On 02/22/2012 05:27 AM, Robert Yang wrote:
> Here is the testing result:
>
> $ ./poky/scripts/sstate-cache-management.sh --cache-dir=sstate-cache.bak/ --remove-duplicated
> Figuring out the archs in the sstate cache dir ...
> The following archs have been found in the sstate cache dir:
> i586 ppc603e x86_64 qemux86 qemuppc
> Removing the sstate-xxx_deploy-rpm.tgz ... (3034 files)
> Removing the sstate-xxx_deploy-ipk.tgz ... (0 files)
> Removing the sstate-xxx_deploy-deb.tgz ... (0 files)
> Removing the sstate-xxx_deploy.tgz ... (8 files)
> Removing the sstate-xxx_package.tgz ... (3282 files)
> Removing the sstate-xxx_populate-lic.tgz ... (2482 files)
> Removing the sstate-xxx_populate-sysroot.tgz ... (3282 files)
> 12088 files have been removed
>
> // Robert
>
> The following changes since commit 87e32edb88c30ac116fa396148ac26357051f93a:
>
>    iputils: Add base_libdir to VPATH in order to find the crypto library (2012-02-21 17:59:40 +0000)
>
> are available in the git repository at:
>    git://git.pokylinux.org/poky-contrib robert/remove-sstate
>    http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=robert/remove-sstate
>
> Robert Yang (1):
>    A script to clean obsolete sstate cache files
>
>   scripts/sstate-cache-management.sh |  135 ++++++++++++++++++++++++++++++++++++
>   1 files changed, 135 insertions(+), 0 deletions(-)
>   create mode 100755 scripts/sstate-cache-management.sh
>

Merged into OE-core

Thanks
	Sau!