Date   

[m-c-s][PATCH] mod-wsgi: move to 4.9.0

Jeremy Puhlman
 

Older version of mod-wsgi no longer builds against python 3.10

Signed-off-by: Jeremy A. Puhlman <jpuhlman@...>
---
...ow-PYTHON-values-to-be-passed-via-en.patch | 37 +++++++++----------
.../recipes-support/mod-wsgi/mod-wsgi_git.bb | 4 +-
2 files changed, 20 insertions(+), 21 deletions(-)

diff --git a/meta-openstack/recipes-support/mod-wsgi/files/configure.ac-allow-PYTHON-values-to-be-passed-via-en.patch b/meta-openstack/recipes-support/mod-wsgi/files/configure.ac-allow-PYTHON-values-to-be-passed-via-en.patch
index 4683db0a..79aedffd 100644
--- a/meta-openstack/recipes-support/mod-wsgi/files/configure.ac-allow-PYTHON-values-to-be-passed-via-en.patch
+++ b/meta-openstack/recipes-support/mod-wsgi/files/configure.ac-allow-PYTHON-values-to-be-passed-via-en.patch
@@ -7,28 +7,31 @@ This allows the recipe to specify specific values instead of them
being 'discovered' which may lead to host contamination or similar
issues.

+Updated for 4.9.0: Jeremy Puhlman
+
Signed-off-by: Mark Asselstine <mark.asselstine@...>
----
+----
configure.ac | 41 +++++++++++++++++++++++++++++++++++++++++
1 file changed, 41 insertions(+)

+
diff --git a/configure.ac b/configure.ac
-index 25afe44..b5a9e03 100644
+index 37a0f86..9b77c7f 100644
--- a/configure.ac
+++ b/configure.ac
-@@ -100,26 +100,38 @@ fi
+@@ -106,26 +106,38 @@ fi

AC_SUBST(PYTHON)

+if test -z "${PYTHON_VERSION}"; then
PYTHON_VERSION=`${PYTHON} -c 'from sys import stdout; \
- from distutils import sysconfig; \
+ import sysconfig; \
stdout.write(sysconfig.get_config_var("VERSION"))'`
+fi

+if test -z "${PYTHON_LDVERSION}"; then
PYTHON_LDVERSION=`${PYTHON} -c 'from sys import stdout; \
- from distutils import sysconfig; \
+ import sysconfig; \
stdout.write(sysconfig.get_config_var("LDVERSION") or "")'`
+fi

@@ -38,7 +41,7 @@ index 25afe44..b5a9e03 100644

+if test -z "${PYTHON_INCLUDEPY}"; then
CPPFLAGS1=`${PYTHON} -c 'from sys import stdout; \
- from distutils import sysconfig; \
+ import sysconfig; \
stdout.write("-I" + sysconfig.get_config_var("INCLUDEPY"))'`
+else
+CPPFLAGS1="${PYTHON_INCLUDEPY}"
@@ -46,7 +49,7 @@ index 25afe44..b5a9e03 100644

+if test -z "${PYTHON_CFLAGS}"; then
CPPFLAGS2=`${PYTHON} -c 'from sys import stdout; \
- from distutils import sysconfig; \
+ import sysconfig; \
stdout.write(" ".join(filter(lambda x: x.startswith("-D"), \
sysconfig.get_config_var("CFLAGS").split())))'`
+else
@@ -55,13 +58,13 @@ index 25afe44..b5a9e03 100644

if test "${ENABLE_EMBEDDED}" != "yes"; then
CPPFLAGS3="-DMOD_WSGI_DISABLE_EMBEDDED"
-@@ -131,22 +143,43 @@ CPPFLAGS="${CPPFLAGS} ${CPPFLAGS1} ${CPPFLAGS2} ${CPPFLAGS3}"
+@@ -137,22 +149,42 @@ CPPFLAGS="${CPPFLAGS} ${CPPFLAGS1} ${CPPFLAGS2} ${CPPFLAGS3}"

AC_SUBST(CPPFLAGS)

+if test -z "${PYTHON_LIBDIR}"; then
PYTHONLIBDIR=`${PYTHON} -c 'from sys import stdout; \
- from distutils import sysconfig; \
+ import sysconfig; \
stdout.write(sysconfig.get_config_var("LIBDIR"))'`
+else
+PYTHONLIBDIR="${PYTHON_LIBDIR}"
@@ -76,22 +79,21 @@ index 25afe44..b5a9e03 100644
+fi
+if test -z "${PYTHON_FRAMEWORKDIR}"; then
PYTHONFRAMEWORKDIR=`${PYTHON} -c 'from sys import stdout; \
- from distutils import sysconfig; \
+ import sysconfig; \
stdout.write(sysconfig.get_config_var("PYTHONFRAMEWORKDIR"))'`
+else
+PYTHONFRAMEWORKDIR="${PYTHON_FRAMEWORKDIR}"
+fi
-+
+if test -z "${PYTHON_FRAMEWORKPREFIX}"; then
PYTHONFRAMEWORKPREFIX=`${PYTHON} -c 'from sys import stdout; \
- from distutils import sysconfig; \
+ import sysconfig; \
stdout.write(sysconfig.get_config_var("PYTHONFRAMEWORKPREFIX"))'`
+else
+PYTHONFRAMEWORKPREFIX="${PYTHON_FRAMEWORKPREFIX}"
+fi
+if test -z "${PYTHON_FRAMEWORK}"; then
PYTHONFRAMEWORK=`${PYTHON} -c 'from sys import stdout; \
- from distutils import sysconfig; \
+ import sysconfig; \
stdout.write(sysconfig.get_config_var("PYTHONFRAMEWORK"))'`
+else
+PYTHONFRAMEWORK="${PYTHON_FRAMEWORK}"
@@ -99,20 +101,20 @@ index 25afe44..b5a9e03 100644

