I guess the problem here is not that you have two versions of u-boot but that you are trying to include both of them at once - e.g. one you added explicitly via IMAGE_INSTALL and one that the machine

This doesn’t seem to be a viable option. I’m still missing something I think. We are adding our own layer on top of our soc vendor’s layer. In their layer there is a specialized u-boot

Current Dev Position: YP 2.1 M4 (Stabilization only milestone.) Next Deadline: YP 2.1 Final Release Target: April 29, 2016 SWAT team rotation: Saul ->

As the stock u-boot appears to be sufficient I'd say use that and then add a u-boot-faux-debug_2014.04.bb recipe that just does "include u-boot-${PV}.bb" and then whatever SRC_URI changes you want in

Ross, Perfect thank you so much. That makes total sense now. I like the idea of just having two different recipes and then use IMAGE_INSTALL. However, in the u-boot example I’m actually

You can't. The basic reason being that images are built from packages, and the packages have already been built when the image is built. In your view, what would happen if you did "bitbake faux-app

Dear Yocto, First of all, I love this project. Thanks for all your hard work. Question: What is the prescribed way to allow image recipes to make global configuration variables that other

In principle, yes - if you need to have pygobject both for 2 and 3 at the same time, you can have two slightly different recipes; but I don't know if it will work. You need to try and see. Alex

in my travels, i frequently read online about people asking how to set up a kernel recipe to point at a local kernel source tree or local kernel git repo and, as best i can tell, this isn't really

This causes do_populate_sysroot error if build two or more types of refpolicy: $ bitbake refpolicy-minimum && bitbake refpolicy-mls ERROR: refpolicy-mls-git-r0 do_populate_sysroot: The recipe

From: Wenzong Fan <wenzong.fan@...> Apply the changes to refpolicy-minimum_2.20151208.bb: commit bfaf278116e6c3a04bb82c9f8a4f8629a0a85df8 Author: Wenzong Fan

Signed-off-by: Yi Zhao <yi.zhao@...> --- documentation/dev-manual/dev-manual-common-tasks.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

I think you should try with master first

> To: yocto@... > From: alexander.kanavin@... > Date: Thu, 7 Apr 2016 16:40:30 +0300 > Subject: Re: [yocto] Python GObject Errors on yocto-2.1_M3.rc2 > > On 04/07/2016 04:35 PM, Burton, Ross wrote: >

The clue is in the output. Don't use -b as it doesn't build dependencies, which is why configure fails. Just do: $ bitbake php Ross

The CC and CXX variables imported from the Yocto build environment may contain additional compiler flags after the compiler name. Extract those and add them to cmake toolchain file variables,

It looks like the variable is indeed defined, however not in a way where I could have seen it via the devshell. I fixed the build by adding an additional `--with-linux-obj=${STAGING_KERNEL_BUILDDIR}`,

Scripts would be fine, however the minimal image boots fine with above and the scripts add about 15K compressed. thats why its removed

Hello, I'm beginning a process to try to build zfs-on-linux for my image (as I have yet to find any existing work in this area), and am running into some trouble building out of tree kernel modules

Yeah, the annoying side effect is that every python thingy needs to be packaged twice - not so visible in oe-core, but very visible in meta-oe's