On Feb 8, 2012, at 8:18 AM, cnxsoft wrote: On 08/02/2012 21:06, autif khan wrote: > On Wed, Feb 8, 2012 at 3:14 AM, cnxsoft<cnxsoft@...> wrote: >> Hi, >> >> .255.0 oprofile.timer=1

I want to change some of the kernel configuration options for my routerstation pro. I have a .config from a 2.6.37 kernel running on my routerstation pro that was not built in Yocto that has the

Hmmm...I'm not sure what to tell you. Really grasping for straws here - one thing you could try is to export the image and load it into VMWare Player and see if there is any difference. If not, that

Thanks Scott. Yes, I have Virtual Box guest additions installed. My host is running Windows XP btw. And yes it was slow...the build for core-image-minimal took around 36 hours... I found a link with

It's perfectly possible, it just may be that you have to create your own bare bones image. The problem with trying to provide generic tasks and images is that everyones opinion of what constitutes

I am sure there are many patches like that in OE, they are written, tested and then forgotten about, our goal here is to not let them get forgotten. Daniel, I think Khem has already said that we are

Am Mittwoch, den 08.02.2012, 10:45 -0800 schrieb Saul Wold: Saul, thank you for the update and enforcing that requirement from the commit and patch message guidelines. Emphasis should be laid on

We understand the lack of upstreaming hence the process of documenting the patches with Upstream-Status was put in place. So step by step we are getting there where we will be able to interact with

I am the maintainer of curl. The curl patches Björn mentioned are clearly not written in way intended to be "upstreamable" so they cannot be accepted by the curl project and nobody has tried

Thanks, Joshua, I have build a number of the images with minimal x11 features to see the difference. All of them appear to be the basic Sato without the apps or borders. And all start with the bit

else explorer is the shell and can be changed. However, there is no argument here - what are >the clear (no brainer) or subjective arguments for one versus the other. There are two reasons or user

<sertacolgunsoylu@...> wrote: its maintained on meta-ti layer. So probably asking meta-ti@... would be good. https://lists.yoctoproject.org/listinfo/meta-ti

patch author importer whoever brings this patch in into oe. Sometimes there might be judgement error on patches thats why I said "for most of them it reflects the status of patch w.r.t.

The developer of the patch submitted to any OE branch (oe-core, meta-oe, ...) should add the appropriate Upstream-Status entry. See:

Jefro: You can get more info about this from Mark's OE page: http://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines The Key thing to note on my numbers is that we have 461 patches that

Ah, documentation :) excellent -- Jeff Osier-Mixon http://jefro.net/blog Yocto Project Community Manager @Intel http://yoctoproject.org

<jeffrey.osier-mixon@...> wrote: it means that all patches have a field 'Upstream-Status' and for most of them it reflects the status of patch w.r.t. upstream of given package

Not quite - we still have most of the patches, it's just we've now declared on each and every one whether it can be/has been upstreamed. Cheers, Paul -- Paul Eggleton Intel Open Source Technology

This sounds fantastic, and I'd love to create a page on the website reflecting this. Just so I am clear, what exactly is this 100% of? Do we have no local patches to upstream projects at all? On Wed,

Nicely done, all! I'm hoping we have can a reputation as a strong supporter of upstream projects, giving back wherever we can.