if test "${PYTHON_LDVERSION}" != "${PYTHON_VERSION}"; then
PYTHONCFGDIR="${PYTHONCFGDIR}-${PYTHON_LDVERSION}"
-@@ -170,12 +203,20 @@ if test "${PYTHONFRAMEWORKDIR}" = "no-framework" -o \
+@@ -180,12 +212,20 @@ if test "${PYTHONFRAMEWORKDIR}" = "no-framework" -o \
LDLIBS1="-lpython${PYTHON_VERSION}"
fi

+ if test -z "${PYTHON_LIBS}"; then
LDLIBS2=`${PYTHON} -c 'from sys import stdout; \
- from distutils import sysconfig; \
+ import sysconfig; \
stdout.write(sysconfig.get_config_var("LIBS"))'`
+ else
+ LDLIBS2="${PYTHON_LIBS}"
+ fi
+ if test -z "${PYTHON_SYSLIBS}"; then
LDLIBS3=`${PYTHON} -c 'from sys import stdout; \
- from distutils import sysconfig; \
+ import sysconfig; \
stdout.write(sysconfig.get_config_var("SYSLIBS"))'`
+ else
+ LDLIBS3="${PYTHON_SYSLIBS}"
@@ -120,6 +122,3 @@ index 25afe44..b5a9e03 100644
else
LDFLAGS1="-Wl,-F${PYTHONFRAMEWORKPREFIX} -framework ${PYTHONFRAMEWORK}"

---
-2.7.4
-
diff --git a/meta-openstack/recipes-support/mod-wsgi/mod-wsgi_git.bb b/meta-openstack/recipes-support/mod-wsgi/mod-wsgi_git.bb
index 79afba81..910bba1b 100644
--- a/meta-openstack/recipes-support/mod-wsgi/mod-wsgi_git.bb
+++ b/meta-openstack/recipes-support/mod-wsgi/mod-wsgi_git.bb
@@ -9,8 +9,8 @@ HOMEPAGE = "https://github.com/GrahamDumpleton/mod_wsgi"
LICENSE = "Apache-2.0"
LIC_FILES_CHKSUM = "file://LICENSE;md5=3b83ef96387f14655fc854ddc3c6bd57"

-SRCREV = "217e80b7436035723b80ff02ee349365e8553dfc"
-PV = "4.6.8+git${SRCPV}"
+SRCREV = "df9faf954a1ab6208f45ba6fde90f0b41f605483"
+PV = "4.9.0+git${SRCPV}"

S = "${WORKDIR}/git"

--
2.31.1


Re: [honister][PATCH] cri-o: switch from master -> main

Bruce Ashfield
 

Cherry-picked to honister.

Bruce

In message: [meta-virtualization][honister][PATCH] cri-o: switch from master -> main
on 16/12/2021 Kristian Klausen wrote:

From: Bruce Ashfield <bruce.ashfield@...>

cri-o has joined the projects switching their default branch to
main (and removing the old one).

We update our recipe to avoid fetcher errors.

Signed-off-by: Bruce Ashfield <bruce.ashfield@...>
---
recipes-containers/cri-o/cri-o_git.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-containers/cri-o/cri-o_git.bb b/recipes-containers/cri-o/cri-o_git.bb
index 41b8625..b93c3de 100644
--- a/recipes-containers/cri-o/cri-o_git.bb
+++ b/recipes-containers/cri-o/cri-o_git.bb
@@ -16,7 +16,7 @@ At a high level, we expect the scope of cri-o to be restricted to the following

SRCREV_cri-o = "1d447191ee73ead59f344f354edac5d64f377e15"
SRC_URI = "\
- git://github.com/kubernetes-sigs/cri-o.git;branch=master;name=cri-o;protocol=https \
+ git://github.com/kubernetes-sigs/cri-o.git;branch=main;name=cri-o;protocol=https \
file://0001-Makefile-force-symlinks.patch \
file://crio.conf \
"
--
2.34.1


[honister][PATCH] cri-o: switch from master -> main

Kristian Klausen <kristian@...>
 

From: Bruce Ashfield <bruce.ashfield@...>

cri-o has joined the projects switching their default branch to
main (and removing the old one).

We update our recipe to avoid fetcher errors.

Signed-off-by: Bruce Ashfield <bruce.ashfield@...>
---
recipes-containers/cri-o/cri-o_git.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-containers/cri-o/cri-o_git.bb b/recipes-containers/c=
ri-o/cri-o_git.bb
index 41b8625..b93c3de 100644
--- a/recipes-containers/cri-o/cri-o_git.bb
+++ b/recipes-containers/cri-o/cri-o_git.bb
@@ -16,7 +16,7 @@ At a high level, we expect the scope of cri-o to be res=
tricted to the following
=20
SRCREV_cri-o =3D "1d447191ee73ead59f344f354edac5d64f377e15"
SRC_URI =3D "\
- git://github.com/kubernetes-sigs/cri-o.git;branch=3Dmaster;name=3Dcri-o=
;protocol=3Dhttps \
+ git://github.com/kubernetes-sigs/cri-o.git;branch=3Dmain;name=3Dcri-o;p=
rotocol=3Dhttps \
file://0001-Makefile-force-symlinks.patch \
file://crio.conf \
"
--=20
2.34.1


