Hi, For those who aren't afraid to digging deeper, it is possible to limit the impact of BSP layers by e.g. restricting which recipes and bbappends get applied in your product via BBMASK in distro con

Hi, I was wondering on same thing few days ago. nativesdk-clang and clang-cross-canadian-aarch64 if your target arch is aarch64 bring a working clang compiler to the SDK. I was also missing the clang-

bitbake -e my-recipe ? Maybe grep for the variable of interest? When adding layers, only way to be sure is to actually review the layers and their bbappends. I tend to BBMASK everything out which I ha

Hi, You can try with SRC_URI_prepend_machine1. Cheers, -Mikko

Hi, Debian developers changed branch names in their repository. Fixed in latest master and dunfell branches so either update or cherry-pick the changes: https://git.yoctoproject.org/cgit/cgit.cgi/poky

Hi, You need to add exceptions to build a lot GPLv3 components but not let them be part of product images. In distro config: INCOMPATIBLE_LICENSE += "GPLv3 GPLv3+ LGPLv3 LGPLv3+" ... WHITELIST_GPL-3.0

Hi, We do something similar except we rsync a sstate mirror to build nodes from latest release before a build (and topic from gerrit are merged to latest release too to avoid sstate and build tree get

Hi, This is a common problem. It is likely that I know which SoC supplier you are talking about and have had the exact same issues. We have managed to fix or workaround all of them. In most cases by r

Actually suggestion to use buildhistory is the first critical step because without this you can't easily see where the size comes from. buildhistory provides for example the list of installed binary p

Hi, Generic approaches for reducing yocto target image size where buildhistory is an important source of information: * review and minimize distro features, enable only what you need https://www.yocto

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

Alternative for tmpfs with hard size limit is to keep file system caches in memory as long as possible and only start writes to disks when page cache gets too full. This scales but still uses all the

Well, I can't build with under 2 gigs per core or I run out of physical memory and kernel oom-killer kicks in to kill the build. Also can't run with yocto default parallel settings which only take int

Drop all virtualization and go for Linux on bare metal. Then make sure there is enough(tm) physical RAM for each CPU thread. For a "big Ryzen" the 64G of RAM sounds too little. I'd go higher there, bu

Sadly custom bbclasses and BSP layers have this effect on my builds and I can't fully trust local incremental builds. Hence I clean sstate cache often. -Mikko

This is what I've come to expect with yocto 2.0 jethro, 2.5 sumo and 3.0 zeus. That's why I always write: $ bitbake -c clean recipe && bitbake -c cleansstate && bitbake -c compile recipe when debuggin

Hi, Thanks for this explanation! Hmm. I would rather see FOO_append += "bar" being used every time when spaces are expected. It's way too easy to forget the extra space which causes annoying and hard

#sdk #systemd

Yes, quite likely. Tough reason why += doesn't work is a mystery to me :) I hack things until "bitbake -e" shows the right things for the recipes. -Mikko

#sdk #systemd

Looks good to me. Lucky you :) -Mikko

#yocto #python

Hi, openssl is tricky to update and requires backporting fixes for many, many recipes to get builds passing etc. Depending on project size, it may be possible to update only those components which you

#yocto #apt #raspberrypi