Date   

[PATCH 3/3] xen: Remove 4.14 recipes and related patches

Michal Orzel
 

We shall only have recipes for the last two stable releases, thus
get rid of the 4.14 recipes and the corresponding patches.

Signed-off-by: Michal Orzel <michal.orzel@...>
---
...-stand-alone-set-of-headers-Xen-4.14.patch | 178 ------------------
...ython-pygrub-pass-DISTUTILS-xen-4.14.patch | 66 -------
...d-firmware-as-ffreestanding-Xen-4.14.patch | 83 --------
recipes-extended/xen/xen-tools_4.14.bb | 21 ---
recipes-extended/xen/xen_4.14.bb | 19 --
5 files changed, 367 deletions(-)
delete mode 100644 recipes-extended/xen/files/0001-firmware-provide-a-stand-alone-set-of-headers-Xen-4.14.patch
delete mode 100644 recipes-extended/xen/files/0001-python-pygrub-pass-DISTUTILS-xen-4.14.patch
delete mode 100644 recipes-extended/xen/files/0001-tools-firmware-Build-firmware-as-ffreestanding-Xen-4.14.patch
delete mode 100644 recipes-extended/xen/xen-tools_4.14.bb
delete mode 100644 recipes-extended/xen/xen_4.14.bb

diff --git a/recipes-extended/xen/files/0001-firmware-provide-a-stand-alone-set-of-headers-Xen-4.14.patch b/recipes-extended/xen/files/0001-firmware-provide-a-stand-alone-set-of-headers-Xen-4.14.patch
deleted file mode 100644
index 7b062b7..0000000
--- a/recipes-extended/xen/files/0001-firmware-provide-a-stand-alone-set-of-headers-Xen-4.14.patch
+++ /dev/null
@@ -1,178 +0,0 @@
-From 73b13705af7c3bb8fdf11932eb68788d090a443f Mon Sep 17 00:00:00 2001
-From: =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@...>
-Date: Thu, 4 Mar 2021 16:49:00 +0100
-Subject: [PATCH] firmware: provide a stand alone set of headers
-MIME-Version: 1.0
-Content-Type: text/plain; charset=UTF-8
-Content-Transfer-Encoding: 8bit
-
-The current build of the firmware relies on having 32bit compatible
-headers installed in order to build some of the 32bit firmware.
-Usually this can be solved by using the -ffreestanding compiler option
-which drops the usage of the system headers in favor of a private set
-of freestanding headers provided by the compiler itself that are not
-tied to libc.
-
-However such option is broken at least in the gcc compiler provided in
-Alpine Linux, as the system include path (ie: /usr/include) takes
-precedence over the gcc private include path:
-
-#include <...> search starts here:
- /usr/include
- /usr/lib/gcc/x86_64-alpine-linux-musl/10.2.1/include
-
-And the headers in /usr/include are exclusively 64bit.
-
-Since -ffreestanding is currently broken on at least that distro, and
-for resilience against future compilers also having the option broken
-provide a set of stand alone 32bit headers required for the firmware
-build.
-
-Signed-off-by: Roger Pau Monné <roger.pau@...>
-Reviewed-by: Jan Beulich <jbeulich@...>
-Release-Acked-by: Ian Jackson <iwj@...>
-Applied to Xen 4.14 by: Christopher Clark <christopher.w.clark@...>
----
- tools/firmware/Rules.mk | 13 +++++++
- tools/firmware/include/stdarg.h | 10 +++++
- tools/firmware/include/stdbool.h | 9 +++++
- tools/firmware/include/stddef.h | 10 +++++
- tools/firmware/include/stdint.h | 39 +++++++++++++++++++
- tools/firmware/rombios/32bit/rombios_compat.h | 4 +-
- 6 files changed, 82 insertions(+), 3 deletions(-)
- create mode 100644 tools/firmware/include/stdarg.h
- create mode 100644 tools/firmware/include/stdbool.h
- create mode 100644 tools/firmware/include/stddef.h
- create mode 100644 tools/firmware/include/stdint.h
-
-diff --git a/tools/firmware/include/stdarg.h b/tools/firmware/include/stdarg.h
-new file mode 100644
-index 0000000000..c5e3761cd2
---- /dev/null
-+++ b/tools/firmware/include/stdarg.h
-@@ -0,0 +1,10 @@
-+#ifndef _STDARG_H_
-+#define _STDARG_H_
-+
-+typedef __builtin_va_list va_list;
-+#define va_copy(dest, src) __builtin_va_copy(dest, src)
-+#define va_start(ap, last) __builtin_va_start(ap, last)
-+#define va_end(ap) __builtin_va_end(ap)
-+#define va_arg __builtin_va_arg
-+
-+#endif
-diff --git a/tools/firmware/include/stdbool.h b/tools/firmware/include/stdbool.h
-new file mode 100644
-index 0000000000..0cf76b106c
---- /dev/null
-+++ b/tools/firmware/include/stdbool.h
-@@ -0,0 +1,9 @@
-+#ifndef _STDBOOL_H_
-+#define _STDBOOL_H_
-+
-+#define bool _Bool
-+#define true 1
-+#define false 0
-+#define __bool_true_false_are_defined 1
-+
-+#endif
-diff --git a/tools/firmware/include/stddef.h b/tools/firmware/include/stddef.h
-new file mode 100644
-index 0000000000..c7f974608a
---- /dev/null
-+++ b/tools/firmware/include/stddef.h
-@@ -0,0 +1,10 @@
-+#ifndef _STDDEF_H_
-+#define _STDDEF_H_
-+
-+typedef __SIZE_TYPE__ size_t;
-+
-+#define NULL ((void*)0)
-+
-+#define offsetof(t, m) __builtin_offsetof(t, m)
-+
-+#endif
-diff --git a/tools/firmware/include/stdint.h b/tools/firmware/include/stdint.h
-new file mode 100644
-index 0000000000..16a0b6de19
---- /dev/null
-+++ b/tools/firmware/include/stdint.h
-@@ -0,0 +1,39 @@
-+#ifndef _STDINT_H_
-+#define _STDINT_H_
-+
-+#if defined(__LP64__) || defined(__P64__)
-+#error "32bit only header"
-+#endif
-+
-+typedef unsigned char uint8_t;
-+typedef signed char int8_t;
-+
-+typedef unsigned short uint16_t;
-+typedef signed short int16_t;
-+
-+typedef unsigned int uint32_t;
-+typedef signed int int32_t;
-+
-+typedef unsigned long long uint64_t;
-+typedef signed long long int64_t;
-+
-+#define INT8_MIN (-0x7f-1)
-+#define INT16_MIN (-0x7fff-1)
-+#define INT32_MIN (-0x7fffffff-1)
-+#define INT64_MIN (-0x7fffffffffffffffll-1)
-+
-+#define INT8_MAX 0x7f
-+#define INT16_MAX 0x7fff
-+#define INT32_MAX 0x7fffffff
-+#define INT64_MAX 0x7fffffffffffffffll
-+
-+#define UINT8_MAX 0xff
-+#define UINT16_MAX 0xffff
-+#define UINT32_MAX 0xffffffffu
-+#define UINT64_MAX 0xffffffffffffffffull
-+
-+typedef uint32_t uintptr_t;
-+
-+#define UINTPTR_MAX UINT32_MAX
-+
-+#endif
-diff --git a/tools/firmware/rombios/32bit/rombios_compat.h b/tools/firmware/rombios/32bit/rombios_compat.h
-index 3fe7d67721..8ba4c17ffd 100644
---- a/tools/firmware/rombios/32bit/rombios_compat.h
-+++ b/tools/firmware/rombios/32bit/rombios_compat.h
-@@ -8,9 +8,7 @@
-
- #define ADDR_FROM_SEG_OFF(seg, off) (void *)((((uint32_t)(seg)) << 4) + (off))
-
--typedef unsigned char uint8_t;
--typedef unsigned short int uint16_t;
--typedef unsigned int uint32_t;
-+#include <stdint.h>
-
- typedef uint8_t Bit8u;
- typedef uint16_t Bit16u;
-diff --git a/tools/firmware/Rules.mk b/tools/firmware/Rules.mk
-index 26bbddccd4..cb388b7011 100644
---- a/tools/firmware/Rules.mk
-+++ b/tools/firmware/Rules.mk
-@@ -17,3 +17,16 @@ $(call cc-options-add,CFLAGS,CC,$(EMBEDDED_EXTRA_CFLAGS))
-
- # Extra CFLAGS suitable for an embedded type of environment.
- CFLAGS += -fno-builtin -msoft-float
-+
-+# Use our own set of stand alone headers to build firmware.
-+#
-+# Ideally using -ffreestanding should be enough, but that relies on the
-+# compiler having the right order for include paths (ie: compiler private
-+# headers before system ones) or the libc headers having proper arch-agnostic
-+# freestanding support. This is not the case in Alpine at least which searches
-+# system headers before compiler ones and has arch-specific libc headers. This
-+# has been reported upstream:
-+# https://gitlab.alpinelinux.org/alpine/aports/-/issues/12477
-+# In the meantime (and for resilience against broken systems) use our own set
-+# of headers that provide what's needed for the firmware build.
-+CFLAGS += -nostdinc -I$(XEN_ROOT)/tools/firmware/include
---
-2.25.1
-
diff --git a/recipes-extended/xen/files/0001-python-pygrub-pass-DISTUTILS-xen-4.14.patch b/recipes-extended/xen/files/0001-python-pygrub-pass-DISTUTILS-xen-4.14.patch
deleted file mode 100644
index f0688fd..0000000
--- a/recipes-extended/xen/files/0001-python-pygrub-pass-DISTUTILS-xen-4.14.patch
+++ /dev/null
@@ -1,66 +0,0 @@
-From d79dcc2002008c58683de82f06c168d6eea57991 Mon Sep 17 00:00:00 2001
-From: Maciej Pijanowski <maciej.pijanowski@...>
-Date: Fri, 19 Oct 2018 11:01:37 +0200
-Subject: [PATCH] python,pygrub: pass DISTUTILS env vars as setup.py args
-
-Allow to respect the target install dir (PYTHON_SITEPACKAGES_DIR)
-as well as other parameters set by the OpenEmbedded build system.
-This is especially useful when the target libdir is not the default one
-(/usr/lib), but for example /usr/lib64.
-
-Signed-off-by: Maciej Pijanowski <maciej.pijanowski@...>
-
-Forward-ported to Xen 4.12.0
-Signed-off-by: Christopher Clark <christopher.clark6@...>
-
-Modified to support pygrub installation with python 3
-Signed-off-by: Christopher Clark <christopher.clark6@...>
-
-Forward-ported to Xen 4.14.0
-Signed-off-by: Christopher Clark <christopher.clark6@...>
-diff --git a/tools/pygrub/Makefile b/tools/pygrub/Makefile
-index 3063c49..513314b 100644
---- a/tools/pygrub/Makefile
-+++ b/tools/pygrub/Makefile
-@@ -10,14 +10,17 @@ INSTALL_LOG = build/installed_files.txt
- all: build
- .PHONY: build
- build:
-- CC="$(CC)" CFLAGS="$(PY_CFLAGS)" LDFLAGS="$(PY_LDFLAGS)" $(PYTHON) setup.py build
-+ CC="$(CC)" CFLAGS="$(PY_CFLAGS)" LDFLAGS="$(PY_LDFLAGS)" $(PYTHON) setup.py build $(DISTUTILS_BUILD_ARGS)
-
- .PHONY: install
- install: all
- $(INSTALL_DIR) $(DESTDIR)/$(bindir)
- CC="$(CC)" CFLAGS="$(PY_CFLAGS)" LDFLAGS="$(PY_LDFLAGS)" $(PYTHON) \
- setup.py install --record $(INSTALL_LOG) $(PYTHON_PREFIX_ARG) \
-- --root="$(DESTDIR)" --install-scripts=$(LIBEXEC_BIN) --force
-+ --root="$(DESTDIR)" --install-scripts=$(LIBEXEC_BIN) --force \
-+ $(DISTUTILS_INSTALL_ARGS)
-+ rm -f $(DESTDIR)/$(LIBEXEC_BIN)/pygrub
-+ $(INSTALL_PYTHON_PROG) src/pygrub $(DESTDIR)/$(LIBEXEC_BIN)/pygrub
- set -e; if [ $(bindir) != $(LIBEXEC_BIN) -a \
- "`readlink -f $(DESTDIR)/$(bindir)`" != \
- "`readlink -f $(LIBEXEC_BIN)`" ]; then \
-diff --git a/tools/python/Makefile b/tools/python/Makefile
-index 541858e..4d4a344 100644
---- a/tools/python/Makefile
-+++ b/tools/python/Makefile
-@@ -10,7 +10,7 @@ INSTALL_LOG = build/installed_files.txt
-
- .PHONY: build
- build:
-- CC="$(CC)" CFLAGS="$(PY_CFLAGS)" $(PYTHON) setup.py build
-+ CC="$(CC)" CFLAGS="$(PY_CFLAGS)" $(PYTHON) setup.py build $(DISTUTILS_BUILD_ARGS)
-
- .PHONY: install
- install:
-@@ -18,7 +18,7 @@ install:
-
- CC="$(CC)" CFLAGS="$(PY_CFLAGS)" LDFLAGS="$(PY_LDFLAGS)" $(PYTHON) \
- setup.py install --record $(INSTALL_LOG) $(PYTHON_PREFIX_ARG) \
-- --root="$(DESTDIR)" --force
-+ --root="$(DESTDIR)" --force $(DISTUTILS_INSTALL_ARGS)
-
- $(INSTALL_PYTHON_PROG) scripts/convert-legacy-stream $(DESTDIR)$(LIBEXEC_BIN)
- $(INSTALL_PYTHON_PROG) scripts/verify-stream-v2 $(DESTDIR)$(LIBEXEC_BIN)
diff --git a/recipes-extended/xen/files/0001-tools-firmware-Build-firmware-as-ffreestanding-Xen-4.14.patch b/recipes-extended/xen/files/0001-tools-firmware-Build-firmware-as-ffreestanding-Xen-4.14.patch
deleted file mode 100644
index 001b196..0000000
--- a/recipes-extended/xen/files/0001-tools-firmware-Build-firmware-as-ffreestanding-Xen-4.14.patch
+++ /dev/null
@@ -1,83 +0,0 @@
-From 0eae016b6e3dce69e3fb86aca5c4f221591a2f12 Mon Sep 17 00:00:00 2001
-From: Andrew Cooper <andrew.cooper3@...>
-Date: Thu, 25 Feb 2021 19:15:08 +0000
-Subject: [PATCH] tools/firmware: Build firmware as -ffreestanding
-
-firmware should always have been -ffreestanding, as it doesn't execute in the
-host environment. -ffreestanding implies -fno-builtin, so replace the option.
-
-inttypes.h isn't a freestanding header, but the 32bitbios_support.c only wants
-the stdint.h types so switch to the more appropriate include.
-
-This removes the build time dependency on a 32bit libc just to compile the
-hvmloader and friends.
-
-Update README and the TravisCI configuration.
-
-Signed-off-by: Andrew Cooper <andrew.cooper3@...>
-Reviewed-by: Jan Beulich <jbeulich@...>
-Reviewed-by: Ian Jackson <iwj@...>
-Release-Acked-by: Ian Jackson <iwj@...>
-Applied to m-v Xen 4.14 series: Christopher Clark <christopher.w.clark@...>
----
- .travis.yml | 1 -
- README | 3 ---
- tools/firmware/Rules.mk | 2 +-
- tools/firmware/hvmloader/32bitbios_support.c | 2 +-
- 4 files changed, 2 insertions(+), 6 deletions(-)
-
-diff --git a/.travis.yml b/.travis.yml
-index 15ca9e9047..2362475f7a 100644
---- a/.travis.yml
-+++ b/.travis.yml
-@@ -58,7 +58,6 @@ addons:
- - acpica-tools
- - bin86
- - bcc
-- - libc6-dev-i386
- - libnl-3-dev
- - ocaml-nox
- - libfindlib-ocaml-dev
-diff --git a/README b/README
-index 6e15242ae1..8c99c30986 100644
---- a/README
-+++ b/README
-@@ -62,9 +62,6 @@ provided by your OS distributor:
- * GNU bison and GNU flex
- * GNU gettext
- * ACPI ASL compiler (iasl)
-- * Libc multiarch package (e.g. libc6-dev-i386 / glibc-devel.i686).
-- Required when building on a 64-bit platform to build
-- 32-bit components which are enabled on a default build.
-
- In addition to the above there are a number of optional build
- prerequisites. Omitting these will cause the related features to be
-diff --git a/tools/firmware/Rules.mk b/tools/firmware/Rules.mk
-index cb388b7011..9f78a7dec9 100644
---- a/tools/firmware/Rules.mk
-+++ b/tools/firmware/Rules.mk
-@@ -16,7 +16,7 @@ CFLAGS += -Werror
- $(call cc-options-add,CFLAGS,CC,$(EMBEDDED_EXTRA_CFLAGS))
-
- # Extra CFLAGS suitable for an embedded type of environment.
--CFLAGS += -fno-builtin -msoft-float
-+CFLAGS += -ffreestanding -msoft-float
-
- # Use our own set of stand alone headers to build firmware.
- #
-diff --git a/tools/firmware/hvmloader/32bitbios_support.c b/tools/firmware/hvmloader/32bitbios_support.c
-index 114135022e..ef681d4f57 100644
---- a/tools/firmware/hvmloader/32bitbios_support.c
-+++ b/tools/firmware/hvmloader/32bitbios_support.c
-@@ -20,7 +20,7 @@
- * this program; If not, see <http://www.gnu.org/licenses/>.
- */
-
--#include <inttypes.h>
-+#include <stdint.h>
- #include <elf.h>
- #ifdef __sun__
- #include <sys/machelf.h>
---
-2.25.1
-
diff --git a/recipes-extended/xen/xen-tools_4.14.bb b/recipes-extended/xen/xen-tools_4.14.bb
deleted file mode 100644
index 9d78e44..0000000
--- a/recipes-extended/xen/xen-tools_4.14.bb
+++ /dev/null
@@ -1,21 +0,0 @@
-# 4.14.3 release SHA
-SRCREV ?= "9f2b6c5ec2ded4c1caf149743e862c5f15d6d083"
-
-XEN_REL ?= "4.14"
-XEN_BRANCH ?= "stable-${XEN_REL}"
-
-SRC_URI = " \
- git://xenbits.xen.org/xen.git;branch=${XEN_BRANCH} \
- file://0001-python-pygrub-pass-DISTUTILS-xen-4.14.patch \
- file://0001-firmware-provide-a-stand-alone-set-of-headers-Xen-4.14.patch \
- file://0001-tools-firmware-Build-firmware-as-ffreestanding-Xen-4.14.patch \
- "
-
-LIC_FILES_CHKSUM ?= "file://COPYING;md5=419739e325a50f3d7b4501338e44a4e5"
-
-PV = "${XEN_REL}+stable${SRCPV}"
-
-S = "${WORKDIR}/git"
-
-require xen.inc
-require xen-tools.inc
diff --git a/recipes-extended/xen/xen_4.14.bb b/recipes-extended/xen/xen_4.14.bb
deleted file mode 100644
index 267db16..0000000
--- a/recipes-extended/xen/xen_4.14.bb
+++ /dev/null
@@ -1,19 +0,0 @@
-# 4.14.3 release SHA
-SRCREV ?= "9f2b6c5ec2ded4c1caf149743e862c5f15d6d083"
-
-XEN_REL ?= "4.14"
-XEN_BRANCH ?= "stable-${XEN_REL}"
-
-SRC_URI = " \
- git://xenbits.xen.org/xen.git;branch=${XEN_BRANCH} \
- file://0001-menuconfig-mconf-cfg-Allow-specification-of-ncurses-location.patch \
- "
-
-LIC_FILES_CHKSUM ?= "file://COPYING;md5=419739e325a50f3d7b4501338e44a4e5"
-
-PV = "${XEN_REL}+stable${SRCPV}"
-
-S = "${WORKDIR}/git"
-
-require xen.inc
-require xen-hypervisor.inc
--
2.25.1


