Re: [OE-core] [PATCH] qemu: access host pkg-config via HOSTTOOLS

[Taras Kondratiuk via lists.openembedded.org]

On Fri, 2020-07-10 at 20:11 +0100, Richard Purdie wrote:
> On Fri, 2020-07-10 at 18:18 +, Taras Kondratiuk (takondra) wrote:
> > On Fri, 2020-07-10 at 18:56 +0100, Richard Purdie wrote:
> > > qemu is a little special, its about the only thing we let look
> > > into
> > > the
> > > system for things like this. We really don't want pkg-config
> > > available
> > > generally in HOSTTOOLS.
> > > 
> > > I'm not 100% sure I understand how this is fixing things either.
> > > Is
> > > this using the pkg-config from your buildtools tarball instead?
> > > 
> > 
> > Yes, it is using pkg-config from buildtools tarball.
> > 
> > As per my understanding other parts of the build will still use
> > pkgconfig-native and should not be affected. Or the concern is that
> > packages without proper pkgconfig-native dependency will find this
> > pkg-config in HOSTTOOLS?
> 
> Yes, that is one concern.
> 
> Another is that if its using nativesdk-pkgconfig from buildtools,
> does
> this break the reason we have this code in the first place (to allow
> qemu to use the host GL for virtgl)? Presumably that is not in
> buildtools...

I see. IIUC this host pkg-config part should be used only
if ASSUME_PROVIDED has libsdl2-native
https://git.openembedded.org/openembedded-core/tree/meta/conf/local.conf.sample?h=2020-04.1-dunfell#n213

Does it make sense to make this part conditional on ASSUME_PROVIDED
containing libsdl2-native?
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#140559): 
https://lists.openembedded.org/g/openembedded-core/message/140559
Mute This Topic: https://lists.openembedded.org/mt/75423722/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] scripts/lib/recipetool/create.py: fix regex strings

[Tim Orling]

Python now expects regex strings to be prepended with r.
Silence pylint/autopep8 and similar warnings by identifying
these regex patterns as... regex patterns.

Signed-off-by: Tim Orling 
---
 scripts/lib/recipetool/create.py | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/scripts/lib/recipetool/create.py b/scripts/lib/recipetool/create.py
index 8d78c5b6f99..566c75369a9 100644
--- a/scripts/lib/recipetool/create.py
+++ b/scripts/lib/recipetool/create.py
@@ -66,7 +66,7 @@ class RecipeHandler(object):
 libdir = d.getVar('libdir')
 base_libdir = d.getVar('base_libdir')
 libpaths = list(set([base_libdir, libdir]))
-libname_re = re.compile('^lib(.+)\.so.*$')
+libname_re = re.compile(r'^lib(.+)\.so.*$')
 pkglibmap = {}
 for lib, item in shlib_providers.items():
 for path, pkg in item.items():
@@ -428,7 +428,7 @@ def create_recipe(args):
 
 if scriptutils.is_src_url(source):
 # Warn about github archive URLs
-if 
re.match('https?://github.com/[^/]+/[^/]+/archive/.+(\.tar\..*|\.zip)$', 
source):
+if 
re.match(r'https?://github.com/[^/]+/[^/]+/archive/.+(\.tar\..*|\.zip)$', 
source):
 logger.warning('github archive files are not guaranteed to be 
stable and may be re-generated over time. If the latter occurs, the checksums 
will likely change and the recipe will fail at do_fetch. It is recommended that 
you point to an actual commit or tag in the repository instead (using the 
repository URL in conjunction with the -S/--srcrev option).')
 # Fetch a URL
 fetchuri = reformat_git_uri(urldefrag(source)[0])
@@ -830,7 +830,7 @@ def create_recipe(args):
 elif line.startswith('PV = '):
 if realpv:
 # Replace the first part of the PV value
-line = re.sub('"[^+]*\+', '"%s+' % realpv, line)
+line = re.sub(r'"[^+]*\+', '"%s+' % realpv, line)
 lines_before.append(line)
 
 if args.also_native:
@@ -1066,8 +1066,8 @@ def crunch_license(licfile):
 import oe.utils
 
 # Note: these are carefully constructed!
-license_title_re = re.compile('^\(?(#+ *)?(The )?.{1,10} [Ll]icen[sc]e( 
\(.{1,10}\))?\)?:?$')
-license_statement_re = re.compile('^(This (project|software) is( free 
software)? (released|licen[sc]ed)|(Released|Licen[cs]ed)) under the .{1,10} 
[Ll]icen[sc]e:?$')
+license_title_re = re.compile(r'^\(?(#+ *)?(The )?.{1,10} [Ll]icen[sc]e( 
\(.{1,10}\))?\)?:?$')
+license_statement_re = re.compile(r'^(This (project|software) is( free 
software)? (released|licen[sc]ed)|(Released|Licen[cs]ed)) under the .{1,10} 
[Ll]icen[sc]e:?$')
 copyright_re = re.compile('^(#+)? *Copyright .*$')
 
 crunched_md5sums = {}
-- 
2.24.0

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

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

[OE-core] [PATCH 0/2] recipetool fixes

[Tim Orling]

There are some issues with the existing recipetool codebase:
(1) It is _impossible_ to insert the AUTHOR variable in the recommended
location [1]. And the BBCLASSEXTEND variable is also missing from
the list (although inserting that in the recommended location is
trivial).
(2) Several regex patterns are missing the r' prefix, which leads tools
like pylint/autopep8 to throw warnings because the regex patterns...
are not identified as regex patterns.

[1] http://www.openembedded.org/wiki/Styleguide

The following changes since commit b3c96103a5063eeefb0c537227eab3f77616b9c0:

  libnl: Extend for native/nativesdk (2020-07-08 10:56:11 +0100)

are available in the Git repository at:

  git://git.openembedded.org/openembedded-core-contrib timo/oe-recipetool-fixes
  
http://cgit.openembedded.org/openembedded-core-contrib/log/?h=timo/oe-recipetool-fixes

Tim Orling (2):
  lib/oe/recipeutils.py: add AUTHOR; BBCLASSEXTEND
  scripts/lib/recipetool/create.py: fix regex strings

 meta/lib/oe/recipeutils.py   |  2 +-
 scripts/lib/recipetool/create.py | 10 +-
 2 files changed, 6 insertions(+), 6 deletions(-)

-- 
2.24.0

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

View/Reply Online (#140556): 
https://lists.openembedded.org/g/openembedded-core/message/140556
Mute This Topic: https://lists.openembedded.org/mt/75433144/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] lib/oe/recipeutils.py: add AUTHOR; BBCLASSEXTEND

[Tim Orling]

If you try to create a plugin for recipetool that
adds the AUTHOR field, it is impossible to put it
in the recommended position [1] without adding to the
recipe_progression variable.

While we are at it, also add BBCLASSEXTEND at the
end, as also recommended by [1].

[1] http://www.openembedded.org/wiki/Styleguide

Signed-off-by: Tim Orling 
---
 meta/lib/oe/recipeutils.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/lib/oe/recipeutils.py b/meta/lib/oe/recipeutils.py
index 29473a98825..36427eec918 100644
--- a/meta/lib/oe/recipeutils.py
+++ b/meta/lib/oe/recipeutils.py
@@ -24,7 +24,7 @@ from collections import OrderedDict, defaultdict
 from bb.utils import vercmp_string
 
 # Help us to find places to insert values
-recipe_progression = ['SUMMARY', 'DESCRIPTION', 'HOMEPAGE', 'BUGTRACKER', 
'SECTION', 'LICENSE', 'LICENSE_FLAGS', 'LIC_FILES_CHKSUM', 'PROVIDES', 
'DEPENDS', 'PR', 'PV', 'SRCREV', 'SRCPV', 'SRC_URI', 'S', 'do_fetch()', 
'do_unpack()', 'do_patch()', 'EXTRA_OECONF', 'EXTRA_OECMAKE', 'EXTRA_OESCONS', 
'do_configure()', 'EXTRA_OEMAKE', 'do_compile()', 'do_install()', 
'do_populate_sysroot()', 'INITSCRIPT', 'USERADD', 'GROUPADD', 'PACKAGES', 
'FILES', 'RDEPENDS', 'RRECOMMENDS', 'RSUGGESTS', 'RPROVIDES', 'RREPLACES', 
'RCONFLICTS', 'ALLOW_EMPTY', 'populate_packages()', 'do_package()', 
'do_deploy()']
+recipe_progression = ['SUMMARY', 'DESCRIPTION', 'AUTHOR', 'HOMEPAGE', 
'BUGTRACKER', 'SECTION', 'LICENSE', 'LICENSE_FLAGS', 'LIC_FILES_CHKSUM', 
'PROVIDES', 'DEPENDS', 'PR', 'PV', 'SRCREV', 'SRCPV', 'SRC_URI', 'S', 
'do_fetch()', 'do_unpack()', 'do_patch()', 'EXTRA_OECONF', 'EXTRA_OECMAKE', 
'EXTRA_OESCONS', 'do_configure()', 'EXTRA_OEMAKE', 'do_compile()', 
'do_install()', 'do_populate_sysroot()', 'INITSCRIPT', 'USERADD', 'GROUPADD', 
'PACKAGES', 'FILES', 'RDEPENDS', 'RRECOMMENDS', 'RSUGGESTS', 'RPROVIDES', 
'RREPLACES', 'RCONFLICTS', 'ALLOW_EMPTY', 'populate_packages()', 
'do_package()', 'do_deploy()', 'BBCLASSEXTEND']
 # Variables that sometimes are a bit long but shouldn't be wrapped
 nowrap_vars = ['SUMMARY', 'HOMEPAGE', 'BUGTRACKER', 
r'SRC_URI\[(.+\.)?md5sum\]', r'SRC_URI\[(.+\.)?sha256sum\]']
 list_vars = ['SRC_URI', 'LIC_FILES_CHKSUM']
-- 
2.24.0

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

View/Reply Online (#140557): 
https://lists.openembedded.org/g/openembedded-core/message/140557
Mute This Topic: https://lists.openembedded.org/mt/75433313/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] scripts/lib/recipetool/create.py: fix regex strings

[Tim Orling]

From: Tim Orling 

Python now expects regex strings to be prepended with r.
Silence pylint/autopep8 and similar warnings by identifying
these regex patterns as... regex patterns.

Signed-off-by: Tim Orling 
---
 scripts/lib/recipetool/create.py | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/scripts/lib/recipetool/create.py b/scripts/lib/recipetool/create.py
index 8d78c5b6f99..566c75369a9 100644
--- a/scripts/lib/recipetool/create.py
+++ b/scripts/lib/recipetool/create.py
@@ -66,7 +66,7 @@ class RecipeHandler(object):
 libdir = d.getVar('libdir')
 base_libdir = d.getVar('base_libdir')
 libpaths = list(set([base_libdir, libdir]))
-libname_re = re.compile('^lib(.+)\.so.*$')
+libname_re = re.compile(r'^lib(.+)\.so.*$')
 pkglibmap = {}
 for lib, item in shlib_providers.items():
 for path, pkg in item.items():
@@ -428,7 +428,7 @@ def create_recipe(args):
 
 if scriptutils.is_src_url(source):
 # Warn about github archive URLs
-if 
re.match('https?://github.com/[^/]+/[^/]+/archive/.+(\.tar\..*|\.zip)$', 
source):
+if 
re.match(r'https?://github.com/[^/]+/[^/]+/archive/.+(\.tar\..*|\.zip)$', 
source):
 logger.warning('github archive files are not guaranteed to be 
stable and may be re-generated over time. If the latter occurs, the checksums 
will likely change and the recipe will fail at do_fetch. It is recommended that 
you point to an actual commit or tag in the repository instead (using the 
repository URL in conjunction with the -S/--srcrev option).')
 # Fetch a URL
 fetchuri = reformat_git_uri(urldefrag(source)[0])
@@ -830,7 +830,7 @@ def create_recipe(args):
 elif line.startswith('PV = '):
 if realpv:
 # Replace the first part of the PV value
-line = re.sub('"[^+]*\+', '"%s+' % realpv, line)
+line = re.sub(r'"[^+]*\+', '"%s+' % realpv, line)
 lines_before.append(line)
 
 if args.also_native:
@@ -1066,8 +1066,8 @@ def crunch_license(licfile):
 import oe.utils
 
 # Note: these are carefully constructed!
-license_title_re = re.compile('^\(?(#+ *)?(The )?.{1,10} [Ll]icen[sc]e( 
\(.{1,10}\))?\)?:?$')
-license_statement_re = re.compile('^(This (project|software) is( free 
software)? (released|licen[sc]ed)|(Released|Licen[cs]ed)) under the .{1,10} 
[Ll]icen[sc]e:?$')
+license_title_re = re.compile(r'^\(?(#+ *)?(The )?.{1,10} [Ll]icen[sc]e( 
\(.{1,10}\))?\)?:?$')
+license_statement_re = re.compile(r'^(This (project|software) is( free 
software)? (released|licen[sc]ed)|(Released|Licen[cs]ed)) under the .{1,10} 
[Ll]icen[sc]e:?$')
 copyright_re = re.compile('^(#+)? *Copyright .*$')
 
 crunched_md5sums = {}
-- 
2.25.0

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