Re: [PATCH v2 1/3] xen-tools: Load xen related kernel modules during system boot

Bruce Ashfield
 

v2 looks good to me, but I'd like to get an Ack from Christopher before merging.

Bruce

On Thu, Dec 9, 2021 at 8:58 AM Kamil Dziezyk <kamil.dziezyk@...> wrote:

This patch changes the location of xen.conf file, that contains list of kernel
modules to be loaded during system boot, to "${nonarch_libdir}".

Previous path based on "${systemd_unitdir}" was not considered by default by
systemd-modules-load.service.

Signed-off-by: Kamil Dziezyk <kamil.dziezyk@...>
---
recipes-extended/xen/xen-tools.inc | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/recipes-extended/xen/xen-tools.inc b/recipes-extended/xen/xen-tools.inc
index d831941..17ef0f7 100644
--- a/recipes-extended/xen/xen-tools.inc
+++ b/recipes-extended/xen/xen-tools.inc
@@ -653,10 +653,10 @@ FILES:${PN}-xm = "\
"

FILES:${PN}-xencommons += "\
+ ${nonarch_libdir}/modules-load.d/xen.conf \
${sysconfdir}/default/xencommons \
${sysconfdir}/init.d/xencommons \
${sysconfdir}/xen/scripts/launch-xenstore \
- ${systemd_unitdir}/modules-load.d/xen.conf \
${systemd_unitdir}/system/proc-xen.mount \
${systemd_unitdir}/system/xen-qemu-dom0-disk-backend.service \
${systemd_unitdir}/system/xenconsoled.service \
@@ -744,7 +744,7 @@ SYSTEMD_SERVICE:${PN}-xendomains = "xendomains.service"

EXTRA_OECONF += " \
--with-systemd=${systemd_unitdir}/system \
- --with-systemd-modules-load=${systemd_unitdir}/modules-load.d \
+ --with-systemd-modules-load=${nonarch_libdir}/modules-load.d \
--with-initddir=${INIT_D_DIR} \
--with-sysconfig-leaf-dir=default \
--with-system-qemu=${bindir}/qemu-system-i386 \
--
2.17.1



--
- 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: Failed build because of lxc-2.0.8

Bruce Ashfield
 

On Sat, Dec 11, 2021 at 9:56 AM <thitgahamtonghop@...> wrote:

I have successfully build a yocto image with branch rocko.

After that, I have cloned the layer meta-virtualization branch rocko and the build has error as bellow. I have checked the lxc-2.0.8.bb file and it is up-to-date to the rocko branch, what could be the problem? And how can I fix this error?
usermerge wasn't tested with lxc in the rocko release, so it is
installing parts of the package where usermerge is supposed to
overlay/manage things.

But at this point Rocko is way out of support, so you'd need to
reproduce it on a newer release before anyone can really help.

Bruce


ERROR: lxc-2.0.8-r0 do_package_qa: QA Issue: lxc-setup package is not obeying usrmerge distro feature. /lib should be relocated to /usr. [usrmerge]
ERROR: lxc-2.0.8-r0 do_package_qa: QA run found fatal errors. Please consider fixing them.
ERROR: lxc-2.0.8-r0 do_package_qa: Function failed: do_package_qa






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


Failed build because of lxc-2.0.8

thitgahamtonghop@...
 

I have successfully build a yocto image with branch rocko.

After that, I have cloned the layer meta-virtualization branch rocko and the build has error as bellow. I have checked the lxc-2.0.8.bb file and it is up-to-date to the rocko branch, what could be the problem? And how can I fix this error?

ERROR: lxc-2.0.8-r0 do_package_qa: QA Issue: lxc-setup package is not obeying usrmerge distro feature. /lib should be relocated to /usr. [usrmerge]
ERROR: lxc-2.0.8-r0 do_package_qa: QA run found fatal errors. Please consider fixing them.
ERROR: lxc-2.0.8-r0 do_package_qa: Function failed: do_package_qa

 


List Archives Available at lore.kernel.org

Michael Halstead
 

This list is now available at https://lore.kernel.org/yocto-meta-virtualization/ for your convenience. 

-- 
Michael Halstead


[PATCH v2 3/3] grub-efi: Add xen_boot support when 'xen' is in DISTRO_FEATURES for aarch64

Kamil Dziezyk
 

Signed-off-by: Kamil Dziezyk <kamil.dziezyk@...>
---
recipes-bsp/grub/grub-efi_%.bbappend | 1 +
recipes-bsp/grub/grub-efi_xen.inc | 1 +
2 files changed, 2 insertions(+)
create mode 100644 recipes-bsp/grub/grub-efi_%.bbappend
create mode 100644 recipes-bsp/grub/grub-efi_xen.inc

