linux/meta-virtualization.git/classes/container-bundle.bbclass, branch master

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

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

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

container tasks: move network access out of build chain

2026-02-10T21:04:20+00:00

yocto-check-layer reports an error for any task between do_fetch and do_build that has network enabled. Two changes fix this: container-bundle.bbclass: Move do_fetch_containers from a standalone task into a do_fetch postfunc. When remote containers are configured, the anonymous function adds extend_recipe_sysroot as a do_fetch prefunc (so skopeo-native is available) and do_fetch_containers as a postfunc. Network access during do_fetch is permitted by the QA check. container-registry-index: Remove do_container_registry_index from the build dependency chain (drop "before do_build"). Registry push is a deployment action requiring explicit invocation: bitbake container-registry-index -c container_registry_index The default do_build task now prints usage instructions. Signed-off-by: Bruce Ashfield

vcontainer: fix yocto-check-layer mcdepends parse error

2026-02-09T20:03:27+00:00

Fix yocto-check-layer failure: ERROR: Multiconfig dependency mc::vruntime-x86-64:vpdmn-initramfs-create:do_deploy depends on nonexistent multiconfig configuration named configuration vruntime-x86-64 Several recipes and classes declared static mcdepends referencing vruntime-aarch64 and vruntime-x86-64 multiconfigs. When parsed without BBMULTICONFIG set (e.g. yocto-check-layer), BitBake validates these and fails because the referenced multiconfigs don't exist. Move mcdepends into anonymous python functions and only set them when the target multiconfig exists in BBMULTICONFIG, following the pattern established in meta/classes-recipe/kernel-fit-image.bbclass. Signed-off-by: Bruce Ashfield

container-cross-install: add CONTAINER_SERVICE_FILE support

2026-02-09T03:34:12+00:00

Add support for custom systemd service files (Docker) or Quadlet container files (Podman) instead of auto-generated ones for container autostart. For containers requiring specific startup configuration (ports, volumes, capabilities, dependencies), users can now provide custom service files using the CONTAINER_SERVICE_FILE varflag: CONTAINER_SERVICE_FILE[container-name] = "${UNPACKDIR}/myservice.service" For BUNDLED_CONTAINERS in image recipes: SRC_URI += "file://myapp.service" BUNDLED_CONTAINERS = "myapp-container:docker:autostart" CONTAINER_SERVICE_FILE[myapp-container] = "${UNPACKDIR}/myapp.service" For container-bundle packages: SRC_URI = "file://myapp.service" CONTAINER_BUNDLES = "myapp-container:autostart" CONTAINER_SERVICE_FILE[myapp-container] = "${UNPACKDIR}/myapp.service" Implementation: - container-cross-install.bbclass: Add get_container_service_file_map() to build varflag map, install_custom_service() for BUNDLED_CONTAINERS, and install_custom_service_from_bundle() for bundle packages - container-bundle.bbclass: Install custom service files to ${datadir}/container-bundles/${runtime}/services/ Signed-off-by: Bruce Ashfield

container-bundle: add CONTAINER_BUNDLE_DEPLOY for base layer use

2026-02-09T03:32:52+00:00

Add CONTAINER_BUNDLE_DEPLOY variable to enable dual-use of container-bundle: 1. Target packages (existing): Creates installable packages for target container storage (Docker/Podman) 2. Base layer source (new): When CONTAINER_BUNDLE_DEPLOY = "1", also deploys the fetched OCI image to DEPLOY_DIR_IMAGE for use as a base layer via OCI_BASE_IMAGE This enables fetching external images (docker.io, quay.io) and using them as base layers for Yocto-built container images. Example usage: # recipes-containers/oci-base-images/alpine-oci-base_3.19.bb inherit container-bundle CONTAINER_BUNDLES = "docker.io/library/alpine:3.19" CONTAINER_DIGESTS[docker.io_library_alpine_3.19] = "sha256:..." CONTAINER_BUNDLE_DEPLOY = "1" # Then in your app container recipe: OCI_BASE_IMAGE = "alpine-oci-base" IMAGE_INSTALL = "myapp" Signed-off-by: Bruce Ashfield

docs: fix dead references to vdkr-native and obsolete test classes

2026-02-09T03:32:52+00:00

Update references to reflect the current architecture: - Change vdkr-native/vpdmn-native to vcontainer-native in comments - Remove TestContainerCrossTools and TestContainerCrossInitramfs from README - Fix build command: vdkr-native → vcontainer-tarball Signed-off-by: Bruce Ashfield

classes: factor out shared functions to container-common.bbclass

2026-02-09T03:32:52+00:00

Create container-common.bbclass with shared Python functions used by both container-bundle.bbclass and container-cross-install.bbclass: - get_vruntime_multiconfig(d): Maps TARGET_ARCH to multiconfig name - get_vruntime_machine(d): Maps TARGET_ARCH to MACHINE for deploy path - get_blob_arch(d): Maps TARGET_ARCH to blob directory name This removes ~55 lines of duplicated code and ensures consistency between the two bbclass files. Signed-off-by: Bruce Ashfield

container-bundle: add package-based container bundling support

2026-02-09T03:32:52+00:00

This class creates installable packages that bundle pre-processed container images. When installed via IMAGE_INSTALL, containers are automatically merged into the target image's container storage. Component relationships for bundling a local container: 1. Application Recipe (builds the software) recipes-demo/myapp/myapp_1.0.bb - Compiles application binaries - Creates installable package (myapp) 2. Container Image Recipe (creates OCI image containing the app) recipes-demo/images/myapp-container.bb - inherit image image-oci - IMAGE_INSTALL = "myapp" - Produces: ${DEPLOY_DIR_IMAGE}/myapp-container-latest-oci/ 3. Bundle Recipe (packages container images for deployment) recipes-demo/bundles/my-bundle_1.0.bb - inherit container-bundle - CONTAINER_BUNDLES = "myapp-container:autostart" - Creates installable package with OCI data Flow: application recipe -> container image recipe -> bundle recipe -> IMAGE_INSTALL in host image -> container deployed on target Usage: inherit container-bundle CONTAINER_BUNDLES = "myapp-container:autostart redis-container" CONTAINER_BUNDLES format: source[:autostart-policy] - source: Container IMAGE recipe name or remote registry URL - autostart-policy: Optional (autostart, always, unless-stopped, on-failure) Features: - Auto-generates dependencies on container image recipes (do_image_complete) - Supports remote containers via skopeo (requires CONTAINER_DIGESTS) - Runtime auto-detected from CONTAINER_PROFILE (docker/podman) - Produces OCI directories and metadata for container-cross-install Signed-off-by: Bruce Ashfield