View/Reply Online (#140555): 
https://lists.openembedded.org/g/openembedded-core/message/140555
Mute This Topic: https://lists.openembedded.org/mt/75433146/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] lib/oe/recipeutils.py: add AUTHOR; BBCLASSEXTEND

[Tim Orling]

From: Tim Orling 

If you try to create a plugin for recipetool that
adds the AUTHOR field, it is impossible to put it
in the recommended position [1] without adding to the
recipe_progression variable.

While we are at it, also add BBCLASSEXTEND at the
end, as also recommended by [1].

[1] http://www.openembedded.org/wiki/Styleguide

Signed-off-by: Tim Orling 
---
 meta/lib/oe/recipeutils.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/lib/oe/recipeutils.py b/meta/lib/oe/recipeutils.py
index 29473a98825..36427eec918 100644
--- a/meta/lib/oe/recipeutils.py
+++ b/meta/lib/oe/recipeutils.py
@@ -24,7 +24,7 @@ from collections import OrderedDict, defaultdict
 from bb.utils import vercmp_string
 
 # Help us to find places to insert values
-recipe_progression = ['SUMMARY', 'DESCRIPTION', 'HOMEPAGE', 'BUGTRACKER', 
'SECTION', 'LICENSE', 'LICENSE_FLAGS', 'LIC_FILES_CHKSUM', 'PROVIDES', 
'DEPENDS', 'PR', 'PV', 'SRCREV', 'SRCPV', 'SRC_URI', 'S', 'do_fetch()', 
'do_unpack()', 'do_patch()', 'EXTRA_OECONF', 'EXTRA_OECMAKE', 'EXTRA_OESCONS', 
'do_configure()', 'EXTRA_OEMAKE', 'do_compile()', 'do_install()', 
'do_populate_sysroot()', 'INITSCRIPT', 'USERADD', 'GROUPADD', 'PACKAGES', 
'FILES', 'RDEPENDS', 'RRECOMMENDS', 'RSUGGESTS', 'RPROVIDES', 'RREPLACES', 
'RCONFLICTS', 'ALLOW_EMPTY', 'populate_packages()', 'do_package()', 
'do_deploy()']
+recipe_progression = ['SUMMARY', 'DESCRIPTION', 'AUTHOR', 'HOMEPAGE', 
'BUGTRACKER', 'SECTION', 'LICENSE', 'LICENSE_FLAGS', 'LIC_FILES_CHKSUM', 
'PROVIDES', 'DEPENDS', 'PR', 'PV', 'SRCREV', 'SRCPV', 'SRC_URI', 'S', 
'do_fetch()', 'do_unpack()', 'do_patch()', 'EXTRA_OECONF', 'EXTRA_OECMAKE', 
'EXTRA_OESCONS', 'do_configure()', 'EXTRA_OEMAKE', 'do_compile()', 
'do_install()', 'do_populate_sysroot()', 'INITSCRIPT', 'USERADD', 'GROUPADD', 
'PACKAGES', 'FILES', 'RDEPENDS', 'RRECOMMENDS', 'RSUGGESTS', 'RPROVIDES', 
'RREPLACES', 'RCONFLICTS', 'ALLOW_EMPTY', 'populate_packages()', 
'do_package()', 'do_deploy()', 'BBCLASSEXTEND']
 # Variables that sometimes are a bit long but shouldn't be wrapped
 nowrap_vars = ['SUMMARY', 'HOMEPAGE', 'BUGTRACKER', 
r'SRC_URI\[(.+\.)?md5sum\]', r'SRC_URI\[(.+\.)?sha256sum\]']
 list_vars = ['SRC_URI', 'LIC_FILES_CHKSUM']
-- 
2.25.0

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

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

[OE-core] [PATCH 0/2] recipetool fixes

[Tim Orling]

From: Tim Orling 

During development of a perl module recipetool plugin, some issues with
the existing codebase were uncovered:
(1) It is _impossible_ to add "AUTHOR" in the appropriate location
(2) Several regex patterns are not prepended with r'

The following changes since commit b3c96103a5063eeefb0c537227eab3f77616b9c0:

  libnl: Extend for native/nativesdk (2020-07-08 10:56:11 +0100)

are available in the Git repository at:

  git://git.openembedded.org/openembedded-core-contrib timo/oe-recipetool-fixes
  
http://cgit.openembedded.org/openembedded-core-contrib/log/?h=timo/oe-recipetool-fixes

Tim Orling (2):
  lib/oe/recipeutils.py: add AUTHOR; BBCLASSEXTEND
  scripts/lib/recipetool/create.py: fix regex strings

 meta/lib/oe/recipeutils.py   |  2 +-
 scripts/lib/recipetool/create.py | 10 +-
 2 files changed, 6 insertions(+), 6 deletions(-)

-- 
2.25.0

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

View/Reply Online (#140553): 
https://lists.openembedded.org/g/openembedded-core/message/140553
Mute This Topic: https://lists.openembedded.org/mt/75433144/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 PATCH] devtool: remove _PYTHON_SYSCONFIGDATA_NAME to fix do_unpack

[Taras Kondratiuk via lists.openembedded.org]

On Fri, 2020-07-10 at 22:16 +0100, Richard Purdie wrote:
> On Fri, 2020-07-10 at 22:41 +0200, Alexander Kanavin wrote:
> > I am able to do 'devtool modify gpgme' without any errors. In what
> > setting does it fail for you?
> > 
> > The purpose of _sysconfigdata is to substitute configuration values
> > that are specific for target python when running native python in
> > cross builds with requests from target component build systems to
> > supply those values. For that to work, the recipe also needs to
> > have
> > target python3 in its DEPENDS. It 
> > 
> > I feel the patch is fixing the symptom rather than the issue
> > somehow?
> 
> We've had other patches like this and were playing "whack-a-mole"
> since
> as soon as one merged, an issue appeared somewhere else. In the end I
> stopped taking them and asked the issue be debugged and fixed
> properly.
> There should be more info in the archives about what I
> suggested/asked
> for to move forward with this...

Is this the one you are referring to?
https://lists.yoctoproject.org/g/yocto/topic/74637733#49571

I like Chris' approach. I'll try to look how to make it work with glib
and a few other packages that unset _PYTHON_SYSCONFIGDATA_NAME.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#140552): 
https://lists.openembedded.org/g/openembedded-core/message/140552
Mute This Topic: https://lists.openembedded.org/mt/75425436/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 PATCH] devtool: remove _PYTHON_SYSCONFIGDATA_NAME to fix do_unpack

[Taras Kondratiuk via lists.openembedded.org]

On Sat, 2020-07-11 at 00:41 +0200, Alexander Kanavin wrote:
> On Sat, 11 Jul 2020 at 00:03, Taras Kondratiuk (takondra) <
> takon...@cisco.com> wrote:
> > The only replaced parameters seems to be replaced with wrong
> > values. Also
> > FIXMESTAGINGDIRHOST will point to recipe-sysroot-native which is
> > not
> > target-specific. What am I missing?
> 
> You are comparing with _sysconfigdata from native sysroot. You need
> to take _sysconfigdata from target sysroot, and then you will see
> quite a few arch-specific differences.

Oh, thanks. Now it makes a bit more sense. I didn't realize that
python3native class uses target-specific configuration and target
sysroot. Shouldn't it be called something like python3cross then?

Now need to figure out how to prevent _PYTHON_SYSCONFIGDATA_NAME from
python3native bleeding into other tools.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#140551): 
https://lists.openembedded.org/g/openembedded-core/message/140551
Mute This Topic: https://lists.openembedded.org/mt/75425436/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] openssl: add rdcpu to rand-seed

[Taras Kondratiuk via lists.openembedded.org]

On Fri, 2020-07-10 at 21:21 +0100, Richard Purdie wrote:
> On Fri, 2020-07-10 at 12:39 -0700, Taras Kondratiuk via 
> lists.openembedded.org wrote:
> > Native[sdk] openssl fails to initialize RNG on systems where native[sdk]
> > glibc is built against pre-3.17 linux-libc-headers, but runs on 4.8+
> > kernel:
> > 140737348333184:error:2406C06E:random number 
> > generator:RAND_DRBG_instantiate:error retrieving 
> > entropy:../openssl-1.1.1g/crypto/rand/drbg_lib.c:342
> > 
> > Commit 3ff98f558157 ("Start up DEVRANDOM entropy improvement for older
> > Linux devices.") in OpenSSL 1.1.1d has effectively disabled devrandom
> > seed source for kernels >=4.8. The assumption is that getrandom(2) will
> > be used instead. Getrandom syscall was added in kernel 3.17 by commit
> > c6e9d6f38894 ("random: introduce getrandom(2) system call"). So on a
> > system with 4.8+ kernel and pre-3.17 libc headers both getrandom and
> > devrandom can't be used.
> 
> Where would we find a system where we're building with pre-3.17 libc
> headers?
> 
> We updated to 3.17 in 2014:
> 
> http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=be50d1dc1c03b709e60d2493df5890f7556852b7
> 
> If I remember correctly this change was added to avoid problems with
> different host OSes and I'm worried we'd see those issues return if we
> change things like this. Whilst the syscall may have been added quite
> early, the glibc wrappers for it are quite recent and where our source
> of problems was.

We build OE SDK that has to work on build machines with kernels from
2.6.32 to 5.4. So in our distro nativesdk-linux-libc-headers is set to
2.6.32.

If you think this is a rare case and won't be useful for others, then
ignore the patch. I'll override --with-rand-seed from distro layer.

But then we can remove --with-rand-seed configuration from OE-core
recipe entirely. Its current value "os,devrandom" is equivalent to the
default configuration.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#140550): 
https://lists.openembedded.org/g/openembedded-core/message/140550
Mute This Topic: https://lists.openembedded.org/mt/75426089/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 PATCH] devtool: remove _PYTHON_SYSCONFIGDATA_NAME to fix do_unpack

[Alexander Kanavin]

On Sat, 11 Jul 2020 at 00:03, Taras Kondratiuk (takondra) <
takon...@cisco.com> wrote:

>
> The only replaced parameters seems to be replaced with wrong values. Also
> FIXMESTAGINGDIRHOST will point to recipe-sysroot-native which is not
> target-specific. What am I missing?
>

You are comparing with _sysconfigdata from native sysroot. You need to take
_sysconfigdata from target sysroot, and then you will see quite a few
arch-specific differences.

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

View/Reply Online (#140549): 
https://lists.openembedded.org/g/openembedded-core/message/140549
Mute This Topic: https://lists.openembedded.org/mt/75425436/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] openssl: add rdcpu to rand-seed

[Taras Kondratiuk via lists.openembedded.org]

On Fri, 2020-07-10 at 13:01 -0700, Khem Raj wrote:
> On Fri, Jul 10, 2020 at 12:40 PM Taras Kondratiuk  wrote:
> > Native[sdk] openssl fails to initialize RNG on systems where native[sdk]
> > glibc is built against pre-3.17 linux-libc-headers, but runs on 4.8+
> > kernel:
> > 140737348333184:error:2406C06E:random number 
> > generator:RAND_DRBG_instantiate:error retrieving 
> > entropy:../openssl-1.1.1g/crypto/rand/drbg_lib.c:342
> > 
> > Commit 3ff98f558157 ("Start up DEVRANDOM entropy improvement for older
> > Linux devices.") in OpenSSL 1.1.1d has effectively disabled devrandom
> > seed source for kernels >=4.8. The assumption is that getrandom(2) will
> > be used instead. Getrandom syscall was added in kernel 3.17 by commit
> > c6e9d6f38894 ("random: introduce getrandom(2) system call"). So on a
> > system with 4.8+ kernel and pre-3.17 libc headers both getrandom and
> > devrandom can't be used.
> > 
> > To workaround this issue add 'rdcpu' as additional source of entropy for
> > the rand seed. Also devrandom in the list is no-op since os = getrandom
> > + devrandom on Linux, so remove it. The comment is also not relevant
> > anymore.
> > 
> 
> I think rdcpu will work on x86 hosts but not on say aarch64 build
> hosts. Can we still
> have devrandom as an option if rdcpu fails ?

Devrandom is part of 'os' already, so devrandom will be still used.
Rdcpu will be tried as a fallback only *after* getrandom and devrandom
failed.

Here in rand_pool_acquire_entropy() the order of sources is getrandom,
devrandom and then rdcpu:
https://github.com/openssl/openssl/blob/OpenSSL_1_1_1g/crypto/rand/rand_unix.c#L618
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#140548): 
https://lists.openembedded.org/g/openembedded-core/message/140548
Mute This Topic: https://lists.openembedded.org/mt/75426089/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] openssl: add rdcpu to rand-seed

[Adrian Bunk]

On Fri, Jul 10, 2020 at 09:21:26PM +0100, Richard Purdie wrote:
> On Fri, 2020-07-10 at 12:39 -0700, Taras Kondratiuk via 
> lists.openembedded.org wrote:
> > Native[sdk] openssl fails to initialize RNG on systems where native[sdk]
> > glibc is built against pre-3.17 linux-libc-headers, but runs on 4.8+
> > kernel:
> > 140737348333184:error:2406C06E:random number 
> > generator:RAND_DRBG_instantiate:error retrieving 
> > entropy:../openssl-1.1.1g/crypto/rand/drbg_lib.c:342
> > 
> > Commit 3ff98f558157 ("Start up DEVRANDOM entropy improvement for older
> > Linux devices.") in OpenSSL 1.1.1d has effectively disabled devrandom
> > seed source for kernels >=4.8. The assumption is that getrandom(2) will
> > be used instead. Getrandom syscall was added in kernel 3.17 by commit
> > c6e9d6f38894 ("random: introduce getrandom(2) system call"). So on a
> > system with 4.8+ kernel and pre-3.17 libc headers both getrandom and
> > devrandom can't be used.
> 
> Where would we find a system where we're building with pre-3.17 libc
> headers?
> 
> We updated to 3.17 in 2014:
>...

Native uses the host one.

In Yocto >= 3.1 old host distributions have to use the 
buildtools-extended tarball for unrelated reasons,
which should fix this problem.

Building Yocto <= 3.0 on Debian 8 (3.16 userspace headers) running the 
optional kernel 4.9 would match the reported problem.

Or building Yocto <= 3.0 in a chroot with an older distribution
on a system running a more recent kernel.

> Cheers,
> 
> Richard

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

View/Reply Online (#140547): 
https://lists.openembedded.org/g/openembedded-core/message/140547
Mute This Topic: https://lists.openembedded.org/mt/75426089/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 PATCH] devtool: remove _PYTHON_SYSCONFIGDATA_NAME to fix do_unpack

[Taras Kondratiuk via lists.openembedded.org]

On Fri, 2020-07-10 at 22:41 +0200, Alexander Kanavin wrote:
> I am able to do 'devtool modify gpgme' without any errors. In what
> setting does it fail for you?

Forgot to mention: it is reproducible with host Python 3.6+. The Python
should have the patch that handles _PYTHON_SYSCONFIGDATA_NAME:
https://github.com/python/cpython/commit/92dec548ff14

I'm currently reproducing this on the latest Poky on Ubuntu 20.04 (has
Python 3.8.2). This is also reproducible on previous branches, like
Zeus.

> The purpose of _sysconfigdata is to substitute configuration values
> that are specific for target python when running native python in
> cross builds with requests from target component build systems to
> supply those values. For that to work, the recipe also needs to have
> target python3 in its DEPENDS. It 

What configuration does it aim to replace? When I compare default
_sysconfigdata__linux_x86_64-linux-gnu.py with _sysconfigdata.py, then
I see this:

% diff -u ./usr/lib/python3.8/_sysconfigdata__linux_x86_64-linux-gnu.py 
./usr/lib/python-sysconfigdata/_sysconfigdata.py
--- ./usr/lib/python3.8/_sysconfigdata__linux_x86_64-linux-gnu.py   
2020-07-10 01:33:47.193574344 -0700
+++ ./usr/lib/python-sysconfigdata/_sysconfigdata.py2020-07-10 
01:33:47.197574384 -0700
@@ -577,12 +577,12 @@
  'HAVE_ZLIB_COPY': 1,
  'HAVE__GETPTY': 0,
  'HOST_GNU_TYPE': 'x86_64-pc-linux-gnu',
- 'INCLDIRSTOMAKE': 'FIXMESTAGINGDIRHOST/usr/include '
-   'FIXMESTAGINGDIRHOST/usr/include '
+ 'INCLDIRSTOMAKE': 'FIXMESTAGINGDIRHOSTFIXMESTAGINGDIRHOST/usr/include '
+   'FIXMESTAGINGDIRHOSTFIXMESTAGINGDIRHOST/usr/include '
'FIXMESTAGINGDIRHOST/usr/include/python3.8 '
'FIXMESTAGINGDIRHOST/usr/include/python3.8',
  'INCLUDEDIR': 'FIXMESTAGINGDIRHOST/usr/include',
- 'INCLUDEPY': 'FIXMESTAGINGDIRHOST/usr/include/python3.8',
+ 'INCLUDEPY': 'FIXMESTAGINGDIRHOSTFIXMESTAGINGDIRHOST/usr/include/python3.8',
  'INSTALL': 'FIXME_HOSTTOOLS_DIR/install -c',
  'INSTALL_DATA': 'FIXME_HOSTTOOLS_DIR/install -c -m '
  '644',

The only replaced parameters seems to be replaced with wrong values. Also
FIXMESTAGINGDIRHOST will point to recipe-sysroot-native which is not
target-specific. What am I missing?

> I feel the patch is fixing the symptom rather than the issue somehow

Agree, it is a workaround, hence I've posted it as RFC. Note, there is
similar workaround already merged for PR server 4b26eaf7152f
("prservice.py: fix do_package with newer Python in Ubuntu 20.04").

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

View/Reply Online (#140546): 
https://lists.openembedded.org/g/openembedded-core/message/140546
Mute This Topic: https://lists.openembedded.org/mt/75425436/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 PATCH] devtool: remove _PYTHON_SYSCONFIGDATA_NAME to fix do_unpack

[Richard Purdie]

On Fri, 2020-07-10 at 22:41 +0200, Alexander Kanavin wrote:
> I am able to do 'devtool modify gpgme' without any errors. In what
> setting does it fail for you?
> 
> The purpose of _sysconfigdata is to substitute configuration values
> that are specific for target python when running native python in
> cross builds with requests from target component build systems to
> supply those values. For that to work, the recipe also needs to have
> target python3 in its DEPENDS. It 
> 
> I feel the patch is fixing the symptom rather than the issue somehow?

We've had other patches like this and were playing "whack-a-mole" since
as soon as one merged, an issue appeared somewhere else. In the end I
stopped taking them and asked the issue be debugged and fixed properly.
There should be more info in the archives about what I suggested/asked
for to move forward with this...

Cheers,

Richard

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

View/Reply Online (#140544): 
https://lists.openembedded.org/g/openembedded-core/message/140544
Mute This Topic: https://lists.openembedded.org/mt/75425436/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] How to install individual -lic packages

[Christian Eggers]

Hi Christopher,

Am Donnerstag, 9. Juli 2020, 18:04:00 CEST schrieb Christopher Larson:
> COMPLEMENTARY_GLOB[lic-pkgs] = '*-lic'
> IMAGE_FEATURES += "lic-pkgs"
>
> This is how the dbg-pkgs, dev-pkgs, doc-pkgs, src-pkgs, ptest-pkgs,
> staticdev-pkgs are done.

I think this is not what I require. How can I install -lic packages directly?

I would like to have all necessary -lic packages in my rootfs, so that I
can publish the licenses via a webserver. I need some extra -lic packages
which are not installed automatically because the main package is not
part of the rootfs.

Example 1: My initramfs used dash from klibc. This code is licensed under
BSD-3-Clause, so I need the copyright disclaimer of this package. How
can I add the license of this package to my rootfs?

Example 2: My application depends on libuuid from util-linux. It looks
like the -lic package is not added to RRECOMMENDS_libuuid because
package splitting is done dynamically for util-linux. So I need a way to
install util-linux-lic manually.

regards
Christian





 
[http://assets.arri.com/media/sign/2020-04-03-E-mail-signature-Stellar2_V1.jpg] 


Get all the latest information from www.arri.com, 
Facebook, 
Twitter, Instagram 
and YouTube.

Arnold & Richter Cine Technik GmbH & Co. Betriebs KG
Sitz: München - Registergericht: Amtsgericht München - Handelsregisternummer: 
HRA 57918
Persönlich haftender Gesellschafter: Arnold & Richter Cine Technik GmbH
Sitz: München - Registergericht: Amtsgericht München - Handelsregisternummer: 
HRB 54477
Geschäftsführer: Dr. Michael Neuhäuser; Stephan Schenk; Walter Trauninger; 
Markus Zeiler
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#140545): 
https://lists.openembedded.org/g/openembedded-core/message/140545
Mute This Topic: https://lists.openembedded.org/mt/75394824/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 PATCH] devtool: remove _PYTHON_SYSCONFIGDATA_NAME to fix do_unpack

[Alexander Kanavin]

I am able to do 'devtool modify gpgme' without any errors. In what setting
does it fail for you?

The purpose of _sysconfigdata is to substitute configuration values that
are specific for target python when running native python in cross builds
with requests from target component build systems to supply those values.
For that to work, the recipe also needs to have target python3 in its
DEPENDS. It

I feel the patch is fixing the symptom rather than the issue somehow?


Alex

On Fri, 10 Jul 2020 at 21:08, Taras Kondratiuk  wrote:

> 'devtool modify' fails for packages that inherit python3native (e.g.
> gpgme or systemd, via meson class):
> | Exception: ModuleNotFoundError: No module named '_sysconfigdata'
>
> After commit 02714c105426 ("python3: upgrade to 3.7.2") python3native
> class exports _PYTHON_SYSCONFIGDATA_NAME = '_sysconfigdata'. I think the
> expectation is that it will find
> usr/lib/python-sysconfigdata/_sysconfigdata.py prepared by the same
> commit. But some places seems to still use host python3 which doesn't
> have _sysconfigdata.py. This leads to "No module named '_sysconfigdata'"
> errors. E.g. commit 4b26eaf7152f ("prservice.py: fix do_package with
> newer Python in Ubuntu 20.04") recently tried to workaround it for PR
> service. And now we see similar issue in devtool. To unblock devtool
> apply similar workaround here.
>
> But looks like there is some deeper issue here. I haven't fully grasped
> the purpose of _sysconfigdata.py yet. It is copied from
> _sysconfigdata_m_linux_x86_64-linux-gnu.py and then some variables are
> modified. But new values seems to be wrong. For example:
> In _sysconfigdata_m_linux_x86_64-linux-gnu.py:
> 'INCLUDEPY': 'FIXMESTAGINGDIRHOST/usr/include/python3.7m',
> While in _sysconfigdata.py:
> 'INCLUDEPY':
> 'FIXMESTAGINGDIRHOSTFIXMESTAGINGDIRHOST/usr/include/python3.7m',
>
> When FIXMESTAGINGDIRHOST is replaces by staging.bbclass, the path in
> _sysconfigdata.py points to nowhere while
> _sysconfigdata_m_linux_x86_64-linux-gnu.py has a correct path.
>
> Signed-off-by: Taras Kondratiuk 
> ---
>  meta/classes/devtool-source.bbclass | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/meta/classes/devtool-source.bbclass
> b/meta/classes/devtool-source.bbclass
> index 280d6009f3c2..4a469bfacad7 100644
> --- a/meta/classes/devtool-source.bbclass
> +++ b/meta/classes/devtool-source.bbclass
> @@ -65,6 +65,11 @@ python() {
>
>
>  python devtool_post_unpack() {
> +# Otherwise this fails when called from recipes which e.g. inherit
> +# python3native (which sets _PYTHON_SYSCONFIGDATA_NAME) with: No
> module
> +# named '_sysconfigdata'
> +if '_PYTHON_SYSCONFIGDATA_NAME' in os.environ:
> +del os.environ['_PYTHON_SYSCONFIGDATA_NAME']
>  import oe.recipeutils
>  import shutil
>  sys.path.insert(0, os.path.join(d.getVar('COREBASE'), 'scripts',
> 'lib'))
> --
> 2.25.1
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#140543): 
https://lists.openembedded.org/g/openembedded-core/message/140543
Mute This Topic: https://lists.openembedded.org/mt/75425436/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] qemu: access host pkg-config via HOSTTOOLS

[Alexander Kanavin]

On Fri, 10 Jul 2020 at 21:11, Richard Purdie <
richard.pur...@linuxfoundation.org> wrote:

> Another is that if its using nativesdk-pkgconfig from buildtools, does
> this break the reason we have this code in the first place (to allow
> qemu to use the host GL for virtgl)? Presumably that is not in
> buildtools...
>

I think fall-through to host pkg-config was there to allow usage of host
libsdl? I think you wanted to keep that in as an example of how to do such
a thing, when I previously proposed removal of it.

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

View/Reply Online (#140542): 
https://lists.openembedded.org/g/openembedded-core/message/140542
Mute This Topic: https://lists.openembedded.org/mt/75423722/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] openssl: add rdcpu to rand-seed

[Richard Purdie]

On Fri, 2020-07-10 at 12:39 -0700, Taras Kondratiuk via lists.openembedded.org 
wrote:
> Native[sdk] openssl fails to initialize RNG on systems where native[sdk]
> glibc is built against pre-3.17 linux-libc-headers, but runs on 4.8+
> kernel:
> 140737348333184:error:2406C06E:random number 
> generator:RAND_DRBG_instantiate:error retrieving 
> entropy:../openssl-1.1.1g/crypto/rand/drbg_lib.c:342
> 
> Commit 3ff98f558157 ("Start up DEVRANDOM entropy improvement for older
> Linux devices.") in OpenSSL 1.1.1d has effectively disabled devrandom
> seed source for kernels >=4.8. The assumption is that getrandom(2) will
> be used instead. Getrandom syscall was added in kernel 3.17 by commit
> c6e9d6f38894 ("random: introduce getrandom(2) system call"). So on a
> system with 4.8+ kernel and pre-3.17 libc headers both getrandom and
> devrandom can't be used.

Where would we find a system where we're building with pre-3.17 libc
headers?

We updated to 3.17 in 2014:

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

If I remember correctly this change was added to avoid problems with
different host OSes and I'm worried we'd see those issues return if we
change things like this. Whilst the syscall may have been added quite
early, the glibc wrappers for it are quite recent and where our source
of problems was.

Khem's concerns about this being x86 only also worry me.

Cheers,

Richard
> 

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

View/Reply Online (#140541): 
https://lists.openembedded.org/g/openembedded-core/message/140541
Mute This Topic: https://lists.openembedded.org/mt/75426089/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] openssl: add rdcpu to rand-seed

[Khem Raj]

On Fri, Jul 10, 2020 at 12:40 PM Taras Kondratiuk  wrote:
>
> Native[sdk] openssl fails to initialize RNG on systems where native[sdk]
> glibc is built against pre-3.17 linux-libc-headers, but runs on 4.8+
> kernel:
> 140737348333184:error:2406C06E:random number 
> generator:RAND_DRBG_instantiate:error retrieving 
> entropy:../openssl-1.1.1g/crypto/rand/drbg_lib.c:342
>
> Commit 3ff98f558157 ("Start up DEVRANDOM entropy improvement for older
> Linux devices.") in OpenSSL 1.1.1d has effectively disabled devrandom
> seed source for kernels >=4.8. The assumption is that getrandom(2) will
> be used instead. Getrandom syscall was added in kernel 3.17 by commit
> c6e9d6f38894 ("random: introduce getrandom(2) system call"). So on a
> system with 4.8+ kernel and pre-3.17 libc headers both getrandom and
> devrandom can't be used.
>
> To workaround this issue add 'rdcpu' as additional source of entropy for
> the rand seed. Also devrandom in the list is no-op since os = getrandom
> + devrandom on Linux, so remove it. The comment is also not relevant
> anymore.
>

I think rdcpu will work on x86 hosts but not on say aarch64 build
hosts. Can we still
have devrandom as an option if rdcpu fails ?

> Signed-off-by: Taras Kondratiuk 
> ---
>  meta/recipes-connectivity/openssl/openssl_1.1.1g.bb | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/meta/recipes-connectivity/openssl/openssl_1.1.1g.bb 
> b/meta/recipes-connectivity/openssl/openssl_1.1.1g.bb
> index 47ed6b7640b3..2bf7f56183ce 100644
> --- a/meta/recipes-connectivity/openssl/openssl_1.1.1g.bb
> +++ b/meta/recipes-connectivity/openssl/openssl_1.1.1g.bb
> @@ -43,10 +43,8 @@ do_configure[cleandirs] = "${B}"
>  EXTRA_OECONF_append_libc-musl = " no-async"
>  EXTRA_OECONF_append_libc-musl_powerpc64 = " no-asm"
>
> -# adding devrandom prevents openssl from using getrandom() which is not 
> available on older glibc versions
> -# (native versions can be built with newer glibc, but then relocated onto a 
> system with older glibc)
> -EXTRA_OECONF_class-native = "--with-rand-seed=os,devrandom"
> -EXTRA_OECONF_class-nativesdk = "--with-rand-seed=os,devrandom"
> +EXTRA_OECONF_class-native = "--with-rand-seed=os,rdcpu"
> +EXTRA_OECONF_class-nativesdk = "--with-rand-seed=os,rdcpu"
>
>  # Relying on hardcoded built-in paths causes openssl-native to not be 
> relocateable from sstate.
>  CFLAGS_append_class-native = " -DOPENSSLDIR=/not/builtin 
> -DENGINESDIR=/not/builtin"
> --
> 2.25.1
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#140540): 
https://lists.openembedded.org/g/openembedded-core/message/140540
Mute This Topic: https://lists.openembedded.org/mt/75426089/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: add rdcpu to rand-seed

[Taras Kondratiuk via lists.openembedded.org]

Native[sdk] openssl fails to initialize RNG on systems where native[sdk]
glibc is built against pre-3.17 linux-libc-headers, but runs on 4.8+
kernel:
140737348333184:error:2406C06E:random number 
generator:RAND_DRBG_instantiate:error retrieving 
entropy:../openssl-1.1.1g/crypto/rand/drbg_lib.c:342

Commit 3ff98f558157 ("Start up DEVRANDOM entropy improvement for older
Linux devices.") in OpenSSL 1.1.1d has effectively disabled devrandom
seed source for kernels >=4.8. The assumption is that getrandom(2) will
be used instead. Getrandom syscall was added in kernel 3.17 by commit
c6e9d6f38894 ("random: introduce getrandom(2) system call"). So on a
system with 4.8+ kernel and pre-3.17 libc headers both getrandom and
devrandom can't be used.

To workaround this issue add 'rdcpu' as additional source of entropy for
the rand seed. Also devrandom in the list is no-op since os = getrandom
+ devrandom on Linux, so remove it. The comment is also not relevant
anymore.

Signed-off-by: Taras Kondratiuk 
---
 meta/recipes-connectivity/openssl/openssl_1.1.1g.bb | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/meta/recipes-connectivity/openssl/openssl_1.1.1g.bb 
b/meta/recipes-connectivity/openssl/openssl_1.1.1g.bb
index 47ed6b7640b3..2bf7f56183ce 100644
--- a/meta/recipes-connectivity/openssl/openssl_1.1.1g.bb
+++ b/meta/recipes-connectivity/openssl/openssl_1.1.1g.bb
@@ -43,10 +43,8 @@ do_configure[cleandirs] = "${B}"
 EXTRA_OECONF_append_libc-musl = " no-async"
 EXTRA_OECONF_append_libc-musl_powerpc64 = " no-asm"
 
-# adding devrandom prevents openssl from using getrandom() which is not 
available on older glibc versions
-# (native versions can be built with newer glibc, but then relocated onto a 
system with older glibc)
-EXTRA_OECONF_class-native = "--with-rand-seed=os,devrandom"
-EXTRA_OECONF_class-nativesdk = "--with-rand-seed=os,devrandom"
+EXTRA_OECONF_class-native = "--with-rand-seed=os,rdcpu"
+EXTRA_OECONF_class-nativesdk = "--with-rand-seed=os,rdcpu"
 
 # Relying on hardcoded built-in paths causes openssl-native to not be 
relocateable from sstate.
 CFLAGS_append_class-native = " -DOPENSSLDIR=/not/builtin 
-DENGINESDIR=/not/builtin"
-- 
2.25.1

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

View/Reply Online (#140539): 
https://lists.openembedded.org/g/openembedded-core/message/140539
Mute This Topic: https://lists.openembedded.org/mt/75426089/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] qemu: access host pkg-config via HOSTTOOLS

[Richard Purdie]

On Fri, 2020-07-10 at 18:18 +, Taras Kondratiuk (takondra) wrote:
> On Fri, 2020-07-10 at 18:56 +0100, Richard Purdie wrote:
> > qemu is a little special, its about the only thing we let look into
> > the
> > system for things like this. We really don't want pkg-config
> > available
> > generally in HOSTTOOLS.
> > 
> > I'm not 100% sure I understand how this is fixing things either. Is
> > this using the pkg-config from your buildtools tarball instead?
> > 
> 
> Yes, it is using pkg-config from buildtools tarball.
> 
> As per my understanding other parts of the build will still use
> pkgconfig-native and should not be affected. Or the concern is that
> packages without proper pkgconfig-native dependency will find this
> pkg-config in HOSTTOOLS?

Yes, that is one concern.

Another is that if its using nativesdk-pkgconfig from buildtools, does
this break the reason we have this code in the first place (to allow
qemu to use the host GL for virtgl)? Presumably that is not in
buildtools...

Cheers,

Richard

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

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

Re: [OE-core] [PATCH 1/2] distutils: put tests to ptest package

[Richard Purdie]

On Wed, 2020-07-08 at 20:44 +0200, Konrad Weihmann wrote:
> Put files from installed tests into a ptest package to avoid having
> them in an image and to avoid having more runtime dependencies
> than necessary.
> 
> Signed-off-by: Konrad Weihmann 
> ---
>  meta/classes/distutils-common-base.bbclass | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/meta/classes/distutils-common-base.bbclass 
> b/meta/classes/distutils-common-base.bbclass
> index 94b5fd426d..e3b36574aa 100644
> --- a/meta/classes/distutils-common-base.bbclass
> +++ b/meta/classes/distutils-common-base.bbclass
> @@ -13,8 +13,13 @@ export CCSHARED  = "-fPIC -DPIC"
>  # the python executable
>  export LINKFORSHARED = "{SECURITY_CFLAGS} -Xlinker -export-dynamic"
>  
> +PACKAGES =+ "${@oe.utils.ifelse(bb.data.inherits_class('image', d), '', 
> '${PN}-ptest')}"

We can't do that as for recipes which inherit ptest, we see duplicates
in PACKAGES:

https://errors.yoctoproject.org/Errors/Build/105653/?limit=150

(recipes from meta-oe failing with this change).

Cheers,

Richard

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

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

[OE-core] [RFC PATCH] devtool: remove _PYTHON_SYSCONFIGDATA_NAME to fix do_unpack

[Taras Kondratiuk via lists.openembedded.org]

'devtool modify' fails for packages that inherit python3native (e.g.
gpgme or systemd, via meson class):
| Exception: ModuleNotFoundError: No module named '_sysconfigdata'

After commit 02714c105426 ("python3: upgrade to 3.7.2") python3native
class exports _PYTHON_SYSCONFIGDATA_NAME = '_sysconfigdata'. I think the
expectation is that it will find
usr/lib/python-sysconfigdata/_sysconfigdata.py prepared by the same
commit. But some places seems to still use host python3 which doesn't
have _sysconfigdata.py. This leads to "No module named '_sysconfigdata'"
errors. E.g. commit 4b26eaf7152f ("prservice.py: fix do_package with
newer Python in Ubuntu 20.04") recently tried to workaround it for PR
service. And now we see similar issue in devtool. To unblock devtool
apply similar workaround here.

But looks like there is some deeper issue here. I haven't fully grasped
the purpose of _sysconfigdata.py yet. It is copied from
_sysconfigdata_m_linux_x86_64-linux-gnu.py and then some variables are
modified. But new values seems to be wrong. For example:
In _sysconfigdata_m_linux_x86_64-linux-gnu.py:
'INCLUDEPY': 'FIXMESTAGINGDIRHOST/usr/include/python3.7m',
While in _sysconfigdata.py:
'INCLUDEPY': 'FIXMESTAGINGDIRHOSTFIXMESTAGINGDIRHOST/usr/include/python3.7m',

When FIXMESTAGINGDIRHOST is replaces by staging.bbclass, the path in
_sysconfigdata.py points to nowhere while
_sysconfigdata_m_linux_x86_64-linux-gnu.py has a correct path.

Signed-off-by: Taras Kondratiuk 
---
 meta/classes/devtool-source.bbclass | 5 +
 1 file changed, 5 insertions(+)

diff --git a/meta/classes/devtool-source.bbclass 
b/meta/classes/devtool-source.bbclass
index 280d6009f3c2..4a469bfacad7 100644
--- a/meta/classes/devtool-source.bbclass
+++ b/meta/classes/devtool-source.bbclass
@@ -65,6 +65,11 @@ python() {
 
 
 python devtool_post_unpack() {
+# Otherwise this fails when called from recipes which e.g. inherit
+# python3native (which sets _PYTHON_SYSCONFIGDATA_NAME) with: No module
+# named '_sysconfigdata'
+if '_PYTHON_SYSCONFIGDATA_NAME' in os.environ:
+del os.environ['_PYTHON_SYSCONFIGDATA_NAME']
 import oe.recipeutils
 import shutil
 sys.path.insert(0, os.path.join(d.getVar('COREBASE'), 'scripts', 'lib'))
-- 
2.25.1

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

View/Reply Online (#140536): 
https://lists.openembedded.org/g/openembedded-core/message/140536
Mute This Topic: https://lists.openembedded.org/mt/75425436/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] Wireguard and wg-quick systemd unit location

[Łukasz Dywicki]

Given basic nature of the issue I was able to patch it quickly. It works
as expected. Thank you very much for the pointer.

I am not quite sure which channel is intended for sending patches. Shall
I create bugzilla entry for this one liner?

Cheers,
Łukasz

On 10.07.2020 15:04, Łukasz Dywicki wrote:
> Hi Quentin,
> Indeed that looks like a valid root cause. I been looking on this make
> call for two days and didn't notice the typo. Nice spot!
> 
> I will test patch to see if it helps. Expect patch for review. :-)
> 
> Best,
> Łukasz
> 
> On 10.07.2020 15:01, Quentin Schulz wrote:
>> Hi Łukasz,
>>
>> On Fri, Jul 10, 2020 at 02:11:51PM +0200, Łukasz Dywicki wrote:
>>> Hi all,
>>> I been learning how to run things lately and I think I've found a bug or
>>> at least an unintended trap for new comers.
>>>
>>> I've ran into exactly same issue as described here:
>>> https://stackoverflow.com/questions/54197951/yocto-systemd-service-to-install-a-parameterized-service-service
>>>
>>> After looking on how to work around the problem I also looked why it
>>> given answer fails and why the heck it works for openvpn. The answer is
>>> simple - wireguard leaves wq-quick@.service in /lib/systemd and not in
>>> /lib/systemd/system. The end result is that any service which uses
>>> SYSTEMD_SERVICE_${PN}=wireguard-tools + wg-quick@aaa.service doesn't work.
>>>
>>
>> Can't comment on that, not familiar with systemd and the recipes
>> providing service units.
>>
>>> I've looked at other distros. In ubuntu and arch unit file is
>>> /usr/lib/systemd/system hence it works as expected there. I've checked
>>> rpm spec and unit is placed in invalid place:
>>> %dir "/lib/systemd"
>>> "/lib/systemd/wg-quick@.service"
>>>
>>> I had a look on the wireguard makefile and it seems fine. Can someone
>>> point me where issue comes from and give a tip how to patch this issue?
>>>
>>
>> If the path is the only issue
>> http://cgit.openembedded.org/meta-openembedded/tree/meta-networking/recipes-kernel/wireguard/wireguard-tools_1.0.20200319.bb?h=master#n12
>> should probably be systemd_system_unitdir instead, c.f.:
>> http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/conf/bitbake.conf#n39
>>
>> If this fixes it and there's no better answer in the next days, please
>> send a patch for that :)
>>
>> Thanks,
>>
>> Quentin
>>
>From beaa3dd63269e6f480a1df30d4129031d886c355 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=C5=81ukasz=20Dywicki?= 
Date: Fri, 10 Jul 2020 17:13:55 +0200
Subject: [PATCH] Fix location for wq-quick@.service systemd unit.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

By default systemd looks for units in {etc,lib}/systemd/system.

Signed-off-by: Łukasz Dywicki 
---
 .../recipes-kernel/wireguard/wireguard-tools_0.0.20190123.bb| 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta-networking/recipes-kernel/wireguard/wireguard-tools_0.0.20190123.bb b/meta-networking/recipes-kernel/wireguard/wireguard-tools_0.0.20190123.bb
index c4ddbcb0e..02dc145c0 100644
--- a/meta-networking/recipes-kernel/wireguard/wireguard-tools_0.0.20190123.bb
+++ b/meta-networking/recipes-kernel/wireguard/wireguard-tools_0.0.20190123.bb
@@ -11,7 +11,7 @@ do_compile_prepend () {
 do_install () {
 cd ${S}/tools
 oe_runmake DESTDIR="${D}" PREFIX="${prefix}" SYSCONFDIR="${sysconfdir}" \
-SYSTEMDUNITDIR="${systemd_unitdir}" \
+SYSTEMDUNITDIR="${systemd_system_unitdir}" \
 WITH_SYSTEMDUNITS=${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 'yes', '', d)} \
 WITH_BASHCOMPLETION=yes \
 WITH_WGQUICK=yes \
-- 
2.27.0

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

View/Reply Online (#140535): 
https://lists.openembedded.org/g/openembedded-core/message/140535
Mute This Topic: https://lists.openembedded.org/mt/75416521/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] qemu: access host pkg-config via HOSTTOOLS

[Taras Kondratiuk via lists.openembedded.org]

On Fri, 2020-07-10 at 18:56 +0100, Richard Purdie wrote:
> On Fri, 2020-07-10 at 10:48 -0700, Taras Kondratiuk wrote:
> > On some build hosts qemu-system-native fails to build with errors:
> > like:
> > > build/tmp/work/x86_64-linux/qemu-system-native/4.1.0-r0/qemu-
> > > 4.1.0/qemu-keymap.c:16:10: fatal error: xkbcommon/xkbcommon.h: No
> > > such file or directory
> > >16 | #include 
> > >   |  ^~~
> > > compilation terminated.
> > > make: *** [build/tmp/work/x86_64-linux/qemu-system-native/4.1.0-
> > > r0/qemu-4.1.0/rules.mak:69: qemu-keymap.o] Error 1
> > 
> > This is a combination of two factors:
> > 1. In our setup we use native toolchain from buildtools-tarball
> > because
> >default host GCC on some machines is too old.
> > 2. Qemu recipe adds host pkg-config paths to PKG_CONFIG_PATH using
> >hardcoded pkg-config tool's location (/usr/bin:/bin).  Added by
> >commit 68a5ed337f8f ("qemu: fix qemu-native pkg-config paths")
> > 
> > Host xkbcommon package is detected in configure. But then the
> > toolchain
> > can't find headers because it uses headers from buildtools-tarball
> > only.
> > 
> > Instead of using hardcoded location, use pkg-config via HOSTTOOLS.
> > It
> > will pick up correct pkg-config from PATH and avoid configuration
> > discrepancies.
> > 
> > Signed-off-by: Taras Kondratiuk 
> > ---
> >  meta/conf/bitbake.conf  | 2 +-
> >  meta/recipes-devtools/qemu/qemu.inc | 2 +-
> >  2 files changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
> > index 353caacef986..fae1147d397c 100644
> > --- a/meta/conf/bitbake.conf
> > +++ b/meta/conf/bitbake.conf
> > @@ -488,7 +488,7 @@ HOSTTOOLS += " \
> >  cpp cut date dd diff diffstat dirname du echo egrep env expand
> > expr false \
> >  fgrep file find flock g++ gawk gcc getconf getopt git grep
> > gunzip gzip \
> >  head hostname iconv id install ld ldd ln ls make md5sum mkdir
> > mknod \
> > -mktemp mv nm objcopy objdump od patch perl pr printf pwd \
> > +mktemp mv nm objcopy objdump od patch perl pkg-config pr
> > printf pwd \
> >  python3 ranlib readelf readlink realpath rm rmdir rpcgen sed
> > seq sh \
> >  sha1sum sha224sum sha256sum sha384sum sha512sum \
> >  sleep sort split stat strings strip tail tar tee test touch tr
> > true uname \
> > diff --git a/meta/recipes-devtools/qemu/qemu.inc b/meta/recipes-
> > devtools/qemu/qemu.inc
> > index d41cc8f200b3..881a5ba65025 100644
> > --- a/meta/recipes-devtools/qemu/qemu.inc
> > +++ b/meta/recipes-devtools/qemu/qemu.inc
> > @@ -94,7 +94,7 @@ EXTRA_OECONF_append = " --
> > python=${HOSTTOOLS_DIR}/python3"
> >  
> >  do_configure_prepend_class-native() {
> > # Append build host pkg-config paths for native target since
> > the host may provide sdl
> > -   BHOST_PKGCONFIG_PATH=$(PATH=/usr/bin:/bin pkg-config --variable 
> > pc_path pkg-config || echo "")
> > +   BHOST_PKGCONFIG_PATH=$(${HOSTTOOLS_DIR}/pkg-config --variable
> > pc_path pkg-config || echo "")
> > if [ ! -z "$BHOST_PKGCONFIG_PATH" ]; then
> > export
> > PKG_CONFIG_PATH=$PKG_CONFIG_PATH:$BHOST_PKGCONFIG_PATH
> > fi
> 
> qemu is a little special, its about the only thing we let look into
> the
> system for things like this. We really don't want pkg-config
> available
> generally in HOSTTOOLS.
> 
> I'm not 100% sure I understand how this is fixing things either. Is
> this using the pkg-config from your buildtools tarball instead?
> 

Yes, it is using pkg-config from buildtools tarball.

As per my understanding other parts of the build will still use
pkgconfig-native and should not be affected. Or the concern is that
packages without proper pkgconfig-native dependency will find this
pkg-config in HOSTTOOLS?
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#140533): 
https://lists.openembedded.org/g/openembedded-core/message/140533
Mute This Topic: https://lists.openembedded.org/mt/75423722/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 2/2] kernel-yocto.bbclass: force creation of config.queue

[Pierre-Jean Texier via lists.openembedded.org]

Max, all,

Le 10/07/2020 à 17:52, Max Krummenacher a écrit :

I don't have to test, this was actually my first approach to make the
build succeed. I thought it to be to invasive for all the other use
cases which I do not fully understand.

If you're working on anything that includes the effects of the attached
patch just drop my submission. Thanks for the work.

I put a workaround for this issue in our kernel recipe, so for me there
is no rush to have it fixed in openembedded-core.

Max

If anyone would need the quick and dirty workaround:

+do_kernel_metadata_append () {
+   touch ${S}/.kernel-meta/config.queue
+}


Thanks for this.
I have the same problem on my side (poky master + meta-freescale ->
imx7s-warp) and this one fixes my build issue [1].

[1] - http://51.75.135.20:8080/job/imx7s-warp/104/console
--
Pierre-Jean Texier
Embedded Linux Engineer
https://koncepto.io
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#140534): 
https://lists.openembedded.org/g/openembedded-core/message/140534
Mute This Topic: https://lists.openembedded.org/mt/75414806/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] qemu: access host pkg-config via HOSTTOOLS

[Richard Purdie]

On Fri, 2020-07-10 at 10:48 -0700, Taras Kondratiuk wrote:
> On some build hosts qemu-system-native fails to build with errors:
> like:
> > build/tmp/work/x86_64-linux/qemu-system-native/4.1.0-r0/qemu-4.1.0/qemu-keymap.c:16:10:
> >  fatal error: xkbcommon/xkbcommon.h: No such file or directory
> >16 | #include 
> >   |  ^~~
> > compilation terminated.
> > make: *** 
> > [build/tmp/work/x86_64-linux/qemu-system-native/4.1.0-r0/qemu-4.1.0/rules.mak:69:
> >  qemu-keymap.o] Error 1
> 
> This is a combination of two factors:
> 1. In our setup we use native toolchain from buildtools-tarball because
>default host GCC on some machines is too old.
> 2. Qemu recipe adds host pkg-config paths to PKG_CONFIG_PATH using
>hardcoded pkg-config tool's location (/usr/bin:/bin).  Added by
>commit 68a5ed337f8f ("qemu: fix qemu-native pkg-config paths")
> 
> Host xkbcommon package is detected in configure. But then the toolchain
> can't find headers because it uses headers from buildtools-tarball only.
> 
> Instead of using hardcoded location, use pkg-config via HOSTTOOLS. It
> will pick up correct pkg-config from PATH and avoid configuration
> discrepancies.
> 
> Signed-off-by: Taras Kondratiuk 
> ---
>  meta/conf/bitbake.conf  | 2 +-
>  meta/recipes-devtools/qemu/qemu.inc | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
> index 353caacef986..fae1147d397c 100644
> --- a/meta/conf/bitbake.conf
> +++ b/meta/conf/bitbake.conf
> @@ -488,7 +488,7 @@ HOSTTOOLS += " \
>  cpp cut date dd diff diffstat dirname du echo egrep env expand expr 
> false \
>  fgrep file find flock g++ gawk gcc getconf getopt git grep gunzip gzip \
>  head hostname iconv id install ld ldd ln ls make md5sum mkdir mknod \
> -mktemp mv nm objcopy objdump od patch perl pr printf pwd \
> +mktemp mv nm objcopy objdump od patch perl pkg-config pr printf pwd \
>  python3 ranlib readelf readlink realpath rm rmdir rpcgen sed seq sh \
>  sha1sum sha224sum sha256sum sha384sum sha512sum \
>  sleep sort split stat strings strip tail tar tee test touch tr true 
> uname \
> diff --git a/meta/recipes-devtools/qemu/qemu.inc 
> b/meta/recipes-devtools/qemu/qemu.inc
> index d41cc8f200b3..881a5ba65025 100644
> --- a/meta/recipes-devtools/qemu/qemu.inc
> +++ b/meta/recipes-devtools/qemu/qemu.inc
> @@ -94,7 +94,7 @@ EXTRA_OECONF_append = " --python=${HOSTTOOLS_DIR}/python3"
>  
>  do_configure_prepend_class-native() {
>   # Append build host pkg-config paths for native target since the host 
> may provide sdl
> - BHOST_PKGCONFIG_PATH=$(PATH=/usr/bin:/bin pkg-config --variable pc_path 
> pkg-config || echo "")
> + BHOST_PKGCONFIG_PATH=$(${HOSTTOOLS_DIR}/pkg-config --variable pc_path 
> pkg-config || echo "")
>   if [ ! -z "$BHOST_PKGCONFIG_PATH" ]; then
>   export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:$BHOST_PKGCONFIG_PATH
>   fi

qemu is a little special, its about the only thing we let look into the
system for things like this. We really don't want pkg-config available
generally in HOSTTOOLS.

I'm not 100% sure I understand how this is fixing things either. Is
this using the pkg-config from your buildtools tarball instead?

Cheers,

Richard


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

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

[OE-core] [PATCH] qemu: access host pkg-config via HOSTTOOLS

[Taras Kondratiuk via lists.openembedded.org]

On some build hosts qemu-system-native fails to build with errors:
like:
| 
build/tmp/work/x86_64-linux/qemu-system-native/4.1.0-r0/qemu-4.1.0/qemu-keymap.c:16:10:
 fatal error: xkbcommon/xkbcommon.h: No such file or directory
|16 | #include 
|   |  ^~~
| compilation terminated.
| make: *** 
[build/tmp/work/x86_64-linux/qemu-system-native/4.1.0-r0/qemu-4.1.0/rules.mak:69:
 qemu-keymap.o] Error 1

This is a combination of two factors:
1. In our setup we use native toolchain from buildtools-tarball because
   default host GCC on some machines is too old.
2. Qemu recipe adds host pkg-config paths to PKG_CONFIG_PATH using
   hardcoded pkg-config tool's location (/usr/bin:/bin).  Added by
   commit 68a5ed337f8f ("qemu: fix qemu-native pkg-config paths")

Host xkbcommon package is detected in configure. But then the toolchain
can't find headers because it uses headers from buildtools-tarball only.

Instead of using hardcoded location, use pkg-config via HOSTTOOLS. It
will pick up correct pkg-config from PATH and avoid configuration
discrepancies.

Signed-off-by: Taras Kondratiuk 
---
 meta/conf/bitbake.conf  | 2 +-
 meta/recipes-devtools/qemu/qemu.inc | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 353caacef986..fae1147d397c 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -488,7 +488,7 @@ HOSTTOOLS += " \
 cpp cut date dd diff diffstat dirname du echo egrep env expand expr false \
 fgrep file find flock g++ gawk gcc getconf getopt git grep gunzip gzip \
 head hostname iconv id install ld ldd ln ls make md5sum mkdir mknod \
-mktemp mv nm objcopy objdump od patch perl pr printf pwd \
+mktemp mv nm objcopy objdump od patch perl pkg-config pr printf pwd \
 python3 ranlib readelf readlink realpath rm rmdir rpcgen sed seq sh \
 sha1sum sha224sum sha256sum sha384sum sha512sum \
 sleep sort split stat strings strip tail tar tee test touch tr true uname \
diff --git a/meta/recipes-devtools/qemu/qemu.inc 
b/meta/recipes-devtools/qemu/qemu.inc
index d41cc8f200b3..881a5ba65025 100644
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtools/qemu/qemu.inc
@@ -94,7 +94,7 @@ EXTRA_OECONF_append = " --python=${HOSTTOOLS_DIR}/python3"
 
 do_configure_prepend_class-native() {
# Append build host pkg-config paths for native target since the host 
may provide sdl
-   BHOST_PKGCONFIG_PATH=$(PATH=/usr/bin:/bin pkg-config --variable pc_path 
pkg-config || echo "")
+   BHOST_PKGCONFIG_PATH=$(${HOSTTOOLS_DIR}/pkg-config --variable pc_path 
pkg-config || echo "")
if [ ! -z "$BHOST_PKGCONFIG_PATH" ]; then
export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:$BHOST_PKGCONFIG_PATH
fi
-- 
2.25.1

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

View/Reply Online (#140531): 
https://lists.openembedded.org/g/openembedded-core/message/140531
Mute This Topic: https://lists.openembedded.org/mt/75423722/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] nfs-utils: use rpcgen tool from HOSTTOOLS_DIR

[Taras Kondratiuk via lists.openembedded.org]

nfs-utils configure searches for rpcgen tool only in default locations:
"/usr/local/bin/rpcgen /usr/bin/rpcgen /bin/rpcgen".
On some of our build machines the rpcgen is not present there and
configure fails:
| configure: error: Please install rpcgen or use --with-rpcgen

HOSTTOOLS_DIR already contains a correct pointer to host rpcgen tool, so
use it from there.

Signed-off-by: Taras Kondratiuk 
---
 meta/recipes-connectivity/nfs-utils/nfs-utils_2.5.1.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-connectivity/nfs-utils/nfs-utils_2.5.1.bb 
b/meta/recipes-connectivity/nfs-utils/nfs-utils_2.5.1.bb
index 188a8893b46f..b8ad23a0d814 100644
--- a/meta/recipes-connectivity/nfs-utils/nfs-utils_2.5.1.bb
+++ b/meta/recipes-connectivity/nfs-utils/nfs-utils_2.5.1.bb
@@ -56,6 +56,7 @@ EXTRA_OECONF = "--with-statduser=rpcuser \
 --disable-gss \
 --disable-nfsdcltrack \
 --with-statdpath=/var/lib/nfs/statd \
+--with-rpcgen=${HOSTTOOLS_DIR}/rpcgen \
"
 
 PACKAGECONFIG ??= "tcp-wrappers \
-- 
2.25.1

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

View/Reply Online (#140530): 
https://lists.openembedded.org/g/openembedded-core/message/140530
Mute This Topic: https://lists.openembedded.org/mt/75423578/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] gtk-icon-cache.bbclass: update RDEPENDS

[Martin Jansa]

With this change now in master and dunfell there is signature issue in
allarch adwaita-icon-theme now runtime depending on TUNE_PKGARCH gdk-pixbuf
as shown by sstate-diff-machines.sh/bitbake-diffsigs:

bitbake-diffsigs
tmp-glibc/sstate-diff/1594398219/qemu*/all-webos-linux/adwaita-icon-theme/*do_prepare_recipe_sysroot*
NOTE: Starting bitbake server...
NOTE: Started PRServer with DBfile: cache/prserv.sqlite3, IP: 127.0.0.1,
PORT: 33511, PID: 36423
Hash for dependent task gdk-pixbuf/gdk-pixbuf_2.40.0.bb:do_populate_sysroot
changed from
a72aba8432699c8ce4ca1f71833ef14a89ffde0ea4063e37b9d819fdb1e407f4 to
1ad4e1bd76921b71482657f3b017184e9ade8e2a0b9f43ad64ed2dda83b1520f
Unable to find matching sigdata for
openembedded-core/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.40.0.bb:do_populate_sysroot
with hashes
a72aba8432699c8ce4ca1f71833ef14a89ffde0ea4063e37b9d819fdb1e407f4 or
1ad4e1bd76921b71482657f3b017184e9ade8e2a0b9f43ad64ed2dda83b1520f

On Wed, Jul 1, 2020 at 3:39 AM Changqing Li 
wrote:

>
> On 6/30/20 6:01 PM, Richard Purdie wrote:
> > On Tue, 2020-06-30 at 17:49 +0800, Changqing Li wrote:
> >> From: Changqing Li 
> >>
> >> fix error:
> >> + /usr/lib/gdk-pixbuf-2.0/gdk-pixbuf-query-loaders --update-cache
> >> /var/tmp/rpm-tmp.mdYxY6: line 12: /usr/lib/gdk-pixbuf-2.0/gdk-pixbuf-
> >> query-loaders: No such file or directory
> >> %post(adwaita-icon-theme-3.36.1-r0.0.noarch): waitpid(2961) rc 2961
> >> status 7f00
> >> warning: %post(adwaita-icon-theme-3.36.1-r0.0.noarch) scriptlet
> >> failed, exit status 127
> >>
> >> when install adwaita-icon-theme, which inherit gtk-icon-cache
> >> on target, above error reported,  fix by add needeed packages
> >> in RDEPENDS
> >>
> >> Signed-off-by: Changqing Li 
> >> ---
> >>   meta/classes/gtk-icon-cache.bbclass | 2 ++
> >>   1 file changed, 2 insertions(+)
> >>
> >> diff --git a/meta/classes/gtk-icon-cache.bbclass b/meta/classes/gtk-
> >> icon-cache.bbclass
> >> index 91cb4ad409..7f218ce7ae 100644
> >> --- a/meta/classes/gtk-icon-cache.bbclass
> >> +++ b/meta/classes/gtk-icon-cache.bbclass
> >> @@ -4,6 +4,8 @@ DEPENDS +=" ${@['hicolor-icon-theme', '']['${BPN}' ==
> >> 'hicolor-icon-theme']} gtk
> >>
> >>   PACKAGE_WRITE_DEPS += "gtk+3-native gdk-pixbuf-native"
> >>
> >> +RDEPENDS_${PN} += "gdk-pixbuf gtk+3"
> >> +
> >>   gtk_icon_cache_postinst() {
> >>   if [ "x$D" != "x" ]; then
> >>  $INTERCEPT_DIR/postinst_intercept update_gtk_icon_cache ${PKG}
> >> \
> > This isn't quite right since the postinst may be added to a package
> > other than ${PN}.
> >
> > You need to add the RDEPENDS to the code:
> >
> >  rdepends = ' ' + d.getVar('MLPREFIX', False) +
> "hicolor-icon-theme"
> >  d.appendVar('RDEPENDS_%s' % pkg, rdepends)
> >
> > later in that class.
> >
> > Cheers,
> >
> > Richard
> Thanks, I will correct it.
> >
> 
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#140529): 
https://lists.openembedded.org/g/openembedded-core/message/140529
Mute This Topic: https://lists.openembedded.org/mt/75210651/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] u-boot: Upgrade 2020.04 -> 2020.07

[Alex Kiernan]

On Fri, Jul 10, 2020 at 4:46 PM Quentin Schulz
 wrote:
>
> Hi Alex,
>
> On Fri, Jul 10, 2020 at 03:28:44PM +, Alex Kiernan wrote:
> > Signed-off-by: Alex Kiernan 
> > ---
> >
> >  meta/recipes-bsp/u-boot/u-boot-common.inc   | 2 +-
> >  .../u-boot/{u-boot-tools_2020.04.bb => u-boot-tools_2020.07.bb} | 0
> >  .../recipes-bsp/u-boot/{u-boot_2020.04.bb => u-boot_2020.07.bb} | 0
> >  3 files changed, 1 insertion(+), 1 deletion(-)
> >  rename meta/recipes-bsp/u-boot/{u-boot-tools_2020.04.bb => 
> > u-boot-tools_2020.07.bb} (100%)
> >  rename meta/recipes-bsp/u-boot/{u-boot_2020.04.bb => u-boot_2020.07.bb} 
> > (100%)
> >
> > diff --git a/meta/recipes-bsp/u-boot/u-boot-common.inc 
> > b/meta/recipes-bsp/u-boot/u-boot-common.inc
> > index f4790532b4..abd9786c0a 100644
> > --- a/meta/recipes-bsp/u-boot/u-boot-common.inc
> > +++ b/meta/recipes-bsp/u-boot/u-boot-common.inc
> > @@ -12,7 +12,7 @@ PE = "1"
> >
> >  # We use the revision in order to avoid having to fetch it from the
> >  # repo during parse
> > -SRCREV = "1079ec0a77c3fda510f07860b2549c47f3a46c21"
> > +SRCREV = "aaab5b273781646d417a6775bddd46f90031ee92"
> >
> >  SRC_URI = "git://git.denx.de/u-boot.git \
> >"
> > diff --git a/meta/recipes-bsp/u-boot/u-boot-tools_2020.04.bb 
> > b/meta/recipes-bsp/u-boot/u-boot-tools_2020.07.bb
> > similarity index 100%
> > rename from meta/recipes-bsp/u-boot/u-boot-tools_2020.04.bb
> > rename to meta/recipes-bsp/u-boot/u-boot-tools_2020.07.bb
> > diff --git a/meta/recipes-bsp/u-boot/u-boot_2020.04.bb 
> > b/meta/recipes-bsp/u-boot/u-boot_2020.07.bb
> > similarity index 100%
> > rename from meta/recipes-bsp/u-boot/u-boot_2020.04.bb
> > rename to meta/recipes-bsp/u-boot/u-boot_2020.07.bb
>
> This patch was already sent:
> https://lists.openembedded.org/g/openembedded-core/message/140369?p=,,,20,0,0,0::Created,,u-boot,20,2,0,75342392
>

Sorry, missed it :|

> Though the SRC_REV are different, yours point to the one in the mail I
> linked above.
>

There's the signed tag and the underlying commit - ultimately they're
the same commit.

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

View/Reply Online (#140528): 
https://lists.openembedded.org/g/openembedded-core/message/140528
Mute This Topic: https://lists.openembedded.org/mt/75420556/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 2/2] kernel-yocto.bbclass: force creation of config.queue

[Bruce Ashfield]

On Fri, Jul 10, 2020 at 11:52 AM Max Krummenacher  wrote:
>
> Hi Bruce
>
> Am Freitag, den 10.07.2020, 11:28 -0400 schrieb Bruce Ashfield:
> > On Fri, Jul 10, 2020 at 11:21 AM Bruce Ashfield
> >  wrote:
> > > On Fri, Jul 10, 2020 at 11:12 AM Max Krummenacher  
> > > wrote:
> > > > Hi Bruce, Hi Andrey
> > > >
> > > > Am Freitag, den 10.07.2020, 15:21 +0200 schrieb Andrey Zhizhikin:
> > > > > On Fri, Jul 10, 2020 at 2:47 PM Bruce Ashfield 
> > > > >  wrote:
> > > > > > On Fri, Jul 10, 2020 at 5:06 AM Max Krummenacher 
> > > > > >  wrote:
> > > > > > > In the case of no patches or no configure fragments, during
> > > > > > > do_kernel_metadata() scc is not called, and thus
> > > > > > > kernel-sources/${meta_dir}/config.queue is not created.
> > > > > > > Later do_kernel_configme fails because the file is missing.
> > > > > >
> > > > > > This is a really strange case, since in tree and defconfigs go 
> > > > > > through
> > > > > > the queue.
> > > > > > How are you ending up in this situation in the first place?
> > > >
> > > > I have a kernel recipe with SRC_URI = "git://kernel-git 
> > > > file://defconfig"
> > > > As far as I understand it no configure fragments kick in from anywhere.
> > > > Whith that the above case is what happens, i.e. none of the variables 
> > > > put together to
> > > > form 'elements' have any content.
> > > >
> > > > Notably, $sccs is empty. I.e. if I add some bbwarns after the sccs 
> > > > assignment
> > > >
> > > > sccs="$sccs_from_src_uri"
> > > > bbwarn "sccs " $sccs
> > > > bbwarn "sccs_from_src_uri " $sccs_from_src_uri
> > > > bbwarn "sccs_defconfig " $sccs_defconfig
> > > >
> > > > I get:
> > > >
> > > >WARNING: sccs
> > > >WARNING: sccs_from_src_uri
> > > >WARNING: sccs_defconfig  
> > > > .../recipes-kernel/linux/linux-toradex-4.14-2.3.x/mx8/defconfig
> > > >
> > > > sccs_defconfig has been removed from the variables which form elements 
> > > > in commit
> > > > 23dcff0d396c (oe: e6845327b693) (kernel/yocto: ensure that defconfigs 
> > > > are
> > > > processed first). Was that removal not intended?
> > > > In which of the variables would you expect an out of tree defconfig to 
> > > > end up?
> > >
> > > It goes into the config.queue just like the rest of .scc files.
> > >
> > > The changes I made recently were only to ensure that it was at the
> > > bottom of the queue, so fragments can logically follow and adjust
> > > settings. So no, the defconfig is not removed from the processing, it
> > > has just been order adjusted.
> > >
> > > > I admit I lack the big picture of what kgit, scc and do_kernel_metadata 
> > > > and
> > > > friends really do, I wrote the patch under the impression that without
> > > > configuration fragments or patches one should not run scc here.
> > > >
> > > > > Can this be the same issue that was solved when defconfig is not 
> > > > > in-tree?
> > > > >
> > > > > I guess this could happen only when the list of elements defined as:
> > > > > elements="`echo -n ${bsp_definition} ${sccs} ${patches} 
> > > > > ${KERNEL_FEATURES}`"
> > > > > would contain nothing at all, which means that even a defconfig is 
> > > > > not found...
> > > > >
> > > > > Max,
> > > > > Can you reproduce this issue from the latest master? Fix for searching
> > > > > for OOT defconfig is already merged there (see [1]).
> > > >
> > > > Yes, I can, actually without your patch the build errors out earlier.
> > > > You could reproduce it too if you removed
> > >
> > > I can build here with a defconfig only kernel, so something else is wrong.
> > >
> > > If you can send me (off list) the details of your build (your
> > > bblayers, local.conf settings), I can fire up a build and see what has
> > > gone wrong.
> >
> > Actually, I think I see the hole that this managed to sail through.
> > Can you try the attached patch ?
> >
> > It isn't the final one, since I'm also going to add a message and
> > error if no configuration elements are found, but I wanted to see if
> > this addresses the immediate issue.
>
> I don't have to test, this was actually my first approach to make the
> build succeed. I thought it to be to invasive for all the other use
> cases which I do not fully understand.
>

Aha. And right you were. It always used to be accounted for in that
test, and when I jiggled it, I missed that side effect. *sigh*

There's lots I don't like with the routines, they were written quite a
while ago and have some nasty conventions that I wouldn't use now.
Hence why I'm working on some medium size changes to it .. but there
are so many use cases I risk breaking, the effort is slow :)

> If you're working on anything that includes the effects of the attached
> patch just drop my submission. Thanks for the work.

The report was useful, so thanks for that. I'll clean up my effort and
have it in my next pull request.

Cheers,

Bruce

>
> I put a workaround for this issue in our kernel recipe, so for me there
> is no rush to have it fixed 

Re: [OE-core][Patch 2/2] kernel-yocto.bbclass: force creation of config.queue

[Max Krummenacher]

Hi Bruce

Am Freitag, den 10.07.2020, 11:28 -0400 schrieb Bruce Ashfield:
> On Fri, Jul 10, 2020 at 11:21 AM Bruce Ashfield
>  wrote:
> > On Fri, Jul 10, 2020 at 11:12 AM Max Krummenacher  
> > wrote:
> > > Hi Bruce, Hi Andrey
> > > 
> > > Am Freitag, den 10.07.2020, 15:21 +0200 schrieb Andrey Zhizhikin:
> > > > On Fri, Jul 10, 2020 at 2:47 PM Bruce Ashfield 
> > > >  wrote:
> > > > > On Fri, Jul 10, 2020 at 5:06 AM Max Krummenacher 
> > > > >  wrote:
> > > > > > In the case of no patches or no configure fragments, during
> > > > > > do_kernel_metadata() scc is not called, and thus
> > > > > > kernel-sources/${meta_dir}/config.queue is not created.
> > > > > > Later do_kernel_configme fails because the file is missing.
> > > > > 
> > > > > This is a really strange case, since in tree and defconfigs go through
> > > > > the queue.
> > > > > How are you ending up in this situation in the first place?
> > > 
> > > I have a kernel recipe with SRC_URI = "git://kernel-git file://defconfig"
> > > As far as I understand it no configure fragments kick in from anywhere.
> > > Whith that the above case is what happens, i.e. none of the variables put 
> > > together to
> > > form 'elements' have any content.
> > > 
> > > Notably, $sccs is empty. I.e. if I add some bbwarns after the sccs 
> > > assignment
> > > 
> > > sccs="$sccs_from_src_uri"
> > > bbwarn "sccs " $sccs
> > > bbwarn "sccs_from_src_uri " $sccs_from_src_uri
> > > bbwarn "sccs_defconfig " $sccs_defconfig
> > > 
> > > I get:
> > > 
> > >WARNING: sccs
> > >WARNING: sccs_from_src_uri
> > >WARNING: sccs_defconfig  
> > > .../recipes-kernel/linux/linux-toradex-4.14-2.3.x/mx8/defconfig
> > > 
> > > sccs_defconfig has been removed from the variables which form elements in 
> > > commit
> > > 23dcff0d396c (oe: e6845327b693) (kernel/yocto: ensure that defconfigs are
> > > processed first). Was that removal not intended?
> > > In which of the variables would you expect an out of tree defconfig to 
> > > end up?
> > 
> > It goes into the config.queue just like the rest of .scc files.
> > 
> > The changes I made recently were only to ensure that it was at the
> > bottom of the queue, so fragments can logically follow and adjust
> > settings. So no, the defconfig is not removed from the processing, it
> > has just been order adjusted.
> > 
> > > I admit I lack the big picture of what kgit, scc and do_kernel_metadata 
> > > and
> > > friends really do, I wrote the patch under the impression that without
> > > configuration fragments or patches one should not run scc here.
> > > 
> > > > Can this be the same issue that was solved when defconfig is not 
> > > > in-tree?
> > > > 
> > > > I guess this could happen only when the list of elements defined as:
> > > > elements="`echo -n ${bsp_definition} ${sccs} ${patches} 
> > > > ${KERNEL_FEATURES}`"
> > > > would contain nothing at all, which means that even a defconfig is not 
> > > > found...
> > > > 
> > > > Max,
> > > > Can you reproduce this issue from the latest master? Fix for searching
> > > > for OOT defconfig is already merged there (see [1]).
> > > 
> > > Yes, I can, actually without your patch the build errors out earlier.
> > > You could reproduce it too if you removed
> > 
> > I can build here with a defconfig only kernel, so something else is wrong.
> > 
> > If you can send me (off list) the details of your build (your
> > bblayers, local.conf settings), I can fire up a build and see what has
> > gone wrong.
> 
> Actually, I think I see the hole that this managed to sail through.
> Can you try the attached patch ?
> 
> It isn't the final one, since I'm also going to add a message and
> error if no configuration elements are found, but I wanted to see if
> this addresses the immediate issue.

I don't have to test, this was actually my first approach to make the
build succeed. I thought it to be to invasive for all the other use
cases which I do not fully understand.

If you're working on anything that includes the effects of the attached
patch just drop my submission. Thanks for the work.

I put a workaround for this issue in our kernel recipe, so for me there
is no rush to have it fixed in openembedded-core.

Max

If anyone would need the quick and dirty workaround:

+do_kernel_metadata_append () {
+   touch ${S}/.kernel-meta/config.queue
+}

> 
> I'm actually in the midst of re-working quite a bit of this flow for
> the fall release, so I'm trying to keep changes to a minimum at the
> moment, since they could end up being tossed in the bin shortly.
> 
> Bruce
> 
> > Bruce
> > 
> > > SRC_URI += 
> > > "file://0001-perf-Make-perf-able-to-build-with-latest-libbfd.patch"
> > > from meta-freescale/recipes-kernel/linux/linux-imx_5.4.3.bb and rebuild 
> > > that kernel e.g.
> > > MACHINE=imx8qmmek bitbake virtual/kernel -fc kernel_configme
> > > 
> > > > > I'd rather not force create this, but detect the misconfiguration and
> > > > > output a useful error 

Re: [OE-Core][PATCH] u-boot: Upgrade 2020.04 -> 2020.07

[Quentin Schulz]

Hi Alex,

On Fri, Jul 10, 2020 at 03:28:44PM +, Alex Kiernan wrote:
> Signed-off-by: Alex Kiernan 
> ---
> 
>  meta/recipes-bsp/u-boot/u-boot-common.inc   | 2 +-
>  .../u-boot/{u-boot-tools_2020.04.bb => u-boot-tools_2020.07.bb} | 0
>  .../recipes-bsp/u-boot/{u-boot_2020.04.bb => u-boot_2020.07.bb} | 0
>  3 files changed, 1 insertion(+), 1 deletion(-)
>  rename meta/recipes-bsp/u-boot/{u-boot-tools_2020.04.bb => 
> u-boot-tools_2020.07.bb} (100%)
>  rename meta/recipes-bsp/u-boot/{u-boot_2020.04.bb => u-boot_2020.07.bb} 
> (100%)
> 
> diff --git a/meta/recipes-bsp/u-boot/u-boot-common.inc 
> b/meta/recipes-bsp/u-boot/u-boot-common.inc
> index f4790532b4..abd9786c0a 100644
> --- a/meta/recipes-bsp/u-boot/u-boot-common.inc
> +++ b/meta/recipes-bsp/u-boot/u-boot-common.inc
> @@ -12,7 +12,7 @@ PE = "1"
>  
>  # We use the revision in order to avoid having to fetch it from the
>  # repo during parse
> -SRCREV = "1079ec0a77c3fda510f07860b2549c47f3a46c21"
> +SRCREV = "aaab5b273781646d417a6775bddd46f90031ee92"
>  
>  SRC_URI = "git://git.denx.de/u-boot.git \
>"
> diff --git a/meta/recipes-bsp/u-boot/u-boot-tools_2020.04.bb 
> b/meta/recipes-bsp/u-boot/u-boot-tools_2020.07.bb
> similarity index 100%
> rename from meta/recipes-bsp/u-boot/u-boot-tools_2020.04.bb
> rename to meta/recipes-bsp/u-boot/u-boot-tools_2020.07.bb
> diff --git a/meta/recipes-bsp/u-boot/u-boot_2020.04.bb 
> b/meta/recipes-bsp/u-boot/u-boot_2020.07.bb
> similarity index 100%
> rename from meta/recipes-bsp/u-boot/u-boot_2020.04.bb
> rename to meta/recipes-bsp/u-boot/u-boot_2020.07.bb

This patch was already sent:
https://lists.openembedded.org/g/openembedded-core/message/140369?p=,,,20,0,0,0::Created,,u-boot,20,2,0,75342392

Though the SRC_REV are different, yours point to the one in the mail I
linked above.

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

View/Reply Online (#140525): 
https://lists.openembedded.org/g/openembedded-core/message/140525
Mute This Topic: https://lists.openembedded.org/mt/75420556/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 2/2] kernel-yocto.bbclass: force creation of config.queue

[Bruce Ashfield]

On Fri, Jul 10, 2020 at 11:21 AM Bruce Ashfield
 wrote:
>
> On Fri, Jul 10, 2020 at 11:12 AM Max Krummenacher  
> wrote:
> >
> > Hi Bruce, Hi Andrey
> >
> > Am Freitag, den 10.07.2020, 15:21 +0200 schrieb Andrey Zhizhikin:
> > > On Fri, Jul 10, 2020 at 2:47 PM Bruce Ashfield  
> > > wrote:
> > > > On Fri, Jul 10, 2020 at 5:06 AM Max Krummenacher  
> > > > wrote:
> > > > > In the case of no patches or no configure fragments, during
> > > > > do_kernel_metadata() scc is not called, and thus
> > > > > kernel-sources/${meta_dir}/config.queue is not created.
> > > > > Later do_kernel_configme fails because the file is missing.
> > > >
> > > > This is a really strange case, since in tree and defconfigs go through
> > > > the queue.
> > > > How are you ending up in this situation in the first place?
> >
> > I have a kernel recipe with SRC_URI = "git://kernel-git file://defconfig"
> > As far as I understand it no configure fragments kick in from anywhere.
> > Whith that the above case is what happens, i.e. none of the variables put 
> > together to
> > form 'elements' have any content.
> >
> > Notably, $sccs is empty. I.e. if I add some bbwarns after the sccs 
> > assignment
> >
> > sccs="$sccs_from_src_uri"
> > bbwarn "sccs " $sccs
> > bbwarn "sccs_from_src_uri " $sccs_from_src_uri
> > bbwarn "sccs_defconfig " $sccs_defconfig
> >
> > I get:
> >
> >WARNING: sccs
> >WARNING: sccs_from_src_uri
> >WARNING: sccs_defconfig  
> > .../recipes-kernel/linux/linux-toradex-4.14-2.3.x/mx8/defconfig
> >
> > sccs_defconfig has been removed from the variables which form elements in 
> > commit
> > 23dcff0d396c (oe: e6845327b693) (kernel/yocto: ensure that defconfigs are
> > processed first). Was that removal not intended?
> > In which of the variables would you expect an out of tree defconfig to end 
> > up?
>
> It goes into the config.queue just like the rest of .scc files.
>
> The changes I made recently were only to ensure that it was at the
> bottom of the queue, so fragments can logically follow and adjust
> settings. So no, the defconfig is not removed from the processing, it
> has just been order adjusted.
>
> >
> > I admit I lack the big picture of what kgit, scc and do_kernel_metadata and
> > friends really do, I wrote the patch under the impression that without
> > configuration fragments or patches one should not run scc here.
> >
> > >
> > > Can this be the same issue that was solved when defconfig is not in-tree?
> > >
> > > I guess this could happen only when the list of elements defined as:
> > > elements="`echo -n ${bsp_definition} ${sccs} ${patches} 
> > > ${KERNEL_FEATURES}`"
> > > would contain nothing at all, which means that even a defconfig is not 
> > > found...
> > >
> > > Max,
> > > Can you reproduce this issue from the latest master? Fix for searching
> > > for OOT defconfig is already merged there (see [1]).
> >
> > Yes, I can, actually without your patch the build errors out earlier.
> > You could reproduce it too if you removed
>
> I can build here with a defconfig only kernel, so something else is wrong.
>
> If you can send me (off list) the details of your build (your
> bblayers, local.conf settings), I can fire up a build and see what has
> gone wrong.

Actually, I think I see the hole that this managed to sail through.
Can you try the attached patch ?

It isn't the final one, since I'm also going to add a message and
error if no configuration elements are found, but I wanted to see if
this addresses the immediate issue.

I'm actually in the midst of re-working quite a bit of this flow for
the fall release, so I'm trying to keep changes to a minimum at the
moment, since they could end up being tossed in the bin shortly.

Bruce

>
> Bruce
>
> > SRC_URI += 
> > "file://0001-perf-Make-perf-able-to-build-with-latest-libbfd.patch"
> > from meta-freescale/recipes-kernel/linux/linux-imx_5.4.3.bb and rebuild 
> > that kernel e.g.
> > MACHINE=imx8qmmek bitbake virtual/kernel -fc kernel_configme
> >
> > >
> > > > I'd rather not force create this, but detect the misconfiguration and
> > > > output a useful error message.
> > > >
> > > > Bruce
> >
> > Max
> >
> > > [1]:
> > > http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=7dbc62a672909adce316bb4a8772be0ee9b480fe
> > >
> >
>
>
> --
> - Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end
> - "Use the force Harry" - Gandalf, Star Trek II



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


0001-kernel-yocto-account-for-extracted-defconfig-in-elem.patch
Description: Binary data
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#140523): 
https://lists.openembedded.org/g/openembedded-core/message/140523
Mute This Topic: https://lists.openembedded.org/mt/75414806/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org

[OE-Core][PATCH] u-boot: Upgrade 2020.04 -> 2020.07

[Alex Kiernan]

Signed-off-by: Alex Kiernan 
---

 meta/recipes-bsp/u-boot/u-boot-common.inc   | 2 +-
 .../u-boot/{u-boot-tools_2020.04.bb => u-boot-tools_2020.07.bb} | 0
 .../recipes-bsp/u-boot/{u-boot_2020.04.bb => u-boot_2020.07.bb} | 0
 3 files changed, 1 insertion(+), 1 deletion(-)
 rename meta/recipes-bsp/u-boot/{u-boot-tools_2020.04.bb => 
u-boot-tools_2020.07.bb} (100%)
 rename meta/recipes-bsp/u-boot/{u-boot_2020.04.bb => u-boot_2020.07.bb} (100%)

diff --git a/meta/recipes-bsp/u-boot/u-boot-common.inc 
b/meta/recipes-bsp/u-boot/u-boot-common.inc
index f4790532b4..abd9786c0a 100644
--- a/meta/recipes-bsp/u-boot/u-boot-common.inc
+++ b/meta/recipes-bsp/u-boot/u-boot-common.inc
@@ -12,7 +12,7 @@ PE = "1"
 
 # We use the revision in order to avoid having to fetch it from the
 # repo during parse
-SRCREV = "1079ec0a77c3fda510f07860b2549c47f3a46c21"
+SRCREV = "aaab5b273781646d417a6775bddd46f90031ee92"
 
 SRC_URI = "git://git.denx.de/u-boot.git \
   "
diff --git a/meta/recipes-bsp/u-boot/u-boot-tools_2020.04.bb 
b/meta/recipes-bsp/u-boot/u-boot-tools_2020.07.bb
similarity index 100%
rename from meta/recipes-bsp/u-boot/u-boot-tools_2020.04.bb
rename to meta/recipes-bsp/u-boot/u-boot-tools_2020.07.bb
diff --git a/meta/recipes-bsp/u-boot/u-boot_2020.04.bb 
b/meta/recipes-bsp/u-boot/u-boot_2020.07.bb
similarity index 100%
rename from meta/recipes-bsp/u-boot/u-boot_2020.04.bb
rename to meta/recipes-bsp/u-boot/u-boot_2020.07.bb
-- 
2.17.1

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

View/Reply Online (#140524): 
https://lists.openembedded.org/g/openembedded-core/message/140524
Mute This Topic: https://lists.openembedded.org/mt/75420556/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 2/2] kernel-yocto.bbclass: force creation of config.queue

[Bruce Ashfield]

On Fri, Jul 10, 2020 at 11:12 AM Max Krummenacher  wrote:
>
> Hi Bruce, Hi Andrey
>
> Am Freitag, den 10.07.2020, 15:21 +0200 schrieb Andrey Zhizhikin:
> > On Fri, Jul 10, 2020 at 2:47 PM Bruce Ashfield  
> > wrote:
> > > On Fri, Jul 10, 2020 at 5:06 AM Max Krummenacher  
> > > wrote:
> > > > In the case of no patches or no configure fragments, during
> > > > do_kernel_metadata() scc is not called, and thus
> > > > kernel-sources/${meta_dir}/config.queue is not created.
> > > > Later do_kernel_configme fails because the file is missing.
> > >
> > > This is a really strange case, since in tree and defconfigs go through
> > > the queue.
> > > How are you ending up in this situation in the first place?
>
> I have a kernel recipe with SRC_URI = "git://kernel-git file://defconfig"
> As far as I understand it no configure fragments kick in from anywhere.
> Whith that the above case is what happens, i.e. none of the variables put 
> together to
> form 'elements' have any content.
>
> Notably, $sccs is empty. I.e. if I add some bbwarns after the sccs assignment
>
> sccs="$sccs_from_src_uri"
> bbwarn "sccs " $sccs
> bbwarn "sccs_from_src_uri " $sccs_from_src_uri
> bbwarn "sccs_defconfig " $sccs_defconfig
>
> I get:
>
>WARNING: sccs
>WARNING: sccs_from_src_uri
>WARNING: sccs_defconfig  
> .../recipes-kernel/linux/linux-toradex-4.14-2.3.x/mx8/defconfig
>
> sccs_defconfig has been removed from the variables which form elements in 
> commit
> 23dcff0d396c (oe: e6845327b693) (kernel/yocto: ensure that defconfigs are
> processed first). Was that removal not intended?
> In which of the variables would you expect an out of tree defconfig to end up?

It goes into the config.queue just like the rest of .scc files.

The changes I made recently were only to ensure that it was at the
bottom of the queue, so fragments can logically follow and adjust
settings. So no, the defconfig is not removed from the processing, it
has just been order adjusted.

>
> I admit I lack the big picture of what kgit, scc and do_kernel_metadata and
> friends really do, I wrote the patch under the impression that without
> configuration fragments or patches one should not run scc here.
>
> >
> > Can this be the same issue that was solved when defconfig is not in-tree?
> >
> > I guess this could happen only when the list of elements defined as:
> > elements="`echo -n ${bsp_definition} ${sccs} ${patches} ${KERNEL_FEATURES}`"
> > would contain nothing at all, which means that even a defconfig is not 
> > found...
> >
> > Max,
> > Can you reproduce this issue from the latest master? Fix for searching
> > for OOT defconfig is already merged there (see [1]).
>
> Yes, I can, actually without your patch the build errors out earlier.
> You could reproduce it too if you removed

I can build here with a defconfig only kernel, so something else is wrong.

If you can send me (off list) the details of your build (your
bblayers, local.conf settings), I can fire up a build and see what has
gone wrong.

Bruce

> SRC_URI += 
> "file://0001-perf-Make-perf-able-to-build-with-latest-libbfd.patch"
> from meta-freescale/recipes-kernel/linux/linux-imx_5.4.3.bb and rebuild that 
> kernel e.g.
> MACHINE=imx8qmmek bitbake virtual/kernel -fc kernel_configme
>
> >
> > > I'd rather not force create this, but detect the misconfiguration and
> > > output a useful error message.
> > >
> > > Bruce
>
> Max
>
> > [1]:
> > http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=7dbc62a672909adce316bb4a8772be0ee9b480fe
> >
>


-- 
- 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 (#140522): 
https://lists.openembedded.org/g/openembedded-core/message/140522
Mute This Topic: https://lists.openembedded.org/mt/75414806/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 2/2] kernel-yocto.bbclass: force creation of config.queue

[Max Krummenacher]

Hi Bruce, Hi Andrey

Am Freitag, den 10.07.2020, 15:21 +0200 schrieb Andrey Zhizhikin:
> On Fri, Jul 10, 2020 at 2:47 PM Bruce Ashfield  
> wrote:
> > On Fri, Jul 10, 2020 at 5:06 AM Max Krummenacher  
> > wrote:
> > > In the case of no patches or no configure fragments, during
> > > do_kernel_metadata() scc is not called, and thus
> > > kernel-sources/${meta_dir}/config.queue is not created.
> > > Later do_kernel_configme fails because the file is missing.
> > 
> > This is a really strange case, since in tree and defconfigs go through
> > the queue.
> > How are you ending up in this situation in the first place?

I have a kernel recipe with SRC_URI = "git://kernel-git file://defconfig"
As far as I understand it no configure fragments kick in from anywhere.
Whith that the above case is what happens, i.e. none of the variables put 
together to
form 'elements' have any content.

Notably, $sccs is empty. I.e. if I add some bbwarns after the sccs assignment

sccs="$sccs_from_src_uri"
bbwarn "sccs " $sccs
bbwarn "sccs_from_src_uri " $sccs_from_src_uri
bbwarn "sccs_defconfig " $sccs_defconfig

I get:

   WARNING: sccs 
   WARNING: sccs_from_src_uri 
   WARNING: sccs_defconfig  
.../recipes-kernel/linux/linux-toradex-4.14-2.3.x/mx8/defconfig

sccs_defconfig has been removed from the variables which form elements in commit
23dcff0d396c (oe: e6845327b693) (kernel/yocto: ensure that defconfigs are
processed first). Was that removal not intended?
In which of the variables would you expect an out of tree defconfig to end up?

I admit I lack the big picture of what kgit, scc and do_kernel_metadata and
friends really do, I wrote the patch under the impression that without
configuration fragments or patches one should not run scc here.

> 
> Can this be the same issue that was solved when defconfig is not in-tree?
> 
> I guess this could happen only when the list of elements defined as:
> elements="`echo -n ${bsp_definition} ${sccs} ${patches} ${KERNEL_FEATURES}`"
> would contain nothing at all, which means that even a defconfig is not 
> found...
> 
> Max,
> Can you reproduce this issue from the latest master? Fix for searching
> for OOT defconfig is already merged there (see [1]).

Yes, I can, actually without your patch the build errors out earlier.
You could reproduce it too if you removed
SRC_URI += 
"file://0001-perf-Make-perf-able-to-build-with-latest-libbfd.patch"
from meta-freescale/recipes-kernel/linux/linux-imx_5.4.3.bb and rebuild that 
kernel e.g.
MACHINE=imx8qmmek bitbake virtual/kernel -fc kernel_configme

> 
> > I'd rather not force create this, but detect the misconfiguration and
> > output a useful error message.
> > 
> > Bruce

Max

> [1]: 
> http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=7dbc62a672909adce316bb4a8772be0ee9b480fe
> 

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

View/Reply Online (#140521): 
https://lists.openembedded.org/g/openembedded-core/message/140521
Mute This Topic: https://lists.openembedded.org/mt/75414806/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 2/2] kernel-yocto.bbclass: force creation of config.queue

[Andrey Zhizhikin]

On Fri, Jul 10, 2020 at 2:47 PM Bruce Ashfield  wrote:
>
> On Fri, Jul 10, 2020 at 5:06 AM Max Krummenacher  wrote:
> >
> > In the case of no patches or no configure fragments, during
> > do_kernel_metadata() scc is not called, and thus
> > kernel-sources/${meta_dir}/config.queue is not created.
> > Later do_kernel_configme fails because the file is missing.
>
> This is a really strange case, since in tree and defconfigs go through
> the queue.
>
> How are you ending up in this situation in the first place?

Can this be the same issue that was solved when defconfig is not in-tree?

I guess this could happen only when the list of elements defined as:
elements="`echo -n ${bsp_definition} ${sccs} ${patches} ${KERNEL_FEATURES}`"
would contain nothing at all, which means that even a defconfig is not found...

Max,
Can you reproduce this issue from the latest master? Fix for searching
for OOT defconfig is already merged there (see [1]).

>
> I'd rather not force create this, but detect the misconfiguration and
> output a useful error message.
>
> Bruce
>
> >
> > | ERROR: Execution of 'run.do_kernel_configme.24874' failed with exit code 
> > 1:
> > | exit 1 from 'configs="$(scc --configs -o ${meta_dir})"'
> >
> > Forcing at least an empty config.queue file fixes this.
> >
> > Fixes: 23dcff0d396c (kernel/yocto: ensure that defconfigs are processed 
> > first)
> > Cc: Bruce Ashfield 
> > Signed-off-by: Max Krummenacher 
> > ---
> >  meta/classes/kernel-yocto.bbclass | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/meta/classes/kernel-yocto.bbclass 
> > b/meta/classes/kernel-yocto.bbclass
> > index 7cedb05e93..7ea3cb5e51 100644
> > --- a/meta/classes/kernel-yocto.bbclass
> > +++ b/meta/classes/kernel-yocto.bbclass
> > @@ -220,6 +220,8 @@ do_kernel_metadata() {
> > if [ $? -ne 0 ]; then
> > bbfatal_log "Could not generate configuration queue 
> > for ${KMACHINE}."
> > fi
> > +   else
> > +   touch ${S}/${meta_dir}/config.queue
> > fi
> >
> > # if KMETA_EXTERNAL_BSPS has been set, or it has been detected from
> > --
> > 2.20.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
> 

[1]: 
http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=7dbc62a672909adce316bb4a8772be0ee9b480fe

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

View/Reply Online (#140520): 
https://lists.openembedded.org/g/openembedded-core/message/140520
Mute This Topic: https://lists.openembedded.org/mt/75414806/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] Wireguard and wg-quick systemd unit location

[Łukasz Dywicki]

Hi Quentin,
Indeed that looks like a valid root cause. I been looking on this make
call for two days and didn't notice the typo. Nice spot!

I will test patch to see if it helps. Expect patch for review. :-)

Best,
Łukasz

On 10.07.2020 15:01, Quentin Schulz wrote:
> Hi Łukasz,
> 
> On Fri, Jul 10, 2020 at 02:11:51PM +0200, Łukasz Dywicki wrote:
>> Hi all,
>> I been learning how to run things lately and I think I've found a bug or
>> at least an unintended trap for new comers.
>>
>> I've ran into exactly same issue as described here:
>> https://stackoverflow.com/questions/54197951/yocto-systemd-service-to-install-a-parameterized-service-service
>>
>> After looking on how to work around the problem I also looked why it
>> given answer fails and why the heck it works for openvpn. The answer is
>> simple - wireguard leaves wq-quick@.service in /lib/systemd and not in
>> /lib/systemd/system. The end result is that any service which uses
>> SYSTEMD_SERVICE_${PN}=wireguard-tools + wg-quick@aaa.service doesn't work.
>>
> 
> Can't comment on that, not familiar with systemd and the recipes
> providing service units.
> 
>> I've looked at other distros. In ubuntu and arch unit file is
>> /usr/lib/systemd/system hence it works as expected there. I've checked
>> rpm spec and unit is placed in invalid place:
>> %dir "/lib/systemd"
>> "/lib/systemd/wg-quick@.service"
>>
>> I had a look on the wireguard makefile and it seems fine. Can someone
>> point me where issue comes from and give a tip how to patch this issue?
>>
> 
> If the path is the only issue
> http://cgit.openembedded.org/meta-openembedded/tree/meta-networking/recipes-kernel/wireguard/wireguard-tools_1.0.20200319.bb?h=master#n12
> should probably be systemd_system_unitdir instead, c.f.:
> http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/conf/bitbake.conf#n39
> 
> If this fixes it and there's no better answer in the next days, please
> send a patch for that :)
> 
> Thanks,
> 
> Quentin
> 
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

Re: [OE-core] [poky][master][PATCH] systemd: Fix codesonar warnings

[Paul Barker]

On Fri, 10 Jul 2020 at 12:55, Amitanand N Chikorde
 wrote:
>
> From: "Amitanand.Chikorde" 
>
> Fixed below systemd codesonar warnings.
> 1. isprint() and isspace() is invoked here with an argument of signed
> type char, but only has defined behavior for int arguments that are
> either representable as unsigned char or equal to the value
> of macro EOF(-1).
>
> As per codesonar report, in a number of libc implementations, isprint()
> and isspace() functions implemented using lookup tables (arrays):
> passing in a negative value can result in a read underrun.
>
> To avoid this unexpected behaviour, typecasted char type argument to
> unsigned char type.
>
> 2. "seqnum" defined, not initialized & used in device-private.c
> Intialized "seqnum" at definition.
>
> Upstream-Status: Pending
> Signed-off-by: Amitanand.Chikorde 
> ---
>  .../files/systemd_codesonar_warnings_fix.patch  | 105 
> 
>  5 files changed, 9 insertions(+), 9 deletions(-)
>  create mode 100644 files/systemd_codesonar_warnings_fix.patch
>
> diff --git a/files/systemd_codesonar_warnings_fix.patch 
> b/files/systemd_codesonar_warnings_fix.patch
> new file mode 100644
> index 000..8138eba
> --- /dev/null
> +++ b/files/systemd_codesonar_warnings_fix.patch
> @@ -0,0 +1,105 @@
> +systemd: fix codesonar warnings
> +
> +Fixed below systemd codesonar warnings.
> +1. isprint() and isspace() is invoked here with an argument of signed
> +type char, but only has defined behavior for int arguments that are
> +either representable as unsigned char or equal to the value
> +of macro EOF(-1).
> +
> +As per codesonar report, in a number of libc implementations, isprint()
> +and isspace() functions implemented using lookup tables (arrays):
> +passing in a negative value can result in a read underrun.
> +
> +To avoid this unexpected behaviour, typecasted char type argument to
> +unsigned char type.
> +
> +2. "seqnum" defined, not initialized & used in device-private.c
> +Intialized "seqnum" at definition.
> +
> +Signed-off-by: Amitanand N. Chikorde 
> +Upstream-Status: Pending
> +
> +--- origcode/src/libsystemd/sd-device/device-private.c 2020-07-09 
> 18:05:13.744127907 +0530
>  modifcode/src/libsystemd/sd-device/device-private.c2020-07-09 
> 18:01:56.494621945 +0530
> +@@ -560,7 +560,7 @@
> + char **key;
> + const char *major = NULL, *minor = NULL;
> + DeviceAction action = _DEVICE_ACTION_INVALID;
> +-uint64_t seqnum;
> ++uint64_t seqnum = 0;
> + int r;
> +
> + assert(ret);
> +--- origcode/src/libudev/libudev-util.c2020-07-09 18:05:13.656049515 
> +0530
>  modifcode/src/libudev/libudev-util.c   2020-07-09 18:02:32.563386414 
> +0530
> +@@ -171,7 +171,7 @@
> +
> + /* strip trailing whitespace */
> + len = strnlen(str, len);
> +-while (len && isspace(str[len-1]))
> ++while (len && isspace((unsigned char) str[len-1]))
> + len--;
> +
> + /* strip leading whitespace */
> +@@ -182,8 +182,8 @@
> + j = 0;
> + while (i < len) {
> + /* substitute multiple whitespace with a single '_' */
> +-if (isspace(str[i])) {
> +-while (isspace(str[i]))
> ++if (isspace((unsigned char) str[i])) {
> ++while (isspace((unsigned char) str[i]))
> + i++;
> + to[j++] = '_';
> + }
> +--- origcode/src/udev/udevadm-hwdb.c   2020-07-09 18:05:13.612010318 +0530
>  modifcode/src/udev/udevadm-hwdb.c  2020-07-09 18:03:26.243530163 +0530
> +@@ -487,7 +487,7 @@
> +
> + /* strip trailing whitespace */
> + len = strlen(line);
> +-while (len > 0 && isspace(line[len-1]))
> ++while (len > 0 && isspace((unsigned char) line[len-1]))
> + len--;
> + line[len] = '\0';
> +
> +--- origcode/src/udev/udevadm-info.c   2020-07-09 18:05:13.616013882 +0530
>  modifcode/src/udev/udevadm-info.c  2020-07-09 18:03:41.621625782 +0530
> +@@ -73,7 +73,7 @@
> +
> + /* skip nonprintable attributes */
> + len = strlen(value);
> +-while (len > 0 && isprint(value[len-1]))
> ++while (len > 0 && isprint((unsigned char) value[len-1]))
> + len--;
> + if (len > 0)
> + continue;
> +--- origcode/src/udev/udev-rules.c 2020-07-09 18:05:13.624021008 +0530
>  modifcode/src/udev/udev-rules.c2020-07-09 18:03:03.227995790 +0530
> +@@ -726,7 +726,7 @@
> + return -1;
> +
> + /* skip whitespace */
> +-while (isspace(linepos[0]) || linepos[0] == ',')
> ++while (isspace((unsigned char) linepos[0]) || linepos[0] == ',')
> + linepos++;
> +
> + /* get the key */
> +@@ -738,7 +738,7 @@
> +

Re: [OE-core] Wireguard and wg-quick systemd unit location

[Quentin Schulz]

Hi Łukasz,

On Fri, Jul 10, 2020 at 02:11:51PM +0200, Łukasz Dywicki wrote:
> Hi all,
> I been learning how to run things lately and I think I've found a bug or
> at least an unintended trap for new comers.
> 
> I've ran into exactly same issue as described here:
> https://stackoverflow.com/questions/54197951/yocto-systemd-service-to-install-a-parameterized-service-service
> 
> After looking on how to work around the problem I also looked why it
> given answer fails and why the heck it works for openvpn. The answer is
> simple - wireguard leaves wq-quick@.service in /lib/systemd and not in
> /lib/systemd/system. The end result is that any service which uses
> SYSTEMD_SERVICE_${PN}=wireguard-tools + wg-quick@aaa.service doesn't work.
> 

Can't comment on that, not familiar with systemd and the recipes
providing service units.

> I've looked at other distros. In ubuntu and arch unit file is
> /usr/lib/systemd/system hence it works as expected there. I've checked
> rpm spec and unit is placed in invalid place:
> %dir "/lib/systemd"
> "/lib/systemd/wg-quick@.service"
> 
> I had a look on the wireguard makefile and it seems fine. Can someone
> point me where issue comes from and give a tip how to patch this issue?
> 

If the path is the only issue
http://cgit.openembedded.org/meta-openembedded/tree/meta-networking/recipes-kernel/wireguard/wireguard-tools_1.0.20200319.bb?h=master#n12
should probably be systemd_system_unitdir instead, c.f.:
http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/conf/bitbake.conf#n39

If this fixes it and there's no better answer in the next days, please
send a patch for that :)

Thanks,

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

View/Reply Online (#140517): 
https://lists.openembedded.org/g/openembedded-core/message/140517
Mute This Topic: https://lists.openembedded.org/mt/75416521/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 2/2] kernel-yocto.bbclass: force creation of config.queue

[Bruce Ashfield]

On Fri, Jul 10, 2020 at 5:06 AM Max Krummenacher  wrote:
>
> In the case of no patches or no configure fragments, during
> do_kernel_metadata() scc is not called, and thus
> kernel-sources/${meta_dir}/config.queue is not created.
> Later do_kernel_configme fails because the file is missing.

This is a really strange case, since in tree and defconfigs go through
the queue.

How are you ending up in this situation in the first place?

I'd rather not force create this, but detect the misconfiguration and
output a useful error message.

Bruce

>
> | ERROR: Execution of 'run.do_kernel_configme.24874' failed with exit code 1:
> | exit 1 from 'configs="$(scc --configs -o ${meta_dir})"'
>
> Forcing at least an empty config.queue file fixes this.
>
> Fixes: 23dcff0d396c (kernel/yocto: ensure that defconfigs are processed first)
> Cc: Bruce Ashfield 
> Signed-off-by: Max Krummenacher 
> ---
>  meta/classes/kernel-yocto.bbclass | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/meta/classes/kernel-yocto.bbclass 
> b/meta/classes/kernel-yocto.bbclass
> index 7cedb05e93..7ea3cb5e51 100644
> --- a/meta/classes/kernel-yocto.bbclass
> +++ b/meta/classes/kernel-yocto.bbclass
> @@ -220,6 +220,8 @@ do_kernel_metadata() {
> if [ $? -ne 0 ]; then
> bbfatal_log "Could not generate configuration queue 
> for ${KMACHINE}."
> fi
> +   else
> +   touch ${S}/${meta_dir}/config.queue
> fi
>
> # if KMETA_EXTERNAL_BSPS has been set, or it has been detected from
> --
> 2.20.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 (#140516): 
https://lists.openembedded.org/g/openembedded-core/message/140516
Mute This Topic: https://lists.openembedded.org/mt/75414806/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] Wireguard and wg-quick systemd unit location

[Łukasz Dywicki]

Hi all,
I been learning how to run things lately and I think I've found a bug or
at least an unintended trap for new comers.

I've ran into exactly same issue as described here:
https://stackoverflow.com/questions/54197951/yocto-systemd-service-to-install-a-parameterized-service-service

After looking on how to work around the problem I also looked why it
given answer fails and why the heck it works for openvpn. The answer is
simple - wireguard leaves wq-quick@.service in /lib/systemd and not in
/lib/systemd/system. The end result is that any service which uses
SYSTEMD_SERVICE_${PN}=wireguard-tools + wg-quick@aaa.service doesn't work.

I've looked at other distros. In ubuntu and arch unit file is
/usr/lib/systemd/system hence it works as expected there. I've checked
rpm spec and unit is placed in invalid place:
%dir "/lib/systemd"
"/lib/systemd/wg-quick@.service"

I had a look on the wireguard makefile and it seems fine. Can someone
point me where issue comes from and give a tip how to patch this issue?

Kind regards,
Łukasz
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

[OE-core] [poky][master][PATCH] systemd: Fix codesonar warnings

[Amitanand N Chikorde]

From: "Amitanand.Chikorde" 

Fixed below systemd codesonar warnings.
1. isprint() and isspace() is invoked here with an argument of signed
type char, but only has defined behavior for int arguments that are
either representable as unsigned char or equal to the value
of macro EOF(-1).

As per codesonar report, in a number of libc implementations, isprint()
and isspace() functions implemented using lookup tables (arrays):
passing in a negative value can result in a read underrun.

To avoid this unexpected behaviour, typecasted char type argument to
unsigned char type.

2. "seqnum" defined, not initialized & used in device-private.c
Intialized "seqnum" at definition.

Upstream-Status: Pending
Signed-off-by: Amitanand.Chikorde 
---
 .../files/systemd_codesonar_warnings_fix.patch  | 105 
 5 files changed, 9 insertions(+), 9 deletions(-)
 create mode 100644 files/systemd_codesonar_warnings_fix.patch

diff --git a/files/systemd_codesonar_warnings_fix.patch 
b/files/systemd_codesonar_warnings_fix.patch
new file mode 100644
index 000..8138eba
--- /dev/null
+++ b/files/systemd_codesonar_warnings_fix.patch
@@ -0,0 +1,105 @@
+systemd: fix codesonar warnings
+
+Fixed below systemd codesonar warnings.
+1. isprint() and isspace() is invoked here with an argument of signed
+type char, but only has defined behavior for int arguments that are
+either representable as unsigned char or equal to the value
+of macro EOF(-1).
+
+As per codesonar report, in a number of libc implementations, isprint()
+and isspace() functions implemented using lookup tables (arrays):
+passing in a negative value can result in a read underrun.
+
+To avoid this unexpected behaviour, typecasted char type argument to
+unsigned char type.
+
+2. "seqnum" defined, not initialized & used in device-private.c
+Intialized "seqnum" at definition.
+
+Signed-off-by: Amitanand N. Chikorde 
+Upstream-Status: Pending
+
+--- origcode/src/libsystemd/sd-device/device-private.c 2020-07-09 
18:05:13.744127907 +0530
 modifcode/src/libsystemd/sd-device/device-private.c2020-07-09 
18:01:56.494621945 +0530
+@@ -560,7 +560,7 @@
+ char **key;
+ const char *major = NULL, *minor = NULL;
+ DeviceAction action = _DEVICE_ACTION_INVALID;
+-uint64_t seqnum;
++uint64_t seqnum = 0;
+ int r;
+
+ assert(ret);
+--- origcode/src/libudev/libudev-util.c2020-07-09 18:05:13.656049515 
+0530
 modifcode/src/libudev/libudev-util.c   2020-07-09 18:02:32.563386414 
+0530
+@@ -171,7 +171,7 @@
+
+ /* strip trailing whitespace */
+ len = strnlen(str, len);
+-while (len && isspace(str[len-1]))
++while (len && isspace((unsigned char) str[len-1]))
+ len--;
+
+ /* strip leading whitespace */
+@@ -182,8 +182,8 @@
+ j = 0;
+ while (i < len) {
+ /* substitute multiple whitespace with a single '_' */
+-if (isspace(str[i])) {
+-while (isspace(str[i]))
++if (isspace((unsigned char) str[i])) {
++while (isspace((unsigned char) str[i]))
+ i++;
+ to[j++] = '_';
+ }
+--- origcode/src/udev/udevadm-hwdb.c   2020-07-09 18:05:13.612010318 +0530
 modifcode/src/udev/udevadm-hwdb.c  2020-07-09 18:03:26.243530163 +0530
+@@ -487,7 +487,7 @@
+
+ /* strip trailing whitespace */
+ len = strlen(line);
+-while (len > 0 && isspace(line[len-1]))
++while (len > 0 && isspace((unsigned char) line[len-1]))
+ len--;
+ line[len] = '\0';
+
+--- origcode/src/udev/udevadm-info.c   2020-07-09 18:05:13.616013882 +0530
 modifcode/src/udev/udevadm-info.c  2020-07-09 18:03:41.621625782 +0530
+@@ -73,7 +73,7 @@
+
+ /* skip nonprintable attributes */
+ len = strlen(value);
+-while (len > 0 && isprint(value[len-1]))
++while (len > 0 && isprint((unsigned char) value[len-1]))
+ len--;
+ if (len > 0)
+ continue;
+--- origcode/src/udev/udev-rules.c 2020-07-09 18:05:13.624021008 +0530
 modifcode/src/udev/udev-rules.c2020-07-09 18:03:03.227995790 +0530
+@@ -726,7 +726,7 @@
+ return -1;
+
+ /* skip whitespace */
+-while (isspace(linepos[0]) || linepos[0] == ',')
++while (isspace((unsigned char) linepos[0]) || linepos[0] == ',')
+ linepos++;
+
+ /* get the key */
+@@ -738,7 +738,7 @@
+ linepos++;
+ if (linepos[0] == '\0')
+ return -1;
+-if (isspace(linepos[0]))
++if (isspace((unsigned char) linepos[0]))
+ break;
+ if (linepos[0] == '=')
+ break;
+@@ 

[OE-core] [PATCH V4] dpkg: change SRC_URI to take dpkg from git

[Changqing Li]

From: Changqing Li 

tar.xz on original URL have been removed, switch to use git

Signed-off-by: Changqing Li 
---
 meta/recipes-devtools/dpkg/dpkg.inc   | 14 +-
 meta/recipes-devtools/dpkg/dpkg_1.20.0.bb |  7 ---
 2 files changed, 17 insertions(+), 4 deletions(-)

diff --git a/meta/recipes-devtools/dpkg/dpkg.inc 
b/meta/recipes-devtools/dpkg/dpkg.inc
index 1c3c585d79..04fe85c4a8 100644
--- a/meta/recipes-devtools/dpkg/dpkg.inc
+++ b/meta/recipes-devtools/dpkg/dpkg.inc
@@ -7,7 +7,7 @@ DEPENDS_class-native = "bzip2-replacement-native zlib-native 
virtual/update-alte
 RDEPENDS_${PN} = "${VIRTUAL-RUNTIME_update-alternatives} perl"
 RDEPENDS_${PN}_class-native = ""
 
-UPSTREAM_CHECK_URI = "${DEBIAN_MIRROR}/main/d/dpkg/"
+UPSTREAM_CHECK_GITTAGREGEX = "(?P(\d+(\.\d+)+))"
 
 inherit autotools gettext perlnative pkgconfig perl-version update-alternatives
 
@@ -30,6 +30,18 @@ EXTRA_OECONF_append_class-target = " 
--disable-update-alternatives DEB_HOST_ARCH
 PACKAGECONFIG = "liblzma"
 PACKAGECONFIG[liblzma] = "--with-liblzma,--without-liblzma, xz"
 
+
+#autotools.bbclass default AUTOTOOLS_AUXDIR is ${S}, we need to under 
${S}/build-aux
+AUTOTOOLS_AUXDIR = "${S}/build-aux"
+
+do_configure_prepend () {
+mkdir -p ${AUTOTOOLS_AUXDIR}
+# autotools_do_configure updates po/Makefile.in.in, we also need
+# update dselect/po and scripts/po
+cp -f ${STAGING_DATADIR_NATIVE}/gettext/po/Makefile.in.in 
${S}/dselect/po/
+cp -f ${STAGING_DATADIR_NATIVE}/gettext/po/Makefile.in.in 
${S}/scripts/po/
+}
+
 do_install_append () {
if [ "${PN}" = "dpkg-native" ]; then
# update-alternatives doesn't have an offline mode
diff --git a/meta/recipes-devtools/dpkg/dpkg_1.20.0.bb 
b/meta/recipes-devtools/dpkg/dpkg_1.20.0.bb
index c98a9e58e2..334294e6f8 100644
--- a/meta/recipes-devtools/dpkg/dpkg_1.20.0.bb
+++ b/meta/recipes-devtools/dpkg/dpkg_1.20.0.bb
@@ -1,7 +1,7 @@
 require dpkg.inc
 LIC_FILES_CHKSUM = "file://COPYING;md5=751419260aa954499f7abaabaa882bbe"
 
-SRC_URI = "${DEBIAN_MIRROR}/main/d/${BPN}/${BPN}_${PV}.tar.xz \
+SRC_URI = "git://salsa.debian.org/dpkg-team/dpkg.git;protocol=https \
file://noman.patch \
file://remove-tar-no-timestamp.patch \
file://arch_pm.patch \
@@ -18,5 +18,6 @@ SRC_URI = "${DEBIAN_MIRROR}/main/d/${BPN}/${BPN}_${PV}.tar.xz 
\
 
 SRC_URI_append_class-native = " 
file://0001-build.c-ignore-return-of-1-from-tar-cf.patch"
 
-SRC_URI[md5sum] = "f88f077236a3ff3decae3b25c989893d"
-SRC_URI[sha256sum] = 
"b633cc2b0e030efb61e11029d8a3fb1123f719864c9992da2e52b471c96d0900"
+SRCREV = "314ac02663c5bd1a82b34745150bf13a39a549a3"
+
+S = "${WORKDIR}/git"
-- 
2.17.1

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

View/Reply Online (#140513): 
https://lists.openembedded.org/g/openembedded-core/message/140513
Mute This Topic: https://lists.openembedded.org/mt/75414984/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] kernel-yocto.bbclass: force creation of config.queue

[Max Krummenacher]

In the case of no patches or no configure fragments, during
do_kernel_metadata() scc is not called, and thus
kernel-sources/${meta_dir}/config.queue is not created.
Later do_kernel_configme fails because the file is missing.

| ERROR: Execution of 'run.do_kernel_configme.24874' failed with exit code 1:
| exit 1 from 'configs="$(scc --configs -o ${meta_dir})"'

Forcing at least an empty config.queue file fixes this.

Fixes: 23dcff0d396c (kernel/yocto: ensure that defconfigs are processed first)
Cc: Bruce Ashfield 
Signed-off-by: Max Krummenacher 
---
 meta/classes/kernel-yocto.bbclass | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/classes/kernel-yocto.bbclass 
b/meta/classes/kernel-yocto.bbclass
index 7cedb05e93..7ea3cb5e51 100644
--- a/meta/classes/kernel-yocto.bbclass
+++ b/meta/classes/kernel-yocto.bbclass
@@ -220,6 +220,8 @@ do_kernel_metadata() {
if [ $? -ne 0 ]; then
bbfatal_log "Could not generate configuration queue for 
${KMACHINE}."
fi
+   else
+   touch ${S}/${meta_dir}/config.queue
fi
 
# if KMETA_EXTERNAL_BSPS has been set, or it has been detected from
-- 
2.20.1

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

View/Reply Online (#140512): 
https://lists.openembedded.org/g/openembedded-core/message/140512
Mute This Topic: https://lists.openembedded.org/mt/75414806/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] kernel-yocto.bbclass: set +e in do_configme

[Max Krummenacher]

The script test the error code to give usefull debug output.
Aborting right after the failing process prevents that output.

This partly reverts commit ec281a948a ("kernel-yocto.bbclass:
do_kernel_configme: don't use +errexit, merge_config_build.log
and fail when /.config wasn't created")

Cc: Martin Jansa 
Signed-off-by: Max Krummenacher 
---
 meta/classes/kernel-yocto.bbclass | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/classes/kernel-yocto.bbclass 
b/meta/classes/kernel-yocto.bbclass
index 54a1a1627a..7cedb05e93 100644
--- a/meta/classes/kernel-yocto.bbclass
+++ b/meta/classes/kernel-yocto.bbclass
@@ -338,6 +338,7 @@ do_kernel_configme[depends] += 
"bc-native:do_populate_sysroot bison-native:do_po
 do_kernel_configme[depends] += "kern-tools-native:do_populate_sysroot"
 do_kernel_configme[dirs] += "${S} ${B}"
 do_kernel_configme() {
+   set +e
# translate the kconfig_mode into something that merge_config.sh
# understands
case ${KCONFIG_MODE} in
-- 
2.20.1

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

View/Reply Online (#140511): 
https://lists.openembedded.org/g/openembedded-core/message/140511
Mute This Topic: https://lists.openembedded.org/mt/75414802/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] linux-firmware: move ibt-misc to the end of ibt packages

[Yongxin Liu]

After commit 3ca1d3fa1d ("linux-firmware: fix the wrong file
path for ibt-misc"), if we don't change the location of ibt-misc
in PACKAGES, ibt-misc will include all ibt files and make other
individual ibt package empty.

Signed-off-by: Yongxin Liu 
---
 meta/recipes-kernel/linux-firmware/linux-firmware_20200619.bb | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-kernel/linux-firmware/linux-firmware_20200619.bb 
b/meta/recipes-kernel/linux-firmware/linux-firmware_20200619.bb
index 79acccddc7..2b5963c0c8 100644
--- a/meta/recipes-kernel/linux-firmware/linux-firmware_20200619.bb
+++ b/meta/recipes-kernel/linux-firmware/linux-firmware_20200619.bb
@@ -278,9 +278,10 @@ PACKAGES =+ "${PN}-ralink-license ${PN}-ralink \
  ${PN}-iwlwifi-7265d ${PN}-iwlwifi-8000c ${PN}-iwlwifi-8265 \
  ${PN}-iwlwifi-9000 \
  ${PN}-iwlwifi-misc \
- ${PN}-ibt-license ${PN}-ibt ${PN}-ibt-misc \
+ ${PN}-ibt-license ${PN}-ibt \
  ${PN}-ibt-11-5 ${PN}-ibt-12-16 ${PN}-ibt-hw-37-7 
${PN}-ibt-hw-37-8 \
  ${PN}-ibt-17 \
+ ${PN}-ibt-misc \
  ${PN}-i915-license ${PN}-i915 \
  ${PN}-ice-license ${PN}-ice \
  ${PN}-adsp-sst-license ${PN}-adsp-sst \
-- 
2.14.4

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

View/Reply Online (#140510): 
https://lists.openembedded.org/g/openembedded-core/message/140510
Mute This Topic: https://lists.openembedded.org/mt/75414697/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 v3] netbase: use git fetcher

[Yu, Mingli]

Please ignore this patch.

Thanks,

On 7/10/20 3:01 PM, Yu, Mingli wrote:

From: Mingli Yu 

Use git repo as the the previous URL only stores the latest
source file and fails to locate the source tar file if we
don't upgrade timely.
---
  meta/recipes-core/netbase/netbase_6.1.bb | 19 ---
  1 file changed, 16 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-core/netbase/netbase_6.1.bb 
b/meta/recipes-core/netbase/netbase_6.1.bb
index bc0049c0201..491e6bf4cbf 100644
--- a/meta/recipes-core/netbase/netbase_6.1.bb
+++ b/meta/recipes-core/netbase/netbase_6.1.bb
@@ -6,10 +6,10 @@ LICENSE = "GPLv2"
  LIC_FILES_CHKSUM = 
"file://debian/copyright;md5=3dd6192d306f582dee7687da3d8748ab"
  PE = "1"
  
-SRC_URI = "${DEBIAN_MIRROR}/main/n/${BPN}/${BPN}_${PV}.tar.xz"

+SRC_URI = "git://salsa.debian.org/md/netbase.git;protocol=https"
+SRCREV = "0fc1e4ce39328f7388badace0aaf7b7294d5ed61"
  
-SRC_URI[md5sum] = "e5871a3a5c8390557b8033cf19316a55"

-SRC_URI[sha256sum] = 
"084d743bd84d4d9380bac4c71c51e57406dce44f5a69289bb823c903e9b035d8"
+S = "${WORKDIR}/git"
  
  UPSTREAM_CHECK_URI = "${DEBIAN_MIRROR}/main/n/netbase/"

  do_install () {
@@ -18,3 +18,16 @@ do_install () {
install -m 0644 ${S}/etc/protocols ${D}${sysconfdir}/protocols
install -m 0644 ${S}/etc/services ${D}${sysconfdir}/services
  }
+
+# The reproducible test failed in autobuilder env as
+# 
https://autobuilder.yocto.io/pub/repro-fail/oe-reproducible-20200630-_jn1koza/packages/diff-html/
+# But I didn't reproduce it locally when run "oe-selftest -r 
reproducible.ReproducibleTests.test_reproducible_builds"
+# Per the logic in meta/classes/reproducible_build.bbclass, it should use
+# get_source_date_epoch_from_git to get the SOURCE_DATE_EPOCH after we
+# switch to use git fetcher, don't understand why the SOURCE_DATE_EPOCH
+# is different between reproducibleA and reproducibleB during reproducible
+# test in autobuilder env. The only difference is reproducibleA use sstate
+# but reproducibleB not. Maybe the sstate in autobuilder env has some problem?
+# Anyway, use the default value for SOURCE_DATE_EPOCH from 
meta/classes/reproducible_build_simple.bbclass
+# to fix the gap as a workaround.
+export SOURCE_DATE_EPOCH = "1520598896"




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

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

[OE-core] ✗ patchtest: failure for netbase: use git fetcher (rev3)

[Patchwork]

== Series Details ==

Series: netbase: use git fetcher (rev3)
Revision: 3
URL   : https://patchwork.openembedded.org/series/23255/
State : failure

== Summary ==


Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests have been executed on the proposed
series by patchtest resulting in the following failures:



* Patch[v3] netbase: use git fetcher
 Issue Patch is missing Signed-off-by [test_signed_off_by_presence] 
  Suggested fixSign off the patch (either manually or with "git commit 
--amend -s")



If you believe any of these test results are incorrect, please reply to the
mailing list (openembedded-core@lists.openembedded.org) raising your concerns.
Otherwise we would appreciate you correcting the issues and submitting a new
version of the patchset if applicable. Please ensure you add/increment the
version number when sending the new version (i.e. [PATCH] -> [PATCH v2] ->
[PATCH v3] -> ...).

---
Guidelines: 
https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest
Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe

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

View/Reply Online (#140508): 
https://lists.openembedded.org/g/openembedded-core/message/140508
Mute This Topic: https://lists.openembedded.org/mt/75414217/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] netbase: use git fetcher

[Yu, Mingli]

From: Mingli Yu 

Use git repo as the the previous URL only stores the latest
source file and fails to locate the source tar file if we
don't upgrade timely.
---
 meta/recipes-core/netbase/netbase_6.1.bb | 19 ---
 1 file changed, 16 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-core/netbase/netbase_6.1.bb 
b/meta/recipes-core/netbase/netbase_6.1.bb
index bc0049c0201..491e6bf4cbf 100644
--- a/meta/recipes-core/netbase/netbase_6.1.bb
+++ b/meta/recipes-core/netbase/netbase_6.1.bb
@@ -6,10 +6,10 @@ LICENSE = "GPLv2"
 LIC_FILES_CHKSUM = 
"file://debian/copyright;md5=3dd6192d306f582dee7687da3d8748ab"
 PE = "1"
 
-SRC_URI = "${DEBIAN_MIRROR}/main/n/${BPN}/${BPN}_${PV}.tar.xz"
+SRC_URI = "git://salsa.debian.org/md/netbase.git;protocol=https"
+SRCREV = "0fc1e4ce39328f7388badace0aaf7b7294d5ed61"
 
-SRC_URI[md5sum] = "e5871a3a5c8390557b8033cf19316a55"
-SRC_URI[sha256sum] = 
"084d743bd84d4d9380bac4c71c51e57406dce44f5a69289bb823c903e9b035d8"
+S = "${WORKDIR}/git"
 
 UPSTREAM_CHECK_URI = "${DEBIAN_MIRROR}/main/n/netbase/"
 do_install () {
@@ -18,3 +18,16 @@ do_install () {
install -m 0644 ${S}/etc/protocols ${D}${sysconfdir}/protocols
install -m 0644 ${S}/etc/services ${D}${sysconfdir}/services
 }
+
+# The reproducible test failed in autobuilder env as
+# 
https://autobuilder.yocto.io/pub/repro-fail/oe-reproducible-20200630-_jn1koza/packages/diff-html/
+# But I didn't reproduce it locally when run "oe-selftest -r 
reproducible.ReproducibleTests.test_reproducible_builds"
+# Per the logic in meta/classes/reproducible_build.bbclass, it should use
+# get_source_date_epoch_from_git to get the SOURCE_DATE_EPOCH after we
+# switch to use git fetcher, don't understand why the SOURCE_DATE_EPOCH
+# is different between reproducibleA and reproducibleB during reproducible
+# test in autobuilder env. The only difference is reproducibleA use sstate
+# but reproducibleB not. Maybe the sstate in autobuilder env has some problem?
+# Anyway, use the default value for SOURCE_DATE_EPOCH from 
meta/classes/reproducible_build_simple.bbclass
+# to fix the gap as a workaround.
+export SOURCE_DATE_EPOCH = "1520598896"
-- 
2.26.2

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

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

[OE-core][zeus][PATCH v2] sqlite: backport CVE fix

[Adrian Bunk]

From: Sakib Sajal 

Fixes CVE-2020-11655

(From OE-Core rev: 3b06a6c73f4e49c6d00f758423c2e8865ec2de00)

Signed-off-by: Sakib Sajal 
Signed-off-by: Richard Purdie 
[ without the CVE-2020-11656 fix that did not apply cleanly ]
Signed-off-by: Adrian Bunk 
---
v2: Upstream Status -> Upstream-Status
---
 .../sqlite/files/CVE-2020-11655.patch | 32 +++
 meta/recipes-support/sqlite/sqlite3_3.29.0.bb |  1 +
 2 files changed, 33 insertions(+)
 create mode 100644 meta/recipes-support/sqlite/files/CVE-2020-11655.patch

diff --git a/meta/recipes-support/sqlite/files/CVE-2020-11655.patch 
b/meta/recipes-support/sqlite/files/CVE-2020-11655.patch
new file mode 100644
index 00..c2360cb867
--- /dev/null
+++ b/meta/recipes-support/sqlite/files/CVE-2020-11655.patch
@@ -0,0 +1,32 @@
+From a4601326d61bf1a11151ac6b78b50804bfd03b4d Mon Sep 17 00:00:00 2001
+From: Sakib Sajal 
+Date: Thu, 30 Apr 2020 10:46:16 -0700
+Subject: [PATCH 2/2] In the event of a semantic error in an aggregate query,
+ early-out the resetAccumulator() function to prevent problems due to
+ incomplete or incorrect initialization of the AggInfo object. Fix for ticket
+ [af4556bb5c285c08].
+
+FossilOrigin-Name: 
4a302b42c7bf5e11ddb5522ca999f74aba397d3a7eb91b1844bb02852f772441
+Upstream-Status: Backport [c415d91007e1680e4eb17def583b202c3c83c718]
+
+CVE: CVE-2020-11655
+Signed-off-by: Sakib Sajal 
+---
+ sqlite3.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/sqlite3.c b/sqlite3.c
+index 1df6633..726adf7 100644
+--- a/sqlite3.c
 b/sqlite3.c
+@@ -133242,6 +133242,7 @@ static void resetAccumulator(Parse *pParse, AggInfo 
*pAggInfo){
+   struct AggInfo_func *pFunc;
+   int nReg = pAggInfo->nFunc + pAggInfo->nColumn;
+   if( nReg==0 ) return;
++  if( pParse->nErr ) return;
+ #ifdef SQLITE_DEBUG
+   /* Verify that all AggInfo registers are within the range specified by
+   ** AggInfo.mnReg..AggInfo.mxReg */
+-- 
+2.17.1
+
diff --git a/meta/recipes-support/sqlite/sqlite3_3.29.0.bb 
b/meta/recipes-support/sqlite/sqlite3_3.29.0.bb
index cf3b179845..95e1174b07 100644
--- a/meta/recipes-support/sqlite/sqlite3_3.29.0.bb
+++ b/meta/recipes-support/sqlite/sqlite3_3.29.0.bb
@@ -12,6 +12,7 @@ SRC_URI = 
"http://www.sqlite.org/2019/sqlite-autoconf-${SQLITE_PV}.tar.gz \
file://CVE-2019-19926.patch \
file://CVE-2019-19959.patch \
file://CVE-2019-20218.patch \
+   file://CVE-2020-11655.patch \
 "
 SRC_URI[md5sum] = "8f3dfe83387e62ecb91c7c5c09c688dc"
 SRC_URI[sha256sum] = 
"8e7c1e2950b5b04c5944a981cb31fffbf9d2ddda939d536838ebc854481afd5b"
-- 
2.17.1

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

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

[OE-core] mv: cannot stat './.builtin-script.o.tmp': No such file or directory

[Pankaj Vinadrao Joshi]

Hi,
i have built minimal-image for RPI4 image with perf enabled in it but i am 
getting following error when i am running some script after booting up the 
image  is this is an issue because i am missing something that i should add 
while building ,can anyone suggest me ??

cc1: all warnings being treated as errors
mv: cannot stat './.builtin-script.o.tmp': No such file or directory
make[3]: *** 
[/home/root/lkp/lkp-tests/tmp-pkg/perf/src/linux/tools/build/Makefile.build:96: 
builtin-script.o] Error 1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#140505): 
https://lists.openembedded.org/g/openembedded-core/message/140505
Mute This Topic: https://lists.openembedded.org/mt/75413874/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] nativesdk: clear MACHINE_FEATURES

[Douglas via lists.openembedded.org]

Further to 96c20c9df7:
Try to avoid nativesdk recipes accidentally being dependent on MACHINE_FEATURES.

Signed-off-by: Douglas Royds 
---
 meta/classes/nativesdk.bbclass | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/classes/nativesdk.bbclass b/meta/classes/nativesdk.bbclass
index 7b75710726..cd389c9c77 100644
--- a/meta/classes/nativesdk.bbclass
+++ b/meta/classes/nativesdk.bbclass
@@ -9,6 +9,7 @@ NATIVESDKLIBC ?= "libc-glibc"
 LIBCOVERRIDE = ":${NATIVESDKLIBC}"
 CLASSOVERRIDE = "class-nativesdk"
 MACHINEOVERRIDES = ""
+MACHINE_FEATURES = ""
 
 MULTILIBS = ""
 
-- 
2.17.1

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

View/Reply Online (#140504): 
https://lists.openembedded.org/g/openembedded-core/message/140504
Mute This Topic: https://lists.openembedded.org/mt/75413827/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 V3] dpkg: change SRC_URI to take dpkg from git

[Richard Purdie]

On Fri, 2020-07-10 at 10:08 +0800, Changqing Li wrote:
> From: Changqing Li 
> 
> tar.xz on original URL have been removed, switch to use git
> 
> Signed-off-by: Changqing Li 
> ---
>  meta/recipes-devtools/dpkg/dpkg.inc   |  9 -
>  meta/recipes-devtools/dpkg/dpkg_1.20.0.bb | 10 +++---
>  2 files changed, 15 insertions(+), 4 deletions(-)

The autobuilder didn't like this change :(

https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/1143

Cheers,

Richard

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

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