summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* tests: fix lxc lifecycle suite hang and tighten download-skip predicateHEADmasterBruce Ashfield2026-06-151-5/+62
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Two diagnostics-quality fixes to test_lxc_runtime.py uncovered by running the full suite after lxc-networking landed in the lxc profile: 1. test_start used `exit $rc` after the lxc-start invocation to propagate the exit code through run_cmd's marker harness. With lxc-networking now installed, lxc-start succeeds (rc=0) and the `exit 0` terminates the guest's interactive login shell, which triggers getty respawn. Every subsequent lifecycle test then times out waiting for its marker because the new getty is sitting at the login prompt with no auto-login. Wrap the cleanup in `( exit $LXC_RC )` so only a subshell exits; the outer login shell stays alive for the next test. While here, pre-flight checks for lxc-net.service and the lxcbr0 link surface in the failure message — the "ABORTING" path that bit us during bring-up gave no hint which precondition was missing. 2. test_create_alpine_via_download treated any non-zero lxc-create rc as "network unreachable" and skipped. That swallowed a stale "Container already exists" left over from an interrupted previous run (or from manual poking), silently turning a real test-harness bug into a green skip. Pre-clean with `lxc-destroy --force` (best-effort, ignores rc), then match a list of known network-error markers explicitly. Any other failure is a real bug and fails the test with the full lxc-create output instead of hiding behind pytest.skip. Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
* tests: use CONTAINER_PROFILE and surface runqemu errors in lxc fixtureBruce Ashfield2026-06-151-9/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Two correctness improvements to the lxc runtime test fixture. 1. Switch the build from CONTAINER_IMAGE_HOST_EXTRA_INSTALL = "lxc" to CONTAINER_PROFILE = "lxc". The original fixture set CONTAINER_IMAGE_HOST_EXTRA_INSTALL to force lxc into the rootfs without depending on a profile fragment, because at the time no lxc profile existed. Now that container-host-lxc.conf is in tree, the test should exercise the same path real users take — which is the entire point of a runtime test. Using the profile also pulls in lxc-networking and lxc-templates automatically (via packagegroup-lxc), where the original "just install lxc" approach silently left a half-broken LXC the test couldn't usefully verify. 2. Capture the runqemu output to a file and surface it in the pexpect.EOF failure message. pexpect's default 100-character "before" buffer truncates runqemu's actual error to the trailing fragment, which is rarely enough to diagnose the failure. Boot failures during fixture setup now print the last 60 lines of the runqemu log into the pytest failure message and leave the full log at /tmp/test_lxc_runtime-runqemu.log for follow-up. When the lxc image still wasn't booting cleanly, this is what made the "lxc-net.service could not be found" / bridge-missing root cause visible without re-instrumenting the fixture. Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
* container-host: add lxc profileBruce Ashfield2026-06-153-0/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | conf/distro/include/ shipped fragments for docker, podman, containerd, incus, k3s, and k3s-node, with the indirection chain local.conf : require container-host-${BUILD_PROFILE}.conf container-host-FOO.conf : CONTAINER_PROFILE = "FOO" meta-virt-container-cfg.bbclass (USER_CLASSES): include meta-virt-container-${CONTAINER_PROFILE}.inc meta-virt-container-FOO.inc : VIRTUAL-RUNTIME_container_engine ??= "FOO" container-image-host.bb : contains_any('VIRTUAL-RUNTIME_container_engine', 'FOO', 'packagegroup-FOO', '', d) lxc was not part of that set, even though packagegroup-lxc existed. Integrators wanting a lxc-flavoured container-image-host had to either add lxc to CORE_IMAGE_EXTRA_INSTALL by hand or invent their own fragment. This commit fills in the three missing pieces so lxc becomes a peer of the existing engines: conf/distro/include/container-host-lxc.conf User-facing fragment. Sets CONTAINER_PROFILE = "lxc". This is the file integrators require from local.conf, same shape as the existing container-host-incus.conf. conf/distro/include/meta-virt-container-lxc.inc Resolved by meta-virt-container-cfg.bbclass from CONTAINER_PROFILE. Sets VIRTUAL-RUNTIME_container_engine ??= "lxc" and zeroes the OCI-shaped VIRTUAL-RUNTIME_container_runtime / _networking / _dns / _orchestration variables (LXC doesn't use any of the OCI engine model), matching the incus .inc. recipes-extended/images/container-image-host.bb Adds the lxc branch to the engine-selection block, alongside the existing docker / podman / containerd / incus checks. When VIRTUAL-RUNTIME_container_engine is "lxc", IMAGE_INSTALL gets packagegroup-lxc, which (with the recipe + packagegroup changes) is now lxc + lxc-networking + lxc-templates. After this change, setting BUILD_PROFILE = "lxc" in local.conf and building container-image-host produces a guest where lxc-create, lxc-start, lxc-attach, etc. work against the download template end-to-end. Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
* packagegroup-lxc: pull in networking and templates explicitlyBruce Ashfield2026-06-151-0/+2
| | | | | | | | | | | | | | | | | | packagegroup-lxc is documented as the "ready-to-use LXC" group but its RDEPENDS only listed the lxc package itself, not the networking or templates sub-packages required for a functional LXC. With the matching change to the lxc recipe (RRECOMMENDS adding both sub-packages to anyone installing lxc), this packagegroup would now pick them up transitively — but listing them in RDEPENDS here keeps the packagegroup honest as a self-contained specification of what it provides, and guards against future BAD_RECOMMENDATIONS in a downstream distro silently turning packagegroup-lxc back into "just the binaries." This is the path container-image-host takes when VIRTUAL-RUNTIME_container_engine is set to "lxc", so it's also the path the just-added container-host-lxc profile fragment exercises. Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
* lxc: pull in networking and templates via RRECOMMENDSBruce Ashfield2026-06-151-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | The lxc recipe ships three sub-packages: ${PN}, ${PN}-networking, and ${PN}-templates. ${PN} contains the lxc-* command-line binaries. ${PN}-networking owns lxc-net.service, /etc/default/lxc-net, the dnsmasq drop-in for the lxcbr0 bridge, and the firewall plumbing. ${PN}-templates owns /usr/share/lxc/templates, the per-distro container-creation scripts that lxc-create invokes via --template. Installing only the main ${PN} package leaves a non-functional LXC. There's no lxcbr0 bridge, so any container whose config references it (every download-template default config does) fails to start with network.c: netdev_configure_server_veth: Failed to attach "vethXXX" to bridge "lxcbr0", bridge interface doesn't exist and there are no template scripts, so lxc-create --template <foo> has nothing to invoke. The user-facing toolchain is effectively broken unless the integrator knows to add the sub-packages by hand. Pull both sub-packages in through RRECOMMENDS so any image that installs lxc gets a functional LXC by default, regardless of whether the install path is packagegroup-lxc, IMAGE_INSTALL:append, or CORE_IMAGE_EXTRA_INSTALL. Integrators who don't want them (custom networking, hand-written templates) can drop either or both through BAD_RECOMMENDATIONS. Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
* tests: add lxc runtime tests with download-template regressionmaster-nextBruce Ashfield2026-06-142-0/+291
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <bruce.ashfield@gmail.com>
* lxc: drop templates-actually-create-DOWNLOAD_TEMP-directory.patchBruce Ashfield2026-06-142-38/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <bruce.ashfield@gmail.com>
* container-bundle: add CONTAINER_FLAGS_ACCEPTED to acknowledge container licensesBruce Ashfield2026-06-132-5/+104
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <bruce.ashfield@gmail.com>
* vcontainer-tarball: unset OECORE_NATIVE_SYSROOT in CITim Orling2026-06-131-0/+2
| | | | | | | | | | | 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 <tim.orling@konsulko.com> Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
* tests: add requirements.txtTim Orling2026-06-121-0/+3
| | | | | | | Add requirements.txt to allow versions to be pinned. Signed-off-by: Tim Orling <tim.orling@konsulko.com> Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
* libvirt: re-add ptest support for meson build systemHaitao Liu2026-06-122-4/+73
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <haitao.liu@windriver.com> Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
* openvswitch: re-enable ptestHaitao Liu2026-06-121-3/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <haitao.liu@windriver.com> Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
* app-container-multilayer: drop redundant IMAGE_INSTALLBruce Ashfield2026-06-121-6/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <bruce.ashfield@gmail.com>
* docs/container-bundling: refresh multi-layer mode sectionBruce Ashfield2026-06-121-4/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <bruce.ashfield@gmail.com>
* image-oci: auto-derive IMAGE_INSTALL from OCI_LAYERS packages layersBruce Ashfield2026-06-121-5/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <bruce.ashfield@gmail.com>
* vcontainer-tarball: track rootfs hash via explicit mcdependsBruce Ashfield2026-06-121-0/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | vcontainer-tarball bundles vdkr and vpdmn rootfs images alongside the helper scripts into a single-shot SDK tarball. Those rootfs images live in the vruntime-x86-64 / vruntime-aarch64 multiconfigs and are pulled into the tarball at do_populate_sdk time from tmp-<mc>/deploy/images/<machine>/<tool>/<arch>/rootfs.img. For sstate to behave correctly, the tarball task's hash must reflect the actual rootfs content. In practice it didn't. A rootfs content change — adding netavark to the image, switching the runtime from iptables to nftables — left consumers of the SDK with a stale runtime even though their config asked for the new behaviour. Cleansstate of vcontainer-tarball alone didn't help: the path through the cached intermediates was serving the old image back. The recipe was relying on the chain rootfs-image:do_build -> initramfs-create:do_compile -> initramfs-create:do_deploy -> mcdepends -> tarball:do_populate_sdk to propagate the rootfs hash. The break is at do_deploy: it reads its rootfs.img out of DEPLOY_DIR, which is a known sstate sharp edge. do_deploy can sstate-hit on its own hash while the file it deploys came from a stale prior run, after which the downstream tarball task hash is computed against the stale content and also hits cache. Add a direct mcdepends from do_populate_sdk to {vdkr,vpdmn}-rootfs-image:do_image_complete for each enabled vruntime multiconfig. The rootfs-image task's hash now feeds the tarball hash directly, independent of the intermediate do_deploy step. If a rootfs content change moves the rootfs-image hash, the tarball is forced to rebuild. When the chain was already healthy this dep adds nothing new and costs nothing. Verified end-to-end: bitbake vcontainer-tarball -c cleansstate bitbake vcontainer-tarball sha256sum tmp/deploy/sdk/vcontainer-standalone.sh # -> f8e75f947a506202d88a6eb196a3616f5088b11247207beab589e91fb6f2bba7 echo 'IMAGE_INSTALL:append:pn-vpdmn-rootfs-image = " bash"' \ >> conf/local.conf bitbake vcontainer-tarball sha256sum tmp/deploy/sdk/vcontainer-standalone.sh # -> 1e89554500b2a4aaabc149a01f85fad2e78ba35796977469e7fcb1ecf15a856f Hashes differ — the rootfs content change correctly invalidated the tarball's sstate hash and produced a fresh build. Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
* vrunner: warn on shutdown-escalation that state disk may be corruptedBruce Ashfield2026-06-121-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | When the guest doesn't exit within the daemon_stop() poll window, the graceful_shutdown() didn't complete and the state disk's ext4 journal may have unflushed writes from this session. Any subsequent escalation (QMP quit, SIGTERM, SIGKILL) leaves the disk image at risk of corruption: layer files end up with correct inode metadata but partially-unwritten data extents, surfacing on the next session as Error: reading blob sha256:<hash>: EOF Error: reading blob sha256:<hash>: file integrity checksum failed for "<file>" These errors are silent today — the operator hits them later in another session with no way to correlate back to the original cause. Emit a WARN as soon as the poll window expires, naming the symptom and pointing at the remediation (`memres restart --clean`) so the next session starts from a known-good state instead of inheriting a corrupted image. This is purely diagnostic — no behavior change to the shutdown sequence itself. The escalation paths (QMP quit, SIGTERM, SIGKILL) still run unchanged. Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
* vrunner: use QMP quit before SIGTERM in daemon_stop escalationBruce Ashfield2026-06-121-1/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | When the SHUTDOWN-via-virtio-serial poll window expires and the QEMU process is still alive, send a QMP quit before SIGTERMing. Functionally near-equivalent to SIGTERM at the process level (both converge on qemu_system_killed() and a block-layer flush) but goes through QEMU's monitor interface, which is the same mechanism hv_idle_shutdown() already uses for idle-timeout shutdowns. Unifying the two escalation paths makes the code easier to reason about — one channel for "ask QEMU to exit cleanly," one fallback for "the monitor isn't responding." QMP quit is NOT a replacement for the virtio-serial ===SHUTDOWN=== command: it stops QEMU without giving the guest a chance to run its own graceful_shutdown() (which is what cleanly unmounts the state disk). It's only an improvement over SIGTERM as the *fallback* when the guest hasn't responded to the SHUTDOWN command within the poll window. The full architectural fix — QMP system_powerdown driving an ACPI handler in the guest that calls graceful_shutdown() — needs guest-side acpid wiring and is tracked separately. SIGTERM and SIGKILL remain as further fallbacks for cases where QMP itself is unresponsive (e.g. older configs without a QMP socket, or QEMU hung in a state where the monitor stops servicing commands). Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
* vrunner: poll for clean VM exit before SIGTERM in daemon_stopBruce Ashfield2026-06-121-3/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The daemon_stop() flow sent ===SHUTDOWN=== over virtio-serial and then slept exactly 2 seconds before unconditionally SIGTERMing QEMU. The guest's graceful_shutdown(), which is what the SHUTDOWN command ultimately triggers, does: sync umount /var/lib/containers/storage (ext4 journal commit) sync blockdev --flushbufs (per disk) sync sleep 2 reboot -f Under load this routinely takes 5-30 seconds — the ext4 journal commit on the state disk after a vimport that just wrote tens of MB of layer blobs is the slow step. A fixed 2-second wait followed by SIGTERM kills the guest mid-umount and leaves the state disk's journal half-committed: layer files have correct inode metadata but partially-unwritten data extents. The next memres session remounts that disk and reads the apparently-OK files. Tar-split reassembly during podman save / podman push then hits the unwritten extents and produces: Error: reading blob sha256:<hash>: EOF Error: reading blob sha256:<hash>: file integrity checksum failed for "<file>" Reported via yocto-patches as a workaround in run-push-containers (`<runtime> image rm --all` before push) on the autobuilder. The "first push works, subsequent fail" pattern in that report comes from the first push hitting a clean session and subsequent pushes inheriting the corrupted state disk from the prior SIGTERM-truncated shutdown. Replace the fixed sleep with a poll loop that watches for the QEMU process to exit, up to 60 seconds (120 * 0.5s). 60s is generous enough to cover heavy ext4 journal commits; short enough that a truly hung guest doesn't block the caller indefinitely. The existing SIGTERM and SIGKILL escalation paths remain as fallbacks for the genuinely-stuck case. Reproducer: vimport an OCI image as testimg:latest, save it, memres restart, re-vimport, save again. Without this fix the second save fails 100% of the time on the same blob digest with EOF or CRC error. With this fix six consecutive vimport+save cycles across three restart rounds complete cleanly. Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
* tests: add containerd and CRI-O recipe and runtime testsBruce Ashfield2026-06-121-0/+358
| | | | | | | | | | | | | | | | | | | | | | | 35 tests across three tiers: Tier 1 (static): containerd recipe checks (virtual/containerd provider, systemd service, CNI networking, ctr/shim install), profile config, packagegroup, nerdctl and cri-tools recipe existence, CRI-O recipe checks (seccomp requirement, systemd service, CNI/conmon/runtime deps). Tier 2 (build): containerd, nerdctl, and container-image-host with containerd profile build verification. Tier 3 (boot): containerd service status, ctr/nerdctl availability and version, namespace listing, runtime availability, CNI plugins, nerdctl pull/run/images cycle with busybox. The boot tests build container-image-host with CONTAINER_PROFILE=containerd automatically. CRI-O boot tests are not included — CRI-O requires a kubelet to drive it, so runtime testing is covered by k3s tests when k3s is configured to use CRI-O as its CRI. Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
* tests: add libvirt recipe and runtime testsBruce Ashfield2026-06-121-0/+468
| | | | | | | | | | | | | | | | | | | | | | | 46 tests across three tiers: Tier 1 (static, no build): Recipe structure, PACKAGECONFIG options, hook_support.py python3 compatibility (text mode, raw string regex, syntax validation), service files, patch files, kvm-image-minimal recipe checks. Tier 2 (build): libvirt and kvm-image-minimal build verification. Tier 3 (boot): libvirtd service status, virtlockd socket, virsh connectivity via monolithic daemon socket, capabilities, nodeinfo, domain listing, default network, hook script installation and permissions, qemu user and libvirt group existence. The boot tests use the explicit monolithic daemon socket path (qemu+unix:///system?socket=/var/run/libvirt/libvirt-sock) because libvirt v12 defaults to modular daemons (virtqemud) but the kvm-image-minimal recipe runs the monolithic libvirtd. Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
* libvirt: enable nftables by defaultBruce Ashfield2026-06-121-1/+1
| | | | | | | | | | | | | | The iptables kernel modules (MASQUERADE, etc.) are increasingly unavailable — the broader container ecosystem has moved to nftables (netavark dropped iptables entirely, incus prefers nft). Without nftables enabled, libvirtd's default network fails to start with "Extension MASQUERADE revision 0 not supported, missing kernel module". Add nftables to the default PACKAGECONFIG. This switches the firewall backend priority to nftables,iptables (prefer nft, fall back to iptables) and changes RDEPENDS from iptables to nftables + iproute2-tc. Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
* libvirt: disable secrets encryption for embedded environmentsBruce Ashfield2026-06-121-0/+10
| | | | | | | | | | | | | | | Libvirt v12 added encrypted secrets storage using systemd-creds. The build-time virt-secret-init-encryption.service generates an encrypted credential via 'systemd-creds encrypt' tied to the build host's TPM or machine key. At runtime in a QEMU VM (or any different machine), the credential cannot be decrypted, causing libvirtd to fail with "Invalid encryption key for the secret" and refuse to start. Set encrypt_data = 0 in secret.conf and remove the stale build-time encrypted key file. Embedded and QEMU-based environments do not have persistent machine credentials needed for this feature. Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
* tests: remove redundant DISTRO_FEATURES appends from build fixturesBruce Ashfield2026-06-123-3/+2
| | | | | | | | | | | | | | | | | The -R conf files used by test build fixtures appended DISTRO_FEATURES values that are already provided by meta-virt-host.conf (virtualization, vcontainer, systemd). BitBake tracks append operations in task hashes, so a duplicate append changes the hash and invalidates sstate for every recipe that depends on DISTRO_FEATURES — causing full rebuilds even when the image was just built. Only append features genuinely needed by the test profile and not already present in the base config: - k3s: append only "k3s" (virtualization already in base) - xen: append only "xen vxn" (virtualization systemd vcontainer in base) - incus: no append needed (CONTAINER_PROFILE alone is sufficient) Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
* linux-yocto: add CONFIG_SCHED_CORE for LXC 7.0Bruce Ashfield2026-06-122-0/+5
| | | | | | | | | | | | | LXC 7.0.0 requires core scheduling support (CONFIG_SCHED_CORE) and aborts container startup with "The kernel does not support core scheduling" when it is missing. This is a new hard requirement — previous LXC versions treated it as optional. Add lxc-extra.cfg fragment unconditionally (alongside the existing lxc.scc from the kernel cache) since any build with the virtualization DISTRO_FEATURE may use LXC containers via incus or directly. Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
* incus: change service type from notify to simpleBruce Ashfield2026-06-121-3/+4
| | | | | | | | | | | | | Incusd does not call sd_notify(READY=1) — the Go source has no systemd notification support in the main daemon (only in incus-agent, the guest-side component). With Type=notify, systemd waits indefinitely for the ready notification and the service stays in 'activating' state even though incusd is fully operational. This was not caught before the v7 uprev because the previous build was cached via sstate or the service was tested manually. Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
* incus: switch from iptables to nftablesBruce Ashfield2026-06-121-1/+1
| | | | | | | | | | Incus detects nftables at runtime and prefers it for firewall management. Without the nft binary, incusd logs "nft missing" and falls back to a degraded mode that can leave the service stuck in activating state. The broader ecosystem has moved to nftables — netavark already dropped iptables support entirely. Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
* k3s: fix pause image reference for containerd v2Bruce Ashfield2026-06-123-5/+15
| | | | | | | | | | | | | | | | | | K3s's default pause image reference "rancher/mirrored-pause:3.6" is a short name that containerd v1 auto-expanded to the fully qualified "docker.io/rancher/mirrored-pause:3.6". The k3s v1.36 uprev moved to containerd v2, which uses a new CRI plugin (io.containerd.cri.v1) with a pinned_images config instead of the old sandbox_image. Containerd v2 no longer auto-expands short names when looking up pinned images, causing every pod sandbox creation to fail with "image not found" even though the image is present in the containerd image store under its fully qualified name. Pass --pause-image docker.io/rancher/mirrored-pause:3.6 in both the server and agent systemd service files to use the fully qualified reference that containerd v2 can resolve. Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
* tests: make k3s, incus, and xen tests self-containedBruce Ashfield2026-06-123-49/+159
| | | | | | | | | | | | | | | | | | | These boot tests previously required manual local.conf changes to set CONTAINER_PROFILE, DISTRO_FEATURES, and other variables before the image could be built and tested. This meant complete test coverage required editing local.conf between runs. Add build fixtures that use bitbake -R with a temporary conf file to inject the required variables automatically: - k3s: builds container-image-host with CONTAINER_PROFILE=k3s-host - incus: builds container-image-host with CONTAINER_PROFILE=incus - xen: builds xen-image-minimal with xen/vxn DISTRO_FEATURES Each test module now builds its own image before booting, using the same run_bitbake + extra_vars pattern established in test_container_cross_install.py. Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
* tests: fix image ID parsing and 9p assertion patternsBruce Ashfield2026-06-122-22/+25
| | | | | | | | | | | | | | test_vdkr_registry.py: Docker's images output changed from separate REPOSITORY TAG IMAGE_ID columns to combined IMAGE ID DISK_USAGE columns. The parser grabbed the disk usage (8.45MB) as the image ID. Handle both old and new formats. test_container_registry_script.py: The secure registry tests checked for literal 'virtfs' and 'cashare' strings in vrunner.sh, but the 9p share setup was refactored to use hv_build_9p_opts(). Update assertions to match the current abstraction. Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
* tests: parametrize boot tests over container profiles for full coverageBruce Ashfield2026-06-122-209/+227
| | | | | | | | | | | | | | | | | | | | | | | | | | The boot tests (TestBundledContainersBoot, TestCustomServiceFileBoot) previously depended on whatever CONTAINER_PROFILE was in local.conf, skipping docker checks when podman was configured and vice versa. Getting complete coverage required manually editing local.conf and running the tests twice. Add --container-profiles pytest option (default: docker,podman) and a profiled_session fixture that builds container-image-host with each profile via a temporary bitbake -R conf file, boots it, and runs all checks. Both docker and podman get a full build-boot-verify cycle in a single test run with no local.conf changes. Also fix: - run_bitbake() gains extra_vars parameter for bitbake -R overrides - Strip OSC 3008 shell integration escape sequences from run_command output (BusyBox shell emits these, corrupting file paths used in subsequent commands) - Use known file paths for service file content checks instead of extracting paths from ls output (avoids escape sequence corruption) - Add test_bundle_class_unpack_enabled to catch do_unpack[noexec] regression Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
* container-bundle: fix do_unpack for custom service filesBruce Ashfield2026-06-121-3/+3
| | | | | | | | | | | | | | | | | 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 <bruce.ashfield@gmail.com>
* tests: fix container-cross-install bitbake invocation and busybox compatBruce Ashfield2026-06-122-20/+34
| | | | | | | | | | | | | | | | | | | | | | | | Three issues in test_container_cross_install.py: - run_bitbake() called bitbake directly, requiring the OE build environment to be pre-sourced. test_multilayer_oci.py wraps bitbake in 'bash -c source oe-init-build-env && bitbake' which is self- contained. Adopt the same pattern so tests work from any shell. - test_vdkr_initramfs_create and test_vpdmn_initramfs_create built the initramfs recipes in the main config, but these recipes require the vruntime multiconfig distro. Use mc:vruntime-x86-64: prefix. - test_systemd_services_directory_exists used 'head -5' which BusyBox does not support (requires 'head -n 5'). The container-image-host image uses BusyBox when built without coreutils. Also fix conftest.py VdkrRunner and VpdmnRunner ensure_memres() to default no_registry=True, so pulled images use short names (alpine:latest) rather than registry-prefixed names from the baked-in VDKR_DEFAULT_REGISTRY config. Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
* netavark: add nftables as runtime dependencyBruce Ashfield2026-06-122-0/+4
| | | | | | | | | | | | | | Netavark dropped iptables support and now uses nft directly for all firewall rules (masquerade, DNAT, connection tracking). Without nftables installed, netavark fails at runtime with "unable to execute nft: No such file or directory", preventing any podman container from starting with network access. Add nftables to netavark's RDEPENDS since it is an unconditional runtime requirement, and to packagegroup-netavark for independent packagegroup usage. Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
* container-host-config: update registries.conf to v2 formatBruce Ashfield2026-06-121-23/+8
| | | | | | | | | | Podman 6.0 rejects the v1 registries.conf format entirely, failing with "registries.conf must be in v2 format but is in v1" at runtime. The old format used [registries.search] with registries = [...] syntax which was deprecated for years. Docker is unaffected — it does not read registries.conf. Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
* vpdmn: switch to nftables and add kernel config for netavarkBruce Ashfield2026-06-043-1/+22
| | | | | | | | | | | | | | | | | | | | Netavark dropped iptables support entirely and now uses nft directly for firewall rules (masquerade, DNAT, connection tracking). The vpdmn rootfs had iptables installed but the vruntime kernel had CONFIG_NF_TABLES disabled, causing netavark to fail at runtime with "Protocol not supported" when trying to initialize the nftables Netlink socket. Replace iptables with nftables in vpdmn-rootfs-image IMAGE_INSTALL and add container-net.cfg kernel config fragment enabling NF_TABLES, NFT_MASQ, NFT_NAT, NFT_CT, NFT_FIB and related options required by netavark's nftables firewall driver. The fragment is gated on the vcontainer DISTRO_FEATURE so it only applies to vruntime/vcontainer kernels, not arbitrary builds that happen to include meta-virtualization. Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
* netavark: update to v2.0.0-dev-tipBruce Ashfield2026-06-042-128/+140
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Bumping netavark to version v1.17.0-165-ga1f48948, which comprises the following commits: 196ff50c fix(deps): update rust crate clap to ~4.6.1 8e7bd639 Cirrus: Remove all setup 7ef20deb packit: Add testing-farm jobs 4e65e01e tmt: Initial enablement 28a9af01 rpm: Add tests subpackage f57e23e0 gitignore: Include generated rpm dirs a105a5d9 Tests: Use environment variables for binary paths 13235bdc fix(deps): update tonic monorepo to 0.14.6 8c066cf0 test: run firewalld with debug logging 0b60e14d fix(deps): update rust crate mozim to 0.3.2 34bce643 fix(deps): update rust crate tokio to 1.52.3 48f26952 bats: remove fd 3 work around 6d59b0d0 bump msrv to 1.88 27a27e82 Packit: Only create dist-git PRs for rawhide f75ebcbb Improve error messages 5fb96334 Remove OWNERS file 230dd6eb routes: Add route_type field for blackhole/unreachable/prohibit routes 06187459 fix(deps): update rust crate tokio to 1.52.1 3f3c588d bridge: default to strict isolation mode 65fe5b5c macvlan: use a default metric of 99 e798da91 fix(deps): update rust crate netlink-packet-route to 0.30.0 ab5e1843 fix(deps): update rust crate tokio to 1.52.0 457369fa Ensure create plugins don't change name, id, or driver 98e8a4c2 Add within-network subnet overlap and duplicate validation f81e2332 chore(deps): update rust crate rand to v0.9.3 [security] c45d1e7f Fix: Add more descriptive netavark error messages(s) 61112f39 Add IPv6 auto-detection in network create 825a2014 Add more create tests. b2f28218 fix(deps): update rust crate tokio to 1.51.1 41ae8821 fix(deps): update rust crate tokio to 1.51.0 0378fa78 fix(deps): update rust crate clap to ~4.6.0 abe3842a fix(deps): update rust crate env_logger to 0.11.10 d9b5a3bd fix(deps): update rust crate regex to 1.12.3 ec9414e9 fix(deps): update rust crate chrono to 0.4.44 4b643515 Re-use parse functions for drivers 7525cba1 Introduce netavark create command fa9a2a30 Break out exec plugin logic 3710f631 Split `install` into sub-targets 80bb1b80 chore(deps): update rust crate once_cell to 1.21.4 59a81031 chore(deps): update dependency containers/automation_images to v20260310 f725857c chore(deps): update rust crate tempfile to 3.27.0 9dadaa43 fix(deps): update rust crate tokio to 1.50.0 a7bb3355 fix(deps): update rust crate ipnet to 2.12.0 497df7eb fix(deps): update rust crate clap to ~4.5.60 358d63a8 [skip-ci] Update GitHub Artifact Actions 39c9a938 chore(deps): update rust crate tempfile to 3.26.0 a3863bb0 remove netlink zero buffer workaround da79ffe6 chore(deps): update rust crate chrono to 0.4.44 b5b9ffd1 fix(deps): update rust crate netlink-packet-route to 0.29.0 402e401b fix(deps): update tonic monorepo to 0.14.5 a85e4938 Support multiple static IPs per subnet b49f7b99 fix(deps): update rust-futures monorepo to 0.3.32 90bbbc12 fix(deps): update tonic monorepo to 0.14.4 c7797087 migrate to oidc faca63ea fix(deps): update rust crate env_logger to 0.11.9 7860f16a chore(deps): update rust crate tempfile to 3.25.0 d082033f fix(deps): update rust crate hyper-util to 0.1.20 e2d40bd4 fix(deps): update tonic monorepo to 0.14.3 3c42c174 fix(deps): update rust crate netlink-sys to 0.8.8 c552dc4b netlink_route: remove NLM_F_ACK from dump requests e76248e2 netlink: validate buffer length fd3d2ad1 netlink: zero out buffer before sending 8b3db5e1 netlink: socket read logic 00ae6483 bridge: read mtu from vrf table if set 0e114222 only consult main routing table for default interface f0bce8d8 chore(deps): update rust crate chrono to 0.4.43 becf497f fix(deps): update rust crate tower to 0.5.3 b070c572 fix(deps): update rust crate zbus to 5.13.1 a8b25232 fix(deps): update rust crate prost to 0.14.3 5eeca3ff fix(deps): update rust crate zbus to 5.13.0 0b0c5c13 fix(deps): update rust crate netlink-packet-route to 0.28.0 aaf2eb54 chore(deps): update rust crate tempfile to 3.24.0 c08db05c fix(deps): update rust crate tokio-stream to 0.1.18 26854297 fix(deps): update rust crate tokio to 1.49.0 d1acb61b fix(deps): update rust crate serde_json to 1.0.146 1b53849b [skip-ci] Update GitHub Artifact Actions c8c07fd7 chore(deps): update dependency containers/automation_images to v20251211 f2c5265a mozim: do not use netlink feature d8901d00 bump mozim to v0.3.1 49ee09b2 make network setup order deterministic eaa44031 fix(deps): update rust crate hyper-util to 0.1.19 d42622bc fix(deps): update rust crate log to 0.4.29 658740ee fix(deps): update rust crate clap to ~4.5.53 6c2066a3 [skip-ci] Update actions/checkout action to v6 02ae64f6 New images 2025-11-20 2355b144 Minor documentation and style fixes 7054ba66 Add test cases that existed for iptables but not for nftables 0fa48211 Remove iptables support 37446a17 fix(deps): update rust crate hyper-util to 0.1.18 1df91984 bump to v2.0.0-dev bd90b616 add outbound_addr4 & outbound_addr6 to bridge driver Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
* podman: switch from CNI to netavark as sole network backendBruce Ashfield2026-06-043-15/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | Podman's vendored containers/common library removed CNI support entirely in commit 8d1f636e40 (March 2026). The NetworkBackend() function now unconditionally rejects any backend other than netavark, making network_backend = "cni" in containers.conf a runtime error. The vpdmn rootfs originally used CNI because netavark's dependency chain (nmap -> libpcap -> bluez5 -> cairo) was too heavy for the vruntime BBMASK environment. That dependency chain no longer exists — netavark v1.16.0+ uses a built-in Rust connection tester and has no heavyweight runtime dependencies. Recipe changes: - Clear BUILDTAGS_EXTRA default (was CNI build tag, now a no-op) - Set VIRTUAL-RUNTIME_container_networking and _container_dns with strong assignments so podman always RDEPENDS on netavark and aardvark-dns regardless of distro config - Remove ${sysconfdir}/cni from FILES vpdmn rootfs changes: - Replace cni with netavark + aardvark-dns in IMAGE_INSTALL - Update containers.conf network_backend from cni to netavark Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
* slirp4netns: update to v1.3.4-tipBruce Ashfield2026-06-031-2/+2
| | | | | | | | Bumping slirp4netns to version v1.3.4-2-g13fd3e7, which comprises the following commits: 4f4bcaf v1.3.4+dev Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
* passt: update to 2026_05_26-tipBruce Ashfield2026-06-031-2/+2
| | | | | | | | | Bumping passt to version 2026_05_26.038c51e-2-g4b28237, which comprises the following commits: 4b28237 tcp: Don't leak sockets on error paths 98e3c01 tcp, tcp_splice: Make helper for setting SO_LINGER socket option Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
* openvswitch: update to v3.7.1-tipBruce Ashfield2026-06-031-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | Bumping ovs to version v3.7.1-18-g04b05b31a, which comprises the following commits: 04b05b31a ofproto-dpif: Fix bundle floodable flag when disabling STP/RSTP. ea4ac2dd5 ovsdb-cs: Fix resource leak in ovsdb_cs_parse_schema(). e2a95595a configure: Allow disabling POSIX async I/O and disable in FreeBSD CI. 8dbcfcc4c cirrus: Remove Cirrus CI for running FreeBSD test builds. 73057faec github: Migrate FreeBSD CI from Cirrus CI to GitHub Actions. 47446a693 ofproto-dpif: Remove unused rule->recirc_id. 502e13a8b ofproto-dpif: Rename recirc_free_ofproto to better match the code. 9b63c2ead ofproto-dpif: Avoid race between recirc id free and the leak check. bc4498ced docs: Remove a few remaining references to the OOT module. b7d221174 vswitch.xml: Remove the claim that OVS processes are single-threaded. 1f28a59dc vswitch.xml: Remove the claim that L3 GRE is not supported. 04ad744ff dpif-netdev: Fix mega flow ufid collisions for different wild cards. 332081017 ofproto-dpif-xlate: Classify ct_clear as non-reversible for clone(). 45443e077 docs: Fix OpenFlow port range. 1a77b18d0 github: Re-enable system tests for DPDK and AF_XDP. b53965f1a netdev-dpdk: Fix memory leak when configuring rx-steering. 1c9b2cefd stream-ssl: Disable TLS session tickets. 78aa10ca3 Prepare for 3.7.2. Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
* cni: bump plugins to v1.9.1-tip and flannel to v1.9.1-flannel1-tipBruce Ashfield2026-06-034-48/+91
| | | | | | | | | | | | | | | | | | | | | | | The cni recipe pins three upstream components. Per-component state: - containernetworking/cni (SRCREV_cni): unchanged at 7c270076 = v1.3.0-27-g7c27007, already at master HEAD. - containernetworking/plugins (SRCREV_plugins): 6d8f05b8 -> d653d38d (v1.9.1-3 -> v1.9.1-10). - flannel-io/cni-plugin (SRCREV_flannel_plugin): 09e4c7f9 -> e4902565 (v1.9.0-flannel1-12 -> v1.9.1-flannel1-6 — crosses to the v1.9.1 flannel line). PV stays at 1.3.0+git since the canonical "cni" component didn't move. Regenerated go-mod sidecars via `bitbake cni -c discover_and_generate` for the new go.sum that the plugins + flannel SRCREV bumps imply. Added `include go-mod-licenses.inc` for first-time per-dependency license tracking on this recipe. Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
* yq: update to v4.53.2-tipBruce Ashfield2026-06-035-13/+104
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Bumping yq to version v4.53.2-25-g8f3291d3, which comprises the following commits: 8f3291d3 fix: decode properties array bracket paths (#2693) 2861815f fix(json): preserve floats with trailing zero when encoding YAML to JSON (#2701) fcb79822 feat(toml): fix JSON to TOML root scope and null handling (#2689) e9acb9b7 Bump golang.org/x/mod from 0.35.0 to 0.36.0 (#2709) 83b282c4 Bump golang.org/x/net from 0.53.0 to 0.54.0 (#2707) 54fa4324 Bump golang from 1.26.2 to 1.26.3 (#2706) ee6c30da fix: reset TOML decoder finished flag on Init to fix multi-doc evaluation (#2704) 722c9aa1 Fix nested inline YAML merge explode (#2699) 702dd160 Bump github.com/pelletier/go-toml/v2 from 2.3.0 to 2.3.1 (#2695) d1dff466 fix: preserve TOML inline table array scope (#2694) cb979355 fix: TOML encoder uses inline tables for YAML FlowStyle mappings, inconsistent with explicit JSON parsing (#2687) cfe2eee7 Preserve empty TOML arrays in tables (#2686) 1a433d10 Bump actions/upload-artifact from 4.6.1 to 7.0.1 (#2663) 1c0d8b9d Bump actions/checkout from 4.2.2 to 6.0.2 (#2668) 0110a3ce Bump golang.org/x/net from 0.52.0 to 0.53.0 (#2669) 54482d44 Bump golang from `2a2b4b5` to `5f3787b` (#2664) 33f3351c Bump ossf/scorecard-action from 2.4.1 to 2.4.3 (#2665) 6cb656ce Bump alpine from `2510918` to `5b10f43` (#2667) ecc43d7c fix: reset TOML decoder between files when evaluating all at once (#2685) 1deec5e4 Fix repeatString overflow test on 32-bit platforms (#2680) ff45fad1 Bump github.com/zclconf/go-cty from 1.18.0 to 1.18.1 (#2682) 6679d3c0 Bump github/codeql-action from 3 to 4 (#2671) 54a7fc8f Bump softprops/action-gh-release from 2.6.2 to 3.0.0 (#2672) 0d3ab079 Bump golang.org/x/text from 0.35.0 to 0.36.0 (#2670) d93987a9 release notes Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
* python3-webob: update to 1.8.10Bruce Ashfield2026-06-031-1/+1
| | | | | | | | Bump 1.8.9 -> 1.8.10 (latest on PyPI). New sdist sha256sum: 1c963a11f307bc3f624fbab9dde737701eae255f32981b7a5486a88db1767c2b Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
* python3-newrelic: update to 13.1.0Bruce Ashfield2026-06-032-20/+40
| | | | | | | | Bump 10.9.0 -> 13.1.0 (latest on PyPI). New sdist sha256sum: 1492f0fe510cdc0c1347f597baca2a3ddd7e0662895a800e19fe524396f7bf05 Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
* python3-dotenv: update to 1.2.2Bruce Ashfield2026-06-032-366/+2
| | | | | | | | Bump 1.1.0 -> 1.2.2 (latest on PyPI). New sdist sha256sum: 2c371a91fbd7ba082c2c1dc1f8bf89ca22564a087c2c287cd9b662adde799cf3 Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
* python3-bugsnag: update to 4.9.0Bruce Ashfield2026-06-031-1/+1
| | | | | | | | Bump 4.7.1 -> 4.9.0 (latest on PyPI). New sdist sha256sum: c22e2d1f0148282a0898e4c81a0ed39c65ee566e20bdc43cec04b978eb272b2b Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
* python3-botocore: update to 1.43.21Bruce Ashfield2026-06-031-1/+1
| | | | | | | | Bump 1.37.35 -> 1.43.21 (latest on PyPI). New sdist sha256sum: 17604607efe28894e947401379e569cc8f0fe2d69337ece98bd0c82d1bcfaf92 Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
* python3-boto3: update to 1.43.21Bruce Ashfield2026-06-031-1/+1
| | | | | | | | Bump 1.37.35 -> 1.43.21 (latest on PyPI). New sdist sha256sum: 6dfeb70bf4f9a3514b91c7199f475f71f939199d62f9c63cd555b033fb283f89 Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
* gunicorn: update to 26.0.0Bruce Ashfield2026-06-031-3/+3
| | | | | | | | Bump 23.0.0 -> 26.0.0 (latest on PyPI). New sdist sha256sum: ca9346f85e3a4aeeb64d491045c16b9a35647abd37ea15efe53080eb8b090baf Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
generated by cgit v1.2.3-54-g00ecf (git 2.39.0) at 2026-07-11 20:16:34 +0000