[PATCH 2/3] xen: Add recipes for stable Xen 4.16 release and update master

Michal Orzel
 

Add recipes for Xen 4.16 release as, according to the documentation
we shall have recipes for the latest stable major version of Xen
before the next Yocto release. Bump PREFERED_VERSION to 4.16 as well.

Take the opportunity to update SRCREV of xen recipes for master
and bump XEN_REL version to 4.17 as this is the current development
version.

Signed-off-by: Michal Orzel <michal.orzel@...>
---
.../include/meta-virt-default-versions.inc | 4 ++--
recipes-extended/xen/xen-tools_4.16.bb | 19 +++++++++++++++++++
recipes-extended/xen/xen-tools_git.bb | 6 +++---
recipes-extended/xen/xen_4.16.bb | 19 +++++++++++++++++++
recipes-extended/xen/xen_git.bb | 6 +++---
5 files changed, 46 insertions(+), 8 deletions(-)
create mode 100644 recipes-extended/xen/xen-tools_4.16.bb
create mode 100644 recipes-extended/xen/xen_4.16.bb

diff --git a/conf/distro/include/meta-virt-default-versions.inc b/conf/di=
stro/include/meta-virt-default-versions.inc
index 8a2db70..b2ce021 100644
--- a/conf/distro/include/meta-virt-default-versions.inc
+++ b/conf/distro/include/meta-virt-default-versions.inc
@@ -1,4 +1,4 @@
# Meta-virtuailization PREFERED_VERSION
=20
-PREFERRED_VERSION_xen ?=3D "4.15+stable%"
-PREFERRED_VERSION_xen-tools ?=3D "4.15+stable%"
+PREFERRED_VERSION_xen ?=3D "4.16+stable%"
+PREFERRED_VERSION_xen-tools ?=3D "4.16+stable%"
diff --git a/recipes-extended/xen/xen-tools_4.16.bb b/recipes-extended/xe=
n/xen-tools_4.16.bb
new file mode 100644
index 0000000..4a07874
--- /dev/null
+++ b/recipes-extended/xen/xen-tools_4.16.bb
@@ -0,0 +1,19 @@
+# xen 4.16.0 release sha
+SRCREV ?=3D "b0b4661fa3cba995e433b94ea569c90f65a3e5fc"
+
+XEN_REL ?=3D "4.16"
+XEN_BRANCH ?=3D "stable-${XEN_REL}"
+
+SRC_URI =3D " \
+ git://xenbits.xen.org/xen.git;branch=3D${XEN_BRANCH} \
+ file://0001-python-pygrub-pass-DISTUTILS-xen-4.15.patch \
+ "
+
+LIC_FILES_CHKSUM ?=3D "file://COPYING;md5=3D419739e325a50f3d7b4501338e44=
a4e5"
+
+PV =3D "${XEN_REL}+stable${SRCPV}"
+
+S =3D "${WORKDIR}/git"
+
+require xen.inc
+require xen-tools.inc
diff --git a/recipes-extended/xen/xen-tools_git.bb b/recipes-extended/xen=
/xen-tools_git.bb
index e733f1d..a450a7d 100644
--- a/recipes-extended/xen/xen-tools_git.bb
+++ b/recipes-extended/xen/xen-tools_git.bb
@@ -1,7 +1,7 @@
-# master status on 2022-03-08
-SRCREV ?=3D "9d4a44380d273de22d5753883cbf5581795ff24d"
+# master status on 2022-04-05
+SRCREV ?=3D "14dd241aad8af447680ac73e8579990e2c09c1e7"
=20
-XEN_REL ?=3D "4.16"
+XEN_REL ?=3D "4.17"
XEN_BRANCH ?=3D "master"
=20
SRC_URI =3D " \
diff --git a/recipes-extended/xen/xen_4.16.bb b/recipes-extended/xen/xen_=
4.16.bb
new file mode 100644
index 0000000..be54d11
--- /dev/null
+++ b/recipes-extended/xen/xen_4.16.bb
@@ -0,0 +1,19 @@
+# xen 4.16.0 release sha
+SRCREV ?=3D "b0b4661fa3cba995e433b94ea569c90f65a3e5fc"
+
+XEN_REL ?=3D "4.16"
+XEN_BRANCH ?=3D "stable-${XEN_REL}"
+
+SRC_URI =3D " \
+ git://xenbits.xen.org/xen.git;branch=3D${XEN_BRANCH} \
+ file://0001-menuconfig-mconf-cfg-Allow-specification-of-ncurses-loca=
tion.patch \
+ "
+
+LIC_FILES_CHKSUM ?=3D "file://COPYING;md5=3D419739e325a50f3d7b4501338e44=
a4e5"
+
+PV =3D "${XEN_REL}+stable${SRCPV}"
+
+S =3D "${WORKDIR}/git"
+
+require xen.inc
+require xen-hypervisor.inc
diff --git a/recipes-extended/xen/xen_git.bb b/recipes-extended/xen/xen_g=
it.bb
index 2fbfb54..ebd1b76 100644
--- a/recipes-extended/xen/xen_git.bb
+++ b/recipes-extended/xen/xen_git.bb
@@ -1,7 +1,7 @@
-# master status on 2022-03-08
-SRCREV ?=3D "9d4a44380d273de22d5753883cbf5581795ff24d"
+# master status on 2022-04-05
+SRCREV ?=3D "14dd241aad8af447680ac73e8579990e2c09c1e7"
=20
-XEN_REL ?=3D "4.16"
+XEN_REL ?=3D "4.17"
XEN_BRANCH ?=3D "master"
=20
SRC_URI =3D " \
--=20
2.25.1


