linux/meta-virtualization.git/classes, branch master-next

container-bundle: add CONTAINER_FLAGS_ACCEPTED to acknowledge container licenses

2026-06-13T03:51:50+00:00

container-bundle.bbclass emits a bb.warn on every parse of a recipe that fetches a remote container. The warning's intent is sound: the integrator is shipping content they did not build from source, and the license/redistribution implications deserve a deliberate review. After that review has happened, though, the warning has nowhere to go. It keeps firing on every build, and there is no way for an image recipe that intentionally bundles e.g. an alpine or busybox base container to have a clean parse log. Users who want to add deliberate third-party base images (the app-container-alpine demo Tim is working on is the immediate motivation) end up either editing the bbclass to suppress the warning entirely or living with the noise — both bad. Add CONTAINER_FLAGS_ACCEPTED, mirroring oe-core's LICENSE_FLAGS / LICENSE_FLAGS_ACCEPTED pattern. The recipe never declares its own container licenses as accepted; instead the integrator opts in via local.conf or distro config after reviewing each container: CONTAINER_FLAGS_ACCEPTED += "docker.io/library/alpine" URLs in CONTAINER_FLAGS_ACCEPTED are matched against both the full URL (with :tag or @digest) and the bare URL with tag/digest stripped, so accepting "docker.io/library/alpine" covers every tag of that container. A "*" wildcard accepts every third-party container — for distros that have a standing review process. When a URL matches, the bb.warn is demoted to a bb.note instead of being silenced entirely. The note remains in the build log and the recipe's task log, so SBOM tools, audit pipelines, and distro release reviews can still see that an acknowledged third-party container was pulled. The point of the change is to remove the visible "WARNING" line from clean builds, not to hide that the fetch happened. The unacknowledged-URL warning is also reworded to print a copy-pasteable CONTAINER_FLAGS_ACCEPTED line for the specific URL, so the user reading the warning doesn't have to grep the docs to find the variable name. Documentation lives in both the bbclass header block and docs/container-bundling.md (under a new "Acknowledging Third-Party Container Licenses" section), with the exact warning text and the exact note text quoted so they're greppable from either entry point. Signed-off-by: Bruce Ashfield

image-oci: auto-derive IMAGE_INSTALL from OCI_LAYERS packages layers

2026-06-12T17:13:07+00:00

A multi-layer image recipe (OCI_LAYER_MODE = "multi") needs every package it puts into a packages: layer to also be reachable by do_rootfs's recrdeptask so the package is actually built before layer assembly tries to pull it from DEPLOY_DIR_*PK. The convention to date has been: list each package twice — once in OCI_LAYERS, once in IMAGE_INSTALL — and keep both in sync by hand. Any drift between the two sources of truth silently breaks the build at layer-assembly time. The error surfaces as "missing package in DEPLOY_DIR" rather than as a parse-time complaint about the recipe, so it's also annoying to debug. The parse-time anonymous python in this class already walks OCI_LAYERS, validates each entry, and collects every package name into a set. It then stops at bb.debug logging that set. Append the set to IMAGE_INSTALL instead. do_rootfs picks the entries up via the existing recrdeptask, the recipe gets one source of truth, and drift is no longer possible. The append is additive — a recipe is still free to add IMAGE_INSTALL entries that aren't named in any final layer (e.g. packages used only during a rootfs postprocess fixup). The auto-derivation only fires when OCI_LAYER_MODE = "multi" and at least one packages: layer is present, so single-layer recipes and pure directories/files/host multi-layer recipes are unaffected. Signed-off-by: Bruce Ashfield

container-bundle: fix do_unpack for custom service files

2026-06-12T02:58:55+00:00

CONTAINER_SERVICE_FILE varflags reference files from SRC_URI via ${UNPACKDIR}, but do_unpack[noexec] = "1" prevented SRC_URI file:// entries from being unpacked. The custom service files never reached UNPACKDIR, the install loop silently skipped them, and bundles ended up with empty services/ directories. The noexec was added when the class had no source files of its own, but CONTAINER_SERVICE_FILE introduced a legitimate need for SRC_URI unpacking. Also fix S to use UNPACKDIR instead of WORKDIR, which OE-core's do_unpack QA check now requires. Signed-off-by: Bruce Ashfield

