| Submitter | Richard Purdie |
|---|---|
| Date | Oct. 19, 2012, 2:48 p.m. |
| Message ID | <1350658135.2520.29.camel@ted> |
| Download | mbox | patch |
| Permalink | /patch/38335/ |
| State | Accepted |
| Commit | febeaf3d1b8917b660c7279b008d8b03337568e9 |
| Headers | show |
Comments
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@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 ... Cheers,
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@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. Can you figure out which two recipes are trying to install these sets of files? 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? Cheers, Richard
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@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,
On Mon, 2012-10-22 at 13:08 +0200, Martin Jansa wrote: > 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@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. If the warnings are showing up even after building one machine, there is something very strange going on. Did it run the setscene do_package task for these recipes? Its as if it installed from sstate and then decided to overwrite the files. Something isn't making sense though :/. Firstly, the sstate should have been invalidated due to the package class and variable changes. Secondly, if it had installed the files, it should be uninstalled them before installing a second set. So I'm confused as to what is going on here... Cheers, Richard
On Mon, Oct 22, 2012 at 12:42:51PM +0100, Richard Purdie wrote: > On Mon, 2012-10-22 at 13:08 +0200, Martin Jansa wrote: > > 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@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. > > If the warnings are showing up even after building one machine, there is > something very strange going on. Did it run the setscene do_package task > for these recipes? No, only for populate_lic and populate_sysroot: NOTE: recipe attr-2.4.46-r4: task do_populate_sysroot_setscene: Started NOTE: recipe attr-2.4.46-r4: task do_populate_sysroot_setscene: Succeeded NOTE: recipe attr-2.4.46-r4: task do_populate_lic_setscene: Started NOTE: recipe attr-2.4.46-r4: task do_populate_lic_setscene: Succeeded NOTE: recipe attr-2.4.46-r4: task do_fetch: Started NOTE: recipe attr-2.4.46-r4: task do_fetch: Succeeded NOTE: recipe attr-2.4.46-r4: task do_unpack: Started NOTE: recipe attr-2.4.46-r4: task do_unpack: Succeeded NOTE: recipe attr-2.4.46-r4: task do_patch: Started NOTE: recipe attr-2.4.46-r4: task do_patch: Succeeded NOTE: recipe attr-2.4.46-r4: task do_configure: Started NOTE: recipe attr-2.4.46-r4: task do_configure: Succeeded NOTE: recipe attr-2.4.46-r4: task do_compile: Started NOTE: recipe attr-2.4.46-r4: task do_compile: Succeeded NOTE: recipe attr-2.4.46-r4: task do_install: Started NOTE: recipe attr-2.4.46-r4: task do_install: Succeeded NOTE: recipe attr-2.4.46-r4: task do_populate_sysroot: Started NOTE: recipe attr-2.4.46-r4: task do_populate_sysroot: Succeeded NOTE: recipe attr-2.4.46-r4: task do_package: Started NOTE: recipe attr-2.4.46-r4: task do_package: Succeeded NOTE: recipe attr-2.4.46-r4: task do_package_write_ipk: Started NOTE: recipe attr-2.4.46-r4: task do_package_write_ipk: Succeeded NOTE: recipe attr-2.4.46-r4: task do_rm_work: Started NOTE: recipe attr-2.4.46-r4: task do_rm_work: Succeeded But I see this behavior when setscene tasks are executed and later it rebuilds it again quite often (assuming that some error in setscene task was hidden - e.g. that fetcher error from https://bugzilla.yoctoproject.org/show_bug.cgi?id=3250 wasn't shown until lately, but maybe was there all the time) > Its as if it installed from sstate and then decided to overwrite the > files. Something isn't making sense though :/. Firstly, the sstate > should have been invalidated due to the package class and variable > changes. Secondly, if it had installed the files, it should be > uninstalled them before installing a second set. So I'm confused as to > what is going on here... It seems to reinstall a lot of files in sysroot too (which weren't shown before). e.g. all files from gst-plugins-good now show warning WARNING: The recipe gst-plugins-good is trying to install files into a shared area when those files already exist. Those files are: /OE/jansa-test/shr-core/tmp-eglibc/sysroots/tuna/usr/share/gstreamer-0.10/presets/GstIirEqualizer10Bands.prs /OE/jansa-test/shr-core/tmp-eglibc/sysroots/tuna/usr/share/gstreamer-0.10/presets/GstIirEqualizer3Bands.prs ... I'll try to wipe tmp-eglibc again after this build finishes to see if it was one off or if it will repeat again. Cheers,
On Mon, Oct 22, 2012 at 02:02:34PM +0200, Martin Jansa wrote: > On Mon, Oct 22, 2012 at 12:42:51PM +0100, Richard Purdie wrote: > > On Mon, 2012-10-22 at 13:08 +0200, Martin Jansa wrote: > > > 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@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. Hmm, checksums are different not only for target recipes but also for native now: OE @ ~/jansa-test/shr-core $ ls */*/*/zlib-native*do_package.sigdata* stamps.1350908965/nokia900/x86_64-linux/zlib-native-1.2.7-r0.do_package.sigdata.f8ca8403df4a25b68553291341717a29 stamps.1350908965/om-gta02/x86_64-linux/zlib-native-1.2.7-r0.do_package.sigdata.af2b16d88415c39245731409c8e15f70 stamps.1350908965/tuna/x86_64-linux/zlib-native-1.2.7-r0.do_package.sigdata.815e9385589d3ffe41099fca79c3d8e7 OE @ ~/jansa-test/shr-core $ ls */*/*/zlib-1*do_package.sigdata* stamps.1350908965/nokia900/armv7a-vfp-neon-oe-linux-gnueabi/zlib-1.2.7-r0.do_package.sigdata.3c23b95f321e5430b3d21d7288acea89 stamps.1350908965/om-gta02/armv4t-oe-linux-gnueabi/zlib-1.2.7-r0.do_package.sigdata.bcfc3d562d4dc6d85b2d8bf0aa7f0b89 stamps.1350908965/tuna/armv7a-vfp-neon-oe-linux-gnueabi/zlib-1.2.7-r0.do_package.sigdata.0b50fd9e90c6c922877f637378280163 OE om-gta02@shr ~/jansa-test/shr-core $ bitbake-diffsigs stamps.1350908965/nokia900/armv7a-vfp-neon-oe-linux-gnueabi/zlib-1.2.7-r0.do_package.sigdata.3c23b95f321e5430b3d21d7288acea89 stamps.1350908965/tuna/armv7a-vfp-neon-oe-linux-gnueabi/zlib-1.2.7-r0.do_package.sigdata.0b50fd9e90c6c922877f637378280163 basehash changed from ff270729884d94ba712e579e19e9989f to b01c64c65799d2a3febcf7ec164a8b14 Variable PKGTRIPLETS value changed from nokia900-oe-linux-gnueabi armv7a-vfp-neon-oe-linux-gnueabi armv7a-vfp-oe-linux-gnueabi armv7a-oe-linux-gnueabi armv6-vfp-oe-linux-gnueabi armv5e-vfp-oe-linux-gnueabi armv5e-oe-linux-gnueabi armv5-vfp-oe-linux-gnueabi armv5-oe-linux-gnueabi armv4-oe-linux-gnueabi arm-oe-linux-gnueabi noarch-oe-linux-gnueabi any-oe-linux-gnueabi all-oe-linux-gnueabi to tuna-oe-linux-gnueabi armv7a-vfp-neon-oe-linux-gnueabi armv7a-vfp-oe-linux-gnueabi armv7a-oe-linux-gnueabi armv6-vfp-oe-linux-gnueabi armv5e-vfp-oe-linux-gnueabi armv5e-oe-linux-gnueabi armv5-vfp-oe-linux-gnueabi armv5-oe-linux-gnueabi armv4-oe-linux-gnueabi arm-oe-linux-gnueabi noarch-oe-linux-gnueabi any-oe-linux-gnueabi all-oe-linux-gnueabi Hash for dependent task eglibc_2.16.bb.do_package changed from 44e54b452f831141f15d7fa61a637997 to 31b9950443659def02296d4b2aed43a5 Hash for dependent task gcc-runtime_4.7.bb.do_package changed from 7db515c51f06c6db5a77e8f089aedf64 to 6e1ee054521f3a41fcc6e17aa0d8acbc OE om-gta02@shr ~/jansa-test/shr-core $ bitbake-diffsigs stamps.1350908965/nokia900/x86_64-linux/zlib-native-1.2.7-r0.do_package.sigdata.f8ca8403df4a25b68553291341717a29 stamps.1350908965/tuna/x86_64-linux/zlib-native-1.2.7-r0.do_package.sigdata.815e9385589d3ffe41099fca79c3d8e7 basehash changed from b086f2a2ad21c163d0002edd355103fb to 61aa7f2d5d3ec073cbde0e1df1b0813b Variable PKGTRIPLETS value changed from nokia900-linux armv7a-vfp-neon-linux armv7a-vfp-linux armv7a-linux armv6-vfp-linux armv5e-vfp-linux armv5e-linux armv5-vfp-linux armv5-linux armv4-linux arm-linux noarch-linux any-linux all-linux to tuna-linux armv7a-vfp-neon-linux armv7a-vfp-linux armv7a-linux armv6-vfp-linux armv5e-vfp-linux armv5e-linux armv5-vfp-linux armv5-linux armv4-linux arm-linux noarch-linux any-linux all-linux I guess I don't need to build test anything now.. > > > > 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. > > > > If the warnings are showing up even after building one machine, there is > > something very strange going on. Did it run the setscene do_package task > > for these recipes? > > No, only for populate_lic and populate_sysroot: > > NOTE: recipe attr-2.4.46-r4: task do_populate_sysroot_setscene: Started > NOTE: recipe attr-2.4.46-r4: task do_populate_sysroot_setscene: Succeeded > NOTE: recipe attr-2.4.46-r4: task do_populate_lic_setscene: Started > NOTE: recipe attr-2.4.46-r4: task do_populate_lic_setscene: Succeeded > NOTE: recipe attr-2.4.46-r4: task do_fetch: Started > NOTE: recipe attr-2.4.46-r4: task do_fetch: Succeeded > NOTE: recipe attr-2.4.46-r4: task do_unpack: Started > NOTE: recipe attr-2.4.46-r4: task do_unpack: Succeeded > NOTE: recipe attr-2.4.46-r4: task do_patch: Started > NOTE: recipe attr-2.4.46-r4: task do_patch: Succeeded > NOTE: recipe attr-2.4.46-r4: task do_configure: Started > NOTE: recipe attr-2.4.46-r4: task do_configure: Succeeded > NOTE: recipe attr-2.4.46-r4: task do_compile: Started > NOTE: recipe attr-2.4.46-r4: task do_compile: Succeeded > NOTE: recipe attr-2.4.46-r4: task do_install: Started > NOTE: recipe attr-2.4.46-r4: task do_install: Succeeded > NOTE: recipe attr-2.4.46-r4: task do_populate_sysroot: Started > NOTE: recipe attr-2.4.46-r4: task do_populate_sysroot: Succeeded > NOTE: recipe attr-2.4.46-r4: task do_package: Started > NOTE: recipe attr-2.4.46-r4: task do_package: Succeeded > NOTE: recipe attr-2.4.46-r4: task do_package_write_ipk: Started > NOTE: recipe attr-2.4.46-r4: task do_package_write_ipk: Succeeded > NOTE: recipe attr-2.4.46-r4: task do_rm_work: Started > NOTE: recipe attr-2.4.46-r4: task do_rm_work: Succeeded > > But I see this behavior when setscene tasks are executed and > later it rebuilds it again quite often (assuming that some error > in setscene task was hidden - e.g. that fetcher error from > https://bugzilla.yoctoproject.org/show_bug.cgi?id=3250 > wasn't shown until lately, but maybe was there all the time) > > > Its as if it installed from sstate and then decided to overwrite the > > files. Something isn't making sense though :/. Firstly, the sstate > > should have been invalidated due to the package class and variable > > changes. Secondly, if it had installed the files, it should be > > uninstalled them before installing a second set. So I'm confused as to > > what is going on here... > > It seems to reinstall a lot of files in sysroot too (which weren't shown before). > > e.g. all files from gst-plugins-good now show warning > WARNING: The recipe gst-plugins-good is trying to install files into a shared area when those files already exist. Those files are: > /OE/jansa-test/shr-core/tmp-eglibc/sysroots/tuna/usr/share/gstreamer-0.10/presets/GstIirEqualizer10Bands.prs > /OE/jansa-test/shr-core/tmp-eglibc/sysroots/tuna/usr/share/gstreamer-0.10/presets/GstIirEqualizer3Bands.prs > ... > > I'll try to wipe tmp-eglibc again after this build finishes to see if it was > one off or if it will repeat again.
On Mon, 2012-10-22 at 15:17 +0200, Martin Jansa wrote: > On Mon, Oct 22, 2012 at 02:02:34PM +0200, Martin Jansa wrote: > > On Mon, Oct 22, 2012 at 12:42:51PM +0100, Richard Purdie wrote: > > > On Mon, 2012-10-22 at 13:08 +0200, Martin Jansa wrote: > > > > 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@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. > > Hmm, checksums are different not only for target recipes but also for native now: > > OE @ ~/jansa-test/shr-core $ ls */*/*/zlib-native*do_package.sigdata* > stamps.1350908965/nokia900/x86_64-linux/zlib-native-1.2.7-r0.do_package.sigdata.f8ca8403df4a25b68553291341717a29 > stamps.1350908965/om-gta02/x86_64-linux/zlib-native-1.2.7-r0.do_package.sigdata.af2b16d88415c39245731409c8e15f70 > stamps.1350908965/tuna/x86_64-linux/zlib-native-1.2.7-r0.do_package.sigdata.815e9385589d3ffe41099fca79c3d8e7 > OE @ ~/jansa-test/shr-core $ ls */*/*/zlib-1*do_package.sigdata* > stamps.1350908965/nokia900/armv7a-vfp-neon-oe-linux-gnueabi/zlib-1.2.7-r0.do_package.sigdata.3c23b95f321e5430b3d21d7288acea89 > stamps.1350908965/om-gta02/armv4t-oe-linux-gnueabi/zlib-1.2.7-r0.do_package.sigdata.bcfc3d562d4dc6d85b2d8bf0aa7f0b89 > stamps.1350908965/tuna/armv7a-vfp-neon-oe-linux-gnueabi/zlib-1.2.7-r0.do_package.sigdata.0b50fd9e90c6c922877f637378280163 > > OE om-gta02@shr ~/jansa-test/shr-core $ bitbake-diffsigs stamps.1350908965/nokia900/armv7a-vfp-neon-oe-linux-gnueabi/zlib-1.2.7-r0.do_package.sigdata.3c23b95f321e5430b3d21d7288acea89 stamps.1350908965/tuna/armv7a-vfp-neon-oe-linux-gnueabi/zlib-1.2.7-r0.do_package.sigdata.0b50fd9e90c6c922877f637378280163 > basehash changed from ff270729884d94ba712e579e19e9989f to b01c64c65799d2a3febcf7ec164a8b14 > Variable PKGTRIPLETS value changed from nokia900-oe-linux-gnueabi armv7a-vfp-neon-oe-linux-gnueabi armv7a-vfp-oe-linux-gnueabi armv7a-oe-linux-gnueabi armv6-vfp-oe-linux-gnueabi armv5e-vfp-oe-linux-gnueabi armv5e-oe-linux-gnueabi armv5-vfp-oe-linux-gnueabi armv5-oe-linux-gnueabi armv4-oe-linux-gnueabi arm-oe-linux-gnueabi noarch-oe-linux-gnueabi any-oe-linux-gnueabi all-oe-linux-gnueabi to tuna-oe-linux-gnueabi armv7a-vfp-neon-oe-linux-gnueabi armv7a-vfp-oe-linux-gnueabi armv7a-oe-linux-gnueabi armv6-vfp-oe-linux-gnueabi armv5e-vfp-oe-linux-gnueabi armv5e-oe-linux-gnueabi armv5-vfp-oe-linux-gnueabi armv5-oe-linux-gnueabi armv4-oe-linux-gnueabi arm-oe-linux-gnueabi noarch-oe-linux-gnueabi any-oe-linux-gnueabi all-oe-linux-gnueabi > Hash for dependent task eglibc_2.16.bb.do_package changed from 44e54b452f831141f15d7fa61a637997 to 31b9950443659def02296d4b2aed43a5 > Hash for dependent task gcc-runtime_4.7.bb.do_package changed from 7db515c51f06c6db5a77e8f089aedf64 to 6e1ee054521f3a41fcc6e17aa0d8acbc Ah, thanks, this explains a few things. I'll exclude that from the checksums as this isn't the way it was intended to work. I'm not sure how my tests locally didn't show this up :/. Cheers, Richard
Patch
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/" # Also need to make cross recipes append to ${PN} and install once for any given PACAGE_ARCH so # can avoid multiple installs (e.g. routerstationpro+qemumips both using mips32) SSTATE_DUPWHITELIST += "${STAGING_LIBDIR_NATIVE}/${MULTIMACH_TARGET_SYS} ${STAGING_DIR_NATIVE}/usr/libexec/${MULTIMACH_TARGET_SYS} ${STAGING_BINDIR_NATIVE}/${MULTIMACH_TARGET_SYS} ${STAGING_DIR_NATIVE}${includedir_native}/gcc-build-internal-${MULTIMACH_TARGET_SYS}" @@ -53,9 +50,8 @@ python () { d.setVar('SSTATE_PKGARCH', d.expand("${SDK_ARCH}_${PACKAGE_ARCH}")) elif bb.data.inherits_class('allarch', d): d.setVar('SSTATE_PKGARCH', "allarch") - d.setVar('SSTATE_MANMACH', d.expand("allarch_${MACHINE}")) else: - d.setVar('SSTATE_MANMACH', d.expand("${MACHINE}")) + d.setVar('SSTATE_MANMACH', d.expand("${PACKAGE_ARCH}")) if bb.data.inherits_class('native', d) or bb.data.inherits_class('crosssdk', d) or bb.data.inherits_class('cross', d): d.setVar('SSTATE_EXTRAPATH', "${NATIVELSBSTRING}/") @@ -125,6 +121,9 @@ def sstate_install(ss, d): shareddirs = [] bb.mkdirhier(d.expand("${SSTATE_MANIFESTS}")) manifest = d.expand("${SSTATE_MANFILEPREFIX}.%s" % ss['name']) + extrainf = d.getVarFlag("do_" + ss['task'], 'stamp-extra-info', True) + if extrainf: + manifest = manifest + "." + extrainf if os.access(manifest, os.R_OK): bb.fatal("Package already staged (%s)?!" % manifest) @@ -307,6 +306,9 @@ def sstate_clean(ss, d): import oe.path manifest = d.expand("${SSTATE_MANFILEPREFIX}.%s" % ss['name']) + extrainf = d.getVarFlag("do_" + ss['task'], 'stamp-extra-info', True) + if extrainf: + manifest = manifest + "." + extrainf if os.path.exists(manifest): locks = [] @@ -321,7 +323,6 @@ def sstate_clean(ss, d): bb.utils.unlockfile(lock) stfile = d.getVar("STAMP", True) + ".do_" + ss['task'] - extrainf = d.getVarFlag("do_" + ss['task'], 'stamp-extra-info', True) oe.path.remove(stfile) oe.path.remove(stfile + "_setscene") if extrainf:
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@linuxfoundation.org> ---