[PATCH 1/3] xen: Bump SRCREV of 4.15 recipes to 4.15.2

Michal Orzel
 

Bump SRCREV version of xen recipes to use the latest 4.15 release
which is 4.15.2.

Signed-off-by: Michal Orzel <michal.orzel@...>
---
recipes-extended/xen/xen-tools_4.15.bb | 4 ++--
recipes-extended/xen/xen_4.15.bb | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/recipes-extended/xen/xen-tools_4.15.bb b/recipes-extended/xe=
n/xen-tools_4.15.bb
index 840f162..5592dd7 100644
--- a/recipes-extended/xen/xen-tools_4.15.bb
+++ b/recipes-extended/xen/xen-tools_4.15.bb
@@ -1,5 +1,5 @@
-# xen 4.15.1 release sha
-SRCREV ?=3D "84fa99099b920f7bcde8899e1a9b756078719d7d"
+# xen 4.15.2 release sha
+SRCREV ?=3D "32dcef072fb37d432fd45c7916383472f3fcbc5e"
=20
XEN_REL ?=3D "4.15"
XEN_BRANCH ?=3D "stable-${XEN_REL}"
diff --git a/recipes-extended/xen/xen_4.15.bb b/recipes-extended/xen/xen_=
4.15.bb
index 1b87ae8..41023b2 100644
--- a/recipes-extended/xen/xen_4.15.bb
+++ b/recipes-extended/xen/xen_4.15.bb
@@ -1,5 +1,5 @@
-# xen 4.15.1 release sha
-SRCREV ?=3D "84fa99099b920f7bcde8899e1a9b756078719d7d"
+# xen 4.15.2 release sha
+SRCREV ?=3D "32dcef072fb37d432fd45c7916383472f3fcbc5e"
=20
XEN_REL ?=3D "4.15"
XEN_BRANCH ?=3D "stable-${XEN_REL}"
--=20
2.25.1


