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

tests: add lxc runtime tests with download-template regression

2026-06-14T03:57:14+00:00

The "lxc was tested" claim during the recent runtime testing sweep was actually transitive — incus runs against LXC libraries under the hood, so incus passing was treated as evidence that LXC itself worked. That inference was wrong: incus uses its own go bindings into liblxc rather than the lxc-* command-line tools, and the breakage Ferry Toth reported on 2026-06-13 sat entirely in templates/lxc-download.in (a script invoked by lxc-create, never reached through incus). The bug would not have been caught by any existing test in the layer. Add tests/test_lxc_runtime.py to close the gap. The suite boots container-image-host with CONTAINER_IMAGE_HOST_EXTRA_INSTALL=lxc, then runs three groups of checks against the live guest: TestLxcInstalled — sanity that lxc-create, lxc-start and lxc --version work at all. Catches packaging and PATH-level regressions. TestLxcDownloadTemplate — explicit regression for the templates-actually-create-DOWNLOAD_TEMP-directory.patch failure mode. Runs `lxc-create --template download` and asserts the broken early-mktemp error string ("mktemp: failed to create file via template '-d…") does not appear in the output. We deliberately do not require the download itself to succeed — the bug fires before any HTTP request, so the test stays meaningful on air-gapped CI where the actual fetch would fail for unrelated reasons. TestLxcContainerLifecycle (@pytest.mark.network) — full end-to-end: create from images.linuxcontainers.org, start, attach, stop, destroy. Marked @network so offline runners deselect it cleanly. The regression test above is the primary guard; this is depth. Also register the lxc marker in pytest.ini so collection doesn't warn. The test conventions (pexpect-driven runqemu boot, marker-delimited command runner, TERM=dumb to suppress shell integration escape sequences) match test_incus_runtime.py and test_xen_runtime.py so the three suites read consistently. Signed-off-by: Bruce Ashfield

lxc: drop templates-actually-create-DOWNLOAD_TEMP-directory.patch

2026-06-14T03:56:57+00:00

The local patch added in 2018 was meant to ensure DOWNLOAD_TEMP pointed at a directory that actually existed by routing mktemp through the -p option. Its else branch is reached precisely when DOWNLOAD_TEMP is unset (the elif catches the set case), but the rewrite DOWNLOAD_TEMP="$(mktemp -p ${DOWNLOAD_TEMP} -d)" substitutes an empty ${DOWNLOAD_TEMP} into the command line, leaving the shell to parse mktemp -p -d as -d being the argument value for -p rather than its own flag. mktemp then fails immediately with mktemp: failed to create file via template '-d/tmp.XXXXXXXXXX': No such file or directory and lxc-create exits before doing any network work. Every invocation of lxc-create --template download is broken. Ferry Toth reported this on the meta-virt list 2026-06-13 (subject "lxc: starting a container errors out"). His diagnosis is correct and the fix he proposed — drop the patch — is the right one. The original upstream line DOWNLOAD_TEMP="${DOWNLOAD_TEMP}$(mktemp -d)" handles both cases correctly: with DOWNLOAD_TEMP set the elif branch runs first, and with it unset the else branch reduces to just DOWNLOAD_TEMP="$(mktemp -d)" which lets mktemp pick the default TMPDIR / /tmp location and create the directory. The original 2018 motivation ("DOWNLOAD_TEMP will not be pointing to an actual directory") does not match how mktemp -d actually behaves on modern systems — the directory IS created, and that's the whole point of mktemp -d. The reported failure mode was likely a build-host environment quirk specific to that 2018 setup rather than a general bug worth carrying a layer-local patch for. Signed-off-by: Bruce Ashfield

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

vcontainer-tarball: unset OECORE_NATIVE_SYSROOT in CI

2026-06-13T03:35:33+00:00

Add 'unset OECORE_NATIVE_SYSROOT' to the end of environment-setup-ci for the same reasons it needed to be in environment-setup-none. This fixes issues seen on AutoBuilder workers which use buildtools-tarball and also usage of oe-run-native (e.g. for skopeo-native or cosign-native). Signed-off-by: Tim Orling Signed-off-by: Bruce Ashfield

tests: add requirements.txt

2026-06-12T18:48:59+00:00

Add requirements.txt to allow versions to be pinned. Signed-off-by: Tim Orling Signed-off-by: Bruce Ashfield

libvirt: re-add ptest support for meson build system

2026-06-12T18:44:00+00:00

