Specifically for bug 14273 (the rcu stall is seen on the logs): ubuntu1804-ty-1 6 23.1% ubuntu1804-ty-2 5 19.2% ubuntu1804-ty-3 12 38.5% fedora31-ty-1 2 7.7% debian8-ty-1

It it can help to understand, I rechecked the full content of source packages and glib-2.0 / networkamanager are not ok like I said earlire. There are not empty but they seem to contain only build

Hello, I currently used yocto warrior and I encounter an issue during packaging of recipes. I would like to embed some source package (to be able to run coverage on target) , this work without issues

Yocto Technical Team Minutes, Engineering Sync, for June 15 2021 archive: https://docs.google.com/document/d/1ly8nyhO14kDNnFcW2QskANXW3ZT7QwKC5wWVDg9dDH4/edit == disclaimer == Best efforts are made

oe-core has mpg123 already, so just use that recipe. Ross

Greetings ! If anyone achieved the task of integrating the "mpg321" in yocto , kindly requesting to share the procedure/steps to be followed . Thanks

Yes it should be. We've looked at a number of logs and I will send a V2 with wild-carding for the cross-compiler paths. After the V2, I plan on submitting patches for the following in roughly the

Hello All, I'm trying to get a Perl module (specifically Google-ProtocolBuffers-Dynamic @ https://metacpan.org/pod/Google::ProtocolBuffers::Dynamic) cross compiled for an imx8 target; and having a

Join Zoom Meeting - 9 AM ET https://windriver.zoom.us/j/3696693975 Attendees: Alex, Richard, Saul, Randy, Tony, Trevor, Sakib Summary: Things are improving somewhat on the autobuilder,

Leon Woestenberg <leon@...> schrieb am Do., 17. Juni 2021, 14:17: The esdk is meant for exactly that use case.

Hello all, In some other build systems the generated SDK can be used to also generate an image. Thus the SDK allows development against the target sysroot using the prebuilt host and target tools, as

When the log name contains a space, the generated URL is not correct. Thi= s later also breaks parsing in swatbot. This was triggered by "property changes" and the correct URL is indeed

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

From: Bruce Ashfield <bruce.ashfield@...> Updating linux-yocto/5.10 to the latest korg -stable release, and to match the qemu BSPs in oe-core Signed-off-by: Bruce Ashfield

The script goes over the raw logfile (for example, foo.txt) which consists of multiple top outputs and summarizes each top output and writes them to foo_summary.txt Some improvements that can be

On 2021-06-16 1:24 pm, Alexander Kanavin wrote: On Wed, 16 Jun 2021 at 16:58, simon <simon@...> wrote:- There's a warning about not finding the IRIS driver: MESA_LOADER: failed to open iris:

[...] One quick question - the above assumes an x86 target machine using those two tunes.  Should that be wildcarded? Cheers, Richard

Hello Simon, I honestly don't know how Intel folks have overlooked this, but mesa in yocto not only does not enable iris, the mesa recipe does not even have an option to enable it. However, it should

Looks good Sakib, Can you show people what the typical output looks like? Is the raw top output still published? ../Randy -- # Randy MacLeod # Wind River Linux

Hi all, I'm having trouble figuring out how to fix my issues with the new intel NUC gen 11 (NUC11TNBi5). At the moment I'm testing with the following meta-layer poky (hardknott) meta-openembedded