From: Mauro Queirós <maurofrqueiros@...> Git-LFS objects were being fetched even when lfs=0 was not set. This patch disables LFS smudging when lfs=0. That way, only the LFS pointers are download

Sorry, third patch needs to be backported from master for git lfs to work nicely on dunfell. Will send a v2. -Mikko

From: Matt Hoosier <matt.hoosier@...> Insert an explicit pass to fetch all blobs needed by Git LFS, during the fetch() function. This avoids the default behavior of Git LFS to wait until 'git c

From: Mauro Queirós <maurofrqueiros@...> Function "contains_lfs" was only looking at the master branch when searching for LFS content. LFS may be configured in specific branches only, so we need

Locally, as developer you always have a local branch where you can cherry-pick changes. With git submodules and repo tooling, you should use a local or project specific clone of poky. Or move all upda

Hi, When backporting changes, I find it better to cherry-pick the changes for e.g. python3 update from master to the old branch that I have to use. In my case I can not update anything which breaks AB

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