[PATCH 0/3] xen: Update recipes for xen and xen-tools

Michal Orzel
 

Before the next Yocto release, Xen recipes need to be updated.
This patch series:
- updates 4.15 recipes
- introduces 4.16 recipes
- removes 4.14 recipes

Michal Orzel (3):
xen: Bump SRCREV of 4.15 recipes to 4.15.2
xen: Add recipes for stable Xen 4.16 release and update master
xen: Remove 4.14 recipes and related patches

.../include/meta-virt-default-versions.inc | 4 +-
...-stand-alone-set-of-headers-Xen-4.14.patch | 178 ------------------
...ython-pygrub-pass-DISTUTILS-xen-4.14.patch | 66 -------
...d-firmware-as-ffreestanding-Xen-4.14.patch | 83 --------
recipes-extended/xen/xen-tools_4.14.bb | 21 ---
recipes-extended/xen/xen-tools_4.15.bb | 4 +-
recipes-extended/xen/xen-tools_4.16.bb | 19 ++
recipes-extended/xen/xen-tools_git.bb | 6 +-
recipes-extended/xen/xen_4.15.bb | 4 +-
.../xen/{xen_4.14.bb =3D> xen_4.16.bb} | 6 +-
recipes-extended/xen/xen_git.bb | 6 +-
11 files changed, 34 insertions(+), 363 deletions(-)
delete mode 100644 recipes-extended/xen/files/0001-firmware-provide-a-st=
and-alone-set-of-headers-Xen-4.14.patch
delete mode 100644 recipes-extended/xen/files/0001-python-pygrub-pass-DI=
STUTILS-xen-4.14.patch
delete mode 100644 recipes-extended/xen/files/0001-tools-firmware-Build-=
firmware-as-ffreestanding-Xen-4.14.patch
delete mode 100644 recipes-extended/xen/xen-tools_4.14.bb
create mode 100644 recipes-extended/xen/xen-tools_4.16.bb
rename recipes-extended/xen/{xen_4.14.bb =3D> xen_4.16.bb} (79%)

