Skip to content

Everything Yocman does, from a failed task to a flashed board

36 commands, one CLI. Each runs locally against your build directory or project. The AI layer is optional for analyses and never touches your files without your confirmation.

Diagnose and fix

  • fix
  • explain
  • ask
  • context
  • login
  • --dry-run
  • --fresh

When bitbake fails, yocman fix reads the failing task log, works out the cause with read-only tools and proposes a unified diff against your own layer. You confirm, it applies the patch and re-runs the task. Every diagnosis is kept in your private history, so the same failure is answered from it next time, without new AI usage.

  • explain gives the diagnosis without changing anything
  • A change found by ask or explain is kept: yocman fix applies it later
  • A failure already solved for you is answered at once; --fresh asks the AI again
  • Patches go to your own layers, never to poky or upstream ones
  • --dry-run prints the masked payload and sends nothing
yocman fix
$ yocman fix
… pre-analysis: missing_dependency in myapp:do_compile
… reading meta-custom/recipes-apps/myapp/myapp_1.0.bb
Diagnosis zlib headers are missing from the recipe sysroot
fatal error: zlib.h: No such file or directory
--- a/recipes-apps/myapp/myapp_1.0.bb
+++ b/recipes-apps/myapp/myapp_1.0.bb
@@ -10,6 +10,7 @@
inherit cmake systemd
+DEPENDS += "zlib"
Apply this patch? [y/N] y
✓ patch applied in meta-custom
✓ do_compile succeeded
Sample output on the bundled demo build

Commands

fix
Fix a failed task: patch for your layer, applied after confirmation, task re-run; with no failure, apply the change ask or explain proposed
explain
Explain the last build failure without changing anything; a fix it finds is kept for yocman fix
ask
Ask a question about your project; a change it finds in a recipe is kept for yocman fix
context
Show the release, machine, distro and layers Yocman detected, offline
login
Store your API key and check it against the service

Analyse the build

  • doctor
  • rules
  • conf
  • layers check
  • deps
  • why
  • provides
  • unused
  • orphans
  • duplicates
  • size
  • buildtime
  • sstate
  • boot
  • --no-ai

Deterministic analyses of your build directory, from the files bitbake already writes: configuration and layers, dependency chains, image contents and size, build time, shared-state reuse and boot time. Facts come from the files; an optional AI summary interprets them.

  • why shows the chains that pull a package into the image
  • size diff compares two builds or buildhistory revisions package by package
  • sstate finds the recipes rebuilt at every build
  • doctor tells you which data source is missing and how to enable it
yocman why busybox · yocman buildtime
$ yocman why busybox
core-image-minimal → packagegroup-core-boot (IMAGE_INSTALL) → busybox
$ yocman buildtime
Wall time 58m20s
Effective parallelism 1.0 (BB_NUMBER_THREADS 64)
linux-yocto do_compile 25m00s
linux-yocto do_fetch 15m00s
myapp do_compile 5m00s
Sample output on the bundled demo build

Commands

doctor
List the data sources in the build directory and how to enable the missing ones
rules
List every analysis rule with its id, category and severity
conf
Check local.conf, bblayers.conf, auto.conf and site.conf
layers check
Check the layers of bblayers.conf: missing, listed twice, incompatible with the release, orphan .bbappend
deps
Dependency tree of a package, runtime or build time, and who depends on it
why
Why a package is in the image: the chains from IMAGE_INSTALL
provides
Which package installs a given file in the image
unused
Packages that are candidates for removal, to review
orphans
Recipes that are built but never reach the image
duplicates
Duplicate functionality in the image, such as two SSH servers
size
Image size by package, file and category; size diff compares two builds
buildtime
Longest tasks and recipes from buildstats, and the effective parallelism
sstate
Shared-state reuse, and the recipes rebuilt at every build
boot
Boot time of the target from systemd-analyze blame and critical-chain

Security and compliance

  • audit
  • cve
  • secrets
  • users
  • perms
  • services
  • kernel-audit
  • licenses
  • sbom
  • cra report

