Is there a reason why you don't use a bbappend file with your patch in it in a custom layer? Something like this: package_ver.bbappend -------------------- FILESEXTRAPATHS_prepend :=

Wow, I'm suprised to discover this meta-rockchip :) Rockchip engineers also publish a meta-rockchip on Github (https://github.com/rockchip-linux/meta-rockchip), although nowadays it's mainly Jeffy

Hi all - I have a recipe that I'd like to patch - the source is in a repo which has a submodule, and the patch occurs in the submodule. Is there a way I can apply this patch without getting an error?

Hi Karthik, <karthik.poduval@...> wrote: According to the log, your board is a "tinker-board-s", please try using that for your MACHINE instead of "tinker-board". Thanks and best regards,

is it something like make -l ? that you are looking for here.

Awesome :) The problems listed in the commit message don't amount to much at first glance. Any other issues that got visible only later ? -- Yann Dirson <yann@...> Blade / Shadow --

You can test with: do_compile[number_threads] = "1" Cheers, Richard

This is a bug: http://bugzilla.yoctoproject.org/show_bug.cgi?id=13306 I sometimes wonder whether something basic like "no more than one compile task at a time" would be sufficient in practice to

You mean like: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/wipqueue4&id=d66a327fb6189db5de8bc489859235dcba306237 ? :) Sadly we never fixed all the issues to let that

Where any tests skipped do to lack of physical access to h/w? A quick look at some of the manual tests do imply physical access. - armin

This could be neatly handled by using the GNU-make job-server mechanism. If bitbake itself would provide a jub-server, all make-based recipes would automatically get their jobs properly limited.

It would be really great if some sort of "weight" could be attached to a task. This relates to memory usage. My system has 16 cores but only 8GB RAM. With both parallelization options to "16", I

Hello all, This is the full report for yocto-3.1_M3.rc1: https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib/tree/?h=intel-yocto-testresults ======= Summary ======== No high

Pls can any body guide and suggest the reason of issue Sent from my Huawei phone

I've fixed the bug now, and am implementing something easier for master, so in the future .. it will be easy to remove that sort of warning. Cheers, Bruce -- - Thou shalt not follow the NULL

Hello, I doesn't look like these last few emails made it to the mailing list. I don't mind creating my own BSP but I thought it might be easier to tweak an existing one. Thanks for your help.

This isn't recipe parsing but runqueue setup and taskgraph calculation which happens after parsing but before task execution. More recent bitbake is probably a bit better at it but it is unfortunately

I will double check, but I'm sure I see IO going to disk when plenty of RAM is still available in page cache. I'm not fully aware what bitbake does before starting task execution. With sumo, there is

Doesn't pseudo intercept and stop these sync calls already? Its supposed to so if its not, we should fix that. Recipe parsing should hit 100% CPU, its one of the few places we can do that. Sadly