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

Ah, indeed. svn is supported and for me it's working quite well. It has some issues like download cache locking when multiple recipes include the same URLs. Where possible, I've switched to using http

#yocto #python

Hmm. Rings a bell. I run builds with a local non-upstreamed patch: Author: Mikko Rapeli <mikko.rapeli@...> AuthorDate: Fri Sep 6 14:15:20 2019 +0200 Commit: Mikko Rapeli <mikko.rapeli@...> Commi

#yocto #python

Hi, I can't comment on svn fetcher but I use subversion via http fetcher. This way the local download cache can have the exact same file and builds can continue off line. One major gotcha is that all

#yocto #python

I always search for existing CVEs for the SW component and check what project and product names were used. For flex, Internet search shows for example https://www.suse.com/security/cve/CVE-2019-6293/

Hi, Set CVE_PRODUCT to match real NVD product name with possibly vendor too. There are a few examples in poky master. Cheers, -Mikko

Hi, Maybe host tool versions differ which trigger recompilation of things like gcc and thus everything gets recompiled. You can use bitbake-diffsigs to figure out why rebuild was triggered. I work aro

Yes, this is what I meant. Basically just adjust the SRC_URI and possibly PV through a linux-libc-headers_%.bbappend in product or BSP specific meta layer. Cheers, -Mikko

Hi, This is the problem I see with multiple BSPs. In the end for every one of them the best solution is to fork linux-libc-headers. Adding custom recipes to export headers for every BSP kernel is not

Hi, How to find a Linux kernel uapi header file with custom ioctl() etc definitions which are missing form the default linux-libc-headers? Other recipes and SDK builds need these. Copying the needed h