I'm seeing it now as well. I've been working on a few things, so my testing against oe-core was at an older commit. So the change is likely good, but I'm waiting for a v2 with Randy's suggested

Hello Diego, Bertrand, Just confirmed that by bringing these changes into hardknott, the modules get correctly probed on bootup. The xen.conf content, just for

The xen modules load from systemd was fixed in master as https://git.yoctoproject.org/meta-virtualization/commit/?id=44dad5105d408e7b6217600eba3672e72db0f42f and honister as

Hi Paulo, This should not impact the module loading. This is the interesting file. It shall be used by systemd on boot to load the modules required by Xen. Please check if gntdev is listed

Hi Bertrand, One very important piece of information I missed to disclose: I am not using runqemu, as it was not being properly set by the resulting bitbake build (the resulting image was pointing to

Hi Paulo, Hardknott is long term while honister is not but both are stable releases. I am not quite sure I get your 4.14 pulling 4.16. The 4.14 recipe is building the latest 4.14 version of

Hello Bertrand, <Bertrand.Marquis@...> wrote: Oops, my mistake, sorry. The main reason was that hardknott is tagged as a stable release and it already includes xen 4.14 or latest (it is actually

Hi Paulo, Please always keep the mailing list in as me asking the questions does not mean I will necessarily be the one working on this. Please see some questions here after. Any reason not to use

Hi Paulo, No problem at all and thanks a lot for the feedback. This should not happen and should be fixed. Could you tell us what you are building (which image) and what parameters did you set in

Hello all, I am a bit new to meta-virtualization and to the Xen project And to virtualizations, so please bear with me :) I've been trying to make use of the xen project, currently targeting qemu (and

The phrase: "was added ... which removes" is awkward. As a student of Strunk and White, I suggest: --- In oe-core, the commit: a83623a54a Revert "cmake.bbclass: Set CXXFLAGS and CFLAGS" drops

commit a83623a54a375d3ae9198a135b94379881a2b7a5 was added to oe-core which removes CXXFLAGS and CFLAGS causing compilation for ceph to fail. Set CXXFLAGS and CFLAGS to resolve the

No problem. I did the cherry pick. Bruce -- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II

merged Bruce -- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II

Hi Bruce, Could this be also added in honister branch ? Thanks Bertrand

cloud-init still requires legacy setup.py behavior. Signed-off-by: Tim Orling <tim.orling@...> --- recipes-extended/cloud-init/cloud-init_21.4.bb | 2 +- 1 file changed, 1 insertion(+), 1

I have never seen the failure. This is from a build that did see it. NOTE: recipe qemu-6.2.0-r0: task do_package_qa: Succeeded NOTE: recipe libvirt-7.2.0-r0: task do_configure: Succeeded NOTE:

merged. Bruce In message: [meta-virtualization][meta-cloud-services][PATCH] layer.conf: Update to kirkstone namespace on 10/03/2022 wangmy wrote:

I've merged the patch, if Christopher has any review comments or needs changes, we'll stack them on top. Bruce In message: [meta-virtualization] [PATCH] xen: Override CC and CPP in make command

s/libvert/libvirt/ In message: [meta-virtualization] [meta-virt][PATCH 1/1] libvert: modify dependencies on lxc_protocol.h on 10/03/2022 Joe Slater wrote: Can you document the configuration (i.e.