At the moment, they are carried forward from kernel version to kernel version and then interpreted by the tools. But I do have some notes and other information that describe how to take upstream tree

2011/6/20 NiQingliang <niqingliang@...>: I'm OpenEmbedded user but this case is similar. OE wiki have solution on "OE and your distro" page, but seems OE website is inaccessible now. I'm

Koen Kooi <koen@...> writes: Several good/bad reasons: 1. Communications so far has been rather clear that OE does not want this kind of change, at least not at this point in

So why not send a patch to make OE-core have per recipe staging?

Hello, Is there someone using archlinux? Under archlinux, the "env python" is pointing to python3, which result in the bitbake's failure. What I can do? I want use "env python=python2", but it

Well, panacea is a very strong work. But per recipe staging does improve build reproducability and reliability quite a bit. As for what it is not, I think you might want to try it before speaking to

<eha@...> wrote: you seem to be stuck in this tight while(1) loop per recipe staging is not panacea Do you have some prototypes ? where you can control what staging is presented and

Which can be properly fixed by using per-recipe (per-workdir) staging. /Esben

Hi all, The open bug number of last week increased to 221. And the weight number of all open bugs increased to 887. QA recovered weekly testing for upstream. Bug status of WW25 could be found on

Thanks, I'll have a look at that. Is there already some doc out on how to create such a structure from scratch?

I've got the linux-yocto-dev recipe in poky-extras, meta-kernel-dev layer. That recipe tracked 2.6.39, and has now jumped to 3.0 (with a minor cheat as I work through the 3.0 naming issues). The

Speaking of .39, is there a 'linux-yocto' type of tree for .39 mainline with a skeleton for machine support? If there is, I'd like to fork it to see if it can improve my current workflow which consist

The .37 isn't used, developed or supported for beagleboard anymore, .39 is all the rage now :)

AFAIK kdrive doesn't read xorg.conf, one of its design principles :) That's we have all those x*-common scripts that start Xfbdev with a gazillion commandline options.

There were about 200 patches in total, I've removed all those that reverse applied and failed do to a conflict that was obviously a merge of a very similar patch. That accounted for most of the

This is my first use of xserver-kdrive. I was experimenting with xorg.conf changes to resolve some USB input issues I was having... it seemed to work. Should it be using something else? Yes, just

You seem to be including the patches that patch the kernel from 37rc7 (or rc8, I forget) to .37 final, which shouldn't apply. So basically leave out the patches in the 'linus' directory. The camera

Since when does kdrive use xorg.conf? Like xserver-xorg-conf in meta-oe?

We need a generic alsa based mechanism that we can use a bbappend to save default mixer controls per bsp. Until that is ready, this ensures the Audio Out on the Beagleboard is enabled out of the

Append xserver-kdrive to allow for BSP specific xorg.conf files. This also appears to drag in a runtime dependency on libhal, so add that to the bbappend's RDEPENDS_${PN} as well. Ultimately we