Re: [OE-core] [RFC][PATCH v2 0/9] standalone wic

["Mathieu Dubois-Briand" <mathieu.dubois-briand@bootlin.com>]

On Mon Feb 2, 2026 at 6:07 PM CET, Trevor Woerner via lists.openembedded.org wrote:
> This series of patches explores the possibility of splitting wic out
> from oe-core into its own standalone utility. The wic utility will
> continue to fall under The Yocto Project umbrella, but will no longer
> be integrated into the project as part of oe-core. The ultimate goal is
> to make wic a completely independent tool, hosted on PyPI, with its own
> tests, development roadmap, and releases.
>
> Some benefits include:
> - relieving the oe-core maintainers from having to review, understand,
>    merge, or reject wic patches
> - allow the tool to be used outside of The Yocto Project for generating
>   Linux images
> - provide more flexibility to explore other features, libraries,
>   mechanisms, etc
>
> The initial task of splitting wic out into its own repository was
> performed with the help of AI. It was checked, and subsequent work was
> done without AI.
>
> These changes have been tested with oe-selftest as follows:
> 	$ sudo .../layers/openembedded-core/scripts/runqemu-gen-tapdevs <my numeric group id> 4
> 	$ oe-selftest -v -r wic
>
> On my machine my oe-selftest results for an unmodified oe-core give:
> 	successes=93, skipped=1, failures=0, errors=1
> with these patches I get:
> 	successes=91, skipped=1, failures=2, errors=0
>
> There are 2 tests that need to be fixed, but it would be great to get
> some feedback on this work, and to see what the AB thinks of it so far.
> I have also done some adhoc testing with meta-rockchip and
> meta-raspberrypi.
>
> Should this work eventually make its way to oe-core, it would need to
> be squashed into a single commit otherwise builds will break when only
> partially applied. They have been submitted here in this RFC series
> separately to make review easier.
>

Hi Trevor,

Thanks for this series. I ran it on the autobuilder, a few issues (maybe
just a single one actually), but most tests succeed.


So first, we have the wic tests, which try to invoke the wic tools
directly. These one entirely failed because wic was not found in the
path at all:

Running '. ./init-build-env; wic create directdisk -e core-image-sato -o ${BUILDDIR}/tmp/deploy/wic_images/qemux86/directdisk/core-image-sato/' with output to /srv/pokybuild/yocto-worker/wic/build/build/command-1-cmds.log in /srv/pokybuild/yocto-worker/wic/build/build
/bin/bash: line 1: wic: command not found

https://autobuilder.yoctoproject.org/valkyrie/#/builders/15/builds/3076

So I still have to look in depth at your patches, but I suspect, as the
tool is now in a separate git, it can no longer be used just by sourcing
the environment file.

In the context of the test, this is probably not really an issue, we can
just fix it to have wic tools. But thinking about users, this might be a
bigger issue as it does change a bit the flow if they want to use wic
directly.


The second issue is similar: one of the selftests fails as the wic
command was not found:

2026-02-03 09:54:38,418 - oe-selftest - INFO - systemd_boot.Systemdboot.test_efi_systemdboot_images_can_be_built (subunit.RemotedTestCase)
2026-02-03 09:54:38,419 - oe-selftest - INFO -  ... FAIL
...
AssertionError: Command 'wic cp /srv/pokybuild/yocto-worker/oe-selftest-armhost/build/build-st-1720620/tmp/deploy/images/genericx86-64/core-image-minimal-genericx86-64.rootfs.wic:1/EFI/BOOT/bootx64.efi /srv/pokybuild/yocto-worker/oe-selftest-armhost/build/build-st-1720620/tmp/deploy/images/genericx86-64/bootx64.efi -n /srv/pokybuild/yocto-worker/oe-selftest-armhost/build/build-st-1720620/tmp/work/core2-64-poky-linux/wic-tools/1.0/recipe-sysroot-native' returned non-zero exit status 127:
/bin/sh: 1: wic: not found

https://autobuilder.yoctoproject.org/valkyrie/#/builders/23/builds/3260
https://autobuilder.yoctoproject.org/valkyrie/#/builders/35/builds/3136
https://autobuilder.yoctoproject.org/valkyrie/#/builders/48/builds/3034


And so far, that's all. So we might have other issues masked behind
this, but overall it looks pretty good in term of tests.

Thanks,
Mathieu

-- 
Mathieu Dubois-Briand, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com