[OE-core] [PATCH 3/5] binutils: Disable parallel install for target binutils

2021-01-29 Thread Khem Raj
2.36 has a build race between libctf and libbfd

Signed-off-by: Khem Raj 
---
 meta/recipes-devtools/binutils/binutils_2.36.bb | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/meta/recipes-devtools/binutils/binutils_2.36.bb 
b/meta/recipes-devtools/binutils/binutils_2.36.bb
index 976e49765a..7caddfd1b9 100644
--- a/meta/recipes-devtools/binutils/binutils_2.36.bb
+++ b/meta/recipes-devtools/binutils/binutils_2.36.bb
@@ -52,6 +52,9 @@ do_install_class-native () {
rmdir ${D}/${libdir}64 || :
 }
 
+# libctf races with libbfd
+PARALLEL_MAKEINST_class-target = ""
+
 # Split out libbfd-*.so and libopcodes-*.so so including perf doesn't include
 # extra stuff
 PACKAGE_BEFORE_PN += "libbfd libopcodes"
-- 
2.30.0


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



[OE-core] [PATCH 4/5] glibc: Drop adding .file directive in asm files

2021-01-29 Thread Khem Raj
it was a workaround for binutils issue which is fixed in 2.36 with

https://sourceware.org/bugzilla/show_bug.cgi?id=26822

Signed-off-by: Khem Raj 
---
 ...0026-inject-file-assembly-directives.patch | 244 --
 meta/recipes-core/glibc/glibc_2.32.bb |   1 -
 2 files changed, 245 deletions(-)
 delete mode 100644 
meta/recipes-core/glibc/glibc/0026-inject-file-assembly-directives.patch

diff --git 
a/meta/recipes-core/glibc/glibc/0026-inject-file-assembly-directives.patch 
b/meta/recipes-core/glibc/glibc/0026-inject-file-assembly-directives.patch
deleted file mode 100644
index 5137fedb7b..00
--- a/meta/recipes-core/glibc/glibc/0026-inject-file-assembly-directives.patch
+++ /dev/null
@@ -1,244 +0,0 @@
-From cf043d56638883157dbfaa8c6a8e2f63a6f66280 Mon Sep 17 00:00:00 2001
-From: Khem Raj 
-Date: Thu, 29 Nov 2018 17:29:35 -0800
-Subject: [PATCH 26/29] inject file assembly directives
-
-Currently, non-IA builds are not reproducibile since build paths are
-being injected into the debug symbols. These are coming from the use of
-.S assembler files during the glibc build. No STT_FILE section is added
-during the assembly but when linking, ld decides to add one to aid
-debugging and ensure references between the different object files its
-linking remain clear.
-
-We can avoid this by injecting a file header into the assembler files
-ahead of time, choosing a filename which does not contain build system
-paths.
-
-This is a bit of a workaround/hack but does significantly reduce the
-build system references in target binaries for the non-IA architectures
-which use .S files.
-
-RP
-2018/10/3
-
-fixed in binutils 2.36 [1]
-
-[1] https://sourceware.org/bugzilla/show_bug.cgi?id=26822
-
-Upstream-Status: OE-Specific [ Drop when upgrading binutils 2.36+ ]
-
-Signed-off-by: Khem Raj 

- csu/abi-note.c| 2 ++
- sysdeps/aarch64/crti.S| 2 ++
- sysdeps/aarch64/crtn.S| 1 +
- sysdeps/aarch64/dl-tlsdesc.S  | 2 ++
- sysdeps/aarch64/dl-trampoline.S   | 2 ++
- sysdeps/aarch64/start.S   | 2 ++
- sysdeps/arm/crti.S| 2 ++
- sysdeps/arm/crtn.S| 2 ++
- sysdeps/arm/dl-tlsdesc.S  | 2 ++
- sysdeps/arm/dl-trampoline.S   | 2 ++
- sysdeps/arm/start.S   | 2 ++
- sysdeps/mips/start.S  | 2 ++
- sysdeps/powerpc/powerpc32/dl-start.S  | 2 ++
- sysdeps/powerpc/powerpc32/start.S | 2 ++
- sysdeps/powerpc/powerpc64/start.S | 2 ++
- sysdeps/unix/sysv/linux/aarch64/__read_tp.S   | 2 ++
- sysdeps/unix/sysv/linux/arm/aeabi_read_tp.S   | 2 ++
- sysdeps/unix/sysv/linux/arm/libc-do-syscall.S | 2 ++
- sysdeps/unix/sysv/linux/powerpc/dl-brk.S  | 2 ++
- 19 files changed, 37 insertions(+)
-
 a/sysdeps/aarch64/crti.S
-+++ b/sysdeps/aarch64/crti.S
-@@ -50,6 +50,8 @@
- # define PREINIT_FUNCTION_WEAK 1
- #endif
- 
-+.file "crti.S"
-+
- #if PREINIT_FUNCTION_WEAK
-   weak_extern (PREINIT_FUNCTION)
- #else
 a/sysdeps/aarch64/crtn.S
-+++ b/sysdeps/aarch64/crtn.S
-@@ -38,6 +38,7 @@
-corresponding to the prologues in crti.S. */
- 
- #include 
-+  .file "crtn.S"
- 
-   .section .init,"ax",%progbits
-   ldp x29, x30, [sp], 16
 a/sysdeps/aarch64/dl-tlsdesc.S
-+++ b/sysdeps/aarch64/dl-tlsdesc.S
-@@ -22,6 +22,8 @@
- #include 
- #include "tlsdesc.h"
- 
-+  .file "dl-tlsdesc.S"
-+
- #define NSAVEDQREGPAIRS   16
- #define SAVE_Q_REGISTERS  \
-   stp q0, q1, [sp, #-32*NSAVEDQREGPAIRS]!;\
 a/sysdeps/aarch64/dl-trampoline.S
-+++ b/sysdeps/aarch64/dl-trampoline.S
-@@ -21,6 +21,8 @@
- 
- #include "dl-link.h"
- 
-+  .file "dl-trampoline.S"
-+
- #define ip0 x16
- #define ip0l PTR_REG (16)
- #define ip1 x17
 a/sysdeps/aarch64/start.S
-+++ b/sysdeps/aarch64/start.S
-@@ -18,6 +18,8 @@
- 
- #include 
- 
-+  .file "start.S"
-+
- /* This is the canonical entry point, usually the first thing in the text
-segment.
- 
 a/sysdeps/arm/crti.S
-+++ b/sysdeps/arm/crti.S
-@@ -57,6 +57,8 @@
-   .hidden PREINIT_FUNCTION
- #endif
- 
-+.file "crti.S"
-+
- #if PREINIT_FUNCTION_WEAK
-   .p2align 2
-   .type call_weak_fn, %function
 a/sysdeps/arm/crtn.S
-+++ b/sysdeps/arm/crtn.S
-@@ -37,6 +37,8 @@
- #define NO_THUMB
- #include 
- 
-+.file "crtn.S"
-+
- /* crtn.S puts function epilogues in the .init and .fini sections
-corresponding to the prologues in crti.S. */
- 
 a/sysdeps/arm/dl-tlsdesc.S
-+++ b/sysdeps/arm/dl-tlsdesc.S
-@@ -21,6 +21,8 @@
- #include 
- #include "tlsdesc.h"
- 
-+  .file "dl-tlsdesc.S"
-+
-   .text
-   @ emit debug information with cfi
-   @ use arm-specific pseudos for unwinding itself
 a/sysdeps/arm/dl-trampoline.S
-+++ b/sysdeps/arm/dl-trampoline.S
-@@ -21,6 +21,8 @@
- #include 
- #include 
- 
-+ 

[OE-core] [PATCH 5/5] musl: Drop adding .file directive in asm files

2021-01-29 Thread Khem Raj
it was a workaround for binutils issue which is fixed in 2.36 with

https://sourceware.org/bugzilla/show_bug.cgi?id=26822

Signed-off-by: Khem Raj 
---
 .../musl/0001-crt-Add-.file-directive.patch   | 245 --
 meta/recipes-core/musl/musl_git.bb|   1 -
 2 files changed, 246 deletions(-)
 delete mode 100644 
meta/recipes-core/musl/musl/0001-crt-Add-.file-directive.patch

diff --git a/meta/recipes-core/musl/musl/0001-crt-Add-.file-directive.patch 
b/meta/recipes-core/musl/musl/0001-crt-Add-.file-directive.patch
deleted file mode 100644
index 1cd08cdcd4..00
--- a/meta/recipes-core/musl/musl/0001-crt-Add-.file-directive.patch
+++ /dev/null
@@ -1,245 +0,0 @@
-From b0124f3c4f2a353506621d387135ebea6b8c6609 Mon Sep 17 00:00:00 2001
-From: Khem Raj 
-Date: Thu, 29 Oct 2020 22:40:53 -0700
-Subject: [PATCH] crt: Add .file directive
-
-Musl linked binaries come out to be not reproducible because
-absolute build path is seen in debug info of crti.o and crtn.o
-This is due to the fact that these objects are built from assembly
-source files and they are missing .file directive
-if we add .file .s in them then debug info encodes this
-value instead of absolute path in debug_line section
-
-fixed in binutils 2.36 [1]
-
-[1] https://sourceware.org/bugzilla/show_bug.cgi?id=26822
-
-Upstream-Status: OE-Specific [ Drop when upgrading binutils 2.36+ ]
-Signed-off-by: Khem Raj 

- crt/aarch64/crti.s| 1 +
- crt/aarch64/crtn.s| 1 +
- crt/arm/crti.s| 1 +
- crt/arm/crtn.s| 1 +
- crt/i386/crti.s   | 1 +
- crt/i386/crtn.s   | 1 +
- crt/microblaze/crti.s | 1 +
- crt/microblaze/crtn.s | 1 +
- crt/mips/crti.s   | 1 +
- crt/mips/crtn.s   | 1 +
- crt/mips64/crti.s | 1 +
- crt/mips64/crtn.s | 1 +
- crt/mipsn32/crti.s| 1 +
- crt/mipsn32/crtn.s| 1 +
- crt/or1k/crti.s   | 1 +
- crt/or1k/crtn.s   | 1 +
- crt/powerpc/crti.s| 1 +
- crt/powerpc/crtn.s| 1 +
- crt/powerpc64/crti.s  | 1 +
- crt/powerpc64/crtn.s  | 1 +
- crt/s390x/crti.s  | 1 +
- crt/s390x/crtn.s  | 1 +
- crt/sh/crti.s | 1 +
- crt/sh/crtn.s | 1 +
- crt/x32/crti.s| 1 +
- crt/x32/crtn.s| 1 +
- crt/x86_64/crti.s | 1 +
- crt/x86_64/crtn.s | 1 +
- 28 files changed, 28 insertions(+)
-
 a/crt/aarch64/crti.s
-+++ b/crt/aarch64/crti.s
-@@ -1,3 +1,4 @@
-+.file "crti.s"
- .section .init
- .global _init
- .type _init,%function
 a/crt/aarch64/crtn.s
-+++ b/crt/aarch64/crtn.s
-@@ -1,3 +1,4 @@
-+.file "crtn.s"
- .section .init
-   ldp x29,x30,[sp],#16
-   ret
 a/crt/arm/crti.s
-+++ b/crt/arm/crti.s
-@@ -1,3 +1,4 @@
-+.file "crti.s"
- .syntax unified
- 
- .section .init
 a/crt/arm/crtn.s
-+++ b/crt/arm/crtn.s
-@@ -1,3 +1,4 @@
-+.file "crtn.s"
- .syntax unified
- 
- .section .init
 a/crt/i386/crti.s
-+++ b/crt/i386/crti.s
-@@ -1,3 +1,4 @@
-+.file "crti.s"
- .section .init
- .global _init
- _init:
 a/crt/i386/crtn.s
-+++ b/crt/i386/crtn.s
-@@ -1,3 +1,4 @@
-+.file "crtn.s"
- .section .init
-   add $12,%esp
-   ret
 a/crt/microblaze/crti.s
-+++ b/crt/microblaze/crti.s
-@@ -1,3 +1,4 @@
-+.file "crti.s"
- .section .init
- .global _init
- .align 2
 a/crt/microblaze/crtn.s
-+++ b/crt/microblaze/crtn.s
-@@ -1,3 +1,4 @@
-+.file "crtn.s"
- .section .init
-   lwi r15, r1, 0
-   rtsd r15, 8
 a/crt/mips/crti.s
-+++ b/crt/mips/crti.s
-@@ -1,3 +1,4 @@
-+.file "crti.s"
- .set noreorder
- 
- .section .init
 a/crt/mips/crtn.s
-+++ b/crt/mips/crtn.s
-@@ -1,3 +1,4 @@
-+.file "crtn.s"
- .set noreorder
- 
- .section .init
 a/crt/mips64/crti.s
-+++ b/crt/mips64/crti.s
-@@ -1,3 +1,4 @@
-+.file "crti.s"
- .set noreorder
- 
- .section .init
 a/crt/mips64/crtn.s
-+++ b/crt/mips64/crtn.s
-@@ -1,3 +1,4 @@
-+.file "crtn.s"
- .set noreorder
- 
- .section .init
 a/crt/mipsn32/crti.s
-+++ b/crt/mipsn32/crti.s
-@@ -1,3 +1,4 @@
-+.file "crti.s"
- .set  noreorder
- .section  .init
- .global   _init
 a/crt/mipsn32/crtn.s
-+++ b/crt/mipsn32/crtn.s
-@@ -1,3 +1,4 @@
-+.file "crtn.s"
- .set  noreorder
- .section  .init
-   ld  $gp, 16($sp)
 a/crt/or1k/crti.s
-+++ b/crt/or1k/crti.s
-@@ -1,3 +1,4 @@
-+.file "crti.s"
- .section .init
- .global _init
- _init:
 a/crt/or1k/crtn.s
-+++ b/crt/or1k/crtn.s
-@@ -1,3 +1,4 @@
-+.file "crtn.s"
- .section .init
-   l.lwz   r9,0(r1)
-   l.jrr9
 a/crt/powerpc/crti.s
-+++ b/crt/powerpc/crti.s
-@@ -1,3 +1,4 @@
-+.file "crti.s"
- .section .init
- .align 2
- .global _init
 a/crt/powerpc/crtn.s
-+++ b/crt/powerpc/crtn.s
-@@ -1,3 +1,4 @@
-+.file "crtn.s"
- .section .init
- .align 2
-   lwz 0,36(1)
 a/crt/powerpc64/crti.s
-+++ b/crt/powerpc64/crti.s
-@@ -1,3 +1,4 @@
-+.file "crti.s"
- .section .init
- .align 2
- .global _init
 a/crt/powerpc64/crtn.s
-+++ b/crt/powerpc64/crtn.s
-@@ -1,3 +1,4 @@
-+.file "crtn.s"
- .section .init
- .align 2
-   addi 1, 1, 32
 a/crt/s390x/crti.s
-+++ b/crt/s390x/crti.s
-@@ -1,3 +1,4 

[OE-core] [PATCH 2/5] binutils: Package libdep linker plugins

2021-01-29 Thread Khem Raj
this is new plugin added in binutils 2.36

Signed-off-by: Khem Raj 
---
 meta/recipes-devtools/binutils/binutils.inc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-devtools/binutils/binutils.inc 
b/meta/recipes-devtools/binutils/binutils.inc
index e93cd50b20..81891963c8 100644
--- a/meta/recipes-devtools/binutils/binutils.inc
+++ b/meta/recipes-devtools/binutils/binutils.inc
@@ -18,6 +18,7 @@ inherit autotools gettext multilib_header texinfo
 FILES_${PN} = " \
${bindir}/${TARGET_PREFIX}* \
${libdir}/lib*.so.* \
+   ${libdir}/bfd-plugins/lib*.so \
${libdir}/lib*-${PV}*.so \
${prefix}/${TARGET_SYS}/bin/* \
 ${bindir}/embedspu"
-- 
2.30.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#147468): 
https://lists.openembedded.org/g/openembedded-core/message/147468
Mute This Topic: https://lists.openembedded.org/mt/80230511/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 v4 4/4] shaderc: fix the build with glslang 11.1.0

2021-01-29 Thread Jose Quaresma
Hi Richard,

Thanks for the help in catch and try to solve this issue.

The recipe shaderc-native is the only recipe that is build in OE-Core
as it is needed by gstreamer plugins bad vulkan element.
The target shaderc is not used by anyone in OE-core at the moment
and because of that it don't have any build issues.

In my setup I don't see any erros and can build without any issues
the target shaderc on qemu as well as the shaderc-native.

I think that this problems can came from the spirv-tools that only generate
static libraries
and some this libraries have reproducible issues related with the glibc
librt.so.
The static libraries that come from spirv-tools are linked with the
librt.so from the host.

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

I will look at this when I have some time.
My next few weeks I’ll be very busy so I don’t promise anything.

Many thanks,

Jose


Richard Purdie  escreveu no dia sexta,
29/01/2021 à(s) 14:24:

> On Fri, 2021-01-29 at 11:42 +, Richard Purdie via
> lists.openembedded.org wrote:
> > On Thu, 2021-01-28 at 22:44 +, Richard Purdie via
> > lists.openembedded.org wrote:
> > > On Thu, 2021-01-28 at 23:38 +0100, Alexandre Belloni wrote:
> > > > Hello Jose,
> > > >
> > > > On 24/01/2021 18:07:58+, Jose Quaresma wrote:
> > > > > Drop patches:
> > > > > * 0001-Fix-the-link-order-of-libglslang-and-libHLSL.patch
> > > > >   is rejected upstream and is not need when glslang as shared
> libs.
> > > > >
> > > > > Update pacthes:
> > > > > * 0001-cmake-de-vendor-libs-and-disable-git-versioning.patch
> > > > >   renamed and refreshed from
> 0003-cmake-de-vendor-libs-and-disable-git-versioning.patch.
> > > > >
> > > >
> > > > It seems there is still a linking issue when building shaderc-native.
> > > > The full log is available here:
> > > >
> > > >
> https://autobuilder.yoctoproject.org/typhoon/#/builders/40/builds/2978/steps/11/logs/stdio
> > >
> > > I have a suspicion this happens on Ubuntu 18.04 systems since I've seen
> > > issues like this locally with 18.04's binutils version and OE generated
> > > vulkan-samples binaries, I think Joshua Watt reported the same issue
> > > too with 18.04.
> > >
> > > Not sure what we can do about it, can we disable the debug symbol types
> > > causing problems in that -native recipe?
> >
> > I tried to reproduce this and couldn't so far. I suspect what happens
> > is that one of the dependencies builds on a newer system, shaderc-
> > native then builds on 1804 and it can't read the binary generated by
> > the newer binutils.
> >
> > This is obviously a pain to setup and reproduce. The "easiest" way may
> > be to build buildtools-tarball to build everything up to shaderc-
> > native, then remove buildtools-tarball and build shaderc-native. I'll
> > see if I can find some time to try that.
> >
> > I've been holding the patches in master-next but I think we probably
> > should merge them as this could well be a generic ubuntu1804 issue that
> > already probably exists.
>
> I tried this and I couldn't reproduce with master's buildtools tarball
> so I guess we wait and see if it comes up again.
>
> Cheers,
>
> Richard
>
>

-- 
best regards,
José Quaresma

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#147467): 
https://lists.openembedded.org/g/openembedded-core/message/147467
Mute This Topic: https://lists.openembedded.org/mt/80084132/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] [RFC] openssl: Enable cryptodev-linux by default

2021-01-29 Thread Otavio Salvador
Em sex., 29 de jan. de 2021 às 18:14, Andre McCurdy
 escreveu:
> On Fri, Jan 29, 2021 at 12:45 PM Otavio Salvador
>  wrote:
> >
> > Em sex., 29 de jan. de 2021 às 17:39, Andre McCurdy
> >  escreveu:
> > >
> > > If a distro or BSP layer wants to enable cryptodev-linux support in
> > > openssl they can already do so by creating a .bbappend for openssl
> > > which adds the PACKAGECONFIG. ie if we decide that the option should
> > > be left disabled by default but controllable by the distro or BSP
> > > layer then no further changes are required - we already have a fully
> > > functional mechanism to do that.
> >
> > DISTRO yes, BSP is harder. If we enable it, it becomes MACHNE_ARCH as
> > well as all packages which depends on it.
>
> That's a concern if you're trying to create a package feed. But in
> that case you should already be taking care that BSP layers don't
> change the way recipes in common layers are built. ie this is
> something you would be controlling from a distro layer anyway.
>
> If you don't care about maintaining a package feed (which I guess is
> the majority of us?) then BSP layers which contain .bbappend files for
> recipes in common layers works just fine.

