It looks like not a whole lot of folks are building 4.17 with systemd as the init system. I ran into a packaging area with the xenstored.mount packaging (it isn't present in 4.17 as you noted in this

From: Xiangyu Chen <xiangyu.chen@...> The /usr/lib64/python3.11/site-packages/.debug/libvirtmod_lxc*.so libraries with build path embedded, and the setup.py doesn't respect our CFLAGS with

merged. Bruce In message: [meta-virtualization][PATCH] libvirt: fix libraries contain build folder path cause QA warning on 19/01/2023 Xiangyu Chen wrote:

merged. Bruce In message: [meta-virtualization][PATCH] libvirt: fix soruce code comments contain build folder path cause QA Issue warning on 18/01/2023 Xiangyu Chen wrote:

merged to langdale, but master is a git based recipe, so we should just be bumping the version/SRCREV. I've taken care of that version bump for master. Bruce In message:

merged. Bruce In message: [meta-virtualization][kirkstone][PATCH] lxc: backport patch to fix CVE-2022-47952 on 18/01/2023 Xiangyu Chen wrote:

Good Catch! My package update scripts don't take that into account, so I missed it! Bruce In message: [meta-virtualization][master][PATCH] ovs: update CVE_VERSION to 3.0.3 on 16/01/2023 Xiangyu

We'll have a look! Outside of doing a lot of builds, i don't suppose there's a specific way to reproduce the issue ? Bruce -- - Thou shalt not follow the NULL pointer, for chaos and madness

Hello Bruce, we had this failure on the xen recipe during an AB meta-virt build: | In file included from xsm/flask/ss/services.c:46: | ./xsm/flask/include/avc.h:18:10: fatal error: av_permissions.h:

From: Xiangyu Chen <xiangyu.chen@...> libvirt debug trace contains source path, and some utils was located to yocto sysroot folder, those full source path cause yocto QA buildpath check

From: Xiangyu Chen <xiangyu.chen@...> gendispatch.pl add build dir in code comments which was generated by itself. those build dir information would cause yocto qa report warnings

From: Xiangyu Chen <xiangyu.chen@...> Signed-off-by: Xiangyu Chen <xiangyu.chen@...> --- ...ching-an-incoming-CVE-CVE-2022-47952.patch | 76 +++++++++++++++++++

From: Xiangyu Chen <xiangyu.chen@...> Signed-off-by: Xiangyu Chen <xiangyu.chen@...> --- ...ching-an-incoming-CVE-CVE-2022-47952.patch | 76 +++++++++++++++++++

From: Xiangyu Chen <xiangyu.chen@...> Signed-off-by: Xiangyu Chen <xiangyu.chen@...> --- recipes-networking/openvswitch/openvswitch_git.bb | 2 +- 1 file changed, 1 insertion(+),

I've pushed this to the stable branches, but I have an uprev of OVS on master-next, so it doesn't look like this is needed there. Bruce <xiangyu.chen@...> wrote: -- - Thou shalt not

Right, that's what I meant that I also have a similar storage patch that I was testing. It is broken across packages with btrfs go interfaces, so I was attempting a single solution. Bruce -- -

Bruce Ashfield <bruce.ashfield@...> escreveu no dia terça, 10/01/2023 à(s) 15:39: I have tried on my side bumping to v1.10.0 as well but this patch is still needed. Thanks for looking at

This is one of the breakages I warned about earlier, I have a version bump in master-next, and pending fix that I'm about to push. If those don't sort it out, I'll have a closer look at

| # github.com/containers/storage/drivers/btrfs | vendor/github.com/containers/storage/drivers/btrfs/btrfs.go:387:11: args.lim.max_referenced undefined (type _Ctype_struct_btrfs_qgroup_limit has no

Hi all, If you run into go applications failing to build in master, I'm aware of the problem and I'm working on it. I can't run system level testing until I get them fixed, so any pending merges