diff --git a/recipes-bsp/grub/grub-efi_%.bbappend b/recipes-bsp/grub/grub-efi_%.bbappend
new file mode 100644
index 0000000..df2b688
--- /dev/null
+++ b/recipes-bsp/grub/grub-efi_%.bbappend
@@ -0,0 +1 @@
+require ${@bb.utils.contains('DISTRO_FEATURES', 'xen', '${BPN}_xen.inc', '', d)}
diff --git a/recipes-bsp/grub/grub-efi_xen.inc b/recipes-bsp/grub/grub-efi_xen.inc
new file mode 100644
index 0000000..5aa0958
--- /dev/null
+++ b/recipes-bsp/grub/grub-efi_xen.inc
@@ -0,0 +1 @@
+GRUB_BUILDIN:append:aarch64 = "${@bb.utils.contains('DISTRO_FEATURES', 'xen', ' xen_boot', '', d)}"
--
2.17.1


[PATCH v2 2/3] xen: Clear TUNE_CCARGS for Xen build for aarch64 machines

Kamil Dziezyk
 

Xen build may fail for arm machines that have enabled extra flags,
that can be enabled only for specific architecture version, e.g. armv8-2a.

Signed-off-by: Kamil Dziezyk <kamil.dziezyk@...>
---
recipes-extended/xen/xen.inc | 5 +++++
1 file changed, 5 insertions(+)

diff --git a/recipes-extended/xen/xen.inc b/recipes-extended/xen/xen.inc
index d3c7a7d..9ac82ef 100644
--- a/recipes-extended/xen/xen.inc
+++ b/recipes-extended/xen/xen.inc
@@ -102,6 +102,11 @@ EXTRA_CFLAGS_XEN_CORE="${DEBUG_PREFIX_MAP}"
# EXTRA_CFLAGS_XEN_TOOLS: so clear TUNE_CCARGS on x86 to prevent that.
TUNE_CCARGS:x86-64=""

+# - The Xen build for aarch64 systems with HVM-mode enabled may include
+# architecture specific flags '-march=*' which causes build failure, so clear
+# TUNE_CCARGS on aarch64 to prevent that.
+TUNE_CCARGS:aarch64=""
+
# - Yocto supplies the _FORTIFY_SOURCE flag via CC/CPP/CXX but then passes the
# optimization -O via C*FLAGS which is problematic when the CFLAGS are cleared
# within the build because compilation fails with the compiler stating
--
2.17.1


[PATCH v2 1/3] xen-tools: Load xen related kernel modules during system boot

Kamil Dziezyk
 

This patch changes the location of xen.conf file, that contains list of kernel
modules to be loaded during system boot, to "${nonarch_libdir}".

Previous path based on "${systemd_unitdir}" was not considered by default by
systemd-modules-load.service.

Signed-off-by: Kamil Dziezyk <kamil.dziezyk@...>
---
recipes-extended/xen/xen-tools.inc | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/recipes-extended/xen/xen-tools.inc b/recipes-extended/xen/xen-tools.inc
index d831941..17ef0f7 100644
--- a/recipes-extended/xen/xen-tools.inc
+++ b/recipes-extended/xen/xen-tools.inc
@@ -653,10 +653,10 @@ FILES:${PN}-xm = "\
"

FILES:${PN}-xencommons += "\
+ ${nonarch_libdir}/modules-load.d/xen.conf \
${sysconfdir}/default/xencommons \
${sysconfdir}/init.d/xencommons \
${sysconfdir}/xen/scripts/launch-xenstore \
- ${systemd_unitdir}/modules-load.d/xen.conf \
${systemd_unitdir}/system/proc-xen.mount \
${systemd_unitdir}/system/xen-qemu-dom0-disk-backend.service \
${systemd_unitdir}/system/xenconsoled.service \
@@ -744,7 +744,7 @@ SYSTEMD_SERVICE:${PN}-xendomains = "xendomains.service"

EXTRA_OECONF += " \
--with-systemd=${systemd_unitdir}/system \
- --with-systemd-modules-load=${systemd_unitdir}/modules-load.d \
+ --with-systemd-modules-load=${nonarch_libdir}/modules-load.d \
--with-initddir=${INIT_D_DIR} \
--with-sysconfig-leaf-dir=default \
--with-system-qemu=${bindir}/qemu-system-i386 \
--
2.17.1


Re: [PATCH 1/3] xen-tools: Load xen related kernel modules during system boot

Kamil Dziezyk
 

Hi Christopher,

Is there any reason that you chose to drop specifying the install directory via the flags passed to EXTRA_OECONF?

I have dropped setting install directory, because it seemed for me to be redundant,

but I missed the case, when user customize exec_prefix or nonarch_libdir, so I will apply your suggestion.

Thanks, Kamil


Re: [PATCH 1/3] xen-tools: Load xen related kernel modules during system boot

Christopher Clark
 

On Wed, Dec 8, 2021 at 6:35 PM Khem Raj <raj.khem@...> wrote:

On Wed, Dec 8, 2021 at 6:24 PM Christopher Clark <christopher.w.clark@...> wrote:
On Wed, Dec 8, 2021 at 5:10 AM Bertrand Marquis <bertrand.marquis@...> wrote:
Hi Kamil,

