Whether your BSP layer has caught up with Yocto

The compatibility string is machine-readable. Every layer declares the Yocto releases it supports through LAYERSERIES_COMPAT in conf/layer.conf. The value quoted here is taken from the repository.

Declaring a release is not the same as shipping one. Several vendor layers follow their own BSP calendar rather than the Yocto cadence, so a declared release may have no branch behind it. Pin to a branch that exists.

A quiet branch means little on its own. Some layers leave master stale while work continues on a release branch; equally, a release branch is supposed to fall silent once its release ships. The activity column therefore measures the newest commit across every branch we recorded, and names the branch the date came from — so a layer keeping normal cadence cannot be marked stale because you happened to look at the branch you build from.

BSP layers and software layers are different obligations. A BSP layer brings up the silicon — machine configuration, the kernel recipe, bootloader and firmware. There is one per SoC family and you do not get to opt out of having it; those are the table above. A software layer adds function that has nothing to do with which chip you chose — updates and rollback, containers, hardening, a UI toolkit, a second toolchain. You choose each one, and each one is a separate upgrade obligation. Those are the table below.

Your board layer is not usually what blocks the upgrade. A product pulls in eight to fifteen layers, and the move to a new LTS is gated by whichever one is furthest behind. The table above says the BSP layers have largely caught up; this one covers the software half.

What gets listed, so a row is a finding and not an opinion: a layer appears here when a product must add it to do something the BSP cannot — update and rollback, containers, hardening, firmware, toolchain — or when practically every build pulls it in. The functions are fixed; the layers are instances of them. Layers are added when they meet that test, not because they are popular.

This column measures a different thing from the one above, deliberately. The BSP table dates the newest commit across every branch it recorded, which is usually master. This one dates the release branch you would actually build from — normally wrynose. A layer can be busy on master and silent on the release branch; meta-rauc below is the clearest case. Each row names the branch its date came from, because not every layer branches on the Yocto release at all.

Every layer here declares the current LTS. That is the finding, not an omission: as of the date above, nothing in this set blocks a move to Wrynose on compatibility grounds. What varies is how actively each branch is being fed.

Not everything you depend on is a layer. ffmpeg is the common example: there is no meta-ffmpeg to track, because the recipe ships in oe-core itself (meta/recipes-multimedia/ffmpeg, version 8.0.1 on the wrynose branch), so every build already has it. gstreamer-1.0 is also in oe-core, while its plugins and the codec libraries around it — x265, dav1d, aom, libde265 — sit in meta-multimedia inside meta-openembedded. Checked the meta-multimedia recipe list on wrynose: 63 recipe directories, no ffmpeg among them.

Two more that catch people out. There is no meta-rust: Rust is in oe-core at meta/recipes-devtools/rust, cargo and libstd included. And there is no meta-rt: PREEMPT_RT is a core kernel recipe variant, meta/recipes-kernel/linux/linux-yocto-rt_6.18.bb on the wrynose branch. If you are hunting for a layer to add for either, there is not one to find.