This series introduces tools and class structure in the layer for enabling testing Xen system images with Qemu, booting with a device tree that describes the target system. A device tree is required

Yup, that's the right thing to do. I've queued it for my local testing now. Bruce -- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" -

Yes, sounds good to me! 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

The wrong link caused conflicts with other packages, so the link error was fixed and the conflict handling was removed. Signed-off-by: Zang Ruochen <zangrc.fnst@...> ---

ack - will do that for v2 ack, I don't think we do. I think the following works OK: put this into the qemuboot-xen-defaults.bbclass: +# Increase the default qemu memory allocation to allow for the

oops, yep, I forgot - I've checked with that done and it works fine, so will update in v2 Will fix. Thanks for the review. Christopher

Bruce, I am resending the v3 which completely removes the bbappend when virtualization is found in DISTRO_FEATURES. As you mentioned the bbappend originates all the way from python2 days and is no

It has been carried over from python2 and is no longer required. More importantly it breaks the python3-native build due to ${STAGING_DIR_TARGET} being "" for native recipes. Signed-off-by: Ruslan

Thanks, Bruce! That's very helpful. I agree having two copies isn't ideal, so it's nice to know an approach that allows decoupling has already been considered. We'll take a look at these and

Hi, I am building with my own kernel meta data and that's my little

Yes .. precisely! I'll reply to both email here, so I'm mixing replies to Diego and Kyle throughout. We had a similar discussion in #meta-virt about a month ago, when some AGL builds were running

I've applied your patch, and have pushed it to the repo. I'm also seeing the build failure now. I tried to bump the version of the package, but it still has the same kernel build issue. (my efforts

it builds ok with 5.4 in dunfell now, only gatesgarth with 5.8 and newer with 5.10 kernel are broken

Now with do_patch fixed it fails a bit later in do_compile with: | make[1]: warning: jobserver unavailable: using -j1. Add '+' to parent make rule. | make[1]: Entering directory

* fixes: ERROR: uxen-guest-tools-4.1.7-r0 do_patch: Command Error: 'quilt --quiltrc /OE/build/oe-core/tmp-glibc/work/qemux86_64-oe-linux/uxen-guest-tools/4.1.7-r0/recipe-sysroot-native/etc/quiltrc

Your question made me remember about the docker.scc. Which is being maintained both on meta-virt and yocto-kernel-cache. And linux-yocto_virtualization.inc makes usage of the one from meta-virt, which

Hello, meta-virtualization's linux-yocto_virtualization.inc includes cfg/virtio.scc in KERNEL_FEATURES, which is a dependency from yocto-kernel-cache. However, we do not use yocto-kernel-cache with

In my case it's a custom layer with a recipe that inherits python3native. To reproduce just build python3-native or anything inheriting python3native thus adding python3-native to DEPENDS. The key is

Diego had sent a patch for this earlier today, so I grabbed his and we should be good to go. Bruce <Daniel.Dragomir@...> wrote: -- - Thou shalt not follow the NULL pointer, for chaos and

merged. Bruce In message: [meta-virtualization][PATCH hardknott] busybox-initrd: Update to 1.33.1 on 21/07/2021 Diego Sueiro wrote: