[OE-core][PATCH v5] patch.py: Initialize git repo before patching

[Pavel Zhukov]

From: Pavel Zhukov 

If PATCHTOOL="git" has been specified but workdir is not git repo
bitbake fails to apply the patches with error message:
Command Error: 'git rev-parse --show-toplevel' exited with 0  Output:
fatal: not a git repository (or any of the parent directories): .git

Fix this by initializing the repo before patching.
This allows binary git patches to be applied.

Signed-off-by: Pavel Zhukov 
---
 meta/lib/oe/patch.py| 16 +++-
 meta/lib/oeqa/selftest/cases/bbtests.py | 15 +++
 2 files changed, 30 insertions(+), 1 deletion(-)

diff --git a/meta/lib/oe/patch.py b/meta/lib/oe/patch.py
index fccbedb519..950fe723dc 100644
--- a/meta/lib/oe/patch.py
+++ b/meta/lib/oe/patch.py
@@ -4,6 +4,7 @@
 
 import oe.path
 import oe.types
+import subprocess
 
 class NotFoundError(bb.BBHandledException):
 def __init__(self, path):
@@ -25,7 +26,6 @@ class CmdError(bb.BBHandledException):
 
 def runcmd(args, dir = None):
 import pipes
-import subprocess
 
 if dir:
 olddir = os.path.abspath(os.curdir)
@@ -56,6 +56,7 @@ def runcmd(args, dir = None):
 if dir:
 os.chdir(olddir)
 
+
 class PatchError(Exception):
 def __init__(self, msg):
 self.msg = msg
@@ -298,6 +299,19 @@ class GitApplyTree(PatchTree):
 PatchTree.__init__(self, dir, d)
 self.commituser = d.getVar('PATCH_GIT_USER_NAME')
 self.commitemail = d.getVar('PATCH_GIT_USER_EMAIL')
+if not self._isInitialized():
+self._initRepo()
+
+def _isInitialized(self):
+cmd = "git rev-parse --show-toplevel"
+(status, output) = subprocess.getstatusoutput(cmd.split())
+## Make sure repo is in builddir to not break top-level git repos
+return status == 0 and os.path.samedir(output, self.dir)
+
+def _initRepo(self):
+runcmd("git init".split(), self.dir)
+runcmd("git add .".split(), self.dir)
+runcmd("git commit -a --allow-empty -m Patching_started".split(), 
self.dir)
 
 @staticmethod
 def extractPatchHeader(patchfile):
diff --git a/meta/lib/oeqa/selftest/cases/bbtests.py 
b/meta/lib/oeqa/selftest/cases/bbtests.py
index 6779e62103..a74576bc02 100644
--- a/meta/lib/oeqa/selftest/cases/bbtests.py
+++ b/meta/lib/oeqa/selftest/cases/bbtests.py
@@ -297,3 +297,18 @@ INHERIT:remove = \"report-error\"
 
 test_recipe_summary_after = get_bb_var('SUMMARY', test_recipe)
 self.assertEqual(expected_recipe_summary, test_recipe_summary_after)
+
+def test_git_patchtool(self):
+""" PATCHTOOL=git should work with non-git sources like tarballs
+test recipe for the test must NOT containt git:// repository in 
SRC_URI
+"""
+test_recipe = "man-db"
+self.write_recipeinc(test_recipe, 'PATCHTOOL=\"git\"')
+src = get_bb_var("SRC_URI",test_recipe)
+gitscm = re.search("git://", src)
+self.assertFalse(gitscm, "test_git_patchtool pre-condition failed: {} 
test recipe contains git repo!".format(test_recipe))
+result = bitbake('man-db -c patch', ignore_status=False)
+fatal = re.search("fatal: not a git repository (or any of the parent 
directories)", result.output)
+self.assertFalse(fatal, "Failed to patch using PATCHTOOL=\"git\"")
+self.delete_recipeinc(test_recipe)
+bitbake('-cclean man-db')
-- 
2.34.0


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

[OE-core] [hardknott][PATCH] glibc: Backport fix for CVE-2021-43396

[Pgowda]

Backport the fix for CVE-2021-43396. It is disputed that this is a
security issue.

(From OE-Core rev: e8de9b01c6b305b2498c5f942397a49ae2af0cde)

Signed-off-by: pgowda 
---
 .../glibc/glibc/0031-CVE-2021-43396.patch | 188 ++
 meta/recipes-core/glibc/glibc_2.33.bb |   1 +
 2 files changed, 189 insertions(+)
 create mode 100644 meta/recipes-core/glibc/glibc/0031-CVE-2021-43396.patch

diff --git a/meta/recipes-core/glibc/glibc/0031-CVE-2021-43396.patch 
b/meta/recipes-core/glibc/glibc/0031-CVE-2021-43396.patch
new file mode 100644
index 00..179b0c559d
--- /dev/null
+++ b/meta/recipes-core/glibc/glibc/0031-CVE-2021-43396.patch
@@ -0,0 +1,188 @@
+From ff012870b2c02a62598c04daa1e54632e020fd7d Mon Sep 17 00:00:00 2001
+From: Nikita Popov 
+Date: Tue, 2 Nov 2021 13:21:42 +0500
+Subject: [PATCH] gconv: Do not emit spurious NUL character in ISO-2022-JP-3
+ (bug 28524)
+
+Bugfix 27256 has introduced another issue:
+In conversion from ISO-2022-JP-3 encoding, it is possible
+to force iconv to emit extra NUL character on internal state reset.
+To do this, it is sufficient to feed iconv with escape sequence
+which switches active character set.
+The simplified check 'data->__statep->__count != ASCII_set'
+introduced by the aforementioned bugfix picks that case and
+behaves as if '\0' character has been queued thus emitting it.
+
+To eliminate this issue, these steps are taken:
+* Restore original condition
+'(data->__statep->__count & ~7) != ASCII_set'.
+It is necessary since bits 0-2 may contain
+number of buffered input characters.
+* Check that queued character is not NUL.
+Similar step is taken for main conversion loop.
+
+Bundled test case follows following logic:
+* Try to convert ISO-2022-JP-3 escape sequence
+switching active character set
+* Reset internal state by providing NULL as input buffer
+* Ensure that nothing has been converted.
+
+Signed-off-by: Nikita Popov 
+
+CVE: CVE-2021-43396
+Upstream-Status: Backport [ff012870b2c02a62598c04daa1e54632e020fd7d]
+---
+ iconvdata/Makefile|  5 +++-
+ iconvdata/bug-iconv15.c   | 60 +++
+ iconvdata/iso-2022-jp-3.c | 28 --
+ 3 files changed, 84 insertions(+), 9 deletions(-)
+ create mode 100644 iconvdata/bug-iconv15.c
+
+diff --git a/iconvdata/Makefile b/iconvdata/Makefile
+index c216f959df..d5507a048c 100644
+--- a/iconvdata/Makefile
 b/iconvdata/Makefile
+@@ -1,4 +1,5 @@
+ # Copyright (C) 1997-2021 Free Software Foundation, Inc.
++# Copyright (C) The GNU Toolchain Authors.
+ # This file is part of the GNU C Library.
+ 
+ # The GNU C Library is free software; you can redistribute it and/or
+@@ -74,7 +75,7 @@ ifeq (yes,$(build-shared))
+ tests = bug-iconv1 bug-iconv2 tst-loading tst-e2big tst-iconv4 bug-iconv4 \
+   tst-iconv6 bug-iconv5 bug-iconv6 tst-iconv7 bug-iconv8 bug-iconv9 \
+   bug-iconv10 bug-iconv11 bug-iconv12 tst-iconv-big5-hkscs-to-2ucs4 \
+-  bug-iconv13 bug-iconv14
++  bug-iconv13 bug-iconv14 bug-iconv15
+ ifeq ($(have-thread-library),yes)
+ tests += bug-iconv3
+ endif
+@@ -327,6 +328,8 @@ $(objpfx)bug-iconv12.out: $(addprefix $(objpfx), 
$(gconv-modules)) \
+ $(addprefix $(objpfx),$(modules.so))
+ $(objpfx)bug-iconv14.out: $(addprefix $(objpfx), $(gconv-modules)) \
+ $(addprefix $(objpfx),$(modules.so))
++$(objpfx)bug-iconv15.out: $(addprefix $(objpfx), $(gconv-modules)) \
++$(addprefix $(objpfx),$(modules.so))
+ 
+ $(objpfx)iconv-test.out: run-iconv-test.sh \
+$(addprefix $(objpfx), $(gconv-modules)) \
+diff --git a/iconvdata/bug-iconv15.c b/iconvdata/bug-iconv15.c
+new file mode 100644
+index 00..cc04bd0313
+--- /dev/null
 b/iconvdata/bug-iconv15.c
+@@ -0,0 +1,60 @@
++/* Bug 28524: Conversion from ISO-2022-JP-3 with iconv
++   may emit spurious NUL character on state reset.
++   Copyright (C) The GNU Toolchain Authors.
++   This file is part of the GNU C Library.
++
++   The GNU C Library is free software; you can redistribute it and/or
++   modify it under the terms of the GNU Lesser General Public
++   License as published by the Free Software Foundation; either
++   version 2.1 of the License, or (at your option) any later version.
++
++   The GNU C Library is distributed in the hope that it will be useful,
++   but WITHOUT ANY WARRANTY; without even the implied warranty of
++   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
++   Lesser General Public License for more details.
++
++   You should have received a copy of the GNU Lesser General Public
++   License along with the GNU C Library; if not, see
++   .  */
++
++#include 
++#include 
++#include 
++
++static int
++do_test (void)
++{
++  char in[] = "\x1b(I";
++  char *inbuf = in;
++  size_t inleft = sizeof (in) - 1;
++  char out[1];
++  char *outbuf = out;
++  size_t outleft = sizeof (out);
++  iconv_t cd;
++
++  cd = 

Re: [OE-core] [PATCH] linux-yocto-dev: Make -dev kernel work for a fixed revision

[Kevin Hao]

On Wed, Dec 01, 2021 at 04:27:44PM -0500, Bruce Ashfield wrote:
> [Please note: This e-mail is from an EXTERNAL e-mail address]
> 
> On Wed, Dec 1, 2021 at 6:28 AM Richard Purdie
>  wrote:
> >
> > On Wed, 2021-12-01 at 12:39 +0800, Kevin Hao wrote:
> > > By default the -dev kernel uses the "AUTOREV" to pull in the branch
> > > head as the revision. Some of our BSPs are based on the -dev kernel and
> > > we choose to nail down the kernel to a specific revision when releasing
> > > our product by using some setting like below:
> > >   PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-dev"
> > >   SRCREV_machine:pn-linux-yocto-dev = 
> > > "6fb48ae18a10770702266dd1f1aa500149e361ec"
> > >   KBRANCH:pn-linux-yocto-dev = "standard/x86"
> > >   LINUX_VERSION = "5.15"
> > >
> > > Since all the standard/* branches will be rebased after each kernel
> > > version bump, we would get bitbake fetch failure due to that specific
> > > commit is not reachable in the new version branch. This kind of issue
> > > can be fixed by setting the "nobranch" parameter in the SRC_URI because
> > > it will cause the fetcher to skip the SHA validation for the branch.
> > > And this also won't cause other side effect because all the branches
> > > will be created in the do_kernel_checkout() and the current branch will
> > > be reset to the reversion we want in do_validate_branches().
> > >
> > > Signed-off-by: Kevin Hao 
> > > ---
> > >  meta/recipes-kernel/linux/linux-yocto-dev.bb | 3 ++-
> > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/meta/recipes-kernel/linux/linux-yocto-dev.bb 
> > > b/meta/recipes-kernel/linux/linux-yocto-dev.bb
> > > index 6b6ea9a7e864..7204c3eddc11 100644
> > > --- a/meta/recipes-kernel/linux/linux-yocto-dev.bb
> > > +++ b/meta/recipes-kernel/linux/linux-yocto-dev.bb
> > > @@ -19,7 +19,8 @@ include 
> > > recipes-kernel/linux/linux-yocto-dev-revisions.inc
> > >  KBRANCH = "standard/base"
> > >  KMETA = "kernel-meta"
> > >
> > > -SRC_URI = 
> > > "git://git.yoctoproject.org/linux-yocto-dev.git;branch=${KBRANCH};name=machine
> > >  \
> > > +# Set nobranch to skip the SHA validation for branch if a fixed revesion 
> > > is used
> > > +SRC_URI = 
> > > "git://git.yoctoproject.org/linux-yocto-dev.git;branch=${KBRANCH};name=machine;nobranch=1
> > >  \
> > > 
> > > git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=master;destsuffix=${KMETA}"
> > >
> > >  # Set default SRCREVs. Both the machine and meta SRCREVs are statically 
> > > set
> >
> > I'm afraid this looks to be a bit of a horrible workaround/hack. It happens 
> > that
> > if you specify a branch and set nobranch it might do what you want but that
> > certainly isn't by design.
> >
> > Either the revision is in the branch or it isn't. The error is telling you 
> > the
> > configuration you set isn't valid and you really need to set a valid
> > configuration, i.e. a revision and a branch or a revision and set nobranch 
> > but
> > not both.
> >
> > I'm not sure I understand why the kernel would be rebasing after each kernel
> > release? Is this because it is one of the unversioned branches?
> 
> Yah, it is exactly that. The -dev kernel has always been a rebase
> tree, like linux-next upstream.
> 
> Since the BSP work started against it (the -dev tree), when I move on
> from a -dev version, I've been saving all work into versioned branches
> ... versus removing them (and storing the history in the
> kernel-cache).
> 
> That being said, we merged some code some time ago that allows the
> -dev kernel to automatically switch to the versioned branches, versus
> the rebased "standard/*" branches. (that supports existing releases
> with the -dev kernel as I move the one in master to new versions).
> Have a look at do_validate_branches(), but unfortunately the fetcher
> error will have already been thrown and we can't adjust to the fixed
> SRCREV.
> 
> The issue here is the attempt to pin the revision (like Richard is
> saying), since if you use AUTOREV the code I just mentioned code kicks
> in to make sure a versioned branch is used. Nothing should be released
> against -dev, so any issues with pinned SRCREVs and branches should be
> transient.
> 
> I've floated the idea a few times that now that versioned branches are
> being created (to keep older dev kernels around) I could just create
> the branches from the start as versioned, and then you wouldn't have
> the issue you are seeing, even with a pinned SRCREV.

That would be great if you can do so.

> We are in a
> middle state, since the structure of -dev has changed over time as
> more use for it appeared (and it was also created when even the
> linux-yocto branches were not versioned). But that isn't something
> that I could do until the next -dev version and only part of the next
> yocto release.
> 
> But for the short term, the fetcher error you are seeing should happen
> once, and you could have a bbappend to adjust the KBRANCH accordingly,
> or 

[OE-core] [PATCH] glibc: Drop patch to support/workaround prelinked apps on armv5

[Khem Raj]

The usecase explained in bug #1443 works fine now a days on qemuarmv5,
tested by using lltng-ust and explicitly linking in liburcu-bp.so as
well, since its no more a direct dependency of liblttng-ust.so.1

Given that usecase works, unbolt this fix now.

Signed-off-by: Khem Raj 
Cc: Mark Hatle 
---
 ...443-which-explains-what-the-patch-do.patch | 58 ---
 meta/recipes-core/glibc/glibc_2.34.bb |  1 -
 2 files changed, 59 deletions(-)
 delete mode 100644 
meta/recipes-core/glibc/glibc/0012-Quote-from-bug-1443-which-explains-what-the-patch-do.patch

diff --git 
a/meta/recipes-core/glibc/glibc/0012-Quote-from-bug-1443-which-explains-what-the-patch-do.patch
 
b/meta/recipes-core/glibc/glibc/0012-Quote-from-bug-1443-which-explains-what-the-patch-do.patch
deleted file mode 100644
index 07d4411c61c..000
--- 
a/meta/recipes-core/glibc/glibc/0012-Quote-from-bug-1443-which-explains-what-the-patch-do.patch
+++ /dev/null
@@ -1,58 +0,0 @@
-From add514edf4299d1bf540d85d0aa0bd5fe0d46b78 Mon Sep 17 00:00:00 2001
-From: Khem Raj 
-Date: Wed, 18 Mar 2015 00:20:09 +
-Subject: [PATCH] Quote from bug 1443 which explains what the patch does :
-
-  We build some random program and link it with -lust.  When we run it,
-  it dies with a SIGSEGV before reaching main().
-
-  Libust.so depends on liburcu-bp.so from the usermode-rcu package.
-  Although libust.so is not prelinked, liburcu-bp.so IS prelinked; this
-  is critical.
-
-  Libust.so uses a TLS / __thread variable that is defined in liburcu-
-  bp.so.  There are special ARM-specific relocation types that allow two
-  shared libraries to share thread-specific data.  This is critical too.
-
-  One more critical issue: although liburcu-bp.so is prelinked, we can't
-  load it at its prelinked address, because we also link against
-  librt.so, and librt.so uses that address.
-
-  The dynamic linker is forced to relink liburcu-bp.so at a different
-  address.  In the course of relinking, it processes the special ARM
-  relocation record mentioned above.  The prelinker has already filled
-  in the information, which is a short offset into a table of thread-
-  specific data that is allocated per-thread for each library that uses
-  TLS.  Because the normal behavior of a relocation is to add the symbol
-  value to an addend stored at the address being relocated, we end up
-  adding the short offset to itself, doubling it.
-
-  Now we have an awkward situation.  The libust.so library doesn't know
-  about the addend, so its TLS data for this element is correct.  The
-  liburcu-bp.so library has a different offset for the element.  When we
-  go to initialize the element for the first time in liburcu-bp.so, we
-  write the address of the result at the doubled (broken) offset.
-  Later, when we refer to the address from libust.so, we check the value
-  at the correct offset, but it's NULL, so we eat hot SIGSEGV.
-
-Upstream-Status: Pending
-
-Signed-off-by: Andrei Dinu 
-Signed-off-by: Khem Raj 

- sysdeps/arm/dl-machine.h | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/sysdeps/arm/dl-machine.h b/sysdeps/arm/dl-machine.h
-index ff5e09e207..d68bfe5cbe 100644
 a/sysdeps/arm/dl-machine.h
-+++ b/sysdeps/arm/dl-machine.h
-@@ -510,7 +510,7 @@ elf_machine_rel (struct link_map *map, const Elf32_Rel 
*reloc,
- 
-   case R_ARM_TLS_DTPOFF32:
- if (sym != NULL)
--  *reloc_addr += sym->st_value;
-+  *reloc_addr = sym->st_value;
- break;
- 
-   case R_ARM_TLS_TPOFF32:
diff --git a/meta/recipes-core/glibc/glibc_2.34.bb 
b/meta/recipes-core/glibc/glibc_2.34.bb
index 02b76ab3f35..1826eba1756 100644
--- a/meta/recipes-core/glibc/glibc_2.34.bb
+++ b/meta/recipes-core/glibc/glibc_2.34.bb
@@ -33,7 +33,6 @@ SRC_URI =  "${GLIBC_GIT_URI};branch=${SRCBRANCH};name=glibc \
file://0009-fsl-e500-e5500-e6500-603e-fsqrt-implementation.patch \
file://0010-ppc-sqrt-Fix-undefined-reference-to-__sqrt_finite.patch 
\

file://0011-__ieee754_sqrt-f-are-now-inline-functions-and-call-o.patch \
-   
file://0012-Quote-from-bug-1443-which-explains-what-the-patch-do.patch \

file://0013-eglibc-run-libm-err-tab.pl-with-specific-dirs-in-S.patch \

file://0014-__ieee754_sqrt-f-are-now-inline-functions-and-call-o.patch \

file://0015-sysdeps-gnu-configure.ac-handle-correctly-libc_cv_ro.patch \
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159072): 
https://lists.openembedded.org/g/openembedded-core/message/159072
Mute This Topic: https://lists.openembedded.org/mt/87447790/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] boost: Fix build on arches with no atomics

[Khem Raj]

1.77 is broken on architectures which dont have lockfree atomics e.g.
armv5 [1], backport relevant fixes from upstream to unbreak the build

[1] https://github.com/boostorg/math/issues/673

Signed-off-by: Khem Raj 
---
 ...th_no_atomic_int-on-the-command-line.patch |  53 ++
 ...oft-failure-in-bernoulli_details_hpp.patch | 151 ++
 meta/recipes-support/boost/boost_1.77.0.bb|   2 +
 3 files changed, 206 insertions(+)
 create mode 100644 
meta/recipes-support/boost/boost/0002-math-allow-definition-of-boost_math_no_atomic_int-on-the-command-line.patch
 create mode 100644 
meta/recipes-support/boost/boost/0003-math-make-no-atomics-a-soft-failure-in-bernoulli_details_hpp.patch

diff --git 
a/meta/recipes-support/boost/boost/0002-math-allow-definition-of-boost_math_no_atomic_int-on-the-command-line.patch
 
b/meta/recipes-support/boost/boost/0002-math-allow-definition-of-boost_math_no_atomic_int-on-the-command-line.patch
new file mode 100644
index 000..b05b7950844
--- /dev/null
+++ 
b/meta/recipes-support/boost/boost/0002-math-allow-definition-of-boost_math_no_atomic_int-on-the-command-line.patch
@@ -0,0 +1,53 @@
+From 32bd6197353f6ea8e5bef01f09e25c944141acfc Mon Sep 17 00:00:00 2001
+From: jzmaddock 
+Date: Wed, 1 Sep 2021 18:54:54 +0100
+Subject: [PATCH] Allow definition of BOOST_MATH_NO_ATOMIC_INT on the command
+ line. Allows us to test/emulate platforms with no atomic integers.
+
+[buildr...@heine.tech:
+  - backport from boostorg/math 32bd6197353f6ea8e5bef01f09e25c944141acfc
+  - alter path to match boost release
+]
+Signed-off-by: Michael Nosthoff 
+---
+Upstream-Status: Backport 
[https://github.com/boostorg/math/pull/684/commits/32bd6197353f6ea8e5bef01f09e25c944141acfc]
+ boost/math/tools/atomic.hpp | 10 +-
+ 1 file changed, 5 insertions(+), 5 deletions(-)
+
+diff --git a/boost/math/tools/atomic.hpp b/boost/math/tools/atomic.hpp
+index cc76ed269f..e3cbf5db89 100644
+--- a/boost/math/tools/atomic.hpp
 b/boost/math/tools/atomic.hpp
+@@ -16,27 +16,27 @@
+ namespace boost {
+namespace math {
+   namespace detail {
+-#if ATOMIC_INT_LOCK_FREE == 2
++#if (ATOMIC_INT_LOCK_FREE == 2) && !defined(BOOST_MATH_NO_ATOMIC_INT)
+  typedef std::atomic atomic_counter_type;
+  typedef std::atomic atomic_unsigned_type;
+  typedef int atomic_integer_type;
+  typedef unsigned atomic_unsigned_integer_type;
+-#elif ATOMIC_SHORT_LOCK_FREE == 2
++#elif (ATOMIC_SHORT_LOCK_FREE == 2) && !defined(BOOST_MATH_NO_ATOMIC_INT)
+  typedef std::atomic atomic_counter_type;
+  typedef std::atomic atomic_unsigned_type;
+  typedef short atomic_integer_type;
+  typedef unsigned short atomic_unsigned_type;
+-#elif ATOMIC_LONG_LOCK_FREE == 2
++#elif (ATOMIC_LONG_LOCK_FREE == 2) && !defined(BOOST_MATH_NO_ATOMIC_INT)
+  typedef std::atomic atomic_unsigned_integer_type;
+  typedef std::atomic atomic_unsigned_type;
+  typedef unsigned long atomic_unsigned_type;
+  typedef long atomic_integer_type;
+-#elif ATOMIC_LLONG_LOCK_FREE == 2
++#elif (ATOMIC_LLONG_LOCK_FREE == 2) && !defined(BOOST_MATH_NO_ATOMIC_INT)
+  typedef std::atomic atomic_unsigned_integer_type;
+  typedef std::atomic atomic_unsigned_type;
+  typedef long long atomic_integer_type;
+  typedef unsigned long long atomic_unsigned_integer_type;
+-#else
++#elif !defined(BOOST_MATH_NO_ATOMIC_INT)
+ #  define BOOST_MATH_NO_ATOMIC_INT
+ #endif
+   } // Namespace detail
diff --git 
a/meta/recipes-support/boost/boost/0003-math-make-no-atomics-a-soft-failure-in-bernoulli_details_hpp.patch
 
b/meta/recipes-support/boost/boost/0003-math-make-no-atomics-a-soft-failure-in-bernoulli_details_hpp.patch
new file mode 100644
index 000..f69e4f21f3e
--- /dev/null
+++ 
b/meta/recipes-support/boost/boost/0003-math-make-no-atomics-a-soft-failure-in-bernoulli_details_hpp.patch
@@ -0,0 +1,151 @@
+From 7d482f6ebc356e6ec455ccb5f51a23971bf6ce5b Mon Sep 17 00:00:00 2001
+From: jzmaddock 
+Date: Wed, 1 Sep 2021 20:31:53 +0100
+Subject: [PATCH] Make no atomics a soft failure in bernoulli_details.hpp.
+ Include an "escape macro" so thread safety can be disabled if certain
+ bernoulli features are to be used in a no-atomics environment. Fixes
+ https://github.com/boostorg/math/issues/673.
+
+[buildr...@heine.tech:
+  - backport from boostorg/math 7d482f6ebc356e6ec455ccb5f51a23971bf6ce5b
+  - alter path to match boost release
+]
+Signed-off-by: Michael Nosthoff 
+---
+Upstream-Status: Backport 
[https://github.com/boostorg/math/pull/684/commits/7d482f6ebc356e6ec455ccb5f51a23971bf6ce5b]
+ .../detail/bernoulli_details.hpp | 10 +++---
+ libs/math/test/Jamfile.v2|  3 +++
+ test/compile_test/bernoulli_no_atomic_d.cpp  | 14 ++
+ test/compile_test/bernoulli_no_atomic_fail.cpp   | 15 +++
+ test/compile_test/bernoulli_no_atomic_mp.cpp | 16 
+ 5 files 

[OE-core] [PATCH] packagegroup-core-tools-testapps: clear GOTOOLS for riscv32

[kai]

From: Kai Kang 

go-helloworld is not compatible with riscv32 and causes error:

| ERROR: Nothing RPROVIDES 'go-helloworld' (but
meta/recipes-core/packagegroups/packagegroup-core-tools-testapps.bb
RDEPENDS on or otherwise requires it)
| go-helloworld was skipped: Unsupported CPU architecture: riscv32

Clear GOTOOLS for riscv32 in recipe packagegroup-core-tools-testapps.

Signed-off-by: Kai Kang 
---
 .../packagegroups/packagegroup-core-tools-testapps.bb| 1 +
 1 file changed, 1 insertion(+)

diff --git 
a/meta/recipes-core/packagegroups/packagegroup-core-tools-testapps.bb 
b/meta/recipes-core/packagegroups/packagegroup-core-tools-testapps.bb
index e8f0811485..1fee1c925d 100644
--- a/meta/recipes-core/packagegroups/packagegroup-core-tools-testapps.bb
+++ b/meta/recipes-core/packagegroups/packagegroup-core-tools-testapps.bb
@@ -23,6 +23,7 @@ KEXECTOOLS:riscv32 ?= ""
 # gccgo may do better
 GOTOOLS ?= "go-helloworld"
 GOTOOLS:powerpc ?= ""
+GOTOOLS:riscv32 ?= ""
 
 GSTEXAMPLES ?= "gst-examples"
 GSTEXAMPLES:riscv64 = ""
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159070): 
https://lists.openembedded.org/g/openembedded-core/message/159070
Mute This Topic: https://lists.openembedded.org/mt/87445157/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] [RFC] meson needs a pkg-config wrapper script

[Joel Winarske]

Actually the recipe pkgconfig_git.bb points to the freedesktop pkg-config
repo, which is used by default.

On Wed, Dec 1, 2021 at 3:27 PM Joel Winarske via lists.openembedded.org
 wrote:

> Forgot the reply all, not intentional :)
>
> Looks like the build is using the pkgconfig flavor:
> meta/recipes-devtools/pkgconfig/pkgconfig_git.bb
>
> Perhaps I just need a PREFERRED_PROVIDER_pkgconfig ?= "pkg-config" and
> pkg-config recipe, then perhaps it will just work.
>
> On Wed, Dec 1, 2021 at 2:39 PM Alexander Kanavin 
> wrote:
>
>> Please keep the conversation on the list.
>>
>> Those are two different, independently developed projects:
>> https://gitlab.freedesktop.org/pkg-config/pkg-config
>> https://github.com/pkgconf/pkgconf
>> and they are not fully compatible as you have just shown.
>>
>> I'm not sure how pkgconf is able to decide that includedir is a path
>> (short of hardcoding that inside the source somewhere), but such logic
>> needs to be carefully investigated before we make use of it, e.g. by
>> switching to pkgconf in oe-core.
>>
>> Alex
>>
>> On Wed, 1 Dec 2021 at 23:31, Joel Winarske 
>> wrote:
>>
>>> pkg-config --version ?
>>>
>>> Using 0.29.2 I get the same output as you:
>>> $ PKG_CONFIG_SYSROOT_DIR=$STAGING_DIR_TARGET
>>> /home/linuxbrew/.linuxbrew/bin/pkg-config --define-variable=prefix=/opt
>>> --variable=includedir glesv2
>>> /usr/include
>>>
>>> Using 1.7.3 it works:
>>>
>>> STAGING_DIR_TARGET=/b/github-ci/_work/meta-flutter/rpi4-drm-honister-latest/raspberrypi4-64/tmp/work/cortexa72-poky-linux/vkmark/git-r0/recipe-sysroot
>>> PKG_CONFIG_SYSROOT_DIR=$STAGING_DIR_TARGET /usr/bin/pkg-config
>>> --variable=includedir glesv2
>>>
>>> /b/github-ci/_work/meta-flutter/rpi4-drm-honister-latest/raspberrypi4-64/tmp/work/cortexa72-poky-linux/vkmark/git-r0/recipe-sysroot/usr/include
>>>
>>> $ /usr/bin/pkg-config --version
>>> 1.7.3
>>>
>>> $ /home/linuxbrew/.linuxbrew/bin/pkg-config --version
>>> 0.29.2
>>>
>>> On Wed, Dec 1, 2021 at 12:36 AM Alexander Kanavin <
>>> alex.kana...@gmail.com> wrote:
>>>
 No, it's not that. Even if you pass PKG_CONFIG_SYSROOT_DIR to
 pkg-config directly, it will apply that only to --cflags and similar, but
 not to generic --variable. Try this:

 alex@alex-lx-laptop:~$ PKG_CONFIG_SYSROOT_DIR=/ pkg-config libdrm
 --cflags
 -I//usr/include/libdrm
 alex@alex-lx-laptop:~$ PKG_CONFIG_SYSROOT_DIR=/ pkg-config libdrm
 --variable=includedir
 /usr/include

 So a wrapper will not solve the 'includedir prefix' problem, and
 neither the wrapper, nor pkg-config or meson can possibly know which
 variable is a path, and which isn't - the only place where that is known is
 the component that obtains the variable. And so that's where it has to be
 prefixed.

 Alex

 On Tue, 30 Nov 2021 at 23:38, Joel Winarske 
 wrote:

> Based on my testing, if PKG_CONFIG_SYSROOT_DIR is set or not makes
> zero difference on the outcome.  I suspect this is related to how
> pkg-config is launched by meson.
>
> Looking at the meson source tree, in all ci/test cross compile
> scenarios they reference a pkg-config wrapper.  No cross compile scenario 
> I
> see referencing the 'pkgconfig' key uses a bare pkg-config.
>
> cross/armclang-linux.txt:#pkgconfig =
> '/usr/bin/arm-linux-gnueabihf-pkg-config'
> cross/linux-mingw-w64-32bit.txt:pkgconfig =
> '/usr/bin/i686-w64-mingw32-pkg-config'
> cross/linux-mingw-w64-64bit.txt:pkgconfig =
> '/usr/bin/x86_64-w64-mingw32-pkg-config'
> cross/ubuntu-armhf.txt:pkgconfig =
> '/usr/bin/arm-linux-gnueabihf-pkg-config'
> test cases/unit/33 cross file overrides always
> args/ubuntu-armhf-overrides.txt:pkgconfig =
> '/usr/bin/arm-linux-gnueabihf-pkg-config'
> test cases/unit/36 exe_wrapper
> behaviour/broken-cross.txt:pkgconfig =
> '/usr/bin/x86_64-w64-mingw32-pkg-config'
>
> I think adding a wrapper makes sense.
>
> 5.2 Tool Calling Conventions -
> https://autotools.io/pkgconfig/cross-compiling.html
>
> On Tue, Nov 30, 2021 at 12:13 PM Alexander Kanavin <
> alex.kana...@gmail.com> wrote:
>
>> On Tue, 30 Nov 2021 at 21:00, Joel Winarske 
>> wrote:
>>
>>> Yes, if the sys_root key value in meson.cross is present
>>> PKG_CONFIG_SYSROOT_DIR gets set.  Honister patch I confirmed with:
>>>
>>> https://github.com/jwinarske/manifests/blob/honister/rpi64/0001-Add-sys_root-to-properties-section.patch
>>>
>>> The issue is that meson doesn't pass PKG_CONFIG_SYSROOT_DIR to the
>>> shell environment that runs pkg-config, as with the pkg-config sandbox 
>>> test
>>> it does work.
>>>
>>
>> Both meson source code and its documentation indicate otherwise - if
>> you set sys_root property, it will get passed to pkg-config via 
>> environment
>> as PKG_CONFIG_SYSROOT_DIR:
>>

Re: [OE-core] [RFC] meson needs a pkg-config wrapper script

[Joel Winarske]

Forgot the reply all, not intentional :)

Looks like the build is using the pkgconfig flavor:
meta/recipes-devtools/pkgconfig/pkgconfig_git.bb

Perhaps I just need a PREFERRED_PROVIDER_pkgconfig ?= "pkg-config" and
pkg-config recipe, then perhaps it will just work.

On Wed, Dec 1, 2021 at 2:39 PM Alexander Kanavin 
wrote:

> Please keep the conversation on the list.
>
> Those are two different, independently developed projects:
> https://gitlab.freedesktop.org/pkg-config/pkg-config
> https://github.com/pkgconf/pkgconf
> and they are not fully compatible as you have just shown.
>
> I'm not sure how pkgconf is able to decide that includedir is a path
> (short of hardcoding that inside the source somewhere), but such logic
> needs to be carefully investigated before we make use of it, e.g. by
> switching to pkgconf in oe-core.
>
> Alex
>
> On Wed, 1 Dec 2021 at 23:31, Joel Winarske 
> wrote:
>
>> pkg-config --version ?
>>
>> Using 0.29.2 I get the same output as you:
>> $ PKG_CONFIG_SYSROOT_DIR=$STAGING_DIR_TARGET
>> /home/linuxbrew/.linuxbrew/bin/pkg-config --define-variable=prefix=/opt
>> --variable=includedir glesv2
>> /usr/include
>>
>> Using 1.7.3 it works:
>>
>> STAGING_DIR_TARGET=/b/github-ci/_work/meta-flutter/rpi4-drm-honister-latest/raspberrypi4-64/tmp/work/cortexa72-poky-linux/vkmark/git-r0/recipe-sysroot
>> PKG_CONFIG_SYSROOT_DIR=$STAGING_DIR_TARGET /usr/bin/pkg-config
>> --variable=includedir glesv2
>>
>> /b/github-ci/_work/meta-flutter/rpi4-drm-honister-latest/raspberrypi4-64/tmp/work/cortexa72-poky-linux/vkmark/git-r0/recipe-sysroot/usr/include
>>
>> $ /usr/bin/pkg-config --version
>> 1.7.3
>>
>> $ /home/linuxbrew/.linuxbrew/bin/pkg-config --version
>> 0.29.2
>>
>> On Wed, Dec 1, 2021 at 12:36 AM Alexander Kanavin 
>> wrote:
>>
>>> No, it's not that. Even if you pass PKG_CONFIG_SYSROOT_DIR to pkg-config
>>> directly, it will apply that only to --cflags and similar, but not to
>>> generic --variable. Try this:
>>>
>>> alex@alex-lx-laptop:~$ PKG_CONFIG_SYSROOT_DIR=/ pkg-config libdrm
>>> --cflags
>>> -I//usr/include/libdrm
>>> alex@alex-lx-laptop:~$ PKG_CONFIG_SYSROOT_DIR=/ pkg-config libdrm
>>> --variable=includedir
>>> /usr/include
>>>
>>> So a wrapper will not solve the 'includedir prefix' problem, and neither
>>> the wrapper, nor pkg-config or meson can possibly know which variable is a
>>> path, and which isn't - the only place where that is known is the component
>>> that obtains the variable. And so that's where it has to be prefixed.
>>>
>>> Alex
>>>
>>> On Tue, 30 Nov 2021 at 23:38, Joel Winarske 
>>> wrote:
>>>
 Based on my testing, if PKG_CONFIG_SYSROOT_DIR is set or not makes zero
 difference on the outcome.  I suspect this is related to how pkg-config is
 launched by meson.

 Looking at the meson source tree, in all ci/test cross compile
 scenarios they reference a pkg-config wrapper.  No cross compile scenario I
 see referencing the 'pkgconfig' key uses a bare pkg-config.

 cross/armclang-linux.txt:#pkgconfig =
 '/usr/bin/arm-linux-gnueabihf-pkg-config'
 cross/linux-mingw-w64-32bit.txt:pkgconfig =
 '/usr/bin/i686-w64-mingw32-pkg-config'
 cross/linux-mingw-w64-64bit.txt:pkgconfig =
 '/usr/bin/x86_64-w64-mingw32-pkg-config'
 cross/ubuntu-armhf.txt:pkgconfig =
 '/usr/bin/arm-linux-gnueabihf-pkg-config'
 test cases/unit/33 cross file overrides always
 args/ubuntu-armhf-overrides.txt:pkgconfig =
 '/usr/bin/arm-linux-gnueabihf-pkg-config'
 test cases/unit/36 exe_wrapper behaviour/broken-cross.txt:pkgconfig
 = '/usr/bin/x86_64-w64-mingw32-pkg-config'

 I think adding a wrapper makes sense.

 5.2 Tool Calling Conventions -
 https://autotools.io/pkgconfig/cross-compiling.html

 On Tue, Nov 30, 2021 at 12:13 PM Alexander Kanavin <
 alex.kana...@gmail.com> wrote:

> On Tue, 30 Nov 2021 at 21:00, Joel Winarske 
> wrote:
>
>> Yes, if the sys_root key value in meson.cross is present
>> PKG_CONFIG_SYSROOT_DIR gets set.  Honister patch I confirmed with:
>>
>> https://github.com/jwinarske/manifests/blob/honister/rpi64/0001-Add-sys_root-to-properties-section.patch
>>
>> The issue is that meson doesn't pass PKG_CONFIG_SYSROOT_DIR to the
>> shell environment that runs pkg-config, as with the pkg-config sandbox 
>> test
>> it does work.
>>
>
> Both meson source code and its documentation indicate otherwise - if
> you set sys_root property, it will get passed to pkg-config via 
> environment
> as PKG_CONFIG_SYSROOT_DIR:
>
> https://github.com/mesonbuild/meson/blob/master/mesonbuild/dependencies/pkgconfig.py#L121
>
> Alex
>
>

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

Re: [OE-core] [RFC PATCH v2 1/2] bitbake.conf: Pad rpath and remove build ID in native binaries

[Richard Purdie]

On Tue, 2021-11-30 at 23:37 +0100, Jacob Kroon wrote:
> Try to make sure that the RUNTIME dynamic entry size is the same for all
> binaries produced with the native compiler. This is necessary in order to
> produce identical binaries when using differently sized buildpaths. I've
> tried using only patchelf, and keeping the linker flags as they are, but
> I am unable to produce identical binaries. Has anyone else managed to do
> this with patchelf ? If not, maybe we can write a new tool that can handle it 
> ?
> 
> The build-id also needs to be removed since it is calculated based on
> the data present at link time. This includes STAGING_LIBDIR_NATIVE
> and STAGING_BASE_LIBDIR_NATIVE. Both will differ and they need to be 
> temporarily
> preserved since some recipes will execute the binaries during do_install()
> (for example python3-native). Later on these are removed in chrpath.bbclass.
> 
> This hack is the first step for producing identical native binaries when using
> different build paths. 'zstd-native' is a working example.
> 
> Signed-off-by: Jacob Kroon 
> ---
>  meta/classes/chrpath.bbclass | 3 +++
>  meta/conf/bitbake.conf   | 5 -
>  2 files changed, 7 insertions(+), 1 deletion(-)

I'm a little torn on this. Our other option would be to hardcoded a specific
dummy path and then edit it later to the correct value. That may be neater than
adding the padding. It will change the end binaries but hopefully only after
they're installed so should give the same net end result more neatly?

If we separate out the build-id patch we could hopefully get that piece merged
as that shouldn't be controversial? 

Cheers,

Richard


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159067): 
https://lists.openembedded.org/g/openembedded-core/message/159067
Mute This Topic: https://lists.openembedded.org/mt/87415016/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] patch.py: Initialize git repo before patching

[Richard Purdie]

On Wed, 2021-12-01 at 17:12 +0100, Pavel Zhukov wrote:
> From: Pavel Zhukov 
> 
> If PATCHTOOL="git" has been specified but workdir is not git repo
> bitbake fails to apply the patches with error message:
> Command Error: 'git rev-parse --show-toplevel' exited with 0  Output:
> fatal: not a git repository (or any of the parent directories): .git
> 
> Fix this by initializing the repo before patching.
> This allows binary git patches to be applied.
> 
> Signed-off-by: Pavel Zhukov 
> ---
>  meta/lib/oe/patch.py| 17 +
>  meta/lib/oeqa/selftest/cases/bbtests.py |  6 ++
>  2 files changed, 23 insertions(+)
> 
> diff --git a/meta/lib/oe/patch.py b/meta/lib/oe/patch.py
> index fccbedb519..8326cb55bc 100644
> --- a/meta/lib/oe/patch.py
> +++ b/meta/lib/oe/patch.py
> @@ -56,6 +56,10 @@ def runcmd(args, dir = None):
>  if dir:
>  os.chdir(olddir)
>  
> +def getstatusoutput(cmd):
> +import subprocess
> +return subprocess.getstatusoutput(cmd.split())
> +

I'm not convinced this function is adding much or is needed. imports can just go
at the start of the python file in this case too.

>  class PatchError(Exception):
>  def __init__(self, msg):
>  self.msg = msg
> @@ -298,6 +302,19 @@ class GitApplyTree(PatchTree):
>  PatchTree.__init__(self, dir, d)
>  self.commituser = d.getVar('PATCH_GIT_USER_NAME')
>  self.commitemail = d.getVar('PATCH_GIT_USER_EMAIL')
> +if not self._isInitialized():
> +self._initRepo()
> +
> +def _isInitialized(self):
> +cmd = "git rev-parse --show-toplevel"
> +(status, output) = getstatusoutput(cmd)
> +## Make sure we're in builddir to not break top-level git repos
> +return status == 0 and os.path.samedir(output, self.dir)
> +
> +def _initRepo(self):
> +runcmd("git init".split(), self.dir)
> +runcmd("git add .".split(), self.dir)
> +runcmd("git commit -a --allow-empty -m Patching_started".split(), 
> self.dir)
>  
>  @staticmethod
>  def extractPatchHeader(patchfile):
> diff --git a/meta/lib/oeqa/selftest/cases/bbtests.py 
> b/meta/lib/oeqa/selftest/cases/bbtests.py
> index 6779e62103..2c3defc6b7 100644
> --- a/meta/lib/oeqa/selftest/cases/bbtests.py
> +++ b/meta/lib/oeqa/selftest/cases/bbtests.py
> @@ -297,3 +297,9 @@ INHERIT:remove = \"report-error\"
>  
>  test_recipe_summary_after = get_bb_var('SUMMARY', test_recipe)
>  self.assertEqual(expected_recipe_summary, test_recipe_summary_after)
> +
> +def test_git_patchtool(self):
> +self.write_recipeinc('man-db', 'PATCHTOOL=\"git\"')
> +result = bitbake('man-db -c patch', ignore_status=False)
> +self.delete_recipeinc('man-db')
> +bitbake('-cclean man-db')

Can you add a comment here about what exactly we're testing please? If something
changes the way the man-db recipe works, this test will break (e.g. it became a
git based recipe rather than tarball).

We may also want to check that the man-db SRC_URI doesn't contain git:// to
guard against that and better document what the test is testing?

Cheers,

Richard





-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159066): 
https://lists.openembedded.org/g/openembedded-core/message/159066
Mute This Topic: https://lists.openembedded.org/mt/87431724/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/40] Pull request (cover letter only)

[Steve Sakoman]

The following changes since commit 44b1970c40e9d73f6e63fb10cdc55837a26f5921:

  build-appliance-image: Update to dunfell head revision (2021-11-15 15:00:44 
+)

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

Alexander Kanavin (17):
  linux-firmware: upgrade 20210919 -> 20211027
  libpcre/libpcre2: correct SRC_URI
  curl: submit patch upstream
  libxml2: submit patch upstream
  cracklib: patches submitted upstream
  docbook-xml: patch is not upstreamable
  lrzsz: patch is not upstreamable
  valgrind: mark ptest-specific patch as inappropriate
  systemd-bootchart: submit musl patches upstream
  libxml2: mark patch as non-upstreamable
  libgpg-error: mark patch as non-upstreamable
  valgrind: submit patch upstream
  webkitgtk: submit patches upstream
  weston: submit patch upstream
  db: mark all patches as non-upstreamable
  unzip/zip: mark all patches as non-upstreamable
  slang: mark patch as inappropriate for upstream submission

Anuj Mittal (1):
  glibc-version.inc: remove branch= from GLIBC_GIT_URI

Bruce Ashfield (4):
  linux-yocto/5.4: update to v5.4.154
  linux-yocto/5.4: update to v5.4.155
  linux-yocto/5.4: update to v5.4.156
  linux-yocto/5.4: update to v5.4.158

Claus Stovgaard (1):
  cups: Fix missing installation of cups sysv init scripts

Daniel Gomez (1):
  os-release: Add DISTRO_CODENAME as vardeps for do_compile

Denys Dmytriyenko (1):
  make-mod-scripts: pass CROSS_COMPILE to configure and build

Jon Mason (1):
  scripts/lib/wic/help.py: Update Fedora Kickstart URLs

Khem Raj (1):
  lrzsz: Use Cross AR during compile

Marta Rybczynska (1):
  python3: upgrade 3.8.11 -> 3.8.12

Minjae Kim (1):
  git: fix CVE-2021-40330

Peter Bergin (1):
  systemd: add packageconfig for wheel-group

Richard Purdie (2):
  scripts/oe-package-browser: Handle no packages being built
  reproducible_build/package_XXX: Ensure SDE task is in dependency chain

Ross Burton (5):
  vim: fix CVE-2021-3796, CVE-2021-3872, and CVE-2021-3875
  vim: add patch number to CVE-2021-3778 patch
  vim: fix CVE-2021-3927 and CVE-2021-3928
  gmp: fix CVE-2021-43618
  openssh: remove redundant BSD license

Steve Sakoman (1):
  Revert "vim: fix 2021-3796"

Wang Mingyu (1):
  openssh: Improve LICENSE to show BSD license variants.

Yi Zhao (1):
  oeqa: fix warnings for append operators combined with +=

 meta/classes/package_deb.bbclass  |   4 +-
 meta/classes/package_ipk.bbclass  |   3 +-
 meta/classes/package_rpm.bbclass  |   3 +-
 meta/classes/reproducible_build.bbclass   |   2 +
 meta/lib/oeqa/runtime/cases/ksample.py|   2 +-
 meta/lib/oeqa/selftest/cases/imagefeatures.py |   2 +-
 ...mpilation-using-autoconf-detected-AR.patch |  36 ++
 .../lrzsz-0.12.20/autotools-update.patch  |   2 +-
 meta/recipes-bsp/lrzsz/lrzsz_0.12.20.bb   |   1 +
 .../openssh/openssh_8.2p1.bb  |   2 +-
 meta/recipes-core/glibc/glibc-version.inc |   2 +-
 .../libxml2/libxml-m4-use-pkgconfig.patch |   6 +-
 .../recipes-core/libxml/libxml2/runtest.patch |   2 +-
 meta/recipes-core/os-release/os-release.bb|   4 +-
 meta/recipes-core/systemd/systemd_244.5.bb|   2 +
 .../docbook-xml-update-catalog.xml.patch  |   2 +-
 .../git/files/CVE-2021-40330.patch| 108 ++
 meta/recipes-devtools/git/git.inc |   4 +-
 .../{python3_3.8.11.bb => python3_3.8.12.bb}  |   4 +-
 ...is-glibc-specific-use-raw-signature-.patch |   2 +-
 .../0002-musl-does-not-provide-printf-h.patch |   2 +-
 ...s-not-provide-canonicalize_file_name.patch |   2 +-
 .../0004-Fix-out-of-tree-builds.patch |   2 +-
 ...est-wrapper-to-support-PTEST-formats.patch |   2 +-
 ...port-dictionary-byte-order-dependent.patch |   2 +-
 ...aklib-fix-testnum-and-teststr-failed.patch |   2 +-
 meta/recipes-extended/cups/cups.inc   |   2 +-
 .../slang/slang/terminfo_fixes.patch  |   4 +-
 .../unzip/unzip/avoid-strip.patch |   2 +-
 .../unzip/unzip/define-ldflags.patch  |   2 +-
 .../unzip/unzip/fix-security-format.patch |   2 +-
 .../unzip/unzip/symlink.patch |   2 +-
 .../zip/zip-3.0/fix-security-format.patch |   2 +-
 ...ovide-a-default-version-that-doesn-t.patch |   2 +-
 ...20210919.bb => linux-firmware_20211027.bb} |   4 +-
 .../linux/linux-yocto-rt_5.4.bb   |   6 +-
 .../linux/linux-yocto-tiny_5.4.bb |   8 +-
 meta/recipes-kernel/linux/linux-yocto_5.4.bb  |  22 ++--
 .../make-mod-scripts/make-mod-scripts_1.0.bb  |   2 +-
 ...spection.cmake-prefix-variables-obta.patch |   2 +-
 ...cy-parallel-build-of-WebKit2-4.0.gir.patch |   2 +-
 ...trospection-files-add-CMAKE_C_FLAGS-.patch |   2 +-
 ...-replace-krb5-config-with-pkg-config.patch |   2 +-
 ...tibility-by-renaming-atomic_init-API.patch |   2 +-
 

Re: [OE-core] [RFC] meson needs a pkg-config wrapper script

[Alexander Kanavin]

Please keep the conversation on the list.

Those are two different, independently developed projects:
https://gitlab.freedesktop.org/pkg-config/pkg-config
https://github.com/pkgconf/pkgconf
and they are not fully compatible as you have just shown.

I'm not sure how pkgconf is able to decide that includedir is a path (short
of hardcoding that inside the source somewhere), but such logic needs to be
carefully investigated before we make use of it, e.g. by switching to
pkgconf in oe-core.

Alex

On Wed, 1 Dec 2021 at 23:31, Joel Winarske  wrote:

> pkg-config --version ?
>
> Using 0.29.2 I get the same output as you:
> $ PKG_CONFIG_SYSROOT_DIR=$STAGING_DIR_TARGET
> /home/linuxbrew/.linuxbrew/bin/pkg-config --define-variable=prefix=/opt
> --variable=includedir glesv2
> /usr/include
>
> Using 1.7.3 it works:
>
> STAGING_DIR_TARGET=/b/github-ci/_work/meta-flutter/rpi4-drm-honister-latest/raspberrypi4-64/tmp/work/cortexa72-poky-linux/vkmark/git-r0/recipe-sysroot
> PKG_CONFIG_SYSROOT_DIR=$STAGING_DIR_TARGET /usr/bin/pkg-config
> --variable=includedir glesv2
>
> /b/github-ci/_work/meta-flutter/rpi4-drm-honister-latest/raspberrypi4-64/tmp/work/cortexa72-poky-linux/vkmark/git-r0/recipe-sysroot/usr/include
>
> $ /usr/bin/pkg-config --version
> 1.7.3
>
> $ /home/linuxbrew/.linuxbrew/bin/pkg-config --version
> 0.29.2
>
> On Wed, Dec 1, 2021 at 12:36 AM Alexander Kanavin 
> wrote:
>
>> No, it's not that. Even if you pass PKG_CONFIG_SYSROOT_DIR to pkg-config
>> directly, it will apply that only to --cflags and similar, but not to
>> generic --variable. Try this:
>>
>> alex@alex-lx-laptop:~$ PKG_CONFIG_SYSROOT_DIR=/ pkg-config libdrm
>> --cflags
>> -I//usr/include/libdrm
>> alex@alex-lx-laptop:~$ PKG_CONFIG_SYSROOT_DIR=/ pkg-config libdrm
>> --variable=includedir
>> /usr/include
>>
>> So a wrapper will not solve the 'includedir prefix' problem, and neither
>> the wrapper, nor pkg-config or meson can possibly know which variable is a
>> path, and which isn't - the only place where that is known is the component
>> that obtains the variable. And so that's where it has to be prefixed.
>>
>> Alex
>>
>> On Tue, 30 Nov 2021 at 23:38, Joel Winarske 
>> wrote:
>>
>>> Based on my testing, if PKG_CONFIG_SYSROOT_DIR is set or not makes zero
>>> difference on the outcome.  I suspect this is related to how pkg-config is
>>> launched by meson.
>>>
>>> Looking at the meson source tree, in all ci/test cross compile scenarios
>>> they reference a pkg-config wrapper.  No cross compile scenario I see
>>> referencing the 'pkgconfig' key uses a bare pkg-config.
>>>
>>> cross/armclang-linux.txt:#pkgconfig =
>>> '/usr/bin/arm-linux-gnueabihf-pkg-config'
>>> cross/linux-mingw-w64-32bit.txt:pkgconfig =
>>> '/usr/bin/i686-w64-mingw32-pkg-config'
>>> cross/linux-mingw-w64-64bit.txt:pkgconfig =
>>> '/usr/bin/x86_64-w64-mingw32-pkg-config'
>>> cross/ubuntu-armhf.txt:pkgconfig =
>>> '/usr/bin/arm-linux-gnueabihf-pkg-config'
>>> test cases/unit/33 cross file overrides always
>>> args/ubuntu-armhf-overrides.txt:pkgconfig =
>>> '/usr/bin/arm-linux-gnueabihf-pkg-config'
>>> test cases/unit/36 exe_wrapper behaviour/broken-cross.txt:pkgconfig
>>> = '/usr/bin/x86_64-w64-mingw32-pkg-config'
>>>
>>> I think adding a wrapper makes sense.
>>>
>>> 5.2 Tool Calling Conventions -
>>> https://autotools.io/pkgconfig/cross-compiling.html
>>>
>>> On Tue, Nov 30, 2021 at 12:13 PM Alexander Kanavin <
>>> alex.kana...@gmail.com> wrote:
>>>
 On Tue, 30 Nov 2021 at 21:00, Joel Winarske 
 wrote:

> Yes, if the sys_root key value in meson.cross is present
> PKG_CONFIG_SYSROOT_DIR gets set.  Honister patch I confirmed with:
>
> https://github.com/jwinarske/manifests/blob/honister/rpi64/0001-Add-sys_root-to-properties-section.patch
>
> The issue is that meson doesn't pass PKG_CONFIG_SYSROOT_DIR to the
> shell environment that runs pkg-config, as with the pkg-config sandbox 
> test
> it does work.
>

 Both meson source code and its documentation indicate otherwise - if
 you set sys_root property, it will get passed to pkg-config via environment
 as PKG_CONFIG_SYSROOT_DIR:

 https://github.com/mesonbuild/meson/blob/master/mesonbuild/dependencies/pkgconfig.py#L121

 Alex



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

Re: [OE-core] [PATCH v2 2/2] vim: set PACKAGECONFIG idiomatically

[Richard Purdie]

On Tue, 2021-11-30 at 13:45 -0800, Andre McCurdy wrote:
> On Tue, Nov 30, 2021 at 1:20 PM Ross Burton  wrote:
> > 
> > On Tue, 30 Nov 2021 at 19:32, Andre McCurdy  wrote:
> > > This isn't equivalent - it will cause a change in behaviour for anyone
> > > using PACKAGECONFIG += "foo" from a .bbappend.
> > 
> > Correct, but this is likely the only recipe in the greater ecosystem
> > which has this behaviour, so I'm not that bothered to be honest. :)
> 
> The only recipe? There are many recipes which set a default
> PACKAGECONFIG with ?= and many which set it with ??=. Your change is
> effectively switching the vim recipe from one approach to the other.
> The fact that adding PACKAGECONFIG options from a .bbappend with +=
> sometimes works OK and sometimes not is a source of confusion for new
> users.
> 
> You are right that no one seems to care though...

Some of us very much do care, it is actually bothering me a lot and I've posted
several times on the architecture list about this kind of issue. 

We haven't worked out what we can agree to do about it though :(.

Cheers,

Richard


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159063): 
https://lists.openembedded.org/g/openembedded-core/message/159063
Mute This Topic: https://lists.openembedded.org/mt/87406894/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 00/14] Backport mandatory dtschema handling for device trees built through the kernel.

[Richard Purdie]

On Wed, 2021-12-01 at 16:33 -0500, Bruce Ashfield wrote:
> On Wed, Dec 1, 2021 at 3:34 PM Bhupesh Sharma  
> wrote:
> > 
> > This is a backport request for dunfell, while picking up only the
> > skeletal support for allowing mandatory dtschema handling for
> > device trees built through the kernel, introduced from kernel
> > version 5.16 onwards.
> 
> The problem with adding this support to dunfell, is obvious in the
> number of patches involved.  We've also said/known that at some point
> that we won't be able to support all new kernel versions with the LTS
> release. This may be the start of drawing that line.
> 
> Also, we've had to do some license tweaks in master just today for one
> of the added packages (idna), so that would be needed as well.
> 
> The validation isn't absolutely critical, I'd suggest that just the
> wrappers and pkg-config fixes would be a smaller footprint to allow
> the kernel to build, without the new package/feature additions to the
> dunfell release. The new packages (and full validation) could still
> possibly be done through a secondary or mixin layer.
> 
> I'm not sure which way to go on this, but I thought I'd offer those
> points for discussion.

I think this needs to be done in a mixin layer for dunfell.

Cheers,

Richard


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159062): 
https://lists.openembedded.org/g/openembedded-core/message/159062
Mute This Topic: https://lists.openembedded.org/mt/87439224/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 00/14] Backport mandatory dtschema handling for device trees built through the kernel.

[Bruce Ashfield]

On Wed, Dec 1, 2021 at 3:34 PM Bhupesh Sharma  wrote:
>
> This is a backport request for dunfell, while picking up only the
> skeletal support for allowing mandatory dtschema handling for
> device trees built through the kernel, introduced from kernel
> version 5.16 onwards.

The problem with adding this support to dunfell, is obvious in the
number of patches involved.  We've also said/known that at some point
that we won't be able to support all new kernel versions with the LTS
release. This may be the start of drawing that line.

Also, we've had to do some license tweaks in master just today for one
of the added packages (idna), so that would be needed as well.

The validation isn't absolutely critical, I'd suggest that just the
wrappers and pkg-config fixes would be a smaller footprint to allow
the kernel to build, without the new package/feature additions to the
dunfell release. The new packages (and full validation) could still
possibly be done through a secondary or mixin layer.

I'm not sure which way to go on this, but I thought I'd offer those
points for discussion.

Bruce

>
> Without this backport compiling 5.16 kernel leads to the following
> error in the dunfell stable branch:
>
> scripts/dtc/Makefile:23: *** dtc needs libyaml for DT schema
>  validation support. Install the necessary libyaml development package..  
> Stop.
>
> Bruce Ashfield (14):
>   kernel: export native PKGCONFIG variables
>   python: introduce python3-dtschema
>   python: import jsonpointer from meta-python
>   python3-jsonpointer: Update 2.1 to 2.2
>   python: import jsonschema from meta-python
>   python: import idna from meta-python
>   python: import rfc3339-validator from meta-python
>   python: import rfc3986-validator from meta-python
>   python: import webcolors from meta-python
>   python: import ruamel-yaml from meta-python
>   python: import pyrsistent from meta-python
>   python: import rfc3987 from meta-pyton
>   python: import strict-rfc3339 from meta-python
>   python: import vcversioner from meta-python
>
>  meta/classes/kernel.bbclass   |  7 +++
>  ...e-pytest-runner-to-test_requirements.patch | 32 +
>  .../python/python3-dtschema_2021.10.bb| 16 +++
>  .../python/python3-idna_3.3.bb| 19 
>  .../python/python3-jsonpointer/run-ptest  |  3 ++
>  .../python/python3-jsonpointer_2.2.bb | 26 ++
>  .../python/python3-jsonschema_3.2.0.bb| 48 +++
>  .../python/python3-pyrsistent_0.18.0.bb   | 14 ++
>  .../python/python3-rfc3339-validator_0.1.4.bb | 20 
>  .../python/python3-rfc3986-validator_0.1.1.bb | 23 +
>  .../python/python3-rfc3987_1.3.8.bb   | 10 
>  .../python/python3-ruamel-yaml_0.17.16.bb | 23 +
>  .../python/python3-strict-rfc3339_0.7.bb  | 10 
>  .../python/python3-vcversioner_2.16.0.0.bb| 12 +
>  .../python/python3-webcolors/run-ptest|  3 ++
>  .../python/python3-webcolors_1.11.1.bb| 27 +++
>  16 files changed, 293 insertions(+)
>  create mode 100644 
> meta/recipes-devtools/python/python-rfc3986-validator/0001-setup.py-move-pytest-runner-to-test_requirements.patch
>  create mode 100644 meta/recipes-devtools/python/python3-dtschema_2021.10.bb
>  create mode 100644 meta/recipes-devtools/python/python3-idna_3.3.bb
>  create mode 100644 meta/recipes-devtools/python/python3-jsonpointer/run-ptest
>  create mode 100644 meta/recipes-devtools/python/python3-jsonpointer_2.2.bb
>  create mode 100644 meta/recipes-devtools/python/python3-jsonschema_3.2.0.bb
>  create mode 100644 meta/recipes-devtools/python/python3-pyrsistent_0.18.0.bb
>  create mode 100644 
> meta/recipes-devtools/python/python3-rfc3339-validator_0.1.4.bb
>  create mode 100644 
> meta/recipes-devtools/python/python3-rfc3986-validator_0.1.1.bb
>  create mode 100644 meta/recipes-devtools/python/python3-rfc3987_1.3.8.bb
>  create mode 100644 
> meta/recipes-devtools/python/python3-ruamel-yaml_0.17.16.bb
>  create mode 100644 meta/recipes-devtools/python/python3-strict-rfc3339_0.7.bb
>  create mode 100644 
> meta/recipes-devtools/python/python3-vcversioner_2.16.0.0.bb
>  create mode 100644 meta/recipes-devtools/python/python3-webcolors/run-ptest
>  create mode 100644 meta/recipes-devtools/python/python3-webcolors_1.11.1.bb
>
> --
> 2.31.1
>


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

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159061): 
https://lists.openembedded.org/g/openembedded-core/message/159061
Mute This Topic: https://lists.openembedded.org/mt/87439224/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] linux-yocto-dev: Make -dev kernel work for a fixed revision

[Bruce Ashfield]

On Wed, Dec 1, 2021 at 6:28 AM Richard Purdie
 wrote:
>
> On Wed, 2021-12-01 at 12:39 +0800, Kevin Hao wrote:
> > By default the -dev kernel uses the "AUTOREV" to pull in the branch
> > head as the revision. Some of our BSPs are based on the -dev kernel and
> > we choose to nail down the kernel to a specific revision when releasing
> > our product by using some setting like below:
> >   PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-dev"
> >   SRCREV_machine:pn-linux-yocto-dev = 
> > "6fb48ae18a10770702266dd1f1aa500149e361ec"
> >   KBRANCH:pn-linux-yocto-dev = "standard/x86"
> >   LINUX_VERSION = "5.15"
> >
> > Since all the standard/* branches will be rebased after each kernel
> > version bump, we would get bitbake fetch failure due to that specific
> > commit is not reachable in the new version branch. This kind of issue
> > can be fixed by setting the "nobranch" parameter in the SRC_URI because
> > it will cause the fetcher to skip the SHA validation for the branch.
> > And this also won't cause other side effect because all the branches
> > will be created in the do_kernel_checkout() and the current branch will
> > be reset to the reversion we want in do_validate_branches().
> >
> > Signed-off-by: Kevin Hao 
> > ---
> >  meta/recipes-kernel/linux/linux-yocto-dev.bb | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/meta/recipes-kernel/linux/linux-yocto-dev.bb 
> > b/meta/recipes-kernel/linux/linux-yocto-dev.bb
> > index 6b6ea9a7e864..7204c3eddc11 100644
> > --- a/meta/recipes-kernel/linux/linux-yocto-dev.bb
> > +++ b/meta/recipes-kernel/linux/linux-yocto-dev.bb
> > @@ -19,7 +19,8 @@ include recipes-kernel/linux/linux-yocto-dev-revisions.inc
> >  KBRANCH = "standard/base"
> >  KMETA = "kernel-meta"
> >
> > -SRC_URI = 
> > "git://git.yoctoproject.org/linux-yocto-dev.git;branch=${KBRANCH};name=machine
> >  \
> > +# Set nobranch to skip the SHA validation for branch if a fixed revesion 
> > is used
> > +SRC_URI = 
> > "git://git.yoctoproject.org/linux-yocto-dev.git;branch=${KBRANCH};name=machine;nobranch=1
> >  \
> > 
> > git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=master;destsuffix=${KMETA}"
> >
> >  # Set default SRCREVs. Both the machine and meta SRCREVs are statically set
>
> I'm afraid this looks to be a bit of a horrible workaround/hack. It happens 
> that
> if you specify a branch and set nobranch it might do what you want but that
> certainly isn't by design.
>
> Either the revision is in the branch or it isn't. The error is telling you the
> configuration you set isn't valid and you really need to set a valid
> configuration, i.e. a revision and a branch or a revision and set nobranch but
> not both.
>
> I'm not sure I understand why the kernel would be rebasing after each kernel
> release? Is this because it is one of the unversioned branches?

Yah, it is exactly that. The -dev kernel has always been a rebase
tree, like linux-next upstream.

Since the BSP work started against it (the -dev tree), when I move on
from a -dev version, I've been saving all work into versioned branches
... versus removing them (and storing the history in the
kernel-cache).

That being said, we merged some code some time ago that allows the
-dev kernel to automatically switch to the versioned branches, versus
the rebased "standard/*" branches. (that supports existing releases
with the -dev kernel as I move the one in master to new versions).
Have a look at do_validate_branches(), but unfortunately the fetcher
error will have already been thrown and we can't adjust to the fixed
SRCREV.

The issue here is the attempt to pin the revision (like Richard is
saying), since if you use AUTOREV the code I just mentioned code kicks
in to make sure a versioned branch is used. Nothing should be released
against -dev, so any issues with pinned SRCREVs and branches should be
transient.

I've floated the idea a few times that now that versioned branches are
being created (to keep older dev kernels around) I could just create
the branches from the start as versioned, and then you wouldn't have
the issue you are seeing, even with a pinned SRCREV. We are in a
middle state, since the structure of -dev has changed over time as
more use for it appeared (and it was also created when even the
linux-yocto branches were not versioned). But that isn't something
that I could do until the next -dev version and only part of the next
yocto release.

But for the short term, the fetcher error you are seeing should happen
once, and you could have a bbappend to adjust the KBRANCH accordingly,
or similar .. which shouldn't be much extra effort, as you mentioned
it was something in a release.  If you have somewhere that you are
setting the SRCREV, why not set the KBRANCH in the same place ?

Cheers,

Bruce

>
> I can fix the fetcher to hard error if both are set...
>
> Cheers,
>
> Richard
>
>
>


--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its 

Re: [OE-core] Correct way to set DRIDRIVERS and GALLIUMDRIVERS from mesa bbappend

[Alexander Kanavin]

I'd like to see specifics though to understand the use case better. What
kind of target you're on, how much space will be saved by only building the
driver you need and which driver is that? If the drivers are in separate
.so objects, you can simply delete the ones you don't need from
do_install_append. The build time savings would be very minimal.

Alex


On Wed, 1 Dec 2021 at 19:06, Mike Crowe  wrote:

> Hi Alex,
>
> Thanks for responding.
>
> Just to make sure I understand, you think that I should add something like:
>
>  PACKAGECONFIG[i915] = ""
>  PACKAGECONFIG[iris] = ""
>  PACKAGECONFIG[crocus] = ""
>  GALLIUMDRIVERS:append = "${@bb.utils.contains('PACKAGECONFIG', 'i915',
> ',i915', '', d)}"
>  GALLIUMDRIVERS:append = "${@bb.utils.contains('PACKAGECONFIG', 'iris',
> ',iris', '', d)}"
>  GALLIUMDRIVERS:append = "${@bb.utils.contains('PACKAGECONFIG', 'crocus',
> ',crocus', '', d)}"
>
> But then I need to find a way to get "i915 iris crocus" into PACKAGECONFIG
> for x86 and x86-64 whilst still letting others override that. The best I
> can come up with is to modify the existing default PACKAGECONFIG to be
> something like:
>
>  PACKAGECONFIG_DEFAULT_FOR_TARGET:x86 = "i915 iris crocus"
>  PACKAGECONFIG_DEFAULT_FOR_TARGET:x86-64 = "i915 iris crocus"
>  PACKAGECONFIG:class-target ??= "${@bb.utils.filter('DISTRO_FEATURES',
> 'wayland vulkan', d)} \
> ${@bb.utils.contains('DISTRO_FEATURES', 'opengl',
> 'opengl egl gles gbm dri gallium virgl', '', d)} \
> ${@bb.utils.contains('DISTRO_FEATURES', 'x11 opengl',
> 'x11 dri3', '', d)} \
> ${@bb.utils.contains('DISTRO_FEATURES', 'x11 vulkan',
> 'dri3', '', d)} \
> elf-tls \
> ${PACKAGECONFIG_DEFAULT_FOR_TARGET} \
> "
>
> This will probably break anyone who currently sets their own PACKAGECONFIG
> for x86 and x86-64 until they add the drivers they require. This would seem
> to be worse than my GALLIUMDRIVERS_DEFAULT suggestion. :(
>
> Have I misunderstood you, or is there a better way?
>
> Thanks.
>
> Mike.
>
> On Wednesday 01 December 2021 at 18:21:44 +0100, Alexander Kanavin wrote:
> > I think you do need to modify oe-core unfortunately, like is done for
> other
> > drivers:
> >
> > PACKAGECONFIG[etnaviv] = ""
> > GALLIUMDRIVERS:append ="${@bb.utils.contains('PACKAGECONFIG', 'etnaviv',
> > ',etnaviv', '', d)}"
> >
> > Alex
> >
> > On Wed, 1 Dec 2021 at 17:44, Mike Crowe via lists.openembedded.org  > mcrowe@lists.openembedded.org> wrote:
> >
> > > I'm building for a specific chip and therefore don't wish to waste
> time and
> > > electricity building and disk space on the target installing unwanted
> mesa
> > > drivers. However, mesa.inc contains:
> > >
> > >  GALLIUMDRIVERS = "swrast"
> > >  GALLIUMDRIVERS:x86-x32 = ""
> > >  GALLIUMDRIVERS:append:x86:class-target = ",i915,iris,crocus"
> > >  GALLIUMDRIVERS:append:x86-64:class-target = ",i915,iris,crocus"
> > >
> > > and mesa_21.3.0.bb contains:
> > >
> > >  DRIDRIVERS ??= ""
> > >  DRIDRIVERS:append:x86:class-target = ",r100,r200,nouveau,i965"
> > >  DRIDRIVERS:append:x86-64:class-target = ",r100,r200,nouveau,i965"
> > >
> > > I'm unable to find a way to override these values. Using (for example):
> > >
> > >  DRIDRIVERS:forcevariable = ""
> > >  GALLIUMDRIVERS:forcevariable = "swrast"
> > >
> > > doesn't work because the append still happens after the forcevariable
> > > override takes effect. :(
> > >
> > > Is there a way that I can override GALLIUMDRIVERS and DRIDRIVERS with
> my
> > > own values for x86 and x86-64 without modifying oe-core itself?
> > >
> > > If not, should the oe-core recipe being using something like:
> > >
> > >  GALLIUMDRIVERS_DEFAULT = "swrast"
> > >  GALLIUMDRIVERS_DEFAULT:x86-x32 = ""
> > >  GALLIUMDRIVERS_DEFAULT:append:x86:class-target = ",i915,iris,crocus"
> > >  GALLIUMDRIVERS_DEFAULT:append:x86-64:class-target =
> ",i915,iris,crocus"
> > >  GALLIUMDRIVERS ?= "${GALLIUMDRIVERS_DEFAULT}"
> > >
> > > and similar for DRIDRIVERS to support this?
> > >
> > > Thanks.
> > >
> > > Mike.
> > >
> > > 
> > >
> > >
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159059): 
https://lists.openembedded.org/g/openembedded-core/message/159059
Mute This Topic: https://lists.openembedded.org/mt/87432435/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] Correct way to set DRIDRIVERS and GALLIUMDRIVERS from mesa bbappend

[Mike Crowe via lists.openembedded.org]

On Wednesday 01 December 2021 at 14:18:19 -0500, Justin Bronder wrote:
> On 01/12/21 16:43 +, Mike Crowe via lists.openembedded.org wrote:
> > I'm building for a specific chip and therefore don't wish to waste time and
> > electricity building and disk space on the target installing unwanted mesa
> > drivers. However, mesa.inc contains:
> > 
> >  GALLIUMDRIVERS = "swrast"
> >  GALLIUMDRIVERS:x86-x32 = ""
> >  GALLIUMDRIVERS:append:x86:class-target = ",i915,iris,crocus"
> >  GALLIUMDRIVERS:append:x86-64:class-target = ",i915,iris,crocus"
> > 
> > and mesa_21.3.0.bb contains:
> > 
> >  DRIDRIVERS ??= ""
> >  DRIDRIVERS:append:x86:class-target = ",r100,r200,nouveau,i965"
> >  DRIDRIVERS:append:x86-64:class-target = ",r100,r200,nouveau,i965"
> > 
> > I'm unable to find a way to override these values. Using (for example):
> 
> You can use an anonymous python function which runs after parsing.
> https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#anonymous-python-functions
> 
> python __anonymous () {
> d.setVar("DRIDRIVERS", "i965")
> }

Thanks for the suggestion. It solves my problem. However, it seems like
quite a subversive way to do the sort of external customisation that
recipes normally support.

Thanks.

Mike.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159058): 
https://lists.openembedded.org/g/openembedded-core/message/159058
Mute This Topic: https://lists.openembedded.org/mt/87432435/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] Correct way to set DRIDRIVERS and GALLIUMDRIVERS from mesa bbappend

[Justin Bronder]

On 01/12/21 16:43 +, Mike Crowe via lists.openembedded.org wrote:
> I'm building for a specific chip and therefore don't wish to waste time and
> electricity building and disk space on the target installing unwanted mesa
> drivers. However, mesa.inc contains:
> 
>  GALLIUMDRIVERS = "swrast"
>  GALLIUMDRIVERS:x86-x32 = ""
>  GALLIUMDRIVERS:append:x86:class-target = ",i915,iris,crocus"
>  GALLIUMDRIVERS:append:x86-64:class-target = ",i915,iris,crocus"
> 
> and mesa_21.3.0.bb contains:
> 
>  DRIDRIVERS ??= ""
>  DRIDRIVERS:append:x86:class-target = ",r100,r200,nouveau,i965"
>  DRIDRIVERS:append:x86-64:class-target = ",r100,r200,nouveau,i965"
> 
> I'm unable to find a way to override these values. Using (for example):

You can use an anonymous python function which runs after parsing.
https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#anonymous-python-functions

python __anonymous () {
d.setVar("DRIDRIVERS", "i965")
}

-- 
Justin Bronder

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159057): 
https://lists.openembedded.org/g/openembedded-core/message/159057
Mute This Topic: https://lists.openembedded.org/mt/87432435/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] ptest-packagelists: Add missing python3-webcolors entry

[Richard Purdie]

On Wed, 2021-12-01 at 11:58 -0500, Bruce Ashfield wrote:
> On Wed, Dec 1, 2021 at 11:28 AM Quentin Schulz
>  wrote:
> > 
> > Resolves:
> > 
> > WARNING: python3-webcolors-1.11.1-r0 do_package_qa: QA Issue: supports 
> > ptests but is not included in oe-core's ptest-packagelists.inc 
> > [missing-ptest]
> > 
> 
> I haven't seen the warning for this either, and I didn't even know
> this packgelist existed :)
> 
> So thanks for the fix, looks good to me.

I fixed one of these on the autobuilder with your series, I'm just not sure why
the other didn't show up...

Cheers,

Richard


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159056): 
https://lists.openembedded.org/g/openembedded-core/message/159056
Mute This Topic: https://lists.openembedded.org/mt/87432028/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] Correct way to set DRIDRIVERS and GALLIUMDRIVERS from mesa bbappend

[Mike Crowe via lists.openembedded.org]

Hi Alex,

Thanks for responding.

Just to make sure I understand, you think that I should add something like:

 PACKAGECONFIG[i915] = ""
 PACKAGECONFIG[iris] = ""
 PACKAGECONFIG[crocus] = ""
 GALLIUMDRIVERS:append = "${@bb.utils.contains('PACKAGECONFIG', 'i915', 
',i915', '', d)}"
 GALLIUMDRIVERS:append = "${@bb.utils.contains('PACKAGECONFIG', 'iris', 
',iris', '', d)}"
 GALLIUMDRIVERS:append = "${@bb.utils.contains('PACKAGECONFIG', 'crocus', 
',crocus', '', d)}"

But then I need to find a way to get "i915 iris crocus" into PACKAGECONFIG
for x86 and x86-64 whilst still letting others override that. The best I
can come up with is to modify the existing default PACKAGECONFIG to be
something like:

 PACKAGECONFIG_DEFAULT_FOR_TARGET:x86 = "i915 iris crocus"
 PACKAGECONFIG_DEFAULT_FOR_TARGET:x86-64 = "i915 iris crocus"
 PACKAGECONFIG:class-target ??= "${@bb.utils.filter('DISTRO_FEATURES', 'wayland 
vulkan', d)} \
${@bb.utils.contains('DISTRO_FEATURES', 'opengl', 'opengl 
egl gles gbm dri gallium virgl', '', d)} \
${@bb.utils.contains('DISTRO_FEATURES', 'x11 opengl', 'x11 
dri3', '', d)} \
${@bb.utils.contains('DISTRO_FEATURES', 'x11 vulkan', 
'dri3', '', d)} \
elf-tls \
${PACKAGECONFIG_DEFAULT_FOR_TARGET} \
"

This will probably break anyone who currently sets their own PACKAGECONFIG
for x86 and x86-64 until they add the drivers they require. This would seem
to be worse than my GALLIUMDRIVERS_DEFAULT suggestion. :(

Have I misunderstood you, or is there a better way?

Thanks.

Mike.

On Wednesday 01 December 2021 at 18:21:44 +0100, Alexander Kanavin wrote:
> I think you do need to modify oe-core unfortunately, like is done for other
> drivers:
> 
> PACKAGECONFIG[etnaviv] = ""
> GALLIUMDRIVERS:append ="${@bb.utils.contains('PACKAGECONFIG', 'etnaviv',
> ',etnaviv', '', d)}"
> 
> Alex
> 
> On Wed, 1 Dec 2021 at 17:44, Mike Crowe via lists.openembedded.org  mcrowe@lists.openembedded.org> wrote:
> 
> > I'm building for a specific chip and therefore don't wish to waste time and
> > electricity building and disk space on the target installing unwanted mesa
> > drivers. However, mesa.inc contains:
> >
> >  GALLIUMDRIVERS = "swrast"
> >  GALLIUMDRIVERS:x86-x32 = ""
> >  GALLIUMDRIVERS:append:x86:class-target = ",i915,iris,crocus"
> >  GALLIUMDRIVERS:append:x86-64:class-target = ",i915,iris,crocus"
> >
> > and mesa_21.3.0.bb contains:
> >
> >  DRIDRIVERS ??= ""
> >  DRIDRIVERS:append:x86:class-target = ",r100,r200,nouveau,i965"
> >  DRIDRIVERS:append:x86-64:class-target = ",r100,r200,nouveau,i965"
> >
> > I'm unable to find a way to override these values. Using (for example):
> >
> >  DRIDRIVERS:forcevariable = ""
> >  GALLIUMDRIVERS:forcevariable = "swrast"
> >
> > doesn't work because the append still happens after the forcevariable
> > override takes effect. :(
> >
> > Is there a way that I can override GALLIUMDRIVERS and DRIDRIVERS with my
> > own values for x86 and x86-64 without modifying oe-core itself?
> >
> > If not, should the oe-core recipe being using something like:
> >
> >  GALLIUMDRIVERS_DEFAULT = "swrast"
> >  GALLIUMDRIVERS_DEFAULT:x86-x32 = ""
> >  GALLIUMDRIVERS_DEFAULT:append:x86:class-target = ",i915,iris,crocus"
> >  GALLIUMDRIVERS_DEFAULT:append:x86-64:class-target = ",i915,iris,crocus"
> >  GALLIUMDRIVERS ?= "${GALLIUMDRIVERS_DEFAULT}"
> >
> > and similar for DRIDRIVERS to support this?
> >
> > Thanks.
> >
> > Mike.
> >
> > 
> >
> >

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159055): 
https://lists.openembedded.org/g/openembedded-core/message/159055
Mute This Topic: https://lists.openembedded.org/mt/87432435/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] python: python3-idna: fix non-existent Unicode license

[Konrad Weihmann]

On 01.12.21 18:20, Quentin Schulz wrote:

Hi Konrad,

On Wed, Dec 01, 2021 at 06:04:36PM +0100, Konrad Weihmann wrote:

I'm kind of following the argumentation in the commit message, still I see
differences between the Unicode-DFS-2016 template file and the text
downloadable from 
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.unicode.org_license.txt=DwICaQ=_sEr5x9kUWhuk4_nFwjJtA=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t=-XEY2f17PVO0eg4ZpVBl4VpV5wPmG0K8z8LDsTQAPRs7x2MriQXaHDjlbwAVuKMk=TL5gUxzxy8LLKVu26a2BDDq1J8fal1pDvVz0ry1MulM=
.

Not much, but enough to make me think, if we wouldn't instead need a
Unicode-DFS-2021 file and reference to that.



We'd need to upload the new license to spdx and I've absolutely no clue
if the differences are enough to warrant a new SPDX entry... especially
since AFAICT, it's just that some of the content is moved to
copyright.txt (which is linked in the new license.txt) resulting to me
to basically a noop? But me stating it was a match was incorrect, thanks
for pointing this out.


Yeah, I'm also not a 100% sure if that's worth all the hustle - maybe 
someone with a more legal like background could just add her/his two 
cents, so things could be cleaned up in a followup





Anyway I fully support that change

On a different note - I think any unicode license reference would also need
a copy of 
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.unicode.org_copyright.html=DwICaQ=_sEr5x9kUWhuk4_nFwjJtA=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t=-XEY2f17PVO0eg4ZpVBl4VpV5wPmG0K8z8LDsTQAPRs7x2MriQXaHDjlbwAVuKMk=GCcxTAmd-wOZF6SPpTOHW392veMDM8RBwO_IAMvDbZA=
, as all the downloads point to that (and the license in just a subset of a
broader scope of rights and regulations) - INAL, but from my limited legal
understanding we should reference both



AFAICT, this looks like it would be Unicode-TOU but it's again not a
perfect match.

So /me shrugs, don't know what we should be doing with that except
fixing the warning one way or the other (preferrably the best one :) ).


same here - *calling for lawyers to jump into the discussion* :)

Still I think the patch should be picked as it is, as it clearly solves 
an issue, that I've seen as well.




Cheers,
Quentin


On 01.12.21 17:13, Quentin Schulz wrote:

In addition to not being an SPDX license, Unicode license also isn't
available in any of the LICENSE_PATH available in openembedded, meaning
the following warning is printed:

python3-idna: No generic license file exists for: Unicode in any provider 
[license-exists]

Unfortunately the license is not really explicit in the project. After
looking at the code, it seems that this license gets pulled by
idna/idnadata.py and idna/uts46data.py which are auto-generated by
tools/idna-data which downloads data from
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.unicode.org_Public_-257Bversion-257D_ucd_=DwICaQ=_sEr5x9kUWhuk4_nFwjJtA=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t=-XEY2f17PVO0eg4ZpVBl4VpV5wPmG0K8z8LDsTQAPRs7x2MriQXaHDjlbwAVuKMk=NVUVu2hKfeamx4mn_29KhgBwY_drrHGSIiEbbTpoUsk=
  and
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.unicode.org_Public_idna_=DwICaQ=_sEr5x9kUWhuk4_nFwjJtA=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t=-XEY2f17PVO0eg4ZpVBl4VpV5wPmG0K8z8LDsTQAPRs7x2MriQXaHDjlbwAVuKMk=XmJGToF17xNKllS2M3Zw4q82BF0PBORm7gMWm2E6sgA=
  which are covered by
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.unicode.org_license.txt=DwICaQ=_sEr5x9kUWhuk4_nFwjJtA=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t=-XEY2f17PVO0eg4ZpVBl4VpV5wPmG0K8z8LDsTQAPRs7x2MriQXaHDjlbwAVuKMk=TL5gUxzxy8LLKVu26a2BDDq1J8fal1pDvVz0ry1MulM=
  as mentioned in
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.unicode.org_copyright.html=DwICaQ=_sEr5x9kUWhuk4_nFwjJtA=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t=-XEY2f17PVO0eg4ZpVBl4VpV5wPmG0K8z8LDsTQAPRs7x2MriQXaHDjlbwAVuKMk=GCcxTAmd-wOZF6SPpTOHW392veMDM8RBwO_IAMvDbZA=
 .

Comparing 
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.unicode.org_license.txt=DwICaQ=_sEr5x9kUWhuk4_nFwjJtA=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t=-XEY2f17PVO0eg4ZpVBl4VpV5wPmG0K8z8LDsTQAPRs7x2MriQXaHDjlbwAVuKMk=TL5gUxzxy8LLKVu26a2BDDq1J8fal1pDvVz0ry1MulM=
  to Unicode-DFS-2016
resulted in a match so let's point to that SPDX license instead.

Cc: Quentin Schulz 
Signed-off-by: Quentin Schulz 
---
   meta/recipes-devtools/python/python3-idna_3.3.bb | 7 ++-
   1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/python/python3-idna_3.3.bb 
b/meta/recipes-devtools/python/python3-idna_3.3.bb
index a0e6b79a56..f3c53a8717 100644
--- a/meta/recipes-devtools/python/python3-idna_3.3.bb
+++ b/meta/recipes-devtools/python/python3-idna_3.3.bb
@@ -1,6 +1,11 @@
   SUMMARY = "Internationalised Domain Names in Applications"
   HOMEPAGE = 

Re: [OE-core] Correct way to set DRIDRIVERS and GALLIUMDRIVERS from mesa bbappend

[Alexander Kanavin]

I think you do need to modify oe-core unfortunately, like is done for other
drivers:

PACKAGECONFIG[etnaviv] = ""
GALLIUMDRIVERS:append ="${@bb.utils.contains('PACKAGECONFIG', 'etnaviv',
',etnaviv', '', d)}"

Alex

On Wed, 1 Dec 2021 at 17:44, Mike Crowe via lists.openembedded.org  wrote:

> I'm building for a specific chip and therefore don't wish to waste time and
> electricity building and disk space on the target installing unwanted mesa
> drivers. However, mesa.inc contains:
>
>  GALLIUMDRIVERS = "swrast"
>  GALLIUMDRIVERS:x86-x32 = ""
>  GALLIUMDRIVERS:append:x86:class-target = ",i915,iris,crocus"
>  GALLIUMDRIVERS:append:x86-64:class-target = ",i915,iris,crocus"
>
> and mesa_21.3.0.bb contains:
>
>  DRIDRIVERS ??= ""
>  DRIDRIVERS:append:x86:class-target = ",r100,r200,nouveau,i965"
>  DRIDRIVERS:append:x86-64:class-target = ",r100,r200,nouveau,i965"
>
> I'm unable to find a way to override these values. Using (for example):
>
>  DRIDRIVERS:forcevariable = ""
>  GALLIUMDRIVERS:forcevariable = "swrast"
>
> doesn't work because the append still happens after the forcevariable
> override takes effect. :(
>
> Is there a way that I can override GALLIUMDRIVERS and DRIDRIVERS with my
> own values for x86 and x86-64 without modifying oe-core itself?
>
> If not, should the oe-core recipe being using something like:
>
>  GALLIUMDRIVERS_DEFAULT = "swrast"
>  GALLIUMDRIVERS_DEFAULT:x86-x32 = ""
>  GALLIUMDRIVERS_DEFAULT:append:x86:class-target = ",i915,iris,crocus"
>  GALLIUMDRIVERS_DEFAULT:append:x86-64:class-target = ",i915,iris,crocus"
>  GALLIUMDRIVERS ?= "${GALLIUMDRIVERS_DEFAULT}"
>
> and similar for DRIDRIVERS to support this?
>
> Thanks.
>
> Mike.
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159053): 
https://lists.openembedded.org/g/openembedded-core/message/159053
Mute This Topic: https://lists.openembedded.org/mt/87432435/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] python: python3-idna: fix non-existent Unicode license

[Quentin Schulz]

Hi Konrad,

On Wed, Dec 01, 2021 at 06:04:36PM +0100, Konrad Weihmann wrote:
> I'm kind of following the argumentation in the commit message, still I see
> differences between the Unicode-DFS-2016 template file and the text
> downloadable from 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.unicode.org_license.txt=DwICaQ=_sEr5x9kUWhuk4_nFwjJtA=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t=-XEY2f17PVO0eg4ZpVBl4VpV5wPmG0K8z8LDsTQAPRs7x2MriQXaHDjlbwAVuKMk=TL5gUxzxy8LLKVu26a2BDDq1J8fal1pDvVz0ry1MulM=
> .
> 
> Not much, but enough to make me think, if we wouldn't instead need a
> Unicode-DFS-2021 file and reference to that.
> 

We'd need to upload the new license to spdx and I've absolutely no clue
if the differences are enough to warrant a new SPDX entry... especially
since AFAICT, it's just that some of the content is moved to
copyright.txt (which is linked in the new license.txt) resulting to me
to basically a noop? But me stating it was a match was incorrect, thanks
for pointing this out.

> Anyway I fully support that change
> 
> On a different note - I think any unicode license reference would also need
> a copy of 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.unicode.org_copyright.html=DwICaQ=_sEr5x9kUWhuk4_nFwjJtA=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t=-XEY2f17PVO0eg4ZpVBl4VpV5wPmG0K8z8LDsTQAPRs7x2MriQXaHDjlbwAVuKMk=GCcxTAmd-wOZF6SPpTOHW392veMDM8RBwO_IAMvDbZA=
> , as all the downloads point to that (and the license in just a subset of a
> broader scope of rights and regulations) - INAL, but from my limited legal
> understanding we should reference both
> 

AFAICT, this looks like it would be Unicode-TOU but it's again not a
perfect match.

So /me shrugs, don't know what we should be doing with that except
fixing the warning one way or the other (preferrably the best one :) ).

Cheers,
Quentin

> On 01.12.21 17:13, Quentin Schulz wrote:
> > In addition to not being an SPDX license, Unicode license also isn't
> > available in any of the LICENSE_PATH available in openembedded, meaning
> > the following warning is printed:
> > 
> > python3-idna: No generic license file exists for: Unicode in any provider 
> > [license-exists]
> > 
> > Unfortunately the license is not really explicit in the project. After
> > looking at the code, it seems that this license gets pulled by
> > idna/idnadata.py and idna/uts46data.py which are auto-generated by
> > tools/idna-data which downloads data from
> > https://urldefense.proofpoint.com/v2/url?u=http-3A__www.unicode.org_Public_-257Bversion-257D_ucd_=DwICaQ=_sEr5x9kUWhuk4_nFwjJtA=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t=-XEY2f17PVO0eg4ZpVBl4VpV5wPmG0K8z8LDsTQAPRs7x2MriQXaHDjlbwAVuKMk=NVUVu2hKfeamx4mn_29KhgBwY_drrHGSIiEbbTpoUsk=
> >   and
> > https://urldefense.proofpoint.com/v2/url?u=http-3A__www.unicode.org_Public_idna_=DwICaQ=_sEr5x9kUWhuk4_nFwjJtA=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t=-XEY2f17PVO0eg4ZpVBl4VpV5wPmG0K8z8LDsTQAPRs7x2MriQXaHDjlbwAVuKMk=XmJGToF17xNKllS2M3Zw4q82BF0PBORm7gMWm2E6sgA=
> >   which are covered by
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.unicode.org_license.txt=DwICaQ=_sEr5x9kUWhuk4_nFwjJtA=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t=-XEY2f17PVO0eg4ZpVBl4VpV5wPmG0K8z8LDsTQAPRs7x2MriQXaHDjlbwAVuKMk=TL5gUxzxy8LLKVu26a2BDDq1J8fal1pDvVz0ry1MulM=
> >   as mentioned in
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.unicode.org_copyright.html=DwICaQ=_sEr5x9kUWhuk4_nFwjJtA=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t=-XEY2f17PVO0eg4ZpVBl4VpV5wPmG0K8z8LDsTQAPRs7x2MriQXaHDjlbwAVuKMk=GCcxTAmd-wOZF6SPpTOHW392veMDM8RBwO_IAMvDbZA=
> >  .
> > 
> > Comparing 
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.unicode.org_license.txt=DwICaQ=_sEr5x9kUWhuk4_nFwjJtA=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t=-XEY2f17PVO0eg4ZpVBl4VpV5wPmG0K8z8LDsTQAPRs7x2MriQXaHDjlbwAVuKMk=TL5gUxzxy8LLKVu26a2BDDq1J8fal1pDvVz0ry1MulM=
> >   to Unicode-DFS-2016
> > resulted in a match so let's point to that SPDX license instead.
> > 
> > Cc: Quentin Schulz 
> > Signed-off-by: Quentin Schulz 
> > ---
> >   meta/recipes-devtools/python/python3-idna_3.3.bb | 7 ++-
> >   1 file changed, 6 insertions(+), 1 deletion(-)
> > 
> > diff --git a/meta/recipes-devtools/python/python3-idna_3.3.bb 
> > b/meta/recipes-devtools/python/python3-idna_3.3.bb
> > index a0e6b79a56..f3c53a8717 100644
> > --- a/meta/recipes-devtools/python/python3-idna_3.3.bb
> > +++ b/meta/recipes-devtools/python/python3-idna_3.3.bb
> > @@ -1,6 +1,11 @@
> >   SUMMARY = "Internationalised Domain Names in Applications"
> >   HOMEPAGE = 
> > 

Re: [OE-core] [PATCH] python: python3-idna: fix non-existent Unicode license

[Konrad Weihmann]

I'm kind of following the argumentation in the commit message, still I 
see differences between the Unicode-DFS-2016 template file and the text 
downloadable from https://www.unicode.org/license.txt.


Not much, but enough to make me think, if we wouldn't instead need a 
Unicode-DFS-2021 file and reference to that.


Anyway I fully support that change

On a different note - I think any unicode license reference would also 
need a copy of https://www.unicode.org/copyright.html, as all the 
downloads point to that (and the license in just a subset of a broader 
scope of rights and regulations) - INAL, but from my limited legal 
understanding we should reference both


On 01.12.21 17:13, Quentin Schulz wrote:

In addition to not being an SPDX license, Unicode license also isn't
available in any of the LICENSE_PATH available in openembedded, meaning
the following warning is printed:

python3-idna: No generic license file exists for: Unicode in any provider 
[license-exists]

Unfortunately the license is not really explicit in the project. After
looking at the code, it seems that this license gets pulled by
idna/idnadata.py and idna/uts46data.py which are auto-generated by
tools/idna-data which downloads data from
http://www.unicode.org/Public/{version}/ucd/ and
http://www.unicode.org/Public/idna/ which are covered by
https://www.unicode.org/license.txt as mentioned in
https://www.unicode.org/copyright.html.

Comparing https://www.unicode.org/license.txt to Unicode-DFS-2016
resulted in a match so let's point to that SPDX license instead.

Cc: Quentin Schulz 
Signed-off-by: Quentin Schulz 
---
  meta/recipes-devtools/python/python3-idna_3.3.bb | 7 ++-
  1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/python/python3-idna_3.3.bb 
b/meta/recipes-devtools/python/python3-idna_3.3.bb
index a0e6b79a56..f3c53a8717 100644
--- a/meta/recipes-devtools/python/python3-idna_3.3.bb
+++ b/meta/recipes-devtools/python/python3-idna_3.3.bb
@@ -1,6 +1,11 @@
  SUMMARY = "Internationalised Domain Names in Applications"
  HOMEPAGE = "https://github.com/kjd/idna;
-LICENSE = "BSD-3-Clause & Python-2.0 & Unicode"
+# Note: Unicode license is pulled in by idna/idnadata.py and idna/uts46data.py
+# files auto-generated by tools/idna-data which downloads data from
+# http://www.unicode.org/Public/{version}/ucd/ and 
http://www.unicode.org/Public/idna/
+# which are covered by https://www.unicode.org/license.txt as mentioned by
+# https://www.unicode.org/copyright.html
+LICENSE = "BSD-3-Clause & Python-2.0 & Unicode-DFS-2016"
  LIC_FILES_CHKSUM = "file://LICENSE.md;md5=239668a7c6066d9e0c5382e9c8c6c0e1"
  
  SRC_URI[sha256sum] = "9d643ff0a55b762d5cdb124b8eaa99c66322e2157b69160bc32796e824360e6d"







-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159051): 
https://lists.openembedded.org/g/openembedded-core/message/159051
Mute This Topic: https://lists.openembedded.org/mt/87431709/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] ptest-packagelists: Add missing python3-webcolors entry

[Bruce Ashfield]

On Wed, Dec 1, 2021 at 11:28 AM Quentin Schulz
 wrote:
>
> Resolves:
>
> WARNING: python3-webcolors-1.11.1-r0 do_package_qa: QA Issue: supports ptests 
> but is not included in oe-core's ptest-packagelists.inc [missing-ptest]
>

I haven't seen the warning for this either, and I didn't even know
this packgelist existed :)

So thanks for the fix, looks good to me.

Bruce

> Cc: Quentin Schulz 
> Signed-off-by: Quentin Schulz 
> ---
>
> Note: Not tested
>
>  meta/conf/distro/include/ptest-packagelists.inc | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/meta/conf/distro/include/ptest-packagelists.inc 
> b/meta/conf/distro/include/ptest-packagelists.inc
> index bf9d158a0a..c503a6a594 100644
> --- a/meta/conf/distro/include/ptest-packagelists.inc
> +++ b/meta/conf/distro/include/ptest-packagelists.inc
> @@ -56,6 +56,7 @@ PTESTS_FAST = "\
>  python3-more-itertools-ptest \
>  python3-pluggy-ptest \
>  python3-wcwidth-ptest \
> +python3-webcolors-ptest \
>  qemu-ptest \
>  quilt-ptest \
>  sed-ptest \
> --
> 2.33.1
>


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

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159050): 
https://lists.openembedded.org/g/openembedded-core/message/159050
Mute This Topic: https://lists.openembedded.org/mt/87432028/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] python: python3-idna: fix non-existent Unicode license

[Bruce Ashfield]

On Wed, Dec 1, 2021 at 11:13 AM Quentin Schulz
 wrote:
>
> In addition to not being an SPDX license, Unicode license also isn't
> available in any of the LICENSE_PATH available in openembedded, meaning
> the following warning is printed:
>
> python3-idna: No generic license file exists for: Unicode in any provider 
> [license-exists]
>
> Unfortunately the license is not really explicit in the project. After
> looking at the code, it seems that this license gets pulled by
> idna/idnadata.py and idna/uts46data.py which are auto-generated by
> tools/idna-data which downloads data from
> http://www.unicode.org/Public/{version}/ucd/ and
> http://www.unicode.org/Public/idna/ which are covered by
> https://www.unicode.org/license.txt as mentioned in
> https://www.unicode.org/copyright.html.
>
> Comparing https://www.unicode.org/license.txt to Unicode-DFS-2016
> resulted in a match so let's point to that SPDX license instead.

I'm not able to reproduce the warning yet, but the license cleanup
makes sense even without that.

Looks good to me.

Bruce


>
> Cc: Quentin Schulz 
> Signed-off-by: Quentin Schulz 
> ---
>  meta/recipes-devtools/python/python3-idna_3.3.bb | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/meta/recipes-devtools/python/python3-idna_3.3.bb 
> b/meta/recipes-devtools/python/python3-idna_3.3.bb
> index a0e6b79a56..f3c53a8717 100644
> --- a/meta/recipes-devtools/python/python3-idna_3.3.bb
> +++ b/meta/recipes-devtools/python/python3-idna_3.3.bb
> @@ -1,6 +1,11 @@
>  SUMMARY = "Internationalised Domain Names in Applications"
>  HOMEPAGE = "https://github.com/kjd/idna;
> -LICENSE = "BSD-3-Clause & Python-2.0 & Unicode"
> +# Note: Unicode license is pulled in by idna/idnadata.py and 
> idna/uts46data.py
> +# files auto-generated by tools/idna-data which downloads data from
> +# http://www.unicode.org/Public/{version}/ucd/ and 
> http://www.unicode.org/Public/idna/
> +# which are covered by https://www.unicode.org/license.txt as mentioned by
> +# https://www.unicode.org/copyright.html
> +LICENSE = "BSD-3-Clause & Python-2.0 & Unicode-DFS-2016"
>  LIC_FILES_CHKSUM = "file://LICENSE.md;md5=239668a7c6066d9e0c5382e9c8c6c0e1"
>
>  SRC_URI[sha256sum] = 
> "9d643ff0a55b762d5cdb124b8eaa99c66322e2157b69160bc32796e824360e6d"
> --
> 2.33.1
>


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

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

[OE-core] Correct way to set DRIDRIVERS and GALLIUMDRIVERS from mesa bbappend

[Mike Crowe via lists.openembedded.org]

I'm building for a specific chip and therefore don't wish to waste time and
electricity building and disk space on the target installing unwanted mesa
drivers. However, mesa.inc contains:

 GALLIUMDRIVERS = "swrast"
 GALLIUMDRIVERS:x86-x32 = ""
 GALLIUMDRIVERS:append:x86:class-target = ",i915,iris,crocus"
 GALLIUMDRIVERS:append:x86-64:class-target = ",i915,iris,crocus"

and mesa_21.3.0.bb contains:

 DRIDRIVERS ??= ""
 DRIDRIVERS:append:x86:class-target = ",r100,r200,nouveau,i965"
 DRIDRIVERS:append:x86-64:class-target = ",r100,r200,nouveau,i965"

I'm unable to find a way to override these values. Using (for example):

 DRIDRIVERS:forcevariable = ""
 GALLIUMDRIVERS:forcevariable = "swrast"

doesn't work because the append still happens after the forcevariable
override takes effect. :(

Is there a way that I can override GALLIUMDRIVERS and DRIDRIVERS with my
own values for x86 and x86-64 without modifying oe-core itself?

If not, should the oe-core recipe being using something like:

 GALLIUMDRIVERS_DEFAULT = "swrast"
 GALLIUMDRIVERS_DEFAULT:x86-x32 = ""
 GALLIUMDRIVERS_DEFAULT:append:x86:class-target = ",i915,iris,crocus"
 GALLIUMDRIVERS_DEFAULT:append:x86-64:class-target = ",i915,iris,crocus"
 GALLIUMDRIVERS ?= "${GALLIUMDRIVERS_DEFAULT}"

and similar for DRIDRIVERS to support this?

Thanks.

Mike.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159048): 
https://lists.openembedded.org/g/openembedded-core/message/159048
Mute This Topic: https://lists.openembedded.org/mt/87432435/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] ptest-packagelists: Add missing python3-webcolors entry

[Quentin Schulz]

Resolves:

WARNING: python3-webcolors-1.11.1-r0 do_package_qa: QA Issue: supports ptests 
but is not included in oe-core's ptest-packagelists.inc [missing-ptest]

Cc: Quentin Schulz 
Signed-off-by: Quentin Schulz 
---

Note: Not tested

 meta/conf/distro/include/ptest-packagelists.inc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/conf/distro/include/ptest-packagelists.inc 
b/meta/conf/distro/include/ptest-packagelists.inc
index bf9d158a0a..c503a6a594 100644
--- a/meta/conf/distro/include/ptest-packagelists.inc
+++ b/meta/conf/distro/include/ptest-packagelists.inc
@@ -56,6 +56,7 @@ PTESTS_FAST = "\
 python3-more-itertools-ptest \
 python3-pluggy-ptest \
 python3-wcwidth-ptest \
+python3-webcolors-ptest \
 qemu-ptest \
 quilt-ptest \
 sed-ptest \
-- 
2.33.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159047): 
https://lists.openembedded.org/g/openembedded-core/message/159047
Mute This Topic: https://lists.openembedded.org/mt/87432028/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 v2] patch.py: Initialize git repo before patching

[Alexander Kanavin]

Nevermind, I do now :)

Alex

On Wed, 1 Dec 2021 at 17:26, Alexander Kanavin 
wrote:

> Not seeing that in v4 :)
>
> Alex
>
> On Wed, 1 Dec 2021 at 17:14, Pavel Zhukov  wrote:
>
>> Thanks. Done in v4.
>>
>> --
>> Pavel
>>
>>
>>
>> 01.12.2021, 17:08, "Alexander Kanavin" :
>>
>> Thanks :) You can add the failure into the commit message.
>>
>> Alex
>>
>> On Wed, 1 Dec 2021 at 17:00, Pavel Zhukov  wrote:
>>
>> without change in patch.py:
>> ERROR: man-db-2.9.0-r1 do_patch: Applying patch
>> 'man_db.conf-avoid-multilib-install-file-conflict.patch' on target
>> directory
>> '/mnt/builds/oniroproject/builds/build-oniro-linux-st/tmp/work/core2-64-oniro-linux-musl/man-db/2.9.0-r1/man-db-2.9.0'
>> Command Error: 'git rev-parse --show-toplevel' exited with 0  Output:
>> fatal: not a git repository (or any of the parent directories): .git
>> ERROR: Logfile of failure stored in:
>> /mnt/builds/oniroproject/builds/build-oniro-linux-st/tmp/work/core2-64-oniro-linux-musl/man-db/2.9.0-r1/temp/log.do_patch.21491
>> NOTE: recipe man-db-2.9.0-r1: task do_patch: Failed
>> ERROR: Task
>> (/mnt/builds/oniroproject/sources/oe-core/meta/recipes-extended/man-db/man-db_2.9.0.bb:do_patch)
>> failed with exit code '1'
>> NOTE: Tasks Summary: Attempted 102 tasks of which 0 didn't need to be
>> rerun and 1 failed.
>>
>> Summary: 1 task failed:
>>
>> /mnt/builds/oniroproject/sources/oe-core/meta/recipes-extended/man-db/man-db_2.9.0.bb:
>> do_patch
>> Summary: There was 1 ERROR message shown, returning a non-zero exit code.
>> --
>> 2021-12-01 15:11:56,184 - oe-selftest - INFO - Ran 1 test in 147.083s
>> 2021-12-01 15:11:56,184 - oe-selftest - INFO - FAILED
>> 2021-12-01 15:11:56,184 - oe-selftest - INFO -  (failures=1)
>> 2021-12-01 15:11:58,721 - oe-selftest - INFO - RESULTS:
>> 2021-12-01 15:11:58,722 - oe-selftest - INFO - RESULTS -
>> bbtests.BitbakeTests.test_git_patchtool: FAILED (145.51s)
>> 2021-12-01 15:11:58,724 - oe-selftest - INFO - SUMMARY:
>> 2021-12-01 15:11:58,724 - oe-selftest - INFO - oe-selftest () - Ran 1
>> test in 147.084s
>> 2021-12-01 15:11:58,724 - oe-selftest - INFO - oe-selftest - FAIL -
>> Required tests failed (successes=0, skipped=0, failures=1, errors=0)
>>
>>
>> with change in patch.py:
>> 2021-12-01 15:12:20,910 - oe-selftest - INFO - Adding: "include
>> selftest.inc" in
>> /mnt/builds/oniroproject/builds/build-oniro-linux-st/conf/local.conf
>> 2021-12-01 15:12:20,911 - oe-selftest - INFO - Adding: "include
>> bblayers.inc" in bblayers.conf
>> 2021-12-01 15:12:20,911 - oe-selftest - INFO - test_git_patchtool
>> (bbtests.BitbakeTests)
>> 2021-12-01 15:15:30,540 - oe-selftest - INFO -  ... ok
>> 2021-12-01 15:15:31,717 - oe-selftest - INFO -
>> --
>> 2021-12-01 15:15:31,717 - oe-selftest - INFO - Ran 1 test in 192.371s
>> 2021-12-01 15:15:31,717 - oe-selftest - INFO - OK
>> 2021-12-01 15:15:34,523 - oe-selftest - INFO - RESULTS:
>> 2021-12-01 15:15:34,524 - oe-selftest - INFO - RESULTS -
>> bbtests.BitbakeTests.test_git_patchtool: PASSED (189.63s)
>> 2021-12-01 15:15:34,526 - oe-selftest - INFO - SUMMARY:
>> 2021-12-01 15:15:34,526 - oe-selftest - INFO - oe-selftest () - Ran 1
>> test in 192.372s
>> 2021-12-01 15:15:34,526 - oe-selftest - INFO - oe-selftest - OK - All
>> required tests passed (successes=1, skipped=0, failures=0, errors=0)
>>
>>
>> --
>> Pavel
>>
>>
>>
>> 01.12.2021, 16:56, "Alexander Kanavin" :
>>
>> Does the test fail without the change in lib/oepatch.py? Can you show how?
>>
>> Alex
>>
>> On Wed, 1 Dec 2021 at 15:17, Pavel Zhukov  wrote:
>>
>> From: Pavel Zhukov 
>>
>> If PATCHTOOL="git" has been specified but workdir is not git repo
>> bitbake fails to apply the patches. Fix this by initializing the repo
>> before patching.
>> This allows binary git patches to be applied.
>>
>> Signed-off-by: Pavel Zhukov 
>> ---
>>  meta/lib/oe/patch.py| 17 +
>>  meta/lib/oeqa/selftest/cases/bbtests.py |  6 ++
>>  2 files changed, 23 insertions(+)
>>
>> diff --git a/meta/lib/oe/patch.py b/meta/lib/oe/patch.py
>> index 7cd8436da5..720c6f663c 100644
>> --- a/meta/lib/oe/patch.py
>> +++ b/meta/lib/oe/patch.py
>> @@ -52,6 +52,10 @@ def runcmd(args, dir = None):
>>  if dir:
>>  os.chdir(olddir)
>>
>> +def getstatusoutput(cmd):
>> +import subprocess
>> +return subprocess.getstatusoutput(cmd.split())
>> +
>>  class PatchError(Exception):
>>  def __init__(self, msg):
>>  self.msg = msg
>> @@ -294,6 +298,19 @@ class GitApplyTree(PatchTree):
>>  PatchTree.__init__(self, dir, d)
>>  self.commituser = d.getVar('PATCH_GIT_USER_NAME')
>>  self.commitemail = d.getVar('PATCH_GIT_USER_EMAIL')
>> +if not self._isInitialized():
>> +self._initRepo()
>> +
>> +def _isInitialized(self):
>> +cmd = "git rev-parse --show-toplevel"
>> +(status, output) = 

Re: [OE-core] [meta-oe][PATCH v2] patch.py: Initialize git repo before patching

[Alexander Kanavin]

Not seeing that in v4 :)

Alex

On Wed, 1 Dec 2021 at 17:14, Pavel Zhukov  wrote:

> Thanks. Done in v4.
>
> --
> Pavel
>
>
>
> 01.12.2021, 17:08, "Alexander Kanavin" :
>
> Thanks :) You can add the failure into the commit message.
>
> Alex
>
> On Wed, 1 Dec 2021 at 17:00, Pavel Zhukov  wrote:
>
> without change in patch.py:
> ERROR: man-db-2.9.0-r1 do_patch: Applying patch
> 'man_db.conf-avoid-multilib-install-file-conflict.patch' on target
> directory
> '/mnt/builds/oniroproject/builds/build-oniro-linux-st/tmp/work/core2-64-oniro-linux-musl/man-db/2.9.0-r1/man-db-2.9.0'
> Command Error: 'git rev-parse --show-toplevel' exited with 0  Output:
> fatal: not a git repository (or any of the parent directories): .git
> ERROR: Logfile of failure stored in:
> /mnt/builds/oniroproject/builds/build-oniro-linux-st/tmp/work/core2-64-oniro-linux-musl/man-db/2.9.0-r1/temp/log.do_patch.21491
> NOTE: recipe man-db-2.9.0-r1: task do_patch: Failed
> ERROR: Task
> (/mnt/builds/oniroproject/sources/oe-core/meta/recipes-extended/man-db/man-db_2.9.0.bb:do_patch)
> failed with exit code '1'
> NOTE: Tasks Summary: Attempted 102 tasks of which 0 didn't need to be
> rerun and 1 failed.
>
> Summary: 1 task failed:
>
> /mnt/builds/oniroproject/sources/oe-core/meta/recipes-extended/man-db/man-db_2.9.0.bb:
> do_patch
> Summary: There was 1 ERROR message shown, returning a non-zero exit code.
> --
> 2021-12-01 15:11:56,184 - oe-selftest - INFO - Ran 1 test in 147.083s
> 2021-12-01 15:11:56,184 - oe-selftest - INFO - FAILED
> 2021-12-01 15:11:56,184 - oe-selftest - INFO -  (failures=1)
> 2021-12-01 15:11:58,721 - oe-selftest - INFO - RESULTS:
> 2021-12-01 15:11:58,722 - oe-selftest - INFO - RESULTS -
> bbtests.BitbakeTests.test_git_patchtool: FAILED (145.51s)
> 2021-12-01 15:11:58,724 - oe-selftest - INFO - SUMMARY:
> 2021-12-01 15:11:58,724 - oe-selftest - INFO - oe-selftest () - Ran 1 test
> in 147.084s
> 2021-12-01 15:11:58,724 - oe-selftest - INFO - oe-selftest - FAIL -
> Required tests failed (successes=0, skipped=0, failures=1, errors=0)
>
>
> with change in patch.py:
> 2021-12-01 15:12:20,910 - oe-selftest - INFO - Adding: "include
> selftest.inc" in
> /mnt/builds/oniroproject/builds/build-oniro-linux-st/conf/local.conf
> 2021-12-01 15:12:20,911 - oe-selftest - INFO - Adding: "include
> bblayers.inc" in bblayers.conf
> 2021-12-01 15:12:20,911 - oe-selftest - INFO - test_git_patchtool
> (bbtests.BitbakeTests)
> 2021-12-01 15:15:30,540 - oe-selftest - INFO -  ... ok
> 2021-12-01 15:15:31,717 - oe-selftest - INFO -
> --
> 2021-12-01 15:15:31,717 - oe-selftest - INFO - Ran 1 test in 192.371s
> 2021-12-01 15:15:31,717 - oe-selftest - INFO - OK
> 2021-12-01 15:15:34,523 - oe-selftest - INFO - RESULTS:
> 2021-12-01 15:15:34,524 - oe-selftest - INFO - RESULTS -
> bbtests.BitbakeTests.test_git_patchtool: PASSED (189.63s)
> 2021-12-01 15:15:34,526 - oe-selftest - INFO - SUMMARY:
> 2021-12-01 15:15:34,526 - oe-selftest - INFO - oe-selftest () - Ran 1 test
> in 192.372s
> 2021-12-01 15:15:34,526 - oe-selftest - INFO - oe-selftest - OK - All
> required tests passed (successes=1, skipped=0, failures=0, errors=0)
>
>
> --
> Pavel
>
>
>
> 01.12.2021, 16:56, "Alexander Kanavin" :
>
> Does the test fail without the change in lib/oepatch.py? Can you show how?
>
> Alex
>
> On Wed, 1 Dec 2021 at 15:17, Pavel Zhukov  wrote:
>
> From: Pavel Zhukov 
>
> If PATCHTOOL="git" has been specified but workdir is not git repo
> bitbake fails to apply the patches. Fix this by initializing the repo
> before patching.
> This allows binary git patches to be applied.
>
> Signed-off-by: Pavel Zhukov 
> ---
>  meta/lib/oe/patch.py| 17 +
>  meta/lib/oeqa/selftest/cases/bbtests.py |  6 ++
>  2 files changed, 23 insertions(+)
>
> diff --git a/meta/lib/oe/patch.py b/meta/lib/oe/patch.py
> index 7cd8436da5..720c6f663c 100644
> --- a/meta/lib/oe/patch.py
> +++ b/meta/lib/oe/patch.py
> @@ -52,6 +52,10 @@ def runcmd(args, dir = None):
>  if dir:
>  os.chdir(olddir)
>
> +def getstatusoutput(cmd):
> +import subprocess
> +return subprocess.getstatusoutput(cmd.split())
> +
>  class PatchError(Exception):
>  def __init__(self, msg):
>  self.msg = msg
> @@ -294,6 +298,19 @@ class GitApplyTree(PatchTree):
>  PatchTree.__init__(self, dir, d)
>  self.commituser = d.getVar('PATCH_GIT_USER_NAME')
>  self.commitemail = d.getVar('PATCH_GIT_USER_EMAIL')
> +if not self._isInitialized():
> +self._initRepo()
> +
> +def _isInitialized(self):
> +cmd = "git rev-parse --show-toplevel"
> +(status, output) = getstatusoutput(cmd)
> +## Make sure we're in builddir to not break top-level git repos
> +return status == 0 and os.path.samedir(output, self.dir)
> +
> +def _initRepo(self):
> +runcmd("git 

[OE-core] [PATCH] README.OE-Core.md: update URLs

[Quentin Schulz]

Update URLs to what they actually redirect to.

Cc: Quentin Schulz 
Signed-off-by: Quentin Schulz 
---
 README.OE-Core.md | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/README.OE-Core.md b/README.OE-Core.md
index 521916cd4f..2f2127fb03 100644
--- a/README.OE-Core.md
+++ b/README.OE-Core.md
@@ -6,24 +6,24 @@ of OpenEmbedded. It is distro-less (can build a functional 
image with
 DISTRO = "nodistro") and contains only emulated machine support.
 
 For information about OpenEmbedded, see the OpenEmbedded website:
-http://www.openembedded.org/
+https://www.openembedded.org/
 
 The Yocto Project has extensive documentation about OE including a reference 
manual
 which can be found at:
-http://yoctoproject.org/documentation
+https://docs.yoctoproject.org/
 
 
 Contributing
 
 
 Please refer to
-http://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded
+https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded
 for guidelines on how to submit patches.
 
 Mailing list:
 
-http://lists.openembedded.org/mailman/listinfo/openembedded-core
+https://lists.openembedded.org/g/openembedded-core
 
 Source code:
 
-http://git.openembedded.org/openembedded-core/
+https://git.openembedded.org/openembedded-core/
-- 
2.33.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159044): 
https://lists.openembedded.org/g/openembedded-core/message/159044
Mute This Topic: https://lists.openembedded.org/mt/87431819/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 v2] patch.py: Initialize git repo before patching

[Pavel Zhukov]

Thanks. Done in v4. -- Pavel   01.12.2021, 17:08, "Alexander Kanavin" :Thanks :) You can add the failure into the commit message. Alex On Wed, 1 Dec 2021 at 17:00, Pavel Zhukov  wrote:without change in patch.py:ERROR: man-db-2.9.0-r1 do_patch: Applying patch 'man_db.conf-avoid-multilib-install-file-conflict.patch' on target directory '/mnt/builds/oniroproject/builds/build-oniro-linux-st/tmp/work/core2-64-oniro-linux-musl/man-db/2.9.0-r1/man-db-2.9.0'Command Error: 'git rev-parse --show-toplevel' exited with 0  Output:fatal: not a git repository (or any of the parent directories): .gitERROR: Logfile of failure stored in: /mnt/builds/oniroproject/builds/build-oniro-linux-st/tmp/work/core2-64-oniro-linux-musl/man-db/2.9.0-r1/temp/log.do_patch.21491NOTE: recipe man-db-2.9.0-r1: task do_patch: FailedERROR: Task (/mnt/builds/oniroproject/sources/oe-core/meta/recipes-extended/man-db/man-db_2.9.0.bb:do_patch) failed with exit code '1'NOTE: Tasks Summary: Attempted 102 tasks of which 0 didn't need to be rerun and 1 failed. Summary: 1 task failed:  /mnt/builds/oniroproject/sources/oe-core/meta/recipes-extended/man-db/man-db_2.9.0.bb:do_patchSummary: There was 1 ERROR message shown, returning a non-zero exit code.--2021-12-01 15:11:56,184 - oe-selftest - INFO - Ran 1 test in 147.083s2021-12-01 15:11:56,184 - oe-selftest - INFO - FAILED2021-12-01 15:11:56,184 - oe-selftest - INFO -  (failures=1)2021-12-01 15:11:58,721 - oe-selftest - INFO - RESULTS:2021-12-01 15:11:58,722 - oe-selftest - INFO - RESULTS - bbtests.BitbakeTests.test_git_patchtool: FAILED (145.51s)2021-12-01 15:11:58,724 - oe-selftest - INFO - SUMMARY:2021-12-01 15:11:58,724 - oe-selftest - INFO - oe-selftest () - Ran 1 test in 147.084s2021-12-01 15:11:58,724 - oe-selftest - INFO - oe-selftest - FAIL - Required tests failed (successes=0, skipped=0, failures=1, errors=0)  with change in patch.py:2021-12-01 15:12:20,910 - oe-selftest - INFO - Adding: "include selftest.inc" in /mnt/builds/oniroproject/builds/build-oniro-linux-st/conf/local.conf2021-12-01 15:12:20,911 - oe-selftest - INFO - Adding: "include bblayers.inc" in bblayers.conf2021-12-01 15:12:20,911 - oe-selftest - INFO - test_git_patchtool (bbtests.BitbakeTests)2021-12-01 15:15:30,540 - oe-selftest - INFO -  ... ok2021-12-01 15:15:31,717 - oe-selftest - INFO - --2021-12-01 15:15:31,717 - oe-selftest - INFO - Ran 1 test in 192.371s2021-12-01 15:15:31,717 - oe-selftest - INFO - OK2021-12-01 15:15:34,523 - oe-selftest - INFO - RESULTS:2021-12-01 15:15:34,524 - oe-selftest - INFO - RESULTS - bbtests.BitbakeTests.test_git_patchtool: PASSED (189.63s)2021-12-01 15:15:34,526 - oe-selftest - INFO - SUMMARY:2021-12-01 15:15:34,526 - oe-selftest - INFO - oe-selftest () - Ran 1 test in 192.372s2021-12-01 15:15:34,526 - oe-selftest - INFO - oe-selftest - OK - All required tests passed (successes=1, skipped=0, failures=0, errors=0)  -- Pavel   01.12.2021, 16:56, "Alexander Kanavin" :Does the test fail without the change in lib/oepatch.py? Can you show how? Alex On Wed, 1 Dec 2021 at 15:17, Pavel Zhukov  wrote:From: Pavel Zhukov If PATCHTOOL="git" has been specified but workdir is not git repobitbake fails to apply the patches. Fix this by initializing the repobefore patching.This allows binary git patches to be applied.Signed-off-by: Pavel Zhukov --- meta/lib/oe/patch.py                    | 17 + meta/lib/oeqa/selftest/cases/bbtests.py |  6 ++ 2 files changed, 23 insertions(+)diff --git a/meta/lib/oe/patch.py b/meta/lib/oe/patch.pyindex 7cd8436da5..720c6f663c 100644--- a/meta/lib/oe/patch.py+++ b/meta/lib/oe/patch.py@@ -52,6 +52,10 @@ def runcmd(args, dir = None):         if dir:             os.chdir(olddir)+def getstatusoutput(cmd):+    import subprocess+    return subprocess.getstatusoutput(cmd.split())+ class PatchError(Exception):     def __init__(self, msg):         self.msg = msg@@ -294,6 +298,19 @@ class GitApplyTree(PatchTree):         PatchTree.__init__(self, dir, d)         self.commituser = d.getVar('PATCH_GIT_USER_NAME')         self.commitemail = d.getVar('PATCH_GIT_USER_EMAIL')+        if not self._isInitialized():+            self._initRepo()++    def _isInitialized(self):+        cmd = "git rev-parse --show-toplevel"+        (status, output) = getstatusoutput(cmd)+        ## Make sure we're in builddir to not break top-level git repos+        return status == 0 and os.path.samedir(output, self.dir)++    def _initRepo(self):+        runcmd("git init".split(), self.dir)+        runcmd("git add .".split(), self.dir)+        runcmd("git commit -a --allow-empty -m Patching_started".split(), self.dir)     @staticmethod     def extractPatchHeader(patchfile):diff --git a/meta/lib/oeqa/selftest/cases/bbtests.py 

[OE-core][PATCH v4] patch.py: Initialize git repo before patching

[Pavel Zhukov]

From: Pavel Zhukov 

If PATCHTOOL="git" has been specified but workdir is not git repo
bitbake fails to apply the patches with error message:
Command Error: 'git rev-parse --show-toplevel' exited with 0  Output:
fatal: not a git repository (or any of the parent directories): .git

Fix this by initializing the repo before patching.
This allows binary git patches to be applied.

Signed-off-by: Pavel Zhukov 
---
 meta/lib/oe/patch.py| 17 +
 meta/lib/oeqa/selftest/cases/bbtests.py |  6 ++
 2 files changed, 23 insertions(+)

diff --git a/meta/lib/oe/patch.py b/meta/lib/oe/patch.py
index fccbedb519..8326cb55bc 100644
--- a/meta/lib/oe/patch.py
+++ b/meta/lib/oe/patch.py
@@ -56,6 +56,10 @@ def runcmd(args, dir = None):
 if dir:
 os.chdir(olddir)
 
+def getstatusoutput(cmd):
+import subprocess
+return subprocess.getstatusoutput(cmd.split())
+
 class PatchError(Exception):
 def __init__(self, msg):
 self.msg = msg
@@ -298,6 +302,19 @@ class GitApplyTree(PatchTree):
 PatchTree.__init__(self, dir, d)
 self.commituser = d.getVar('PATCH_GIT_USER_NAME')
 self.commitemail = d.getVar('PATCH_GIT_USER_EMAIL')
+if not self._isInitialized():
+self._initRepo()
+
+def _isInitialized(self):
+cmd = "git rev-parse --show-toplevel"
+(status, output) = getstatusoutput(cmd)
+## Make sure we're in builddir to not break top-level git repos
+return status == 0 and os.path.samedir(output, self.dir)
+
+def _initRepo(self):
+runcmd("git init".split(), self.dir)
+runcmd("git add .".split(), self.dir)
+runcmd("git commit -a --allow-empty -m Patching_started".split(), 
self.dir)
 
 @staticmethod
 def extractPatchHeader(patchfile):
diff --git a/meta/lib/oeqa/selftest/cases/bbtests.py 
b/meta/lib/oeqa/selftest/cases/bbtests.py
index 6779e62103..2c3defc6b7 100644
--- a/meta/lib/oeqa/selftest/cases/bbtests.py
+++ b/meta/lib/oeqa/selftest/cases/bbtests.py
@@ -297,3 +297,9 @@ INHERIT:remove = \"report-error\"
 
 test_recipe_summary_after = get_bb_var('SUMMARY', test_recipe)
 self.assertEqual(expected_recipe_summary, test_recipe_summary_after)
+
+def test_git_patchtool(self):
+self.write_recipeinc('man-db', 'PATCHTOOL=\"git\"')
+result = bitbake('man-db -c patch', ignore_status=False)
+self.delete_recipeinc('man-db')
+bitbake('-cclean man-db')
-- 
2.34.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159042): 
https://lists.openembedded.org/g/openembedded-core/message/159042
Mute This Topic: https://lists.openembedded.org/mt/87431724/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] python: python3-idna: fix non-existent Unicode license

[Quentin Schulz]

In addition to not being an SPDX license, Unicode license also isn't
available in any of the LICENSE_PATH available in openembedded, meaning
the following warning is printed:

python3-idna: No generic license file exists for: Unicode in any provider 
[license-exists]

Unfortunately the license is not really explicit in the project. After
looking at the code, it seems that this license gets pulled by
idna/idnadata.py and idna/uts46data.py which are auto-generated by
tools/idna-data which downloads data from
http://www.unicode.org/Public/{version}/ucd/ and
http://www.unicode.org/Public/idna/ which are covered by
https://www.unicode.org/license.txt as mentioned in
https://www.unicode.org/copyright.html.

Comparing https://www.unicode.org/license.txt to Unicode-DFS-2016
resulted in a match so let's point to that SPDX license instead.

Cc: Quentin Schulz 
Signed-off-by: Quentin Schulz 
---
 meta/recipes-devtools/python/python3-idna_3.3.bb | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/python/python3-idna_3.3.bb 
b/meta/recipes-devtools/python/python3-idna_3.3.bb
index a0e6b79a56..f3c53a8717 100644
--- a/meta/recipes-devtools/python/python3-idna_3.3.bb
+++ b/meta/recipes-devtools/python/python3-idna_3.3.bb
@@ -1,6 +1,11 @@
 SUMMARY = "Internationalised Domain Names in Applications"
 HOMEPAGE = "https://github.com/kjd/idna;
-LICENSE = "BSD-3-Clause & Python-2.0 & Unicode"
+# Note: Unicode license is pulled in by idna/idnadata.py and idna/uts46data.py
+# files auto-generated by tools/idna-data which downloads data from
+# http://www.unicode.org/Public/{version}/ucd/ and 
http://www.unicode.org/Public/idna/
+# which are covered by https://www.unicode.org/license.txt as mentioned by
+# https://www.unicode.org/copyright.html
+LICENSE = "BSD-3-Clause & Python-2.0 & Unicode-DFS-2016"
 LIC_FILES_CHKSUM = "file://LICENSE.md;md5=239668a7c6066d9e0c5382e9c8c6c0e1"
 
 SRC_URI[sha256sum] = 
"9d643ff0a55b762d5cdb124b8eaa99c66322e2157b69160bc32796e824360e6d"
-- 
2.33.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159041): 
https://lists.openembedded.org/g/openembedded-core/message/159041
Mute This Topic: https://lists.openembedded.org/mt/87431709/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 v2] patch.py: Initialize git repo before patching

[Alexander Kanavin]

Thanks :) You can add the failure into the commit message.

Alex

On Wed, 1 Dec 2021 at 17:00, Pavel Zhukov  wrote:

> without change in patch.py:
> ERROR: man-db-2.9.0-r1 do_patch: Applying patch
> 'man_db.conf-avoid-multilib-install-file-conflict.patch' on target
> directory
> '/mnt/builds/oniroproject/builds/build-oniro-linux-st/tmp/work/core2-64-oniro-linux-musl/man-db/2.9.0-r1/man-db-2.9.0'
> Command Error: 'git rev-parse --show-toplevel' exited with 0  Output:
> fatal: not a git repository (or any of the parent directories): .git
> ERROR: Logfile of failure stored in:
> /mnt/builds/oniroproject/builds/build-oniro-linux-st/tmp/work/core2-64-oniro-linux-musl/man-db/2.9.0-r1/temp/log.do_patch.21491
> NOTE: recipe man-db-2.9.0-r1: task do_patch: Failed
> ERROR: Task
> (/mnt/builds/oniroproject/sources/oe-core/meta/recipes-extended/man-db/man-db_2.9.0.bb:do_patch)
> failed with exit code '1'
> NOTE: Tasks Summary: Attempted 102 tasks of which 0 didn't need to be
> rerun and 1 failed.
>
> Summary: 1 task failed:
>
> /mnt/builds/oniroproject/sources/oe-core/meta/recipes-extended/man-db/man-db_2.9.0.bb:
> do_patch
> Summary: There was 1 ERROR message shown, returning a non-zero exit code.
> --
> 2021-12-01 15:11:56,184 - oe-selftest - INFO - Ran 1 test in 147.083s
> 2021-12-01 15:11:56,184 - oe-selftest - INFO - FAILED
> 2021-12-01 15:11:56,184 - oe-selftest - INFO -  (failures=1)
> 2021-12-01 15:11:58,721 - oe-selftest - INFO - RESULTS:
> 2021-12-01 15:11:58,722 - oe-selftest - INFO - RESULTS -
> bbtests.BitbakeTests.test_git_patchtool: FAILED (145.51s)
> 2021-12-01 15:11:58,724 - oe-selftest - INFO - SUMMARY:
> 2021-12-01 15:11:58,724 - oe-selftest - INFO - oe-selftest () - Ran 1 test
> in 147.084s
> 2021-12-01 15:11:58,724 - oe-selftest - INFO - oe-selftest - FAIL -
> Required tests failed (successes=0, skipped=0, failures=1, errors=0)
>
>
> with change in patch.py:
> 2021-12-01 15:12:20,910 - oe-selftest - INFO - Adding: "include
> selftest.inc" in
> /mnt/builds/oniroproject/builds/build-oniro-linux-st/conf/local.conf
> 2021-12-01 15:12:20,911 - oe-selftest - INFO - Adding: "include
> bblayers.inc" in bblayers.conf
> 2021-12-01 15:12:20,911 - oe-selftest - INFO - test_git_patchtool
> (bbtests.BitbakeTests)
> 2021-12-01 15:15:30,540 - oe-selftest - INFO -  ... ok
> 2021-12-01 15:15:31,717 - oe-selftest - INFO -
> --
> 2021-12-01 15:15:31,717 - oe-selftest - INFO - Ran 1 test in 192.371s
> 2021-12-01 15:15:31,717 - oe-selftest - INFO - OK
> 2021-12-01 15:15:34,523 - oe-selftest - INFO - RESULTS:
> 2021-12-01 15:15:34,524 - oe-selftest - INFO - RESULTS -
> bbtests.BitbakeTests.test_git_patchtool: PASSED (189.63s)
> 2021-12-01 15:15:34,526 - oe-selftest - INFO - SUMMARY:
> 2021-12-01 15:15:34,526 - oe-selftest - INFO - oe-selftest () - Ran 1 test
> in 192.372s
> 2021-12-01 15:15:34,526 - oe-selftest - INFO - oe-selftest - OK - All
> required tests passed (successes=1, skipped=0, failures=0, errors=0)
>
>
> --
> Pavel
>
>
>
> 01.12.2021, 16:56, "Alexander Kanavin" :
>
> Does the test fail without the change in lib/oepatch.py? Can you show how?
>
> Alex
>
> On Wed, 1 Dec 2021 at 15:17, Pavel Zhukov  wrote:
>
> From: Pavel Zhukov 
>
> If PATCHTOOL="git" has been specified but workdir is not git repo
> bitbake fails to apply the patches. Fix this by initializing the repo
> before patching.
> This allows binary git patches to be applied.
>
> Signed-off-by: Pavel Zhukov 
> ---
>  meta/lib/oe/patch.py| 17 +
>  meta/lib/oeqa/selftest/cases/bbtests.py |  6 ++
>  2 files changed, 23 insertions(+)
>
> diff --git a/meta/lib/oe/patch.py b/meta/lib/oe/patch.py
> index 7cd8436da5..720c6f663c 100644
> --- a/meta/lib/oe/patch.py
> +++ b/meta/lib/oe/patch.py
> @@ -52,6 +52,10 @@ def runcmd(args, dir = None):
>  if dir:
>  os.chdir(olddir)
>
> +def getstatusoutput(cmd):
> +import subprocess
> +return subprocess.getstatusoutput(cmd.split())
> +
>  class PatchError(Exception):
>  def __init__(self, msg):
>  self.msg = msg
> @@ -294,6 +298,19 @@ class GitApplyTree(PatchTree):
>  PatchTree.__init__(self, dir, d)
>  self.commituser = d.getVar('PATCH_GIT_USER_NAME')
>  self.commitemail = d.getVar('PATCH_GIT_USER_EMAIL')
> +if not self._isInitialized():
> +self._initRepo()
> +
> +def _isInitialized(self):
> +cmd = "git rev-parse --show-toplevel"
> +(status, output) = getstatusoutput(cmd)
> +## Make sure we're in builddir to not break top-level git repos
> +return status == 0 and os.path.samedir(output, self.dir)
> +
> +def _initRepo(self):
> +runcmd("git init".split(), self.dir)
> +runcmd("git add .".split(), self.dir)
> +runcmd("git commit -a --allow-empty -m Patching_started".split(),
> self.dir)
>
>  

Re: [OE-core] [meta-oe][PATCH v2] patch.py: Initialize git repo before patching

[Pavel Zhukov]

without change in patch.py:ERROR: man-db-2.9.0-r1 do_patch: Applying patch 'man_db.conf-avoid-multilib-install-file-conflict.patch' on target directory '/mnt/builds/oniroproject/builds/build-oniro-linux-st/tmp/work/core2-64-oniro-linux-musl/man-db/2.9.0-r1/man-db-2.9.0'Command Error: 'git rev-parse --show-toplevel' exited with 0  Output:fatal: not a git repository (or any of the parent directories): .gitERROR: Logfile of failure stored in: /mnt/builds/oniroproject/builds/build-oniro-linux-st/tmp/work/core2-64-oniro-linux-musl/man-db/2.9.0-r1/temp/log.do_patch.21491NOTE: recipe man-db-2.9.0-r1: task do_patch: FailedERROR: Task (/mnt/builds/oniroproject/sources/oe-core/meta/recipes-extended/man-db/man-db_2.9.0.bb:do_patch) failed with exit code '1'NOTE: Tasks Summary: Attempted 102 tasks of which 0 didn't need to be rerun and 1 failed. Summary: 1 task failed:  /mnt/builds/oniroproject/sources/oe-core/meta/recipes-extended/man-db/man-db_2.9.0.bb:do_patchSummary: There was 1 ERROR message shown, returning a non-zero exit code.--2021-12-01 15:11:56,184 - oe-selftest - INFO - Ran 1 test in 147.083s2021-12-01 15:11:56,184 - oe-selftest - INFO - FAILED2021-12-01 15:11:56,184 - oe-selftest - INFO -  (failures=1)2021-12-01 15:11:58,721 - oe-selftest - INFO - RESULTS:2021-12-01 15:11:58,722 - oe-selftest - INFO - RESULTS - bbtests.BitbakeTests.test_git_patchtool: FAILED (145.51s)2021-12-01 15:11:58,724 - oe-selftest - INFO - SUMMARY:2021-12-01 15:11:58,724 - oe-selftest - INFO - oe-selftest () - Ran 1 test in 147.084s2021-12-01 15:11:58,724 - oe-selftest - INFO - oe-selftest - FAIL - Required tests failed (successes=0, skipped=0, failures=1, errors=0)  with change in patch.py:2021-12-01 15:12:20,910 - oe-selftest - INFO - Adding: "include selftest.inc" in /mnt/builds/oniroproject/builds/build-oniro-linux-st/conf/local.conf2021-12-01 15:12:20,911 - oe-selftest - INFO - Adding: "include bblayers.inc" in bblayers.conf2021-12-01 15:12:20,911 - oe-selftest - INFO - test_git_patchtool (bbtests.BitbakeTests)2021-12-01 15:15:30,540 - oe-selftest - INFO -  ... ok2021-12-01 15:15:31,717 - oe-selftest - INFO - --2021-12-01 15:15:31,717 - oe-selftest - INFO - Ran 1 test in 192.371s2021-12-01 15:15:31,717 - oe-selftest - INFO - OK2021-12-01 15:15:34,523 - oe-selftest - INFO - RESULTS:2021-12-01 15:15:34,524 - oe-selftest - INFO - RESULTS - bbtests.BitbakeTests.test_git_patchtool: PASSED (189.63s)2021-12-01 15:15:34,526 - oe-selftest - INFO - SUMMARY:2021-12-01 15:15:34,526 - oe-selftest - INFO - oe-selftest () - Ran 1 test in 192.372s2021-12-01 15:15:34,526 - oe-selftest - INFO - oe-selftest - OK - All required tests passed (successes=1, skipped=0, failures=0, errors=0)  -- Pavel   01.12.2021, 16:56, "Alexander Kanavin" :Does the test fail without the change in lib/oepatch.py? Can you show how? Alex On Wed, 1 Dec 2021 at 15:17, Pavel Zhukov  wrote:From: Pavel Zhukov If PATCHTOOL="git" has been specified but workdir is not git repobitbake fails to apply the patches. Fix this by initializing the repobefore patching.This allows binary git patches to be applied.Signed-off-by: Pavel Zhukov --- meta/lib/oe/patch.py                    | 17 + meta/lib/oeqa/selftest/cases/bbtests.py |  6 ++ 2 files changed, 23 insertions(+)diff --git a/meta/lib/oe/patch.py b/meta/lib/oe/patch.pyindex 7cd8436da5..720c6f663c 100644--- a/meta/lib/oe/patch.py+++ b/meta/lib/oe/patch.py@@ -52,6 +52,10 @@ def runcmd(args, dir = None):         if dir:             os.chdir(olddir)+def getstatusoutput(cmd):+    import subprocess+    return subprocess.getstatusoutput(cmd.split())+ class PatchError(Exception):     def __init__(self, msg):         self.msg = msg@@ -294,6 +298,19 @@ class GitApplyTree(PatchTree):         PatchTree.__init__(self, dir, d)         self.commituser = d.getVar('PATCH_GIT_USER_NAME')         self.commitemail = d.getVar('PATCH_GIT_USER_EMAIL')+        if not self._isInitialized():+            self._initRepo()++    def _isInitialized(self):+        cmd = "git rev-parse --show-toplevel"+        (status, output) = getstatusoutput(cmd)+        ## Make sure we're in builddir to not break top-level git repos+        return status == 0 and os.path.samedir(output, self.dir)++    def _initRepo(self):+        runcmd("git init".split(), self.dir)+        runcmd("git add .".split(), self.dir)+        runcmd("git commit -a --allow-empty -m Patching_started".split(), self.dir)     @staticmethod     def extractPatchHeader(patchfile):diff --git a/meta/lib/oeqa/selftest/cases/bbtests.py b/meta/lib/oeqa/selftest/cases/bbtests.pyindex d4f6a08991..8c046074f6 100644--- a/meta/lib/oeqa/selftest/cases/bbtests.py+++ b/meta/lib/oeqa/selftest/cases/bbtests.py@@ -294,3 +294,9 @@ INHERIT_remove = \"report-error\"         test_recipe_summary_after = 

Re: [OE-core] [meta-oe][PATCH v2] patch.py: Initialize git repo before patching

[Alexander Kanavin]

Does the test fail without the change in lib/oepatch.py? Can you show how?

Alex

On Wed, 1 Dec 2021 at 15:17, Pavel Zhukov  wrote:

> From: Pavel Zhukov 
>
> If PATCHTOOL="git" has been specified but workdir is not git repo
> bitbake fails to apply the patches. Fix this by initializing the repo
> before patching.
> This allows binary git patches to be applied.
>
> Signed-off-by: Pavel Zhukov 
> ---
>  meta/lib/oe/patch.py| 17 +
>  meta/lib/oeqa/selftest/cases/bbtests.py |  6 ++
>  2 files changed, 23 insertions(+)
>
> diff --git a/meta/lib/oe/patch.py b/meta/lib/oe/patch.py
> index 7cd8436da5..720c6f663c 100644
> --- a/meta/lib/oe/patch.py
> +++ b/meta/lib/oe/patch.py
> @@ -52,6 +52,10 @@ def runcmd(args, dir = None):
>  if dir:
>  os.chdir(olddir)
>
> +def getstatusoutput(cmd):
> +import subprocess
> +return subprocess.getstatusoutput(cmd.split())
> +
>  class PatchError(Exception):
>  def __init__(self, msg):
>  self.msg = msg
> @@ -294,6 +298,19 @@ class GitApplyTree(PatchTree):
>  PatchTree.__init__(self, dir, d)
>  self.commituser = d.getVar('PATCH_GIT_USER_NAME')
>  self.commitemail = d.getVar('PATCH_GIT_USER_EMAIL')
> +if not self._isInitialized():
> +self._initRepo()
> +
> +def _isInitialized(self):
> +cmd = "git rev-parse --show-toplevel"
> +(status, output) = getstatusoutput(cmd)
> +## Make sure we're in builddir to not break top-level git repos
> +return status == 0 and os.path.samedir(output, self.dir)
> +
> +def _initRepo(self):
> +runcmd("git init".split(), self.dir)
> +runcmd("git add .".split(), self.dir)
> +runcmd("git commit -a --allow-empty -m Patching_started".split(),
> self.dir)
>
>  @staticmethod
>  def extractPatchHeader(patchfile):
> diff --git a/meta/lib/oeqa/selftest/cases/bbtests.py
> b/meta/lib/oeqa/selftest/cases/bbtests.py
> index d4f6a08991..8c046074f6 100644
> --- a/meta/lib/oeqa/selftest/cases/bbtests.py
> +++ b/meta/lib/oeqa/selftest/cases/bbtests.py
> @@ -294,3 +294,9 @@ INHERIT_remove = \"report-error\"
>
>  test_recipe_summary_after = get_bb_var('SUMMARY', test_recipe)
>  self.assertEqual(expected_recipe_summary,
> test_recipe_summary_after)
> +
> +def test_git_patchtool(self):
> +self.write_recipeinc('man-db', 'PATCHTOOL=\"git\"')
> +result = bitbake('man-db -c patch', ignore_status=False)
> +self.delete_recipeinc('man-db')
> +bitbake('-cclean man-db')
> --
> 2.34.0
>
>
> 
>
>

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

[OE-core][PATCH v3] patch.py: Initialize git repo before patching

[Pavel Zhukov]

From: Pavel Zhukov 

If PATCHTOOL="git" has been specified but workdir is not git repo
bitbake fails to apply the patches. Fix this by initializing the repo
before patching.
This allows binary git patches to be applied.

Signed-off-by: Pavel Zhukov 
---
 meta/lib/oe/patch.py| 17 +
 meta/lib/oeqa/selftest/cases/bbtests.py |  6 ++
 2 files changed, 23 insertions(+)

diff --git a/meta/lib/oe/patch.py b/meta/lib/oe/patch.py
index fccbedb519..8326cb55bc 100644
--- a/meta/lib/oe/patch.py
+++ b/meta/lib/oe/patch.py
@@ -56,6 +56,10 @@ def runcmd(args, dir = None):
 if dir:
 os.chdir(olddir)
 
+def getstatusoutput(cmd):
+import subprocess
+return subprocess.getstatusoutput(cmd.split())
+
 class PatchError(Exception):
 def __init__(self, msg):
 self.msg = msg
@@ -298,6 +302,19 @@ class GitApplyTree(PatchTree):
 PatchTree.__init__(self, dir, d)
 self.commituser = d.getVar('PATCH_GIT_USER_NAME')
 self.commitemail = d.getVar('PATCH_GIT_USER_EMAIL')
+if not self._isInitialized():
+self._initRepo()
+
+def _isInitialized(self):
+cmd = "git rev-parse --show-toplevel"
+(status, output) = getstatusoutput(cmd)
+## Make sure we're in builddir to not break top-level git repos
+return status == 0 and os.path.samedir(output, self.dir)
+
+def _initRepo(self):
+runcmd("git init".split(), self.dir)
+runcmd("git add .".split(), self.dir)
+runcmd("git commit -a --allow-empty -m Patching_started".split(), 
self.dir)
 
 @staticmethod
 def extractPatchHeader(patchfile):
diff --git a/meta/lib/oeqa/selftest/cases/bbtests.py 
b/meta/lib/oeqa/selftest/cases/bbtests.py
index 6779e62103..2c3defc6b7 100644
--- a/meta/lib/oeqa/selftest/cases/bbtests.py
+++ b/meta/lib/oeqa/selftest/cases/bbtests.py
@@ -297,3 +297,9 @@ INHERIT:remove = \"report-error\"
 
 test_recipe_summary_after = get_bb_var('SUMMARY', test_recipe)
 self.assertEqual(expected_recipe_summary, test_recipe_summary_after)
+
+def test_git_patchtool(self):
+self.write_recipeinc('man-db', 'PATCHTOOL=\"git\"')
+result = bitbake('man-db -c patch', ignore_status=False)
+self.delete_recipeinc('man-db')
+bitbake('-cclean man-db')
-- 
2.34.0


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

[OE-core] [PATCH 1/2] recipetool: handle GitLab URLs like we do GitHub

[Ross Burton]

GitHub URLs are automatically transformed to git: fetches, so handle
GitLab URLs too.

Signed-off-by: Ross Burton 
---
 scripts/lib/recipetool/create.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/lib/recipetool/create.py b/scripts/lib/recipetool/create.py
index b6c4564761..4f6e01c639 100644
--- a/scripts/lib/recipetool/create.py
+++ b/scripts/lib/recipetool/create.py
@@ -366,7 +366,7 @@ def supports_srcrev(uri):
 def reformat_git_uri(uri):
 '''Convert any http[s]://git URI into git://...;protocol=http[s]'''
 checkuri = uri.split(';', 1)[0]
-if checkuri.endswith('.git') or '/git/' in checkuri or 
re.match('https?://github.com/[^/]+/[^/]+/?$', checkuri):
+if checkuri.endswith('.git') or '/git/' in checkuri or 
re.match('https?://git(hub|lab).com/[^/]+/[^/]+/?$', checkuri):
 # Appends scheme if the scheme is missing
 if not '://' in uri:
 uri = 'git://' + uri
-- 
2.25.1


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

[OE-core] [PATCH 2/2] recipetool: extend curl detection when creating recipes

[Ross Burton]

If a configure.ac uses LIBCURL_CHECK_CONFIG it wants curl.

Signed-off-by: Ross Burton 
---
 scripts/lib/recipetool/create_buildsys.py | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/scripts/lib/recipetool/create_buildsys.py 
b/scripts/lib/recipetool/create_buildsys.py
index 35a97c9345..5015634476 100644
--- a/scripts/lib/recipetool/create_buildsys.py
+++ b/scripts/lib/recipetool/create_buildsys.py
@@ -545,7 +545,7 @@ class AutotoolsRecipeHandler(RecipeHandler):
 deps.append('zlib')
 elif keyword in ('AX_CHECK_OPENSSL', 'AX_LIB_CRYPTO'):
 deps.append('openssl')
-elif keyword == 'AX_LIB_CURL':
+elif keyword in ('AX_LIB_CURL', 'LIBCURL_CHECK_CONFIG'):
 deps.append('curl')
 elif keyword == 'AX_LIB_BEECRYPT':
 deps.append('beecrypt')
@@ -624,6 +624,7 @@ class AutotoolsRecipeHandler(RecipeHandler):
 'AX_CHECK_OPENSSL',
 'AX_LIB_CRYPTO',
 'AX_LIB_CURL',
+'LIBCURL_CHECK_CONFIG',
 'AX_LIB_BEECRYPT',
 'AX_LIB_EXPAT',
 'AX_LIB_GCRYPT',
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159036): 
https://lists.openembedded.org/g/openembedded-core/message/159036
Mute This Topic: https://lists.openembedded.org/mt/87430930/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 files in a directory aren't applied

[Vyacheslav Yurkov]

Hi Max,
I think you are interpreting it not entirely correctly. You are reading 
do_patch() description and the task would pick up all patches it finds. 
But SRC_URI is another thing and it is looked at during parsing time.


Vyacheslav

On 01.12.2021 15:26, Max Krummenacher wrote:

Hello

I tried to add patches by specifing a directory in SRC_URI and have
bitbake appling all patch files in it without explicitely adding the
individual file names in SRC_URI.
According to the do_patch description [1] that should work, however
for my example recipe it does not. The files in the directory end up
in ${WORKDIR}/path_to_lots_of_patch_files/ but none of the *.patch
files are applied.

Looking at meta/lib/oe/patch.py src_patches() I believe that the
documented behaviour is not implemented.

Does anyone know why this is documented but not implemented?
Has it been removed for good reason and is now undesired in OE?
I'd be willing to work on the feature.

Max

[1] 
https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#ref-tasks-patch






-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159034): 
https://lists.openembedded.org/g/openembedded-core/message/159034
Mute This Topic: https://lists.openembedded.org/mt/87429103/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 files in a directory aren't applied

[Max Krummenacher]

Hello

I tried to add patches by specifing a directory in SRC_URI and have
bitbake appling all patch files in it without explicitely adding the
individual file names in SRC_URI.
According to the do_patch description [1] that should work, however
for my example recipe it does not. The files in the directory end up
in ${WORKDIR}/path_to_lots_of_patch_files/ but none of the *.patch
files are applied.

Looking at meta/lib/oe/patch.py src_patches() I believe that the
documented behaviour is not implemented.

Does anyone know why this is documented but not implemented?
Has it been removed for good reason and is now undesired in OE?
I'd be willing to work on the feature.

Max

[1] 
https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#ref-tasks-patch

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159033): 
https://lists.openembedded.org/g/openembedded-core/message/159033
Mute This Topic: https://lists.openembedded.org/mt/87429103/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] patch.py: Initialize git repo before patching

[Pavel Zhukov]

Hi Konrad,Test (very simple one) has been added (see v2). I'm not familiar with testsuite so please excuse me if I put it into wrong place. Also I'm not sure if it's ok to keep test more general (catch all errors like I did) or I have to check for specific error message. -- Pavel   01.12.2021, 14:25, "Konrad Weihmann" :Could you please add a test case for that to the testing suite, as I'mhaving issues to understand under what circumstances we are getting intosuch kind of situationOn 01.12.21 14:19, Pavel Zhukov wrote: From: Pavel Zhukov   If PATCHTOOL="git" has been specified but workdir is not git repo bitbake fails to apply the patches. Fix this by initializing the repo before patching. This allows binary git patches to be applied.  Signed-off-by: Pavel Zhukov  ---   meta/lib/oe/patch.py | 17 +   1 file changed, 17 insertions(+)  diff --git a/meta/lib/oe/patch.py b/meta/lib/oe/patch.py index fccbedb519..8326cb55bc 100644 --- a/meta/lib/oe/patch.py +++ b/meta/lib/oe/patch.py @@ -56,6 +56,10 @@ def runcmd(args, dir = None):   if dir:   os.chdir(olddir)+def getstatusoutput(cmd): + import subprocess + return subprocess.getstatusoutput(cmd.split()) +   class PatchError(Exception):   def __init__(self, msg):   self.msg = msg @@ -298,6 +302,19 @@ class GitApplyTree(PatchTree):   PatchTree.__init__(self, dir, d)   self.commituser = d.getVar('PATCH_GIT_USER_NAME')   self.commitemail = d.getVar('PATCH_GIT_USER_EMAIL') + if not self._isInitialized(): + self._initRepo() + + def _isInitialized(self): + cmd = "git rev-parse --show-toplevel" + (status, output) = getstatusoutput(cmd) + ## Make sure we're in builddir to not break top-level git repos + return status == 0 and os.path.samedir(output, self.dir) + + def _initRepo(self): + runcmd("git init".split(), self.dir) + runcmd("git add .".split(), self.dir) + runcmd("git commit -a --allow-empty -m Patching_started".split(), self.dir)  @staticmethod   def extractPatchHeader(patchfile): 
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159032): 
https://lists.openembedded.org/g/openembedded-core/message/159032
Mute This Topic: https://lists.openembedded.org/mt/87426820/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [meta-oe][PATCH v2] patch.py: Initialize git repo before patching

[Pavel Zhukov]

From: Pavel Zhukov 

If PATCHTOOL="git" has been specified but workdir is not git repo
bitbake fails to apply the patches. Fix this by initializing the repo
before patching.
This allows binary git patches to be applied.

Signed-off-by: Pavel Zhukov 
---
 meta/lib/oe/patch.py| 17 +
 meta/lib/oeqa/selftest/cases/bbtests.py |  6 ++
 2 files changed, 23 insertions(+)

diff --git a/meta/lib/oe/patch.py b/meta/lib/oe/patch.py
index 7cd8436da5..720c6f663c 100644
--- a/meta/lib/oe/patch.py
+++ b/meta/lib/oe/patch.py
@@ -52,6 +52,10 @@ def runcmd(args, dir = None):
 if dir:
 os.chdir(olddir)
 
+def getstatusoutput(cmd):
+import subprocess
+return subprocess.getstatusoutput(cmd.split())
+
 class PatchError(Exception):
 def __init__(self, msg):
 self.msg = msg
@@ -294,6 +298,19 @@ class GitApplyTree(PatchTree):
 PatchTree.__init__(self, dir, d)
 self.commituser = d.getVar('PATCH_GIT_USER_NAME')
 self.commitemail = d.getVar('PATCH_GIT_USER_EMAIL')
+if not self._isInitialized():
+self._initRepo()
+
+def _isInitialized(self):
+cmd = "git rev-parse --show-toplevel"
+(status, output) = getstatusoutput(cmd)
+## Make sure we're in builddir to not break top-level git repos
+return status == 0 and os.path.samedir(output, self.dir)
+
+def _initRepo(self):
+runcmd("git init".split(), self.dir)
+runcmd("git add .".split(), self.dir)
+runcmd("git commit -a --allow-empty -m Patching_started".split(), 
self.dir)
 
 @staticmethod
 def extractPatchHeader(patchfile):
diff --git a/meta/lib/oeqa/selftest/cases/bbtests.py 
b/meta/lib/oeqa/selftest/cases/bbtests.py
index d4f6a08991..8c046074f6 100644
--- a/meta/lib/oeqa/selftest/cases/bbtests.py
+++ b/meta/lib/oeqa/selftest/cases/bbtests.py
@@ -294,3 +294,9 @@ INHERIT_remove = \"report-error\"
 
 test_recipe_summary_after = get_bb_var('SUMMARY', test_recipe)
 self.assertEqual(expected_recipe_summary, test_recipe_summary_after)
+
+def test_git_patchtool(self):
+self.write_recipeinc('man-db', 'PATCHTOOL=\"git\"')
+result = bitbake('man-db -c patch', ignore_status=False)
+self.delete_recipeinc('man-db')
+bitbake('-cclean man-db')
-- 
2.34.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159031): 
https://lists.openembedded.org/g/openembedded-core/message/159031
Mute This Topic: https://lists.openembedded.org/mt/87428914/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] patch.py: Initialize git repo before patching

[Konrad Weihmann]

Could you please add a test case for that to the testing suite, as I'm 
having issues to understand under what circumstances we are getting into 
such kind of situation


On 01.12.21 14:19, Pavel Zhukov wrote:

From: Pavel Zhukov 

If PATCHTOOL="git" has been specified but workdir is not git repo
bitbake fails to apply the patches. Fix this by initializing the repo
before patching.
This allows binary git patches to be applied.

Signed-off-by: Pavel Zhukov 
---
  meta/lib/oe/patch.py | 17 +
  1 file changed, 17 insertions(+)

diff --git a/meta/lib/oe/patch.py b/meta/lib/oe/patch.py
index fccbedb519..8326cb55bc 100644
--- a/meta/lib/oe/patch.py
+++ b/meta/lib/oe/patch.py
@@ -56,6 +56,10 @@ def runcmd(args, dir = None):
  if dir:
  os.chdir(olddir)
  
+def getstatusoutput(cmd):

+import subprocess
+return subprocess.getstatusoutput(cmd.split())
+
  class PatchError(Exception):
  def __init__(self, msg):
  self.msg = msg
@@ -298,6 +302,19 @@ class GitApplyTree(PatchTree):
  PatchTree.__init__(self, dir, d)
  self.commituser = d.getVar('PATCH_GIT_USER_NAME')
  self.commitemail = d.getVar('PATCH_GIT_USER_EMAIL')
+if not self._isInitialized():
+self._initRepo()
+
+def _isInitialized(self):
+cmd = "git rev-parse --show-toplevel"
+(status, output) = getstatusoutput(cmd)
+## Make sure we're in builddir to not break top-level git repos
+return status == 0 and os.path.samedir(output, self.dir)
+
+def _initRepo(self):
+runcmd("git init".split(), self.dir)
+runcmd("git add .".split(), self.dir)
+runcmd("git commit -a --allow-empty -m Patching_started".split(), 
self.dir)
  
  @staticmethod

  def extractPatchHeader(patchfile):






-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159030): 
https://lists.openembedded.org/g/openembedded-core/message/159030
Mute This Topic: https://lists.openembedded.org/mt/87426820/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] patch.py: Initialize git repo before patching

[Pavel Zhukov]

From: Pavel Zhukov 

If PATCHTOOL="git" has been specified but workdir is not git repo
bitbake fails to apply the patches. Fix this by initializing the repo
before patching.
This allows binary git patches to be applied.

Signed-off-by: Pavel Zhukov 
---
 meta/lib/oe/patch.py | 17 +
 1 file changed, 17 insertions(+)

diff --git a/meta/lib/oe/patch.py b/meta/lib/oe/patch.py
index fccbedb519..8326cb55bc 100644
--- a/meta/lib/oe/patch.py
+++ b/meta/lib/oe/patch.py
@@ -56,6 +56,10 @@ def runcmd(args, dir = None):
 if dir:
 os.chdir(olddir)
 
+def getstatusoutput(cmd):
+import subprocess
+return subprocess.getstatusoutput(cmd.split())
+
 class PatchError(Exception):
 def __init__(self, msg):
 self.msg = msg
@@ -298,6 +302,19 @@ class GitApplyTree(PatchTree):
 PatchTree.__init__(self, dir, d)
 self.commituser = d.getVar('PATCH_GIT_USER_NAME')
 self.commitemail = d.getVar('PATCH_GIT_USER_EMAIL')
+if not self._isInitialized():
+self._initRepo()
+
+def _isInitialized(self):
+cmd = "git rev-parse --show-toplevel"
+(status, output) = getstatusoutput(cmd)
+## Make sure we're in builddir to not break top-level git repos
+return status == 0 and os.path.samedir(output, self.dir)
+
+def _initRepo(self):
+runcmd("git init".split(), self.dir)
+runcmd("git add .".split(), self.dir)
+runcmd("git commit -a --allow-empty -m Patching_started".split(), 
self.dir)
 
 @staticmethod
 def extractPatchHeader(patchfile):
-- 
2.34.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159029): 
https://lists.openembedded.org/g/openembedded-core/message/159029
Mute This Topic: https://lists.openembedded.org/mt/87426820/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] Yocto Project Status WW48`21

[Alexander Kanavin]

On Tue, 30 Nov 2021 at 21:40, Stephen Jolley 
wrote:

> We continue to see a reduction in the number of patches in “Pending”
> state. Many thanks to everyone who has taken the time to review patch
> status and handle accordingly, particularly where they were accepted
> upstream. This will significantly benefit the project in the long term.
>
Patches in the Pending State: 412 (32%) [last week 422 (33%)]
>

I went ahead and made a list of top 10 'owners of pending patches'. I have
to stress that this is absolutely not a 'wall of shame' or anything
negative: these patches are in itself significant work, and sending patches
upstream - and crucially, rebasing, fixing CI fails and following up on
upstream feedback - is a significant effort on top, and when yocto project
itself needs to move forward and company management is asking to deliver a
product at the same time, the time for upstreaming may simply not be there.
So  please keep these numbers in mind and try to avoid making them bigger.

109 Khem Raj
29 Richard Purdie
24 Alexander Kanavin
15 unknown
15 Ross Burton
15 Robert Yang
11 Hongxu Jia
10 Martin Jansa
8 Joe Slater
8 Chen Qi

Another interesting statistic is that of 108 people with pending patches,
80 own only one or two patches.

Alex

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159026): 
https://lists.openembedded.org/g/openembedded-core/message/159026
Mute This Topic: https://lists.openembedded.org/mt/87412476/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] linux-yocto-dev: Make -dev kernel work for a fixed revision

[Richard Purdie]

On Wed, 2021-12-01 at 12:39 +0800, Kevin Hao wrote:
> By default the -dev kernel uses the "AUTOREV" to pull in the branch
> head as the revision. Some of our BSPs are based on the -dev kernel and
> we choose to nail down the kernel to a specific revision when releasing
> our product by using some setting like below:
>   PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-dev"
>   SRCREV_machine:pn-linux-yocto-dev = 
> "6fb48ae18a10770702266dd1f1aa500149e361ec"
>   KBRANCH:pn-linux-yocto-dev = "standard/x86"
>   LINUX_VERSION = "5.15"
> 
> Since all the standard/* branches will be rebased after each kernel
> version bump, we would get bitbake fetch failure due to that specific
> commit is not reachable in the new version branch. This kind of issue
> can be fixed by setting the "nobranch" parameter in the SRC_URI because
> it will cause the fetcher to skip the SHA validation for the branch.
> And this also won't cause other side effect because all the branches
> will be created in the do_kernel_checkout() and the current branch will
> be reset to the reversion we want in do_validate_branches().
> 
> Signed-off-by: Kevin Hao 
> ---
>  meta/recipes-kernel/linux/linux-yocto-dev.bb | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/meta/recipes-kernel/linux/linux-yocto-dev.bb 
> b/meta/recipes-kernel/linux/linux-yocto-dev.bb
> index 6b6ea9a7e864..7204c3eddc11 100644
> --- a/meta/recipes-kernel/linux/linux-yocto-dev.bb
> +++ b/meta/recipes-kernel/linux/linux-yocto-dev.bb
> @@ -19,7 +19,8 @@ include recipes-kernel/linux/linux-yocto-dev-revisions.inc
>  KBRANCH = "standard/base"
>  KMETA = "kernel-meta"
>  
> -SRC_URI = 
> "git://git.yoctoproject.org/linux-yocto-dev.git;branch=${KBRANCH};name=machine
>  \
> +# Set nobranch to skip the SHA validation for branch if a fixed revesion is 
> used
> +SRC_URI = 
> "git://git.yoctoproject.org/linux-yocto-dev.git;branch=${KBRANCH};name=machine;nobranch=1
>  \
> 
> git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=master;destsuffix=${KMETA}"
>  
>  # Set default SRCREVs. Both the machine and meta SRCREVs are statically set

I'm afraid this looks to be a bit of a horrible workaround/hack. It happens that
if you specify a branch and set nobranch it might do what you want but that
certainly isn't by design.

Either the revision is in the branch or it isn't. The error is telling you the
configuration you set isn't valid and you really need to set a valid
configuration, i.e. a revision and a branch or a revision and set nobranch but
not both.

I'm not sure I understand why the kernel would be rebasing after each kernel
release? Is this because it is one of the unversioned branches?

I can fix the fetcher to hard error if both are set...

Cheers,

Richard




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159025): 
https://lists.openembedded.org/g/openembedded-core/message/159025
Mute This Topic: https://lists.openembedded.org/mt/87421079/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] openssl: fix EVP_PKEY_CTX_get_rsa_pss_saltlen() not returning a value

[Ross Burton]

Backport a patch from upstream. Specifically, this fixes signature
validation in trusted-firmware-a with OpenSSL 3.

Signed-off-by: Ross Burton 
---
 ...-EVP_PKEY_CTX_get_rsa_pss_saltlen-no.patch | 108 ++
 .../openssl/openssl_3.0.0.bb  |   1 +
 2 files changed, 109 insertions(+)
 create mode 100644 
meta/recipes-connectivity/openssl/openssl/0001-Fix-EVP_PKEY_CTX_get_rsa_pss_saltlen-no.patch

diff --git 
a/meta/recipes-connectivity/openssl/openssl/0001-Fix-EVP_PKEY_CTX_get_rsa_pss_saltlen-no.patch
 
b/meta/recipes-connectivity/openssl/openssl/0001-Fix-EVP_PKEY_CTX_get_rsa_pss_saltlen-no.patch
new file mode 100644
index 00..b85a3ad7d2
--- /dev/null
+++ 
b/meta/recipes-connectivity/openssl/openssl/0001-Fix-EVP_PKEY_CTX_get_rsa_pss_saltlen-no.patch
@@ -0,0 +1,108 @@
+Fix EVP_PKEY_CTX_get_rsa_pss_saltlen, and also disable the tests in non-default
+context (required when backporting, not needed with 3.0.1).
+
+Upstream-Status: Backport
+Signed-off-by: Ross Burton 
+
+From 6b5c02f6173e5fd46a3685e676fcb5eee9ac43ea Mon Sep 17 00:00:00 2001
+From: Tom Cosgrove 
+Date: Thu, 25 Nov 2021 15:49:26 +
+Subject: [PATCH] Fix EVP_PKEY_CTX_get_rsa_pss_saltlen() not returning a value
+
+When an integer value was specified, it was not being passed back via
+the orig_p2 weirdness.
+
+Regression test included.
+
+Reviewed-by: Tomas Mraz 
+Reviewed-by: Paul Dale 
+(Merged from https://github.com/openssl/openssl/pull/17136)
+---
+ crypto/evp/ctrl_params_translate.c | 12 +++-
+ test/evp_extra_test.c  | 30 ++
+ 2 files changed, 37 insertions(+), 5 deletions(-)
+
+diff --git a/crypto/evp/ctrl_params_translate.c 
b/crypto/evp/ctrl_params_translate.c
+index 88945e13e6..6638209a8d 100644
+--- a/crypto/evp/ctrl_params_translate.c
 b/crypto/evp/ctrl_params_translate.c
+@@ -1379,21 +1379,23 @@ static int fix_rsa_pss_saltlen(enum state state,
+ if ((ctx->action_type == SET && state == PRE_PARAMS_TO_CTRL)
+ || (ctx->action_type == GET && state == POST_CTRL_TO_PARAMS)) {
+ size_t i;
++int val;
+ 
+ for (i = 0; i < OSSL_NELEM(str_value_map); i++) {
+ if (strcmp(ctx->p2, str_value_map[i].ptr) == 0)
+ break;
+ }
+-if (i == OSSL_NELEM(str_value_map)) {
+-ctx->p1 = atoi(ctx->p2);
+-} else if (state == POST_CTRL_TO_PARAMS) {
++
++val = i == OSSL_NELEM(str_value_map) ? atoi(ctx->p2)
++ : (int)str_value_map[i].id;
++if (state == POST_CTRL_TO_PARAMS) {
+ /*
+  * EVP_PKEY_CTRL_GET_RSA_PSS_SALTLEN weirdness explained further
+  * up
+  */
+-*(int *)ctx->orig_p2 = str_value_map[i].id;
++*(int *)ctx->orig_p2 = val;
+ } else {
+-ctx->p1 = (int)str_value_map[i].id;
++ctx->p1 = val;
+ }
+ ctx->p2 = NULL;
+ }
+diff --git a/test/evp_extra_test.c b/test/evp_extra_test.c
+index 83f8902d24..9ad37a2bce 100644
+--- a/test/evp_extra_test.c
 b/test/evp_extra_test.c
