Hi Emily, I'm not sure how the patch is generated, and (not using devtool myself) I may understood your problem wrongly (showing the relevant part of your diff could help), but you could try to

Yes :) But you observe the key issue, Trevor is correctly focused on the upstream kernel and the vendor layer on an old vendor kernel. The vendor kernels rapidly turn into maintenance nightmares over

I tried compiling octave on an ARM board with 1GB of RAM (because octave is virtually impossible to cross-compile). There was one C++ in there that triggered a huge memory load of about 1GB, thus

Hi Paul - I’m not sure what you mean by “include all the necessary changes to the submodule in the patch”, because anytime I change something in the submodule then the git diff for the main

The issue appears to be that patches are applied using quilt which doesn't understand a patch like this. I don't know of a good solution to this other than making a new commit in the top level

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