Audit the image you actually ship: unpatched CVEs, embedded secrets, accounts and permissions, enabled services, kernel hardening, licenses and the SPDX SBOM, with a score per category.

  • Secrets are reported by location and type, never displayed
  • cve diff shows what a release update fixed or introduced
  • kernel-audit checks the kernel .config against a hardening list
  • Markdown and JSON reports for reviews and audits
yocman audit
$ yocman audit --fail-on high
Overall score 18/100 over 10 categories
conf 17 findings, worst high 0
secrets 7 findings, worst critical 0
licenses 4 findings, worst medium 76
sbom 3 findings, worst medium 86
critical CVE-001 CVE-2099-0101 (CVSS 9.8) in openssl 3.2.1
→ upgrade the recipe or backport the fix with 'CVE: <id>'
exit 1: findings at or above high
Sample output on the bundled demo build

Commands

audit
Full security and compliance audit with a score per category
cve
Unpatched CVEs from the cve-check report by CVSS; cve diff compares two builds
secrets
Keys, tokens and passwords embedded in the rootfs and layers, never displayed
users
Accounts: empty passwords, extra UID 0, weak hashes, login shells
perms
File permissions: setuid, world-writable, sensitive files, unknown owners
services
Services enabled at boot, insecure network services, SSH and debug settings
kernel-audit
Kernel .config against a hardening checklist
licenses
GPLv3, proprietary and unclear licenses, and source obligations
sbom
SPDX SBOM presence and consistency with the image
cra report
Cyber Resilience Act readiness: build-side evidence from cve, secrets, sbom, licenses and kernel, mapped to CRA requirement areas

Start a project

  • init
  • add
  • remove
  • build
  • shell
  • env
  • flash
  • init --describe
  • init --board-search

Create a kas project for one of 21 verified boards (Raspberry Pi, BeagleBone, Radxa, Orange Pi, i.MX 8M Plus EVK, QEMU…), or describe it in your own words and let the AI fill in the choices. Add features such as SSH, Wi-Fi, Qt 6 or Docker, build on the host or in the kas container with live progress, and flash an SD card with a device check you cannot skip.

  • Board catalogue checked against the real layer repositories
  • init --board-search looks up other boards in the OpenEmbedded layer index
  • build shows the phase, the running tasks and the time left
  • env switches between host and container after checking the prerequisites
  • flash only lists removable disks and asks you to type the device name
yocman init
$ yocman init --release scarthgap --board rpi4-64 \
--feature ssh-openssh --feature wifi --env container
✓ Project generated in ~/yocto/rpi4-64-scarthgap
… kas checkout, kas lock (layers pinned)
$ yocman build
Compiling 2140/3412 tasks (62%) ~38 min left
linux-raspberrypi:do_compile qtbase:do_compile gcc:do_install
$ yocman flash --device /dev/sdb
sdb SanDisk Ultra 29.7 GiB usb removable
Type the device name (sdb) to confirm: sdb
Sample output on the bundled demo build

Commands

init
Create a kas project for a verified board and release; --describe lets the AI fill in the choices
add
Add a feature (SSH, Wi-Fi, Qt 6, Docker…) with a diff to confirm and a commit
remove
Remove a feature, refused while another feature still needs it
build
Build the image with live progress: phase, running tasks, time left
shell
Open a shell with the bitbake environment, on the host or in the container
env
Check and switch the build environment between host and container, update the kas image
flash
Write the image to an SD card or USB drive, removable disks only, with a typed confirmation

Integrations

  • --format json
  • --fail-on
  • --no-ai
  • VS Code(coming soon)

Yocman is a plain CLI: it fits in any CI runner. Every analysis has machine-readable output and exit codes you can gate a pipeline on.

  • --fail-on high exits with 1 when a finding reaches that level
  • --no-ai keeps a pipeline fully offline
  • A VS Code extension is coming soon
.gitlab-ci.yml
audit:
script:
- yocman audit --no-ai --format json -o audit.json --fail-on high
- yocman size diff previous/ build/ --format md -o size.md
artifacts:
paths: [audit.json, size.md]
Sample output on the bundled demo build

The free plan covers fixes, explanations and every local analysis.

Get started free