Patchwork sstate breakage with multimachine

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

On Tue, 2011-05-17 at 08:34 +0200, Koen Kooi wrote:
> 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/
> 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?

Yes please.

Cheers,

Richard