oe-go-mod-fetcher + go-mod-discovery: add --build-target license-scan filter

2026-05-29T13:37:32+00:00

The license-scan filter previously had two tiers — walk GOMODCACHE for unpacked module dirs, falling back to `go list -m all` (the MVS set). For recipes whose do_compile builds multiple binaries spanning a wider import graph than the discovery step's single GO_MOD_DISCOVERY_BUILD_TARGET (incus: 8 cmd/* binaries vs the single ./cmd/incus-migrate used by discovery), the GOMODCACHE walk under-includes and the MVS fallback over-includes — producing go-mod-licenses.inc entries that point to modules bitbake never unpacks, which then trip do_populate_lic's "invalid file" QA gate. Add a tier-0 filter: when a recipe declares its full set of build targets via the new GO_MOD_DISCOVERY_LICENSE_TARGETS variable, the generator runs `go list -deps` on those targets and uses the union of their imported modules as the filter set. This is the most accurate signal for "what bitbake will unpack at build time" — equivalent to what go build would resolve before bitbake's do_unpack runs. Mechanism: - oe-go-mod-fetcher.py: new --build-target flag (repeatable) and _get_imported_modules() helper. Repeats over `action='append'` so the per-target paths survive shell word-splitting in the bbclass invocation without quoting tricks. - go-mod-discovery.bbclass: when GO_MOD_DISCOVERY_LICENSE_TARGETS is set, loop over its values and emit --build-target for each. The list is space-separated in the recipe; the bbclass loop keeps each target as its own shell word. Tier order is now: 1. --build-target (this commit): `go list -deps` on declared targets 2. GOMODCACHE walk (existing): modules unpacked by the discovery build 3. `go list -m all` MVS-selected set (existing): full module graph 4. No filter (existing): all go.sum entries Recipes without GO_MOD_DISCOVERY_LICENSE_TARGETS see no behavior change — verified against cosign via a real bitbake -c discover_and_generate run (zero diff vs HEAD on its sidecars). Incus's go-mod-licenses.inc drops from 418 (MVS fallback) to 176 lines once the new tier is wired up, matching the build's actual ~170 unpacked modules. Signed-off-by: Bruce Ashfield

image-oci: don't preserve ownership in directories/files/host layer copies

2026-05-11T20:11:22+00:00