> On 8 Dec 2021, at 10:44, Kamil Dziezyk via lists.yoctoproject.org <kamil.dziezyk=arm.com@...> wrote:
>
> This patch changes the location of xen.conf file, that contains list of kernel
> modules to be loaded during system boot, to "${nonarch_libdir}". This is done
> by removing '--with-systemd-modules-load=' flag from EXTRA_OECONF variable.
>
> Previous path based on "${systemd_unitdir}" was not considered by default by
> systemd-modules-load.service.

ok, it does look like there's a fix that should be made here, thanks. It took a bit of following to see what's involved, so:

There are two recipes in meta-openembedded that do use ${nonarch_libdir} for this, but the systemd package itself doesn't: the recipe has ${exec_prefix}/lib/modules-load.d instead, and there's a systemd patch that applies ${exec_prefix}/lib/modules-load.d too; but then in oe-core, bitbake.conf defines: nonarch_libdir = "${exec_prefix}/lib"
so the end result should work in the default configuration.

Khem: should the OE Core systemd recipe and patch be using ${nonarch_libdir} too? Or should the recipes that package modules.d config files place them via ${exec_prefix}/lib ?

I think nonarch_libdir is right option here 

Thanks, Khem.

Kamil: Is there any reason that you chose to drop specifying the install directory via the flags passed to EXTRA_OECONF?
ie. An alternative would be: rather than remove the "--with-systemd-modules-load" flag, you could update it to use the correct location:
    ${nonarch_libdir}/modules-load.d
so that if exec_prefix or nonarch_libdir are ever overridden to a non-default value, the config file will still be placed correctly.

Christopher


 

thanks

Christopher

 
>
> Signed-off-by: Kamil Dziezyk <kamil.dziezyk@...>
Reviewed-by: Bertrand Marquis <bertrand.marquis@...>

Cheers
Bertrand

> ---
> recipes-extended/xen/xen-tools.inc | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/recipes-extended/xen/xen-tools.inc b/recipes-extended/xen/xen-tools.inc
> index d831941..6b99040 100644
> --- a/recipes-extended/xen/xen-tools.inc
> +++ b/recipes-extended/xen/xen-tools.inc
> @@ -653,10 +653,10 @@ FILES:${PN}-xm = "\
>     "
>
> FILES:${PN}-xencommons += "\
> +    ${nonarch_libdir}/modules-load.d/xen.conf \
>     ${sysconfdir}/default/xencommons \
>     ${sysconfdir}/init.d/xencommons \
>     ${sysconfdir}/xen/scripts/launch-xenstore \
> -    ${systemd_unitdir}/modules-load.d/xen.conf \
>     ${systemd_unitdir}/system/proc-xen.mount \
>     ${systemd_unitdir}/system/xen-qemu-dom0-disk-backend.service \
>     ${systemd_unitdir}/system/xenconsoled.service \
> @@ -744,7 +744,6 @@ SYSTEMD_SERVICE:${PN}-xendomains = "xendomains.service"
>
> EXTRA_OECONF += " \
>     --with-systemd=${systemd_unitdir}/system \
> -    --with-systemd-modules-load=${systemd_unitdir}/modules-load.d \
>     --with-initddir=${INIT_D_DIR} \
>     --with-sysconfig-leaf-dir=default \
>     --with-system-qemu=${bindir}/qemu-system-i386 \
> --
> 2.17.1
>
>
>
>





Re: [PATCH 1/3] xen-tools: Load xen related kernel modules during system boot

Christopher Clark
 

On Wed, Dec 8, 2021 at 5:10 AM Bertrand Marquis <bertrand.marquis@...> wrote:
Hi Kamil,

> On 8 Dec 2021, at 10:44, Kamil Dziezyk via lists.yoctoproject.org <kamil.dziezyk=arm.com@...> wrote:
>
> This patch changes the location of xen.conf file, that contains list of kernel
> modules to be loaded during system boot, to "${nonarch_libdir}". This is done
> by removing '--with-systemd-modules-load=' flag from EXTRA_OECONF variable.
>
> Previous path based on "${systemd_unitdir}" was not considered by default by
> systemd-modules-load.service.

ok, it does look like there's a fix that should be made here, thanks. It took a bit of following to see what's involved, so:

There are two recipes in meta-openembedded that do use ${nonarch_libdir} for this, but the systemd package itself doesn't: the recipe has ${exec_prefix}/lib/modules-load.d instead, and there's a systemd patch that applies ${exec_prefix}/lib/modules-load.d too; but then in oe-core, bitbake.conf defines: nonarch_libdir = "${exec_prefix}/lib"
so the end result should work in the default configuration.

Khem: should the OE Core systemd recipe and patch be using ${nonarch_libdir} too? Or should the recipes that package modules.d config files place them via ${exec_prefix}/lib ?

thanks

Christopher

 
>
> Signed-off-by: Kamil Dziezyk <kamil.dziezyk@...>
Reviewed-by: Bertrand Marquis <bertrand.marquis@...>

Cheers
Bertrand