--=20
2.25.1


Re: [PATCH] virt-what: add new recipe

Bruce Ashfield
 

merged to master.

Bruce

In message: [meta-virtualization] [PATCH] virt-what: add new recipe
on 06/04/2022 Ross Burton wrote:

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-extended/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 = "Detect if we are running in a virtual machine"
+HOMEPAGE = "https://people.redhat.com/~rjones/virt-what/"
+LICENSE = "GPL-2.0-only"
+LIC_FILES_CHKSUM = "file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263"
+
+SRC_URI = "https://people.redhat.com/~rjones/virt-what/files/${BP}.tar.gz"
+SRC_URI[sha256sum] = "12cb455334aa4cfd53ab78f27e2252e94d1f676dd093f48327ed94d8080d1f7b"
+
+DEPENDS = "perl-native"
+
+inherit autotools
--
2.25.1



Re: [PATCH] virt-what: add new recipe

Ross Burton <ross@...>
 

It pokes at /proc, /sys, and cpuid, so it should be initsystem agnostic.

Ross

On Wed, 6 Apr 2022 at 17:45, Bruce Ashfield <bruce.ashfield@...> wrote:

I've always used systemd-detect-virt for this same use case.

Can you confirm if it works both on sysvinit and systemd based
init setups ?

Bruce

