From patchwork Tue May 17 06:34:46 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: sstate breakage with multimachine Date: Tue, 17 May 2011 06:34:46 -0000 From: Koen Kooi X-Patchwork-Id: 4217 Message-Id: To: Patches and discussions about the oe-core layer Op 17 mei 2011, om 01:13 heeft Richard Purdie het volgende geschreven: > On Mon, 2011-05-16 at 13:20 +0200, Koen Kooi wrote: >> This bug gets reintroduced every other week, so let's try to fix it >> properly this time. The situation: >> >> 2 machines (beagleboard, pandaboard) using the same base architecture >> (armv7a). >> >> step 0: rm build pseudone -rf >> step 1: MACHINE=beagleboard bitbake console-image >> step 2: MACHINE=omap4430-panda bitbake console-image >> >> Step 0 and 1 work great, but I can't get step 2 to work. Attached is >> the complete output of step 2. As you can see without any updates to >> the repositories it wants to rebuild (e)glibc. >> >> Why does it wants to rebuild all that? Why does it fail? > > I had a look at this. Firstly, I figured out I needed an incantation to > reproduce which turned out to be: > > git clone git://git.angstrom-distribution.org/setup-scripts > git checkout oe-core > MACHINE=beagleboard ./oebb.sh config beagleboard > MACHINE=beagleboard ./oebb.sh bitbake console-image -S > MACHINE=omap4430-panda ./oebb.sh bitbake console-image -S > > I added the -S option to dump sigdata files into the stamp directory so > I didn't need to run two builds before being able to look at this. Sure > enough, if you look > at /media/build2/builds/angstrom/setup-scripts/build/tmp-angstrom_2010_x/stamps/all-angstrom-linux-gnueabi > update-rc.d* then the do_populate_lic task is duplicated as are the > do_package and its subsequent tasks. > > Diffing the do_populate_lic task, it shows DEPLOY_DIR_IMAGE has a > dependency on the MACHINE variable so its correctly rerunning the task > for that reason. This is an Angstrom specific change and adding: > > DEPLOY_DIR_IMAGE = "${DEPLOY_DIR}/images/${MACHINE}" > +DEPLOY_DIR_IMAGE[vardepsexclude] = "MACHINE" > > to conf/distro/include/angstrom.inc makes it go away. I'm not claiming > its the correct fix, it just proves where the problem is. > > Secondly, the do_package task was depending on eglibc do_package. This > is almost certainly due to the default dependencies on things like > virtual/libc which we add. Being an "all" PACKAGE_ARCH, it clearly > doesn't depend on this so adding INHIBIT_DEFAULT_DEPS = "1" to the > update-rc.d recipe removed that problem and meant packaging didn't > rerun. > > Further investigation is needed and these fixes need some thought and > creation of proper patches but hopefully this gives a handle on whats > going on and it turns out its not that hard to figure out (although some > scripts to compare two such runs would be interesting and/or some proper > test cases). > > Note that the DEPLOY_DIR_IMAGE[vardepsexclude] is not correct. The > do_populate_lic task is putting files into the directory and the system > is therefore totally correct in deciding that the task needed to rerun > as the files were being placed in a different directory. do_populate_lic > could likely use some work in that regard as I'm not sure this is the > right place to be putting its data though. Thanks for looking into this! For the time being I'll work around it with: oen@dominion:/OE/tentacle/sources/meta-angstrom$ git diff conf/distro/ Koen diff --git a/conf/distro/include/angstrom-core-tweaks.inc b/conf/distro/include/angstrom-core-tweaks.inc index e4bd798..fe9225c 100644 --- a/conf/distro/include/angstrom-core-tweaks.inc +++ b/conf/distro/include/angstrom-core-tweaks.inc @@ -18,6 +18,11 @@ STAGING_DIR_HOST = "${STAGING_DIR}/${MACHINE}-${TCLIBC}" +# Work around multimachine breakage +# See http://lists.linuxtogo.org/pipermail/openembedded-core/2011-May/002535.html + +LICENSE_DIRECTORY = "${DEPLOY_DIR}/licenses" I think that's a better place to stash those licenses, since we drop images in DEPLOY/image, sources in DEPLOY/sources and sdks in DEPLOY/sdk so DEPLOY/licenses makes sense. Do you want me to send a patch to license.bbclass for this? regards,