> ---
> recipes-extended/xen/xen-tools.inc | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/recipes-extended/xen/xen-tools.inc b/recipes-extended/xen/xen-tools.inc
> index d831941..6b99040 100644
> --- a/recipes-extended/xen/xen-tools.inc
> +++ b/recipes-extended/xen/xen-tools.inc
> @@ -653,10 +653,10 @@ FILES:${PN}-xm = "\
>     "
>
> FILES:${PN}-xencommons += "\
> +    ${nonarch_libdir}/modules-load.d/xen.conf \
>     ${sysconfdir}/default/xencommons \
>     ${sysconfdir}/init.d/xencommons \
>     ${sysconfdir}/xen/scripts/launch-xenstore \
> -    ${systemd_unitdir}/modules-load.d/xen.conf \
>     ${systemd_unitdir}/system/proc-xen.mount \
>     ${systemd_unitdir}/system/xen-qemu-dom0-disk-backend.service \
>     ${systemd_unitdir}/system/xenconsoled.service \
> @@ -744,7 +744,6 @@ SYSTEMD_SERVICE:${PN}-xendomains = "xendomains.service"
>
> EXTRA_OECONF += " \
>     --with-systemd=${systemd_unitdir}/system \
> -    --with-systemd-modules-load=${systemd_unitdir}/modules-load.d \
>     --with-initddir=${INIT_D_DIR} \
>     --with-sysconfig-leaf-dir=default \
>     --with-system-qemu=${bindir}/qemu-system-i386 \
> --
> 2.17.1
>
>
>
>





[PATCH 3/3] MAINTAINERS: add xtf and the raspberry pi dynamic layer for Xen

Christopher Clark
 

Add the more recent Xen-related recipes to the list.

Signed-off-by: Christopher Clark <christopher.w.clark@...>
---
MAINTAINERS | 2 ++
1 file changed, 2 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 1bb9a24..4b41bad 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -32,3 +32,5 @@ M: Christopher Clark <christopher.w.clark@...>
F: recipes-extended/xen/
F: recipes-extended/uxen/
F: recipes-extended/images/*xen*.bb
+F: recipes-extended/images/xtf*.bb
+F: dynamic-layers/raspberrypi/
--
2.25.1


[PATCH 2/3] xen-tools: upgrade RSUGGESTS to RRECOMMENDS for ifupdown

Christopher Clark
 

Xen's networking for guests is typically configured using bridges and
the standalone ifupdown package, which contains a more capable version
of the tool than busybox, is needed to configure them, so:

Increase the recommendation strength from RSUGGESTS to RRECOMMENDS to
bring the package in by default, which fixes networking for images built
with packaging formats that follow RRECOMMENDS but not RSUGGESTS.

I should've paid closer attention to Corey's recommendation for this, so:
Suggested-by: Corey Minyard <cminyard@...>

Signed-off-by: Christopher Clark <christopher.w.clark@...>
---
recipes-extended/xen/xen-tools.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-extended/xen/xen-tools.inc b/recipes-extended/xen/xen-tools.inc
index d831941..ca924f4 100644
--- a/recipes-extended/xen/xen-tools.inc
+++ b/recipes-extended/xen/xen-tools.inc
@@ -94,7 +94,7 @@ RDEPENDS:${PN}-scripts-network = "\
${PN}-volatiles \
"

-RSUGGESTS:${PN}-scripts-network = "\
+RRECOMMENDS:${PN}-scripts-network = "\
ifupdown \
"

--
2.25.1


[PATCH 1/3] xen: drop patch to workaround prelink on aarch64

Christopher Clark
 

prelink is no longer default enabled and has been recommended to be
disabled since OE-core f9719cc1.

Signed-off-by: Christopher Clark <christopher.w.clark@...>
---
...xen-arm64-implement-atomic-fetch-add.patch | 50 -------------------
recipes-extended/xen/xen_4.14.bb | 1 -
recipes-extended/xen/xen_4.15.bb | 1 -
recipes-extended/xen/xen_git.bb | 1 -
4 files changed, 53 deletions(-)
delete mode 100644 recipes-extended/xen/files/xen-arm64-implement-atomic-fetch-add.patch

diff --git a/recipes-extended/xen/files/xen-arm64-implement-atomic-fetch-add.patch b/recipes-extended/xen/files/xen-arm64-implement-atomic-fetch-add.patch
deleted file mode 100644
index 6e957a5..0000000
--- a/recipes-extended/xen/files/xen-arm64-implement-atomic-fetch-add.patch
+++ /dev/null
@@ -1,50 +0,0 @@
-From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
-From: Christopher Clark <christopher.w.clark@...>
-Date: Fri, 26 June 2020 16:34:00 -0800
-Subject: [PATCH] xen: implement atomic op to fix arm64 compilation
-
-Xen's ARM implementation of arch_fetch_and_add since f9cc3cd9
-uses a builtin, despite the build being performed with -fno-builtin.
-With gcc 10.1.0, this now breaks prelinking spinlock.c, so
-implement the one atomic operation that is required with logic
-derived from Linux's atomic_ll_sc.h: ATOMIC_FETCH_OP and comparison with
-the binary produced with and without the patch with gcc 9.2.0.
-
-Signed-off-by: Christopher Clark <christopher.w.clark@...>
-diff --git a/xen/include/asm-arm/system.h b/xen/include/asm-arm/system.h
-index e5d062667d..c46dd3ac71 100644
---- a/xen/include/asm-arm/system.h
-+++ b/xen/include/asm-arm/system.h
-@@ -55,7 +55,32 @@ static inline int local_abort_is_enabled(void)
- return !(flags & PSR_ABT_MASK);
- }
-
-+#ifdef CONFIG_ARM_64
-+
-+/* see atomic_ll_sc.h: ATOMIC_FETCH_OP(name, mb, acq, rel, cl, op, asm_op, constraint) */
-+static inline int arch_fetch_and_add(unsigned int *ptr, unsigned long i)
-+{
-+ int register lptr asm("x0");
-+ int register result asm("w1");
-+ int register newval asm("w2");
-+ int register status asm("w3");
-+
-+ asm volatile(
-+ " mov %[lptr], %[ptr]\n"
-+ "1: ldxr %w[result], [%[lptr]]\n"
-+ " add %w[newval], %w[result], %w[i]\n"
-+ " stlxr %w[status], %w[newval], [%[lptr]]\n"
-+ " cbnz %w[status], 1b\n"
-+ " dmb ish\n"
-+ : [result] "=&r" (result), [lptr] "=&r" (lptr), [newval] "=&r" (newval), [status] "=&r" (status), [i] "+r" (i), "+Q" (*ptr)
-+ : [ptr] "r" (ptr), "r" (i)
-+ : "memory");
-+
-+ return result;
-+}
-+#else
- #define arch_fetch_and_add(x, v) __sync_fetch_and_add(x, v)
-+#endif
-
- extern struct vcpu *__context_switch(struct vcpu *prev, struct vcpu *next);
-
diff --git a/recipes-extended/xen/xen_4.14.bb b/recipes-extended/xen/xen_4.14.bb
index 0d7d20b..267db16 100644
--- a/recipes-extended/xen/xen_4.14.bb
+++ b/recipes-extended/xen/xen_4.14.bb
@@ -6,7 +6,6 @@ XEN_BRANCH ?= "stable-${XEN_REL}"

