this change causes ERROR here with nokia900: Error, the PACKAGE_ARCHS variable contains duplicates. The following archs are listed more than once: armv7a-vfp-neon Regards, -- Martin 'JaMa' Jansa

so in conf/bitbake.conf PACKAGE_ARCH = "${TUNE_PKGARCH}" MACHINE_ARCH = "${@[bb.data.getVar('TUNE_PKGARCH', d, 1), bb.data.getVar('MACHINE', d, 1)][bool(bb.data.getVar('MACHINE', d, 1))].replace('-',

Why do we let the host perl in the path for target installs at all? Is there some precedence for what can be used from the host machine and what can not? -M

I have, it doesn't help. I believe its partly due to how we are appending to TUNE_PKGARCH, but what's not clear to me is what case is failing and looking for just ppc603e instead of powerpcppc603e -

This might also be related to the PACKAGE_EXTRA_ARCHS issue, please try the patch that Koen posted. Thanks Sau!

I think I know the cause, let me dig up the change that is related. What bit is looking for just ppc603e? - k

Hi Kumar, I'm just debugging the same issue. It's caused by folder for the target specific packages being mis-named "powerpcppc603e" instead of "ppc603e" which the rpm package bbclass is expecting.

Anyone got any ideas about the following: | ERROR: Function 'do_rootfs' failed (see

It seems like there is a way to use a prebuilt toolchain with poky but no real details. Some refs in the docs like: POKYMODE Toolchain selector. It can be external toolchain built from Poky or few

Matthew, Thanks for submitting this. A similar fix was recently rejected, as we are looking at a different way to accomplish this. See

Is it normal that the first stage (native) portion does not seem to either deal with BB_NUMBER_THREADS or PARALLEL_MAKE? - k

Saul has not woken up completely yet and thought that Paul made that change, thanks for speaking up! Sau!

Agreed, patch merged to master, thanks. Richard

Hmm, actually I missed the default to xterm change and thus did not alter that aspect of the comments. Therefore I think we should apply this. Cheers, Paul -- Paul Eggleton Intel Open Source

Matthew, Paul Eggelton recently made a similar change so I am going to drop this one. In the future Sau!

The original criteria for what we included was: * One board per architecture * Should be available to a general developer in a relatively cost effective manner (sub $1000?) * Lets us test

This sort of coverage would be great, and your options would be the big ones on my hit list as well. It allows us to at the least ensure that the build coverage is complete. This makes sense as

Most definitely. Having some sort of alignment on the kernel versions is nice, but we definitely don't expect all BSPs to follow every new kernel. And like Richard said, the model you are thinking

Just for reference, this is exactly what meta-intel intends to do. The released versions of the code there are based on a specific release of Yocto/OE-Core. When new BSPs are developed they are likely