In message: [meta-virtualization] [PATCH] virt-what: add new recipe
on 06/04/2022 Ross Burton wrote:

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-extended/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 = "Detect if we are running in a virtual machine"
+HOMEPAGE = "https://people.redhat.com/~rjones/virt-what/"
+LICENSE = "GPL-2.0-only"
+LIC_FILES_CHKSUM = "file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263"
+
+SRC_URI = "https://people.redhat.com/~rjones/virt-what/files/${BP}.tar.gz"
+SRC_URI[sha256sum] = "12cb455334aa4cfd53ab78f27e2252e94d1f676dd093f48327ed94d8080d1f7b"
+
+DEPENDS = "perl-native"
+
+inherit autotools
--
2.25.1



Re: [PATCH] virt-what: add new recipe

Bruce Ashfield
 

I've always used systemd-detect-virt for this same use case.

Can you confirm if it works both on sysvinit and systemd based
init setups ?

Bruce

In message: [meta-virtualization] [PATCH] virt-what: add new recipe
on 06/04/2022 Ross Burton wrote:

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-extended/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 = "Detect if we are running in a virtual machine"
+HOMEPAGE = "https://people.redhat.com/~rjones/virt-what/"
+LICENSE = "GPL-2.0-only"
+LIC_FILES_CHKSUM = "file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263"
+
+SRC_URI = "https://people.redhat.com/~rjones/virt-what/files/${BP}.tar.gz"
+SRC_URI[sha256sum] = "12cb455334aa4cfd53ab78f27e2252e94d1f676dd093f48327ed94d8080d1f7b"
+
+DEPENDS = "perl-native"
+
+inherit autotools
--
2.25.1



Re: [dunfell][PATCH] containerd-opencontainers: add EXTRA_EXTLDFLAGS and use it to fix build with gold

Bruce Ashfield
 

Sorry for the delay, this is now merged to dunfell.

Bruce

In message: [meta-virtualization][dunfell][PATCH] containerd-opencontainers: add EXTRA_EXTLDFLAGS and use it to fix build with gold
on 01/04/2022 Martin Jansa wrote:

* 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



[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

361 - 380 of 7487