SRC_URI = " \
git://xenbits.xen.org/xen.git;branch=${XEN_BRANCH} \
- file://xen-arm64-implement-atomic-fetch-add.patch \
file://0001-menuconfig-mconf-cfg-Allow-specification-of-ncurses-location.patch \
"

diff --git a/recipes-extended/xen/xen_4.15.bb b/recipes-extended/xen/xen_4.15.bb
index 0cfaf0c..1b87ae8 100644
--- a/recipes-extended/xen/xen_4.15.bb
+++ b/recipes-extended/xen/xen_4.15.bb
@@ -6,7 +6,6 @@ XEN_BRANCH ?= "stable-${XEN_REL}"

SRC_URI = " \
git://xenbits.xen.org/xen.git;branch=${XEN_BRANCH} \
- file://xen-arm64-implement-atomic-fetch-add.patch \
file://0001-menuconfig-mconf-cfg-Allow-specification-of-ncurses-location.patch \
"

diff --git a/recipes-extended/xen/xen_git.bb b/recipes-extended/xen/xen_git.bb
index 20227e0..e014733 100644
--- a/recipes-extended/xen/xen_git.bb
+++ b/recipes-extended/xen/xen_git.bb
@@ -6,7 +6,6 @@ XEN_BRANCH ?= "master"

SRC_URI = " \
git://xenbits.xen.org/xen.git;branch=${XEN_BRANCH} \
- file://xen-arm64-implement-atomic-fetch-add.patch \
file://0001-menuconfig-mconf-cfg-Allow-specification-of-ncurses-location.patch \
"

--
2.25.1


Re: [PATCH 3/3] grub-efi: Add xen_boot support when 'xen' is in DISTRO_FEATURES for aarch64

Bertrand Marquis
 

Hi Kamil,

On 8 Dec 2021, at 10:44, Kamil Dziezyk via lists.yoctoproject.org <kamil.dziezyk=arm.com@...> wrote:

Signed-off-by: Kamil Dziezyk <kamil.dziezyk@...>
Reviewed-by: Bertrand Marquis <bertrand.marquis@...>

But an empty commit message is not something that I like (more for next time, no need to change this patch).

Cheers
Bertrand
---
recipes-bsp/grub/grub-efi_%.bbappend | 1 +
recipes-bsp/grub/grub-efi_xen.inc | 1 +
2 files changed, 2 insertions(+)
create mode 100644 recipes-bsp/grub/grub-efi_%.bbappend
create mode 100644 recipes-bsp/grub/grub-efi_xen.inc

diff --git a/recipes-bsp/grub/grub-efi_%.bbappend b/recipes-bsp/grub/grub-efi_%.bbappend
new file mode 100644
index 0000000..df2b688
--- /dev/null
+++ b/recipes-bsp/grub/grub-efi_%.bbappend
@@ -0,0 +1 @@
+require ${@bb.utils.contains('DISTRO_FEATURES', 'xen', '${BPN}_xen.inc', '', d)}
diff --git a/recipes-bsp/grub/grub-efi_xen.inc b/recipes-bsp/grub/grub-efi_xen.inc
new file mode 100644
index 0000000..5aa0958
--- /dev/null
+++ b/recipes-bsp/grub/grub-efi_xen.inc
@@ -0,0 +1 @@
+GRUB_BUILDIN:append:aarch64 = "${@bb.utils.contains('DISTRO_FEATURES', 'xen', ' xen_boot', '', d)}"
--
2.17.1




Re: [PATCH 2/3] xen: Clear TUNE_CCARGS for Xen build for aarch64 machines

Bertrand Marquis
 

Hi Kamil,

