Hi Bruce, Looking at the issue a little further, I found we need to use the hardcoded ‘/usr/lib’. This is because sysctl is hardcoding that. Some codes in sysctl.c from procps: static

The libvirtd package has already packaged ${sysconfdir}/sysctl.d, and also the /usr/lib/sysctl.d/60-libvirtd.conf, it would be reasonable for it to package other sysctl conf files, otherwise we will

On Mon, Apr 11, 2022 at 9:05 AM Bruce Ashfield via lists.yoctoproject.org <bruce.ashfield=gmail.com@...> wrote: I've pushed my WIP patch

Aha. Right you are. So we should tweak libvirt to use ${libdir} and not the hardcoded /user/lib (which it never really should have been), and package anything that gets installed into sysctl.d/ It

Hi Bruce & Preeti, I was trying to fix the same issue when I found this thread. This issue appears when multilib is enabled. When multilib is disabled, ${libdir} is /usr/lib, thus packaging

No libvirt bbappend file in build and multiconfig is created to build with particular kernel version. In recipe

There's definitely something different in your configuration, so that needs to be understood first. That file is packaged as part of libvirt-python here, and should be the same for others, as I

It had a protocol specification already, I just managed to miss an 'o'. I've fixed that, and pushed the change. Annoying that github didn't break/stop my build immediately with that typo, but at least

Also, fix the indentation for the SRC_URI variable assignment. Signed-off-by: Diego Sueiro <diego.sueiro@...> --- recipes-networking/cni/cni_git.bb | 9 +++++---- 1 file changed, 5

Hi Michal, Thanks a lot for this. For the whole serie: Reviewed-by: Bertrand Marquis <bertrand.marquis@...> Cheers Bertrand

ERROR: mc:x86-2020:libvirt-8.1.0-r0 do_package: QA Issue: libvirt: Files/directories were installed but not shipped in any package: /usr/lib/sysctl.d/60-qemu-postcopy-migration.conf Please set FILES

I'm not seeing any packaging issues here. Can you elaborate on what warning/QA/other issue you are seeing ? Bruce -- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its

From: Preeti Sachan <preeti.sachan@...> Signed-off-by: Preeti Sachan <preeti.sachan@...> --- recipes-extended/libvirt/libvirt_8.1.0.bb | 1 + 1 file changed, 1 insertion(+) diff --git

It isn't strictly required. There's so many entries in the SRC_URI for some packages, we can't really list them all, and have the SRCREV format be useful at all. Bruce -- - Thou shalt not follow the

From: Bruce Ashfield <bruce.ashfield@...> Sent: 08 April 2022 18:39 To: Bruce Ashfield <bruce.ashfield@...> Cc: Diego Sueiro <Diego.Sueiro@...>; meta-virtualization@...; Richard Neill

I'll see if I see the same behaviour, as i've done a LOT of cleanalls as I battled the uprev of k3s, and didn't see that. But it could have been hidden in a fail -> restart cycle as things moved past

On Fri, Apr 8, 2022 at 1:04 PM Bruce Ashfield via lists.yoctoproject.org <bruce.ashfield=gmail.com@...> wrote: FYI: Here's the WIP change:

Hi Bruce Build with empty download folder works: bitbake k3s -c cleanall (cd downloads; find -name \*andreyvit\* -delete ) bitbake k3s My download folder looks like that after building

Yep. I don't use flannel, so it wasn't something that I had done. That being said, I wanted to avoid maintaining separate recipes per-plugin, so when the need arose, I was going to add it to cni_git

Hi Bruce, I'm having k3s runtime issues where during the k3s.service start I'm getting error messages about missing/usr/libexec/cni/flannel. I saw that the cni_git.bb recipe was bumped to versions