+@@ -3049,6 +3049,35 @@ static int test_EVP_rsa_pss_with_keygen_bits(void)
+ return ret;
+ }
+ 
++static int test_EVP_rsa_pss_set_saltlen(void)
++{
++int ret = 0;
++EVP_PKEY *pkey = NULL;
++EVP_PKEY_CTX *pkey_ctx = NULL;
++EVP_MD *sha256 = NULL;
++EVP_MD_CTX *sha256_ctx = NULL;
++int saltlen = ; /* buggy EVP_PKEY_CTX_get_rsa_pss_saltlen() didn't 
update this */
++const int test_value = 32;
++
++if (nullprov != NULL)
++return TEST_skip("Test does not support a non-default library 
context");
++
++ret = TEST_ptr(pkey = load_example_rsa_key())
++&& TEST_ptr(sha256 = EVP_MD_fetch(testctx, "sha256", NULL))
++&& TEST_ptr(sha256_ctx = EVP_MD_CTX_new())
++&& TEST_true(EVP_DigestSignInit(sha256_ctx, _ctx, sha256, NULL, 
pkey))
++&& TEST_true(EVP_PKEY_CTX_set_rsa_padding(pkey_ctx, 
RSA_PKCS1_PSS_PADDING))
++&& TEST_true(EVP_PKEY_CTX_set_rsa_pss_saltlen(pkey_ctx, test_value))
++&& TEST_true(EVP_PKEY_CTX_get_rsa_pss_saltlen(pkey_ctx, ))
++&& TEST_int_eq(saltlen, test_value);
++
++EVP_MD_CTX_free(sha256_ctx);
++EVP_PKEY_free(pkey);
++EVP_MD_free(sha256);
++
++return ret;
++}
++
+ static int success = 1;
+ static void md_names(const char *name, void *vctx)
+ {
+@@ -3966,6 +3995,7 @@ int setup_tests(void)
+ ADD_ALL_TESTS(test_evp_iv_des, 6);
+ #endif
+ ADD_TEST(test_EVP_rsa_pss_with_keygen_bits);
++ADD_TEST(test_EVP_rsa_pss_set_saltlen);
+ #ifndef OPENSSL_NO_EC
+ ADD_ALL_TESTS(test_ecpub, OSSL_NELEM(ecpub_nids));
+ #endif
+-- 
+2.25.1
+
diff --git a/meta/recipes-connectivity/openssl/openssl_3.0.0.bb 
b/meta/recipes-connectivity/openssl/openssl_3.0.0.bb
index 8852a51ca8..4b1ae71a85 100644
--- a/meta/recipes-connectivity/openssl/openssl_3.0.0.bb
+++ b/meta/recipes-connectivity/openssl/openssl_3.0.0.bb
@@ 

Re: [OE-core] [PATCH] [master] [dunfell] [hardknott] Revert "db: update CVE_PRODUCT"

[Ranjitsinh Rathod via lists.openembedded.org]

HI Steve,

When do you plan to add these db CVEs in the 
'meta/conf/distro/include/cve-extra-exclusions.inc' file?


Thanks,

Best Regards,

Ranjitsinh Rathod
Technical Leader |  | KPIT Technologies Ltd.
Cellphone: +91-84606 92403
__
KPIT | Follow us on LinkedIn

[cid:bd98461e-3fae-4ae5-bd5d-5abc68f568c4]


From: openembedded-core@lists.openembedded.org 
 on behalf of Steve Sakoman via 
lists.openembedded.org 
Sent: Wednesday, September 15, 2021 12:38 AM
To: Steve Sakoman 
Cc: Patches and discussions about the oe-core layer 

Subject: Re: [OE-core] [PATCH] [master] [dunfell] [hardknott] Revert "db: 
update CVE_PRODUCT"

Caution: This email originated from outside of the KPIT. Do not click links or 
open attachments unless you recognize the sender and know the content is safe.

On Tue, Sep 14, 2021 at 8:41 AM Steve Sakoman via
lists.openembedded.org 
wrote:
>
> On Tue, Sep 14, 2021 at 8:04 AM Steve Sakoman via
> lists.openembedded.org 
> wrote:
> >
> > The CVE database correctly reports CVEs for oracle_berkley_db and
> > berkley_db.  We use the oracle_berkley_db source tree and therefore
> > should only check for oracle_berkely_db CVEs. Otherwise the scanner
> > falsely reports CVEs that are fixed in oracle_berkley_db
>
> Please hold off on taking this patch -- I need to do some more
> research.  I may have confused myself :-(

I did indeed confuse myself, so ignore this patch.

The CVE database is reporting CVEs for the Oracle db code base under
the name berkley_db, so the original patch in question is indeed
correct and the CVEs are valid.

Our CVE reporting has been whitelisting db CVEs.  I'm going to remove
that from the tool and submit a patch to add the db CVEs to the
exclusion list in meta/conf/distro/include/cve-extra-exclusions.inc
since it seems unlikely that we will be moving to a version of db with
these issues fixed.

Steve

> > This reverts commit ad799b109716ccd2f44dcf7a6a4cfcbd622ea661.
> >
> > Signed-off-by: Steve Sakoman 
> > ---
> >  meta/recipes-support/db/db_5.3.28.bb | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/meta/recipes-support/db/db_5.3.28.bb 
> > b/meta/recipes-support/db/db_5.3.28.bb
> > index d5b788a3d7..5e9305ab06 100644
> > --- a/meta/recipes-support/db/db_5.3.28.bb
> > +++ b/meta/recipes-support/db/db_5.3.28.bb
> > @@ -15,7 +15,7 @@ HOMEPAGE = 
> > "https://www.oracle.com/database/technologies/related/berkeleydb.html
> >  LICENSE = "Sleepycat"
> >  RCONFLICTS:${PN} = "db3"
> >
> > -CVE_PRODUCT = "oracle_berkeley_db berkeley_db"
> > +CVE_PRODUCT = "oracle_berkeley_db"
> >  CVE_VERSION = "11.2.${PV}"
> >
> >  PR = "r1"
> > --
> > 2.25.1
> >
> >
> >
> >
>
>
>
This message contains information that may be privileged or confidential and is 
the property of the KPIT Technologies Ltd. It is intended only for the person 
to whom it is addressed. If you are not the intended recipient, you are not 
authorized to read, print, retain copy, disseminate, distribute, or use this 
message or any part thereof. If you receive this message in error, please 
notify the sender immediately and delete all copies of this message. KPIT 
Technologies Ltd. does not accept any liability for virus infected mails.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159023): 
https://lists.openembedded.org/g/openembedded-core/message/159023
Mute This Topic: https://lists.openembedded.org/mt/85608645/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] busybox: Fix for CVE-2021-42376

[Pavel Zhukov]

From: Pavel Zhukov 

A NULL pointer dereference in Busybox's hush applet leads to denial of service
when processing a crafted shell command, due to missing validation after
a \x03 delimiter character.
This may be used for DoS under very rare conditions of filtered command input.

Reference: https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-42376

Signed-off-by: Pavel Zhukov 
---
 .../busybox/busybox/CVE-2021-42376.patch  | 138 ++
 meta/recipes-core/busybox/busybox_1.31.1.bb   |   1 +
 2 files changed, 139 insertions(+)
 create mode 100644 meta/recipes-core/busybox/busybox/CVE-2021-42376.patch

diff --git a/meta/recipes-core/busybox/busybox/CVE-2021-42376.patch 
b/meta/recipes-core/busybox/busybox/CVE-2021-42376.patch
new file mode 100644
index 00..c913eaee9c
--- /dev/null
+++ b/meta/recipes-core/busybox/busybox/CVE-2021-42376.patch
@@ -0,0 +1,138 @@
+From 56a335378ac100d51c30b21eee499a2effa37fba Mon Sep 17 00:00:00 2001
+From: Denys Vlasenko 
+Date: Tue, 15 Jun 2021 16:05:57 +0200
+Subject: hush: fix handling of \^C and "^C"
+
+function old new   delta
+parse_stream22382252 +14
+encode_string243 256 +13
+--
+(add/remove: 0/0 grow/shrink: 2/0 up/down: 27/0)   Total: 27 bytes
+
+Signed-off-by: Denys Vlasenko 
+(cherry picked from commit 1b7a9b68d0e9aa19147d7fda16eb9a6b54156985)
+
+Signed-off-by: Pavel Zhukov 
+
+CVE: CVE-2021-42376
+Upstream-Status: Backport 
[https://git.busybox.net/busybox/patch/?id=56a335378ac100d51c30b21eee499a2effa37fba]
+Comment: No changes in any hunk
+---
+ shell/ash_test/ash-misc/control_char3.right   |  1 +
+ shell/ash_test/ash-misc/control_char3.tests   |  2 ++
+ shell/ash_test/ash-misc/control_char4.right   |  1 +
+ shell/ash_test/ash-misc/control_char4.tests   |  2 ++
+ shell/hush.c  | 11 +++
+ shell/hush_test/hush-misc/control_char3.right |  1 +
+ shell/hush_test/hush-misc/control_char3.tests |  2 ++
+ shell/hush_test/hush-misc/control_char4.right |  1 +
+ shell/hush_test/hush-misc/control_char4.tests |  2 ++
+ 9 files changed, 23 insertions(+)
+ create mode 100644 shell/ash_test/ash-misc/control_char3.right
+ create mode 100755 shell/ash_test/ash-misc/control_char3.tests
+ create mode 100644 shell/ash_test/ash-misc/control_char4.right
+ create mode 100755 shell/ash_test/ash-misc/control_char4.tests
+ create mode 100644 shell/hush_test/hush-misc/control_char3.right
+ create mode 100755 shell/hush_test/hush-misc/control_char3.tests
+ create mode 100644 shell/hush_test/hush-misc/control_char4.right
+ create mode 100755 shell/hush_test/hush-misc/control_char4.tests
+
+diff --git a/shell/ash_test/ash-misc/control_char3.right 
b/shell/ash_test/ash-misc/control_char3.right
+new file mode 100644
+index 0..283e02cbb
+--- /dev/null
 b/shell/ash_test/ash-misc/control_char3.right
+@@ -0,0 +1 @@
++SHELL: line 1: : not found
+diff --git a/shell/ash_test/ash-misc/control_char3.tests 
b/shell/ash_test/ash-misc/control_char3.tests
+new file mode 100755
+index 0..4359db3f3
+--- /dev/null
 b/shell/ash_test/ash-misc/control_char3.tests
+@@ -0,0 +1,2 @@
++# (set argv0 to "SHELL" to avoid "/path/to/shell: blah" in error messages)
++$THIS_SH -c '\' SHELL
+diff --git a/shell/ash_test/ash-misc/control_char4.right 
b/shell/ash_test/ash-misc/control_char4.right
+new file mode 100644
+index 0..2bf18e684
+--- /dev/null
 b/shell/ash_test/ash-misc/control_char4.right
+@@ -0,0 +1 @@
++SHELL: line 1: -: not found
+diff --git a/shell/ash_test/ash-misc/control_char4.tests 
b/shell/ash_test/ash-misc/control_char4.tests
+new file mode 100755
+index 0..48010f154
+--- /dev/null
 b/shell/ash_test/ash-misc/control_char4.tests
+@@ -0,0 +1,2 @@
++# (set argv0 to "SHELL" to avoid "/path/to/shell: blah" in error messages)
++$THIS_SH -c '"-"' SHELL
+diff --git a/shell/hush.c b/shell/hush.c
+index 9fead37da..249728b9d 100644
+--- a/shell/hush.c
 b/shell/hush.c
+@@ -5235,6 +5235,11 @@ static int encode_string(o_string *as_string,
+   }
+ #endif
+   o_addQchr(dest, ch);
++  if (ch == SPECIAL_VAR_SYMBOL) {
++  /* Convert "^C" to corresponding special variable reference */
++  o_addchr(dest, SPECIAL_VAR_QUOTED_SVS);
++  o_addchr(dest, SPECIAL_VAR_SYMBOL);
++  }
+   goto again;
+ #undef as_string
+ }
+@@ -5346,6 +5351,11 @@ static struct pipe *parse_stream(char **pstring,
+   if (ch == '\n')
+   continue; /* drop \, get next char */
+   nommu_addchr(_string, '\\');
++  if (ch == SPECIAL_VAR_SYMBOL) {
++  nommu_addchr(_string, ch);
++  /* Convert \^C to corresponding 

[OE-core] [dunfell][PATCH 1/2] busybox: Fix for CVE-2021-42374

[Pavel Zhukov]

From: Pavel Zhukov 

An out-of-bounds heap read in unlzma leads to information leak and
denial of service when crafted LZMA-compressed input is decompressed.
This can be triggered by any applet/format that internally supports
LZMA compression.

Reference: https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-42374

Signed-off-by: Pavel Zhukov 
---
 .../busybox/busybox/CVE-2021-42374.patch  | 53 +++
 meta/recipes-core/busybox/busybox_1.31.1.bb   |  1 +
 2 files changed, 54 insertions(+)
 create mode 100644 meta/recipes-core/busybox/busybox/CVE-2021-42374.patch

diff --git a/meta/recipes-core/busybox/busybox/CVE-2021-42374.patch 
b/meta/recipes-core/busybox/busybox/CVE-2021-42374.patch
new file mode 100644
index 00..aef8a3db85
--- /dev/null
+++ b/meta/recipes-core/busybox/busybox/CVE-2021-42374.patch
@@ -0,0 +1,53 @@
+From 04f052c56ded5ab6a904e3a264a73dc0412b2e78 Mon Sep 17 00:00:00 2001
+From: Denys Vlasenko 
+Date: Tue, 15 Jun 2021 15:07:57 +0200
+Subject: [PATCH] unlzma: fix a case where we could read before beginning of
+ buffer
+Cc: pa...@zhukoff.net
+
+Testcase:
+
+  21 01 01 00 00 00 00 00 e7 01 01 01 ef 00 df b6
+  00 17 02 10 11 0f ff 00 16 00 00
+
+Unfortunately, the bug is not reliably causing a segfault,
+the behavior depends on what's in memory before the buffer.
+
+function old new   delta
+unpack_lzma_stream  27622768  +6
+
+Signed-off-by: Denys Vlasenko 
+
+Signed-off-by: Pavel Zhukov 
+
+CVE: CVE-2021-42374
+Upstream-Status: Backport 
[https://git.busybox.net/busybox/commit/?h=1_33_stable=d326be2850ea2bd78fe2c22d6c45c3b861d82937]
+Comment: testdata dropped because of binary format
+
+---
+ archival/libarchive/decompress_unlzma.c |   5 -
+ testsuite/unlzma.tests  |  17 +
+ testsuite/unlzma_issue_3.lzma   | Bin 0 -> 27 bytes
+ 3 files changed, 17 insertions(+), 5 deletions(-)
+ create mode 100644 testsuite/unlzma_issue_3.lzma
+
+diff --git a/archival/libarchive/decompress_unlzma.c 
b/archival/libarchive/decompress_unlzma.c
+index 
0744f231a1d64d92676b0cada2342f88f3b39b31..fb5aac8fe9ea0c53e0c2d7a7cbd05a753e39bc9d
 100644
+--- a/archival/libarchive/decompress_unlzma.c
 b/archival/libarchive/decompress_unlzma.c
+@@ -290,8 +290,11 @@ unpack_lzma_stream(transformer_state_t *xstate)
+   uint32_t pos;
+ 
+   pos = buffer_pos - rep0;
+-  if ((int32_t)pos < 0)
++  if ((int32_t)pos < 0) {
+   pos += header.dict_size;
++  if ((int32_t)pos < 0)
++  goto bad;
++  }
+   match_byte = buffer[pos];
+   do {
+   int bit;
+-- 
+2.34.0
+
diff --git a/meta/recipes-core/busybox/busybox_1.31.1.bb 
b/meta/recipes-core/busybox/busybox_1.31.1.bb
index d9d5f4f96b..55c00eb483 100644
--- a/meta/recipes-core/busybox/busybox_1.31.1.bb
+++ b/meta/recipes-core/busybox/busybox_1.31.1.bb
@@ -52,6 +52,7 @@ SRC_URI = 
"https://busybox.net/downloads/busybox-${PV}.tar.bz2;name=tarball \
file://0001-hwclock-make-glibc-2.31-compatible.patch \
file://0001-decompress_gunzip-Fix-DoS-if-gzip-is-corrupt.patch \
file://0001-mktemp-add-tmpdir-option.patch \
+   file://CVE-2021-42374.patch \
"
 SRC_URI_append_libc-musl = " file://musl.cfg "
 
-- 
2.34.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159021): 
https://lists.openembedded.org/g/openembedded-core/message/159021
Mute This Topic: https://lists.openembedded.org/mt/87424098/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] [RFC] meson needs a pkg-config wrapper script

[Eero Aaltonen]

You can use `${pcfiledir}/../..` within a pkg-config file to reference
the install path.
Unfortunately the last time I tried it when cross-compiling, the
PKG_CONFIG_SYSROOT_DIR was ended up in the path as a duplicate.

-Eero

On Wed, 2021-12-01 at 09:36 +0100, Alexander Kanavin via
lists.openembedded.org wrote:
> No, it's not that. Even if you pass PKG_CONFIG_SYSROOT_DIR to pkg-
> config directly, it will apply that only to --cflags and similar, but
> not to generic --variable. Try this:
> 
> alex@alex-lx-laptop:~$ PKG_CONFIG_SYSROOT_DIR=/ pkg-config libdrm
> --cflags
> -I//usr/include/libdrm
> alex@alex-lx-laptop:~$ PKG_CONFIG_SYSROOT_DIR=/ pkg-config libdrm
> --variable=includedir
> /usr/include
> 
> So a wrapper will not solve the 'includedir prefix' problem, and
> neither the wrapper, nor pkg-config or meson can possibly know which
> variable is a path, and which isn't - the only place where that is
> known is the component that obtains the variable. And so that's where
> it has to be prefixed.
> 
> Alex
> 
> 
> On Tue, 30 Nov 2021 at 23:38, Joel Winarske 
> wrote:
> > Based on my testing, if PKG_CONFIG_SYSROOT_DIR is set or not makes
> > zero difference on the outcome.  I suspect this is related to how
> > pkg-config is launched by meson.
> > 
> > Looking at the meson source tree, in all ci/test cross compile 
> > scenarios they reference a pkg-config wrapper.  No cross compile 
> > scenario I see referencing the 'pkgconfig' key uses a bare pkg-
> > config.
> > 
> > cross/armclang-linux.txt:#pkgconfig = '/usr/bin/arm-linux-
> > gnueabihf-pkg-config'
> > cross/linux-mingw-w64-32bit.txt:pkgconfig = '/usr/bin/i686-w64-
> > mingw32-pkg-config'
> > cross/linux-mingw-w64-64bit.txt:pkgconfig = '/usr/bin/x86_64-
> > w64-mingw32-pkg-config'
> > cross/ubuntu-armhf.txt:pkgconfig = '/usr/bin/arm-linux-
> > gnueabihf-pkg-config'
> >
> >  test cases/unit/33 cross file overrides always 
> > args/ubuntu-armhf-overrides.txt:pkgconfig = 
> > '/usr/bin/arm-linux-gnueabihf-pkg-config'
> > test cases/unit/36 exe_wrapper behaviour/broken-
> > cross.txt:pkgconfig = '/usr/bin/x86_64-w64-mingw32-pkg-config'
> > 
> > 
> > I think adding a wrapper makes sense.
> > 
> > 5.2 Tool Calling Conventions - 
> > https://autotools.io/pkgconfig/cross-compiling.html
> > On Tue, Nov 30, 2021 at 12:13 PM Alexander Kanavin <
> > alex.kana...@gmail.com> wrote:
> > > On Tue, 30 Nov 2021 at 21:00, Joel Winarske <
> > > joel.winar...@gmail.com> wrote:
> > > > Yes, if the sys_root key value in meson.cross is present
> > > > PKG_CONFIG_SYSROOT_DIR gets set.  Honister patch I confirmed
> > > > with:
> > > > 
https://github.com/jwinarske/manifests/blob/honister/rpi64/0001-Add-sys_root-to-properties-section.patch
> > > > 
> > > > The issue is that meson doesn't pass PKG_CONFIG_SYSROOT_DIR to
> > > > the shell environment that runs pkg-config, as with the pkg-
> > > > config sandbox test it does work.
> > > > 
> > > 
> > > Both meson source code and its documentation indicate otherwise -
> > > if you set sys_root property, it will get passed to pkg-config
> > > via environment as PKG_CONFIG_SYSROOT_DIR:
> > > https://github.com/mesonbuild/meson/blob/master/mesonbuild/dependencies/pkgconfig.py#L121
> > > Alex
> > > 
> > > 
> 
> 
> 
> 

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159020): 
https://lists.openembedded.org/g/openembedded-core/message/159020
Mute This Topic: https://lists.openembedded.org/mt/87407703/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] [RFC] meson needs a pkg-config wrapper script

[Alexander Kanavin]

No, it's not that. Even if you pass PKG_CONFIG_SYSROOT_DIR to pkg-config
directly, it will apply that only to --cflags and similar, but not to
generic --variable. Try this:

alex@alex-lx-laptop:~$ PKG_CONFIG_SYSROOT_DIR=/ pkg-config libdrm
--cflags
-I//usr/include/libdrm
alex@alex-lx-laptop:~$ PKG_CONFIG_SYSROOT_DIR=/ pkg-config libdrm
--variable=includedir
/usr/include

So a wrapper will not solve the 'includedir prefix' problem, and neither
the wrapper, nor pkg-config or meson can possibly know which variable is a
path, and which isn't - the only place where that is known is the component
that obtains the variable. And so that's where it has to be prefixed.

Alex

On Tue, 30 Nov 2021 at 23:38, Joel Winarske  wrote:

> Based on my testing, if PKG_CONFIG_SYSROOT_DIR is set or not makes zero
> difference on the outcome.  I suspect this is related to how pkg-config is
> launched by meson.
>
> Looking at the meson source tree, in all ci/test cross compile scenarios
> they reference a pkg-config wrapper.  No cross compile scenario I see
> referencing the 'pkgconfig' key uses a bare pkg-config.
>
> cross/armclang-linux.txt:#pkgconfig =
> '/usr/bin/arm-linux-gnueabihf-pkg-config'
> cross/linux-mingw-w64-32bit.txt:pkgconfig =
> '/usr/bin/i686-w64-mingw32-pkg-config'
> cross/linux-mingw-w64-64bit.txt:pkgconfig =
> '/usr/bin/x86_64-w64-mingw32-pkg-config'
> cross/ubuntu-armhf.txt:pkgconfig =
> '/usr/bin/arm-linux-gnueabihf-pkg-config'
> test cases/unit/33 cross file overrides always
> args/ubuntu-armhf-overrides.txt:pkgconfig =
> '/usr/bin/arm-linux-gnueabihf-pkg-config'
> test cases/unit/36 exe_wrapper behaviour/broken-cross.txt:pkgconfig =
> '/usr/bin/x86_64-w64-mingw32-pkg-config'
>
> I think adding a wrapper makes sense.
>
> 5.2 Tool Calling Conventions -
> https://autotools.io/pkgconfig/cross-compiling.html
>
> On Tue, Nov 30, 2021 at 12:13 PM Alexander Kanavin 
> wrote:
>
>> On Tue, 30 Nov 2021 at 21:00, Joel Winarske 
>> wrote:
>>
>>> Yes, if the sys_root key value in meson.cross is present
>>> PKG_CONFIG_SYSROOT_DIR gets set.  Honister patch I confirmed with:
>>>
>>> https://github.com/jwinarske/manifests/blob/honister/rpi64/0001-Add-sys_root-to-properties-section.patch
>>>
>>> The issue is that meson doesn't pass PKG_CONFIG_SYSROOT_DIR to the shell
>>> environment that runs pkg-config, as with the pkg-config sandbox test it
>>> does work.
>>>
>>
>> Both meson source code and its documentation indicate otherwise - if you
>> set sys_root property, it will get passed to pkg-config via environment as
>> PKG_CONFIG_SYSROOT_DIR:
>>
>> https://github.com/mesonbuild/meson/blob/master/mesonbuild/dependencies/pkgconfig.py#L121
>>
>> Alex
>>
>>

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