libvirt has switched its build system from Makefile to meson, so the original run-ptest which relied on "make -C tests -k check-TESTS" no longer works. Re-add ptest support based on the meson build system: - Rewrite run-ptest to directly execute the compiled test binaries instead of invoking make. - Patch meson.build at configure time to replace absolute build/source paths with the ptest install paths, removing the need for separate path-stripping patches. - Install test binaries and their required data files into the ptest directory. Test results on genericx86-64: All 120 tests passed (0 failures, 0 skips). root@genericx86-64:/usr/lib/libvirt/ptest# ./run-ptest PASS: chxml2xmltest PASS: nssguestlinktest PASS: virbuftest PASS: viracpitest PASS: esxutilstest PASS: ssh PASS: storagepoolxml2xmltest PASS: commandtest ... ... PASS: nwfilterebiptablestest PASS: cputest === Test Summary === PASS: 120 FAIL: 0 SKIP: 0 TOTAL: 120 Signed-off-by: Haitao Liu Signed-off-by: Bruce Ashfield

openvswitch: re-enable ptest

2026-06-12T18:34:56+00:00

Ptest support was disabled in commit 816d4c6e0e7c due to breakage in source handling that prevented proper installation of test files. Fix the ptest installation by: - Copying test binaries from the build directory, preserving subdirectory structure (e.g., oss-fuzz/) for optional test components - Installing *.at test definitions and *.py test scripts from the source tree - Fixing PYTHONPATH in atlocal to use runtime paths instead of build paths - Symlinking schema files already provided by the main package to avoid file duplication Re-enable ptest now that installation works correctly. Test results on genericx86-64: PASS: checkpatch - catastrophic backtracking PASS: checkpatch - Unicode code PASS: appctl-bashcomp - complex completion check 4 PASS: appctl-bashcomp - complex completion check 2 PASS: checkpatch - check misuse APIs PASS: checkpatch - whitespace around cast PASS: checkpatch - comments PASS: checkpatch - check egrep / fgrep PASS: checkpatch - file contents checks - bare return PASS: checkpatch - subject PASS: appctl-bashcomp - negative test ... ... ... PASS: drop-stats - bridge sampling PASS: drop-stats - sampling action PASS: ovsdb-idl - Check Python IDL reconnects to leader - Python3 (leader only) PASS: monitor-cond-change with many sessions pending 2658 tests were successful. 89 tests were skipped. Signed-off-by: Haitao Liu Signed-off-by: Bruce Ashfield

app-container-multilayer: drop redundant IMAGE_INSTALL

2026-06-12T17:54:14+00:00

The canonical multi-layer demo recipe listed every package in two places — once in OCI_LAYERS and again in IMAGE_INSTALL — and carried a four-line comment block explaining why the duplication was needed to trigger do_rootfs's recrdeptask. The matching bbclass change folds OCI_LAYERS packages: layers into IMAGE_INSTALL automatically, so the duplication is no longer needed and the explanatory comment for the old workaround is no longer accurate. Drop the IMAGE_INSTALL line and the obsolete comment. Replace them with a short note in-line with OCI_LAYERS that describes the new behaviour and tells readers when they would still need to add to IMAGE_INSTALL themselves (e.g. for packages used only by a rootfs postprocess fixup that don't land in any final layer). Functional verification on qemux86-64: 1. Snapshot the existing build (with explicit IMAGE_INSTALL): cp -a tmp/deploy/images/qemux86-64/app-container-multilayer-...-oci /tmp/baseline ls -1 /tmp/baseline/blobs/sha256/ | sort > /tmp/baseline.txt 2. Edit recipe (drop IMAGE_INSTALL), cleansstate, rebuild. 3. Compare blob digest lists. Result: all three OCI image layer blobs (the actual container content, ~16 MB total) match byte-for-byte between the two builds. Only the config and manifest blobs differ, which is expected — they embed the build timestamp via org.opencontainers.image.created and reference the new config digest. No layer content drift. Signed-off-by: Bruce Ashfield

docs/container-bundling: refresh multi-layer mode section

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

Three related updates to the multi-layer documentation, all driven by patterns that came up reviewing recent OCI image recipes: - Drop the "IMAGE_INSTALL must include all packages to trigger builds" guidance from the example. As of the matching bbclass change, image-oci.bbclass folds OCI_LAYERS packages: entries into IMAGE_INSTALL automatically, so recipes only set the package list once. The example used to demonstrate the dual-source-of-truth workaround for the original limitation; with the limitation gone the example was actively misleading. - Add a "Conditional Packages per Layer" subsection documenting the bb.utils.contains() pattern for adding/omitting packages from a packages: layer based on PACKAGECONFIG (or any other variable), without duplicating the whole OCI_LAYERS declaration in two branches. This is a real, useful idiom that recipes have started using; previously undocumented. - Fill in the "host" layer type row in the layer-type table. The type was already supported and explained in image-oci.bbclass inline docs, but the user-facing reference table only listed packages / directories / files. 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