Re: [OE-core] [PATCH] grub: disable build on armv7ve/a with hardfp

[Andrei Gherzan]

Hi,

On Wed, Oct 19, 2022 at 3:54 AM Yu, Mingli  wrote:

> From: Mingli Yu 
>
> The commit(75dbdea940 grub: Allow build on armv7ve/a with softfp)
> enable build on armv7ve/a with softfp, but it acutally enable
> build on armv7ve/a with hardfp altogether and result in below build
> failure:
>  | checking for compile options to get strict alignment...
> -mno-unaligned-access
>  | checking if compiler generates unaligned accesses... no
>  | checking if C symbols get an underscore after compilation... no
>  | checking whether target compiler is working... no
>  | configure: error: cannot compile for the target
>
> So update the check to disable build on armv7ve/a with hardfp.
>
> Signed-off-by: Mingli Yu 
> ---
>  meta/recipes-bsp/grub/grub2.inc | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/meta/recipes-bsp/grub/grub2.inc
> b/meta/recipes-bsp/grub/grub2.inc
> index 2545b99b6a..7161c4560b 100644
> --- a/meta/recipes-bsp/grub/grub2.inc
> +++ b/meta/recipes-bsp/grub/grub2.inc
> @@ -50,8 +50,8 @@ COMPATIBLE_HOST = "${GRUB_COMPATIBLE_HOST}"
>  # Grub doesn't support hard float toolchain and won't be able to
> forcefully
>  # disable it on some of the target CPUs. See 'configure.ac' for
>  # supported/unsupported CPUs in hardfp.
> -COMPATIBLE_HOST:armv7a = "${@'null' if d.getVar('TUNE_CCARGS_MFLOAT') ==
> 'hardfp' else d.getVar('GRUB_COMPATIBLE_HOST')}"
> -COMPATIBLE_HOST:armv7ve = "${@'null' if d.getVar('TUNE_CCARGS_MFLOAT') ==
> 'hardfp' else d.getVar('GRUB_COMPATIBLE_HOST')}"
> +COMPATIBLE_HOST:armv7a = "${@'null' if
> bb.utils.contains('TUNE_CCARGS_MFLOAT', 'hard', True, False, d) else
> d.getVar('GRUB_COMPATIBLE_HOST')}"
> +COMPATIBLE_HOST:armv7ve = "${@'null' if
> bb.utils.contains('TUNE_CCARGS_MFLOAT', 'hard', True, False, d) else
> d.getVar('GRUB_COMPATIBLE_HOST')}"
>

Sounds like a typo on my side. I'll check my testing as I'm curious how
I've managed to miss this. Thanks for fixing it!

Andrei

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#171963): 
https://lists.openembedded.org/g/openembedded-core/message/171963
Mute This Topic: https://lists.openembedded.org/mt/94423825/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH] grub: Allow build on armv7ve/a with softfp

[Andrei Gherzan]

Hi,

On Thu, 15 Sep 2022, at 13:50, Andrei Gherzan wrote:
> From: Andrei Gherzan 
>
> Grub tries to force the compilation in softfp mode for some known target
> CPU. That is because it doesn't use floats or doubles and there are
> known limitations of using a configuration with hardfp. There are though
> target CPUs that grub won't know how to configure failing with something
> similar to:
>
> | checking for options to get soft-float... no
> | configure: error: could not force soft-float
>
> This change relaxes a bit the COMPATIBLE_HOST restriction to only apply
> for hardfp configuration even for arm7ve/a.
>
> Signed-off-by: Andrei Gherzan 
> ---
>  meta/recipes-bsp/grub/grub2.inc | 15 ---
>  1 file changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/meta/recipes-bsp/grub/grub2.inc b/meta/recipes-bsp/grub/grub2.inc
> index 47ea561002..6c9952d2d7 100644
> --- a/meta/recipes-bsp/grub/grub2.inc
> +++ b/meta/recipes-bsp/grub/grub2.inc
> @@ -43,9 +43,18 @@ CVE_CHECK_IGNORE += "CVE-2021-46705"
> 
>  DEPENDS = "flex-native bison-native gettext-native"
> 
> -COMPATIBLE_HOST = 
> '(x86_64.*|i.86.*|arm.*|aarch64.*|riscv.*)-(linux.*|freebsd.*)'
> -COMPATIBLE_HOST:armv7a = 'null'
> -COMPATIBLE_HOST:armv7ve = 'null'
> +GRUB_COMPATIBLE_HOST = 
> '(x86_64.*|i.86.*|arm.*|aarch64.*|riscv.*)-(linux.*|freebsd.*)'
> +COMPATIBLE_HOST = "${GRUB_COMPATIBLE_HOST}"
> +# Grub doesn't support hard float toolchain and won't be able to 
> forcefully
> +# disable it on some of the target CPUs. See 'configure.ac' for
> +# supported/unsupported CPUs in hardfp.
> +COMPATIBLE_HOST:armv7a = "${@'null' if d.getVar('TUNE_CCARGS_MFLOAT') 
> == 'hardfp' else d.getVar('GRUB_COMPATIBLE_HOST')}"
> +COMPATIBLE_HOST:armv7ve = "${@'null' if d.getVar('TUNE_CCARGS_MFLOAT') 
> == 'hardfp' else d.getVar('GRUB_COMPATIBLE_HOST')}"
> +
> +# Grub doesn't use float or doubles and tries to disable forcefully 
> floating
> +# point at configure time. That dynamic flags configuration doesn't 
> always work
> +# (for example on arm 32bit) so force the compilation in softfp.
> +TUNE_CCARGS_MFLOAT:class-target = "softfp"

Please ignore this v1 patch as the above was not supposed to be part of the 
patch. I've sent a cleaned up v2: 
https://lists.openembedded.org/g/openembedded-core/message/170695

Thanks,
Andrei

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170696): 
https://lists.openembedded.org/g/openembedded-core/message/170696
Mute This Topic: https://lists.openembedded.org/mt/93699086/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH v2] grub: Allow build on armv7ve/a with softfp

[Andrei Gherzan]

From: Andrei Gherzan 

Grub tries to force the compilation in softfp mode for some known target
CPU. That is because it doesn't use floats or doubles and there are
known limitations of using a configuration with hardfp. There are though
target CPUs that grub won't know how to configure failing with something
similar to:

| checking for options to get soft-float... no
| configure: error: could not force soft-float

This change relaxes a bit the COMPATIBLE_HOST restriction to only apply
for hardfp configuration even for arm7ve/a.

Signed-off-by: Andrei Gherzan 
---
 meta/recipes-bsp/grub/grub2.inc | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-bsp/grub/grub2.inc b/meta/recipes-bsp/grub/grub2.inc
index 47ea561002..e257c31235 100644
--- a/meta/recipes-bsp/grub/grub2.inc
+++ b/meta/recipes-bsp/grub/grub2.inc
@@ -43,9 +43,13 @@ CVE_CHECK_IGNORE += "CVE-2021-46705"
 
 DEPENDS = "flex-native bison-native gettext-native"
 
-COMPATIBLE_HOST = 
'(x86_64.*|i.86.*|arm.*|aarch64.*|riscv.*)-(linux.*|freebsd.*)'
-COMPATIBLE_HOST:armv7a = 'null'
-COMPATIBLE_HOST:armv7ve = 'null'
+GRUB_COMPATIBLE_HOST = 
'(x86_64.*|i.86.*|arm.*|aarch64.*|riscv.*)-(linux.*|freebsd.*)'
+COMPATIBLE_HOST = "${GRUB_COMPATIBLE_HOST}"
+# Grub doesn't support hard float toolchain and won't be able to forcefully
+# disable it on some of the target CPUs. See 'configure.ac' for
+# supported/unsupported CPUs in hardfp.
+COMPATIBLE_HOST:armv7a = "${@'null' if d.getVar('TUNE_CCARGS_MFLOAT') == 
'hardfp' else d.getVar('GRUB_COMPATIBLE_HOST')}"
+COMPATIBLE_HOST:armv7ve = "${@'null' if d.getVar('TUNE_CCARGS_MFLOAT') == 
'hardfp' else d.getVar('GRUB_COMPATIBLE_HOST')}"
 
 # configure.ac has code to set this automagically from the target tuple
 # but the OE freeform one (core2-foo-bar-linux) don't work with that.
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170695): 
https://lists.openembedded.org/g/openembedded-core/message/170695
Mute This Topic: https://lists.openembedded.org/mt/93699232/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH] grub: Allow build on armv7ve/a with softfp

[Andrei Gherzan]

From: Andrei Gherzan 

Grub tries to force the compilation in softfp mode for some known target
CPU. That is because it doesn't use floats or doubles and there are
known limitations of using a configuration with hardfp. There are though
target CPUs that grub won't know how to configure failing with something
similar to:

| checking for options to get soft-float... no
| configure: error: could not force soft-float

This change relaxes a bit the COMPATIBLE_HOST restriction to only apply
for hardfp configuration even for arm7ve/a.

Signed-off-by: Andrei Gherzan 
---
 meta/recipes-bsp/grub/grub2.inc | 15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-bsp/grub/grub2.inc b/meta/recipes-bsp/grub/grub2.inc
index 47ea561002..6c9952d2d7 100644
--- a/meta/recipes-bsp/grub/grub2.inc
+++ b/meta/recipes-bsp/grub/grub2.inc
@@ -43,9 +43,18 @@ CVE_CHECK_IGNORE += "CVE-2021-46705"
 
 DEPENDS = "flex-native bison-native gettext-native"
 
-COMPATIBLE_HOST = 
'(x86_64.*|i.86.*|arm.*|aarch64.*|riscv.*)-(linux.*|freebsd.*)'
-COMPATIBLE_HOST:armv7a = 'null'
-COMPATIBLE_HOST:armv7ve = 'null'
+GRUB_COMPATIBLE_HOST = 
'(x86_64.*|i.86.*|arm.*|aarch64.*|riscv.*)-(linux.*|freebsd.*)'
+COMPATIBLE_HOST = "${GRUB_COMPATIBLE_HOST}"
+# Grub doesn't support hard float toolchain and won't be able to forcefully
+# disable it on some of the target CPUs. See 'configure.ac' for
+# supported/unsupported CPUs in hardfp.
+COMPATIBLE_HOST:armv7a = "${@'null' if d.getVar('TUNE_CCARGS_MFLOAT') == 
'hardfp' else d.getVar('GRUB_COMPATIBLE_HOST')}"
+COMPATIBLE_HOST:armv7ve = "${@'null' if d.getVar('TUNE_CCARGS_MFLOAT') == 
'hardfp' else d.getVar('GRUB_COMPATIBLE_HOST')}"
+
+# Grub doesn't use float or doubles and tries to disable forcefully floating
+# point at configure time. That dynamic flags configuration doesn't always work
+# (for example on arm 32bit) so force the compilation in softfp.
+TUNE_CCARGS_MFLOAT:class-target = "softfp"
 
 # configure.ac has code to set this automagically from the target tuple
 # but the OE freeform one (core2-foo-bar-linux) don't work with that.
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170694): 
https://lists.openembedded.org/g/openembedded-core/message/170694
Mute This Topic: https://lists.openembedded.org/mt/93699086/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH] rootfs.py: Drop FAKEROOT support in exec function

[Andrei Gherzan]

From: Andrei Gherzan 

The _exec_shell_cmd function is used by a couple of other functions that
are ultimatelly called from the create_rootfs function. The latter is
used in image bbclass' do_rootfs which is running using the fakeroot
support in bitbake. This makes the fakeroot support in _exec_shell_cmd
redundant and never actually used.

Signed-off-by: Andrei Gherzan 
---
 meta/lib/oe/rootfs.py | 8 +---
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/meta/lib/oe/rootfs.py b/meta/lib/oe/rootfs.py
index 8587c5db82..890ba5f039 100644
--- a/meta/lib/oe/rootfs.py
+++ b/meta/lib/oe/rootfs.py
@@ -173,14 +173,8 @@ class Rootfs(object, metaclass=ABCMeta):
 bb.utils.rename(self.image_rootfs + '-orig', self.image_rootfs)
 
 def _exec_shell_cmd(self, cmd):
-fakerootcmd = self.d.getVar('FAKEROOT')
-if fakerootcmd is not None:
-exec_cmd = [fakerootcmd, cmd]
-else:
-exec_cmd = cmd
-
 try:
-subprocess.check_output(exec_cmd, stderr=subprocess.STDOUT)
+subprocess.check_output(cmd, stderr=subprocess.STDOUT)
 except subprocess.CalledProcessError as e:
 return("Command '%s' returned %d:\n%s" % (e.cmd, e.returncode, 
e.output))
 
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170657): 
https://lists.openembedded.org/g/openembedded-core/message/170657
Mute This Topic: https://lists.openembedded.org/mt/93676035/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH 4/4] rootfs.py: Run depmod(wrapper) against each compiled kernel

[Andrei Gherzan]

From: Andrei Gherzan 

We run depmod (through depmodwrapper) at the end of the rootfs
generation process. This part of the process assumes in its current
implementation that the kernel package name is always 'kernel' and that
there is only one set of kernel modules for which we need to generate
the modules.dep and map files.

The kernel package name can be configured via a variable
(KERNEL_PACKAGE_NAME) and becomes a namespace that enables the build
system to deal with multiple compiled kernel recipes. This patch checks
for all the depmod pkgdata and runs depmod for each of the detected
kernel versions/kernel package name.

Signed-off-by: Andrei Gherzan 
---
 meta/lib/oe/rootfs.py | 28 +++-
 1 file changed, 19 insertions(+), 9 deletions(-)

diff --git a/meta/lib/oe/rootfs.py b/meta/lib/oe/rootfs.py
index 0b9911e3a6..a02dddf23d 100644
--- a/meta/lib/oe/rootfs.py
+++ b/meta/lib/oe/rootfs.py
@@ -325,19 +325,29 @@ class Rootfs(object, metaclass=ABCMeta):
 bb.note("No Kernel Modules found, not running depmod")
 return
 
