[OE-core] [PATCH] kernel: provide module.lds for out of tree builds in v5.10+

[Bruce Ashfield]

From: Bruce Ashfield 

The upstream commit 596b0474d3d [kbuild: preprocess module linker
script], adds a dependency on module.lds for external module
building.

Since module.lds is generated as part of 'modules_prepare', we
must make it available with the other kernel artifacts in the
kernel shared workdir, otherwise out of tree builds fail.

This fixes errors like:

| make[4]: *** No rule to make target 'scripts/module.lds', needed by

'build/tmp/work/qemuarm64-poky-linux/cryptodev-module/1.11-r0/git/cryptodev.ko'.
Stop.
| make[4]: *** Waiting for unfinished jobs

We also ensure that kernel-devsrc has a copy to support on
target module builds that are often prepared with 'make scripts
prepare'. Those targets won't regenerate it, so the build fails.
If 'make modules_prepare' is used, the file will be regenerated
and overwrite our copy (as expected).

Signed-off-by: Pan, Kris 
Signed-off-by: Lili Li 
Signed-off-by: Bruce Ashfield 
---
 meta/classes/kernel.bbclass| 1 +
 meta/recipes-kernel/linux/kernel-devsrc.bb | 6 ++
 2 files changed, 7 insertions(+)

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index be93a258f6..ccd74e61e8 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -494,6 +494,7 @@ do_shared_workdir () {
# Copy files required for module builds
cp System.map $kerneldir/System.map-${KERNEL_VERSION}
[ -e Module.symvers ] && cp Module.symvers $kerneldir/
+   [ -e scripts/module.lds ] && install -Dm 0644 scripts/module.lds 
$kerneldir/scripts/module.lds
cp .config $kerneldir/
mkdir -p $kerneldir/include/config
cp include/config/kernel.release 
$kerneldir/include/config/kernel.release
diff --git a/meta/recipes-kernel/linux/kernel-devsrc.bb 
b/meta/recipes-kernel/linux/kernel-devsrc.bb
index 81b1e36041..5f0dedbdf7 100644
--- a/meta/recipes-kernel/linux/kernel-devsrc.bb
+++ b/meta/recipes-kernel/linux/kernel-devsrc.bb
@@ -100,6 +100,12 @@ do_install() {
# be dealt with.
# cp -a scripts $kerneldir/build
 
+   # although module.lds can be regenerated on target via 'make 
modules_prepare'
+   # there are several places where 'makes scripts prepare' is done, and 
that won't
+   # regenerate the file. So we copy it onto the target as a migration to 
using
+   # modules_prepare
+   cp -a --parents scripts/module.lds $kerneldir/build/ 2>/dev/null || :
+
 if [ -d arch/${ARCH}/scripts ]; then
cp -a arch/${ARCH}/scripts $kerneldir/build/arch/${ARCH}
fi
-- 
2.19.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#144544): 
https://lists.openembedded.org/g/openembedded-core/message/144544
Mute This Topic: https://lists.openembedded.org/mt/78224757/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][gatesgarth][dunfell][master][PATCH] kernel.bbclass: fix module.lds missing issue since kernel v5.10

[Lili Li]

> -Original Message-
> From: openembedded-core@lists.openembedded.org  c...@lists.openembedded.org> On Behalf Of Bruce Ashfield
> Sent: Friday, November 13, 2020 11:50 AM
> To: Li, Lili 
> Cc: Patches and discussions about the oe-core layer  c...@lists.openembedded.org>; Mittal, Anuj ; Pan,
> Kris 
> Subject: Re: [OE-core][gatesgarth][dunfell][master][PATCH] kernel.bbclass: fix
> module.lds missing issue since kernel v5.10
> 
> On Thu, Nov 12, 2020 at 10:22 PM Li, Lili  wrote:
> >
> >
> >
> > > -Original Message-
> > > From: openembedded-core@lists.openembedded.org  > > c...@lists.openembedded.org> On Behalf Of Bruce Ashfield
> > > Sent: Friday, November 13, 2020 10:42 AM
> > > To: Li, Lili 
> > > Cc: Patches and discussions about the oe-core layer  > > c...@lists.openembedded.org>; Mittal, Anuj ;
> > > Pan, Kris 
> > > Subject: Re: [OE-core][gatesgarth][dunfell][master][PATCH]
> > > kernel.bbclass: fix module.lds missing issue since kernel v5.10
> > >
> > > On Thu, Nov 12, 2020 at 9:11 PM Lili Li  wrote:
> > > >
> > > > With v5.10-rc1 kernel commit 596b0474d3d9 (kbuild: preprocess
> > > > module linker script), external kernel module need
> > > > scripts/module.lds for compiling.
> > > >
> > > > Error Log:
> > > > *** No rule to make target 'scripts/module.lds', needed by 
> > >
> > > I have a similar change locally, but I do have a question.
> > >
> > > >
> > > > Signed-off-by: Pan, Kris 
> > > > Signed-off-by: Lili Li 
> > > > ---
> > > >  meta/classes/kernel.bbclass | 9 +
> > > >  1 file changed, 9 insertions(+)
> > > >
> > > > diff --git a/meta/classes/kernel.bbclass
> > > > b/meta/classes/kernel.bbclass index 9e3c34ad48..5c262f340e 100644
> > > > --- a/meta/classes/kernel.bbclass
> > > > +++ b/meta/classes/kernel.bbclass
> > > > @@ -358,6 +358,10 @@ do_compile_kernelmodules() {
> > > > # other kernel modules and will look at this
> > > > # file to do symbol lookups
> > > > cp ${B}/Module.symvers ${STAGING_KERNEL_BUILDDIR}/
> > > > +   if [ -e ${B}/scripts/module.lds ]; then
> > > > +   mkdir -p ${STAGING_KERNEL_BUILDDIR}/scripts
> > > > +   cp ${B}/scripts/module.lds
> > > ${STAGING_KERNEL_BUILDDIR}/scripts/
> > > > +   fi
> > >
> > > You really shouldn't need this here.
> > >
> > > The only reason we copy Module.symvers is that the kernel module
> > > build updates it.
> > >
> > > I only have the single copy in my local change (since it is created
> > > by modules_prepare), and I'm not seeing any breakage.
> > >
> > > Were you seeing somewhere that it was updated, or something that was
> > > breaking ?
> > >
> > > Bruce
> >
> > Thanks Bruce for catching this! I add this here just in case any further 
> > changes,
> we can remove it as of current process.
> > Will you post your local patch or do you want me to submit v2 version?
> 
> I have a commit with a few extra details in it here, I can send it on
> (my) Friday, and add your Signed-off-by on it as well.
> 
> If that's ok with you ?
Sure, that's great! Thanks!

Lili

>  just wanted to run one more round of testing with my queued changes, and will
> send them all together.
> 
> Bruce
> 
> >
> > Thanks
> > >
> > > > else
> > > > bbnote "no modules to compile"
> > > > fi
> > > > @@ -465,6 +469,11 @@ do_shared_workdir () {
> > > > # Copy files required for module builds
> > > > cp System.map $kerneldir/System.map-${KERNEL_VERSION}
> > > > [ -e Module.symvers ] && cp Module.symvers $kerneldir/
> > > > +   if [ -e ./scripts/module.lds ]; then
> > > > +   mkdir -p $kerneldir/scripts
> > > > +   cp ./scripts/module.lds $kerneldir/scripts/
> > > > +   fi
> > > > +
> > > > cp .config $kerneldir/
> > > > mkdir -p $kerneldir/include/config
> > > > cp include/config/kernel.release
> > > > $kerneldir/include/config/kernel.release
> > > > --
> > > > 2.17.1
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > > --
> > > - Thou shalt not follow the NULL pointer, for chaos and madness
> > > await thee at its end
> > > - "Use the force Harry" - Gandalf, Star Trek II
> 
> 
> 
> --
> - Thou shalt not follow the NULL pointer, for chaos and madness await thee at 
> its
> end
> - "Use the force Harry" - Gandalf, Star Trek II

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#144543): 
https://lists.openembedded.org/g/openembedded-core/message/144543
Mute This Topic: https://lists.openembedded.org/mt/78221736/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][gatesgarth][dunfell][master][PATCH] kernel.bbclass: fix module.lds missing issue since kernel v5.10

[Bruce Ashfield]

On Thu, Nov 12, 2020 at 10:22 PM Li, Lili  wrote:
>
>
>
> > -Original Message-
> > From: openembedded-core@lists.openembedded.org  > c...@lists.openembedded.org> On Behalf Of Bruce Ashfield
> > Sent: Friday, November 13, 2020 10:42 AM
> > To: Li, Lili 
> > Cc: Patches and discussions about the oe-core layer  > c...@lists.openembedded.org>; Mittal, Anuj ; Pan,
> > Kris 
> > Subject: Re: [OE-core][gatesgarth][dunfell][master][PATCH] kernel.bbclass: 
> > fix
> > module.lds missing issue since kernel v5.10
> >
> > On Thu, Nov 12, 2020 at 9:11 PM Lili Li  wrote:
> > >
> > > With v5.10-rc1 kernel commit 596b0474d3d9 (kbuild: preprocess module
> > > linker script), external kernel module need scripts/module.lds for
> > > compiling.
> > >
> > > Error Log:
> > > *** No rule to make target 'scripts/module.lds', needed by 
> >
> > I have a similar change locally, but I do have a question.
> >
> > >
> > > Signed-off-by: Pan, Kris 
> > > Signed-off-by: Lili Li 
> > > ---
> > >  meta/classes/kernel.bbclass | 9 +
> > >  1 file changed, 9 insertions(+)
> > >
> > > diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
> > > index 9e3c34ad48..5c262f340e 100644
> > > --- a/meta/classes/kernel.bbclass
> > > +++ b/meta/classes/kernel.bbclass
> > > @@ -358,6 +358,10 @@ do_compile_kernelmodules() {
> > > # other kernel modules and will look at this
> > > # file to do symbol lookups
> > > cp ${B}/Module.symvers ${STAGING_KERNEL_BUILDDIR}/
> > > +   if [ -e ${B}/scripts/module.lds ]; then
> > > +   mkdir -p ${STAGING_KERNEL_BUILDDIR}/scripts
> > > +   cp ${B}/scripts/module.lds
> > ${STAGING_KERNEL_BUILDDIR}/scripts/
> > > +   fi
> >
> > You really shouldn't need this here.
> >
> > The only reason we copy Module.symvers is that the kernel module build
> > updates it.
> >
> > I only have the single copy in my local change (since it is created by
> > modules_prepare), and I'm not seeing any breakage.
> >
> > Were you seeing somewhere that it was updated, or something that was
> > breaking ?
> >
> > Bruce
>
> Thanks Bruce for catching this! I add this here just in case any further 
> changes, we can remove it as of current process.
> Will you post your local patch or do you want me to submit v2 version?

I have a commit with a few extra details in it here, I can send it on
(my) Friday, and add your Signed-off-by on it as well.

If that's ok with you ?

 just wanted to run one more round of testing with my queued changes,
and will send them all together.

Bruce

>
> Thanks
> >
> > > else
> > > bbnote "no modules to compile"
> > > fi
> > > @@ -465,6 +469,11 @@ do_shared_workdir () {
> > > # Copy files required for module builds
> > > cp System.map $kerneldir/System.map-${KERNEL_VERSION}
> > > [ -e Module.symvers ] && cp Module.symvers $kerneldir/
> > > +   if [ -e ./scripts/module.lds ]; then
> > > +   mkdir -p $kerneldir/scripts
> > > +   cp ./scripts/module.lds $kerneldir/scripts/
> > > +   fi
> > > +
> > > cp .config $kerneldir/
> > > mkdir -p $kerneldir/include/config
> > > cp include/config/kernel.release
> > > $kerneldir/include/config/kernel.release
> > > --
> > > 2.17.1
> > >
> > >
> > >
> > >
> >
> >
> > --
> > - Thou shalt not follow the NULL pointer, for chaos and madness await thee 
> > at its
> > end
> > - "Use the force Harry" - Gandalf, Star Trek II



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

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#144542): 
https://lists.openembedded.org/g/openembedded-core/message/144542
Mute This Topic: https://lists.openembedded.org/mt/78221736/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][gatesgarth][dunfell][master][PATCH] kernel.bbclass: fix module.lds missing issue since kernel v5.10

[Lili Li]

> -Original Message-
> From: openembedded-core@lists.openembedded.org  c...@lists.openembedded.org> On Behalf Of Bruce Ashfield
> Sent: Friday, November 13, 2020 10:42 AM
> To: Li, Lili 
> Cc: Patches and discussions about the oe-core layer  c...@lists.openembedded.org>; Mittal, Anuj ; Pan,
> Kris 
> Subject: Re: [OE-core][gatesgarth][dunfell][master][PATCH] kernel.bbclass: fix
> module.lds missing issue since kernel v5.10
> 
> On Thu, Nov 12, 2020 at 9:11 PM Lili Li  wrote:
> >
> > With v5.10-rc1 kernel commit 596b0474d3d9 (kbuild: preprocess module
> > linker script), external kernel module need scripts/module.lds for
> > compiling.
> >
> > Error Log:
> > *** No rule to make target 'scripts/module.lds', needed by 
> 
> I have a similar change locally, but I do have a question.
> 
> >
> > Signed-off-by: Pan, Kris 
> > Signed-off-by: Lili Li 
> > ---
> >  meta/classes/kernel.bbclass | 9 +
> >  1 file changed, 9 insertions(+)
> >
> > diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
> > index 9e3c34ad48..5c262f340e 100644
> > --- a/meta/classes/kernel.bbclass
> > +++ b/meta/classes/kernel.bbclass
> > @@ -358,6 +358,10 @@ do_compile_kernelmodules() {
> > # other kernel modules and will look at this
> > # file to do symbol lookups
> > cp ${B}/Module.symvers ${STAGING_KERNEL_BUILDDIR}/
> > +   if [ -e ${B}/scripts/module.lds ]; then
> > +   mkdir -p ${STAGING_KERNEL_BUILDDIR}/scripts
> > +   cp ${B}/scripts/module.lds
> ${STAGING_KERNEL_BUILDDIR}/scripts/
> > +   fi
> 
> You really shouldn't need this here.
> 
> The only reason we copy Module.symvers is that the kernel module build
> updates it.
> 
> I only have the single copy in my local change (since it is created by
> modules_prepare), and I'm not seeing any breakage.
> 
> Were you seeing somewhere that it was updated, or something that was
> breaking ?
> 
> Bruce

Thanks Bruce for catching this! I add this here just in case any further 
changes, we can remove it as of current process.
Will you post your local patch or do you want me to submit v2 version?

Thanks
> 
> > else
> > bbnote "no modules to compile"
> > fi
> > @@ -465,6 +469,11 @@ do_shared_workdir () {
> > # Copy files required for module builds
> > cp System.map $kerneldir/System.map-${KERNEL_VERSION}
> > [ -e Module.symvers ] && cp Module.symvers $kerneldir/
> > +   if [ -e ./scripts/module.lds ]; then
> > +   mkdir -p $kerneldir/scripts
> > +   cp ./scripts/module.lds $kerneldir/scripts/
> > +   fi
> > +
> > cp .config $kerneldir/
> > mkdir -p $kerneldir/include/config
> > cp include/config/kernel.release
> > $kerneldir/include/config/kernel.release
> > --
> > 2.17.1
> >
> >
> >
> >
> 
> 
> --
> - Thou shalt not follow the NULL pointer, for chaos and madness await thee at 
> its
> end
> - "Use the force Harry" - Gandalf, Star Trek II

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#144541): 
https://lists.openembedded.org/g/openembedded-core/message/144541
Mute This Topic: https://lists.openembedded.org/mt/78221736/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][gatesgarth][dunfell][master][PATCH] kernel.bbclass: fix module.lds missing issue since kernel v5.10

[Bruce Ashfield]

On Thu, Nov 12, 2020 at 9:11 PM Lili Li  wrote:
>
> With v5.10-rc1 kernel commit 596b0474d3d9 (kbuild: preprocess module
>  linker script), external kernel module need scripts/module.lds
> for compiling.
>
> Error Log:
> *** No rule to make target 'scripts/module.lds', needed by 

I have a similar change locally, but I do have a question.

>
> Signed-off-by: Pan, Kris 
> Signed-off-by: Lili Li 
> ---
>  meta/classes/kernel.bbclass | 9 +
>  1 file changed, 9 insertions(+)
>
> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
> index 9e3c34ad48..5c262f340e 100644
> --- a/meta/classes/kernel.bbclass
> +++ b/meta/classes/kernel.bbclass
> @@ -358,6 +358,10 @@ do_compile_kernelmodules() {
> # other kernel modules and will look at this
> # file to do symbol lookups
> cp ${B}/Module.symvers ${STAGING_KERNEL_BUILDDIR}/
> +   if [ -e ${B}/scripts/module.lds ]; then
> +   mkdir -p ${STAGING_KERNEL_BUILDDIR}/scripts
> +   cp ${B}/scripts/module.lds 
> ${STAGING_KERNEL_BUILDDIR}/scripts/
> +   fi

You really shouldn't need this here.

The only reason we copy Module.symvers is that the kernel module build
updates it.

I only have the single copy in my local change (since it is created by
modules_prepare), and I'm not seeing any breakage.

Were you seeing somewhere that it was updated, or something that was breaking ?

Bruce


> else
> bbnote "no modules to compile"
> fi
> @@ -465,6 +469,11 @@ do_shared_workdir () {
> # Copy files required for module builds
> cp System.map $kerneldir/System.map-${KERNEL_VERSION}
> [ -e Module.symvers ] && cp Module.symvers $kerneldir/
> +   if [ -e ./scripts/module.lds ]; then
> +   mkdir -p $kerneldir/scripts
> +   cp ./scripts/module.lds $kerneldir/scripts/
> +   fi
> +
> cp .config $kerneldir/
> mkdir -p $kerneldir/include/config
> cp include/config/kernel.release 
> $kerneldir/include/config/kernel.release
> --
> 2.17.1
>
>
> 
>


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

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

[OE-core][gatesgarth][dunfell][master][PATCH] kernel.bbclass: fix module.lds missing issue since kernel v5.10

[Lili Li]

With v5.10-rc1 kernel commit 596b0474d3d9 (kbuild: preprocess module
 linker script), external kernel module need scripts/module.lds
for compiling.

Error Log:
*** No rule to make target 'scripts/module.lds', needed by 

Signed-off-by: Pan, Kris 
Signed-off-by: Lili Li 
---
 meta/classes/kernel.bbclass | 9 +
 1 file changed, 9 insertions(+)

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 9e3c34ad48..5c262f340e 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -358,6 +358,10 @@ do_compile_kernelmodules() {
# other kernel modules and will look at this
# file to do symbol lookups
cp ${B}/Module.symvers ${STAGING_KERNEL_BUILDDIR}/
+   if [ -e ${B}/scripts/module.lds ]; then
+   mkdir -p ${STAGING_KERNEL_BUILDDIR}/scripts
+   cp ${B}/scripts/module.lds 
${STAGING_KERNEL_BUILDDIR}/scripts/
+   fi
else
bbnote "no modules to compile"
fi
@@ -465,6 +469,11 @@ do_shared_workdir () {
# Copy files required for module builds
cp System.map $kerneldir/System.map-${KERNEL_VERSION}
[ -e Module.symvers ] && cp Module.symvers $kerneldir/
+   if [ -e ./scripts/module.lds ]; then
+   mkdir -p $kerneldir/scripts
+   cp ./scripts/module.lds $kerneldir/scripts/
+   fi
+
cp .config $kerneldir/
mkdir -p $kerneldir/include/config
cp include/config/kernel.release 
$kerneldir/include/config/kernel.release
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#144539): 
https://lists.openembedded.org/g/openembedded-core/message/144539
Mute This Topic: https://lists.openembedded.org/mt/78221736/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] kexec: arm64: disabled check if kaslr-seed dtb property was wiped

[Alexander Kamensky]

qemuarm64 fails to kexec secondary kernel with following message:

setup_2nd_dtb: kaslr-seed is not wiped to 0.
kexec: setup_2nd_dtb failed.
kexec: load failed.

It happens because kaslr-seed is not wiped in case when CONFIG_RANDOMIZE_BASE
is not set and qemu generates chosen/kaslr-seed property.

Solution is to remove check in kexec-tools that kaslr-seed is 0.

Signed-off-by: Alexander Kamensky 
---
 ...bled-check-if-kaslr-seed-dtb-propert.patch | 67 +++
 .../kexec/kexec-tools_2.0.20.bb   |  1 +
 2 files changed, 68 insertions(+)
 create mode 100644 
meta/recipes-kernel/kexec/kexec-tools/0001-arm64-kexec-disabled-check-if-kaslr-seed-dtb-propert.patch

diff --git 
a/meta/recipes-kernel/kexec/kexec-tools/0001-arm64-kexec-disabled-check-if-kaslr-seed-dtb-propert.patch
 
b/meta/recipes-kernel/kexec/kexec-tools/0001-arm64-kexec-disabled-check-if-kaslr-seed-dtb-propert.patch
new file mode 100644
index 00..c2301e711d
--- /dev/null
+++ 
b/meta/recipes-kernel/kexec/kexec-tools/0001-arm64-kexec-disabled-check-if-kaslr-seed-dtb-propert.patch
@@ -0,0 +1,67 @@
+From d48ec5e1a5fb7907520dee71b1d94045486a0c29 Mon Sep 17 00:00:00 2001
+From: Alexander Kamensky 
+Date: Thu, 12 Nov 2020 12:56:46 -0800
+Subject: [PATCH] arm64: kexec: disabled check if kaslr-seed dtb property was
+ wiped
+
+Kexec when loading arm64 kernel checks if chosen/kaslr-seed dtb property is
+wiped. It's a good assertion to verify proper behavior of kernel. However,
+if bootloader creates and fills kaslr-seed property and kernel is not
+configured with CONFIG_RANDOMIZE_BASE then logic of reading and wiping
+kaslr-seed does not run. As a result kaslr-seed property is not zero and when
+kexec tries to load secondary kernel it fails with the following message:
+
+setup_2nd_dtb: kaslr-seed is not wiped to 0.
+kexec: setup_2nd_dtb failed.
+kexec: load failed.
+
+This was observed on Yocto Project on qemuarm64 machine with 5.8 kernel,
+qemu 5.1.0. Qemu created kaslr-seed property but kernel was not configured
+with CONFIG_RANDOMIZE_BASE.
+
+Although check has some value, there is a use-case where it breaks kexec,
+this patch removes it.
+
+Note in described use-case the fact that kaslr-seed is not wiped and user
+readable through /sys/firmware/fdt or
+/sys/firmware/devicetree/base/chosen/kaslr-seed is not a security problem
+as kaslr is disabled anyway.
+
+Signed-off-by: Alexander Kamensky 
+Upstream-Status: Submitted 
[http://lists.infradead.org/pipermail/kexec/2020-November/021740.html]
+---
+ kexec/arch/arm64/kexec-arm64.c | 14 +-
+ 1 file changed, 1 insertion(+), 13 deletions(-)
+
+Index: kexec-tools-2.0.20/kexec/arch/arm64/kexec-arm64.c
+===
+--- kexec-tools-2.0.20.orig/kexec/arch/arm64/kexec-arm64.c
 kexec-tools-2.0.20/kexec/arch/arm64/kexec-arm64.c
+@@ -428,7 +428,7 @@ static int setup_2nd_dtb(struct dtb *dtb
+   int len, range_len;
+   int nodeoffset;
+   int new_size;
+-  int result, kaslr_seed;
++  int result;
+ 
+   result = fdt_check_header(dtb->buf);
+ 
+@@ -499,18 +499,6 @@ static int setup_2nd_dtb(struct dtb *dtb
+   return result;
+   }
+   } else {
+-  kaslr_seed = fdt64_to_cpu(*prop);
+-
+-  /* kaslr_seed must be wiped clean by primary
+-   * kernel during boot
+-   */
+-  if (kaslr_seed != 0) {
+-  dbgprintf("%s: kaslr-seed is not wiped to 0.\n",
+-  __func__);
+-  result = -EINVAL;
+-  goto on_error;
+-  }
+-
+   /*
+* Invoke the getrandom system call with
+* GRND_NONBLOCK, to make sure we
diff --git a/meta/recipes-kernel/kexec/kexec-tools_2.0.20.bb 
b/meta/recipes-kernel/kexec/kexec-tools_2.0.20.bb
index 1e81ecc2c7..69d2e9bfba 100644
--- a/meta/recipes-kernel/kexec/kexec-tools_2.0.20.bb
+++ b/meta/recipes-kernel/kexec/kexec-tools_2.0.20.bb
@@ -21,6 +21,7 @@ SRC_URI = 
"${KERNELORG_MIRROR}/linux/utils/kernel/kexec/kexec-tools-${PV}.tar.gz
file://0006-kexec-arm-undefine-__NR_kexec_file_load-for-arm.patch \
file://0007-kexec-un-break-the-build-on-32-bit-x86.patch \
file://0001-kexec-Fix-build-with-fno-common.patch \
+   
file://0001-arm64-kexec-disabled-check-if-kaslr-seed-dtb-propert.patch \
"
 
 SRC_URI[md5sum] = "46724b67f32501c5d3e778161347cad9"
-- 
2.26.2


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#144538): 
https://lists.openembedded.org/g/openembedded-core/message/144538
Mute This Topic: https://lists.openembedded.org/mt/78218253/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: Add xcb-fixes to loader when using x11 and dri3

[Tom Hochstein]

> -Original Message-
> From: Andrey Zhizhikin 
> Sent: Thursday, November 12, 2020 3:23 PM
> 
> I believe all patch files are located in `files` folder, while this
> patch tries to put it into `mesa` folder which does not exist yet? Is
> it intended here?
> 

It was a mistake, thanks for catching it. V2 submitted.

Tom

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#144537): 
https://lists.openembedded.org/g/openembedded-core/message/144537
Mute This Topic: https://lists.openembedded.org/mt/78060312/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] mesa: Add xcb-fixes to loader when using x11 and dri3

[Tom Hochstein]

Backport fix for undefined symbol for xcb_xfixes_create_region in 
loader_dri3_helper.c.

Signed-off-by: Tom Hochstein 
---
 ...xes-to-loader-when-using-x11-and-dri.patch | 36 +++
 meta/recipes-graphics/mesa/mesa.inc   |  1 +
 2 files changed, 37 insertions(+)
 create mode 100644 
meta/recipes-graphics/mesa/files/0001-meson-Add-xcb-fixes-to-loader-when-using-x11-and-dri.patch

diff --git 
a/meta/recipes-graphics/mesa/files/0001-meson-Add-xcb-fixes-to-loader-when-using-x11-and-dri.patch
 
b/meta/recipes-graphics/mesa/files/0001-meson-Add-xcb-fixes-to-loader-when-using-x11-and-dri.patch
new file mode 100644
index 00..9ee72880a2
--- /dev/null
+++ 
b/meta/recipes-graphics/mesa/files/0001-meson-Add-xcb-fixes-to-loader-when-using-x11-and-dri.patch
@@ -0,0 +1,36 @@
+From cf17d6251653f4a98e7c4f904ea2f0bc0ecedd5c Mon Sep 17 00:00:00 2001
+From: Duncan Hopkins 
+Date: Thu, 15 Oct 2020 12:14:57 +0100
+Subject: [PATCH] meson: Add xcb-fixes to loader when using x11 and dri3. Fixes
+ undefined symbol for xcb_xfixes_create_region in loader_dri3_helper.c
+
+loader_dr3_helper.c uses xcb_xfixes_create_region() that requires 
dep_xcb_xfixes to link. This is dependent on with_platform_x11 and with_dri3.
+But the source meson file does not set this up dependent on with_dri3.
+The build was initialsed using platforms=x11 and gallium-drivers=zink,swrast.
+
+Reviewed-by: Eric Anholt 
+Part-of: 
+
+Upstream-Status: Backport [cf17d6251653f4a98e7c4f904ea2f0bc0ecedd5c]
+
+---
+ meson.build | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/meson.build b/meson.build
+index cfe02fa6373..3cb3c904927 100644
+--- a/meson.build
 b/meson.build
+@@ -1782,7 +1782,8 @@ if with_platform_x11
+   dep_xxf86vm = dependency('xxf86vm')
+ endif
+   endif
+-  if (with_egl or (
++  if (with_egl or 
++  with_dri3 or (
+   with_gallium_vdpau or with_gallium_xvmc or with_gallium_xa or
+   with_gallium_omx != 'disabled'))
+ dep_xcb_xfixes = dependency('xcb-xfixes')
+-- 
+2.17.1
+
diff --git a/meta/recipes-graphics/mesa/mesa.inc 
b/meta/recipes-graphics/mesa/mesa.inc
index 5a6caf2662..ca593b8b1f 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -22,6 +22,7 @@ SRC_URI = 
"https://mesa.freedesktop.org/archive/mesa-${PV}.tar.xz \
file://0001-meson-misdetects-64bit-atomics-on-mips-clang.patch \
file://0001-futex.h-Define-__NR_futex-if-it-does-not-exist.patch \

file://0001-anv-fix-a-build-race-between-generating-a-header-and.patch \
+   
file://0001-meson-Add-xcb-fixes-to-loader-when-using-x11-and-dri.patch \
"
 
 SRC_URI[sha256sum] = 
"d1a46d9a3f291bc0e0374600bdcb59844fa3eafaa50398e472a36fc65fd0244a"
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#144536): 
https://lists.openembedded.org/g/openembedded-core/message/144536
Mute This Topic: https://lists.openembedded.org/mt/78217060/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: Add xcb-fixes to loader when using x11 and dri3

[Andrey Zhizhikin]

On Thu, Nov 5, 2020 at 9:39 PM Tom Hochstein  wrote:
>
> Backport fix for undefined symbol for xcb_xfixes_create_region in 
> loader_dri3_helper.c.
>
> Signed-off-by: Tom Hochstein 
> ---
>  meta/recipes-graphics/mesa/mesa.inc   |  1 +
>  ...xes-to-loader-when-using-x11-and-dri.patch | 36 +++
>  2 files changed, 37 insertions(+)
>  create mode 100644 
> meta/recipes-graphics/mesa/mesa/0001-meson-Add-xcb-fixes-to-loader-when-using-x11-and-dri.patch
>
> diff --git a/meta/recipes-graphics/mesa/mesa.inc 
> b/meta/recipes-graphics/mesa/mesa.inc
> index 15f54c5acd..246ed936e7 100644
> --- a/meta/recipes-graphics/mesa/mesa.inc
> +++ b/meta/recipes-graphics/mesa/mesa.inc
> @@ -21,6 +21,7 @@ SRC_URI = 
> "https://mesa.freedesktop.org/archive/mesa-${PV}.tar.xz \
> 
> file://0005-vc4-use-intmax_t-for-formatted-output-of-timespec-me.patch \
> file://0001-meson-misdetects-64bit-atomics-on-mips-clang.patch \
> file://0001-futex.h-Define-__NR_futex-if-it-does-not-exist.patch \
> +   
> file://0001-meson-Add-xcb-fixes-to-loader-when-using-x11-and-dri.patch \
> "
>
>  SRC_URI[sha256sum] = 
> "d1a46d9a3f291bc0e0374600bdcb59844fa3eafaa50398e472a36fc65fd0244a"
> diff --git 
> a/meta/recipes-graphics/mesa/mesa/0001-meson-Add-xcb-fixes-to-loader-when-using-x11-and-dri.patch
>  
> b/meta/recipes-graphics/mesa/mesa/0001-meson-Add-xcb-fixes-to-loader-when-using-x11-and-dri.patch
> new file mode 100644
> index 00..9ee72880a2
> --- /dev/null
> +++ 
> b/meta/recipes-graphics/mesa/mesa/0001-meson-Add-xcb-fixes-to-loader-when-using-x11-and-dri.patch

I believe all patch files are located in `files` folder, while this
patch tries to put it into `mesa` folder which does not exist yet? Is
it intended here?

> @@ -0,0 +1,36 @@
> +From cf17d6251653f4a98e7c4f904ea2f0bc0ecedd5c Mon Sep 17 00:00:00 2001
> +From: Duncan Hopkins 
> +Date: Thu, 15 Oct 2020 12:14:57 +0100
> +Subject: [PATCH] meson: Add xcb-fixes to loader when using x11 and dri3. 
> Fixes
> + undefined symbol for xcb_xfixes_create_region in loader_dri3_helper.c
> +
> +loader_dr3_helper.c uses xcb_xfixes_create_region() that requires 
> dep_xcb_xfixes to link. This is dependent on with_platform_x11 and with_dri3.
> +But the source meson file does not set this up dependent on with_dri3.
> +The build was initialsed using platforms=x11 and gallium-drivers=zink,swrast.
> +
> +Reviewed-by: Eric Anholt 
> +Part-of: 
> +
> +Upstream-Status: Backport [cf17d6251653f4a98e7c4f904ea2f0bc0ecedd5c]
> +
> +---
> + meson.build | 3 ++-
> + 1 file changed, 2 insertions(+), 1 deletion(-)
> +
> +diff --git a/meson.build b/meson.build
> +index cfe02fa6373..3cb3c904927 100644
> +--- a/meson.build
>  b/meson.build
> +@@ -1782,7 +1782,8 @@ if with_platform_x11
> +   dep_xxf86vm = dependency('xxf86vm')
> + endif
> +   endif
> +-  if (with_egl or (
> ++  if (with_egl or
> ++  with_dri3 or (
> +   with_gallium_vdpau or with_gallium_xvmc or with_gallium_xa or
> +   with_gallium_omx != 'disabled'))
> + dep_xcb_xfixes = dependency('xcb-xfixes')
> +--
> +2.17.1
> +
> --
> 2.17.1
>
>
> 
>


-- 
Regards,
Andrey.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#144535): 
https://lists.openembedded.org/g/openembedded-core/message/144535
Mute This Topic: https://lists.openembedded.org/mt/78060312/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] python3-native sysconfig failing to load in dunfell

[Alexander Kanavin]

Right, I think this is better too. The only problematic bit is that
situations where target _sysconfigdata is needed can produce really
unhelpful errors (e.g. meson hides this behind a generic 'python is not
working' message), and it is not obvious that these errors can be resolved
by adding a target python dependency.

Alex

On Thu, 12 Nov 2020 at 20:39, Martin Jansa  wrote:

> Do you remember kergoth's take on this? From "[RFC PATCH] devtool: remove
> _PYTHON_SYSCONFIGDATA_NAME to fix do_unpack" thread and
> https://lists.yoctoproject.org/g/yocto/topic/74637733#49571
>
>
> https://github.com/openembedded/openembedded-core/compare/master...kergoth:python-sysconfig
>
> I think wrapper is a bit better, because it will also catch cases where
> host python3 is being called from e.g. do_compile (e.g. by full path -
> after debugging ROS catkin in last few days, some components are really
> creative how to find their preferred python) even when python3native is
> inherited. And also doesn't need another bbclass to be inherited in cases
> where target _sysconfigdata is really needed.
>
> On Thu, Nov 12, 2020 at 8:26 PM Alexander Kanavin 
> wrote:
>
>> Thanks - I have a preliminary fix here (needs thorough testing):
>>
>> http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=akanavin/package-version-updates=d6b6a6f67cc967c0ead6dbab3c95435b7ca85246
>>
>> Alex
>>
>> On Thu, 12 Nov 2020 at 19:46, Glenn Stroz  wrote:
>>
>>> Hi Alex,
>>>
>>> We have a custom fetcher implemented as a bbclass that calls out to a
>>> python script.  That is why we see these issues with native. Here's a
>>> sample bbclass and recipe that reproduces the issue:
>>>
>>> impfail.bbclass
>>> ```
>>> inherit python3native
>>>
>>> do_unpack[noexec] = "1"
>>> do_patch[noexec] = "1"
>>> do_install[noexec] = "1"
>>>
>>> do_fetch() {
>>> python3 -c "import pydoc"
>>> }
>>> ```
>>>
>>> classrunner_0.0.1.bb
>>> ```
>>> SUMMARY = "Python runner"
>>> LICENSE = "CLOSED"
>>> inherit impfail
>>> ```
>>>
>>> -Glenn
>>>
>>>
>>> On Thu, Nov 12, 2020 at 4:52 AM Alexander Kanavin <
>>> alex.kana...@gmail.com> wrote:
>>>
 A quick fix may be to add a target python3 dependency to your recipe,
 yes ugly, but I can't figure out how to provide target python configuration
 to native python used in the context of building target recipes otherwise.

 Alex


 On Thu, 12 Nov 2020 at 10:49, Alexander Kanavin 
 wrote:

> On Thu, 12 Nov 2020 at 02:23, Glenn Stroz via lists.openembedded.org
>  wrote:
>
>> We've been upgrading our work to Dunfell and have encountered an
>> issue with python3-native.
>>
>> One of our python3-native scripts uses pydoc and that in turn
>> eventually pulls in python's sysconfig. However, this is failing to 
>> import
>> with the following stack trace:
>>
>> ```
>> import pydoc
>>   File
>> "/home/gstroz/.cache/avos/_avos_gstroz/avos/yocto-dunfell/build/tmp/work/corei7-64-poky-linux/ebpf-daemon/2020.282.17-r0/recipe-sysroot-native/usr/lib/python3.8/pydoc.py",
>> line 366, in 
>> class Doc:
>>   File
>> "/home/gstroz/.cache/avos/_avos_gstroz/avos/yocto-dunfell/build/tmp/work/corei7-64-poky-linux/ebpf-daemon/2020.282.17-r0/recipe-sysroot-native/usr/lib/python3.8/pydoc.py",
>> line 396, in Doc
>> def getdocloc(self, object, basedir=sysconfig.get_path('stdlib')):
>>   File
>> "/home/gstroz/.cache/avos/_avos_gstroz/avos/yocto-dunfell/build/tmp/work/corei7-64-poky-linux/ebpf-daemon/2020.282.17-r0/recipe-sysroot-native/usr/lib/python3.8/sysconfig.py",
>> line 519, in get_path
>> return get_paths(scheme, vars, expand)[name]
>>   File
>> "/home/gstroz/.cache/avos/_avos_gstroz/avos/yocto-dunfell/build/tmp/work/corei7-64-poky-linux/ebpf-daemon/2020.282.17-r0/recipe-sysroot-native/usr/lib/python3.8/sysconfig.py",
>> line 509, in get_paths
>> return _expand_vars(scheme, vars)
>>   File
>> "/home/gstroz/.cache/avos/_avos_gstroz/avos/yocto-dunfell/build/tmp/work/corei7-64-poky-linux/ebpf-daemon/2020.282.17-r0/recipe-sysroot-native/usr/lib/python3.8/sysconfig.py",
>> line 172, in _expand_vars
>> _extend_dict(vars, get_config_vars())
>>   File
>> "/home/gstroz/.cache/avos/_avos_gstroz/avos/yocto-dunfell/build/tmp/work/corei7-64-poky-linux/ebpf-daemon/2020.282.17-r0/recipe-sysroot-native/usr/lib/python3.8/sysconfig.py",
>> line 558, in get_config_vars
>> _init_posix(_CONFIG_VARS)
>>   File
>> "/home/gstroz/.cache/avos/_avos_gstroz/avos/yocto-dunfell/build/tmp/work/corei7-64-poky-linux/ebpf-daemon/2020.282.17-r0/recipe-sysroot-native/usr/lib/python3.8/sysconfig.py",
>> line 428, in _init_posix
>> _temp = __import__(name, globals(), locals(),
>> ['build_time_vars'], 0)
>> ModuleNotFoundError: No module named '_sysconfigdata'
>> ```
>>
>> I did a little digging and the following commit seems to 

Re: [OE-core] python3-native sysconfig failing to load in dunfell

[Martin Jansa]

Do you remember kergoth's take on this? From "[RFC PATCH] devtool: remove
_PYTHON_SYSCONFIGDATA_NAME to fix do_unpack" thread and
https://lists.yoctoproject.org/g/yocto/topic/74637733#49571

https://github.com/openembedded/openembedded-core/compare/master...kergoth:python-sysconfig

I think wrapper is a bit better, because it will also catch cases where
host python3 is being called from e.g. do_compile (e.g. by full path -
after debugging ROS catkin in last few days, some components are really
creative how to find their preferred python) even when python3native is
inherited. And also doesn't need another bbclass to be inherited in cases
where target _sysconfigdata is really needed.

On Thu, Nov 12, 2020 at 8:26 PM Alexander Kanavin 
wrote:

> Thanks - I have a preliminary fix here (needs thorough testing):
>
> http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=akanavin/package-version-updates=d6b6a6f67cc967c0ead6dbab3c95435b7ca85246
>
> Alex
>
> On Thu, 12 Nov 2020 at 19:46, Glenn Stroz  wrote:
>
>> Hi Alex,
>>
>> We have a custom fetcher implemented as a bbclass that calls out to a
>> python script.  That is why we see these issues with native. Here's a
>> sample bbclass and recipe that reproduces the issue:
>>
>> impfail.bbclass
>> ```
>> inherit python3native
>>
>> do_unpack[noexec] = "1"
>> do_patch[noexec] = "1"
>> do_install[noexec] = "1"
>>
>> do_fetch() {
>> python3 -c "import pydoc"
>> }
>> ```
>>
>> classrunner_0.0.1.bb
>> ```
>> SUMMARY = "Python runner"
>> LICENSE = "CLOSED"
>> inherit impfail
>> ```
>>
>> -Glenn
>>
>>
>> On Thu, Nov 12, 2020 at 4:52 AM Alexander Kanavin 
>> wrote:
>>
>>> A quick fix may be to add a target python3 dependency to your recipe,
>>> yes ugly, but I can't figure out how to provide target python configuration
>>> to native python used in the context of building target recipes otherwise.
>>>
>>> Alex
>>>
>>>
>>> On Thu, 12 Nov 2020 at 10:49, Alexander Kanavin 
>>> wrote:
>>>
 On Thu, 12 Nov 2020 at 02:23, Glenn Stroz via lists.openembedded.org
  wrote:

> We've been upgrading our work to Dunfell and have encountered an issue
> with python3-native.
>
> One of our python3-native scripts uses pydoc and that in turn
> eventually pulls in python's sysconfig. However, this is failing to import
> with the following stack trace:
>
> ```
> import pydoc
>   File
> "/home/gstroz/.cache/avos/_avos_gstroz/avos/yocto-dunfell/build/tmp/work/corei7-64-poky-linux/ebpf-daemon/2020.282.17-r0/recipe-sysroot-native/usr/lib/python3.8/pydoc.py",
> line 366, in 
> class Doc:
>   File
> "/home/gstroz/.cache/avos/_avos_gstroz/avos/yocto-dunfell/build/tmp/work/corei7-64-poky-linux/ebpf-daemon/2020.282.17-r0/recipe-sysroot-native/usr/lib/python3.8/pydoc.py",
> line 396, in Doc
> def getdocloc(self, object, basedir=sysconfig.get_path('stdlib')):
>   File
> "/home/gstroz/.cache/avos/_avos_gstroz/avos/yocto-dunfell/build/tmp/work/corei7-64-poky-linux/ebpf-daemon/2020.282.17-r0/recipe-sysroot-native/usr/lib/python3.8/sysconfig.py",
> line 519, in get_path
> return get_paths(scheme, vars, expand)[name]
>   File
> "/home/gstroz/.cache/avos/_avos_gstroz/avos/yocto-dunfell/build/tmp/work/corei7-64-poky-linux/ebpf-daemon/2020.282.17-r0/recipe-sysroot-native/usr/lib/python3.8/sysconfig.py",
> line 509, in get_paths
> return _expand_vars(scheme, vars)
>   File
> "/home/gstroz/.cache/avos/_avos_gstroz/avos/yocto-dunfell/build/tmp/work/corei7-64-poky-linux/ebpf-daemon/2020.282.17-r0/recipe-sysroot-native/usr/lib/python3.8/sysconfig.py",
> line 172, in _expand_vars
> _extend_dict(vars, get_config_vars())
>   File
> "/home/gstroz/.cache/avos/_avos_gstroz/avos/yocto-dunfell/build/tmp/work/corei7-64-poky-linux/ebpf-daemon/2020.282.17-r0/recipe-sysroot-native/usr/lib/python3.8/sysconfig.py",
> line 558, in get_config_vars
> _init_posix(_CONFIG_VARS)
>   File
> "/home/gstroz/.cache/avos/_avos_gstroz/avos/yocto-dunfell/build/tmp/work/corei7-64-poky-linux/ebpf-daemon/2020.282.17-r0/recipe-sysroot-native/usr/lib/python3.8/sysconfig.py",
> line 428, in _init_posix
> _temp = __import__(name, globals(), locals(), ['build_time_vars'],
> 0)
> ModuleNotFoundError: No module named '_sysconfigdata'
> ```
>
> I did a little digging and the following commit seems to reference
> related work:
>
>
> https://github.com/openembedded/openembedded-core/commit/02714c105426b0d687620913c1a7401b386428b6
>
> I see that there is a patch added which adds the following to
> `sysconfig.py`:
>
> ```
>   if 'STAGING_LIBDIR' in os.environ:
>
> sys.path.append(os.environ['STAGING_LIBDIR']+'/python-sysconfigdata')
> ```
>
> However, STAGING_LIBDIR does not contain this path:
>
> ```
> ls
> 

[OE-core] [PATCH] libbsd: Remove BSD-4-Clause from main package

[Mark Jonas]

libbsd contains a multitude of licenses. For (commercial) projects the
3rd clause of the BSD-4-Clause license can be problematic. But only a
few man pages use this license. This means that the main package
containing the binary library itself is not under BSD-4-Clause ruling.

Signed-off-by: Mark Jonas 
---
 meta/recipes-support/libbsd/libbsd_0.10.0.bb | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-support/libbsd/libbsd_0.10.0.bb 
b/meta/recipes-support/libbsd/libbsd_0.10.0.bb
index 3b9ac5a01f..5b32b9af41 100644
--- a/meta/recipes-support/libbsd/libbsd_0.10.0.bb
+++ b/meta/recipes-support/libbsd/libbsd_0.10.0.bb
@@ -27,7 +27,8 @@ HOMEPAGE = "https://libbsd.freedesktop.org/wiki/;
 # License: ISC-Original
 # License: public-domain
 # License: public-domain-Colin-Plumb
-LICENSE = "BSD-4-Clause & ISC & PD"
+LICENSE = "BSD-3-Clause & BSD-4-Clause & ISC & PD"
+LICENSE_${PN} = "BSD-3-Clause & ISC & PD"
 LIC_FILES_CHKSUM = "file://COPYING;md5=2120be0173469a06ed185b688e0e1ae0"
 SECTION = "libs"
 
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#144532): 
https://lists.openembedded.org/g/openembedded-core/message/144532
Mute This Topic: https://lists.openembedded.org/mt/78214400/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] python3-native sysconfig failing to load in dunfell

[Alexander Kanavin]

Thanks - I have a preliminary fix here (needs thorough testing):
http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=akanavin/package-version-updates=d6b6a6f67cc967c0ead6dbab3c95435b7ca85246

Alex

On Thu, 12 Nov 2020 at 19:46, Glenn Stroz  wrote:

> Hi Alex,
>
> We have a custom fetcher implemented as a bbclass that calls out to a
> python script.  That is why we see these issues with native. Here's a
> sample bbclass and recipe that reproduces the issue:
>
> impfail.bbclass
> ```
> inherit python3native
>
> do_unpack[noexec] = "1"
> do_patch[noexec] = "1"
> do_install[noexec] = "1"
>
> do_fetch() {
> python3 -c "import pydoc"
> }
> ```
>
> classrunner_0.0.1.bb
> ```
> SUMMARY = "Python runner"
> LICENSE = "CLOSED"
> inherit impfail
> ```
>
> -Glenn
>
>
> On Thu, Nov 12, 2020 at 4:52 AM Alexander Kanavin 
> wrote:
>
>> A quick fix may be to add a target python3 dependency to your recipe, yes
>> ugly, but I can't figure out how to provide target python configuration to
>> native python used in the context of building target recipes otherwise.
>>
>> Alex
>>
>>
>> On Thu, 12 Nov 2020 at 10:49, Alexander Kanavin 
>> wrote:
>>
>>> On Thu, 12 Nov 2020 at 02:23, Glenn Stroz via lists.openembedded.org
>>>  wrote:
>>>
 We've been upgrading our work to Dunfell and have encountered an issue
 with python3-native.

 One of our python3-native scripts uses pydoc and that in turn
 eventually pulls in python's sysconfig. However, this is failing to import
 with the following stack trace:

 ```
 import pydoc
   File
 "/home/gstroz/.cache/avos/_avos_gstroz/avos/yocto-dunfell/build/tmp/work/corei7-64-poky-linux/ebpf-daemon/2020.282.17-r0/recipe-sysroot-native/usr/lib/python3.8/pydoc.py",
 line 366, in 
 class Doc:
   File
 "/home/gstroz/.cache/avos/_avos_gstroz/avos/yocto-dunfell/build/tmp/work/corei7-64-poky-linux/ebpf-daemon/2020.282.17-r0/recipe-sysroot-native/usr/lib/python3.8/pydoc.py",
 line 396, in Doc
 def getdocloc(self, object, basedir=sysconfig.get_path('stdlib')):
   File
 "/home/gstroz/.cache/avos/_avos_gstroz/avos/yocto-dunfell/build/tmp/work/corei7-64-poky-linux/ebpf-daemon/2020.282.17-r0/recipe-sysroot-native/usr/lib/python3.8/sysconfig.py",
 line 519, in get_path
 return get_paths(scheme, vars, expand)[name]
   File
 "/home/gstroz/.cache/avos/_avos_gstroz/avos/yocto-dunfell/build/tmp/work/corei7-64-poky-linux/ebpf-daemon/2020.282.17-r0/recipe-sysroot-native/usr/lib/python3.8/sysconfig.py",
 line 509, in get_paths
 return _expand_vars(scheme, vars)
   File
 "/home/gstroz/.cache/avos/_avos_gstroz/avos/yocto-dunfell/build/tmp/work/corei7-64-poky-linux/ebpf-daemon/2020.282.17-r0/recipe-sysroot-native/usr/lib/python3.8/sysconfig.py",
 line 172, in _expand_vars
 _extend_dict(vars, get_config_vars())
   File
 "/home/gstroz/.cache/avos/_avos_gstroz/avos/yocto-dunfell/build/tmp/work/corei7-64-poky-linux/ebpf-daemon/2020.282.17-r0/recipe-sysroot-native/usr/lib/python3.8/sysconfig.py",
 line 558, in get_config_vars
 _init_posix(_CONFIG_VARS)
   File
 "/home/gstroz/.cache/avos/_avos_gstroz/avos/yocto-dunfell/build/tmp/work/corei7-64-poky-linux/ebpf-daemon/2020.282.17-r0/recipe-sysroot-native/usr/lib/python3.8/sysconfig.py",
 line 428, in _init_posix
 _temp = __import__(name, globals(), locals(), ['build_time_vars'],
 0)
 ModuleNotFoundError: No module named '_sysconfigdata'
 ```

 I did a little digging and the following commit seems to reference
 related work:


 https://github.com/openembedded/openembedded-core/commit/02714c105426b0d687620913c1a7401b386428b6

 I see that there is a patch added which adds the following to
 `sysconfig.py`:

 ```
   if 'STAGING_LIBDIR' in os.environ:

 sys.path.append(os.environ['STAGING_LIBDIR']+'/python-sysconfigdata')
 ```

 However, STAGING_LIBDIR does not contain this path:

 ```
 ls
 /home/gstroz/.cache/avos/_avos_gstroz/avos/yocto-dunfell/build/tmp/work/corei7-64-poky-linux/ebpf-daemon/2020.282.17-r0/recipe-sysroot/usr/lib/python-sysconfigdata

 ls: cannot access
 '/home/gstroz/.cache/avos/_avos_gstroz/avos/yocto-dunfell/build/tmp/work/corei7-64-poky-linux/ebpf-daemon/2020.282.17-r0/recipe-sysroot/usr/lib/python-sysconfigdata':
 No such file or directory
 ```

 It appears as if this should really be pointing
 to STAGING_LIBDIR_NATIVE which does exist:

 ```
 ls
 /home/gstroz/.cache/avos/_avos_gstroz/avos/yocto-dunfell/build/tmp/work/corei7-64-poky-linux/ebpf-daemon/2020.282.17-r0/recipe-sysroot-native/usr/lib/python-sysconfigdata
 _sysconfigdata.py
 ```

 The referenced commit made efforts to combine the native and cross
 python3 bbclass files into one. However, I think this may be something that
 needs to be treated 

Re: [OE-core] devtool modify - ModuleNotFoundError: No module named '_sysconfigdata'

[Alexander Kanavin]

I have a tentative fix, but need to test it thoroughly, and adjust recipes
to use the new class where needed:
http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=akanavin/package-version-updates=d6b6a6f67cc967c0ead6dbab3c95435b7ca85246

It does resolve the devtool issue though.

Alex

On Thu, 12 Nov 2020 at 17:03, Alexander Kanavin via lists.openembedded.org
 wrote:

> I have just seen it first-hand for the first time. It happens on Ubuntu
> 20.04, but not on for example OpenSuse tumbleweed. So something in Ubuntu
> causes the native python environment to leak into the host python
> environment. Will investigate.
>
> Alex
>
> On Thu, 12 Nov 2020 at 13:59, Peter Bergin  wrote:
>
>> Hi Alex,
>>
>> On 2020-11-12 12:38, Alexander Kanavin wrote:
>> > If you can provide exact steps to reproduce (the recipe is not
>> > available in oe-core), I can take a look. It's been reported plenty of
>> > times, but always with something not in core and not easily available.
>>
>> here are the steps to reproduce with only poky. I hope it can help you
>> find the root cause:
>>
>>  $ git clone https://git.yoctoproject.org/git/poky sources/poky
>>  $ . ./sources/poky/oe-init-build-env
>>  $ echo 'MACHINE = "qemuarm64"' >> conf/auto.conf
>>  $ devtool modify u-boot
>>
>> And here is the output on my machine:
>>
>>  Build Configuration:
>>  BB_VERSION   = "1.49.0"
>>  BUILD_SYS= "x86_64-linux"
>>  NATIVELSBSTRING      = "ubuntu-20.04"
>>  TARGET_SYS   = "aarch64-poky-linux"
>>  MACHINE  = "qemuarm64"
>>  DISTRO   = "poky"
>>  DISTRO_VERSION   = "3.2+snapshot-20201112"
>>  TUNE_FEATURES= "aarch64 armv8a crc cortexa57"
>>  TARGET_FPU   = ""
>>  meta
>>  meta-poky
>>  meta-yocto-bsp   =
>> "master:e949e76d0f6897ec5d4feaa47afd2b049b32707f"
>>  workspace= ":"
>>
>>  Initialising tasks: 100%
>> |###| Time:
>> 0:00:00
>>  Sstate summary: Wanted 20 Found 20 Missed 0 Current 0 (100% match,
>> 0% complete)
>>  NOTE: Executing Tasks
>>  ERROR: Error executing a python function in exec_python_func()
>> autogenerated:
>>
>>  The stack trace of python calls that resulted in this
>> exception/failure was:
>>  File: 'exec_python_func() autogenerated', lineno: 2, function:
>> 
>>   0001:
>>   *** 0002:devtool_post_unpack(d)
>>   0003:
>>  File:
>> '/work/yocto/devtool-reproduce2/sources/poky/meta/classes/devtool-source.bbclass',
>>
>> lineno: 68, function: devtool_post_unpack
>>   0064:}
>>   0065:
>>   0066:
>>   0067:python devtool_post_unpack() {
>>   *** 0068:import oe.recipeutils
>>   0069:import shutil
>>   0070:sys.path.insert(0, os.path.join(d.getVar('COREBASE'),
>> 'scripts', 'lib'))
>>   0071:import scriptutils
>>   0072:from devtool import setup_git_repo
>>  File:
>> '/work/yocto/devtool-reproduce2/sources/poky/meta/lib/oe/recipeutils.py',
>> lineno: 21, function: 
>>   0017:import shutil
>>   0018:import re
>>   0019:import fnmatch
>>   0020:import glob
>>   *** 0021:import bb.tinfoil
>>   0022:
>>   0023:from collections import OrderedDict, defaultdict
>>   0024:from bb.utils import vercmp_string
>>   0025:
>>  File:
>> '/work/yocto/devtool-reproduce2/sources/poky/bitbake/lib/bb/tinfoil.py',
>> lineno: 19, function: 
>>   0015:from collections import OrderedDict, defaultdict
>>   0016:from functools import partial
>>   0017:
>>   0018:import bb.cache
>>   *** 0019:import bb.cooker
>>   0020:import bb.providers
>>   0021:import bb.taskdata
>>   0022:import bb.utils
>>   0023:import bb.command
>>  File:
>> '/work/yocto/devtool-reproduce2/sources/poky/bitbake/lib/bb/cooker.py',
>> lineno: 25, function: 
>>   0021:import bb, bb.exceptions, bb.command
>>   0022:from bb import utils, data, parse, event, cache,
>> providers, taskdata, runqueue, build
>>   0023:import queue
>>   002

Re: [OE-core] [PATCH v2] gdb: add PACKAGECONFIG for xz (lzma) compression support

[Khem Raj]

On Wed, Nov 11, 2020 at 11:40 PM Dan Callaghan via
lists.openembedded.org
 wrote:
>
> Bump... I just noticed this patch was never applied. I have been
> carrying it locally all year and it still applies cleanly. Any issues
> preventing it from being applied?
>

thanks, I think this patch is fine.

> Excerpts from Dan Callaghan's message of 2020-01-21 11:24:12 +10:00:
> > Similar to elfutils, when xz support is built into gdb it will be able
> > to read xz-compressed ELF sections containing debuginfo. This is used by
> > the "mini debuginfo" format:
> > https://sourceware.org/gdb/onlinedocs/gdb/MiniDebugInfo.html
> >
> > Signed-off-by: Dan Callaghan 
> > ---
> >  meta/recipes-devtools/gdb/gdb-common.inc | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/meta/recipes-devtools/gdb/gdb-common.inc 
> > b/meta/recipes-devtools/gdb/gdb-common.inc
> > index 08f615addf..878a03715c 100644
> > --- a/meta/recipes-devtools/gdb/gdb-common.inc
> > +++ b/meta/recipes-devtools/gdb/gdb-common.inc
> > @@ -21,7 +21,7 @@ EXPAT = "--with-expat 
> > --with-libexpat-prefix=${STAGING_DIR_HOST}"
> >
> >  EXTRA_OECONF = "--disable-gdbtk --disable-x --disable-werror \
> >  --with-curses --disable-multilib --disable-sim \
> > ---without-lzma --without-guile \
> > +--without-guile \
> >  ${GDBPROPREFIX} ${EXPAT} \
> >  ${@bb.utils.contains('DISTRO_FEATURES', 'multiarch', 
> > '--enable-64-bit-bfd', '', d)} \
> >  --disable-rpath \
> > @@ -37,6 +37,7 @@ PACKAGECONFIG[python] = 
> > "--with-python=${WORKDIR}/python,--without-python,python
> >  PACKAGECONFIG[babeltrace] = 
> > "--with-babeltrace,--without-babeltrace,babeltrace"
> >  # ncurses is already a hard DEPENDS, but would be added here if it weren't
> >  PACKAGECONFIG[tui] = "--enable-tui,--disable-tui"
> > +PACKAGECONFIG[xz] = "--with-lzma,--without-lzma,xz"
> >
> >  GDBPROPREFIX = "--program-prefix=''"
> >
>
> --
> Dan Callaghan 
> Software Engineer
> Opengear 
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#144529): 
https://lists.openembedded.org/g/openembedded-core/message/144529
Mute This Topic: https://lists.openembedded.org/mt/72392181/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] python3-native sysconfig failing to load in dunfell

[Glenn Stroz via lists.openembedded.org]

Hi Alex,

We have a custom fetcher implemented as a bbclass that calls out to a
python script.  That is why we see these issues with native. Here's a
sample bbclass and recipe that reproduces the issue:

impfail.bbclass
```
inherit python3native

do_unpack[noexec] = "1"
do_patch[noexec] = "1"
do_install[noexec] = "1"

do_fetch() {
python3 -c "import pydoc"
}
```

classrunner_0.0.1.bb
```
SUMMARY = "Python runner"
LICENSE = "CLOSED"
inherit impfail
```

-Glenn


On Thu, Nov 12, 2020 at 4:52 AM Alexander Kanavin 
wrote:

> A quick fix may be to add a target python3 dependency to your recipe, yes
> ugly, but I can't figure out how to provide target python configuration to
> native python used in the context of building target recipes otherwise.
>
> Alex
>
>
> On Thu, 12 Nov 2020 at 10:49, Alexander Kanavin 
> wrote:
>
>> On Thu, 12 Nov 2020 at 02:23, Glenn Stroz via lists.openembedded.org
>>  wrote:
>>
>>> We've been upgrading our work to Dunfell and have encountered an issue
>>> with python3-native.
>>>
>>> One of our python3-native scripts uses pydoc and that in turn eventually
>>> pulls in python's sysconfig. However, this is failing to import with the
>>> following stack trace:
>>>
>>> ```
>>> import pydoc
>>>   File
>>> "/home/gstroz/.cache/avos/_avos_gstroz/avos/yocto-dunfell/build/tmp/work/corei7-64-poky-linux/ebpf-daemon/2020.282.17-r0/recipe-sysroot-native/usr/lib/python3.8/pydoc.py",
>>> line 366, in 
>>> class Doc:
>>>   File
>>> "/home/gstroz/.cache/avos/_avos_gstroz/avos/yocto-dunfell/build/tmp/work/corei7-64-poky-linux/ebpf-daemon/2020.282.17-r0/recipe-sysroot-native/usr/lib/python3.8/pydoc.py",
>>> line 396, in Doc
>>> def getdocloc(self, object, basedir=sysconfig.get_path('stdlib')):
>>>   File
>>> "/home/gstroz/.cache/avos/_avos_gstroz/avos/yocto-dunfell/build/tmp/work/corei7-64-poky-linux/ebpf-daemon/2020.282.17-r0/recipe-sysroot-native/usr/lib/python3.8/sysconfig.py",
>>> line 519, in get_path
>>> return get_paths(scheme, vars, expand)[name]
>>>   File
>>> "/home/gstroz/.cache/avos/_avos_gstroz/avos/yocto-dunfell/build/tmp/work/corei7-64-poky-linux/ebpf-daemon/2020.282.17-r0/recipe-sysroot-native/usr/lib/python3.8/sysconfig.py",
>>> line 509, in get_paths
>>> return _expand_vars(scheme, vars)
>>>   File
>>> "/home/gstroz/.cache/avos/_avos_gstroz/avos/yocto-dunfell/build/tmp/work/corei7-64-poky-linux/ebpf-daemon/2020.282.17-r0/recipe-sysroot-native/usr/lib/python3.8/sysconfig.py",
>>> line 172, in _expand_vars
>>> _extend_dict(vars, get_config_vars())
>>>   File
>>> "/home/gstroz/.cache/avos/_avos_gstroz/avos/yocto-dunfell/build/tmp/work/corei7-64-poky-linux/ebpf-daemon/2020.282.17-r0/recipe-sysroot-native/usr/lib/python3.8/sysconfig.py",
>>> line 558, in get_config_vars
>>> _init_posix(_CONFIG_VARS)
>>>   File
>>> "/home/gstroz/.cache/avos/_avos_gstroz/avos/yocto-dunfell/build/tmp/work/corei7-64-poky-linux/ebpf-daemon/2020.282.17-r0/recipe-sysroot-native/usr/lib/python3.8/sysconfig.py",
>>> line 428, in _init_posix
>>> _temp = __import__(name, globals(), locals(), ['build_time_vars'], 0)
>>> ModuleNotFoundError: No module named '_sysconfigdata'
>>> ```
>>>
>>> I did a little digging and the following commit seems to reference
>>> related work:
>>>
>>>
>>> https://github.com/openembedded/openembedded-core/commit/02714c105426b0d687620913c1a7401b386428b6
>>>
>>> I see that there is a patch added which adds the following to
>>> `sysconfig.py`:
>>>
>>> ```
>>>   if 'STAGING_LIBDIR' in os.environ:
>>>
>>> sys.path.append(os.environ['STAGING_LIBDIR']+'/python-sysconfigdata')
>>> ```
>>>
>>> However, STAGING_LIBDIR does not contain this path:
>>>
>>> ```
>>> ls
>>> /home/gstroz/.cache/avos/_avos_gstroz/avos/yocto-dunfell/build/tmp/work/corei7-64-poky-linux/ebpf-daemon/2020.282.17-r0/recipe-sysroot/usr/lib/python-sysconfigdata
>>>
>>> ls: cannot access
>>> '/home/gstroz/.cache/avos/_avos_gstroz/avos/yocto-dunfell/build/tmp/work/corei7-64-poky-linux/ebpf-daemon/2020.282.17-r0/recipe-sysroot/usr/lib/python-sysconfigdata':
>>> No such file or directory
>>> ```
>>>
>>> It appears as if this should really be pointing to STAGING_LIBDIR_NATIVE
>>> which does exist:
>>>
>>> ```
>>> ls
>>> /home/gstroz/.cache/avos/_avos_gstroz/avos/yocto-dunfell/build/tmp/work/corei7-64-poky-linux/ebpf-daemon/2020.282.17-r0/recipe-sysroot-native/usr/lib/python-sysconfigdata
>>> _sysconfigdata.py
>>> ```
>>>
>>> The referenced commit made efforts to combine the native and cross
>>> python3 bbclass files into one. However, I think this may be something that
>>> needs to be treated differently.
>>>
>>> Anyone have any thoughts on how to proceed?
>>>
>>
>> Can you share the exact context where this is happening? Is your script
>> coming from a recipe and can you show that recipe?
>>
>> Alex
>>
>>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#144528): 
https://lists.openembedded.org/g/openembedded-core/message/144528
Mute This Topic: 

Re: [OE-core] [PATCH v2] dbus: split -common and -tools out of main package

[Luca Boccassi via lists.openembedded.org]

On Thu, 2020-11-12 at 17:29 +, Richard Purdie wrote:
> On Mon, 2020-11-02 at 19:18 +, Luca Bocassi wrote:
> > From: Luca Boccassi 
> > 
> > Certain config files and units are shared between dbus-daemon and
> > dbus-broker (available in meta-openembedded), so split them out to
> > allow installing dbus-broker without pulling in dbus-daemon and its
> > dependencies.
> > Stand-alone command line tools can also be used regardless of whether
> > the buses are provided by dbus-daemon or dbus-broker, so split them
> > out into dbus-tools.
> > Finally, move the XML schema files out of the main package and into
> > the development package.
> > 
> > All these changes follow the same pattern used by Fedora, which was
> > one of the first distro to switch to dbus-broker by default:
> > 
> > https://src.fedoraproject.org/rpms/dbus/blob/master/f/dbus.spec
> > 
> > Signed-off-by: Luca Boccassi 
> > ---
> > v2: fix FILES_ regex to correctly include all units but the sockets
> > in the main package
> 
> I tried putting this through testing on the autobuilder but it fails in
> world builds:
> 
> https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/1589/steps/13/logs/stdio
> 
> (dbus-native seems to depend upon dbus-native-tools-native)
> 
> so I've had to drop the patch.
> 
> Cheers,
> 
> Richard

Hi,

That's a weird error? Building the basic poky reference didn't show it.

Any suggestion on how to fix it? Do you see anything obviously wrong
with the patch? Is this the correct way to add a runtime dependency in
Yocto:

RDEPENDS_${PN} += "${PN}-common ${PN}-tools"

Should it hard-code the name and drop the ${PN} perhaps?

-- 
Kind regards,
Luca Boccassi

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#144527): 
https://lists.openembedded.org/g/openembedded-core/message/144527
Mute This Topic: https://lists.openembedded.org/mt/77989696/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] dbus: split -common and -tools out of main package

[Richard Purdie]

On Mon, 2020-11-02 at 19:18 +, Luca Bocassi wrote:
> From: Luca Boccassi 
> 
> Certain config files and units are shared between dbus-daemon and
> dbus-broker (available in meta-openembedded), so split them out to
> allow installing dbus-broker without pulling in dbus-daemon and its
> dependencies.
> Stand-alone command line tools can also be used regardless of whether
> the buses are provided by dbus-daemon or dbus-broker, so split them
> out into dbus-tools.
> Finally, move the XML schema files out of the main package and into
> the development package.
> 
> All these changes follow the same pattern used by Fedora, which was
> one of the first distro to switch to dbus-broker by default:
> 
> https://src.fedoraproject.org/rpms/dbus/blob/master/f/dbus.spec
> 
> Signed-off-by: Luca Boccassi 
> ---
> v2: fix FILES_ regex to correctly include all units but the sockets
> in the main package

I tried putting this through testing on the autobuilder but it fails in
world builds:

https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/1589/steps/13/logs/stdio

(dbus-native seems to depend upon dbus-native-tools-native)

so I've had to drop the patch.

Cheers,

Richard


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#144526): 
https://lists.openembedded.org/g/openembedded-core/message/144526
Mute This Topic: https://lists.openembedded.org/mt/77989696/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 4/5] systemtap: fix install when python3-probes is disabled in PACKAGECONFIG

[Yann Dirson]

From: Yann Dirson 

---
 meta/recipes-kernel/systemtap/systemtap_git.bb | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-kernel/systemtap/systemtap_git.bb 
b/meta/recipes-kernel/systemtap/systemtap_git.bb
index 89f550c859..74bf7cb35c 100644
--- a/meta/recipes-kernel/systemtap/systemtap_git.bb
+++ b/meta/recipes-kernel/systemtap/systemtap_git.bb
@@ -66,7 +66,7 @@ do_install_append () {
   rm ${D}${libexecdir}/${PN}/stap-env
fi
 
-   if [ ${D}${prefix}/lib != `dirname ${D}${systemd_unitdir}` ]; then
+   if [ -d ${D}${prefix}/lib/systemd -a ${D}${prefix}/lib != `dirname 
${D}${systemd_unitdir}` ]; then
   # Fix makefile hardcoded path assumptions for systemd (assumes $prefix)
   # without usrmerge distro feature enabled
   install -d `dirname ${D}${systemd_unitdir}`
@@ -75,7 +75,9 @@ do_install_append () {
fi
 
# Ensure correct ownership for files copied in
-   chown root:root ${D}${sysconfdir}/stap-exporter/* -R
+   if [ -d ${D}${sysconfdir}/stap-exporter ]; then
+   chown root:root ${D}${sysconfdir}/stap-exporter/* -R
+   fi
 }
 
 BBCLASSEXTEND = "nativesdk"
-- 
2.28.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#144524): 
https://lists.openembedded.org/g/openembedded-core/message/144524
Mute This Topic: https://lists.openembedded.org/mt/78211647/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 3/5] systemtap: clarify the relation between exporter and python3-probes feature

[Yann Dirson]

From: Yann Dirson 

---
 meta/recipes-kernel/systemtap/systemtap_git.bb | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/meta/recipes-kernel/systemtap/systemtap_git.bb 
b/meta/recipes-kernel/systemtap/systemtap_git.bb
index 375e570454..89f550c859 100644
--- a/meta/recipes-kernel/systemtap/systemtap_git.bb
+++ b/meta/recipes-kernel/systemtap/systemtap_git.bb
@@ -27,15 +27,13 @@ PACKAGECONFIG[python3-probes] = 
"--with-python3-probes,--without-python3-probes,
 
 inherit autotools gettext pkgconfig distutils3-base systemd
 
+# exporter comes with python3-probes
 PACKAGES =+ "${PN}-exporter"
-
 FILES_${PN}-exporter = "${sysconfdir}/stap-exporter/* \
 ${sysconfdir}/sysconfig/stap-exporter \
 ${systemd_unitdir}/system/stap-exporter.service \
 ${sbindir}/stap-exporter"
-
 RDEPENDS_${PN}-exporter = "${PN} python3-core python3-netclient"
-
 SYSTEMD_SERVICE_${PN}-exporter = "stap-exporter.service"
 
 PACKAGES =+ "${PN}-examples"
-- 
2.28.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#144522): 
https://lists.openembedded.org/g/openembedded-core/message/144522
Mute This Topic: https://lists.openembedded.org/mt/78211644/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/5] systemtap: remove extra dependencies

[Yann Dirson]

From: Yann Dirson 

Most of the RDEPENDS part of PACKAGECONFIG[translator] appears to be related to
examples only.
---
 meta/recipes-kernel/systemtap/systemtap_git.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-kernel/systemtap/systemtap_git.bb 
b/meta/recipes-kernel/systemtap/systemtap_git.bb
index e98aff1851..375e570454 100644
--- a/meta/recipes-kernel/systemtap/systemtap_git.bb
+++ b/meta/recipes-kernel/systemtap/systemtap_git.bb
@@ -19,7 +19,7 @@ STAP_DOCS ?= "--disable-docs --disable-publican 
--disable-refdocs"
 EXTRA_OECONF += "${STAP_DOCS} "
 
 PACKAGECONFIG ??= "translator sqlite monitor python3-probes"
-PACKAGECONFIG[translator] = 
"--enable-translator,--disable-translator,boost,python3-core bash perl"
+PACKAGECONFIG[translator] = 
"--enable-translator,--disable-translator,boost,bash"
 PACKAGECONFIG[libvirt] = "--enable-libvirt,--disable-libvirt,libvirt"
 PACKAGECONFIG[sqlite] = "--enable-sqlite,--disable-sqlite,sqlite3"
 PACKAGECONFIG[monitor] = "--enable-monitor,--disable-monitor,ncurses json-c"
-- 
2.28.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#144521): 
https://lists.openembedded.org/g/openembedded-core/message/144521
Mute This Topic: https://lists.openembedded.org/mt/78211641/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] [poky][master][PATCH] systemd: selinux hook handling to enumerate nexthop

[Purushottam choudhary]

Hi Richard,

Thanks for the confirmation.

Thanks & Regards,
Purushottam


From: openembedded-core@lists.openembedded.org 
 on behalf of Richard Purdie via 
lists.openembedded.org 

Sent: Thursday, November 12, 2020 6:26 PM
To: Purushottam Choudhary ; 
openembedded-core@lists.openembedded.org 
; raj.k...@gmail.com 

Cc: Nisha Parrakat ; Anuj Chougule 
; Aditya Tayade 
Subject: Re: [OE-core] [poky][master][PATCH] systemd: selinux hook handling to 
enumerate nexthop

On Thu, 2020-11-12 at 09:33 +, Purushottam choudhary wrote:
> Hi Openembedded/Khem,
>
> Is there any update on this patch?
>
> Could you please let me know?

Its merged in master?

https://apc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgit.yoctoproject.org%2Fcgit.cgi%2Fpoky%2Fcommit%2F%3Fid%3Dec37a2be661bbaa494455a5417db148495920039data=04%7C01%7Cpurushottam.choudhary%40kpit.com%7Cdb50284ca0484f529a0008d8870a60ff%7C3539451eb46e4a26a242ff61502855c7%7C0%7C0%7C637407825958213035%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=LburxF64bQEONDaryJB35DBr4bRLas6wg8GWudVOID0%3Dreserved=0

Cheers,

Richard

This message contains information that may be privileged or confidential and is 
the property of the KPIT Technologies Ltd. It is intended only for the person 
to whom it is addressed. If you are not the intended recipient, you are not 
authorized to read, print, retain copy, disseminate, distribute, or use this 
message or any part thereof. If you receive this message in error, please 
notify the sender immediately and delete all copies of this message. KPIT 
Technologies Ltd. does not accept any liability for virus infected mails.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#144525): 
https://lists.openembedded.org/g/openembedded-core/message/144525
Mute This Topic: https://lists.openembedded.org/mt/78026125/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 5/5] systemtap: split runtime material in its own package

[Yann Dirson]

From: Yann Dirson 

Note the _class-target qualifier, here to prevent a funky dependency of
systemtap-native on systemtap-native-runtime-native.  This possibly hints
to something deeper ?
---
 meta/lib/oeqa/selftest/cases/runtime_test.py   | 2 +-
 meta/recipes-kernel/systemtap/systemtap_git.bb | 9 +
 2 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/meta/lib/oeqa/selftest/cases/runtime_test.py 
b/meta/lib/oeqa/selftest/cases/runtime_test.py
index 1bb1c4bee4..7189e4e6c5 100644
--- a/meta/lib/oeqa/selftest/cases/runtime_test.py
+++ b/meta/lib/oeqa/selftest/cases/runtime_test.py
@@ -384,7 +384,7 @@ KERNEL_EXTRA_FEATURES_append = " 
features/debug/debug-kernel.scc"
 KERNEL_EXTRA_FEATURES_append = " features/systemtap/systemtap.scc"
 
 # add systemtap run-time into target image if it is not there yet
-IMAGE_INSTALL_append = " systemtap"
+IMAGE_INSTALL_append = " systemtap-runtime"
 """
 
 def test_crosstap_helloworld(self):
diff --git a/meta/recipes-kernel/systemtap/systemtap_git.bb 
b/meta/recipes-kernel/systemtap/systemtap_git.bb
index 74bf7cb35c..8dad5b15f0 100644
--- a/meta/recipes-kernel/systemtap/systemtap_git.bb
+++ b/meta/recipes-kernel/systemtap/systemtap_git.bb
@@ -36,6 +36,15 @@ FILES_${PN}-exporter = "${sysconfdir}/stap-exporter/* \
 RDEPENDS_${PN}-exporter = "${PN} python3-core python3-netclient"
 SYSTEMD_SERVICE_${PN}-exporter = "stap-exporter.service"
 
+PACKAGES =+ "${PN}-runtime"
+FILES_${PN}-runtime = "\
+ ${bindir}/staprun \
+ ${bindir}/stap-merge \
+ ${bindir}/stapsh \
+ ${libexecdir}/${BPN}/stapio \
+"
+RDEPENDS_${PN}_class-target += "${PN}-runtime"
+
 PACKAGES =+ "${PN}-examples"
 FILES_${PN}-examples = "${datadir}/${BPN}/examples/"
 RDEPENDS_${PN}-examples += "${PN}"
-- 
2.28.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#144523): 
https://lists.openembedded.org/g/openembedded-core/message/144523
Mute This Topic: https://lists.openembedded.org/mt/78211645/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 0/5] systemtap improvements

[Yann Dirson]

From: Yann Dirson 

The goal of this series is to make it possible to run compiled
systemtap probes on the target without all the tools otherwise
necessary to compile them.

This series also includes unrelated fixes to the systemtap packaging,
on which I stumbled while on the main subject.

Changes from v1:

* the last 3 patches, whole goal is to provide a systemtap.bbclass
  will be rerolled into another series later and were removed
* the "split runtime material" changes the runtime test to use the
  smaller runtime package


Yann Dirson (5):
  systemtap: split examples and python scripts out of main package
  systemtap: remove extra dependencies
  systemtap: clarify the relation between exporter and python3-probes
feature
  systemtap: fix install when python3-probes is disabled in
PACKAGECONFIG
  systemtap: split runtime material in its own package

 meta/lib/oeqa/selftest/cases/runtime_test.py  |  2 +-
 .../recipes-kernel/systemtap/systemtap_git.bb | 38 ---
 2 files changed, 33 insertions(+), 7 deletions(-)

-- 
2.28.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#144519): 
https://lists.openembedded.org/g/openembedded-core/message/144519
Mute This Topic: https://lists.openembedded.org/mt/78211639/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/5] systemtap: split examples and python scripts out of main package

[Yann Dirson]

From: Yann Dirson 

---
 meta/recipes-kernel/systemtap/systemtap_git.bb | 17 +
 1 file changed, 17 insertions(+)

diff --git a/meta/recipes-kernel/systemtap/systemtap_git.bb 
b/meta/recipes-kernel/systemtap/systemtap_git.bb
index 1c9f2aed16..e98aff1851 100644
--- a/meta/recipes-kernel/systemtap/systemtap_git.bb
+++ b/meta/recipes-kernel/systemtap/systemtap_git.bb
@@ -38,6 +38,23 @@ RDEPENDS_${PN}-exporter = "${PN} python3-core 
python3-netclient"
 
 SYSTEMD_SERVICE_${PN}-exporter = "stap-exporter.service"
 
+PACKAGES =+ "${PN}-examples"
+FILES_${PN}-examples = "${datadir}/${BPN}/examples/"
+RDEPENDS_${PN}-examples += "${PN}"
+
+# don't complain that some examples involve bash, perl, php...
+INSANE_SKIP_${PN}-examples += "file-rdeps"
+
+PACKAGES =+ "${PN}-python"
+FILES_${PN}-python += "\
+ ${bindir}/dtrace \
+ ${libdir}/python*/ \
+ ${libexecdir}/${BPN}/python/ \
+"
+# python material requires sdt headers
+RDEPENDS_${PN}-python += "${PN}-dev python3-core"
+INSANE_SKIP_${PN}-python += "dev-deps"
+
 do_configure_prepend () {
 # Improve reproducibility for c++ object files
 reltivepath="${@os.path.relpath(d.getVar('STAGING_INCDIR'), 
d.getVar('S'))}"
-- 
2.28.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#144520): 
https://lists.openembedded.org/g/openembedded-core/message/144520
Mute This Topic: https://lists.openembedded.org/mt/78211640/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 8/8] New systemtap.bb class, and systemtap-demo.bb to illustrate it.

[Bruce Ashfield]

On Thu, Nov 12, 2020 at 12:02 PM Yann Dirson
 wrote:
>
>
>
> Le mar. 22 sept. 2020 à 02:41, Bruce Ashfield  a 
> écrit :
>>
>> On Mon, Sep 21, 2020 at 6:51 PM Richard Purdie
>>  wrote:
>> >
>> > On Mon, 2020-09-21 at 23:23 +0200, Yann Dirson wrote:
>> > >
>> > >
>> > > Le lun. 21 sept. 2020 à 21:46, Richard Purdie <
>> > > richard.pur...@linuxfoundation.org> a écrit :
>> > > > On Mon, 2020-09-21 at 16:15 +0200, Yann Dirson wrote:
>> > > > > From: Yann Dirson 
>> > > > >
>> > > > > ---
>> > > > >  meta/classes/systemtap.bbclass| 74
>> > > > +++
>> > > > >  .../systemtap/systemtap-demo_git.bb   | 71
>> > > > ++
>> > > > >  2 files changed, 145 insertions(+)
>> > > > >  create mode 100644 meta/classes/systemtap.bbclass
>> > > > >  create mode 100644 meta/recipes-kernel/systemtap/systemtap-
>> > > > demo_git.bb
>> > > >
>> > > > I'm afraid this patch is going to throw warnings all over the
>> > > > autobuilder, e.g.:
>> > > >
>> > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/40/builds/2488
>> > > >
>> > > > (and there will be more).
>> > > >
>> > > > We are trying to ensure all warnings are solved so that any that do
>> > > > show are real issues and this patch would significantly distract
>> > > > from
>> > > > that.
>> > >
>> > > OK, we could default to built just the handful of probes that should
>> > > always build, and give instructions for those willing to use the
>> > > current behaviour.
>> >
>> > I think that is going to be safer and we could grow into more examples
>> > if/as/when we van build them.
>>
>> Also, as the person that usually picks up systemtap breakage first
>> on our new kernel versions .. we need to make sure that the reworked
>> recipe and class pass the oe-selftest for stap.
>
>
> AFAICT, if we exclude this last patch, the only impact on tests is that those
> testing modules with crosstap (which I only learnt about when looking for 
> those tests)
> and pulling the full systemtap package should be changed to pull 
> systemtap-runtime
> instead.
>
> Now adding tests for the modules built with systemtap.class is a different 
> thing.
>
>> It is doing on target compilation, so ideally, that test should be expanded
>> to test bot the cross and on-target variants.
>
>
> The on-target compilation is already tested by 
> meta/lib/oeqa/runtime/cases/stap.py,
> and there are crosstap tests in meta/lib/oeqa/selftest/cases/runtime_test.py.

I'm aware of that . I'm the one that runs them against most new kernels :D

Bruce

>
> I have started to look at adding a test for modules cross-built by 
> systemtap.bbclass,
> but as it takes ages to run those tests it seems it would make sense to move 
> this last
> patch into a series of its own.
>
>
>>
>>
>> Cheers,
>>
>> Bruce
>>
>> >
>> > >
>> > > > I'm also wary that we're now in feature freeze for release so
>> > > > perhaps
>> > > > these changes should wait until 3.3?
>> > >
>> > > OK, I can reroll a series with just the fixes.
>> >
>> > That would be great.
>> >
>> > > For the rest should I just wait for the gatesgarth branch to be
>> > > created and resubmit then ?
>> >
>> > Once we start taking new work on master, yes.
>> >
>> > Also, for a new recipe like this we need a maintainers entry, else we
>> > see:
>> >
>> > https://autobuilder.yoctoproject.org/typhoon/#/builders/80/builds/1377
>> >
>> > Cheers,
>> >
>> > Richard
>> >
>> >
>> >
>> > 
>> >
>>
>>
>> --
>> - Thou shalt not follow the NULL pointer, for chaos and madness await
>> thee at its end
>> - "Use the force Harry" - Gandalf, Star Trek II
>
>
>
> --
> Yann Dirson 
> Blade / Shadow -- http://shadow.tech
>


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

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#144518): 
https://lists.openembedded.org/g/openembedded-core/message/144518
Mute This Topic: https://lists.openembedded.org/mt/76990992/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] OE-core CVE metrics for dunfell on Sun 08 Nov 2020 07:30:01 AM HST

[Steve Sakoman]

On Thu, Nov 12, 2020 at 6:49 AM Sakib Sajal  wrote:

> I've triaged the qemu CVE's mentioned below, summary as follows:
>
> CVE-2015-8345 - CVE-2017-5957 all have fixes that are in qemu 4.2 used
> by dunfell.
>
> CVE-2018-12617 onwards have fixes but are introduced in qemu 5.[0 | 1]

Good to hear!  So a database update request for these CVE's would be
the next step.

I'll forward some sample update request emails off-list since you
haven't done this before.

> CVE's with proposed fixes are as follows:
>
> https://nvd.nist.gov/vuln/detail/CVE-2018-18438
> v1: https://lists.gnu.org/archive/html/qemu-devel/2018-10/msg02294.html
> v2: https://lists.gnu.org/archive/html/qemu-devel/2018-10/msg02396.html
>
> https://nvd.nist.gov/vuln/detail/CVE-2020-15859
> https://lists.gnu.org/archive/html/qemu-devel/2020-07/msg05304.html
> https://lists.gnu.org/archive/html/qemu-devel/2020-07/msg05341.html
>
> https://nvd.nist.gov/vuln/detail/CVE-2020-25742
> https://nvd.nist.gov/vuln/detail/CVE-2020-25743
> https://lists.nongnu.org/archive/html/qemu-devel/2020-09/msg07779.html
> https://lists.nongnu.org/archive/html/qemu-devel/2020-09/msg01568.html

Thanks for tracking down these fixes.  Do you plan to submit patches for them?

Thanks again for helping with CVE reduction!  I really appreciate the help.

Steve

> I have never sent database update requests, some examples will
> definitely be helpful.
>
> Sakib
>
> >> CVE-2012-4564: tiff 
> >> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-4564 *
> >> CVE-2012-6094: cups 
> >> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-6094 *
> >> CVE-2013-0800: cairo 
> >> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-0800 *
> >> CVE-2013-4235: shadow-native 
> >> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-4235 *
> >> CVE-2013-6629: ghostscript 
> >> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-6629 *
> >> CVE-2013-7381: libnotify 
> >> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-7381 *
> >> CVE-2014-9278: openssh 
> >> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-9278 *
> >> CVE-2015-7313: tiff 
> >> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-7313 *
> >> CVE-2015-8345: qemu 
> >> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-8345 *
> >> CVE-2015-8619: qemu 
> >> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-8619 *
> >> CVE-2016-4002: qemu 
> >> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-4002 *
> >> CVE-2016-4614: libxml2 
> >> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-4614 *
> >> CVE-2016-6328: libexif 
> >> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-6328 *
> >> CVE-2016-6489: nettle 
> >> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-6489 *
> >> CVE-2016-9101: qemu 
> >> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-9101 *
> >> CVE-2016-9596: libxml2 
> >> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-9596 *
> >> CVE-2016-9598: libxml2 
> >> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-9598 *
> >> CVE-2016-9907: qemu 
> >> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-9907 *
> >> CVE-2016-9908: qemu 
> >> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-9908 *
> >> CVE-2016-9911: qemu 
> >> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-9911 *
> >> CVE-2016-9912: qemu 
> >> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-9912 *
> >> CVE-2016-9921: qemu 
> >> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-9921 *
> >> CVE-2016-9923: qemu 
> >> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-9923 *
> >> CVE-2017-3139: bind 
> >> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2017-3139 *
> >> CVE-2017-5957: qemu 
> >> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2017-5957 *
> >> CVE-2018-141: librsvg 
> >> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2018-141 *
> >> CVE-2018-12433: libgcrypt 
> >> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2018-12433 *
> >> CVE-2018-12437: libgcrypt 
> >> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2018-12437 *
> >> CVE-2018-12438: libgcrypt 
> >> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2018-12438 *
> >> CVE-2018-12617: qemu 
> >> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2018-12617 *
> >> CVE-2018-13410: zip 
> >> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2018-13410 *
> >> CVE-2018-13684: zip 
> >> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2018-13684 *
> >> CVE-2018-16517: nasm-native 
> >> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2018-16517 *
> >> CVE-2018-16868: gnutls 
> >> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2018-16868 *
> >> CVE-2018-16869: nettle 
> >> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2018-16869 *
> >> CVE-2018-18438: qemu 
> >> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2018-18438 *
> >> CVE-2018-19665: qemu 
> >> 

Re: [OE-core] [PATCH 8/8] New systemtap.bb class, and systemtap-demo.bb to illustrate it.

[Yann Dirson]

Le mar. 22 sept. 2020 à 02:41, Bruce Ashfield  a
écrit :

> On Mon, Sep 21, 2020 at 6:51 PM Richard Purdie
>  wrote:
> >
> > On Mon, 2020-09-21 at 23:23 +0200, Yann Dirson wrote:
> > >
> > >
> > > Le lun. 21 sept. 2020 à 21:46, Richard Purdie <
> > > richard.pur...@linuxfoundation.org> a écrit :
> > > > On Mon, 2020-09-21 at 16:15 +0200, Yann Dirson wrote:
> > > > > From: Yann Dirson 
> > > > >
> > > > > ---
> > > > >  meta/classes/systemtap.bbclass| 74
> > > > +++
> > > > >  .../systemtap/systemtap-demo_git.bb   | 71
> > > > ++
> > > > >  2 files changed, 145 insertions(+)
> > > > >  create mode 100644 meta/classes/systemtap.bbclass
> > > > >  create mode 100644 meta/recipes-kernel/systemtap/systemtap-
> > > > demo_git.bb
> > > >
> > > > I'm afraid this patch is going to throw warnings all over the
> > > > autobuilder, e.g.:
> > > >
> > > >
> https://autobuilder.yoctoproject.org/typhoon/#/builders/40/builds/2488
> > > >
> > > > (and there will be more).
> > > >
> > > > We are trying to ensure all warnings are solved so that any that do
> > > > show are real issues and this patch would significantly distract
> > > > from
> > > > that.
> > >
> > > OK, we could default to built just the handful of probes that should
> > > always build, and give instructions for those willing to use the
> > > current behaviour.
> >
> > I think that is going to be safer and we could grow into more examples
> > if/as/when we van build them.
>
> Also, as the person that usually picks up systemtap breakage first
> on our new kernel versions .. we need to make sure that the reworked
> recipe and class pass the oe-selftest for stap.
>

AFAICT, if we exclude this last patch, the only impact on tests is that
those
testing modules with crosstap (which I only learnt about when looking for
those tests)
and pulling the full systemtap package should be changed to pull
systemtap-runtime
instead.

Now adding tests for the modules built with systemtap.class is a different
thing.

It is doing on target compilation, so ideally, that test should be expanded
> to test bot the cross and on-target variants.
>

The on-target compilation is already tested by
meta/lib/oeqa/runtime/cases/stap.py,
and there are crosstap tests in
meta/lib/oeqa/selftest/cases/runtime_test.py.

I have started to look at adding a test for modules cross-built by
systemtap.bbclass,
but as it takes ages to run those tests it seems it would make sense to
move this last
patch into a series of its own.



>
> Cheers,
>
> Bruce
>
> >
> > >
> > > > I'm also wary that we're now in feature freeze for release so
> > > > perhaps
> > > > these changes should wait until 3.3?
> > >
> > > OK, I can reroll a series with just the fixes.
> >
> > That would be great.
> >
> > > For the rest should I just wait for the gatesgarth branch to be
> > > created and resubmit then ?
> >
> > Once we start taking new work on master, yes.
> >
> > Also, for a new recipe like this we need a maintainers entry, else we
> > see:
> >
> > https://autobuilder.yoctoproject.org/typhoon/#/builders/80/builds/1377
> >
> > Cheers,
> >
> > Richard
> >
> >
> >
> > 
> >
>
>
> --
> - Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end
> - "Use the force Harry" - Gandalf, Star Trek II
>


-- 
Yann Dirson 
Blade / Shadow -- http://shadow.tech

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#144516): 
https://lists.openembedded.org/g/openembedded-core/message/144516
Mute This Topic: https://lists.openembedded.org/mt/76990992/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 0/2] Make rt-tests buildable for all architectures

[Khem Raj]

On Wed, Nov 11, 2020 at 11:35 PM Peter Bergin  wrote:
>
> Hi Khem,
>
> On 2020-11-12 02:33, Khem Raj wrote:
> > this seems to improve the situation but its not clear if arches
> > without frc() will now fail miserably at runtime or will it only fail
> > a subset of tests and rt-tests will still be largely useful for such
> > arches. In the latter case, I am fine with this series.
>
> oslat is a newly added (in v1.9) test to rt-tests and is just one of
> many tests in the suite. With this patch the oslat application will fail
> with an error message to stdout.
>
>  #ifdef FRC_MISSING
>  printf("This architecture is not yet supported. "
> "Please implement frc() function first for %s.\n", argv[0]);
>  return 0;
>  #endif
>
> I searched rt-tests repo for other usages of frc() but it is isolated
> and only used in src/oslat/oslat.c. With this patch others tests in the
> rt-tests suite can be built and run on other architectures and it would
> be helpful to get it in to oe-core to be able to run, for example,
> cyclictest on arm64.
>

thanks Peter, seems fine to me then

> Best regards,
> /Peter
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#144515): 
https://lists.openembedded.org/g/openembedded-core/message/144515
Mute This Topic: https://lists.openembedded.org/mt/78194428/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] OE-core CVE metrics for dunfell on Sun 08 Nov 2020 07:30:01 AM HST

[Sakib Sajal]

On 2020-11-09 2:57 p.m., Steve Sakoman wrote:

[Please note this e-mail is from an EXTERNAL e-mail address]

On Mon, Nov 9, 2020 at 8:36 AM Sakib Sajal  wrote:


On 2020-11-08 12:34 p.m., Steve Sakoman wrote:

[Please note this e-mail is from an EXTERNAL e-mail address]

Branch: dunfell

New this week:
CVE-2020-27619: python3-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-27619 *

Removed this week:
CVE-2019-20175: qemu 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2019-20175 *
CVE-2019-20334: nasm-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2019-20334 *
CVE-2019-6290: nasm-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2019-6290 *
CVE-2019-6291: nasm-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2019-6291 *
CVE-2019-8343: nasm-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2019-8343 *

Full list:  Found 86 unpatched CVEs

I will look after the qemu CVE's from CVE-2015-8345 and onwards.

Thanks Sakib.  I appreciate all the help I can get!

Note that many of these are matching due to the CPE wildcard entry
matching all versions.

So the CVEs may be fixed in recent qemu versions and all that is
required is a request to the CPE maintainer to update the wildcard.

But some research will be required to see if this is the case.  If so
an email to the maintainer can get this corrected.

I've already done many where the fixes were somewhat easy to locate.
The remaining ones will require varying levels of effort.

If you haven't sent database update requests before let me know and
I'll send you some examples.

Steve


I've triaged the qemu CVE's mentioned below, summary as follows:

CVE-2015-8345 - CVE-2017-5957 all have fixes that are in qemu 4.2 used 
by dunfell.


CVE-2018-12617 onwards have fixes but are introduced in qemu 5.[0 | 1]

CVE's with proposed fixes are as follows:

https://nvd.nist.gov/vuln/detail/CVE-2018-18438
v1: https://lists.gnu.org/archive/html/qemu-devel/2018-10/msg02294.html
v2: https://lists.gnu.org/archive/html/qemu-devel/2018-10/msg02396.html

https://nvd.nist.gov/vuln/detail/CVE-2020-15859
https://lists.gnu.org/archive/html/qemu-devel/2020-07/msg05304.html
https://lists.gnu.org/archive/html/qemu-devel/2020-07/msg05341.html

https://nvd.nist.gov/vuln/detail/CVE-2020-25742
https://nvd.nist.gov/vuln/detail/CVE-2020-25743
https://lists.nongnu.org/archive/html/qemu-devel/2020-09/msg07779.html
https://lists.nongnu.org/archive/html/qemu-devel/2020-09/msg01568.html

I have never sent database update requests, some examples will 
definitely be helpful.


Sakib


CVE-2012-4564: tiff 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-4564 *
CVE-2012-6094: cups 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-6094 *
CVE-2013-0800: cairo 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-0800 *
CVE-2013-4235: shadow-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-4235 *
CVE-2013-6629: ghostscript 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-6629 *
CVE-2013-7381: libnotify 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-7381 *
CVE-2014-9278: openssh 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-9278 *
CVE-2015-7313: tiff 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-7313 *
CVE-2015-8345: qemu 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-8345 *
CVE-2015-8619: qemu 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-8619 *
CVE-2016-4002: qemu 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-4002 *
CVE-2016-4614: libxml2 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-4614 *
CVE-2016-6328: libexif 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-6328 *
CVE-2016-6489: nettle 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-6489 *
CVE-2016-9101: qemu 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-9101 *
CVE-2016-9596: libxml2 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-9596 *
CVE-2016-9598: libxml2 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-9598 *
CVE-2016-9907: qemu 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-9907 *
CVE-2016-9908: qemu 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-9908 *
CVE-2016-9911: qemu 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-9911 *
CVE-2016-9912: qemu 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-9912 *
CVE-2016-9921: qemu 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-9921 *
CVE-2016-9923: qemu 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-9923 *
CVE-2017-3139: bind 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2017-3139 *
CVE-2017-5957: qemu 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2017-5957 *
CVE-2018-141: librsvg 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2018-141 *
CVE-2018-12433: libgcrypt 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2018-12433 *
CVE-2018-12437: 

Re: [OE-core] devtool modify - ModuleNotFoundError: No module named '_sysconfigdata'

[Alexander Kanavin]

I have just seen it first-hand for the first time. It happens on Ubuntu
20.04, but not on for example OpenSuse tumbleweed. So something in Ubuntu
causes the native python environment to leak into the host python
environment. Will investigate.

Alex

On Thu, 12 Nov 2020 at 13:59, Peter Bergin  wrote:

> Hi Alex,
>
> On 2020-11-12 12:38, Alexander Kanavin wrote:
> > If you can provide exact steps to reproduce (the recipe is not
> > available in oe-core), I can take a look. It's been reported plenty of
> > times, but always with something not in core and not easily available.
>
> here are the steps to reproduce with only poky. I hope it can help you
> find the root cause:
>
>  $ git clone https://git.yoctoproject.org/git/poky sources/poky
>  $ . ./sources/poky/oe-init-build-env
>  $ echo 'MACHINE = "qemuarm64"' >> conf/auto.conf
>  $ devtool modify u-boot
>
> And here is the output on my machine:
>
>  Build Configuration:
>  BB_VERSION   = "1.49.0"
>  BUILD_SYS= "x86_64-linux"
>  NATIVELSBSTRING  = "ubuntu-20.04"
>  TARGET_SYS   = "aarch64-poky-linux"
>  MACHINE  = "qemuarm64"
>  DISTRO   = "poky"
>  DISTRO_VERSION   = "3.2+snapshot-20201112"
>  TUNE_FEATURES= "aarch64 armv8a crc cortexa57"
>  TARGET_FPU   = ""
>  meta
>  meta-poky
>  meta-yocto-bsp   =
> "master:e949e76d0f6897ec5d4feaa47afd2b049b32707f"
>  workspace= ":"
>
>  Initialising tasks: 100%
> |###| Time: 0:00:00
>  Sstate summary: Wanted 20 Found 20 Missed 0 Current 0 (100% match,
> 0% complete)
>  NOTE: Executing Tasks
>  ERROR: Error executing a python function in exec_python_func()
> autogenerated:
>
>  The stack trace of python calls that resulted in this
> exception/failure was:
>  File: 'exec_python_func() autogenerated', lineno: 2, function:
> 
>   0001:
>   *** 0002:devtool_post_unpack(d)
>   0003:
>  File:
> '/work/yocto/devtool-reproduce2/sources/poky/meta/classes/devtool-source.bbclass',
>
> lineno: 68, function: devtool_post_unpack
>   0064:}
>   0065:
>   0066:
>   0067:python devtool_post_unpack() {
>   *** 0068:import oe.recipeutils
>   0069:import shutil
>   0070:sys.path.insert(0, os.path.join(d.getVar('COREBASE'),
> 'scripts', 'lib'))
>   0071:import scriptutils
>   0072:from devtool import setup_git_repo
>  File:
> '/work/yocto/devtool-reproduce2/sources/poky/meta/lib/oe/recipeutils.py',
> lineno: 21, function: 
>   0017:import shutil
>   0018:import re
>   0019:import fnmatch
>   0020:import glob
>   *** 0021:import bb.tinfoil
>   0022:
>   0023:from collections import OrderedDict, defaultdict
>   0024:from bb.utils import vercmp_string
>   0025:
>  File:
> '/work/yocto/devtool-reproduce2/sources/poky/bitbake/lib/bb/tinfoil.py',
> lineno: 19, function: 
>   0015:from collections import OrderedDict, defaultdict
>   0016:from functools import partial
>   0017:
>   0018:import bb.cache
>   *** 0019:import bb.cooker
>   0020:import bb.providers
>   0021:import bb.taskdata
>   0022:import bb.utils
>   0023:import bb.command
>  File:
> '/work/yocto/devtool-reproduce2/sources/poky/bitbake/lib/bb/cooker.py',
> lineno: 25, function: 
>   0021:import bb, bb.exceptions, bb.command
>   0022:from bb import utils, data, parse, event, cache,
> providers, taskdata, runqueue, build
>   0023:import queue
>   0024:import signal
>   *** 0025:import prserv.serv
>   0026:import pyinotify
>   0027:import json
>   0028:import pickle
>   0029:import codecs
>  File:
> '/work/yocto/devtool-reproduce2/sources/poky/bitbake/lib/prserv/serv.py',
> lineno: 7, function: 
>   0003:#
>   0004:
>   0005:import os,sys,logging
>   0006:import signal, time
>   *** 0007:from xmlrpc.server import SimpleXMLRPCServer,
> SimpleXMLRPCRequestHandler
>   0008:import threading
>   0009:import queue
>   0010:import socket
>   0011:import io
>  File: '/usr/lib/python3.8/xmlrpc/server.py', lineno: 117, function:
> 
>   0113:import socketserver
>   0114

[OE-core] [PATCH] layer.conf: fix syntax error in PATH setting

[Matt Madison]

Commit 05a87be51b44608ce4f77ac332df90a3cd2445ef introduced
a Python conditional expression when updating PATH that
generates syntax warnings in bitbake-cookerdaemon.log:

  Var :1: SyntaxWarning: "is not" with a literal. Did you mean "!="?

Fix this by using the more appropriate '!=' comparison
operator.

Signed-off-by: Matt Madison 
---
 meta/conf/layer.conf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/conf/layer.conf b/meta/conf/layer.conf
index 2d9cd05695..cda37c33b4 100644
--- a/meta/conf/layer.conf
+++ b/meta/conf/layer.conf
@@ -104,4 +104,4 @@ SSTATE_EXCLUDEDEPS_SYSROOT += ".*->autoconf-archive-native"
 # We need to keep bitbake tools in PATH
 # Avoid empty path entries
 BITBAKEPATH := 
"${@os.path.dirname(bb.utils.which(d.getVar('PATH'),'bitbake'))}"
-PATH := "${@'${BITBAKEPATH}:' if '${BITBAKEPATH}' is not '' else 
''}${HOSTTOOLS_DIR}"
+PATH := "${@'${BITBAKEPATH}:' if '${BITBAKEPATH}' != '' else 
''}${HOSTTOOLS_DIR}"
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#144512): 
https://lists.openembedded.org/g/openembedded-core/message/144512
Mute This Topic: https://lists.openembedded.org/mt/78207716/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] devtool modify - ModuleNotFoundError: No module named '_sysconfigdata'

[Peter Bergin]

Hi Alex,

On 2020-11-12 12:38, Alexander Kanavin wrote:
If you can provide exact steps to reproduce (the recipe is not 
available in oe-core), I can take a look. It's been reported plenty of 
times, but always with something not in core and not easily available.


here are the steps to reproduce with only poky. I hope it can help you 
find the root cause:


    $ git clone https://git.yoctoproject.org/git/poky sources/poky
    $ . ./sources/poky/oe-init-build-env
    $ echo 'MACHINE = "qemuarm64"' >> conf/auto.conf
    $ devtool modify u-boot

And here is the output on my machine:

    Build Configuration:
    BB_VERSION   = "1.49.0"
    BUILD_SYS    = "x86_64-linux"
    NATIVELSBSTRING  = "ubuntu-20.04"
    TARGET_SYS   = "aarch64-poky-linux"
    MACHINE  = "qemuarm64"
    DISTRO       = "poky"
    DISTRO_VERSION   = "3.2+snapshot-20201112"
    TUNE_FEATURES    = "aarch64 armv8a crc cortexa57"
    TARGET_FPU   = ""
    meta
    meta-poky
    meta-yocto-bsp   = 
"master:e949e76d0f6897ec5d4feaa47afd2b049b32707f"

    workspace    = ":"

    Initialising tasks: 100% 
|###| Time: 0:00:00
    Sstate summary: Wanted 20 Found 20 Missed 0 Current 0 (100% match, 
0% complete)

    NOTE: Executing Tasks
    ERROR: Error executing a python function in exec_python_func() 
autogenerated:


    The stack trace of python calls that resulted in this 
exception/failure was:

    File: 'exec_python_func() autogenerated', lineno: 2, function: 
     0001:
 *** 0002:devtool_post_unpack(d)
         0003:
    File: 
'/work/yocto/devtool-reproduce2/sources/poky/meta/classes/devtool-source.bbclass', 
lineno: 68, function: devtool_post_unpack

     0064:}
         0065:
         0066:
         0067:python devtool_post_unpack() {
 *** 0068:    import oe.recipeutils
         0069:    import shutil
         0070:    sys.path.insert(0, os.path.join(d.getVar('COREBASE'), 
'scripts', 'lib'))

         0071:    import scriptutils
         0072:    from devtool import setup_git_repo
    File: 
'/work/yocto/devtool-reproduce2/sources/poky/meta/lib/oe/recipeutils.py', 
lineno: 21, function: 

         0017:import shutil
         0018:import re
         0019:import fnmatch
         0020:import glob
 *** 0021:import bb.tinfoil
         0022:
         0023:from collections import OrderedDict, defaultdict
         0024:from bb.utils import vercmp_string
         0025:
    File: 
'/work/yocto/devtool-reproduce2/sources/poky/bitbake/lib/bb/tinfoil.py', 
lineno: 19, function: 

         0015:from collections import OrderedDict, defaultdict
         0016:from functools import partial
         0017:
         0018:import bb.cache
 *** 0019:import bb.cooker
         0020:import bb.providers
         0021:import bb.taskdata
         0022:import bb.utils
         0023:import bb.command
    File: 
'/work/yocto/devtool-reproduce2/sources/poky/bitbake/lib/bb/cooker.py', 
lineno: 25, function: 

         0021:import bb, bb.exceptions, bb.command
         0022:from bb import utils, data, parse, event, cache, 
providers, taskdata, runqueue, build

         0023:import queue
         0024:import signal
 *** 0025:import prserv.serv
         0026:import pyinotify
         0027:import json
         0028:import pickle
         0029:import codecs
    File: 
'/work/yocto/devtool-reproduce2/sources/poky/bitbake/lib/prserv/serv.py', 
lineno: 7, function: 

         0003:#
         0004:
         0005:import os,sys,logging
         0006:import signal, time
 *** 0007:from xmlrpc.server import SimpleXMLRPCServer, 
SimpleXMLRPCRequestHandler

         0008:import threading
         0009:import queue
         0010:import socket
         0011:import io
    File: '/usr/lib/python3.8/xmlrpc/server.py', lineno: 117, function: 


         0113:import socketserver
         0114:import sys
         0115:import os
         0116:import re
 *** 0117:import pydoc
         0118:import traceback
         0119:try:
         0120:    import fcntl
         0121:except ImportError:
    File: '/usr/lib/python3.8/pydoc.py', lineno: 370, function: 
         0366:    return module
         0367:
         0368:#  
formatter base class

         0369:
 *** 0370:class Doc:
         0371:
         0372:    PYTHONDOCS = os.environ.get("PYTHONDOCS",
         0373: "https://docs.python.org/%d.%d/library;
         0374:    % sys.version_info[:2])
    File: '/usr/lib/python3.8/pydoc.py', lineno: 400, function: Doc
         0396:    raise TypeError(message)
         0397:
         0398:    docmodule = docclass = docroutine = docother = 
docproperty = docdata = fail

         0399:
 *** 0400:    def getdoclo

Re: [OE-core] [poky][master][PATCH] systemd: selinux hook handling to enumerate nexthop

[Richard Purdie]

On Thu, 2020-11-12 at 09:33 +, Purushottam choudhary wrote:
> Hi Openembedded/Khem,
> 
> Is there any update on this patch?
> 
> Could you please let me know?

Its merged in master?

http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=ec37a2be661bbaa494455a5417db148495920039

Cheers,

Richard


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#144510): 
https://lists.openembedded.org/g/openembedded-core/message/144510
Mute This Topic: https://lists.openembedded.org/mt/78026125/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] devtool modify - ModuleNotFoundError: No module named '_sysconfigdata'

[Martin Jansa]

Breaking host python in ubuntu 18.04-20.10 like this is very easy, just
exporting _PYTHON_SYSCONFIGDATA_NAME like OE tasks do is enough.

I can reproduce it e.g. with command_not_found_handle in ubuntu:

$ export _PYTHON_SYSCONFIGDATA_NAME="_sysconfigdata"
$ command_not_found_handle foo
Failed to import the site module
Traceback (most recent call last):
  File "/usr/lib/python3.6/site.py", line 570, in 
main()
  File "/usr/lib/python3.6/site.py", line 556, in main
known_paths = addusersitepackages(known_paths)
  File "/usr/lib/python3.6/site.py", line 288, in addusersitepackages
user_site = getusersitepackages()
  File "/usr/lib/python3.6/site.py", line 264, in getusersitepackages
user_base = getuserbase() # this will also set USER_BASE
  File "/usr/lib/python3.6/site.py", line 254, in getuserbase
USER_BASE = get_config_var('userbase')
  File "/usr/lib/python3.6/sysconfig.py", line 607, in get_config_var
return get_config_vars().get(name)
  File "/usr/lib/python3.6/sysconfig.py", line 550, in get_config_vars
_init_posix(_CONFIG_VARS)
  File "/usr/lib/python3.6/sysconfig.py", line 421, in _init_posix
_temp = __import__(name, globals(), locals(), ['build_time_vars'], 0)
ModuleNotFoundError: No module named '_sysconfigdata'

$ unset _PYTHON_SYSCONFIGDATA_NAME
$ command_not_found_handle foo

Command 'foo' not found, did you mean:

  command 'fox' from deb objcryst-fox
  command 'fio' from deb fio
  command 'goo' from deb goo
  command 'fop' from deb fop
  command 'fog' from deb ruby-fog
  command 'woo' from deb python-woo
  command 'fgo' from deb fgo

Try: sudo apt install 

So whenever _PYTHON_SYSCONFIGDATA_NAME is exported you need to ensure that
you're exclusively using python from python3native any call from this
environment to host python (other than  python3 --version: Python 3.6.9).
With 20.04 it's usually more common to see, because default python on host
will be most likely python3 not python2 which doesn't have this issue.

On Thu, Nov 12, 2020 at 12:38 PM Alexander Kanavin 
wrote:

> If you can provide exact steps to reproduce (the recipe is not available
> in oe-core), I can take a look. It's been reported plenty of times, but
> always with something not in core and not easily available.
>
> Alex
>
> On Thu, 12 Nov 2020 at 12:07,  wrote:
>
>> Here are two other threads on the same topic. I've also run into this.
>>
>> https://lists.yoctoproject.org/g/yocto/topic/74637733#51189
>>
>> and
>>
>>
>> https://lists.yoctoproject.org/g/yocto/message/50856?p=,,,20,0,0,0::Created,,devtool,20,2,0,77178360
>>
>> Regards
>> //Ernst
>>
>>
>>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#144509): 
https://lists.openembedded.org/g/openembedded-core/message/144509
Mute This Topic: https://lists.openembedded.org/mt/78203937/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] oe-buildenv-internal: Support extra settings

[Robert Yang]

On 11/12/20 7:47 PM, Andreas Oberritter wrote:

On Thu, 12 Nov 2020 19:32:59 +0800
Robert Yang  wrote:


Hi Andreas,

On 11/12/20 7:24 PM, Andreas Oberritter wrote:

Dear Robert,

On Thu, 12 Nov 2020 19:25:49 +0800
"Robert Yang"  wrote:


This can make it possible to do extra settings such as PATH for other layers,
for exampole, other layers may also have scripts directories as oe-core, we
have to run them with path since they are not in PATH, for example, there is a
tool meta-browser/scripts/firefox-gen-l10n-recipes, we have to use
/path/to/meta-browser/scripts to run it. Make oe-buildenv-internal check and
enable $OEROOT/extrasettings, and set a line like the following can fix the
problem:

PATH=/relative/to/$OEROOT/meta-browser/scripts:$PATH

Signed-off-by: Robert Yang 
---
   scripts/oe-buildenv-internal | 4 
   1 file changed, 4 insertions(+)

diff --git a/scripts/oe-buildenv-internal b/scripts/oe-buildenv-internal
index ba0a9b44d6..bf84003d72 100755
--- a/scripts/oe-buildenv-internal
+++ b/scripts/oe-buildenv-internal
@@ -98,6 +98,10 @@ for newpath in "$BITBAKEDIR/bin" "$OEROOT/scripts"; do
   done
   unset BITBAKEDIR newpath
   
+if [ -e $OEROOT/extrasettings ]; then

+. $OEROOT/extrasettings
+fi


I think this filename isn't very descriptive, and people finding this file 
might wonder what it is about.


There is no such a file by default, the file should be created by other layers
or people out of oe-core.



How about sourcing all files (maybe with a given suffix like .sh) in 
$OEROOT/scripts/oe-buildenv-internal.d/ in lexical order?


If we do this, people need to patch oe-core/scripts/oe-buildenv-internal.d/ to
add their own settings, and oe-core can't accept such customization patches,
then it would make their oe-core repo non-fastword because of the local patches,
so I'm afraid that we can't do this.


The same restrictions apply to $OEROOT/extrasettings.


There is a slightly different, if make a symlink outside of oe-core
to oe-init-build-env, then the symlink's dir will be used as OEROOT:

if [ -z "$OEROOT" ]; then
OEROOT=$(dirname "$THIS_SCRIPT")
OEROOT=$(readlink -f "$OEROOT")
fi

So $OEROOT/extrasettings can be in the symlink's directory which is out of
oe-core, but '$OEROOT/scripts' can't since it conflicts with oe-core/scripts,
another directory such as $OEROOT/oe-buildenv-internal.d/ should work.

// Robert




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#144508): 
https://lists.openembedded.org/g/openembedded-core/message/144508
Mute This Topic: https://lists.openembedded.org/mt/78204025/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] oe-buildenv-internal: Support extra settings

[Andreas Oberritter]

On Thu, 12 Nov 2020 19:32:59 +0800
Robert Yang  wrote:

> Hi Andreas,
> 
> On 11/12/20 7:24 PM, Andreas Oberritter wrote:
> > Dear Robert,
> > 
> > On Thu, 12 Nov 2020 19:25:49 +0800
> > "Robert Yang"  wrote:
> > 
> >> This can make it possible to do extra settings such as PATH for other 
> >> layers,
> >> for exampole, other layers may also have scripts directories as oe-core, we
> >> have to run them with path since they are not in PATH, for example, there 
> >> is a
> >> tool meta-browser/scripts/firefox-gen-l10n-recipes, we have to use
> >> /path/to/meta-browser/scripts to run it. Make oe-buildenv-internal check 
> >> and
> >> enable $OEROOT/extrasettings, and set a line like the following can fix the
> >> problem:
> >>
> >> PATH=/relative/to/$OEROOT/meta-browser/scripts:$PATH
> >>
> >> Signed-off-by: Robert Yang 
> >> ---
> >>   scripts/oe-buildenv-internal | 4 
> >>   1 file changed, 4 insertions(+)
> >>
> >> diff --git a/scripts/oe-buildenv-internal b/scripts/oe-buildenv-internal
> >> index ba0a9b44d6..bf84003d72 100755
> >> --- a/scripts/oe-buildenv-internal
> >> +++ b/scripts/oe-buildenv-internal
> >> @@ -98,6 +98,10 @@ for newpath in "$BITBAKEDIR/bin" "$OEROOT/scripts"; do
> >>   done
> >>   unset BITBAKEDIR newpath
> >>   
> >> +if [ -e $OEROOT/extrasettings ]; then
> >> +. $OEROOT/extrasettings
> >> +fi
> > 
> > I think this filename isn't very descriptive, and people finding this file 
> > might wonder what it is about.
> 
> There is no such a file by default, the file should be created by other layers
> or people out of oe-core.
> 
> > 
> > How about sourcing all files (maybe with a given suffix like .sh) in 
> > $OEROOT/scripts/oe-buildenv-internal.d/ in lexical order?
> 
> If we do this, people need to patch oe-core/scripts/oe-buildenv-internal.d/ to
> add their own settings, and oe-core can't accept such customization patches,
> then it would make their oe-core repo non-fastword because of the local 
> patches,
> so I'm afraid that we can't do this.

The same restrictions apply to $OEROOT/extrasettings.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#144507): 
https://lists.openembedded.org/g/openembedded-core/message/144507
Mute This Topic: https://lists.openembedded.org/mt/78204025/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] devtool modify - ModuleNotFoundError: No module named '_sysconfigdata'

[Alexander Kanavin]

If you can provide exact steps to reproduce (the recipe is not available in
oe-core), I can take a look. It's been reported plenty of times, but always
with something not in core and not easily available.

Alex

On Thu, 12 Nov 2020 at 12:07,  wrote:

> Here are two other threads on the same topic. I've also run into this.
>
> https://lists.yoctoproject.org/g/yocto/topic/74637733#51189
>
> and
>
>
> https://lists.yoctoproject.org/g/yocto/message/50856?p=,,,20,0,0,0::Created,,devtool,20,2,0,77178360
>
> Regards
> //Ernst
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#144506): 
https://lists.openembedded.org/g/openembedded-core/message/144506
Mute This Topic: https://lists.openembedded.org/mt/78203937/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] oe-buildenv-internal: Support extra settings

[Robert Yang]

Hi Andreas,

On 11/12/20 7:24 PM, Andreas Oberritter wrote:

Dear Robert,

On Thu, 12 Nov 2020 19:25:49 +0800
"Robert Yang"  wrote:


This can make it possible to do extra settings such as PATH for other layers,
for exampole, other layers may also have scripts directories as oe-core, we
have to run them with path since they are not in PATH, for example, there is a
tool meta-browser/scripts/firefox-gen-l10n-recipes, we have to use
/path/to/meta-browser/scripts to run it. Make oe-buildenv-internal check and
enable $OEROOT/extrasettings, and set a line like the following can fix the
problem:

PATH=/relative/to/$OEROOT/meta-browser/scripts:$PATH

Signed-off-by: Robert Yang 
---
  scripts/oe-buildenv-internal | 4 
  1 file changed, 4 insertions(+)

diff --git a/scripts/oe-buildenv-internal b/scripts/oe-buildenv-internal
index ba0a9b44d6..bf84003d72 100755
--- a/scripts/oe-buildenv-internal
+++ b/scripts/oe-buildenv-internal
@@ -98,6 +98,10 @@ for newpath in "$BITBAKEDIR/bin" "$OEROOT/scripts"; do
  done
  unset BITBAKEDIR newpath
  
+if [ -e $OEROOT/extrasettings ]; then

+. $OEROOT/extrasettings
+fi


I think this filename isn't very descriptive, and people finding this file 
might wonder what it is about.


There is no such a file by default, the file should be created by other layers
or people out of oe-core.



How about sourcing all files (maybe with a given suffix like .sh) in 
$OEROOT/scripts/oe-buildenv-internal.d/ in lexical order?


If we do this, people need to patch oe-core/scripts/oe-buildenv-internal.d/ to
add their own settings, and oe-core can't accept such customization patches,
then it would make their oe-core repo non-fastword because of the local patches,
so I'm afraid that we can't do this.

// Robert



Regards,
Andreas


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#144505): 
https://lists.openembedded.org/g/openembedded-core/message/144505
Mute This Topic: https://lists.openembedded.org/mt/78204025/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] oe-buildenv-internal: Support extra settings

[Andreas Oberritter]

Dear Robert,

On Thu, 12 Nov 2020 19:25:49 +0800
"Robert Yang"  wrote:

> This can make it possible to do extra settings such as PATH for other layers,
> for exampole, other layers may also have scripts directories as oe-core, we
> have to run them with path since they are not in PATH, for example, there is a
> tool meta-browser/scripts/firefox-gen-l10n-recipes, we have to use
> /path/to/meta-browser/scripts to run it. Make oe-buildenv-internal check and
> enable $OEROOT/extrasettings, and set a line like the following can fix the
> problem:
> 
> PATH=/relative/to/$OEROOT/meta-browser/scripts:$PATH
> 
> Signed-off-by: Robert Yang 
> ---
>  scripts/oe-buildenv-internal | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/scripts/oe-buildenv-internal b/scripts/oe-buildenv-internal
> index ba0a9b44d6..bf84003d72 100755
> --- a/scripts/oe-buildenv-internal
> +++ b/scripts/oe-buildenv-internal
> @@ -98,6 +98,10 @@ for newpath in "$BITBAKEDIR/bin" "$OEROOT/scripts"; do
>  done
>  unset BITBAKEDIR newpath
>  
> +if [ -e $OEROOT/extrasettings ]; then
> +. $OEROOT/extrasettings
> +fi

I think this filename isn't very descriptive, and people finding this file 
might wonder what it is about.

How about sourcing all files (maybe with a given suffix like .sh) in 
$OEROOT/scripts/oe-buildenv-internal.d/ in lexical order?

Regards,
Andreas

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#144504): 
https://lists.openembedded.org/g/openembedded-core/message/144504
Mute This Topic: https://lists.openembedded.org/mt/78204025/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] oe-buildenv-internal: Support extra settings

[Robert Yang]

This can make it possible to do extra settings such as PATH for other layers,
for exampole, other layers may also have scripts directories as oe-core, we
have to run them with path since they are not in PATH, for example, there is a
tool meta-browser/scripts/firefox-gen-l10n-recipes, we have to use
/path/to/meta-browser/scripts to run it. Make oe-buildenv-internal check and
enable $OEROOT/extrasettings, and set a line like the following can fix the
problem:

PATH=/relative/to/$OEROOT/meta-browser/scripts:$PATH

Signed-off-by: Robert Yang 
---
 scripts/oe-buildenv-internal | 4 
 1 file changed, 4 insertions(+)

diff --git a/scripts/oe-buildenv-internal b/scripts/oe-buildenv-internal
index ba0a9b44d6..bf84003d72 100755
--- a/scripts/oe-buildenv-internal
+++ b/scripts/oe-buildenv-internal
@@ -98,6 +98,10 @@ for newpath in "$BITBAKEDIR/bin" "$OEROOT/scripts"; do
 done
 unset BITBAKEDIR newpath
 
+if [ -e $OEROOT/extrasettings ]; then
+. $OEROOT/extrasettings
+fi
+
 # Used by the runqemu script
 export BUILDDIR
 export PATH
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#144503): 
https://lists.openembedded.org/g/openembedded-core/message/144503
Mute This Topic: https://lists.openembedded.org/mt/78204025/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 0/1] oe-buildenv-internal: Support extra settings

[Robert Yang]

The following changes since commit 4dce4e01cfa153fb12cfd1684d36e0432bef6741:

  binutils: reproducibility: reuse debug-prefix-map for stabs (2020-11-11 
10:08:07 +)

are available in the Git repository at:

  git://git.openembedded.org/openembedded-core-contrib rbt/path
  http://cgit.openembedded.org/openembedded-core-contrib/log/?h=rbt/path

Robert Yang (1):
  oe-buildenv-internal: Support extra settings

 scripts/oe-buildenv-internal | 4 
 1 file changed, 4 insertions(+)

-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#144502): 
https://lists.openembedded.org/g/openembedded-core/message/144502
Mute This Topic: https://lists.openembedded.org/mt/78204024/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] devtool modify - ModuleNotFoundError: No module named '_sysconfigdata'

[ernst . sjostrand]

Here are two other threads on the same topic. I've also run into this.

https://lists.yoctoproject.org/g/yocto/topic/74637733#51189

and

https://lists.yoctoproject.org/g/yocto/message/50856?p=,,,20,0,0,0::Created,,devtool,20,2,0,77178360

Regards
//Ernst

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

[OE-core] devtool modify - ModuleNotFoundError: No module named '_sysconfigdata'

[Peter Bergin]

Hi,

when running 'devtool modify u-boot-imx' I get a stacktrace ending up in 
"ModuleNotFoundError: No module named '_sysconfigdata'". 'devtool 
modify' works for other recipes. Detailed stacktrace and layer info is 
added below.


The stacktrace seems very similar to 
https://lists.openembedded.org/g/openembedded-core/message/144484 but I 
decided to start a new thread to not highjack another issue. As the 
stacktarces are very similar I have  guess that they are related in some 
way. My host machine is running Ubuntu 20.04.


I'm out of ideas how to debug this further and would like some help to 
sort this out.


Best regards,
/Peter



    $ devtool modify u-boot-imx

    ...

    Build Configuration:
    BB_VERSION   = "1.49.0"
    BUILD_SYS    = "x86_64-linux"
    NATIVELSBSTRING  = "universal"
    TARGET_SYS   = "aarch64-fslc-linux"
    MACHINE  = "imx8mnevk"
    DISTRO   = "fslc-wayland"
    DISTRO_VERSION   = "3.2-snapshot-20201112"
    TUNE_FEATURES    = "aarch64 armv8a crc cortexa53 crypto"
    TARGET_FPU   = ""
    meta
    meta-poky    = 
"master:be17f6bacc6ba8ee5c92cf4b2ec5b43c8e660b33"
    meta-freescale   = 
"master:447032d809427a20cc066b32254cea8821073281"
    meta-freescale-3rdparty = 
"master:b85d08a55cb833bfc4e8b5034ff804286c67620e"
    meta-freescale-distro = 
"master:11be3f01962df8436c5c7b0d61cd3dbd1b872905"

    meta-oe
    meta-networking
    meta-python  = 
"master:b6e14805923a0dec17140c9df45434a9bea951d9"


    ERROR: Error executing a python function in exec_python_func() 
autogenerated:


    The stack trace of python calls that resulted in this 
exception/failure was:

    File: 'exec_python_func() autogenerated', lineno: 2, function: 
         0001:
 *** 0002:devtool_post_unpack(d)
     0003:
    File: 
'/work/yocto/elektron-master/sources/poky/meta/classes/devtool-source.bbclass', 
lineno: 68, function:    devtool_post_unpack

     0064:}
     0065:
         0066:
         0067:python devtool_post_unpack() {
 *** 0068:    import oe.recipeutils
         0069:    import shutil
         0070:    sys.path.insert(0, os.path.join(d.getVar('COREBASE'), 
'scripts', 'lib'))

         0071:    import scriptutils
         0072:    from devtool import setup_git_repo
    File: 
'/work/yocto/elektron-master/sources/poky/meta/lib/oe/recipeutils.py', 
lineno: 21, function: 

         0017:import shutil
         0018:import re
         0019:import fnmatch
         0020:import glob
 *** 0021:import bb.tinfoil
         0022:
         0023:from collections import OrderedDict, defaultdict
         0024:from bb.utils import vercmp_string
         0025:
    File: 
'/work/yocto/elektron-master/sources/poky/bitbake/lib/bb/tinfoil.py', 
lineno: 19, function: 

         0015:from collections import OrderedDict, defaultdict
         0016:from functools import partial
         0017:
         0018:import bb.cache
 *** 0019:import bb.cooker
         0020:import bb.providers
         0021:import bb.taskdata
         0022:import bb.utils
         0023:import bb.command
    File: 
'/work/yocto/elektron-master/sources/poky/bitbake/lib/bb/cooker.py', 
lineno: 25, function: 

         0021:import bb, bb.exceptions, bb.command
         0022:from bb import utils, data, parse, event, cache, 
providers, taskdata, runqueue, build

         0023:import queue
         0024:import signal
 *** 0025:import prserv.serv
         0026:import pyinotify
         0027:import json
         0028:import pickle
         0029:import codecs
    File: 
'/work/yocto/elektron-master/sources/poky/bitbake/lib/prserv/serv.py', 
lineno: 7, function: 

         0003:#
         0004:
         0005:import os,sys,logging
         0006:import signal, time
 *** 0007:from xmlrpc.server import SimpleXMLRPCServer, 
SimpleXMLRPCRequestHandler

         0008:import threading
         0009:import queue
         0010:import socket
         0011:import io
    File: '/usr/lib/python3.8/xmlrpc/server.py', lineno: 117, function: 


         0113:import socketserver
         0114:import sys
         0115:import os
         0116:import re
 *** 0117:import pydoc
         0118:import traceback
         0119:try:
         0120:    import fcntl
         0121:except ImportError:
    File: '/usr/lib/python3.8/pydoc.py', lineno: 370, function: 
         0366:    return module
         0367:
         0368:#  
formatter base class

         0369:
 *** 0370:class Doc:
         0371:
         0372:    PYTHONDOCS = os.environ.get("PYTHONDOCS",
         0373: "https://docs.python.org/%d.%d/library;
         0374:    % sys.version_info[:2])
    File: '/usr/lib/python3.8/pydoc.py', lineno: 400, funct

Re: [OE-core] [PATCH] icu: upgrade 67.1 -> 68.1

[Alexander Kanavin]

There are several ways to find out what depends on a recipe: you can for
example do it with a simple grep:

ak@linux-f9zs:~/development/poky/meta> grep -ilr "\Wicu\W" *
classes/rm_work.bbclass
conf/distro/include/maintainers.inc
recipes-graphics/harfbuzz/harfbuzz_2.7.2.bb
recipes-sato/webkit/webkitgtk/0001-ICU-68.1-no-longer-exposes-FALSE-and-TRUE-macros-by-.patch

recipes-sato/webkit/webkitgtk_2.30.2.bb
recipes-support/boost/boost.inc
recipes-support/icu/icu/0001-Disable-LDFLAGSICUDT-for-Linux.patch
recipes-support/icu/icu/fix-install-manx.patch
recipes-support/icu/icu/0001-icu-Added-armeb-support.patch
recipes-support/icu/icu_68.1.bb
recipes-support/vte/vte_0.62.1.bb
recipes-support/libical/libical/0001-Fix-build-with-icu-68.1.patch
recipes-support/libical/libical_3.0.8.bb



Alex



On Thu, 12 Nov 2020 at 10:26, zangrc  wrote:

> Thank you very much, this is indeed a way, but the storage space of our
> test environment is limited, not enough to support bitbake world on
> multiple platforms. Is there any other way?
>
> Zang Ruochen
>
> > -Original Message-
> > From: Khem Raj 
> > Sent: Thursday, November 12, 2020 12:15 PM
> > To: Zang, Ruochen/臧 若尘 ; Ross Burton
> > 
> > Cc: OE-core 
> > Subject: Re: [OE-core] [PATCH] icu: upgrade 67.1 -> 68.1
> >
> >
> >
> > On 11/11/20 6:45 PM, zangrc wrote:
> > > Sorry, we will improve in the future, but we don’t know how to
> determine
> > which recipes need to be tested during the upgrade. Is there any way you
> can
> > provide us?
> > >
> >
> > one way would be to do bitbake -k world,
> >
> > > Zang Ruochen
> > >
> > >> -Original Message-
> > >> From: Ross Burton 
> > >> Sent: Wednesday, November 11, 2020 6:49 PM
> > >> To: Zang, Ruochen/臧 若尘 
> > >> Cc: OE-core 
> > >> Subject: Re: [OE-core] [PATCH] icu: upgrade 67.1 -> 68.1
> > >>
> > >> Please remember to build more than just a single recipe when testing,
> > >> in particular dependents.  This upgrade broke libical and webkitgtk,
> > >> which resulted in three iterations though the autobuilder and me
> > >> finding/backporting fixes as appropriate.
> > >>
> > >> Ross
> > >>
> > >> On Mon, 9 Nov 2020 at 03:39, zangrc 
> wrote:
> > >>>
> > >>> -License-Update:The address changes are as follows:
> > >>>   # Project: http://code.google.com/p/lao-dictionary/
> > >>>   # Dictionary:
> http://lao-dictionary.googlecode.com/git/Lao-Dictionary.txt
> > >>>   # License:
> > >>> http://lao-dictionary.googlecode.com/git/Lao-Dictionary-LICENSE.txt
> > >>>
> > >>> Signed-off-by: Zang Ruochen 
> > >>> ---
> > >>>  meta/recipes-support/icu/{icu_67.1.bb => icu_68.1.bb} | 6 +++---
> > >>>  1 file changed, 3 insertions(+), 3 deletions(-)  rename
> > >>> meta/recipes-support/icu/{icu_67.1.bb => icu_68.1.bb} (95%)
> > >>>
> > >>> diff --git a/meta/recipes-support/icu/icu_67.1.bb
> > >>> b/meta/recipes-support/icu/icu_68.1.bb
> > >>> similarity index 95%
> > >>> rename from meta/recipes-support/icu/icu_67.1.bb
> > >>> rename to meta/recipes-support/icu/icu_68.1.bb
> > >>> index 9e8091ba01..98aa6b7be6 100644
> > >>> --- a/meta/recipes-support/icu/icu_67.1.bb
> > >>> +++ b/meta/recipes-support/icu/icu_68.1.bb
> > >>> @@ -83,7 +83,7 @@ FILES_libicuio = "${libdir}/libicuio.so.*"
> > >>>
> > >>>  BBCLASSEXTEND = "native nativesdk"
> > >>>
> > >>> -LIC_FILES_CHKSUM =
> > >> "file://../LICENSE;md5=a3808a5b70071b07f87ff2205e4d75a0"
> > >>> +LIC_FILES_CHKSUM =
> > >> "file://../LICENSE;md5=002d2fdc32d17f0ec06e9a47f2c0c8d0"
> > >>>
> > >>>  def icu_download_version(d):
> > >>>  pvsplit = d.getVar('PV').split('.') @@ -112,8 +112,8 @@ SRC_URI
> > >>> = "${BASE_SRC_URI};name=code \  SRC_URI_append_class-target = "\
> > >>> file://0001-Disable-LDFLAGSICUDT-for-Linux.patch \
> > >>>"
> > >>> -SRC_URI[code.sha256sum] =
> > >>
> > "94a80cd6f251a53bd2a997f6f1b5ac6653fe791dfab66e1eb0227740fb86d5
> > >> dc"
> > >>> -SRC_URI[data.sha256sum] =
> > >>
> > "7c16a59cc8c06128b7ecc1dc4fc056b36b17349312829b17408b9e67b05c4
> > >> a7e"
> > >>> +SRC_URI[code.sha256sum] =
> > >>
> > "a9f2e3d8b4434b8e53878b4308bd1e6ee51c9c7042e2b1a376abefb6fbb2
> > >> 9f2d"
> > >>> +SRC_URI[data.sha256sum] =
> > >>
> > "03ea8b4694155620548c8c0ba20444f1e7db246cc79e3b9c4fc7a960b160d
> > >> 510"
> > >>>
> > >>>  UPSTREAM_CHECK_REGEX = "icu4c-(?P\d+(_\d+)+)-src"
> > >>>  UPSTREAM_CHECK_URI = "https://github.com/unicode-
> > org/icu/releases"
> > >>> --
> > >>> 2.25.1
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
>
>
>
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#144499): 
https://lists.openembedded.org/g/openembedded-core/message/144499
Mute This Topic: https://lists.openembedded.org/mt/78129127/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] python3-native sysconfig failing to load in dunfell

[Alexander Kanavin]

A quick fix may be to add a target python3 dependency to your recipe, yes
ugly, but I can't figure out how to provide target python configuration to
native python used in the context of building target recipes otherwise.

Alex


On Thu, 12 Nov 2020 at 10:49, Alexander Kanavin 
wrote:

> On Thu, 12 Nov 2020 at 02:23, Glenn Stroz via lists.openembedded.org
>  wrote:
>
>> We've been upgrading our work to Dunfell and have encountered an issue
>> with python3-native.
>>
>> One of our python3-native scripts uses pydoc and that in turn eventually
>> pulls in python's sysconfig. However, this is failing to import with the
>> following stack trace:
>>
>> ```
>> import pydoc
>>   File
>> "/home/gstroz/.cache/avos/_avos_gstroz/avos/yocto-dunfell/build/tmp/work/corei7-64-poky-linux/ebpf-daemon/2020.282.17-r0/recipe-sysroot-native/usr/lib/python3.8/pydoc.py",
>> line 366, in 
>> class Doc:
>>   File
>> "/home/gstroz/.cache/avos/_avos_gstroz/avos/yocto-dunfell/build/tmp/work/corei7-64-poky-linux/ebpf-daemon/2020.282.17-r0/recipe-sysroot-native/usr/lib/python3.8/pydoc.py",
>> line 396, in Doc
>> def getdocloc(self, object, basedir=sysconfig.get_path('stdlib')):
>>   File
>> "/home/gstroz/.cache/avos/_avos_gstroz/avos/yocto-dunfell/build/tmp/work/corei7-64-poky-linux/ebpf-daemon/2020.282.17-r0/recipe-sysroot-native/usr/lib/python3.8/sysconfig.py",
>> line 519, in get_path
>> return get_paths(scheme, vars, expand)[name]
>>   File
>> "/home/gstroz/.cache/avos/_avos_gstroz/avos/yocto-dunfell/build/tmp/work/corei7-64-poky-linux/ebpf-daemon/2020.282.17-r0/recipe-sysroot-native/usr/lib/python3.8/sysconfig.py",
>> line 509, in get_paths
>> return _expand_vars(scheme, vars)
>>   File
>> "/home/gstroz/.cache/avos/_avos_gstroz/avos/yocto-dunfell/build/tmp/work/corei7-64-poky-linux/ebpf-daemon/2020.282.17-r0/recipe-sysroot-native/usr/lib/python3.8/sysconfig.py",
>> line 172, in _expand_vars
>> _extend_dict(vars, get_config_vars())
>>   File
>> "/home/gstroz/.cache/avos/_avos_gstroz/avos/yocto-dunfell/build/tmp/work/corei7-64-poky-linux/ebpf-daemon/2020.282.17-r0/recipe-sysroot-native/usr/lib/python3.8/sysconfig.py",
>> line 558, in get_config_vars
>> _init_posix(_CONFIG_VARS)
>>   File
>> "/home/gstroz/.cache/avos/_avos_gstroz/avos/yocto-dunfell/build/tmp/work/corei7-64-poky-linux/ebpf-daemon/2020.282.17-r0/recipe-sysroot-native/usr/lib/python3.8/sysconfig.py",
>> line 428, in _init_posix
>> _temp = __import__(name, globals(), locals(), ['build_time_vars'], 0)
>> ModuleNotFoundError: No module named '_sysconfigdata'
>> ```
>>
>> I did a little digging and the following commit seems to reference
>> related work:
>>
>>
>> https://github.com/openembedded/openembedded-core/commit/02714c105426b0d687620913c1a7401b386428b6
>>
>> I see that there is a patch added which adds the following to
>> `sysconfig.py`:
>>
>> ```
>>   if 'STAGING_LIBDIR' in os.environ:
>>
>> sys.path.append(os.environ['STAGING_LIBDIR']+'/python-sysconfigdata')
>> ```
>>
>> However, STAGING_LIBDIR does not contain this path:
>>
>> ```
>> ls
>> /home/gstroz/.cache/avos/_avos_gstroz/avos/yocto-dunfell/build/tmp/work/corei7-64-poky-linux/ebpf-daemon/2020.282.17-r0/recipe-sysroot/usr/lib/python-sysconfigdata
>>
>> ls: cannot access
>> '/home/gstroz/.cache/avos/_avos_gstroz/avos/yocto-dunfell/build/tmp/work/corei7-64-poky-linux/ebpf-daemon/2020.282.17-r0/recipe-sysroot/usr/lib/python-sysconfigdata':
>> No such file or directory
>> ```
>>
>> It appears as if this should really be pointing to STAGING_LIBDIR_NATIVE
>> which does exist:
>>
>> ```
>> ls
>> /home/gstroz/.cache/avos/_avos_gstroz/avos/yocto-dunfell/build/tmp/work/corei7-64-poky-linux/ebpf-daemon/2020.282.17-r0/recipe-sysroot-native/usr/lib/python-sysconfigdata
>> _sysconfigdata.py
>> ```
>>
>> The referenced commit made efforts to combine the native and cross
>> python3 bbclass files into one. However, I think this may be something that
>> needs to be treated differently.
>>
>> Anyone have any thoughts on how to proceed?
>>
>
> Can you share the exact context where this is happening? Is your script
> coming from a recipe and can you show that recipe?
>
> Alex
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#144498): 
https://lists.openembedded.org/g/openembedded-core/message/144498
Mute This Topic: https://lists.openembedded.org/mt/78197661/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] python3-native sysconfig failing to load in dunfell

[Alexander Kanavin]

On Thu, 12 Nov 2020 at 02:23, Glenn Stroz via lists.openembedded.org
 wrote:

> We've been upgrading our work to Dunfell and have encountered an issue
> with python3-native.
>
> One of our python3-native scripts uses pydoc and that in turn eventually
> pulls in python's sysconfig. However, this is failing to import with the
> following stack trace:
>
> ```
> import pydoc
>   File
> "/home/gstroz/.cache/avos/_avos_gstroz/avos/yocto-dunfell/build/tmp/work/corei7-64-poky-linux/ebpf-daemon/2020.282.17-r0/recipe-sysroot-native/usr/lib/python3.8/pydoc.py",
> line 366, in 
> class Doc:
>   File
> "/home/gstroz/.cache/avos/_avos_gstroz/avos/yocto-dunfell/build/tmp/work/corei7-64-poky-linux/ebpf-daemon/2020.282.17-r0/recipe-sysroot-native/usr/lib/python3.8/pydoc.py",
> line 396, in Doc
> def getdocloc(self, object, basedir=sysconfig.get_path('stdlib')):
>   File
> "/home/gstroz/.cache/avos/_avos_gstroz/avos/yocto-dunfell/build/tmp/work/corei7-64-poky-linux/ebpf-daemon/2020.282.17-r0/recipe-sysroot-native/usr/lib/python3.8/sysconfig.py",
> line 519, in get_path
> return get_paths(scheme, vars, expand)[name]
>   File
> "/home/gstroz/.cache/avos/_avos_gstroz/avos/yocto-dunfell/build/tmp/work/corei7-64-poky-linux/ebpf-daemon/2020.282.17-r0/recipe-sysroot-native/usr/lib/python3.8/sysconfig.py",
> line 509, in get_paths
> return _expand_vars(scheme, vars)
>   File
> "/home/gstroz/.cache/avos/_avos_gstroz/avos/yocto-dunfell/build/tmp/work/corei7-64-poky-linux/ebpf-daemon/2020.282.17-r0/recipe-sysroot-native/usr/lib/python3.8/sysconfig.py",
> line 172, in _expand_vars
> _extend_dict(vars, get_config_vars())
>   File
> "/home/gstroz/.cache/avos/_avos_gstroz/avos/yocto-dunfell/build/tmp/work/corei7-64-poky-linux/ebpf-daemon/2020.282.17-r0/recipe-sysroot-native/usr/lib/python3.8/sysconfig.py",
> line 558, in get_config_vars
> _init_posix(_CONFIG_VARS)
>   File
> "/home/gstroz/.cache/avos/_avos_gstroz/avos/yocto-dunfell/build/tmp/work/corei7-64-poky-linux/ebpf-daemon/2020.282.17-r0/recipe-sysroot-native/usr/lib/python3.8/sysconfig.py",
> line 428, in _init_posix
> _temp = __import__(name, globals(), locals(), ['build_time_vars'], 0)
> ModuleNotFoundError: No module named '_sysconfigdata'
> ```
>
> I did a little digging and the following commit seems to reference related
> work:
>
>
> https://github.com/openembedded/openembedded-core/commit/02714c105426b0d687620913c1a7401b386428b6
>
> I see that there is a patch added which adds the following to
> `sysconfig.py`:
>
> ```
>   if 'STAGING_LIBDIR' in os.environ:
>
> sys.path.append(os.environ['STAGING_LIBDIR']+'/python-sysconfigdata')
> ```
>
> However, STAGING_LIBDIR does not contain this path:
>
> ```
> ls
> /home/gstroz/.cache/avos/_avos_gstroz/avos/yocto-dunfell/build/tmp/work/corei7-64-poky-linux/ebpf-daemon/2020.282.17-r0/recipe-sysroot/usr/lib/python-sysconfigdata
>
> ls: cannot access
> '/home/gstroz/.cache/avos/_avos_gstroz/avos/yocto-dunfell/build/tmp/work/corei7-64-poky-linux/ebpf-daemon/2020.282.17-r0/recipe-sysroot/usr/lib/python-sysconfigdata':
> No such file or directory
> ```
>
> It appears as if this should really be pointing to STAGING_LIBDIR_NATIVE
> which does exist:
>
> ```
> ls
> /home/gstroz/.cache/avos/_avos_gstroz/avos/yocto-dunfell/build/tmp/work/corei7-64-poky-linux/ebpf-daemon/2020.282.17-r0/recipe-sysroot-native/usr/lib/python-sysconfigdata
> _sysconfigdata.py
> ```
>
> The referenced commit made efforts to combine the native and cross python3
> bbclass files into one. However, I think this may be something that needs
> to be treated differently.
>
> Anyone have any thoughts on how to proceed?
>

Can you share the exact context where this is happening? Is your script
coming from a recipe and can you show that recipe?

Alex

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#144497): 
https://lists.openembedded.org/g/openembedded-core/message/144497
Mute This Topic: https://lists.openembedded.org/mt/78197661/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] [poky][master][PATCH] systemd: selinux hook handling to enumerate nexthop

[Purushottam choudhary]

Hi Openembedded/Khem,

Is there any update on this patch?

Could you please let me know?

Thanks & Regards,
Purushottam


From: Purushottam Choudhary 
Sent: Wednesday, November 4, 2020 4:04 PM
To: openembedded-core@lists.openembedded.org 
; raj.k...@gmail.com 

Cc: Nisha Parrakat ; Anuj Chougule 
; Aditya Tayade 
Subject: [poky][master][PATCH] systemd: selinux hook handling to enumerate 
nexthop

When selinux is enabled, the call of
manager_rtnl_enumerate_nexthop() fails.
This fix is to facilitate selinux hook handling
for enumerating nexthop.

In manager_rtnl_enumerate_nexthop() there is a check
if "Not supported" is returned by the send_netlink() call.
This check expects that -EOPNOTSUPP is returned,
the selinux hook seems to return -EINVAL instead.
This happens in kernel older than 5.3
(more specificallytorvalds/linux@65ee00a) as it does not support
nexthop handling through netlink.
And if SELinux is enforced in the order kernel, callingRTM_GETNEXTHOP
returns -EINVAL.

Thus adding a call in the manager_rtnl_enumerate_nexthop for the
extra return -EINVAL.

Note: systemd version is different in yocto project (v246.6) and
systemd master(v247) and In systemd verison(246.6)
mac_selinux_enforcing() function is not declared and defined.

Signed-off-by: Purushottam choudhary 
---
 ...elinux-hook-handling-to-enumerate-nexthop.patch | 46 ++
 meta/recipes-core/systemd/systemd_246.6.bb |  1 +
 2 files changed, 47 insertions(+)
 create mode 100644 
meta/recipes-core/systemd/systemd/selinux-hook-handling-to-enumerate-nexthop.patch

diff --git 
a/meta/recipes-core/systemd/systemd/selinux-hook-handling-to-enumerate-nexthop.patch
 
b/meta/recipes-core/systemd/systemd/selinux-hook-handling-to-enumerate-nexthop.patch
new file mode 100644
index 000..b1c92ed
--- /dev/null
+++ 
b/meta/recipes-core/systemd/systemd/selinux-hook-handling-to-enumerate-nexthop.patch
@@ -0,0 +1,46 @@
+From 92b555aaabf710e0a672a7244e8c0e3963075133 Mon Sep 17 00:00:00 2001
+From: Purushottam choudhary 
+Date: Wed, 28 Oct 2020 22:11:49 +0530
+Subject: [PATCH] network: selinux hook handling to enumerate nexthop
+
+When selinux is enabled, the call of
+manager_rtnl_enumerate_nexthop() fails.
+
+This fix is to facilitate selinux hook handling for enumerating
+nexthop.
+
+In manager_rtnl_enumerate_nexthop() there is a check
+if "Not supported" is returned by the send_netlink() call.
+
+This check expects that -EOPNOTSUPP is returned,
+the selinux hook seems to return -EINVAL instead.
+
+This happens in kernel older than 5.3
+(more specificallytorvalds/linux@65ee00a) as it does not support
+nexthop handling through netlink.
+
+And if SELinux is enforced in the order kernel, callingRTM_GETNEXTHOP
+returns -EINVAL.
+
+Thus adding a call in the manager_rtnl_enumerate_nexthop for the
+extra return -EINVAL.
+
+Upstream-Status: Backport
+https://github.com/systemd/systemd/commit/92b555aaabf710e0a672a7244e8c0e3963075133
+---
+ src/network/networkd-manager.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/src/network/networkd-manager.c b/src/network/networkd-manager.c
+index a6c1a39..2a9be85 100644
+--- a/src/network/networkd-manager.c
 b/src/network/networkd-manager.c
+@@ -2121,7 +2121,7 @@ int manager_rtnl_enumerate_nexthop(Manager *m) {
+
+ r = sd_netlink_call(m->rtnl, req, 0, );
+ if (r < 0) {
+-if (r == -EOPNOTSUPP) {
++if (r == -EOPNOTSUPP || r == -EINVAL) {
+ log_debug("Nexthop are not supported by the kernel. 
Ignoring.");
+ return 0;
+ }
diff --git a/meta/recipes-core/systemd/systemd_246.6.bb 
b/meta/recipes-core/systemd/systemd_246.6.bb
index 9215adf..78990f4 100644
--- a/meta/recipes-core/systemd/systemd_246.6.bb
+++ b/meta/recipes-core/systemd/systemd_246.6.bb
@@ -21,6 +21,7 @@ SRC_URI += "file://touchscreen.rules \

file://0001-binfmt-Don-t-install-dependency-links-at-install-tim.patch \
file://0003-implment-systemd-sysv-install-for-OE.patch \

file://0001-systemd.pc.in-use-ROOTPREFIX-without-suffixed-slash.patch \
+   file://selinux-hook-handling-to-enumerate-nexthop.patch \
"

 # patches needed by musl
--
2.7.4

This message contains information that may be privileged or confidential and is 
the property of the KPIT Technologies Ltd. It is intended only for the person 
to whom it is addressed. If you are not the intended recipient, you are not 
authorized to read, print, retain copy, disseminate, distribute, or use this 
message or any part thereof. If you receive this message in error, please 
notify the sender immediately and delete all copies of this message. KPIT 
Technologies Ltd. does not accept any liability for virus infected mails.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#144496): 

Re: [OE-core] [PATCH] icu: upgrade 67.1 -> 68.1

[zangrc]

Thank you very much, this is indeed a way, but the storage space of our test 
environment is limited, not enough to support bitbake world on multiple 
platforms. Is there any other way?

Zang Ruochen

> -Original Message-
> From: Khem Raj 
> Sent: Thursday, November 12, 2020 12:15 PM
> To: Zang, Ruochen/臧 若尘 ; Ross Burton
> 
> Cc: OE-core 
> Subject: Re: [OE-core] [PATCH] icu: upgrade 67.1 -> 68.1
> 
> 
> 
> On 11/11/20 6:45 PM, zangrc wrote:
> > Sorry, we will improve in the future, but we don’t know how to determine
> which recipes need to be tested during the upgrade. Is there any way you can
> provide us?
> >
> 
> one way would be to do bitbake -k world,
> 
> > Zang Ruochen
> >
> >> -Original Message-
> >> From: Ross Burton 
> >> Sent: Wednesday, November 11, 2020 6:49 PM
> >> To: Zang, Ruochen/臧 若尘 
> >> Cc: OE-core 
> >> Subject: Re: [OE-core] [PATCH] icu: upgrade 67.1 -> 68.1
> >>
> >> Please remember to build more than just a single recipe when testing,
> >> in particular dependents.  This upgrade broke libical and webkitgtk,
> >> which resulted in three iterations though the autobuilder and me
> >> finding/backporting fixes as appropriate.
> >>
> >> Ross
> >>
> >> On Mon, 9 Nov 2020 at 03:39, zangrc  wrote:
> >>>
> >>> -License-Update:The address changes are as follows:
> >>>   # Project: http://code.google.com/p/lao-dictionary/
> >>>   # Dictionary: 
> >>> http://lao-dictionary.googlecode.com/git/Lao-Dictionary.txt
> >>>   # License:
> >>> http://lao-dictionary.googlecode.com/git/Lao-Dictionary-LICENSE.txt
> >>>
> >>> Signed-off-by: Zang Ruochen 
> >>> ---
> >>>  meta/recipes-support/icu/{icu_67.1.bb => icu_68.1.bb} | 6 +++---
> >>>  1 file changed, 3 insertions(+), 3 deletions(-)  rename
> >>> meta/recipes-support/icu/{icu_67.1.bb => icu_68.1.bb} (95%)
> >>>
> >>> diff --git a/meta/recipes-support/icu/icu_67.1.bb
> >>> b/meta/recipes-support/icu/icu_68.1.bb
> >>> similarity index 95%
> >>> rename from meta/recipes-support/icu/icu_67.1.bb
> >>> rename to meta/recipes-support/icu/icu_68.1.bb
> >>> index 9e8091ba01..98aa6b7be6 100644
> >>> --- a/meta/recipes-support/icu/icu_67.1.bb
> >>> +++ b/meta/recipes-support/icu/icu_68.1.bb
> >>> @@ -83,7 +83,7 @@ FILES_libicuio = "${libdir}/libicuio.so.*"
> >>>
> >>>  BBCLASSEXTEND = "native nativesdk"
> >>>
> >>> -LIC_FILES_CHKSUM =
> >> "file://../LICENSE;md5=a3808a5b70071b07f87ff2205e4d75a0"
> >>> +LIC_FILES_CHKSUM =
> >> "file://../LICENSE;md5=002d2fdc32d17f0ec06e9a47f2c0c8d0"
> >>>
> >>>  def icu_download_version(d):
> >>>  pvsplit = d.getVar('PV').split('.') @@ -112,8 +112,8 @@ SRC_URI
> >>> = "${BASE_SRC_URI};name=code \  SRC_URI_append_class-target = "\
> >>> file://0001-Disable-LDFLAGSICUDT-for-Linux.patch \
> >>>"
> >>> -SRC_URI[code.sha256sum] =
> >>
> "94a80cd6f251a53bd2a997f6f1b5ac6653fe791dfab66e1eb0227740fb86d5
> >> dc"
> >>> -SRC_URI[data.sha256sum] =
> >>
> "7c16a59cc8c06128b7ecc1dc4fc056b36b17349312829b17408b9e67b05c4
> >> a7e"
> >>> +SRC_URI[code.sha256sum] =
> >>
> "a9f2e3d8b4434b8e53878b4308bd1e6ee51c9c7042e2b1a376abefb6fbb2
> >> 9f2d"
> >>> +SRC_URI[data.sha256sum] =
> >>
> "03ea8b4694155620548c8c0ba20444f1e7db246cc79e3b9c4fc7a960b160d
> >> 510"
> >>>
> >>>  UPSTREAM_CHECK_REGEX = "icu4c-(?P\d+(_\d+)+)-src"
> >>>  UPSTREAM_CHECK_URI = "https://github.com/unicode-
> org/icu/releases"
> >>> --
> >>> 2.25.1
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
> >
> >
> >
> >
> >
> > 
> >
> 




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