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 might

You should really investigate the sstate-cache. Oh, and don't delete everything after every build... If you take a brand new Ubuntu machine to our network, clone the repo and run a build, the XFCE des

Seems a bit excessive to buy hardware just to handle a particular corner case. Most of OE/Yocto code is plain C, not even C++. My rig only has 8GB but doesn't run into memory issues during big GUI bui

Sorry - wrong number. My rig does not have a 1900, but an "AMD Ryzen 7 1700".

Big ryzen is a good choice. My home rig is a Ryzen 1900, with only 8GB RAM. It's way faster at OE yocto builds than the i7 at work that has 32GB RAM installed. My 8GB rig does not use swap space while

theyoctoproject@... <theyoctoproject@...> has invited you to [yocto] Invitation: Yocto Project Technical Team Meeting @ Monthly from 8am to 9am on the third Tuesday (PDT) (yocto@yoctoproje

One solution I can think of is to put the header into it's own recipe/repository and then refer to it like any other library would. Refer to that recipe from the module (or kernel) recipe that needs i

It is not broken, so please don't fix it. OpenPLi has been using kernels way older than 4.1 with the kernel-headers generated by OE/yocto and did not experience any problems with that. There's about 5

I ran into this issue yesterday, and this patch solves the compilation on warrior. However, it's a patch for Qt itself, and not for OE. Is there already a warrior patch in the making, or should I subm

The version of your OE layer is all the version that you'll ever (technically) need. That version (usually a git hash) dictates all other versions. When asked for version numbers of included packages,

Just attempting to revive this dead horse again... Anyone made any proress here? Since cross-compiling turned out to be really really painful, I tried if compiling on the board would be an option. No

OpenEmbedded already created it, it's usually in build/tmp-glibc/deploy/ipk To turn it into a "feed" just share this directory through http. On my development setup, I installed apache and created a s

... With NAND you'll probably have a filesystem (jffs2 or UBI) in place. With that, you could just use a package manager like opkg to update sofware. If the box has a network connection, just running

You can mount something writeable on top of /home/root to accomplish that. (Being able to write onto a read-only partition would kind of defeat the purpose of a read-only filesystem...)

The first thing you should realize is that providing your recipe files will produce a lot more insight into your issue than lengthy e-mails ever will. What I was attempting to convey to you is that yo

Two products sounds like two machines. Just create a machine.conf for each product (even if they use similar hardware), then you don't need overrides elsewhere. OE/Yocto is smart enough to figure out

As for the particular case of /mnt, on most images, /mnt is a symlink to /media, and /media is (on) a filesystem in RAM, so it's already writeable. If the write does not need to persist across reboots

Depends on your definition of "dangerous". Sure, doing it all the time (from ipk, but that shouldn't matter much). If the kernel/dts is just a file on the system, there's just a package that installs

+1 Got lapack to compile, but no such luck with any "blas" package (like openblas). And that's a requirement for octave, which was what I was aiming at. I'll share some recipes, tomorrow or so (today

Sometimes the problem is that parts of the underscored function name are seen as overrides, so you should try using "mysetcapfunction" instead as a name. Also, there's a semicolon missing: ROOTFS_POST