[OE-core] [PATCH] sstate: Improve handling of machine specific manifests

[Martin Jansa]

On Mon, Oct 22, 2012 at 11:58:28AM +0100, Richard Purdie wrote:
> On Mon, 2012-10-22 at 12:44 +0200, Martin Jansa wrote:
> > On Fri, Oct 19, 2012 at 03:48:55PM +0100, Richard Purdie wrote:
> > > Now do_package isn't machine specific, we're only left with do_populate_sysroot as a
> > > machine specific task. This change marks only the machine specific manifests as machine
> > > specific, defaulting to PACKAGE_ARCH for everything else.
> > > 
> > > This means we do less work where there are multiple machines using the same
> > > core package architecture and we can start to clean up the sstate duplicate files
> > > whitelist.
> > > 
> > > Signed-off-by: Richard Purdie <richard.purdie at linuxfoundation.org>
> > > ---
> > > diff --git a/meta/classes/sstate.bbclass b/meta/classes/sstate.bbclass
> > > index d2a120b..dee84bf 100644
> > > --- a/meta/classes/sstate.bbclass
> > > +++ b/meta/classes/sstate.bbclass
> > > @@ -17,10 +17,7 @@ SSTATE_EXTRAPATH   = ""
> > >  SSTATE_EXTRAPATHWILDCARD = ""
> > >  SSTATE_PATHSPEC   = "${SSTATE_DIR}/${SSTATE_EXTRAPATHWILDCARD}*/${SSTATE_PKGSPEC}"
> > >  
> > > -# In theory we should be using:
> > > -# SSTATE_DUPWHITELIST = "${DEPLOY_DIR_IMAGE}/ ${DEPLOY_DIR}/licenses/ ${DEPLOY_DIR_IPK}/all/ ${DEPLOY_DIR_RPM}/all ${DEPLOY_DIR_DEB}/all/ ${TMPDIR}/pkgdata/all${TARGET_VENDOR}-${TARGET_OS}"
> > > -# However until do_package is not machine specific, we'll have to make do with all of deploy/pkgdata.
> > > -SSTATE_DUPWHITELIST = "${DEPLOY_DIR}/ ${TMPDIR}/pkgdata/"
> > > +SSTATE_DUPWHITELIST = "${DEPLOY_DIR_IMAGE}/ ${DEPLOY_DIR}/licenses/"
> > 
> > Looks like warnings are back :/
> > 
> > WARNING: The recipe attr is trying to install files into a shared area when those files already exist. Those files are:
> >    /OE/jansa-test/shr-core/tmp-eglibc/deploy/ipk/armv7a-vfp-neon/attr-locale-de_2.4.46-r4_armv7a-vfp-neon.ipk
> >    /OE/jansa-test/shr-core/tmp-eglibc/deploy/ipk/armv7a-vfp-neon/attr-dbg_2.4.46-r4_armv7a-vfp-neon.ipk
> >    /OE/jansa-test/shr-core/tmp-eglibc/deploy/ipk/armv7a-vfp-neon/attr-locale-sv_2.4.46-r4_armv7a-vfp-neon.ipk
> > ...
> > 
> > and new warnings from pkgdata
> > WARNING: The recipe bison is trying to install files into a shared area when those files already exist. Those files are:
> >    /OE/jansa-test/shr-core/tmp-eglibc/pkgdata/armv7a-vfp-neon-oe-linux-gnueabi/bison
> >    /OE/jansa-test/shr-core/tmp-eglibc/pkgdata/armv7a-vfp-neon-oe-linux-gnueabi/runtime/bison-locale-nl.packaged
> >    /OE/jansa-test/shr-core/tmp-eglibc/pkgdata/armv7a-vfp-neon-oe-linux-gnueabi/runtime/bison-dbg.packaged
> >    /OE/jansa-test/shr-core/tmp-eglibc/pkgdata/armv7a-vfp-neon-oe-linux-gnueabi/runtime/bison-doc
> >    /OE/jansa-test/shr-core/tmp-eglibc/pkgdata/armv7a-vfp-neon-oe-linux-gnueabi/runtime/bison-locale-th.packaged
> > ...
> 
> The question is why as they shouldn't be, these changes were meant to
> fix this properly. Initially I wondered if this was another
> manifestation of https://bugzilla.yoctoproject.org/show_bug.cgi?id=3219
> but I'm not so sure.

Probably not as this happens on builder with 2 machines using the same
tune and the same CCARGS.

> Can you figure out which two recipes are trying to install these sets of
> files?

I'll try to compare them with scripts/sstate-diff.sh again to see if
checksums are the same between those 2 machines, but those warnings are
shown already when building 1 machine.
 
> Or perhaps this is a one off transition issue I didn't see here when
> testing this? Does a build from a clean tmp do this?

Yes I've removed tmp-eglibc before starting this build (kept only
sstate-cache) and it's building first machine.

Cheers,

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20121022/96aec869/attachment-0002.sig>