[PATCH] virt-what: add new recipe
Ross Burton <ross@...>
Signed-off-by: Ross Burton <ross.burton@...>
--- recipes-extended/virt-what/virt-what_1.21.bb | 11 +++++++++++ 1 file changed, 11 insertions(+) create mode 100644 recipes-extended/virt-what/virt-what_1.21.bb diff --git a/recipes-extended/virt-what/virt-what_1.21.bb b/recipes-exten= ded/virt-what/virt-what_1.21.bb new file mode 100644 index 0000000..aa235b3 --- /dev/null +++ b/recipes-extended/virt-what/virt-what_1.21.bb @@ -0,0 +1,11 @@ +SUMMARY =3D "Detect if we are running in a virtual machine" +HOMEPAGE =3D "https://people.redhat.com/~rjones/virt-what/" +LICENSE =3D "GPL-2.0-only" +LIC_FILES_CHKSUM =3D "file://COPYING;md5=3Db234ee4d69f5fce4486a80fdaf4a4= 263" + +SRC_URI =3D "https://people.redhat.com/~rjones/virt-what/files/${BP}.tar= .gz" +SRC_URI[sha256sum] =3D "12cb455334aa4cfd53ab78f27e2252e94d1f676dd093f483= 27ed94d8080d1f7b" + +DEPENDS =3D "perl-native" + +inherit autotools --=20 2.25.1
|
|
[dunfell][PATCH] containerd-opencontainers: add EXTRA_EXTLDFLAGS and use it to fix build with gold
Martin Jansa
* Work around internal error in gold triggered due to DWARF-5 by forcing to use bfd even with ld-is-gold:
_/OE/lge/build/webosose/dunfell/BUILD/work/qemux86_64-webos-linux/containerd-opencontainers/v1.2.14+gitAUTOINC+3b3e9d5f62-r0/git/src/import/cmd/containerd-shim /OE/lge/build/webosose/dunfell/BUILD/work/qemux86_64-webos-linux/containerd-opencontainers/v1.2.14+gitAUTOINC+3b3e9d5f62-r0/recipe-sysroot-native/usr/lib/x86_64-webos-linux/go/pkg/tool/linux_amd64/link: running x86_64-webos-linux-gcc failed: exit status 1 /OE/lge/build/webosose/dunfell/BUILD/work/qemux86_64-webos-linux/containerd-opencontainers/v1.2.14+gitAUTOINC+3b3e9d5f62-r0/recipe-sysroot-native/usr/bin/x86_64-webos-linux/../../libexec/x86_64-webos-linux/gcc/x86_64-webos-linux/9.3.0/ld: internal error in read_header_prolog, at ../../gold/dwarf_reader.cc:1678 collect2: error: ld returned 1 exit status * alternatively we can backport DWARF-5 support to binutils-2.34 used in dunfell like in: https://git.openembedded.org/openembedded-core/commit/?id=d07d4d739ae17787017f771dd2068fda0e836722 Signed-off-by: Martin Jansa <Martin.Jansa@...> --- .../0001-Add-build-option-GODEBUG-1.patch | 2 +- .../0001-build-use-oe-provided-GO-and-flags.patch | 0 .../containerd/containerd-opencontainers_git.bb | 11 ++++++++++- 3 files changed, 11 insertions(+), 2 deletions(-) rename recipes-containers/containerd/{files => containerd-opencontainers}/0001-build-use-oe-provided-GO-and-flags.patch (100%) diff --git a/recipes-containers/containerd/containerd-opencontainers/0001-Add-build-option-GODEBUG-1.patch b/recipes-containers/containerd/containerd-opencontainers/0001-Add-build-option-GODEBUG-1.patch index 05c4f15..fec9ea6 100644 --- a/recipes-containers/containerd/containerd-opencontainers/0001-Add-build-option-GODEBUG-1.patch +++ b/recipes-containers/containerd/containerd-opencontainers/0001-Add-build-option-GODEBUG-1.patch @@ -33,7 +33,7 @@ index 4355395..4fb5d3b 100644 -GO_LDFLAGS=-ldflags '-s -w -X $(PKG)/version.Version=$(VERSION) -X $(PKG)/version.Revision=$(REVISION) -X $(PKG)/version.Package=$(PACKAGE) $(EXTRA_LDFLAGS)' -SHIM_GO_LDFLAGS=-ldflags '-s -w -X $(PKG)/version.Version=$(VERSION) -X $(PKG)/version.Revision=$(REVISION) -X $(PKG)/version.Package=$(PACKAGE) -extldflags "-static"' +GO_LDFLAGS=-ldflags '-X $(PKG)/version.Version=$(VERSION) -X $(PKG)/version.Revision=$(REVISION) -X $(PKG)/version.Package=$(PACKAGE) $(EXTRA_LDFLAGS)' -+SHIM_GO_LDFLAGS=-ldflags '-X $(PKG)/version.Version=$(VERSION) -X $(PKG)/version.Revision=$(REVISION) -X $(PKG)/version.Package=$(PACKAGE) -extldflags "-static" $(EXTRA_LDFLAGS)' ++SHIM_GO_LDFLAGS=-ldflags '-X $(PKG)/version.Version=$(VERSION) -X $(PKG)/version.Revision=$(REVISION) -X $(PKG)/version.Package=$(PACKAGE) -extldflags "-static $(EXTRA_EXTLDFLAGS)" $(EXTRA_LDFLAGS)' #Replaces ":" (*nix), ";" (windows) with newline for easy parsing GOPATHS=$(shell echo ${GOPATH} | tr ":" "\n" | tr ";" "\n") diff --git a/recipes-containers/containerd/files/0001-build-use-oe-provided-GO-and-flags.patch b/recipes-containers/containerd/containerd-opencontainers/0001-build-use-oe-provided-GO-and-flags.patch similarity index 100% rename from recipes-containers/containerd/files/0001-build-use-oe-provided-GO-and-flags.patch rename to recipes-containers/containerd/containerd-opencontainers/0001-build-use-oe-provided-GO-and-flags.patch diff --git a/recipes-containers/containerd/containerd-opencontainers_git.bb b/recipes-containers/containerd/containerd-opencontainers_git.bb index a52a5c3..5f697ed 100644 --- a/recipes-containers/containerd/containerd-opencontainers_git.bb +++ b/recipes-containers/containerd/containerd-opencontainers_git.bb @@ -10,7 +10,16 @@ LIC_FILES_CHKSUM = "file://src/import/LICENSE;md5=1269f40c0d099c21a871163984590d CONTAINERD_VERSION = "v1.2.14" -EXTRA_OEMAKE += "GODEBUG=1" +# Work around internal error in gold triggered due to DWARF-5 by forcing to use bfd even with ld-is-gold: +# _/OE/lge/build/webosose/dunfell/BUILD/work/qemux86_64-webos-linux/containerd-opencontainers/v1.2.14+gitAUTOINC+3b3e9d5f62-r0/git/src/import/cmd/containerd-shim +# /OE/lge/build/webosose/dunfell/BUILD/work/qemux86_64-webos-linux/containerd-opencontainers/v1.2.14+gitAUTOINC+3b3e9d5f62-r0/recipe-sysroot-native/usr/lib/x86_64-webos-linux/go/pkg/tool/linux_amd64/link: running x86_64-webos-linux-gcc failed: exit status 1 +# /OE/lge/build/webosose/dunfell/BUILD/work/qemux86_64-webos-linux/containerd-opencontainers/v1.2.14+gitAUTOINC+3b3e9d5f62-r0/recipe-sysroot-native/usr/bin/x86_64-webos-linux/../../libexec/x86_64-webos-linux/gcc/x86_64-webos-linux/9.3.0/ld: internal error in read_header_prolog, at ../../gold/dwarf_reader.cc:1678 +# collect2: error: ld returned 1 exit status +# alternatively we can backport DWARF-5 support to binutils-2.34 used in dunfell like in: +# https://git.openembedded.org/openembedded-core/commit/?id=d07d4d739ae17787017f771dd2068fda0e836722 +EXTRA_EXTLDFLAGS = "${@bb.utils.contains('DISTRO_FEATURES', 'ld-is-gold', ' -fuse-ld=bfd ', '', d)}" + +EXTRA_OEMAKE += "GODEBUG=1 EXTRA_EXTLDFLAGS='${EXTRA_EXTLDFLAGS}'" PROVIDES += "virtual/containerd" RPROVIDES_${PN} = "virtual/containerd" -- 2.35.1
|
|
Re: k3s build issues on master
Bruce Ashfield
On Thu, Mar 31, 2022 at 2:05 PM Diego Sueiro <Diego.Sueiro@...> wrote:
The SRCREV is as intended. It is not intended to be that tag exactly, it is the tip of the 1.22.x branch (and that's what all of them have been throughout the history of the recipes). We can use +git${SRCPV} in the recipe, but honestly, that's not the biggest challenge with the go mod chaos, but I'll add it as part of my next update. Cheers, 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
|
|
Re: k3s build issues on master
Diego Sueiro
Hi Bruce,
From: Bruce Ashfield <bruce.ashfield@...>
Sent: 31 March 2022 17:38 To: Diego Sueiro <Diego.Sueiro@...> Cc: meta-virtualization@... <meta-virtualization@...>; nd <nd@...> Subject: Re: k3s build issues on master On Thu, Mar 31, 2022 at 12:22 PM Diego Sueiro <Diego.Sueiro@...> wrote:
In this case it seems that thev1.22.6+k3s1 tag
is pointing to 3228d9cb9a4727d48f60de4f1ab472f7c50df904.
Cheers,
Diego
Cheers,
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
|
|
Re: k3s build issues on master
Bruce Ashfield
On Thu, Mar 31, 2022 at 12:22 PM Diego Sueiro <Diego.Sueiro@...> wrote:
The short log is wrong, the SRCREV and PV are correct. There's some fundamental issues with 1.23.x that prevented it from building inside or outside of bitbake, so I scaled back the version bump at the last minute to stay in 1.22.x series. And yes, there's no more vendoring in k3s, so you can't just bump the SRCREV and PV, we have to adjust all of the git clones and shuffling to make it build. I have some more changes to that recipe pending, so I'll do a minor cleanup, with a shortlog that makes things clear. Cheers, 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
|
|
k3s build issues on master
Diego Sueiro
Hi Bruce,
Whilst investigating a build problem on our CI related to sstate mirror of the k3s recipe, I found that the commit "k3s:
update to 1.23.1" (8cba065209dd668afe939f878da340a017ecdd7d) didn't change the PV and SRCREV_k3s
variables correctly.
I changed those values to v1.23.1+k3s1 and 08d538fb3a04a0fe904b34cf04f7e21191b82449 respectively and now I'm getting the following do_compile error:
```
go: inconsistent vendoring in /kas_build_dir/tmp/work/neoversen1-poky-linux/k3s/v1.23.3+k3s1-r0/k3s-v1.23.3+k3s1/src/import:
github.com/google/cadvisor@...: is explicitly required in go.mod, but not marked as explicit in vendor/modules.txt
[...]
k8s.io/sample-controller: is marked as replaced by github.com/k3s-io/kubernetes/staging/src/k8s.io/sample-controller@... in vendor/modules.txt, but replaced by github.com/k3s-io/kubernetes/staging/src/k8s.io/sample-controller@...
in go.mod
To ignore the vendor directory, use -mod=readonly or -mod=mod.
To sync the vendor directory, run:
go mod vendor
```
Unfortunately, I have zero knowledge in go and I have no idea how I could fix this.
Diego Sueiro
|
|
Re: [PATCH] libvirt: upgrade 7.2.0 -> 8.1.0
Bruce Ashfield
There's already a libvirt upgrade in master-next. Check it out and send any patches incrementally to that. Bruce
On Thu, Mar 31, 2022 at 10:18 AM <sakib.sajal@...> wrote: Dropped patches which are part of the new version: --
- Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II
|
|
[PATCH] libvirt: upgrade 7.2.0 -> 8.1.0
sakib.sajal@...
Dropped patches which are part of the new version:
0001-docs-Fix-template-matching-in-page.xsl.patch 0001-security-fix-SELinux-label-generation-logic.patch 0001-storage_driver-Unlock-object-on-ACL-fail-in-storageP.patch 0002-meson-Fix-compatibility-with-Meson-0.58.patch Dropped the obsolete md5checksum. From upstream libvirt, the commit: 8eb4461645 remove sysconfig files removes all sysconfig files. Add the former libvirtd sysconfig file that starts libvirtd in the right mode. Since the sysconfig file has already been sed'ed, remove the sed line from the install rule. Signed-off-by: Sakib Sajal <sakib.sajal@...> --- recipes-extended/libvirt/libvirt-python.inc | 4 +- ...cs-Fix-template-matching-in-page.xsl.patch | 64 ------------------- ...y-fix-SELinux-label-generation-logic.patch | 56 ---------------- ...nlock-object-on-ACL-fail-in-storageP.patch | 40 ------------ ...on-Fix-compatibility-with-Meson-0.58.patch | 48 -------------- recipes-extended/libvirt/libvirt/libvirtd | 22 +++++++ .../{libvirt_7.2.0.bb => libvirt_8.1.0.bb} | 19 +++--- 7 files changed, 34 insertions(+), 219 deletions(-) delete mode 100644 recipes-extended/libvirt/libvirt/0001-docs-Fix-template-matching-in-page.xsl.patch delete mode 100644 recipes-extended/libvirt/libvirt/0001-security-fix-SELinux-label-generation-logic.patch delete mode 100644 recipes-extended/libvirt/libvirt/0001-storage_driver-Unlock-object-on-ACL-fail-in-storageP.patch delete mode 100644 recipes-extended/libvirt/libvirt/0002-meson-Fix-compatibility-with-Meson-0.58.patch create mode 100644 recipes-extended/libvirt/libvirt/libvirtd rename recipes-extended/libvirt/{libvirt_7.2.0.bb => libvirt_8.1.0.bb} (94%) diff --git a/recipes-extended/libvirt/libvirt-python.inc b/recipes-extended/libvirt/libvirt-python.inc index a48aaea5..6f963fb8 100644 --- a/recipes-extended/libvirt/libvirt-python.inc +++ b/recipes-extended/libvirt/libvirt-python.inc @@ -17,8 +17,8 @@ FILES:${PN}-python = "${bindir}/* ${libdir}/* ${libdir}/${PYTHON_DIR}/*" SRC_URI += "http://libvirt.org/sources/python/libvirt-python-${PV}.tar.gz;name=libvirt_python" -SRC_URI[libvirt_python.md5sum] = "19bf22414a43d358581b9259b52047a7" -SRC_URI[libvirt_python.sha256sum] = "c0c3bac54c55622e17927b09cd9843869600d71842fb072c99491fe2608dcee7" +SRC_URI[libvirt_python.md5sum] = "dbb1ab179303700aefa20f831b645ee2" +SRC_URI[libvirt_python.sha256sum] = "a21ecfab6d29ac1bdd1bfd4aa3ef58447f9f70919aefecd03774613f65914e43" export LIBVIRT_API_PATH = "${S}/docs/libvirt-api.xml" export LIBVIRT_CFLAGS = "-I${S}/include" diff --git a/recipes-extended/libvirt/libvirt/0001-docs-Fix-template-matching-in-page.xsl.patch b/recipes-extended/libvirt/libvirt/0001-docs-Fix-template-matching-in-page.xsl.patch deleted file mode 100644 index 9dd650ee..00000000 --- a/recipes-extended/libvirt/libvirt/0001-docs-Fix-template-matching-in-page.xsl.patch +++ /dev/null @@ -1,64 +0,0 @@ -Upstream-Status: Backport - -Signed-off-by: Kai Kang <kai.kang@...> - -From 54814c87f3706cc8eb894634ebef0f9cf7dabae6 Mon Sep 17 00:00:00 2001 -From: Martin Kletzander <mkletzan@...> -Date: Mon, 21 Feb 2022 09:26:13 +0100 -Subject: [PATCH] docs: Fix template matching in page.xsl - -Our last default template had a match of "node()" which incidentally matched -everything, including text nodes. Since this has the same priority according to -the XSLT spec, section 5.5: - - https://www.w3.org/TR/1999/REC-xslt-19991116#conflict - -this is an error. Also according to the same spec section, the XSLT processor -may signal the error or pick the last rule. - -This was uncovered with libxslt 1.1.35 which contains the following commit: - - https://gitlab.gnome.org/GNOME/libxslt/-/commit/b0074eeca3c6b21b4da14fdf712b853900c51635 - -which makes the build fail with: - - runtime error: file ../docs/page.xsl line 223 element element - xsl:element: The effective name '' is not a valid QName. - -because our last rule also matches text nodes and we are trying to extract the -node name out of them. - -To fix this we change the match to "*" which only matches elements and not all -the nodes, and to avoid any possible errors with different XSLT processors we -also bump the priority of the match="text()" rule a little higher, just in case -someone needs to use an XSLT processor that chooses signalling the error instead -of the optional recovery. - -https://bugs.gentoo.org/833586 - -Signed-off-by: Martin Kletzander <mkletzan@...> ---- - docs/page.xsl | 4 ++-- - 1 file changed, 2 insertions(+), 2 deletions(-) - -diff --git a/docs/page.xsl b/docs/page.xsl -index fd67918d3b..72a6fa0842 100644 ---- a/docs/page.xsl -+++ b/docs/page.xsl -@@ -215,11 +215,11 @@ - </xsl:element> - </xsl:template> - -- <xsl:template match="text()" mode="copy"> -+ <xsl:template match="text()" mode="copy" priority="0"> - <xsl:value-of select="."/> - </xsl:template> - -- <xsl:template match="node()" mode="copy"> -+ <xsl:template match="*" mode="copy"> - <xsl:element name="{name()}"> - <xsl:copy-of select="./@*"/> - <xsl:apply-templates mode="copy" /> --- -2.33.0 - diff --git a/recipes-extended/libvirt/libvirt/0001-security-fix-SELinux-label-generation-logic.patch b/recipes-extended/libvirt/libvirt/0001-security-fix-SELinux-label-generation-logic.patch deleted file mode 100644 index 2753503d..00000000 --- a/recipes-extended/libvirt/libvirt/0001-security-fix-SELinux-label-generation-logic.patch +++ /dev/null @@ -1,56 +0,0 @@ -From 15073504dbb624d3f6c911e85557019d3620fdb2 Mon Sep 17 00:00:00 2001 -From: =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= <berrange@...> -Date: Mon, 28 Jun 2021 13:09:04 +0100 -Subject: [PATCH] security: fix SELinux label generation logic -MIME-Version: 1.0 -Content-Type: text/plain; charset=UTF-8 -Content-Transfer-Encoding: 8bit - -A process can access a file if the set of MCS categories -for the file is equal-to *or* a subset-of, the set of -MCS categories for the process. - -If there are two VMs: - - a) svirt_t:s0:c117 - b) svirt_t:s0:c117,c720 - -Then VM (b) is able to access files labelled for VM (a). - -IOW, we must discard case where the categories are equal -because that is a subset of many other valid category pairs. - -Upstream-status: Backport - -Fixes: https://gitlab.com/libvirt/libvirt/-/issues/153 -CVE-2021-3631 -Reviewed-by: Peter Krempa <pkrempa@...> -Signed-off-by: Daniel P. Berrangé <berrange@...> ---- - src/security/security_selinux.c | 10 +++++++++- - 1 file changed, 9 insertions(+), 1 deletion(-) - -diff --git a/src/security/security_selinux.c b/src/security/security_selinux.c -index b50f4463cc..0c2cf1d1c7 100644 ---- a/src/security/security_selinux.c -+++ b/src/security/security_selinux.c -@@ -383,7 +383,15 @@ virSecuritySELinuxMCSFind(virSecurityManager *mgr, - VIR_DEBUG("Try cat %s:c%d,c%d", sens, c1 + catMin, c2 + catMin); - - if (c1 == c2) { -- mcs = g_strdup_printf("%s:c%d", sens, catMin + c1); -+ /* -+ * A process can access a file if the set of MCS categories -+ * for the file is equal-to *or* a subset-of, the set of -+ * MCS categories for the process. -+ * -+ * IOW, we must discard case where the categories are equal -+ * because that is a subset of other category pairs. -+ */ -+ continue; - } else { - if (c1 > c2) { - int t = c1; --- -2.17.1 - diff --git a/recipes-extended/libvirt/libvirt/0001-storage_driver-Unlock-object-on-ACL-fail-in-storageP.patch b/recipes-extended/libvirt/libvirt/0001-storage_driver-Unlock-object-on-ACL-fail-in-storageP.patch deleted file mode 100644 index 608322d9..00000000 --- a/recipes-extended/libvirt/libvirt/0001-storage_driver-Unlock-object-on-ACL-fail-in-storageP.patch +++ /dev/null @@ -1,40 +0,0 @@ -From d3e20e186ed531e196bb1529430f39b0c917e6dc Mon Sep 17 00:00:00 2001 -From: Peter Krempa <pkrempa@...> -Date: Wed, 21 Jul 2021 11:22:25 +0200 -Subject: [PATCH] storage_driver: Unlock object on ACL fail in - storagePoolLookupByTargetPath - -'virStoragePoolObjListSearch' returns a locked and refed object, thus we -must release it on ACL permission failure. - -Fixes: 7aa0e8c0cb8 -Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1984318 -Signed-off-by: Peter Krempa <pkrempa@...> -Reviewed-by: Michal Privoznik <mprivozn@...> - -Upstream-status: Backport -CVE-2021-3667 [https://bugzilla.redhat.com/show_bug.cgi?id=1986094] -Signed-off-by: Yanfei Xu <yanfei.xu@...> ---- - src/storage/storage_driver.c | 4 +++- - 1 file changed, 3 insertions(+), 1 deletion(-) - -diff --git a/src/storage/storage_driver.c b/src/storage/storage_driver.c -index ecb5b86b4f..de66f1f9e5 100644 ---- a/src/storage/storage_driver.c -+++ b/src/storage/storage_driver.c -@@ -1739,8 +1739,10 @@ storagePoolLookupByTargetPath(virConnectPtr conn, - storagePoolLookupByTargetPathCallback, - cleanpath))) { - def = virStoragePoolObjGetDef(obj); -- if (virStoragePoolLookupByTargetPathEnsureACL(conn, def) < 0) -+ if (virStoragePoolLookupByTargetPathEnsureACL(conn, def) < 0) { -+ virStoragePoolObjEndAPI(&obj); - return NULL; -+ } - - pool = virGetStoragePool(conn, def->name, def->uuid, NULL, NULL); - virStoragePoolObjEndAPI(&obj); --- -2.27.0 - diff --git a/recipes-extended/libvirt/libvirt/0002-meson-Fix-compatibility-with-Meson-0.58.patch b/recipes-extended/libvirt/libvirt/0002-meson-Fix-compatibility-with-Meson-0.58.patch deleted file mode 100644 index 3201eede..00000000 --- a/recipes-extended/libvirt/libvirt/0002-meson-Fix-compatibility-with-Meson-0.58.patch +++ /dev/null @@ -1,48 +0,0 @@ -From c607266619c5ab78ad5d4179b3ea93cfb6348391 Mon Sep 17 00:00:00 2001 -From: Andrea Bolognani <abologna@...> -Date: Mon, 3 May 2021 09:06:34 +0200 -Subject: [PATCH] meson: Fix compatibility with Meson 0.58 - -Builds failed with - - tests/meson.build:690:0: ERROR: List item must be one - of <class 'str'>, not <class 'list'> - -before this change. - -https://gitlab.com/libvirt/libvirt/-/issues/158 - -Upstream-Status: Backport [https://gitlab.com/libvirt/libvirt/-/commit/c607266619c5ab78ad5d4179b3ea93cfb6348391] - -Signed-off-by: Martin Jansa <Martin.Jansa@...> -Signed-off-by: Andrea Bolognani <abologna@...> -Reviewed-by: Peter Krempa <pkrempa@...> -Reviewed-by: Pavel Hrdina <phrdina@...> ---- - tests/meson.build | 8 ++++---- - 1 file changed, 4 insertions(+), 4 deletions(-) - -diff --git a/tests/meson.build b/tests/meson.build -index 05c3e90195..9900983d0c 100644 ---- a/tests/meson.build -+++ b/tests/meson.build -@@ -687,12 +687,12 @@ foreach name : test_scripts - test(name, script, env: tests_env) - endforeach - -+testenv = runutf8 -+testenv += 'VIR_TEST_FILE_ACCESS=1' -+ - add_test_setup( - 'access', -- env: [ -- 'VIR_TEST_FILE_ACCESS=1', -- runutf8, -- ], -+ env: testenv, - exe_wrapper: [ python3_prog, check_file_access_prog.path() ], - ) - --- -GitLab - diff --git a/recipes-extended/libvirt/libvirt/libvirtd b/recipes-extended/libvirt/libvirt/libvirtd new file mode 100644 index 00000000..455b4395 --- /dev/null +++ b/recipes-extended/libvirt/libvirt/libvirtd @@ -0,0 +1,22 @@ +# Customizations for the libvirtd.service systemd unit + +# Default behaviour is for libvirtd.service to start on boot +# so that VM autostart can be performed. We then want it to +# shutdown again if nothing was started and rely on systemd +# socket activation to start it again when some client app +# connects. +LIBVIRTD_ARGS="--timeout 120" + +# If systemd socket activation is disabled, then the following +# can be used to listen on TCP/TLS sockets +#LIBVIRTD_ARGS="--listen" +LIBVIRTD_ARGS="--listen --daemon" + +# Override the QEMU/SDL default audio driver probing when +# starting virtual machines using SDL graphics +# +# NB these have no effect for VMs using VNC, unless vnc_allow_host_audio +# is enabled in /etc/libvirt/qemu.conf +#QEMU_AUDIO_DRV=sdl +# +#SDL_AUDIODRIVER=pulse diff --git a/recipes-extended/libvirt/libvirt_7.2.0.bb b/recipes-extended/libvirt/libvirt_8.1.0.bb similarity index 94% rename from recipes-extended/libvirt/libvirt_7.2.0.bb rename to recipes-extended/libvirt/libvirt_8.1.0.bb index 1fc55b8d..f4c0722a 100644 --- a/recipes-extended/libvirt/libvirt_7.2.0.bb +++ b/recipes-extended/libvirt/libvirt_8.1.0.bb @@ -23,19 +23,15 @@ RDEPENDS:libvirt-libvirtd:append:x86 = " dmidecode" RCONFLICTS:${PN}_libvirtd = "connman" SRC_URI = "http://libvirt.org/sources/libvirt-${PV}.tar.xz;name=libvirt \ + file://libvirtd \ file://libvirtd.sh \ file://libvirtd.conf \ file://dnsmasq.conf \ file://hook_support.py \ file://gnutls-helper.py \ - file://0002-meson-Fix-compatibility-with-Meson-0.58.patch \ - file://0001-security-fix-SELinux-label-generation-logic.patch \ - file://0001-storage_driver-Unlock-object-on-ACL-fail-in-storageP.patch \ - file://0001-docs-Fix-template-matching-in-page.xsl.patch \ " -SRC_URI[libvirt.md5sum] = "92044b629216e44adce63224970a54a3" -SRC_URI[libvirt.sha256sum] = "01f459d0c7ba5009622a628dba1a026200e8f4a299fea783b936a71d7e0ed1d0" +SRC_URI[libvirt.sha256sum] = "3c6c43becffeb34a3f397c616206aa69a893ff8bf5e8208393c84e8e75352934" inherit meson gettext update-rc.d pkgconfig systemd useradd perlnative USERADD_PACKAGES = "${PN}" @@ -160,7 +156,7 @@ PACKAGECONFIG[fuse] = "-Dfuse=enabled,-Dfuse=disabled,fuse," PACKAGECONFIG[audit] = "-Daudit=enabled,-Daudit=disabled,audit," PACKAGECONFIG[libcap-ng] = "-Dcapng=enabled,-Dcapng=disabled,libcap-ng," PACKAGECONFIG[wireshark] = "-Dwireshark_dissector=enabled,-Dwireshark_dissector=disabled,wireshark libwsutil," -PACKAGECONFIG[apparmor_profiles] = "-Dapparmor_profiles=true, -Dapparmor_profiles=false," +PACKAGECONFIG[apparmor_profiles] = "-Dapparmor_profiles=enabled, -Dapparmor_profiles=disabled," PACKAGECONFIG[firewalld] = "-Dfirewalld=enabled, -Dfirewalld=disabled," PACKAGECONFIG[libpcap] = "-Dlibpcap=enabled, -Dlibpcap=disabled,libpcap,libpcap" PACKAGECONFIG[numad] = "-Dnumad=enabled, -Dnumad=disabled," @@ -211,8 +207,8 @@ do_install:append() { rmdir ${D}${prefix}/lib/systemd/system ${D}${prefix}/lib/systemd fi - # This variable is used by libvirtd.service to start libvirtd in the right mode - sed -i '/#LIBVIRTD_ARGS="--listen"/a LIBVIRTD_ARGS="--listen --daemon"' ${D}/${sysconfdir}/sysconfig/libvirtd + mkdir -p ${D}/${sysconfdir}/sysconfig + install -m 0644 ${WORKDIR}/libvirtd ${D}/${sysconfdir}/sysconfig # We can't use 'notify' when we don't support 'sd_notify' dbus capabilities. sed -i -e 's/Type=notify/Type=forking/' \ @@ -307,6 +303,11 @@ do_install:append() { # virt-login-shell needs to run with setuid permission chmod 4755 ${D}${bindir}/virt-login-shell + + # remove unsupported migration config file + # migration process is described here: + # https://wiki.qemu.org/Features/PostCopyLiveMigration + rm ${D}/usr/lib/sysctl.d/60-qemu-postcopy-migration.conf } EXTRA_OEMESON += " \ -- 2.33.0
|
|
Re: Loading the module xen-gntdev on boot
Bruce Ashfield
On Thu, Mar 24, 2022 at 9:03 AM Bertrand Marquis <Bertrand.Marquis@...> wrote: Hi Bruce, Fundamentally, the same criteria that apply to OEcore apply to meta-virt (bugfixes, CVEs), except perhaps with a less well defined turn around time if other things are going on in master. There's more flexibility around some new features or additions that don't impact existing behaviour, since the stack of software on top isn't nearly as broad as OEcore's user base. Generally speaking, those are case-by-case. It is fine to propose most any fix to be backported, I was just setting expectations about limitations on the amount of cycles that are typically available for the released branches. i.e. I don't have runtime's available for every old release, so I rely on the users of those branches to report runtime issues after a change is 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
|
|
Re: Loading the module xen-gntdev on boot
Bertrand Marquis
Hi Bruce,
On 24 Mar 2022, at 13:06, Bruce Ashfield <bruce.ashfield@...> wrote:Sorry if my tone did not sound right, that was not my intention. I just wanted to understand what we should expect and hence what we should do in stable branches. Thanks. I think that would be good to be clear on what can be expected in a stable branch after the release for meta-virtualization. That could also help me to know what I should consider critical ornate and fix in stable releases. Kind regards Bertrand
|
|
Re: [PATCH V2] ceph: set CXXFLAGS and CFLAGS
Bruce Ashfield
thanks for V2!
toggle quoted messageShow quoted text
I forgot that I was testing with v1, and pushed it instead of this .. but since the functional change is the same, we'll leave it as-is. Cheers, Bruce In message: [meta-virtualization][PATCH V2] ceph: set CXXFLAGS and CFLAGS on 22/03/2022 sakib.sajal@... wrote:
In oe-core, the commit:
|
|
Re: Loading the module xen-gntdev on boot
Bruce Ashfield
On Thu, Mar 24, 2022 at 4:42 AM Bertrand Marquis <Bertrand.Marquis@...> wrote: Hi, Broken is a far too dramatic description of this issue. Also, when talking about support, we are talking about OEcore / Yocto Project support. The rest of the layers in the ecosystem do this sort of support as best effort. So a gentle reminder that we should all be careful with expectations and the tone of our communications. Anyway the fix is simple and the person is unblocked so it will be easy for the next one to solve it, so my argumentation is more in general around what should the end of support date mean for users. I have queued the change, but my reminder about expectations stands. 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
|
|
Re: Loading the module xen-gntdev on boot
Bertrand Marquis
Hi,
On 23 Mar 2022, at 22:17, Bruce Ashfield via lists.yoctoproject.org <bruce.ashfield=gmail.com@...> wrote:The branch is still supported at the moment and is broken. I do not think it is right to say “we will stop fixing issues a bit before the branch is out of support” as this is equivalent to reducing the support time. Out of support is more something which should be works but does not get any update or security fixes, here we have something broken while under support. Anyway the fix is simple and the person is unblocked so it will be easy for the next one to solve it, so my argumentation is more in general around what should the end of support date mean for users. Cheers Bertrand
|
|
Re: Loading the module xen-gntdev on boot
Bruce Ashfield
On Wed, Mar 23, 2022 at 6:30 AM Richard Purdie <richard.purdie@...> wrote: On Wed, 2022-03-23 at 08:38 +0000, Bertrand Marquis wrote: Agreed. I don't like to leave things broken either .. but we really shouldn't encourage people to keep using the branches that are going out of support. If I fix this one, there will be other issues that aren't fixed/patched in the future (and potentially security issues) .. so I'm leaning towards leaving this not backported. Bruce https://wiki.yoctoproject.org/wiki/Releases - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II
|
|
Re: [PATCH] python3-sphinx: Drop as newer recipe merged to OE-Core
Bruce Ashfield
Unfortunately not. I have a dependency on this version, which means i need to fork the recipe, create a version specific one and then do some regression testing. I'm tied up with a few other high priority issues .. and the merge without realizing that this recipe was in meta-virt, does not make an emergency on my part. Bruce
On Wed, Mar 23, 2022 at 3:30 PM Jon Mason <jdmason@...> wrote: Good fix. Please pull this in, as it is causing autobuilder errors --
- Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II
|
|
Re: [PATCH] python3-sphinx: Drop as newer recipe merged to OE-Core
Jon Mason
Good fix. Please pull this in, as it is causing autobuilder errors
See https://autobuilder.yoctoproject.org/typhoon/#/builders/121/builds/601/steps/23/logs/stdio Thanks, Jon On Wed, Mar 23, 2022 at 1:33 PM Richard Purdie <richard.purdie@...> wrote:
|
|
[PATCH] python3-sphinx: Drop as newer recipe merged to OE-Core
Richard Purdie
A newer version of this was merged to OE-Core and there shouldn't be a hard
version dependency in meta-virtualization so this can be droped from here. Signed-off-by: Richard Purdie <richard.purdie@...> --- recipes-devtools/python/python3-sphinx_4.2.0.bb | 11 ----------- 1 file changed, 11 deletions(-) delete mode 100644 recipes-devtools/python/python3-sphinx_4.2.0.bb diff --git a/recipes-devtools/python/python3-sphinx_4.2.0.bb b/recipes-devtools/python/python3-sphinx_4.2.0.bb deleted file mode 100644 index 01f36ea..0000000 --- a/recipes-devtools/python/python3-sphinx_4.2.0.bb +++ /dev/null @@ -1,11 +0,0 @@ -DESCRIPTION = "Python documentation generator" -HOMEPAGE = "http://sphinx-doc.org/" -SECTION = "devel/python" -LICENSE = "BSD-2-Clause & BSD-3-Clause & MIT" -LIC_FILES_CHKSUM = "file://LICENSE;md5=82cc7d23060a75a07b820eaaf75abecf" - -PYPI_PACKAGE = "Sphinx" - -SRC_URI[sha256sum] = "94078db9184491e15bce0a56d9186e0aec95f16ac20b12d00e06d4e36f1058a6" - -inherit setuptools3 pypi -- 2.32.0
|
|
Re: Loading the module xen-gntdev on boot
Richard Purdie
On Wed, 2022-03-23 at 08:38 +0000, Bertrand Marquis wrote:
Hi Paulohardknott is not LTS, it is about to go EOL.On 22 Mar 2022, at 16:52, Paulo Sherring via lists.yoctoproject.org <pauloasherring=gmail.com@...> wrote:Great thanks for the info. https://wiki.yoctoproject.org/wiki/Releases Cheers, Richard
|
|
Re: Loading the module xen-gntdev on boot
Bertrand Marquis
Hi Bruce
On 23 Mar 2022, at 09:38, Bertrand Marquis via lists.yoctoproject.org <bertrand.marquis=arm.com@...> wrote:In fact hardnott is not LTS (my mistake) but as support is broken it would still make sense to backport this I think. Cheers Bertrand
|
|
Re: Loading the module xen-gntdev on boot
Bertrand Marquis
Hi Paulo
On 22 Mar 2022, at 16:52, Paulo Sherring via lists.yoctoproject.org <pauloasherring=gmail.com@...> wrote:Great thanks for the info. @Bruce: Maybe it would make sense to backport this as hardknott is LTS ? If yes, please ping me if you need support to do it. Cheers Bertrand
|
|