Re: [OE-core] [PATCH] Add nativesdk of systemd-systemctl

2022-11-14 Thread Zoltan Boszormenyi via lists.openembedded.org

Hi,

I think this is not the correct approach, but here are my
use cases:

I recently discovered that the python script replacement
of the native build of systemctl mishandles services with
multiple RequiredBy= and WantedBy= clauses in the [Install]
section and only creates the symlink for the first service
or target in the list. It doesn't matter if there are multiple
RequiredBy= or WantedBy= lines, or the services/targets are
listed in a single clause line.

It also doesn't handle "systemctl set-default custom.target".
I need it for some custom images, currently I am setting the
target symlink manually in an image postprocess script.

With a cross-script setting the proper --root option for
calling the native systemctl, both would be solved.

Also, to be able to include libfprint / fprintd in Yocto,
the native build of systend is needed for the dependency list:

libfprint
->  libfprint-native (for native generator binaries)
-> libgusb-native
   -> systemd-native (for native libudev)

Best regards,
Zoltán Böszörményi

2022. 10. 31. 9:52 keltezéssel, Alexander Kanavin írta:

You need to explain why this is useful to the broader community. What
is the use case? Each addition to oe-core adds to the maintenance
costs, so it needs to be justified and explained.

Alex

On Mon, 31 Oct 2022 at 09:38, wan...@fujitsu.com  wrote:


I need to use nativesdk-systemd-systemctl.
I added this file in meta-oe, and the maintainers received it.
However, they suggested that it was better to contribute to oe-core.

   --
Best Regards
---
Wang Mingyu
Development Dept.I
Nanjing Fujitsu Nanda Software Tech. Co., Ltd.(FNST) No. 6 Wenzhu Road, 
Nanjing, 210012, China
TEL: +86+25-86630566-8568
COINS: 79988548
FAX: +86+25-83317685
MAIL: wan...@fujitsu.com
http://www.fujitsu.com/cn/fnst/


-Original Message-
From: Alexander Kanavin 
Sent: Monday, October 31, 2022 4:24 PM
To: Wang, Mingyu/王 鸣瑜 
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [PATCH] Add nativesdk of systemd-systemctl

You need to explain the use case. Why is this beneficial to have on oe-core?

Alex

On Mon, 31 Oct 2022 at 09:17, wangmy  wrote:


From: Wang Mingyu 

Signed-off-by: Wang Mingyu 
---
  .../systemd/nativesdk-systemd-systemctl.bb  | 17

+

  1 file changed, 17 insertions(+)
  create mode 100644
meta/recipes-core/systemd/nativesdk-systemd-systemctl.bb

diff --git a/meta/recipes-core/systemd/nativesdk-systemd-systemctl.bb
b/meta/recipes-core/systemd/nativesdk-systemd-systemctl.bb
new file mode 100644
index 00..66b5ec5e6e
--- /dev/null
+++ b/meta/recipes-core/systemd/nativesdk-systemd-systemctl.bb
@@ -0,0 +1,17 @@
+SUMMARY = "Wrapper for enabling systemd services"
+
+LICENSE = "MIT"
+LIC_FILES_CHKSUM =

"file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de
20420"

+
+PR = "r0"
+
+inherit nativesdk
+
+SRC_URI = "file://systemctl"
+
+S = "${WORKDIR}"
+
+do_install() {
+   install -d ${D}${bindir}
+   install -m 0755 ${WORKDIR}/systemctl ${D}${bindir} }
--
2.25.1











-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#173232): 
https://lists.openembedded.org/g/openembedded-core/message/173232
Mute This Topic: https://lists.openembedded.org/mt/94680777/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/6] npm: replace 'npm pack' call by 'tar czf'

2022-05-19 Thread Zoltan Boszormenyi via lists.openembedded.org

2022. 05. 19. 12:05 keltezéssel, Enrico Scholz via lists.openembedded.org írta:

'npm pack' is a maintainer tool which tries to execute 'prepare'
and similar scripts.  This fails usually in OE because it requires
completely installed 'node_modules'.

Earlier nodejs versions supported an undocumented 'ignore-scripts'
option.  This has been removed in nodejs 16.

We could patch 'package.json' and remove the unwanted scripts.  But
this might complicate local workflows (applying patches) and installed
packages will contain the modified 'package.json'.

Instead of, package it manually by 'tar czf'.  As a sideeffect,
'do_configure' is running much faster now.


\o/ Hurray!



Signed-off-by: Enrico Scholz 
---
  meta/classes/npm.bbclass | 35 +--
  1 file changed, 29 insertions(+), 6 deletions(-)

diff --git a/meta/classes/npm.bbclass b/meta/classes/npm.bbclass
index ba50fcac20..91f8f36b0d 100644
--- a/meta/classes/npm.bbclass
+++ b/meta/classes/npm.bbclass
@@ -57,13 +57,36 @@ def npm_global_configs(d):
  configs.append(("cache", d.getVar("NPM_CACHE")))
  return configs
  
+## 'npm pack' runs 'prepare' and 'prepack' scripts. Support for

+## 'ignore-scripts' which prevents this behavior has been removed
+## from nodejs 16.  Use simple 'tar' instead of.
  def npm_pack(env, srcdir, workdir):
-"""Run 'npm pack' on a specified directory"""
-import shlex
-cmd = "npm pack %s" % shlex.quote(srcdir)
-args = [("ignore-scripts", "true")]
-tarball = env.run(cmd, args=args, workdir=workdir).strip("\n")
-return os.path.join(workdir, tarball)
+"""Emulate 'npm pack' on a specified directory"""
+import subprocess
+import os
+import json
+
+src = os.path.join(srcdir, 'package.json')
+with open(src) as f:
+j = json.load(f)
+
+# base does not really matter and is for documentation purposes
+# only.  But the 'version' part must exist because other parts of
+# the bbclass rely on it.
+base = j['name'].split('/')[-1]
+tarball = os.path.join(workdir, "%s-%s.tgz" % (base, j['version']));
+
+# TODO: real 'npm pack' does not include directories while 'tar'
+# does.  But this does not seem to matter...
+subprocess.run(['tar', 'czf', tarball,
+'--exclude', './node-modules',
+'--exclude-vcs',
+'--transform', 's,^\./,package/,',
+'--mtime', '1985-10-26T08:15:00.000Z',
+'.'],
+   check = True, cwd = srcdir)
+
+return tarball
  
  python npm_do_configure() {

  """








-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#165879): 
https://lists.openembedded.org/g/openembedded-core/message/165879
Mute This Topic: https://lists.openembedded.org/mt/91205436/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] python3-setuptools: Fix building python modules using cython

2022-05-19 Thread Zoltan Boszormenyi via lists.openembedded.org

2022. 05. 18. 17:55 keltezéssel, Khem Raj írta:



On 5/18/22 6:28 AM, Zoltan Boszormenyi via lists.openembedded.org wrote:

2022. 05. 18. 14:32 keltezéssel, Ross Burton írta:
I left a comment on the PR you filed, but the triplet thing seems to be a red herring 
as the old code uses ‘in’ so a compiler called arm-poky-linux-gcc would still be 
detected as gcc.


The "in" is also a problem. Any command can have a
"gcc" substring somewhere in the middle.

It's important that the command name ends in the pattern.

Maybe compiler_name.endswith() would be a better choice
but a regex is less typing and more compact then spelling
out compiler_name.endswith() 4 times on the same line.


Sneaking clang under is_gcc() garb seems a bit dubious to me. Perhaps check if is_gcc is 
meant to select some gcc'ness. Then you are better of detecting clang separately.


Python core has this particular quirk for some reason.
I thought is wasn't a big deal because of this.

But for this particular problem (passing "-Wl,-Rpath"
vs "-Rpath" to the compiler), the upstream distutils
has a different solution. It simply handles every other
system where GCC is not a thing then does -Wl,-R for
the remaining systems unconditionally.

It's just a matter of time when setuptools syncs with distutils.







If this patch is just extending the logic to consider clang as gcc, then that should be 
called out explicitly




Ross

*From: *openembedded-core@lists.openembedded.org 
 on behalf of Zoltan Boszormenyi via 
lists.openembedded.org 

*Date: *Wednesday, 18 May 2022 at 08:16
*To: *openembedded-core@lists.openembedded.org 

*Cc: *Zoltán Böszörményi 
*Subject: *[OE-core] [PATCH] python3-setuptools: Fix building python modules 
using cython

From: Zoltán Böszörményi 

The function _is_gcc() was not taking a machine triplet into
account. Also handle clang and clang++ because they also
want the rpath option via -Wl,-R instead of just -R.

Signed-off-by: Zoltán Böszörményi 
---
  ...cross-compiler-prefixes-and-handle-c.patch | 31 +++
  .../python/python3-setuptools_59.5.0.bb   |  1 +
  2 files changed, 32 insertions(+)
  create mode 100644 
meta/recipes-devtools/python/python3-setuptools/0001-Fix-_is_gcc-for-cross-compiler-prefixes-and-handle-c.patch 



diff --git 
a/meta/recipes-devtools/python/python3-setuptools/0001-Fix-_is_gcc-for-cross-compiler-prefixes-and-handle-c.patch 
b/meta/recipes-devtools/python/python3-setuptools/0001-Fix-_is_gcc-for-cross-compiler-prefixes-and-handle-c.patch 


new file mode 100644
index 00..7f91d8e6cd
--- /dev/null
+++ 
b/meta/recipes-devtools/python/python3-setuptools/0001-Fix-_is_gcc-for-cross-compiler-prefixes-and-handle-c.patch 


@@ -0,0 +1,31 @@
+From 695800847eb519209c2b45e26fd65d3117a4efcd Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Zolt=C3=A1n=20B=C3=B6sz=C3=B6rm=C3=A9nyi?=
+ 
+Date: Wed, 18 May 2022 06:51:22 +0200
+Subject: [PATCH] Fix _is_gcc() for cross-compiler prefixes and handle
+ clang and clang++
+
+Upstream-Status: Submitted [https://github.com/pypa/setuptools/pull/3326 
<https://github.com/pypa/setuptools/pull/3326>]

+
+Signed-off-by: Zoltán Böszörményi 
+---
+ setuptools/_distutils/unixccompiler.py | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/setuptools/_distutils/unixccompiler.py 
b/setuptools/_distutils/unixccompiler.py

+index 715408f5..3a4d642e 100644
+--- a/setuptools/_distutils/unixccompiler.py
 b/setuptools/_distutils/unixccompiler.py
+@@ -260,7 +260,8 @@ class UnixCCompiler(CCompiler):
+ return "-L" + dir
+
+ def _is_gcc(self, compiler_name):
+-    return "gcc" in compiler_name or "g++" in compiler_name
++    cnpat = re.compile('.*(gcc|g\+\+|clang|clang\+\+)$')
++    return not (cnpat.match(compiler_name) is None)
+
+ def runtime_library_dir_option(self, dir):
+ # XXX Hackish, at the very least.  See Python bug #445902:
+--
+2.36.1
+
diff --git a/meta/recipes-devtools/python/python3-setuptools_59.5.0.bb 
b/meta/recipes-devtools/python/python3-setuptools_59.5.0.bb

index f2810e18d3..20ecf5223d 100644
--- a/meta/recipes-devtools/python/python3-setuptools_59.5.0.bb
+++ b/meta/recipes-devtools/python/python3-setuptools_59.5.0.bb
@@ -11,6 +11,7 @@ SRC_URI:append:class-native = " 
file://0001-conditionally-do-not-fetch-code-by-e 


  SRC_URI += "\
file://0001-change-shebang-to-python3.patch 
 \
file://0001-_distutils-sysconfig-append-STAGING_LIBDIR-python-sy.patch 
 \
+ file://0001-Fix-_is_gcc-for-cross-compiler-prefixes-and-handle-c.patch 
 \

  "

  SRC_URI[sha256sum] = 
"d144f85102f999444d06f9c0e8c737fd0194f10f2f7e5fdb77573f6e2fa4fad0"
--
2.36.1

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and 
may also be privileged. If you are not the intended recipient, please notify the sender 
immediately and do not disclose the contents to

Re: [OE-core] [PATCH] python3-setuptools: Fix building python modules using cython

2022-05-18 Thread Zoltan Boszormenyi via lists.openembedded.org

2022. 05. 18. 14:32 keltezéssel, Ross Burton írta:
I left a comment on the PR you filed, but the triplet thing seems to be a red herring as 
the old code uses ‘in’ so a compiler called arm-poky-linux-gcc would still be detected as gcc.


The "in" is also a problem. Any command can have a
"gcc" substring somewhere in the middle.

It's important that the command name ends in the pattern.

Maybe compiler_name.endswith() would be a better choice
but a regex is less typing and more compact then spelling
out compiler_name.endswith() 4 times on the same line.



If this patch is just extending the logic to consider clang as gcc, then that should be 
called out explicitly.


Ross

*From: *openembedded-core@lists.openembedded.org 
 on behalf of Zoltan Boszormenyi via 
lists.openembedded.org 

*Date: *Wednesday, 18 May 2022 at 08:16
*To: *openembedded-core@lists.openembedded.org 

*Cc: *Zoltán Böszörményi 
*Subject: *[OE-core] [PATCH] python3-setuptools: Fix building python modules 
using cython

From: Zoltán Böszörményi 

The function _is_gcc() was not taking a machine triplet into
account. Also handle clang and clang++ because they also
want the rpath option via -Wl,-R instead of just -R.

Signed-off-by: Zoltán Böszörményi 
---
  ...cross-compiler-prefixes-and-handle-c.patch | 31 +++
  .../python/python3-setuptools_59.5.0.bb   |  1 +
  2 files changed, 32 insertions(+)
  create mode 100644 
meta/recipes-devtools/python/python3-setuptools/0001-Fix-_is_gcc-for-cross-compiler-prefixes-and-handle-c.patch


diff --git 
a/meta/recipes-devtools/python/python3-setuptools/0001-Fix-_is_gcc-for-cross-compiler-prefixes-and-handle-c.patch 
b/meta/recipes-devtools/python/python3-setuptools/0001-Fix-_is_gcc-for-cross-compiler-prefixes-and-handle-c.patch

new file mode 100644
index 00..7f91d8e6cd
--- /dev/null
+++ 
b/meta/recipes-devtools/python/python3-setuptools/0001-Fix-_is_gcc-for-cross-compiler-prefixes-and-handle-c.patch

@@ -0,0 +1,31 @@
+From 695800847eb519209c2b45e26fd65d3117a4efcd Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Zolt=C3=A1n=20B=C3=B6sz=C3=B6rm=C3=A9nyi?=
+ 
+Date: Wed, 18 May 2022 06:51:22 +0200
+Subject: [PATCH] Fix _is_gcc() for cross-compiler prefixes and handle
+ clang and clang++
+
+Upstream-Status: Submitted [https://github.com/pypa/setuptools/pull/3326 
<https://github.com/pypa/setuptools/pull/3326>]

+
+Signed-off-by: Zoltán Böszörményi 
+---
+ setuptools/_distutils/unixccompiler.py | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/setuptools/_distutils/unixccompiler.py 
b/setuptools/_distutils/unixccompiler.py
+index 715408f5..3a4d642e 100644
+--- a/setuptools/_distutils/unixccompiler.py
 b/setuptools/_distutils/unixccompiler.py
+@@ -260,7 +260,8 @@ class UnixCCompiler(CCompiler):
+ return "-L" + dir
+
+ def _is_gcc(self, compiler_name):
+-    return "gcc" in compiler_name or "g++" in compiler_name
++    cnpat = re.compile('.*(gcc|g\+\+|clang|clang\+\+)$')
++    return not (cnpat.match(compiler_name) is None)
+
+ def runtime_library_dir_option(self, dir):
+ # XXX Hackish, at the very least.  See Python bug #445902:
+--
+2.36.1
+
diff --git a/meta/recipes-devtools/python/python3-setuptools_59.5.0.bb 
b/meta/recipes-devtools/python/python3-setuptools_59.5.0.bb

index f2810e18d3..20ecf5223d 100644
--- a/meta/recipes-devtools/python/python3-setuptools_59.5.0.bb
+++ b/meta/recipes-devtools/python/python3-setuptools_59.5.0.bb
@@ -11,6 +11,7 @@ SRC_URI:append:class-native = " 
file://0001-conditionally-do-not-fetch-code-by-e 


  SRC_URI += "\
file://0001-change-shebang-to-python3.patch 
 \
file://0001-_distutils-sysconfig-append-STAGING_LIBDIR-python-sy.patch 
 \
+ file://0001-Fix-_is_gcc-for-cross-compiler-prefixes-and-handle-c.patch 
 \

  "

  SRC_URI[sha256sum] = 
"d144f85102f999444d06f9c0e8c737fd0194f10f2f7e5fdb77573f6e2fa4fad0"
--
2.36.1

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may 
also be privileged. If you are not the intended recipient, please notify the sender 
immediately and do not disclose the contents to any other person, use it for any purpose, 
or store or copy the information in any medium. Thank you.








-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#165853): 
https://lists.openembedded.org/g/openembedded-core/message/165853
Mute This Topic: https://lists.openembedded.org/mt/91181312/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] python3-setuptools: Fix building python modules using cython

2022-05-18 Thread Zoltan Boszormenyi via lists.openembedded.org
From: Zoltán Böszörményi 

The function _is_gcc() was not taking a machine triplet into
account. Also handle clang and clang++ because they also
want the rpath option via -Wl,-R instead of just -R.

Signed-off-by: Zoltán Böszörményi 
---
 ...cross-compiler-prefixes-and-handle-c.patch | 31 +++
 .../python/python3-setuptools_59.5.0.bb   |  1 +
 2 files changed, 32 insertions(+)
 create mode 100644 
meta/recipes-devtools/python/python3-setuptools/0001-Fix-_is_gcc-for-cross-compiler-prefixes-and-handle-c.patch

diff --git 
a/meta/recipes-devtools/python/python3-setuptools/0001-Fix-_is_gcc-for-cross-compiler-prefixes-and-handle-c.patch
 
b/meta/recipes-devtools/python/python3-setuptools/0001-Fix-_is_gcc-for-cross-compiler-prefixes-and-handle-c.patch
new file mode 100644
index 00..7f91d8e6cd
--- /dev/null
+++ 
b/meta/recipes-devtools/python/python3-setuptools/0001-Fix-_is_gcc-for-cross-compiler-prefixes-and-handle-c.patch
@@ -0,0 +1,31 @@
+From 695800847eb519209c2b45e26fd65d3117a4efcd Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Zolt=C3=A1n=20B=C3=B6sz=C3=B6rm=C3=A9nyi?=
+ 
+Date: Wed, 18 May 2022 06:51:22 +0200
+Subject: [PATCH] Fix _is_gcc() for cross-compiler prefixes and handle
+ clang and clang++
+
+Upstream-Status: Submitted [https://github.com/pypa/setuptools/pull/3326]
+
+Signed-off-by: Zoltán Böszörményi 
+---
+ setuptools/_distutils/unixccompiler.py | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/setuptools/_distutils/unixccompiler.py 
b/setuptools/_distutils/unixccompiler.py
+index 715408f5..3a4d642e 100644
+--- a/setuptools/_distutils/unixccompiler.py
 b/setuptools/_distutils/unixccompiler.py
+@@ -260,7 +260,8 @@ class UnixCCompiler(CCompiler):
+ return "-L" + dir
+ 
+ def _is_gcc(self, compiler_name):
+-return "gcc" in compiler_name or "g++" in compiler_name
++cnpat = re.compile('.*(gcc|g\+\+|clang|clang\+\+)$')
++return not (cnpat.match(compiler_name) is None)
+ 
+ def runtime_library_dir_option(self, dir):
+ # XXX Hackish, at the very least.  See Python bug #445902:
+-- 
+2.36.1
+
diff --git a/meta/recipes-devtools/python/python3-setuptools_59.5.0.bb 
b/meta/recipes-devtools/python/python3-setuptools_59.5.0.bb
index f2810e18d3..20ecf5223d 100644
--- a/meta/recipes-devtools/python/python3-setuptools_59.5.0.bb
+++ b/meta/recipes-devtools/python/python3-setuptools_59.5.0.bb
@@ -11,6 +11,7 @@ SRC_URI:append:class-native = " 
file://0001-conditionally-do-not-fetch-code-by-e
 SRC_URI += "\
 file://0001-change-shebang-to-python3.patch \
 file://0001-_distutils-sysconfig-append-STAGING_LIBDIR-python-sy.patch \
+file://0001-Fix-_is_gcc-for-cross-compiler-prefixes-and-handle-c.patch \
 "
 
 SRC_URI[sha256sum] = 
"d144f85102f999444d06f9c0e8c737fd0194f10f2f7e5fdb77573f6e2fa4fad0"
-- 
2.36.1


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



Re: [OE-core] [meta-oe][PATCH v2 3/3] nodejs: Add /usr/lib/node -> node_modules symlink

2022-05-13 Thread Zoltan Boszormenyi via lists.openembedded.org

2022. 05. 13. 17:42 keltezéssel, Alexander Kanavin írta:

This needs to be sent to the openembedded-devel list.


Is it ok just to cc openembedded-devel? Because applying
this 3rd patch to meta-oe without applying the second to
oe-core will cause conflicts and has a high chance to be
rejected.



Alex

On Fri, 13 May 2022 at 17:31, Zoltan Boszormenyi via
lists.openembedded.org  wrote:


From: Zoltán Böszörményi 

While /usr/lib/node_modules and all npm-related modules are
shipped in the npm subpackage, keep the symlink in the main
package because 3rd party modules that don't need npm are
also installed into /usr/lib/node_modules.

Signed-off-by: Zoltán Böszörményi 
---
  meta-oe/recipes-devtools/nodejs/nodejs_16.14.2.bb | 5 +
  1 file changed, 5 insertions(+)

diff --git a/meta-oe/recipes-devtools/nodejs/nodejs_16.14.2.bb 
b/meta-oe/recipes-devtools/nodejs/nodejs_16.14.2.bb
index 62188f94a..be68afd4c 100644
--- a/meta-oe/recipes-devtools/nodejs/nodejs_16.14.2.bb
+++ b/meta-oe/recipes-devtools/nodejs/nodejs_16.14.2.bb
@@ -159,6 +159,10 @@ do_compile () {

  do_install () {
  oe_runmake install DESTDIR=${D}
+
+# node(1) is using /usr/lib/node as default include directory and npm(1) is
+# using /usr/lib/node_modules as install directory. Let's make both happy.
+ln -fs node_modules ${D}/${nonarch_libdir}/node
  }

  BINARIES = " \
@@ -176,6 +180,7 @@ do_install:append:class-native() {
  }

  PACKAGES =+ "${PN}-npm"
+FILES:${PN} += "${nonarch_libdir}/node"
  FILES:${PN}-npm = "${nonarch_libdir}/node_modules ${bindir}/npm ${bindir}/npx"
  RDEPENDS:${PN}-npm = "bash python3-core python3-shell python3-datetime \
  python3-misc python3-multiprocessing"
--
2.36.1







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



[OE-core] [meta-oe][PATCH v2 3/3] nodejs: Add /usr/lib/node -> node_modules symlink

2022-05-13 Thread Zoltan Boszormenyi via lists.openembedded.org
From: Zoltán Böszörményi 

While /usr/lib/node_modules and all npm-related modules are
shipped in the npm subpackage, keep the symlink in the main
package because 3rd party modules that don't need npm are
also installed into /usr/lib/node_modules.

Signed-off-by: Zoltán Böszörményi 
---
 meta-oe/recipes-devtools/nodejs/nodejs_16.14.2.bb | 5 +
 1 file changed, 5 insertions(+)

diff --git a/meta-oe/recipes-devtools/nodejs/nodejs_16.14.2.bb 
b/meta-oe/recipes-devtools/nodejs/nodejs_16.14.2.bb
index 62188f94a..be68afd4c 100644
--- a/meta-oe/recipes-devtools/nodejs/nodejs_16.14.2.bb
+++ b/meta-oe/recipes-devtools/nodejs/nodejs_16.14.2.bb
@@ -159,6 +159,10 @@ do_compile () {
 
 do_install () {
 oe_runmake install DESTDIR=${D}
+
+# node(1) is using /usr/lib/node as default include directory and npm(1) is
+# using /usr/lib/node_modules as install directory. Let's make both happy.
+ln -fs node_modules ${D}/${nonarch_libdir}/node
 }
 
 BINARIES = " \
@@ -176,6 +180,7 @@ do_install:append:class-native() {
 }
 
 PACKAGES =+ "${PN}-npm"
+FILES:${PN} += "${nonarch_libdir}/node"
 FILES:${PN}-npm = "${nonarch_libdir}/node_modules ${bindir}/npm ${bindir}/npx"
 RDEPENDS:${PN}-npm = "bash python3-core python3-shell python3-datetime \
 python3-misc python3-multiprocessing"
-- 
2.36.1


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



[OE-core] [PATCH v2 1/3] npm.bbclass: Fix file permissions before opening it for writing

2022-05-13 Thread Zoltan Boszormenyi via lists.openembedded.org
From: Zoltán Böszörményi 

Some node module archives in npmjs.org contain wrong permissions.
I found a case with package.json in the archive being r-xr-xr-x
for which open(..., "w") fails. Modify the manifest file permissions
to add the write bit for the owner.

Signed-off-by: Zoltán Böszörményi 
---
 meta/classes/npm.bbclass | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/classes/npm.bbclass b/meta/classes/npm.bbclass
index ba50fcac20..86ee0f665a 100644
--- a/meta/classes/npm.bbclass
+++ b/meta/classes/npm.bbclass
@@ -81,6 +81,7 @@ python npm_do_configure() {
 import json
 import re
 import shlex
+import stat
 import tempfile
 from bb.fetch2.npm import NpmEnvironment
 from bb.fetch2.npm import npm_unpack
@@ -202,6 +203,7 @@ python npm_do_configure() {
 if has_shrinkwrap_file:
 _update_manifest("devDependencies")
 
+os.chmod(cached_manifest_file, os.stat(cached_manifest_file).st_mode | 
stat.S_IWUSR)
 with open(cached_manifest_file, "w") as f:
 json.dump(cached_manifest, f, indent=2)
 
-- 
2.36.1


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



[OE-core] [PATCH v2 2/3] npm.bbclass: Don't create /usr/lib/node symlink

2022-05-13 Thread Zoltan Boszormenyi via lists.openembedded.org
From: Zoltán Böszörményi 

When a recipe DEPENDS on multiple other npm based recipes,
the symlink will create a conflict.

Signed-off-by: Zoltán Böszörményi 
---
 meta/classes/npm.bbclass | 4 
 1 file changed, 4 deletions(-)

diff --git a/meta/classes/npm.bbclass b/meta/classes/npm.bbclass
index 86ee0f665a..dbfc2e728e 100644
--- a/meta/classes/npm.bbclass
+++ b/meta/classes/npm.bbclass
@@ -307,10 +307,6 @@ npm_do_install() {
 # Remove the shrinkwrap file which does not need to be packed
 rm -f ${D}/${nonarch_libdir}/node_modules/*/npm-shrinkwrap.json
 rm -f ${D}/${nonarch_libdir}/node_modules/@*/*/npm-shrinkwrap.json
-
-# node(1) is using /usr/lib/node as default include directory and npm(1) is
-# using /usr/lib/node_modules as install directory. Let's make both happy.
-ln -fs node_modules ${D}/${nonarch_libdir}/node
 }
 
 FILES:${PN} += " \
-- 
2.36.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#165575): 
https://lists.openembedded.org/g/openembedded-core/message/165575
Mute This Topic: https://lists.openembedded.org/mt/91083343/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] staging.bbclass: Ignore installing multiple symlinks of the same name

2022-05-13 Thread Zoltan Boszormenyi via lists.openembedded.org

2022. 05. 13. 15:55 keltezéssel, Alexander Kanavin írta:

Apologies, but special-casing this in staging class is not right
either. The problem should be addressed at the making of
sysroot-destdir/ step from the npm class.


npm.bbclass creates the symlink in sysroot-destdir for recipe A

But then it's the job of staging.bbclass to populate a recipe B's
recipe-sysroot and recipe-sysroot-native from recipe A.

How can this be worked around from npm.bbclass?



Alex


On Fri, 13 May 2022 at 15:49, Zoltan Boszormenyi via
lists.openembedded.org  wrote:


From: Zoltán Böszörményi 

Recipes using "inherit npm" install the same /usr/lib/node symlink
that points to node_modules. When a recipe DEPENDS on multiple
npm based recipe, do_prepare_recipe_sysroot() fails.

Ignore this symlink in a way that the set of ignored symlinks
can be extended later if needed.

Signed-off-by: Zoltán Böszörményi 
---
  meta/classes/staging.bbclass | 6 +-
  1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/meta/classes/staging.bbclass b/meta/classes/staging.bbclass
index 9fc8f4f283..f7b6056219 100644
--- a/meta/classes/staging.bbclass
+++ b/meta/classes/staging.bbclass
@@ -528,6 +528,7 @@ python extend_recipe_sysroot() {

  with open(manifest, "r") as f:
  manifests[dep] = manifest
+ignored_dests = [ ''.join([d.getVar('nonarch_libdir'), '/node' 
]) ]
  for l in f:
  l = l.strip()
  if l.endswith("/fixmepath"):
@@ -545,7 +546,10 @@ python extend_recipe_sysroot() {
  hashname = targetdir + dest
  if not hashname.endswith("/"):
  if hashname in fileset:
-bb.fatal("The file %s is installed by both %s and %s, 
aborting" % (dest, c, fileset[hashname]))
+if os.path.islink(hashname) and  dest in 
ignored_dests:
+bb.note("The symlink '%s' %s wants to install is 
already installed by %s, ignoring" % (dest, c, fileset[hashname]))
+else:
+bb.fatal("The file %s is installed by both %s and 
%s, aborting" % (dest, c, fileset[hashname]))
  else:
  fileset[hashname] = c

--
2.36.1











-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#165570): 
https://lists.openembedded.org/g/openembedded-core/message/165570
Mute This Topic: https://lists.openembedded.org/mt/91080993/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] staging.bbclass: Ignore installing multiple symlinks of the same name

2022-05-13 Thread Zoltan Boszormenyi via lists.openembedded.org
From: Zoltán Böszörményi 

Recipes using "inherit npm" install the same /usr/lib/node symlink
that points to node_modules. When a recipe DEPENDS on multiple
npm based recipe, do_prepare_recipe_sysroot() fails.

Ignore this symlink in a way that the set of ignored symlinks
can be extended later if needed.

Signed-off-by: Zoltán Böszörményi 
---
 meta/classes/staging.bbclass | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/meta/classes/staging.bbclass b/meta/classes/staging.bbclass
index 9fc8f4f283..f7b6056219 100644
--- a/meta/classes/staging.bbclass
+++ b/meta/classes/staging.bbclass
@@ -528,6 +528,7 @@ python extend_recipe_sysroot() {
 
 with open(manifest, "r") as f:
 manifests[dep] = manifest
+ignored_dests = [ ''.join([d.getVar('nonarch_libdir'), '/node' 
]) ]
 for l in f:
 l = l.strip()
 if l.endswith("/fixmepath"):
@@ -545,7 +546,10 @@ python extend_recipe_sysroot() {
 hashname = targetdir + dest
 if not hashname.endswith("/"):
 if hashname in fileset:
-bb.fatal("The file %s is installed by both %s and 
%s, aborting" % (dest, c, fileset[hashname]))
+if os.path.islink(hashname) and  dest in 
ignored_dests:
+bb.note("The symlink '%s' %s wants to install 
is already installed by %s, ignoring" % (dest, c, fileset[hashname]))
+else:
+bb.fatal("The file %s is installed by both %s 
and %s, aborting" % (dest, c, fileset[hashname]))
 else:
 fileset[hashname] = c
 
-- 
2.36.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#165566): 
https://lists.openembedded.org/g/openembedded-core/message/165566
Mute This Topic: https://lists.openembedded.org/mt/91080993/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] npm.bbclass: Fix file permissions before opening it for writing

2022-05-13 Thread Zoltan Boszormenyi via lists.openembedded.org
From: Zoltán Böszörményi 

Some node module archives in npmjs.org contain wrong permissions.
I found a case with package.json in the archive being r-xr-xr-x
for which open(..., "w") fails. Set the manifest file permissions
to 0666 just in case.

Signed-off-by: Zoltán Böszörményi 
---
 meta/classes/npm.bbclass | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/classes/npm.bbclass b/meta/classes/npm.bbclass
index ba50fcac20..7f52ec6061 100644
--- a/meta/classes/npm.bbclass
+++ b/meta/classes/npm.bbclass
@@ -202,6 +202,7 @@ python npm_do_configure() {
 if has_shrinkwrap_file:
 _update_manifest("devDependencies")
 
+os.chmod(cached_manifest_file, 0o666)
 with open(cached_manifest_file, "w") as f:
 json.dump(cached_manifest, f, indent=2)
 
-- 
2.36.1


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



[OE-core] Fix some NPM related problems

2022-05-13 Thread Zoltan Boszormenyi via lists.openembedded.org

When trying to create recipes for Angular so that "ng build"
can be run, I ran into some problems. Two of them I was able fix.

The first two problems are in the same class and boil down to
the fact that some node module archives are created by an idiotic
tar client (probably on Windows) and contain wrong permissions.

Problem 1) Directories have no "x" permission bit

This cannot be worked around as tar creates the directory as is
but creating the first file in the directory will fail.

tar exits with an error and there is no option for it to
override directory permissions.

license-webpack-plugin 2.3.1, a dependency for Angular 11 is
such a contender.

Problem 2) package.json have no "w" permission bit

This can be worked around with
[PATCH 1/2] npm.bbclass: Fix file permissions before opening it for writing

Problem 3) Recipes with "inherit npm" install the /usr/lib/node symlink

I needed to create a complete set of Angular recipes where "ng build"
can run. But when trying to use them in DEPENDS for an Angular based
project, this error kicked in from staging.bbclass:

bb.fatal("The file %s is installed by both %s and %s, aborting" % (dest, c, 
fileset[hashname]))

This is fixed by ignoring the sole /usr/lib/node symlink in staging.bbclass
when checking for identical files with

[PATCH 2/2] staging.bbclass: Ignore installing multiple symlinks of the same 
name

I discovered this issue in Yocto 3.3.

I cc-ed relevant parties who edited either bbclass around where
I just modified them.

Best regards,
Zoltán Böszörményi


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



[OE-core] [PATCH v2] mesa: Allow building Mesa's OpenCL through PACKAGECONFIG

2022-03-17 Thread Zoltan Boszormenyi via lists.openembedded.org
From: Zoltán Böszörményi 

v2: Fix libopencl-mesa-dev packaging

Signed-off-by: Zoltán Böszörményi 
---
 meta/recipes-graphics/mesa/mesa.inc | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-graphics/mesa/mesa.inc 
b/meta/recipes-graphics/mesa/mesa.inc
index 2a89b8e8f0..d1d4276aeb 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -74,7 +74,6 @@ MESON_BUILDTYPE = "${@check_buildtype(d)}"
 
 EXTRA_OEMESON = " \
 -Dshared-glapi=enabled \
--Dgallium-opencl=disabled \
 -Dglx-read-only-text=true \
 -Dplatforms='${@",".join("${PLATFORMS}".split())}' \
 "
@@ -122,6 +121,9 @@ PACKAGECONFIG[gles] = "-Dgles1=enabled -Dgles2=enabled, 
-Dgles1=disabled -Dgles2
 # "egl" requires "opengl"
 PACKAGECONFIG[egl] = "-Degl=enabled, -Degl=disabled"
 
+# "opencl" requires libclc from meta-clang and spirv-tools from OE-Core
+PACKAGECONFIG[opencl] = "-Dgallium-opencl=icd 
-Dopencl-spirv=true,-Dgallium-opencl=disabled -Dopencl-spirv=false,libclc 
spirv-tools"
+
 PACKAGECONFIG[broadcom] = ""
 PACKAGECONFIG[etnaviv] = ""
 PACKAGECONFIG[freedreno] = ""
@@ -190,6 +192,8 @@ RDEPENDS:${PN}-dev = ""
 # development package of libgles3.
 RDEPENDS:libgles3-mesa-dev += "libgles2-mesa-dev"
 
+RDEPENDS:libopencl-mesa += "${@bb.utils.contains('PACKAGECONFIG', 'opencl', 
'libclc spirv-tools', '', d)}"
+
 PACKAGES =+ "libegl-mesa libegl-mesa-dev \
  libosmesa libosmesa-dev \
  libgl-mesa libgl-mesa-dev \
@@ -198,6 +202,7 @@ PACKAGES =+ "libegl-mesa libegl-mesa-dev \
  libgles1-mesa libgles1-mesa-dev \
  libgles2-mesa libgles2-mesa-dev \
  libgles3-mesa libgles3-mesa-dev \
+ libopencl-mesa libopencl-mesa-dev \
  libxatracker libxatracker-dev \
  mesa-megadriver mesa-vulkan-drivers \
  mesa-vdpau-drivers \
@@ -230,7 +235,8 @@ python __anonymous() {
   ("opengl", "libgl", "libgl1"),
   ("gles", "libgles1", "libglesv1-cm1"),
   ("gles", "libgles2", "libglesv2-2"),
-  ("gles", "libgles3",)):
+  ("gles", "libgles3",),
+  ("opencl", "libopencl",)):
 if not p[0] in pkgconfig:
 continue
 mlprefix = d.getVar("MLPREFIX")
@@ -290,6 +296,7 @@ FILES:libgbm = "${libdir}/libgbm.so.*"
 FILES:libgles1-mesa = "${libdir}/libGLESv1*.so.*"
 FILES:libgles2-mesa = "${libdir}/libGLESv2.so.*"
 FILES:libgl-mesa = "${libdir}/libGL.so.*"
+FILES:libopencl-mesa = "${libdir}/libMesaOpenCL.so.* 
${sysconfdir}/OpenCL/vendors/mesa.icd"
 FILES:libglapi = "${libdir}/libglapi.so.*"
 FILES:libosmesa = "${libdir}/libOSMesa.so.*"
 FILES:libxatracker = "${libdir}/libxatracker.so.*"
@@ -302,6 +309,7 @@ FILES:libglapi-dev = "${libdir}/libglapi.*"
 FILES:libgles1-mesa-dev = "${libdir}/libGLESv1*.* ${includedir}/GLES 
${libdir}/pkgconfig/glesv1*.pc"
 FILES:libgles2-mesa-dev = "${libdir}/libGLESv2.* ${includedir}/GLES2 
${libdir}/pkgconfig/glesv2.pc"
 FILES:libgles3-mesa-dev = "${includedir}/GLES3"
+FILES:libopencl-mesa-dev = "${libdir}/libMesaOpenCL.so"
 FILES:libosmesa-dev = "${libdir}/libOSMesa.* ${includedir}/GL/osmesa.h 
${libdir}/pkgconfig/osmesa.pc"
 FILES:libxatracker-dev = "${libdir}/libxatracker.so ${libdir}/libxatracker.la \
   ${includedir}/xa_tracker.h 
${includedir}/xa_composite.h ${includedir}/xa_context.h \
-- 
2.35.1


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



Re: [OE-core] [PATCH] mesa: Fix libopencl-mesa-dev packaging

2022-03-17 Thread Zoltan Boszormenyi via lists.openembedded.org

2022. 03. 17. 11:35 keltezéssel, Jose Quaresma írta:

Hi Zoltán,

This patch seems to be a fixup for the previous

https://lists.openembedded.org/g/openembedded-core/message/163331 
<https://lists.openembedded.org/g/openembedded-core/message/163331>


I think a v2 is more appropriate


I will send a v2 then. Thanks.



Jose

Zoltan Boszormenyi via lists.openembedded.org <http://lists.openembedded.org> 
mailto:pr...@lists.openembedded.org>> escreveu no 
dia quinta, 17/03/2022 à(s) 10:29:


From: Zoltán Böszörményi mailto:zbos...@gmail.com>>

Signed-off-by: Zoltán Böszörményi mailto:zbos...@gmail.com>>
---
  meta/recipes-graphics/mesa/mesa.inc | 1 +
  1 file changed, 1 insertion(+)

diff --git a/meta/recipes-graphics/mesa/mesa.inc 
b/meta/recipes-graphics/mesa/mesa.inc
index c6e85520f8..e8c07a4563 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -307,6 +307,7 @@ FILES:libglapi-dev = "${libdir}/libglapi.*"
  FILES:libgles1-mesa-dev = "${libdir}/libGLESv1*.* ${includedir}/GLES
${libdir}/pkgconfig/glesv1*.pc"
  FILES:libgles2-mesa-dev = "${libdir}/libGLESv2.* ${includedir}/GLES2
${libdir}/pkgconfig/glesv2.pc"
  FILES:libgles3-mesa-dev = "${includedir}/GLES3"
+FILES:libopencl-mesa-dev = "${libdir}/libMesaOpenCL.so"
  FILES:libosmesa-dev = "${libdir}/libOSMesa.* ${includedir}/GL/osmesa.h
${libdir}/pkgconfig/osmesa.pc"
  FILES:libxatracker-dev = "${libdir}/libxatracker.so 
${libdir}/libxatracker.la
<http://libxatracker.la> \
                            ${includedir}/xa_tracker.h 
${includedir}/xa_composite.h
${includedir}/xa_context.h \
-- 
2.35.1








--
Best regards,

José Quaresma



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



[OE-core] [PATCH] mesa: Fix libopencl-mesa-dev packaging

2022-03-17 Thread Zoltan Boszormenyi via lists.openembedded.org
From: Zoltán Böszörményi 

Signed-off-by: Zoltán Böszörményi 
---
 meta/recipes-graphics/mesa/mesa.inc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-graphics/mesa/mesa.inc 
b/meta/recipes-graphics/mesa/mesa.inc
index c6e85520f8..e8c07a4563 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -307,6 +307,7 @@ FILES:libglapi-dev = "${libdir}/libglapi.*"
 FILES:libgles1-mesa-dev = "${libdir}/libGLESv1*.* ${includedir}/GLES 
${libdir}/pkgconfig/glesv1*.pc"
 FILES:libgles2-mesa-dev = "${libdir}/libGLESv2.* ${includedir}/GLES2 
${libdir}/pkgconfig/glesv2.pc"
 FILES:libgles3-mesa-dev = "${includedir}/GLES3"
+FILES:libopencl-mesa-dev = "${libdir}/libMesaOpenCL.so"
 FILES:libosmesa-dev = "${libdir}/libOSMesa.* ${includedir}/GL/osmesa.h 
${libdir}/pkgconfig/osmesa.pc"
 FILES:libxatracker-dev = "${libdir}/libxatracker.so ${libdir}/libxatracker.la \
   ${includedir}/xa_tracker.h 
${includedir}/xa_composite.h ${includedir}/xa_context.h \
-- 
2.35.1


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



[OE-core] [PATCH] mesa: Allow building Mesa's OpenCL through PACKAGECONFIG

2022-03-16 Thread Zoltan Boszormenyi via lists.openembedded.org
From: Zoltán Böszörményi 

Signed-off-by: Zoltán Böszörményi 
---
 meta/recipes-graphics/mesa/mesa.inc | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-graphics/mesa/mesa.inc 
b/meta/recipes-graphics/mesa/mesa.inc
index 2a89b8e8f0..4ce69a78f8 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -74,7 +74,6 @@ MESON_BUILDTYPE = "${@check_buildtype(d)}"
 
 EXTRA_OEMESON = " \
 -Dshared-glapi=enabled \
--Dgallium-opencl=disabled \
 -Dglx-read-only-text=true \
 -Dplatforms='${@",".join("${PLATFORMS}".split())}' \
 "
@@ -122,6 +121,9 @@ PACKAGECONFIG[gles] = "-Dgles1=enabled -Dgles2=enabled, 
-Dgles1=disabled -Dgles2
 # "egl" requires "opengl"
 PACKAGECONFIG[egl] = "-Degl=enabled, -Degl=disabled"
 
+# "opencl" requires libclc from meta-clang and spirv-tools from OE-Core
+PACKAGECONFIG[opencl] = "-Dgallium-opencl=icd 
-Dopencl-spirv=true,-Dgallium-opencl=disabled -Dopencl-spirv=false,libclc 
spirv-tools"
+
 PACKAGECONFIG[broadcom] = ""
 PACKAGECONFIG[etnaviv] = ""
 PACKAGECONFIG[freedreno] = ""
@@ -190,6 +192,8 @@ RDEPENDS:${PN}-dev = ""
 # development package of libgles3.
 RDEPENDS:libgles3-mesa-dev += "libgles2-mesa-dev"
 
+RDEPENDS:libopencl-mesa += "${@bb.utils.contains('PACKAGECONFIG', 'opencl', 
'libclc spirv-tools', '', d)}"
+
 PACKAGES =+ "libegl-mesa libegl-mesa-dev \
  libosmesa libosmesa-dev \
  libgl-mesa libgl-mesa-dev \
@@ -198,6 +202,7 @@ PACKAGES =+ "libegl-mesa libegl-mesa-dev \
  libgles1-mesa libgles1-mesa-dev \
  libgles2-mesa libgles2-mesa-dev \
  libgles3-mesa libgles3-mesa-dev \
+ libopencl-mesa libopencl-mesa-dev \
  libxatracker libxatracker-dev \
  mesa-megadriver mesa-vulkan-drivers \
  mesa-vdpau-drivers \
@@ -230,7 +235,8 @@ python __anonymous() {
   ("opengl", "libgl", "libgl1"),
   ("gles", "libgles1", "libglesv1-cm1"),
   ("gles", "libgles2", "libglesv2-2"),
-  ("gles", "libgles3",)):
+  ("gles", "libgles3",),
+  ("opencl", "libopencl",)):
 if not p[0] in pkgconfig:
 continue
 mlprefix = d.getVar("MLPREFIX")
@@ -290,6 +296,7 @@ FILES:libgbm = "${libdir}/libgbm.so.*"
 FILES:libgles1-mesa = "${libdir}/libGLESv1*.so.*"
 FILES:libgles2-mesa = "${libdir}/libGLESv2.so.*"
 FILES:libgl-mesa = "${libdir}/libGL.so.*"
+FILES:libopencl-mesa = "${libdir}/libMesaOpenCL.so.* 
${sysconfdir}/OpenCL/vendors/mesa.icd"
 FILES:libglapi = "${libdir}/libglapi.so.*"
 FILES:libosmesa = "${libdir}/libOSMesa.so.*"
 FILES:libxatracker = "${libdir}/libxatracker.so.*"
-- 
2.35.1


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



[OE-core] [PATCH v2] gtk-icon-cache: Allow using gtk4

2022-02-24 Thread Zoltan Boszormenyi via lists.openembedded.org
From: Zoltán Böszörményi 

meta-openembedded has gtk4 which has its own version of
gtk-update-icon-cache. Allow programs that want to use gtk4
use the proper version of the gtk-update-icon-cache utility
and the proper build and runtime dependencies.

Also use a more readable syntax for conditional values in DEPENDS.

Signed-off-by: Zoltán Böszörményi 
---
 meta/classes/gtk-icon-cache.bbclass | 27 ---
 1 file changed, 16 insertions(+), 11 deletions(-)

diff --git a/meta/classes/gtk-icon-cache.bbclass 
b/meta/classes/gtk-icon-cache.bbclass
index 0248ba285e..6808339b90 100644
--- a/meta/classes/gtk-icon-cache.bbclass
+++ b/meta/classes/gtk-icon-cache.bbclass
@@ -1,17 +1,22 @@
 FILES:${PN} += "${datadir}/icons/hicolor"
 
-#gtk+3 reqiure GTK3DISTROFEATURES, DEPENDS on it make all the
+GTKIC_VERSION ??= '3'
+
+GTKPN = "${@ 'gtk4' if d.getVar('GTKIC_VERSION') == '4' else 'gtk+3' }"
+GTKIC_CMD = "${@ 'gtk-update-icon-cache-3.0.0' if d.getVar('GTKIC_VERSION') == 
'4' else 'gtk4-update-icon-cache' }"
+
+#gtk+3/gtk4 require GTK3DISTROFEATURES, DEPENDS on it make all the
 #recipes inherit this class require GTK3DISTROFEATURES
 inherit features_check
 ANY_OF_DISTRO_FEATURES = "${GTK3DISTROFEATURES}"
 
-DEPENDS +=" ${@['hicolor-icon-theme', '']['${BPN}' == 'hicolor-icon-theme']} \
-${@['gdk-pixbuf', '']['${BPN}' == 'gdk-pixbuf']} \
-${@['gtk+3', '']['${BPN}' == 'gtk+3']} \
-gtk+3-native \
+DEPENDS +=" ${@ '' if d.getVar('BPN') == 'hicolor-icon-theme' else 
'hicolor-icon-theme' } \
+${@ '' if d.getVar('BPN') == 'gdk-pixbuf' else 'gdk-pixbuf' } \
+${@ '' if d.getVar('BPN') == d.getVar('GTKPN') else 
d.getVar('GTKPN') } \
+${GTKPN}-native \
 "
 
-PACKAGE_WRITE_DEPS += "gtk+3-native gdk-pixbuf-native"
+PACKAGE_WRITE_DEPS += "${GTKPN}-native gdk-pixbuf-native"
 
 gtk_icon_cache_postinst() {
 if [ "x$D" != "x" ]; then
@@ -25,7 +30,7 @@ else
 
for icondir in /usr/share/icons/* ; do
if [ -d $icondir ] ; then
-   gtk-update-icon-cache -fqt  $icondir
+   ${GTKIC_CMD} -fqt  $icondir
fi
done
 fi
@@ -39,7 +44,7 @@ if [ "x$D" != "x" ]; then
 else
for icondir in /usr/share/icons/* ; do
if [ -d $icondir ] ; then
-   gtk-update-icon-cache -qt  $icondir
+   ${GTKIC_CMD} -qt  $icondir
fi
done
 fi
@@ -58,13 +63,13 @@ python populate_packages:append () {
 rdepends = ' ' + d.getVar('MLPREFIX', False) + "hicolor-icon-theme"
 d.appendVar('RDEPENDS:%s' % pkg, rdepends)
 
-#gtk_icon_cache_postinst depend on gdk-pixbuf and gtk+3
+#gtk_icon_cache_postinst depend on gdk-pixbuf and gtk+3/gtk4
 bb.note("adding gdk-pixbuf dependency to %s" % pkg)
 rdepends = ' ' + d.getVar('MLPREFIX', False) + "gdk-pixbuf"
 d.appendVar('RDEPENDS:%s' % pkg, rdepends)
 
-bb.note("adding gtk+3 dependency to %s" % pkg)
-rdepends = ' ' + d.getVar('MLPREFIX', False) + "gtk+3"
+bb.note("adding %s dependency to %s" % (d.getVar('GTKPN'), pkg))
+rdepends = ' ' + d.getVar('MLPREFIX', False) + d.getVar('GTKPN')
 d.appendVar('RDEPENDS:%s' % pkg, rdepends)
 
 bb.note("adding gtk-icon-cache postinst and postrm scripts to %s" % 
pkg)
-- 
2.35.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162312): 
https://lists.openembedded.org/g/openembedded-core/message/162312
Mute This Topic: https://lists.openembedded.org/mt/89364261/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: Allow using gtk4

2022-02-24 Thread Zoltan Boszormenyi via lists.openembedded.org

2022. 02. 24. 13:48 keltezéssel, Ross Burton írta:

On Thu, 24 Feb 2022 at 07:23, Zoltan Boszormenyi via
lists.openembedded.org  wrote:

+${@['${GTKPN}', '']['${BPN}' == '${GTKPN}']} \


I know this was the syntax originally here, but please change this to
use the "a if b else c" syntax used elsewhere.


I will send a new version, thanks.



Ross








-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162310): 
https://lists.openembedded.org/g/openembedded-core/message/162310
Mute This Topic: https://lists.openembedded.org/mt/89360865/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] gtk-icon-cache: Allow using gtk4

2022-02-23 Thread Zoltan Boszormenyi via lists.openembedded.org
From: Zoltán Böszörményi 

meta-openembedded has gtk4 which has its own version of
gtk-update-icon-cache. Allow programs that want to use gtk4
use the proper version of the gtk-update-icon-cache utility
and the proper build and runtime dependencies.

Signed-off-by: Zoltán Böszörményi 
---
 meta/classes/gtk-icon-cache.bbclass | 23 ++-
 1 file changed, 14 insertions(+), 9 deletions(-)

diff --git a/meta/classes/gtk-icon-cache.bbclass 
b/meta/classes/gtk-icon-cache.bbclass
index 0248ba285e..ec97467e15 100644
--- a/meta/classes/gtk-icon-cache.bbclass
+++ b/meta/classes/gtk-icon-cache.bbclass
@@ -1,17 +1,22 @@
 FILES:${PN} += "${datadir}/icons/hicolor"
 
-#gtk+3 reqiure GTK3DISTROFEATURES, DEPENDS on it make all the
+GTKIC_VERSION ??= '3'
+
+GTKPN = "${@ 'gtk4' if d.getVar('GTKIC_VERSION') == '4' else 'gtk+3' }"
+GTKIC_CMD = "${@ 'gtk-update-icon-cache-3.0.0' if d.getVar('GTKIC_VERSION') == 
'4' else 'gtk4-update-icon-cache' }"
+
+#gtk+3/gtk4 require GTK3DISTROFEATURES, DEPENDS on it make all the
 #recipes inherit this class require GTK3DISTROFEATURES
 inherit features_check
 ANY_OF_DISTRO_FEATURES = "${GTK3DISTROFEATURES}"
 
 DEPENDS +=" ${@['hicolor-icon-theme', '']['${BPN}' == 'hicolor-icon-theme']} \
 ${@['gdk-pixbuf', '']['${BPN}' == 'gdk-pixbuf']} \
-${@['gtk+3', '']['${BPN}' == 'gtk+3']} \
-gtk+3-native \
+${@['${GTKPN}', '']['${BPN}' == '${GTKPN}']} \
+${GTKPN}-native \
 "
 
-PACKAGE_WRITE_DEPS += "gtk+3-native gdk-pixbuf-native"
+PACKAGE_WRITE_DEPS += "${GTKPN}-native gdk-pixbuf-native"
 
 gtk_icon_cache_postinst() {
 if [ "x$D" != "x" ]; then
@@ -25,7 +30,7 @@ else
 
for icondir in /usr/share/icons/* ; do
if [ -d $icondir ] ; then
-   gtk-update-icon-cache -fqt  $icondir
+   ${GTKIC_CMD} -fqt  $icondir
fi
done
 fi
@@ -39,7 +44,7 @@ if [ "x$D" != "x" ]; then
 else
for icondir in /usr/share/icons/* ; do
if [ -d $icondir ] ; then
-   gtk-update-icon-cache -qt  $icondir
+   ${GTKIC_CMD} -qt  $icondir
fi
done
 fi
@@ -58,13 +63,13 @@ python populate_packages:append () {
 rdepends = ' ' + d.getVar('MLPREFIX', False) + "hicolor-icon-theme"
 d.appendVar('RDEPENDS:%s' % pkg, rdepends)
 
-#gtk_icon_cache_postinst depend on gdk-pixbuf and gtk+3
+#gtk_icon_cache_postinst depend on gdk-pixbuf and gtk+3/gtk4
 bb.note("adding gdk-pixbuf dependency to %s" % pkg)
 rdepends = ' ' + d.getVar('MLPREFIX', False) + "gdk-pixbuf"
 d.appendVar('RDEPENDS:%s' % pkg, rdepends)
 
-bb.note("adding gtk+3 dependency to %s" % pkg)
-rdepends = ' ' + d.getVar('MLPREFIX', False) + "gtk+3"
+bb.note("adding %s dependency to %s" % (d.getVar('GTKPN'), pkg))
+rdepends = ' ' + d.getVar('MLPREFIX', False) + d.getVar('GTKPN')
 d.appendVar('RDEPENDS:%s' % pkg, rdepends)
 
 bb.note("adding gtk-icon-cache postinst and postrm scripts to %s" % 
pkg)
-- 
2.35.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162302): 
https://lists.openembedded.org/g/openembedded-core/message/162302
Mute This Topic: https://lists.openembedded.org/mt/89360865/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] qemuboot: Fix build error if UNINATIVE_LOADER is unset

2022-02-09 Thread Zoltan Boszormenyi via lists.openembedded.org
From: Zoltán Böszörményi 

I got this error on current master:

File: 'exec_func_python() autogenerated', lineno: 2, function: 
 0001:
 *** 0002:do_write_qemuboot_conf(d)
 0003:
File: '.../layers/openembedded-core/meta/classes/qemuboot.bbclass', lineno: 
141, function: do_write_qemuboot_conf
 0137:else:
 0138:val = d.getVar(k)
 0139:# we only want to write out relative paths so that we can 
relocate images
 0140:# and still run them
 *** 0141:if val.startswith(topdir):
 0142:val = os.path.relpath(val, finalpath)
 0143:cf.set('config_bsp', k, '%s' % val)
 0144:
 0145:# QB_DEFAULT_KERNEL's value of KERNEL_IMAGETYPE is the name of a 
symlink
Exception: AttributeError: 'NoneType' object has no attribute 'startswith'

Do nothing if "val" is None, which may happen for k = "UNINATIVE_LOADER".

Signed-off-by: Zoltán Böszörményi 
---
 meta/classes/qemuboot.bbclass | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/classes/qemuboot.bbclass b/meta/classes/qemuboot.bbclass
index 229bd88527..755d49acd6 100644
--- a/meta/classes/qemuboot.bbclass
+++ b/meta/classes/qemuboot.bbclass
@@ -136,6 +136,8 @@ python do_write_qemuboot_conf() {

'qemu-helper-native/1.0-r1/recipe-sysroot-native/usr/bin/')
 else:
 val = d.getVar(k)
+if val is None:
+continue
 # we only want to write out relative paths so that we can relocate 
images
 # and still run them
 if val.startswith(topdir):
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#161568): 
https://lists.openembedded.org/g/openembedded-core/message/161568
Mute This Topic: https://lists.openembedded.org/mt/89024474/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] qemuboot: Fix NoneType error in do_write_qemuboot_conf

2022-02-09 Thread Zoltan Boszormenyi via lists.openembedded.org

I guess this commit below is what broke the image build for me,
as it added UNINATIVE_LOADER handling to qemuboot.bbclass.

commit 39c10816d5ec9d9c7952d786d7a3f942d25d0c27
Author: Alexander Kanavin 
Date:   Fri Feb 4 20:59:43 2022 +0100

runqemu: preload uninative libraries when host gl drivers are in use

Some of the host distributions build the drivers in a way (RPATH/RUNPATH)
that tricks uninative loader into loading pieces of the host libc, if
the same pieces haven't been previously loaded by native binaries. Mixing
the two libc versions leads to failures.

This change ensures that the correct (uninative) versions are always in use.

Signed-off-by: Alexander Kanavin 
Signed-off-by: Richard Purdie 


Zoltán

2022. 02. 09. 15:55 keltezéssel, Zoltan Boszormenyi via lists.openembedded.org 
írta:

I have added a bb.error line to print the value of "k".
It's "UNINATIVE_LOADER".

I am not touching this variable in my custom distro layer. Should I?

Zoltán

2022. 02. 09. 11:56 keltezéssel, Alexander Kanavin írta:

Right, but this might be fixing the symptom, and not the problem.

Alex

On Wed, 9 Feb 2022 at 11:53, Böszörményi Zoltán  wrote:


(Resending from the address I am subscribed with.)

I have no idea.

It was working a week ago for me but today after "repo sync"
the image build failed on me with the quoted error.

With this fix, the image is built with the expected contents.

The change with "if val.startswith()" was from 2017,
something around it must have changed very recently.

Zoltán

2022. 02. 09. 11:35 keltezéssel, Alexander Kanavin írta:

Wait, why val is none in the first place? Why aren't others seeing it?

Alex

On Wed, 9 Feb 2022 at 10:53, Zoltan Boszormenyi via
lists.openembedded.org  wrote:


From: Zoltán Böszörményi 

I got this error on current master:

File: 'exec_func_python() autogenerated', lineno: 2, function: 
   0001:
   *** 0002:do_write_qemuboot_conf(d)
   0003:
File: '.../layers/openembedded-core/meta/classes/qemuboot.bbclass', lineno: 141, 
function: do_write_qemuboot_conf

   0137:    else:
   0138:    val = d.getVar(k)
   0139:    # we only want to write out relative paths so that we can 
relocate images

   0140:    # and still run them
   *** 0141:    if val.startswith(topdir):
   0142:    val = os.path.relpath(val, finalpath)
   0143:    cf.set('config_bsp', k, '%s' % val)
   0144:
   0145:    # QB_DEFAULT_KERNEL's value of KERNEL_IMAGETYPE is the name of 
a symlink
Exception: AttributeError: 'NoneType' object has no attribute 'startswith'

Do nothing if "val" is None.

Signed-off-by: Zoltán Böszörményi 
---
   meta/classes/qemuboot.bbclass | 2 ++
   1 file changed, 2 insertions(+)

diff --git a/meta/classes/qemuboot.bbclass b/meta/classes/qemuboot.bbclass
index 229bd88527..755d49acd6 100644
--- a/meta/classes/qemuboot.bbclass
+++ b/meta/classes/qemuboot.bbclass
@@ -136,6 +136,8 @@ python do_write_qemuboot_conf() {
  
'qemu-helper-native/1.0-r1/recipe-sysroot-native/usr/bin/')

   else:
   val = d.getVar(k)
+    if val is None:
+    continue
   # we only want to write out relative paths so that we can relocate 
images
   # and still run them
   if val.startswith(topdir):
--
2.34.1















-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#161565): 
https://lists.openembedded.org/g/openembedded-core/message/161565
Mute This Topic: https://lists.openembedded.org/mt/89018458/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] qemuboot: Fix NoneType error in do_write_qemuboot_conf

2022-02-09 Thread Zoltan Boszormenyi via lists.openembedded.org

I have added a bb.error line to print the value of "k".
It's "UNINATIVE_LOADER".

I am not touching this variable in my custom distro layer. Should I?

Zoltán

2022. 02. 09. 11:56 keltezéssel, Alexander Kanavin írta:

Right, but this might be fixing the symptom, and not the problem.

Alex

On Wed, 9 Feb 2022 at 11:53, Böszörményi Zoltán  wrote:


(Resending from the address I am subscribed with.)

I have no idea.

It was working a week ago for me but today after "repo sync"
the image build failed on me with the quoted error.

With this fix, the image is built with the expected contents.

The change with "if val.startswith()" was from 2017,
something around it must have changed very recently.

Zoltán

2022. 02. 09. 11:35 keltezéssel, Alexander Kanavin írta:

Wait, why val is none in the first place? Why aren't others seeing it?

Alex

On Wed, 9 Feb 2022 at 10:53, Zoltan Boszormenyi via
lists.openembedded.org  wrote:


From: Zoltán Böszörményi 

I got this error on current master:

File: 'exec_func_python() autogenerated', lineno: 2, function: 
   0001:
   *** 0002:do_write_qemuboot_conf(d)
   0003:
File: '.../layers/openembedded-core/meta/classes/qemuboot.bbclass', lineno: 
141, function: do_write_qemuboot_conf
   0137:else:
   0138:val = d.getVar(k)
   0139:# we only want to write out relative paths so that we can 
relocate images
   0140:# and still run them
   *** 0141:if val.startswith(topdir):
   0142:val = os.path.relpath(val, finalpath)
   0143:cf.set('config_bsp', k, '%s' % val)
   0144:
   0145:# QB_DEFAULT_KERNEL's value of KERNEL_IMAGETYPE is the name of 
a symlink
Exception: AttributeError: 'NoneType' object has no attribute 'startswith'

Do nothing if "val" is None.

Signed-off-by: Zoltán Böszörményi 
---
   meta/classes/qemuboot.bbclass | 2 ++
   1 file changed, 2 insertions(+)

diff --git a/meta/classes/qemuboot.bbclass b/meta/classes/qemuboot.bbclass
index 229bd88527..755d49acd6 100644
--- a/meta/classes/qemuboot.bbclass
+++ b/meta/classes/qemuboot.bbclass
@@ -136,6 +136,8 @@ python do_write_qemuboot_conf() {
  
'qemu-helper-native/1.0-r1/recipe-sysroot-native/usr/bin/')
   else:
   val = d.getVar(k)
+if val is None:
+continue
   # we only want to write out relative paths so that we can relocate 
images
   # and still run them
   if val.startswith(topdir):
--
2.34.1









-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#161564): 
https://lists.openembedded.org/g/openembedded-core/message/161564
Mute This Topic: https://lists.openembedded.org/mt/89018458/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] qemuboot: Fix NoneType error in do_write_qemuboot_conf

2022-02-09 Thread Zoltan Boszormenyi via lists.openembedded.org

(Resending from the address I am subscribed with.)

I have no idea.

It was working a week ago for me but today after "repo sync"
the image build failed on me with the quoted error.

With this fix, the image is built with the expected contents.

The change with "if val.startswith()" was from 2017,
something around it must have changed very recently.

Zoltán

2022. 02. 09. 11:35 keltezéssel, Alexander Kanavin írta:

Wait, why val is none in the first place? Why aren't others seeing it?

Alex

On Wed, 9 Feb 2022 at 10:53, Zoltan Boszormenyi via
lists.openembedded.org  wrote:


From: Zoltán Böszörményi 

I got this error on current master:

File: 'exec_func_python() autogenerated', lineno: 2, function: 
  0001:
  *** 0002:do_write_qemuboot_conf(d)
  0003:
File: '.../layers/openembedded-core/meta/classes/qemuboot.bbclass', lineno: 
141, function: do_write_qemuboot_conf
  0137:else:
  0138:val = d.getVar(k)
  0139:# we only want to write out relative paths so that we can 
relocate images
  0140:# and still run them
  *** 0141:if val.startswith(topdir):
  0142:val = os.path.relpath(val, finalpath)
  0143:cf.set('config_bsp', k, '%s' % val)
  0144:
  0145:# QB_DEFAULT_KERNEL's value of KERNEL_IMAGETYPE is the name of a 
symlink
Exception: AttributeError: 'NoneType' object has no attribute 'startswith'

Do nothing if "val" is None.

Signed-off-by: Zoltán Böszörményi 
---
  meta/classes/qemuboot.bbclass | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/meta/classes/qemuboot.bbclass b/meta/classes/qemuboot.bbclass
index 229bd88527..755d49acd6 100644
--- a/meta/classes/qemuboot.bbclass
+++ b/meta/classes/qemuboot.bbclass
@@ -136,6 +136,8 @@ python do_write_qemuboot_conf() {
 
'qemu-helper-native/1.0-r1/recipe-sysroot-native/usr/bin/')
  else:
  val = d.getVar(k)
+if val is None:
+continue
  # we only want to write out relative paths so that we can relocate 
images
  # and still run them
  if val.startswith(topdir):
--
2.34.1







-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#161550): 
https://lists.openembedded.org/g/openembedded-core/message/161550
Mute This Topic: https://lists.openembedded.org/mt/89018458/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] qemuboot: Fix NoneType error in do_write_qemuboot_conf

2022-02-09 Thread Zoltan Boszormenyi via lists.openembedded.org
From: Zoltán Böszörményi 

I got this error on current master:

File: 'exec_func_python() autogenerated', lineno: 2, function: 
 0001:
 *** 0002:do_write_qemuboot_conf(d)
 0003:
File: '.../layers/openembedded-core/meta/classes/qemuboot.bbclass', lineno: 
141, function: do_write_qemuboot_conf
 0137:else:
 0138:val = d.getVar(k)
 0139:# we only want to write out relative paths so that we can 
relocate images
 0140:# and still run them
 *** 0141:if val.startswith(topdir):
 0142:val = os.path.relpath(val, finalpath)
 0143:cf.set('config_bsp', k, '%s' % val)
 0144:
 0145:# QB_DEFAULT_KERNEL's value of KERNEL_IMAGETYPE is the name of a 
symlink
Exception: AttributeError: 'NoneType' object has no attribute 'startswith'

Do nothing if "val" is None.

Signed-off-by: Zoltán Böszörményi 
---
 meta/classes/qemuboot.bbclass | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/classes/qemuboot.bbclass b/meta/classes/qemuboot.bbclass
index 229bd88527..755d49acd6 100644
--- a/meta/classes/qemuboot.bbclass
+++ b/meta/classes/qemuboot.bbclass
@@ -136,6 +136,8 @@ python do_write_qemuboot_conf() {

'qemu-helper-native/1.0-r1/recipe-sysroot-native/usr/bin/')
 else:
 val = d.getVar(k)
+if val is None:
+continue
 # we only want to write out relative paths so that we can relocate 
images
 # and still run them
 if val.startswith(topdir):
-- 
2.34.1


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



Re: [yocto] [OE-core] Question of Yocto dunfell LTS period

2022-01-14 Thread Zoltan Boszormenyi via lists.openembedded.org

Funny you mention PR.

It would also help if recipes staying on the same version
but adding patches for e.g. CVE fixes should increase their
PR value so their rebuilt versions can be put into a package repo.

Throwing away the buildroot (as suggested any time some obscure
build error happens) and restarting a complete image build
resets the autopr value so the repo would contain packages with
the same r0.0 release string and the package manager doesn't know
that the package is newer.

2022. 01. 14. 10:42 keltezéssel, Alexander Kanavin írta:
Actually, I think this was some kind of missed PR opportunity. Regular distros, such as 
RHEL, Debian and everyone else, are constantly trotting out their support windows as the 
reason to hand them the job of making products, so we could counter that better perhaps.


Alex

On Fri, 14 Jan 2022 at 06:28, Michael Opdenacker > wrote:



On 1/14/22 2:36 AM, Jate Sujjavanich wrote:
 > I received the answer to this question in IRC on 10/29/2021.
 >
 > 16:06
 > > 
 > I saw a wiki edit that said dunfell's LTS period is now through April
 > 2024, but I've seen no announcements. Any truth to this rumor?
 > 16:20
 > > 
 > jatedev: it was announced on one of the technical calls a few weeks
 > back, so yes AFAIK
 > 16:25
 > > 
 > jatedev: definitely true. I wish we could sort out the project
 > advocacy side of things :(
 >
 > Let this email serve as a little advocacy.


I believe this would also help if the website (releases page) and/or
official documentation carried such information.
Thanks for raising this concern!
Cheers
Michael.

-- 
Michael Opdenacker, Bootlin

Embedded Linux and Kernel engineering
https://bootlin.com 











-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#160563): 
https://lists.openembedded.org/g/openembedded-core/message/160563
Mute This Topic: https://lists.openembedded.org/mt/88415300/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] xserver-xorg: update to 21.1.2

2022-01-04 Thread Zoltan Boszormenyi via lists.openembedded.org

2021. 12. 18. 21:52 keltezéssel, Oleksandr Kravchuk írta:

Signed-off-by: Oleksandr Kravchuk 
---
  .../{xserver-xorg_21.1.1.bb => xserver-xorg_21.1.2.bb}  | 2 +-


21.1.3 was released recently.


  1 file changed, 1 insertion(+), 1 deletion(-)
  rename meta/recipes-graphics/xorg-xserver/{xserver-xorg_21.1.1.bb => 
xserver-xorg_21.1.2.bb} (92%)

diff --git a/meta/recipes-graphics/xorg-xserver/xserver-xorg_21.1.1.bb 
b/meta/recipes-graphics/xorg-xserver/xserver-xorg_21.1.2.bb
similarity index 92%
rename from meta/recipes-graphics/xorg-xserver/xserver-xorg_21.1.1.bb
rename to meta/recipes-graphics/xorg-xserver/xserver-xorg_21.1.2.bb
index 196d1edff5..60c18c0a47 100644
--- a/meta/recipes-graphics/xorg-xserver/xserver-xorg_21.1.1.bb
+++ b/meta/recipes-graphics/xorg-xserver/xserver-xorg_21.1.2.bb
@@ -3,7 +3,7 @@ require xserver-xorg.inc
  SRC_URI += 
"file://0001-xf86pciBus.c-use-Intel-ddx-only-for-pre-gen4-hardwar.patch \
 file://0001-Avoid-duplicate-definitions-of-IOPortBase.patch \
 "
-SRC_URI[sha256sum] = 
"782e7fef2ca0c7cbe60a937b8bf42dac69c904fb841950fd0363e1c2346ea755"
+SRC_URI[sha256sum] = 
"c20bf46a9fe8e74bf4e75430637e58d49a02d806609dc161462bceb1ef7e8db0"
  
  # These extensions are now integrated into the server, so declare the migration

  # path for in-place upgrades.








-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#160157): 
https://lists.openembedded.org/g/openembedded-core/message/160157
Mute This Topic: https://lists.openembedded.org/mt/8782/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 05/24] xserver-xorg: convert from autotools to meson

2021-11-14 Thread Zoltan Boszormenyi via lists.openembedded.org

2021. 11. 10. 20:39 keltezéssel, Alexander Kanavin írta:

Not every option was carried over, drop them accordingly.

Signed-off-by: Alexander Kanavin 
---
  .../xorg-xserver/xserver-xorg.inc | 55 ---
  1 file changed, 22 insertions(+), 33 deletions(-)

diff --git a/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc 
b/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc
index 6a5f274046..4a7048aced 100644
--- a/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc
+++ b/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc
@@ -23,7 +23,7 @@ CVE_PRODUCT = "xorg-server"
  
  S = "${WORKDIR}/${XORG_PN}-${PV}"
  
-inherit autotools pkgconfig

+inherit meson pkgconfig
  
  inherit features_check

  REQUIRED_DISTRO_FEATURES = "x11"
@@ -105,50 +105,39 @@ FILES:${PN}-module-libxf1bpp = 
"${libdir}/xorg/modules/libxf1bpp.so"
  FILES:${PN}-module-libxf4bpp = "${libdir}/xorg/modules/libxf4bpp.so"
  FILES:xf86-video-modesetting = 
"${libdir}/xorg/modules/drivers/modesetting_drv.so"
  
-EXTRA_OECONF += "--with-fop=no \

- --with-pic \
- --disable-static \
- --disable-record \
- --disable-xnest \
- --enable-xvfb \
- --enable-composite \
- --without-dtrace \
- --with-int10=x86emu \
- --sysconfdir=/etc/X11 \
- --localstatedir=/var \
- --with-xkb-output=/var/lib/xkb \
+EXTRA_OEMESON += " \
+ -Dxnest=false \
+ -Dxvfb=true \
+ -Ddtrace=false \
+ -Dint10=x86emu \
+ -Dxkb_output_dir=/var/lib/xkb \
  "
  
-OPENGL_PKGCONFIGS = "dri glx glamor dri3 xshmfence"

+OPENGL_PKGCONFIGS = "dri glx glamor dri3"
  PACKAGECONFIG ??= "dga dri2 udev ${XORG_CRYPTO} \
 ${@bb.utils.contains('DISTRO_FEATURES', 'opengl', 
'${OPENGL_PKGCONFIGS}', '', d)} \
-   ${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 'systemd 
systemd-logind', '', d)} \
+   ${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 
'systemd-logind', '', d)} \
  "
  
-PACKAGECONFIG[udev] = "--enable-config-udev,--disable-config-udev,udev"

-PACKAGECONFIG[dga] = "--enable-dga,--disable-dga"
-PACKAGECONFIG[dri] = "--enable-dri,--disable-dri,virtual/mesa"
-PACKAGECONFIG[dri2] = "--enable-dri2,--disable-dri2"
-# DRI3 requires xshmfence to also be enabled
-PACKAGECONFIG[dri3] = "--enable-dri3,--disable-dri3"
-PACKAGECONFIG[glx] = "--enable-glx,--disable-glx,virtual/libgl virtual/libx11"
-PACKAGECONFIG[glamor] = "--enable-glamor,--disable-glamor,libepoxy 
virtual/libgbm,libegl"
-PACKAGECONFIG[unwind] = "--enable-libunwind,--disable-libunwind,libunwind"
-PACKAGECONFIG[xshmfence] = 
"--enable-xshmfence,--disable-xshmfence,libxshmfence"
-PACKAGECONFIG[xmlto] = "--with-xmlto, --without-xmlto, xmlto-native 
docbook-xml-dtd4-native docbook-xsl-stylesheets-native"
-PACKAGECONFIG[systemd-logind] = 
"--enable-systemd-logind=yes,--enable-systemd-logind=no,dbus,"
-PACKAGECONFIG[systemd] = 
"--with-systemd-daemon,--without-systemd-daemon,systemd"
-PACKAGECONFIG[xinerama] = "--enable-xinerama,--disable-xinerama"
+PACKAGECONFIG[udev] = "-Dudev=true,-Dudev=false,udev"
+PACKAGECONFIG[dga] = "-Ddga=true,-Ddga=false"
+PACKAGECONFIG[dri] = "-Ddri1=true,-Ddri1=false,virtual/mesa"
+PACKAGECONFIG[dri2] = "-Ddri2=true,-Ddri2=false"
+PACKAGECONFIG[dri3] = "-Ddri3=true,-Ddri3=false"
+PACKAGECONFIG[glx] = "-Dglx=true,-Dglx=false,virtual/libgl virtual/libx11"
+PACKAGECONFIG[glamor] = "-Dglamor=true,-Dglamor=false,libepoxy 
virtual/libgbm,libegl"
+PACKAGECONFIG[unwind] = "-Dlibunwind=true,-Dlibunwind=false,libunwind"
+PACKAGECONFIG[systemd-logind] = 
"-Dsystemd_logind=true,-Dsystemd_logind=false,dbus,"
+PACKAGECONFIG[xinerama] = "-Dxinerama=true,-Dxinerama=false"
  
  # Xorg requires a SHA1 implementation, pick one

  XORG_CRYPTO ??= "openssl"
-PACKAGECONFIG[openssl] = "--with-sha1=libcrypto,,openssl"
-PACKAGECONFIG[nettle] = "--with-sha1=libnettle,,nettle"
-PACKAGECONFIG[gcrypt] = "--with-sha1=libgcrypt,,libgcrypt"
+PACKAGECONFIG[openssl] = "-Dsha1=libcrypto,,openssl"
+PACKAGECONFIG[nettle] = "-Dsha1=libnettle,,nettle"
+PACKAGECONFIG[gcrypt] = "-Dsha1=libgcrypt,,libgcrypt"
  
  do_install:append () {

# Its assumed base-files creates this for us
-   rmdir ${D}${localstatedir}/log/


The comment is related to the presence of /var/log and
now it doesn't make sense after removing the above line.
Please remove the comment, too.


  sed -i -e 's,${libdir}/xorg/modules,${prefix}/lib*/xorg/modules,' 
${D}${mandir}/man5/xorg.conf.5
  }
  









-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#158273): 
https://lists.openembedded.org/g/openembedded-core/message/158273
Mute This Topic: https://lists.openembedded.org/mt/86965698/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: 

Re: [OE-core] cargo-native do_fetch error

2021-11-06 Thread Zoltan Boszormenyi via lists.openembedded.org

2021. 11. 06. 14:02 keltezéssel, Konrad Weihmann írta:



On 06.11.21 13:49, Zoltan Boszormenyi via lists.openembedded.org wrote:

I tried building my custom OS rebased on current master.

I got this error:

ERROR: cargo-native-1.56.0-r0 do_fetch: No checksum specified for 
'/data/genericx86-64-yocto-3.5/downloads/rustc-1.56.0-src.tar.xz', please add at least 
one to the recipe:
SRC_URI[rust.sha256sum] = 
"f13468889833c88e744ad579c5d8fbb7ecb53216159b54481a90e5dcdaa9e320"
ERROR: cargo-native-1.56.0-r0 do_fetch: Bitbake Fetcher Error: NoChecksumError('Missing 
SRC_URI checksum', 'https://static.rust-lang.org/dist/rustc-1.56.0-src.tar.xz;name=rust')
ERROR: Logfile of failure stored in: 
/data/genericx86-64-yocto-3.5/tmp-sicom-glibc/work/x86_64-linux/cargo-native/1.56.0-r0/temp/log.do_fetch.3495409 



Could you kindly double check your setup, because at 
meta/recipes-devtools/rust/rust-source.inc one will find


SRC_URI += "https://static.rust-lang.org/dist/rustc-${PV}-src.tar.xz;name=rust;
SRC_URI[rust.sha256sum] = 
"f13468889833c88e744ad579c5d8fbb7ecb53216159b54481a90e5dcdaa9e320"

which looks okayish to me.
And this include is direct injected in meta/recipes-devtools/cargo/cargo_1.56.0.bb right 
at the first line


I saw that file and that's why I wondered.


Maybe this file went missing or was otherwise masked in your setup


No, it's there and not masked.

The problem was that I didn't realize that oe-core master has merged meta-rust.
I still had the standalone meta-rust in my repo manifest xml.
After removing it, cargo(-native) can be fetched and built just fine.

Sorry for the noise.






ERROR: Task 
(virtual:native:/data/genericx86-64-yocto-3.5/conf/../layers/openembedded-core/meta/recipes-devtools/cargo/cargo_1.56.0.bb:do_fetch) 
failed with exit code '1'


I found no bbappend for cargo or rust in any layers I currently use
so it must be a genuine bug in Yocto 3.5 at the moment.

Best regards,
Zoltán Böszörményi







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



[OE-core] cargo-native do_fetch error

2021-11-06 Thread Zoltan Boszormenyi via lists.openembedded.org

I tried building my custom OS rebased on current master.

I got this error:

ERROR: cargo-native-1.56.0-r0 do_fetch: No checksum specified for 
'/data/genericx86-64-yocto-3.5/downloads/rustc-1.56.0-src.tar.xz', please add at least one 
to the recipe:

SRC_URI[rust.sha256sum] = 
"f13468889833c88e744ad579c5d8fbb7ecb53216159b54481a90e5dcdaa9e320"
ERROR: cargo-native-1.56.0-r0 do_fetch: Bitbake Fetcher Error: NoChecksumError('Missing 
SRC_URI checksum', 'https://static.rust-lang.org/dist/rustc-1.56.0-src.tar.xz;name=rust')
ERROR: Logfile of failure stored in: 
/data/genericx86-64-yocto-3.5/tmp-sicom-glibc/work/x86_64-linux/cargo-native/1.56.0-r0/temp/log.do_fetch.3495409
ERROR: Task 
(virtual:native:/data/genericx86-64-yocto-3.5/conf/../layers/openembedded-core/meta/recipes-devtools/cargo/cargo_1.56.0.bb:do_fetch) 
failed with exit code '1'


I found no bbappend for cargo or rust in any layers I currently use
so it must be a genuine bug in Yocto 3.5 at the moment.

Best regards,
Zoltán Böszörményi

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#157937): 
https://lists.openembedded.org/g/openembedded-core/message/157937
Mute This Topic: https://lists.openembedded.org/mt/86862283/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] libpam: Fix build with DISTRO_FEATURES usrmerge

2021-10-14 Thread Zoltan Boszormenyi via lists.openembedded.org

On 2021. 10. 13. 21:38, Dan McGregor wrote:

Thanks for this. I hit it pretty immediately.

On Tue, 12 Oct 2021 at 05:17, Zoltan Boszormenyi via
lists.openembedded.org  wrote:


From: Zoltán Böszörményi 

Signed-off-by: Zoltán Böszörményi 
---
  meta/recipes-extended/pam/libpam_1.5.2.bb | 6 --
  1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-extended/pam/libpam_1.5.2.bb 
b/meta/recipes-extended/pam/libpam_1.5.2.bb
index a3c4a50cb3..ee3a84a3b6 100644
--- a/meta/recipes-extended/pam/libpam_1.5.2.bb
+++ b/meta/recipes-extended/pam/libpam_1.5.2.bb
@@ -147,8 +147,10 @@ do_install() {
 if 
${@bb.utils.contains('DISTRO_FEATURES','systemd','true','false',d)}; then
 echo "session optional pam_systemd.so" >> 
${D}${sysconfdir}/pam.d/common-session
 fi
-install -d ${D}/${libdir}/
-   mv ${D}/${base_libdir}/pkgconfig ${D}/${libdir}/
+   if 
${@bb.utils.contains('DISTRO_FEATURES','usrmerge','false','true',d)}; then


In the patch I made that I kept local for now my condition was

if [ "${base_libdir}" != "${libdir}" ]

It could be that a user sets libdir and base_libdir to be equal
without enabling usrmerge, but both checks solve the immediate
problem.


Right, this is the correct solution.





+   install -d ${D}/${libdir}/
+   mv ${D}/${base_libdir}/pkgconfig ${D}/${libdir}/
+   fi
  }

  do_install_ptest() {
--
2.31.1











-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#156929): 
https://lists.openembedded.org/g/openembedded-core/message/156929
Mute This Topic: https://lists.openembedded.org/mt/86259670/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] libpam: Fix build with DISTRO_FEATURES usrmerge

2021-10-12 Thread Zoltan Boszormenyi via lists.openembedded.org
From: Zoltán Böszörményi 

Signed-off-by: Zoltán Böszörményi 
---
 meta/recipes-extended/pam/libpam_1.5.2.bb | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-extended/pam/libpam_1.5.2.bb 
b/meta/recipes-extended/pam/libpam_1.5.2.bb
index a3c4a50cb3..ee3a84a3b6 100644
--- a/meta/recipes-extended/pam/libpam_1.5.2.bb
+++ b/meta/recipes-extended/pam/libpam_1.5.2.bb
@@ -147,8 +147,10 @@ do_install() {
if ${@bb.utils.contains('DISTRO_FEATURES','systemd','true','false',d)}; 
then
echo "session optional pam_systemd.so" >> 
${D}${sysconfdir}/pam.d/common-session
fi
-install -d ${D}/${libdir}/
-   mv ${D}/${base_libdir}/pkgconfig ${D}/${libdir}/
+   if 
${@bb.utils.contains('DISTRO_FEATURES','usrmerge','false','true',d)}; then
+   install -d ${D}/${libdir}/
+   mv ${D}/${base_libdir}/pkgconfig ${D}/${libdir}/
+   fi
 }
 
 do_install_ptest() {
-- 
2.31.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#156873): 
https://lists.openembedded.org/g/openembedded-core/message/156873
Mute This Topic: https://lists.openembedded.org/mt/86259670/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 22/26] libpam: update 1.5.1 -> 1.5.2

2021-10-12 Thread Zoltan Boszormenyi via lists.openembedded.org

On 2021. 09. 08. 20:01, Alexander Kanavin wrote:

From: Alexander Kanavin 

Drop patches: issues fixed upstream.

Move .pc files to correct place as libpam is instructed to install them in /lib 
via
--libdir.

Signed-off-by: Alexander Kanavin 
---
  .../0001-Makefile.am-support-usrmage.patch| 28 ---
  ...space-Makefile.am-correctly-install-.patch | 28 ---
  .../pam/{libpam_1.5.1.bb => libpam_1.5.2.bb}  |  7 +++--
  3 files changed, 4 insertions(+), 59 deletions(-)
  delete mode 100644 
meta/recipes-extended/pam/libpam/0001-Makefile.am-support-usrmage.patch
  delete mode 100644 
meta/recipes-extended/pam/libpam/0001-modules-pam_namespace-Makefile.am-correctly-install-.patch
  rename meta/recipes-extended/pam/{libpam_1.5.1.bb => libpam_1.5.2.bb} (96%)

diff --git 
a/meta/recipes-extended/pam/libpam/0001-Makefile.am-support-usrmage.patch 
b/meta/recipes-extended/pam/libpam/0001-Makefile.am-support-usrmage.patch
deleted file mode 100644
index 5c6bc92705..00
--- a/meta/recipes-extended/pam/libpam/0001-Makefile.am-support-usrmage.patch
+++ /dev/null
@@ -1,28 +0,0 @@
-From c09e012590c1ec2d3b622b64f1bfc10a2286c9ea Mon Sep 17 00:00:00 2001
-From: Changqing Li 
-Date: Wed, 6 Jan 2021 12:08:20 +0800
-Subject: [PATCH] Makefile.am: support usrmage
-
-Upstream-Status: Inappropriate [oe-specific]
-
-Signed-off-by: Changqing Li 

- modules/pam_namespace/Makefile.am | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/modules/pam_namespace/Makefile.am 
b/modules/pam_namespace/Makefile.am
-index ddd5fc0..a1f1bec 100644
 a/modules/pam_namespace/Makefile.am
-+++ b/modules/pam_namespace/Makefile.am
-@@ -18,7 +18,7 @@ TESTS = $(dist_check_SCRIPTS)
- securelibdir = $(SECUREDIR)
- secureconfdir = $(SCONFIGDIR)
- namespaceddir = $(SCONFIGDIR)/namespace.d
--servicedir = /lib/systemd/system
-+servicedir = $(systemd_system_unitdir)
-
- AM_CFLAGS = -I$(top_srcdir)/libpam/include -I$(top_srcdir)/libpamc/include \
- -DSECURECONF_DIR=\"$(SCONFIGDIR)/\" $(WARN_CFLAGS)
---
-2.17.1
-
diff --git 
a/meta/recipes-extended/pam/libpam/0001-modules-pam_namespace-Makefile.am-correctly-install-.patch
 
b/meta/recipes-extended/pam/libpam/0001-modules-pam_namespace-Makefile.am-correctly-install-.patch
deleted file mode 100644
index b41d1e5962..00
--- 
a/meta/recipes-extended/pam/libpam/0001-modules-pam_namespace-Makefile.am-correctly-install-.patch
+++ /dev/null
@@ -1,28 +0,0 @@
-From e2db4082f6b988f1d5803028e9e47aee5f3519ac Mon Sep 17 00:00:00 2001
-From: Alexander Kanavin 
-Date: Sun, 27 Dec 2020 00:30:45 +0100
-Subject: [PATCH] modules/pam_namespace/Makefile.am: correctly install systemd
- unit file
-
-Upstream-Status: Pending
-Signed-off-by: Alexander Kanavin 

- modules/pam_namespace/Makefile.am | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/modules/pam_namespace/Makefile.am 
b/modules/pam_namespace/Makefile.am
-index 21e1b33..ddd5fc0 100644
 a/modules/pam_namespace/Makefile.am
-+++ b/modules/pam_namespace/Makefile.am
-@@ -18,7 +18,7 @@ TESTS = $(dist_check_SCRIPTS)
- securelibdir = $(SECUREDIR)
- secureconfdir = $(SCONFIGDIR)
- namespaceddir = $(SCONFIGDIR)/namespace.d
--servicedir = $(prefix)/lib/systemd/system
-+servicedir = /lib/systemd/system
-
- AM_CFLAGS = -I$(top_srcdir)/libpam/include -I$(top_srcdir)/libpamc/include \
- -DSECURECONF_DIR=\"$(SCONFIGDIR)/\" $(WARN_CFLAGS)
---
-2.24.0
-
diff --git a/meta/recipes-extended/pam/libpam_1.5.1.bb 
b/meta/recipes-extended/pam/libpam_1.5.2.bb
similarity index 96%
rename from meta/recipes-extended/pam/libpam_1.5.1.bb
rename to meta/recipes-extended/pam/libpam_1.5.2.bb
index efcd27137f..a3c4a50cb3 100644
--- a/meta/recipes-extended/pam/libpam_1.5.1.bb
+++ b/meta/recipes-extended/pam/libpam_1.5.2.bb
@@ -21,18 +21,17 @@ SRC_URI = 
"https://github.com/linux-pam/linux-pam/releases/download/v${PV}/Linux
 file://pam.d/common-session-noninteractive \
 file://pam.d/other \
 file://libpam-xtests.patch \
-   
file://0001-modules-pam_namespace-Makefile.am-correctly-install-.patch \
-   file://0001-Makefile.am-support-usrmage.patch \
 file://run-ptest \
 file://pam-volatiles.conf \
 "
  
-SRC_URI[sha256sum] = "201d40730b1135b1b3cdea09f2c28ac634d73181ccd0172ceddee3649c5792fc"

+SRC_URI[sha256sum] = 
"e4ec7131a91da44512574268f493c6d8ca105c87091691b8e9b56ca685d4f94d"
  
  DEPENDS = "bison-native flex flex-native cracklib libxml2-native virtual/crypt"
  
  EXTRA_OECONF = "--includedir=${includedir}/security \

  --libdir=${base_libdir} \
+--with-systemdunitdir=${systemd_system_unitdir} \
  --disable-nis \
  --disable-regenerate-docu \
  --disable-doc \
@@ -148,6 +147,8 @@ do_install() {
if ${@bb.utils.contains('DISTRO_FEATURES','systemd','true','false',d)}; 
then
echo "session optional pam_systemd.so" 

Re: [OE-core] [PATCH 1/2] python3-setuptools: update to 58.0.4

2021-10-12 Thread Zoltan Boszormenyi via lists.openembedded.org

This version broke at least python3-jsmin 2.2.2.

I am hitting this issue:

https://github.com/tikitu/jsmin/issues/33
"error in jsmin setup command: use_2to3 is invalid."

setuptools 58 removed support for use_2to3.
python3-jsmin must be upgraded to 3.0.0 as a result.

There be other fallouts, too.

On 2021. 09. 19. 0:18, Oleksandr Kravchuk wrote:

Signed-off-by: Oleksandr Kravchuk 
---
  ...ython3-setuptools_57.4.0.bb => python3-setuptools_58.0.4.bb} | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
  rename meta/recipes-devtools/python/{python3-setuptools_57.4.0.bb => 
python3-setuptools_58.0.4.bb} (94%)

diff --git a/meta/recipes-devtools/python/python3-setuptools_57.4.0.bb 
b/meta/recipes-devtools/python/python3-setuptools_58.0.4.bb
similarity index 94%
rename from meta/recipes-devtools/python/python3-setuptools_57.4.0.bb
rename to meta/recipes-devtools/python/python3-setuptools_58.0.4.bb
index ae45936c39..2000d355a9 100644
--- a/meta/recipes-devtools/python/python3-setuptools_57.4.0.bb
+++ b/meta/recipes-devtools/python/python3-setuptools_58.0.4.bb
@@ -10,7 +10,7 @@ SRC_URI:append:class-native = " 
file://0001-conditionally-do-not-fetch-code-by-e
  
  SRC_URI += "file://0001-change-shebang-to-python3.patch"
  
-SRC_URI[sha256sum] = "6bac238ffdf24e8806c61440e755192470352850f3419a52f26ffe0a1a64f465"

+SRC_URI[sha256sum] = 
"f10059f0152e0b7fb6b2edd77bcb1ecd4c9ed7048a826eb2d79f72fd2e6e237b"
  
  DEPENDS += "${PYTHON_PN}"
  









-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#156862): 
https://lists.openembedded.org/g/openembedded-core/message/156862
Mute This Topic: https://lists.openembedded.org/mt/85708588/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 1/2] kernel, kernel-module-split: Add runtime dependency to subpackages on main package

2021-10-05 Thread Zoltan Boszormenyi via lists.openembedded.org

On 2021. 10. 05. 12:18, Alexandre Belloni wrote:

Hello,

On 30/09/2021 16:14:43+0200, Zoltan Boszormenyi via lists.openembedded.org 
wrote:

From: Zoltán Böszörményi 

This creates a circular dependency between the main kernel package
and its subpackages. It helps package managers to automatically
remove all kernel packages of the same version when upgrading.

Signed-off-by: Zoltán Böszörményi 
---
v2: No changes

v3: Add reverse RDEPENDS to subpackages unconditionally
 Handle KERNEL_SPLIT_MODULES=1 (default) case in
 meta/classes/kernel-module-split.bbclass

  meta/classes/kernel-module-split.bbclass | 5 +++--
  meta/classes/kernel.bbclass  | 7 ++-
  2 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/meta/classes/kernel-module-split.bbclass 
b/meta/classes/kernel-module-split.bbclass
index a29c294810..2ddcea538c 100644
--- a/meta/classes/kernel-module-split.bbclass
+++ b/meta/classes/kernel-module-split.bbclass
@@ -176,8 +176,9 @@ python split_kernel_module_packages () {
  module_pattern = module_pattern_prefix + kernel_package_name + 
'-module-%s' + module_pattern_suffix
  
  modules = do_split_packages(d, root='${nonarch_base_libdir}/modules', file_regex=module_regex, output_pattern=module_pattern, description='%s kernel module', postinst=postinst, postrm=postrm, recursive=True, hook=frob_metadata, extra_depends='%s-%s' % (kernel_package_name, kernel_version))

-if modules:
-d.appendVar('RDEPENDS:' + metapkg, ' '+' '.join(modules))
+for mod in modules:
+d.appendVar('RDEPENDS:' + metapkg, ' %s (= ${EXTENDPKGV})' % mod)
+d.appendVar('RDEPENDS:' + mod, ' %s (= ${EXTENDPKGV})' % 
kernel_package_name)
  


I believe this causes the following issues:

https://autobuilder.yoctoproject.org/typhoon/#/builders/72/builds/4135/steps/18/logs/stdio

Error:
  Problem: package hello-mod-0.1-r0.qemux86_64 requires 
kernel-module-hello-5.14.6-yocto-standard = 0.1-r0, but none of the providers 
can be installed

https://autobuilder.yoctoproject.org/typhoon/#/builders/82/builds/2342/steps/11/logs/stdio

Error:
  Problem: package lttng-tools-ptest-2.13.0-r0.cortexa57 requires 
lttng-modules, but none of the providers can be installed
   - package lttng-modules-2.13.0-r0.qemuarm64 requires 
kernel-module-lttng-wrapper-5.14.6-yocto-standard = 2.13.0-r0, but none of the 
providers can be installed
   - conflicting requests
   - nothing provides kernel = 2.13.0-r0 needed by 
kernel-module-lttng-wrapper-5.14.6-yocto-standard-2.13.0-r0.qemuarm64
(try to add '--skip-broken' to skip uninstallable packages)


Arrggh. Externally built modules?

That exact ${EXTENDPKGV} match was intended only for
the kernel and its own modules.

An extra opt-out knob should be devised to be used
by such individual module recipes because their
full version may not match the kernel's.





  # If modules-load.d and modprobe.d are empty at this point, remove them to
  # avoid warnings. removedirs only raises an OSError if an empty
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 4acec1877e..afd9f8045e 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -98,7 +98,9 @@ python __anonymous () {
  typelower = type.lower()
  d.appendVar('PACKAGES', ' %s-image-%s' % (kname, typelower))
  d.setVar('FILES:' + kname + '-image-' + typelower, '/' + imagedest + 
'/' + type + '-${KERNEL_VERSION_NAME}' + ' /' + imagedest + '/' + type)
+d.appendVar('RDEPENDS:%s-image' % kname, ' %s (= ${EXTENDPKGV})' % 
kname)
  d.appendVar('RDEPENDS:%s-image' % kname, ' %s-image-%s (= 
${EXTENDPKGV})' % (kname, typelower))
+d.appendVar('RDEPENDS:%s-image-%s' % (kname, typelower), ' %s (= 
${EXTENDPKGV})' % kname)
  splitmods = d.getVar("KERNEL_SPLIT_MODULES")
  if splitmods != '1':
  d.appendVar('RDEPENDS:%s-image' % kname, ' %s-modules (= 
${EXTENDPKGV})' % kname)
@@ -627,8 +629,11 @@ RDEPENDS:${KERNEL_PACKAGE_NAME} = 
"${KERNEL_PACKAGE_NAME}-base (= ${EXTENDPKGV})
  # Allow machines to override this dependency if kernel image files are
  # not wanted in images as standard
  RDEPENDS:${KERNEL_PACKAGE_NAME}-base ?= "${KERNEL_PACKAGE_NAME}-image (= 
${EXTENDPKGV})"
+RDEPENDS:${KERNEL_PACKAGE_NAME}-base:append = " ${KERNEL_PACKAGE_NAME} (= 
${EXTENDPKGV})"
  PKG:${KERNEL_PACKAGE_NAME}-image = 
"${KERNEL_PACKAGE_NAME}-image-${@legitimize_package_name(d.getVar('KERNEL_VERSION'))}"
-RDEPENDS:${KERNEL_PACKAGE_NAME}-image += 
"${@oe.utils.conditional('KERNEL_IMAGETYPE', 'vmlinux', 
'${KERNEL_PACKAGE_NAME}-vmlinux (= ${EXTENDPKGV})', '', d)}"
+RDEPENDS:${KERNEL_PACKAGE_NAME}-image:append = 
"${@oe.utils.conditional('KERNEL_IMAGETYPE', 'vmlinux', ' 
${KERNEL_PACKAGE_NAME}-vmlinux (= ${EXTENDPKGV})', '', d)}"
+RDEPENDS:${KERNEL_PACKAGE_NAME}-vmlinux:append = 
"${@oe.utils.conditional('KERNEL_IMAGETYPE', 'vmli

[OE-core] [PATCH v3 2/2] kernel.bbclass: Allow using update-alternatives for the kernel image

2021-09-30 Thread Zoltan Boszormenyi via lists.openembedded.org
From: Zoltán Böszörményi 

When using dnf to install new kernel versions and installonly_limit
is reached, dnf automatically removes the oldest kernel version.
For the dnf.conf documentation on installonlypkgs, installonly_limit
and others settings, see:
https://dnf.readthedocs.io/en/latest/conf_ref.html

When this happens, the kernel image symlink is removed because
1) the postrm script uses rm -f /boot/ and
2) postrm for the old version is run later than postinst of
   the new one with dnf.

Obviously, it makes the system fail to boot the next time.
Theoretically, this may happen for any package manager.

Allow using the alternative symlink machinery so the highest
kernel version takes precedence and the symlink always stays
in place. This depends on the new variable called
KERNEL_IMAGEDEST_USE_UPDATE_ALTERNATIVES. If it's set to non-0
then update-alternatives is used. Default is 0.

Signed-off-by: Zoltán Böszörményi 
---
v2: Mention dnf.conf documentation link
Protect against "IndexError: list index out of range"

v3: Make update-alternatives --install work for do_rootfs
Move constructing alternative priority to a python function
Fix indentation of postinst/postrm scripts

 meta/classes/kernel.bbclass | 39 +++--
 1 file changed, 29 insertions(+), 10 deletions(-)

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index afd9f8045e..40f3361053 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -42,6 +42,16 @@ KERNEL_VERSION_NAME[vardepvalue] = "${LINUX_VERSION}"
 KERNEL_VERSION_PKG_NAME = 
"${@legitimize_package_name(d.getVar('KERNEL_VERSION'))}"
 KERNEL_VERSION_PKG_NAME[vardepvalue] = "${LINUX_VERSION}"
 
+def kernel_alternative_priority(d):
+import re
+kver =  d.getVar("KERNEL_VERSION")
+kverp = re.compile('[\.-]')
+kvparts = kverp.split(kver)
+if len(kvparts) >= 3:
+return 
str(kvparts[0])+str(kvparts[1]).zfill(2)+str(kvparts[2]).zfill(3)
+else:
+return "00"
+
 python __anonymous () {
 pn = d.getVar("PN")
 kpn = d.getVar("KERNEL_PACKAGE_NAME")
@@ -111,23 +121,31 @@ python __anonymous () {
 d.setVar('PKG:%s-image-%s' % (kname,typelower), 
'%s-image-%s-${KERNEL_VERSION_PKG_NAME}' % (kname, typelower))
 d.setVar('ALLOW_EMPTY:%s-image-%s' % (kname, typelower), '1')
 d.setVar('pkg_postinst:%s-image-%s' % (kname,typelower), """set +e
-if [ -n "$D" ]; then
-ln -sf %s-${KERNEL_VERSION} $D/${KERNEL_IMAGEDEST}/%s > /dev/null 2>&1
+if [ "${KERNEL_IMAGEDEST_USE_UPDATE_ALTERNATIVES}" != "0" ]; then
+update-alternatives --install /${KERNEL_IMAGEDEST}/%s %s 
%s-${KERNEL_VERSION_NAME} ${@kernel_alternative_priority(d)}
 else
-ln -sf %s-${KERNEL_VERSION} ${KERNEL_IMAGEDEST}/%s > /dev/null 2>&1
-if [ $? -ne 0 ]; then
-echo "Filesystem on ${KERNEL_IMAGEDEST}/ doesn't support symlinks, 
falling back to copied image (%s)."
-install -m 0644 ${KERNEL_IMAGEDEST}/%s-${KERNEL_VERSION} 
${KERNEL_IMAGEDEST}/%s
+if [ -n "$D" ]; then
+ln -sf %s-${KERNEL_VERSION} $D/${KERNEL_IMAGEDEST}/%s > /dev/null 2>&1
+else
+ln -sf %s-${KERNEL_VERSION} ${KERNEL_IMAGEDEST}/%s > /dev/null 2>&1
+if [ $? -ne 0 ]; then
+echo "Filesystem on ${KERNEL_IMAGEDEST}/ doesn't support symlinks, 
falling back to copied image (%s)."
+install -m 0644 ${KERNEL_IMAGEDEST}/%s-${KERNEL_VERSION} 
${KERNEL_IMAGEDEST}/%s
+fi
 fi
 fi
 set -e
-""" % (type, type, type, type, type, type, type))
+""" % (type, type, type, type, type, type, type, type, type, type))
 d.setVar('pkg_postrm:%s-image-%s' % (kname,typelower), """set +e
-if [ -f "${KERNEL_IMAGEDEST}/%s" -o -L "${KERNEL_IMAGEDEST}/%s" ]; then
-rm -f ${KERNEL_IMAGEDEST}/%s  > /dev/null 2>&1
+if [ "${KERNEL_IMAGEDEST_USE_UPDATE_ALTERNATIVES}" != "0" ]; then
+update-alternatives --remove %s %s-${KERNEL_VERSION_NAME}
+else
+if [ -f "${KERNEL_IMAGEDEST}/%s" -o -L "${KERNEL_IMAGEDEST}/%s" ]; then
+rm -f ${KERNEL_IMAGEDEST}/%s  > /dev/null 2>&1
+fi
 fi
 set -e
-""" % (type, type, type))
+""" % (type, type, type, type, type))
 
 
 image = d.getVar('INITRAMFS_IMAGE')
@@ -208,6 +226,7 @@ KERNEL_RELEASE ?= "${KERNEL_VERSION}"
 # The directory where built kernel lies in the kernel tree
 KERNEL_OUTPUT_DIR ?= "arch/${ARCH}/boot"
 KERNEL_IMAGEDEST ?= "boot"
+KERNEL_IMAGEDEST_USE_UPDATE_ALTERNATIVES ?= "0"
 
 #
 # configuration
-- 
2.31.1


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



[OE-core] [PATCH v3 1/2] kernel, kernel-module-split: Add runtime dependency to subpackages on main package

2021-09-30 Thread Zoltan Boszormenyi via lists.openembedded.org
From: Zoltán Böszörményi 

This creates a circular dependency between the main kernel package
and its subpackages. It helps package managers to automatically
remove all kernel packages of the same version when upgrading.

Signed-off-by: Zoltán Böszörményi 
---
v2: No changes

v3: Add reverse RDEPENDS to subpackages unconditionally
Handle KERNEL_SPLIT_MODULES=1 (default) case in
meta/classes/kernel-module-split.bbclass

 meta/classes/kernel-module-split.bbclass | 5 +++--
 meta/classes/kernel.bbclass  | 7 ++-
 2 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/meta/classes/kernel-module-split.bbclass 
b/meta/classes/kernel-module-split.bbclass
index a29c294810..2ddcea538c 100644
--- a/meta/classes/kernel-module-split.bbclass
+++ b/meta/classes/kernel-module-split.bbclass
@@ -176,8 +176,9 @@ python split_kernel_module_packages () {
 module_pattern = module_pattern_prefix + kernel_package_name + 
'-module-%s' + module_pattern_suffix
 
 modules = do_split_packages(d, root='${nonarch_base_libdir}/modules', 
file_regex=module_regex, output_pattern=module_pattern, description='%s kernel 
module', postinst=postinst, postrm=postrm, recursive=True, hook=frob_metadata, 
extra_depends='%s-%s' % (kernel_package_name, kernel_version))
-if modules:
-d.appendVar('RDEPENDS:' + metapkg, ' '+' '.join(modules))
+for mod in modules:
+d.appendVar('RDEPENDS:' + metapkg, ' %s (= ${EXTENDPKGV})' % mod)
+d.appendVar('RDEPENDS:' + mod, ' %s (= ${EXTENDPKGV})' % 
kernel_package_name)
 
 # If modules-load.d and modprobe.d are empty at this point, remove them to
 # avoid warnings. removedirs only raises an OSError if an empty
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 4acec1877e..afd9f8045e 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -98,7 +98,9 @@ python __anonymous () {
 typelower = type.lower()
 d.appendVar('PACKAGES', ' %s-image-%s' % (kname, typelower))
 d.setVar('FILES:' + kname + '-image-' + typelower, '/' + imagedest + 
'/' + type + '-${KERNEL_VERSION_NAME}' + ' /' + imagedest + '/' + type)
+d.appendVar('RDEPENDS:%s-image' % kname, ' %s (= ${EXTENDPKGV})' % 
kname)
 d.appendVar('RDEPENDS:%s-image' % kname, ' %s-image-%s (= 
${EXTENDPKGV})' % (kname, typelower))
+d.appendVar('RDEPENDS:%s-image-%s' % (kname, typelower), ' %s (= 
${EXTENDPKGV})' % kname)
 splitmods = d.getVar("KERNEL_SPLIT_MODULES")
 if splitmods != '1':
 d.appendVar('RDEPENDS:%s-image' % kname, ' %s-modules (= 
${EXTENDPKGV})' % kname)
@@ -627,8 +629,11 @@ RDEPENDS:${KERNEL_PACKAGE_NAME} = 
"${KERNEL_PACKAGE_NAME}-base (= ${EXTENDPKGV})
 # Allow machines to override this dependency if kernel image files are
 # not wanted in images as standard
 RDEPENDS:${KERNEL_PACKAGE_NAME}-base ?= "${KERNEL_PACKAGE_NAME}-image (= 
${EXTENDPKGV})"
+RDEPENDS:${KERNEL_PACKAGE_NAME}-base:append = " ${KERNEL_PACKAGE_NAME} (= 
${EXTENDPKGV})"
 PKG:${KERNEL_PACKAGE_NAME}-image = 
"${KERNEL_PACKAGE_NAME}-image-${@legitimize_package_name(d.getVar('KERNEL_VERSION'))}"
-RDEPENDS:${KERNEL_PACKAGE_NAME}-image += 
"${@oe.utils.conditional('KERNEL_IMAGETYPE', 'vmlinux', 
'${KERNEL_PACKAGE_NAME}-vmlinux (= ${EXTENDPKGV})', '', d)}"
+RDEPENDS:${KERNEL_PACKAGE_NAME}-image:append = 
"${@oe.utils.conditional('KERNEL_IMAGETYPE', 'vmlinux', ' 
${KERNEL_PACKAGE_NAME}-vmlinux (= ${EXTENDPKGV})', '', d)}"
+RDEPENDS:${KERNEL_PACKAGE_NAME}-vmlinux:append = 
"${@oe.utils.conditional('KERNEL_IMAGETYPE', 'vmlinux', ' 
${KERNEL_PACKAGE_NAME} (= ${EXTENDPKGV})', '', d)}"
+RDEPENDS:${KERNEL_PACKAGE_NAME}-modules:append = " ${KERNEL_PACKAGE_NAME} (= 
${EXTENDPKGV})"
 PKG:${KERNEL_PACKAGE_NAME}-base = 
"${KERNEL_PACKAGE_NAME}-${@legitimize_package_name(d.getVar('KERNEL_VERSION'))}"
 RPROVIDES:${KERNEL_PACKAGE_NAME}-base += 
"${KERNEL_PACKAGE_NAME}-${KERNEL_VERSION}"
 ALLOW_EMPTY:${KERNEL_PACKAGE_NAME} = "1"
-- 
2.31.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#156498): 
https://lists.openembedded.org/g/openembedded-core/message/156498
Mute This Topic: https://lists.openembedded.org/mt/85974630/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 [v3]: Make kernel upgrades via dnf work like on Red Hat

2021-09-30 Thread Zoltan Boszormenyi via lists.openembedded.org
I have observed two issues when upgrading kernel versions
successively.

One is that when installonly_limit is reached in dnf, only the
main kernel package was removed. Patch 1 fixes this by adding
extra RDEPENDS to the kernel subpackages on the main kernel package.
This circular dependency helps package managers to remove all subpackages.
Only rpm packages was build tested, the dependencies are in place for
both 0 and 1 for KERNEL_SPLIT_MODULES. dnf upgrade is doing the
right thing now with removing all subpackages of the oldest
kernel version.

dnf.conf settings "installonlypkgs", "installonly_limit" and
others are documented at https://dnf.readthedocs.io/en/latest/conf_ref.html

The second issue is that when the oldest kernel version is
removed by dnf, the /boot/bzImage symlink is also gone.
It seems that with dnf, postrm of the old version is run later
than postinst of the new one.

Fix this by using update-alternatives instead of hardcoded ln -s
and rm -f. This is configurable via a new variable.

This is still an RFC.

1) The first fix is applied in both cases of KERNEL_SPLIT_MODULES=0 and 1.
   It's applied unconditionally.

2) The new knob name for patch #2 is KERNEL_IMAGEDEST_USE_UPDATE_ALTERNATIVES.
   It is admittedly too chatty, it can be renamed if someone suggests
   a better name.

2) There's an extra issue I found while implementing the second patch:
   even with moving generating the alternative priority value to
   a python function and using a non-expanded substitution, it's
   still expanded during early parsing. The result is thrown away
   so it doesn't cause basehash issues, but still, the function
   needs to protect itself against KERNEL_VERSION being unset.

Please comment.

Best regards,
Zoltán Böszörményi



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



Re: [OE-core] [PATCH v2 2/2] kernel.bbclass: Allow using update-alternatives for the kernel image

2021-09-29 Thread Zoltan Boszormenyi via lists.openembedded.org

On 2021. 09. 29. 18:07, Bruce Ashfield wrote:

On Wed, Sep 29, 2021 at 1:34 AM Zoltán Böszörményi  wrote:


From: Zoltán Böszörményi 

When using dnf to install new kernel versions and installonly_limit
is reached, dnf automatically removes the oldest kernel version.

For the dnf.conf documentation on installonlypkgs, installonly_limit
and others settings, see:
https://dnf.readthedocs.io/en/latest/conf_ref.html

However, the /boot/bzImage symlink (or whatever image type is used)
is removed unconditionally.

Allow using the alternative symlink machinery so the highest
kernel version takes precedence and the symlink stays in place.

Signed-off-by: Zoltán Böszörményi 
---
v2: Mention dnf.conf documentation link
 Protect against "IndexError: list index out of range"


There were other comments / questions on v1 that were missed. I'll add them
in this reply again (at least in short form).

We also need to document the new variable that is controlling the functionality

As you mentioned in the RFC cover letter, If this only works with rpm
then that needs to be checked, and we shouldn't allow the enablement
to do anything if it doesn't work or if what update-alternatives + the
package manager of choice isn't fully understood in all cases.



  meta/classes/kernel.bbclass | 27 +--
  1 file changed, 25 insertions(+), 2 deletions(-)

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 882858e22e..47a78f0dd2 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -43,9 +43,23 @@ KERNEL_VERSION_PKG_NAME = 
"${@legitimize_package_name(d.getVar('KERNEL_VERSION')
  KERNEL_VERSION_PKG_NAME[vardepvalue] = "${LINUX_VERSION}"

  python __anonymous () {
+import re
  pn = d.getVar("PN")
  kpn = d.getVar("KERNEL_PACKAGE_NAME")

+# KERNEL_VERSION cannot be used here as it would cause
+# "basehash value changed" issues.
+kver =  d.getVar("PV")
+kverp = re.compile('[\.-]')
+kvparts = kverp.split(kver)
+# It seems PV is unset or empty for early recipe parsing
+# but __anonymous functions are run nevertheless.
+# Protect against "IndexError: list index out of range".
+if len(kvparts) >= 3:
+kverstr = 
str(kvparts[0])+str(kvparts[1]).zfill(2)+str(kvparts[2]).zfill(3)
+else:
+kverstr = '00'
+


I was asking about using something else than PV, since we are now up
to about three different variables being used to check versions. The
basehash question / issue is valid, but at this point we are packaging
based on something parsed out of the Makefile and then doing postinst
/ update alternatives steps based on PV. It is just going to cause a
lot of pain. And as you mentioned in your cover letter, it isn't
consistently used .. and hence we can't rely on it in this common
code.


That's why the series is RFC because the added inconsistency was painful to me.


I've asked around a bit, and we need to consider getting this code out
of the anonymous python completely. See how classes/fontcache.bbclass
uses PACKAGEFUNCS to create the postfunc steps. Since this isn't used
until packaging time, then it does need to move something that is run
in the proper context and we can avoid basehash and other issues.


I will look at it, thanks.


  # XXX Remove this after bug 11905 is resolved
  #  FILES:${KERNEL_PACKAGE_NAME}-dev doesn't expand correctly
  if kpn == pn:
@@ -117,6 +131,9 @@ python __anonymous () {
  d.setVar('PKG:%s-image-%s' % (kname,typelower), 
'%s-image-%s-${KERNEL_VERSION_PKG_NAME}' % (kname, typelower))
  d.setVar('ALLOW_EMPTY:%s-image-%s' % (kname, typelower), '1')
  d.setVar('pkg_postinst:%s-image-%s' % (kname,typelower), """set +e
+if [ "${KERNEL_IMAGEDEST_USE_UPDATE_ALTERNATIVES}" != "0" ]; then
+update-alternatives --install ${KERNEL_IMAGEDEST}/%s %s 
%s-${KERNEL_VERSION_NAME} %s
+else


Here is where I was asking about why this isn't checking $D like the
previous code block.  Unless we want this running on both the host and
the target, it needs a check.


The update-alternatives intercept script is installed for
for the image (to allow packages work that have "inherit
update-alternatives") and it's doing the right thing during
do_rootfs, internally dealing with $D.

Well, except for one thing, which is my fault here that
I discovered today after inspecting the resulting image.

The symlink path must be "/${KERNEL_IMAGEDEST}/%s".
The starter "/" is missing in v2, I will have to send a v3.

Well, here's "release often, release early" for you, with bugs and all.




  if [ -n "$D" ]; then


And now this block of code isn't indented and is in a big 'else'
block. Sure it is just a scriptlet, but it is getting hard to read and
follow.


I will fix the indentation.

Thanks for your comments,
Zoltán



Cheers,

Bruce


  ln -sf %s-${KERNEL_VERSION} $D/${KERNEL_IMAGEDEST}/%s > /dev/null 2>&1
  else
@@ -126,14 +143,19 @@ else
  install -m 

Re: [OE-core] RFC [v2]: Make kernel upgrades via dnf work like on Red Hat

2021-09-29 Thread Zoltan Boszormenyi via lists.openembedded.org

On 2021. 09. 29. 18:06, Bruce Ashfield wrote:

On Wed, Sep 29, 2021 at 1:34 AM Zoltán Böszörményi  wrote:


I have observed two issues when upgrading to kernel versions
successively.

One is that when installonly_limit is reached in dnf, only the
main kernel package was removed. Patch 1 fixes this by adding
extra RDEPENDS to the kernel subpackages on the main kernel package.
This circular dependency helps dnf to remove all subpackages.

dnf.conf settings "installonlypkgs", "installonly_limit" and
others are documented at https://dnf.readthedocs.io/en/latest/conf_ref.html

The second issue is that when the oldest kernel version is
removed by dnf, the /boot/bzImage symlink is also gone.

Fix this by using update-alternatives instead of hardcoded ln -s
and rm -f. This is configurable via a new variable.


I'll comment on patch 2/2 directly, but I have a few things here as well.



This is only an RFC at this point, because
1) The first fix is only applied in the KERNEL_SPLIT_MODULES=0 case,
it may need its own knob or applied unconditionally.


What is the outcome of the circular dependency you mention in patch
1/1 ? Does DNF warn, or something else ? What do the other package
managers do when the circular dependency is detected ?


No warning, it's just that the dnf transaction looks like this:

# dnf --disablerepo="*" install kernel-*
Dependencies resolved.

 Package ArchitectureVersionRepository Size

Installing:
 kernel  intel_corei7_64 5.14.8-r0.0@commandline  6.4 k
 kernel-5.14.8   intel_corei7_64 5.14.8-r0.0@commandline   48 k
 kernel-image-5.14.8 intel_corei7_64 5.14.8-r0.0@commandline  6.6 k
 kernel-image-bzimage-5.14.8 intel_corei7_64 5.14.8-r0.0@commandline  9.1 M
 kernel-modules-5.14.8   intel_corei7_64 5.14.8-r0.0@commandline   53 M
Removing:
 kernel  intel_corei7_64 5.14.5-r0.0@@commandline  88
Transaction Summary

Install  5 Packages
Remove   1 Packages
Total size: 75 M
Is this ok [y/N]:

instead of:

# dnf --disablerepo="*" install kernel-*
Dependencies resolved.

 Package ArchitectureVersionRepository Size

Installing:
 kernel  intel_corei7_64 5.14.8-r0.0@commandline  6.4 k
 kernel-5.14.8   intel_corei7_64 5.14.8-r0.0@commandline   48 k
 kernel-image-5.14.8 intel_corei7_64 5.14.8-r0.0@commandline  6.6 k
 kernel-image-bzimage-5.14.8 intel_corei7_64 5.14.8-r0.0@commandline  9.1 M
 kernel-modules-5.14.8   intel_corei7_64 5.14.8-r0.0@commandline   53 M
Removing:
 kernel  intel_corei7_64 5.14.5-r0.0@@commandline  88
Removing dependent packages:
 kernel-5.14.5   intel_corei7_64 5.14.5-r0.0@@commandline 222 k
 kernel-image-5.14.5 intel_corei7_64 5.14.5-r0.0@@commandline   0
 kernel-image-bzimage-5.14.5 intel_corei7_64 5.14.5-r0.0@@commandline 9.2 M
 kernel-modules-5.14.5   intel_corei7_64 5.14.5-r0.0@@commandline  52 M
Transaction Summary

Install  5 Packages
Remove   5 Packages
Total size: 75 M
Is this ok [y/N]:

Since the dependency matches the exact version via ${EXTENDPKGV},
I would expect other package managers to do what dnf is doing.

At least, IIRC, opkg built with libsolv does.


But yes, I agree that we really don't want any more conditional code
in the kernel packaging, since it isn't going to get tested. So
whatever we do needs to work on all package managers and with or
without kernel module splitting.



2) There's an extra issue I found while implementing the second patch:
instead of using KERNEL_VERSION, I had to resort to using PV
because the former is dynamically set via a python function
and it changes its value at some point between build phases.
AFAIK, there are kernel recipes out there using only the major
version with two numbers in PV instead of the full version triplet.
I can live with this as my kernel recipe uses the version triplet.

3) The new knob name for patch #2 is KERNEL_IMAGEDEST_USE_UPDATE_ALTERNATIVES.
It is admittedly too chatty, it can be renamed if someone suggests
a better name.


I'll ponder this as well, but nothing is immediately coming to mind.

Bruce



Please advise how to fix and make it final so these fixes can be
accepted into openembedded-core.

Best regards,
Zoltán Böszörményi








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

[OE-core] [PATCH v2 2/2] kernel.bbclass: Allow using update-alternatives for the kernel image

2021-09-28 Thread Zoltan Boszormenyi via lists.openembedded.org
From: Zoltán Böszörményi 

When using dnf to install new kernel versions and installonly_limit
is reached, dnf automatically removes the oldest kernel version.

For the dnf.conf documentation on installonlypkgs, installonly_limit
and others settings, see:
https://dnf.readthedocs.io/en/latest/conf_ref.html

However, the /boot/bzImage symlink (or whatever image type is used)
is removed unconditionally.

Allow using the alternative symlink machinery so the highest
kernel version takes precedence and the symlink stays in place.

Signed-off-by: Zoltán Böszörményi 
---
v2: Mention dnf.conf documentation link
Protect against "IndexError: list index out of range"

 meta/classes/kernel.bbclass | 27 +--
 1 file changed, 25 insertions(+), 2 deletions(-)

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 882858e22e..47a78f0dd2 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -43,9 +43,23 @@ KERNEL_VERSION_PKG_NAME = 
"${@legitimize_package_name(d.getVar('KERNEL_VERSION')
 KERNEL_VERSION_PKG_NAME[vardepvalue] = "${LINUX_VERSION}"
 
 python __anonymous () {
+import re
 pn = d.getVar("PN")
 kpn = d.getVar("KERNEL_PACKAGE_NAME")
 
+# KERNEL_VERSION cannot be used here as it would cause
+# "basehash value changed" issues.
+kver =  d.getVar("PV")
+kverp = re.compile('[\.-]')
+kvparts = kverp.split(kver)
+# It seems PV is unset or empty for early recipe parsing
+# but __anonymous functions are run nevertheless.
+# Protect against "IndexError: list index out of range".
+if len(kvparts) >= 3:
+kverstr = 
str(kvparts[0])+str(kvparts[1]).zfill(2)+str(kvparts[2]).zfill(3)
+else:
+kverstr = '00'
+
 # XXX Remove this after bug 11905 is resolved
 #  FILES:${KERNEL_PACKAGE_NAME}-dev doesn't expand correctly
 if kpn == pn:
@@ -117,6 +131,9 @@ python __anonymous () {
 d.setVar('PKG:%s-image-%s' % (kname,typelower), 
'%s-image-%s-${KERNEL_VERSION_PKG_NAME}' % (kname, typelower))
 d.setVar('ALLOW_EMPTY:%s-image-%s' % (kname, typelower), '1')
 d.setVar('pkg_postinst:%s-image-%s' % (kname,typelower), """set +e
+if [ "${KERNEL_IMAGEDEST_USE_UPDATE_ALTERNATIVES}" != "0" ]; then
+update-alternatives --install ${KERNEL_IMAGEDEST}/%s %s 
%s-${KERNEL_VERSION_NAME} %s
+else
 if [ -n "$D" ]; then
 ln -sf %s-${KERNEL_VERSION} $D/${KERNEL_IMAGEDEST}/%s > /dev/null 2>&1
 else
@@ -126,14 +143,19 @@ else
 install -m 0644 ${KERNEL_IMAGEDEST}/%s-${KERNEL_VERSION} 
${KERNEL_IMAGEDEST}/%s
 fi
 fi
+fi
 set -e
-""" % (type, type, type, type, type, type, type))
+""" % (type, type, type, kverstr, type, type, type, type, type, type, type))
 d.setVar('pkg_postrm:%s-image-%s' % (kname,typelower), """set +e
+if [ "${KERNEL_IMAGEDEST_USE_UPDATE_ALTERNATIVES}" != "0" ]; then
+update-alternatives --remove %s %s-${KERNEL_VERSION_NAME}
+else
 if [ -f "${KERNEL_IMAGEDEST}/%s" -o -L "${KERNEL_IMAGEDEST}/%s" ]; then
 rm -f ${KERNEL_IMAGEDEST}/%s  > /dev/null 2>&1
 fi
+fi
 set -e
-""" % (type, type, type))
+""" % (type, type, type, type, type))
 
 
 image = d.getVar('INITRAMFS_IMAGE')
@@ -214,6 +236,7 @@ KERNEL_RELEASE ?= "${KERNEL_VERSION}"
 # The directory where built kernel lies in the kernel tree
 KERNEL_OUTPUT_DIR ?= "arch/${ARCH}/boot"
 KERNEL_IMAGEDEST ?= "boot"
+KERNEL_IMAGEDEST_USE_UPDATE_ALTERNATIVES ?= "0"
 
 #
 # configuration
-- 
2.31.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#156446): 
https://lists.openembedded.org/g/openembedded-core/message/156446
Mute This Topic: https://lists.openembedded.org/mt/85942510/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 [v2]: Make kernel upgrades via dnf work like on Red Hat

2021-09-28 Thread Zoltan Boszormenyi via lists.openembedded.org
I have observed two issues when upgrading to kernel versions
successively.

One is that when installonly_limit is reached in dnf, only the
main kernel package was removed. Patch 1 fixes this by adding
extra RDEPENDS to the kernel subpackages on the main kernel package.
This circular dependency helps dnf to remove all subpackages.

dnf.conf settings "installonlypkgs", "installonly_limit" and
others are documented at https://dnf.readthedocs.io/en/latest/conf_ref.html

The second issue is that when the oldest kernel version is
removed by dnf, the /boot/bzImage symlink is also gone.

Fix this by using update-alternatives instead of hardcoded ln -s
and rm -f. This is configurable via a new variable.

This is only an RFC at this point, because
1) The first fix is only applied in the KERNEL_SPLIT_MODULES=0 case,
   it may need its own knob or applied unconditionally.

2) There's an extra issue I found while implementing the second patch:
   instead of using KERNEL_VERSION, I had to resort to using PV
   because the former is dynamically set via a python function
   and it changes its value at some point between build phases.
   AFAIK, there are kernel recipes out there using only the major
   version with two numbers in PV instead of the full version triplet.
   I can live with this as my kernel recipe uses the version triplet.

3) The new knob name for patch #2 is KERNEL_IMAGEDEST_USE_UPDATE_ALTERNATIVES.
   It is admittedly too chatty, it can be renamed if someone suggests
   a better name.

Please advise how to fix and make it final so these fixes can be
accepted into openembedded-core.

Best regards,
Zoltán Böszörményi



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



[OE-core] [PATCH v2 1/2] kernel.bbclass: Add runtime dependency to subpackages on main package

2021-09-28 Thread Zoltan Boszormenyi via lists.openembedded.org
From: Zoltán Böszörményi 

Although this creates a circular dependency between the main
kernel package and its subpackages, it helps dnf to automatically
remove all kernel packages of the same version.

Signed-off-by: Zoltán Böszörményi 
---
 meta/classes/kernel.bbclass | 8 
 1 file changed, 8 insertions(+)

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 4acec1877e..882858e22e 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -105,6 +105,14 @@ python __anonymous () {
 d.appendVar('RDEPENDS:%s-image-%s' % (kname, typelower), ' 
%s-modules-${KERNEL_VERSION_PKG_NAME} (= ${EXTENDPKGV})' % kname)
 d.setVar('PKG:%s-modules' % kname, 
'%s-modules-${KERNEL_VERSION_PKG_NAME}' % kname)
 d.appendVar('RPROVIDES:%s-modules' % kname, 
'%s-modules-${KERNEL_VERSION_PKG_NAME}' % kname)
+# Reverse RDEPENDS on main kernel package so dnf upgrades can 
honor installonly_limit
+# and remove all subpackages of old versions automatically
+d.appendVar('RDEPENDS:%s-base' % kname, ' %s (= ${EXTENDPKGV})' % 
kname)
+d.appendVar('RDEPENDS:%s-image' % kname, ' %s (= ${EXTENDPKGV})' % 
kname)
+d.appendVar('RDEPENDS:%s-image-%s' % (kname, typelower), ' %s (= 
${EXTENDPKGV})' % kname)
+d.appendVar('RDEPENDS:%s-modules' % kname, ' %s (= ${EXTENDPKGV})' 
% kname)
+if d.getVar('KERNEL_IMAGETYPE') == 'vmlinux':
+d.appendVar('RDEPENDS:%s-vmlinux' % kname,   ' %s (= 
${EXTENDPKGV})' % kname)
 
 d.setVar('PKG:%s-image-%s' % (kname,typelower), 
'%s-image-%s-${KERNEL_VERSION_PKG_NAME}' % (kname, typelower))
 d.setVar('ALLOW_EMPTY:%s-image-%s' % (kname, typelower), '1')
-- 
2.31.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#156445): 
https://lists.openembedded.org/g/openembedded-core/message/156445
Mute This Topic: https://lists.openembedded.org/mt/85942509/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.bbclass: Allow using update-alternatives for the kernel image

2021-09-28 Thread Zoltan Boszormenyi via lists.openembedded.org

On 2021. 09. 29. 6:18, Zoltan Boszormenyi via lists.openembedded.org wrote:

On 2021. 09. 29. 6:01, Böszörményi Zoltán wrote:

On 2021. 09. 28. 22:27, Bruce Ashfield wrote:

On Tue, Sep 28, 2021 at 10:16 AM Zoltan Boszormenyi via
lists.openembedded.org  wrote:

From: Zoltán Böszörményi 

When using dnf to install new kernel versions and installonly_limit
is reached, dnf automatically removes the oldest kernel version.

What about other package managers ? Is there a similar limit ? And
does the fallback still work the same ?


opkg definitely doesn't know about "install-only" entities.

I think apt has something like dnf, otherwise Debian and Ubuntu
wouldn't be able to offer a boot menu with fallback kernels.


I can't say that I'm aware of exactly what this dnf limit is, can we
either link to it, or document the value in the commit message ?


It's a konfiguration knob in /etc/dnf/dnf.conf:

[main]
...
installonly_limit=3
...


Sorry for not including the documentation link,
I was before my morning coffee. Here it is:

https://dnf.readthedocs.io/en/latest/conf_ref.html

Look for "installonlypkgs" and "installonly_limit".

FYI, "installonlypkgs" does include the package named
"kernel" by default and the value set in dnf.conf only
appends to the list of package names.

I will resend a v2 with this added to the commit message
and a fix for parsing/splitting PV, which also seems to
be unstable between very early parsing stages and later build
stages but it doesn't cause "basehash value changes" issues
but it does cause "IndexError: list index out of range"
when trying to use elements from the split PV array when
PV is likely not set yet.




And just so I understand, this is on the install (not the removal)
that dnf is removing the oldest kernel (by its versioning checks) when
the limit is hit ?


Yes.

One thing I didn't pursue is that on Fedora (and presumably RHEL)
the currently running kernel is exempted from removal. There may
be cases when you upgrade/install but not reboot with the latest
and it may occur that the currently running kernel is the oldest one.
In this case on Fedora, dnf removes the oldest version that's not
running. I think there's a complete kernel version check including
EXTRAVERSION (from the kernel toplevel Makefile) vs "uname -r".
In Yocto, the toplevel Makefile is not patched with the fully formed
PR value.


However, the /boot/bzImage symlink (or whatever image type is used)
is removed unconditionally.

And this removal, that's on the package uninstall ? or is that also a
dnf install quirk ?


That's on package uninstall and controlled by the postrm script
that the kernel.bbclass adds to the kernel-image-bzimage-
package, i.e. explicit
 ln -sf ... /boot/bzImage
to postinst and
 rm -f /boot/bzImage
to postrm.

This is modified to update-alternatives --install/--remove
if the newly added knob is set to 1. dnf can have multiple
kernel versions installed and the implicit ln -sf/rm -f is also
there for package managers that can keep only one version
from every package.

Now I also have a question. Is it only me, or this [PATCH 2/2]
didn't actually reach everyone?


Sorry, I meant "the other mails from this series besides [PATCH 2/2]"


I didn't receive the cover mail
and [PATCH 1/2] back from the mailing list, although I can see
them in the web archive:

https://lists.openembedded.org/g/openembedded-core/message/156420
https://lists.openembedded.org/g/openembedded-core/message/156419


Allow using the alternative symlink machinery so the highest
kernel version takes precedence and the symlink stays in place.

Signed-off-by: Zoltán Böszörményi 
---
  meta/classes/kernel.bbclass | 21 +++--
  1 file changed, 19 insertions(+), 2 deletions(-)

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index deccc0e58c..a687e5259d 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -43,9 +43,17 @@ KERNEL_VERSION_PKG_NAME = 
"${@legitimize_package_name(d.getVar('KERNEL_VERSION')

  KERNEL_VERSION_PKG_NAME[vardepvalue] = "${LINUX_VERSION}"

  python __anonymous () {
+    import re
  pn = d.getVar("PN")
  kpn = d.getVar("KERNEL_PACKAGE_NAME")

+    # KERNEL_VERSION cannot be used here as it would cause
+    # "basehash value changed" issues.
+    kver =  d.getVar("PV")
+    kverp = re.compile('[\.-]')
+    kvparts = kverp.split(kver)
+    kverstr = str(kvparts[0])+str(kvparts[1]).zfill(2)+str(kvparts[2]).zfill(3)

It would be really nice to avoid this logic, since in my years of
suffering, PV cannot be trusted on this front.

Why can't this use KERNEL_VERSION_PACKAGE_NAME ? It is already used in
this anonymous python code, and as the vardepexclude (which may just
be what you need to use KERNEL_VERSION directly).


+
  # XXX Remove this after bug 11905 is resolved
  #  FIL

Re: [OE-core] [PATCH 2/2] kernel.bbclass: Allow using update-alternatives for the kernel image

2021-09-28 Thread Zoltan Boszormenyi via lists.openembedded.org

On 2021. 09. 29. 6:01, Böszörményi Zoltán wrote:

On 2021. 09. 28. 22:27, Bruce Ashfield wrote:

On Tue, Sep 28, 2021 at 10:16 AM Zoltan Boszormenyi via
lists.openembedded.org  wrote:

From: Zoltán Böszörményi 

When using dnf to install new kernel versions and installonly_limit
is reached, dnf automatically removes the oldest kernel version.

What about other package managers ? Is there a similar limit ? And
does the fallback still work the same ?


opkg definitely doesn't know about "install-only" entities.

I think apt has something like dnf, otherwise Debian and Ubuntu
wouldn't be able to offer a boot menu with fallback kernels.


I can't say that I'm aware of exactly what this dnf limit is, can we
either link to it, or document the value in the commit message ?


It's a konfiguration knob in /etc/dnf/dnf.conf:

[main]
...
installonly_limit=3
...


And just so I understand, this is on the install (not the removal)
that dnf is removing the oldest kernel (by its versioning checks) when
the limit is hit ?


Yes.

One thing I didn't pursue is that on Fedora (and presumably RHEL)
the currently running kernel is exempted from removal. There may
be cases when you upgrade/install but not reboot with the latest
and it may occur that the currently running kernel is the oldest one.
In this case on Fedora, dnf removes the oldest version that's not
running. I think there's a complete kernel version check including
EXTRAVERSION (from the kernel toplevel Makefile) vs "uname -r".
In Yocto, the toplevel Makefile is not patched with the fully formed
PR value.


However, the /boot/bzImage symlink (or whatever image type is used)
is removed unconditionally.

And this removal, that's on the package uninstall ? or is that also a
dnf install quirk ?


That's on package uninstall and controlled by the postrm script
that the kernel.bbclass adds to the kernel-image-bzimage-
package, i.e. explicit
     ln -sf ... /boot/bzImage
to postinst and
     rm -f /boot/bzImage
to postrm.

This is modified to update-alternatives --install/--remove
if the newly added knob is set to 1. dnf can have multiple
kernel versions installed and the implicit ln -sf/rm -f is also
there for package managers that can keep only one version
from every package.

Now I also have a question. Is it only me, or this [PATCH 2/2]
didn't actually reach everyone?


Sorry, I meant "the other mails from this series besides [PATCH 2/2]"


I didn't receive the cover mail
and [PATCH 1/2] back from the mailing list, although I can see
them in the web archive:

https://lists.openembedded.org/g/openembedded-core/message/156420
https://lists.openembedded.org/g/openembedded-core/message/156419


Allow using the alternative symlink machinery so the highest
kernel version takes precedence and the symlink stays in place.

Signed-off-by: Zoltán Böszörményi 
---
  meta/classes/kernel.bbclass | 21 +++--
  1 file changed, 19 insertions(+), 2 deletions(-)

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index deccc0e58c..a687e5259d 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -43,9 +43,17 @@ KERNEL_VERSION_PKG_NAME = 
"${@legitimize_package_name(d.getVar('KERNEL_VERSION')

  KERNEL_VERSION_PKG_NAME[vardepvalue] = "${LINUX_VERSION}"

  python __anonymous () {
+    import re
  pn = d.getVar("PN")
  kpn = d.getVar("KERNEL_PACKAGE_NAME")

+    # KERNEL_VERSION cannot be used here as it would cause
+    # "basehash value changed" issues.
+    kver =  d.getVar("PV")
+    kverp = re.compile('[\.-]')
+    kvparts = kverp.split(kver)
+    kverstr = str(kvparts[0])+str(kvparts[1]).zfill(2)+str(kvparts[2]).zfill(3)

It would be really nice to avoid this logic, since in my years of
suffering, PV cannot be trusted on this front.

Why can't this use KERNEL_VERSION_PACKAGE_NAME ? It is already used in
this anonymous python code, and as the vardepexclude (which may just
be what you need to use KERNEL_VERSION directly).


+
  # XXX Remove this after bug 11905 is resolved
  #  FILES:${KERNEL_PACKAGE_NAME}-dev doesn't expand correctly
  if kpn == pn:
@@ -117,6 +125,9 @@ python __anonymous () {
  d.setVar('PKG:%s-image-%s' % (kname,typelower), 
'%s-image-%s-${KERNEL_VERSION_PKG_NAME}' % (kname, typelower))

  d.setVar('ALLOW_EMPTY:%s-image-%s' % (kname, typelower), '1')
  d.setVar('pkg_postinst:%s-image-%s' % (kname,typelower), """set +e
+if [ "${KERNEL_IMAGEDEST_USE_UPDATE_ALTERNATIVES}" != "0" ]; then
+    update-alternatives --install ${KERNEL_IMAGEDEST}/%s %s 
%s-${KERNEL_VERSION_NAME} %s
+else

I know it is just an inline postinst, but this is starting to get
unreadable quickly.

Shouldn't $D come into play here ? i.e. the existing postinst snippet
is taking it into account for doing the install, update alternatives
should also know if it is defined as well. Shou

Re: [OE-core] [PATCH 2/2] kernel.bbclass: Allow using update-alternatives for the kernel image

2021-09-28 Thread Zoltan Boszormenyi via lists.openembedded.org

Resending from the subscribed address.

On 2021. 09. 28. 22:27, Bruce Ashfield wrote:

On Tue, Sep 28, 2021 at 10:16 AM Zoltan Boszormenyi via
lists.openembedded.org  wrote:

From: Zoltán Böszörményi 

When using dnf to install new kernel versions and installonly_limit
is reached, dnf automatically removes the oldest kernel version.

What about other package managers ? Is there a similar limit ? And
does the fallback still work the same ?


opkg definitely doesn't know about "install-only" entities.

I think apt has something like dnf, otherwise Debian and Ubuntu
wouldn't be able to offer a boot menu with fallback kernels.


I can't say that I'm aware of exactly what this dnf limit is, can we
either link to it, or document the value in the commit message ?


It's a konfiguration knob in /etc/dnf/dnf.conf:

[main]
...
installonly_limit=3
...


And just so I understand, this is on the install (not the removal)
that dnf is removing the oldest kernel (by its versioning checks) when
the limit is hit ?


Yes.

One thing I didn't pursue is that on Fedora (and presumably RHEL)
the currently running kernel is exempted from removal. There may
be cases when you upgrade/install but not reboot with the latest
and it may occur that the currently running kernel is the oldest one.
In this case on Fedora, dnf removes the oldest version that's not
running. I think there's a complete kernel version check including
EXTRAVERSION (from the kernel toplevel Makefile) vs "uname -r".
In Yocto, the toplevel Makefile is not patched with the fully formed
PR value.


However, the /boot/bzImage symlink (or whatever image type is used)
is removed unconditionally.

And this removal, that's on the package uninstall ? or is that also a
dnf install quirk ?


That's on package uninstall and controlled by the postrm script
that the kernel.bbclass adds to the kernel-image-bzimage-
package, i.e. explicit
    ln -sf ... /boot/bzImage
to postinst and
    rm -f /boot/bzImage
to postrm.

This is modified to update-alternatives --install/--remove
if the newly added knob is set to 1. dnf can have multiple
kernel versions installed and the implicit ln -sf/rm -f is also
there for package managers that can keep only one version
from every package.

Now I also have a question. Is it only me, or this [PATCH 2/2]
didn't actually reach everyone? I didn't receive the cover mail
and [PATCH 1/2] back from the mailing list, although I can see
them in the web archive:

https://lists.openembedded.org/g/openembedded-core/message/156420
https://lists.openembedded.org/g/openembedded-core/message/156419


Allow using the alternative symlink machinery so the highest
kernel version takes precedence and the symlink stays in place.

Signed-off-by: Zoltán Böszörményi 
---
   meta/classes/kernel.bbclass | 21 +++--
   1 file changed, 19 insertions(+), 2 deletions(-)

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index deccc0e58c..a687e5259d 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -43,9 +43,17 @@ KERNEL_VERSION_PKG_NAME = 
"${@legitimize_package_name(d.getVar('KERNEL_VERSION')
   KERNEL_VERSION_PKG_NAME[vardepvalue] = "${LINUX_VERSION}"

   python __anonymous () {
+import re
   pn = d.getVar("PN")
   kpn = d.getVar("KERNEL_PACKAGE_NAME")

+# KERNEL_VERSION cannot be used here as it would cause
+# "basehash value changed" issues.
+kver =  d.getVar("PV")
+kverp = re.compile('[\.-]')
+kvparts = kverp.split(kver)
+kverstr = str(kvparts[0])+str(kvparts[1]).zfill(2)+str(kvparts[2]).zfill(3)

It would be really nice to avoid this logic, since in my years of
suffering, PV cannot be trusted on this front.

Why can't this use KERNEL_VERSION_PACKAGE_NAME ? It is already used in
this anonymous python code, and as the vardepexclude (which may just
be what you need to use KERNEL_VERSION directly).


+
   # XXX Remove this after bug 11905 is resolved
   #  FILES:${KERNEL_PACKAGE_NAME}-dev doesn't expand correctly
   if kpn == pn:
@@ -117,6 +125,9 @@ python __anonymous () {
   d.setVar('PKG:%s-image-%s' % (kname,typelower), 
'%s-image-%s-${KERNEL_VERSION_PKG_NAME}' % (kname, typelower))
   d.setVar('ALLOW_EMPTY:%s-image-%s' % (kname, typelower), '1')
   d.setVar('pkg_postinst:%s-image-%s' % (kname,typelower), """set +e
+if [ "${KERNEL_IMAGEDEST_USE_UPDATE_ALTERNATIVES}" != "0" ]; then
+update-alternatives --install ${KERNEL_IMAGEDEST}/%s %s 
%s-${KERNEL_VERSION_NAME} %s
+else

I know it is just an inline postinst, but this is starting to get
unreadable quickly.

Shouldn't $D come into play here ? i.e. the existing postinst snippet
is taking it into account for doing the install, update alternatives
should also know if it is defined as well. Shouldn't this be in the
else block of the [ -n "$D" ] test ? if it shouldn't, 

[OE-core] [PATCH 2/2] kernel.bbclass: Allow using update-alternatives for the kernel image

2021-09-28 Thread Zoltan Boszormenyi via lists.openembedded.org
From: Zoltán Böszörményi 

When using dnf to install new kernel versions and installonly_limit
is reached, dnf automatically removes the oldest kernel version.

However, the /boot/bzImage symlink (or whatever image type is used)
is removed unconditionally.

Allow using the alternative symlink machinery so the highest
kernel version takes precedence and the symlink stays in place.

Signed-off-by: Zoltán Böszörményi 
---
 meta/classes/kernel.bbclass | 21 +++--
 1 file changed, 19 insertions(+), 2 deletions(-)

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index deccc0e58c..a687e5259d 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -43,9 +43,17 @@ KERNEL_VERSION_PKG_NAME = 
"${@legitimize_package_name(d.getVar('KERNEL_VERSION')
 KERNEL_VERSION_PKG_NAME[vardepvalue] = "${LINUX_VERSION}"
 
 python __anonymous () {
+import re
 pn = d.getVar("PN")
 kpn = d.getVar("KERNEL_PACKAGE_NAME")
 
+# KERNEL_VERSION cannot be used here as it would cause
+# "basehash value changed" issues.
+kver =  d.getVar("PV")
+kverp = re.compile('[\.-]')
+kvparts = kverp.split(kver)
+kverstr = str(kvparts[0])+str(kvparts[1]).zfill(2)+str(kvparts[2]).zfill(3)
+
 # XXX Remove this after bug 11905 is resolved
 #  FILES:${KERNEL_PACKAGE_NAME}-dev doesn't expand correctly
 if kpn == pn:
@@ -117,6 +125,9 @@ python __anonymous () {
 d.setVar('PKG:%s-image-%s' % (kname,typelower), 
'%s-image-%s-${KERNEL_VERSION_PKG_NAME}' % (kname, typelower))
 d.setVar('ALLOW_EMPTY:%s-image-%s' % (kname, typelower), '1')
 d.setVar('pkg_postinst:%s-image-%s' % (kname,typelower), """set +e
+if [ "${KERNEL_IMAGEDEST_USE_UPDATE_ALTERNATIVES}" != "0" ]; then
+update-alternatives --install ${KERNEL_IMAGEDEST}/%s %s 
%s-${KERNEL_VERSION_NAME} %s
+else
 if [ -n "$D" ]; then
 ln -sf %s-${KERNEL_VERSION} $D/${KERNEL_IMAGEDEST}/%s > /dev/null 2>&1
 else
@@ -126,14 +137,19 @@ else
 install -m 0644 ${KERNEL_IMAGEDEST}/%s-${KERNEL_VERSION} 
${KERNEL_IMAGEDEST}/%s
 fi
 fi
+fi
 set -e
-""" % (type, type, type, type, type, type, type))
+""" % (type, type, type, kverstr, type, type, type, type, type, type, type))
 d.setVar('pkg_postrm:%s-image-%s' % (kname,typelower), """set +e
+if [ "${KERNEL_IMAGEDEST_USE_UPDATE_ALTERNATIVES}" != "0" ]; then
+update-alternatives --remove %s %s-${KERNEL_VERSION_NAME}
+else
 if [ -f "${KERNEL_IMAGEDEST}/%s" -o -L "${KERNEL_IMAGEDEST}/%s" ]; then
 rm -f ${KERNEL_IMAGEDEST}/%s  > /dev/null 2>&1
 fi
+fi
 set -e
-""" % (type, type, type))
+""" % (type, type, type, type, type))
 
 
 image = d.getVar('INITRAMFS_IMAGE')
@@ -214,6 +230,7 @@ KERNEL_RELEASE ?= "${KERNEL_VERSION}"
 # The directory where built kernel lies in the kernel tree
 KERNEL_OUTPUT_DIR ?= "arch/${ARCH}/boot"
 KERNEL_IMAGEDEST ?= "boot"
+KERNEL_IMAGEDEST_USE_UPDATE_ALTERNATIVES ?= "0"
 
 #
 # configuration
-- 
2.31.1


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



Re: [OE-core] [meta-security][PATCH] clamav: Set clamav:clamav ownership on /var/lib/clamav in do_install

2021-09-26 Thread Zoltan Boszormenyi via lists.openembedded.org

On 2021. 09. 26. 17:35, Armin Kuster wrote:



On 9/26/21 5:25 AM, Zoltán Böszörményi wrote:

From: Zoltán Böszörményi 

Also, rearrange the runtime-dependencies a little so
clamav-freshclam is installed later than clamav.

The issue is that clamav-freshclam ships /var/lib/clamav
and the main clamav package uses chown in pkg_postinst to set
the ownership of this directory. But pkg_postinst is not
marked as "ontarget" so this chown only took effect when
upgrading or reinstalling the package.

So when clamav is part of an OS image out of the box, freshclamd
cannot populate this directory since it's running under the clamav
user.

Fix this by creating /var/lib/clamav with the proper ownership
in do_install and rearrange runtime-dependencies, so clamav-freshclam
RDEPENDS on clamav and clamav relaxes its runtime-dependency into
RRECOMMENDS so clamav-freshclam is installed later than clamav,
avoiding these warnings:

   Installing   : clamav-freshclam-...487/1954
warning: user clamav does not exist - using root
warning: group clamav does not exist - using root

Signed-off-by: Zoltán Böszörményi 

This patch does not apply if I have the previous one applied. I see a
dup of the chown changes in the do_install step.
Can you clarify?


This patch is an alternative solution.
You can choose whichever you prefer.

Thanks,
Zoltán



-armin

---
  recipes-scanners/clamav/clamav_0.104.0.bb | 9 +
  1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/recipes-scanners/clamav/clamav_0.104.0.bb 
b/recipes-scanners/clamav/clamav_0.104.0.bb
index 0d3a678..25123dc 100644
--- a/recipes-scanners/clamav/clamav_0.104.0.bb
+++ b/recipes-scanners/clamav/clamav_0.104.0.bb
@@ -54,7 +54,7 @@ export OECMAKE_C_FLAGS += " -I${STAGING_INCDIR} -L 
${RECIPE_SYSROOT}${nonarch_li
  
  do_install:append () {

  install -d ${D}/${sysconfdir}
-install -d ${D}/${localstatedir}/lib/clamav
+install -d -o ${CLAMAV_UID} -g ${CLAMAV_GID} 
${D}/${localstatedir}/lib/clamav
  install -d ${D}${sysconfdir}/clamav ${D}${sysconfdir}/default/volatiles
  
  install -m 644 ${WORKDIR}/clamd.conf ${D}/${prefix}/${sysconfdir}

@@ -83,7 +83,6 @@ pkg_postinst:${PN} () {
  elif [ -e ${sysconfdir}/init.d/populate-volatile.sh ]; then
  ${sysconfdir}/init.d/populate-volatile.sh update
  fi
-chown -R ${CLAMAV_UID}:${CLAMAV_GID} ${localstatedir}/lib/clamav
  fi
  }
  
@@ -149,5 +148,7 @@ SYSTEMD_PACKAGES  = "${PN}-daemon ${PN}-freshclam"

  SYSTEMD_SERVICE:${PN}-daemon = "clamav-daemon.service"
  SYSTEMD_SERVICE:${PN}-freshclam = "clamav-freshclam.service"
  
-RDEPENDS:${PN} = "openssl ncurses-libncurses libxml2 libbz2 ncurses-libtinfo curl libpcre2 clamav-freshclam clamav-libclamav"

-RDEPENDS:${PN}-daemon = "clamav"
+RDEPENDS:${PN} = "openssl ncurses-libncurses libxml2 libbz2 ncurses-libtinfo curl 
libpcre2 clamav-libclamav"
+RRECOMMENDS:${PN} = "clamav-freshclam"
+RDEPENDS:${PN}-freshclam = "clamav"
+RDEPENDS:${PN}-daemon = "clamav clamav-freshclam"









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



[OE-core] Cover mail for "clamav: Set clamav:clamav ownership on /var/lib/clamav in do_install"

2021-09-26 Thread Zoltan Boszormenyi via lists.openembedded.org
Hi,

this is what Khem suggested. Please review.

Thanks in advance,
Zoltán Böszörményi



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



[OE-core] [meta-security][PATCH] clamav: Set clamav:clamav ownership on /var/lib/clamav in do_install

2021-09-26 Thread Zoltan Boszormenyi via lists.openembedded.org
From: Zoltán Böszörményi 

Also, rearrange the runtime-dependencies a little so
clamav-freshclam is installed later than clamav.

The issue is that clamav-freshclam ships /var/lib/clamav
and the main clamav package uses chown in pkg_postinst to set
the ownership of this directory. But pkg_postinst is not
marked as "ontarget" so this chown only took effect when
upgrading or reinstalling the package.

So when clamav is part of an OS image out of the box, freshclamd
cannot populate this directory since it's running under the clamav
user.

Fix this by creating /var/lib/clamav with the proper ownership
in do_install and rearrange runtime-dependencies, so clamav-freshclam
RDEPENDS on clamav and clamav relaxes its runtime-dependency into
RRECOMMENDS so clamav-freshclam is installed later than clamav,
avoiding these warnings:

  Installing   : clamav-freshclam-...487/1954
warning: user clamav does not exist - using root
warning: group clamav does not exist - using root

Signed-off-by: Zoltán Böszörményi 
---
 recipes-scanners/clamav/clamav_0.104.0.bb | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/recipes-scanners/clamav/clamav_0.104.0.bb 
b/recipes-scanners/clamav/clamav_0.104.0.bb
index 0d3a678..25123dc 100644
--- a/recipes-scanners/clamav/clamav_0.104.0.bb
+++ b/recipes-scanners/clamav/clamav_0.104.0.bb
@@ -54,7 +54,7 @@ export OECMAKE_C_FLAGS += " -I${STAGING_INCDIR} -L 
${RECIPE_SYSROOT}${nonarch_li
 
 do_install:append () {
 install -d ${D}/${sysconfdir}
-install -d ${D}/${localstatedir}/lib/clamav
+install -d -o ${CLAMAV_UID} -g ${CLAMAV_GID} 
${D}/${localstatedir}/lib/clamav
 install -d ${D}${sysconfdir}/clamav ${D}${sysconfdir}/default/volatiles
 
 install -m 644 ${WORKDIR}/clamd.conf ${D}/${prefix}/${sysconfdir}
@@ -83,7 +83,6 @@ pkg_postinst:${PN} () {
 elif [ -e ${sysconfdir}/init.d/populate-volatile.sh ]; then
 ${sysconfdir}/init.d/populate-volatile.sh update
 fi
-chown -R ${CLAMAV_UID}:${CLAMAV_GID} ${localstatedir}/lib/clamav
 fi
 }
 
@@ -149,5 +148,7 @@ SYSTEMD_PACKAGES  = "${PN}-daemon ${PN}-freshclam"
 SYSTEMD_SERVICE:${PN}-daemon = "clamav-daemon.service"
 SYSTEMD_SERVICE:${PN}-freshclam = "clamav-freshclam.service"
 
-RDEPENDS:${PN} = "openssl ncurses-libncurses libxml2 libbz2 ncurses-libtinfo 
curl libpcre2 clamav-freshclam clamav-libclamav"
-RDEPENDS:${PN}-daemon = "clamav"
+RDEPENDS:${PN} = "openssl ncurses-libncurses libxml2 libbz2 ncurses-libtinfo 
curl libpcre2 clamav-libclamav"
+RRECOMMENDS:${PN} = "clamav-freshclam"
+RDEPENDS:${PN}-freshclam = "clamav"
+RDEPENDS:${PN}-daemon = "clamav clamav-freshclam"
-- 
2.31.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#156360): 
https://lists.openembedded.org/g/openembedded-core/message/156360
Mute This Topic: https://lists.openembedded.org/mt/85877808/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] user/group XXX does not exist, using root with RPM/DNF packaging in Hardknott and Honister

2021-09-25 Thread Zoltan Boszormenyi via lists.openembedded.org

On 2021. 09. 25. 11:18, Richard Purdie wrote:

On Sat, 2021-09-25 at 10:48 +0200, Zoltan Boszormenyi via lists.openembedded.org
wrote:

On 2021. 09. 24. 19:17, Mark Hatle wrote:



On 9/24/21 9:02 AM, Zoltan Boszormenyi via lists.openembedded.org wrote:

Hi,

I have a special package that creates users and groups
via inherit useradd. This package doesn't depend on any
others but it is depended on, both via DEPENDS and RDEPENDS
by packages using those users/groups in their do_install
scripts.

This works for packaging becase these ownerships
are encoded in the packages, confirmed by rpm -qp --dump ...


Does it show the useradd in the _PREINSTALL_ (you can use --scriptlets in the
rpm -qp)?


For the package that adds the users, yes.




However, during do_rootfs, a couple of
"user/group XXX does not exist, using root"
messages appear for the packages depending on others
creating these users/groups.


Do the using packages contain RDEPENDS on the package that adds the user/group
to the system?


My bad. One of my custom packages did not and the
warnings were printed by that single package.

On the other hand, clamav-freshclam (both in meta-security
and my layer where I forked an older version of the recipe)
do not have an RDEPENDS on clamav. Instead, it's the other
way around.

There the problem is that clamav-freshclam is shipping
/var/lib/clamav that should be owned by clamav:clamav.
meta-security works this around badly by using chown in its
pkg_postinst which is NOT marked as "ontarget" so if clamav
is included in an image, then that chown doesn't take effect
and e.g. freshclamd (running under the clamav user) cannot
populate /var/lib/clamav with the current virus database.




That sounds like a bug in clamav-freshclam which needs a dependency adding?


Or just move /var/lib/clamav (the empty directory)
from clamav-freshclam to clamav.



Cheers,

Richard








-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#156351): 
https://lists.openembedded.org/g/openembedded-core/message/156351
Mute This Topic: https://lists.openembedded.org/mt/85839631/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] user/group XXX does not exist, using root with RPM/DNF packaging in Hardknott and Honister

2021-09-25 Thread Zoltan Boszormenyi via lists.openembedded.org

On 2021. 09. 24. 19:17, Mark Hatle wrote:



On 9/24/21 9:02 AM, Zoltan Boszormenyi via lists.openembedded.org wrote:

Hi,

I have a special package that creates users and groups
via inherit useradd. This package doesn't depend on any
others but it is depended on, both via DEPENDS and RDEPENDS
by packages using those users/groups in their do_install
scripts.

This works for packaging becase these ownerships
are encoded in the packages, confirmed by rpm -qp --dump ...


Does it show the useradd in the _PREINSTALL_ (you can use --scriptlets in the
rpm -qp)?


For the package that adds the users, yes.




However, during do_rootfs, a couple of
"user/group XXX does not exist, using root"
messages appear for the packages depending on others
creating these users/groups.


Do the using packages contain RDEPENDS on the package that adds the user/group
to the system?


My bad. One of my custom packages did not and the
warnings were printed by that single package.

On the other hand, clamav-freshclam (both in meta-security
and my layer where I forked an older version of the recipe)
do not have an RDEPENDS on clamav. Instead, it's the other
way around.

There the problem is that clamav-freshclam is shipping
/var/lib/clamav that should be owned by clamav:clamav.
meta-security works this around badly by using chown in its
pkg_postinst which is NOT marked as "ontarget" so if clamav
is included in an image, then that chown doesn't take effect
and e.g. freshclamd (running under the clamav user) cannot
populate /var/lib/clamav with the current virus database.




log.do_rootfs shows that the package installation ordering
does not follow RDEPENDS. Instead, it's practically an
alphabetical order when running dnf.

This doesn't just involve my custom packages, but also clamav
plus another one in which I ship a small limited set of
virus signatures, also chown'd to clamav and with RDEPENDS
on clamav.

What is the correct solution to this?


Typically the combination of the pre-install scriptlet, along with RDEPENDS will
ensure that the user has been added before the install completes.

--Mark


Thanks in advance,
Zoltán Böszörményi












-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#156341): 
https://lists.openembedded.org/g/openembedded-core/message/156341
Mute This Topic: https://lists.openembedded.org/mt/85839631/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] user/group XXX does not exist, using root with RPM/DNF packaging in Hardknott and Honister

2021-09-24 Thread Zoltan Boszormenyi via lists.openembedded.org

On 2021. 09. 24. 18:22, Khem Raj wrote:



On 9/24/21 7:02 AM, Böszörményi Zoltán wrote:

Hi,

I have a special package that creates users and groups
via inherit useradd. This package doesn't depend on any
others but it is depended on, both via DEPENDS and RDEPENDS
by packages using those users/groups in their do_install
scripts.

This works for packaging becase these ownerships
are encoded in the packages, confirmed by rpm -qp --dump ...

However, during do_rootfs, a couple of
"user/group XXX does not exist, using root"
messages appear for the packages depending on others
creating these users/groups.

log.do_rootfs shows that the package installation ordering
does not follow RDEPENDS. Instead, it's practically an
alphabetical order when running dnf.

This doesn't just involve my custom packages, but also clamav
plus another one in which I ship a small limited set of
virus signatures, also chown'd to clamav and with RDEPENDS
on clamav.

What is the correct solution to this?


You can define it via conf metadata e.g.

INHERIT += "extrausers"


EXTRA_USERS_PARAMS += "\
     useradd foo; \
     usermod -p '' foo; \
     usermod -a -G adm foo; \
     usermod -a -G video foo; \
     usermod -a -G audio foo; \
     usermod -a -G systemd-journal foo; \
"


Thanks, I will try it.
You mean local.conf or layer.conf?






Thanks in advance,
Zoltán Böszörményi








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



[OE-core] user/group XXX does not exist, using root with RPM/DNF packaging in Hardknott and Honister

2021-09-24 Thread Zoltan Boszormenyi via lists.openembedded.org

Hi,

I have a special package that creates users and groups
via inherit useradd. This package doesn't depend on any
others but it is depended on, both via DEPENDS and RDEPENDS
by packages using those users/groups in their do_install
scripts.

This works for packaging becase these ownerships
are encoded in the packages, confirmed by rpm -qp --dump ...

However, during do_rootfs, a couple of
"user/group XXX does not exist, using root"
messages appear for the packages depending on others
creating these users/groups.

log.do_rootfs shows that the package installation ordering
does not follow RDEPENDS. Instead, it's practically an
alphabetical order when running dnf.

This doesn't just involve my custom packages, but also clamav
plus another one in which I ship a small limited set of
virus signatures, also chown'd to clamav and with RDEPENDS
on clamav.

What is the correct solution to this?

Thanks in advance,
Zoltán Böszörményi

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



Re: [OE-core] [PATCH v4 3/4] kernel.bbclass: Use full versions for inter-package dependencies

2021-08-30 Thread Zoltan Boszormenyi via lists.openembedded.org

2021. 08. 30. 21:51 keltezéssel, Jon Mason írta:

On Mon, Aug 30, 2021 at 6:26 AM Andrey Zhizhikin  wrote:


On Mon, Aug 30, 2021 at 12:06 PM Böszörményi Zoltán  wrote:


2021. 08. 30. 11:30 keltezéssel, Andrey Zhizhikin írta:

Hello Zoltan,

On Fri, Aug 27, 2021 at 9:37 AM Zoltan Boszormenyi via
lists.openembedded.org  wrote:

From: Zoltán Böszörményi 

If the kernel configuration enables module signing but no key
is provided, then the kernel generates one during the kernel build.

The current runtime-dependency references (with only package names
without full versions) allow mixed package installations from different
rebuilds of the same kernel version.

This creates an issue because then the modules either don't work
or taint the kernel.

Tighten RDEPENDS with the full package version, i.e. use (= ${EXTENDPKGV})
markers for inter-package dependencies.

The kernel will pull in the kernel-modules subpackage of the same
exact version automatically if KERNEL_SPLIT_MODULES="0" is set.
Otherwise the situation is the same as with the old default with
one subpackage per kernel module where they have to be upgraded
manually.

Signed-off-by: Zoltán Böszörményi 
---
   meta/classes/kernel.bbclass | 13 +++--
   1 file changed, 7 insertions(+), 6 deletions(-)


I'm seeing errors during the do_rootfs() with this patch applied,
there are few messages like this:

   * Solver encountered 1 problem(s):
   * Problem 1/1:
   *   - package 
kernel-module-libchacha-5.13.13+g91381833a4e2-5.13.13+git0+91381833a4-r0.imx8mp_lpddr4_evk
requires kernel-5.13.13+g91381833a4e2, but none of the providers can
be installed
   *   - package kernel-modules-5.13.13+git0+91381833a4-r0.imx8mp_lpddr4_evk
requires kernel-module-libchacha-5.13.13+g91381833a4e2, but none of
the providers can be installed
   *   - package 
kernel-5.13.13+g91381833a4e2-5.13.13+git0+91381833a4-r0.imx8mp_lpddr4_evk
requires kernel-image-5.13.13+g91381833a4e2 =
5.13.13+git0+91381833a4-r0, but none of the providers can be installed
   *   - conflicting requests
   *   - nothing provides kernel-image-image-5.13.13+g91381833a4e2 =
5.13.13+gitAUTOINC+91381833a4-r0 needed by


This seems to be the problem.
Is there a "kernel-image-image-5.13.13" built from your kernel recipe?


Yes, it is produced. But for some reasons opkg cannot resolve it
during the do_rootfs(), which is quite odd.


I'm seeing the same issue.  All of the BSPs that I set the kernel to
not be 5.13 (i.e., 5.10, 5.4, etc) fail.  For example,
https://gitlab.com/jonmason00/meta-arm/-/jobs/1544819828
If I set the PACKAGE_CLASS to be rpm instead of ipk, everything works
as expected.  So, there must be some difference in the dep calculation
in ipk.


Interesting.

Can you both please try setting KERNEL_SPLIT_MODULES="0" in your kernel recipe?
In my testing, it works for both ipk and rpm properly.

I am thinking that probably the full version dependency should
only be used in the KERNEL_SPLIT_MODULES="0" case.
This can be easily tested, unlike the packaging method.





Thanks,
Jon


For me, a kernel-image-bzimage-x.y.z is built.


kernel-image-5.13.13+g91381833a4e2-5.13.13+git0+91381833a4-r0.imx8mp_lpddr4_evk
   *
   * Solution 1:
   *   - do not ask to install a package providing kernel-modules

Reverting this commit does solve it, but I would like to understand
more on what should be done in order to use this new mechanism you've
introduced. Do you have any suggestion on what should be adapted in
the BSP layer to have those RDEPENDS properly resolved?

Package manager is set for me to IPK.

Setting KERNEL_SPLIT_MODULES="1" does not solve the issue.


This is the default.
But setting it to "0" won't change whether the
kernel-image-image-x.y.z subpackage gets built or not.




--
Regards,
Andrey.










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



Re: [OE-core] [PATCH v4 3/4] kernel.bbclass: Use full versions for inter-package dependencies

2021-08-30 Thread Zoltan Boszormenyi via lists.openembedded.org

2021. 08. 30. 11:30 keltezéssel, Andrey Zhizhikin írta:

Hello Zoltan,

On Fri, Aug 27, 2021 at 9:37 AM Zoltan Boszormenyi via
lists.openembedded.org  wrote:

From: Zoltán Böszörményi 

If the kernel configuration enables module signing but no key
is provided, then the kernel generates one during the kernel build.

The current runtime-dependency references (with only package names
without full versions) allow mixed package installations from different
rebuilds of the same kernel version.

This creates an issue because then the modules either don't work
or taint the kernel.

Tighten RDEPENDS with the full package version, i.e. use (= ${EXTENDPKGV})
markers for inter-package dependencies.

The kernel will pull in the kernel-modules subpackage of the same
exact version automatically if KERNEL_SPLIT_MODULES="0" is set.
Otherwise the situation is the same as with the old default with
one subpackage per kernel module where they have to be upgraded
manually.

Signed-off-by: Zoltán Böszörményi 
---
   meta/classes/kernel.bbclass | 13 +++--
   1 file changed, 7 insertions(+), 6 deletions(-)


I'm seeing errors during the do_rootfs() with this patch applied,
there are few messages like this:

   * Solver encountered 1 problem(s):
   * Problem 1/1:
   *   - package 
kernel-module-libchacha-5.13.13+g91381833a4e2-5.13.13+git0+91381833a4-r0.imx8mp_lpddr4_evk
requires kernel-5.13.13+g91381833a4e2, but none of the providers can
be installed
   *   - package kernel-modules-5.13.13+git0+91381833a4-r0.imx8mp_lpddr4_evk
requires kernel-module-libchacha-5.13.13+g91381833a4e2, but none of
the providers can be installed
   *   - package 
kernel-5.13.13+g91381833a4e2-5.13.13+git0+91381833a4-r0.imx8mp_lpddr4_evk
requires kernel-image-5.13.13+g91381833a4e2 =
5.13.13+git0+91381833a4-r0, but none of the providers can be installed
   *   - conflicting requests
   *   - nothing provides kernel-image-image-5.13.13+g91381833a4e2 =
5.13.13+gitAUTOINC+91381833a4-r0 needed by


This seems to be the problem.
Is there a "kernel-image-image-5.13.13" built from your kernel recipe?
For me, a kernel-image-bzimage-x.y.z is built.


kernel-image-5.13.13+g91381833a4e2-5.13.13+git0+91381833a4-r0.imx8mp_lpddr4_evk
   *
   * Solution 1:
   *   - do not ask to install a package providing kernel-modules

Reverting this commit does solve it, but I would like to understand
more on what should be done in order to use this new mechanism you've
introduced. Do you have any suggestion on what should be adapted in
the BSP layer to have those RDEPENDS properly resolved?

Package manager is set for me to IPK.

Setting KERNEL_SPLIT_MODULES="1" does not solve the issue.


This is the default.
But setting it to "0" won't change whether the
kernel-image-image-x.y.z subpackage gets built or not.



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#155483): 
https://lists.openembedded.org/g/openembedded-core/message/155483
Mute This Topic: https://lists.openembedded.org/mt/85181063/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 v4 4/4] Support zstd-compressed squashfs and cpio initramfs

2021-08-27 Thread Zoltan Boszormenyi via lists.openembedded.org
From: Zoltán Böszörményi 

Enable zstd PACKAGECONFIG knob for squashfs-tools.

Signed-off-by: Zoltán Böszörményi 
---
 meta/classes/base.bbclass  |  4 
 meta/classes/image_types.bbclass   |  6 --
 meta/classes/kernel-fitimage.bbclass   |  2 +-
 meta/classes/kernel.bbclass| 10 --
 .../squashfs-tools/squashfs-tools_git.bb   |  2 +-
 5 files changed, 18 insertions(+), 6 deletions(-)

diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index 11b65171d9..340ebe7d78 100644
--- a/meta/classes/base.bbclass
+++ b/meta/classes/base.bbclass
@@ -631,6 +631,10 @@ python () {
 if path.endswith('.lz4'):
 d.appendVarFlag('do_unpack', 'depends', ' 
lz4-native:do_populate_sysroot')
 
+# *.zst should DEPEND on zstd-native for unpacking
+elif path.endswith('.zst'):
+d.appendVarFlag('do_unpack', 'depends', ' 
zstd-native:do_populate_sysroot')
+
 # *.lz should DEPEND on lzip-native for unpacking
 elif path.endswith('.lz'):
 d.appendVarFlag('do_unpack', 'depends', ' 
lzip-native:do_populate_sysroot')
diff --git a/meta/classes/image_types.bbclass b/meta/classes/image_types.bbclass
index e0eb06c1e3..32d4cd4c76 100644
--- a/meta/classes/image_types.bbclass
+++ b/meta/classes/image_types.bbclass
@@ -107,6 +107,7 @@ IMAGE_CMD:squashfs = "mksquashfs ${IMAGE_ROOTFS} 
${IMGDEPLOYDIR}/${IMAGE_NAME}${
 IMAGE_CMD:squashfs-xz = "mksquashfs ${IMAGE_ROOTFS} 
${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.squashfs-xz ${EXTRA_IMAGECMD} 
-noappend -comp xz"
 IMAGE_CMD:squashfs-lzo = "mksquashfs ${IMAGE_ROOTFS} 
${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.squashfs-lzo 
${EXTRA_IMAGECMD} -noappend -comp lzo"
 IMAGE_CMD:squashfs-lz4 = "mksquashfs ${IMAGE_ROOTFS} 
${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.squashfs-lz4 
${EXTRA_IMAGECMD} -noappend -comp lz4"
+IMAGE_CMD:squashfs-zst = "mksquashfs ${IMAGE_ROOTFS} 
${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.squashfs-zst 
${EXTRA_IMAGECMD} -noappend -comp zstd"
 
 IMAGE_CMD:erofs = "mkfs.erofs ${EXTRA_IMAGECMD} 
${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.erofs ${IMAGE_ROOTFS}"
 IMAGE_CMD:erofs-lz4 = "mkfs.erofs -zlz4 ${EXTRA_IMAGECMD} 
${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.erofs-lz4 ${IMAGE_ROOTFS}"
@@ -244,6 +245,7 @@ do_image_squashfs[depends] += 
"squashfs-tools-native:do_populate_sysroot"
 do_image_squashfs_xz[depends] += "squashfs-tools-native:do_populate_sysroot"
 do_image_squashfs_lzo[depends] += "squashfs-tools-native:do_populate_sysroot"
 do_image_squashfs_lz4[depends] += "squashfs-tools-native:do_populate_sysroot"
+do_image_squashfs_zst[depends] += "squashfs-tools-native:do_populate_sysroot"
 do_image_ubi[depends] += "mtd-utils-native:do_populate_sysroot"
 do_image_ubifs[depends] += "mtd-utils-native:do_populate_sysroot"
 do_image_multiubi[depends] += "mtd-utils-native:do_populate_sysroot"
@@ -262,10 +264,10 @@ IMAGE_TYPES = " \
 btrfs \
 iso \
 hddimg \
-squashfs squashfs-xz squashfs-lzo squashfs-lz4 \
+squashfs squashfs-xz squashfs-lzo squashfs-lz4 squashfs-zst \
 ubi ubifs multiubi \
 tar tar.gz tar.bz2 tar.xz tar.lz4 tar.zst \
-cpio cpio.gz cpio.xz cpio.lzma cpio.lz4 \
+cpio cpio.gz cpio.xz cpio.lzma cpio.lz4 cpio.zst \
 wic wic.gz wic.bz2 wic.lzma wic.zst \
 container \
 f2fs \
diff --git a/meta/classes/kernel-fitimage.bbclass 
b/meta/classes/kernel-fitimage.bbclass
index 2ef8f06b14..38e05153e3 100644
--- a/meta/classes/kernel-fitimage.bbclass
+++ b/meta/classes/kernel-fitimage.bbclass
@@ -576,7 +576,7 @@ fitimage_assemble() {
#
if [ "x${ramdiskcount}" = "x1" ] && [ "${INITRAMFS_IMAGE_BUNDLE}" != 
"1" ]; then
# Find and use the first initramfs image archive type we find
-   for img in cpio.lz4 cpio.lzo cpio.lzma cpio.xz cpio.gz ext2.gz 
cpio; do
+   for img in cpio.lz4 cpio.lzo cpio.lzma cpio.xz cpio.zst cpio.gz 
ext2.gz cpio; do

initramfs_path="${DEPLOY_DIR_IMAGE}/${INITRAMFS_IMAGE_NAME}.${img}"
echo "Using $initramfs_path"
if [ -e "${initramfs_path}" ]; then
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 9ec7daa17a..ab60e060c6 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -9,6 +9,7 @@ PROVIDES += "${@ "virtual/kernel" if 
(d.getVar("KERNEL_PACKAGE_NAME") == "kernel
 DEPENDS += "virtual/${TARGET_PREFIX}binutils virtual/${TARGET_PREFIX}gcc 
kmod-native bc-native bison-native"
 DEPENDS += "${@bb.utils.contains("INITRAMFS_FSTYPES", "cpio.lzo", 
"lzop-native", "", d)}"
 DEPENDS += "${@bb.utils.contains("INITRAMFS_FSTYPES", "cpio.lz4", 
"lz4-native", "", d)}"
+DEPENDS += "${@bb.utils.contains("INITRAMFS_FSTYPES", "cpio.zst", 
"zstd-native", "", d)}"
 PACKAGE_WRITE_DEPS += "depmodwrapper-cross"
 
 

[OE-core] [PATCH v4 3/4] kernel.bbclass: Use full versions for inter-package dependencies

2021-08-27 Thread Zoltan Boszormenyi via lists.openembedded.org
From: Zoltán Böszörményi 

If the kernel configuration enables module signing but no key
is provided, then the kernel generates one during the kernel build.

The current runtime-dependency references (with only package names
without full versions) allow mixed package installations from different
rebuilds of the same kernel version.

This creates an issue because then the modules either don't work
or taint the kernel.

Tighten RDEPENDS with the full package version, i.e. use (= ${EXTENDPKGV})
markers for inter-package dependencies.

The kernel will pull in the kernel-modules subpackage of the same
exact version automatically if KERNEL_SPLIT_MODULES="0" is set.
Otherwise the situation is the same as with the old default with
one subpackage per kernel module where they have to be upgraded
manually.

Signed-off-by: Zoltán Böszörményi 
---
 meta/classes/kernel.bbclass | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 6dc5387a9b..9ec7daa17a 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -91,17 +91,18 @@ python __anonymous () {
 kname = d.getVar('KERNEL_PACKAGE_NAME') or "kernel"
 imagedest = d.getVar('KERNEL_IMAGEDEST')
 
+fullver = d.getVar('EXTENDPKGV')
 for type in types.split():
 if bb.data.inherits_class('nopackages', d):
 continue
 typelower = type.lower()
 d.appendVar('PACKAGES', ' %s-image-%s' % (kname, typelower))
 d.setVar('FILES:' + kname + '-image-' + typelower, '/' + imagedest + 
'/' + type + '-${KERNEL_VERSION_NAME}' + ' /' + imagedest + '/' + type)
-d.appendVar('RDEPENDS:%s-image' % kname, ' %s-image-%s' % (kname, 
typelower))
+d.appendVar('RDEPENDS:%s-image' % kname, ' %s-image-%s (= %s)' % 
(kname, typelower, fullver))
 splitmods = d.getVar("KERNEL_SPLIT_MODULES")
 if splitmods != '1':
-d.appendVar('RDEPENDS:%s-image' % kname, ' %s-modules' % kname)
-d.appendVar('RDEPENDS:%s-image-%s' % (kname, typelower), ' 
%s-modules-${KERNEL_VERSION_PKG_NAME}' % kname)
+d.appendVar('RDEPENDS:%s-image' % kname, ' %s-modules (= %s)' % 
(kname, fullver))
+d.appendVar('RDEPENDS:%s-image-%s' % (kname, typelower), ' 
%s-modules-${KERNEL_VERSION_PKG_NAME} (= %s)' % (kname, fullver))
 d.setVar('PKG:%s-modules' % kname, 
'%s-modules-${KERNEL_VERSION_PKG_NAME}' % kname)
 d.appendVar('RPROVIDES:%s-modules' % kname, 
'%s-modules-${KERNEL_VERSION_PKG_NAME}' % kname)
 
@@ -628,12 +629,12 @@ FILES:${KERNEL_PACKAGE_NAME}-image = ""
 FILES:${KERNEL_PACKAGE_NAME}-dev = "/boot/System.map* /boot/Module.symvers* 
/boot/config* ${KERNEL_SRC_PATH} 
${nonarch_base_libdir}/modules/${KERNEL_VERSION}/build"
 FILES:${KERNEL_PACKAGE_NAME}-vmlinux = "/boot/vmlinux-${KERNEL_VERSION_NAME}"
 FILES:${KERNEL_PACKAGE_NAME}-modules = ""
-RDEPENDS:${KERNEL_PACKAGE_NAME} = "${KERNEL_PACKAGE_NAME}-base"
+RDEPENDS:${KERNEL_PACKAGE_NAME} = "${KERNEL_PACKAGE_NAME}-base (= 
${EXTENDPKGV})"
 # Allow machines to override this dependency if kernel image files are
 # not wanted in images as standard
-RDEPENDS:${KERNEL_PACKAGE_NAME}-base ?= "${KERNEL_PACKAGE_NAME}-image"
+RDEPENDS:${KERNEL_PACKAGE_NAME}-base ?= "${KERNEL_PACKAGE_NAME}-image (= 
${EXTENDPKGV})"
 PKG:${KERNEL_PACKAGE_NAME}-image = 
"${KERNEL_PACKAGE_NAME}-image-${@legitimize_package_name(d.getVar('KERNEL_VERSION'))}"
-RDEPENDS:${KERNEL_PACKAGE_NAME}-image += 
"${@oe.utils.conditional('KERNEL_IMAGETYPE', 'vmlinux', 
'${KERNEL_PACKAGE_NAME}-vmlinux', '', d)}"
+RDEPENDS:${KERNEL_PACKAGE_NAME}-image += 
"${@oe.utils.conditional('KERNEL_IMAGETYPE', 'vmlinux', 
'${KERNEL_PACKAGE_NAME}-vmlinux (= ${EXTENDPKGV})', '', d)}"
 PKG:${KERNEL_PACKAGE_NAME}-base = 
"${KERNEL_PACKAGE_NAME}-${@legitimize_package_name(d.getVar('KERNEL_VERSION'))}"
 RPROVIDES:${KERNEL_PACKAGE_NAME}-base += 
"${KERNEL_PACKAGE_NAME}-${KERNEL_VERSION}"
 ALLOW_EMPTY:${KERNEL_PACKAGE_NAME} = "1"
-- 
2.31.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#155395): 
https://lists.openembedded.org/g/openembedded-core/message/155395
Mute This Topic: https://lists.openembedded.org/mt/85181063/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 v4 2/4] Allow opt-out of split kernel modules

2021-08-27 Thread Zoltan Boszormenyi via lists.openembedded.org
From: Zoltán Böszörményi 

For some use cases, a monolithic kernel-modules package containing
all modules built from the kernel sources may be preferred.
For one, download time is shorter and installation time is faster.

Set KERNEL_SPLIT_MODULES="0" for this in. The default is one subpackage
per module.

Also, adapt kernel.bbclass to KERNEL_SPLIT_MODULES != "1" case
Extra RDEPENDS and other inter-package references are needed in
this case.

Signed-off-by: Zoltán Böszörményi 
---
 meta/classes/kernel-module-split.bbclass | 17 +
 meta/classes/kernel.bbclass  |  7 +++
 2 files changed, 20 insertions(+), 4 deletions(-)

diff --git a/meta/classes/kernel-module-split.bbclass 
b/meta/classes/kernel-module-split.bbclass
index 6c1de4c992..a29c294810 100644
--- a/meta/classes/kernel-module-split.bbclass
+++ b/meta/classes/kernel-module-split.bbclass
@@ -28,6 +28,7 @@ do_install:append() {
install -d ${D}${sysconfdir}/modules-load.d/ 
${D}${sysconfdir}/modprobe.d/
 }
 
+KERNEL_SPLIT_MODULES ?= "1"
 PACKAGESPLITFUNCS:prepend = "split_kernel_module_packages "
 
 KERNEL_MODULES_META_PACKAGE ?= "${@ d.getVar("KERNEL_PACKAGE_NAME") or 
"kernel" }-modules"
@@ -156,18 +157,26 @@ python split_kernel_module_packages () {
 kernel_package_name = d.getVar("KERNEL_PACKAGE_NAME") or "kernel"
 kernel_version = d.getVar("KERNEL_VERSION")
 
+metapkg = d.getVar('KERNEL_MODULES_META_PACKAGE')
+splitmods = d.getVar('KERNEL_SPLIT_MODULES')
+postinst = d.getVar('pkg_postinst:modules')
+postrm = d.getVar('pkg_postrm:modules')
+
+if splitmods != '1':
+etcdir = d.getVar('sysconfdir')
+d.appendVar('FILES:' + metapkg, '%s/modules-load.d/ %s/modprobe.d/ 
%s/modules/' % (etcdir, etcdir, d.getVar("nonarch_base_libdir")))
+d.appendVar('pkg_postinst:%s' % metapkg, postinst)
+d.prependVar('pkg_postrm:%s' % metapkg, postrm);
+return
+
 module_regex = r'^(.*)\.k?o(?:\.(gz|xz|zst))?$'
 
 module_pattern_prefix = d.getVar('KERNEL_MODULE_PACKAGE_PREFIX')
 module_pattern_suffix = d.getVar('KERNEL_MODULE_PACKAGE_SUFFIX')
 module_pattern = module_pattern_prefix + kernel_package_name + 
'-module-%s' + module_pattern_suffix
 
-postinst = d.getVar('pkg_postinst:modules')
-postrm = d.getVar('pkg_postrm:modules')
-
 modules = do_split_packages(d, root='${nonarch_base_libdir}/modules', 
file_regex=module_regex, output_pattern=module_pattern, description='%s kernel 
module', postinst=postinst, postrm=postrm, recursive=True, hook=frob_metadata, 
extra_depends='%s-%s' % (kernel_package_name, kernel_version))
 if modules:
-metapkg = d.getVar('KERNEL_MODULES_META_PACKAGE')
 d.appendVar('RDEPENDS:' + metapkg, ' '+' '.join(modules))
 
 # If modules-load.d and modprobe.d are empty at this point, remove them to
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 027e66eec7..6dc5387a9b 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -98,6 +98,13 @@ python __anonymous () {
 d.appendVar('PACKAGES', ' %s-image-%s' % (kname, typelower))
 d.setVar('FILES:' + kname + '-image-' + typelower, '/' + imagedest + 
'/' + type + '-${KERNEL_VERSION_NAME}' + ' /' + imagedest + '/' + type)
 d.appendVar('RDEPENDS:%s-image' % kname, ' %s-image-%s' % (kname, 
typelower))
+splitmods = d.getVar("KERNEL_SPLIT_MODULES")
+if splitmods != '1':
+d.appendVar('RDEPENDS:%s-image' % kname, ' %s-modules' % kname)
+d.appendVar('RDEPENDS:%s-image-%s' % (kname, typelower), ' 
%s-modules-${KERNEL_VERSION_PKG_NAME}' % kname)
+d.setVar('PKG:%s-modules' % kname, 
'%s-modules-${KERNEL_VERSION_PKG_NAME}' % kname)
+d.appendVar('RPROVIDES:%s-modules' % kname, 
'%s-modules-${KERNEL_VERSION_PKG_NAME}' % kname)
+
 d.setVar('PKG:%s-image-%s' % (kname,typelower), 
'%s-image-%s-${KERNEL_VERSION_PKG_NAME}' % (kname, typelower))
 d.setVar('ALLOW_EMPTY:%s-image-%s' % (kname, typelower), '1')
 d.setVar('pkg_postinst:%s-image-%s' % (kname,typelower), """set +e
-- 
2.31.1


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



[OE-core] Kernel and image related bbclass changes

2021-08-27 Thread Zoltan Boszormenyi via lists.openembedded.org
I have been carrying some forked bbclass recipes and I think
these can be beneficial to others, not to mention that I could
get rid of the private forks of these.

v2:
- drop the package_rpm.bbclass / posttrans patch
- squash the previous patches #3 and #4 together (patch #2 now)
- more verbose commit message for patch #3 (previously patch #5)

v3:
- fix commit message for patch #3 (stupid copy)

v4:
- enable PACKAGECONFIG=zstd for squashfs-tools in patch #4



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#155392): 
https://lists.openembedded.org/g/openembedded-core/message/155392
Mute This Topic: https://lists.openembedded.org/mt/85181058/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 v4 1/4] kernel-module-split.bbclass: Support zstd-compressed modules

2021-08-27 Thread Zoltan Boszormenyi via lists.openembedded.org
From: Zoltán Böszörményi 

Signed-off-by: Zoltán Böszörményi 
---
 meta/classes/kernel-module-split.bbclass | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/meta/classes/kernel-module-split.bbclass 
b/meta/classes/kernel-module-split.bbclass
index b56dd4a9c7..6c1de4c992 100644
--- a/meta/classes/kernel-module-split.bbclass
+++ b/meta/classes/kernel-module-split.bbclass
@@ -44,17 +44,20 @@ python split_kernel_module_packages () {
 def extract_modinfo(file):
 import tempfile, subprocess
 tempfile.tempdir = d.getVar("WORKDIR")
-compressed = re.match( r'.*\.([xg])z$', file)
+compressed = re.match( r'.*\.(gz|xz|zst)$', file)
 tf = tempfile.mkstemp()
 tmpfile = tf[1]
 if compressed:
 tmpkofile = tmpfile + ".ko"
-if compressed.group(1) == 'g':
+if compressed.group(1) == 'gz':
 cmd = "gunzip -dc %s > %s" % (file, tmpkofile)
 subprocess.check_call(cmd, shell=True)
-elif compressed.group(1) == 'x':
+elif compressed.group(1) == 'xz':
 cmd = "xz -dc %s > %s" % (file, tmpkofile)
 subprocess.check_call(cmd, shell=True)
+elif compressed.group(1) == 'zst':
+cmd = "zstd -dc %s > %s" % (file, tmpkofile)
+subprocess.check_call(cmd, shell=True)
 else:
 msg = "Cannot decompress '%s'" % file
 raise msg
@@ -153,7 +156,7 @@ python split_kernel_module_packages () {
 kernel_package_name = d.getVar("KERNEL_PACKAGE_NAME") or "kernel"
 kernel_version = d.getVar("KERNEL_VERSION")
 
-module_regex = r'^(.*)\.k?o(?:\.[xg]z)?$'
+module_regex = r'^(.*)\.k?o(?:\.(gz|xz|zst))?$'
 
 module_pattern_prefix = d.getVar('KERNEL_MODULE_PACKAGE_PREFIX')
 module_pattern_suffix = d.getVar('KERNEL_MODULE_PACKAGE_SUFFIX')
-- 
2.31.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#155393): 
https://lists.openembedded.org/g/openembedded-core/message/155393
Mute This Topic: https://lists.openembedded.org/mt/85181059/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 4/4] Support zstd-compressed squashfs and cpio initramfs

2021-08-27 Thread Zoltan Boszormenyi via lists.openembedded.org

Yeah, squashfs-tools needs PACKAGECONFIG = "zstd" by default.
I will send an updated series soon with this patch updated.

2021. 08. 26. 14:04 keltezéssel, Richard Purdie írta:

On Mon, 2021-08-23 at 16:54 +0200, Zoltan Boszormenyi via lists.openembedded.org
wrote:

From: Zoltán Böszörményi 

Signed-off-by: Zoltán Böszörményi 
---
  meta/classes/base.bbclass|  4 
  meta/classes/image_types.bbclass |  6 --
  meta/classes/kernel-fitimage.bbclass |  2 +-
  meta/classes/kernel.bbclass  | 10 --
  4 files changed, 17 insertions(+), 5 deletions(-)

diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index 11b65171d9..340ebe7d78 100644
--- a/meta/classes/base.bbclass
+++ b/meta/classes/base.bbclass
@@ -631,6 +631,10 @@ python () {
  if path.endswith('.lz4'):
  d.appendVarFlag('do_unpack', 'depends', ' 
lz4-native:do_populate_sysroot')
  
+# *.zst should DEPEND on zstd-native for unpacking

+elif path.endswith('.zst'):
+d.appendVarFlag('do_unpack', 'depends', ' 
zstd-native:do_populate_sysroot')
+
  # *.lz should DEPEND on lzip-native for unpacking
  elif path.endswith('.lz'):
  d.appendVarFlag('do_unpack', 'depends', ' 
lzip-native:do_populate_sysroot')
diff --git a/meta/classes/image_types.bbclass b/meta/classes/image_types.bbclass
index e0eb06c1e3..32d4cd4c76 100644
--- a/meta/classes/image_types.bbclass
+++ b/meta/classes/image_types.bbclass
@@ -107,6 +107,7 @@ IMAGE_CMD:squashfs = "mksquashfs ${IMAGE_ROOTFS} 
${IMGDEPLOYDIR}/${IMAGE_NAME}${
  IMAGE_CMD:squashfs-xz = "mksquashfs ${IMAGE_ROOTFS} 
${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.squashfs-xz ${EXTRA_IMAGECMD} -noappend 
-comp xz"
  IMAGE_CMD:squashfs-lzo = "mksquashfs ${IMAGE_ROOTFS} 
${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.squashfs-lzo ${EXTRA_IMAGECMD} 
-noappend -comp lzo"
  IMAGE_CMD:squashfs-lz4 = "mksquashfs ${IMAGE_ROOTFS} 
${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.squashfs-lz4 ${EXTRA_IMAGECMD} 
-noappend -comp lz4"
+IMAGE_CMD:squashfs-zst = "mksquashfs ${IMAGE_ROOTFS} 
${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.squashfs-zst ${EXTRA_IMAGECMD} 
-noappend -comp zstd"
  
  IMAGE_CMD:erofs = "mkfs.erofs ${EXTRA_IMAGECMD} ${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.erofs ${IMAGE_ROOTFS}"

  IMAGE_CMD:erofs-lz4 = "mkfs.erofs -zlz4 ${EXTRA_IMAGECMD} 
${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.erofs-lz4 ${IMAGE_ROOTFS}"
@@ -244,6 +245,7 @@ do_image_squashfs[depends] += 
"squashfs-tools-native:do_populate_sysroot"
  do_image_squashfs_xz[depends] += "squashfs-tools-native:do_populate_sysroot"
  do_image_squashfs_lzo[depends] += "squashfs-tools-native:do_populate_sysroot"
  do_image_squashfs_lz4[depends] += "squashfs-tools-native:do_populate_sysroot"
+do_image_squashfs_zst[depends] += "squashfs-tools-native:do_populate_sysroot"
  do_image_ubi[depends] += "mtd-utils-native:do_populate_sysroot"
  do_image_ubifs[depends] += "mtd-utils-native:do_populate_sysroot"
  do_image_multiubi[depends] += "mtd-utils-native:do_populate_sysroot"
@@ -262,10 +264,10 @@ IMAGE_TYPES = " \
  btrfs \
  iso \
  hddimg \
-squashfs squashfs-xz squashfs-lzo squashfs-lz4 \
+squashfs squashfs-xz squashfs-lzo squashfs-lz4 squashfs-zst \
  ubi ubifs multiubi \
  tar tar.gz tar.bz2 tar.xz tar.lz4 tar.zst \
-cpio cpio.gz cpio.xz cpio.lzma cpio.lz4 \
+cpio cpio.gz cpio.xz cpio.lzma cpio.lz4 cpio.zst \
  wic wic.gz wic.bz2 wic.lzma wic.zst \
  container \
  f2fs \
diff --git a/meta/classes/kernel-fitimage.bbclass 
b/meta/classes/kernel-fitimage.bbclass
index 2ef8f06b14..38e05153e3 100644
--- a/meta/classes/kernel-fitimage.bbclass
+++ b/meta/classes/kernel-fitimage.bbclass
@@ -576,7 +576,7 @@ fitimage_assemble() {
#
if [ "x${ramdiskcount}" = "x1" ] && [ "${INITRAMFS_IMAGE_BUNDLE}" != 
"1" ]; then
# Find and use the first initramfs image archive type we find
-   for img in cpio.lz4 cpio.lzo cpio.lzma cpio.xz cpio.gz ext2.gz 
cpio; do
+   for img in cpio.lz4 cpio.lzo cpio.lzma cpio.xz cpio.zst cpio.gz 
ext2.gz cpio; do

initramfs_path="${DEPLOY_DIR_IMAGE}/${INITRAMFS_IMAGE_NAME}.${img}"
echo "Using $initramfs_path"
if [ -e "${initramfs_path}" ]; then
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 9ec7daa17a..ab60e060c6 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -9,6 +9,7 @@ PROVIDES += "${@ "virtual/kernel" if 
(d.getVar("KERNEL_PACKAGE_NAME") == "kernel
  DEPENDS += "virtual/${TARGET_PREFIX}binutils virtual/${

Re: [OE-core] usermod in EXTRA_USERS_PARAMS is broken in master

2021-08-24 Thread Zoltan Boszormenyi via lists.openembedded.org

2021. 08. 24. 23:21 keltezéssel, Peter Kjellerstedt írta:

-Original Message-
From: openembedded-core@lists.openembedded.org  On Behalf Of Zoltan Boszormenyi via
lists.openembedded.org
Sent: den 24 augusti 2021 16:22
To: openembedded-core@lists.openembedded.org
Subject: [OE-core] usermod in EXTRA_USERS_PARAMS is broken in master

Hi,

I tried to port my distro layer to Honister and
attempted to build an OS image.

I have this in the image recipe:

EXTRA_USERS_PARAMS += "usermod -P mypassword root; usermod -P mypassword2 
myuser;"


The 0002-Allow-for-setting-password-in-clear-text.patch patch has been dropped
from shadow with the update to 4.9 (see commit 759df739). It previously renamed
the -P option to -A and added an insecure -P  option.

Replace the use of the -P  option with -p 
and you should be good to go, also with Hardknott.


Thank you.





and the error I got was:

NOTE: my-test-image: Performing usermod with [-R
/data/yocto/tmp-sicom-glibc/work/genericx86_64-oe-linux/my-test-image/1.0-
r0/rootfs -P
mypassword root]
usermod: prefix must be an absolute path
ERROR: my-test-image: usermod command did not succeed.
WARNING:
/data/yocto/tmp-sicom-glibc/work/genericx86_64-oe-linux/my-test-image/1.0-
r0/temp/run.set_user_group.2583229:260
exit 1 from 'exit 1'

EXTRA_USERS_PARAMS has userdel and useradd commands
before the last two usermod, all of which succeed.

I got the same error on both Fedora 33 and Fedora 34 hosts.

It works with Hardknott.

Best regards,
Zoltán Böszörményi


//Peter




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



[OE-core] usermod in EXTRA_USERS_PARAMS is broken in master

2021-08-24 Thread Zoltan Boszormenyi via lists.openembedded.org

Hi,

I tried to port my distro layer to Honister and
attempted to build an OS image.

I have this in the image recipe:

EXTRA_USERS_PARAMS += "usermod -P mypassword root; usermod -P mypassword2 
myuser;"

and the error I got was:

NOTE: my-test-image: Performing usermod with [-R 
/data/yocto/tmp-sicom-glibc/work/genericx86_64-oe-linux/my-test-image/1.0-r0/rootfs -P 
mypassword root]

usermod: prefix must be an absolute path
ERROR: my-test-image: usermod command did not succeed.
WARNING: 
/data/yocto/tmp-sicom-glibc/work/genericx86_64-oe-linux/my-test-image/1.0-r0/temp/run.set_user_group.2583229:260 
exit 1 from 'exit 1'


EXTRA_USERS_PARAMS has userdel and useradd commands
before the last two usermod, all of which succeed.

I got the same error on both Fedora 33 and Fedora 34 hosts.

It works with Hardknott.

Best regards,
Zoltán Böszörményi

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#155222): 
https://lists.openembedded.org/g/openembedded-core/message/155222
Mute This Topic: https://lists.openembedded.org/mt/85111613/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 3/4] kernel.bbclass: Use full versions for inter-package dependencies

2021-08-23 Thread Zoltan Boszormenyi via lists.openembedded.org
From: Zoltán Böszörményi 

If the kernel configuration enables module signing but no key
is provided, then the kernel generates one during the kernel build.

The current runtime-dependency references (with only package names
without full versions) allow mixed package installations from different
rebuilds of the same kernel version.

This creates an issue because then the modules either don't work
or taint the kernel.

Tighten RDEPENDS with the full package version, i.e. use (= ${EXTENDPKGV})
markers for inter-package dependencies.

The kernel will pull in the kernel-modules subpackage of the same
exact version automatically if KERNEL_SPLIT_MODULES="0" is set.
Otherwise the situation is the same as with the old default with
one subpackage per kernel module where they have to be upgraded
manually.

Signed-off-by: Zoltán Böszörményi 
---
 meta/classes/kernel.bbclass | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 6dc5387a9b..9ec7daa17a 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -91,17 +91,18 @@ python __anonymous () {
 kname = d.getVar('KERNEL_PACKAGE_NAME') or "kernel"
 imagedest = d.getVar('KERNEL_IMAGEDEST')
 
+fullver = d.getVar('EXTENDPKGV')
 for type in types.split():
 if bb.data.inherits_class('nopackages', d):
 continue
 typelower = type.lower()
 d.appendVar('PACKAGES', ' %s-image-%s' % (kname, typelower))
 d.setVar('FILES:' + kname + '-image-' + typelower, '/' + imagedest + 
'/' + type + '-${KERNEL_VERSION_NAME}' + ' /' + imagedest + '/' + type)
-d.appendVar('RDEPENDS:%s-image' % kname, ' %s-image-%s' % (kname, 
typelower))
+d.appendVar('RDEPENDS:%s-image' % kname, ' %s-image-%s (= %s)' % 
(kname, typelower, fullver))
 splitmods = d.getVar("KERNEL_SPLIT_MODULES")
 if splitmods != '1':
-d.appendVar('RDEPENDS:%s-image' % kname, ' %s-modules' % kname)
-d.appendVar('RDEPENDS:%s-image-%s' % (kname, typelower), ' 
%s-modules-${KERNEL_VERSION_PKG_NAME}' % kname)
+d.appendVar('RDEPENDS:%s-image' % kname, ' %s-modules (= %s)' % 
(kname, fullver))
+d.appendVar('RDEPENDS:%s-image-%s' % (kname, typelower), ' 
%s-modules-${KERNEL_VERSION_PKG_NAME} (= %s)' % (kname, fullver))
 d.setVar('PKG:%s-modules' % kname, 
'%s-modules-${KERNEL_VERSION_PKG_NAME}' % kname)
 d.appendVar('RPROVIDES:%s-modules' % kname, 
'%s-modules-${KERNEL_VERSION_PKG_NAME}' % kname)
 
@@ -628,12 +629,12 @@ FILES:${KERNEL_PACKAGE_NAME}-image = ""
 FILES:${KERNEL_PACKAGE_NAME}-dev = "/boot/System.map* /boot/Module.symvers* 
/boot/config* ${KERNEL_SRC_PATH} 
${nonarch_base_libdir}/modules/${KERNEL_VERSION}/build"
 FILES:${KERNEL_PACKAGE_NAME}-vmlinux = "/boot/vmlinux-${KERNEL_VERSION_NAME}"
 FILES:${KERNEL_PACKAGE_NAME}-modules = ""
-RDEPENDS:${KERNEL_PACKAGE_NAME} = "${KERNEL_PACKAGE_NAME}-base"
+RDEPENDS:${KERNEL_PACKAGE_NAME} = "${KERNEL_PACKAGE_NAME}-base (= 
${EXTENDPKGV})"
 # Allow machines to override this dependency if kernel image files are
 # not wanted in images as standard
-RDEPENDS:${KERNEL_PACKAGE_NAME}-base ?= "${KERNEL_PACKAGE_NAME}-image"
+RDEPENDS:${KERNEL_PACKAGE_NAME}-base ?= "${KERNEL_PACKAGE_NAME}-image (= 
${EXTENDPKGV})"
 PKG:${KERNEL_PACKAGE_NAME}-image = 
"${KERNEL_PACKAGE_NAME}-image-${@legitimize_package_name(d.getVar('KERNEL_VERSION'))}"
-RDEPENDS:${KERNEL_PACKAGE_NAME}-image += 
"${@oe.utils.conditional('KERNEL_IMAGETYPE', 'vmlinux', 
'${KERNEL_PACKAGE_NAME}-vmlinux', '', d)}"
+RDEPENDS:${KERNEL_PACKAGE_NAME}-image += 
"${@oe.utils.conditional('KERNEL_IMAGETYPE', 'vmlinux', 
'${KERNEL_PACKAGE_NAME}-vmlinux (= ${EXTENDPKGV})', '', d)}"
 PKG:${KERNEL_PACKAGE_NAME}-base = 
"${KERNEL_PACKAGE_NAME}-${@legitimize_package_name(d.getVar('KERNEL_VERSION'))}"
 RPROVIDES:${KERNEL_PACKAGE_NAME}-base += 
"${KERNEL_PACKAGE_NAME}-${KERNEL_VERSION}"
 ALLOW_EMPTY:${KERNEL_PACKAGE_NAME} = "1"
-- 
2.31.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#155177): 
https://lists.openembedded.org/g/openembedded-core/message/155177
Mute This Topic: https://lists.openembedded.org/mt/85087031/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 4/4] Support zstd-compressed squashfs and cpio initramfs

2021-08-23 Thread Zoltan Boszormenyi via lists.openembedded.org
From: Zoltán Böszörményi 

Signed-off-by: Zoltán Böszörményi 
---
 meta/classes/base.bbclass|  4 
 meta/classes/image_types.bbclass |  6 --
 meta/classes/kernel-fitimage.bbclass |  2 +-
 meta/classes/kernel.bbclass  | 10 --
 4 files changed, 17 insertions(+), 5 deletions(-)

diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index 11b65171d9..340ebe7d78 100644
--- a/meta/classes/base.bbclass
+++ b/meta/classes/base.bbclass
@@ -631,6 +631,10 @@ python () {
 if path.endswith('.lz4'):
 d.appendVarFlag('do_unpack', 'depends', ' 
lz4-native:do_populate_sysroot')
 
+# *.zst should DEPEND on zstd-native for unpacking
+elif path.endswith('.zst'):
+d.appendVarFlag('do_unpack', 'depends', ' 
zstd-native:do_populate_sysroot')
+
 # *.lz should DEPEND on lzip-native for unpacking
 elif path.endswith('.lz'):
 d.appendVarFlag('do_unpack', 'depends', ' 
lzip-native:do_populate_sysroot')
diff --git a/meta/classes/image_types.bbclass b/meta/classes/image_types.bbclass
index e0eb06c1e3..32d4cd4c76 100644
--- a/meta/classes/image_types.bbclass
+++ b/meta/classes/image_types.bbclass
@@ -107,6 +107,7 @@ IMAGE_CMD:squashfs = "mksquashfs ${IMAGE_ROOTFS} 
${IMGDEPLOYDIR}/${IMAGE_NAME}${
 IMAGE_CMD:squashfs-xz = "mksquashfs ${IMAGE_ROOTFS} 
${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.squashfs-xz ${EXTRA_IMAGECMD} 
-noappend -comp xz"
 IMAGE_CMD:squashfs-lzo = "mksquashfs ${IMAGE_ROOTFS} 
${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.squashfs-lzo 
${EXTRA_IMAGECMD} -noappend -comp lzo"
 IMAGE_CMD:squashfs-lz4 = "mksquashfs ${IMAGE_ROOTFS} 
${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.squashfs-lz4 
${EXTRA_IMAGECMD} -noappend -comp lz4"
+IMAGE_CMD:squashfs-zst = "mksquashfs ${IMAGE_ROOTFS} 
${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.squashfs-zst 
${EXTRA_IMAGECMD} -noappend -comp zstd"
 
 IMAGE_CMD:erofs = "mkfs.erofs ${EXTRA_IMAGECMD} 
${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.erofs ${IMAGE_ROOTFS}"
 IMAGE_CMD:erofs-lz4 = "mkfs.erofs -zlz4 ${EXTRA_IMAGECMD} 
${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.erofs-lz4 ${IMAGE_ROOTFS}"
@@ -244,6 +245,7 @@ do_image_squashfs[depends] += 
"squashfs-tools-native:do_populate_sysroot"
 do_image_squashfs_xz[depends] += "squashfs-tools-native:do_populate_sysroot"
 do_image_squashfs_lzo[depends] += "squashfs-tools-native:do_populate_sysroot"
 do_image_squashfs_lz4[depends] += "squashfs-tools-native:do_populate_sysroot"
+do_image_squashfs_zst[depends] += "squashfs-tools-native:do_populate_sysroot"
 do_image_ubi[depends] += "mtd-utils-native:do_populate_sysroot"
 do_image_ubifs[depends] += "mtd-utils-native:do_populate_sysroot"
 do_image_multiubi[depends] += "mtd-utils-native:do_populate_sysroot"
@@ -262,10 +264,10 @@ IMAGE_TYPES = " \
 btrfs \
 iso \
 hddimg \
-squashfs squashfs-xz squashfs-lzo squashfs-lz4 \
+squashfs squashfs-xz squashfs-lzo squashfs-lz4 squashfs-zst \
 ubi ubifs multiubi \
 tar tar.gz tar.bz2 tar.xz tar.lz4 tar.zst \
-cpio cpio.gz cpio.xz cpio.lzma cpio.lz4 \
+cpio cpio.gz cpio.xz cpio.lzma cpio.lz4 cpio.zst \
 wic wic.gz wic.bz2 wic.lzma wic.zst \
 container \
 f2fs \
diff --git a/meta/classes/kernel-fitimage.bbclass 
b/meta/classes/kernel-fitimage.bbclass
index 2ef8f06b14..38e05153e3 100644
--- a/meta/classes/kernel-fitimage.bbclass
+++ b/meta/classes/kernel-fitimage.bbclass
@@ -576,7 +576,7 @@ fitimage_assemble() {
#
if [ "x${ramdiskcount}" = "x1" ] && [ "${INITRAMFS_IMAGE_BUNDLE}" != 
"1" ]; then
# Find and use the first initramfs image archive type we find
-   for img in cpio.lz4 cpio.lzo cpio.lzma cpio.xz cpio.gz ext2.gz 
cpio; do
+   for img in cpio.lz4 cpio.lzo cpio.lzma cpio.xz cpio.zst cpio.gz 
ext2.gz cpio; do

initramfs_path="${DEPLOY_DIR_IMAGE}/${INITRAMFS_IMAGE_NAME}.${img}"
echo "Using $initramfs_path"
if [ -e "${initramfs_path}" ]; then
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 9ec7daa17a..ab60e060c6 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -9,6 +9,7 @@ PROVIDES += "${@ "virtual/kernel" if 
(d.getVar("KERNEL_PACKAGE_NAME") == "kernel
 DEPENDS += "virtual/${TARGET_PREFIX}binutils virtual/${TARGET_PREFIX}gcc 
kmod-native bc-native bison-native"
 DEPENDS += "${@bb.utils.contains("INITRAMFS_FSTYPES", "cpio.lzo", 
"lzop-native", "", d)}"
 DEPENDS += "${@bb.utils.contains("INITRAMFS_FSTYPES", "cpio.lz4", 
"lz4-native", "", d)}"
+DEPENDS += "${@bb.utils.contains("INITRAMFS_FSTYPES", "cpio.zst", 
"zstd-native", "", d)}"
 PACKAGE_WRITE_DEPS += "depmodwrapper-cross"
 
 do_deploy[depends] += "depmodwrapper-cross:do_populate_sysroot 
gzip-native:do_populate_sysroot"
@@ -237,7 +238,7 @@ copy_initramfs() {
mkdir -p ${B}/usr
# Find and use the first 

[OE-core] [PATCH v3 2/4] Allow opt-out of split kernel modules

2021-08-23 Thread Zoltan Boszormenyi via lists.openembedded.org
From: Zoltán Böszörményi 

For some use cases, a monolithic kernel-modules package containing
all modules built from the kernel sources may be preferred.
For one, download time is shorter and installation time is faster.

Set KERNEL_SPLIT_MODULES="0" for this in. The default is one subpackage
per module.

Also, adapt kernel.bbclass to KERNEL_SPLIT_MODULES != "1" case
Extra RDEPENDS and other inter-package references are needed in
this case.

Signed-off-by: Zoltán Böszörményi 
---
 meta/classes/kernel-module-split.bbclass | 17 +
 meta/classes/kernel.bbclass  |  7 +++
 2 files changed, 20 insertions(+), 4 deletions(-)

diff --git a/meta/classes/kernel-module-split.bbclass 
b/meta/classes/kernel-module-split.bbclass
index 6c1de4c992..a29c294810 100644
--- a/meta/classes/kernel-module-split.bbclass
+++ b/meta/classes/kernel-module-split.bbclass
@@ -28,6 +28,7 @@ do_install:append() {
install -d ${D}${sysconfdir}/modules-load.d/ 
${D}${sysconfdir}/modprobe.d/
 }
 
+KERNEL_SPLIT_MODULES ?= "1"
 PACKAGESPLITFUNCS:prepend = "split_kernel_module_packages "
 
 KERNEL_MODULES_META_PACKAGE ?= "${@ d.getVar("KERNEL_PACKAGE_NAME") or 
"kernel" }-modules"
@@ -156,18 +157,26 @@ python split_kernel_module_packages () {
 kernel_package_name = d.getVar("KERNEL_PACKAGE_NAME") or "kernel"
 kernel_version = d.getVar("KERNEL_VERSION")
 
+metapkg = d.getVar('KERNEL_MODULES_META_PACKAGE')
+splitmods = d.getVar('KERNEL_SPLIT_MODULES')
+postinst = d.getVar('pkg_postinst:modules')
+postrm = d.getVar('pkg_postrm:modules')
+
+if splitmods != '1':
+etcdir = d.getVar('sysconfdir')
+d.appendVar('FILES:' + metapkg, '%s/modules-load.d/ %s/modprobe.d/ 
%s/modules/' % (etcdir, etcdir, d.getVar("nonarch_base_libdir")))
+d.appendVar('pkg_postinst:%s' % metapkg, postinst)
+d.prependVar('pkg_postrm:%s' % metapkg, postrm);
+return
+
 module_regex = r'^(.*)\.k?o(?:\.(gz|xz|zst))?$'
 
 module_pattern_prefix = d.getVar('KERNEL_MODULE_PACKAGE_PREFIX')
 module_pattern_suffix = d.getVar('KERNEL_MODULE_PACKAGE_SUFFIX')
 module_pattern = module_pattern_prefix + kernel_package_name + 
'-module-%s' + module_pattern_suffix
 
-postinst = d.getVar('pkg_postinst:modules')
-postrm = d.getVar('pkg_postrm:modules')
-
 modules = do_split_packages(d, root='${nonarch_base_libdir}/modules', 
file_regex=module_regex, output_pattern=module_pattern, description='%s kernel 
module', postinst=postinst, postrm=postrm, recursive=True, hook=frob_metadata, 
extra_depends='%s-%s' % (kernel_package_name, kernel_version))
 if modules:
-metapkg = d.getVar('KERNEL_MODULES_META_PACKAGE')
 d.appendVar('RDEPENDS:' + metapkg, ' '+' '.join(modules))
 
 # If modules-load.d and modprobe.d are empty at this point, remove them to
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 027e66eec7..6dc5387a9b 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -98,6 +98,13 @@ python __anonymous () {
 d.appendVar('PACKAGES', ' %s-image-%s' % (kname, typelower))
 d.setVar('FILES:' + kname + '-image-' + typelower, '/' + imagedest + 
'/' + type + '-${KERNEL_VERSION_NAME}' + ' /' + imagedest + '/' + type)
 d.appendVar('RDEPENDS:%s-image' % kname, ' %s-image-%s' % (kname, 
typelower))
+splitmods = d.getVar("KERNEL_SPLIT_MODULES")
+if splitmods != '1':
+d.appendVar('RDEPENDS:%s-image' % kname, ' %s-modules' % kname)
+d.appendVar('RDEPENDS:%s-image-%s' % (kname, typelower), ' 
%s-modules-${KERNEL_VERSION_PKG_NAME}' % kname)
+d.setVar('PKG:%s-modules' % kname, 
'%s-modules-${KERNEL_VERSION_PKG_NAME}' % kname)
+d.appendVar('RPROVIDES:%s-modules' % kname, 
'%s-modules-${KERNEL_VERSION_PKG_NAME}' % kname)
+
 d.setVar('PKG:%s-image-%s' % (kname,typelower), 
'%s-image-%s-${KERNEL_VERSION_PKG_NAME}' % (kname, typelower))
 d.setVar('ALLOW_EMPTY:%s-image-%s' % (kname, typelower), '1')
 d.setVar('pkg_postinst:%s-image-%s' % (kname,typelower), """set +e
-- 
2.31.1


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



[OE-core] [PATCH v3 1/4] kernel-module-split.bbclass: Support zstd-compressed modules

2021-08-23 Thread Zoltan Boszormenyi via lists.openembedded.org
From: Zoltán Böszörményi 

Signed-off-by: Zoltán Böszörményi 
---
 meta/classes/kernel-module-split.bbclass | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/meta/classes/kernel-module-split.bbclass 
b/meta/classes/kernel-module-split.bbclass
index b56dd4a9c7..6c1de4c992 100644
--- a/meta/classes/kernel-module-split.bbclass
+++ b/meta/classes/kernel-module-split.bbclass
@@ -44,17 +44,20 @@ python split_kernel_module_packages () {
 def extract_modinfo(file):
 import tempfile, subprocess
 tempfile.tempdir = d.getVar("WORKDIR")
-compressed = re.match( r'.*\.([xg])z$', file)
+compressed = re.match( r'.*\.(gz|xz|zst)$', file)
 tf = tempfile.mkstemp()
 tmpfile = tf[1]
 if compressed:
 tmpkofile = tmpfile + ".ko"
-if compressed.group(1) == 'g':
+if compressed.group(1) == 'gz':
 cmd = "gunzip -dc %s > %s" % (file, tmpkofile)
 subprocess.check_call(cmd, shell=True)
-elif compressed.group(1) == 'x':
+elif compressed.group(1) == 'xz':
 cmd = "xz -dc %s > %s" % (file, tmpkofile)
 subprocess.check_call(cmd, shell=True)
+elif compressed.group(1) == 'zst':
+cmd = "zstd -dc %s > %s" % (file, tmpkofile)
+subprocess.check_call(cmd, shell=True)
 else:
 msg = "Cannot decompress '%s'" % file
 raise msg
@@ -153,7 +156,7 @@ python split_kernel_module_packages () {
 kernel_package_name = d.getVar("KERNEL_PACKAGE_NAME") or "kernel"
 kernel_version = d.getVar("KERNEL_VERSION")
 
-module_regex = r'^(.*)\.k?o(?:\.[xg]z)?$'
+module_regex = r'^(.*)\.k?o(?:\.(gz|xz|zst))?$'
 
 module_pattern_prefix = d.getVar('KERNEL_MODULE_PACKAGE_PREFIX')
 module_pattern_suffix = d.getVar('KERNEL_MODULE_PACKAGE_SUFFIX')
-- 
2.31.1


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



[OE-core] Kernel related bbclass changes

2021-08-23 Thread Zoltan Boszormenyi via lists.openembedded.org
I have been carrying some forked bbclass recipes and I think
these can be beneficial to others, not to mention that I could
get rid of the private forks of these.

v2:
- drop the package_rpm.bbclass / posttrans patch
- squash the previous patches #3 and #4 together (patch #2 now)
- more verbose commit message for patch #3 (previously patch #5)

v3:
- fix commit message for patch #3 (stupid copy)



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



[OE-core] [PATCH v2 4/4] Support zstd-compressed squashfs and cpio initramfs

2021-08-23 Thread Zoltan Boszormenyi via lists.openembedded.org
From: Zoltán Böszörményi 

Signed-off-by: Zoltán Böszörményi 
---
 meta/classes/base.bbclass|  4 
 meta/classes/image_types.bbclass |  6 --
 meta/classes/kernel-fitimage.bbclass |  2 +-
 meta/classes/kernel.bbclass  | 10 --
 4 files changed, 17 insertions(+), 5 deletions(-)

diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index 11b65171d9..340ebe7d78 100644
--- a/meta/classes/base.bbclass
+++ b/meta/classes/base.bbclass
@@ -631,6 +631,10 @@ python () {
 if path.endswith('.lz4'):
 d.appendVarFlag('do_unpack', 'depends', ' 
lz4-native:do_populate_sysroot')
 
+# *.zst should DEPEND on zstd-native for unpacking
+elif path.endswith('.zst'):
+d.appendVarFlag('do_unpack', 'depends', ' 
zstd-native:do_populate_sysroot')
+
 # *.lz should DEPEND on lzip-native for unpacking
 elif path.endswith('.lz'):
 d.appendVarFlag('do_unpack', 'depends', ' 
lzip-native:do_populate_sysroot')
diff --git a/meta/classes/image_types.bbclass b/meta/classes/image_types.bbclass
index e0eb06c1e3..32d4cd4c76 100644
--- a/meta/classes/image_types.bbclass
+++ b/meta/classes/image_types.bbclass
@@ -107,6 +107,7 @@ IMAGE_CMD:squashfs = "mksquashfs ${IMAGE_ROOTFS} 
${IMGDEPLOYDIR}/${IMAGE_NAME}${
 IMAGE_CMD:squashfs-xz = "mksquashfs ${IMAGE_ROOTFS} 
${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.squashfs-xz ${EXTRA_IMAGECMD} 
-noappend -comp xz"
 IMAGE_CMD:squashfs-lzo = "mksquashfs ${IMAGE_ROOTFS} 
${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.squashfs-lzo 
${EXTRA_IMAGECMD} -noappend -comp lzo"
 IMAGE_CMD:squashfs-lz4 = "mksquashfs ${IMAGE_ROOTFS} 
${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.squashfs-lz4 
${EXTRA_IMAGECMD} -noappend -comp lz4"
+IMAGE_CMD:squashfs-zst = "mksquashfs ${IMAGE_ROOTFS} 
${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.squashfs-zst 
${EXTRA_IMAGECMD} -noappend -comp zstd"
 
 IMAGE_CMD:erofs = "mkfs.erofs ${EXTRA_IMAGECMD} 
${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.erofs ${IMAGE_ROOTFS}"
 IMAGE_CMD:erofs-lz4 = "mkfs.erofs -zlz4 ${EXTRA_IMAGECMD} 
${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.erofs-lz4 ${IMAGE_ROOTFS}"
@@ -244,6 +245,7 @@ do_image_squashfs[depends] += 
"squashfs-tools-native:do_populate_sysroot"
 do_image_squashfs_xz[depends] += "squashfs-tools-native:do_populate_sysroot"
 do_image_squashfs_lzo[depends] += "squashfs-tools-native:do_populate_sysroot"
 do_image_squashfs_lz4[depends] += "squashfs-tools-native:do_populate_sysroot"
+do_image_squashfs_zst[depends] += "squashfs-tools-native:do_populate_sysroot"
 do_image_ubi[depends] += "mtd-utils-native:do_populate_sysroot"
 do_image_ubifs[depends] += "mtd-utils-native:do_populate_sysroot"
 do_image_multiubi[depends] += "mtd-utils-native:do_populate_sysroot"
@@ -262,10 +264,10 @@ IMAGE_TYPES = " \
 btrfs \
 iso \
 hddimg \
-squashfs squashfs-xz squashfs-lzo squashfs-lz4 \
+squashfs squashfs-xz squashfs-lzo squashfs-lz4 squashfs-zst \
 ubi ubifs multiubi \
 tar tar.gz tar.bz2 tar.xz tar.lz4 tar.zst \
-cpio cpio.gz cpio.xz cpio.lzma cpio.lz4 \
+cpio cpio.gz cpio.xz cpio.lzma cpio.lz4 cpio.zst \
 wic wic.gz wic.bz2 wic.lzma wic.zst \
 container \
 f2fs \
diff --git a/meta/classes/kernel-fitimage.bbclass 
b/meta/classes/kernel-fitimage.bbclass
index 2ef8f06b14..38e05153e3 100644
--- a/meta/classes/kernel-fitimage.bbclass
+++ b/meta/classes/kernel-fitimage.bbclass
@@ -576,7 +576,7 @@ fitimage_assemble() {
#
if [ "x${ramdiskcount}" = "x1" ] && [ "${INITRAMFS_IMAGE_BUNDLE}" != 
"1" ]; then
# Find and use the first initramfs image archive type we find
-   for img in cpio.lz4 cpio.lzo cpio.lzma cpio.xz cpio.gz ext2.gz 
cpio; do
+   for img in cpio.lz4 cpio.lzo cpio.lzma cpio.xz cpio.zst cpio.gz 
ext2.gz cpio; do

initramfs_path="${DEPLOY_DIR_IMAGE}/${INITRAMFS_IMAGE_NAME}.${img}"
echo "Using $initramfs_path"
if [ -e "${initramfs_path}" ]; then
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 9ec7daa17a..ab60e060c6 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -9,6 +9,7 @@ PROVIDES += "${@ "virtual/kernel" if 
(d.getVar("KERNEL_PACKAGE_NAME") == "kernel
 DEPENDS += "virtual/${TARGET_PREFIX}binutils virtual/${TARGET_PREFIX}gcc 
kmod-native bc-native bison-native"
 DEPENDS += "${@bb.utils.contains("INITRAMFS_FSTYPES", "cpio.lzo", 
"lzop-native", "", d)}"
 DEPENDS += "${@bb.utils.contains("INITRAMFS_FSTYPES", "cpio.lz4", 
"lz4-native", "", d)}"
+DEPENDS += "${@bb.utils.contains("INITRAMFS_FSTYPES", "cpio.zst", 
"zstd-native", "", d)}"
 PACKAGE_WRITE_DEPS += "depmodwrapper-cross"
 
 do_deploy[depends] += "depmodwrapper-cross:do_populate_sysroot 
gzip-native:do_populate_sysroot"
@@ -237,7 +238,7 @@ copy_initramfs() {
mkdir -p ${B}/usr
# Find and use the first 

[OE-core] [PATCH v2 3/4] kernel.bbclass: Use full versions for inter-package dependencies

2021-08-23 Thread Zoltan Boszormenyi via lists.openembedded.org
From: Zoltán Böszörményi 

If the kernel configuration enables module signing but no key
is provided, then the kernel generates one during the kernel build.

The current runtime-dependency references (with only package names
without full versions) allow mixed package installations from different
rebuilds of the same kernel version.

This does create an issue if the kernel configuration enables module
signing but no key is provided, in which case the kernel generates
the signing key during the kernel build.

Tighten RDEPENDS with the full package version, i.e. use (= ${EXTENDPKGV})
markers for inter-package dependencies.

The kernel will pull in the kernel-modules subpackage of the same
exact version automatically if KERNEL_SPLIT_MODULES="0" is set.
Otherwise the situation is the same as with the old default with
one subpackage per kernel module where they have to be upgraded
manually.

Signed-off-by: Zoltán Böszörményi 
---
 meta/classes/kernel.bbclass | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 6dc5387a9b..9ec7daa17a 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -91,17 +91,18 @@ python __anonymous () {
 kname = d.getVar('KERNEL_PACKAGE_NAME') or "kernel"
 imagedest = d.getVar('KERNEL_IMAGEDEST')
 
+fullver = d.getVar('EXTENDPKGV')
 for type in types.split():
 if bb.data.inherits_class('nopackages', d):
 continue
 typelower = type.lower()
 d.appendVar('PACKAGES', ' %s-image-%s' % (kname, typelower))
 d.setVar('FILES:' + kname + '-image-' + typelower, '/' + imagedest + 
'/' + type + '-${KERNEL_VERSION_NAME}' + ' /' + imagedest + '/' + type)
-d.appendVar('RDEPENDS:%s-image' % kname, ' %s-image-%s' % (kname, 
typelower))
+d.appendVar('RDEPENDS:%s-image' % kname, ' %s-image-%s (= %s)' % 
(kname, typelower, fullver))
 splitmods = d.getVar("KERNEL_SPLIT_MODULES")
 if splitmods != '1':
-d.appendVar('RDEPENDS:%s-image' % kname, ' %s-modules' % kname)
-d.appendVar('RDEPENDS:%s-image-%s' % (kname, typelower), ' 
%s-modules-${KERNEL_VERSION_PKG_NAME}' % kname)
+d.appendVar('RDEPENDS:%s-image' % kname, ' %s-modules (= %s)' % 
(kname, fullver))
+d.appendVar('RDEPENDS:%s-image-%s' % (kname, typelower), ' 
%s-modules-${KERNEL_VERSION_PKG_NAME} (= %s)' % (kname, fullver))
 d.setVar('PKG:%s-modules' % kname, 
'%s-modules-${KERNEL_VERSION_PKG_NAME}' % kname)
 d.appendVar('RPROVIDES:%s-modules' % kname, 
'%s-modules-${KERNEL_VERSION_PKG_NAME}' % kname)
 
@@ -628,12 +629,12 @@ FILES:${KERNEL_PACKAGE_NAME}-image = ""
 FILES:${KERNEL_PACKAGE_NAME}-dev = "/boot/System.map* /boot/Module.symvers* 
/boot/config* ${KERNEL_SRC_PATH} 
${nonarch_base_libdir}/modules/${KERNEL_VERSION}/build"
 FILES:${KERNEL_PACKAGE_NAME}-vmlinux = "/boot/vmlinux-${KERNEL_VERSION_NAME}"
 FILES:${KERNEL_PACKAGE_NAME}-modules = ""
-RDEPENDS:${KERNEL_PACKAGE_NAME} = "${KERNEL_PACKAGE_NAME}-base"
+RDEPENDS:${KERNEL_PACKAGE_NAME} = "${KERNEL_PACKAGE_NAME}-base (= 
${EXTENDPKGV})"
 # Allow machines to override this dependency if kernel image files are
 # not wanted in images as standard
-RDEPENDS:${KERNEL_PACKAGE_NAME}-base ?= "${KERNEL_PACKAGE_NAME}-image"
+RDEPENDS:${KERNEL_PACKAGE_NAME}-base ?= "${KERNEL_PACKAGE_NAME}-image (= 
${EXTENDPKGV})"
 PKG:${KERNEL_PACKAGE_NAME}-image = 
"${KERNEL_PACKAGE_NAME}-image-${@legitimize_package_name(d.getVar('KERNEL_VERSION'))}"
-RDEPENDS:${KERNEL_PACKAGE_NAME}-image += 
"${@oe.utils.conditional('KERNEL_IMAGETYPE', 'vmlinux', 
'${KERNEL_PACKAGE_NAME}-vmlinux', '', d)}"
+RDEPENDS:${KERNEL_PACKAGE_NAME}-image += 
"${@oe.utils.conditional('KERNEL_IMAGETYPE', 'vmlinux', 
'${KERNEL_PACKAGE_NAME}-vmlinux (= ${EXTENDPKGV})', '', d)}"
 PKG:${KERNEL_PACKAGE_NAME}-base = 
"${KERNEL_PACKAGE_NAME}-${@legitimize_package_name(d.getVar('KERNEL_VERSION'))}"
 RPROVIDES:${KERNEL_PACKAGE_NAME}-base += 
"${KERNEL_PACKAGE_NAME}-${KERNEL_VERSION}"
 ALLOW_EMPTY:${KERNEL_PACKAGE_NAME} = "1"
-- 
2.31.1


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



[OE-core] [PATCH v2 2/4] Allow opt-out of split kernel modules

2021-08-23 Thread Zoltan Boszormenyi via lists.openembedded.org
From: Zoltán Böszörményi 

For some use cases, a monolithic kernel-modules package containing
all modules built from the kernel sources may be preferred.
For one, download time is shorter and installation time is faster.

Set KERNEL_SPLIT_MODULES="0" for this in. The default is one subpackage
per module.

Also, adapt kernel.bbclass to KERNEL_SPLIT_MODULES != "1" case
Extra RDEPENDS and other inter-package references are needed in
this case.

Signed-off-by: Zoltán Böszörményi 
---
 meta/classes/kernel-module-split.bbclass | 17 +
 meta/classes/kernel.bbclass  |  7 +++
 2 files changed, 20 insertions(+), 4 deletions(-)

diff --git a/meta/classes/kernel-module-split.bbclass 
b/meta/classes/kernel-module-split.bbclass
index 6c1de4c992..a29c294810 100644
--- a/meta/classes/kernel-module-split.bbclass
+++ b/meta/classes/kernel-module-split.bbclass
@@ -28,6 +28,7 @@ do_install:append() {
install -d ${D}${sysconfdir}/modules-load.d/ 
${D}${sysconfdir}/modprobe.d/
 }
 
+KERNEL_SPLIT_MODULES ?= "1"
 PACKAGESPLITFUNCS:prepend = "split_kernel_module_packages "
 
 KERNEL_MODULES_META_PACKAGE ?= "${@ d.getVar("KERNEL_PACKAGE_NAME") or 
"kernel" }-modules"
@@ -156,18 +157,26 @@ python split_kernel_module_packages () {
 kernel_package_name = d.getVar("KERNEL_PACKAGE_NAME") or "kernel"
 kernel_version = d.getVar("KERNEL_VERSION")
 
+metapkg = d.getVar('KERNEL_MODULES_META_PACKAGE')
+splitmods = d.getVar('KERNEL_SPLIT_MODULES')
+postinst = d.getVar('pkg_postinst:modules')
+postrm = d.getVar('pkg_postrm:modules')
+
+if splitmods != '1':
+etcdir = d.getVar('sysconfdir')
+d.appendVar('FILES:' + metapkg, '%s/modules-load.d/ %s/modprobe.d/ 
%s/modules/' % (etcdir, etcdir, d.getVar("nonarch_base_libdir")))
+d.appendVar('pkg_postinst:%s' % metapkg, postinst)
+d.prependVar('pkg_postrm:%s' % metapkg, postrm);
+return
+
 module_regex = r'^(.*)\.k?o(?:\.(gz|xz|zst))?$'
 
 module_pattern_prefix = d.getVar('KERNEL_MODULE_PACKAGE_PREFIX')
 module_pattern_suffix = d.getVar('KERNEL_MODULE_PACKAGE_SUFFIX')
 module_pattern = module_pattern_prefix + kernel_package_name + 
'-module-%s' + module_pattern_suffix
 
-postinst = d.getVar('pkg_postinst:modules')
-postrm = d.getVar('pkg_postrm:modules')
-
 modules = do_split_packages(d, root='${nonarch_base_libdir}/modules', 
file_regex=module_regex, output_pattern=module_pattern, description='%s kernel 
module', postinst=postinst, postrm=postrm, recursive=True, hook=frob_metadata, 
extra_depends='%s-%s' % (kernel_package_name, kernel_version))
 if modules:
-metapkg = d.getVar('KERNEL_MODULES_META_PACKAGE')
 d.appendVar('RDEPENDS:' + metapkg, ' '+' '.join(modules))
 
 # If modules-load.d and modprobe.d are empty at this point, remove them to
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 027e66eec7..6dc5387a9b 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -98,6 +98,13 @@ python __anonymous () {
 d.appendVar('PACKAGES', ' %s-image-%s' % (kname, typelower))
 d.setVar('FILES:' + kname + '-image-' + typelower, '/' + imagedest + 
'/' + type + '-${KERNEL_VERSION_NAME}' + ' /' + imagedest + '/' + type)
 d.appendVar('RDEPENDS:%s-image' % kname, ' %s-image-%s' % (kname, 
typelower))
+splitmods = d.getVar("KERNEL_SPLIT_MODULES")
+if splitmods != '1':
+d.appendVar('RDEPENDS:%s-image' % kname, ' %s-modules' % kname)
+d.appendVar('RDEPENDS:%s-image-%s' % (kname, typelower), ' 
%s-modules-${KERNEL_VERSION_PKG_NAME}' % kname)
+d.setVar('PKG:%s-modules' % kname, 
'%s-modules-${KERNEL_VERSION_PKG_NAME}' % kname)
+d.appendVar('RPROVIDES:%s-modules' % kname, 
'%s-modules-${KERNEL_VERSION_PKG_NAME}' % kname)
+
 d.setVar('PKG:%s-image-%s' % (kname,typelower), 
'%s-image-%s-${KERNEL_VERSION_PKG_NAME}' % (kname, typelower))
 d.setVar('ALLOW_EMPTY:%s-image-%s' % (kname, typelower), '1')
 d.setVar('pkg_postinst:%s-image-%s' % (kname,typelower), """set +e
-- 
2.31.1


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



[OE-core] [PATCH v2 1/4] kernel-module-split.bbclass: Support zstd-compressed modules

2021-08-23 Thread Zoltan Boszormenyi via lists.openembedded.org
From: Zoltán Böszörményi 

Signed-off-by: Zoltán Böszörményi 
---
 meta/classes/kernel-module-split.bbclass | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/meta/classes/kernel-module-split.bbclass 
b/meta/classes/kernel-module-split.bbclass
index b56dd4a9c7..6c1de4c992 100644
--- a/meta/classes/kernel-module-split.bbclass
+++ b/meta/classes/kernel-module-split.bbclass
@@ -44,17 +44,20 @@ python split_kernel_module_packages () {
 def extract_modinfo(file):
 import tempfile, subprocess
 tempfile.tempdir = d.getVar("WORKDIR")
-compressed = re.match( r'.*\.([xg])z$', file)
+compressed = re.match( r'.*\.(gz|xz|zst)$', file)
 tf = tempfile.mkstemp()
 tmpfile = tf[1]
 if compressed:
 tmpkofile = tmpfile + ".ko"
-if compressed.group(1) == 'g':
+if compressed.group(1) == 'gz':
 cmd = "gunzip -dc %s > %s" % (file, tmpkofile)
 subprocess.check_call(cmd, shell=True)
-elif compressed.group(1) == 'x':
+elif compressed.group(1) == 'xz':
 cmd = "xz -dc %s > %s" % (file, tmpkofile)
 subprocess.check_call(cmd, shell=True)
+elif compressed.group(1) == 'zst':
+cmd = "zstd -dc %s > %s" % (file, tmpkofile)
+subprocess.check_call(cmd, shell=True)
 else:
 msg = "Cannot decompress '%s'" % file
 raise msg
@@ -153,7 +156,7 @@ python split_kernel_module_packages () {
 kernel_package_name = d.getVar("KERNEL_PACKAGE_NAME") or "kernel"
 kernel_version = d.getVar("KERNEL_VERSION")
 
-module_regex = r'^(.*)\.k?o(?:\.[xg]z)?$'
+module_regex = r'^(.*)\.k?o(?:\.(gz|xz|zst))?$'
 
 module_pattern_prefix = d.getVar('KERNEL_MODULE_PACKAGE_PREFIX')
 module_pattern_suffix = d.getVar('KERNEL_MODULE_PACKAGE_SUFFIX')
-- 
2.31.1


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



[OE-core] Kernel related bbclass changes

2021-08-23 Thread Zoltan Boszormenyi via lists.openembedded.org
I have been carrying some forked bbclass recipes and I think
these can be beneficial to others, not to mention that I could
get rid of the private forks of these.

v2:
- drop the package_rpm.bbclass / posttrans patch
- squash the previous patches #3 and #4 together (patch #2 now)
- more verbose commit message for patch #3 (previously patch #5)



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#155169): 
https://lists.openembedded.org/g/openembedded-core/message/155169
Mute This Topic: https://lists.openembedded.org/mt/85086832/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 5/6] kernel.bbclass: Use full versions for inter-package dependencies

2021-08-23 Thread Zoltan Boszormenyi via lists.openembedded.org

2021. 08. 23. 15:38 keltezéssel, Bruce Ashfield írta:

On Mon, Aug 23, 2021 at 9:30 AM Böszörményi Zoltán  wrote:


2021. 08. 23. 15:03 keltezéssel, Bruce Ashfield írta:

On Mon, Aug 23, 2021 at 8:23 AM Zoltan Boszormenyi via
lists.openembedded.org  wrote:


From: Zoltán Böszörményi 

Some Yocto users do use package repositories and sometimes the PR
value is forgotten. Use full versions for inter-package dependencies
for the kernel subpackages.


Can you expand this commit message ?


I will send a new version with the expanded message.


What is the observable problem
with the full versions not being in the rdpends ?


Currently the kernel creates such subpackages:

kernel
kernel-x.y.z
kernel-image-x.y.z
kernel-image-bzimage-x.y.z
kernel-modules-x.y.z

and in the split modules case, a lot of

kernel-module-*-x.y.z

RDEPENDS currently only references the package names.

The issue I observe is this: I have enabled kernel module signing
but I don't provide a key, so the kernel will generate one at
every rebuild.

You get the idea what problem this can make if there's a
rebuild:

x.y.z-r0.0 -> x.y.z-r1.0 (in which case the PR value was duly changed)
or
x.y.z-r0.0 -> x.y.z-r0.1 (where not)

It's actually indifferent, but the same issue occurs if
only the kernel-image-bzimage is upgraded: the modules either
won't work or taint the kernel.


Your second example is similar to the times I've seen some module
issues as well, and honestly, I can't recall if it was solved in a
similar way to this (I don't have access to my old repos from Wind
River any more).

But that does make sense to me, and the details you have in this
follow up, make a nice commit explanation.

While opkg may not handle the situation you describe as well as RPM,
we should make sure that the full version doesn't cause issues with
the package generation or standard image creation.


You can bet it doesn't. I have the same patch in a Sumo-based distro
where we still use ipk and opkg and there's no issue in either image
generation or package upgrades. Only that there's no "installonly"
knowledge in opkg (unlike dnf) so old kernel packages have to be
manually cleaned up there.



Cheers,

Bruce



This scenario is currently valid in the package manager because
of the versionless RDEPENDS.



I've run many different package feeds with different kernels and
modules, and haven't run into anything on this front, in my experience
the extended version in the package depends/provides causes issues
with some package managers .. so we'd need the testing for this
documented/provided so we could ensure that there are no hidden
issues.

Bruce




Signed-off-by: Zoltán Böszörményi 
---
   meta/classes/kernel.bbclass | 13 +++--
   1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 6dc5387a9b..9ec7daa17a 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -91,17 +91,18 @@ python __anonymous () {
   kname = d.getVar('KERNEL_PACKAGE_NAME') or "kernel"
   imagedest = d.getVar('KERNEL_IMAGEDEST')

+fullver = d.getVar('EXTENDPKGV')
   for type in types.split():
   if bb.data.inherits_class('nopackages', d):
   continue
   typelower = type.lower()
   d.appendVar('PACKAGES', ' %s-image-%s' % (kname, typelower))
   d.setVar('FILES:' + kname + '-image-' + typelower, '/' + imagedest + 
'/' + type + '-${KERNEL_VERSION_NAME}' + ' /' + imagedest + '/' + type)
-d.appendVar('RDEPENDS:%s-image' % kname, ' %s-image-%s' % (kname, 
typelower))
+d.appendVar('RDEPENDS:%s-image' % kname, ' %s-image-%s (= %s)' % 
(kname, typelower, fullver))
   splitmods = d.getVar("KERNEL_SPLIT_MODULES")
   if splitmods != '1':
-d.appendVar('RDEPENDS:%s-image' % kname, ' %s-modules' % kname)
-d.appendVar('RDEPENDS:%s-image-%s' % (kname, typelower), ' 
%s-modules-${KERNEL_VERSION_PKG_NAME}' % kname)
+d.appendVar('RDEPENDS:%s-image' % kname, ' %s-modules (= %s)' % 
(kname, fullver))
+d.appendVar('RDEPENDS:%s-image-%s' % (kname, typelower), ' 
%s-modules-${KERNEL_VERSION_PKG_NAME} (= %s)' % (kname, fullver))
   d.setVar('PKG:%s-modules' % kname, 
'%s-modules-${KERNEL_VERSION_PKG_NAME}' % kname)
   d.appendVar('RPROVIDES:%s-modules' % kname, 
'%s-modules-${KERNEL_VERSION_PKG_NAME}' % kname)

@@ -628,12 +629,12 @@ FILES:${KERNEL_PACKAGE_NAME}-image = ""
   FILES:${KERNEL_PACKAGE_NAME}-dev = "/boot/System.map* /boot/Module.symvers* 
/boot/config* ${KERNEL_SRC_PATH} 
${nonarch_base_libdir}/modules/${KERNEL_VERSION}/build"
   FILES:${KERNEL_PACKAGE_NAME}-vmlinux = "/boot/vmlinux-${KERNEL_VERSION_NAME}"
   FILES:${KERNEL_PACKAGE_NAME}-modules = ""
-RDEPENDS:${KERNEL_PACKAGE_NAME} = "${KERNEL_PACKAGE_NAME}-base"
+RDEPENDS:${KERNEL_PACKAGE_NAME} = "${KE

Re: [OE-core] [PATCH 1/6] package_rpm.bbclass: Handle posttrans scriptlets

2021-08-23 Thread Zoltan Boszormenyi via lists.openembedded.org

2021. 08. 23. 15:23 keltezéssel, Richard Purdie írta:

On Mon, 2021-08-23 at 15:14 +0200, Zoltan Boszormenyi via lists.openembedded.org
wrote:

It's documented at www.rpm.org, Red Hat and SuSE.

https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/
https://en.opensuse.org/openSUSE:Packaging_scriptlet_snippets
https://rpm-packaging-guide.github.io/

It's available since RPM 4.4. RPM 4.16.1.3 is in Hardknott.

A short Google search showed that *maybe* dpkg also supports it,
or at least there are(were?) plans to implement it:
https://wiki.debian.org/i18n/TranslationDebsProposals

With postinst, the time when the scriptlet runs may depend
on the order of the packages in the upgrade transaction and
may run with the older binaries in place.

The posttrans scriptlet runs at the very end of the
install/upgrade transaction, just like the OPKG "intercept"
scripts.

I successfully tested it long ago with a kernel upgrade
that was running dracut on the new version, plus a dracut
upgrade in the same session. Dissecting the initramfs proved
that with postinst, the old dracut version generated it,
while with posttrans, the new one did.

Who would want to use it? Anyone who needs some finalizer
script to be run at the end of an RPM/DNF transaction.

I started on Angstrom and I know opkg doesn't implement this
and Yocto inherited it. This patch is basically a heads up
that there's another way to do the same thing. Maybe opkg
implements this some day, maybe not. Anyway, Yocto in general
will need more changes before the main package.bbclass can
start to use it for all package formats.



There is a bigger issue here which is how can anyone use this without making
their recipe rpm specific? I'm very reluctant to add functionality like this
unless we have a way to emulate it or fall back on the other package formats.


Indeed. This patch can be dropped.

Full disclosure: I don't use this anymore, since I implemented
another two bbclass recipes to generate the kernel's initramfs
either during the kernel build (and ship it in a subpackage) or
during do_rootfs and move it out of the way in the image postprocess
script so e.g. a squashfs image will have it separately.
They work well for my use limited cases:
* full OS installed on disk
* squashfs for PXE-based remote booted machines

FYI: the dracutsysrootdir feature in recent dracut versions is my work.

I just carried this patch for a couple of years now and I thought maybe
someone sees some value in it.



The intercept pieces are used by both rpm and opkg and actually do something
slightly different, they stack common calls until the end of the transaction.
This means for example we can call "ldconfig" once rather than in every
postinst.

Cheers,

Richard










-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#155163): 
https://lists.openembedded.org/g/openembedded-core/message/155163
Mute This Topic: https://lists.openembedded.org/mt/85083966/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 3/6] kernel-module-split.bbclass: Allow opt-out of split kernel modules

2021-08-23 Thread Zoltan Boszormenyi via lists.openembedded.org

2021. 08. 23. 15:27 keltezéssel, Bruce Ashfield írta:

On Mon, Aug 23, 2021 at 9:18 AM Böszörményi Zoltán  wrote:


2021. 08. 23. 14:55 keltezéssel, Bruce Ashfield írta:

On Mon, Aug 23, 2021 at 8:23 AM Zoltan Boszormenyi via
lists.openembedded.org  wrote:


From: Zoltán Böszörményi 

For some use cases, a monolithic kernel-modules package containing
all modules built from the kernel sources may be preferred.
For one, download time is shorter and installation time is faster.



There's still an outstanding issue though. Unless you generate the
provides/rdepends along with the monolithic package, any existing
rdepends on kernel modules break.


The next patch in the thread does it.


That's what my follow up said ;)

See my second reply though, this gap in functionality created by this
commit, should be documented in the commit that it will be restored in
future ones.


I can squash the two commits so there's no gap.



Cheers,

Bruce





While that likely isn't something you hit in your use case, it would
be something that would have to be covered to make this part of core.

About 7 years ago, I was most of the way through a similar change,
that created on large package with all the rprovides generated (I'm
not sure I can track it down now, but I could have a look), since
doing an on target update with thousands of kernel module package is
very painful.


Well, yes. In our defconfig, about 1500 kernel-module-* subpackages
were created and had to be upgraded at once. It was *very* painful
with over 50 minutes to download and upgrade the kernel.



Cheers,

Bruce


Set KERNEL_SPLIT_MODULES="0" for this.

The default is one subpackage per module.

Signed-off-by: Zoltán Böszörményi 
---
   meta/classes/kernel-module-split.bbclass | 17 +
   1 file changed, 13 insertions(+), 4 deletions(-)

diff --git a/meta/classes/kernel-module-split.bbclass 
b/meta/classes/kernel-module-split.bbclass
index 6c1de4c992..a29c294810 100644
--- a/meta/classes/kernel-module-split.bbclass
+++ b/meta/classes/kernel-module-split.bbclass
@@ -28,6 +28,7 @@ do_install:append() {
  install -d ${D}${sysconfdir}/modules-load.d/ 
${D}${sysconfdir}/modprobe.d/
   }

+KERNEL_SPLIT_MODULES ?= "1"
   PACKAGESPLITFUNCS:prepend = "split_kernel_module_packages "

   KERNEL_MODULES_META_PACKAGE ?= "${@ d.getVar("KERNEL_PACKAGE_NAME") or "kernel" 
}-modules"
@@ -156,18 +157,26 @@ python split_kernel_module_packages () {
   kernel_package_name = d.getVar("KERNEL_PACKAGE_NAME") or "kernel"
   kernel_version = d.getVar("KERNEL_VERSION")

+metapkg = d.getVar('KERNEL_MODULES_META_PACKAGE')
+splitmods = d.getVar('KERNEL_SPLIT_MODULES')
+postinst = d.getVar('pkg_postinst:modules')
+postrm = d.getVar('pkg_postrm:modules')
+
+if splitmods != '1':
+etcdir = d.getVar('sysconfdir')
+d.appendVar('FILES:' + metapkg, '%s/modules-load.d/ %s/modprobe.d/ %s/modules/' 
% (etcdir, etcdir, d.getVar("nonarch_base_libdir")))
+d.appendVar('pkg_postinst:%s' % metapkg, postinst)
+d.prependVar('pkg_postrm:%s' % metapkg, postrm);
+return
+
   module_regex = r'^(.*)\.k?o(?:\.(gz|xz|zst))?$'

   module_pattern_prefix = d.getVar('KERNEL_MODULE_PACKAGE_PREFIX')
   module_pattern_suffix = d.getVar('KERNEL_MODULE_PACKAGE_SUFFIX')
   module_pattern = module_pattern_prefix + kernel_package_name + 
'-module-%s' + module_pattern_suffix

-postinst = d.getVar('pkg_postinst:modules')
-postrm = d.getVar('pkg_postrm:modules')
-
   modules = do_split_packages(d, root='${nonarch_base_libdir}/modules', 
file_regex=module_regex, output_pattern=module_pattern, description='%s kernel 
module', postinst=postinst, postrm=postrm, recursive=True, hook=frob_metadata, 
extra_depends='%s-%s' % (kernel_package_name, kernel_version))
   if modules:
-metapkg = d.getVar('KERNEL_MODULES_META_PACKAGE')
   d.appendVar('RDEPENDS:' + metapkg, ' '+' '.join(modules))

   # If modules-load.d and modprobe.d are empty at this point, remove them 
to
--
2.31.1























-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#155160): 
https://lists.openembedded.org/g/openembedded-core/message/155160
Mute This Topic: https://lists.openembedded.org/mt/85083968/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 5/6] kernel.bbclass: Use full versions for inter-package dependencies

2021-08-23 Thread Zoltan Boszormenyi via lists.openembedded.org

2021. 08. 23. 15:03 keltezéssel, Bruce Ashfield írta:

On Mon, Aug 23, 2021 at 8:23 AM Zoltan Boszormenyi via
lists.openembedded.org  wrote:


From: Zoltán Böszörményi 

Some Yocto users do use package repositories and sometimes the PR
value is forgotten. Use full versions for inter-package dependencies
for the kernel subpackages.


Can you expand this commit message ?


I will send a new version with the expanded message.


What is the observable problem
with the full versions not being in the rdpends ?


Currently the kernel creates such subpackages:

kernel
kernel-x.y.z
kernel-image-x.y.z
kernel-image-bzimage-x.y.z
kernel-modules-x.y.z

and in the split modules case, a lot of

kernel-module-*-x.y.z

RDEPENDS currently only references the package names.

The issue I observe is this: I have enabled kernel module signing
but I don't provide a key, so the kernel will generate one at
every rebuild.

You get the idea what problem this can make if there's a
rebuild:

x.y.z-r0.0 -> x.y.z-r1.0 (in which case the PR value was duly changed)
or
x.y.z-r0.0 -> x.y.z-r0.1 (where not)

It's actually indifferent, but the same issue occurs if
only the kernel-image-bzimage is upgraded: the modules either
won't work or taint the kernel.

This scenario is currently valid in the package manager because
of the versionless RDEPENDS.



I've run many different package feeds with different kernels and
modules, and haven't run into anything on this front, in my experience
the extended version in the package depends/provides causes issues
with some package managers .. so we'd need the testing for this
documented/provided so we could ensure that there are no hidden
issues.

Bruce




Signed-off-by: Zoltán Böszörményi 
---
  meta/classes/kernel.bbclass | 13 +++--
  1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 6dc5387a9b..9ec7daa17a 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -91,17 +91,18 @@ python __anonymous () {
  kname = d.getVar('KERNEL_PACKAGE_NAME') or "kernel"
  imagedest = d.getVar('KERNEL_IMAGEDEST')

+fullver = d.getVar('EXTENDPKGV')
  for type in types.split():
  if bb.data.inherits_class('nopackages', d):
  continue
  typelower = type.lower()
  d.appendVar('PACKAGES', ' %s-image-%s' % (kname, typelower))
  d.setVar('FILES:' + kname + '-image-' + typelower, '/' + imagedest + 
'/' + type + '-${KERNEL_VERSION_NAME}' + ' /' + imagedest + '/' + type)
-d.appendVar('RDEPENDS:%s-image' % kname, ' %s-image-%s' % (kname, 
typelower))
+d.appendVar('RDEPENDS:%s-image' % kname, ' %s-image-%s (= %s)' % 
(kname, typelower, fullver))
  splitmods = d.getVar("KERNEL_SPLIT_MODULES")
  if splitmods != '1':
-d.appendVar('RDEPENDS:%s-image' % kname, ' %s-modules' % kname)
-d.appendVar('RDEPENDS:%s-image-%s' % (kname, typelower), ' 
%s-modules-${KERNEL_VERSION_PKG_NAME}' % kname)
+d.appendVar('RDEPENDS:%s-image' % kname, ' %s-modules (= %s)' % 
(kname, fullver))
+d.appendVar('RDEPENDS:%s-image-%s' % (kname, typelower), ' 
%s-modules-${KERNEL_VERSION_PKG_NAME} (= %s)' % (kname, fullver))
  d.setVar('PKG:%s-modules' % kname, 
'%s-modules-${KERNEL_VERSION_PKG_NAME}' % kname)
  d.appendVar('RPROVIDES:%s-modules' % kname, 
'%s-modules-${KERNEL_VERSION_PKG_NAME}' % kname)

@@ -628,12 +629,12 @@ FILES:${KERNEL_PACKAGE_NAME}-image = ""
  FILES:${KERNEL_PACKAGE_NAME}-dev = "/boot/System.map* /boot/Module.symvers* 
/boot/config* ${KERNEL_SRC_PATH} 
${nonarch_base_libdir}/modules/${KERNEL_VERSION}/build"
  FILES:${KERNEL_PACKAGE_NAME}-vmlinux = "/boot/vmlinux-${KERNEL_VERSION_NAME}"
  FILES:${KERNEL_PACKAGE_NAME}-modules = ""
-RDEPENDS:${KERNEL_PACKAGE_NAME} = "${KERNEL_PACKAGE_NAME}-base"
+RDEPENDS:${KERNEL_PACKAGE_NAME} = "${KERNEL_PACKAGE_NAME}-base (= 
${EXTENDPKGV})"
  # Allow machines to override this dependency if kernel image files are
  # not wanted in images as standard
-RDEPENDS:${KERNEL_PACKAGE_NAME}-base ?= "${KERNEL_PACKAGE_NAME}-image"
+RDEPENDS:${KERNEL_PACKAGE_NAME}-base ?= "${KERNEL_PACKAGE_NAME}-image (= 
${EXTENDPKGV})"
  PKG:${KERNEL_PACKAGE_NAME}-image = 
"${KERNEL_PACKAGE_NAME}-image-${@legitimize_package_name(d.getVar('KERNEL_VERSION'))}"
-RDEPENDS:${KERNEL_PACKAGE_NAME}-image += 
"${@oe.utils.conditional('KERNEL_IMAGETYPE', 'vmlinux', 
'${KERNEL_PACKAGE_NAME}-vmlinux', '', d)}"
+RDEPENDS:${KERNEL_PACKAGE_NAME}-image += 
"${@oe.utils.conditional('KERNEL_IMAGETYPE', 'vmlinux', 
'${KERNEL_PACKAGE_NAME}-vmlinux (= ${EXTENDPKGV})', '', d)}"
  PKG:${KERNEL_PACKAGE_NAME}-base = 
"${KERNEL_PACKAGE_NAME}-${@legitimize_package_name(d.getVar('KERNEL_VERSION'))}"
  RPROVIDES:${KERNEL_PACKAGE_NAME}-base += 
"

Re: [OE-core] [PATCH 3/6] kernel-module-split.bbclass: Allow opt-out of split kernel modules

2021-08-23 Thread Zoltan Boszormenyi via lists.openembedded.org

2021. 08. 23. 14:55 keltezéssel, Bruce Ashfield írta:

On Mon, Aug 23, 2021 at 8:23 AM Zoltan Boszormenyi via
lists.openembedded.org  wrote:


From: Zoltán Böszörményi 

For some use cases, a monolithic kernel-modules package containing
all modules built from the kernel sources may be preferred.
For one, download time is shorter and installation time is faster.



There's still an outstanding issue though. Unless you generate the
provides/rdepends along with the monolithic package, any existing
rdepends on kernel modules break.


The next patch in the thread does it.



While that likely isn't something you hit in your use case, it would
be something that would have to be covered to make this part of core.

About 7 years ago, I was most of the way through a similar change,
that created on large package with all the rprovides generated (I'm
not sure I can track it down now, but I could have a look), since
doing an on target update with thousands of kernel module package is
very painful.


Well, yes. In our defconfig, about 1500 kernel-module-* subpackages
were created and had to be upgraded at once. It was *very* painful
with over 50 minutes to download and upgrade the kernel.



Cheers,

Bruce


Set KERNEL_SPLIT_MODULES="0" for this.

The default is one subpackage per module.

Signed-off-by: Zoltán Böszörményi 
---
  meta/classes/kernel-module-split.bbclass | 17 +
  1 file changed, 13 insertions(+), 4 deletions(-)

diff --git a/meta/classes/kernel-module-split.bbclass 
b/meta/classes/kernel-module-split.bbclass
index 6c1de4c992..a29c294810 100644
--- a/meta/classes/kernel-module-split.bbclass
+++ b/meta/classes/kernel-module-split.bbclass
@@ -28,6 +28,7 @@ do_install:append() {
 install -d ${D}${sysconfdir}/modules-load.d/ 
${D}${sysconfdir}/modprobe.d/
  }

+KERNEL_SPLIT_MODULES ?= "1"
  PACKAGESPLITFUNCS:prepend = "split_kernel_module_packages "

  KERNEL_MODULES_META_PACKAGE ?= "${@ d.getVar("KERNEL_PACKAGE_NAME") or "kernel" 
}-modules"
@@ -156,18 +157,26 @@ python split_kernel_module_packages () {
  kernel_package_name = d.getVar("KERNEL_PACKAGE_NAME") or "kernel"
  kernel_version = d.getVar("KERNEL_VERSION")

+metapkg = d.getVar('KERNEL_MODULES_META_PACKAGE')
+splitmods = d.getVar('KERNEL_SPLIT_MODULES')
+postinst = d.getVar('pkg_postinst:modules')
+postrm = d.getVar('pkg_postrm:modules')
+
+if splitmods != '1':
+etcdir = d.getVar('sysconfdir')
+d.appendVar('FILES:' + metapkg, '%s/modules-load.d/ %s/modprobe.d/ %s/modules/' 
% (etcdir, etcdir, d.getVar("nonarch_base_libdir")))
+d.appendVar('pkg_postinst:%s' % metapkg, postinst)
+d.prependVar('pkg_postrm:%s' % metapkg, postrm);
+return
+
  module_regex = r'^(.*)\.k?o(?:\.(gz|xz|zst))?$'

  module_pattern_prefix = d.getVar('KERNEL_MODULE_PACKAGE_PREFIX')
  module_pattern_suffix = d.getVar('KERNEL_MODULE_PACKAGE_SUFFIX')
  module_pattern = module_pattern_prefix + kernel_package_name + 
'-module-%s' + module_pattern_suffix

-postinst = d.getVar('pkg_postinst:modules')
-postrm = d.getVar('pkg_postrm:modules')
-
  modules = do_split_packages(d, root='${nonarch_base_libdir}/modules', 
file_regex=module_regex, output_pattern=module_pattern, description='%s kernel 
module', postinst=postinst, postrm=postrm, recursive=True, hook=frob_metadata, 
extra_depends='%s-%s' % (kernel_package_name, kernel_version))
  if modules:
-metapkg = d.getVar('KERNEL_MODULES_META_PACKAGE')
  d.appendVar('RDEPENDS:' + metapkg, ' '+' '.join(modules))

  # If modules-load.d and modprobe.d are empty at this point, remove them to
--
2.31.1














-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#155156): 
https://lists.openembedded.org/g/openembedded-core/message/155156
Mute This Topic: https://lists.openembedded.org/mt/85083968/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/6] package_rpm.bbclass: Handle posttrans scriptlets

2021-08-23 Thread Zoltan Boszormenyi via lists.openembedded.org

It's documented at www.rpm.org, Red Hat and SuSE.

https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/
https://en.opensuse.org/openSUSE:Packaging_scriptlet_snippets
https://rpm-packaging-guide.github.io/

It's available since RPM 4.4. RPM 4.16.1.3 is in Hardknott.

A short Google search showed that *maybe* dpkg also supports it,
or at least there are(were?) plans to implement it:
https://wiki.debian.org/i18n/TranslationDebsProposals

With postinst, the time when the scriptlet runs may depend
on the order of the packages in the upgrade transaction and
may run with the older binaries in place.

The posttrans scriptlet runs at the very end of the
install/upgrade transaction, just like the OPKG "intercept"
scripts.

I successfully tested it long ago with a kernel upgrade
that was running dracut on the new version, plus a dracut
upgrade in the same session. Dissecting the initramfs proved
that with postinst, the old dracut version generated it,
while with posttrans, the new one did.

Who would want to use it? Anyone who needs some finalizer
script to be run at the end of an RPM/DNF transaction.

I started on Angstrom and I know opkg doesn't implement this
and Yocto inherited it. This patch is basically a heads up
that there's another way to do the same thing. Maybe opkg
implements this some day, maybe not. Anyway, Yocto in general
will need more changes before the main package.bbclass can
start to use it for all package formats.

Zoltán

2021. 08. 23. 14:34 keltezéssel, Alexander Kanavin írta:

This needs to be better documented and tested.

What does this posttrans thing really do?
Who would want to use it?
Can there be examples?
Can the Postinst test in meta/lib/oeqa/selftest/cases/runtime_test.py be extended to 
regression-check that it works?


Alex

On Mon, 23 Aug 2021 at 14:23, Zoltan Boszormenyi via lists.openembedded.org 
<http://lists.openembedded.org> <mailto:pr...@lists.openembedded.org>> wrote:


From: Zoltán Böszörményi mailto:zbos...@gmail.com>>

The "posttrans" scriptlet is the RPM equivalent of the
OPKG "intercept script" concept and probably a cleaner one.

"pretrans" also exists in RPM but there's no equivalent
for it in OPKG.

Signed-off-by: Zoltán Böszörményi mailto:zbos...@gmail.com>>
---
  meta/classes/package_rpm.bbclass | 30 +-
  1 file changed, 21 insertions(+), 9 deletions(-)

diff --git a/meta/classes/package_rpm.bbclass 
b/meta/classes/package_rpm.bbclass
index 88d861c0e7..5992d3fd06 100644
--- a/meta/classes/package_rpm.bbclass
+++ b/meta/classes/package_rpm.bbclass
@@ -308,10 +308,11 @@ python write_specfile () {
      srcrconflicts  = ""
      srcrobsoletes  = ""

-    srcrpreinst  = []
-    srcrpostinst = []
-    srcrprerm    = []
-    srcrpostrm   = []
+    srcrpreinst   = []
+    srcrpostinst  = []
+    srcrprerm     = []
+    srcrpostrm    = []
+    srcrposttrans = []

      spec_preamble_top = []
      spec_preamble_bottom = []
@@ -373,11 +374,11 @@ python write_specfile () {
          splitrconflicts  = localdata.getVar('RCONFLICTS') or ""
          splitrobsoletes  = ""

-        splitrpreinst  = localdata.getVar('pkg_preinst')
-        splitrpostinst = localdata.getVar('pkg_postinst')
-        splitrprerm    = localdata.getVar('pkg_prerm')
-        splitrpostrm   = localdata.getVar('pkg_postrm')
-
+        splitrpreinst   = localdata.getVar('pkg_preinst')
+        splitrpostinst  = localdata.getVar('pkg_postinst')
+        splitrprerm     = localdata.getVar('pkg_prerm')
+        splitrpostrm    = localdata.getVar('pkg_postrm')
+        splitrposttrans = localdata.getVar('pkg_posttrans')

          if not perfiledeps:
              # Add in summary of per file dependencies
@@ -405,6 +406,7 @@ python write_specfile () {
              srcrpostinst   = splitrpostinst
              srcrprerm      = splitrprerm
              srcrpostrm     = splitrpostrm
+            srcrposttrans  = splitrposttrans

              file_list = []
              walk_files(root, file_list, conffiles, dirfiles)
@@ -496,6 +498,11 @@ python write_specfile () {
              scriptvar = wrap_uninstall(splitrpostrm)
              spec_scriptlets_bottom.append(scriptvar)
              spec_scriptlets_bottom.append('')
+        if splitrposttrans:
+            spec_scriptlets_bottom.append('%%posttrans -n %s' % splitname)
+            spec_scriptlets_bottom.append('# %s - posttrans' % splitname)
+            spec_scriptlets_bottom.append(splitrposttrans)
+            spec_scriptlets_bottom.append('')

          # Now process files
          file_list = []
@@ -590,6 +597,11 @@ python write_specfile (

[OE-core] [PATCH 6/6] Support zstd-compressed squashfs and cpio initramfs

2021-08-23 Thread Zoltan Boszormenyi via lists.openembedded.org
From: Zoltán Böszörményi 

Signed-off-by: Zoltán Böszörményi 
---
 meta/classes/base.bbclass|  4 
 meta/classes/image_types.bbclass |  6 --
 meta/classes/kernel-fitimage.bbclass |  2 +-
 meta/classes/kernel.bbclass  | 10 --
 4 files changed, 17 insertions(+), 5 deletions(-)

diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index 11b65171d9..340ebe7d78 100644
--- a/meta/classes/base.bbclass
+++ b/meta/classes/base.bbclass
@@ -631,6 +631,10 @@ python () {
 if path.endswith('.lz4'):
 d.appendVarFlag('do_unpack', 'depends', ' 
lz4-native:do_populate_sysroot')
 
+# *.zst should DEPEND on zstd-native for unpacking
+elif path.endswith('.zst'):
+d.appendVarFlag('do_unpack', 'depends', ' 
zstd-native:do_populate_sysroot')
+
 # *.lz should DEPEND on lzip-native for unpacking
 elif path.endswith('.lz'):
 d.appendVarFlag('do_unpack', 'depends', ' 
lzip-native:do_populate_sysroot')
diff --git a/meta/classes/image_types.bbclass b/meta/classes/image_types.bbclass
index e0eb06c1e3..32d4cd4c76 100644
--- a/meta/classes/image_types.bbclass
+++ b/meta/classes/image_types.bbclass
@@ -107,6 +107,7 @@ IMAGE_CMD:squashfs = "mksquashfs ${IMAGE_ROOTFS} 
${IMGDEPLOYDIR}/${IMAGE_NAME}${
 IMAGE_CMD:squashfs-xz = "mksquashfs ${IMAGE_ROOTFS} 
${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.squashfs-xz ${EXTRA_IMAGECMD} 
-noappend -comp xz"
 IMAGE_CMD:squashfs-lzo = "mksquashfs ${IMAGE_ROOTFS} 
${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.squashfs-lzo 
${EXTRA_IMAGECMD} -noappend -comp lzo"
 IMAGE_CMD:squashfs-lz4 = "mksquashfs ${IMAGE_ROOTFS} 
${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.squashfs-lz4 
${EXTRA_IMAGECMD} -noappend -comp lz4"
+IMAGE_CMD:squashfs-zst = "mksquashfs ${IMAGE_ROOTFS} 
${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.squashfs-zst 
${EXTRA_IMAGECMD} -noappend -comp zstd"
 
 IMAGE_CMD:erofs = "mkfs.erofs ${EXTRA_IMAGECMD} 
${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.erofs ${IMAGE_ROOTFS}"
 IMAGE_CMD:erofs-lz4 = "mkfs.erofs -zlz4 ${EXTRA_IMAGECMD} 
${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.erofs-lz4 ${IMAGE_ROOTFS}"
@@ -244,6 +245,7 @@ do_image_squashfs[depends] += 
"squashfs-tools-native:do_populate_sysroot"
 do_image_squashfs_xz[depends] += "squashfs-tools-native:do_populate_sysroot"
 do_image_squashfs_lzo[depends] += "squashfs-tools-native:do_populate_sysroot"
 do_image_squashfs_lz4[depends] += "squashfs-tools-native:do_populate_sysroot"
+do_image_squashfs_zst[depends] += "squashfs-tools-native:do_populate_sysroot"
 do_image_ubi[depends] += "mtd-utils-native:do_populate_sysroot"
 do_image_ubifs[depends] += "mtd-utils-native:do_populate_sysroot"
 do_image_multiubi[depends] += "mtd-utils-native:do_populate_sysroot"
@@ -262,10 +264,10 @@ IMAGE_TYPES = " \
 btrfs \
 iso \
 hddimg \
-squashfs squashfs-xz squashfs-lzo squashfs-lz4 \
+squashfs squashfs-xz squashfs-lzo squashfs-lz4 squashfs-zst \
 ubi ubifs multiubi \
 tar tar.gz tar.bz2 tar.xz tar.lz4 tar.zst \
-cpio cpio.gz cpio.xz cpio.lzma cpio.lz4 \
+cpio cpio.gz cpio.xz cpio.lzma cpio.lz4 cpio.zst \
 wic wic.gz wic.bz2 wic.lzma wic.zst \
 container \
 f2fs \
diff --git a/meta/classes/kernel-fitimage.bbclass 
b/meta/classes/kernel-fitimage.bbclass
index 2ef8f06b14..38e05153e3 100644
--- a/meta/classes/kernel-fitimage.bbclass
+++ b/meta/classes/kernel-fitimage.bbclass
@@ -576,7 +576,7 @@ fitimage_assemble() {
#
if [ "x${ramdiskcount}" = "x1" ] && [ "${INITRAMFS_IMAGE_BUNDLE}" != 
"1" ]; then
# Find and use the first initramfs image archive type we find
-   for img in cpio.lz4 cpio.lzo cpio.lzma cpio.xz cpio.gz ext2.gz 
cpio; do
+   for img in cpio.lz4 cpio.lzo cpio.lzma cpio.xz cpio.zst cpio.gz 
ext2.gz cpio; do

initramfs_path="${DEPLOY_DIR_IMAGE}/${INITRAMFS_IMAGE_NAME}.${img}"
echo "Using $initramfs_path"
if [ -e "${initramfs_path}" ]; then
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 9ec7daa17a..ab60e060c6 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -9,6 +9,7 @@ PROVIDES += "${@ "virtual/kernel" if 
(d.getVar("KERNEL_PACKAGE_NAME") == "kernel
 DEPENDS += "virtual/${TARGET_PREFIX}binutils virtual/${TARGET_PREFIX}gcc 
kmod-native bc-native bison-native"
 DEPENDS += "${@bb.utils.contains("INITRAMFS_FSTYPES", "cpio.lzo", 
"lzop-native", "", d)}"
 DEPENDS += "${@bb.utils.contains("INITRAMFS_FSTYPES", "cpio.lz4", 
"lz4-native", "", d)}"
+DEPENDS += "${@bb.utils.contains("INITRAMFS_FSTYPES", "cpio.zst", 
"zstd-native", "", d)}"
 PACKAGE_WRITE_DEPS += "depmodwrapper-cross"
 
 do_deploy[depends] += "depmodwrapper-cross:do_populate_sysroot 
gzip-native:do_populate_sysroot"
@@ -237,7 +238,7 @@ copy_initramfs() {
mkdir -p ${B}/usr
# Find and use the first 

[OE-core] [PATCH 5/6] kernel.bbclass: Use full versions for inter-package dependencies

2021-08-23 Thread Zoltan Boszormenyi via lists.openembedded.org
From: Zoltán Böszörményi 

Some Yocto users do use package repositories and sometimes the PR
value is forgotten. Use full versions for inter-package dependencies
for the kernel subpackages.

Signed-off-by: Zoltán Böszörményi 
---
 meta/classes/kernel.bbclass | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 6dc5387a9b..9ec7daa17a 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -91,17 +91,18 @@ python __anonymous () {
 kname = d.getVar('KERNEL_PACKAGE_NAME') or "kernel"
 imagedest = d.getVar('KERNEL_IMAGEDEST')
 
+fullver = d.getVar('EXTENDPKGV')
 for type in types.split():
 if bb.data.inherits_class('nopackages', d):
 continue
 typelower = type.lower()
 d.appendVar('PACKAGES', ' %s-image-%s' % (kname, typelower))
 d.setVar('FILES:' + kname + '-image-' + typelower, '/' + imagedest + 
'/' + type + '-${KERNEL_VERSION_NAME}' + ' /' + imagedest + '/' + type)
-d.appendVar('RDEPENDS:%s-image' % kname, ' %s-image-%s' % (kname, 
typelower))
+d.appendVar('RDEPENDS:%s-image' % kname, ' %s-image-%s (= %s)' % 
(kname, typelower, fullver))
 splitmods = d.getVar("KERNEL_SPLIT_MODULES")
 if splitmods != '1':
-d.appendVar('RDEPENDS:%s-image' % kname, ' %s-modules' % kname)
-d.appendVar('RDEPENDS:%s-image-%s' % (kname, typelower), ' 
%s-modules-${KERNEL_VERSION_PKG_NAME}' % kname)
+d.appendVar('RDEPENDS:%s-image' % kname, ' %s-modules (= %s)' % 
(kname, fullver))
+d.appendVar('RDEPENDS:%s-image-%s' % (kname, typelower), ' 
%s-modules-${KERNEL_VERSION_PKG_NAME} (= %s)' % (kname, fullver))
 d.setVar('PKG:%s-modules' % kname, 
'%s-modules-${KERNEL_VERSION_PKG_NAME}' % kname)
 d.appendVar('RPROVIDES:%s-modules' % kname, 
'%s-modules-${KERNEL_VERSION_PKG_NAME}' % kname)
 
@@ -628,12 +629,12 @@ FILES:${KERNEL_PACKAGE_NAME}-image = ""
 FILES:${KERNEL_PACKAGE_NAME}-dev = "/boot/System.map* /boot/Module.symvers* 
/boot/config* ${KERNEL_SRC_PATH} 
${nonarch_base_libdir}/modules/${KERNEL_VERSION}/build"
 FILES:${KERNEL_PACKAGE_NAME}-vmlinux = "/boot/vmlinux-${KERNEL_VERSION_NAME}"
 FILES:${KERNEL_PACKAGE_NAME}-modules = ""
-RDEPENDS:${KERNEL_PACKAGE_NAME} = "${KERNEL_PACKAGE_NAME}-base"
+RDEPENDS:${KERNEL_PACKAGE_NAME} = "${KERNEL_PACKAGE_NAME}-base (= 
${EXTENDPKGV})"
 # Allow machines to override this dependency if kernel image files are
 # not wanted in images as standard
-RDEPENDS:${KERNEL_PACKAGE_NAME}-base ?= "${KERNEL_PACKAGE_NAME}-image"
+RDEPENDS:${KERNEL_PACKAGE_NAME}-base ?= "${KERNEL_PACKAGE_NAME}-image (= 
${EXTENDPKGV})"
 PKG:${KERNEL_PACKAGE_NAME}-image = 
"${KERNEL_PACKAGE_NAME}-image-${@legitimize_package_name(d.getVar('KERNEL_VERSION'))}"
-RDEPENDS:${KERNEL_PACKAGE_NAME}-image += 
"${@oe.utils.conditional('KERNEL_IMAGETYPE', 'vmlinux', 
'${KERNEL_PACKAGE_NAME}-vmlinux', '', d)}"
+RDEPENDS:${KERNEL_PACKAGE_NAME}-image += 
"${@oe.utils.conditional('KERNEL_IMAGETYPE', 'vmlinux', 
'${KERNEL_PACKAGE_NAME}-vmlinux (= ${EXTENDPKGV})', '', d)}"
 PKG:${KERNEL_PACKAGE_NAME}-base = 
"${KERNEL_PACKAGE_NAME}-${@legitimize_package_name(d.getVar('KERNEL_VERSION'))}"
 RPROVIDES:${KERNEL_PACKAGE_NAME}-base += 
"${KERNEL_PACKAGE_NAME}-${KERNEL_VERSION}"
 ALLOW_EMPTY:${KERNEL_PACKAGE_NAME} = "1"
-- 
2.31.1


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



[OE-core] [PATCH 4/6] kernel.bbclass: Adapt to KERNEL_SPLIT_MODULES != "1" case

2021-08-23 Thread Zoltan Boszormenyi via lists.openembedded.org
From: Zoltán Böszörményi 

Extra RDEPENDS and other inter-package references are needed.

Signed-off-by: Zoltán Böszörményi 
---
 meta/classes/kernel.bbclass | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 027e66eec7..6dc5387a9b 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -98,6 +98,13 @@ python __anonymous () {
 d.appendVar('PACKAGES', ' %s-image-%s' % (kname, typelower))
 d.setVar('FILES:' + kname + '-image-' + typelower, '/' + imagedest + 
'/' + type + '-${KERNEL_VERSION_NAME}' + ' /' + imagedest + '/' + type)
 d.appendVar('RDEPENDS:%s-image' % kname, ' %s-image-%s' % (kname, 
typelower))
+splitmods = d.getVar("KERNEL_SPLIT_MODULES")
+if splitmods != '1':
+d.appendVar('RDEPENDS:%s-image' % kname, ' %s-modules' % kname)
+d.appendVar('RDEPENDS:%s-image-%s' % (kname, typelower), ' 
%s-modules-${KERNEL_VERSION_PKG_NAME}' % kname)
+d.setVar('PKG:%s-modules' % kname, 
'%s-modules-${KERNEL_VERSION_PKG_NAME}' % kname)
+d.appendVar('RPROVIDES:%s-modules' % kname, 
'%s-modules-${KERNEL_VERSION_PKG_NAME}' % kname)
+
 d.setVar('PKG:%s-image-%s' % (kname,typelower), 
'%s-image-%s-${KERNEL_VERSION_PKG_NAME}' % (kname, typelower))
 d.setVar('ALLOW_EMPTY:%s-image-%s' % (kname, typelower), '1')
 d.setVar('pkg_postinst:%s-image-%s' % (kname,typelower), """set +e
-- 
2.31.1


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



[OE-core] [PATCH 3/6] kernel-module-split.bbclass: Allow opt-out of split kernel modules

2021-08-23 Thread Zoltan Boszormenyi via lists.openembedded.org
From: Zoltán Böszörményi 

For some use cases, a monolithic kernel-modules package containing
all modules built from the kernel sources may be preferred.
For one, download time is shorter and installation time is faster.

Set KERNEL_SPLIT_MODULES="0" for this.

The default is one subpackage per module.

Signed-off-by: Zoltán Böszörményi 
---
 meta/classes/kernel-module-split.bbclass | 17 +
 1 file changed, 13 insertions(+), 4 deletions(-)

diff --git a/meta/classes/kernel-module-split.bbclass 
b/meta/classes/kernel-module-split.bbclass
index 6c1de4c992..a29c294810 100644
--- a/meta/classes/kernel-module-split.bbclass
+++ b/meta/classes/kernel-module-split.bbclass
@@ -28,6 +28,7 @@ do_install:append() {
install -d ${D}${sysconfdir}/modules-load.d/ 
${D}${sysconfdir}/modprobe.d/
 }
 
+KERNEL_SPLIT_MODULES ?= "1"
 PACKAGESPLITFUNCS:prepend = "split_kernel_module_packages "
 
 KERNEL_MODULES_META_PACKAGE ?= "${@ d.getVar("KERNEL_PACKAGE_NAME") or 
"kernel" }-modules"
@@ -156,18 +157,26 @@ python split_kernel_module_packages () {
 kernel_package_name = d.getVar("KERNEL_PACKAGE_NAME") or "kernel"
 kernel_version = d.getVar("KERNEL_VERSION")
 
+metapkg = d.getVar('KERNEL_MODULES_META_PACKAGE')
+splitmods = d.getVar('KERNEL_SPLIT_MODULES')
+postinst = d.getVar('pkg_postinst:modules')
+postrm = d.getVar('pkg_postrm:modules')
+
+if splitmods != '1':
+etcdir = d.getVar('sysconfdir')
+d.appendVar('FILES:' + metapkg, '%s/modules-load.d/ %s/modprobe.d/ 
%s/modules/' % (etcdir, etcdir, d.getVar("nonarch_base_libdir")))
+d.appendVar('pkg_postinst:%s' % metapkg, postinst)
+d.prependVar('pkg_postrm:%s' % metapkg, postrm);
+return
+
 module_regex = r'^(.*)\.k?o(?:\.(gz|xz|zst))?$'
 
 module_pattern_prefix = d.getVar('KERNEL_MODULE_PACKAGE_PREFIX')
 module_pattern_suffix = d.getVar('KERNEL_MODULE_PACKAGE_SUFFIX')
 module_pattern = module_pattern_prefix + kernel_package_name + 
'-module-%s' + module_pattern_suffix
 
-postinst = d.getVar('pkg_postinst:modules')
-postrm = d.getVar('pkg_postrm:modules')
-
 modules = do_split_packages(d, root='${nonarch_base_libdir}/modules', 
file_regex=module_regex, output_pattern=module_pattern, description='%s kernel 
module', postinst=postinst, postrm=postrm, recursive=True, hook=frob_metadata, 
extra_depends='%s-%s' % (kernel_package_name, kernel_version))
 if modules:
-metapkg = d.getVar('KERNEL_MODULES_META_PACKAGE')
 d.appendVar('RDEPENDS:' + metapkg, ' '+' '.join(modules))
 
 # If modules-load.d and modprobe.d are empty at this point, remove them to
-- 
2.31.1


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



[OE-core] [PATCH 2/6] kernel-module-split.bbclass: Support zstd-compressed modules

2021-08-23 Thread Zoltan Boszormenyi via lists.openembedded.org
From: Zoltán Böszörményi 

Signed-off-by: Zoltán Böszörményi 
---
 meta/classes/kernel-module-split.bbclass | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/meta/classes/kernel-module-split.bbclass 
b/meta/classes/kernel-module-split.bbclass
index b56dd4a9c7..6c1de4c992 100644
--- a/meta/classes/kernel-module-split.bbclass
+++ b/meta/classes/kernel-module-split.bbclass
@@ -44,17 +44,20 @@ python split_kernel_module_packages () {
 def extract_modinfo(file):
 import tempfile, subprocess
 tempfile.tempdir = d.getVar("WORKDIR")
-compressed = re.match( r'.*\.([xg])z$', file)
+compressed = re.match( r'.*\.(gz|xz|zst)$', file)
 tf = tempfile.mkstemp()
 tmpfile = tf[1]
 if compressed:
 tmpkofile = tmpfile + ".ko"
-if compressed.group(1) == 'g':
+if compressed.group(1) == 'gz':
 cmd = "gunzip -dc %s > %s" % (file, tmpkofile)
 subprocess.check_call(cmd, shell=True)
-elif compressed.group(1) == 'x':
+elif compressed.group(1) == 'xz':
 cmd = "xz -dc %s > %s" % (file, tmpkofile)
 subprocess.check_call(cmd, shell=True)
+elif compressed.group(1) == 'zst':
+cmd = "zstd -dc %s > %s" % (file, tmpkofile)
+subprocess.check_call(cmd, shell=True)
 else:
 msg = "Cannot decompress '%s'" % file
 raise msg
@@ -153,7 +156,7 @@ python split_kernel_module_packages () {
 kernel_package_name = d.getVar("KERNEL_PACKAGE_NAME") or "kernel"
 kernel_version = d.getVar("KERNEL_VERSION")
 
-module_regex = r'^(.*)\.k?o(?:\.[xg]z)?$'
+module_regex = r'^(.*)\.k?o(?:\.(gz|xz|zst))?$'
 
 module_pattern_prefix = d.getVar('KERNEL_MODULE_PACKAGE_PREFIX')
 module_pattern_suffix = d.getVar('KERNEL_MODULE_PACKAGE_SUFFIX')
-- 
2.31.1


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



[OE-core] [PATCH 1/6] package_rpm.bbclass: Handle posttrans scriptlets

2021-08-23 Thread Zoltan Boszormenyi via lists.openembedded.org
From: Zoltán Böszörményi 

The "posttrans" scriptlet is the RPM equivalent of the
OPKG "intercept script" concept and probably a cleaner one.

"pretrans" also exists in RPM but there's no equivalent
for it in OPKG.

Signed-off-by: Zoltán Böszörményi 
---
 meta/classes/package_rpm.bbclass | 30 +-
 1 file changed, 21 insertions(+), 9 deletions(-)

diff --git a/meta/classes/package_rpm.bbclass b/meta/classes/package_rpm.bbclass
index 88d861c0e7..5992d3fd06 100644
--- a/meta/classes/package_rpm.bbclass
+++ b/meta/classes/package_rpm.bbclass
@@ -308,10 +308,11 @@ python write_specfile () {
 srcrconflicts  = ""
 srcrobsoletes  = ""
 
-srcrpreinst  = []
-srcrpostinst = []
-srcrprerm= []
-srcrpostrm   = []
+srcrpreinst   = []
+srcrpostinst  = []
+srcrprerm = []
+srcrpostrm= []
+srcrposttrans = []
 
 spec_preamble_top = []
 spec_preamble_bottom = []
@@ -373,11 +374,11 @@ python write_specfile () {
 splitrconflicts  = localdata.getVar('RCONFLICTS') or ""
 splitrobsoletes  = ""
 
-splitrpreinst  = localdata.getVar('pkg_preinst')
-splitrpostinst = localdata.getVar('pkg_postinst')
-splitrprerm= localdata.getVar('pkg_prerm')
-splitrpostrm   = localdata.getVar('pkg_postrm')
-
+splitrpreinst   = localdata.getVar('pkg_preinst')
+splitrpostinst  = localdata.getVar('pkg_postinst')
+splitrprerm = localdata.getVar('pkg_prerm')
+splitrpostrm= localdata.getVar('pkg_postrm')
+splitrposttrans = localdata.getVar('pkg_posttrans')
 
 if not perfiledeps:
 # Add in summary of per file dependencies
@@ -405,6 +406,7 @@ python write_specfile () {
 srcrpostinst   = splitrpostinst
 srcrprerm  = splitrprerm
 srcrpostrm = splitrpostrm
+srcrposttrans  = splitrposttrans
 
 file_list = []
 walk_files(root, file_list, conffiles, dirfiles)
@@ -496,6 +498,11 @@ python write_specfile () {
 scriptvar = wrap_uninstall(splitrpostrm)
 spec_scriptlets_bottom.append(scriptvar)
 spec_scriptlets_bottom.append('')
+if splitrposttrans:
+spec_scriptlets_bottom.append('%%posttrans -n %s' % splitname)
+spec_scriptlets_bottom.append('# %s - posttrans' % splitname)
+spec_scriptlets_bottom.append(splitrposttrans)
+spec_scriptlets_bottom.append('')
 
 # Now process files
 file_list = []
@@ -590,6 +597,11 @@ python write_specfile () {
 scriptvar = wrap_uninstall(srcrpostrm)
 spec_scriptlets_top.append(scriptvar)
 spec_scriptlets_top.append('')
+if srcrposttrans:
+spec_scriptlets_top.append('%posttrans')
+spec_scriptlets_top.append('# %s - posttrans' % srcname)
+spec_scriptlets_top.append(srcrposttrans)
+spec_scriptlets_top.append('')
 
 # Write the SPEC file
 specfile = open(outspecfile, 'w')
-- 
2.31.1


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



[OE-core] Kernel and RPM related bbclass changes

2021-08-23 Thread Zoltan Boszormenyi via lists.openembedded.org
I have been carrying some forked bbclass recipes and I think
these can be beneficial to others, not to mention that I could
get rid of the private forks of these.

Please, review.

Best regards,
Zoltán Böszörményi



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#155143): 
https://lists.openembedded.org/g/openembedded-core/message/155143
Mute This Topic: https://lists.openembedded.org/mt/85083965/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] xserver-xorg: upgrade 1.20.11 -> 21.0.99.1

2021-07-08 Thread Zoltan Boszormenyi via lists.openembedded.org

2021. 07. 08. 7:38 keltezéssel, Alexander Kanavin írta:

This is a development snapshot, should not be used.


Still, it works a lot better than the 1.20.x stable branch.



Alex

On Thu 8. Jul 2021 at 2.18, wangmy mailto:wan...@fujitsu.com>> wrote:

0001-test-xtest-Initialize-array-with-braces.patch
pkgconfig.patch
sdksyms-no-build-path.patch
removed since they're included in 21.0.99.1

refresh 0001-Avoid-duplicate-definitions-of-IOPortBase.patch

Signed-off-by: Wang Mingyu mailto:wan...@fujitsu.com>>
---
  .../xorg-xserver/xserver-xorg.inc             |  3 +-
  ...-duplicate-definitions-of-IOPortBase.patch | 16 +-
  ...t-xtest-Initialize-array-with-braces.patch | 36 -
  .../xorg-xserver/xserver-xorg/pkgconfig.patch | 34 -
  .../xserver-xorg/sdksyms-no-build-path.patch  | 50 ---
  ...g_1.20.11.bb  => xserver-xorg_21.0.99.1.bb
} |  6 +--
  6 files changed, 4 insertions(+), 141 deletions(-)
  delete mode 100644

meta/recipes-graphics/xorg-xserver/xserver-xorg/0001-test-xtest-Initialize-array-with-braces.patch
  delete mode 100644 
meta/recipes-graphics/xorg-xserver/xserver-xorg/pkgconfig.patch
  delete mode 100644
meta/recipes-graphics/xorg-xserver/xserver-xorg/sdksyms-no-build-path.patch
  rename meta/recipes-graphics/xorg-xserver/{xserver-xorg_1.20.11.bb
 => xserver-xorg_21.0.99.1.bb
} (77%)

diff --git a/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc
b/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc
index da025171db..7bbff0073b 100644
--- a/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc
+++ b/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc
@@ -65,6 +65,7 @@ PACKAGES =+ "${PN}-sdl \
               ${PN}-module-xaa \
               ${PN}-module-libxf1bpp \
               ${PN}-module-libxf4bpp \
+            ${PN}-input-modules \
               xf86-video-modesetting"

  SUMMARY_xf86-video-modesetting = "X.Org X server -- modesetting display 
driver"
@@ -101,6 +102,7 @@ FILES_${PN}-module-exa = 
"${libdir}/xorg/modules/libexa.so"
  FILES_${PN}-module-xaa = "${libdir}/xorg/modules/libxaa.so"
  FILES_${PN}-module-libxf1bpp = "${libdir}/xorg/modules/libxf1bpp.so"
  FILES_${PN}-module-libxf4bpp = "${libdir}/xorg/modules/libxf4bpp.so"
+FILES_${PN}-input-modules = "${libdir}/xorg/modules/input/*drv*"
  FILES_xf86-video-modesetting = 
"${libdir}/xorg/modules/drivers/modesetting_drv.so"

  EXTRA_OECONF += "--with-fop=no \
@@ -116,7 +118,6 @@ EXTRA_OECONF += "--with-fop=no \
                   --sysconfdir=/etc/X11 \
                   --localstatedir=/var \
                   --with-xkb-output=/var/lib/xkb \
-                 --with-os-name=Linux \
  "

  OPENGL_PKGCONFIGS = "dri glx glamor dri3 xshmfence"
diff --git

a/meta/recipes-graphics/xorg-xserver/xserver-xorg/0001-Avoid-duplicate-definitions-of-IOPortBase.patch

b/meta/recipes-graphics/xorg-xserver/xserver-xorg/0001-Avoid-duplicate-definitions-of-IOPortBase.patch
index 4737040675..d876958898 100644
---

a/meta/recipes-graphics/xorg-xserver/xserver-xorg/0001-Avoid-duplicate-definitions-of-IOPortBase.patch
+++

b/meta/recipes-graphics/xorg-xserver/xserver-xorg/0001-Avoid-duplicate-definitions-of-IOPortBase.patch
@@ -11,23 +11,9 @@ compiler.h:528: multiple definition of `IOPortBase';
  Upstream-Status: Pending
  Signed-off-by: Khem Raj mailto:raj.k...@gmail.com>>
  ---
- hw/xfree86/common/compiler.h            | 2 +-
   hw/xfree86/os-support/linux/lnx_video.c | 1 +
- 2 files changed, 2 insertions(+), 1 deletion(-)
+ 1 files changed, 1 insertions(+), 0 deletion(-)

-diff --git a/hw/xfree86/common/compiler.h b/hw/xfree86/common/compiler.h
-index 2b2008b..c7d617e 100644
 a/hw/xfree86/common/compiler.h
-+++ b/hw/xfree86/common/compiler.h
-@@ -525,7 +525,7 @@ xf86WriteMmio32Le(__volatile__ void *base, const 
unsigned long
offset,
- #define PORT_SIZE short
- #endif
-
--_X_EXPORT unsigned int IOPortBase;      /* Memory mapped I/O port area */
-+extern _X_EXPORT unsigned int IOPortBase;      /* Memory mapped I/O port 
area */
-
- static __inline__ void
- outb(unsigned PORT_SIZE port, unsigned char val)
  diff --git a/hw/xfree86/os-support/linux/lnx_video.c
b/hw/xfree86/os-support/linux/lnx_video.c
  index 04e4509..9dc7316 100644
  --- a/hw/xfree86/os-support/linux/lnx_video.c
diff --git

a/meta/recipes-graphics/xorg-xserver/xserver-xorg/0001-test-xtest-Initialize-array-with-braces.patch

b/meta/recipes-graphics/xorg-xserver/xserver-xorg/0001-test-xtest-Initialize-array-with-braces.patch
deleted file mode 100644
index 

Re: [OE-core] [PATCH] tzdata: Allow controlling zoneinfo binary format

2021-07-06 Thread Zoltan Boszormenyi via lists.openembedded.org

2021. 07. 06. 17:12 keltezéssel, Zoltan Boszormenyi via lists.openembedded.org 
írta:

From: Zoltán Böszörményi 

tzcode 2020b changed the default format from "-b fat" to "-b slim".
Allow external control for the binary format.

Signed-off-by: Zoltán Böszörményi 
---
  meta/recipes-extended/timezone/tzdata.bb | 10 +++---
  1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-extended/timezone/tzdata.bb 
b/meta/recipes-extended/timezone/tzdata.bb
index f8443110d5..09145e1ed0 100644
--- a/meta/recipes-extended/timezone/tzdata.bb
+++ b/meta/recipes-extended/timezone/tzdata.bb
@@ -19,13 +19,17 @@ TZONES= "africa antarctica asia australasia europe 
northamerica southamerica  \
  "
  # pacificnew
  
+# "slim" is the default since 2020b

+# "fat" is needed by e.g. MariaDB's mysql_tzinfo_to_sql


FYI, the issue fixed by this change is:
https://jira.mariadb.org/browse/MDEV-26093


+ZIC_FMT ?= "slim"
+
  do_compile () {
  for zone in ${TZONES}; do \
-${STAGING_BINDIR_NATIVE}/zic -d ${WORKDIR}${datadir}/zoneinfo -L 
/dev/null \
+${STAGING_BINDIR_NATIVE}/zic -b ${ZIC_FMT} -d 
${WORKDIR}${datadir}/zoneinfo -L /dev/null \
  ${S}/${zone} ; \
-${STAGING_BINDIR_NATIVE}/zic -d 
${WORKDIR}${datadir}/zoneinfo/posix -L /dev/null \
+${STAGING_BINDIR_NATIVE}/zic -b ${ZIC_FMT} -d 
${WORKDIR}${datadir}/zoneinfo/posix -L /dev/null \
  ${S}/${zone} ; \
-${STAGING_BINDIR_NATIVE}/zic -d 
${WORKDIR}${datadir}/zoneinfo/right -L ${S}/leapseconds \
+${STAGING_BINDIR_NATIVE}/zic -b ${ZIC_FMT} -d 
${WORKDIR}${datadir}/zoneinfo/right -L ${S}/leapseconds \
  ${S}/${zone} ; \
  done
  }








-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#153616): 
https://lists.openembedded.org/g/openembedded-core/message/153616
Mute This Topic: https://lists.openembedded.org/mt/84022657/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] tzdata: Allow controlling zoneinfo binary format

2021-07-06 Thread Zoltan Boszormenyi via lists.openembedded.org
From: Zoltán Böszörményi 

tzcode 2020b changed the default format from "-b fat" to "-b slim".
Allow external control for the binary format.

Signed-off-by: Zoltán Böszörményi 
---
 meta/recipes-extended/timezone/tzdata.bb | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-extended/timezone/tzdata.bb 
b/meta/recipes-extended/timezone/tzdata.bb
index f8443110d5..09145e1ed0 100644
--- a/meta/recipes-extended/timezone/tzdata.bb
+++ b/meta/recipes-extended/timezone/tzdata.bb
@@ -19,13 +19,17 @@ TZONES= "africa antarctica asia australasia europe 
northamerica southamerica  \
 "
 # pacificnew 
 
+# "slim" is the default since 2020b
+# "fat" is needed by e.g. MariaDB's mysql_tzinfo_to_sql
+ZIC_FMT ?= "slim"
+
 do_compile () {
 for zone in ${TZONES}; do \
-${STAGING_BINDIR_NATIVE}/zic -d ${WORKDIR}${datadir}/zoneinfo -L 
/dev/null \
+${STAGING_BINDIR_NATIVE}/zic -b ${ZIC_FMT} -d 
${WORKDIR}${datadir}/zoneinfo -L /dev/null \
 ${S}/${zone} ; \
-${STAGING_BINDIR_NATIVE}/zic -d 
${WORKDIR}${datadir}/zoneinfo/posix -L /dev/null \
+${STAGING_BINDIR_NATIVE}/zic -b ${ZIC_FMT} -d 
${WORKDIR}${datadir}/zoneinfo/posix -L /dev/null \
 ${S}/${zone} ; \
-${STAGING_BINDIR_NATIVE}/zic -d 
${WORKDIR}${datadir}/zoneinfo/right -L ${S}/leapseconds \
+${STAGING_BINDIR_NATIVE}/zic -b ${ZIC_FMT} -d 
${WORKDIR}${datadir}/zoneinfo/right -L ${S}/leapseconds \
 ${S}/${zone} ; \
 done
 }
-- 
2.31.1


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



Re: [OE-core][PATCH] mesa: Allow building the iris driver

2021-02-23 Thread Zoltan Boszormenyi via lists.openembedded.org

Hi,

2021. 02. 24. 1:31 keltezéssel, Yongxin Liu írta:


Iris driver supports Broadwell and newer (Gen8+) for very low CPU overhead.

With this patch, user can add PACKAGECONFIG_append = " iris" in their bbappend 
file.

And then iris will be added in build options, like 
"-Dgallium-drivers=swrast,virgl,iris".
You can check mesa/2_20.3.2-r0/build/meson-logs/meson-log.txt for this.

The driver can be found in build directory: 
mesa/2_20.3.2-r0/image/usr/lib64/dri/iris_dri.so


Thanks,
Yongxin


Since VAR_append can appear multiple times,
bbappend files can equally do

GALLIUMDRIVERS_append_x86_class-target = ",iris"
GALLIUMDRIVERS_append_x86-64_class-target = ",iris"

instead of this PACKAGECONFIG.

Anyway, since this MR exists in Mesa:
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8015
after a certain point this will have to be used in the
upstream recipe (pseudo-patch follows):

...
-DRIDRIVERS_append_x86_class-target = ",r100,r200,nouveau,i965,i915"
-DRIDRIVERS_append_x86-64_class-target = ",r100,r200,nouveau,i965,i915"
...
+GALLIUMDRIVERS_append_x86_class-target = ",nouveau,i915,iris"
+GALLIUMDRIVERS_append_x86-64_class-target = ",nouveau,i915,iris"
...

Best regards,
Zoltán Böszörményi




-Original Message-
From: openembedded-core@lists.openembedded.org  On Behalf Of Yongxin Liu
Sent: Thursday, February 18, 2021 16:56
To: openembedded-core@lists.openembedded.org;
richard.pur...@linuxfoundation.org
Subject: [OE-core][PATCH] mesa: Allow building the iris driver

Signed-off-by: Yongxin Liu 
---
  meta/recipes-graphics/mesa/mesa.inc | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/meta/recipes-graphics/mesa/mesa.inc b/meta/recipes-
graphics/mesa/mesa.inc
index cb075a8b89..72e22d654e 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -168,6 +168,9 @@ GALLIUMDRIVERS_append
="${@bb.utils.contains('PACKAGECONFIG', 'lima', ',lima', '
  PACKAGECONFIG[panfrost] = ""
  GALLIUMDRIVERS_append ="${@bb.utils.contains('PACKAGECONFIG', 'panfrost',
',panfrost', '', d)}"

+PACKAGECONFIG[iris] = ""
+GALLIUMDRIVERS_append ="${@bb.utils.contains('PACKAGECONFIG', 'iris',
',iris', '', d)}"
+
  OSMESA = "${@bb.utils.contains('PACKAGECONFIG', 'gallium', 'gallium',
'classic', d)}"
  PACKAGECONFIG[osmesa] = "-Dosmesa=${OSMESA},-Dosmesa=none"

--
2.14.5









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



Re: [OE-core] [PATCH 0/2] Fix issue with npm shrinkwrap fetcher

2021-02-03 Thread Zoltan Boszormenyi via lists.openembedded.org

2021. 01. 14. 16:40 keltezéssel, Kamel Bouhara írta:

On Thu, Jan 14, 2021 at 03:25:50PM +0100, Jean-Marie Lemetayer wrote:

Hi Kamel,



Hi Jean-Marie,


Thanks for your work. I should have fixed this a long time ago but I
didn't have the time :(



Well its never too late !


There is actually an open bug for this issue:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=13901
I think you can add the reference to your commit messages. And close
it if merged.


Please backport this series to Gatesgarth as soon
as possible because it's a problem there, too.
The series applies cleanly.

It fixes some of the issues I see with
https://www.npmjs.com/package/nanomsg which
still fails for a different reason.

Thanks in advance,
Zoltán





OK, let's see if there are other comments then I shall resent with
proper commit messages.


Please add some tests to ensure that:
  1. devtool / recipetool do not create empty shrinkwrap file
  2. the npmsw fetcher allows empty shrinkwrap file
  3. the npm class allows empty shrinkwrap


Actually the fix is only to check wether or not the dependencies are
listed and if not we make sure the npm fetcher will not look for them.

So the empty shrinkwrap file is still created and allowed.

I've already done some test in both case with and w/o dependencies.



See:
https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=22dd46cc34629d0750177fddff2e1c178c854340
https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=44b2ab8d5eb4fd1fc9a157fce37aaa7b7a7065e5
https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=f6728edb7e022b27223d28bd80ce40c2f2374a13

Also Sandra has already worked on it, but it didn't get merged. I
don't know why.

See:
https://lists.openembedded.org/g/bitbake-devel/topic/76459311#11643
https://lists.openembedded.org/g/bitbake-devel/message/11648



I see, yet I went a bit further ensuring the npm recipes will not call
the npmsw fetcher when no dependencies are given.

Thanks for you comments.

Cheers,
Kamel


BR
Jean-Marie

On Thu, Jan 14, 2021 at 8:13 AM Kamel Bouhara  wrote:


Hello all,

This small patch series aims to fix the following build issue faced
with some npm packages:

DEBUG: Executing python function do_fetch
DEBUG: Executing python function base_do_fetch
DEBUG: Python function base_do_fetch finished
DEBUG: Python function do_fetch finished
ERROR: Failure expanding variable TUNE_FEATURES_tune-armv7at-neon, expression 
was ${TUNE_FEATURES_tune-armv7at} neon which triggered exception 
RecursionError: maximum recursion depth exceeded while calling a Python object

After struggling a lot, I figured out that this only happen for npm
packages not having dependencies listed in their shrinkwrap file (e.g. 
bcryptjs).

Yet I still didn't got how is the json parsing impacting
the python context here ?

Please feel free to comment.

Thanks.

Kamel Bouhara (2):
   npm.bbclass: make shrinkwrap file optional
   recipetool: create: only add npmsw url if required

  meta/classes/npm.bbclass | 31 +--
  scripts/lib/recipetool/create_npm.py |  6 +-
  2 files changed, 26 insertions(+), 11 deletions(-)

--
2.11.0






--
Kamel Bouhara, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com








-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#147616): 
https://lists.openembedded.org/g/openembedded-core/message/147616
Mute This Topic: https://lists.openembedded.org/mt/79670723/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 2/4] libva-initial: New bootstrap recipe

2020-05-07 Thread Zoltan Boszormenyi via lists.openembedded.org
Mesa needs libva.pc and libva headers to enable the VAAPI
state tracker and drivers.

This recipe is a variant of the full libva package build as in:
* it only depends on libdrm to build so it doesn't introduce
  the circular dependency between mesa and libva, and
* it doesn't include the libraries in the final package.

However, there is another issue with build dependency handling
in Yocto. libva depends on mesa and mesa depends on this package.
Any package that depends on libva therefore would pull in libva
and this package resulting in an error in the prepare-sysroot
phase because they would install identical files into the
per-recipe sysroot.

Using the package name "*-initial" avoids this because of the
interaction between sstate.bbclass and staging.bbclass: any
package with the pattern "*-initial" in the name is excluded
from the dependency list unless explicitly added to DEPENDS.

Signed-off-by: Böszörményi Zoltán 
---
v2: The include file is not versioned, more verbose commit message
v3: Rebased to current master

 meta/recipes-graphics/libva/libva-initial_2.6.1.bb | 9 +
 meta/recipes-graphics/libva/libva.inc  | 4 +++-
 2 files changed, 12 insertions(+), 1 deletion(-)
 create mode 100644 meta/recipes-graphics/libva/libva-initial_2.6.1.bb

diff --git a/meta/recipes-graphics/libva/libva-initial_2.6.1.bb 
b/meta/recipes-graphics/libva/libva-initial_2.6.1.bb
new file mode 100644
index 00..a3b04eb02a
--- /dev/null
+++ b/meta/recipes-graphics/libva/libva-initial_2.6.1.bb
@@ -0,0 +1,9 @@
+require libva-${PV}.inc
+
+LIC_FILES_CHKSUM = "file://COPYING;md5=2e48940f94acb0af582e5ef03537800f"
+SRC_URI[md5sum] = "aef13eb48e01a47d1416d97462a22a11"
+SRC_URI[sha256sum] = 
"6c57eb642d828af2411aa38f55dc10111e8c98976dbab8fd62e48629401eaea5"
+
+do_install_append () {
+   rm -f ${D}${libdir}/*.so*
+}
diff --git a/meta/recipes-graphics/libva/libva.inc 
b/meta/recipes-graphics/libva/libva.inc
index e03451240c..ac39e92de7 100644
--- a/meta/recipes-graphics/libva/libva.inc
+++ b/meta/recipes-graphics/libva/libva.inc
@@ -16,7 +16,9 @@ BUGTRACKER = "https://github.com/intel/libva/issues;
 SECTION = "x11"
 LICENSE = "MIT"
 
-SRC_URI = 
"https://github.com/intel/${BPN}/releases/download/${PV}/${BP}.tar.bz2;
+SRC_URI = 
"https://github.com/intel/libva/releases/download/${PV}/libva-${PV}.tar.bz2;
+
+S = "${WORKDIR}/libva-${PV}"
 
 UPSTREAM_CHECK_URI = "https://github.com/intel/libva/releases;
 
-- 
2.26.2

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

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


[OE-core] [PATCH v3 1/4] libva: Factor out base parts into an include file

2020-05-07 Thread Zoltan Boszormenyi via lists.openembedded.org
To enable the VAAPI state tracker and drivers in mesa, it needs
libva.pc and the libva headers. To enable GLX support in libva,
it needs mesa to be compiled first. At the recipe level, this
would create a circular dependency between libva and mesa.

This is a preparation step before introducing a new libva recipe
variant to break the circular dependency.

Signed-off-by: Böszörményi Zoltán 
---
v2: The include file is not versioned, verbose commit message
v3: Rebased to current master

 meta/recipes-graphics/libva/libva.inc  | 25 ++
 meta/recipes-graphics/libva/libva_2.6.1.bb | 25 +-
 2 files changed, 26 insertions(+), 24 deletions(-)
 create mode 100644 meta/recipes-graphics/libva/libva.inc

diff --git a/meta/recipes-graphics/libva/libva.inc 
b/meta/recipes-graphics/libva/libva.inc
new file mode 100644
index 00..e03451240c
--- /dev/null
+++ b/meta/recipes-graphics/libva/libva.inc
@@ -0,0 +1,25 @@
+SUMMARY = "Video Acceleration (VA) API for Linux"
+DESCRIPTION = "Video Acceleration API (VA API) is a library (libVA) \
+and API specification which enables and provides access to graphics \
+hardware (GPU) acceleration for video processing on Linux and UNIX \
+based operating systems. Accelerated processing includes video \
+decoding, video encoding, subpicture blending and rendering. The \
+specification was originally designed by Intel for its GMA (Graphics \
+Media Accelerator) series of GPU hardware, the API is however not \
+limited to GPUs or Intel specific hardware, as other hardware and \
+manufacturers can also freely use this API for hardware accelerated \
+video decoding."
+
+HOMEPAGE = "https://01.org/linuxmedia/vaapi;
+BUGTRACKER = "https://github.com/intel/libva/issues;
+
+SECTION = "x11"
+LICENSE = "MIT"
+
+SRC_URI = 
"https://github.com/intel/${BPN}/releases/download/${PV}/${BP}.tar.bz2;
+
+UPSTREAM_CHECK_URI = "https://github.com/intel/libva/releases;
+
+DEPENDS = "libdrm"
+
+inherit meson pkgconfig features_check
diff --git a/meta/recipes-graphics/libva/libva_2.6.1.bb 
b/meta/recipes-graphics/libva/libva_2.6.1.bb
index 071be345d2..e8cb8678bc 100644
--- a/meta/recipes-graphics/libva/libva_2.6.1.bb
+++ b/meta/recipes-graphics/libva/libva_2.6.1.bb
@@ -1,32 +1,9 @@
-SUMMARY = "Video Acceleration (VA) API for Linux"
-DESCRIPTION = "Video Acceleration API (VA API) is a library (libVA) \
-and API specification which enables and provides access to graphics \
-hardware (GPU) acceleration for video processing on Linux and UNIX \
-based operating systems. Accelerated processing includes video \
-decoding, video encoding, subpicture blending and rendering. The \
-specification was originally designed by Intel for its GMA (Graphics \
-Media Accelerator) series of GPU hardware, the API is however not \
-limited to GPUs or Intel specific hardware, as other hardware and \
-manufacturers can also freely use this API for hardware accelerated \
-video decoding."
+require libva.inc
 
-HOMEPAGE = "https://01.org/linuxmedia/vaapi;
-BUGTRACKER = "https://github.com/intel/libva/issues;
-
-SECTION = "x11"
-LICENSE = "MIT"
 LIC_FILES_CHKSUM = "file://COPYING;md5=2e48940f94acb0af582e5ef03537800f"
-
-SRC_URI = 
"https://github.com/intel/${BPN}/releases/download/${PV}/${BP}.tar.bz2;
 SRC_URI[md5sum] = "aef13eb48e01a47d1416d97462a22a11"
 SRC_URI[sha256sum] = 
"6c57eb642d828af2411aa38f55dc10111e8c98976dbab8fd62e48629401eaea5"
 
-UPSTREAM_CHECK_URI = "https://github.com/intel/libva/releases;
-
-DEPENDS = "libdrm"
-
-inherit meson pkgconfig features_check
-
 PACKAGECONFIG ??= " \
 ${@bb.utils.contains('DISTRO_FEATURES', 'x11 opengl', 'glx', '', d)} \
 ${@bb.utils.filter('DISTRO_FEATURES', 'x11 wayland', d)} \
-- 
2.26.2

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

View/Reply Online (#138025): 
https://lists.openembedded.org/g/openembedded-core/message/138025
Mute This Topic: https://lists.openembedded.org/mt/74050174/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 3/4] mesa: Add PACKAGECONFIG knob to enable VAAPI

2020-05-07 Thread Zoltan Boszormenyi via lists.openembedded.org
The previously added libva-initial recipe makes it possible and
trivial.

Signed-off-by: Böszörményi Zoltán 
---
v2: Small explanation in the commit message
v3: Rebased to current master

 meta/recipes-graphics/mesa/mesa.inc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-graphics/mesa/mesa.inc 
b/meta/recipes-graphics/mesa/mesa.inc
index f59503bf14..7a889a5b11 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -142,6 +142,7 @@ PACKAGECONFIG[gallium] = 
"-Dgallium-drivers=${GALLIUMDRIVERS}, -Dgallium-drivers
 PACKAGECONFIG[gallium-llvm] = "-Dllvm=true -Dshared-llvm=true, -Dllvm=false, 
llvm${MESA_LLVM_RELEASE} llvm-native \
${@'elfutils' if 
${GALLIUMDRIVERS_LLVM33_ENABLED} else ''}"
 PACKAGECONFIG[xa]  = "-Dgallium-xa=true, -Dgallium-xa=false"
+PACKAGECONFIG[va] = "-Dgallium-va=true,-Dgallium-va=false,libva-initial"
 
 PACKAGECONFIG[lima] = ""
 GALLIUMDRIVERS_append ="${@bb.utils.contains('PACKAGECONFIG', 'lima', ',lima', 
'', d)}"
-- 
2.26.2

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

View/Reply Online (#138027): 
https://lists.openembedded.org/g/openembedded-core/message/138027
Mute This Topic: https://lists.openembedded.org/mt/74050178/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 4/4] mesa: Add PACKAGECONFIG knob to enable VDPAU state tracker and drivers

2020-05-07 Thread Zoltan Boszormenyi via lists.openembedded.org
Signed-off-by: Böszörményi Zoltán 
---
v2: Replaced FILES_${PN}-vdpau-drivers with FILES_mesa-vdpau-drivers
to match the name in PACKAGES.
v3: Rebased to current master

 meta/recipes-graphics/mesa/mesa.inc | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-graphics/mesa/mesa.inc 
b/meta/recipes-graphics/mesa/mesa.inc
index 7a889a5b11..fede691d6f 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -144,6 +144,8 @@ PACKAGECONFIG[gallium-llvm] = "-Dllvm=true 
-Dshared-llvm=true, -Dllvm=false, llv
 PACKAGECONFIG[xa]  = "-Dgallium-xa=true, -Dgallium-xa=false"
 PACKAGECONFIG[va] = "-Dgallium-va=true,-Dgallium-va=false,libva-initial"
 
+PACKAGECONFIG[vdpau] = "-Dgallium-vdpau=true,-Dgallium-vdpau=false,libvdpau"
+
 PACKAGECONFIG[lima] = ""
 GALLIUMDRIVERS_append ="${@bb.utils.contains('PACKAGECONFIG', 'lima', ',lima', 
'', d)}"
 
@@ -180,6 +182,7 @@ PACKAGES =+ "libegl-mesa libegl-mesa-dev \
  libgles3-mesa libgles3-mesa-dev \
  libxatracker libxatracker-dev \
  mesa-megadriver mesa-vulkan-drivers \
+ mesa-vdpau-drivers \
 "
 
 do_install_append () {
@@ -257,6 +260,7 @@ PACKAGES_DYNAMIC += "^mesa-driver-.*"
 
 FILES_mesa-megadriver = "${libdir}/dri/* 
${datadir}/drirc.d/00-mesa-defaults.conf"
 FILES_mesa-vulkan-drivers = "${libdir}/libvulkan_*.so ${datadir}/vulkan"
+FILES_${PN}-vdpau-drivers = "${libdir}/vdpau/*.so.*"
 FILES_libegl-mesa = "${libdir}/libEGL.so.*"
 FILES_libgbm = "${libdir}/libgbm.so.*"
 FILES_libgles1-mesa = "${libdir}/libGLESv1*.so.*"
@@ -266,7 +270,7 @@ FILES_libglapi = "${libdir}/libglapi.so.*"
 FILES_libosmesa = "${libdir}/libOSMesa.so.*"
 FILES_libxatracker = "${libdir}/libxatracker.so.*"
 
-FILES_${PN}-dev = "${libdir}/pkgconfig/dri.pc ${includedir}/vulkan"
+FILES_${PN}-dev = "${libdir}/pkgconfig/dri.pc ${includedir}/vulkan 
${libdir}/vdpau/*.so"
 FILES_libegl-mesa-dev = "${libdir}/libEGL.* ${includedir}/EGL 
${includedir}/KHR ${libdir}/pkgconfig/egl.pc"
 FILES_libgbm-dev = "${libdir}/libgbm.* ${libdir}/pkgconfig/gbm.pc 
${includedir}/gbm.h"
 FILES_libgl-mesa-dev = "${libdir}/libGL.* ${includedir}/GL 
${libdir}/pkgconfig/gl.pc"
-- 
2.26.2

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

View/Reply Online (#138028): 
https://lists.openembedded.org/g/openembedded-core/message/138028
Mute This Topic: https://lists.openembedded.org/mt/74050180/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 0/4] Enable VAAPI and VDPAU video drivers in Mesa

2020-05-07 Thread Zoltan Boszormenyi via lists.openembedded.org
Mesa needs libva to enable VAAPI state tracker and drivers.
libva needs Mesa to enable its GLX part.

This is a circular dependency that can be solved by introducing
a new libva recipe variant that doesn't enable GLX.

Actually, the presence of Mesa/OpenGL headers is autodetected
in libva so it's enough to leave out Mesa from DEPENDS in the
new libva recipe variant.

With magic already existing in sstate.bbclass and staging.bbclass,
naming the new libva recipe variant "libva-initial" avoids an
error for every other recipe that pulls in libva as dependency,
including libva-utils and intel-vaapi-driver.

The error (if not naming the recipe as "*-initial") is that
the prepare-sysroot phase of a package would pull in the files 
rom both libva build variants that would obviously install identical
files.

Enabling the VDPAU state tracker and libraries is trivial,
it was just missing from the recipe.

[PATCH v3 1/4] libva: Factor out base parts into an include file
[PATCH v3 2/4] libva-initial: New bootstrap recipe
[PATCH v3 3/4] mesa: Add PACKAGECONFIG knob to enable VAAPI
[PATCH v3 4/4] mesa: Add PACKAGECONFIG knob to enable VDPAU state

Signed-off-by: Böszörményi Zoltán 


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

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


Re: [OE-core] [meta-oe][PATCH] libva: Removed virtual/mesa dependency

2020-05-07 Thread Zoltan Boszormenyi via lists.openembedded.org

2020. 05. 07. 13:48 keltezéssel, Richard Purdie írta:

On Wed, 2020-05-06 at 14:41 +0200, Zoltan Boszormenyi via
lists.openembedded.org wrote:

2020. 04. 24. 17:01 keltezéssel, Bartłomiej Burdukiewicz írta:

Mesa can be compiled with libva support, in order to avoid
recursive
dependency between mesa and libva, virtual/mesa must be removed
from libva recipe.


This is why this patch series was created, to break the
circular dependency in a clean way:
https://patchwork.openembedded.org/series/22976/#

The libva-initial recipe was introduced that doesn't need
mesa, then mesa can be built with vaapi state tracker enabled,
finally libva can be built with dependency on mesa so its
GLX support is enabled.

What happened to it?


I think it came in late during the release and was a bit too risky to
be taken at the time.


I didn't get that impression after the response from Khem Raj:
>> OK, I guess, we should give it a test.


It think it is a good solution to the problem,
would you be able to rebase the patches and we can queue them for
testing? Its a much better time now to merge a change like that.


I will rebase them, thanks.
Does it have a chance to be backported to 3.1?



Cheers,

Richard






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

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


Re: [OE-core] [meta-oe][PATCH] libva: Removed virtual/mesa dependency

2020-05-06 Thread Zoltan Boszormenyi via lists.openembedded.org

2020. 04. 24. 17:01 keltezéssel, Bartłomiej Burdukiewicz írta:

Mesa can be compiled with libva support, in order to avoid recursive
dependency between mesa and libva, virtual/mesa must be removed
from libva recipe.


This is why this patch series was created, to break the
circular dependency in a clean way:
https://patchwork.openembedded.org/series/22976/#

The libva-initial recipe was introduced that doesn't need
mesa, then mesa can be built with vaapi state tracker enabled,
finally libva can be built with dependency on mesa so its
GLX support is enabled.

What happened to it?

Best regards,
Zoltán Böszörményi



Signed-off-by: Bartłomiej Burdukiewicz 
---
  meta/recipes-graphics/libva/libva_2.6.1.bb | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-graphics/libva/libva_2.6.1.bb 
b/meta/recipes-graphics/libva/libva_2.6.1.bb
index 92cea83bc1..c1a441a18b 100644
--- a/meta/recipes-graphics/libva/libva_2.6.1.bb
+++ b/meta/recipes-graphics/libva/libva_2.6.1.bb
@@ -23,7 +23,7 @@ SRC_URI[sha256sum] = 
"6c57eb642d828af2411aa38f55dc10111e8c98976dbab8fd62e4862940
  
  UPSTREAM_CHECK_URI = "https://github.com/intel/libva/releases;
  
-DEPENDS = "libdrm virtual/mesa"

+DEPENDS = "libdrm"
  
  inherit meson pkgconfig features_check
  







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

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