On 8 Dec 2021, at 10:44, Kamil Dziezyk via lists.yoctoproject.org <kamil.dziezyk=arm.com@...> wrote:

Xen build may fail for arm machines that have enabled extra flags,
that can be enabled only for specific architecture version, e.g. armv8-2a.

Signed-off-by: Kamil Dziezyk <kamil.dziezyk@...>
Reviewed-by: Bertrand Marquis <bertrand.marquis@...>

Cheers
Bertrand

---
recipes-extended/xen/xen.inc | 5 +++++
1 file changed, 5 insertions(+)

diff --git a/recipes-extended/xen/xen.inc b/recipes-extended/xen/xen.inc
index d3c7a7d..9ac82ef 100644
--- a/recipes-extended/xen/xen.inc
+++ b/recipes-extended/xen/xen.inc
@@ -102,6 +102,11 @@ EXTRA_CFLAGS_XEN_CORE="${DEBUG_PREFIX_MAP}"
# EXTRA_CFLAGS_XEN_TOOLS: so clear TUNE_CCARGS on x86 to prevent that.
TUNE_CCARGS:x86-64=""

+# - The Xen build for aarch64 systems with HVM-mode enabled may include
+# architecture specific flags '-march=*' which causes build failure, so clear
+# TUNE_CCARGS on aarch64 to prevent that.
+TUNE_CCARGS:aarch64=""
+
# - Yocto supplies the _FORTIFY_SOURCE flag via CC/CPP/CXX but then passes the
# optimization -O via C*FLAGS which is problematic when the CFLAGS are cleared
# within the build because compilation fails with the compiler stating
--
2.17.1




Re: [PATCH 1/3] xen-tools: Load xen related kernel modules during system boot

Bertrand Marquis
 

Hi Kamil,

On 8 Dec 2021, at 10:44, Kamil Dziezyk via lists.yoctoproject.org <kamil.dziezyk=arm.com@...> wrote:

This patch changes the location of xen.conf file, that contains list of kernel
modules to be loaded during system boot, to "${nonarch_libdir}". This is done
by removing '--with-systemd-modules-load=' flag from EXTRA_OECONF variable.

Previous path based on "${systemd_unitdir}" was not considered by default by
systemd-modules-load.service.

Signed-off-by: Kamil Dziezyk <kamil.dziezyk@...>
Reviewed-by: Bertrand Marquis <bertrand.marquis@...>

Cheers
Bertrand

---
recipes-extended/xen/xen-tools.inc | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/recipes-extended/xen/xen-tools.inc b/recipes-extended/xen/xen-tools.inc
index d831941..6b99040 100644
--- a/recipes-extended/xen/xen-tools.inc
+++ b/recipes-extended/xen/xen-tools.inc
@@ -653,10 +653,10 @@ FILES:${PN}-xm = "\
"

FILES:${PN}-xencommons += "\
+ ${nonarch_libdir}/modules-load.d/xen.conf \
${sysconfdir}/default/xencommons \
${sysconfdir}/init.d/xencommons \
${sysconfdir}/xen/scripts/launch-xenstore \
- ${systemd_unitdir}/modules-load.d/xen.conf \
${systemd_unitdir}/system/proc-xen.mount \
${systemd_unitdir}/system/xen-qemu-dom0-disk-backend.service \
${systemd_unitdir}/system/xenconsoled.service \
@@ -744,7 +744,6 @@ SYSTEMD_SERVICE:${PN}-xendomains = "xendomains.service"

EXTRA_OECONF += " \
--with-systemd=${systemd_unitdir}/system \
- --with-systemd-modules-load=${systemd_unitdir}/modules-load.d \
--with-initddir=${INIT_D_DIR} \
--with-sysconfig-leaf-dir=default \
--with-system-qemu=${bindir}/qemu-system-i386 \
--
2.17.1




[PATCH 2/3] xen: Clear TUNE_CCARGS for Xen build for aarch64 machines

Kamil Dziezyk
 

Xen build may fail for arm machines that have enabled extra flags,
that can be enabled only for specific architecture version, e.g. armv8-2a.

Signed-off-by: Kamil Dziezyk <kamil.dziezyk@...>
---
recipes-extended/xen/xen.inc | 5 +++++
1 file changed, 5 insertions(+)

diff --git a/recipes-extended/xen/xen.inc b/recipes-extended/xen/xen.inc
index d3c7a7d..9ac82ef 100644
--- a/recipes-extended/xen/xen.inc
+++ b/recipes-extended/xen/xen.inc
@@ -102,6 +102,11 @@ EXTRA_CFLAGS_XEN_CORE="${DEBUG_PREFIX_MAP}"
# EXTRA_CFLAGS_XEN_TOOLS: so clear TUNE_CCARGS on x86 to prevent that.
TUNE_CCARGS:x86-64=""

+# - The Xen build for aarch64 systems with HVM-mode enabled may include
+# architecture specific flags '-march=*' which causes build failure, so clear
+# TUNE_CCARGS on aarch64 to prevent that.
+TUNE_CCARGS:aarch64=""
+
# - Yocto supplies the _FORTIFY_SOURCE flag via CC/CPP/CXX but then passes the
# optimization -O via C*FLAGS which is problematic when the CFLAGS are cleared
# within the build because compilation fails with the compiler stating
--
2.17.1

541 - 560 of 7515