The multi-layer 'directories', 'files', and 'host' branches in IMAGE_CMD:oci copy delta content into the OCI bundle rootfs with 'cp -a'. 'cp -a' implies '--preserve=all', which calls lchown() on the destination to copy ownership from the source. When a directories/files layer copies a symbolic link whose target does not exist at build time (for example, the '/dev/stdout' and '/dev/stderr' log forwarding symlinks used by the official nginx Docker image), lchown() can return EINVAL under pseudo and 'cp' aborts with: cp: failed to preserve ownership for .../var/log/nginx/access.log: Invalid argument failing the whole do_image_oci task. The single-layer rootfs copy already handles this correctly: cp -r -a --no-preserve=ownership ${IMAGE_ROOTFS}/* $image_bundle_name/rootfs and the multi-layer 'packages' branch uses 'rsync -a --no-owner --no-group' for the same reason. Bring the three remaining cp -a sites in line by adding '--no-preserve=ownership'. Ownership inside an OCI image is set by umoci based on the image config and source ownership has no meaning for symlinks to runtime device nodes anyway, so dropping preservation is the correct behaviour. Reproduce: declare a directories: layer that copies a path containing a symlink to '/dev/stdout' or '/dev/stderr' (e.g. a postprocess that creates /var/log/nginx/{access,error}.log -> /dev/{stdout,stderr} to mirror the upstream nginx Docker image). Signed-off-by: Tim Orling Signed-off-by: Bruce Ashfield

oci-multiarch: fix MC defaults, deploy dependency, and OCI layout

2026-05-10T13:58:10+00:00

Three issues prevented oci-multiarch.bbclass from producing usable multi-architecture container images: 1. MC defaults pointed to vruntime-* multiconfigs, whose BBMASK blocks OCI tooling. Changed to container-* multiconfigs which use the new vcontainer distro without BBMASK. 2. mcdepends targeted do_image_oci, but the OCI output is only deployed to deploy/images/ by the later do_image_complete task. The bbclass then failed to find the OCI directory at the expected deploy path. The original implementation assumed do_image_oci was the final step, but OE-core's image pipeline has a separate deploy phase. 3. The OCI Image Index was written directly into index.json with multiple manifest entries. This is valid per the OCI spec but skopeo requires index.json to reference a single entry when there are multiple images. The fix writes the multi-platform image index as a blob in blobs/sha256/ and has index.json reference it with a single entry of mediaType application/vnd.oci.image.index.v1+json. This nested layout is what tools like buildah and crane produce for multi-arch images, and is required for 'skopeo copy --all' to work. Also adds container-base-multiarch.bb recipe that wires up container-base for aarch64 + x86_64 builds via the oci-multiarch class. Signed-off-by: Bruce Ashfield

oe-go-mod-fetcher: add license scanning for Go module dependencies

2026-04-28T18:49:19+00:00

Add --scan-licenses to oe-go-mod-fetcher.py which scans Go module zips for license files and generates go-mod-licenses.inc with LICENSE and LIC_FILES_CHKSUM entries matching OE-core's go-mod-update-modules format. License detection uses OE-core's glob patterns and MD5 + crunched MD5 matching against known SPDX licenses. The hash database resolves from: 1. --common-license-dir (explicit path) 2. Auto-detected poky tree common-licenses 3. Bundled scripts/data/license-hashes.csv (offline fallback) New files: - scripts/generate-license-hashes.py: regenerate bundled CSV - scripts/data/license-hashes.csv: pre-computed hash DB (704 entries) bbclass changes: - go-mod-discovery: pass --scan-licenses during do_generate_modules - GO_MOD_DISCOVERY_SKIP_LICENSES variable to bypass scanning - do_update_license_hashes task to refresh bundled CSV Co-Authored-By: Claude Opus 4.6 (1M context)

go-mod-vcs.bbclass: handle pure hybrid mode gracefully

2026-03-26T17:55:14+00:00

When a recipe uses only gomod:// fetches with no VCS (git://) modules, GO_MODULE_CACHE_DATA is an empty list. Previously do_create_module_cache would run with nothing to process and do_sync_go_files would fatal with "No modules found in cache". Detect the empty module list and return early with an informational message in both tasks, allowing pure hybrid recipes (like yq) to build without workarounds. Signed-off-by: Bruce Ashfield

go-mod-discovery/oe-go-mod-fetcher: add GO_MOD_VCS_EXCLUDE for deleted repos

2026-03-19T15:56:06+00:00

Some upstream Go module repositories get deleted from GitHub (e.g., github.com/vtolstov/go-ioctl). While the Go module proxy still serves cached archives, VCS mode cannot git clone a deleted repo. This causes both do_fetch failures and generator verification failures. Add GO_MOD_VCS_EXCLUDE recipe variable (space-separated module path prefixes) and corresponding --exclude-module CLI flag. Excluded modules are filtered out before verification and SRC_URI generation. Recipes must provide a gomod:// SRC_URI entry for excluded modules as fallback. Usage in recipe: SRC_URI += "gomod://example.com/deleted-repo;version=v1.0.0;sha256sum=..." GO_MOD_VCS_EXCLUDE = "example.com/deleted-repo" Signed-off-by: Bruce Ashfield

container-bundle: add explicit do_fetch dependency on skopeo-native

2026-03-12T19:59:59+00:00

do_fetch_containers runs as a postfunc of do_fetch and needs skopeo from the native sysroot. However, DEPENDS only gates do_prepare_recipe_sysroot which runs after do_fetch, so with a clean tmp/ directory skopeo-native may not be built when do_fetch runs. Add an explicit do_fetch[depends] on skopeo-native:do_populate_sysroot when remote containers are configured so the ordering is correct. Signed-off-by: Bruce Ashfield