Kas

TL;DR: Building natively on a Yocto workspace on Arch Linux hits two separate failures. The host’s rolling toolchain is not pinned, so bitbake’s own host-side tooling drifts under you between builds. And uninative, the prebuilt glibc that keeps -native binaries loadable across hosts, disables itself silently once the glibc it sees outruns the ceiling baked into its own payload: one bb.warn line, and native sstate quietly stops being shareable. buildtools-extended, the Yocto Project’s own documented recommendation for unsupported hosts, fixes the first problem. Nothing off the shelf fixed the second, so I built yocto-uninative-tarball, an AUR (Arch User Repository) package that rebuilds the payload from the exact glibc commit Arch itself ships, so host and payload glibc are the same build by construction instead of racing each other. ...

TL;DR: bakar is a Python CLI that wraps kas and kas-container for Yocto Board Support Package (BSP) builds. It defaults to container builds via kas-container when KAS_CONTAINER_IMAGE is set, and falls back to plain kas on the host when it is not. Pass --host to any subcommand to force host mode. On top of kas, bakar adds pre-flight environment checks before the build starts, applies a curated tuning overlay (ccache, fetch mirrors, reproducibility knobs) without modifying your YAML on disk, writes structured per-run logs, and provides bakar triage to locate the failing recipe after a crash. For vendor BSPs that ship as repo manifests (NXP i.MX) or oe-layertool configs (TI Sitara), it translates those to kas YAMLs automatically. For projects initialized with bitbake-setup (the official Yocto 5.3+ workspace tool), bakar detects the workspace automatically, translates the JSON layer config to a kas YAML, and drives the same pipeline. Install: uv tool install bakar. ...