Also build time is a lot bigger.

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854  Mobile: +1 (347) 903-9750

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#147466): 
https://lists.openembedded.org/g/openembedded-core/message/147466
Mute This Topic: https://lists.openembedded.org/mt/80195674/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] [RFC] openssl: Enable cryptodev-linux by default

2021-01-29 Thread Andre McCurdy
On Fri, Jan 29, 2021 at 12:45 PM Otavio Salvador
 wrote:
>
> Em sex., 29 de jan. de 2021 às 17:39, Andre McCurdy
>  escreveu:
> >
> > If a distro or BSP layer wants to enable cryptodev-linux support in
> > openssl they can already do so by creating a .bbappend for openssl
> > which adds the PACKAGECONFIG. ie if we decide that the option should
> > be left disabled by default but controllable by the distro or BSP
> > layer then no further changes are required - we already have a fully
> > functional mechanism to do that.
>
> DISTRO yes, BSP is harder. If we enable it, it becomes MACHNE_ARCH as
> well as all packages which depends on it.

That's a concern if you're trying to create a package feed. But in
that case you should already be taking care that BSP layers don't
change the way recipes in common layers are built. ie this is
something you would be controlling from a distro layer anyway.

If you don't care about maintaining a package feed (which I guess is
the majority of us?) then BSP layers which contain .bbappend files for
recipes in common layers works just fine.

> > Going back to the original question of whether cryptodev-linux should
> > be enabled by default, I would say no. It's very much the legacy
> > approach and in the absence of benchmarks to prove otherwise I doubt
> > it gives any advantage in performance on modern platforms (especially
> > CPUs with dedicated crypto instructions).
>
>
> Tom, this is indeed the most important aspect to discuss. We need to
> check if latest openssl with new Linux kernels still require
> cryptodev-linux to use the acceleration.
>
> --
> Otavio Salvador O.S. Systems
> http://www.ossystems.com.brhttp://code.ossystems.com.br
> Mobile: +55 (53) 9 9981-7854  Mobile: +1 (347) 903-9750

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#147465): 
https://lists.openembedded.org/g/openembedded-core/message/147465
Mute This Topic: https://lists.openembedded.org/mt/80195674/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] [RFC] openssl: Enable cryptodev-linux by default

2021-01-29 Thread Otavio Salvador
Em sex., 29 de jan. de 2021 às 17:39, Andre McCurdy
 escreveu:
>
> If a distro or BSP layer wants to enable cryptodev-linux support in
> openssl they can already do so by creating a .bbappend for openssl
> which adds the PACKAGECONFIG. ie if we decide that the option should
> be left disabled by default but controllable by the distro or BSP
> layer then no further changes are required - we already have a fully
> functional mechanism to do that.


DISTRO yes, BSP is harder. If we enable it, it becomes MACHNE_ARCH as
well as all packages which depends on it.

> Going back to the original question of whether cryptodev-linux should
> be enabled by default, I would say no. It's very much the legacy
> approach and in the absence of benchmarks to prove otherwise I doubt
> it gives any advantage in performance on modern platforms (especially
> CPUs with dedicated crypto instructions).


Tom, this is indeed the most important aspect to discuss. We need to
check if latest openssl with new Linux kernels still require
cryptodev-linux to use the acceleration.

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854  Mobile: +1 (347) 903-9750

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#147464): 
https://lists.openembedded.org/g/openembedded-core/message/147464
Mute This Topic: https://lists.openembedded.org/mt/80195674/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] [RFC] openssl: Enable cryptodev-linux by default

2021-01-29 Thread Andre McCurdy
On Fri, Jan 29, 2021 at 12:34 AM Diego Santa Cruz via
lists.openembedded.org
 wrote:
>
> > -Original Message-
> > From: openembedded-core@lists.openembedded.org  > c...@lists.openembedded.org> On Behalf Of Khem Raj via
> > lists.openembedded.org
> > Sent: 29 January 2021 02:16
> > To: Tom Hochstein ; openembedded-
> > c...@lists.openembedded.org
> > Cc: ota...@ossystems.com.br
> > Subject: Re: [OE-core] [PATCH] [RFC] openssl: Enable cryptodev-linux by
> > default
> >
> >
> >
> > On 1/28/21 1:35 PM, Tom Hochstein wrote:
> > > This is a Request for Comment. Would it be a good idea to enable
> > cryptodev-linux
> > > by default, gaining hardware acceleration where supported? Are there any
> > > unacceptable drawbacks? What happens on hardware without
> > acceleration?
> > >
> >
> > this perhaps helps with devices that include a hardware crypto device
> > but not as much with one;s thats fine but we use qemu machines quite a
> > bit in testing so it would be good to get a readout on qemu secondly, if
> > it does not, then maybe we should see if defining it via
> > MACHINE_FEATUREs might be an option to enable it.
>
> I think that making it a MACHINE_FEATURES would effectively make the task 
> signatures for openssl be machine dependent and that would also make all 
> recipes which depend directly or indirectly on openssl (and there are a lot!) 
> have their task signatures be machine dependent, so they would need to have 
> their PACKAGE_ARCH set to MACHINE_ARCH to avoid triggering spurious rebuilds 
> when switching between machines with and without cryptodev-linux in 
> MACHINE_FEATURES.
>
> So MACHINE_FEATURES does not look like a viable option, a DISTRO_FEATURES 
> might be, although it does not really look like a nice fit either.

MACHINE and DISTRO features are global variables which should be
reserved for configuration decisions which affect multiple recipes (so
that multiple recipes can be configured together under the control of
one option). It doesn't make much sense to create a new MACHINE or
DISTRO feature if it's only going to be used by one recipe.

If a distro or BSP layer wants to enable cryptodev-linux support in
openssl they can already do so by creating a .bbappend for openssl
which adds the PACKAGECONFIG. ie if we decide that the option should
be left disabled by default but controllable by the distro or BSP
layer then no further changes are required - we already have a fully
functional mechanism to do that.

Going back to the original question of whether cryptodev-linux should
be enabled by default, I would say no. It's very much the legacy
approach and in the absence of benchmarks to prove otherwise I doubt
it gives any advantage in performance on modern platforms (especially
CPUs with dedicated crypto instructions).

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#147463): 
https://lists.openembedded.org/g/openembedded-core/message/147463
Mute This Topic: https://lists.openembedded.org/mt/80195674/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] [meta-oe][PATCH] glm: Fix packaging for header-only recipe

2021-01-29 Thread Otavio Salvador
Em sex., 29 de jan. de 2021 às 13:06, Tom Hochstein
 escreveu:
> On Thu, Jan 28, 2021 at 10:57 PM Khem Raj  wrote:
> > On Thu, Jan 28, 2021 at 5:44 PM Tom Hochstein 
> >  wrote:
> > > Set ALLOW_EMPTY for the main package to "1" for this header-only recipe. 
> > > This
> > > allows the SDK to be created properly when there is an RDEPENDS on glm.
> >
> > Runtime dependency on a header only package seems a bit iffy it's perhaps 
> > better to depend on glm-dev perhaps ?
>
> Well, it's all iffy in my mind since these are just different workarounds for 
> the root problem that header-only packages are not included in the SDK. If 
> you think including the headers in the image is the better workaround, then I 
> will switch to that.

The allow empty seems to be the right workaround here as it allow
people to consistently use the `dev-pkgs` filter to populate the SDK.

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854  Mobile: +1 (347) 903-9750

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#147462): 
https://lists.openembedded.org/g/openembedded-core/message/147462
Mute This Topic: https://lists.openembedded.org/mt/80200725/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] [meta-oe][PATCH] glm: Fix packaging for header-only recipe

2021-01-29 Thread Tom Hochstein

On Thu, Jan 28, 2021 at 10:57 PM Khem Raj  wrote:
> 
> On Thu, Jan 28, 2021 at 5:44 PM Tom Hochstein  
> wrote:
> > Set ALLOW_EMPTY for the main package to "1" for this header-only recipe. 
> > This
> > allows the SDK to be created properly when there is an RDEPENDS on glm.
> 
> Runtime dependency on a header only package seems a bit iffy it's perhaps 
> better to depend on glm-dev perhaps ?

Well, it's all iffy in my mind since these are just different workarounds for 
the root problem that header-only packages are not included in the SDK. If you 
think including the headers in the image is the better workaround, then I will 
switch to that.

Tom

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



[OE-core][dunfell 00/46] Pull request (cover letter only)

2021-01-29 Thread Steve Sakoman
The following changes since commit b286258fc2f6974a88ebd90d3c2f9465437cfcfd:

  linuxloader: Avoid confusing string concat errors (2021-01-27 09:32:57 +)

are available in the Git repository at:

  git://git.openembedded.org/openembedded-core-contrib stable/dunfell-next
  
http://cgit.openembedded.org/openembedded-core-contrib/log/?h=stable/dunfell-next

Jack Mitchell (1):
  distutils3: allow setup.py to be run from a different directory to
${S}

Joe Slater (1):
  pseudo: fix renaming to self

Martin Jansa (2):
  base.bbclass: use os.path.normpath instead of just comparing WORKDIR
and S as strings
  license.bbclass: Add COMMON_LICENSE_DIR and LICENSE_PATH dirs to
PSEUDO_IGNORE_PATHS

Mingli Yu (2):
  tcl: adapt to potential pseudo changes
  bitbake.conf: Exclude ${CCACHE_DIR} from pseudo database

Paul Barker (8):
  bitbake.conf: Prevent pyc file generation in pseudo context
  wic: Add workdir argument
  wic: Allow exec_native_cmd to run HOSTTOOLS
  wic: Ensure internal workdir is not reused
  image_types_wic: Move wic working directory
  wic: Update pseudo db when excluding content from rootfs
  wic: Copy rootfs dir if fstab needs updating
  wic: Optimise fstab modification for ext2/3/4 and msdos partitions

Peter Kjellerstedt (4):
  pseudo: Simplify pseudo_client_ignore_path_chroot()
  lib/oe/path: Add canonicalize()
  bitbake.conf: Canonicalize paths in PSEUDO_IGNORE_PATHS
  wic: Pass canonicalized paths in PSEUDO_IGNORE_PATHS

Ricardo Ribalda Delgado (4):
  wic: Fix permissions when using exclude or include path
  wic: Fix multi images .wks with bitbake
  wic: Avoid creating invalid pseudo directory
  wic: Add --change-directory argument

Richard Purdie (23):
  pseudo: Switch to oe-core branch in git repo
  pseudo: merge in fixes for setfacl issue
  pseudo: Update to add OFC fcntl lock updates
  pseudo: Ignore mismatched inodes from the db
  pseudo: Add support for ignoring paths from the pseudo DB
  pseudo: Abort on mismatch patch
  psuedo: Add tracking of linked files for fds
  pseudo: Fix xattr segfault
  pseudo: Add may unlink patch
  pseudo: Add pathfix patch
  base/bitbake.conf: Enable pseudo path filtering
  wic: Handle new PSEUDO_IGNORE_PATHS variable
  pseudo: Fix statx function usage
  bitbake.conf: Extend PSEUDO_IGNORE_PATHS to ${COREBASE}/meta
  abi_version,sanity: Tell users TMPDIR must be clean after pseudo
changes
  pseudo: Update to account for patches merged on branch
  pseudo: Upgrade to include mkostemp64 wrapper
  oeqa/selftest/runtime_test: Exclude gpg directory from pseudo database
  uninative: Don't use single sstate for pseudo-native
  pseudo: Drop patches merged into upstream branch
  bitbake.conf: Add /run/ to PSEUDO_IGNORE_PATHS
  pseudo: Add lchmod wrapper
  pseudo: Update for arm host and memleak fixes/cleanup

Tomasz Dziendzielski (1):
  pseudo: Update to print PSEUDO_LOGFILE in abort message on path
mismatches

 meta-selftest/lib/pseudo_pyc_test1.py |   1 +
 meta-selftest/lib/pseudo_pyc_test2.py |   1 +
 .../pseudo-pyc-test/pseudo-pyc-test.bb|  15 ++
 meta/classes/archiver.bbclass |   2 +-
 meta/classes/base.bbclass |   6 +
 meta/classes/distutils3.bbclass   |  10 +-
 meta/classes/image_types_wic.bbclass  |  20 ++-
 meta/classes/license.bbclass  |   1 +
 meta/classes/populate_sdk_base.bbclass|   2 +
 meta/classes/sanity.bbclass   |   3 +
 meta/classes/sstate.bbclass   |   4 +
 meta/conf/abi_version.conf|   2 +-
 meta/conf/bitbake.conf|  13 +-
 meta/lib/oe/path.py   |  21 +++
 meta/lib/oe/sstatesig.py  |   4 +-
 meta/lib/oeqa/selftest/cases/pseudo.py|  27 
 meta/lib/oeqa/selftest/cases/runtime_test.py  |   1 +
 .../pseudo/files/0001-Add-statx.patch | 106 --
 ...001-maketables-wrappers-use-Python-3.patch |  34 -
 ...ixup-remove-files-that-do-not-exist-.patch |  49 ---
 .../0001-pseudo_ipc.h-Fix-enum-typedef.patch  |  31 
 ...1-realpath.c-Remove-trailing-slashes.patch |  57 
 ...xattr-adjust-for-attr-2.4.48-release.patch |  48 --
 .../pseudo/files/moreretries.patch|  19 ---
 .../pseudo/files/seccomp.patch| 137 --
 .../pseudo/files/toomanyfiles.patch   |  71 -
 .../pseudo/files/xattr_version.patch  |  54 ---
 meta/recipes-devtools/pseudo/pseudo_git.bb|  14 +-
 meta/recipes-devtools/tcltk/tcl_8.6.10.bb |   1 +
 scripts/lib/wic/help.py   |   6 +
 scripts/lib/wic/ksparser.py   |   1 +
 scripts/lib/wic/misc.py   |   7 +-
 scripts/lib/wic/partition.py  |  66 ++---
 scripts/lib/wic/plugins/imager/direct.py  |  48 +++---
 scripts/lib/wic/plugins/source/rootfs.py  |  85 +--
 