-kernel_abi_ver_file = oe.path.join(self.d.getVar('PKGDATA_DIR'), 
"kernel-depmod",
-   'kernel-abiversion')
-if not os.path.exists(kernel_abi_ver_file):
-bb.fatal("No kernel-abiversion file found (%s), cannot run depmod, 
aborting" % kernel_abi_ver_file)
+pkgdatadir = self.d.getVar('PKGDATA_DIR')
 
-with open(kernel_abi_ver_file) as f:
-kernel_ver = f.read().strip(' \n')
+# PKGDATA_DIR can include multiple kernels so we run depmod for each
+# one of them.
+for direntry in os.listdir(pkgdatadir):
+match = re.match('(.*)-depmod', direntry)
+if not match:
+continue
+kernel_package_name = match.group(1)
+
+kernel_abi_ver_file = oe.path.join(pkgdatadir, direntry, 
kernel_package_name + '-abiversion')
+if not os.path.exists(kernel_abi_ver_file):
+bb.fatal("No kernel-abiversion file found (%s), cannot run 
depmod, aborting" % kernel_abi_ver_file)
+
+with open(kernel_abi_ver_file) as f:
+kernel_ver = f.read().strip(' \n')
 
-versioned_modules_dir = os.path.join(self.image_rootfs, modules_dir, 
kernel_ver)
+versioned_modules_dir = os.path.join(self.image_rootfs, 
modules_dir, kernel_ver)
 
-bb.utils.mkdirhier(versioned_modules_dir)
+bb.utils.mkdirhier(versioned_modules_dir)
 
-self._exec_shell_cmd(['depmodwrapper', '-a', '-b', self.image_rootfs, 
kernel_ver])
+bb.note("Running depmodwrapper for %s ..." % versioned_modules_dir)
+self._exec_shell_cmd(['depmodwrapper', '-a', '-b', 
self.image_rootfs, kernel_ver, kernel_package_name])
 
 """
 Create devfs:
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170508): 
https://lists.openembedded.org/g/openembedded-core/message/170508
Mute This Topic: https://lists.openembedded.org/mt/93583770/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH 3/4] kernel-module-split.bbclass: Pass the kernel package name to depmodwrapper

[Andrei Gherzan]

From: Andrei Gherzan 

This makes sure that the postrm script it using the right kernel paths.

Signed-off-by: Andrei Gherzan 
---
 meta/classes-recipe/kernel-module-split.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes-recipe/kernel-module-split.bbclass 
b/meta/classes-recipe/kernel-module-split.bbclass
index 1b4c864a63..08c2e54e86 100644
--- a/meta/classes-recipe/kernel-module-split.bbclass
+++ b/meta/classes-recipe/kernel-module-split.bbclass
@@ -18,7 +18,7 @@ pkg_postrm:modules () {
 if [ -z "$D" ]; then
depmod -a ${KERNEL_VERSION}
 else
-   depmodwrapper -a -b $D ${KERNEL_VERSION}
+   depmodwrapper -a -b $D ${KERNEL_VERSION} ${KERNEL_PACKAGE_NAME}
 fi
 }
 
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170507): 
https://lists.openembedded.org/g/openembedded-core/message/170507
Mute This Topic: https://lists.openembedded.org/mt/93583769/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH 2/4] kernel.bbclass: Pass the kernel package name to depmodwrapper

[Andrei Gherzan]

From: Andrei Gherzan 

This makes sure that the postinstall script it using the right kernel
paths.

Signed-off-by: Andrei Gherzan 
---
 meta/classes-recipe/kernel.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes-recipe/kernel.bbclass 
b/meta/classes-recipe/kernel.bbclass
index de1b80d0ae..e4e69e0763 100644
--- a/meta/classes-recipe/kernel.bbclass
+++ b/meta/classes-recipe/kernel.bbclass
@@ -677,7 +677,7 @@ pkg_postinst:${KERNEL_PACKAGE_NAME}-base () {
mkdir -p $D/lib/modules/${KERNEL_VERSION}
fi
if [ -n "$D" ]; then
-   depmodwrapper -a -b $D ${KERNEL_VERSION}
+   depmodwrapper -a -b $D ${KERNEL_VERSION} ${KERNEL_PACKAGE_NAME}
else
depmod -a ${KERNEL_VERSION}
fi
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170506): 
https://lists.openembedded.org/g/openembedded-core/message/170506
Mute This Topic: https://lists.openembedded.org/mt/93583767/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH 1/4] depmodwrapper-cross: Take into consideration kernel package name

[Andrei Gherzan]

From: Andrei Gherzan 

depmodwrapper assumes that the kernel package name is "kernel". Since
this is configurable via KERNEL_PACKAGE_NAME variable, the wrapper can
easily look in the wrong place. This change adds an optional positional
argument that can be used to provide the kernel package name - when not
provided, it defaults to "kernel" (current behaviour).

Signed-off-by: Andrei Gherzan 
---
 .../kmod/depmodwrapper-cross_1.0.bb  | 16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/meta/recipes-kernel/kmod/depmodwrapper-cross_1.0.bb 
b/meta/recipes-kernel/kmod/depmodwrapper-cross_1.0.bb
index 303026ad78..6c0739d64f 100644
--- a/meta/recipes-kernel/kmod/depmodwrapper-cross_1.0.bb
+++ b/meta/recipes-kernel/kmod/depmodwrapper-cross_1.0.bb
@@ -21,13 +21,17 @@ do_install() {
 #!/bin/sh
 # Expected to be called as: depmodwrapper -a KERNEL_VERSION
 if [ "\$1" != "-a" -o "\$2" != "-b" ]; then
-echo "Usage: depmodwrapper -a -b rootfs KERNEL_VERSION" >&2
+echo "Usage: depmodwrapper -a -b rootfs KERNEL_VERSION 
[KERNEL_PACKAGE_NAME]" >&2
 exit 1
 fi
 
+kernelpkgname="kernel"
+# If no KERNEL_PACKAGE_NAME, assume "kernel".
+[ -z "\$5" ] || kernelpkgname="\$5"
+
 kernelabi=""
-if [ -r "${PKGDATA_DIR}/kernel-depmod/kernel-abiversion" ]; then
-kernelabi=\$(cat "${PKGDATA_DIR}/kernel-depmod/kernel-abiversion")
+if [ -r "${PKGDATA_DIR}/\${kernelpkgname}-depmod/\${kernelpkgname}-abiversion" 
]; then
+kernelabi=\$(cat 
"${PKGDATA_DIR}/\${kernelpkgname}-depmod/\${kernelpkgname}-abiversion")
 fi
 
 if [ ! -e "\$3${nonarch_base_libdir}/depmod.d/exclude.conf" ]; then
@@ -35,11 +39,11 @@ if [ ! -e "\$3${nonarch_base_libdir}/depmod.d/exclude.conf" 
]; then
 echo "exclude .debug" > "\$3${nonarch_base_libdir}/depmod.d/exclude.conf"
 fi
 
-if [ ! -r ${PKGDATA_DIR}/kernel-depmod/System.map-\$4 ] || [ "\$kernelabi" != 
"\$4" ]; then
-echo "Unable to read: ${PKGDATA_DIR}/kernel-depmod/System.map-\$4" >&2
+if [ ! -r ${PKGDATA_DIR}/\${kernelpkgname}-depmod/System.map-\$4 ] || [ 
"\$kernelabi" != "\$4" ]; then
+echo "Unable to read: 
${PKGDATA_DIR}/\${kernelpkgname}-depmod/System.map-\$4" >&2
 exec env depmod -C "\$3${nonarch_base_libdir}/depmod.d" "\$1" "\$2" "\$3" 
"\$4"
 else
-exec env depmod -C "\$3${nonarch_base_libdir}/depmod.d" "\$1" "\$2" "\$3" 
-F "${PKGDATA_DIR}/kernel-depmod/System.map-\$4" "\$4"
+exec env depmod -C "\$3${nonarch_base_libdir}/depmod.d" "\$1" "\$2" "\$3" 
-F "${PKGDATA_DIR}/\${kernelpkgname}-depmod/System.map-\$4" "\$4"
 fi
 EOF
chmod +x ${D}${bindir_crossscripts}/depmodwrapper
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170505): 
https://lists.openembedded.org/g/openembedded-core/message/170505
Mute This Topic: https://lists.openembedded.org/mt/93583762/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [kirkstone][PATCH] linux-yocto: Fix COMPATIBLE_MACHINE regex match

[Andrei Gherzan]

From: Andrei Gherzan 

With the current regex expression, a machine that is not part of the
compatible could match the regex expression.

For example, consider the following COMPATIBLE_MACHINE:

COMPATIBLE_MACHINE = "qemuarm|qemuarm64"

A machine definition bringing in "qemuarm-foo" would match against the
COMPATIBLE_MACHINE pattern above (see base.bbclass for implementation
details).

Fix this by matching the start and the end of the string.

Signed-off-by: Andrei Gherzan 
---
 meta/recipes-kernel/linux/linux-yocto-dev.bb   | 2 +-
 meta/recipes-kernel/linux/linux-yocto-rt_5.10.bb   | 2 +-
 meta/recipes-kernel/linux/linux-yocto-rt_5.15.bb   | 2 +-
 meta/recipes-kernel/linux/linux-yocto-tiny_5.10.bb | 2 +-
 meta/recipes-kernel/linux/linux-yocto-tiny_5.15.bb | 2 +-
 meta/recipes-kernel/linux/linux-yocto_5.10.bb  | 2 +-
 meta/recipes-kernel/linux/linux-yocto_5.15.bb  | 2 +-
 7 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/meta/recipes-kernel/linux/linux-yocto-dev.bb 
b/meta/recipes-kernel/linux/linux-yocto-dev.bb
index d35632071b..75b1cb2a49 100644
--- a/meta/recipes-kernel/linux/linux-yocto-dev.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-dev.bb
@@ -50,7 +50,7 @@ PACKAGECONFIG[dt-validation] = ",,python3-dtschema-native"
 # we need the wrappers if validation isn't in the packageconfig
 DEPENDS += "${@bb.utils.contains('PACKAGECONFIG', 'dt-validation', '', 
'python3-dtschema-wrapper-native', d)}"
 
-COMPATIBLE_MACHINE = 
"(qemuarm|qemux86|qemuppc|qemumips|qemumips64|qemux86-64|qemuriscv32|qemuriscv64)"
+COMPATIBLE_MACHINE = 
"^(qemuarm|qemux86|qemuppc|qemumips|qemumips64|qemux86-64|qemuriscv32|qemuriscv64)$"
 
 KERNEL_DEVICETREE:qemuarmv5 = "versatile-pb.dtb"
 
diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_5.10.bb 
b/meta/recipes-kernel/linux/linux-yocto-rt_5.10.bb
index 9387c67cfb..aac5e97657 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_5.10.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_5.10.bb
@@ -31,7 +31,7 @@ KCONF_BSP_AUDIT_LEVEL = "1"
 
 LINUX_KERNEL_TYPE = "preempt-rt"
 
-COMPATIBLE_MACHINE = 
"(qemux86|qemux86-64|qemuarm|qemuarmv5|qemuarm64|qemuppc|qemumips)"
+COMPATIBLE_MACHINE = 
"^(qemux86|qemux86-64|qemuarm|qemuarmv5|qemuarm64|qemuppc|qemumips)$"
 
 KERNEL_DEVICETREE:qemuarmv5 = "versatile-pb.dtb"
 
diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_5.15.bb 
b/meta/recipes-kernel/linux/linux-yocto-rt_5.15.bb
index 32c7db2c74..61200cc456 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_5.15.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_5.15.bb
@@ -31,7 +31,7 @@ KCONF_BSP_AUDIT_LEVEL = "1"
 
 LINUX_KERNEL_TYPE = "preempt-rt"
 
-COMPATIBLE_MACHINE = 
"(qemux86|qemux86-64|qemuarm|qemuarmv5|qemuarm64|qemuppc|qemumips)"
+COMPATIBLE_MACHINE = 
"^(qemux86|qemux86-64|qemuarm|qemuarmv5|qemuarm64|qemuppc|qemumips)$"
 
 KERNEL_DEVICETREE:qemuarmv5 = "versatile-pb.dtb"
 
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_5.10.bb 
b/meta/recipes-kernel/linux/linux-yocto-tiny_5.10.bb
index d7aa3281cc..d9b5e00378 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_5.10.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_5.10.bb
@@ -24,7 +24,7 @@ PV = "${LINUX_VERSION}+git${SRCPV}"
 SRC_URI = 
"git://git.yoctoproject.org/linux-yocto.git;branch=${KBRANCH};name=machine \

git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-5.10;destsuffix=${KMETA}"
 
-COMPATIBLE_MACHINE = "qemux86|qemux86-64|qemuarm|qemuarmv5"
+COMPATIBLE_MACHINE = "^(qemux86|qemux86-64|qemuarm|qemuarmv5)$"
 
 # Functionality flags
 KERNEL_FEATURES = ""
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_5.15.bb 
b/meta/recipes-kernel/linux/linux-yocto-tiny_5.15.bb
index 8eb138e78b..0707b41494 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_5.15.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_5.15.bb
@@ -22,7 +22,7 @@ PV = "${LINUX_VERSION}+git${SRCPV}"
 SRC_URI = 
"git://git.yoctoproject.org/linux-yocto.git;branch=${KBRANCH};name=machine \

git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-5.15;destsuffix=${KMETA}"
 
-COMPATIBLE_MACHINE = "qemux86|qemux86-64|qemuarm64|qemuarm|qemuarmv5"
+COMPATIBLE_MACHINE = "^(qemux86|qemux86-64|qemuarm64|qemuarm|qemuarmv5)$"
 
 # Functionality flags
 KERNEL_FEATURES = ""
diff --git a/meta/recipes-kernel/linux/linux-yocto_5.10.bb 
b/meta/recipes-kernel/linux/linux-yocto_5.10.bb
index 73a58e59a0..bc4430cc1c 100644
--- a/meta/recipes-kernel/linux/linux-yocto_5.10.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_5.10.bb
@@ -42,7 +42,7 @@ KCONF_BSP_AUDIT_LEVEL = "1"
 
 KERNEL_DEVICETREE:qemuarmv5 = "versatile-pb.dtb"
 
-COMPATIBLE_MACHINE = 
"qemuarm|qemua

[OE-core] [PATCH] linux-yocto: Fix COMPATIBLE_MACHINE regex match

[Andrei Gherzan]

From: Andrei Gherzan 

With the current regex expression, a machine that is not part of the
compatible could match the regex expression.

For example, consider the following COMPATIBLE_MACHINE:

COMPATIBLE_MACHINE = "qemuarm|qemuarm64"

A machine definition bringing in "qemuarm-foo" would match against the
COMPATIBLE_MACHINE pattern above (see base.bbclass for implementation
details).

Fix this by matching the start and the end of the string.

Signed-off-by: Andrei Gherzan 
---
 meta/recipes-kernel/linux/linux-yocto-dev.bb   | 2 +-
 meta/recipes-kernel/linux/linux-yocto-rt_5.15.bb   | 2 +-
 meta/recipes-kernel/linux/linux-yocto-rt_5.19.bb   | 2 +-
 meta/recipes-kernel/linux/linux-yocto-tiny_5.15.bb | 2 +-
 meta/recipes-kernel/linux/linux-yocto-tiny_5.19.bb | 2 +-
 meta/recipes-kernel/linux/linux-yocto_5.15.bb  | 2 +-
 meta/recipes-kernel/linux/linux-yocto_5.19.bb  | 2 +-
 7 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/meta/recipes-kernel/linux/linux-yocto-dev.bb 
b/meta/recipes-kernel/linux/linux-yocto-dev.bb
index 5a420b7fb2..b1b57beac3 100644
--- a/meta/recipes-kernel/linux/linux-yocto-dev.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-dev.bb
@@ -50,7 +50,7 @@ PACKAGECONFIG[dt-validation] = ",,python3-dtschema-native"
 # we need the wrappers if validation isn't in the packageconfig
 DEPENDS += "${@bb.utils.contains('PACKAGECONFIG', 'dt-validation', '', 
'python3-dtschema-wrapper-native', d)}"
 
-COMPATIBLE_MACHINE = 
"(qemuarm|qemux86|qemuppc|qemumips|qemumips64|qemux86-64|qemuriscv32|qemuriscv64)"
+COMPATIBLE_MACHINE = 
"^(qemuarm|qemux86|qemuppc|qemumips|qemumips64|qemux86-64|qemuriscv32|qemuriscv64)$"
 
 KERNEL_DEVICETREE:qemuarmv5 = "versatile-pb.dtb"
 
diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_5.15.bb 
b/meta/recipes-kernel/linux/linux-yocto-rt_5.15.bb
index f374fb593f..9e37494a4b 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_5.15.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_5.15.bb
@@ -31,7 +31,7 @@ KCONF_BSP_AUDIT_LEVEL = "1"
 
 LINUX_KERNEL_TYPE = "preempt-rt"
 
-COMPATIBLE_MACHINE = 
"(qemux86|qemux86-64|qemuarm|qemuarmv5|qemuarm64|qemuppc|qemumips)"
+COMPATIBLE_MACHINE = 
"^(qemux86|qemux86-64|qemuarm|qemuarmv5|qemuarm64|qemuppc|qemumips)$"
 
 KERNEL_DEVICETREE:qemuarmv5 = "versatile-pb.dtb"
 
diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_5.19.bb 
b/meta/recipes-kernel/linux/linux-yocto-rt_5.19.bb
index 60ca638bdd..c12bec3e4e 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_5.19.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_5.19.bb
@@ -31,7 +31,7 @@ KCONF_BSP_AUDIT_LEVEL = "1"
 
 LINUX_KERNEL_TYPE = "preempt-rt"
 
-COMPATIBLE_MACHINE = 
"(qemux86|qemux86-64|qemuarm|qemuarmv5|qemuarm64|qemuppc|qemumips)"
+COMPATIBLE_MACHINE = 
"^(qemux86|qemux86-64|qemuarm|qemuarmv5|qemuarm64|qemuppc|qemumips)$"
 
 KERNEL_DEVICETREE:qemuarmv5 = "versatile-pb.dtb"
 
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_5.15.bb 
b/meta/recipes-kernel/linux/linux-yocto-tiny_5.15.bb
index f1b6f98c77..2de32ffecd 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_5.15.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_5.15.bb
@@ -22,7 +22,7 @@ PV = "${LINUX_VERSION}+git${SRCPV}"
 SRC_URI = 
"git://git.yoctoproject.org/linux-yocto.git;branch=${KBRANCH};name=machine \

git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-5.15;destsuffix=${KMETA}"
 
-COMPATIBLE_MACHINE = "qemux86|qemux86-64|qemuarm64|qemuarm|qemuarmv5"
+COMPATIBLE_MACHINE = "^(qemux86|qemux86-64|qemuarm64|qemuarm|qemuarmv5)$"
 
 # Functionality flags
 KERNEL_FEATURES = ""
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_5.19.bb 
b/meta/recipes-kernel/linux/linux-yocto-tiny_5.19.bb
index c1638f5cc2..339f7f69a6 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_5.19.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_5.19.bb
@@ -22,7 +22,7 @@ PV = "${LINUX_VERSION}+git${SRCPV}"
 SRC_URI = 
"git://git.yoctoproject.org/linux-yocto.git;branch=${KBRANCH};name=machine \

git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-5.19;destsuffix=${KMETA}"
 
-COMPATIBLE_MACHINE = "qemux86|qemux86-64|qemuarm64|qemuarm|qemuarmv5"
+COMPATIBLE_MACHINE = "^(qemux86|qemux86-64|qemuarm64|qemuarm|qemuarmv5)$"
 
 # Functionality flags
 KERNEL_FEATURES = ""
diff --git a/meta/recipes-kernel/linux/linux-yocto_5.15.bb 
b/meta/recipes-kernel/linux/linux-yocto_5.15.bb
index 26cdfb744a..40c430aee3 100644
--- a/meta/recipes-kernel/linux/linux-yocto_5.15.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_5.15.bb
@@ -51,7 +51,7 @@ KCONF_BSP_AUDIT_LEVEL = "1"
 
 KERNEL_DEVICETREE:qemuarmv5 = "versatile-pb.dtb"
 
-COMPATIBLE_MACHINE = 
"

[OE-core] [kirkstone][PATCH 3/3] shadow: Avoid nss warning/error with musl

[Andrei Gherzan]

From: Andrei Gherzan 

The libnss configuration file is only installed when glibc is used. The
inexistence of it on a musl-based rootfs, will make shadow complain
about it:

Failed opening /etc/nsswitch.conf

This is because shadow will try to use nsswich when dealing with
subordinate IDs and the message is just a warning as the tool will still
generate them correctly in subuid/subgid files.

We drop this log message for class native to avoid an error when rootfs
logs are checked ('Failed' will match the regex bitbake is using to
check for rootfs generation errors).

Signed-off-by: Andrei Gherzan 
---
 ...f-message-when-not-in-place-eg.-musl.patch | 27 +++
 meta/recipes-extended/shadow/shadow.inc   |  2 ++
 2 files changed, 29 insertions(+)
 create mode 100644 
meta/recipes-extended/shadow/files/0001-Drop-nsswitch.conf-message-when-not-in-place-eg.-musl.patch

diff --git 
a/meta/recipes-extended/shadow/files/0001-Drop-nsswitch.conf-message-when-not-in-place-eg.-musl.patch
 
b/meta/recipes-extended/shadow/files/0001-Drop-nsswitch.conf-message-when-not-in-place-eg.-musl.patch
new file mode 100644
index 00..6c04769713
--- /dev/null
+++ 
b/meta/recipes-extended/shadow/files/0001-Drop-nsswitch.conf-message-when-not-in-place-eg.-musl.patch
@@ -0,0 +1,27 @@
+From aed5a184401fbbe901cb825be4004ced885b6f9a Mon Sep 17 00:00:00 2001
+From: Andrei Gherzan 
+Date: Wed, 24 Aug 2022 00:54:47 +0200
+Subject: [PATCH] Drop nsswitch.conf message when not in place - eg. musl
+
+Upstream-Status: Inappropriate [issue reported at 
https://github.com/shadow-maint/shadow/issues/557]
+Signed-off-by: Andrei Gherzan 
+---
+ lib/nss.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/lib/nss.c b/lib/nss.c
+index af3e95a..74e0e16 100644
+--- a/lib/nss.c
 b/lib/nss.c
+@@ -57,7 +57,7 @@ void nss_init(char *nsswitch_path) {
+   //   subid: files
+   nssfp = fopen(nsswitch_path, "r");
+   if (!nssfp) {
+-  fprintf(shadow_logfd, "Failed opening %s: %m", nsswitch_path);
++  //fprintf(shadow_logfd, "Failed opening %s: %m", nsswitch_path);
+   atomic_store(_init_completed, true);
+   return;
+   }
+-- 
+2.25.1
+
diff --git a/meta/recipes-extended/shadow/shadow.inc 
b/meta/recipes-extended/shadow/shadow.inc
index b3ae2b4874..5106b95571 100644
--- a/meta/recipes-extended/shadow/shadow.inc
+++ b/meta/recipes-extended/shadow/shadow.inc
@@ -26,6 +26,7 @@ SRC_URI:append:class-target = " \
 SRC_URI:append:class-native = " \
file://0001-Disable-use-of-syslog-for-sysroot.patch \
file://commonio.c-fix-unexpected-open-failure-in-chroot-env.patch \
+   
file://0001-Drop-nsswitch.conf-message-when-not-in-place-eg.-musl.patch \
"
 SRC_URI:append:class-nativesdk = " \
file://0001-Disable-use-of-syslog-for-sysroot.patch \
@@ -33,6 +34,7 @@ SRC_URI:append:class-nativesdk = " \
 
 SRC_URI[sha256sum] = 
"f262089be6a1011d50ec7849e14571b7b2e788334368f3dccb718513f17935ed"
 
+
 # Additional Policy files for PAM
 PAM_SRC_URI = "file://pam.d/chfn \
file://pam.d/chpasswd \
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#169882): 
https://lists.openembedded.org/g/openembedded-core/message/169882
Mute This Topic: https://lists.openembedded.org/mt/93252114/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [kirkstone][PATCH 2/3] rootfspostcommands.py: Cleanup subid backup files generated by shadow-utils

[Andrei Gherzan]

From: Andrei Gherzan 

When creating users, shadow-utils might create backup files for
subordinate ID files (subid, subgid). Make sure we clean them up
similarly to the other backup files shadow-utils creates.

This is a backport from master that brings in only the cleanup of the
subid backup files without the code restructure.

Signed-off-by: Andrei Gherzan 
---
 meta/lib/rootfspostcommands.py | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/meta/lib/rootfspostcommands.py b/meta/lib/rootfspostcommands.py
index fdb9f5b850..12f66d2ce2 100644
--- a/meta/lib/rootfspostcommands.py
+++ b/meta/lib/rootfspostcommands.py
@@ -58,3 +58,10 @@ def sort_passwd(sysconfdir):
 remove_backup(filename)
 if os.path.exists(filename):
  sort_file(filename, mapping)
+# Drop other known backup shadow-utils.
+for filename in (
+'subgid',
+'subuid',
+):
+filepath = os.path.join(sysconfdir, filename)
+remove_backup(filepath)
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#169881): 
https://lists.openembedded.org/g/openembedded-core/message/169881
Mute This Topic: https://lists.openembedded.org/mt/93252113/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [kirkstone][PATCH 1/3] shadow: Enable subid support

[Andrei Gherzan]

From: Andrei Gherzan 

shadow utils are used when creating users at image creation time. The
useradd/usermod tools will only try to add a default configuration for
subid files if they exist.

Signed-off-by: Andrei Gherzan 
---
 meta/recipes-extended/shadow/shadow.inc | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/meta/recipes-extended/shadow/shadow.inc 
b/meta/recipes-extended/shadow/shadow.inc
index f5fdf436f7..b3ae2b4874 100644
--- a/meta/recipes-extended/shadow/shadow.inc
+++ b/meta/recipes-extended/shadow/shadow.inc
@@ -149,6 +149,13 @@ do_install:append() {
# Handle link properly after rename, otherwise missing files would
# lead rpm failed dependencies.
ln -sf newgrp.${BPN} ${D}${bindir}/sg
+
+   # usermod requires the subuid/subgid files to be in place before being
+   # able to use the -v/-V flags otherwise it fails:
+   # usermod: /etc/subuid does not exist, you cannot use the flags -v or -V
+   install -d ${D}${sysconfdir}
+   touch ${D}${sysconfdir}/subuid
+   touch ${D}${sysconfdir}/subgid
 }
 
 PACKAGES =+ "${PN}-base"
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#169880): 
https://lists.openembedded.org/g/openembedded-core/message/169880
Mute This Topic: https://lists.openembedded.org/mt/93252112/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH 6/6] shadow: Avoid nss warning/error with musl

[Andrei Gherzan]

On Wed, 24 Aug 2022, at 10:39, Alexander Kanavin wrote:
> Almost there :) As the patch was not actually submitted, the correct
> metadata is:
>
> Upstream-Status: Inappropriate [issue reported at
> https://github.com/shadow-maint/shadow/issues/557]

Now I know :)

https://lists.openembedded.org/g/openembedded-core/message/169804

Andrei

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#169805): 
https://lists.openembedded.org/g/openembedded-core/message/169805
Mute This Topic: https://lists.openembedded.org/mt/93217143/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH v3 6/6] shadow: Avoid nss warning/error with musl

[Andrei Gherzan]

From: Andrei Gherzan 

The libnss configuration file is only installed when glibc is used. The
inexistence of it on a musl-based rootfs, will make shadow complain
about it:

Failed opening /etc/nsswitch.conf

This is because shadow will try to use nsswich when dealing with
subordinate IDs and the message is just a warning as the tool will still
generate them correctly in subuid/subgid files.

We drop this log message for class native to avoid an error when rootfs
logs are checked ('Failed' will match the regex bitbake is using to
check for rootfs generation errors).

Signed-off-by: Andrei Gherzan 
---
 ...f-message-when-not-in-place-eg.-musl.patch | 27 +++
 meta/recipes-extended/shadow/shadow.inc   |  2 ++
 2 files changed, 29 insertions(+)
 create mode 100644 
meta/recipes-extended/shadow/files/0001-Drop-nsswitch.conf-message-when-not-in-place-eg.-musl.patch

diff --git 
a/meta/recipes-extended/shadow/files/0001-Drop-nsswitch.conf-message-when-not-in-place-eg.-musl.patch
 
b/meta/recipes-extended/shadow/files/0001-Drop-nsswitch.conf-message-when-not-in-place-eg.-musl.patch
new file mode 100644
index 00..21c9a1415c
--- /dev/null
+++ 
b/meta/recipes-extended/shadow/files/0001-Drop-nsswitch.conf-message-when-not-in-place-eg.-musl.patch
@@ -0,0 +1,27 @@
+From 11290e897a49adddee215833944a518443d9b0d6 Mon Sep 17 00:00:00 2001
+From: Andrei Gherzan 
+Date: Wed, 24 Aug 2022 00:54:47 +0200
+Subject: [PATCH] Drop nsswitch.conf message when not in place - eg. musl
+
+Upstream-Status: Inappropriate [issue reported at 
https://github.com/shadow-maint/shadow/issues/557]
+Signed-off-by: Andrei Gherzan 
+---
+ lib/nss.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/lib/nss.c b/lib/nss.c
+index 06fa48e..44245da 100644
+--- a/lib/nss.c
 b/lib/nss.c
+@@ -59,7 +59,7 @@ void nss_init(const char *nsswitch_path) {
+   //   subid: files
+   nssfp = fopen(nsswitch_path, "r");
+   if (!nssfp) {
+-  fprintf(shadow_logfd, "Failed opening %s: %m\n", nsswitch_path);
++  //fprintf(shadow_logfd, "Failed opening %s: %m\n", 
nsswitch_path);
+   atomic_store(_init_completed, true);
+   return;
+   }
+-- 
+2.25.1
+
diff --git a/meta/recipes-extended/shadow/shadow.inc 
b/meta/recipes-extended/shadow/shadow.inc
index b2f82e9ac7..414bf467ba 100644
--- a/meta/recipes-extended/shadow/shadow.inc
+++ b/meta/recipes-extended/shadow/shadow.inc
@@ -25,12 +25,14 @@ SRC_URI:append:class-target = " \
 SRC_URI:append:class-native = " \
file://0001-Disable-use-of-syslog-for-sysroot.patch \
file://commonio.c-fix-unexpected-open-failure-in-chroot-env.patch \
+   
file://0001-Drop-nsswitch.conf-message-when-not-in-place-eg.-musl.patch \
"
 SRC_URI:append:class-nativesdk = " \
file://0001-Disable-use-of-syslog-for-sysroot.patch \
"
 SRC_URI[sha256sum] = 
"9fdb73b5d2b44e8ba9fcee1b4493ac75dd5040bda35b9ac8b06570cd192e7ee3"
 
+
 # Additional Policy files for PAM
 PAM_SRC_URI = "file://pam.d/chfn \
file://pam.d/chpasswd \
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#169804): 
https://lists.openembedded.org/g/openembedded-core/message/169804
Mute This Topic: https://lists.openembedded.org/mt/93223361/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH v3 1/6] shadow: Enable subid support

[Andrei Gherzan]

From: Andrei Gherzan 

shadow utils are used when creating users at image creation time. The
useradd/usermod tools will only try to add a default configuration for
subid files if they exist.

Signed-off-by: Andrei Gherzan 
---
 meta/recipes-extended/shadow/shadow.inc | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/meta/recipes-extended/shadow/shadow.inc 
b/meta/recipes-extended/shadow/shadow.inc
index fbb1d395ff..b2f82e9ac7 100644
--- a/meta/recipes-extended/shadow/shadow.inc
+++ b/meta/recipes-extended/shadow/shadow.inc
@@ -147,6 +147,13 @@ do_install:append() {
# Handle link properly after rename, otherwise missing files would
# lead rpm failed dependencies.
ln -sf newgrp.${BPN} ${D}${bindir}/sg
+
+   # usermod requires the subuid/subgid files to be in place before being
+   # able to use the -v/-V flags otherwise it fails:
+   # usermod: /etc/subuid does not exist, you cannot use the flags -v or -V
+   install -d ${D}${sysconfdir}
+   touch ${D}${sysconfdir}/subuid
+   touch ${D}${sysconfdir}/subgid
 }
 
 PACKAGES =+ "${PN}-base"
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#169803): 
https://lists.openembedded.org/g/openembedded-core/message/169803
Mute This Topic: https://lists.openembedded.org/mt/93223357/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH 6/6] shadow: Avoid nss warning/error with musl

[Andrei Gherzan]

On Wed, 24 Aug 2022, at 09:56, Alexander Kanavin wrote:
> Thanks, can you also resend the patch with the link to the ticket included?

Sure. https://lists.openembedded.org/g/openembedded-core/message/169800

Andrei

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#169801): 
https://lists.openembedded.org/g/openembedded-core/message/169801
Mute This Topic: https://lists.openembedded.org/mt/93217143/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH v2 6/6] shadow: Avoid nss warning/error with musl

[Andrei Gherzan]

From: Andrei Gherzan 

The libnss configuration file is only installed when glibc is used. The
inexistence of it on a musl-based rootfs, will make shadow complain
about it:

Failed opening /etc/nsswitch.conf

This is because shadow will try to use nsswich when dealing with
subordinate IDs and the message is just a warning as the tool will still
generate them correctly in subuid/subgid files.

We drop this log message for class native to avoid an error when rootfs
logs are checked ('Failed' will match the regex bitbake is using to
check for rootfs generation errors).

Signed-off-by: Andrei Gherzan 
---
 ...f-message-when-not-in-place-eg.-musl.patch | 27 +++
 meta/recipes-extended/shadow/shadow.inc   |  2 ++
 2 files changed, 29 insertions(+)
 create mode 100644 
meta/recipes-extended/shadow/files/0001-Drop-nsswitch.conf-message-when-not-in-place-eg.-musl.patch

diff --git 
a/meta/recipes-extended/shadow/files/0001-Drop-nsswitch.conf-message-when-not-in-place-eg.-musl.patch
 
b/meta/recipes-extended/shadow/files/0001-Drop-nsswitch.conf-message-when-not-in-place-eg.-musl.patch
new file mode 100644
index 00..895c09e738
--- /dev/null
+++ 
b/meta/recipes-extended/shadow/files/0001-Drop-nsswitch.conf-message-when-not-in-place-eg.-musl.patch
@@ -0,0 +1,27 @@
+From 11290e897a49adddee215833944a518443d9b0d6 Mon Sep 17 00:00:00 2001
+From: Andrei Gherzan 
+Date: Wed, 24 Aug 2022 00:54:47 +0200
+Subject: [PATCH] Drop nsswitch.conf message when not in place - eg. musl
+
+Upstream-Status: Submitted [https://github.com/shadow-maint/shadow/issues/557]
+Signed-off-by: Andrei Gherzan 
+---
+ lib/nss.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/lib/nss.c b/lib/nss.c
+index 06fa48e..44245da 100644
+--- a/lib/nss.c
 b/lib/nss.c
+@@ -59,7 +59,7 @@ void nss_init(const char *nsswitch_path) {
+   //   subid: files
+   nssfp = fopen(nsswitch_path, "r");
+   if (!nssfp) {
+-  fprintf(shadow_logfd, "Failed opening %s: %m\n", nsswitch_path);
++  //fprintf(shadow_logfd, "Failed opening %s: %m\n", 
nsswitch_path);
+   atomic_store(_init_completed, true);
+   return;
+   }
+-- 
+2.25.1
+
diff --git a/meta/recipes-extended/shadow/shadow.inc 
b/meta/recipes-extended/shadow/shadow.inc
index b2f82e9ac7..414bf467ba 100644
--- a/meta/recipes-extended/shadow/shadow.inc
+++ b/meta/recipes-extended/shadow/shadow.inc
@@ -25,12 +25,14 @@ SRC_URI:append:class-target = " \
 SRC_URI:append:class-native = " \
file://0001-Disable-use-of-syslog-for-sysroot.patch \
file://commonio.c-fix-unexpected-open-failure-in-chroot-env.patch \
+   
file://0001-Drop-nsswitch.conf-message-when-not-in-place-eg.-musl.patch \
"
 SRC_URI:append:class-nativesdk = " \
file://0001-Disable-use-of-syslog-for-sysroot.patch \
"
 SRC_URI[sha256sum] = 
"9fdb73b5d2b44e8ba9fcee1b4493ac75dd5040bda35b9ac8b06570cd192e7ee3"
 
+
 # Additional Policy files for PAM
 PAM_SRC_URI = "file://pam.d/chfn \
file://pam.d/chpasswd \
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#169800): 
https://lists.openembedded.org/g/openembedded-core/message/169800
Mute This Topic: https://lists.openembedded.org/mt/93223305/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH 6/6] shadow: Avoid nss warning/error with musl

[Andrei Gherzan]

On Wed, 24 Aug 2022, at 09:30, Alexander Kanavin wrote:
> I trust the upstream will figure this out. My goal is to avoid adding
> more patches that are declared unsuitable for upstream, and so have to
> be rebased until the end of time by (usually) me.

OK. I have created an upstream issue: 
https://github.com/shadow-maint/shadow/issues/557.

Andrei

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#169794): 
https://lists.openembedded.org/g/openembedded-core/message/169794
Mute This Topic: https://lists.openembedded.org/mt/93217143/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH 6/6] shadow: Avoid nss warning/error with musl

[Andrei Gherzan]

On Wed, 24 Aug 2022, at 09:21, Alexander Kanavin wrote:
> The issue is described by you in the commit message? I think this is
> good enough for upstream submission as is, as long as you edit out the
> yocto specific references.

RIght. I was more interested in how you see this issue per se. At the end of 
the day, it is not a bug, it is more of a warning/log message while the 
functionality is in place. What would you expect upstream to do?

Of course, there are a couple of options here. Compile macro for musl, change 
the log format for that specific message, etc. But it can also be treated as a 
dynamic check with an associated log message.

Andrei

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#169787): 
https://lists.openembedded.org/g/openembedded-core/message/169787
Mute This Topic: https://lists.openembedded.org/mt/93217143/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH 6/6] shadow: Avoid nss warning/error with musl

[Andrei Gherzan]

On Wed, 24 Aug 2022, at 08:36, Alexander Kanavin wrote:
> I do not think it is inappropriate, as it does highlight an issue
> which we need to inform upstream about. Can you submit it upstream
> anyway please?

Just to be sure we have the same understanding, could you detail the issue you 
are seeing?

Andrei

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#169785): 
https://lists.openembedded.org/g/openembedded-core/message/169785
Mute This Topic: https://lists.openembedded.org/mt/93217143/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH 6/6] shadow: Avoid nss warning/error with musl

[Andrei Gherzan]

From: Andrei Gherzan 

The libnss configuration file is only installed when glibc is used. The
inexistence of it on a musl-based rootfs, will make shadow complain
about it:

Failed opening /etc/nsswitch.conf

This is because shadow will try to use nsswich when dealing with
subordinate IDs and the message is just a warning as the tool will still
generate them correctly in subuid/subgid files.

We drop this log message for class native to avoid an error when rootfs
logs are checked ('Failed' will match the regex bitbake is using to
check for rootfs generation errors).

Signed-off-by: Andrei Gherzan 
---
 ...f-message-when-not-in-place-eg.-musl.patch | 27 +++
 meta/recipes-extended/shadow/shadow.inc   |  2 ++
 2 files changed, 29 insertions(+)
 create mode 100644 
meta/recipes-extended/shadow/files/0001-Drop-nsswitch.conf-message-when-not-in-place-eg.-musl.patch

diff --git 
a/meta/recipes-extended/shadow/files/0001-Drop-nsswitch.conf-message-when-not-in-place-eg.-musl.patch
 
b/meta/recipes-extended/shadow/files/0001-Drop-nsswitch.conf-message-when-not-in-place-eg.-musl.patch
new file mode 100644
index 00..aeb89ff6a0
--- /dev/null
+++ 
b/meta/recipes-extended/shadow/files/0001-Drop-nsswitch.conf-message-when-not-in-place-eg.-musl.patch
@@ -0,0 +1,27 @@
+From 11290e897a49adddee215833944a518443d9b0d6 Mon Sep 17 00:00:00 2001
+From: Andrei Gherzan 
+Date: Wed, 24 Aug 2022 00:54:47 +0200
+Subject: [PATCH] Drop nsswitch.conf message when not in place - eg. musl
+
+Upstream-Status: Inappropriate [OE specific]
+Signed-off-by: Andrei Gherzan 
+---
+ lib/nss.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/lib/nss.c b/lib/nss.c
+index 06fa48e..44245da 100644
+--- a/lib/nss.c
 b/lib/nss.c
+@@ -59,7 +59,7 @@ void nss_init(const char *nsswitch_path) {
+   //   subid: files
+   nssfp = fopen(nsswitch_path, "r");
+   if (!nssfp) {
+-  fprintf(shadow_logfd, "Failed opening %s: %m\n", nsswitch_path);
++  //fprintf(shadow_logfd, "Failed opening %s: %m\n", 
nsswitch_path);
+   atomic_store(_init_completed, true);
+   return;
+   }
+-- 
+2.25.1
+
diff --git a/meta/recipes-extended/shadow/shadow.inc 
b/meta/recipes-extended/shadow/shadow.inc
index b2f82e9ac7..414bf467ba 100644
--- a/meta/recipes-extended/shadow/shadow.inc
+++ b/meta/recipes-extended/shadow/shadow.inc
@@ -25,12 +25,14 @@ SRC_URI:append:class-target = " \
 SRC_URI:append:class-native = " \
file://0001-Disable-use-of-syslog-for-sysroot.patch \
file://commonio.c-fix-unexpected-open-failure-in-chroot-env.patch \
+   
file://0001-Drop-nsswitch.conf-message-when-not-in-place-eg.-musl.patch \
"
 SRC_URI:append:class-nativesdk = " \
file://0001-Disable-use-of-syslog-for-sysroot.patch \
"
 SRC_URI[sha256sum] = 
"9fdb73b5d2b44e8ba9fcee1b4493ac75dd5040bda35b9ac8b06570cd192e7ee3"
 
+
 # Additional Policy files for PAM
 PAM_SRC_URI = "file://pam.d/chfn \
file://pam.d/chpasswd \
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#169767): 
https://lists.openembedded.org/g/openembedded-core/message/169767
Mute This Topic: https://lists.openembedded.org/mt/93217143/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH 5/6] rootfs-postcommands.bbclass: Follow function rename in rootfspostcommands.py

[Andrei Gherzan]

From: Andrei Gherzan 

'shadow_sort' was renamed to 'tidy_shadowutils_files' in
rootfspostcommands.py so we reflect this in
SORT_PASSWD_POSTPROCESS_COMMAND. This also creates a deprecation
function for 'shadow_sort'.

Signed-off-by: Andrei Gherzan 
---
 meta/classes-recipe/rootfs-postcommands.bbclass | 15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/meta/classes-recipe/rootfs-postcommands.bbclass 
b/meta/classes-recipe/rootfs-postcommands.bbclass
index bf1e992bb2..215e38e33d 100644
--- a/meta/classes-recipe/rootfs-postcommands.bbclass
+++ b/meta/classes-recipe/rootfs-postcommands.bbclass
@@ -63,7 +63,7 @@ inherit image-artifact-names
 # systemd_sysusers_create and set_user_group. Using :append is not
 # enough for that, set_user_group is added that way and would end
 # up running after us.
-SORT_PASSWD_POSTPROCESS_COMMAND ??= " sort_passwd; "
+SORT_PASSWD_POSTPROCESS_COMMAND ??= " tidy_shadowutils_files; "
 python () {
 d.appendVar('ROOTFS_POSTPROCESS_COMMAND', 
'${SORT_PASSWD_POSTPROCESS_COMMAND}')
 d.appendVar('ROOTFS_POSTPROCESS_COMMAND', 'rootfs_reproducible;')
@@ -221,9 +221,20 @@ serial_autologin_root () {
fi
 }
 
+python tidy_shadowutils_files () {
+import rootfspostcommands
+
rootfspostcommands.tidy_shadowutils_files(d.expand('${IMAGE_ROOTFS}${sysconfdir}'))
+}
+
 python sort_passwd () {
+"""
+Deprecated in the favour of tidy_shadowutils_files.
+"""
 import rootfspostcommands
-rootfspostcommands.sort_passwd(d.expand('${IMAGE_ROOTFS}${sysconfdir}'))
+bb.warn('[sort_passwd] You are using a deprecated function for '
+'SORT_PASSWD_POSTPROCESS_COMMAND. The default one is now called '
+'"tidy_shadowutils_files".')
+
rootfspostcommands.tidy_shadowutils_files(d.expand('${IMAGE_ROOTFS}${sysconfdir}'))
 }
 
 #
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#169766): 
https://lists.openembedded.org/g/openembedded-core/message/169766
Mute This Topic: https://lists.openembedded.org/mt/93217141/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH 4/6] selftest: Add module for testing rootfs postcommands

[Andrei Gherzan]

From: Andrei Gherzan 

The initial implementation adds tests for 'tidy_shadowutils_files'.

Signed-off-by: Andrei Gherzan 
---
 .../selftest/cases/rootfspostcommandstests.py | 97 +++
 1 file changed, 97 insertions(+)
 create mode 100644 meta/lib/oeqa/selftest/cases/rootfspostcommandstests.py

diff --git a/meta/lib/oeqa/selftest/cases/rootfspostcommandstests.py 
b/meta/lib/oeqa/selftest/cases/rootfspostcommandstests.py
new file mode 100644
index 00..44e2c09a6f
--- /dev/null
+++ b/meta/lib/oeqa/selftest/cases/rootfspostcommandstests.py
@@ -0,0 +1,97 @@
+# SPDX-FileCopyrightText: Huawei Inc.
+#
+# SPDX-License-Identifier: MIT
+
+import os
+import oe
+import unittest
+from oeqa.selftest.case import OESelftestTestCase
+from oeqa.utils.commands import bitbake, get_bb_vars
+
+class ShadowUtilsTidyFiles(OESelftestTestCase):
+"""
+Check if shadow image rootfs files are tidy.
+
+The tests are focused on testing the functionality provided by the
+'tidy_shadowutils_files' rootfs postprocess command (via
+SORT_PASSWD_POSTPROCESS_COMMAND).
+"""
+
+def sysconf_build(self):
+"""
+Verify if shadow tidy files tests are to be run and if yes, build a
+test image and return its sysconf rootfs path.
+"""
+
+test_image = "core-image-minimal"
+
+config = 'IMAGE_CLASSES += "extrausers"\n'
+config += 'EXTRA_USERS_PARAMS = "groupadd -g 1000 oeqatester; "\n'
+config += 'EXTRA_USERS_PARAMS += "useradd -p \'\' -u 1000 -N -g 1000 
oeqatester; "\n'
+self.write_config(config)
+
+vars = get_bb_vars(("IMAGE_ROOTFS", "SORT_PASSWD_POSTPROCESS_COMMAND", 
"sysconfdir"),
+test_image)
+passwd_postprocess_cmd = vars["SORT_PASSWD_POSTPROCESS_COMMAND"]
+self.assertIsNotNone(passwd_postprocess_cmd)
+if (passwd_postprocess_cmd.strip() != 'tidy_shadowutils_files;'):
+raise unittest.SkipTest("Testcase skipped as 
'tidy_shadowutils_files' "
+"rootfs post process command is not the set 
SORT_PASSWD_POSTPROCESS_COMMAND.")
+
+rootfs = vars["IMAGE_ROOTFS"]
+self.assertIsNotNone(rootfs)
+sysconfdir = vars["sysconfdir"]
+bitbake(test_image)
+self.assertIsNotNone(sysconfdir)
+
+return oe.path.join(rootfs, sysconfdir)
+
+def test_shadowutils_backup_files(self):
+"""
+Test that the rootfs doesn't include any known shadow backup files.
+"""
+
+backup_files = (
+'group-',
+'gshadow-',
+'passwd-',
+'shadow-',
+'subgid-',
+'subuid-',
+)
+
+rootfs_sysconfdir = self.sysconf_build()
+found = []
+for backup_file in backup_files:
+backup_filepath = oe.path.join(rootfs_sysconfdir, backup_file)
+if os.path.exists(backup_filepath):
+found.append(backup_file)
+if (found):
+raise Exception('The following shadow backup files were found in '
+'the rootfs: %s' % found)
+
+def test_shadowutils_sorted_files(self):
+"""
+Test that the 'passwd' and the 'group' shadow utils files are ordered
+by ID.
+"""
+
+files = (
+'passwd',
+'group',
+)
+
+rootfs_sysconfdir = self.sysconf_build()
+unsorted = []
+for file in files:
+filepath = oe.path.join(rootfs_sysconfdir, file)
+with open(filepath, 'rb') as f:
+ids = []
+lines = f.readlines()
+for line in lines:
+entries = line.split(b':')
+ids.append(int(entries[2]))
+if (ids != sorted(ids)):
+unsorted.append(file)
+if (unsorted):
+raise Exception("The following files were not sorted by ID as 
expected: %s" % unsorted)
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#169765): 
https://lists.openembedded.org/g/openembedded-core/message/169765
Mute This Topic: https://lists.openembedded.org/mt/93217138/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH 3/6] rootfspostcommands.py: Cleanup subid backup files generated by shadow-utils

[Andrei Gherzan]

From: Andrei Gherzan 

When creating users, shadow-utils might create backup files for
subordinate ID files (subid, subgid). Make sure we clean them up
similarly to the other backup files shadow-utils creates.

Signed-off-by: Andrei Gherzan 
---
 meta/lib/rootfspostcommands.py | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/lib/rootfspostcommands.py b/meta/lib/rootfspostcommands.py
index e344ae2efc..5386eea409 100644
--- a/meta/lib/rootfspostcommands.py
+++ b/meta/lib/rootfspostcommands.py
@@ -73,6 +73,8 @@ def remove_shadowutils_backup_files(sysconfdir):
 'gshadow',
 'passwd',
 'shadow',
+'subgid',
+'subuid',
 ):
 filepath = os.path.join(sysconfdir, filename)
 remove_shadowutils_backup_file(filepath)
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#169764): 
https://lists.openembedded.org/g/openembedded-core/message/169764
Mute This Topic: https://lists.openembedded.org/mt/93217137/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH 2/6] rootfspostcommands.py: Restructure sort_passwd and related functions

[Andrei Gherzan]

From: Andrei Gherzan 

This change proposes a restructure of the functions in
rootfspostcommandstests.py to clarify the purpose of each function and
also, make it scalable for other use cases (for example adding support
for removing subid backup files).

The main function of interest here is 'tidy_shadowutils_files' which
brings in the functionality of the old 'sort_passwd' making it clear
that it doesn't only sort the passwd file:
- delete backup files
- it sorts passwd, group and the associated shadow files

The other functions are also renamed for consistency and clarity and
more documentation was added.

Signed-off-by: Andrei Gherzan 
---
 meta/lib/rootfspostcommands.py | 60 --
 1 file changed, 43 insertions(+), 17 deletions(-)

diff --git a/meta/lib/rootfspostcommands.py b/meta/lib/rootfspostcommands.py
index b5a51295e2..e344ae2efc 100644
--- a/meta/lib/rootfspostcommands.py
+++ b/meta/lib/rootfspostcommands.py
@@ -6,13 +6,14 @@
 
 import os
 
-def sort_file(filename, mapping):
+def sort_shadowutils_file(filename, mapping):
 """
 Sorts a passwd or group file based on the numeric ID in the third column.
 If a mapping is given, the name from the first column is mapped via that
 dictionary instead (necessary for /etc/shadow and /etc/gshadow). If not,
 a new mapping is created on the fly and returned.
 """
+
 new_mapping = {}
 with open(filename, 'rb+') as f:
 lines = f.readlines()
@@ -33,30 +34,55 @@ def sort_file(filename, mapping):
 # We overwrite the entire file, i.e. no truncate() necessary.
 f.seek(0)
 f.write(b''.join(lines))
+
 return new_mapping
 
-def remove_backup(filename):
+def sort_shadowutils_files(sysconfdir):
 """
-Removes the backup file for files like /etc/passwd.
+Sorts shadow-utils 'passwd' and 'group' files in a rootfs' /etc directory
+by ID.
 """
-backup_filename = filename + '-'
-if os.path.exists(backup_filename):
-os.unlink(backup_filename)
 
-def sort_passwd(sysconfdir):
-"""
-Sorts passwd and group files in a rootfs /etc directory by ID.
-Backup files are sometimes are inconsistent and then cannot be
-sorted (YOCTO #11043), and more importantly, are not needed in
-the initial rootfs, so they get deleted.
-"""
 for main, shadow in (('passwd', 'shadow'),
  ('group', 'gshadow')):
 filename = os.path.join(sysconfdir, main)
-remove_backup(filename)
 if os.path.exists(filename):
-mapping = sort_file(filename, None)
+mapping = sort_shadowutils_file(filename, None)
 filename = os.path.join(sysconfdir, shadow)
-remove_backup(filename)
 if os.path.exists(filename):
- sort_file(filename, mapping)
+ sort_shadowutils_file(filename, mapping)
+
+def remove_shadowutils_backup_file(filename):
+"""
+Remove shadow-utils backup file for files like /etc/passwd.
+"""
+
+backup_filename = filename + '-'
+if os.path.exists(backup_filename):
+os.unlink(backup_filename)
+
+def remove_shadowutils_backup_files(sysconfdir):
+"""
+Remove shadow-utils backup files in a rootfs /etc directory. They are not
+needed in the initial root filesystem and sorting them can be inconsistent
+(YOCTO #11043).
+"""
+
+for filename in (
+'group',
+'gshadow',
+'passwd',
+'shadow',
+):
+filepath = os.path.join(sysconfdir, filename)
+remove_shadowutils_backup_file(filepath)
+
+def tidy_shadowutils_files(sysconfdir):
+"""
+Tidy up shadow-utils files.
+"""
+
+remove_shadowutils_backup_files(sysconfdir)
+sort_shadowutils_files(sysconfdir)
+
+return True
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#169763): 
https://lists.openembedded.org/g/openembedded-core/message/169763
Mute This Topic: https://lists.openembedded.org/mt/93217124/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH 1/6] shadow: Enable subid support

[Andrei Gherzan]

From: Andrei Gherzan 

shadow utils are used when creating users at image creation time. The
useradd/usermod tools will only try to add a default configuration for
subid files if they exist.

Signed-off-by: Andrei Gherzan 
---
 meta/recipes-extended/shadow/shadow.inc | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/meta/recipes-extended/shadow/shadow.inc 
b/meta/recipes-extended/shadow/shadow.inc
index fbb1d395ff..b2f82e9ac7 100644
--- a/meta/recipes-extended/shadow/shadow.inc
+++ b/meta/recipes-extended/shadow/shadow.inc
@@ -147,6 +147,13 @@ do_install:append() {
# Handle link properly after rename, otherwise missing files would
# lead rpm failed dependencies.
ln -sf newgrp.${BPN} ${D}${bindir}/sg
+
+   # usermod requires the subuid/subgid files to be in place before being
+   # able to use the -v/-V flags otherwise it fails:
+   # usermod: /etc/subuid does not exist, you cannot use the flags -v or -V
+   install -d ${D}${sysconfdir}
+   touch ${D}${sysconfdir}/subuid
+   touch ${D}${sysconfdir}/subgid
 }
 
 PACKAGES =+ "${PN}-base"
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#169762): 
https://lists.openembedded.org/g/openembedded-core/message/169762
Mute This Topic: https://lists.openembedded.org/mt/93217113/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH] kmod: Enable xz support by default

[Andrei Gherzan]

On Thu, 28 Apr 2022, at 07:26, Khem Raj wrote:
> RPi kernel has started building compressed kernel modules by default
> starting 5.15, currenrly therefore meta-raspberrypi kernels are unable
> to load kernel modules since kmod and kmod-native do not entertain xz
> compressed modules. There is a fix proposed in meta-raspberrypi [1]
> but the fix is needed for native and nativesdk recipes as well, perhaps
> its best to enable it here for best out of box experience with
> meta-raspberrypi
>
> [1] https://github.com/agherzan/meta-raspberrypi/pull/1056
>
> Signed-off-by: Khem Raj 

I don't see any reason not to do this and it does help with the BSPs using this 
compression requirement. So here is my +1. Would it be reasonable to propose to 
have it in kirkstone too? Otherwise, @khem, I'd need to drop compression or 
downgrade the kernel in kirkstone rpi (or make some yocto incompatible changes 
- which I'd rather not).

Andrei

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#164941): 
https://lists.openembedded.org/g/openembedded-core/message/164941
Mute This Topic: https://lists.openembedded.org/mt/90747997/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH v2 1/1] automake: Drop redundant 'u' flag in ARFLAGS

[Andrei Gherzan]

From: Andrei Gherzan 

Signed-off-by: Andrei Gherzan 
---
 .../automake/0001-Drop-ar-u-argument.patch| 35 +++
 .../automake/automake_1.16.5.bb   |  1 +
 2 files changed, 36 insertions(+)
 create mode 100644 
meta/recipes-devtools/automake/automake/0001-Drop-ar-u-argument.patch

diff --git 
a/meta/recipes-devtools/automake/automake/0001-Drop-ar-u-argument.patch 
b/meta/recipes-devtools/automake/automake/0001-Drop-ar-u-argument.patch
new file mode 100644
index 00..f72788c3a6
--- /dev/null
+++ b/meta/recipes-devtools/automake/automake/0001-Drop-ar-u-argument.patch
@@ -0,0 +1,35 @@
+From bed646918bc67e9e2151ccbda03aae34717821fe Mon Sep 17 00:00:00 2001
+From: Andrei Gherzan 
+Date: Wed, 20 Apr 2022 14:57:14 +0200
+Subject: [PATCH] Drop ar 'u' argument
+
+binutils/ar is configured in deterministic mode by default making the
+'u' argument irrelevant while leading to warning massages similar to:
+
+| ar: `u' modifier ignored since `D' is the default (see `U')
+
+We also add 'D' flag explicitely to not rely in the default configuration
+for reproducible archives.
+
+Upstream-Status: Inappropriate [OE specific]
+Signed-off-by: Andrei Gherzan 
+---
+ bin/automake.in | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/bin/automake.in b/bin/automake.in
+index 92bcebe..0f2b84b 100644
+--- a/bin/automake.in
 b/bin/automake.in
+@@ -2678,7 +2678,7 @@ sub handle_libraries ()
+ }
+ 
+   define_variable ('AR', 'ar', INTERNAL);
+-  define_variable ('ARFLAGS', 'cru', INTERNAL);
++  define_variable ('ARFLAGS', 'crD', INTERNAL);
+   define_verbose_tagvar ('AR');
+ 
+   foreach my $pair (@liblist)
+-- 
+2.25.1
+
diff --git a/meta/recipes-devtools/automake/automake_1.16.5.bb 
b/meta/recipes-devtools/automake/automake_1.16.5.bb
index ba5ce7b9bb..469fcd69f7 100644
--- a/meta/recipes-devtools/automake/automake_1.16.5.bb
+++ b/meta/recipes-devtools/automake/automake_1.16.5.bb
@@ -25,6 +25,7 @@ SRC_URI += "\
file://new_rt_path_for_test-driver.patch \
file://0001-automake-Add-default-libtool_tag-to-cppasm.patch \
file://0001-build-fix-race-in-parallel-builds.patch \
+   file://0001-Drop-ar-u-argument.patch \
"
 
 SRC_URI[sha256sum] = 
"07bd24ad08a64bc17250ce09ec56e921d6343903943e99ccf63bbf0705e34605"
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#164708): 
https://lists.openembedded.org/g/openembedded-core/message/164708
Mute This Topic: https://lists.openembedded.org/mt/90586689/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH 1/1] automake: Drop redundant 'u' flag in ARFLAGS

[Andrei Gherzan]

On Wed, 20 Apr 2022, at 16:36, Khem Raj wrote:
> On Wed, Apr 20, 2022 at 8:17 AM Andrei Gherzan  wrote:
>>
>> From: Andrei Gherzan 
>>
>> Signed-off-by: Andrei Gherzan 
>> ---
>>  .../automake/0001-Drop-ar-u-argument.patch| 32 +++
>>  .../automake/automake_1.16.5.bb   |  1 +
>>  2 files changed, 33 insertions(+)
>>  create mode 100644 
>> meta/recipes-devtools/automake/automake/0001-Drop-ar-u-argument.patch
>>
>> diff --git 
>> a/meta/recipes-devtools/automake/automake/0001-Drop-ar-u-argument.patch 
>> b/meta/recipes-devtools/automake/automake/0001-Drop-ar-u-argument.patch
>> new file mode 100644
>> index 00..260c51f517
>> --- /dev/null
>> +++ b/meta/recipes-devtools/automake/automake/0001-Drop-ar-u-argument.patch
>> @@ -0,0 +1,32 @@
>> +From bed646918bc67e9e2151ccbda03aae34717821fe Mon Sep 17 00:00:00 2001
>> +From: Andrei Gherzan 
>> +Date: Wed, 20 Apr 2022 14:57:14 +0200
>> +Subject: [PATCH] Drop ar 'u' argument
>> +
>> +binutils/ar is configured in deterministic mode by default making the
>> +'u' argument irrelevant while leading to warning massages similar to:
>> +
>> +| ar: `u' modifier ignored since `D' is the default (see `U')
>> +
>
> this is perhaps due to the way we build binutils and I am fine with
> removing -u here but
> I think the patch is OE specific. While you are here can you add -D
> explicitly, because we
> do have option to use llvm ar and it would help those distributions to
> create reproducible archives too.

Agreed. I'll send v2.

Andrei

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#164706): 
https://lists.openembedded.org/g/openembedded-core/message/164706
Mute This Topic: https://lists.openembedded.org/mt/90586101/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH 1/1] automake: Drop redundant 'u' flag in ARFLAGS

[Andrei Gherzan]

From: Andrei Gherzan 

Signed-off-by: Andrei Gherzan 
---
 .../automake/0001-Drop-ar-u-argument.patch| 32 +++
 .../automake/automake_1.16.5.bb   |  1 +
 2 files changed, 33 insertions(+)
 create mode 100644 
meta/recipes-devtools/automake/automake/0001-Drop-ar-u-argument.patch

diff --git 
a/meta/recipes-devtools/automake/automake/0001-Drop-ar-u-argument.patch 
b/meta/recipes-devtools/automake/automake/0001-Drop-ar-u-argument.patch
new file mode 100644
index 00..260c51f517
--- /dev/null
+++ b/meta/recipes-devtools/automake/automake/0001-Drop-ar-u-argument.patch
@@ -0,0 +1,32 @@
+From bed646918bc67e9e2151ccbda03aae34717821fe Mon Sep 17 00:00:00 2001
+From: Andrei Gherzan 
+Date: Wed, 20 Apr 2022 14:57:14 +0200
+Subject: [PATCH] Drop ar 'u' argument
+
+binutils/ar is configured in deterministic mode by default making the
+'u' argument irrelevant while leading to warning massages similar to:
+
+| ar: `u' modifier ignored since `D' is the default (see `U')
+
+Upstream-Status: Pending
+Signed-off-by: Andrei Gherzan 
+---
+ bin/automake.in | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/bin/automake.in b/bin/automake.in
+index 92bcebe..0f2b84b 100644
+--- a/bin/automake.in
 b/bin/automake.in
+@@ -2678,7 +2678,7 @@ sub handle_libraries ()
+ }
+ 
+   define_variable ('AR', 'ar', INTERNAL);
+-  define_variable ('ARFLAGS', 'cru', INTERNAL);
++  define_variable ('ARFLAGS', 'cr', INTERNAL);
+   define_verbose_tagvar ('AR');
+ 
+   foreach my $pair (@liblist)
+-- 
+2.25.1
+
diff --git a/meta/recipes-devtools/automake/automake_1.16.5.bb 
b/meta/recipes-devtools/automake/automake_1.16.5.bb
index ba5ce7b9bb..469fcd69f7 100644
--- a/meta/recipes-devtools/automake/automake_1.16.5.bb
+++ b/meta/recipes-devtools/automake/automake_1.16.5.bb
@@ -25,6 +25,7 @@ SRC_URI += "\
file://new_rt_path_for_test-driver.patch \
file://0001-automake-Add-default-libtool_tag-to-cppasm.patch \
file://0001-build-fix-race-in-parallel-builds.patch \
+   file://0001-Drop-ar-u-argument.patch \
"
 
 SRC_URI[sha256sum] = 
"07bd24ad08a64bc17250ce09ec56e921d6343903943e99ccf63bbf0705e34605"
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#164702): 
https://lists.openembedded.org/g/openembedded-core/message/164702
Mute This Topic: https://lists.openembedded.org/mt/90586101/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH 1/1] go.bbclass: Allow network in do_compile

[Andrei Gherzan]

On Thu, 3 Mar 2022, at 03:34, Bruce Ashfield wrote:
> On Wed, Mar 2, 2022 at 4:57 PM Andrei Gherzan  wrote:
>>
>>
>> Mar 1, 2022 20:15:52 Bruce Ashfield :
>>
>> > On Tue, Mar 1, 2022 at 10:54 AM  wrote:
>> >>
>> >> On Tue, Mar 1, 2022 at 02:14 PM, Bruce Ashfield wrote:
>> >>
>> >> On Tue, Mar 1, 2022 at 6:42 AM Andrei Gherzan  wrote:
>> >>
>> >>
>> >> On Tue, 1 Mar 2022, at 01:55, Bruce Ashfield wrote:
>> >>
>> >> On Mon, Feb 28, 2022 at 8:17 PM Bruce Ashfield via
>> >> lists.openembedded.org
>> >>  wrote:
>> >>
>> >>
>> >> On Mon, Feb 28, 2022 at 6:54 PM Andrei Gherzan  wrote:
>> >>
>> >>
>> >> From: Andrei Gherzan 
>> >>
>> >> Compile pulls in the go.mod list requiring network. Without this, do
>> >> compile would fail with a similar error to the following:
>> >>
>> >> dial tcp: lookup proxy.golang.org: Temporary failure in name resolution
>> >>
>> >> This is something that needs to be carried in your own layers, IMHO it
>> >> isn't appropriate for core.
>> >>
>> >> It isn't about the fetching, it is the entire gap in functionality
>> >> that we are missing if go starts fetching dependencies during compile.
>> >>
>> >> A further thought is that if this is for go.mod issues, there is the
>> >> go-mod.bbclass.
>> >>
>> >> Perhaps enabling it in that class and doing a bbwarn about go fetching
>> >> dependencies would be appropriate ?
>> >>
>> >> Otherwise, someone may not know that this is happening and that a no
>> >> network configuration has no chance of working.
>> >>
>> >> I reckon that is reasonable. I'll personally go down the recipe level to 
>> >> workaround this change but understanding and agreeing with the reasoning 
>> >> behind this change, I want to invest a bit into trying to find a proper 
>> >> solution in the core. Bruce, I know you invested a fair amount of time 
>> >> into this already. Would you be willing to sync up and see how we can 
>> >> work together in tackling this?
>> >>
>> >> Definitely, more ideas are good. In fact, I think there are probably
>> >> several approaches that can co-exist, depending on what a
>> >> recipe/developer needs.
>> >>
>> >> I'm in the Eastern time zone here, and will try and grab folks on IRC
>> >> to have a level set
>> >>
>> >> Bruce
>> >>
>> >> Added Zyga to CC as he is also interested in this as part of his go 
>> >> development activities.
>> >>
>> >> Thanks,
>> >> Andrei
>> >>
>> >>
>> >>
>> >> --
>> >> - Thou shalt not follow the NULL pointer, for chaos and madness await
>> >> thee at its end
>> >> - "Use the force Harry" - Gandalf, Star Trek II
>> >>
>> >> The problem in allowing downloads during compile (e.g. by go) is, that it 
>> >> leads to non-reproducable builds. I'm currently facing the same issue and 
>> >> would like to have a reproducable go *offline* build.
>> >> I would like to propose two ideas to workaround the go-compile fetching 
>> >> issue:
>> >>
>> >> First:
>> >> - Fetch go-dependencies using go.mod file from 'proxy.golang.org' (e.g. 
>> >> by writing a seperate go fetcher or a wget-fetcher) and unpack the 
>> >> dependencies into go projects 'vendor' folder. This forces go to compile 
>> >> offline. However, one have to generate the 'modules.txt' file in the 
>> >> vendor folder 'manually' during unpack. This is error prone, as there is 
>> >> no official documentation how this format should look like. Anyway, I've 
>> >> tried this approach and it works for me.
>> >>
>> >> Second:
>> >> - Fetch go-dependencies using go.mod file from 'proxy.golang.org' (e.g. 
>> >> by writing a seperate go fetcher) and unpack the dependencies into a 
>> >> local (workdir) go-path. This seemed a good solution for me as the 
>> >> go-path is well defined. But for some reason 'go'  fetches the zip-files 
>> >> during compile into it's download-cache AGAIN, even if the source is 
>> >> already unpacked in the go-path. I'll assume this is required t

Re: [OE-core] [PATCH] wic: Use custom kernel path if provided

[Andrei Gherzan]

Feb 15, 2022 16:54:28 Bill Pittman :

> If the custom kernel path is provided in options, then
> use that path instead of the default path.

Just to understand this a bit, what is your usecase here?
--
Andrei Gherzan
gpg: rsa4096/D4D94F67AD0E9640

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162627): 
https://lists.openembedded.org/g/openembedded-core/message/162627
Mute This Topic: https://lists.openembedded.org/mt/89165206/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH 1/1] go.bbclass: Allow network in do_compile

[Andrei Gherzan]

Mar 1, 2022 20:15:52 Bruce Ashfield :

> On Tue, Mar 1, 2022 at 10:54 AM  wrote:
>>
>> On Tue, Mar 1, 2022 at 02:14 PM, Bruce Ashfield wrote:
>>
>> On Tue, Mar 1, 2022 at 6:42 AM Andrei Gherzan  wrote:
>>
>>
>> On Tue, 1 Mar 2022, at 01:55, Bruce Ashfield wrote:
>>
>> On Mon, Feb 28, 2022 at 8:17 PM Bruce Ashfield via
>> lists.openembedded.org
>>  wrote:
>>
>>
>> On Mon, Feb 28, 2022 at 6:54 PM Andrei Gherzan  wrote:
>>
>>
>> From: Andrei Gherzan 
>>
>> Compile pulls in the go.mod list requiring network. Without this, do
>> compile would fail with a similar error to the following:
>>
>> dial tcp: lookup proxy.golang.org: Temporary failure in name resolution
>>
>> This is something that needs to be carried in your own layers, IMHO it
>> isn't appropriate for core.
>>
>> It isn't about the fetching, it is the entire gap in functionality
>> that we are missing if go starts fetching dependencies during compile.
>>
>> A further thought is that if this is for go.mod issues, there is the
>> go-mod.bbclass.
>>
>> Perhaps enabling it in that class and doing a bbwarn about go fetching
>> dependencies would be appropriate ?
>>
>> Otherwise, someone may not know that this is happening and that a no
>> network configuration has no chance of working.
>>
>> I reckon that is reasonable. I'll personally go down the recipe level to 
>> workaround this change but understanding and agreeing with the reasoning 
>> behind this change, I want to invest a bit into trying to find a proper 
>> solution in the core. Bruce, I know you invested a fair amount of time into 
>> this already. Would you be willing to sync up and see how we can work 
>> together in tackling this?
>>
>> Definitely, more ideas are good. In fact, I think there are probably
>> several approaches that can co-exist, depending on what a
>> recipe/developer needs.
>>
>> I'm in the Eastern time zone here, and will try and grab folks on IRC
>> to have a level set
>>
>> Bruce
>>
>> Added Zyga to CC as he is also interested in this as part of his go 
>> development activities.
>>
>> Thanks,
>> Andrei
>>
>>
>>
>> --
>> - Thou shalt not follow the NULL pointer, for chaos and madness await
>> thee at its end
>> - "Use the force Harry" - Gandalf, Star Trek II
>>
>> The problem in allowing downloads during compile (e.g. by go) is, that it 
>> leads to non-reproducable builds. I'm currently facing the same issue and 
>> would like to have a reproducable go *offline* build.
>> I would like to propose two ideas to workaround the go-compile fetching 
>> issue:
>>
>> First:
>> - Fetch go-dependencies using go.mod file from 'proxy.golang.org' (e.g. by 
>> writing a seperate go fetcher or a wget-fetcher) and unpack the dependencies 
>> into go projects 'vendor' folder. This forces go to compile offline. 
>> However, one have to generate the 'modules.txt' file in the vendor folder 
>> 'manually' during unpack. This is error prone, as there is no official 
>> documentation how this format should look like. Anyway, I've tried this 
>> approach and it works for me.
>>
>> Second:
>> - Fetch go-dependencies using go.mod file from 'proxy.golang.org' (e.g. by 
>> writing a seperate go fetcher) and unpack the dependencies into a local 
>> (workdir) go-path. This seemed a good solution for me as the go-path is well 
>> defined. But for some reason 'go'  fetches the zip-files during compile into 
>> it's download-cache AGAIN, even if the source is already unpacked in the 
>> go-path. I'll assume this is required to verify the source files integrity?! 
>> With this approach one have to adapt 'go' to suppress this download 
>> behaviour.
>>
>
> I've been doing offline builds using a constructed vendor/ directory
> and generated modules.txt.
>
> The only difference between what I have working and what you are
> suggesting (type 1), is that I've gone directly to the sources and
> constructed the vendor directory using the OE git fetcher. That allows
> all functionality to continue to work that is part of OEcore, and the
> build to continue.  Switching out the git fetches for tarballs would
> be possible, I just wasn't sure how to use the proxied modules (and I
> wanted the history for debug).
>
> I've never had any issues with the modules.txt, as I generate it at
> the same time as the git fetch lines for the SRC_URI. I've also not
> been using information from the go.mod directly from go.prox

Re: [OE-core] [PATCH 1/1] go.bbclass: Allow network in do_compile

[Andrei Gherzan]

On Tue, 1 Mar 2022, at 01:55, Bruce Ashfield wrote:
> On Mon, Feb 28, 2022 at 8:17 PM Bruce Ashfield via
> lists.openembedded.org
>  wrote:
>>
>> On Mon, Feb 28, 2022 at 6:54 PM Andrei Gherzan  wrote:
>> >
>> > From: Andrei Gherzan 
>> >
>> > Compile pulls in the go.mod list requiring network. Without this, do
>> > compile would fail with a similar error to the following:
>> >
>> > dial tcp: lookup proxy.golang.org: Temporary failure in name resolution
>>
>> This is something that needs to be carried in your own layers, IMHO it
>> isn't appropriate for core.
>>
>> It isn't about the fetching, it is the entire gap in functionality
>> that we are missing if go starts fetching dependencies during compile.
>
> A further thought is that if this is for go.mod issues, there is the
> go-mod.bbclass.
>
> Perhaps enabling it in that class and doing a bbwarn about go fetching
> dependencies would be appropriate ?
>
> Otherwise, someone may not know that this is happening and that a no
> network configuration has no chance of working.
>

I reckon that is reasonable. I'll personally go down the recipe level to 
workaround this change but understanding and agreeing with the reasoning behind 
this change, I want to invest a bit into trying to find a proper solution in 
the core. Bruce, I know you invested a fair amount of time into this already. 
Would you be willing to sync up and see how we can work together in tackling 
this? 

Added Zyga to CC as he is also interested in this as part of his go development 
activities.

Thanks,
Andrei

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162542): 
https://lists.openembedded.org/g/openembedded-core/message/162542
Mute This Topic: https://lists.openembedded.org/mt/89464905/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH 1/1] go.bbclass: Allow network in do_compile

[Andrei Gherzan]

From: Andrei Gherzan 

Compile pulls in the go.mod list requiring network. Without this, do
compile would fail with a similar error to the following:

dial tcp: lookup proxy.golang.org: Temporary failure in name resolution

Signed-off-by: Andrei Gherzan 
---
 meta/classes/go.bbclass | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/classes/go.bbclass b/meta/classes/go.bbclass
index 9c4c92bffd..dc246c72cb 100644
--- a/meta/classes/go.bbclass
+++ b/meta/classes/go.bbclass
@@ -113,6 +113,7 @@ go_do_compile() {
 }
 do_compile[dirs] =+ "${GOTMPDIR}"
 do_compile[cleandirs] = "${B}/bin ${B}/pkg"
+do_compile[network] = "1"
 
 go_do_install() {
install -d ${D}${libdir}/go/src/${GO_IMPORT}
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162517): 
https://lists.openembedded.org/g/openembedded-core/message/162517
Mute This Topic: https://lists.openembedded.org/mt/89464905/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH 1/1] gcc: Fix typo in linux64.h install patch

[Andrei Gherzan]

From: Andrei Gherzan 

The "gcc: Fix compile of gcc plugins" patch had a typo making it a noop.
This was due to a rework to make it specific to the linux64.h header.

Signed-off-by: Andrei Gherzan 
---
 .../gcc/gcc/0001-Fix-install-path-of-linux64.h.patch| 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/meta/recipes-devtools/gcc/gcc/0001-Fix-install-path-of-linux64.h.patch 
b/meta/recipes-devtools/gcc/gcc/0001-Fix-install-path-of-linux64.h.patch
index 9201538f0e..5bf895d6e7 100644
--- a/meta/recipes-devtools/gcc/gcc/0001-Fix-install-path-of-linux64.h.patch
+++ b/meta/recipes-devtools/gcc/gcc/0001-Fix-install-path-of-linux64.h.patch
@@ -23,7 +23,7 @@ index 9b17d120a..d175ec4e3 100644
  "$(srcdir)"/config/* | "$(srcdir)"/common/config/* \
  | "$(srcdir)"/c-family/* | "$(srcdir)"/*.def ) \
base=`echo "$$path" | sed -e "s|$$srcdirstrip/||"`;; \
-+./linux64.h ) \
++*/linux64.h ) \
 +  base=`dirname $$path`;;\
  *) base=`basename $$path` ;; \
  esac; \
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#160362): 
https://lists.openembedded.org/g/openembedded-core/message/160362
Mute This Topic: https://lists.openembedded.org/mt/88323604/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH v2] perl: Enable threading

[Andrei Gherzan]

On Mon, 10 Jan 2022, at 13:15, Alexander Kanavin wrote:
> On Mon, 10 Jan 2022 at 14:08, Andrei Gherzan  wrote:
>> 
>> You need to clean before every build. Perl doesn't correctly reconfigure 
>> itself when settings like this change.
>> 
>> I'm not sure I get you here. Are you saying that this is normal behavior or 
>> that it is a known issue? If the latter, do we have an bug raised on it?
> 
> Yes, it's something to be fixed, I'm just saying that the specific change 
> itself is not the source of trouble.

That makes sense and after a bit more debugging it seems to match my testing as 
well.

Thanks,
Andrei

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#160351): 
https://lists.openembedded.org/g/openembedded-core/message/160351
Mute This Topic: https://lists.openembedded.org/mt/88246693/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH v2] perl: Enable threading

[Andrei Gherzan]

On Mon, 10 Jan 2022, at 13:01, Alexander Kanavin wrote:
> You need to clean before every build. Perl doesn't correctly reconfigure 
> itself when settings like this change.

I'm not sure I get you here. Are you saying that this is normal behavior or 
that it is a known issue? If the latter, do we have an bug raised on it?

Andrei

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#160349): 
https://lists.openembedded.org/g/openembedded-core/message/160349
Mute This Topic: https://lists.openembedded.org/mt/88246693/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH v2] perl: Enable threading

[Andrei Gherzan]

On Mon, 10 Jan 2022, at 12:39, Andrei Gherzan wrote:
> Hi,
>
> On Thu, 6 Jan 2022, at 20:12, Saul Wold wrote:
>> From: Saul Wold 
>>
>> When the tranisiton to perl-cross occured, the threading define
>> seems to have been missed.  The perl tests for threading where
>> simply skipped, so there was no direct failures.  This was verified
>> by running perl ptest before and after the change to see PASS vs SKIP
>> results of threaded related tests.
>>
>> NOTE: Perl officially discourges the use of threads, so this
>> functionality maybe depercated in the future [0][1]
>>
>> v2: adds the usethreads to native and nativesdk. This was tested by
>> builing postresql and rrdtool which use perl and automake.
>>
>> [0] https://perldoc.perl.org/5.34.0-RC2/threads#WARNING
>> [1] https://perldoc.perl.org/perlpolicy#discouraged
>>
>> Signed-off-by: Saul Wold 
>> ---
>>  meta/recipes-devtools/perl/perl_5.34.0.bb | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/meta/recipes-devtools/perl/perl_5.34.0.bb 
>> b/meta/recipes-devtools/perl/perl_5.34.0.bb
>> index a6ae80f07e1..e4bcfe3ce69 100644
>> --- a/meta/recipes-devtools/perl/perl_5.34.0.bb
>> +++ b/meta/recipes-devtools/perl/perl_5.34.0.bb
>> @@ -53,6 +53,7 @@ do_configure:class-target() {
>>  ./configure --prefix=${prefix} --libdir=${libdir} \
>>  --target=${TARGET_SYS} \
>>  -Duseshrplib \
>> +-Dusethreads \
>>  -Dsoname=libperl.so.5 \
>>  -Dvendorprefix=${prefix} \
>>  -Darchlibexp=${STAGING_LIBDIR}/perl5/${PV}/${TARGET_ARCH}-linux \
>> @@ -80,6 +81,7 @@ do_configure:class-nativesdk() {
>>  ./configure --prefix=${prefix} \
>>  --target=${TARGET_SYS} \
>>  -Duseshrplib \
>> +-Dusethreads \
>>  -Dsoname=libperl.so.5 \
>>  -Dvendorprefix=${prefix} \
>>  -Darchlibexp=${STAGING_LIBDIR}/perl5/${PV}/${TARGET_ARCH}-linux \
>> @@ -94,6 +96,7 @@ do_configure:class-native() {
>>  ./configure --prefix=${prefix} \
>>  -Dbin=${bindir}/perl-native \
>>  -Duseshrplib \
>> +-Dusethreads \
>>  -Dsoname=libperl.so.5 \
>>  -Dvendorprefix=${prefix} \
>>  -Ui_xlocale \
>
> This patch seems to break perl-native with musl:

It seems like it is persistent and it can be workaround-ed with a cleansstate. 
the way to reproduce (if anyone is interested) is to:
0. I've only tested it with musl so it might be musl specific
1. cleansstate perl-native
2. build without this patch - reverted
3. build with this patch

Andrei

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#160347): 
https://lists.openembedded.org/g/openembedded-core/message/160347
Mute This Topic: https://lists.openembedded.org/mt/88246693/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH v2] perl: Enable threading

[Andrei Gherzan]

Hi,

On Thu, 6 Jan 2022, at 20:12, Saul Wold wrote:
> From: Saul Wold 
>
> When the tranisiton to perl-cross occured, the threading define
> seems to have been missed.  The perl tests for threading where
> simply skipped, so there was no direct failures.  This was verified
> by running perl ptest before and after the change to see PASS vs SKIP
> results of threaded related tests.
>
> NOTE: Perl officially discourges the use of threads, so this
> functionality maybe depercated in the future [0][1]
>
> v2: adds the usethreads to native and nativesdk. This was tested by
> builing postresql and rrdtool which use perl and automake.
>
> [0] https://perldoc.perl.org/5.34.0-RC2/threads#WARNING
> [1] https://perldoc.perl.org/perlpolicy#discouraged
>
> Signed-off-by: Saul Wold 
> ---
>  meta/recipes-devtools/perl/perl_5.34.0.bb | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/meta/recipes-devtools/perl/perl_5.34.0.bb 
> b/meta/recipes-devtools/perl/perl_5.34.0.bb
> index a6ae80f07e1..e4bcfe3ce69 100644
> --- a/meta/recipes-devtools/perl/perl_5.34.0.bb
> +++ b/meta/recipes-devtools/perl/perl_5.34.0.bb
> @@ -53,6 +53,7 @@ do_configure:class-target() {
>  ./configure --prefix=${prefix} --libdir=${libdir} \
>  --target=${TARGET_SYS} \
>  -Duseshrplib \
> +-Dusethreads \
>  -Dsoname=libperl.so.5 \
>  -Dvendorprefix=${prefix} \
>  -Darchlibexp=${STAGING_LIBDIR}/perl5/${PV}/${TARGET_ARCH}-linux \
> @@ -80,6 +81,7 @@ do_configure:class-nativesdk() {
>  ./configure --prefix=${prefix} \
>  --target=${TARGET_SYS} \
>  -Duseshrplib \
> +-Dusethreads \
>  -Dsoname=libperl.so.5 \
>  -Dvendorprefix=${prefix} \
>  -Darchlibexp=${STAGING_LIBDIR}/perl5/${PV}/${TARGET_ARCH}-linux \
> @@ -94,6 +96,7 @@ do_configure:class-native() {
>  ./configure --prefix=${prefix} \
>  -Dbin=${bindir}/perl-native \
>  -Duseshrplib \
> +-Dusethreads \
>  -Dsoname=libperl.so.5 \
>  -Dvendorprefix=${prefix} \
>  -Ui_xlocale \

This patch seems to break perl-native with musl:

| /[...]/tmp/hosttools/ld: perlmini.c:(.text+0x8298): undefined reference to 
`PL_perldb'
| /[...]/tmp/hosttools/ld: perlmini.c:(.text+0x82a4): undefined reference to 
`PL_DBsingle'
| /[...]/tmp/hosttools/ld: perlmini.c:(.text+0x82b1): undefined reference to 
`PL_DBcontrol'
| /[...]/tmp/hosttools/ld: perlmini.c:(.text+0x82bf): undefined reference to 
`PL_initav'
| /[...]/tmp/hosttools/ld: perlmini.c:(.text+0x82d2): undefined reference to 
`PL_phase'
| /[...]/tmp/hosttools/ld: perlmini.o: in function `Perl_my_failure_exit':
| perlmini.c:(.text+0x831d): undefined reference to `PL_statusvalue'
| /[...]/tmp/hosttools/ld: perlmini.c:(.text+0x8336): undefined reference to 
`PL_exit_flags'
| /[...]/tmp/hosttools/ld: perlmini.o: in function `Perl_xs_boot_epilog':
| perlmini.c:(.text+0x83a7): undefined reference to `PL_unitcheckav'
| /[...]/tmp/hosttools/ld: perlmini.c:(.text+0x83b9): undefined reference to 
`PL_scopestack_ix'
| /[...]/tmp/hosttools/ld: perlmini.c:(.text+0x83c7): undefined reference to 
`PL_stack_base'
| /[...]/tmp/hosttools/ld: perlmini.c:(.text+0x83ce): undefined reference to 
`PL_sv_immortals'
| /[...]/tmp/hosttools/ld: perlmini.c:(.text+0x83e6): undefined reference to 
`PL_stack_sp'
| collect2: error: ld returned 1 exit status
| make[1]: *** [Makefile:99: miniperl] Error 1
| make[1]: Leaving directory 
'/[...]/tmp/work/x86_64-linux/perl-native/5.34.0-r0/perl-5.34.0'
| make: *** [Makefile:79: all] Error 2
| ERROR: oe_runmake failed
| WARNING: 
/[...]/work/x86_64-linux/perl-native/5.34.0-r0/temp/run.do_compile.685819:191 
exit 1 from 'exit 1'
| WARNING: Backtrace (BB generated script):
|   #1: bbfatal_log, 
/[...]/tmp/work/x86_64-linux/perl-native/5.34.0-r0/temp/run.do_compile.685819, 
line 191
|   #2: die, 
/[...]/tmp/work/x86_64-linux/perl-native/5.34.0-r0/temp/run.do_compile.685819, 
line 175
|   #3: oe_runmake, 
/[...]/tmp/work/x86_64-linux/perl-native/5.34.0-r0/temp/run.do_compile.685819, 
line 170
|   #4: do_compile, 
/[...]/tmp/work/x86_64-linux/perl-native/5.34.0-r0/temp/run.do_compile.685819, 
line 148
|   #5: main, 
/[...]/work/x86_64-linux/perl-native/5.34.0-r0/temp/run.do_compile.685819, line 
195

Andrei

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#160346): 
https://lists.openembedded.org/g/openembedded-core/message/160346
Mute This Topic: https://lists.openembedded.org/mt/88246693/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH v2 1/1] gcc: Fix compile of gcc plugins

[Andrei Gherzan]

From: Andrei Gherzan 

Without this, compiling gcc plugins will fail with an error similar to:
[...]
fatal error: ./config/i386/linux64.h: No such file or directory
[...]

In Yocto, we set up compiling gcc-cross out of tree. Which in turn makes
the generated headers end up in B. The tm.h header will include
generated headers that are expected in plugin/include/config/*.

For example, the linux64.h header, when generating gcc-cross for x86-64,
will end up in tm.h header as:

include "./config/i386/linux64.h"

On the other hand, the make rule `install-plugin` in gcc/Makefile.in
will install the linux64.h assuming that it is generated in the sources
directory and because this is not the case in our setup, the Makefile
ends up installing it in plugin_includedir/`basename $$path` which ends
up installing the header in [..]plugin/include as opposed to
[..]plugin/include/config/i386 (as expected by the generator of tm.h).

The included patch modifies the Makefile rule to match the assumption of
gcc-cross being compiled out of tree.

Signed-off-by: Andrei Gherzan 
---
 meta/recipes-devtools/gcc/gcc-11.2.inc|  1 +
 .../0001-Fix-install-path-of-linux64.h.patch  | 33 +++
 2 files changed, 34 insertions(+)
 create mode 100644 
meta/recipes-devtools/gcc/gcc/0001-Fix-install-path-of-linux64.h.patch

diff --git a/meta/recipes-devtools/gcc/gcc-11.2.inc 
b/meta/recipes-devtools/gcc/gcc-11.2.inc
index e352c958de..f07a5be507 100644
--- a/meta/recipes-devtools/gcc/gcc-11.2.inc
+++ b/meta/recipes-devtools/gcc/gcc-11.2.inc
@@ -59,6 +59,7 @@ SRC_URI = "\
file://0037-libatomic-Do-not-enforce-march-on-aarch64.patch \
file://0041-apply-debug-prefix-maps-before-checksumming-DIEs.patch \

file://0006-If-CXXFLAGS-contains-something-unsupported-by-the-bu.patch \
+   file://0001-Fix-install-path-of-linux64.h.patch \
file://0001-CVE-2021-35465.patch \
file://0002-CVE-2021-35465.patch \
file://0003-CVE-2021-35465.patch \
diff --git 
a/meta/recipes-devtools/gcc/gcc/0001-Fix-install-path-of-linux64.h.patch 
b/meta/recipes-devtools/gcc/gcc/0001-Fix-install-path-of-linux64.h.patch
new file mode 100644
index 00..9201538f0e
--- /dev/null
+++ b/meta/recipes-devtools/gcc/gcc/0001-Fix-install-path-of-linux64.h.patch
@@ -0,0 +1,33 @@
+From 58211c7ceb0510b2a11a7f1da3c7fa968c658749 Mon Sep 17 00:00:00 2001
+From: Andrei Gherzan 
+Date: Wed, 22 Dec 2021 12:49:25 +0100
+Subject: [PATCH] Fix install path of linux64.h
+
+We add linux64.h to tm includes[1] as a relative path to B. This patch
+adapts the install path of linux64.h to match the include in tm.h.
+
+[1] 0016-Use-the-multilib-config-files-from-B-instead-of-usin.patch
+
+Signed-off-by: Andrei Gherzan 
+
+Upstream-Status: Inappropriate [configuration]
+---
+ gcc/Makefile.in | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/gcc/Makefile.in b/gcc/Makefile.in
+index 9b17d120a..d175ec4e3 100644
+--- a/gcc/Makefile.in
 b/gcc/Makefile.in
+@@ -3693,6 +3693,8 @@ install-plugin: installdirs lang.install-plugin 
s-header-vars install-gengtype
+ "$(srcdir)"/config/* | "$(srcdir)"/common/config/* \
+ | "$(srcdir)"/c-family/* | "$(srcdir)"/*.def ) \
+   base=`echo "$$path" | sed -e "s|$$srcdirstrip/||"`;; \
++./linux64.h ) \
++  base=`dirname $$path`;;\
+ *) base=`basename $$path` ;; \
+ esac; \
+ dest=$(plugin_includedir)/$$base; \
+-- 
+2.25.1
+
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#160232): 
https://lists.openembedded.org/g/openembedded-core/message/160232
Mute This Topic: https://lists.openembedded.org/mt/88238073/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH] gcc: Fix compile of gcc plugins

[Andrei Gherzan]

On Fri, 24 Dec 2021, at 05:50, Khem Raj wrote:
> On Thu, Dec 23, 2021 at 4:26 AM Andrei Gherzan  wrote:
>>
>> From: Andrei Gherzan 
>>
>> Without this, compiling gcc plugins will fail with an error similar to:
>> [...]
>> fatal error: ./config/i386/linux64.h: No such file or directory
>> [...]
>>
>> Signed-off-by: Andrei Gherzan 
>> ---
>>  meta/recipes-devtools/gcc/gcc-11.2.inc|  1 +
>>  .../0001-Fix-install-path-of-linux64.h.patch  | 33 +++
>>  2 files changed, 34 insertions(+)
>>  create mode 100644 
>> meta/recipes-devtools/gcc/gcc/0001-Fix-install-path-of-linux64.h.patch
>>
>> diff --git a/meta/recipes-devtools/gcc/gcc-11.2.inc 
>> b/meta/recipes-devtools/gcc/gcc-11.2.inc
>> index e352c958de..f07a5be507 100644
>> --- a/meta/recipes-devtools/gcc/gcc-11.2.inc
>> +++ b/meta/recipes-devtools/gcc/gcc-11.2.inc
>> @@ -59,6 +59,7 @@ SRC_URI = "\
>> file://0037-libatomic-Do-not-enforce-march-on-aarch64.patch \
>> 
>> file://0041-apply-debug-prefix-maps-before-checksumming-DIEs.patch \
>> 
>> file://0006-If-CXXFLAGS-contains-something-unsupported-by-the-bu.patch \
>> +   file://0001-Fix-install-path-of-linux64.h.patch \
>> file://0001-CVE-2021-35465.patch \
>> file://0002-CVE-2021-35465.patch \
>> file://0003-CVE-2021-35465.patch \
>> diff --git 
>> a/meta/recipes-devtools/gcc/gcc/0001-Fix-install-path-of-linux64.h.patch 
>> b/meta/recipes-devtools/gcc/gcc/0001-Fix-install-path-of-linux64.h.patch
>> new file mode 100644
>> index 000000..55f78eaa0b
>> --- /dev/null
>> +++ b/meta/recipes-devtools/gcc/gcc/0001-Fix-install-path-of-linux64.h.patch
>> @@ -0,0 +1,33 @@
>> +From 58211c7ceb0510b2a11a7f1da3c7fa968c658749 Mon Sep 17 00:00:00 2001
>> +From: Andrei Gherzan 
>> +Date: Wed, 22 Dec 2021 12:49:25 +0100
>> +Subject: [PATCH] Fix install path of linux64.h
>> +
>> +We add linux64.h to tm includes[1] as a relative path to B. This patch
>> +adapts the install path of linux64.h to match the include in tm.h.
>> +
>> +[1] 0016-Use-the-multilib-config-files-from-B-instead-of-usin.patch
>> +
>> +Signed-off-by: Andrei Gherzan 
>> +
>> +Upstream-Status: Inappropriate [configuration]
>> +---
>> + gcc/Makefile.in | 2 ++
>> + 1 file changed, 2 insertions(+)
>> +
>> +diff --git a/gcc/Makefile.in b/gcc/Makefile.in
>> +index 9b17d120a..d175ec4e3 100644
>> +--- a/gcc/Makefile.in
>>  b/gcc/Makefile.in
>> +@@ -3693,6 +3693,8 @@ install-plugin: installdirs lang.install-plugin 
>> s-header-vars install-gengtype
>> + "$(srcdir)"/config/* | "$(srcdir)"/common/config/* \
>> + | "$(srcdir)"/c-family/* | "$(srcdir)"/*.def ) \
>> +   base=`echo "$$path" | sed -e "s|$$srcdirstrip/||"`;; \
>> ++./* ) \
>> ++  base=`dirname $$path`;;\
>
> this needs better explaining, and I have a hunch that it could be a
> broad brush too,

The initial fix was to "case it" on the specific header file but I reckon this 
will be useful for other ./* header that might be added in the future.

I'm going to explain it more in git log and also make it specific to the header.

Andrei

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#160230): 
https://lists.openembedded.org/g/openembedded-core/message/160230
Mute This Topic: https://lists.openembedded.org/mt/87916998/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH] gcc: Fix tm.h plugin header

[Andrei Gherzan]

Hi Richard,

On Tue, 21 Dec 2021, at 12:04, Richard Purdie wrote:
> On Tue, 2021-12-21 at 11:56 +0000, Andrei Gherzan wrote:
>> On Mon, 20 Dec 2021, at 01:39, Bernhard Rosenkränzer via
>> lists.openembedded.org wrote:
>> > On Thu, Dec 9, 2021 at 07:40 PM, Andrei Gherzan wrote:
>> >  
>> > > On Thu, 9 Dec 2021, at 16:40, Khem Raj wrote:
>> > >  
>> > > > On Thu, Dec 9, 2021 at 7:40 AM Andrei Gherzan 
>> > > > wrote:
>> > > >  
>> > > > > From: Andrei Gherzan 
>> > > > > 
>> > > > > On x86-64, tm.h (needed to build gcc plugins) tries to include
>> > > > > config/i386/linux64.h, which isn't installed. Fortunately it also
>> > > > > isn't
>> > > > > used, so simply removing the include statement is an ok fix.
>> > > > is it due to multilib support ? if so we might be ok since we may not
>> > > > be using it
>> > > > but really it will be good to check it with multilib builds of
>> > > > x86_64/x86
>> > > I don't think it is related to multilib but I'll give multilib a try. In
>> > > my case, the issue was revealed when compiling a kernel plugin config. I
>> > > can't remember right now which one but I can replicate it for logs.
>> > Hi,
>> > I've had a closer look at the problem, and can confirm the patch doesn't
>> > break even in multilib setups.
>> > 
>> > The problem is that in a non-multilib setup, the config/i386/linux64.h
>> > header is not generated, but tm.h tries to include it nevertheless, causing
>> > any gcc plugin that #includes tm.h (such as all the gcc plugins in the
>> > kernel -- tm.h is included by scripts/gcc-plugins/gcc-common.h) to fail to
>> > build.
>> > An alternative fix would be adding
>> > mkdir -p ${D}${libdir}/gcc/${TARGET_SYS}/${BINV}/plugin/include/config/i386
>> > touch 
>> > ${D}${libdir}/gcc/${TARGET_SYS}/${BINV}/plugin/include/config/i386/lin
>> > ux64.h
>> > (creating the file if it isn't there) instead. This would make sure that in
>> > cases where config/i386/linux64.h does exist, it doesn't get removed from
>> > tm.h (potentially fixing plugins that reference any of the #defines in
>> > i386/linux64.h without including the file manually -- but I have yet to see
>> > any such plugin).
>> > 
>> > I will try to get a better fix (not adding the include statement to tm.h in
>> > the first place rather than having to remove it later in install scripts)
>> > upstream, but in the mean time, the patch fixes our builds before the 
>> > better
>> > fix is ready/applied.
>> 
>> Ping on this patch. Any chance we can pull it in as a first iteration of the
>> solution?
>
> I don't like sed in this context as if the code changes, it silently stops
> working and we struggle to know what broke or whether we need to fix it. We
> don't have any test case.
>
> Given all that, the touch of the file is a neater solution as it is more 
> obvious
> what it is doing. I'd also want to see some more detailed comments in the code
> about what it is doing and why.
>
> Maintainability of these kinds of fixes is key.

I totally agree so I dug a bit more into this and arrived at a different fix. 
Pushed it to the ml - 
https://lists.openembedded.org/g/openembedded-core/message/159978

---
Andrei

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159979): 
https://lists.openembedded.org/g/openembedded-core/message/159979
Mute This Topic: https://lists.openembedded.org/mt/87614108/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH] gcc: Fix compile of gcc plugins

[Andrei Gherzan]

From: Andrei Gherzan 

Without this, compiling gcc plugins will fail with an error similar to:
[...]
fatal error: ./config/i386/linux64.h: No such file or directory
[...]

Signed-off-by: Andrei Gherzan 
---
 meta/recipes-devtools/gcc/gcc-11.2.inc|  1 +
 .../0001-Fix-install-path-of-linux64.h.patch  | 33 +++
 2 files changed, 34 insertions(+)
 create mode 100644 
meta/recipes-devtools/gcc/gcc/0001-Fix-install-path-of-linux64.h.patch

diff --git a/meta/recipes-devtools/gcc/gcc-11.2.inc 
b/meta/recipes-devtools/gcc/gcc-11.2.inc
index e352c958de..f07a5be507 100644
--- a/meta/recipes-devtools/gcc/gcc-11.2.inc
+++ b/meta/recipes-devtools/gcc/gcc-11.2.inc
@@ -59,6 +59,7 @@ SRC_URI = "\
file://0037-libatomic-Do-not-enforce-march-on-aarch64.patch \
file://0041-apply-debug-prefix-maps-before-checksumming-DIEs.patch \

file://0006-If-CXXFLAGS-contains-something-unsupported-by-the-bu.patch \
+   file://0001-Fix-install-path-of-linux64.h.patch \
file://0001-CVE-2021-35465.patch \
file://0002-CVE-2021-35465.patch \
file://0003-CVE-2021-35465.patch \
diff --git 
a/meta/recipes-devtools/gcc/gcc/0001-Fix-install-path-of-linux64.h.patch 
b/meta/recipes-devtools/gcc/gcc/0001-Fix-install-path-of-linux64.h.patch
new file mode 100644
index 00..55f78eaa0b
--- /dev/null
+++ b/meta/recipes-devtools/gcc/gcc/0001-Fix-install-path-of-linux64.h.patch
@@ -0,0 +1,33 @@
+From 58211c7ceb0510b2a11a7f1da3c7fa968c658749 Mon Sep 17 00:00:00 2001
+From: Andrei Gherzan 
+Date: Wed, 22 Dec 2021 12:49:25 +0100
+Subject: [PATCH] Fix install path of linux64.h
+
+We add linux64.h to tm includes[1] as a relative path to B. This patch
+adapts the install path of linux64.h to match the include in tm.h.
+
+[1] 0016-Use-the-multilib-config-files-from-B-instead-of-usin.patch
+
+Signed-off-by: Andrei Gherzan 
+
+Upstream-Status: Inappropriate [configuration]
+---
+ gcc/Makefile.in | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/gcc/Makefile.in b/gcc/Makefile.in
+index 9b17d120a..d175ec4e3 100644
+--- a/gcc/Makefile.in
 b/gcc/Makefile.in
+@@ -3693,6 +3693,8 @@ install-plugin: installdirs lang.install-plugin 
s-header-vars install-gengtype
+ "$(srcdir)"/config/* | "$(srcdir)"/common/config/* \
+ | "$(srcdir)"/c-family/* | "$(srcdir)"/*.def ) \
+   base=`echo "$$path" | sed -e "s|$$srcdirstrip/||"`;; \
++./* ) \
++  base=`dirname $$path`;;\
+ *) base=`basename $$path` ;; \
+ esac; \
+ dest=$(plugin_includedir)/$$base; \
+-- 
+2.25.1
+
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159978): 
https://lists.openembedded.org/g/openembedded-core/message/159978
Mute This Topic: https://lists.openembedded.org/mt/87916998/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH] gcc: Fix tm.h plugin header

[Andrei Gherzan]

On Mon, 20 Dec 2021, at 01:39, Bernhard Rosenkränzer via lists.openembedded.org 
wrote:
> On Thu, Dec 9, 2021 at 07:40 PM, Andrei Gherzan wrote:
> 
>> On Thu, 9 Dec 2021, at 16:40, Khem Raj wrote:
>> 
>>> On Thu, Dec 9, 2021 at 7:40 AM Andrei Gherzan  wrote:
>>> 
>>>> From: Andrei Gherzan 
>>>> 
>>>> On x86-64, tm.h (needed to build gcc plugins) tries to include
>>>> config/i386/linux64.h, which isn't installed. Fortunately it also isn't
>>>> used, so simply removing the include statement is an ok fix.
>>> is it due to multilib support ? if so we might be ok since we may not
>>> be using it
>>> but really it will be good to check it with multilib builds of x86_64/x86
>> I don't think it is related to multilib but I'll give multilib a try. In my 
>> case, the issue was revealed when compiling a kernel plugin config. I can't 
>> remember right now which one but I can replicate it for logs.
> Hi,
> I've had a closer look at the problem, and can confirm the patch doesn't 
> break even in multilib setups.
> 
> The problem is that in a non-multilib setup, the config/i386/linux64.h header 
> is not generated, but tm.h tries to include it nevertheless, causing any gcc 
> plugin that #includes tm.h (such as all the gcc plugins in the kernel -- tm.h 
> is included by scripts/gcc-plugins/gcc-common.h) to fail to build.
> An alternative fix would be adding
> mkdir -p ${D}${libdir}/gcc/${TARGET_SYS}/${BINV}/plugin/include/config/i386
> touch 
> ${D}${libdir}/gcc/${TARGET_SYS}/${BINV}/plugin/include/config/i386/linux64.h
> (creating the file if it isn't there) instead. This would make sure that in 
> cases where config/i386/linux64.h does exist, it doesn't get removed from 
> tm.h (potentially fixing plugins that reference any of the #defines in 
> i386/linux64.h without including the file manually -- but I have yet to see 
> any such plugin).
> 
> I will try to get a better fix (not adding the include statement to tm.h in 
> the first place rather than having to remove it later in install scripts) 
> upstream, but in the mean time, the patch fixes our builds before the better 
> fix is ready/applied.

Ping on this patch. Any chance we can pull it in as a first iteration of the 
solution?

---
Andrei

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159913): 
https://lists.openembedded.org/g/openembedded-core/message/159913
Mute This Topic: https://lists.openembedded.org/mt/87614108/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH] gcc: Fix tm.h plugin header

[Andrei Gherzan]

On Thu, 9 Dec 2021, at 16:40, Khem Raj wrote:
> On Thu, Dec 9, 2021 at 7:40 AM Andrei Gherzan  wrote:
>>
>> From: Andrei Gherzan 
>>
>> On x86-64, tm.h (needed to build gcc plugins) tries to include
>> config/i386/linux64.h, which isn't installed. Fortunately it also isn't
>> used, so simply removing the include statement is an ok fix.
>>
>
> is it due to multilib support ? if so we might be ok since we may not
> be using it
> but really it will be good to check it with multilib builds of x86_64/x86

I don't think it is related to multilib but I'll give multilib a try. In my 
case, the issue was revealed when compiling a kernel plugin config. I can't 
remember right now which one but I can replicate it for logs.

--
Andrei

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159474): 
https://lists.openembedded.org/g/openembedded-core/message/159474
Mute This Topic: https://lists.openembedded.org/mt/87614108/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH] mesa: Avoid PACKAGECONFIG warning for broadcom entry

[Andrei Gherzan]

Hi,

On Thu, 9 Dec 2021, at 15:41, Konrad Weihmann wrote:
> On 09.12.21 16:38, Andrei Gherzan wrote:
>> From: Andrei Gherzan 
>> 
>> Signed-off-by: Andrei Gherzan 
>> ---
>>   meta/recipes-graphics/mesa/mesa.inc | 1 +
>>   1 file changed, 1 insertion(+)
>> 
>> diff --git a/meta/recipes-graphics/mesa/mesa.inc 
>> b/meta/recipes-graphics/mesa/mesa.inc
>> index c894c2dab5..8db91a7b2e 100644
>> --- a/meta/recipes-graphics/mesa/mesa.inc
>> +++ b/meta/recipes-graphics/mesa/mesa.inc
>> @@ -128,6 +128,7 @@ PACKAGECONFIG[egl] = "-Degl=enabled, -Degl=disabled"
>>   PACKAGECONFIG[broadcom] = ""
>
> Isn't that the very same as this one ^^^?

It is indeed. Khem was faster and I haven't seen his patch. Can be ignored.

It was fixes as part of

commit 6add96e4af46eaabb6c70e3ce3a27a4b198d7cb6
Author: Khem Raj 
Date:   Tue Dec 7 12:16:43 2021 -0800
mesa: Define broadcom packageconfig knob

--
Andrei

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159459): 
https://lists.openembedded.org/g/openembedded-core/message/159459
Mute This Topic: https://lists.openembedded.org/mt/87614068/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH] gcc: Fix tm.h plugin header

[Andrei Gherzan]

From: Andrei Gherzan 

On x86-64, tm.h (needed to build gcc plugins) tries to include
config/i386/linux64.h, which isn't installed. Fortunately it also isn't
used, so simply removing the include statement is an ok fix.

Signed-off-by: Bernhard Rosenkränzer 
Signed-off-by: Andrei Gherzan 
---
 meta/recipes-devtools/gcc/gcc-cross-canadian.inc | 3 +++
 meta/recipes-devtools/gcc/gcc-cross.inc  | 3 +++
 meta/recipes-devtools/gcc/gcc-target.inc | 3 +++
 3 files changed, 9 insertions(+)

diff --git a/meta/recipes-devtools/gcc/gcc-cross-canadian.inc 
b/meta/recipes-devtools/gcc/gcc-cross-canadian.inc
index 495dd9070b..a64fcc50ce 100644
--- a/meta/recipes-devtools/gcc/gcc-cross-canadian.inc
+++ b/meta/recipes-devtools/gcc/gcc-cross-canadian.inc
@@ -139,6 +139,9 @@ do_install () {
cp ${S}/libquadmath/quadmath.h 
${D}${libdir}/gcc/${TARGET_SYS}/${BINV}/include/
cp ${S}/libquadmath/quadmath_weak.h 
${D}${libdir}/gcc/${TARGET_SYS}/${BINV}/include/
 
+   # Fix a plugin header including a nonexistant (and unnecessary) header
+   sed -i -e '/config\/i386\/linux64\.h/d' 
${D}${libdir}/gcc/${TARGET_SYS}/${BINV}/plugin/include/tm.h
+
# install LTO linker plugins where binutils tools can find it
install -d ${D}${libdir}/bfd-plugins
ln -sf ${LIBRELPATH}/liblto_plugin.so 
${D}${libdir}/bfd-plugins/liblto_plugin.so
diff --git a/meta/recipes-devtools/gcc/gcc-cross.inc 
b/meta/recipes-devtools/gcc/gcc-cross.inc
index 3ffa1f0c46..ac34d5116a 100644
--- a/meta/recipes-devtools/gcc/gcc-cross.inc
+++ b/meta/recipes-devtools/gcc/gcc-cross.inc
@@ -119,6 +119,9 @@ do_install () {
cp ${S}/libquadmath/quadmath.h 
${D}${libdir}/gcc/${TARGET_SYS}/${BINV}/include/
cp ${S}/libquadmath/quadmath_weak.h 
${D}${libdir}/gcc/${TARGET_SYS}/${BINV}/include/
 
+   # Fix a plugin header including a nonexistant (and unnecessary) header
+   sed -i -e '/config\/i386\/linux64\.h/d' 
${D}${libdir}/gcc/${TARGET_SYS}/${BINV}/plugin/include/tm.h
+
find ${D}${libdir}/gcc/${TARGET_SYS}/${BINV}/include-fixed -type f -not 
-name "README" -not -name limits.h -not -name syslimits.h | xargs rm -f
 
# install LTO linker plugins where binutils tools can find it
diff --git a/meta/recipes-devtools/gcc/gcc-target.inc 
b/meta/recipes-devtools/gcc/gcc-target.inc
index bf55e692e6..4d087c5183 100644
--- a/meta/recipes-devtools/gcc/gcc-target.inc
+++ b/meta/recipes-devtools/gcc/gcc-target.inc
@@ -187,6 +187,9 @@ do_install () {
rm -f 
${D}${libdir}/gcc/${TARGET_SYS}/${BINV}/plugin/include/auto-build.h
rm -f ${D}${libdir}/gcc/${TARGET_SYS}/${BINV}/plugin/include/bconfig.h
 
+   # Fix a plugin header including a nonexistant (and unnecessary) header
+   sed -i -e '/config\/i386\/linux64\.h/d' 
${D}${libdir}/gcc/${TARGET_SYS}/${BINV}/plugin/include/tm.h
+
cd ${D}${bindir}
 
# We care about g++ not c++
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159457): 
https://lists.openembedded.org/g/openembedded-core/message/159457
Mute This Topic: https://lists.openembedded.org/mt/87614108/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH] mesa: Avoid PACKAGECONFIG warning for broadcom entry

[Andrei Gherzan]

From: Andrei Gherzan 

Signed-off-by: Andrei Gherzan 
---
 meta/recipes-graphics/mesa/mesa.inc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-graphics/mesa/mesa.inc 
b/meta/recipes-graphics/mesa/mesa.inc
index c894c2dab5..8db91a7b2e 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -128,6 +128,7 @@ PACKAGECONFIG[egl] = "-Degl=enabled, -Degl=disabled"
 PACKAGECONFIG[broadcom] = ""
 PACKAGECONFIG[etnaviv] = ""
 PACKAGECONFIG[freedreno] = ""
+PACKAGECONFIG[broadcom] = ""
 PACKAGECONFIG[kmsro] = ""
 PACKAGECONFIG[vc4] = ""
 PACKAGECONFIG[v3d] = ""
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159456): 
https://lists.openembedded.org/g/openembedded-core/message/159456
Mute This Topic: https://lists.openembedded.org/mt/87614068/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH] qemu: Define libnfs PACKAGECONFIG

[Andrei Gherzan]

From: Andrei Gherzan 

The upstream qemu recipe uses host's pkg-config files as a solution to
detecting host's SDL. This has a side effect of using other host
libraries that are later queried by the configure script. This can get
into a situation when the host provides libnfs (for example) and because
later this dependency is not in place anymore, qemu will fail at
runtime.

This change adds a PACKAGECONFIG definition for libnfs that is disabled
by default, in turn disabling the pkgconfig autodetection in configure.

Signed-off-by: Andrei Gherzan 
---
 meta/recipes-devtools/qemu/qemu.inc | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-devtools/qemu/qemu.inc 
b/meta/recipes-devtools/qemu/qemu.inc
index 76e8da159c..4c94060222 100644
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtools/qemu/qemu.inc
@@ -203,6 +203,8 @@ PACKAGECONFIG[vhost] = 
"--enable-vhost-net,--disable-vhost-net,,"
 PACKAGECONFIG[ust] = 
"--enable-trace-backend=ust,--enable-trace-backend=nop,lttng-ust,"
 PACKAGECONFIG[pie] = "--enable-pie,--disable-pie,,"
 PACKAGECONFIG[seccomp] = "--enable-seccomp,--disable-seccomp,libseccomp"
+# libnfs is currently provided by meta-kodi
+PACKAGECONFIG[libnfs] = "--enable-libnfs,--disable-libnfs,libnfs"
 
 INSANE_SKIP:${PN} = "arch"
 
-- 
2.33.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#156694): 
https://lists.openembedded.org/g/openembedded-core/message/156694
Mute This Topic: https://lists.openembedded.org/mt/86117490/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [dunfell][PATCH 1/2] bitbake: fetch2: fix handling of `\` in file:// SRC_URI

[Andrei Gherzan]

Hey,

On Tue, 24 Aug 2021, at 16:25, Andrei Gherzan wrote:
> On Tue, 24 Aug 2021, at 15:24, Richard Purdie wrote:
> > On Tue, 2021-08-24 at 04:20 -1000, Steve Sakoman wrote:
> > > On Mon, Aug 23, 2021 at 3:53 AM Andrei Gherzan  wrote:
> > > > 
> > > > From: Leif Middelschulte 
> > > > 
> > > > Using backslashes in file:// URIs was broken.
> > > > Either the resolver would fail or the subsequent `cp` command.
> > > > Try to avoid this by putting the filenames into quotes.
> > > > 
> > > > Fixes https://bugzilla.yoctoproject.org/show_bug.cgi?id=8161
> > > > 
> > > > (Bitbake rev: aa857fa2e9cf3b0e43a9049b04ec4b0b3c779b11)
> > > 
> > > Patches for bitbake should be sent to: 
> > > bitbake-de...@lists.openembedded.org
> > > 
> > > I tried applying this patch, but found that it caused errors on the 
> > > autobuilder:
> > > 
> > > https://errors.yoctoproject.org/Errors/Build/129189/
> > > 
> > 
> > We dropped wildcard support in master but that is still present in dunfell. 
> > That
> > means we can't quote things as we are relying on expansion of the wildcards 
> > for
> > some SRC_URIs. This could be difficult to fix with the compatibility 
> > constraints
> > of an older release funfortunately :/.
> 
> Got it now. That's going to be painful indeed. I can't think of an easy 
> way out of this either.

Can you guys think of a way forward with this? Or shall we just drop it and 
consider it unsupported?

Andrei

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#155524): 
https://lists.openembedded.org/g/openembedded-core/message/155524
Mute This Topic: https://lists.openembedded.org/mt/85085599/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [dunfell][PATCH 1/2] bitbake: fetch2: fix handling of `\` in file:// SRC_URI

[Andrei Gherzan]

On Tue, 24 Aug 2021, at 15:24, Richard Purdie wrote:
> On Tue, 2021-08-24 at 04:20 -1000, Steve Sakoman wrote:
> > On Mon, Aug 23, 2021 at 3:53 AM Andrei Gherzan  wrote:
> > > 
> > > From: Leif Middelschulte 
> > > 
> > > Using backslashes in file:// URIs was broken.
> > > Either the resolver would fail or the subsequent `cp` command.
> > > Try to avoid this by putting the filenames into quotes.
> > > 
> > > Fixes https://bugzilla.yoctoproject.org/show_bug.cgi?id=8161
> > > 
> > > (Bitbake rev: aa857fa2e9cf3b0e43a9049b04ec4b0b3c779b11)
> > 
> > Patches for bitbake should be sent to: bitbake-de...@lists.openembedded.org
> > 
> > I tried applying this patch, but found that it caused errors on the 
> > autobuilder:
> > 
> > https://errors.yoctoproject.org/Errors/Build/129189/
> > 
> 
> We dropped wildcard support in master but that is still present in dunfell. 
> That
> means we can't quote things as we are relying on expansion of the wildcards 
> for
> some SRC_URIs. This could be difficult to fix with the compatibility 
> constraints
> of an older release funfortunately :/.

Got it now. That's going to be painful indeed. I can't think of an easy way out 
of this either.

Andrei

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#155226): 
https://lists.openembedded.org/g/openembedded-core/message/155226
Mute This Topic: https://lists.openembedded.org/mt/85085599/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [dunfell][PATCH 1/2] bitbake: fetch2: fix handling of `\` in file:// SRC_URI

[Andrei Gherzan]

From: Leif Middelschulte 

Using backslashes in file:// URIs was broken.
Either the resolver would fail or the subsequent `cp` command.
Try to avoid this by putting the filenames into quotes.

Fixes https://bugzilla.yoctoproject.org/show_bug.cgi?id=8161

(Bitbake rev: aa857fa2e9cf3b0e43a9049b04ec4b0b3c779b11)

Signed-off-by: Leif Middelschulte 
Signed-off-by: Richard Purdie 
---
 bitbake/lib/bb/fetch2/__init__.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bitbake/lib/bb/fetch2/__init__.py 
b/bitbake/lib/bb/fetch2/__init__.py
index dc99914cd9..ece07f611c 100644
--- a/bitbake/lib/bb/fetch2/__init__.py
+++ b/bitbake/lib/bb/fetch2/__init__.py
@@ -1525,7 +1525,7 @@ class FetchMethod(object):
 if urlpath.find("/") != -1:
 destdir = urlpath.rsplit("/", 1)[0] + '/'
 bb.utils.mkdirhier("%s/%s" % (unpackdir, destdir))
-cmd = 'cp -fpPRH %s %s' % (file, destdir)
+cmd = 'cp -fpPRH "%s" "%s"' % (file, destdir)
 
 if not cmd:
 return
-- 
2.31.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#155167): 
https://lists.openembedded.org/g/openembedded-core/message/155167
Mute This Topic: https://lists.openembedded.org/mt/85085599/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [dunfell][PATCH 2/2] Use the label provided when formating a dos partition

[Andrei Gherzan]

From: jbouchard 

Previously the bootimg-pcbios wic plugin was not respecting
the --label option provided from the wks file. The plugin
was setting the label to 'boot'. With this fix, the --label
option is use. If no option are specified, then the default
is 'boot'.

(From OE-Core rev: 0fd7a73c1bd2486b7a022f0f69bbcb2e0d9cb141)

Signed-off-by: jbouchard 
Signed-off-by: Alexandre Belloni 
Signed-off-by: Richard Purdie 
---
 scripts/lib/wic/plugins/source/bootimg-pcbios.py | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/scripts/lib/wic/plugins/source/bootimg-pcbios.py 
b/scripts/lib/wic/plugins/source/bootimg-pcbios.py
index f2639e7004..32e47f1831 100644
--- a/scripts/lib/wic/plugins/source/bootimg-pcbios.py
+++ b/scripts/lib/wic/plugins/source/bootimg-pcbios.py
@@ -186,8 +186,10 @@ class BootimgPcbiosPlugin(SourcePlugin):
 # dosfs image, created by mkdosfs
 bootimg = "%s/boot%s.img" % (cr_workdir, part.lineno)
 
-dosfs_cmd = "mkdosfs -n boot -i %s -S 512 -C %s %d" % \
-(part.fsuuid, bootimg, blocks)
+label = part.label if part.label else "boot"
+
+dosfs_cmd = "mkdosfs -n %s -i %s -S 512 -C %s %d" % \
+(label, part.fsuuid, bootimg, blocks)
 exec_native_cmd(dosfs_cmd, native_sysroot)
 
 mcopy_cmd = "mcopy -i %s -s %s/* ::/" % (bootimg, hdddir)
-- 
2.31.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#155166): 
https://lists.openembedded.org/g/openembedded-core/message/155166
Mute This Topic: https://lists.openembedded.org/mt/85085598/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [dunfell][PATCH 1/1] ovmf: Fix VLA warnings with GCC 11

[Andrei Gherzan]

From: Khem Raj 

(From OE-Core rev: 5406ce83e07c3f89b9f2bb26f083861467b7bc59)

Signed-off-by: Khem Raj 
Signed-off-by: Richard Purdie 
---
 .../ovmf/0001-Fix-VLA-parameter-warning.patch | 51 +++
 meta/recipes-core/ovmf/ovmf_git.bb|  3 +-
 2 files changed, 53 insertions(+), 1 deletion(-)
 create mode 100644 
meta/recipes-core/ovmf/ovmf/0001-Fix-VLA-parameter-warning.patch

diff --git a/meta/recipes-core/ovmf/ovmf/0001-Fix-VLA-parameter-warning.patch 
b/meta/recipes-core/ovmf/ovmf/0001-Fix-VLA-parameter-warning.patch
new file mode 100644
index 00..d658123b81
--- /dev/null
+++ b/meta/recipes-core/ovmf/ovmf/0001-Fix-VLA-parameter-warning.patch
@@ -0,0 +1,51 @@
+From 498627ebda6271b59920f43a0b9b6187edeb7b09 Mon Sep 17 00:00:00 2001
+From: Adrian Herrera 
+Date: Mon, 22 Mar 2021 21:06:47 +
+Subject: [PATCH] Fix VLA parameter warning
+
+Make VLA buffer types consistent in declarations and definitions.
+Resolves build crash when using -Werror due to "vla-parameter" warning.
+
+Upstream-Status: Submitted [https://github.com/google/brotli/pull/893]
+Signed-off-by: Adrian Herrera 
+---
+ c/dec/decode.c | 6 --
+ c/enc/encode.c | 5 +++--
+ 2 files changed, 7 insertions(+), 4 deletions(-)
+
+diff --git a/BaseTools/Source/C/BrotliCompress/brotli/c/dec/decode.c 
b/BaseTools/Source/C/BrotliCompress/brotli/c/dec/decode.c
+index 114c505..bb6f1ab 100644
+--- a/BaseTools/Source/C/BrotliCompress/brotli/c/dec/decode.c
 b/BaseTools/Source/C/BrotliCompress/brotli/c/dec/decode.c
+@@ -2030,8 +2030,10 @@ static BROTLI_NOINLINE BrotliDecoderErrorCode 
SafeProcessCommands(
+ }
+ 
+ BrotliDecoderResult BrotliDecoderDecompress(
+-size_t encoded_size, const uint8_t* encoded_buffer, size_t* decoded_size,
+-uint8_t* decoded_buffer) {
++size_t encoded_size,
++const uint8_t encoded_buffer[BROTLI_ARRAY_PARAM(encoded_size)],
++size_t* decoded_size,
++uint8_t decoded_buffer[BROTLI_ARRAY_PARAM(*decoded_size)]) {
+   BrotliDecoderState s;
+   BrotliDecoderResult result;
+   size_t total_out = 0;
+diff --git a/c/enc/encode.c b/c/enc/encode.c
+index 68548ef..ab0a490 100644
+--- a/BaseTools/Source/C/BrotliCompress/brotli/c/enc/encode.c
 c/BaseTools/Source/C/BrotliCompress/brotli/c/enc/encode.c
+@@ -1470,8 +1470,9 @@ static size_t MakeUncompressedStream(
+ 
+ BROTLI_BOOL BrotliEncoderCompress(
+ int quality, int lgwin, BrotliEncoderMode mode, size_t input_size,
+-const uint8_t* input_buffer, size_t* encoded_size,
+-uint8_t* encoded_buffer) {
++const uint8_t input_buffer[BROTLI_ARRAY_PARAM(input_size)],
++size_t* encoded_size,
++uint8_t encoded_buffer[BROTLI_ARRAY_PARAM(*encoded_size)]) {
+   BrotliEncoderState* s;
+   size_t out_size = *encoded_size;
+   const uint8_t* input_start = input_buffer;
+-- 
+2.31.1
+
diff --git a/meta/recipes-core/ovmf/ovmf_git.bb 
b/meta/recipes-core/ovmf/ovmf_git.bb
index 088e348bdc..a73bb916b0 100644
--- a/meta/recipes-core/ovmf/ovmf_git.bb
+++ b/meta/recipes-core/ovmf/ovmf_git.bb
@@ -17,7 +17,8 @@ SRC_URI = 
"gitsm://github.com/tianocore/edk2.git;branch=master;protocol=https \

file://0002-BaseTools-makefile-adjust-to-build-in-under-bitbake.patch \
file://0003-ovmf-enable-long-path-file.patch \
file://0004-ovmf-Update-to-latest.patch \
-"
+   file://0001-Fix-VLA-parameter-warning.patch \
+   "
 
 PV = "edk2-stable202008"
 SRCREV = "06dc822d045c2bb42e497487935485302486e151"
-- 
2.31.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#154111): 
https://lists.openembedded.org/g/openembedded-core/message/154111
Mute This Topic: https://lists.openembedded.org/mt/84398113/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [dunfell][PATCH 0/1] Backport an ovmf GCC11 fix

[Andrei Gherzan]

From: Andrei Gherzan 

There can be situations where downstreamers work with updated GCC
versions and this fix would help. Even if that is not the case, the fix
is an improvement nevertheless.

Khem Raj (1):
  ovmf: Fix VLA warnings with GCC 11

 .../ovmf/0001-Fix-VLA-parameter-warning.patch | 51 +++
 meta/recipes-core/ovmf/ovmf_git.bb|  3 +-
 2 files changed, 53 insertions(+), 1 deletion(-)
 create mode 100644 
meta/recipes-core/ovmf/ovmf/0001-Fix-VLA-parameter-warning.patch

-- 
2.31.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#154110): 
https://lists.openembedded.org/g/openembedded-core/message/154110
Mute This Topic: https://lists.openembedded.org/mt/84398112/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH] overlayfs.bbclass: generate overlayfs mount units

[Andrei Gherzan]

Hi,

On Thu, 3 Jun 2021, at 15:21, Vyacheslav Yurkov wrote:
> It's often desired in Embedded System design to have a read-only rootfs.
> But a lot of different applications might want to have a read-write access
> to some parts of a filesystem. It can be especially useful when your update
> mechanism overwrites the whole rootfs, but you want your application data
> to be preserved between updates. This class provides a way to achieve that
> by means of overlayfs and at the same time keeping the base rootfs read-only.

I was looking into something like this lately. There are actually two kinds of 
write access - volatile (tmpfs) and persistent (to disk). So my approach would 
have been to use bind mounts from a tmpfs/ext4 based on configuration per 
recipe. Is there any advantage to working with overlayfs in this case? The main 
idea is to have state that doesn't come from the ro part of the OS because 
otherwise, updates will be shadowed by the overlayfs. So I fail to see the 
advantage of using a set of overlayfs mounts instead of bind mounts. At least 
with bind mounts, it will always shadow the rootfs bits so you can catch early 
this case.

Depending on your use case, most of the times, you'd want this "state" setup 
happening pre init (in initramfs, for example), especially if you want to 
handle persistent systemd logging or machine id, etc.

-- 
Andrei Gherzan 
gpg: rsa4096/D4D94F67AD0E9640

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#152807): 
https://lists.openembedded.org/g/openembedded-core/message/152807
Mute This Topic: https://lists.openembedded.org/mt/83284453/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH] ca-certificates: Fix openssl runtime cert dependencies

[Andrei Gherzan]

On Sun, 18 Apr 2021, at 23:53, Khem Raj wrote:
> With commit dc778c70449ee5401b5a24ad18b22b88338c47c5, dependency was
> moved to openssl-bin which in itself was a fine change, but dropping
> dependency on openssl too should have been kept along, dropping this
> meant that openssl binary wont be able to validate secure connections as
> the CApath files wont be installed, which infact are required for
> openssl bins to work, following call e.g. fails
> 
> $ openssl s_client -connect google.com:443
> 
> 
> New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
> Server public key is 256 bit
> Secure Renegotiation IS NOT supported
> Compression: NONE
> Expansion: NONE
> No ALPN negotiated
> Early data was not sent
> Verify return code: 20 (unable to get local issuer certificate)
> 
> 
> The local issuer certs are not found in default location
> /usr/lib/ssh-1.1/certs, this dir and its content is installed by openssl 
> package
> therefore re-add the dependency on openssl

Good idea for a ptest. Change looks good to me.

--
Andrei

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#150875): 
https://lists.openembedded.org/g/openembedded-core/message/150875
Mute This Topic: https://lists.openembedded.org/mt/82197118/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH] webkitgtk: Reduce stack and heap sizes for jsc on musl

[Andrei Gherzan]

Hi,

On Wed, 17 Mar 2021, at 00:31, Khem Raj wrote:
> Fixes
> 
> [YOCTO #14281]
> 
> Signed-off-by: Khem Raj 
> Cc: Andrei Gherzan 
> ---
>  .../webkitgtk/musl-lower-stack-usage.patch| 51 +++
>  meta/recipes-sato/webkit/webkitgtk_2.30.5.bb  |  1 +
>  2 files changed, 52 insertions(+)
>  create mode 100644 
> meta/recipes-sato/webkit/webkitgtk/musl-lower-stack-usage.patch
> 
> diff --git 
> a/meta/recipes-sato/webkit/webkitgtk/musl-lower-stack-usage.patch 
> b/meta/recipes-sato/webkit/webkitgtk/musl-lower-stack-usage.patch
> new file mode 100644
> index 00..3d66766d9a
> --- /dev/null
> +++ b/meta/recipes-sato/webkit/webkitgtk/musl-lower-stack-usage.patch
> @@ -0,0 +1,51 @@
> +reduce thread stack and heap usage for javascriptcore on musl
> +
> +default sizes for musl are smaller compared to glibc, this matches
> +to musl defaults, avoid stack overflow crashes in jscore

Tested and it works as expected. I was fixing it a bit hacky doing something 
similar to https://github.com/yaegashi/muslstack but this is cleaner.

I've backported your patch for dunfell too (rebased the patch).

Andrei

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149603): 
https://lists.openembedded.org/g/openembedded-core/message/149603
Mute This Topic: https://lists.openembedded.org/mt/81392614/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH] glibc: Bring back L1 icache line size

[Andrei Gherzan]

Superseded by https://lists.openembedded.org/g/openembedded-core/message/149192
---
Andrei

On Fri, 19 Feb 2021, at 23:53, Andrei Gherzan wrote:
> From: Andrei Gherzan 
> 
> It was observerd that with glibc 2.33, sysconf reports unsupported
> option (-1) for _SC_LEVEL1_ICACHE_LINESIZE.
> 
> This can be reproduced with sysconf tool:
> 
> ```
> └─❯  docker run -ti --rm archlinux:base-20210214.0.15477 getconf -a |
> grep "GNU_LIBC_VERSION\|LEVEL1_ICACHE_LINESIZE"
> GNU_LIBC_VERSION   glibc 2.33
> LEVEL1_ICACHE_LINESIZE
> └─❯  docker run -ti --rm archlinux:base-20210131.0.14634 getconf -a |
> grep "GNU_LIBC_VERSION\|LEVEL1_ICACHE_LINESIZE"
> GNU_LIBC_VERSION   glibc 2.32
> LEVEL1_ICACHE_LINESIZE 64
> ```
> 
> The offending patch in glibc is:
> 
> commit 2d651eb9265d1366d7b9e881bfddd46db9c1ecc4
> Author: H.J. Lu 
> Date:   Fri Sep 18 07:55:14 2020 -0700
> x86: Move x86 processor cache info to cpu_features
> 
> This patch reverts the above mentioned glibc change. It was tested on
> qemux86.
> 
> Extra small cosmetic tweaks brought you by devtool (a superflous newline
> and whitespace).
> 
> Signed-off-by: Andrei Gherzan 
> ---
> ...x86-processor-cache-info-to-cpu_feat.patch | 1074 +
> meta/recipes-core/glibc/glibc_2.33.bb |4 +-
> 2 files changed, 1076 insertions(+), 2 deletions(-)
> create mode 100644 
> meta/recipes-core/glibc/glibc/0032-Revert-x86-Move-x86-processor-cache-info-to-cpu_feat.patch
> 
> diff --git 
> a/meta/recipes-core/glibc/glibc/0032-Revert-x86-Move-x86-processor-cache-info-to-cpu_feat.patch
>  
> b/meta/recipes-core/glibc/glibc/0032-Revert-x86-Move-x86-processor-cache-info-to-cpu_feat.patch
> new file mode 100644
> index 00..0ff1eba82b
> --- /dev/null
> +++ 
> b/meta/recipes-core/glibc/glibc/0032-Revert-x86-Move-x86-processor-cache-info-to-cpu_feat.patch
> @@ -0,0 +1,1074 @@
> +From 961d681e38d30a4de06c980de0a96464fa3b4d74 Mon Sep 17 00:00:00 2001
> +From: Andrei Gherzan 
> +Date: Fri, 19 Feb 2021 23:06:50 +
> +Subject: [PATCH] Revert "x86: Move x86 processor cache info to cpu_features"
> +
> +This reverts commit 2d651eb9265d1366d7b9e881bfddd46db9c1ecc4.
> +
> +Upstream-Status: Pending
> +Signed-off-by: Andrei Gherzan 
> +---
> + sysdeps/x86/cacheinfo.c|  46 +--
> + sysdeps/x86/cacheinfo.h| 400 +++--
> + sysdeps/x86/cpu-features.c |  35 ++-
> + sysdeps/x86/dl-cacheinfo.h | 460 -
> + sysdeps/x86/include/cpu-features.h |  22 --
> + 5 files changed, 412 insertions(+), 551 deletions(-)
> +
> +diff --git a/sysdeps/x86/cacheinfo.c b/sysdeps/x86/cacheinfo.c
> +index 7b8df45e3b..948dbea3db 100644
> +--- a/sysdeps/x86/cacheinfo.c
>  b/sysdeps/x86/cacheinfo.c
> +@@ -18,8 +18,11 @@
> + 
> + #if IS_IN (libc)
> + 
> ++#include 
> + #include 
> ++#include 
> + #include 
> ++#include 
> + 
> + /* Get the value of the system variable NAME.  */
> + long int
> +@@ -27,45 +30,20 @@ attribute_hidden
> + __cache_sysconf (int name)
> + {
> +   const struct cpu_features *cpu_features = __get_cpu_features ();
> +-  switch (name)
> +-{
> +-case _SC_LEVEL1_ICACHE_SIZE:
> +-  return cpu_features->level1_icache_size;
> + 
> +-case _SC_LEVEL1_DCACHE_SIZE:
> +-  return cpu_features->level1_dcache_size;
> ++  if (cpu_features->basic.kind == arch_kind_intel)
> ++return handle_intel (name, cpu_features);
> + 
> +-case _SC_LEVEL1_DCACHE_ASSOC:
> +-  return cpu_features->level1_dcache_assoc;
> ++  if (cpu_features->basic.kind == arch_kind_amd)
> ++return handle_amd (name);
> + 
> +-case _SC_LEVEL1_DCACHE_LINESIZE:
> +-  return cpu_features->level1_dcache_linesize;
> ++  if (cpu_features->basic.kind == arch_kind_zhaoxin)
> ++return handle_zhaoxin (name);
> + 
> +-case _SC_LEVEL2_CACHE_SIZE:
> +-  return cpu_features->level2_cache_size;
> ++  // XXX Fill in more vendors.
> + 
> +-case _SC_LEVEL2_CACHE_ASSOC:
> +-  return cpu_features->level2_cache_assoc;
> +-
> +-case _SC_LEVEL2_CACHE_LINESIZE:
> +-  return cpu_features->level2_cache_linesize;
> +-
> +-case _SC_LEVEL3_CACHE_SIZE:
> +-  return cpu_features->level3_cache_size;
> +-
> +-case _SC_LEVEL3_CACHE_ASSOC:
> +-  return cpu_features->level3_cache_assoc;
> +-
> +-case _SC_LEVEL3_CACHE_LINESIZE:
> +-  return cpu_features->level3_cache_linesize;
> +-
> +-case _SC_LEVEL4_CACHE_SIZE:
> +-  return cpu_features->level4_cache_size;
> +-
> +-default

[OE-core] [PATCH] glibc: Backport patch to fix _SC_LEVEL1_ICACHE_LINESIZE

[Andrei Gherzan]

From: Andrei Gherzan 

Signed-off-by: Andrei Gherzan 
---
 ...-_SC_LEVEL1_ICACHE_LINESIZE-BZ-27444.patch | 185 ++
 meta/recipes-core/glibc/glibc_2.33.bb |   1 +
 2 files changed, 186 insertions(+)
 create mode 100644 
meta/recipes-core/glibc/glibc/0033-x86-Handle-_SC_LEVEL1_ICACHE_LINESIZE-BZ-27444.patch

diff --git 
a/meta/recipes-core/glibc/glibc/0033-x86-Handle-_SC_LEVEL1_ICACHE_LINESIZE-BZ-27444.patch
 
b/meta/recipes-core/glibc/glibc/0033-x86-Handle-_SC_LEVEL1_ICACHE_LINESIZE-BZ-27444.patch
new file mode 100644
index 00..3a004e227f
--- /dev/null
+++ 
b/meta/recipes-core/glibc/glibc/0033-x86-Handle-_SC_LEVEL1_ICACHE_LINESIZE-BZ-27444.patch
@@ -0,0 +1,185 @@
+From 750b00a1ddae220403fd892a6fd4e0791ffd154a Mon Sep 17 00:00:00 2001
+From: "H.J. Lu" 
+Date: Fri, 18 Sep 2020 07:55:14 -0700
+Subject: [PATCH] x86: Handle _SC_LEVEL1_ICACHE_LINESIZE [BZ #27444]
+
+x86: Move x86 processor cache info to cpu_features
+
+missed _SC_LEVEL1_ICACHE_LINESIZE.
+
+1. Add level1_icache_linesize to struct cpu_features.
+2. Initialize level1_icache_linesize by calling handle_intel,
+handle_zhaoxin and handle_amd with _SC_LEVEL1_ICACHE_LINESIZE.
+3. Return level1_icache_linesize for _SC_LEVEL1_ICACHE_LINESIZE.
+
+Upstream-Status: Backport 
[https://sourceware.org/bugzilla/show_bug.cgi?id=27444]
+Signed-off-by: Andrei Gherzan 
+---
+ sysdeps/x86/Makefile  |  8 +++
+ sysdeps/x86/cacheinfo.c   |  3 +
+ sysdeps/x86/dl-cacheinfo.h|  6 ++
+ sysdeps/x86/include/cpu-features.h|  2 +
+ .../x86/tst-sysconf-cache-linesize-static.c   |  1 +
+ sysdeps/x86/tst-sysconf-cache-linesize.c  | 57 +++
+ 6 files changed, 77 insertions(+)
+ create mode 100644 sysdeps/x86/tst-sysconf-cache-linesize-static.c
+ create mode 100644 sysdeps/x86/tst-sysconf-cache-linesize.c
+
+diff --git a/sysdeps/x86/Makefile b/sysdeps/x86/Makefile
+index dd82674342..d231263051 100644
+--- a/sysdeps/x86/Makefile
 b/sysdeps/x86/Makefile
+@@ -208,3 +208,11 @@ $(objpfx)check-cet.out: $(..)sysdeps/x86/check-cet.awk \
+ generated += check-cet.out
+ endif
+ endif
++
++ifeq ($(subdir),posix)
++tests += \
++  tst-sysconf-cache-linesize \
++  tst-sysconf-cache-linesize-static
++tests-static += \
++  tst-sysconf-cache-linesize-static
++endif
+diff --git a/sysdeps/x86/cacheinfo.c b/sysdeps/x86/cacheinfo.c
+index 7b8df45e3b..5ea4723ca6 100644
+--- a/sysdeps/x86/cacheinfo.c
 b/sysdeps/x86/cacheinfo.c
+@@ -32,6 +32,9 @@ __cache_sysconf (int name)
+ case _SC_LEVEL1_ICACHE_SIZE:
+   return cpu_features->level1_icache_size;
+ 
++case _SC_LEVEL1_ICACHE_LINESIZE:
++  return cpu_features->level1_icache_linesize;
++
+ case _SC_LEVEL1_DCACHE_SIZE:
+   return cpu_features->level1_dcache_size;
+ 
+diff --git a/sysdeps/x86/dl-cacheinfo.h b/sysdeps/x86/dl-cacheinfo.h
+index a31fa0783a..7cd00b92f1 100644
+--- a/sysdeps/x86/dl-cacheinfo.h
 b/sysdeps/x86/dl-cacheinfo.h
+@@ -707,6 +707,7 @@ dl_init_cacheinfo (struct cpu_features *cpu_features)
+   long int core;
+   unsigned int threads = 0;
+   unsigned long int level1_icache_size = -1;
++  unsigned long int level1_icache_linesize = -1;
+   unsigned long int level1_dcache_size = -1;
+   unsigned long int level1_dcache_assoc = -1;
+   unsigned long int level1_dcache_linesize = -1;
+@@ -726,6 +727,8 @@ dl_init_cacheinfo (struct cpu_features *cpu_features)
+ 
+   level1_icache_size
+   = handle_intel (_SC_LEVEL1_ICACHE_SIZE, cpu_features);
++  level1_icache_linesize
++  = handle_intel (_SC_LEVEL1_ICACHE_LINESIZE, cpu_features);
+   level1_dcache_size = data;
+   level1_dcache_assoc
+   = handle_intel (_SC_LEVEL1_DCACHE_ASSOC, cpu_features);
+@@ -753,6 +756,7 @@ dl_init_cacheinfo (struct cpu_features *cpu_features)
+   shared = handle_zhaoxin (_SC_LEVEL3_CACHE_SIZE);
+ 
+   level1_icache_size = handle_zhaoxin (_SC_LEVEL1_ICACHE_SIZE);
++  level1_icache_linesize = handle_zhaoxin (_SC_LEVEL1_ICACHE_LINESIZE);
+   level1_dcache_size = data;
+   level1_dcache_assoc = handle_zhaoxin (_SC_LEVEL1_DCACHE_ASSOC);
+   level1_dcache_linesize = handle_zhaoxin (_SC_LEVEL1_DCACHE_LINESIZE);
+@@ -772,6 +776,7 @@ dl_init_cacheinfo (struct cpu_features *cpu_features)
+   shared = handle_amd (_SC_LEVEL3_CACHE_SIZE);
+ 
+   level1_icache_size = handle_amd (_SC_LEVEL1_ICACHE_SIZE);
++  level1_icache_linesize = handle_amd (_SC_LEVEL1_ICACHE_LINESIZE);
+   level1_dcache_size = data;
+   level1_dcache_assoc = handle_amd (_SC_LEVEL1_DCACHE_ASSOC);
+   level1_dcache_linesize = handle_amd (_SC_LEVEL1_DCACHE_LINESIZE);
+@@ -833,6 +838,7 @@ dl_init_cacheinfo (struct cpu_features *cpu_features)
+ }
+ 
+   cpu_features->level1_icache_size = level1_icache_size;
++  cpu_features->level1_icache_linesize = level1_icache_linesize;
+   cpu_features->level1_dcache_size = level1_dcache_size;
+   cpu_f

Re: [OE-core] [PATCH 2/2] epiphany: Add package configuration for building in developer mode

[Andrei Gherzan]

Hi,

On Fri, 5 Mar 2021, at 08:00, Khem Raj wrote:
> On Thu, Mar 4, 2021 at 3:36 PM Andrei Gherzan  wrote:
> >
> > From: Andrei Gherzan 
> >
> > Signed-off-by: Andrei Gherzan 
> > ---
> >  meta/recipes-gnome/epiphany/epiphany_3.38.2.bb | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/meta/recipes-gnome/epiphany/epiphany_3.38.2.bb 
> > b/meta/recipes-gnome/epiphany/epiphany_3.38.2.bb
> > index 7fedc43a99..8e697b4a44 100644
> > --- a/meta/recipes-gnome/epiphany/epiphany_3.38.2.bb
> > +++ b/meta/recipes-gnome/epiphany/epiphany_3.38.2.bb
> > @@ -21,5 +21,8 @@ SRC_URI = 
> > "${GNOME_MIRROR}/${GNOMEBN}/${@gnome_verdir("${PV}")}/${GNOMEBN}-${PV}
> > "
> >  SRC_URI[archive.sha256sum] = 
> > "8b05f2bcc1e80ecf4a10f6f01b3285087eb4cbdf5741dffb8c0355715ef5116d"
> >
> > +# Developer mode enables debugging
> > +PACKAGECONFIG[developer-mode] = "-Ddeveloper_mode=true"
> 
> add else case to define it to false as well.

Thanks. Sent v2.

---
Andrei

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149059): 
https://lists.openembedded.org/g/openembedded-core/message/149059
Mute This Topic: https://lists.openembedded.org/mt/81090982/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH 1/2] gcr: Add support for building without x11

[Andrei Gherzan]

On Fri, 5 Mar 2021, at 10:23, Alexander Kanavin wrote:
> On Fri, 5 Mar 2021 at 00:36, Andrei Gherzan  wrote:
>>  GNOMEBASEBUILDCLASS = "meson"
>>  GTKDOC_MESON_OPTION = "gtk_doc"
>>  inherit gnomebase gtk-icon-cache gtk-doc features_check 
>> upstream-version-is-even vala gobject-introspection gettext mime mime-xdg
>> -# depends on gtk+3, but also x11 through gtk+-x11
>> -REQUIRED_DISTRO_FEATURES = "x11"
>> 
>>  SRC_URI[archive.sha256sum] = 
>> "17fcaf9c4a93a65fb1c72b82643bb102c13344084687d5886ea66313868d9ec9"
>> 
>> +PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'gtk+', 
>> '', d)}"
>> +PACKAGECONFIG[gtk+] = ",--without-gtk,gtk+3"
> 
> This does not look like a meson option, and needs a on-setting as well. 
> Please test the new options both ways.

Thanks. Sent v2.

---
Andrei

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149058): 
https://lists.openembedded.org/g/openembedded-core/message/149058
Mute This Topic: https://lists.openembedded.org/mt/81090983/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH v2 1/2] gcr: Add support for building without x11

[Andrei Gherzan]

From: Andrei Gherzan 

Signed-off-by: Andrei Gherzan 
---
 meta/recipes-gnome/gcr/gcr_3.38.1.bb | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-gnome/gcr/gcr_3.38.1.bb 
b/meta/recipes-gnome/gcr/gcr_3.38.1.bb
index fe80439b00..563087a360 100644
--- a/meta/recipes-gnome/gcr/gcr_3.38.1.bb
+++ b/meta/recipes-gnome/gcr/gcr_3.38.1.bb
@@ -8,7 +8,7 @@ BUGTRACKER = "https://gitlab.gnome.org/GNOME/gcr/issues;
 LICENSE = "GPLv2"
 LIC_FILES_CHKSUM = "file://COPYING;md5=55ca817ccb7d5b5b66355690e9abc605"
 
-DEPENDS = "gtk+3 p11-kit glib-2.0 libgcrypt gnupg-native \
+DEPENDS = "p11-kit glib-2.0 libgcrypt gnupg-native \
${@bb.utils.contains('GI_DATA_ENABLED', 'True', 'libxslt-native', 
'', d)}"
 
 CACHED_CONFIGUREVARS += "ac_cv_path_GPG='gpg2'"
@@ -16,11 +16,12 @@ CACHED_CONFIGUREVARS += "ac_cv_path_GPG='gpg2'"
 GNOMEBASEBUILDCLASS = "meson"
 GTKDOC_MESON_OPTION = "gtk_doc"
 inherit gnomebase gtk-icon-cache gtk-doc features_check 
upstream-version-is-even vala gobject-introspection gettext mime mime-xdg
-# depends on gtk+3, but also x11 through gtk+-x11
-REQUIRED_DISTRO_FEATURES = "x11"
 
 SRC_URI[archive.sha256sum] = 
"17fcaf9c4a93a65fb1c72b82643bb102c13344084687d5886ea66313868d9ec9"
 
+PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'gtk', '', 
d)}"
+PACKAGECONFIG[gtk] = "-Dgtk=true,-Dgtk=false,gtk+3"
+
 FILES_${PN} += " \
 ${datadir}/dbus-1 \
 ${datadir}/gcr-3 \
-- 
2.30.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149056): 
https://lists.openembedded.org/g/openembedded-core/message/149056
Mute This Topic: https://lists.openembedded.org/mt/81105649/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH v2 2/2] epiphany: Add package configuration for building in developer mode

[Andrei Gherzan]

From: Andrei Gherzan 

Signed-off-by: Andrei Gherzan 
---
 meta/recipes-gnome/epiphany/epiphany_3.38.2.bb | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/meta/recipes-gnome/epiphany/epiphany_3.38.2.bb 
b/meta/recipes-gnome/epiphany/epiphany_3.38.2.bb
index 7fedc43a99..04f340f133 100644
--- a/meta/recipes-gnome/epiphany/epiphany_3.38.2.bb
+++ b/meta/recipes-gnome/epiphany/epiphany_3.38.2.bb
@@ -21,5 +21,8 @@ SRC_URI = 
"${GNOME_MIRROR}/${GNOMEBN}/${@gnome_verdir("${PV}")}/${GNOMEBN}-${PV}
"
 SRC_URI[archive.sha256sum] = 
"8b05f2bcc1e80ecf4a10f6f01b3285087eb4cbdf5741dffb8c0355715ef5116d"
 
+# Developer mode enables debugging
+PACKAGECONFIG[developer-mode] = "-Ddeveloper_mode=true,-Ddeveloper_mode=false"
+
 FILES_${PN} += "${datadir}/dbus-1 ${datadir}/gnome-shell/search-providers 
${datadir}/metainfo"
 RDEPENDS_${PN} = "iso-codes adwaita-icon-theme gsettings-desktop-schemas"
-- 
2.30.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149057): 
https://lists.openembedded.org/g/openembedded-core/message/149057
Mute This Topic: https://lists.openembedded.org/mt/81105650/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH 2/2] epiphany: Add package configuration for building in developer mode

[Andrei Gherzan]

From: Andrei Gherzan 

Signed-off-by: Andrei Gherzan 
---
 meta/recipes-gnome/epiphany/epiphany_3.38.2.bb | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/meta/recipes-gnome/epiphany/epiphany_3.38.2.bb 
b/meta/recipes-gnome/epiphany/epiphany_3.38.2.bb
index 7fedc43a99..8e697b4a44 100644
--- a/meta/recipes-gnome/epiphany/epiphany_3.38.2.bb
+++ b/meta/recipes-gnome/epiphany/epiphany_3.38.2.bb
@@ -21,5 +21,8 @@ SRC_URI = 
"${GNOME_MIRROR}/${GNOMEBN}/${@gnome_verdir("${PV}")}/${GNOMEBN}-${PV}
"
 SRC_URI[archive.sha256sum] = 
"8b05f2bcc1e80ecf4a10f6f01b3285087eb4cbdf5741dffb8c0355715ef5116d"
 
+# Developer mode enables debugging
+PACKAGECONFIG[developer-mode] = "-Ddeveloper_mode=true"
+
 FILES_${PN} += "${datadir}/dbus-1 ${datadir}/gnome-shell/search-providers 
${datadir}/metainfo"
 RDEPENDS_${PN} = "iso-codes adwaita-icon-theme gsettings-desktop-schemas"
-- 
2.30.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#148949): 
https://lists.openembedded.org/g/openembedded-core/message/148949
Mute This Topic: https://lists.openembedded.org/mt/81090982/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH 1/2] gcr: Add support for building without x11

[Andrei Gherzan]

From: Andrei Gherzan 

Signed-off-by: Andrei Gherzan 
---
 meta/recipes-gnome/gcr/gcr_3.38.1.bb | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-gnome/gcr/gcr_3.38.1.bb 
b/meta/recipes-gnome/gcr/gcr_3.38.1.bb
index fe80439b00..292f5b5655 100644
--- a/meta/recipes-gnome/gcr/gcr_3.38.1.bb
+++ b/meta/recipes-gnome/gcr/gcr_3.38.1.bb
@@ -8,7 +8,7 @@ BUGTRACKER = "https://gitlab.gnome.org/GNOME/gcr/issues;
 LICENSE = "GPLv2"
 LIC_FILES_CHKSUM = "file://COPYING;md5=55ca817ccb7d5b5b66355690e9abc605"
 
-DEPENDS = "gtk+3 p11-kit glib-2.0 libgcrypt gnupg-native \
+DEPENDS = "p11-kit glib-2.0 libgcrypt gnupg-native \
${@bb.utils.contains('GI_DATA_ENABLED', 'True', 'libxslt-native', 
'', d)}"
 
 CACHED_CONFIGUREVARS += "ac_cv_path_GPG='gpg2'"
@@ -16,11 +16,12 @@ CACHED_CONFIGUREVARS += "ac_cv_path_GPG='gpg2'"
 GNOMEBASEBUILDCLASS = "meson"
 GTKDOC_MESON_OPTION = "gtk_doc"
 inherit gnomebase gtk-icon-cache gtk-doc features_check 
upstream-version-is-even vala gobject-introspection gettext mime mime-xdg
-# depends on gtk+3, but also x11 through gtk+-x11
-REQUIRED_DISTRO_FEATURES = "x11"
 
 SRC_URI[archive.sha256sum] = 
"17fcaf9c4a93a65fb1c72b82643bb102c13344084687d5886ea66313868d9ec9"
 
+PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'gtk+', '', 
d)}"
+PACKAGECONFIG[gtk+] = ",--without-gtk,gtk+3"
+
 FILES_${PN} += " \
 ${datadir}/dbus-1 \
 ${datadir}/gcr-3 \
-- 
2.30.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#148950): 
https://lists.openembedded.org/g/openembedded-core/message/148950
Mute This Topic: https://lists.openembedded.org/mt/81090983/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [dunfell][PATCH 4/4] qemu: Backport patch to avoid assertion fails on icache line size

[Andrei Gherzan]

From: Andrei Gherzan 

Due to a bug in glibc 2.33, the value of the icache line size is now
reported as unsupported option. This breaks qemu at runtime with:

cacheinfo.c:182: init_cache_info: Assertion `(isize & (isize - 1)) == 0'
failed.
Aborted (core dumped)

We haven't caught this one yet because we were already on qemu 5.2.0
when we started to play with glibc 2.33 so it was only reproducible on
dunfell.

Signed-off-by: Andrei Gherzan 
---
 meta/recipes-devtools/qemu/qemu.inc   |  1 +
 ...fix-crash-when-compiling-with-uClibc.patch | 48 +++
 2 files changed, 49 insertions(+)
 create mode 100644 
meta/recipes-devtools/qemu/qemu/0012-util-cacheinfo-fix-crash-when-compiling-with-uClibc.patch

diff --git a/meta/recipes-devtools/qemu/qemu.inc 
b/meta/recipes-devtools/qemu/qemu.inc
index 7a963ad57c..a1a418374f 100644
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtools/qemu/qemu.inc
@@ -28,6 +28,7 @@ SRC_URI = "https://download.qemu.org/${BPN}-${PV}.tar.xz \
file://0009-Fix-webkitgtk-builds.patch \
file://0010-configure-Add-pkg-config-handling-for-libgcrypt.patch \

file://0011-hw-i386-pc-fix-regression-in-parsing-vga-cmdline-par.patch \
+   
file://0012-util-cacheinfo-fix-crash-when-compiling-with-uClibc.patch \
file://CVE-2019-15890.patch \
file://CVE-2020-1711.patch \
file://CVE-2020-7039-1.patch \
diff --git 
a/meta/recipes-devtools/qemu/qemu/0012-util-cacheinfo-fix-crash-when-compiling-with-uClibc.patch
 
b/meta/recipes-devtools/qemu/qemu/0012-util-cacheinfo-fix-crash-when-compiling-with-uClibc.patch
new file mode 100644
index 00..741a4fce0e
--- /dev/null
+++ 
b/meta/recipes-devtools/qemu/qemu/0012-util-cacheinfo-fix-crash-when-compiling-with-uClibc.patch
@@ -0,0 +1,48 @@
+From 00b5032eaddb7193f03f0a28b10286244d2e2a7b Mon Sep 17 00:00:00 2001
+From: Carlos Santos 
+Date: Thu, 17 Oct 2019 09:37:13 -0300
+Subject: [PATCH 1/1] util/cacheinfo: fix crash when compiling with uClibc
+
+uClibc defines _SC_LEVEL1_ICACHE_LINESIZE and _SC_LEVEL1_DCACHE_LINESIZE
+but the corresponding sysconf calls returns -1, which is a valid result,
+meaning that the limit is indeterminate.
+
+Handle this situation using the fallback values instead of crashing due
+to an assertion failure.
+
+Signed-off-by: Carlos Santos 
+Message-Id: <20191017123713.30192-1-casan...@redhat.com>
+Signed-off-by: Richard Henderson 
+
+Upstream-status: Backport
+Signed-off-by: Andrei Gherzan 
+---
+ util/cacheinfo.c | 10 --
+ 1 file changed, 8 insertions(+), 2 deletions(-)
+
+diff --git a/util/cacheinfo.c b/util/cacheinfo.c
+index ea6f3e99bf..d94dc6adc8 100644
+--- a/util/cacheinfo.c
 b/util/cacheinfo.c
+@@ -93,10 +93,16 @@ static void sys_cache_info(int *isize, int *dsize)
+ static void sys_cache_info(int *isize, int *dsize)
+ {
+ # ifdef _SC_LEVEL1_ICACHE_LINESIZE
+-*isize = sysconf(_SC_LEVEL1_ICACHE_LINESIZE);
++int tmp_isize = (int) sysconf(_SC_LEVEL1_ICACHE_LINESIZE);
++if (tmp_isize > 0) {
++*isize = tmp_isize;
++}
+ # endif
+ # ifdef _SC_LEVEL1_DCACHE_LINESIZE
+-*dsize = sysconf(_SC_LEVEL1_DCACHE_LINESIZE);
++int tmp_dsize = (int) sysconf(_SC_LEVEL1_DCACHE_LINESIZE);
++if (tmp_dsize > 0) {
++*dsize = tmp_dsize;
++}
+ # endif
+ }
+ #endif /* sys_cache_info */
+-- 
+2.30.1
+
-- 
2.30.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#148370): 
https://lists.openembedded.org/g/openembedded-core/message/148370
Mute This Topic: https://lists.openembedded.org/mt/80771005/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [dunfell][PATCH 2/4] oe/recipeutils: Fix copying patches when BBLAYERS entries are not normalised

[Andrei Gherzan]

From: Andrei Gherzan 

`devtool` uses `copy_recipe_files` for the upgrade operation when
creating the new, workspace recipe. Before handling the copy operations,
the function checks the entry in `SRC_URI` against `FILE` while in turn
uses absolute paths. When BBLAYERS contains entries that are not
normalised, this check will fail resulting in having the recipe in the
workspace without the initial patches.

Signef-off-by: Robert Drab 
Signed-off-by: Andrei Gherzan 
---
 meta/lib/oe/recipeutils.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/lib/oe/recipeutils.py b/meta/lib/oe/recipeutils.py
index fde1ad3ddd..f36a2fb0ac 100644
--- a/meta/lib/oe/recipeutils.py
+++ b/meta/lib/oe/recipeutils.py
@@ -409,7 +409,7 @@ def copy_recipe_files(d, tgt_dir, whole_dir=False, 
download=True, all_variants=F
 fetch.download()
 for pth in fetch.localpaths():
 if pth not in localpaths:
-localpaths.append(pth)
+localpaths.append(os.path.abspath(pth))
 uri_values.append(srcuri)
 
 fetch_urls(d)
-- 
2.30.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#148368): 
https://lists.openembedded.org/g/openembedded-core/message/148368
Mute This Topic: https://lists.openembedded.org/mt/80771003/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [dunfell][PATCH 3/4] oeqa/commands: Fix compatibility with python 3.9

[Andrei Gherzan]

From: Richard Purdie 

Python 3.9 dropped isAlive() so use the preferred is_alive().

(From OE-Core rev: 9bb06428cbb2ac0f3d98a1696f050d3393385503)

Signed-off-by: Richard Purdie 
---
 meta/lib/oeqa/utils/commands.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/lib/oeqa/utils/commands.py b/meta/lib/oeqa/utils/commands.py
index 8b3e12038d..a71c16ab14 100644
--- a/meta/lib/oeqa/utils/commands.py
+++ b/meta/lib/oeqa/utils/commands.py
@@ -125,11 +125,11 @@ class Command(object):
 
 def stop(self):
 for thread in self.threads:
-if thread.isAlive():
+if thread.is_alive():
 self.process.terminate()
 # let's give it more time to terminate gracefully before killing it
 thread.join(5)
-if thread.isAlive():
+if thread.is_alive():
 self.process.kill()
 thread.join()
 
-- 
2.30.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#148369): 
https://lists.openembedded.org/g/openembedded-core/message/148369
Mute This Topic: https://lists.openembedded.org/mt/80771004/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [dunfell][PATCH 1/4] pseudo: Backport fixes for glibc 2.33

[Andrei Gherzan]

From: Andrei Gherzan 

Signed-off-by: Andrei Gherzan 
---
 ...h-Fix-pseudo-to-work-with-glibc-2.33.patch | 46 +++
 ...wrapper-for-fstatat-fstatat64-in-gli.patch | 77 +++
 meta/recipes-devtools/pseudo/pseudo_git.bb|  2 +
 3 files changed, 125 insertions(+)
 create mode 100644 
meta/recipes-devtools/pseudo/files/0001-linux-portdefs.h-Fix-pseudo-to-work-with-glibc-2.33.patch
 create mode 100644 
meta/recipes-devtools/pseudo/files/0002-ports-linux-Add-wrapper-for-fstatat-fstatat64-in-gli.patch

diff --git 
a/meta/recipes-devtools/pseudo/files/0001-linux-portdefs.h-Fix-pseudo-to-work-with-glibc-2.33.patch
 
b/meta/recipes-devtools/pseudo/files/0001-linux-portdefs.h-Fix-pseudo-to-work-with-glibc-2.33.patch
new file mode 100644
index 00..7347e13a7d
--- /dev/null
+++ 
b/meta/recipes-devtools/pseudo/files/0001-linux-portdefs.h-Fix-pseudo-to-work-with-glibc-2.33.patch
@@ -0,0 +1,46 @@
+From 3a72456779ff958ab9db274eab665ddb5333d9b2 Mon Sep 17 00:00:00 2001
+From: Richard Purdie 
+Date: Fri, 5 Feb 2021 08:19:01 +
+Subject: [PATCH 3/3] linux/portdefs.h: Fix pseudo to work with glibc 2.33
+
+In glibc 2.33, they've removed the _STAT_VER and _MKNOD_VER definitions
+from public headers. They have no plans to add these back so pseudo needs
+to attempt its own definitions. There is some protection as if they were
+wrong and there was a mismatch, we'd get an error art runtime.
+
+Signed-off-by: Richard Purdie 
+Upstream-Status: Backported [oe-core branch]
+---
+ ports/linux/portdefs.h | 19 +++
+ 1 file changed, 19 insertions(+)
+
+diff --git a/ports/linux/portdefs.h b/ports/linux/portdefs.h
+index a92e969..9545550 100644
+--- a/ports/linux/portdefs.h
 b/ports/linux/portdefs.h
+@@ -34,3 +34,22 @@ GLIBC_COMPAT_SYMBOL(memcpy,2.0);
+ #include 
+ #include 
+ #include 
++
++#ifndef _STAT_VER
++#if defined (__aarch64__)
++#define _STAT_VER 0
++#elif defined (__x86_64__)
++#define _STAT_VER 1
++#else
++#define _STAT_VER 3
++#endif
++#endif
++#ifndef _MKNOD_VER
++#if defined (__aarch64__)
++#define _MKNOD_VER 0
++#elif defined (__x86_64__)
++#define _MKNOD_VER 0
++#else
++#define _MKNOD_VER 1
++#endif
++#endif
+-- 
+2.30.1
+
diff --git 
a/meta/recipes-devtools/pseudo/files/0002-ports-linux-Add-wrapper-for-fstatat-fstatat64-in-gli.patch
 
b/meta/recipes-devtools/pseudo/files/0002-ports-linux-Add-wrapper-for-fstatat-fstatat64-in-gli.patch
new file mode 100644
index 00..8316770f3d
--- /dev/null
+++ 
b/meta/recipes-devtools/pseudo/files/0002-ports-linux-Add-wrapper-for-fstatat-fstatat64-in-gli.patch
@@ -0,0 +1,77 @@
+From 7a5f9e43711d372f4f3c9346b3c3c2959b00770f Mon Sep 17 00:00:00 2001
+From: Richard Purdie 
+Date: Mon, 15 Feb 2021 20:47:39 +
+Subject: [PATCH 2/3] ports/linux: Add wrapper for fstatat/fstatat64 in glibc
+ 2.33
+
+Signed-off-by: Richard Purdie 
+Upstream-Status: Backported [oe-core branch]
+---
+ ports/linux/guts/fstatat.c   | 15 +++
+ ports/linux/guts/fstatat64.c | 15 +++
+ ports/linux/wrapfuncs.in |  2 ++
+ 3 files changed, 32 insertions(+)
+ create mode 100644 ports/linux/guts/fstatat.c
+ create mode 100644 ports/linux/guts/fstatat64.c
+
+diff --git a/ports/linux/guts/fstatat.c b/ports/linux/guts/fstatat.c
+new file mode 100644
+index 000..3267641
+--- /dev/null
 b/ports/linux/guts/fstatat.c
+@@ -0,0 +1,15 @@
++/*
++ * Copyright (c) 2021 Linux Foundation; see
++ * guts/COPYRIGHT for information.
++ *
++ * SPDX-License-Identifier: LGPL-2.1-only
++ *
++ * int fstatat(int dirfd, const char *path, struct stat *buf, int flags)
++ *int rc = -1;
++ */
++
++  rc = wrap___fxstatat(_STAT_VER, dirfd, path, buf, flags);
++
++/*return rc;
++ * }
++ */
+diff --git a/ports/linux/guts/fstatat64.c b/ports/linux/guts/fstatat64.c
+new file mode 100644
+index 000..c981e14
+--- /dev/null
 b/ports/linux/guts/fstatat64.c
+@@ -0,0 +1,15 @@
++/*
++ * Copyright (c) 2021 Linux Foundation; see
++ * guts/COPYRIGHT for information.
++ *
++ * SPDX-License-Identifier: LGPL-2.1-only
++ *
++ * int fstatat64(int dirfd, const char *path, struct stat64 *buf, int flags)
++ *int rc = -1;
++ */
++
++  rc = wrap___fxstatat64(_STAT_VER, dirfd, path, buf, flags);
++
++/*return rc;
++ * }
++ */
+diff --git a/ports/linux/wrapfuncs.in b/ports/linux/wrapfuncs.in
+index aae0f0d..ea27392 100644
+--- a/ports/linux/wrapfuncs.in
 b/ports/linux/wrapfuncs.in
+@@ -22,9 +22,11 @@ int creat64(const char *path, mode_t mode);
+ int stat(const char *path, struct stat *buf); /* real_func=pseudo_stat */
+ int lstat(const char *path, struct stat *buf); /* real_func=pseudo_lstat, 
flags=AT_SYMLINK_NOFOLLOW */
+ int fstat(int fd, struct stat *buf); /* real_func=pseudo_fstat */
++int fstatat(int dirfd, const char *path, struct stat *buf, int flags);
+ int stat64(const char *path, struct stat64 *buf); /* real_func=pseudo_stat64 
*/
+ int lstat64(const char *path, struct stat64 *buf); /* 
real_func=pseudo_lstat64, flags=AT_SYMLINK_NOFOLLOW

[OE-core] [PATCH] glibc: Bring back L1 icache line size

[Andrei Gherzan]

From: Andrei Gherzan 

It was observerd that with glibc 2.33, sysconf reports unsupported
option (-1) for _SC_LEVEL1_ICACHE_LINESIZE.

This can be reproduced with sysconf tool:

```
└─❯  docker run -ti --rm archlinux:base-20210214.0.15477 getconf -a |
grep "GNU_LIBC_VERSION\|LEVEL1_ICACHE_LINESIZE"
GNU_LIBC_VERSION   glibc 2.33
LEVEL1_ICACHE_LINESIZE
└─❯  docker run -ti --rm archlinux:base-20210131.0.14634 getconf -a |
grep "GNU_LIBC_VERSION\|LEVEL1_ICACHE_LINESIZE"
GNU_LIBC_VERSION   glibc 2.32
LEVEL1_ICACHE_LINESIZE 64
```

The offending patch in glibc is:

commit 2d651eb9265d1366d7b9e881bfddd46db9c1ecc4
Author: H.J. Lu 
Date:   Fri Sep 18 07:55:14 2020 -0700
x86: Move x86 processor cache info to cpu_features

This patch reverts the above mentioned glibc change. It was tested on
qemux86.

Extra small cosmetic tweaks brought you by devtool (a superflous newline
and whitespace).

Signed-off-by: Andrei Gherzan 
---
 ...x86-processor-cache-info-to-cpu_feat.patch | 1074 +
 meta/recipes-core/glibc/glibc_2.33.bb |4 +-
 2 files changed, 1076 insertions(+), 2 deletions(-)
 create mode 100644 
meta/recipes-core/glibc/glibc/0032-Revert-x86-Move-x86-processor-cache-info-to-cpu_feat.patch

diff --git 
a/meta/recipes-core/glibc/glibc/0032-Revert-x86-Move-x86-processor-cache-info-to-cpu_feat.patch
 
b/meta/recipes-core/glibc/glibc/0032-Revert-x86-Move-x86-processor-cache-info-to-cpu_feat.patch
new file mode 100644
index 00..0ff1eba82b
--- /dev/null
+++ 
b/meta/recipes-core/glibc/glibc/0032-Revert-x86-Move-x86-processor-cache-info-to-cpu_feat.patch
@@ -0,0 +1,1074 @@
+From 961d681e38d30a4de06c980de0a96464fa3b4d74 Mon Sep 17 00:00:00 2001
+From: Andrei Gherzan 
+Date: Fri, 19 Feb 2021 23:06:50 +
+Subject: [PATCH] Revert "x86: Move x86 processor cache info to cpu_features"
+
+This reverts commit 2d651eb9265d1366d7b9e881bfddd46db9c1ecc4.
+
+Upstream-Status: Pending
+Signed-off-by: Andrei Gherzan 
+---
+ sysdeps/x86/cacheinfo.c|  46 +--
+ sysdeps/x86/cacheinfo.h| 400 +++--
+ sysdeps/x86/cpu-features.c |  35 ++-
+ sysdeps/x86/dl-cacheinfo.h | 460 -
+ sysdeps/x86/include/cpu-features.h |  22 --
+ 5 files changed, 412 insertions(+), 551 deletions(-)
+
+diff --git a/sysdeps/x86/cacheinfo.c b/sysdeps/x86/cacheinfo.c
+index 7b8df45e3b..948dbea3db 100644
+--- a/sysdeps/x86/cacheinfo.c
 b/sysdeps/x86/cacheinfo.c
+@@ -18,8 +18,11 @@
+ 
+ #if IS_IN (libc)
+ 
++#include 
+ #include 
++#include 
+ #include 
++#include 
+ 
+ /* Get the value of the system variable NAME.  */
+ long int
+@@ -27,45 +30,20 @@ attribute_hidden
+ __cache_sysconf (int name)
+ {
+   const struct cpu_features *cpu_features = __get_cpu_features ();
+-  switch (name)
+-{
+-case _SC_LEVEL1_ICACHE_SIZE:
+-  return cpu_features->level1_icache_size;
+ 
+-case _SC_LEVEL1_DCACHE_SIZE:
+-  return cpu_features->level1_dcache_size;
++  if (cpu_features->basic.kind == arch_kind_intel)
++return handle_intel (name, cpu_features);
+ 
+-case _SC_LEVEL1_DCACHE_ASSOC:
+-  return cpu_features->level1_dcache_assoc;
++  if (cpu_features->basic.kind == arch_kind_amd)
++return handle_amd (name);
+ 
+-case _SC_LEVEL1_DCACHE_LINESIZE:
+-  return cpu_features->level1_dcache_linesize;
++  if (cpu_features->basic.kind == arch_kind_zhaoxin)
++return handle_zhaoxin (name);
+ 
+-case _SC_LEVEL2_CACHE_SIZE:
+-  return cpu_features->level2_cache_size;
++  // XXX Fill in more vendors.
+ 
+-case _SC_LEVEL2_CACHE_ASSOC:
+-  return cpu_features->level2_cache_assoc;
+-
+-case _SC_LEVEL2_CACHE_LINESIZE:
+-  return cpu_features->level2_cache_linesize;
+-
+-case _SC_LEVEL3_CACHE_SIZE:
+-  return cpu_features->level3_cache_size;
+-
+-case _SC_LEVEL3_CACHE_ASSOC:
+-  return cpu_features->level3_cache_assoc;
+-
+-case _SC_LEVEL3_CACHE_LINESIZE:
+-  return cpu_features->level3_cache_linesize;
+-
+-case _SC_LEVEL4_CACHE_SIZE:
+-  return cpu_features->level4_cache_size;
+-
+-default:
+-  break;
+-}
+-  return -1;
++  /* CPU not known, we have no information.  */
++  return 0;
+ }
+ 
+ # ifdef SHARED
+diff --git a/sysdeps/x86/cacheinfo.h b/sysdeps/x86/cacheinfo.h
+index 68c253542f..736189f7f2 100644
+--- a/sysdeps/x86/cacheinfo.h
 b/sysdeps/x86/cacheinfo.h
+@@ -18,16 +18,7 @@
+ 
+ #include 
+ #include 
+-#include 
+-#include 
+ 
+-#if HAVE_TUNABLES
+-# define TUNABLE_NAMESPACE cpu
+-# include   /* Get STDOUT_FILENO for _dl_printf.  */
+-# include 
+-#endif
+-
+-#if IS_IN (libc)
+ /* Data cache size for use in memory and string routines, typically
+L1 size, rounded to multiple of 256 bytes.  */
+ long int __x86_data_cache_size_half attribute_hidden = 32 * 1024 / 2;
+@@ -54,30 +45,385 @@ long int __x86_rep_movsb_threshold attribute_

[OE-core] [PATCH] oe/recipeutils: Fix copying patches when BBLAYERS entries are not normalised

[Andrei Gherzan]

From: Andrei Gherzan 

`devtool` uses `copy_recipe_files` for the upgrade operation when
creating the new, workspace recipe. Before handling the copy operations,
the function checks the entry in `SRC_URI` against `FILE` while in turn
uses absolute paths. When BBLAYERS contains entries that are not
normalised, this check will fail resulting in having the recipe in the
workspace without the initial patches.

Signef-off-by: Robert Drab 
Signed-off-by: Andrei Gherzan 
---
 meta/lib/oe/recipeutils.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/lib/oe/recipeutils.py b/meta/lib/oe/recipeutils.py
index ef69ef207f..407d168894 100644
--- a/meta/lib/oe/recipeutils.py
+++ b/meta/lib/oe/recipeutils.py
@@ -409,7 +409,7 @@ def copy_recipe_files(d, tgt_dir, whole_dir=False, 
download=True, all_variants=F
 fetch.download()
 for pth in fetch.localpaths():
 if pth not in localpaths:
-localpaths.append(pth)
+localpaths.append(os.path.abspath(pth))
 uri_values.append(srcuri)
 
 fetch_urls(d)
-- 
2.30.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#148331): 
https://lists.openembedded.org/g/openembedded-core/message/148331
Mute This Topic: https://lists.openembedded.org/mt/80741128/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH] wic/bootimg-efi: Respect fixed partition size

[Andrei Gherzan]

Hi,

On Mon, Mar 16, 2020 at 3:28 PM Andrei Gherzan  wrote:

> Signed-off-by: Andrei Gherzan 
> ---
>  scripts/lib/wic/plugins/source/bootimg-efi.py | 21 +++
>  1 file changed, 12 insertions(+), 9 deletions(-)
>
> diff --git a/scripts/lib/wic/plugins/source/bootimg-efi.py
> b/scripts/lib/wic/plugins/source/bootimg-efi.py
> index 2cfdc10ecd..6c3d7b8491 100644
> --- a/scripts/lib/wic/plugins/source/bootimg-efi.py
> +++ b/scripts/lib/wic/plugins/source/bootimg-efi.py
> @@ -263,19 +263,22 @@ class BootimgEFIPlugin(SourcePlugin):
>  cp_cmd = "cp %s %s/" % (startup, hdddir)
>  exec_cmd(cp_cmd, True)
>
> -du_cmd = "du -bks %s" % hdddir
> -out = exec_cmd(du_cmd)
> -blocks = int(out.split()[0])
> +if part.fixed-size:
> +blocks = part.fixed_size
> +else:
> +du_cmd = "du -bks %s" % hdddir
> +out = exec_cmd(du_cmd)
> +blocks = int(out.split()[0])
>
> -extra_blocks = part.get_extra_block_count(blocks)
> +extra_blocks = part.get_extra_block_count(blocks)
>
> -if extra_blocks < BOOTDD_EXTRA_SPACE:
> -extra_blocks = BOOTDD_EXTRA_SPACE
> +if extra_blocks < BOOTDD_EXTRA_SPACE:
> +extra_blocks = BOOTDD_EXTRA_SPACE
>
> -blocks += extra_blocks
> +blocks += extra_blocks
>
> -logger.debug("Added %d extra blocks to %s to get to %d total
> blocks",
> - extra_blocks, part.mountpoint, blocks)
> +logger.debug("Added %d extra blocks to %s to get to %d total
> blocks",
> + extra_blocks, part.mountpoint, blocks)
>
>  # dosfs image, created by mkdosfs
>  bootimg = "%s/boot.img" % cr_workdir
>
>
Small ping for this.

Thanks,
Andrei
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#141430): 
https://lists.openembedded.org/g/openembedded-core/message/141430
Mute This Topic: https://lists.openembedded.org/mt/72395923/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH 1/2] initscripts: Fix various shellcheck warnings in populate-volatile.sh

[Andrei Gherzan]

On Sat, Jul 25, 2020 at 6:14 AM Khem Raj  wrote:

> What all shells has it been tested for ?
>

I've used shellcheck for static analysis and tested at runtime with busybox
shell.

Andrei
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#140943): 
https://lists.openembedded.org/g/openembedded-core/message/140943
Mute This Topic: https://lists.openembedded.org/mt/75770568/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH 1/2] initscripts: Fix various shellcheck warnings in populate-volatile.sh

[Andrei Gherzan]

Signed-off-by: Andrei Gherzan 
---
 .../initscripts-1.0/populate-volatile.sh  | 58 +--
 1 file changed, 29 insertions(+), 29 deletions(-)

diff --git a/meta/recipes-core/initscripts/initscripts-1.0/populate-volatile.sh 
b/meta/recipes-core/initscripts/initscripts-1.0/populate-volatile.sh
index 1c525b71bd..3a265329f0 100755
--- a/meta/recipes-core/initscripts/initscripts-1.0/populate-volatile.sh
+++ b/meta/recipes-core/initscripts/initscripts-1.0/populate-volatile.sh
@@ -9,10 +9,10 @@
 ### END INIT INFO
 
 # Get ROOT_DIR
-DIRNAME=`dirname $0`
-ROOT_DIR=`echo $DIRNAME | sed -ne 's:/etc/.*::p'`
+DIRNAME="$(dirname "$0")"
+ROOT_DIR="$(echo "$DIRNAME" | sed -ne 's:/etc/.*::p')"
 
-[ -e ${ROOT_DIR}/etc/default/rcS ] && . ${ROOT_DIR}/etc/default/rcS
+[ -e "${ROOT_DIR}/etc/default/rcS" ] && . "${ROOT_DIR}/etc/default/rcS"
 # When running populate-volatile.sh at rootfs time, disable cache.
 [ -n "$ROOT_DIR" ] && VOLATILE_ENABLE_CACHE=no
 # If rootfs is read-only, disable cache.
@@ -46,13 +46,13 @@ create_file() {
[ "${VERBOSE}" != "no" ] && echo "Target already exists. 
Skipping."
} || {
if [ -z "$ROOT_DIR" ]; then
-   eval $EXEC
+   eval "$EXEC"
else
# Creating some files at rootfs time may fail and 
should fail,
# but these failures should not be logged to make sure 
the do_rootfs
# process doesn't fail. This does no harm, as this 
script will
# run on target to set up the correct files and 
directories.
-   eval $EXEC > /dev/null 2>&1
+   eval "$EXEC" > /dev/null 2>&1
fi
}
 }
@@ -68,11 +68,11 @@ mk_dir() {
[ "${VERBOSE}" != "no" ] && echo "Target already exists. 
Skipping."
} || {
if [ -z "$ROOT_DIR" ]; then
-   eval $EXEC
+   eval "$EXEC"
else
# For the same reason with create_file(), failures 
should
# not be logged.
-   eval $EXEC > /dev/null 2>&1
+   eval "$EXEC" > /dev/null 2>&1
fi
}
 }
@@ -96,11 +96,11 @@ link_file() {
test "$VOLATILE_ENABLE_CACHE" = yes && echo "   $EXEC" >> 
/etc/volatile.cache.build
 
if [ -z "$ROOT_DIR" ]; then
-   eval $EXEC
+   eval "$EXEC"
else
# For the same reason with create_file(), failures should
# not be logged.
-   eval $EXEC > /dev/null 2>&1
+   eval "$EXEC" > /dev/null 2>&1
fi
 }
 
@@ -117,11 +117,11 @@ check_requirements() {
TMP_DEFINED="${TMPROOT}/tmpdefined.$$"
TMP_COMBINED="${TMPROOT}/tmpcombined.$$"
 
-   sed 's@\(^:\)*:.*@\1@' ${ROOT_DIR}/etc/passwd | sort | uniq > 
"${TMP_DEFINED}"
-   cat ${CFGFILE} | grep -v "^#" | cut -s -d " " -f 2 > "${TMP_INTERMED}"
+   sed 's@\(^:\)*:.*@\1@' "${ROOT_DIR}/etc/passwd" | sort | uniq > 
"${TMP_DEFINED}"
+   grep -v "^#" "${CFGFILE}" | cut -s -d " " -f 2 > "${TMP_INTERMED}"
cat "${TMP_DEFINED}" "${TMP_INTERMED}" | sort | uniq > "${TMP_COMBINED}"
-   NR_DEFINED_USERS="`cat "${TMP_DEFINED}" | wc -l`"
-   NR_COMBINED_USERS="`cat "${TMP_COMBINED}" | wc -l`"
+   NR_DEFINED_USERS="$(wc -l < "${TMP_DEFINED}")"
+   NR_COMBINED_USERS="$(wc -l < "${TMP_COMBINED}")"
 
[ "${NR_DEFINED_USERS}" -ne "${NR_COMBINED_USERS}" ] && {
echo "Undefined users:"
@@ -131,12 +131,12 @@ check_requirements() {
}
 
 
-   sed 's@\(^:\)*:.*@\1@' ${ROOT_DIR}/etc/group | sort | uniq > 
"${TMP_DEFINED}"
-   cat ${CFGFILE} | grep -v "^#" | cut -s -d " " -f 3 > "${TMP_INTERMED}"
+   sed 's@\(^:\)*:.*@\1@' "${ROOT_DIR}/etc/group" | sort | uniq > 
"${TMP_DEFINED}"
+   grep -v "^#" "${CFGFILE}" | cut -s -d " " -f 3 > "${TMP_INTERMED}"
cat "${TMP_DEFINED}" "${TMP_INTERMED}" | sort | uniq > "${TMP_COMBINED}"
 
-   NR_DEFINED_GROUPS="`cat "${TMP_DEFINED}" | wc -l`"
-   NR_C

[OE-core] [PATCH 2/2] initscripts: Fix populate-volatile.sh bug when file/dir exists

[Andrei Gherzan]

The blocks which test for entry exitence (file or directory) use a
`A && B || C` syntax. This form is not behaving as a if-then-else block
even the code logic assumes that. C may run when A is true which breaks
the case where VERBOSE is 'no' but the file/directory exists.

Along with fixing these specific issues, this patch fixes the other
instances where blocks of form `A && B || C` are used as if-then-else.

Signed-off-by: Andrei Gherzan 
---
 .../initscripts-1.0/populate-volatile.sh  | 24 +--
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/meta/recipes-core/initscripts/initscripts-1.0/populate-volatile.sh 
b/meta/recipes-core/initscripts/initscripts-1.0/populate-volatile.sh
index 3a265329f0..f21f48dd30 100755
--- a/meta/recipes-core/initscripts/initscripts-1.0/populate-volatile.sh
+++ b/meta/recipes-core/initscripts/initscripts-1.0/populate-volatile.sh
@@ -26,15 +26,15 @@ COREDEF="00_core"
 
 create_file() {
EXEC=""
-   [ -z "$2" ] && {
+   if [ -z "$2" ]; then
EXEC="
touch \"$1\";
"
-   } || {
+   else
EXEC="
cp \"$2\" \"$1\";
"
-   }
+   fi
EXEC="
${EXEC}
chown ${TUSER}:${TGROUP} $1 || echo \"Failed to set owner -${TUSER}- 
for -$1-.\" >/dev/tty0 2>&1;
@@ -42,9 +42,9 @@ create_file() {
 
test "$VOLATILE_ENABLE_CACHE" = yes && echo "$EXEC" >> 
/etc/volatile.cache.build
 
-   [ -e "$1" ] && {
+   if [ -e "$1" ]; then
[ "${VERBOSE}" != "no" ] && echo "Target already exists. 
Skipping."
-   } || {
+   else
if [ -z "$ROOT_DIR" ]; then
eval "$EXEC"
else
@@ -54,7 +54,7 @@ create_file() {
# run on target to set up the correct files and 
directories.
eval "$EXEC" > /dev/null 2>&1
fi
-   }
+   fi
 }
 
 mk_dir() {
@@ -64,9 +64,9 @@ mk_dir() {
chmod ${TMODE} $1 || echo \"Failed to set mode -${TMODE}- for -$1-.\" 
>/dev/tty0 2>&1 "
 
test "$VOLATILE_ENABLE_CACHE" = yes && echo "$EXEC" >> 
/etc/volatile.cache.build
-   [ -e "$1" ] && {
+   if [ -e "$1" ]; then
[ "${VERBOSE}" != "no" ] && echo "Target already exists. 
Skipping."
-   } || {
+   else
if [ -z "$ROOT_DIR" ]; then
eval "$EXEC"
else
@@ -74,7 +74,7 @@ mk_dir() {
# not be logged.
eval "$EXEC" > /dev/null 2>&1
fi
-   }
+   fi
 }
 
 link_file() {
@@ -188,13 +188,13 @@ apply_cfgfile() {
[ -L "${TNAME}" ] && {
[ "${VERBOSE}" != "no" ] && echo "Found link."
NEWNAME=$(ls -l "${TNAME}" | sed -e 's/^.*-> 
\(.*\)$/\1/')
-   echo "${NEWNAME}" | grep -v "^/" >/dev/null && {
+   if echo "${NEWNAME}" | grep -v "^/" >/dev/null; then
TNAME="$(echo "${TNAME}" | sed -e 
's@\(.*\)/.*@\1@')/${NEWNAME}"
[ "${VERBOSE}" != "no" ] && echo "Converted 
relative linktarget to absolute path -${TNAME}-."
-   } || {
+   else
TNAME="${NEWNAME}"
[ "${VERBOSE}" != "no" ] && echo "Using 
absolute link target -${TNAME}-."
-   }
+   fi
}
 
case "${TTYPE}" in
-- 
2.17.1

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#140937): 
https://lists.openembedded.org/g/openembedded-core/message/140937
Mute This Topic: https://lists.openembedded.org/mt/75770574/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH] wic/bootimg-efi: Respect fixed partition size

[Andrei Gherzan]

Signed-off-by: Andrei Gherzan 
---
 scripts/lib/wic/plugins/source/bootimg-efi.py | 21 +++
 1 file changed, 12 insertions(+), 9 deletions(-)

diff --git a/scripts/lib/wic/plugins/source/bootimg-efi.py 
b/scripts/lib/wic/plugins/source/bootimg-efi.py
index 2cfdc10ecd..6c3d7b8491 100644
--- a/scripts/lib/wic/plugins/source/bootimg-efi.py
+++ b/scripts/lib/wic/plugins/source/bootimg-efi.py
@@ -263,19 +263,22 @@ class BootimgEFIPlugin(SourcePlugin):
 cp_cmd = "cp %s %s/" % (startup, hdddir)
 exec_cmd(cp_cmd, True)
 
-du_cmd = "du -bks %s" % hdddir
-out = exec_cmd(du_cmd)
-blocks = int(out.split()[0])
+if part.fixed-size:
+blocks = part.fixed_size
+else:
+du_cmd = "du -bks %s" % hdddir
+out = exec_cmd(du_cmd)
+blocks = int(out.split()[0])
 
-extra_blocks = part.get_extra_block_count(blocks)
+extra_blocks = part.get_extra_block_count(blocks)
 
-if extra_blocks < BOOTDD_EXTRA_SPACE:
-extra_blocks = BOOTDD_EXTRA_SPACE
+if extra_blocks < BOOTDD_EXTRA_SPACE:
+extra_blocks = BOOTDD_EXTRA_SPACE
 
-blocks += extra_blocks
+blocks += extra_blocks
 
-logger.debug("Added %d extra blocks to %s to get to %d total blocks",
- extra_blocks, part.mountpoint, blocks)
+logger.debug("Added %d extra blocks to %s to get to %d total 
blocks",
+ extra_blocks, part.mountpoint, blocks)
 
 # dosfs image, created by mkdosfs
 bootimg = "%s/boot.img" % cr_workdir
-- 
2.17.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] archiver: avoid empty incfile in ar_recipe

[Andrei Gherzan]

Hi,

On 11/11/2019 12:29, Grygorii Tertychnyi (gtertych) wrote:

Hi Andrei,

From: Andrei Gherzan 
Sent: Monday, November 11, 2019 13:18
Subject: Re: [OE-core] [PATCH] archiver: avoid empty incfile in ar_recipe


Not sure I understand. Archiver class does not interpret "include" directive.
It just parses text files. The regular expression looks correct:

These lines:

440 elif include_re.match(line):
441 incfile = include_re.match(line).group(1)

put "${...}" _string_ into "incfile" variable. So, "incfile" is not None at 
"this stage.



"${...}" it's already expanded to a white-space. So in that case it
matches "include  ".


No. "incfile" is not expanded here, it actually contains "${...}", e.g.
${@bb.utils.contains('PACKAGECONFIG', 'scripting', 'perf-perl.inc', '', d)}


Give me a simple way to reproduce this.

--
Andrei Gherzan
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] archiver: avoid empty incfile in ar_recipe

[Andrei Gherzan]

Hi Grygorii,

On 04/11/2019 15:09, Grygorii Tertychnyi (gtertych) wrote:

Andrei,

From: Andrei Gherzan 
Sent: Friday, November 1, 2019 13:28
To: Grygorii Tertychnyi (gtertych); openembedded-core@lists.openembedded.org
Cc: xe-linux-external(mailer list)
Subject: Re: [OE-core] [PATCH] archiver: avoid empty incfile in ar_recipe


do_ar_recipe fails on perf recipe on line:

include ${@bb.utils.contains('PACKAGECONFIG', 'scripting', 'perf-perl.inc', '', 
d)}

1. "${...}" part expands into empty string
2. bb.utils.which() takes empty string and returns first directory name from 
bbpath



This doesn't sound sane. If the include directive has no argument,
incfile should end up None. That's what the code "assumes" at this


I agree.


point. I would fix it either at the regex expression level or
stripping the matched string. I reckon the former makes more sense
(.*).


Not sure I understand. Archiver class does not interpret "include" directive.
It just parses text files. The regular expression looks correct:

These lines:

440 elif include_re.match(line):
441 incfile = include_re.match(line).group(1)

put "${...}" _string_ into "incfile" variable. So, "incfile" is not None at 
"this stage.


"${...}" it's already expanded to a white-space. So in that case it 
matches "include  ".



Then,

443 incfile = d.expand(incfile)

Now "incfile" is empty and nobody checks it.


incfile is not empty. It's actually a string containing one white-space.



444 incfile = bb.utils.which(bbpath, incfile)

Now "incfile" is set to first directory name in BBPATH (wrong behavour?)

445 if incfile:
446 shutil.copy(incfile, outdir)

Exception here: "incfile" is directory, not a file.



The include regex is the following:

include_re = re.compile( r"include\s+(.+)" )

The issue is that when this is matched on a string suffixed with only 
spaces, it will match the last space as group(1). This is because ".+" 
forces to match the last white-space. Changing that to ".*" will make 
the group(1) be an empty string and later the if will evaluate False.


--
Andrei Gherzan
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] archiver: avoid empty incfile in ar_recipe

[Andrei Gherzan]

Hi,

On 01/11/2019 07:10, grygorii tertychnyi via Openembedded-core wrote:
> do_ar_recipe fails on perf recipe on line:
>
> include ${@bb.utils.contains('PACKAGECONFIG', 'scripting', 'perf-perl.inc', 
> '', d)}
>
> 1. "${...}" part expands into empty string
> 2. bb.utils.which() takes empty string and returns first directory name from 
> bbpath

This doesn't sound sane. If the include directive has no argument,
incfile should end up None. That's what the code "assumes" at this
point. I would fix it either at the regex expression level or
stripping the matched string. I reckon the former makes more sense
(.*).

--
Andrei Gherzan
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] archiver: avoid empty incfile in ar_recipe

[Andrei Gherzan]

Hi,

On 01/11/2019 07:10, grygorii tertychnyi via Openembedded-core wrote:

do_ar_recipe fails on perf recipe on line:

include ${@bb.utils.contains('PACKAGECONFIG', 'scripting', 'perf-perl.inc', '', 
d)}

1. "${...}" part expands into empty string
2. bb.utils.which() takes empty string and returns first directory name from 
bbpath


This doesn't sound sane. If the include directive has no argument, 
incfile should end up None. That's what the code "assumes" at this 
point. I would fix it either at the regex expression level or strip the 
match. I reckon former would make more sense. It sounds like the match 
expression should use * (none or more).



3. shutil.copy() fails on copying directory:

Exception: IsADirectoryError: [Errno 21] Is a directory: ..

Hence, check "incfile" variable on each step.

Signed-off-by: grygorii tertychnyi 
---
  meta/classes/archiver.bbclass | 5 +++--
  1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/meta/classes/archiver.bbclass b/meta/classes/archiver.bbclass
index 093e2d95af..7c46cff91f 100644
--- a/meta/classes/archiver.bbclass
+++ b/meta/classes/archiver.bbclass
@@ -441,9 +441,10 @@ python do_ar_recipe () {
  incfile = include_re.match(line).group(1)
  if incfile:
  incfile = d.expand(incfile)
+if incfile:
  incfile = bb.utils.which(bbpath, incfile)
-if incfile:
-shutil.copy(incfile, outdir)
+if incfile:
+shutil.copy(incfile, outdir)
  
  create_tarball(d, outdir, 'recipe', d.getVar('ARCHIVER_OUTDIR'))

  bb.utils.remove(outdir, recurse=True)




--
Andrei Gherzan
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 2/2] image-buildinfo.bbclass: Introduce IMAGE_BUILDINFO_GITDESCRIBE

[Andrei Gherzan]

On 09/10/2019 18:58, Richard Purdie wrote:

On Wed, 2019-10-09 at 18:05 +0100, Andrei Gherzan wrote:

This knob can switch in between having full revisions and having git
describe references in the build info file. By default it is set to 0
to
maintain the old behaviour.

Signed-off-by: Andrei Gherzan 
---
  meta/classes/image-buildinfo.bbclass | 14 --
  1 file changed, 12 insertions(+), 2 deletions(-)


I'm not sure we want to even encourage this. We probably do want to
print/store the full hashes as output from this class as they may be
used by CI or in bug reports. The could be unique at the time of
printing but clash later. The output is also dependent on the fetched
tree.


Wait. There is indeed an issue: it should fallback to full hashes when 
human readable tags are not available. I'll address. When tags are 
available, the describe will give you the hask as well including a delta 
integer. Is that what you were concerned about?


--
Andrei Gherzan
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 2/2] image-buildinfo.bbclass: Introduce IMAGE_BUILDINFO_GITDESCRIBE

[Andrei Gherzan]

This knob can switch in between having full revisions and having git
describe references in the build info file. By default it is set to 0 to
maintain the old behaviour.

Signed-off-by: Andrei Gherzan 
---
 meta/classes/image-buildinfo.bbclass | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/meta/classes/image-buildinfo.bbclass 
b/meta/classes/image-buildinfo.bbclass
index 94c585d4cd..fb8677fe69 100644
--- a/meta/classes/image-buildinfo.bbclass
+++ b/meta/classes/image-buildinfo.bbclass
@@ -15,6 +15,9 @@ IMAGE_BUILDINFO_VARS ?= "DISTRO DISTRO_VERSION"
 # Desired location of the output file in the image.
 IMAGE_BUILDINFO_FILE ??= "${sysconfdir}/build"
 
+# By default use HEAD revision. Set this to 1 for git human readable revisions.
+IMAGE_BUILDINFO_GITDESCRIBE ?= "0"
+
 # From buildhistory.bbclass
 def image_buildinfo_outputvars(vars, d):
 vars = vars.split()
@@ -45,9 +48,16 @@ def get_layer_git_status(path):
 # Returns layer revisions along with their respective status
 def get_layer_revs(d):
 layers = (d.getVar("BBLAYERS") or "").split()
-medadata_revs = ["%-17s = %s:%s %s" % (os.path.basename(i), \
+gitdescribe = d.getVar("IMAGE_BUILDINFO_GITDESCRIBE") or "0"
+
+if gitdescribe == "1":
+revision_func = base_get_metadata_git_describe
+else:
+revision_func = base_get_metadata_git_revision
+
+medadata_revs = ["%-27s = %s:%s %s" % (os.path.basename(i), \
 base_get_metadata_git_branch(i, None).strip(), \
-base_get_metadata_git_revision(i, None), \
+revision_func(i, None), \
 get_layer_git_status(i)) \
 for i in layers]
 return '\n'.join(medadata_revs)
-- 
2.23.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 1/2] metadata_scm.bbclass: Add git human readable ref function

[Andrei Gherzan]

This function finds the most recent tag reachable from the current
commit and computes a nice reference. In order to avoid code
duplication, I generalized the branch and revision functions as well
(base_get_metadata_git_branch, base_get_metadata_git_revision).

Signed-off-by: Andrei Gherzan 
---
 meta/classes/metadata_scm.bbclass | 17 -
 1 file changed, 8 insertions(+), 9 deletions(-)

diff --git a/meta/classes/metadata_scm.bbclass 
b/meta/classes/metadata_scm.bbclass
index 58bb4c555a..1fe4b55dca 100644
--- a/meta/classes/metadata_scm.bbclass
+++ b/meta/classes/metadata_scm.bbclass
@@ -23,20 +23,19 @@ def base_get_metadata_svn_revision(path, d):
 pass
 return revision
 
-def base_get_metadata_git_branch(path, d):
+def base_get_metadata_git(path, cmd, d):
 import bb.process
-
 try:
-rev, _ = bb.process.run('git rev-parse --abbrev-ref HEAD', cwd=path)
+rev, _ = bb.process.run(cmd, cwd=path)
 except bb.process.ExecutionError:
 rev = ''
 return rev.strip()
 
+def base_get_metadata_git_branch(path, d):
+return base_get_metadata_git(path, 'git rev-parse --abbrev-ref HEAD', d)
+
 def base_get_metadata_git_revision(path, d):
-import bb.process
+return base_get_metadata_git(path, 'git rev-parse HEAD', d)
 
-try:
-rev, _ = bb.process.run('git rev-parse HEAD', cwd=path)
-except bb.process.ExecutionError:
-rev = ''
-return rev.strip()
+def base_get_metadata_git_describe(path, d):
+return base_get_metadata_git(path, 'git describe --tags', d)
-- 
2.23.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH V2] ca-certificates: Fix openssl runtime dependency

[Andrei Gherzan]

On 29/05/2019 19.45, Richard Purdie wrote:
> On Wed, 2019-05-29 at 15:41 +0100, Andrei Gherzan wrote:
>> Signed-off-by: Andrei Gherzan 
>> ---
>>  .../ca-certificates/ca-certificates_20190110.bb   | 4
>> +++-
>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/meta/recipes-support/ca-certificates/ca-
>> certificates_20190110.bb b/meta/recipes-support/ca-certificates/ca-
>> certificates_20190110.bb
>> index 4c0425302f..7c06573db2 100644
>> --- a/meta/recipes-support/ca-certificates/ca-
>> certificates_20190110.bb
>> +++ b/meta/recipes-support/ca-certificates/ca-
>> certificates_20190110.bb
>> @@ -82,6 +82,8 @@ do_install_append_class-native () {
>>  SYSROOT="${D}${base_prefix}" ${D}${sbindir}/update-ca-
>> certificates
>>  }
>>  
>> -RDEPENDS_${PN} += "openssl"
>> +RDEPENDS_${PN}_class-target = "openssl-bin"
>> +RDEPENDS_${PN}_class-native = "openssl"
>> +RDEPENDS_${PN}_class-nativesdk = "openssl"
> Wouldn't the nativesdk version be openssl-bin too?
>
> or really these would end up being openssl-native and 
> nativesdk-openssl-bin?
I completely abominated this one. Pushed v3.

-- 
Andrei Gherzan
gpg: rsa4096/D4D94F67AD0E9640 | t: @agherzan

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH V3] ca-certificates: Fix openssl runtime dependencies

[Andrei Gherzan]

Since yocto thud, and more specifically since poky switched to
openssl 1.1 line, the openssl binary is provided by 'openssl-bin'. This
impacts the native and nativesdk recipe variants as well.

Signed-off-by: Andrei Gherzan 
---
 .../ca-certificates/ca-certificates_20190110.bb   | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-support/ca-certificates/ca-certificates_20190110.bb 
b/meta/recipes-support/ca-certificates/ca-certificates_20190110.bb
index 4c0425302f..efd9eaa71e 100644
--- a/meta/recipes-support/ca-certificates/ca-certificates_20190110.bb
+++ b/meta/recipes-support/ca-certificates/ca-certificates_20190110.bb
@@ -82,6 +82,8 @@ do_install_append_class-native () {
 SYSROOT="${D}${base_prefix}" ${D}${sbindir}/update-ca-certificates
 }
 
-RDEPENDS_${PN} += "openssl"
+RDEPENDS_${PN}_class-target = "openssl-bin"
+RDEPENDS_${PN}_class-native = "openssl-native"
+RDEPENDS_${PN}_class-nativesdk = "nativesdk-openssl-bin"
 
 BBCLASSEXTEND = "native nativesdk"
-- 
2.17.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] ca-certificates: Fix openssl runtime dependency

[Andrei Gherzan]

On 29/05/2019 15.29, Peter Kjellerstedt wrote:
>> -Original Message-
>> From: openembedded-core-boun...@lists.openembedded.org 
>>  On Behalf Of Richard 
>> Purdie
>> Sent: den 29 maj 2019 01:24
>> To: Andrei Gherzan ; 
>> openembedded-core@lists.openembedded.org
>> Subject: Re: [OE-core] [PATCH] ca-certificates: Fix openssl runtime 
>> dependency
>>
>> On Tue, 2019-05-28 at 15:30 +0100, Andrei Gherzan wrote:
>>> Since yocto thud, and more specifically since poky switched to
>>> openssl 1.1 line, the openssl binary is provided by 'openssl-bin'.
>>>
>>> Signed-off-by: Andrei Gherzan 
>>> ---
>>>  .../recipes-support/ca-certificates/ca-certificates_20190110.bb | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git 
>>> a/meta/recipes-support/ca-certificates/ca-certificates_20190110.bb 
>>> b/meta/recipes-support/ca-certificates/ca-certificates_20190110.bb
>>> index 4c0425302f..bc69c55daa 100644
>>> --- a/meta/recipes-support/ca-certificates/ca-certificates_20190110.bb
>>> +++ b/meta/recipes-support/ca-certificates/ca-certificates_20190110.bb
>>> @@ -82,6 +82,6 @@ do_install_append_class-native () {
>>>  SYSROOT="${D}${base_prefix}" ${D}${sbindir}/update-ca-certificates
>>>  }
>>>
>>> -RDEPENDS_${PN} += "openssl"
>>> +RDEPENDS_${PN} += "openssl-bin"
>> Doesn't work for ca-certificates-native:
>>
>> https://autobuilder.yoctoproject.org/typhoon/#/builders/39/builds/638
>> [amongst many other failures]
Fixed native and nativesdk in a V2 that I just pushed. Made them
explicit RDEPENDS .
> I assume the above can be fixed by instead using:
>
> RDEPENDS_${PN}_append_class-target = " openssl-bin"
>
> However, has there been any attempts at rectifying the situation where 
> runtime dependencies on packages are turned into recipe dependencies 
> for the native version of a recipe, which obviously does not work when 
> the package name does not match a recipe name?
-- 

Andrei Gherzan
gpg: rsa4096/D4D94F67AD0E9640 | t: @agherzan

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH V2] ca-certificates: Fix openssl runtime dependency

[Andrei Gherzan]

Signed-off-by: Andrei Gherzan 
---
 .../ca-certificates/ca-certificates_20190110.bb   | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-support/ca-certificates/ca-certificates_20190110.bb 
b/meta/recipes-support/ca-certificates/ca-certificates_20190110.bb
index 4c0425302f..7c06573db2 100644
--- a/meta/recipes-support/ca-certificates/ca-certificates_20190110.bb
+++ b/meta/recipes-support/ca-certificates/ca-certificates_20190110.bb
@@ -82,6 +82,8 @@ do_install_append_class-native () {
 SYSROOT="${D}${base_prefix}" ${D}${sbindir}/update-ca-certificates
 }
 
-RDEPENDS_${PN} += "openssl"
+RDEPENDS_${PN}_class-target = "openssl-bin"
+RDEPENDS_${PN}_class-native = "openssl"
+RDEPENDS_${PN}_class-nativesdk = "openssl"
 
 BBCLASSEXTEND = "native nativesdk"
-- 
2.17.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] ca-certificates: Fix openssl runtime dependency

[Andrei Gherzan]

Since yocto thud, and more specifically since poky switched to
openssl 1.1 line, the openssl binary is provided by 'openssl-bin'.

Signed-off-by: Andrei Gherzan 
---
 .../recipes-support/ca-certificates/ca-certificates_20190110.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-support/ca-certificates/ca-certificates_20190110.bb 
b/meta/recipes-support/ca-certificates/ca-certificates_20190110.bb
index 4c0425302f..bc69c55daa 100644
--- a/meta/recipes-support/ca-certificates/ca-certificates_20190110.bb
+++ b/meta/recipes-support/ca-certificates/ca-certificates_20190110.bb
@@ -82,6 +82,6 @@ do_install_append_class-native () {
 SYSROOT="${D}${base_prefix}" ${D}${sbindir}/update-ca-certificates
 }
 
-RDEPENDS_${PN} += "openssl"
+RDEPENDS_${PN} += "openssl-bin"
 
 BBCLASSEXTEND = "native nativesdk"
-- 
2.17.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Linux firmware for iwlwifi 8000c disappeared in pyro

[Andrei Gherzan]

On Fri, Feb 16, 2018 at 2:08 PM, Andrei Gherzan <and...@gherzan.ro> wrote:

> On Fri, Feb 16, 2018 at 1:48 PM, Palleti, Avinash Reddy <
> avinash.reddy.pall...@intel.com> wrote:
>
>>  I submitted a fix sometime back,
>> http://lists.openembedded.org/pipermail/openembedded-core/20
>> 18-February/147291.html
>>
>>
> Great. We have the fix available and approved by Saul. Shall we merge?
>

Adding the pyro maintainer to this thread.

--
Andrei Gherzan
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Linux firmware for iwlwifi 8000c disappeared in pyro

[Andrei Gherzan]

On Fri, Feb 16, 2018 at 1:48 PM, Palleti, Avinash Reddy <
avinash.reddy.pall...@intel.com> wrote:

>  I submitted a fix sometime back,
> http://lists.openembedded.org/pipermail/openembedded-core/
> 2018-February/147291.html
>
>
Great. We have the fix available and approved by Saul. Shall we merge?


>
> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org [mailto:
> openembedded-core-boun...@lists.openembedded.org] On Behalf Of Alexander
> Kanavin
> Sent: Friday, February 16, 2018 6:54 PM
> To: Andrei Gherzan <and...@gherzan.ro>; openembedded <
> openembedded-core@lists.openembedded.org>
> Subject: Re: [OE-core] Linux firmware for iwlwifi 8000c disappeared in pyro
>
> On 02/16/2018 01:42 PM, Andrei Gherzan wrote:
> > This happened because the removal of the 8000c-19 firmware patch in
> > pyro removes the package completely as well
> > (http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/
> meta/recipes-kernel/linux-firmware/linux-firmware_git.bb?h=pyro=
> 3e4b382c0c687a76f824cd84b478c4f778e15e3e).
> > While the patch that ended up in master only removed that specific
> > firmware
> > (http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/
> meta/recipes-kernel/linux-firmware/linux-firmware_git.bb?id=
> 8d2e66817a6e5cea5a0146f2804e703402de44dc).
> >
> > Any idea why this happened? Can we bring back the package in pyro as
> well?
>
> This looks like a simple mistake. Prepare (and test :) a patch to correct
> it, and send it here with [pyro] prefix.
>

That's what I suspected too. But wasn't sure as it could have been that we
intentionally moved it to misc package. Anyway looks simple and fixed
already.

--
Andrei Gherzan
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] Linux firmware for iwlwifi 8000c disappeared in pyro

[Andrei Gherzan]

Hi guys,

I'm using pyro for a set of boards including the Intel NUC one. This has an
integrated WiFi chip which works with iwlwifi 8000c firmware. While
updating the pyro branch of poky lately I saw that the package where this
firmware is available now is changed which is not the case in rocko and
master.

In pyro (
http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb?h=pyro)
the 8000c package was completely removed and the firmwares now fall back to
be included in iwlwifi-misc.

In master (
http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb?h=master)
that package still exists and everything is fine.

This happened because the removal of the 8000c-19 firmware patch in pyro
removes the package completely as well (
http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb?h=pyro=3e4b382c0c687a76f824cd84b478c4f778e15e3e).
While the patch that ended up in master only removed that specific firmware
(
http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb?id=8d2e66817a6e5cea5a0146f2804e703402de44dc
).

Any idea why this happened? Can we bring back the package in pyro as well?

--
Andrei Gherzan
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v2] kernel-yocto: relax BSP definition test

[Andrei Gherzan]

On Wed, Aug 23, 2017 at 8:20 PM, Bruce Ashfield <
bruce.ashfi...@windriver.com> wrote:

> commit 44aea7b873 [kernel-yocto: ensure that only valid BSPs are built]
> introduced a new check to ensure that a valid BSP definition was found,
> rather than building something that 'closely' matched the current
> MACHINE.
>
> This check breaks valid configurations which do not have a bsp
> definition but are otherwise completely configured machines.
>
> To allow both elements to co-exist (and not add warnings or errors
> to otherwise valid builds), we first check to see if an empty bsp
> definition was found, but then check to see if a defconfig was
> provided.
>
> If a defconfig has been provided, that is a sign that the board
> configuration is complete and we should continue the build without
> otherwise bothering the user.
>
> Tested on meta-raspberrypi and linux-yocto*
>
> Signed-off-by: Bruce Ashfield 
> ---
>
> v2: fixed the badly placed -q
>
>  meta/classes/kernel-yocto.bbclass | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/meta/classes/kernel-yocto.bbclass
> b/meta/classes/kernel-yocto.bbclass
> index 3c6df92131bc..20b4942320d6 100644
> --- a/meta/classes/kernel-yocto.bbclass
> +++ b/meta/classes/kernel-yocto.bbclass
> @@ -143,8 +143,11 @@ do_kernel_metadata() {
>
> # expand kernel features into their full path equivalents
> bsp_definition=$(spp ${includes} --find -DKMACHINE=${KMACHINE}
> -DKTYPE=${LINUX_KERNEL_TYPE})
> -   if [ $? -ne 0 ] || [ -z "${bsp_definition}" ]; then
> -   bbfatal_log "Could not locate BSP definiton for
> ${KMACHINE}/${LINUX_KERNEL_TYPE}."
> +   if [ -z "$bsp_definition" ]; then
> +   echo "$sccs" | grep -q defconfig
> +   if [ $? -ne 0 ]; then
> +   bberror "Could not locate BSP definition for
> ${KMACHINE}/${LINUX_KERNEL_TYPE} and no defconfig was provided"
> +   fi
> fi
> meta_dir=$(kgit --meta)
>
>
Looks good.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Fwd: kernel-yocto class requires BSP definition now

[Andrei Gherzan]

On Wed, Aug 23, 2017 at 6:08 PM, Bruce Ashfield <bruce.ashfi...@gmail.com>
wrote:

>
>
> On Wed, Aug 23, 2017 at 1:01 PM, Andrei Gherzan <and...@gherzan.ro> wrote:
>
>> On Wed, Aug 23, 2017 at 5:54 PM, Bruce Ashfield <
>> bruce.ashfi...@windriver.com> wrote:
>>
>>> Already discussed with Khem and Richard in the original
>>> thread.
>>>
>>> I'm sending another patch shortly to back this off to a note/warning.
>>>
>>>
>> That is nice but wouldn't that clutter the build logs for no reason? For
>> people who don't take advantage of scc definitions that is. Could you point
>> me to the initial discussion? Just want to understand and maybe vote to
>> remove it altogether.
>>
>
> It's a yocto bug. We need to flag BSP definitions that aren't valid,
> otherwise the tools
> will end up building things like qemuarm for someone that has a
> misconfigured BSP.
>
> If you don't have a defconfig (as someone won't have if they are using a
> fully defined
> BSP, but with the wrong name) and the wrong entry point, or no entry
> point, is returned
> we have to flag it.
>
> The actual bug is: 11878, and there's a related fallout of that bad
> definition.
>
> So no, it won't be deleted, but I will make it check for a few more
> parameters before
> erroring or logging.
>

That makes sense. Thanks for clarifying. I'll keep an eye on the ml for the
fix.

--
Andrei Gherzan
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Fwd: kernel-yocto class requires BSP definition now

[Andrei Gherzan]

On Wed, Aug 23, 2017 at 5:54 PM, Bruce Ashfield <
bruce.ashfi...@windriver.com> wrote:

> Already discussed with Khem and Richard in the original
> thread.
>
> I'm sending another patch shortly to back this off to a note/warning.
>
>
That is nice but wouldn't that clutter the build logs for no reason? For
people who don't take advantage of scc definitions that is. Could you point
me to the initial discussion? Just want to understand and maybe vote to
remove it altogether.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] Fwd: kernel-yocto class requires BSP definition now

[Andrei Gherzan]

(Resending this from the yocto mailing list)

Hello all,

Since...

commit b6f78c7a27d6d3acae63cf1fdb7b56c11c919830
Author: Bruce Ashfield <bruce.ashfi...@windriver.com>
Date:   Sun Aug 20 22:58:21 2017 -0400

kernel-yocto: ensure that only valid BSPs are built

There was a bug in the search routines responsible for locating
BSP definitions which returned a valid match if only the ktype
matched.

This meant that someone looking for "qemux86foo" (which is an
invalid definition) would potentially end up building "qemuarm"
and be none the wiser (until it didn't boot).

With this fix to the tools search routine, and improved return
code testing, we will now stop the build and report and error to
the user.

[YOCTO: #11878]

(From OE-Core rev: 44aea7b87307795fe4e089c51d45afccaa2f6525)

Signed-off-by: Bruce Ashfield <bruce.ashfi...@windriver.com>
Signed-off-by: Richard Purdie <richard.pur...@linuxfoundation.org>


... the build fails for cases where there is no scc definition used.
meta-raspberrypi was using this for configuration fragments feature but
without defining any scc or using any feature branches etc. This got broken
now since finding BSP definition files is a requirement in the class.

--
Andrei Gherzan
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [Openembedded-architecture] [oe] OpenEmbedded 2017 General Meeting

[Andrei Gherzan]

On Mon, May 1, 2017 at 12:59 PM, Martin Jansa <martin.ja...@gmail.com> wrote:
> I had to change the password on the login, but then it worked for me.
>
> I've added Andrea and Andrei to the list.

Thanks Martin.

--
Andrei Gherzan
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core