Date   

[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:
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:
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
```


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.

In this case it seems that thev1.22.6+k3s1 tag is pointing to 3228d9cb9a4727d48f60de4f1ab472f7c50df904.

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

 

Cheers,

Diego

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

 
Unfortunately, I have zero knowledge in go and I have no idea how I could fix this. 

Diego Sueiro
Staff Software Developer – ARM – Automotive and Industrial Solutions (CE-OSS)



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



--
- 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:
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
```


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.

In this case it seems that thev1.22.6+k3s1 tag is pointing to 3228d9cb9a4727d48f60de4f1ab472f7c50df904.

Cheers,

Diego

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

 
Unfortunately, I have zero knowledge in go and I have no idea how I could fix this. 

Diego Sueiro
Staff Software Developer – ARM – Automotive and Industrial Solutions (CE-OSS)



--
- 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:
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
```


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

 
Unfortunately, I have zero knowledge in go and I have no idea how I could fix this. 

Diego Sueiro
Staff Software Developer – ARM – Automotive and Industrial Solutions (CE-OSS)



--
- 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
Staff Software Developer – ARM – Automotive and Industrial Solutions (CE-OSS)


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:
        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






--
- 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,

> On 24 Mar 2022, at 13:06, Bruce Ashfield <bruce.ashfield@...> wrote:
>
>
>
> On Thu, Mar 24, 2022 at 4:42 AM Bertrand Marquis <Bertrand.Marquis@...> wrote:
> Hi,
>
> > On 23 Mar 2022, at 22:17, Bruce Ashfield via lists.yoctoproject.org <bruce.ashfield=gmail.com@...> wrote:
> >
> >
> >
> > 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:
> > > Hi Paulo
> > >
> > > > On 22 Mar 2022, at 16:52, Paulo Sherring via lists.yoctoproject.org <pauloasherring=gmail.com@...> wrote:
> > > >
> > > > Hello Diego, Bertrand,
> > > > Just confirmed that by bringing these changes into hardknott, the
> > > > modules get correctly probed on bootup.
> > >
> > > 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.
> >
> > hardknott is not LTS, it is about to go EOL.
> >
> >
> > 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.
>
> 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.
>
>
> 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.
>

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.


> 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.

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.

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

 

Kind regards
Bertrand

>
> Bruce
>

>
> Cheers
> Bertrand
>
> >
> > Bruce
> >
> > 
> > https://wiki.yoctoproject.org/wiki/Releases
> >
> > Cheers,
> >
> > Richard
> >
> >
> >
> > --
> > - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end
> > - "Use the force Harry" - Gandalf, Star Trek II
> >
> >
> >
>
>
>
> --
> - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end
> - "Use the force Harry" - Gandalf, Star Trek II



--
- 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:



On Thu, Mar 24, 2022 at 4:42 AM Bertrand Marquis <Bertrand.Marquis@...> wrote:
Hi,

On 23 Mar 2022, at 22:17, Bruce Ashfield via lists.yoctoproject.org <bruce.ashfield=gmail.com@...> wrote:



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:
Hi Paulo

On 22 Mar 2022, at 16:52, Paulo Sherring via lists.yoctoproject.org <pauloasherring=gmail.com@...> wrote:

Hello Diego, Bertrand,
Just confirmed that by bringing these changes into hardknott, the
modules get correctly probed on bootup.
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.
hardknott is not LTS, it is about to go EOL.


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.
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.


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.
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.


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.
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


Bruce



Cheers
Bertrand


Bruce


https://wiki.yoctoproject.org/wiki/Releases

Cheers,

Richard



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




--
- 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 V2] ceph: set CXXFLAGS and CFLAGS

Bruce Ashfield
 

thanks for V2!

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:
a83623a54a Revert "cmake.bbclass: Set CXXFLAGS and CFLAGS"

drops compiler flags overrides for all cmake-based recipes,
causing the ceph compile to fail with the error:
ld: cannot find crtn.o: No such file or directory

collect2: error: ld returned 1 exit status

Add the override back for ceph to fix the build error.

Signed-off-by: Sakib Sajal <sakib.sajal@...>
---
recipes-extended/ceph/ceph_15.2.15.bb | 3 +++
1 file changed, 3 insertions(+)

diff --git a/recipes-extended/ceph/ceph_15.2.15.bb b/recipes-extended/ceph/ceph_15.2.15.bb
index c72953a..17dbcf3 100644
--- a/recipes-extended/ceph/ceph_15.2.15.bb
+++ b/recipes-extended/ceph/ceph_15.2.15.bb
@@ -66,6 +66,9 @@ EXTRA_OECMAKE = "-DWITH_MANPAGE=OFF \
-DWITH_REENTRANT_STRSIGNAL=ON \
"

+CXXFLAGS += "${HOST_CC_ARCH} ${TOOLCHAIN_OPTIONS}"
+CFLAGS += "${HOST_CC_ARCH} ${TOOLCHAIN_OPTIONS}"
+
export STAGING_DIR_HOST

do_configure:prepend () {
--
2.25.1



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,

> On 23 Mar 2022, at 22:17, Bruce Ashfield via lists.yoctoproject.org <bruce.ashfield=gmail.com@...> wrote:
>
>
>
> 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:
> > Hi Paulo
> >
> > > On 22 Mar 2022, at 16:52, Paulo Sherring via lists.yoctoproject.org <pauloasherring=gmail.com@...> wrote:
> > >
> > > Hello Diego, Bertrand,
> > > Just confirmed that by bringing these changes into hardknott, the
> > > modules get correctly probed on bootup.
> >
> > 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.
>
> hardknott is not LTS, it is about to go EOL.
>
>
> 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.

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.


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

 

Cheers
Bertrand

>
> Bruce
>

> https://wiki.yoctoproject.org/wiki/Releases
>
> Cheers,
>
> Richard
>
>
>
> --
> - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end
> - "Use the force Harry" - Gandalf, Star Trek II
>
>
>



--
- 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:



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:
Hi Paulo

On 22 Mar 2022, at 16:52, Paulo Sherring via lists.yoctoproject.org <pauloasherring=gmail.com@...> wrote:

Hello Diego, Bertrand,
Just confirmed that by bringing these changes into hardknott, the
modules get correctly probed on bootup.
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.
hardknott is not LTS, it is about to go EOL.


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.
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


Bruce


https://wiki.yoctoproject.org/wiki/Releases

Cheers,

Richard



--
- 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

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:
> Hi Paulo
>
> > On 22 Mar 2022, at 16:52, Paulo Sherring via lists.yoctoproject.org <pauloasherring=gmail.com@...> wrote:
> >
> > Hello Diego, Bertrand,
> > Just confirmed that by bringing these changes into hardknott, the
> > modules get correctly probed on bootup.
>
> 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.

hardknott is not LTS, it is about to go EOL.


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

Cheers,

Richard



--
- 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
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:
>
> 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
>
>
>
>





--
- 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:

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




[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 Paulo

On 22 Mar 2022, at 16:52, Paulo Sherring via lists.yoctoproject.org <pauloasherring=gmail.com@...> wrote:

Hello Diego, Bertrand,
Just confirmed that by bringing these changes into hardknott, the
modules get correctly probed on bootup.
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.
hardknott is not LTS, it is about to go EOL.

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:

Hi Paulo

On 22 Mar 2022, at 16:52, Paulo Sherring via lists.yoctoproject.org <pauloasherring=gmail.com@...> wrote:

Hello Diego, Bertrand,
Just confirmed that by bringing these changes into hardknott, the
modules get correctly probed on bootup.
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.
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


Cheers
Bertrand


The xen.conf content, just for completeness:
xen-evtchn
xen-gntdev
xen-gntalloc
xen-blkback
xen-netback
xen-pciback
evtchn
gntdev
netbk
blkbk
xen-scsibk
usbbk
pciback

Thanks for the support :)
Kind regards, Paulo.

On Tue, Mar 22, 2022 at 3:30 PM Diego Sueiro <Diego.Sueiro@...> wrote:

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

You might need to backport this to hardknott as well.

--
Diego Sueiro
Staff Software Developer - Automotive and Industrial Solutions (CE-OSS)

-----Original Message-----
From: meta-virtualization@... <meta-
virtualization@...> On Behalf Of Bertrand Marquis via
lists.yoctoproject.org
Sent: 22 March 2022 15:23
To: Paulo Sherring <pauloasherring@...>
Cc: meta-virtualization@...; nd <nd@...>; Bruce
Ashfield <bruce.ashfield@...>
Subject: Re: [meta-virtualization] Loading the module xen-gntdev on boot

Hi Paulo,

On 22 Mar 2022, at 16:01, Paulo Sherring <pauloasherring@...>
wrote:

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 the kernel instead
of the xen binary).
This should not impact the module loading.


So, I am launching it "by hand":

./tmp/work/x86_64-linux/qemu-helper-native/1.0-r1/recipe-sysroot-nativ
e/usr/bin/qemu-system-aarch64
\
-nographic \
-machine virt,gic-version=3 \
-machine virtualization=true \
-cpu cortex-a57 -smp 4 -m 4G -machine type=virt \ -bios
./tmp/deploy/images/qemuarm64/u-boot-qemuarm64.bin \ -device
loader,file=./tmp/deploy/images/qemuarm64/xen-
qemuarm64,addr=0x4500000
0
\
-device
loader,file=./tmp/deploy/images/qemuarm64/Image--
5.10.103+git0+792f127
2dd_3aab5bb12b-r0-qemuarm64-20220317212819.bin,addr=0x46000000
\
-device
loader,file=./tmp/deploy/images/qemuarm64/Image--
5.10.103+git0+792f127
2dd_3aab5bb12b-r0-qemuarm64-20220317212819.bin,addr=0x48000000
\
-device loader,file=./virt.dtb,addr=0x44000000 \ -drive
id=disk0,file=./tmp/deploy/images/qemuarm64/xen-image-minimal-
qemuarm6
4.ext4,if=none,index=0,format=raw
\
-device virtio-blk-device,drive=disk0 \

And then stop it on u-boot, and setup the fdt:
## Dom0 only:
fdt addr 0x44000000
fdt resize
fdt set /chosen \#address-cells <1>
fdt set /chosen \#size-cells <1>
fdt set /chosen xen,xen-bootargs "dom0_mem=512M"
fdt mknod /chosen module@0
fdt set /chosen/module@0 compatible "xen,linux-zimage" "xen,multiboot-
module"
fdt set /chosen/module@0 reg <0x46000000 0x1373a00> fdt set
/chosen/module@0 bootargs "dom0_mem=512M root=/dev/vda rw
earlyprintk=serial,ttyAMA0 console=ttyAMA0,115200n8 earlycon=xenboot"
booti 0x45000000 - 0x44000000

Please find also some more information below:

On Tue, Mar 22, 2022 at 12:59 PM Bertrand Marquis
<Bertrand.Marquis@...> wrote:

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 Xen.
That was just me being silly. I was looking into xen_git.bb which
clearly is not the preferred provider. I am in fact using Xen 4.14, as
you pointed out. Sorry for the mistake.
From what I see modules to load are in a xen.conf in modules-load.d
generated by Xen tools compilation.
Gntdev is properly listed in the current xen source tree as one of the
default modules to actually load on boot.

Can you check the content of modules-load.d/xen.conf (somewhere in /etc
in your dom0 roots) ?
I have nothing there. But, I did have two hits when searching the rootfs:
/etc/tmpfiles.d/xen.conf
/lib/systemd/modules-load.d/xen.conf
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 there.

If yes then this is a systemd issue, if not this is a Xen issue which appear to be
solved in xen master and I will have to check in the 4.14 version used by Yocto
LTS.


Not sure if there there is some sort of startup script that was
supposed to move around these files or even if
systemd-modules-load.service would be supposed to be looking
elsewhere.
No the lib one is the right one for systemd.

Cheers
Bertrand

It could be that this was actually missing in the xen release you are building
or that systemd is not actually loading modules listed there.

Cheers
Bertrand
Cheers, Paulo.



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:

Hello Diego, Bertrand,
Just confirmed that by bringing these changes into hardknott, the
modules get correctly probed on bootup.
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


The xen.conf content, just for completeness:
xen-evtchn
xen-gntdev
xen-gntalloc
xen-blkback
xen-netback
xen-pciback
evtchn
gntdev
netbk
blkbk
xen-scsibk
usbbk
pciback

Thanks for the support :)
Kind regards, Paulo.

On Tue, Mar 22, 2022 at 3:30 PM Diego Sueiro <Diego.Sueiro@...> wrote:

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

You might need to backport this to hardknott as well.

--
Diego Sueiro
Staff Software Developer - Automotive and Industrial Solutions (CE-OSS)

-----Original Message-----
From: meta-virtualization@... <meta-
virtualization@...> On Behalf Of Bertrand Marquis via
lists.yoctoproject.org
Sent: 22 March 2022 15:23
To: Paulo Sherring <pauloasherring@...>
Cc: meta-virtualization@...; nd <nd@...>; Bruce
Ashfield <bruce.ashfield@...>
Subject: Re: [meta-virtualization] Loading the module xen-gntdev on boot

Hi Paulo,

On 22 Mar 2022, at 16:01, Paulo Sherring <pauloasherring@...>
wrote:

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 the kernel instead
of the xen binary).
This should not impact the module loading.


So, I am launching it "by hand":

./tmp/work/x86_64-linux/qemu-helper-native/1.0-r1/recipe-sysroot-nativ
e/usr/bin/qemu-system-aarch64
\
-nographic \
-machine virt,gic-version=3 \
-machine virtualization=true \
-cpu cortex-a57 -smp 4 -m 4G -machine type=virt \ -bios
./tmp/deploy/images/qemuarm64/u-boot-qemuarm64.bin \ -device
loader,file=./tmp/deploy/images/qemuarm64/xen-
qemuarm64,addr=0x4500000
0
\
-device
loader,file=./tmp/deploy/images/qemuarm64/Image--
5.10.103+git0+792f127
2dd_3aab5bb12b-r0-qemuarm64-20220317212819.bin,addr=0x46000000
\
-device
loader,file=./tmp/deploy/images/qemuarm64/Image--
5.10.103+git0+792f127
2dd_3aab5bb12b-r0-qemuarm64-20220317212819.bin,addr=0x48000000
\
-device loader,file=./virt.dtb,addr=0x44000000 \ -drive
id=disk0,file=./tmp/deploy/images/qemuarm64/xen-image-minimal-
qemuarm6
4.ext4,if=none,index=0,format=raw
\
-device virtio-blk-device,drive=disk0 \

And then stop it on u-boot, and setup the fdt:
## Dom0 only:
fdt addr 0x44000000
fdt resize
fdt set /chosen \#address-cells <1>
fdt set /chosen \#size-cells <1>
fdt set /chosen xen,xen-bootargs "dom0_mem=512M"
fdt mknod /chosen module@0
fdt set /chosen/module@0 compatible "xen,linux-zimage" "xen,multiboot-
module"
fdt set /chosen/module@0 reg <0x46000000 0x1373a00> fdt set
/chosen/module@0 bootargs "dom0_mem=512M root=/dev/vda rw
earlyprintk=serial,ttyAMA0 console=ttyAMA0,115200n8 earlycon=xenboot"
booti 0x45000000 - 0x44000000

Please find also some more information below:

On Tue, Mar 22, 2022 at 12:59 PM Bertrand Marquis
<Bertrand.Marquis@...> wrote:

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 Xen.
That was just me being silly. I was looking into xen_git.bb which
clearly is not the preferred provider. I am in fact using Xen 4.14, as
you pointed out. Sorry for the mistake.
From what I see modules to load are in a xen.conf in modules-load.d
generated by Xen tools compilation.
Gntdev is properly listed in the current xen source tree as one of the
default modules to actually load on boot.

Can you check the content of modules-load.d/xen.conf (somewhere in /etc
in your dom0 roots) ?
I have nothing there. But, I did have two hits when searching the rootfs:
/etc/tmpfiles.d/xen.conf
/lib/systemd/modules-load.d/xen.conf
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 there.

If yes then this is a systemd issue, if not this is a Xen issue which appear to be
solved in xen master and I will have to check in the 4.14 version used by Yocto
LTS.


Not sure if there there is some sort of startup script that was
supposed to move around these files or even if
systemd-modules-load.service would be supposed to be looking
elsewhere.
No the lib one is the right one for systemd.

Cheers
Bertrand

It could be that this was actually missing in the xen release you are building
or that systemd is not actually loading modules listed there.

Cheers
Bertrand
Cheers, Paulo.

421 - 440 of 7539