One more workflow question: so to test my patch, I need to commit it to my real git repo, then push to the bare git repo, then rebuild Poky. When I find the inevitable problem, do I need to manually

Hello Martin, Thanks for the info. Oops. Will bbappend to the above mentioned recipe. Regards Joshua -- Joshua Immanuel HiPro IT Solutions Private Limited http://hipro.co.in

You need to set something like FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:" for fetcher to look in ${PN} subdirectory of directory where you have .bbappend And you're bbappending wrong recipe,

Hello all, I added a base-files_3.0.14.bbappend file in my custom layer and pointed the SRC_URI as follows SRC_URI += "file://xorg.conf" The xorg.conf file is at

Hi, I'm attempting to build the head of the master branch, targeting core-image-minimal on qemux86 with an up to date Ubuntu 10.04 32-bit system. I am getting the following error from

Ni Qingliang wrote on 2012-02-17: In case you need another target sysroot which is different from the sysroot defined in the environment files. Best Regards, Lianhao

thanks! another question: why I must specify the sysroot location in eclipse plugin? the environment-setup has it already. -- Yi

Ni Qingliang wrote on 2012-02-17: The eclipse-plugin by default assumes the user using the same target sysroot for both cross compiling and qemu launching. So this requires the target sysroot having

the environment-setup file in build tree had defined CFLAGS and CXXFLAGS which include the sysroot argument(<build_tree>/tmp/sysroots/<machine>). Do we must specify the sysroot location in the

thanks, I found the problem, I have setup one new meta layer, and use a new distro (new name and new version), but the eclipse-plugin is only for native poky distro, and will check if the version is

Ni Qingliang wrote on 2012-02-17: Looks like you're using the 1.1 eclipse plugin against the 1.1+snapshot poky. You may manually change the OECORE_SDK_VERSION in the environment file as a workaround.

and there is no use to change DISTRO_VERSION in <build_tree>/tmp/tmp/environment-setup-ppc603e-insigma-linux. -- Yi Qingliang niqingliang@... https://niqingliang2003.wordpress.com

I'm using the ecipse-plugin: http://autobuilder.yoctoproject.org/pub/nightly/20120216-2/eclipse-plugin/indigo/org.yocto.sdk-rc1-201202161547-archive.zip my build tree is following the latest yocto

It's a build system thing, what can I say ? When you are working with the raw tree, and your own cross compiler, that's absolutely the workflow. It's the same as having to write recipes versus

Hmm, I'm not at all a git expert, but I thought common practice was to clone the upstream git tree, then create local branches that track the upstream ones. I've never seen any directions say "first

The point is that the tree is local to your machine, but it doesn't have to be. You may only have push, not direct commit access. It's really not asking for anything that isn't already common

Do I want to do my development in a different tree? Are you sure? ;) I don't need to scale to hundreds of branches -- I just have one small patch I wanted to test. I already have it in a "clean" tree

That's the problem. I have a patch that detects this and abort is a non bare upstream is used. I just need to send them .. which I'll do when I get back to my desk next week. There are two reason for

On 02/16/2012 02:11 PM, Bruce Ashfield wrote: I ran this: [snip] As you can tell from my clone command above, it is a non-bare clone (though I have no idea what that actually

I just sent a reply with this. We crossed on the 'net. I have changes to detect and report this, but yes, it would be the clone tripping us up. I've never seen the heads vs head change, but all my