[OE-core] [dunfell][PATCH v2 3/3] bitbake: fetch/git: download LFS content too during do_fetch

2021-01-29 Thread Mikko Rapeli
From: Matt Hoosier 

Insert an explicit pass to fetch all blobs needed by Git LFS, during the
fetch() function. This avoids the default behavior of Git LFS to wait
until 'git checkout' to begin downloading the blobs pointed to by LFS records.
Network access is not allowed at that point in the recipe's lifecycle.

[YOCTO #14191]

(Bitbake rev: 0efac66043662e7a2027192f50e92e982db2ba1c)

Signed-off-by: Matt Hoosier 
Signed-off-by: Richard Purdie 
---
 bitbake/lib/bb/fetch2/git.py  | 44 ---
 bitbake/lib/bb/tests/fetch.py | 28 +++---
 2 files changed, 61 insertions(+), 11 deletions(-)

diff --git a/bitbake/lib/bb/fetch2/git.py b/bitbake/lib/bb/fetch2/git.py
index d255afeb36..7c32eba6c3 100644
--- a/bitbake/lib/bb/fetch2/git.py
+++ b/bitbake/lib/bb/fetch2/git.py
@@ -378,6 +378,35 @@ class Git(FetchMethod):
 if missing_rev:
 raise bb.fetch2.FetchError("Unable to find revision %s even 
from upstream" % missing_rev)
 
+if self._contains_lfs(ud, d, ud.clonedir) and self._need_lfs(ud):
+# Unpack temporary working copy, use it to run 'git checkout' to 
force pre-fetching
+# of all LFS blobs needed at the the srcrev.
+#
+# It would be nice to just do this inline here by running 'git-lfs 
fetch'
+# on the bare clonedir, but that operation requires a working copy 
on some
+# releases of Git LFS.
+tmpdir = tempfile.mkdtemp(dir=d.getVar('DL_DIR'))
+try:
+# Do the checkout. This implicitly involves a Git LFS fetch.
+self.unpack(ud, tmpdir, d)
+
+# Scoop up a copy of any stuff that Git LFS downloaded. Merge 
them into
+# the bare clonedir.
+#
+# As this procedure is invoked repeatedly on incremental 
fetches as
+# a recipe's SRCREV is bumped throughout its lifetime, this 
will
+# result in a gradual accumulation of LFS blobs in 
/lfs
+# corresponding to all the blobs reachable from the different 
revs
+# fetched across time.
+#
+# Only do this if the unpack resulted in a .git/lfs directory 
being
+# created; this only happens if at least one blob needed to be
+# downloaded.
+if os.path.exists(os.path.join(tmpdir, "git", ".git", "lfs")):
+runfetchcmd("tar -cf - lfs | tar -xf - -C %s" % 
ud.clonedir, d, workdir="%s/git/.git" % tmpdir)
+finally:
+bb.utils.remove(tmpdir, recurse=True)
+
 def build_mirror_data(self, ud, d):
 if ud.shallow and ud.write_shallow_tarballs:
 if not os.path.exists(ud.fullshallow):
@@ -473,7 +502,7 @@ class Git(FetchMethod):
 if os.path.exists(destdir):
 bb.utils.prunedir(destdir)
 
-need_lfs = ud.parm.get("lfs", "1") == "1"
+need_lfs = self._need_lfs(ud)
 
 if not need_lfs:
 ud.basecmd = "GIT_LFS_SKIP_SMUDGE=1 " + ud.basecmd
@@ -562,6 +591,9 @@ class Git(FetchMethod):
 raise bb.fetch2.FetchError("The command '%s' gave output with more 
then 1 line unexpectedly, output: '%s'" % (cmd, output))
 return output.split()[0] != "0"
 
+def _need_lfs(self, ud):
+return ud.parm.get("lfs", "1") == "1"
+
 def _contains_lfs(self, ud, d, wd):
 """
 Check if the repository has 'lfs' (large file) content
@@ -572,8 +604,14 @@ class Git(FetchMethod):
 else:
 branchname = "master"
 
-cmd = "%s grep lfs origin/%s:.gitattributes | wc -l" % (
-ud.basecmd, ud.branches[ud.names[0]])
+# The bare clonedir doesn't use the remote names; it has the branch 
immediately.
+if wd == ud.clonedir:
+refname = ud.branches[ud.names[0]]
+else:
+refname = "origin/%s" % ud.branches[ud.names[0]]
+
+cmd = "%s grep lfs %s:.gitattributes | wc -l" % (
+ud.basecmd, refname)
 
 try:
 output = runfetchcmd(cmd, d, quiet=True, workdir=wd)
diff --git a/bitbake/lib/bb/tests/fetch.py b/bitbake/lib/bb/tests/fetch.py
index 4702c99a7e..9453c90d2b 100644
--- a/bitbake/lib/bb/tests/fetch.py
+++ b/bitbake/lib/bb/tests/fetch.py
@@ -2046,13 +2046,14 @@ class GitLfsTest(FetcherTest):
 cwd = self.gitdir
 return bb.process.run(cmd, cwd=cwd)[0]
 
-def fetch(self, uri=None):
+def fetch(self, uri=None, download=True):
 uris = self.d.getVar('SRC_URI').split()
 uri = uris[0]
 d = self.d
 
 fetcher = bb.fetch2.Fetch(uris, d)
-fetcher.download()
+if download:
+fetcher.download()
 ud = fetcher.ud[uri]
 return fetcher, ud
 
@@ -2062,16 +2063,21 @@ class GitLfsTest(FetcherTest):
 uri = 'git://%s;protocol=file;subdir=${S};lfs=1' % self.srcdir
 

[OE-core] [dunfell][PATCH v2 2/3] bitbake: git.py: Use the correct branch to check if the repository has LFS objects.

2021-01-29 Thread Mikko Rapeli
From: Mauro Queirós 

Function "contains_lfs" was only looking at the master branch when searching 
for LFS
content. LFS may be configured in specific branches only, so we need to use the
correct branch.

(Bitbake rev: 4fa67c2af830035a1ddedc14592ee25a15ebff22)

Signed-off-by: Mauro Queiros 
Signed-off-by: Richard Purdie 
---
 bitbake/lib/bb/fetch2/git.py | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/bitbake/lib/bb/fetch2/git.py b/bitbake/lib/bb/fetch2/git.py
index 59afc32de1..d255afeb36 100644
--- a/bitbake/lib/bb/fetch2/git.py
+++ b/bitbake/lib/bb/fetch2/git.py
@@ -566,8 +566,15 @@ class Git(FetchMethod):
 """
 Check if the repository has 'lfs' (large file) content
 """
-cmd = "%s grep lfs HEAD:.gitattributes | wc -l" % (
-ud.basecmd)
+
+if not ud.nobranch:
+branchname = ud.branches[ud.names[0]]
+else:
+branchname = "master"
+
+cmd = "%s grep lfs origin/%s:.gitattributes | wc -l" % (
+ud.basecmd, ud.branches[ud.names[0]])
+
 try:
 output = runfetchcmd(cmd, d, quiet=True, workdir=wd)
 if int(output) > 0:
-- 
2.20.1


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



[OE-core] [dunfell][PATCH v2 1/3] bitbake: git.py: skip smudging if lfs=0 is set

2021-01-29 Thread Mikko Rapeli
From: Mauro Queirós 

Git-LFS objects were being fetched even when lfs=0 was not set.
This patch disables LFS smudging when lfs=0. That way, only the LFS pointers
are downloaded during checkout.

(Bitbake rev: 646d86df7de774255246a3d7051c308e43eb257d)

Signed-off-by: Mauro Queiros 
Signed-off-by: Richard Purdie 
---
 bitbake/lib/bb/fetch2/git.py | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/bitbake/lib/bb/fetch2/git.py b/bitbake/lib/bb/fetch2/git.py
index dcecff5d38..59afc32de1 100644
--- a/bitbake/lib/bb/fetch2/git.py
+++ b/bitbake/lib/bb/fetch2/git.py
@@ -475,6 +475,9 @@ class Git(FetchMethod):
 
 need_lfs = ud.parm.get("lfs", "1") == "1"
 
+if not need_lfs:
+ud.basecmd = "GIT_LFS_SKIP_SMUDGE=1 " + ud.basecmd
+
 source_found = False
 source_error = []
 
-- 
2.20.1


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



Re: [OE-core] [dunfell][PATCH 1/2] bitbake: git.py: Use the correct branch to check if the repository has LFS objects.

2021-01-29 Thread Mikko Rapeli
Sorry, third patch needs to be backported from master for git lfs to work
nicely on dunfell. Will send a v2.

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



[OE-core] [dunfell][PATCH 2/2] bitbake: fetch/git: download LFS content too during do_fetch

2021-01-29 Thread Mikko Rapeli
From: Matt Hoosier 

Insert an explicit pass to fetch all blobs needed by Git LFS, during the
fetch() function. This avoids the default behavior of Git LFS to wait
until 'git checkout' to begin downloading the blobs pointed to by LFS records.
Network access is not allowed at that point in the recipe's lifecycle.

[YOCTO #14191]

(Bitbake rev: 0efac66043662e7a2027192f50e92e982db2ba1c)

Signed-off-by: Matt Hoosier 
Signed-off-by: Richard Purdie 
---
 bitbake/lib/bb/fetch2/git.py  | 44 ---
 bitbake/lib/bb/tests/fetch.py | 28 +++---
 2 files changed, 61 insertions(+), 11 deletions(-)

diff --git a/bitbake/lib/bb/fetch2/git.py b/bitbake/lib/bb/fetch2/git.py
index fc14192e24..85c45d4dd4 100644
--- a/bitbake/lib/bb/fetch2/git.py
+++ b/bitbake/lib/bb/fetch2/git.py
@@ -378,6 +378,35 @@ class Git(FetchMethod):
 if missing_rev:
 raise bb.fetch2.FetchError("Unable to find revision %s even 
from upstream" % missing_rev)
 
+if self._contains_lfs(ud, d, ud.clonedir) and self._need_lfs(ud):
+# Unpack temporary working copy, use it to run 'git checkout' to 
force pre-fetching
+# of all LFS blobs needed at the the srcrev.
+#
+# It would be nice to just do this inline here by running 'git-lfs 
fetch'
+# on the bare clonedir, but that operation requires a working copy 
on some
+# releases of Git LFS.
+tmpdir = tempfile.mkdtemp(dir=d.getVar('DL_DIR'))
+try:
+# Do the checkout. This implicitly involves a Git LFS fetch.
+self.unpack(ud, tmpdir, d)
+
+# Scoop up a copy of any stuff that Git LFS downloaded. Merge 
them into
+# the bare clonedir.
+#
+# As this procedure is invoked repeatedly on incremental 
fetches as
+# a recipe's SRCREV is bumped throughout its lifetime, this 
will
+# result in a gradual accumulation of LFS blobs in 
/lfs
+# corresponding to all the blobs reachable from the different 
revs
+# fetched across time.
+#
+# Only do this if the unpack resulted in a .git/lfs directory 
being
+# created; this only happens if at least one blob needed to be
+# downloaded.
+if os.path.exists(os.path.join(tmpdir, "git", ".git", "lfs")):
+runfetchcmd("tar -cf - lfs | tar -xf - -C %s" % 
ud.clonedir, d, workdir="%s/git/.git" % tmpdir)
+finally:
+bb.utils.remove(tmpdir, recurse=True)
+
 def build_mirror_data(self, ud, d):
 if ud.shallow and ud.write_shallow_tarballs:
 if not os.path.exists(ud.fullshallow):
@@ -473,7 +502,7 @@ class Git(FetchMethod):
 if os.path.exists(destdir):
 bb.utils.prunedir(destdir)
 
-need_lfs = ud.parm.get("lfs", "1") == "1"
+need_lfs = self._need_lfs(ud)
 
 source_found = False
 source_error = []
@@ -559,6 +588,9 @@ class Git(FetchMethod):
 raise bb.fetch2.FetchError("The command '%s' gave output with more 
then 1 line unexpectedly, output: '%s'" % (cmd, output))
 return output.split()[0] != "0"
 
+def _need_lfs(self, ud):
+return ud.parm.get("lfs", "1") == "1"
+
 def _contains_lfs(self, ud, d, wd):
 """
 Check if the repository has 'lfs' (large file) content
@@ -569,8 +601,14 @@ class Git(FetchMethod):
 else:
 branchname = "master"
 
-cmd = "%s grep lfs origin/%s:.gitattributes | wc -l" % (
-ud.basecmd, ud.branches[ud.names[0]])
+# The bare clonedir doesn't use the remote names; it has the branch 
immediately.
+if wd == ud.clonedir:
+refname = ud.branches[ud.names[0]]
+else:
+refname = "origin/%s" % ud.branches[ud.names[0]]
+
+cmd = "%s grep lfs %s:.gitattributes | wc -l" % (
+ud.basecmd, refname)
 
 try:
 output = runfetchcmd(cmd, d, quiet=True, workdir=wd)
diff --git a/bitbake/lib/bb/tests/fetch.py b/bitbake/lib/bb/tests/fetch.py
index 4702c99a7e..9453c90d2b 100644
--- a/bitbake/lib/bb/tests/fetch.py
+++ b/bitbake/lib/bb/tests/fetch.py
@@ -2046,13 +2046,14 @@ class GitLfsTest(FetcherTest):
 cwd = self.gitdir
 return bb.process.run(cmd, cwd=cwd)[0]
 
-def fetch(self, uri=None):
+def fetch(self, uri=None, download=True):
 uris = self.d.getVar('SRC_URI').split()
 uri = uris[0]
 d = self.d
 
 fetcher = bb.fetch2.Fetch(uris, d)
-fetcher.download()
+if download:
+fetcher.download()
 ud = fetcher.ud[uri]
 return fetcher, ud
 
@@ -2062,16 +2063,21 @@ class GitLfsTest(FetcherTest):
 uri = 'git://%s;protocol=file;subdir=${S};lfs=1' % self.srcdir
 self.d.setVar('SRC_URI', uri)
 
-  

[OE-core] [dunfell][PATCH 1/2] bitbake: git.py: Use the correct branch to check if the repository has LFS objects.

2021-01-29 Thread Mikko Rapeli
From: Mauro Queirós 

Function "contains_lfs" was only looking at the master branch when searching 
for LFS
content. LFS may be configured in specific branches only, so we need to use the
correct branch.

(Bitbake rev: 4fa67c2af830035a1ddedc14592ee25a15ebff22)

Signed-off-by: Mauro Queiros 
Signed-off-by: Richard Purdie 
---
 bitbake/lib/bb/fetch2/git.py | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/bitbake/lib/bb/fetch2/git.py b/bitbake/lib/bb/fetch2/git.py
index dcecff5d38..fc14192e24 100644
--- a/bitbake/lib/bb/fetch2/git.py
+++ b/bitbake/lib/bb/fetch2/git.py
@@ -563,8 +563,15 @@ class Git(FetchMethod):
 """
 Check if the repository has 'lfs' (large file) content
 """
-cmd = "%s grep lfs HEAD:.gitattributes | wc -l" % (
-ud.basecmd)
+
+if not ud.nobranch:
+branchname = ud.branches[ud.names[0]]
+else:
+branchname = "master"
+
+cmd = "%s grep lfs origin/%s:.gitattributes | wc -l" % (
+ud.basecmd, ud.branches[ud.names[0]])
+
 try:
 output = runfetchcmd(cmd, d, quiet=True, workdir=wd)
 if int(output) > 0:
-- 
2.20.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#147454): 
https://lists.openembedded.org/g/openembedded-core/message/147454
Mute This Topic: https://lists.openembedded.org/mt/80210764/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 v4 4/4] shaderc: fix the build with glslang 11.1.0

2021-01-29 Thread Richard Purdie
On Fri, 2021-01-29 at 11:42 +, Richard Purdie via
lists.openembedded.org wrote:
> On Thu, 2021-01-28 at 22:44 +, Richard Purdie via
> lists.openembedded.org wrote:
> > On Thu, 2021-01-28 at 23:38 +0100, Alexandre Belloni wrote:
> > > Hello Jose,
> > > 
> > > On 24/01/2021 18:07:58+, Jose Quaresma wrote:
> > > > Drop patches:
> > > > * 0001-Fix-the-link-order-of-libglslang-and-libHLSL.patch
> > > >   is rejected upstream and is not need when glslang as shared libs.
> > > > 
> > > > Update pacthes:
> > > > * 0001-cmake-de-vendor-libs-and-disable-git-versioning.patch
> > > >   renamed and refreshed from 
> > > > 0003-cmake-de-vendor-libs-and-disable-git-versioning.patch.
> > > > 
> > > 
> > > It seems there is still a linking issue when building shaderc-native.
> > > The full log is available here:
> > > 
> > > https://autobuilder.yoctoproject.org/typhoon/#/builders/40/builds/2978/steps/11/logs/stdio
> > 
> > I have a suspicion this happens on Ubuntu 18.04 systems since I've seen
> > issues like this locally with 18.04's binutils version and OE generated
> > vulkan-samples binaries, I think Joshua Watt reported the same issue
> > too with 18.04.
> > 
> > Not sure what we can do about it, can we disable the debug symbol types
> > causing problems in that -native recipe?
> 
> I tried to reproduce this and couldn't so far. I suspect what happens
> is that one of the dependencies builds on a newer system, shaderc-
> native then builds on 1804 and it can't read the binary generated by
> the newer binutils.
> 
> This is obviously a pain to setup and reproduce. The "easiest" way may
> be to build buildtools-tarball to build everything up to shaderc-
> native, then remove buildtools-tarball and build shaderc-native. I'll
> see if I can find some time to try that.
> 
> I've been holding the patches in master-next but I think we probably
> should merge them as this could well be a generic ubuntu1804 issue that
> already probably exists.

I tried this and I couldn't reproduce with master's buildtools tarball
so I guess we wait and see if it comes up again.

Cheers,

Richard


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#147453): 
https://lists.openembedded.org/g/openembedded-core/message/147453
Mute This Topic: https://lists.openembedded.org/mt/80084132/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] kernel.bbclass: fix deployment for initramfs images

2021-01-29 Thread Awais Belal
The do_bundle_initramfs() only processes kernel image
types that are found in KERNEL_IMAGETYPE_FOR_MAKE whereas
the build system can generate other types that are not
directly supported by the kernel build system. In which
case when we come to the deploy phase not all the images
mentioned in KERNEL_IMAGETYPES would have a respective
initramfs bundled image. An example is using vmlinux.gz
in KERNEL_IMAGETYPES and enabling initramfs and then we
see

install: cannot stat 'arch/arm64/boot/vmlinux.gz.initramfs': No such file or 
directory

So we align the deploy phase with bundle initramfs phase
and pick up relevant initramfs bundled images using
KERNEL_IMAGETYPE_FOR_MAKE instead of KERNEL_IMAGETYPES.

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

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index ddff2ddcd2..8693ab86be 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -759,7 +759,7 @@ kernel_do_deploy() {
fi
 
if [ ! -z "${INITRAMFS_IMAGE}" -a x"${INITRAMFS_IMAGE_BUNDLE}" = x1 ]; 
then
-   for imageType in ${KERNEL_IMAGETYPES} ; do
+   for imageType in ${KERNEL_IMAGETYPE_FOR_MAKE} ; do
if [ "$imageType" = "fitImage" ] ; then
continue
fi
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#147452): 
https://lists.openembedded.org/g/openembedded-core/message/147452
Mute This Topic: https://lists.openembedded.org/mt/80208526/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] lib/oe/patch.py: Don't return command stderr from runcmd function

2021-01-29 Thread Richard Purdie
On Fri, 2021-01-29 at 12:41 +0100, Quentin Schulz wrote:
> Hi Tomasz,
> 
> On Fri, Jan 29, 2021 at 12:38:08PM +0100, Tomasz Dziendzielski wrote:
> > If a function returns any stderr it will be passed to extractPatches and
> > used as path to patch.
> > 
> > For example subprocess command output can be:
> > > sh: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
> > > /tmp/oepatchhuqle8fj/0001-foo.patch
> > > /tmp/oepatchhuqle8fj/0002-bar.patch
> > 
> > that will result in:
> > > FileNotFoundError: [Errno 2] No such file or directory: 'sh:'
> > 
> > To fix this I separated output, made the function return stdout and
> > print stderr only in case of command error.
> > 
> > Signed-off-by: Tomasz Dziendzielski 
> > ---
> >  meta/lib/oe/patch.py | 14 +-
> >  1 file changed, 9 insertions(+), 5 deletions(-)
> > 
> > diff --git a/meta/lib/oe/patch.py b/meta/lib/oe/patch.py
> > index 40755fbb03..8ad70f53f1 100644
> > --- a/meta/lib/oe/patch.py
> > +++ b/meta/lib/oe/patch.py
> > @@ -38,15 +38,19 @@ def runcmd(args, dir = None):
> >  args = [ pipes.quote(str(arg)) for arg in args ]
> >  cmd = " ".join(args)
> >  # print("cmd: %s" % cmd)
> > -(exitstatus, output) = subprocess.getstatusoutput(cmd)
> > +proc = subprocess.Popen(cmd, stdout=subprocess.PIPE, 
> > stderr=subprocess.PIPE, shell=True)
> 
> I'd rather avoid having shell=True passed to Popen, read
> https://docs.python.org/3/library/subprocess.html#security-considerations
> 
> Can't we just use args directly instead of cmd in Popen to avoid using
> shell=True?

Whilst that would be nice, we already effectively use this all over.
I'm not adverse to cleaning up all the quoting but I think its a
separate topic. If you don't trust our metadata there are much bigger
and easier ways to run commands...

Cheers,

Richard




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#147451): 
https://lists.openembedded.org/g/openembedded-core/message/147451
Mute This Topic: https://lists.openembedded.org/mt/80207407/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] lib/oe/patch.py: Don't return command stderr from runcmd function

2021-01-29 Thread Tomasz Dziendzielski
As far as I understand subprocess.getstatusoutput is actually doing the
same and also we're using "sh -c" in that command anyway. There is one case
where "PATCHFILE="%s" is passed at the beginning of "cmd" variable so we
would need to modify this file to stop doing that and pass it through env
argument.

Best regards,
Tomasz Dziendzielski

pt., 29 sty 2021 o 12:41 Quentin Schulz 
napisał(a):

> Hi Tomasz,
>
> On Fri, Jan 29, 2021 at 12:38:08PM +0100, Tomasz Dziendzielski wrote:
> > If a function returns any stderr it will be passed to extractPatches and
> > used as path to patch.
> >
> > For example subprocess command output can be:
> > | sh: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
> > | /tmp/oepatchhuqle8fj/0001-foo.patch
> > | /tmp/oepatchhuqle8fj/0002-bar.patch
> >
> > that will result in:
> > | FileNotFoundError: [Errno 2] No such file or directory: 'sh:'
> >
> > To fix this I separated output, made the function return stdout and
> > print stderr only in case of command error.
> >
> > Signed-off-by: Tomasz Dziendzielski 
> > ---
> >  meta/lib/oe/patch.py | 14 +-
> >  1 file changed, 9 insertions(+), 5 deletions(-)
> >
> > diff --git a/meta/lib/oe/patch.py b/meta/lib/oe/patch.py
> > index 40755fbb03..8ad70f53f1 100644
> > --- a/meta/lib/oe/patch.py
> > +++ b/meta/lib/oe/patch.py
> > @@ -38,15 +38,19 @@ def runcmd(args, dir = None):
> >  args = [ pipes.quote(str(arg)) for arg in args ]
> >  cmd = " ".join(args)
> >  # print("cmd: %s" % cmd)
> > -(exitstatus, output) = subprocess.getstatusoutput(cmd)
> > +proc = subprocess.Popen(cmd, stdout=subprocess.PIPE,
> stderr=subprocess.PIPE, shell=True)
>
> I'd rather avoid having shell=True passed to Popen, read
> https://docs.python.org/3/library/subprocess.html#security-considerations
>
> Can't we just use args directly instead of cmd in Popen to avoid using
> shell=True?
>
> Cheers,
> Quentin
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#147450): 
https://lists.openembedded.org/g/openembedded-core/message/147450
Mute This Topic: https://lists.openembedded.org/mt/80207407/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 v4 4/4] shaderc: fix the build with glslang 11.1.0

2021-01-29 Thread Richard Purdie
On Thu, 2021-01-28 at 22:44 +, Richard Purdie via
lists.openembedded.org wrote:
> On Thu, 2021-01-28 at 23:38 +0100, Alexandre Belloni wrote:
> > Hello Jose,
> > 
> > On 24/01/2021 18:07:58+, Jose Quaresma wrote:
> > > Drop patches:
> > > * 0001-Fix-the-link-order-of-libglslang-and-libHLSL.patch
> > >   is rejected upstream and is not need when glslang as shared libs.
> > > 
> > > Update pacthes:
> > > * 0001-cmake-de-vendor-libs-and-disable-git-versioning.patch
> > >   renamed and refreshed from 
> > > 0003-cmake-de-vendor-libs-and-disable-git-versioning.patch.
> > > 
> > 
> > It seems there is still a linking issue when building shaderc-native.
> > The full log is available here:
> > 
> > https://autobuilder.yoctoproject.org/typhoon/#/builders/40/builds/2978/steps/11/logs/stdio
> 
> I have a suspicion this happens on Ubuntu 18.04 systems since I've seen
> issues like this locally with 18.04's binutils version and OE generated
> vulkan-samples binaries, I think Joshua Watt reported the same issue
> too with 18.04.
> 
> Not sure what we can do about it, can we disable the debug symbol types
> causing problems in that -native recipe?

I tried to reproduce this and couldn't so far. I suspect what happens
is that one of the dependencies builds on a newer system, shaderc-
native then builds on 1804 and it can't read the binary generated by
the newer binutils.

This is obviously a pain to setup and reproduce. The "easiest" way may
be to build buildtools-tarball to build everything up to shaderc-
native, then remove buildtools-tarball and build shaderc-native. I'll
see if I can find some time to try that.

I've been holding the patches in master-next but I think we probably
should merge them as this could well be a generic ubuntu1804 issue that
already probably exists.

Cheers,

Richard


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#147449): 
https://lists.openembedded.org/g/openembedded-core/message/147449
Mute This Topic: https://lists.openembedded.org/mt/80084132/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] lib/oe/patch.py: Don't return command stderr from runcmd function

2021-01-29 Thread Quentin Schulz
Hi Tomasz,

On Fri, Jan 29, 2021 at 12:38:08PM +0100, Tomasz Dziendzielski wrote:
> If a function returns any stderr it will be passed to extractPatches and
> used as path to patch.
> 
> For example subprocess command output can be:
> | sh: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
> | /tmp/oepatchhuqle8fj/0001-foo.patch
> | /tmp/oepatchhuqle8fj/0002-bar.patch
> 
> that will result in:
> | FileNotFoundError: [Errno 2] No such file or directory: 'sh:'
> 
> To fix this I separated output, made the function return stdout and
> print stderr only in case of command error.
> 
> Signed-off-by: Tomasz Dziendzielski 
> ---
>  meta/lib/oe/patch.py | 14 +-
>  1 file changed, 9 insertions(+), 5 deletions(-)
> 
> diff --git a/meta/lib/oe/patch.py b/meta/lib/oe/patch.py
> index 40755fbb03..8ad70f53f1 100644
> --- a/meta/lib/oe/patch.py
> +++ b/meta/lib/oe/patch.py
> @@ -38,15 +38,19 @@ def runcmd(args, dir = None):
>  args = [ pipes.quote(str(arg)) for arg in args ]
>  cmd = " ".join(args)
>  # print("cmd: %s" % cmd)
> -(exitstatus, output) = subprocess.getstatusoutput(cmd)
> +proc = subprocess.Popen(cmd, stdout=subprocess.PIPE, 
> stderr=subprocess.PIPE, shell=True)

I'd rather avoid having shell=True passed to Popen, read
https://docs.python.org/3/library/subprocess.html#security-considerations

Can't we just use args directly instead of cmd in Popen to avoid using
shell=True?

Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#147448): 
https://lists.openembedded.org/g/openembedded-core/message/147448
Mute This Topic: https://lists.openembedded.org/mt/80207407/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] lib/oe/patch.py: Don't return command stderr from runcmd function

2021-01-29 Thread Tomasz Dziendzielski
If a function returns any stderr it will be passed to extractPatches and
used as path to patch.

For example subprocess command output can be:
| sh: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
| /tmp/oepatchhuqle8fj/0001-foo.patch
| /tmp/oepatchhuqle8fj/0002-bar.patch

that will result in:
| FileNotFoundError: [Errno 2] No such file or directory: 'sh:'

To fix this I separated output, made the function return stdout and
print stderr only in case of command error.

Signed-off-by: Tomasz Dziendzielski 
---
 meta/lib/oe/patch.py | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/meta/lib/oe/patch.py b/meta/lib/oe/patch.py
index 40755fbb03..8ad70f53f1 100644
--- a/meta/lib/oe/patch.py
+++ b/meta/lib/oe/patch.py
@@ -38,15 +38,19 @@ def runcmd(args, dir = None):
 args = [ pipes.quote(str(arg)) for arg in args ]
 cmd = " ".join(args)
 # print("cmd: %s" % cmd)
-(exitstatus, output) = subprocess.getstatusoutput(cmd)
+proc = subprocess.Popen(cmd, stdout=subprocess.PIPE, 
stderr=subprocess.PIPE, shell=True)
+stdout, stderr = proc.communicate()
+stdout = stdout.decode('utf-8')
+stderr = stderr.decode('utf-8')
+exitstatus = proc.returncode
 if exitstatus != 0:
-raise CmdError(cmd, exitstatus >> 8, output)
-if " fuzz " in output and "Hunk " in output:
+raise CmdError(cmd, exitstatus >> 8, "stdout: %s\nstderr: %s" % 
(stdout, stderr))
+if " fuzz " in stdout and "Hunk " in stdout:
 # Drop patch fuzz info with header and footer to log file so
 # insane.bbclass can handle to throw error/warning
-bb.note("--- Patch fuzz start ---\n%s\n--- Patch fuzz end ---" % 
format(output))
+bb.note("--- Patch fuzz start ---\n%s\n--- Patch fuzz end ---" % 
format(stdout))
 
-return output
+return stdout
 
 finally:
 if dir:
-- 
2.30.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#147447): 
https://lists.openembedded.org/g/openembedded-core/message/147447
Mute This Topic: https://lists.openembedded.org/mt/80207407/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 01/13] gobject-introspection: Fix variable override order

2021-01-29 Thread Richard Purdie
On Fri, 2021-01-29 at 11:31 +0100, Quentin Schulz wrote:
> Hi Richard,
> 
> On Fri, Jan 29, 2021 at 10:24:07AM +, Richard Purdie wrote:
> > The DEPENDS variable override ordering here was almostly certainly
> > incorrect and led to weird behaviour when making changes elsewhere.
> > Correct it.
> > 
> > Signed-off-by: Richard Purdie 
> > ---
> >  .../gobject-introspection/gobject-introspection_1.66.1.bb | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git 
> > a/meta/recipes-gnome/gobject-introspection/gobject-introspection_1.66.1.bb 
> > b/meta/recipes-gnome/gobject-introspection/gobject-introspection_1.66.1.bb
> > index ee0ab2866b8..ebac8d3a432 100644
> > --- 
> > a/meta/recipes-gnome/gobject-introspection/gobject-introspection_1.66.1.bb
> > +++ 
> > b/meta/recipes-gnome/gobject-introspection/gobject-introspection_1.66.1.bb
> > @@ -28,14 +28,14 @@ GTKDOC_MESON_OPTION = "gtk_doc"
> > 
> >  MULTILIB_SCRIPTS = "${PN}:${bindir}/g-ir-annotation-tool 
> > ${PN}:${bindir}/g-ir-scanner"

> > -DEPENDS_append = " libffi zlib glib-2.0 python3 flex-native bison-native 
> > autoconf-archive"
> > +DEPENDS += " libffi zlib glib-2.0 python3 flex-native bison-native 
> > autoconf-archive"
> >  
> 
> Not sure to understand the reason for this change other than "cleanup"?
> 
> Are you expecting to be able to override DEPENDS from other recipes and
> couldn't do so because of the "_append"?
> 
> If that is the case, it seems this patch should be split in two so
> there's proper explanation?

This is a recipe, not a class so overriding from other recipes isn't an
issue here and I maintain that even the classes should really be using
+=. What is an issue is how the DEPENDS_append below interacts and also
how the native.bbclass remapping interacts with things. I was wrestling
with both of those trying to get the code to do the correct thing,
probably before realising the bigger issue was the reversed overrides
order below.

It probably is ultimately a cosmetic change but it seemed 
to make sense to clean it up whilst in here. To me, it seemed in
keeping with the other change and I was already sending enough
patches...

It is also the combination I tested and I have little interest in
separating and testing it individually without the other change which I
suspect will break.

> >  # target build needs qemu to run temporary introspection binaries created
> >  # on the fly by g-ir-scanner and a native version of itself to run
> >  # native versions of its own tools during build.
> >  # Also prelink-rtld is used to find out library dependencies of 
> > introspection binaries
> >  # (standard ldd doesn't work when cross-compiling).
> > -DEPENDS_class-target_append = " gobject-introspection-native qemu-native 
> > prelink-native"
> > +DEPENDS_append_class-target = " gobject-introspection-native qemu-native 
> > prelink-native"
> > 
> 
> Ah, the classic :)

Indeed. I do suspect there were issues in the way native class
extensions were behaving which may have lead to this :/.

Cheers,

Richard



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#147446): 
https://lists.openembedded.org/g/openembedded-core/message/147446
Mute This Topic: https://lists.openembedded.org/mt/80206621/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 01/13] gobject-introspection: Fix variable override order

2021-01-29 Thread Quentin Schulz
Hi Richard,

On Fri, Jan 29, 2021 at 10:24:07AM +, Richard Purdie wrote:
> The DEPENDS variable override ordering here was almostly certainly
> incorrect and led to weird behaviour when making changes elsewhere.
> Correct it.
> 
> Signed-off-by: Richard Purdie 
> ---
>  .../gobject-introspection/gobject-introspection_1.66.1.bb | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git 
> a/meta/recipes-gnome/gobject-introspection/gobject-introspection_1.66.1.bb 
> b/meta/recipes-gnome/gobject-introspection/gobject-introspection_1.66.1.bb
> index ee0ab2866b8..ebac8d3a432 100644
> --- a/meta/recipes-gnome/gobject-introspection/gobject-introspection_1.66.1.bb
> +++ b/meta/recipes-gnome/gobject-introspection/gobject-introspection_1.66.1.bb
> @@ -28,14 +28,14 @@ GTKDOC_MESON_OPTION = "gtk_doc"
>  
>  MULTILIB_SCRIPTS = "${PN}:${bindir}/g-ir-annotation-tool 
> ${PN}:${bindir}/g-ir-scanner"
>  
> -DEPENDS_append = " libffi zlib glib-2.0 python3 flex-native bison-native 
> autoconf-archive"
> +DEPENDS += " libffi zlib glib-2.0 python3 flex-native bison-native 
> autoconf-archive"
>  

Not sure to understand the reason for this change other than "cleanup"?

Are you expecting to be able to override DEPENDS from other recipes and
couldn't do so because of the "_append"?

If that is the case, it seems this patch should be split in two so
there's proper explanation?

>  # target build needs qemu to run temporary introspection binaries created
>  # on the fly by g-ir-scanner and a native version of itself to run
>  # native versions of its own tools during build.
>  # Also prelink-rtld is used to find out library dependencies of 
> introspection binaries
>  # (standard ldd doesn't work when cross-compiling).
> -DEPENDS_class-target_append = " gobject-introspection-native qemu-native 
> prelink-native"
> +DEPENDS_append_class-target = " gobject-introspection-native qemu-native 
> prelink-native"
>  

Ah, the classic :)

Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#147445): 
https://lists.openembedded.org/g/openembedded-core/message/147445
Mute This Topic: https://lists.openembedded.org/mt/80206621/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 09/13] apr: Fix to work with autoconf 2.70

2021-01-29 Thread Richard Purdie
Fix an issue with autoconf 2.70 where duplicate macro includes
caused configure failures.

Signed-off-by: Richard Purdie 
---
 .../recipes-support/apr/apr/autoconf270.patch | 22 +++
 meta/recipes-support/apr/apr_1.7.0.bb |  1 +
 2 files changed, 23 insertions(+)
 create mode 100644 meta/recipes-support/apr/apr/autoconf270.patch

diff --git a/meta/recipes-support/apr/apr/autoconf270.patch 
b/meta/recipes-support/apr/apr/autoconf270.patch
new file mode 100644
index 000..9f7b5c624cf
--- /dev/null
+++ b/meta/recipes-support/apr/apr/autoconf270.patch
@@ -0,0 +1,22 @@
+With autoconf 2.70 confdefs.h is already included. Including it twice generates
+compiler warnings and since this macros is to error on warnings, it breaks.
+
+Fix by not including the file.
+
+Upstream-Status: Pending
+RP - 2021/1/28
+
+Index: apr-1.7.0/build/apr_common.m4
+===
+--- apr-1.7.0.orig/build/apr_common.m4
 apr-1.7.0/build/apr_common.m4
+@@ -505,8 +505,7 @@ AC_DEFUN([APR_TRY_COMPILE_NO_WARNING],
+  fi
+  AC_COMPILE_IFELSE(
+   [AC_LANG_SOURCE(
+-   [#include "confdefs.h"
+-   ]
++   []
+[[$1]]
+[int main(int argc, const char *const *argv) {]
+[[$2]]
diff --git a/meta/recipes-support/apr/apr_1.7.0.bb 
b/meta/recipes-support/apr/apr_1.7.0.bb
index c9b9bf0f50b..f879e2864a7 100644
--- a/meta/recipes-support/apr/apr_1.7.0.bb
+++ b/meta/recipes-support/apr/apr_1.7.0.bb
@@ -23,6 +23,7 @@ SRC_URI = "${APACHE_MIRROR}/apr/${BPN}-${PV}.tar.bz2 \

file://0007-explicitly-link-libapr-against-phtread-to-make-gold-.patch \
file://libtoolize_check.patch \
file://0001-Add-option-to-disable-timed-dependant-tests.patch \
+   file://autoconf270.patch \
"
 
 SRC_URI[md5sum] = "7a14a83d664e87599ea25ff4432e48a7"
-- 
2.27.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#147440): 
https://lists.openembedded.org/g/openembedded-core/message/147440
Mute This Topic: https://lists.openembedded.org/mt/80206629/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 10/13] lrzsz: Fix to work with autoconf 2.70

2021-01-29 Thread Richard Purdie
Add the missing gettext version needed for autoconf 2.70.

Signed-off-by: Richard Purdie 
---
 .../lrzsz-0.12.20/autotools-update.patch  | 249 ++
 1 file changed, 142 insertions(+), 107 deletions(-)

diff --git a/meta/recipes-bsp/lrzsz/lrzsz-0.12.20/autotools-update.patch 
b/meta/recipes-bsp/lrzsz/lrzsz-0.12.20/autotools-update.patch
index 33af38b4a8d..4a50f7410a2 100644
--- a/meta/recipes-bsp/lrzsz/lrzsz-0.12.20/autotools-update.patch
+++ b/meta/recipes-bsp/lrzsz/lrzsz-0.12.20/autotools-update.patch
@@ -3,9 +3,10 @@ Update autotools infrastructure (including gettext) to modern 
versions.
 Upstream-Status: Pending
 Signed-off-by: Phil Blundell 
 
-diff -uprN clean/lrzsz-0.12.20/configure.in lrzsz-0.12.20/configure.in
 clean/lrzsz-0.12.20/configure.in   1998-12-30 07:50:07.0 +
-+++ lrzsz-0.12.20/configure.in 2019-11-25 16:22:37.0 +
+Index: lrzsz-0.12.20/configure.in
+===
+--- lrzsz-0.12.20.orig/configure.in
 lrzsz-0.12.20/configure.in
 @@ -92,7 +92,6 @@ AC_PROG_RANLIB
  AC_ISC_POSIX
  AC_AIX
@@ -14,7 +15,7 @@ diff -uprN clean/lrzsz-0.12.20/configure.in 
lrzsz-0.12.20/configure.in
  AC_C_CONST
  AC_C_INLINE
  
-@@ -253,18 +252,13 @@ ihave$lookup_facility
+@@ -253,18 +252,14 @@ ihave$lookup_facility
  fi
  
  
@@ -24,6 +25,7 @@ diff -uprN clean/lrzsz-0.12.20/configure.in 
lrzsz-0.12.20/configure.in
  
 -AM_GNU_GETTEXT
 +AM_GNU_GETTEXT([external])
++AM_GNU_GETTEXT_VERSION([0.21])
  
 -AC_DEFINE_UNQUOTED(LOCALEDIR,"$prefix/$DATADIRNAME")
 -AC_LINK_FILES($nls_cv_header_libgt, $nls_cv_header_intl)
@@ -36,9 +38,10 @@ diff -uprN clean/lrzsz-0.12.20/configure.in 
lrzsz-0.12.20/configure.in
 +[
  chmod +x debian/rules;
  test -z "$CONFIG_HEADERS" || echo timestamp > stamp-h])
-diff -uprN clean/lrzsz-0.12.20/intl/bindtextdom.c 
lrzsz-0.12.20/intl/bindtextdom.c
 clean/lrzsz-0.12.20/intl/bindtextdom.c 1998-04-26 14:22:36.0 
+0100
-+++ lrzsz-0.12.20/intl/bindtextdom.c   1970-01-01 01:00:00.0 +0100
+Index: lrzsz-0.12.20/intl/bindtextdom.c
+===
+--- lrzsz-0.12.20.orig/intl/bindtextdom.c
 /dev/null
 @@ -1,199 +0,0 @@
 -/* Implementation of the bindtextdomain(3) function
 -   Copyright (C) 1995, 1996, 1997 Free Software Foundation, Inc.
@@ -239,9 +242,10 @@ diff -uprN clean/lrzsz-0.12.20/intl/bindtextdom.c 
lrzsz-0.12.20/intl/bindtextdom
 -/* Alias for function name in GNU C Library.  */
 -weak_alias (__bindtextdomain, bindtextdomain);
 -#endif
-diff -uprN clean/lrzsz-0.12.20/intl/cat-compat.c 
lrzsz-0.12.20/intl/cat-compat.c
 clean/lrzsz-0.12.20/intl/cat-compat.c  1998-04-26 14:22:37.0 
+0100
-+++ lrzsz-0.12.20/intl/cat-compat.c1970-01-01 01:00:00.0 +0100
+Index: lrzsz-0.12.20/intl/cat-compat.c
+===
+--- lrzsz-0.12.20.orig/intl/cat-compat.c
 /dev/null
 @@ -1,262 +0,0 @@
 -/* Compatibility code for gettext-using-catgets interface.
 -   Copyright (C) 1995, 1997 Free Software Foundation, Inc.
@@ -505,9 +509,10 @@ diff -uprN clean/lrzsz-0.12.20/intl/cat-compat.c 
lrzsz-0.12.20/intl/cat-compat.c
 -  return dest - 1;
 -}
 -#endif
-diff -uprN clean/lrzsz-0.12.20/intl/ChangeLog lrzsz-0.12.20/intl/ChangeLog
 clean/lrzsz-0.12.20/intl/ChangeLog 1998-04-26 14:22:35.0 +0100
-+++ lrzsz-0.12.20/intl/ChangeLog   1970-01-01 01:00:00.0 +0100
+Index: lrzsz-0.12.20/intl/ChangeLog
+===
+--- lrzsz-0.12.20.orig/intl/ChangeLog
 /dev/null
 @@ -1,1022 +0,0 @@
 -1997-09-06 02:10  Ulrich Drepper  
 -
@@ -1531,9 +1536,10 @@ diff -uprN clean/lrzsz-0.12.20/intl/ChangeLog 
lrzsz-0.12.20/intl/ChangeLog
 -  which allow to use the X/Open catgets function with an interface
 -  like the Uniforum gettext function.  For system which does not
 -  have neither of those a complete implementation is provided.
-diff -uprN clean/lrzsz-0.12.20/intl/dcgettext.c lrzsz-0.12.20/intl/dcgettext.c
 clean/lrzsz-0.12.20/intl/dcgettext.c   1998-04-26 14:22:36.0 
+0100
-+++ lrzsz-0.12.20/intl/dcgettext.c 1970-01-01 01:00:00.0 +0100
+Index: lrzsz-0.12.20/intl/dcgettext.c
+===
+--- lrzsz-0.12.20.orig/intl/dcgettext.c
 /dev/null
 @@ -1,593 +0,0 @@
 -/* Implementation of the dcgettext(3) function
 -   Copyright (C) 1995, 1996, 1997 Free Software Foundation, Inc.
@@ -2128,9 +2134,10 @@ diff -uprN clean/lrzsz-0.12.20/intl/dcgettext.c 
lrzsz-0.12.20/intl/dcgettext.c
 -  return dest - 1;
 -}
 -#endif
-diff -uprN clean/lrzsz-0.12.20/intl/dgettext.c lrzsz-0.12.20/intl/dgettext.c
 clean/lrzsz-0.12.20/intl/dgettext.c1998-04-26 14:20:52.0 
+0100
-+++ lrzsz-0.12.20/intl/dgettext.c  1970-01-01 01:00:00.0 +0100
+Index: lrzsz-0.12.20/intl/dgettext.c

[OE-core] [PATCH 12/13] msmtp: Fix to work with autoconf 2.70

2021-01-29 Thread Richard Purdie
Add the required gettext version macro to work with the new autoconf
version.

Signed-off-by: Richard Purdie 
---
 .../msmtp/msmtp/autoconf270.patch   | 17 +
 meta/recipes-extended/msmtp/msmtp_1.8.14.bb |  3 ++-
 2 files changed, 19 insertions(+), 1 deletion(-)
 create mode 100644 meta/recipes-extended/msmtp/msmtp/autoconf270.patch

diff --git a/meta/recipes-extended/msmtp/msmtp/autoconf270.patch 
b/meta/recipes-extended/msmtp/msmtp/autoconf270.patch
new file mode 100644
index 000..6efd3d6d7cc
--- /dev/null
+++ b/meta/recipes-extended/msmtp/msmtp/autoconf270.patch
@@ -0,0 +1,17 @@
+Update to add the required gettext version to work with autoconf 2.70
+
+Upstream-Status: Pending
+RP - 2021/1/28
+
+Index: msmtp-1.8.14/configure.ac
+===
+--- msmtp-1.8.14.orig/configure.ac
 msmtp-1.8.14/configure.ac
+@@ -44,6 +44,7 @@ case "${target}" in *-*-mingw*) LIBS="$L
+ 
+ dnl Gettext
+ AM_GNU_GETTEXT([external])
++AM_GNU_GETTEXT_VERSION([0.21])
+ 
+ dnl Headers, functions, and types
+ AC_CHECK_HEADERS([sysexits.h netdb.h arpa/inet.h sys/select.h sys/socket.h 
sys/wait.h netinet/in.h])
diff --git a/meta/recipes-extended/msmtp/msmtp_1.8.14.bb 
b/meta/recipes-extended/msmtp/msmtp_1.8.14.bb
index 3bd5f9edeb5..c35c8e7ecc9 100644
--- a/meta/recipes-extended/msmtp/msmtp_1.8.14.bb
+++ b/meta/recipes-extended/msmtp/msmtp_1.8.14.bb
@@ -10,7 +10,8 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=d32239bcb673463ab874e80d47fae504"
 
 UPSTREAM_CHECK_URI = "https://marlam.de/msmtp/download/;
 
-SRC_URI = "https://marlam.de/${BPN}/releases/${BP}.tar.xz;
+SRC_URI = "https://marlam.de/${BPN}/releases/${BP}.tar.xz \
+   file://autoconf270.patch"
 SRC_URI[sha256sum] = 
"d56f065d711486e9c234618515a02a48a48dab4051b34f3e108fbecb6fb773b4"
 
 inherit gettext autotools update-alternatives pkgconfig
-- 
2.27.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#147443): 
https://lists.openembedded.org/g/openembedded-core/message/147443
Mute This Topic: https://lists.openembedded.org/mt/80206632/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 13/13] ruby: Fix to work with autoconf 2.70

2021-01-29 Thread Richard Purdie
Drop a macro we don't need which was breaking with autoconf 2.70.

Signed-off-by: Richard Purdie 
---
 .../ruby/ruby/autoconf270.patch   | 34 +++
 meta/recipes-devtools/ruby/ruby_2.7.2.bb  |  1 +
 2 files changed, 35 insertions(+)
 create mode 100644 meta/recipes-devtools/ruby/ruby/autoconf270.patch

diff --git a/meta/recipes-devtools/ruby/ruby/autoconf270.patch 
b/meta/recipes-devtools/ruby/ruby/autoconf270.patch
new file mode 100644
index 000..8d205bde431
--- /dev/null
+++ b/meta/recipes-devtools/ruby/ruby/autoconf270.patch
@@ -0,0 +1,34 @@
+This macro breaks under autoconf 2.70. Since we don't worry abot darwin or
+openbsd builds, simply remove it.
+
+Upstream-Status: Pending
+RP - 2021/1/28
+
+Index: ruby-2.7.2/configure.ac
+===
+--- ruby-2.7.2.orig/configure.ac
 ruby-2.7.2/configure.ac
+@@ -170,23 +170,6 @@ dnl orig_cxxflags="$cxxflags"
+ dnl cxxflags="$cxxflags "'${optflags} ${debugflags} ${warnflags}'
+ dnl ])
+ 
+-AS_CASE(["$host_os:$build_os"],
+-[darwin*:darwin*], [
+-AC_CHECK_TOOLS(CC, [clang gcc cc])
+-# Following Apple deployed clang are broken
+-# clang version 1.0 
(http://llvm.org/svn/llvm-project/cfe/tags/Apple/clang-23 exported)
+-# Apple clang version 2.0 (tags/Apple/clang-137) (based on LLVM 2.9svn)
+-# Apple clang version 2.1 (tags/Apple/clang-163.7.1) (based on LLVM 
3.0svn)
+-AS_IF([! $CC -E -xc - 

[OE-core] [PATCH 11/13] at: Upgrade 3.1.23 -> 3.2.1

2021-01-29 Thread Richard Purdie
This fixes flex issues with autoconf 2.70 rather than backporting patches.

Patches refreshed.

Signed-off-by: Richard Purdie 
---
 .../at/at/0001-remove-glibc-assumption.patch  | 23 ---
 .../at/at/file_replacement_with_gplv2.patch   |  8 +++
 .../at/at/fix_parallel_build_error.patch  | 11 -
 .../at/at/makefile-fix-parallel.patch |  8 +++
 .../at/{at_3.1.23.bb => at_3.2.1.bb}  |  5 ++--
 5 files changed, 24 insertions(+), 31 deletions(-)
 rename meta/recipes-extended/at/{at_3.1.23.bb => at_3.2.1.bb} (90%)

diff --git a/meta/recipes-extended/at/at/0001-remove-glibc-assumption.patch 
b/meta/recipes-extended/at/at/0001-remove-glibc-assumption.patch
index 7fdecc7fd1b..fd57f94cd5a 100644
--- a/meta/recipes-extended/at/at/0001-remove-glibc-assumption.patch
+++ b/meta/recipes-extended/at/at/0001-remove-glibc-assumption.patch
@@ -18,21 +18,21 @@ Signed-off-by: Dengke Du 
  parsetime.y | 11 +++
  1 file changed, 7 insertions(+), 4 deletions(-)
 
-diff --git a/parsetime.y b/parsetime.y
-index 7005e88..324e6d3 100644
 a/parsetime.y
-+++ b/parsetime.y
-@@ -8,6 +8,9 @@
- 
- #define YYDEBUG 1
+Index: at-3.2.1/parsetime.y
+===
+--- at-3.2.1.orig/parsetime.y
 at-3.2.1/parsetime.y
+@@ -14,6 +14,9 @@
+ ((y) % 4 == 0 && ((y) % 100 != 0 || (y) % 400 == 0))
+ #endif
  
 +#define is_leap_year(y) \
 +((y) % 4 == 0 && ((y) % 100 != 0 || (y) % 400 == 0))
 +
  struct tm exectm;
  static int isgmt;
- static int yearspec;
-@@ -217,8 +220,8 @@ date: month_name day_number
+ static char *tz = NULL;
+@@ -230,8 +233,8 @@ date: month_name day_number
 mnum == 12) && dnum > 31)
|| ((mnum ==  4 || mnum ==  6 || mnum ==  9 ||
 mnum == 11) && dnum > 30)
@@ -43,7 +43,7 @@ index 7005e88..324e6d3 100644
   )
{
yyerror("Error in day of month");
-@@ -261,8 +264,8 @@ date: month_name day_number
+@@ -274,8 +277,8 @@ date: month_name day_number
 mnum == 12) && dnum > 31)
|| ((mnum ==  4 || mnum ==  6 || mnum ==  9 ||
 mnum == 11) && dnum > 30)
@@ -54,6 +54,3 @@ index 7005e88..324e6d3 100644
   )
{
yyerror("Error in day of month");
--- 
-2.8.1
-
diff --git a/meta/recipes-extended/at/at/file_replacement_with_gplv2.patch 
b/meta/recipes-extended/at/at/file_replacement_with_gplv2.patch
index d5ef0032be2..11023bdf52f 100644
--- a/meta/recipes-extended/at/at/file_replacement_with_gplv2.patch
+++ b/meta/recipes-extended/at/at/file_replacement_with_gplv2.patch
@@ -10,11 +10,11 @@ update the Copyright file information to reflect the 
replaced files.
 Date: 2010/08/31
 Nitin A Kamble nitin.a.kam...@intel.com
 
-Index: at-3.1.12/Copyright
+Index: at-3.2.1/Copyright
 ===
 at-3.1.12.orig/Copyright
-+++ at-3.1.12/Copyright
-@@ -31,10 +31,10 @@ The files posixtm.c and posixtm.h have t
+--- at-3.2.1.orig/Copyright
 at-3.2.1/Copyright
+@@ -34,10 +34,10 @@ The files posixtm.c and posixtm.h have t
 Copyright (C) 1989, 1990, 1991, 1998, 2000, 2001, 2002, 2003, 2004,
 2005, 2006, 2007 Free Software Foundation Inc.
  
diff --git a/meta/recipes-extended/at/at/fix_parallel_build_error.patch 
b/meta/recipes-extended/at/at/fix_parallel_build_error.patch
index 30d2324126d..e4f32b82b6c 100644
--- a/meta/recipes-extended/at/at/fix_parallel_build_error.patch
+++ b/meta/recipes-extended/at/at/fix_parallel_build_error.patch
@@ -22,10 +22,10 @@ Signed-off-by: Chen Qi 
  Makefile.in | 2 ++
  1 file changed, 2 insertions(+)
 
-diff --git a/Makefile.in b/Makefile.in
-index 4c11913..18ecc23 100644
 a/Makefile.in
-+++ b/Makefile.in
+Index: at-3.2.1/Makefile.in
+===
+--- at-3.2.1.orig/Makefile.in
 at-3.2.1/Makefile.in
 @@ -83,6 +83,8 @@ y.tab.c y.tab.h: parsetime.y
  lex.yy.c: parsetime.l
$(LEX) -i parsetime.l
@@ -35,6 +35,3 @@ index 4c11913..18ecc23 100644
  atd.service: atd.service.in
cat $< | sed -e 's![@]sbindir[@]!$(sbindir)!g' | sed -e 
's![@]atjobdir[@]!$(atjobdir)!g' > $@
  
--- 
-2.7.4
-
diff --git a/meta/recipes-extended/at/at/makefile-fix-parallel.patch 
b/meta/recipes-extended/at/at/makefile-fix-parallel.patch
index d6056dceffa..adb8652053b 100644
--- a/meta/recipes-extended/at/at/makefile-fix-parallel.patch
+++ b/meta/recipes-extended/at/at/makefile-fix-parallel.patch
@@ -15,11 +15,11 @@ Signed-off-by: Robert Yang 
  Makefile |4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)
 
-Index: at-3.1.20/Makefile.in
+Index: at-3.2.1/Makefile.in
 

[OE-core] [PATCH 06/13] meta: Clean up various class-native* RDEPENDS overrides

2021-01-29 Thread Richard Purdie
With PACKAGES functioning more correctly for native recipes combined
with classextend improvements over the years, there are various overrides
of RDEPENDS which look unecessary now, clean them up.

There some some minor changes in dependencies, specifically:

"python3-numpy-native.do_populate_sysroot" -> 
"python3-native.do_populate_sysroot"
"python3-mako-native.do_populate_sysroot" -> 
"python3-native.do_populate_sysroot"
"itstool-native.do_populate_sysroot" -> "libxml2-native.do_populate_sysroot"

however there are already:

XXX-native.do_prepare_recipe_ssysroot -> YYY-native.do_populate_sysroot

mappings from DEPENDS so this is effectively a null op.

Signed-off-by: Richard Purdie 
---
 meta/recipes-core/dbus/dbus_1.12.20.bb|  2 --
 meta/recipes-devtools/autoconf/autoconf.inc   | 29 +--
 .../automake/automake_1.16.2.bb   |  1 -
 .../python-numpy/python3-numpy_1.19.5.bb  |  2 --
 .../python/python3-mako_1.1.4.bb  |  2 --
 meta/recipes-devtools/tcltk/tcl_8.6.11.bb |  1 -
 .../perl/libtimedate-perl_2.30.bb |  1 -
 meta/recipes-support/itstool/itstool_2.0.6.bb |  1 -
 8 files changed, 1 insertion(+), 38 deletions(-)

diff --git a/meta/recipes-core/dbus/dbus_1.12.20.bb 
b/meta/recipes-core/dbus/dbus_1.12.20.bb
index 09049301cc7..32e7d9cfa38 100644
--- a/meta/recipes-core/dbus/dbus_1.12.20.bb
+++ b/meta/recipes-core/dbus/dbus_1.12.20.bb
@@ -6,8 +6,6 @@ SECTION = "base"
 require dbus.inc
 
 DEPENDS = "expat virtual/libintl autoconf-archive"
-RDEPENDS_dbus_class-native = ""
-RDEPENDS_dbus_class-nativesdk = ""
 PACKAGES += "${@bb.utils.contains('DISTRO_FEATURES', 'ptest', '${PN}-ptest', 
'', d)}"
 ALLOW_EMPTY_dbus-ptest = "1"
 RDEPENDS_dbus-ptest_class-target = "dbus-test-ptest"
diff --git a/meta/recipes-devtools/autoconf/autoconf.inc 
b/meta/recipes-devtools/autoconf/autoconf.inc
index 868e1c8256d..03e4ca8a3ed 100644
--- a/meta/recipes-devtools/autoconf/autoconf.inc
+++ b/meta/recipes-devtools/autoconf/autoconf.inc
@@ -34,34 +34,7 @@ RDEPENDS_${PN} = "m4 gnu-config \
  perl-module-thread-queue \
  perl-module-threads \
 "
-RDEPENDS_${PN}_class-native = "m4-native gnu-config-native"
-RDEPENDS_${PN}_class-nativesdk = "\
- nativesdk-gnu-config \
- nativesdk-m4 \
- nativesdk-perl \
- nativesdk-perl-module-bytes \
- nativesdk-perl-module-carp \
- nativesdk-perl-module-constant \
- nativesdk-perl-module-data-dumper \
- nativesdk-perl-module-errno \
- nativesdk-perl-module-exporter \
- nativesdk-perl-module-file-basename \
- nativesdk-perl-module-file-compare \
- nativesdk-perl-module-file-copy \
- nativesdk-perl-module-file-find \
- nativesdk-perl-module-file-glob \
- nativesdk-perl-module-file-path \
- nativesdk-perl-module-file-spec \
- nativesdk-perl-module-file-spec-unix \
- nativesdk-perl-module-file-stat \
- nativesdk-perl-module-getopt-long \
- nativesdk-perl-module-io-file \
- nativesdk-perl-module-overloading \
- nativesdk-perl-module-posix \
- nativesdk-perl-module-symbol \
- nativesdk-perl-module-thread-queue \
- nativesdk-perl-module-threads \
-  "
+RDEPENDS_${PN}_class-native = "m4-native gnu-config-native 
hostperl-runtime-native"
 
 inherit autotools texinfo
 
diff --git a/meta/recipes-devtools/automake/automake_1.16.2.bb 
b/meta/recipes-devtools/automake/automake_1.16.2.bb
index fd8ed0ed3b8..08ec0346263 100644
--- a/meta/recipes-devtools/automake/automake_1.16.2.bb
+++ b/meta/recipes-devtools/automake/automake_1.16.2.bb
@@ -17,7 +17,6 @@ RDEPENDS_${PN} += "\
 perl-module-vars "
 
 RDEPENDS_${PN}_class-native = "autoconf-native hostperl-runtime-native"
-RDEPENDS_${PN}_class-nativesdk = "nativesdk-autoconf"
 
 SRC_URI += "file://python-libdir.patch \
 file://buildtest.patch \
diff --git a/meta/recipes-devtools/python-numpy/python3-numpy_1.19.5.bb 
b/meta/recipes-devtools/python-numpy/python3-numpy_1.19.5.bb
index 5037d2a4221..b619bf6f32a 100644
--- a/meta/recipes-devtools/python-numpy/python3-numpy_1.19.5.bb
+++ b/meta/recipes-devtools/python-numpy/python3-numpy_1.19.5.bb
@@ -53,6 +53,4 @@ RDEPENDS_${PN}-ptest += "${PYTHON_PN}-pytest \
  ldd \
 "
 
-RDEPENDS_${PN}_class-native = ""
-
 BBCLASSEXTEND = "native nativesdk"
diff --git a/meta/recipes-devtools/python/python3-mako_1.1.4.bb 
b/meta/recipes-devtools/python/python3-mako_1.1.4.bb
index 531fc6a3c0e..1645f37da44 100644
--- a/meta/recipes-devtools/python/python3-mako_1.1.4.bb
+++ b/meta/recipes-devtools/python/python3-mako_1.1.4.bb
@@ -15,6 +15,4 @@ RDEPENDS_${PN} = "${PYTHON_PN}-html \
   

[OE-core] [PATCH 07/13] gtk-doc: Disable dependencies in native case

2021-01-29 Thread Richard Purdie
Ensure that dependencies like qemu-native aren't added in the native
case since we don't want docs generate for native recipes.

Signed-off-by: Richard Purdie 
---
 meta/classes/gtk-doc.bbclass | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/classes/gtk-doc.bbclass b/meta/classes/gtk-doc.bbclass
index 7dd662bf868..ef99e63faf9 100644
--- a/meta/classes/gtk-doc.bbclass
+++ b/meta/classes/gtk-doc.bbclass
@@ -7,6 +7,7 @@
 #
 # It should be used in recipes to determine whether gtk-doc based 
documentation should be built,
 # so that qemu use can be avoided when necessary.
+GTKDOC_ENABLED_class-native = "False"
 GTKDOC_ENABLED ?= "${@bb.utils.contains('DISTRO_FEATURES', 
'api-documentation', \
   bb.utils.contains('MACHINE_FEATURES', 'qemu-usermode', 
'True', 'False', d), 'False', d)}"
 
-- 
2.27.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#147438): 
https://lists.openembedded.org/g/openembedded-core/message/147438
Mute This Topic: https://lists.openembedded.org/mt/80206627/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 08/13] pseudo: Update to include passwd and file renaming fixes

2021-01-29 Thread Richard Purdie
Pulls in:
  pseudo_client: Ensure renames update open fd file paths
  pseudo_client.c: Rebuild passwd paths after chroot

which should fix issues seen in apt package index creation, new
binutils and other autobuilder race issues in pseudo amongst other
issues.

Signed-off-by: Richard Purdie 
---
 meta/recipes-devtools/pseudo/pseudo_git.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/pseudo/pseudo_git.bb 
b/meta/recipes-devtools/pseudo/pseudo_git.bb
index 29fa9152e2d..0ba7b503551 100644
--- a/meta/recipes-devtools/pseudo/pseudo_git.bb
+++ b/meta/recipes-devtools/pseudo/pseudo_git.bb
@@ -6,7 +6,7 @@ SRC_URI = "git://git.yoctoproject.org/pseudo;branch=oe-core \
file://fallback-group \
"
 
-SRCREV = "f9754ac14672c4af19b77bc698a1a808b0828265"
+SRCREV = "8317c0ab172db47dabcef909bae02cd77b1f1010"
 S = "${WORKDIR}/git"
 PV = "1.9.0+git${SRCPV}"
 
-- 
2.27.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#147439): 
https://lists.openembedded.org/g/openembedded-core/message/147439
Mute This Topic: https://lists.openembedded.org/mt/80206628/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 05/13] native: Stop clearing PACKAGES

2021-01-29 Thread Richard Purdie
Native recipes have been special and they don't have packages generated
from them. The RDEPENDS/RPROVIDES and other runtime package specific
variables can contain important data about dependencies recipes need
though and currently it is required to write this information explicitly
in the native case.

We now delete the packaging tasks for native recipes which removes the
need to clear PACKAGES. The next step to improve the metadata is to
stop clearing it and ensure any entries in these variables are remapped
appropriately. The R* variables were already being processed by the class
extension code but the implementation was suboptimal.

This patch stops clearing PACKAGES and PACKAGES_DYNAMIC and fixes the places
where that caused issues in OE-Core, for example PACKAGES additions in anonymous
python without the "-native" suffix and a case where the included classes
caused a self reference in DEPENDS which would once have been removed by
the previous code.

The implementation uses datastore/parser parameters to ensure that the
variable overrides are not overwritten when calling setVar which is appropriate
for a function as close to the core as this one is.

Some now unneeded code in python3-setuptools is dropped, there are further
changes like this which can follow.

This change was verified with OE-Core by comparing task-depends.dot generated
by "bitbake world -g" before and after the change, the files were identical.

Signed-off-by: Richard Purdie 
---
 meta/classes/native.bbclass   | 23 ---
 .../python/python3-setuptools_51.0.0.bb   |  5 
 .../gdk-pixbuf/gdk-pixbuf_2.40.0.bb   |  1 +
 meta/recipes-graphics/mesa/mesa.inc   | 14 +++
 meta/recipes-support/boost/boost.inc  |  3 +++
 5 files changed, 22 insertions(+), 24 deletions(-)

diff --git a/meta/classes/native.bbclass b/meta/classes/native.bbclass
index 08106e345ca..a0838e41b97 100644
--- a/meta/classes/native.bbclass
+++ b/meta/classes/native.bbclass
@@ -5,20 +5,12 @@ inherit relocatable
 # no need for them to be a direct target of 'world'
 EXCLUDE_FROM_WORLD = "1"
 
-PACKAGES = ""
-PACKAGES_class-native = ""
-PACKAGES_DYNAMIC = ""
-PACKAGES_DYNAMIC_class-native = ""
 PACKAGE_ARCH = "${BUILD_ARCH}"
 
 # used by cmake class
 OECMAKE_RPATH = "${libdir}"
 OECMAKE_RPATH_class-native = "${libdir}"
 
-# When this class has packaging enabled, setting 
-# RPROVIDES becomes unnecessary.
-RPROVIDES = "${PN}"
-
 TARGET_ARCH = "${BUILD_ARCH}"
 TARGET_OS = "${BUILD_OS}"
 TARGET_VENDOR = "${BUILD_VENDOR}"
@@ -138,7 +130,7 @@ python native_virtclass_handler () {
 if "native" not in classextend:
 return
 
-def map_dependencies(varname, d, suffix = ""):
+def map_dependencies(varname, d, suffix = "", selfref=True):
 if suffix:
 varname = varname + "_" + suffix
 deps = d.getVar(varname)
@@ -148,22 +140,25 @@ python native_virtclass_handler () {
 newdeps = []
 for dep in deps:
 if dep == pn:
-continue
+if not selfref:
+continue
+newdeps.append(dep)
 elif "-cross-" in dep:
 newdeps.append(dep.replace("-cross", "-native"))
 elif not dep.endswith("-native"):
-newdeps.append(dep + "-native")
+newdeps.append(dep.replace("-native", "") + "-native")
 else:
 newdeps.append(dep)
-d.setVar(varname, " ".join(newdeps))
+d.setVar(varname, " ".join(newdeps), parsing=True)
 
-map_dependencies("DEPENDS", e.data)
-for pkg in [e.data.getVar("PN"), "", "${PN}"]:
+map_dependencies("DEPENDS", e.data, selfref=False)
+for pkg in e.data.getVar("PACKAGES", False).split():
 map_dependencies("RDEPENDS", e.data, pkg)
 map_dependencies("RRECOMMENDS", e.data, pkg)
 map_dependencies("RSUGGESTS", e.data, pkg)
 map_dependencies("RPROVIDES", e.data, pkg)
 map_dependencies("RREPLACES", e.data, pkg)
+map_dependencies("PACKAGES", e.data)
 
 provides = e.data.getVar("PROVIDES")
 nprovides = []
diff --git a/meta/recipes-devtools/python/python3-setuptools_51.0.0.bb 
b/meta/recipes-devtools/python/python3-setuptools_51.0.0.bb
index 6ee935f8f79..db336bfa13b 100644
--- a/meta/recipes-devtools/python/python3-setuptools_51.0.0.bb
+++ b/meta/recipes-devtools/python/python3-setuptools_51.0.0.bb
@@ -58,8 +58,3 @@ RDEPENDS_${PYTHON_PN}-pkg-resources = "\
   ${PYTHON_PN}-plistlib \
   ${PYTHON_PN}-pprint \
 "
-# Due to the way OE-Core implemented native recipes, the native class cannot
-# have a dependency on something that is not a recipe name. Work around that by
-# manually setting RPROVIDES.
-RDEPENDS_${PN}_append = " ${PYTHON_PN}-pkg-resources"
-RPROVIDES_append_class-native = " ${PYTHON_PN}-pkg-resources-native"
diff --git a/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.40.0.bb 

[OE-core] [PATCH 03/13] package_rpm: Clean up unset runtime package variable handling

2021-01-29 Thread Richard Purdie
If the R* runtime package variables are unset it could cause trackbacks. There
were some fallbacks already, clean this up to handle consistently.

The code was expecting strings but setting defaults of empty lists
which silently were converted to strings by the "or" statements which
was a nightmare to understand or alter.

Signed-off-by: Richard Purdie 
---
 meta/classes/package_rpm.bbclass | 40 
 1 file changed, 20 insertions(+), 20 deletions(-)

diff --git a/meta/classes/package_rpm.bbclass b/meta/classes/package_rpm.bbclass
index 53b4700cddb..43a825ad424 100644
--- a/meta/classes/package_rpm.bbclass
+++ b/meta/classes/package_rpm.bbclass
@@ -300,13 +300,13 @@ python write_specfile () {
 srccustomtagschunk = get_package_additional_metadata("rpm", localdata)
 
 srcdepends = d.getVar('DEPENDS')
-srcrdepends= []
-srcrrecommends = []
-srcrsuggests   = []
-srcrprovides   = []
-srcrreplaces   = []
-srcrconflicts  = []
-srcrobsoletes  = []
+srcrdepends= ""
+srcrrecommends = ""
+srcrsuggests   = ""
+srcrprovides   = ""
+srcrreplaces   = ""
+srcrconflicts  = ""
+srcrobsoletes  = ""
 
 srcrpreinst  = []
 srcrpostinst = []
@@ -365,13 +365,13 @@ python write_specfile () {
 # Map the dependencies into their final form
 mapping_rename_hook(localdata)
 
-splitrdepends= localdata.getVar('RDEPENDS')
-splitrrecommends = localdata.getVar('RRECOMMENDS')
-splitrsuggests   = localdata.getVar('RSUGGESTS')
-splitrprovides   = localdata.getVar('RPROVIDES')
-splitrreplaces   = localdata.getVar('RREPLACES')
-splitrconflicts  = localdata.getVar('RCONFLICTS')
-splitrobsoletes  = []
+splitrdepends= localdata.getVar('RDEPENDS') or ""
+splitrrecommends = localdata.getVar('RRECOMMENDS') or ""
+splitrsuggests   = localdata.getVar('RSUGGESTS') or ""
+splitrprovides   = localdata.getVar('RPROVIDES') or ""
+splitrreplaces   = localdata.getVar('RREPLACES') or ""
+splitrconflicts  = localdata.getVar('RCONFLICTS') or ""
+splitrobsoletes  = ""
 
 splitrpreinst  = localdata.getVar('pkg_preinst')
 splitrpostinst = localdata.getVar('pkg_postinst')
@@ -439,9 +439,9 @@ python write_specfile () {
 spec_preamble_bottom.append(splitcustomtagschunk)
 
 # Replaces == Obsoletes && Provides
-robsoletes = bb.utils.explode_dep_versions2(splitrobsoletes or "")
-rprovides = bb.utils.explode_dep_versions2(splitrprovides or "")
-rreplaces = bb.utils.explode_dep_versions2(splitrreplaces or "")
+robsoletes = bb.utils.explode_dep_versions2(splitrobsoletes)
+rprovides = bb.utils.explode_dep_versions2(splitrprovides)
+rreplaces = bb.utils.explode_dep_versions2(splitrreplaces)
 for dep in rreplaces:
 if not dep in robsoletes:
 robsoletes[dep] = rreplaces[dep]
@@ -533,9 +533,9 @@ python write_specfile () {
 tail_source(d)
 
 # Replaces == Obsoletes && Provides
-robsoletes = bb.utils.explode_dep_versions2(srcrobsoletes or "")
-rprovides = bb.utils.explode_dep_versions2(srcrprovides or "")
-rreplaces = bb.utils.explode_dep_versions2(srcrreplaces or "")
+robsoletes = bb.utils.explode_dep_versions2(srcrobsoletes)
+rprovides = bb.utils.explode_dep_versions2(srcrprovides)
+rreplaces = bb.utils.explode_dep_versions2(srcrreplaces)
 for dep in rreplaces:
 if not dep in robsoletes:
 robsoletes[dep] = rreplaces[dep]
-- 
2.27.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#147434): 
https://lists.openembedded.org/g/openembedded-core/message/147434
Mute This Topic: https://lists.openembedded.org/mt/80206623/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 04/13] bitbake.conf/python: Drop setting RDEPENDS/RPROVIDES default

2021-01-29 Thread Richard Purdie
We never recommend setting RDEPENDS or RPROVIDES without a package name
against them. The default in bitbake.conf is legacy only, drop it.

The python recipe was trying to add to the empty variable in the native case
fix that too.

Signed-off-by: Richard Purdie 
---
 meta/conf/bitbake.conf| 2 --
 meta/recipes-devtools/python/python3_3.9.1.bb | 2 +-
 2 files changed, 1 insertion(+), 3 deletions(-)

diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index af1b3b8c3e2..790859e8ae1 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -272,10 +272,8 @@ DEPCHAIN_PRE = ""
 DEPCHAIN_POST = "-dev -dbg"
 
 DEPENDS = ""
-RDEPENDS = ""
 PROVIDES = ""
 PROVIDES_prepend = "${PN} "
-RPROVIDES = ""
 
 MULTI_PROVIDER_WHITELIST = "virtual/libintl virtual/libintl-native 
virtual/nativesdk-libintl virtual/xserver virtual/update-alternatives-native 
virtual/update-alternatives"
 
diff --git a/meta/recipes-devtools/python/python3_3.9.1.bb 
b/meta/recipes-devtools/python/python3_3.9.1.bb
index a89122f9494..a2dc572672c 100644
--- a/meta/recipes-devtools/python/python3_3.9.1.bb
+++ b/meta/recipes-devtools/python/python3_3.9.1.bb
@@ -240,7 +240,7 @@ python(){
 # First set RPROVIDES for -native case
 # Hardcoded since it cant be python3-native-foo, should be 
python3-foo-native
 pn = 'python3'
-rprovides = d.getVar('RPROVIDES').split()
+rprovides = (d.getVar('RPROVIDES') or "").split()
 
 # ${PN}-misc-native is not in the manifest
 rprovides.append(pn + '-misc-native')
-- 
2.27.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#147435): 
https://lists.openembedded.org/g/openembedded-core/message/147435
Mute This Topic: https://lists.openembedded.org/mt/80206624/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 01/13] gobject-introspection: Fix variable override order

2021-01-29 Thread Richard Purdie
The DEPENDS variable override ordering here was almostly certainly
incorrect and led to weird behaviour when making changes elsewhere.
Correct it.

Signed-off-by: Richard Purdie 
---
 .../gobject-introspection/gobject-introspection_1.66.1.bb | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git 
a/meta/recipes-gnome/gobject-introspection/gobject-introspection_1.66.1.bb 
b/meta/recipes-gnome/gobject-introspection/gobject-introspection_1.66.1.bb
index ee0ab2866b8..ebac8d3a432 100644
--- a/meta/recipes-gnome/gobject-introspection/gobject-introspection_1.66.1.bb
+++ b/meta/recipes-gnome/gobject-introspection/gobject-introspection_1.66.1.bb
@@ -28,14 +28,14 @@ GTKDOC_MESON_OPTION = "gtk_doc"
 
 MULTILIB_SCRIPTS = "${PN}:${bindir}/g-ir-annotation-tool 
${PN}:${bindir}/g-ir-scanner"
 
-DEPENDS_append = " libffi zlib glib-2.0 python3 flex-native bison-native 
autoconf-archive"
+DEPENDS += " libffi zlib glib-2.0 python3 flex-native bison-native 
autoconf-archive"
 
 # target build needs qemu to run temporary introspection binaries created
 # on the fly by g-ir-scanner and a native version of itself to run
 # native versions of its own tools during build.
 # Also prelink-rtld is used to find out library dependencies of introspection 
binaries
 # (standard ldd doesn't work when cross-compiling).
-DEPENDS_class-target_append = " gobject-introspection-native qemu-native 
prelink-native"
+DEPENDS_append_class-target = " gobject-introspection-native qemu-native 
prelink-native"
 
 # needed for writing out the qemu wrapper script
 export STAGING_DIR_HOST
-- 
2.27.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#147432): 
https://lists.openembedded.org/g/openembedded-core/message/147432
Mute This Topic: https://lists.openembedded.org/mt/80206621/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 02/13] nativesdk-buildtools-perl-dummy: Add missing entries for nativesdk-automake

2021-01-29 Thread Richard Purdie
This allows the hardcoded nativesdk dependency hacking in the
automake recipe to be dropped and matches what autoconf is doing.

Signed-off-by: Richard Purdie 
---
 meta/recipes-core/meta/nativesdk-buildtools-perl-dummy.bb | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/meta/recipes-core/meta/nativesdk-buildtools-perl-dummy.bb 
b/meta/recipes-core/meta/nativesdk-buildtools-perl-dummy.bb
index cfa41c4ae63..cce086caf2a 100644
--- a/meta/recipes-core/meta/nativesdk-buildtools-perl-dummy.bb
+++ b/meta/recipes-core/meta/nativesdk-buildtools-perl-dummy.bb
@@ -21,9 +21,12 @@ DUMMYPROVIDES_PACKAGES = "\
 nativesdk-perl-module-io-file \
 nativesdk-perl-module-overloading \
 nativesdk-perl-module-posix \
+nativesdk-perl-module-strict \
+nativesdk-perl-module-text-parsewords \
 nativesdk-perl-module-thread-queue \
 nativesdk-perl-module-threads \
 nativesdk-perl-module-warnings \
+nativesdk-perl-module-vars \
 "
 
 DUMMYPROVIDES = "\
-- 
2.27.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#147433): 
https://lists.openembedded.org/g/openembedded-core/message/147433
Mute This Topic: https://lists.openembedded.org/mt/80206622/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] buildhistory.bbclass: avoid exception for empty BUILDHISTORY_FEATURES variable

2021-01-29 Thread Peter Bergin
An exception is fired when a BuildStarted event is sent to buildhistory bbclass
and the variable BUILDHISTORY_FEATURES is not set.

ERROR: Execution of event handler 'buildhistory_eventhandler' failed
Traceback (most recent call last):
  File "<...>/meta/classes/buildhistory.bbclass", line 862, in 
buildhistory_eventhandler(e=):
 python buildhistory_eventhandler() {
>if e.data.getVar('BUILDHISTORY_FEATURES').strip():
 reset = e.data.getVar("BUILDHISTORY_RESET")
AttributeError: 'NoneType' object has no attribute 'strip'

This can happen in a multiconfig build where the default configuration use the
buildhistory class but not the configuration in mc. It should be a rare case 
that
this happens and it was found in a missconfigured build.

Signed-off-by: Peter Bergin 
---
This should be a rare configuration but it possible to reproduce on oe-core
with the following setup:

$ . ./oe-init-build-env build-mc
$ mkdir conf/multiconfig
$ echo "INHERIT += 'buildhistory'" >> conf/auto.conf
$ echo "BBMULTICONFIG = 'altconf'" >> conf/auto.conf
$ echo "INHERIT_remove += 'buildhistory'" >> conf/multiconfig/altconf.conf
$ bitbake core-image-base


 meta/classes/buildhistory.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/buildhistory.bbclass 
b/meta/classes/buildhistory.bbclass
index daae056144..117a44eaf3 100644
--- a/meta/classes/buildhistory.bbclass
+++ b/meta/classes/buildhistory.bbclass
@@ -859,7 +859,7 @@ END
 }
 
 python buildhistory_eventhandler() {
-if e.data.getVar('BUILDHISTORY_FEATURES').strip():
+if (e.data.getVar('BUILDHISTORY_FEATURES') or "").strip():
 reset = e.data.getVar("BUILDHISTORY_RESET")
 olddir = e.data.getVar("BUILDHISTORY_OLD_DIR")
 if isinstance(e, bb.event.BuildStarted):
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#147431): 
https://lists.openembedded.org/g/openembedded-core/message/147431
Mute This Topic: https://lists.openembedded.org/mt/80206240/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] sanity.bbclass: verify that user isn't building in PSEUDO_IGNORE_PATHS

2021-01-29 Thread Chen Qi

Hi Richard,

I've sent out the patches. They are tested with:
1. bitbake IMAGE && bitbake IMAGE -c populate_sdk
2. bitbake world
3. bitbake IMAGE -c populate_sdk_ext; Install the eSDK

The world build covers all oe-core recipes and part of the recipes in 
some other meta layers such as meta-openembedded, meta-virtualization, 
meta-secure-core, etc. The recipe number is about 2000.


Best Regards,
Chen Qi

On 01/27/2021 05:49 PM, Richard Purdie wrote:

Hi,

On Wed, 2021-01-27 at 17:46 +0800, ChenQi wrote:

  Is it possible to use an opposite way for pseudo path filtering?
  Instead of ignoring paths, only take into consideration paths in
something like PSEUDO_CONSIDER_PATHS.
  The list should be short. ${D}, ${PKGD}, ${PKGDEST},
${IMAGE_ROOTFS}?

Its a good question, I was convinced by the pseudo authors that it was
a bad idea. The reason being that it isn't just the above paths but we
also need to catch calls where files are transiently in other
directories or in other parts of the filesystem such as /tmp/. Code
creates files in interesting and convoluted ways to preserve
permissions, for security reasons and so on and there was a worry that
masking just a specific list would cause a different set of problems.
It probably shouldn't be crossing filesystem boundaries doing it but I
know there were complications due to it.

That said, now that pseudo can support path filtering, it may be worth
an experiment to see how whether it could work better than what we're
doing now. The algorithm (whether its include or exclude) should be
relatively easy to test.

I can also say the above list would need expanding as some sstate
objects need to preserve ownership/permissions during creating and so
on. It probably would still be simpler than our current ignore list
though.

Cheers,

Richard








-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#147430): 
https://lists.openembedded.org/g/openembedded-core/message/147430
Mute This Topic: https://lists.openembedded.org/mt/80117826/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] [RFC] openssl: Enable cryptodev-linux by default

2021-01-29 Thread Diego Santa Cruz via lists.openembedded.org
> -Original Message-
> From: openembedded-core@lists.openembedded.org  c...@lists.openembedded.org> On Behalf Of Khem Raj via
> lists.openembedded.org
> Sent: 29 January 2021 02:16
> To: Tom Hochstein ; openembedded-
> c...@lists.openembedded.org
> Cc: ota...@ossystems.com.br
> Subject: Re: [OE-core] [PATCH] [RFC] openssl: Enable cryptodev-linux by
> default
> 
> 
> 
> On 1/28/21 1:35 PM, Tom Hochstein wrote:
> > This is a Request for Comment. Would it be a good idea to enable
> cryptodev-linux
> > by default, gaining hardware acceleration where supported? Are there any
> > unacceptable drawbacks? What happens on hardware without
> acceleration?
> >
> 
> this perhaps helps with devices that include a hardware crypto device
> but not as much with one;s thats fine but we use qemu machines quite a
> bit in testing so it would be good to get a readout on qemu secondly, if
> it does not, then maybe we should see if defining it via
> MACHINE_FEATUREs might be an option to enable it.
> 

I think that making it a MACHINE_FEATURES would effectively make the task 
signatures for openssl be machine dependent and that would also make all 
recipes which depend directly or indirectly on openssl (and there are a lot!) 
have their task signatures be machine dependent, so they would need to have 
their PACKAGE_ARCH set to MACHINE_ARCH to avoid triggering spurious rebuilds 
when switching between machines with and without cryptodev-linux in 
MACHINE_FEATURES.

So MACHINE_FEATURES does not look like a viable option, a DISTRO_FEATURES might 
be, although it does not really look like a nice fit either.

> > Signed-off-by: Tom Hochstein 
> > ---
> >   meta/recipes-connectivity/openssl/openssl_1.1.1i.bb | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/meta/recipes-connectivity/openssl/openssl_1.1.1i.bb
> b/meta/recipes-connectivity/openssl/openssl_1.1.1i.bb
> > index 5617f337e0..d4c19f1a52 100644
> > --- a/meta/recipes-connectivity/openssl/openssl_1.1.1i.bb
> > +++ b/meta/recipes-connectivity/openssl/openssl_1.1.1i.bb
> > @@ -28,7 +28,7 @@ SRC_URI[sha256sum] =
> "e8be6a35fe41d10603c3cc635e93289ed00bf34b79671a3a4de64fcee0
> >   inherit lib_package multilib_header multilib_script ptest
> >   MULTILIB_SCRIPTS = "${PN}-bin:${bindir}/c_rehash"
> >
> > -PACKAGECONFIG ?= ""
> > +PACKAGECONFIG ?= "cryptodev-linux"
> >   PACKAGECONFIG_class-native = ""
> >   PACKAGECONFIG_class-nativesdk = ""
> >
> >
> >
> >
> >
> >

-- 
Diego Santa Cruz, PhD
Technology Architect
spinetix.com

 

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



[OE-core][PATCH 3/3] libc-package: add locale stash related dirs to PSEUDO_CONSIDER_PATHS

2021-01-29 Thread Chen Qi
The locale stash related directories need to be considered, otherwise,
there will be QA warning for glibc-locale about host contamination.

Signed-off-by: Chen Qi 
---
 meta/classes/libc-package.bbclass | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/classes/libc-package.bbclass 
b/meta/classes/libc-package.bbclass
index de3b4250c7..d947cb6a7c 100644
--- a/meta/classes/libc-package.bbclass
+++ b/meta/classes/libc-package.bbclass
@@ -54,6 +54,7 @@ localedef --delete-from-archive 
--inputfile=${datadir}/locales/%s --charmap=%s %
 }
 
 LOCALETREESRC ?= "${PKGD}"
+PSEUDO_CONSIDER_PATHS .= 
",${WORKDIR}/locale-tree,${WORKDIR}/stashed-locale,${COMPONENTS_DIR}/${PACKAGE_ARCH}/glibc-stash-locale"
 
 do_prep_locale_tree() {
treedir=${WORKDIR}/locale-tree
-- 
2.17.1


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



[OE-core][PATCH 2/3] bitbake.conf: use PSEUDO_CONSIDER_PATHS

2021-01-29 Thread Chen Qi
Instead of ignoring paths for pseudo path filtering, we use the opposite
logic to only take into consideration a few paths we care about.

Signed-off-by: Chen Qi 
---
 meta/conf/bitbake.conf | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index fd31c3f18d..cae319287c 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -687,15 +687,15 @@ SRC_URI = ""
 PSEUDO_LOCALSTATEDIR ?= "${WORKDIR}/pseudo/"
 PSEUDO_PASSWD ?= "${STAGING_DIR_TARGET}:${PSEUDO_SYSROOT}"
 PSEUDO_SYSROOT = "${COMPONENTS_DIR}/${BUILD_ARCH}/pseudo-native"
-PSEUDO_IGNORE_PATHS = 
"/usr/,/etc/,/lib,/dev/,/run/,${T},${RECIPE_SYSROOT},${SSTATE_DIR},${STAMPS_DIR},${WORKDIR}/pkgdata-sysroot,${TMPDIR}/sstate-control,${DEPLOY_DIR},${WORKDIR}/deploy-,${TMPDIR}/buildstats,${WORKDIR}/sstate-build-package_,${WORKDIR}/sstate-install-package_,${WORKDIR}/sstate-build-image_complete,${TMPDIR}/sysroots-components,${BUILDHISTORY_DIR},${TMPDIR}/pkgdata,${TOPDIR}/cache,${COREBASE}/scripts,${CCACHE_DIR}"
+PSEUDO_CONSIDER_PATHS = "${D},${PKGD},${PKGDEST},${IMAGE_ROOTFS},${SDK_OUTPUT}"
 
 export PSEUDO_DISABLED = "1"
 #export PSEUDO_PREFIX = "${STAGING_DIR_NATIVE}${prefix_native}"
 #export PSEUDO_BINDIR = "${STAGING_DIR_NATIVE}${bindir_native}"
 #export PSEUDO_LIBDIR = "${STAGING_DIR_NATIVE}$PSEUDOBINDIR/../lib/pseudo/lib
-FAKEROOTBASEENV = "PSEUDO_BINDIR=${PSEUDO_SYSROOT}${bindir_native} 
PSEUDO_LIBDIR=${PSEUDO_SYSROOT}${prefix_native}/lib/pseudo/lib 
PSEUDO_PREFIX=${PSEUDO_SYSROOT}${prefix_native} 
PSEUDO_IGNORE_PATHS=${@oe.path.canonicalize(d.getVar('PSEUDO_IGNORE_PATHS'))} 
PSEUDO_DISABLED=1 PYTHONDONTWRITEBYTECODE=1"
+FAKEROOTBASEENV = "PSEUDO_BINDIR=${PSEUDO_SYSROOT}${bindir_native} 
PSEUDO_LIBDIR=${PSEUDO_SYSROOT}${prefix_native}/lib/pseudo/lib 
PSEUDO_PREFIX=${PSEUDO_SYSROOT}${prefix_native} 
PSEUDO_CONSIDER_PATHS=${@oe.path.canonicalize(d.getVar('PSEUDO_CONSIDER_PATHS'))}
 PSEUDO_DISABLED=1 PYTHONDONTWRITEBYTECODE=1"
 FAKEROOTCMD = "${PSEUDO_SYSROOT}${bindir_native}/pseudo"
-FAKEROOTENV = "PSEUDO_PREFIX=${PSEUDO_SYSROOT}${prefix_native} 
PSEUDO_LOCALSTATEDIR=${PSEUDO_LOCALSTATEDIR} PSEUDO_PASSWD=${PSEUDO_PASSWD} 
PSEUDO_NOSYMLINKEXP=1 
PSEUDO_IGNORE_PATHS=${@oe.path.canonicalize(d.getVar('PSEUDO_IGNORE_PATHS'))} 
PSEUDO_DISABLED=0"
+FAKEROOTENV = "PSEUDO_PREFIX=${PSEUDO_SYSROOT}${prefix_native} 
PSEUDO_LOCALSTATEDIR=${PSEUDO_LOCALSTATEDIR} PSEUDO_PASSWD=${PSEUDO_PASSWD} 
PSEUDO_NOSYMLINKEXP=1 
PSEUDO_CONSIDER_PATHS=${@oe.path.canonicalize(d.getVar('PSEUDO_CONSIDER_PATHS'))}
 PSEUDO_DISABLED=0"
 FAKEROOTNOENV = "PSEUDO_UNLOAD=1"
 FAKEROOTDIRS = "${PSEUDO_LOCALSTATEDIR}"
 PREFERRED_PROVIDER_virtual/fakeroot-native ?= "pseudo-native"
@@ -886,7 +886,7 @@ BB_HASHEXCLUDE_COMMON ?= "TMPDIR FILE PATH PWD BB_TASKHASH 
BBPATH BBSERVER DL_DI
 BB_WORKERCONTEXT BB_LIMITEDDEPS BB_UNIHASH extend_recipe_sysroot 
DEPLOY_DIR \
 SSTATE_HASHEQUIV_METHOD SSTATE_HASHEQUIV_REPORT_TASKDATA \
 SSTATE_HASHEQUIV_OWNER CCACHE_TOP_DIR BB_HASHSERVE GIT_CEILING_DIRECTORIES"
-BB_HASHBASE_WHITELIST ?= "${BB_HASHEXCLUDE_COMMON} PSEUDO_IGNORE_PATHS 
BUILDHISTORY_DIR SSTATE_DIR "
+BB_HASHBASE_WHITELIST ?= "${BB_HASHEXCLUDE_COMMON} PSEUDO_CONSIDER_PATHS 
BUILDHISTORY_DIR SSTATE_DIR "
 BB_HASHCONFIG_WHITELIST ?= "${BB_HASHEXCLUDE_COMMON} DATE TIME SSH_AGENT_PID \
 SSH_AUTH_SOCK PSEUDO_BUILD BB_ENV_EXTRAWHITE DISABLE_SANITY_CHECKS \
 PARALLEL_MAKE BB_NUMBER_THREADS BB_ORIGENV BB_INVALIDCONF BBINCLUDED \
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#147427): 
https://lists.openembedded.org/g/openembedded-core/message/147427
Mute This Topic: https://lists.openembedded.org/mt/80205584/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/3] pseudo: use PSEUDO_CONSIDER_PATHS for path filetering

2021-01-29 Thread Chen Qi
Patch pseudo to only take into consideration paths we care about.
Use PSEUDO_CONSIDER_PATHS to hold the paths. The behavior of this
var is the opposite of PSEUDO_IGNORE_PATHS.

Signed-off-by: Chen Qi 
---
 ...DO_CONSIDER_PATHS-for-path-filtering.patch | 55 +++
 meta/recipes-devtools/pseudo/pseudo_git.bb|  1 +
 2 files changed, 56 insertions(+)
 create mode 100644 
meta/recipes-devtools/pseudo/files/0001-pseudo-use-PSEUDO_CONSIDER_PATHS-for-path-filtering.patch

diff --git 
a/meta/recipes-devtools/pseudo/files/0001-pseudo-use-PSEUDO_CONSIDER_PATHS-for-path-filtering.patch
 
b/meta/recipes-devtools/pseudo/files/0001-pseudo-use-PSEUDO_CONSIDER_PATHS-for-path-filtering.patch
new file mode 100644
index 00..e17a2f1459
--- /dev/null
+++ 
b/meta/recipes-devtools/pseudo/files/0001-pseudo-use-PSEUDO_CONSIDER_PATHS-for-path-filtering.patch
@@ -0,0 +1,55 @@
+From 683c6e39e214b34b6ecc77684ebfdfef38a2b1e1 Mon Sep 17 00:00:00 2001
+From: Chen Qi 
+Date: Wed, 27 Jan 2021 18:31:26 -0800
+Subject: [PATCH] pseudo: use PSEUDO_CONSIDER_PATHS for path filtering
+
+Signed-off-by: Chen Qi 
+---
+ pseudo_client.c | 8 
+ pseudo_util.c   | 2 +-
+ 2 files changed, 5 insertions(+), 5 deletions(-)
+
+diff --git a/pseudo_client.c b/pseudo_client.c
+index 6310b99..5ac0702 100644
+--- a/pseudo_client.c
 b/pseudo_client.c
+@@ -1543,19 +1543,19 @@ int pseudo_client_ignore_path_chroot(const char *path, 
int ignore_chroot) {
+   if (ignore_chroot && pseudo_chroot && strncmp(path, pseudo_chroot, 
pseudo_chroot_len) == 0)
+   return 0;
+ 
+-  env = pseudo_get_value("PSEUDO_IGNORE_PATHS");
++  env = pseudo_get_value("PSEUDO_CONSIDER_PATHS");
+   if (!env)
+   return 0;
+ 
+-  int ret = 0;
++  int ret = 1;
+   char *p = env;
+   while (p) {
+   char *next = strchr(p, ',');
+   if (next)
+   *next++ = '\0';
+   if (*p && !strncmp(path, p, strlen(p))) {
+-  pseudo_debug(PDBGF_PATH | PDBGF_VERBOSE, "ignoring 
path: '%s'\n", path);
+-  ret = 1;
++  pseudo_debug(PDBGF_PATH | PDBGF_VERBOSE, "considering 
path: '%s'\n", path);
++  ret = 0;
+   break;
+   }
+   p = next;
+diff --git a/pseudo_util.c b/pseudo_util.c
+index b6980c2..065d975 100644
+--- a/pseudo_util.c
 b/pseudo_util.c
+@@ -43,7 +43,7 @@ static struct pseudo_variables pseudo_env[] = {
+   { "PSEUDO_BINDIR", 13, NULL },
+   { "PSEUDO_LIBDIR", 13, NULL },
+   { "PSEUDO_LOCALSTATEDIR", 20, NULL },
+-  { "PSEUDO_IGNORE_PATHS", 19, NULL },
++  { "PSEUDO_CONSIDER_PATHS", 21, NULL },
+   { "PSEUDO_PASSWD", 13, NULL },
+   { "PSEUDO_CHROOT", 13, NULL },
+   { "PSEUDO_UIDS", 11, NULL },
+-- 
+2.29.2
+
diff --git a/meta/recipes-devtools/pseudo/pseudo_git.bb 
b/meta/recipes-devtools/pseudo/pseudo_git.bb
index 29fa9152e2..ca9dc96c99 100644
--- a/meta/recipes-devtools/pseudo/pseudo_git.bb
+++ b/meta/recipes-devtools/pseudo/pseudo_git.bb
@@ -2,6 +2,7 @@ require pseudo.inc
 
 SRC_URI = "git://git.yoctoproject.org/pseudo;branch=oe-core \
file://0001-configure-Prune-PIE-flags.patch \
+   
file://0001-pseudo-use-PSEUDO_CONSIDER_PATHS-for-path-filtering.patch \
file://fallback-passwd \
file://fallback-group \
"
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#147426): 
https://lists.openembedded.org/g/openembedded-core/message/147426
Mute This Topic: https://lists.openembedded.org/mt/80205583/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/7] ncurses: Don't put terminfo into the sysroot

2021-01-29 Thread Mikko Rapeli
On Thu, Jan 28, 2021 at 04:38:08PM +, Richard Purdie wrote:
> On Thu, 2021-01-28 at 08:45 +, mikko.rap...@bmw.de wrote:
> > Interesting series! Do you already have some numbers how this affects
> > bitbake builds?
> 
> We do now have measurements:
> 
> https://autobuilder.yocto.io/pub/non-release/20210128-10/testresults/buildperf-centos7/perf-centos7.yoctoproject.org_master-next_20210128130350_0ec9fb3f98.html
> 
> https://autobuilder.yocto.io/pub/non-release/20210128-9/testresults/buildperf-ubuntu1604/perf-ubuntu1604_master-next_20210128130346_0ec9fb3f98.html
> 
> so a 5-7% build time speedup with and without rm_work and a 7%
> reduction in disk usage without rm_work.

Awesome! Thanks, Richard!

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