[OE-core] [PATCH 0/1] A script to clean obsolete sstate cache files

Richard Purdie richard.purdie at linuxfoundation.org
Wed Feb 22 16:05:41 UTC 2012


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





More information about the Openembedded-core mailing list