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

Hi, Good pointers in this thread already. Here are mine: * Share sstate mirror and download cache from release builds to developer topic builds. NFS, web server or rsync before calling bitbake will wo

#yocto

Hi, (lets keep this on the list too) You can add _class-[target|native|nativesdk] to all variables to override defaults. Verify with "bitbake -e". Hope this helps, -Mikko

#sdk #systemd

Hi, Make the systemd dependency for target only, e.g. DEPENDS_class-target += "systemd" etc. There may be relevant use cases to build some of systemd components or tools to native or nativesdk targets

#sdk #systemd

Well I have zeus and am using read-only rootfs with volatile binds and I did not need anything extra. I would dig into this /var/log thing and patch it away. I use systemd journal so no need for syslo

(trimming lists to yocto only) Hi, I think you may be missing volatile-binds package and service from your image. See poky/meta/recipes-core/volatile-binds/volatile-binds.bb It may be missing /var/log