[OE-core] [PATCH] python3-pycairo:upgrade 1.19.0 -> 1.19.1

[zangrc]

Signed-off-by: Zang Ruochen 
---
 .../{python3-pycairo_1.19.0.bb => python3-pycairo_1.19.1.bb}  | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-devtools/python/{python3-pycairo_1.19.0.bb => 
python3-pycairo_1.19.1.bb} (84%)

diff --git a/meta/recipes-devtools/python/python3-pycairo_1.19.0.bb 
b/meta/recipes-devtools/python/python3-pycairo_1.19.1.bb
similarity index 84%
rename from meta/recipes-devtools/python/python3-pycairo_1.19.0.bb
rename to meta/recipes-devtools/python/python3-pycairo_1.19.1.bb
index 8f60834c17..34c8543bce 100644
--- a/meta/recipes-devtools/python/python3-pycairo_1.19.0.bb
+++ b/meta/recipes-devtools/python/python3-pycairo_1.19.1.bb
@@ -13,8 +13,8 @@ DEPENDS = "cairo python3"
 SRC_URI = 
"https://github.com/pygobject/pycairo/releases/download/v${PV}/pycairo-${PV}.tar.gz;
 UPSTREAM_CHECK_URI = "https://github.com/pygobject/pycairo/releases/;
 
-SRC_URI[md5sum] = "38b84416021640b01250c8f8ec4c52d4"
-SRC_URI[sha256sum] = 
"4f5ba9374a46c98729dd3727d993f5e17ed0286fd6738ed464fe4efa0612d19c"
+SRC_URI[md5sum] = "59bc5c5d1debc3af0f6791af9d612551"
+SRC_URI[sha256sum] = 
"2c143183280feb67f5beb4e543fd49990c28e7df427301ede04fc550d3562e84"
 
 S = "${WORKDIR}/pycairo-${PV}"
 
-- 
2.17.1



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

View/Reply Online (#138754): 
https://lists.openembedded.org/g/openembedded-core/message/138754
Mute This Topic: https://lists.openembedded.org/mt/74490950/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] armv8/tunes: Set TUNE_PKGARCH_64 based on ARMPKGARCH

[Khem Raj]

The setting is to modify TUNE_PKGARCH which is filled with
TUNE_PKGARCH_64 or TUNE_PKGARCH_32 in arm-arch64.inc
This lets higher up tune files for arm64 SOCs override them if needed,
this can help building multiple armv8 machines with different tunes in
same workspace.

No need to set TUNE_PKGARCH in tune files as it is synthesized from ARMPKGARCH

Add ARMPKGARCH for aarch64 tunes

Signed-off-by: Khem Raj 
Signed-off-by: Richard Purdie 
---
v2: Differentiate triplet for crypto feature

 meta/conf/machine/include/arm/arch-arm64.inc   | 4 +++-
 meta/conf/machine/include/tune-cortexa53.inc   | 5 +
 meta/conf/machine/include/tune-cortexa55.inc   | 1 -
 meta/conf/machine/include/tune-cortexa57-cortexa53.inc | 1 -
 meta/conf/machine/include/tune-cortexa57.inc   | 4 +---
 meta/conf/machine/include/tune-cortexa72-cortexa53.inc | 4 +---
 meta/conf/machine/include/tune-cortexa72.inc   | 1 -
 meta/conf/machine/include/tune-cortexa73-cortexa53.inc | 4 +---
 8 files changed, 7 insertions(+), 17 deletions(-)

diff --git a/meta/conf/machine/include/arm/arch-arm64.inc 
b/meta/conf/machine/include/arm/arch-arm64.inc
index 53f4566815..6d5b22fff0 100644
--- a/meta/conf/machine/include/arm/arch-arm64.inc
+++ b/meta/conf/machine/include/arm/arch-arm64.inc
@@ -12,6 +12,8 @@ ARMPKGARCH_tune-aarch64 ?= "aarch64"
 ARMPKGARCH_tune-aarch64_be ?= "aarch64_be"
 TUNE_FEATURES_tune-aarch64 = "aarch64"
 TUNE_FEATURES_tune-aarch64_be = "${TUNE_FEATURES_tune-aarch64} bigendian"
+TUNE_PKGARCH_64_tune-aarch64 = "aarch64"
+TUNE_PKGARCH_64_tune-aarch64_be = "aarch64_be"
 BASE_LIB_tune-aarch64 = "lib64"
 BASE_LIB_tune-aarch64_be = "lib64"
 
@@ -20,7 +22,7 @@ PACKAGE_EXTRA_ARCHS_tune-aarch64_be = "aarch64_be"
 
 ARMPKGSFX_ENDIAN_64 = "${@bb.utils.contains('TUNE_FEATURES', 'bigendian', 
'_be', '', d)}"
 TUNE_ARCH_64 = "aarch64${ARMPKGSFX_ENDIAN_64}"
-TUNE_PKGARCH_64 = "aarch64${ARMPKGSFX_ENDIAN_64}"
+TUNE_PKGARCH_64 = "${ARMPKGARCH}${ARMPKGSFX_ENDIAN_64}"
 ABIEXTENSION_64 = ""
 TARGET_FPU_64 = ""
 
diff --git a/meta/conf/machine/include/tune-cortexa53.inc 
b/meta/conf/machine/include/tune-cortexa53.inc
index b7327d00c4..c0bb28a19e 100644
--- a/meta/conf/machine/include/tune-cortexa53.inc
+++ b/meta/conf/machine/include/tune-cortexa53.inc
@@ -8,14 +8,11 @@ require conf/machine/include/arm/arch-armv8a.inc
 # Little Endian base configs
 AVAILTUNES += "cortexa53 cortexa53-crypto"
 ARMPKGARCH_tune-cortexa53 = "cortexa53"
-ARMPKGARCH_tune-cortexa53-crypto  = "cortexa53"
+ARMPKGARCH_tune-cortexa53-crypto  = "cortexa53-crypto"
 TUNE_FEATURES_tune-cortexa53  = "aarch64 cortexa53 crc"
 TUNE_FEATURES_tune-cortexa53-crypto   = "aarch64 cortexa53 crc crypto"
 PACKAGE_EXTRA_ARCHS_tune-cortexa53 = 
"${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc} cortexa53"
 PACKAGE_EXTRA_ARCHS_tune-cortexa53-crypto  = 
"${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc-crypto} cortexa53 cortexa53-crypto"
 
-TUNE_PKGARCH_tune-cortexa53 = "cortexa53"
-TUNE_PKGARCH_tune-cortexa53-crypto = "cortexa53-crypto"
-
 BASE_LIB_tune-cortexa53   = "lib64"
 BASE_LIB_tune-cortexa53-crypto= "lib64"
diff --git a/meta/conf/machine/include/tune-cortexa55.inc 
b/meta/conf/machine/include/tune-cortexa55.inc
index 274944819e..89032b59ec 100644
--- a/meta/conf/machine/include/tune-cortexa55.inc
+++ b/meta/conf/machine/include/tune-cortexa55.inc
@@ -9,6 +9,5 @@ require conf/machine/include/arm/arch-armv8a.inc
 AVAILTUNES += "cortexa55"
 ARMPKGARCH_tune-cortexa55 = "cortexa55"
 TUNE_FEATURES_tune-cortexa55  = "aarch64 cortexa55 crc crypto"
-TUNE_PKGARCH_tune-cortexa55   = "cortexa55"
 PACKAGE_EXTRA_ARCHS_tune-cortexa55= 
"${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc-crypto} cortexa55"
 BASE_LIB_tune-cortexa55   = "lib64"
diff --git a/meta/conf/machine/include/tune-cortexa57-cortexa53.inc 
b/meta/conf/machine/include/tune-cortexa57-cortexa53.inc
index b95d63e86b..ba4b073852 100644
--- a/meta/conf/machine/include/tune-cortexa57-cortexa53.inc
+++ b/meta/conf/machine/include/tune-cortexa57-cortexa53.inc
@@ -11,6 +11,5 @@ require conf/machine/include/arm/arch-armv8a.inc
 AVAILTUNES += "cortexa57-cortexa53"
 ARMPKGARCH_tune-cortexa57-cortexa53 = "cortexa57-cortexa53"
 TUNE_FEATURES_tune-cortexa57-cortexa53 = "aarch64 cortexa57-cortexa53"
-TUNE_PKGARCH_tune-cortexa57-cortexa53 = "cortexa57-cortexa53"
 PACKAGE_EXTRA_ARCHS_tune-cortexa57-cortexa53 = 
"${PACKAGE_EXTRA_ARCHS_tune-aarch64} cortexa57-cortexa53"
 BASE_LIB_tune-cortexa57-cortexa53 = "lib64"
diff --git a/meta/conf/machine/include/tune-cortexa57.inc 
b/meta/conf/machine/include/tune-cortexa57.inc
index e8ddeb5786..0811d503cc 100644
--- a/meta/conf/machine/include/tune-cortexa57.inc
+++ b/meta/conf/machine/include/tune-cortexa57.inc
@@ -8,12 +8,10 @@ require conf/machine/include/arm/arch-armv8a.inc
 # Little Endian base configs
 AVAILTUNES += "cortexa57 cortexa57-crypto"
 ARMPKGARCH_tune-cortexa57 = "cortexa57"

Re: [OE-core] [PATCH 1/5 v2] multilib/recipes: Use new RecipePostKeyExpansion event

[Richard Purdie]

On Tue, 2020-05-26 at 15:12 -0700, Jeremy Puhlman wrote:
> The one question I did have is there are a couple of places where you
> add the ML prefix for
> nativesdk classes. If we don't have them, it shouldn't hurt anything,
> but do we actually support
> multilib nativesdk packages?

nativesdk actually uses the same mechanism to extend the package names
as multilib does so for nativesdk, MLPREFIX="nativesdk-".

So no, we don't support mulitlib nativesdk but nativesdk is a kind of
multilib in some ways as it also sets MLPREFIX.

Cheers,

Richard

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

View/Reply Online (#138752): 
https://lists.openembedded.org/g/openembedded-core/message/138752
Mute This Topic: https://lists.openembedded.org/mt/74488041/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/5 v2] multilib/recipes: Use new RecipePostKeyExpansion event

[Jeremy Puhlman]

The one question I did have is there are a couple of places where you 
add the ML prefix for
nativesdk classes. If we don't have them, it shouldn't hurt anything, 
but do we actually support

multilib nativesdk packages?

On 5/26/2020 2:57 PM, Richard Purdie wrote:

There are issues with multilib due to the ordering of events where some
functions see the remapped multilib dependencies and some do not. A significant
problem is that the multilib class needs to make some changes before key 
expansion
and some afterwards but by using existing event handlers, some code sees things
in a partially translated state, leading to bugs.

This patch changes things to use a new event handler from bitbake which makes 
the
ordering of the changes explcit.

The challenge in doing this is that it breaks some existing anonymous python and
dyanmic assignments. In some cases these used to be translated and no longer 
are,
meaning MLPREFIX has to be added. In some cases these are now translated and the
MLPREFIX can be removed.

This change does now make it very clear when MLPREFIX is required and when it is
not, its just the migration path which is harder. The patch changes the small 
number
of cases where fixes are needed.

In particular, where a variable like RDEPENDS is conditionally extended (e.g.
with an override), MLPREFIX is now required.

This patch also reverts:
base: Revert 'base.bbclass: considering multilib when setting LICENSE_EXCLUSION'

This reverts 6597130256a1609c3e05ec5891aceaf549c37985 as the changes
to multilib datastore handling mean its no longer necessary.

Signed-off-by: Richard Purdie 
---
  meta/classes/base.bbclass |  3 +-
  meta/classes/fontcache.bbclass|  2 +-
  meta/classes/multilib.bbclass | 28 ---
  meta/lib/oe/classextend.py| 35 +--
  meta/recipes-core/glibc/glibc-package.inc |  2 +-
  .../packagegroups/packagegroup-base.bb|  8 ++---
  meta/recipes-core/psplash/psplash_git.bb  |  5 +--
  meta/recipes-devtools/perl/perl_5.30.2.bb |  2 +-
  meta/recipes-devtools/python/python3_3.8.2.bb | 14 
  .../packagegroup-core-full-cmdline.bb | 10 +++---
  meta/recipes-graphics/mesa/mesa.inc   | 10 +++---
  .../alsa/alsa-plugins_1.2.1.bb|  6 ++--
  meta/recipes-support/boost/boost.inc  | 10 --
  13 files changed, 95 insertions(+), 40 deletions(-)

diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index 7aa2e144eb7..4c681cc870d 100644
--- a/meta/classes/base.bbclass
+++ b/meta/classes/base.bbclass
@@ -570,8 +570,7 @@ python () {
  if unskipped_pkgs:
  for pkg in skipped_pkgs:
  bb.debug(1, "Skipping the package %s at do_rootfs because 
of incompatible license(s): %s" % (pkg, ' '.join(skipped_pkgs[pkg])))
-mlprefix = d.getVar('MLPREFIX')
-d.setVar('LICENSE_EXCLUSION-' + mlprefix + pkg, ' 
'.join(skipped_pkgs[pkg]))
+d.setVar('LICENSE_EXCLUSION-' + pkg, ' 
'.join(skipped_pkgs[pkg]))
  for pkg in unskipped_pkgs:
  bb.debug(1, "Including the package %s" % pkg)
  else:
diff --git a/meta/classes/fontcache.bbclass b/meta/classes/fontcache.bbclass
index 97e7f17f00e..624a420a0de 100644
--- a/meta/classes/fontcache.bbclass
+++ b/meta/classes/fontcache.bbclass
@@ -7,7 +7,7 @@ PACKAGE_WRITE_DEPS += "qemu-native"
  inherit qemu
  
  FONT_PACKAGES ??= "${PN}"

-FONT_EXTRA_RDEPENDS ?= "fontconfig-utils"
+FONT_EXTRA_RDEPENDS ?= "${MLPREFIX}fontconfig-utils"
  FONTCONFIG_CACHE_DIR ?= "${localstatedir}/cache/fontconfig"
  FONTCONFIG_CACHE_PARAMS ?= "-v"
  # You can change this to e.g. FC_DEBUG=16 to debug fc-cache issues,
diff --git a/meta/classes/multilib.bbclass b/meta/classes/multilib.bbclass
index ee677da1e20..9f726e45371 100644
--- a/meta/classes/multilib.bbclass
+++ b/meta/classes/multilib.bbclass
@@ -91,13 +91,12 @@ addhandler multilib_virtclass_handler
  multilib_virtclass_handler[eventmask] = "bb.event.RecipePreFinalise"
  
  python __anonymous () {

-variant = d.getVar("BBEXTENDVARIANT")
-
-import oe.classextend
+if bb.data.inherits_class('image', d):
+variant = d.getVar("BBEXTENDVARIANT")
+import oe.classextend
  
-clsextend = oe.classextend.ClassExtender(variant, d)

+clsextend = oe.classextend.ClassExtender(variant, d)
  
-if bb.data.inherits_class('image', d):

  clsextend.map_depends_variable("PACKAGE_INSTALL")
  clsextend.map_depends_variable("LINGUAS_INSTALL")
  clsextend.map_depends_variable("RDEPENDS")
@@ -109,6 +108,22 @@ python __anonymous () {
  bb.build.deltask('do_populate_sdk', d)
  bb.build.deltask('do_populate_sdk_ext', d)
  return
+}
+
+python multilib_virtclass_handler_postkeyexp () {
+cls = d.getVar("BBEXTENDCURR")
+variant = 

Re: [OE-core] [PATCH] multilib/recipes: Use new RecipePostKeyExpansion event

[Richard Purdie]

On Tue, 2020-05-26 at 08:45 -0700, Jeremy Puhlman wrote:
> For master I this looks great. We have been bitten in various edge
> cases by this in the past. You mentioned
> pushing it on to dunfell. I a little leary at this point, but if we
> are going to its kind of now or never. My feeling
> is there will be some fallout(which is perfectly fine on master, a
> little questionable on a stable release) in other
> layers.

Right, I tend to agree that its probably too invasive for dunfell...

I've posted a tweaked v2 of the patch which fixes some regressions this
version had.

Cheers,

Richard

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

View/Reply Online (#138750): 
https://lists.openembedded.org/g/openembedded-core/message/138750
Mute This Topic: https://lists.openembedded.org/mt/74372041/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/5 v2] multilib/recipes: Use new RecipePostKeyExpansion event

[Richard Purdie]

There are issues with multilib due to the ordering of events where some
functions see the remapped multilib dependencies and some do not. A significant
problem is that the multilib class needs to make some changes before key 
expansion
and some afterwards but by using existing event handlers, some code sees things
in a partially translated state, leading to bugs.

This patch changes things to use a new event handler from bitbake which makes 
the
ordering of the changes explcit.

The challenge in doing this is that it breaks some existing anonymous python and
dyanmic assignments. In some cases these used to be translated and no longer 
are,
meaning MLPREFIX has to be added. In some cases these are now translated and the
MLPREFIX can be removed.

This change does now make it very clear when MLPREFIX is required and when it is
not, its just the migration path which is harder. The patch changes the small 
number
of cases where fixes are needed.

In particular, where a variable like RDEPENDS is conditionally extended (e.g.
with an override), MLPREFIX is now required.

This patch also reverts:
base: Revert 'base.bbclass: considering multilib when setting LICENSE_EXCLUSION'

This reverts 6597130256a1609c3e05ec5891aceaf549c37985 as the changes
to multilib datastore handling mean its no longer necessary.

Signed-off-by: Richard Purdie 
---
 meta/classes/base.bbclass |  3 +-
 meta/classes/fontcache.bbclass|  2 +-
 meta/classes/multilib.bbclass | 28 ---
 meta/lib/oe/classextend.py| 35 +--
 meta/recipes-core/glibc/glibc-package.inc |  2 +-
 .../packagegroups/packagegroup-base.bb|  8 ++---
 meta/recipes-core/psplash/psplash_git.bb  |  5 +--
 meta/recipes-devtools/perl/perl_5.30.2.bb |  2 +-
 meta/recipes-devtools/python/python3_3.8.2.bb | 14 
 .../packagegroup-core-full-cmdline.bb | 10 +++---
 meta/recipes-graphics/mesa/mesa.inc   | 10 +++---
 .../alsa/alsa-plugins_1.2.1.bb|  6 ++--
 meta/recipes-support/boost/boost.inc  | 10 --
 13 files changed, 95 insertions(+), 40 deletions(-)

diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index 7aa2e144eb7..4c681cc870d 100644
--- a/meta/classes/base.bbclass
+++ b/meta/classes/base.bbclass
@@ -570,8 +570,7 @@ python () {
 if unskipped_pkgs:
 for pkg in skipped_pkgs:
 bb.debug(1, "Skipping the package %s at do_rootfs 
because of incompatible license(s): %s" % (pkg, ' '.join(skipped_pkgs[pkg])))
-mlprefix = d.getVar('MLPREFIX')
-d.setVar('LICENSE_EXCLUSION-' + mlprefix + pkg, ' 
'.join(skipped_pkgs[pkg]))
+d.setVar('LICENSE_EXCLUSION-' + pkg, ' 
'.join(skipped_pkgs[pkg]))
 for pkg in unskipped_pkgs:
 bb.debug(1, "Including the package %s" % pkg)
 else:
diff --git a/meta/classes/fontcache.bbclass b/meta/classes/fontcache.bbclass
index 97e7f17f00e..624a420a0de 100644
--- a/meta/classes/fontcache.bbclass
+++ b/meta/classes/fontcache.bbclass
@@ -7,7 +7,7 @@ PACKAGE_WRITE_DEPS += "qemu-native"
 inherit qemu
 
 FONT_PACKAGES ??= "${PN}"
-FONT_EXTRA_RDEPENDS ?= "fontconfig-utils"
+FONT_EXTRA_RDEPENDS ?= "${MLPREFIX}fontconfig-utils"
 FONTCONFIG_CACHE_DIR ?= "${localstatedir}/cache/fontconfig"
 FONTCONFIG_CACHE_PARAMS ?= "-v"
 # You can change this to e.g. FC_DEBUG=16 to debug fc-cache issues,
diff --git a/meta/classes/multilib.bbclass b/meta/classes/multilib.bbclass
index ee677da1e20..9f726e45371 100644
--- a/meta/classes/multilib.bbclass
+++ b/meta/classes/multilib.bbclass
@@ -91,13 +91,12 @@ addhandler multilib_virtclass_handler
 multilib_virtclass_handler[eventmask] = "bb.event.RecipePreFinalise"
 
 python __anonymous () {
-variant = d.getVar("BBEXTENDVARIANT")
-
-import oe.classextend
+if bb.data.inherits_class('image', d):
+variant = d.getVar("BBEXTENDVARIANT")
+import oe.classextend
 
-clsextend = oe.classextend.ClassExtender(variant, d)
+clsextend = oe.classextend.ClassExtender(variant, d)
 
-if bb.data.inherits_class('image', d):
 clsextend.map_depends_variable("PACKAGE_INSTALL")
 clsextend.map_depends_variable("LINGUAS_INSTALL")
 clsextend.map_depends_variable("RDEPENDS")
@@ -109,6 +108,22 @@ python __anonymous () {
 bb.build.deltask('do_populate_sdk', d)
 bb.build.deltask('do_populate_sdk_ext', d)
 return
+}
+
+python multilib_virtclass_handler_postkeyexp () {
+cls = d.getVar("BBEXTENDCURR")
+variant = d.getVar("BBEXTENDVARIANT")
+if cls != "multilib" or not variant:
+return
+
+variant = d.getVar("BBEXTENDVARIANT")
+
+import oe.classextend
+
+clsextend = oe.classextend.ClassExtender(variant, d)
+
+if bb.data.inherits_class('image', d):
+return
 
 

[OE-core] [PATCH 4/5] resulttool/log: Add ability to dump ltp logs as well as ptest

[Richard Purdie]

Currently only ptest logs are accessible with the log command, this
adds support so the ltp logs can be extracted too.

Signed-off-by: Richard Purdie 
---
 scripts/lib/resulttool/log.py | 21 ++---
 scripts/lib/resulttool/resultutils.py | 22 ++
 2 files changed, 28 insertions(+), 15 deletions(-)

diff --git a/scripts/lib/resulttool/log.py b/scripts/lib/resulttool/log.py
index f1bfd99500b..eb3927ec82a 100644
--- a/scripts/lib/resulttool/log.py
+++ b/scripts/lib/resulttool/log.py
@@ -34,13 +34,17 @@ def log(args, logger):
 return 1
 
 for _, run_name, _, r in resultutils.test_run_results(results):
-if args.dump_ptest and 'ptestresult.sections' in r:
-for name, ptest in r['ptestresult.sections'].items():
-logdata = resultutils.ptestresult_get_log(r, name)
+if args.dump_ptest:
+for sectname in ['ptestresult.sections', 
'ltpposixresult.sections', 'ltpresult.sections']:
+ if sectname in r:
+  for name, ptest in r[sectname].items():
+logdata = resultutils.generic_get_log(sectname, r, name)
 if logdata is not None:
 dest_dir = args.dump_ptest
 if args.prepend_run:
 dest_dir = os.path.join(dest_dir, run_name)
+if not sectname.startswith("ptest"):
+dest_dir = os.path.join(dest_dir, 
sectname.split(".")[0])
 
 os.makedirs(dest_dir, exist_ok=True)
 dest = os.path.join(dest_dir, '%s.log' % name)
@@ -49,10 +53,13 @@ def log(args, logger):
 f.write(logdata)
 
 if args.raw_ptest:
-rawlog = resultutils.ptestresult_get_rawlogs(r)
-if rawlog is not None:
-print(rawlog)
-else:
+found = False
+for sectname in ['ptestresult.rawlogs', 'ltpposixresult.rawlogs', 
'ltpresult.rawlogs']:
+rawlog = resultutils.generic_get_rawlogs(sectname, r)
+if rawlog is not None:
+print(rawlog)
+found = True
+if not found:
 print('Raw ptest logs not found')
 return 1
 
diff --git a/scripts/lib/resulttool/resultutils.py 
b/scripts/lib/resulttool/resultutils.py
index 5fec01f6f34..8917022d36e 100644
--- a/scripts/lib/resulttool/resultutils.py
+++ b/scripts/lib/resulttool/resultutils.py
@@ -130,23 +130,29 @@ def decode_log(logdata):
 return data.decode("utf-8", errors='ignore')
 return None
 
-def ptestresult_get_log(results, section):
-if 'ptestresult.sections' not in results:
+def generic_get_log(sectionname, results, section):
+if sectionname not in results:
 return None
-if section not in results['ptestresult.sections']:
+if section not in results[sectionname]:
 return None
 
-ptest = results['ptestresult.sections'][section]
+ptest = results[sectionname][section]
 if 'log' not in ptest:
 return None
 return decode_log(ptest['log'])
 
-def ptestresult_get_rawlogs(results):
-if 'ptestresult.rawlogs' not in results:
+def ptestresult_get_log(results, section):
+return generic_get_log('ptestresuls.sections', results, section)
+
+def generic_get_rawlogs(sectname, results):
+if sectname not in results:
 return None
-if 'log' not in results['ptestresult.rawlogs']:
+if 'log' not in results[sectname]:
 return None
-return decode_log(results['ptestresult.rawlogs']['log'])
+return decode_log(results[sectname]['log'])
+
+def ptestresult_get_rawlogs(results):
+return generic_get_rawlogs('ptestresult.rawlogs', results)
 
 def save_resultsdata(results, destdir, fn="testresults.json", ptestjson=False, 
ptestlogs=False):
 for res in results:
-- 
2.25.1

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

View/Reply Online (#138748): 
https://lists.openembedded.org/g/openembedded-core/message/138748
Mute This Topic: https://lists.openembedded.org/mt/74488044/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 5/5] ltp: Exclude the memcg_stress tests due to timeout problems

[Richard Purdie]

This test runs for 900s, we often see tests killed after 300s without
output which makes the test results unreliable and inconsistent. The
easiest solution for now is to skip this long running test, patching
it out wth sed.

Signed-off-by: Richard Purdie 
---
 meta/recipes-extended/ltp/ltp_20200515.bb | 4 
 1 file changed, 4 insertions(+)

diff --git a/meta/recipes-extended/ltp/ltp_20200515.bb 
b/meta/recipes-extended/ltp/ltp_20200515.bb
index 0304a40185b..67c75903204 100644
--- a/meta/recipes-extended/ltp/ltp_20200515.bb
+++ b/meta/recipes-extended/ltp/ltp_20200515.bb
@@ -72,6 +72,10 @@ do_install(){
  -e 's@[^ ]*-fdebug-prefix-map=[^ "]*@@g' \
  -e 's@[^ ]*-fmacro-prefix-map=[^ "]*@@g' \
  -e 's@[^ ]*--sysroot=[^ "]*@@g' 
+
+# The controllers memcg_stree test seems to cause us hangs and takes 900s
+# (maybe we expect more regular output?), anyhow, skip it
+sed -e '/^memcg_stress/d' -i ${D}${prefix}/runtest/controllers
 }
 
 RDEPENDS_${PN} = "\
-- 
2.25.1

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

View/Reply Online (#138749): 
https://lists.openembedded.org/g/openembedded-core/message/138749
Mute This Topic: https://lists.openembedded.org/mt/74488046/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/5] resulttool/report: Remove leftover debugging

[Richard Purdie]

I've long since wondered why there was some odd output in result reports,
remove the leftover debug which was causing it.

Signed-off-by: Richard Purdie 
---
 scripts/lib/resulttool/report.py | 1 -
 1 file changed, 1 deletion(-)

diff --git a/scripts/lib/resulttool/report.py b/scripts/lib/resulttool/report.py
index 7ceceac802c..f0ca50ebe24 100644
--- a/scripts/lib/resulttool/report.py
+++ b/scripts/lib/resulttool/report.py
@@ -96,7 +96,6 @@ class ResultsTextReport(object):
 if 'ltpresult.sections' in result and suite not in 
result['ltpresult.sections']:
 try:
 _, suite, suite1, test = k.split(".", 3)
-print("split2: %s %s %s" % (suite, suite1, test))
 if suite + "." + suite1 in result['ltpresult.sections']:
 suite = suite + "." + suite1
 except ValueError:
-- 
2.25.1

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

View/Reply Online (#138747): 
https://lists.openembedded.org/g/openembedded-core/message/138747
Mute This Topic: https://lists.openembedded.org/mt/74488043/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/5] ltp: Add missing dependencies on coreutils, bc, e2fsprogs and gdb

[Richard Purdie]

When the tests are run we see messages like:

/opt/ltp/testcases/bin/run_cpuctl_stress_test.sh: line 242: nice: command not 
found
/opt/ltp/testcases/bin/run_cpuctl_test_fj.sh: line 66: tac: command not found
vma05 1 TCONF: 'gdb' not found
memcg_failcnt 1 TCONF: 'bc' not found
Owner=nobody; perms=-rw---; sudo: lsattr: command not found

so add missing dependencies to avoid these.

Signed-off-by: Richard Purdie 
---
 meta/recipes-extended/ltp/ltp_20200515.bb | 4 
 1 file changed, 4 insertions(+)

diff --git a/meta/recipes-extended/ltp/ltp_20200515.bb 
b/meta/recipes-extended/ltp/ltp_20200515.bb
index 317a4e461a7..0304a40185b 100644
--- a/meta/recipes-extended/ltp/ltp_20200515.bb
+++ b/meta/recipes-extended/ltp/ltp_20200515.bb
@@ -77,13 +77,17 @@ do_install(){
 RDEPENDS_${PN} = "\
 attr \
 bash \
+bc \
+coreutils \
 cpio \
 cronie \
 curl \
+e2fsprogs \
 e2fsprogs-mke2fs \
 expect \
 file \
 gawk \
+gdb \
 gzip \
 iproute2 \
 ldd \
-- 
2.25.1

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

View/Reply Online (#138745): 
https://lists.openembedded.org/g/openembedded-core/message/138745
Mute This Topic: https://lists.openembedded.org/mt/74488040/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] libexif: upgrade to 0.6.22, change source to GitHub

[Trevor Gamblin]

Updated libexif to 0.6.22, but needed to change to GitHub as a source,
since SourceForge does not yet have 0.6.22 version. The new version
includes the fixes for the three patch files that have been removed,
as well as other severe CVEs.

CVE: CVE-2018-20030
CVE: CVE-2020-13114
CVE: CVE-2020-13113
CVE: CVE-2020-13112
CVE: CVE-2020-0093
CVE: CVE-2019-9278
CVE: CVE-2020-12767
CVE: CVE-2016-6328
CVE: CVE-2017-7544

Signed-off-by: Trevor Gamblin 
---
 .../libexif/libexif/CVE-2016-6328.patch   |  64 --
 .../libexif/libexif/CVE-2017-7544.patch   |  40 --
 .../libexif/libexif/CVE-2018-20030.patch  | 115 --
 .../recipes-support/libexif/libexif_0.6.21.bb |  17 ---
 .../recipes-support/libexif/libexif_0.6.22.bb |  21 
 5 files changed, 21 insertions(+), 236 deletions(-)
 delete mode 100644 meta/recipes-support/libexif/libexif/CVE-2016-6328.patch
 delete mode 100644 meta/recipes-support/libexif/libexif/CVE-2017-7544.patch
 delete mode 100644 meta/recipes-support/libexif/libexif/CVE-2018-20030.patch
 delete mode 100644 meta/recipes-support/libexif/libexif_0.6.21.bb
 create mode 100644 meta/recipes-support/libexif/libexif_0.6.22.bb

diff --git a/meta/recipes-support/libexif/libexif/CVE-2016-6328.patch 
b/meta/recipes-support/libexif/libexif/CVE-2016-6328.patch
deleted file mode 100644
index a6f307439b..00
--- a/meta/recipes-support/libexif/libexif/CVE-2016-6328.patch
+++ /dev/null
@@ -1,64 +0,0 @@
-CVE: CVE-2016-6328
-Upstream-Status: Backport
-Signed-off-by: Ross Burton 
-
-From 41bd04234b104312f54d25822f68738ba8d7133d Mon Sep 17 00:00:00 2001
-From: Marcus Meissner 
-Date: Tue, 25 Jul 2017 23:44:44 +0200
-Subject: [PATCH] fixes some (not all) buffer overreads during decoding pentax
- makernote entries.
-
-This should fix:
-https://sourceforge.net/p/libexif/bugs/125/ CVE-2016-6328

- libexif/pentax/mnote-pentax-entry.c | 16 +---
- 1 file changed, 13 insertions(+), 3 deletions(-)
-
-diff --git a/libexif/pentax/mnote-pentax-entry.c 
b/libexif/pentax/mnote-pentax-entry.c
-index d03d159..ea0429a 100644
 a/libexif/pentax/mnote-pentax-entry.c
-+++ b/libexif/pentax/mnote-pentax-entry.c
-@@ -425,24 +425,34 @@ mnote_pentax_entry_get_value (MnotePentaxEntry *entry,
-   case EXIF_FORMAT_SHORT:
- {
-   const unsigned char *data = entry->data;
--  size_t k, len = strlen(val);
-+  size_t k, len = strlen(val), sizeleft;
-+
-+  sizeleft = entry->size;
-   for(k=0; kcomponents; k++) {
-+  if (sizeleft < 2)
-+  break;
-   vs = exif_get_short (data, entry->order);
-   snprintf (val+len, maxlen-len, "%i ", vs);
-   len = strlen(val);
-   data += 2;
-+  sizeleft -= 2;
-   }
- }
- break;
-   case EXIF_FORMAT_LONG:
- {
-   const unsigned char *data = entry->data;
--  size_t k, len = strlen(val);
-+  size_t k, len = strlen(val), sizeleft;
-+
-+  sizeleft = entry->size;
-   for(k=0; kcomponents; k++) {
-+  if (sizeleft < 4)
-+  break;
-   vl = exif_get_long (data, entry->order);
-   snprintf (val+len, maxlen-len, "%li", (long 
int) vl);
-   len = strlen(val);
-   data += 4;
-+  sizeleft -= 4;
-   }
- }
- break;
-@@ -455,5 +465,5 @@ mnote_pentax_entry_get_value (MnotePentaxEntry *entry,
-   break;
-   }
- 
--  return (val);
-+  return val;
- }
diff --git a/meta/recipes-support/libexif/libexif/CVE-2017-7544.patch 
b/meta/recipes-support/libexif/libexif/CVE-2017-7544.patch
deleted file mode 100644
index e49481ff84..00
--- a/meta/recipes-support/libexif/libexif/CVE-2017-7544.patch
+++ /dev/null
@@ -1,40 +0,0 @@
-From 8a92f964a66d476ca8907234359e92a70fc1325b Mon Sep 17 00:00:00 2001
-From: Changqing Li 
-Date: Tue, 28 Aug 2018 15:12:10 +0800
-Subject: [PATCH] On saving makernotes, make sure the makernote container tags
- has a type with 1 byte components.
-
-Fixes (at least):
-   https://sourceforge.net/p/libexif/bugs/130
-   https://sourceforge.net/p/libexif/bugs/129
-
-Upstream-Status: Backport[https://github.com/libexif/libexif/commit/
-c39acd1692023b26290778a02a9232c873f9d71a#diff-830e348923810f00726700b083ec00cd]
-
-CVE: CVE-2017-7544
-
-Signed-off-by: Changqing Li 

- libexif/exif-data.c | 6 ++
- 1 file changed, 6 insertions(+)
-
-diff --git a/libexif/exif-data.c 

[OE-core] ✗ patchtest: failure for bind: Apply CVE-2020-8616.patch for bind 9.11.13

[Patchwork]

== Series Details ==

Series: bind: Apply CVE-2020-8616.patch for bind 9.11.13
Revision: 1
URL   : https://patchwork.openembedded.org/series/24328/
State : failure

== Summary ==


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



* Patchbind: Apply CVE-2020-8616.patch for bind 9.11.13
 Issue Missing or incorrectly formatted CVE tag in included patch 
file [test_cve_tag_format] 
  Suggested fixCorrect or include the CVE tag on cve patch with format: 
"CVE: CVE--"



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

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

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

View/Reply Online (#138743): 
https://lists.openembedded.org/g/openembedded-core/message/138743
Mute This Topic: https://lists.openembedded.org/mt/74487137/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 6/6] perf: drop 'include' copy

[Andrey Zhizhikin]

On Tue, May 26, 2020 at 10:44 PM Martin Jansa  wrote:
>
> On Tue, May 26, 2020 at 10:22:07PM +0200, Andrey Zhizhikin wrote:
> > Kernel 4.4 is also LTS and has (had) a very long time span, so I
> > believe there are some people out there who might still have it in
> > their Products (industrial applications are pretty conservative guys).
> > I have to admit that Yocto 3.1 + Kernel 4.4 is a rather strange
> > combination, but it also has a valid reason to exist.
> >
> > I guess reverting this patch is not really an option, but this topic
> > deserves then a bit of documentation somewhere so people can look this
> > up and have a quick fix for themselves. The question is: where to put
> > this information?
> >
> > Honestly, it didn't take me long to find the commit that solved the
> > build, it took me rather long to figure out why I didn't see changes
> > from it on the [dunfell]...
> >
> > >
> > > What exactly was the build error that you saw ?
> >
> > Exactly what JaMa had and fixed with his commit, namely a multitude of:
> >  error: #include nested too deeply
> >
> > and some of:
> >
> > /perf/1.0-r9/perf-1.0/tools/include/linux/list.h:5:10: fatal
> > error: ../../../include/linux/list.h: No such file or directory
>
> But this isn't your only issue with perf on 4.4 kernel, right?
>
> I still carry whatever is needed in a .bbappend, for dunfell I have
> also:
>
> # The tools/lib/api in kernels older than 4.8 don't respect WERROR env
> # variable exported by perf.bb
> EXTRA_OEMAKE += "EXTRA_CFLAGS='-ldw -Wno-error=stringop-truncation'"
>
> # scripting PACKAGECONFIG is now using python3, but perf in kernel
> # supports python3 only with 4.17-rc1 and newer kernel (here we are
> # currently using 4.4.84), see:
> # 
> http://lists.openembedded.org/pipermail/openembedded-core/2019-September/286902.html
> PACKAGECONFIG_remove = "scripting"

Mine's got only:
PACKAGECONFIG_remove = "scripting"

And now I have in addition:
+PERF_SRC = "Makefile \
+include \
+tools/arch \
+tools/build \
+tools/include \
+tools/lib \
+tools/Makefile \
+tools/perf \
+tools/scripts \
+scripts/ \
+arch/${ARCH}/Makefile \

I guess you can safely drop the -Wno-error=stringop-truncation, it was
fixed with [d943a53ac6d7bd5eab93adecfe9b37356e46da44] in 4.4.y

>
> Maybe some of it got already resolved elsewhere, this bbappend just
> collects whatever tweaks are needed when it gets broken and I very
> rarely have time to go back through them to re-check if it's still
> needed (with newer oe-core revision or slightly newer 4.4 kernel).
>
> Cheers,



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

View/Reply Online (#138742): 
https://lists.openembedded.org/g/openembedded-core/message/138742
Mute This Topic: https://lists.openembedded.org/mt/72386349/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] bind: Apply CVE-2020-8616.patch for bind 9.11.13

[Khem Raj]

Steve

this is Dunfell worthy too. So please track it.

On Tue, May 26, 2020 at 1:51 PM Khem Raj  wrote:
>
> From: Rense Jacob 
>
> backport for nvd.nist.gov/vuln/detail/CVE-2020-8616
>
> Signed-off-by: Rense 
> Signed-off-by: Khem Raj 
> ---
>  .../bind/bind/CVE-2020-8616.patch | 221 ++
>  .../recipes-connectivity/bind/bind_9.11.13.bb |   1 +
>  2 files changed, 222 insertions(+)
>  create mode 100644 meta/recipes-connectivity/bind/bind/CVE-2020-8616.patch
>
> diff --git a/meta/recipes-connectivity/bind/bind/CVE-2020-8616.patch 
> b/meta/recipes-connectivity/bind/bind/CVE-2020-8616.patch
> new file mode 100644
> index 00..16ff86016b
> --- /dev/null
> +++ b/meta/recipes-connectivity/bind/bind/CVE-2020-8616.patch
> @@ -0,0 +1,221 @@
> +backport for nvd.nist.gov/vuln/detail/CVE-2020-8616
> +
> +Upstream-Status: Backport 
> [downloads.isc.org/isc/bind9/9.11.19/patches/CVE-2020-8616.patch]
> +
> +Signed-off-by: Rense 
> +Signed-off-by: Khem Raj 
> +
> +Index: bind-9.11.13/lib/dns/adb.c
> +===
> +--- bind-9.11.13.orig/lib/dns/adb.c
>  bind-9.11.13/lib/dns/adb.c
> +@@ -404,16 +404,14 @@ static void log_quota(dns_adbentry_t *en
> +  */
> + #define FIND_WANTEVENT(fn)  (((fn)->options & DNS_ADBFIND_WANTEVENT) != 
> 0)
> + #define FIND_WANTEMPTYEVENT(fn) (((fn)->options & DNS_ADBFIND_EMPTYEVENT) 
> != 0)
> +-#define FIND_AVOIDFETCHES(fn)   (((fn)->options & DNS_ADBFIND_AVOIDFETCHES) 
> \
> +-   != 0)
> +-#define FIND_STARTATZONE(fn)(((fn)->options & DNS_ADBFIND_STARTATZONE) \
> +-   != 0)
> +-#define FIND_HINTOK(fn) (((fn)->options & DNS_ADBFIND_HINTOK) != 0)
> +-#define FIND_GLUEOK(fn) (((fn)->options & DNS_ADBFIND_GLUEOK) != 0)
> +-#define FIND_HAS_ADDRS(fn)  (!ISC_LIST_EMPTY((fn)->list))
> +-#define FIND_RETURNLAME(fn) (((fn)->options & DNS_ADBFIND_RETURNLAME) 
> != 0)
> +-
> +-/*
> ++#define FIND_AVOIDFETCHES(fn) (((fn)->options & DNS_ADBFIND_AVOIDFETCHES) 
> != 0)
> ++#define FIND_STARTATZONE(fn)  (((fn)->options & DNS_ADBFIND_STARTATZONE) != 
> 0)
> ++#define FIND_HINTOK(fn)   (((fn)->options & DNS_ADBFIND_HINTOK) 
> != 0)
> ++#define FIND_GLUEOK(fn)   (((fn)->options & DNS_ADBFIND_GLUEOK) 
> != 0)
> ++#define FIND_HAS_ADDRS(fn)(!ISC_LIST_EMPTY((fn)->list))
> ++#define FIND_RETURNLAME(fn)   (((fn)->options & DNS_ADBFIND_RETURNLAME) != 
> 0)
> ++#define FIND_NOFETCH(fn)  (((fn)->options & DNS_ADBFIND_NOFETCH) != 0)
> ++/*
> +  * These are currently used on simple unsigned ints, so they are
> +  * not really associated with any particular type.
> +  */
> +@@ -3155,21 +3153,25 @@ dns_adb_createfind2(dns_adb_t *adb, isc_
> +* Listen to negative cache hints, and don't start
> +* another query.
> +*/
> +-  if (NCACHE_RESULT(result) || AUTH_NX(result))
> ++  if (NCACHE_RESULT(result) || AUTH_NX(result)) {
> +   goto fetch;
> +-
> +-  if (!NAME_FETCH_V6(adbname))
> ++}
> ++  if (!NAME_FETCH_V6(adbname)) {
> +   wanted_fetches |= DNS_ADBFIND_INET6;
> ++  }
> +   }
> +
> +  fetch:
> +   if ((WANT_INET(wanted_addresses) && NAME_HAS_V4(adbname)) ||
> +   (WANT_INET6(wanted_addresses) && NAME_HAS_V6(adbname)))
> ++  {
> +   have_address = true;
> +-  else
> +-  have_address = false;
> +-  if (wanted_fetches != 0 &&
> +-  ! (FIND_AVOIDFETCHES(find) && have_address)) {
> ++  } else {
> ++  have_address = false;
> ++  }
> ++  if (wanted_fetches != 0 && !(FIND_AVOIDFETCHES(find) && have_address) 
> &&
> ++  !FIND_NOFETCH(find))
> ++  {
> +   /*
> +* We're missing at least one address family.  Either the
> +* caller hasn't instructed us to avoid fetches, or we don't
> +@@ -3177,8 +3179,9 @@ dns_adb_createfind2(dns_adb_t *adb, isc_
> +* be acceptable so we have to launch fetches.
> +*/
> +
> +-  if (FIND_STARTATZONE(find))
> ++  if (FIND_STARTATZONE(find)) {
> +   start_at_zone = true;
> ++  }
> +
> +   /*
> +* Start V4.
> +Index: bind-9.11.13/lib/dns/include/dns/adb.h
> +===
> +--- bind-9.11.13.orig/lib/dns/include/dns/adb.h
>  bind-9.11.13/lib/dns/include/dns/adb.h
> +@@ -209,6 +209,12 @@ struct dns_adbfind {
> + #define DNS_ADBFIND_OVERQUOTA 0x0400
> +
> + /*%
> ++ *Don't perform a fetch even if there are no address records available.
> ++ */
> ++#define DNS_ADBFIND_NOFETCH   0x0800
> ++
> ++
> ++/*%
> +  * The answers to queries come back as a list of these.
> +  */
> + struct dns_adbaddrinfo {
> 

[OE-core] [PATCH] bind: Apply CVE-2020-8616.patch for bind 9.11.13

[Khem Raj]

From: Rense Jacob 

backport for nvd.nist.gov/vuln/detail/CVE-2020-8616

Signed-off-by: Rense 
Signed-off-by: Khem Raj 
---
 .../bind/bind/CVE-2020-8616.patch | 221 ++
 .../recipes-connectivity/bind/bind_9.11.13.bb |   1 +
 2 files changed, 222 insertions(+)
 create mode 100644 meta/recipes-connectivity/bind/bind/CVE-2020-8616.patch

diff --git a/meta/recipes-connectivity/bind/bind/CVE-2020-8616.patch 
b/meta/recipes-connectivity/bind/bind/CVE-2020-8616.patch
new file mode 100644
index 00..16ff86016b
--- /dev/null
+++ b/meta/recipes-connectivity/bind/bind/CVE-2020-8616.patch
@@ -0,0 +1,221 @@
+backport for nvd.nist.gov/vuln/detail/CVE-2020-8616
+
+Upstream-Status: Backport 
[downloads.isc.org/isc/bind9/9.11.19/patches/CVE-2020-8616.patch]
+
+Signed-off-by: Rense 
+Signed-off-by: Khem Raj 
+
+Index: bind-9.11.13/lib/dns/adb.c
+===
+--- bind-9.11.13.orig/lib/dns/adb.c
 bind-9.11.13/lib/dns/adb.c
+@@ -404,16 +404,14 @@ static void log_quota(dns_adbentry_t *en
+  */
+ #define FIND_WANTEVENT(fn)  (((fn)->options & DNS_ADBFIND_WANTEVENT) != 0)
+ #define FIND_WANTEMPTYEVENT(fn) (((fn)->options & DNS_ADBFIND_EMPTYEVENT) != 
0)
+-#define FIND_AVOIDFETCHES(fn)   (((fn)->options & DNS_ADBFIND_AVOIDFETCHES) \
+-   != 0)
+-#define FIND_STARTATZONE(fn)(((fn)->options & DNS_ADBFIND_STARTATZONE) \
+-   != 0)
+-#define FIND_HINTOK(fn) (((fn)->options & DNS_ADBFIND_HINTOK) != 0)
+-#define FIND_GLUEOK(fn) (((fn)->options & DNS_ADBFIND_GLUEOK) != 0)
+-#define FIND_HAS_ADDRS(fn)  (!ISC_LIST_EMPTY((fn)->list))
+-#define FIND_RETURNLAME(fn) (((fn)->options & DNS_ADBFIND_RETURNLAME) != 
0)
+-
+-/*
++#define FIND_AVOIDFETCHES(fn) (((fn)->options & DNS_ADBFIND_AVOIDFETCHES) != 
0)
++#define FIND_STARTATZONE(fn)  (((fn)->options & DNS_ADBFIND_STARTATZONE) != 0)
++#define FIND_HINTOK(fn)   (((fn)->options & DNS_ADBFIND_HINTOK) 
!= 0)
++#define FIND_GLUEOK(fn)   (((fn)->options & DNS_ADBFIND_GLUEOK) 
!= 0)
++#define FIND_HAS_ADDRS(fn)(!ISC_LIST_EMPTY((fn)->list))
++#define FIND_RETURNLAME(fn)   (((fn)->options & DNS_ADBFIND_RETURNLAME) != 0)
++#define FIND_NOFETCH(fn)  (((fn)->options & DNS_ADBFIND_NOFETCH) != 0)
++/*
+  * These are currently used on simple unsigned ints, so they are
+  * not really associated with any particular type.
+  */
+@@ -3155,21 +3153,25 @@ dns_adb_createfind2(dns_adb_t *adb, isc_
+* Listen to negative cache hints, and don't start
+* another query.
+*/
+-  if (NCACHE_RESULT(result) || AUTH_NX(result))
++  if (NCACHE_RESULT(result) || AUTH_NX(result)) {
+   goto fetch;
+-
+-  if (!NAME_FETCH_V6(adbname))
++}
++  if (!NAME_FETCH_V6(adbname)) {
+   wanted_fetches |= DNS_ADBFIND_INET6;
++  }
+   }
+ 
+  fetch:
+   if ((WANT_INET(wanted_addresses) && NAME_HAS_V4(adbname)) ||
+   (WANT_INET6(wanted_addresses) && NAME_HAS_V6(adbname)))
++  {   
+   have_address = true;
+-  else
+-  have_address = false;
+-  if (wanted_fetches != 0 &&
+-  ! (FIND_AVOIDFETCHES(find) && have_address)) {
++  } else {
++  have_address = false;
++  }
++  if (wanted_fetches != 0 && !(FIND_AVOIDFETCHES(find) && have_address) &&
++  !FIND_NOFETCH(find))
++  {
+   /*
+* We're missing at least one address family.  Either the
+* caller hasn't instructed us to avoid fetches, or we don't
+@@ -3177,8 +3179,9 @@ dns_adb_createfind2(dns_adb_t *adb, isc_
+* be acceptable so we have to launch fetches.
+*/
+ 
+-  if (FIND_STARTATZONE(find))
++  if (FIND_STARTATZONE(find)) {
+   start_at_zone = true;
++  }   
+ 
+   /*
+* Start V4.
+Index: bind-9.11.13/lib/dns/include/dns/adb.h
+===
+--- bind-9.11.13.orig/lib/dns/include/dns/adb.h
 bind-9.11.13/lib/dns/include/dns/adb.h
+@@ -209,6 +209,12 @@ struct dns_adbfind {
+ #define DNS_ADBFIND_OVERQUOTA 0x0400
+ 
+ /*%
++ *Don't perform a fetch even if there are no address records available.
++ */
++#define DNS_ADBFIND_NOFETCH   0x0800
++
++
++/*%
+  * The answers to queries come back as a list of these.
+  */
+ struct dns_adbaddrinfo {
+Index: bind-9.11.13/lib/dns/resolver.c
+===
+--- bind-9.11.13.orig/lib/dns/resolver.c
 bind-9.11.13/lib/dns/resolver.c
+@@ -172,6 +172,15 @@
+ #define DEFAULT_MAX_QUERIES 75
+ #endif
+ 
++/*
++ * After NS_FAIL_LIMIT attempts to fetch a name server address,
++ * if the number 

Re: [OE-core] [PATCH 6/6] perf: drop 'include' copy

[Martin Jansa]

On Tue, May 26, 2020 at 10:22:07PM +0200, Andrey Zhizhikin wrote:
> Kernel 4.4 is also LTS and has (had) a very long time span, so I
> believe there are some people out there who might still have it in
> their Products (industrial applications are pretty conservative guys).
> I have to admit that Yocto 3.1 + Kernel 4.4 is a rather strange
> combination, but it also has a valid reason to exist.
> 
> I guess reverting this patch is not really an option, but this topic
> deserves then a bit of documentation somewhere so people can look this
> up and have a quick fix for themselves. The question is: where to put
> this information?
> 
> Honestly, it didn't take me long to find the commit that solved the
> build, it took me rather long to figure out why I didn't see changes
> from it on the [dunfell]...
> 
> >
> > What exactly was the build error that you saw ?
> 
> Exactly what JaMa had and fixed with his commit, namely a multitude of:
>  error: #include nested too deeply
> 
> and some of:
> 
> /perf/1.0-r9/perf-1.0/tools/include/linux/list.h:5:10: fatal
> error: ../../../include/linux/list.h: No such file or directory

But this isn't your only issue with perf on 4.4 kernel, right?

I still carry whatever is needed in a .bbappend, for dunfell I have
also:

# The tools/lib/api in kernels older than 4.8 don't respect WERROR env
# variable exported by perf.bb
EXTRA_OEMAKE += "EXTRA_CFLAGS='-ldw -Wno-error=stringop-truncation'"

# scripting PACKAGECONFIG is now using python3, but perf in kernel
# supports python3 only with 4.17-rc1 and newer kernel (here we are
# currently using 4.4.84), see:
# 
http://lists.openembedded.org/pipermail/openembedded-core/2019-September/286902.html
PACKAGECONFIG_remove = "scripting"

Maybe some of it got already resolved elsewhere, this bbappend just
collects whatever tweaks are needed when it gets broken and I very
rarely have time to go back through them to re-check if it's still
needed (with newer oe-core revision or slightly newer 4.4 kernel).

Cheers,


signature.asc
Description: PGP signature
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138739): 
https://lists.openembedded.org/g/openembedded-core/message/138739
Mute This Topic: https://lists.openembedded.org/mt/72386349/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 6/6] perf: drop 'include' copy

[Andrey Zhizhikin]

On Tue, May 26, 2020 at 2:31 PM Bruce Ashfield  wrote:
>
> On Tue, May 26, 2020 at 1:44 AM Andrey Zhizhikin  wrote:
> >
> > On Mon, Oct 21, 2019 at 10:58 PM Bruce Ashfield
> >  wrote:
> > >
> > > On Mon, Oct 21, 2019 at 4:24 PM Martin Jansa  
> > > wrote:
> > > >
> > > > On Mon, Oct 21, 2019 at 04:16:18PM -0400, bruce.ashfi...@gmail.com 
> > > > wrote:
> > > > > From: Bruce Ashfield 
> > > > >
> > > > > The copy of the kernel's top level include directory is not
> > > > > required to build perf. We have both the linux-libc-headers and
> > > > > perf's captured/copied headers for what it requires.
> > > > >
> > > > > The copy of the kernel's headers is leading us to multiple smaller
> > > > > fixes to ensure that the various .h files are in sync. We can
> > > > > remove the copy and all of the sync checks, and perf still builds
> > > > > and executes correctly.
> > > >
> > > > Maybe reorder this before "[OE-core] [PATCH 3/6] perf: fix v5.4+ builds"
> > > > as it removes most of what was possibly incorrectly added there (see 2nd
> > > > review)
> > > >
> > >
> > > I left this here on purpose, since it is only RFC. The other patches
> > > as they appear in the series are required to build against 5.4+, but
> > > this is optional.
> >
> > Look like this patch causes issues with building perf for 4.4.y kernel...
> >
> > I've recently started to upgrade some of BSPs from zeus to dunfell,
> > and kernel 4.4.y fails to build with this patch applied. When I
> > applied changes from Martin in commit
> > [f3515d2d2545cae6b88fe5e86d081f4ef6133bf6] - build went through.
> >
> > I have now the bbappend in the layer, which sets the PERF_SRC to add
> > the "include" folder back but I don't think this is a clean approach.
> >
> > Should this be reverted, or those who has a "dunfell+4.4.y kernel"
> > setup need to use appends to override the PERF_SRC?
>
> If you revert it, you might be trading warnings and breakages for
> newer kernels to fix 4.4. That's the issue with perf, since it builds
> right from the kernel source, it has to serve many different versions
> (and we juggle breaking/fixing that from time to time).

I got the same conclusion that healing one can hurt the other... perf
is a gentle beast, I had my own history with it already.

>
> So any revert would have to then build all of the different kernel
> versions and perf to make sure that we don't trade one breakage for
> another .. and being LTS we need to be extra careful. Since we don't
> have an active 4.4 kernel in that branch, it would have to be ad-hoc
> testing to confirm.

Kernel 4.4 is also LTS and has (had) a very long time span, so I
believe there are some people out there who might still have it in
their Products (industrial applications are pretty conservative guys).
I have to admit that Yocto 3.1 + Kernel 4.4 is a rather strange
combination, but it also has a valid reason to exist.

I guess reverting this patch is not really an option, but this topic
deserves then a bit of documentation somewhere so people can look this
up and have a quick fix for themselves. The question is: where to put
this information?

Honestly, it didn't take me long to find the commit that solved the
build, it took me rather long to figure out why I didn't see changes
from it on the [dunfell]...

>
> What exactly was the build error that you saw ?

Exactly what JaMa had and fixed with his commit, namely a multitude of:
 error: #include nested too deeply

and some of:

/perf/1.0-r9/perf-1.0/tools/include/linux/list.h:5:10: fatal
error: ../../../include/linux/list.h: No such file or directory

>
> Bruce
>
>
>
> Bruce
>
> >
> > >
> > > Bruce
> > >
> > > > > Signed-off-by: Bruce Ashfield 
> > > > > ---
> > > > >  meta/recipes-kernel/perf/perf.bb | 9 -
> > > > >  1 file changed, 9 deletions(-)
> > > > >
> > > > > diff --git a/meta/recipes-kernel/perf/perf.bb 
> > > > > b/meta/recipes-kernel/perf/perf.bb
> > > > > index 191305969c..5f0ba7c180 100644
> > > > > --- a/meta/recipes-kernel/perf/perf.bb
> > > > > +++ b/meta/recipes-kernel/perf/perf.bb
> > > > > @@ -106,7 +106,6 @@ EXTRA_OEMAKE += "\
> > > > >  EXTRA_OEMAKE_append_task-configure = " JOBS=1"
> > > > >
> > > > >  PERF_SRC ?= "Makefile \
> > > > > - include \
> > > > >   tools/arch \
> > > > >   tools/build \
> > > > >   tools/include \
> > > > > @@ -248,14 +247,6 @@ do_configure_prepend () {
> > > > >  # so we copy it from the sysroot unistd.h to the perf unistd.h
> > > > >  install -D -m0644 ${STAGING_INCDIR}/asm-generic/unistd.h 
> > > > > ${S}/tools/include/uapi/asm-generic/unistd.h
> > > > >  install -D -m0644 ${STAGING_INCDIR}/asm-generic/unistd.h 
> > > > > ${S}/include/uapi/asm-generic/unistd.h
> > > > > -
> > > > > -# bits.h can have the same issue as unistd.h, so we make the 
> > > > > tools variant take precedence
> > > > > -[ -e ${S}/tools/include/linux/bits.h ] && install -D -m0644 
> > > > > ${S}/tools/include/linux/bits.h 

[OE-core] ✗ patchtest: failure for Add a new bbclass that abstracts the generation of FIT blobs (rev7)

[Patchwork]

== Series Details ==

Series: Add a new bbclass that abstracts the generation of FIT blobs (rev7)
Revision: 7
URL   : https://patchwork.openembedded.org/series/23431/
State : failure

== Summary ==


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



* Patch[v6,1/3] Add a recipe for `python3-fdt` package
 Issue Shortlog does not follow expected format 
[test_shortlog_format] 
  Suggested fixCommit shortlog (first line of commit message) should follow 
the format ": "

* Issue Errors in your Python code were encountered [test_pylint] 
  Suggested fixCorrect the lines introduced by your patch
  Output   Please, fix the listed issues:
   meta/lib/oeqa/selftest/cases/fit_image.py does not exist



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

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

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

View/Reply Online (#138737): 
https://lists.openembedded.org/g/openembedded-core/message/138737
Mute This Topic: https://lists.openembedded.org/mt/74484066/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 v6 1/3] Add a recipe for `python3-fdt` package

[Nandor Han]

The package `python3-fdt` is used for parsing and generating DTBs.

Signed-off-by: Nandor Han 
---
 meta/recipes-devtools/python/python3-fdt_0.2.0.bb | 14 ++
 1 file changed, 14 insertions(+)
 create mode 100644 meta/recipes-devtools/python/python3-fdt_0.2.0.bb

diff --git a/meta/recipes-devtools/python/python3-fdt_0.2.0.bb 
b/meta/recipes-devtools/python/python3-fdt_0.2.0.bb
new file mode 100644
index 00..040ceba980
--- /dev/null
+++ b/meta/recipes-devtools/python/python3-fdt_0.2.0.bb
@@ -0,0 +1,14 @@
+SUMMARY = "Library for manipulation of Device Tree Data"
+HOMEPAGE = "https://github.com/molejar/pyFDT;
+SECTION = "devel/python"
+LICENSE = "Apache-2.0"
+LIC_FILES_CHKSUM = 
"file://PKG-INFO;beginline=8;endline=8;md5=9a6ea5b6c346a830f54cc95f6a2a9245"
+
+SRC_URI[md5sum] = "a91daa36b3216f54feeac74ea8e5a475"
+SRC_URI[sha256sum] = 
"b675139346946115513e27b5eed9aa882628ab74ed500bd5e25e122ee0afa2f6"
+
+PYPI_PACKAGE = "fdt"
+
+inherit pypi setuptools3
+
+BBCLASSEXTEND = "native"
-- 
2.24.1

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

View/Reply Online (#138733): 
https://lists.openembedded.org/g/openembedded-core/message/138733
Mute This Topic: https://lists.openembedded.org/mt/74483804/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 v6 3/3] selftest: add a unit-test for fit-image bbclass

[Nandor Han]

The unit-test will test the basic functionality of `fit-image.bbclass`.

Signed-off-by: Nandor Han 
---
 .../fit-image-test/files/dt-fake.dtb  |   3 +
 .../fit-image-test/files/zImage-fake  |   3 +
 .../fit-image-test/fit-image-test.bb  |  17 ++
 meta/lib/oeqa/selftest/cases/fit_image.py | 212 ++
 4 files changed, 235 insertions(+)
 create mode 100644 meta-selftest/recipes-test/fit-image-test/files/dt-fake.dtb
 create mode 100644 meta-selftest/recipes-test/fit-image-test/files/zImage-fake
 create mode 100644 meta-selftest/recipes-test/fit-image-test/fit-image-test.bb
 create mode 100644 meta/lib/oeqa/selftest/cases/fit_image.py

diff --git a/meta-selftest/recipes-test/fit-image-test/files/dt-fake.dtb 
b/meta-selftest/recipes-test/fit-image-test/files/dt-fake.dtb
new file mode 100644
index 00..7fa871ff00
--- /dev/null
+++ b/meta-selftest/recipes-test/fit-image-test/files/dt-fake.dtb
@@ -0,0 +1,3 @@
+Z�P�acn�ZWD1\�!΄�l�V
+t(��H��
��z��jb4.���݁�W;I�ƶb�e���Ñ�5�x�&�9,��g
+�;���!cV
diff --git a/meta-selftest/recipes-test/fit-image-test/files/zImage-fake 
b/meta-selftest/recipes-test/fit-image-test/files/zImage-fake
new file mode 100644
index 00..7fa871ff00
--- /dev/null
+++ b/meta-selftest/recipes-test/fit-image-test/files/zImage-fake
@@ -0,0 +1,3 @@
+Z�P�acn�ZWD1\�!΄�l�V
+t(��H��
��z��jb4.���݁�W;I�ƶb�e���Ñ�5�x�&�9,��g
+�;���!cV
diff --git a/meta-selftest/recipes-test/fit-image-test/fit-image-test.bb 
b/meta-selftest/recipes-test/fit-image-test/fit-image-test.bb
new file mode 100644
index 00..c7f325ec8a
--- /dev/null
+++ b/meta-selftest/recipes-test/fit-image-test/fit-image-test.bb
@@ -0,0 +1,17 @@
+SUMMARY = "Recipe for testing the fit_image bbclass"
+LICENSE = "MIT"
+LIC_FILES_CHKSUM = 
"file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
+
+DEPENDS += "\
+python3-fdt-native \
+"
+
+SRC_URI = "\
+file://zImage-fake \
+file://dt-fake.dtb \
+"
+
+inherit fit_image
+
+include test_recipe.inc
+
diff --git a/meta/lib/oeqa/selftest/cases/fit_image.py 
b/meta/lib/oeqa/selftest/cases/fit_image.py
new file mode 100644
index 00..866e48b20e
--- /dev/null
+++ b/meta/lib/oeqa/selftest/cases/fit_image.py
@@ -0,0 +1,212 @@
+import os
+from oeqa.selftest.case import OESelftestTestCase
+from oeqa.utils.commands import get_bb_var, bitbake, get_bb_vars
+
+class FitImage(OESelftestTestCase):
+
+@classmethod
+def setUpClass(cls):
+super(FitImage, cls).setUpClass()
+cls.recipe_name = 'fit-image-test'
+cls.build_dir = get_bb_var('B', cls.recipe_name)
+cls.fit_blob_path = os.path.join(cls.build_dir, 'image-fit.itb')
+
+bitbake('python3-fdt-native')
+fdt_sitepackage=get_bb_var("S", "python3-fdt-native")
+os.sys.path.append(fdt_sitepackage)
+import fdt
+
+bitbake('{recipe_name} -c 
cleanall'.format(recipe_name=cls.recipe_name))
+
+@classmethod
+def tearDownClass(cls):
+bitbake('{recipe_name} -c 
cleanall'.format(recipe_name=cls.recipe_name))
+super(FitImage, cls).tearDownClass()
+
+def _get_fit_configuration(self):
+configuration = """
+KERNEL_IMAGE_NODE[name] = "kernel"
+KERNEL_IMAGE_NODE[description] = "${PF}"
+KERNEL_IMAGE_NODE[data] = '/incbin/("${WORKDIR}/zImage-fake")'
+KERNEL_IMAGE_NODE[type] = "kernel"
+KERNEL_IMAGE_NODE[arch] = "arm"
+KERNEL_IMAGE_NODE[os] = "linux"
+KERNEL_IMAGE_NODE[compression] = "none"
+KERNEL_IMAGE_NODE[load] = "0x8400"
+KERNEL_IMAGE_NODE[entry] = "0x8400"
+KERNEL_IMAGE_NODE[hash] = "sha256"
+
+FDT_IMAGE_NODE[name] = "fdt"
+FDT_IMAGE_NODE[description] = "FDT blob"
+FDT_IMAGE_NODE[data] = '/incbin/("${WORKDIR}/dt-fake.dtb")'
+FDT_IMAGE_NODE[type] = "flat_dt"
+FDT_IMAGE_NODE[arch] = "arm"
+FDT_IMAGE_NODE[compression] = "none"
+FDT_IMAGE_NODE[hash] = "sha256"
+
+CONF1_CONF_NODE[name] = "conf"
+CONF1_CONF_NODE[description] = "Linux kernel and FDT blob"
+CONF1_CONF_NODE[kernel] = "kernel"
+CONF1_CONF_NODE[fdt] = "fdt"
+
+FIT_IMAGES_NODE = "KERNEL_IMAGE_NODE FDT_IMAGE_NODE"
+FIT_CONFIGURATIONS_NODE = "CONF1_CONF_NODE"
+FIT_CONFIGURATIONS_NODE[default] = "${@d.getVarFlag('CONF1_CONF_NODE', 'name') 
or ""}"
+"""
+return configuration
+
+def setUp(self):
+super(FitImage, self).setUp()
+self.write_recipeinc(self.recipe_name, self._get_fit_configuration())
+
+def tearDown(self):
+self.delete_recipeinc(self.recipe_name)
+super(FitImage, self).tearDown()
+
+def test_fit_source_is_generated_correctly(self):
+ret = bitbake("{recipe} -D -f -c 
generate_fit_image".format(recipe=self.recipe_name)).output
+self.logger.info('HN {log}'.format(log=ret))
+
+def test_fit_blob_is_generated_successfully(self):
+"""
+Summary: Able to apply a single patch to the Linux kernel source
+Expected:The README file should exist and the patch changes should 
be
+  

[OE-core][PATCH v6 2/3] classes: Add a new bbclass that abstracts the generation of FIT blobs

[Nandor Han]

FIT format is very versatile allowing various combination of booting
sequences. In the same time different U-Boot boot stages can use FIT
blobs to pack various binaries (e.g. SPL supports reading U-Boot from a
FIT blob). Because of the allowed level of customization, the generation
of a FIT blob using a fixed image tree source, becomes challenging and
increase the level of complexity where different configurations and
combinations are needed.

This bbclass will know how to generate a FIT blob, leaving the mechanics
of the process (dependencies, task order...) to be handled by the users
of the bbclass. In the same time will allow to separate the knowledge of
the FIT format leaving the user code cleaner and more readable.

Signed-off-by: Nandor Han 
---
 meta/classes/fit_image.bbclass | 387 +
 1 file changed, 387 insertions(+)
 create mode 100644 meta/classes/fit_image.bbclass

diff --git a/meta/classes/fit_image.bbclass b/meta/classes/fit_image.bbclass
new file mode 100644
index 00..2d1451020c
--- /dev/null
+++ b/meta/classes/fit_image.bbclass
@@ -0,0 +1,387 @@
+#
+# The class will facilitate the generation of FIT blobs.
+#
+# Glossary
+#FIT - Flattened uImage Tree
+#
+# Requirements:
+#
+#* The user need to specify the image content using the format specified 
in the "FIT Image API" section.
+#
+# FIT Image API
+#
+# The bbclass is using variable and variable flags to declare the FIT image 
content.
+#
+#* Sub-Images and Configuration Nodes
+#
+#   ** A sub-image node content is declared using the format 
`VAR_NODE[] = `.
+# * VAR_NODE - freely selected name of the variable representing a 
node.
+# *  - a sub-image property (e.g. description, type...).
+# *  - the property value.
+# Depending of the property the value can support different 
formats.
+#   ** Property Values Formats
+#
+#string property
+#---
+#format: "" - in case the property expects a text.
+#(e.g. IMAGE_NODE_KERNEL[type] = "kernel")
+#
+#address property
+#
+#format: "" - in case the property expects an address.
+#(e.g. IMAGE_NODE_KERNEL[entry] = "0xABCDABCD")
+#
+#hash property
+#-
+#format: "" - for hash property the hash type needs to 
be specified.
+#(e.g. IMAGE_NODE_KERNEL[hash] = "sha256")
+#
+#sub-image signature property
+#
+#format: ";;" - for image signature node.
+#Both algorithm and key name needs to be provided.
+#(e.g. IMAGE_NODE_KERNEL[signature] = "sha256,rsa2048;kernel;"
+#
+#configuration signature property
+#
+#format: ";;" - for 
configuration signature properties algorithm,
+#key name and sub-image nodes needs to be provided.
+#(e.g. CONF_NODE_CONF1[signature] = 
"sha256,rsa2048;kernel;"kernel","fdt";")
+#
+#   ** Sub-Image and Configuration Nodes Flags
+#  See the code for supported flags.
+#
+#* FIT_IMAGES_NODE - contains a list of variables used to declare the 
sub-images nodes, separated by space.
+#(e.g. FIT_IMAGES_NODE = "IMAGE_NODE_KERNEL 
IMAGE_NODE_FDT")
+#
+#* FIT_CONFIGURATIONS_NODE - contains a list of variables used to declare 
the configuration nodes,
+#  separated by space. (e.g. FIT_CONFIGURATIONS_NODE = 
"CONF_NODE_CONF1")
+#** Flags
+#   - "default": used to configure the default configuration node.
+# (e.g. FIT_CONFIGURATIONS_NODE[default] = "conf@0")
+#
+# Example:
+# This is part of a linux_%.bbappend recipe.
+#
+# KERNEL_IMAGE_NODE[name] = "kernel"
+# KERNEL_IMAGE_NODE[description] = "${PF}"
+# KERNEL_IMAGE_NODE[data] = '/incbin/("./arch/${ARCH}/boot/zImage")'
+# KERNEL_IMAGE_NODE[type] = "kernel"
+# KERNEL_IMAGE_NODE[arch] = "${ARCH}"
+# KERNEL_IMAGE_NODE[os] = "linux"
+# KERNEL_IMAGE_NODE[compression] = "none"
+# KERNEL_IMAGE_NODE[load] = "${UBOOT_LOADADDRESS}"
+# KERNEL_IMAGE_NODE[entry] = "${UBOOT_ENTRYPOINT}"
+# KERNEL_IMAGE_NODE[hash] = "sha256"
+#
+# FDT_IMAGE_NODE[name] = "fdt"
+# FDT_IMAGE_NODE[description] = "FDT blob"
+# FDT_IMAGE_NODE[data] = '/incbin/("./arch/${ARCH}/boot/dts/am335x-bone.dtb")'
+# FDT_IMAGE_NODE[type] = "flat_dt"
+# FDT_IMAGE_NODE[arch] = "${ARCH}"
+# FDT_IMAGE_NODE[compression] = "none"
+# FDT_IMAGE_NODE[hash] = "sha256"
+#
+# CONF1_CONF_NODE[name] = "conf"
+# CONF1_CONF_NODE[description] = "Linux kernel and FDT blob"
+# CONF1_CONF_NODE[kernel] = "kernel"
+# CONF1_CONF_NODE[fdt] = "fdt"
+#
+# FIT_IMAGES_NODE = "KERNEL_IMAGE_NODE FDT_IMAGE_NODE"
+# FIT_CONFIGURATIONS_NODE = "CONF1_CONF_NODE"
+# FIT_CONFIGURATIONS_NODE[default] = "${@d.getVarFlag('CONF1_CONF_NODE', 
'name') or ""}"
+#
+
+DEPENDS += "\

[OE-core][PATCH v6 0/3] Add a new bbclass that abstracts the generation of FIT blobs

[Nandor Han]

Description
--
Add a new class and unittest for generating FIT blobs.


Testing
---

1. linux-yocto_5.4.bbappend was modified to have the following 
configuration:

```
inherit fit-image

KERNEL_IMAGE_NODE[name] = "kernel"
KERNEL_IMAGE_NODE[description] = "${PF}"
KERNEL_IMAGE_NODE[data] = '/incbin/("./arch/${ARCH}/boot/zImage")'
KERNEL_IMAGE_NODE[type] = "kernel"
KERNEL_IMAGE_NODE[arch] = "${ARCH}"
KERNEL_IMAGE_NODE[os] = "linux"
KERNEL_IMAGE_NODE[compression] = "none"
KERNEL_IMAGE_NODE[load] = "${UBOOT_LOADADDRESS}"
KERNEL_IMAGE_NODE[entry] = "${UBOOT_ENTRYPOINT}"
KERNEL_IMAGE_NODE[hash] = "sha256"

FDT_IMAGE_NODE[name] = "fdt"
FDT_IMAGE_NODE[description] = "FDT blob"
FDT_IMAGE_NODE[data] = '/incbin/("./arch/${ARCH}/boot/dts/am335x-bone.dtb")'
FDT_IMAGE_NODE[type] = "flat_dt"
FDT_IMAGE_NODE[arch] = "${ARCH}"
FDT_IMAGE_NODE[compression] = "none"
FDT_IMAGE_NODE[hash] = "sha256"

CONF1_CONF_NODE[name] = "conf"
CONF1_CONF_NODE[description] = "Linux kernel and FDT blob"
CONF1_CONF_NODE[kernel] = "kernel"
CONF1_CONF_NODE[fdt] = "fdt"

FIT_IMAGES_NODE = "KERNEL_IMAGE_NODE FDT_IMAGE_NODE"
FIT_CONFIGURATIONS_NODE = "CONF1_CONF_NODE"
FIT_CONFIGURATIONS_NODE[default] = "${@d.getVarFlag('CONF1_CONF_NODE', 
'name') or ""}"
```
2. Build the kernel: `bitbake virtual/kernel`
3. Verify that `image-fit.itb` is present in the build directory: PASS
4. Disassemble the image using the command: `dtc -I dtb -O dts 
image-fit.itb`
5. Verify that the FIT source contains the expected configuration: PASS
6. Run the unittest using the command: `oe-selftest --run-tests 
fit_image.FitImage`
7. Verify that is successfully: PASS
```
2020-05-26 16:54:34,996 - oe-selftest - INFO - SUMMARY:
2020-05-26 16:54:34,996 - oe-selftest - INFO - oe-selftest () - Ran 13
tests in 1956.639s
2020-05-26 16:54:34,997 - oe-selftest - INFO - oe-selftest - OK - All
required tests passed (successes=13, skipped=0, failures=0, errors=0)
``` 
 

Changes since v1:

- Change the format of short-log to ": "

Changes since v2:

- rename the file from `fit-image` to `fit_image` to successfully export 
the class functions.
- adding new sanity checks.
- add missing dependency.
- fix a variable reference in a debug log.

Changes since v3:

- unit-test added
- class updated to support also properties for U-Boot image

Changes since v4:

- remove a wrong patch

Changes since v5:

- something went wrong with generation of the patches. regenerate


Nandor Han (3):
  Add a recipe for `python3-fdt` package
  classes: Add a new bbclass that abstracts the generation of FIT blobs
  selftest: add a unit-test for fit-image bbclass

 .../fit-image-test/files/dt-fake.dtb  |   3 +
 .../fit-image-test/files/zImage-fake  |   3 +
 .../fit-image-test/fit-image-test.bb  |  17 +
 meta/classes/fit_image.bbclass| 387 ++
 meta/lib/oeqa/selftest/cases/fit_image.py | 212 ++
 .../python/python3-fdt_0.2.0.bb   |  14 +
 6 files changed, 636 insertions(+)
 create mode 100644 meta-selftest/recipes-test/fit-image-test/files/dt-fake.dtb
 create mode 100644 meta-selftest/recipes-test/fit-image-test/files/zImage-fake
 create mode 100644 meta-selftest/recipes-test/fit-image-test/fit-image-test.bb
 create mode 100644 meta/classes/fit_image.bbclass
 create mode 100644 meta/lib/oeqa/selftest/cases/fit_image.py
 create mode 100644 meta/recipes-devtools/python/python3-fdt_0.2.0.bb

-- 
2.24.1

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

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

[OE-core] ✗ patchtest: failure for Add a new bbclass that abstracts the generation of FIT blobs (rev6)

[Patchwork]

== Series Details ==

Series: Add a new bbclass that abstracts the generation of FIT blobs (rev6)
Revision: 6
URL   : https://patchwork.openembedded.org/series/23431/
State : failure

== Summary ==


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



* Issue Series does not apply on top of target branch 
[test_series_merge_on_head] 
  Suggested fixRebase your series on top of targeted branch
  Targeted branch  master (currently at 9106d0381d)



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

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

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

View/Reply Online (#138732): 
https://lists.openembedded.org/g/openembedded-core/message/138732
Mute This Topic: https://lists.openembedded.org/mt/74483439/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 3/3] selftest: add a unit-test for fit-image bbclass

[Nandor Han]

The unit-test will test the basic functionality of `fit-image.bbclass`.

Signed-off-by: Nandor Han 
---
 .../fit-image-test/files/dt-fake.dtb  |   3 +
 .../fit-image-test/files/zImage-fake  |   3 +
 .../fit-image-test/fit-image-test.bb  |  17 ++
 meta/lib/oeqa/selftest/cases/fit_image.py | 212 ++
 4 files changed, 235 insertions(+)
 create mode 100644 meta-selftest/recipes-test/fit-image-test/files/dt-fake.dtb
 create mode 100644 meta-selftest/recipes-test/fit-image-test/files/zImage-fake
 create mode 100644 meta-selftest/recipes-test/fit-image-test/fit-image-test.bb
 create mode 100644 meta/lib/oeqa/selftest/cases/fit_image.py

diff --git a/meta-selftest/recipes-test/fit-image-test/files/dt-fake.dtb 
b/meta-selftest/recipes-test/fit-image-test/files/dt-fake.dtb
new file mode 100644
index 00..7fa871ff00
--- /dev/null
+++ b/meta-selftest/recipes-test/fit-image-test/files/dt-fake.dtb
@@ -0,0 +1,3 @@
+Z�P�acn�ZWD1\�!΄�l�V
+t(��H��
��z��jb4.���݁�W;I�ƶb�e���Ñ�5�x�&�9,��g
+�;���!cV
diff --git a/meta-selftest/recipes-test/fit-image-test/files/zImage-fake 
b/meta-selftest/recipes-test/fit-image-test/files/zImage-fake
new file mode 100644
index 00..7fa871ff00
--- /dev/null
+++ b/meta-selftest/recipes-test/fit-image-test/files/zImage-fake
@@ -0,0 +1,3 @@
+Z�P�acn�ZWD1\�!΄�l�V
+t(��H��
��z��jb4.���݁�W;I�ƶb�e���Ñ�5�x�&�9,��g
+�;���!cV
diff --git a/meta-selftest/recipes-test/fit-image-test/fit-image-test.bb 
b/meta-selftest/recipes-test/fit-image-test/fit-image-test.bb
new file mode 100644
index 00..c7f325ec8a
--- /dev/null
+++ b/meta-selftest/recipes-test/fit-image-test/fit-image-test.bb
@@ -0,0 +1,17 @@
+SUMMARY = "Recipe for testing the fit_image bbclass"
+LICENSE = "MIT"
+LIC_FILES_CHKSUM = 
"file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
+
+DEPENDS += "\
+python3-fdt-native \
+"
+
+SRC_URI = "\
+file://zImage-fake \
+file://dt-fake.dtb \
+"
+
+inherit fit_image
+
+include test_recipe.inc
+
diff --git a/meta/lib/oeqa/selftest/cases/fit_image.py 
b/meta/lib/oeqa/selftest/cases/fit_image.py
new file mode 100644
index 00..866e48b20e
--- /dev/null
+++ b/meta/lib/oeqa/selftest/cases/fit_image.py
@@ -0,0 +1,212 @@
+import os
+from oeqa.selftest.case import OESelftestTestCase
+from oeqa.utils.commands import get_bb_var, bitbake, get_bb_vars
+
+class FitImage(OESelftestTestCase):
+
+@classmethod
+def setUpClass(cls):
+super(FitImage, cls).setUpClass()
+cls.recipe_name = 'fit-image-test'
+cls.build_dir = get_bb_var('B', cls.recipe_name)
+cls.fit_blob_path = os.path.join(cls.build_dir, 'image-fit.itb')
+
+bitbake('python3-fdt-native')
+fdt_sitepackage=get_bb_var("S", "python3-fdt-native")
+os.sys.path.append(fdt_sitepackage)
+import fdt
+
+bitbake('{recipe_name} -c 
cleanall'.format(recipe_name=cls.recipe_name))
+
+@classmethod
+def tearDownClass(cls):
+bitbake('{recipe_name} -c 
cleanall'.format(recipe_name=cls.recipe_name))
+super(FitImage, cls).tearDownClass()
+
+def _get_fit_configuration(self):
+configuration = """
+KERNEL_IMAGE_NODE[name] = "kernel"
+KERNEL_IMAGE_NODE[description] = "${PF}"
+KERNEL_IMAGE_NODE[data] = '/incbin/("${WORKDIR}/zImage-fake")'
+KERNEL_IMAGE_NODE[type] = "kernel"
+KERNEL_IMAGE_NODE[arch] = "arm"
+KERNEL_IMAGE_NODE[os] = "linux"
+KERNEL_IMAGE_NODE[compression] = "none"
+KERNEL_IMAGE_NODE[load] = "0x8400"
+KERNEL_IMAGE_NODE[entry] = "0x8400"
+KERNEL_IMAGE_NODE[hash] = "sha256"
+
+FDT_IMAGE_NODE[name] = "fdt"
+FDT_IMAGE_NODE[description] = "FDT blob"
+FDT_IMAGE_NODE[data] = '/incbin/("${WORKDIR}/dt-fake.dtb")'
+FDT_IMAGE_NODE[type] = "flat_dt"
+FDT_IMAGE_NODE[arch] = "arm"
+FDT_IMAGE_NODE[compression] = "none"
+FDT_IMAGE_NODE[hash] = "sha256"
+
+CONF1_CONF_NODE[name] = "conf"
+CONF1_CONF_NODE[description] = "Linux kernel and FDT blob"
+CONF1_CONF_NODE[kernel] = "kernel"
+CONF1_CONF_NODE[fdt] = "fdt"
+
+FIT_IMAGES_NODE = "KERNEL_IMAGE_NODE FDT_IMAGE_NODE"
+FIT_CONFIGURATIONS_NODE = "CONF1_CONF_NODE"
+FIT_CONFIGURATIONS_NODE[default] = "${@d.getVarFlag('CONF1_CONF_NODE', 'name') 
or ""}"
+"""
+return configuration
+
+def setUp(self):
+super(FitImage, self).setUp()
+self.write_recipeinc(self.recipe_name, self._get_fit_configuration())
+
+def tearDown(self):
+self.delete_recipeinc(self.recipe_name)
+super(FitImage, self).tearDown()
+
+def test_fit_source_is_generated_correctly(self):
+ret = bitbake("{recipe} -D -f -c 
generate_fit_image".format(recipe=self.recipe_name)).output
+self.logger.info('HN {log}'.format(log=ret))
+
+def test_fit_blob_is_generated_successfully(self):
+"""
+Summary: Able to apply a single patch to the Linux kernel source
+Expected:The README file should exist and the patch changes should 
be
+  

[OE-core] [PATCH v3] classes: Add a new bbclass that abstracts the generation of FIT blobs

[Nandor Han]

FIT format is very versatile allowing various combination of booting
sequences. In the same time different U-Boot boot stages can use FIT
blobs to pack various binaries (e.g. SPL supports reading U-Boot from a
FIT blob). Because of the allowed level of customization, the generation
of a FIT blob using a fixed image tree source, becomes challenging and
increase the level of complexity where different configurations and
combinations are needed.

This bbclass will know how to generate a FIT blob, leaving the mechanics
of the process (dependencies, task order...) to be handled by the users
of the bbclass. In the same time will allow to separate the knowledge of
the FIT format leaving the user code cleaner and more readable.

Signed-off-by: Nandor Han 
---

Notes:
Testing
---

1. linux-yocto_5.4.bbappend was modified to have the following 
configuration:

```
inherit fit-image

KERNEL_IMAGE_NODE[name] = "kernel"
KERNEL_IMAGE_NODE[description] = "${PF}"
KERNEL_IMAGE_NODE[data] = '/incbin/("./arch/${ARCH}/boot/zImage")'
KERNEL_IMAGE_NODE[type] = "kernel"
KERNEL_IMAGE_NODE[arch] = "${ARCH}"
KERNEL_IMAGE_NODE[os] = "linux"
KERNEL_IMAGE_NODE[compression] = "none"
KERNEL_IMAGE_NODE[load] = "${UBOOT_LOADADDRESS}"
KERNEL_IMAGE_NODE[entry] = "${UBOOT_ENTRYPOINT}"
KERNEL_IMAGE_NODE[hash] = "sha256"

FDT_IMAGE_NODE[name] = "fdt"
FDT_IMAGE_NODE[description] = "FDT blob"
FDT_IMAGE_NODE[data] = '/incbin/("./arch/${ARCH}/boot/dts/am335x-bone.dtb")'
FDT_IMAGE_NODE[type] = "flat_dt"
FDT_IMAGE_NODE[arch] = "${ARCH}"
FDT_IMAGE_NODE[compression] = "none"
FDT_IMAGE_NODE[hash] = "sha256"

CONF1_CONF_NODE[name] = "conf"
CONF1_CONF_NODE[description] = "Linux kernel and FDT blob"
CONF1_CONF_NODE[kernel] = "kernel"
CONF1_CONF_NODE[fdt] = "fdt"

FIT_IMAGES_NODE = "KERNEL_IMAGE_NODE FDT_IMAGE_NODE"
FIT_CONFIGURATIONS_NODE = "CONF1_CONF_NODE"
FIT_CONFIGURATIONS_NODE[default] = "${@d.getVarFlag('CONF1_CONF_NODE', 
'name') or ""}"
```
2. Build the kernel: `bitbake virtual/kernel`
3. Verify that `image-fit.itb` is present in the build directory: PASS
4. Disassemble the image using the command: `dtc -I dtb -O dts 
image-fit.itb`
5. Verify that the FIT source contains the expected configuration: PASS

Changes since v1:

- Change the format of short-log to ": "

Changes since v2:

- rename the file from `fit-image` to `fit_image` to
successfully export the class functions.
- adding new sanity checks.
- add missing dependency.
- fix a variable reference in a debug log.

 meta/classes/fit_image.bbclass | 382 +
 1 file changed, 382 insertions(+)
 create mode 100644 meta/classes/fit_image.bbclass

diff --git a/meta/classes/fit_image.bbclass b/meta/classes/fit_image.bbclass
new file mode 100644
index 00..87d92db122
--- /dev/null
+++ b/meta/classes/fit_image.bbclass
@@ -0,0 +1,382 @@
+#
+# The class will facilitate the generation of FIT blobs.
+#
+# Glossary
+#FIT - Flattened uImage Tree
+#
+# Requirements:
+#
+#* The user need to specify the image content using the format specified 
in the "FIT Image API" section.
+#
+# FIT Image API
+#
+# The bbclass is using variable and variable flags to declare the FIT image 
content.
+#
+#* Sub-Images and Configuration Nodes
+#
+#   ** A sub-image node content is declared using the format 
`VAR_NODE[] = `.
+# * VAR_NODE - freely selected name of the variable representing a 
node.
+# *  - a sub-image property (e.g. description, type...).
+# *  - the property value.
+# Depending of the property the value can support different 
formats.
+#   ** Property Values Formats
+#
+#string property
+#---
+#format: "" - in case the property expects a text.
+#(e.g. IMAGE_NODE_KERNEL[type] = "kernel")
+#
+#address property
+#
+#format: "" - in case the property expects an address.
+#(e.g. IMAGE_NODE_KERNEL[entry] = "0xABCDABCD")
+#
+#hash property
+#-
+#format: "" - for hash property the hash type needs to 
be specified.
+#(e.g. IMAGE_NODE_KERNEL[hash] = "sha256")
+#
+#sub-image signature property
+#
+#format: ";;" - for image signature node.
+#Both algorithm and key name needs to be provided.
+#(e.g. IMAGE_NODE_KERNEL[signature] = "sha256,rsa2048;kernel;"
+#
+#configuration signature property
+#
+#format: ";;" - for 
configuration signature properties algorithm,
+#key name and sub-image nodes needs to be provided.
+#(e.g. 

[OE-core][PATCH v4 2/3] classes: Add a new bbclass that abstracts the generation of FIT blobs

[Nandor Han]

FIT format is very versatile allowing various combination of booting
sequences. In the same time different U-Boot boot stages can use FIT
blobs to pack various binaries (e.g. SPL supports reading U-Boot from a
FIT blob). Because of the allowed level of customization, the generation
of a FIT blob using a fixed image tree source, becomes challenging and
increase the level of complexity where different configurations and
combinations are needed.

This bbclass will know how to generate a FIT blob, leaving the mechanics
of the process (dependencies, task order...) to be handled by the users
of the bbclass. In the same time will allow to separate the knowledge of
the FIT format leaving the user code cleaner and more readable.

Signed-off-by: Nandor Han 
---
 meta/classes/fit_image.bbclass | 387 +
 1 file changed, 387 insertions(+)
 create mode 100644 meta/classes/fit_image.bbclass

diff --git a/meta/classes/fit_image.bbclass b/meta/classes/fit_image.bbclass
new file mode 100644
index 00..2d1451020c
--- /dev/null
+++ b/meta/classes/fit_image.bbclass
@@ -0,0 +1,387 @@
+#
+# The class will facilitate the generation of FIT blobs.
+#
+# Glossary
+#FIT - Flattened uImage Tree
+#
+# Requirements:
+#
+#* The user need to specify the image content using the format specified 
in the "FIT Image API" section.
+#
+# FIT Image API
+#
+# The bbclass is using variable and variable flags to declare the FIT image 
content.
+#
+#* Sub-Images and Configuration Nodes
+#
+#   ** A sub-image node content is declared using the format 
`VAR_NODE[] = `.
+# * VAR_NODE - freely selected name of the variable representing a 
node.
+# *  - a sub-image property (e.g. description, type...).
+# *  - the property value.
+# Depending of the property the value can support different 
formats.
+#   ** Property Values Formats
+#
+#string property
+#---
+#format: "" - in case the property expects a text.
+#(e.g. IMAGE_NODE_KERNEL[type] = "kernel")
+#
+#address property
+#
+#format: "" - in case the property expects an address.
+#(e.g. IMAGE_NODE_KERNEL[entry] = "0xABCDABCD")
+#
+#hash property
+#-
+#format: "" - for hash property the hash type needs to 
be specified.
+#(e.g. IMAGE_NODE_KERNEL[hash] = "sha256")
+#
+#sub-image signature property
+#
+#format: ";;" - for image signature node.
+#Both algorithm and key name needs to be provided.
+#(e.g. IMAGE_NODE_KERNEL[signature] = "sha256,rsa2048;kernel;"
+#
+#configuration signature property
+#
+#format: ";;" - for 
configuration signature properties algorithm,
+#key name and sub-image nodes needs to be provided.
+#(e.g. CONF_NODE_CONF1[signature] = 
"sha256,rsa2048;kernel;"kernel","fdt";")
+#
+#   ** Sub-Image and Configuration Nodes Flags
+#  See the code for supported flags.
+#
+#* FIT_IMAGES_NODE - contains a list of variables used to declare the 
sub-images nodes, separated by space.
+#(e.g. FIT_IMAGES_NODE = "IMAGE_NODE_KERNEL 
IMAGE_NODE_FDT")
+#
+#* FIT_CONFIGURATIONS_NODE - contains a list of variables used to declare 
the configuration nodes,
+#  separated by space. (e.g. FIT_CONFIGURATIONS_NODE = 
"CONF_NODE_CONF1")
+#** Flags
+#   - "default": used to configure the default configuration node.
+# (e.g. FIT_CONFIGURATIONS_NODE[default] = "conf@0")
+#
+# Example:
+# This is part of a linux_%.bbappend recipe.
+#
+# KERNEL_IMAGE_NODE[name] = "kernel"
+# KERNEL_IMAGE_NODE[description] = "${PF}"
+# KERNEL_IMAGE_NODE[data] = '/incbin/("./arch/${ARCH}/boot/zImage")'
+# KERNEL_IMAGE_NODE[type] = "kernel"
+# KERNEL_IMAGE_NODE[arch] = "${ARCH}"
+# KERNEL_IMAGE_NODE[os] = "linux"
+# KERNEL_IMAGE_NODE[compression] = "none"
+# KERNEL_IMAGE_NODE[load] = "${UBOOT_LOADADDRESS}"
+# KERNEL_IMAGE_NODE[entry] = "${UBOOT_ENTRYPOINT}"
+# KERNEL_IMAGE_NODE[hash] = "sha256"
+#
+# FDT_IMAGE_NODE[name] = "fdt"
+# FDT_IMAGE_NODE[description] = "FDT blob"
+# FDT_IMAGE_NODE[data] = '/incbin/("./arch/${ARCH}/boot/dts/am335x-bone.dtb")'
+# FDT_IMAGE_NODE[type] = "flat_dt"
+# FDT_IMAGE_NODE[arch] = "${ARCH}"
+# FDT_IMAGE_NODE[compression] = "none"
+# FDT_IMAGE_NODE[hash] = "sha256"
+#
+# CONF1_CONF_NODE[name] = "conf"
+# CONF1_CONF_NODE[description] = "Linux kernel and FDT blob"
+# CONF1_CONF_NODE[kernel] = "kernel"
+# CONF1_CONF_NODE[fdt] = "fdt"
+#
+# FIT_IMAGES_NODE = "KERNEL_IMAGE_NODE FDT_IMAGE_NODE"
+# FIT_CONFIGURATIONS_NODE = "CONF1_CONF_NODE"
+# FIT_CONFIGURATIONS_NODE[default] = "${@d.getVarFlag('CONF1_CONF_NODE', 
'name') or ""}"
+#
+
+DEPENDS += "\

[OE-core][PATCH v4 0/3] Add a new bbclass that abstracts the generation of FIT blobs

[Nandor Han]

Description
--
Add a new class and unittest for generating FIT blobs.


Testing
---

1. linux-yocto_5.4.bbappend was modified to have the following 
configuration:

```
inherit fit-image

KERNEL_IMAGE_NODE[name] = "kernel"
KERNEL_IMAGE_NODE[description] = "${PF}"
KERNEL_IMAGE_NODE[data] = '/incbin/("./arch/${ARCH}/boot/zImage")'
KERNEL_IMAGE_NODE[type] = "kernel"
KERNEL_IMAGE_NODE[arch] = "${ARCH}"
KERNEL_IMAGE_NODE[os] = "linux"
KERNEL_IMAGE_NODE[compression] = "none"
KERNEL_IMAGE_NODE[load] = "${UBOOT_LOADADDRESS}"
KERNEL_IMAGE_NODE[entry] = "${UBOOT_ENTRYPOINT}"
KERNEL_IMAGE_NODE[hash] = "sha256"

FDT_IMAGE_NODE[name] = "fdt"
FDT_IMAGE_NODE[description] = "FDT blob"
FDT_IMAGE_NODE[data] = '/incbin/("./arch/${ARCH}/boot/dts/am335x-bone.dtb")'
FDT_IMAGE_NODE[type] = "flat_dt"
FDT_IMAGE_NODE[arch] = "${ARCH}"
FDT_IMAGE_NODE[compression] = "none"
FDT_IMAGE_NODE[hash] = "sha256"

CONF1_CONF_NODE[name] = "conf"
CONF1_CONF_NODE[description] = "Linux kernel and FDT blob"
CONF1_CONF_NODE[kernel] = "kernel"
CONF1_CONF_NODE[fdt] = "fdt"

FIT_IMAGES_NODE = "KERNEL_IMAGE_NODE FDT_IMAGE_NODE"
FIT_CONFIGURATIONS_NODE = "CONF1_CONF_NODE"
FIT_CONFIGURATIONS_NODE[default] = "${@d.getVarFlag('CONF1_CONF_NODE', 
'name') or ""}"
```
2. Build the kernel: `bitbake virtual/kernel`
3. Verify that `image-fit.itb` is present in the build directory: PASS
4. Disassemble the image using the command: `dtc -I dtb -O dts 
image-fit.itb`
5. Verify that the FIT source contains the expected configuration: PASS
6. Run the unittest using the command: `oe-selftest --run-tests 
fit_image.FitImage`
7. Verify that is successfully: PASS
```
2020-05-26 16:54:34,996 - oe-selftest - INFO - SUMMARY:
2020-05-26 16:54:34,996 - oe-selftest - INFO - oe-selftest () - Ran 13
tests in 1956.639s
2020-05-26 16:54:34,997 - oe-selftest - INFO - oe-selftest - OK - All
required tests passed (successes=13, skipped=0, failures=0, errors=0)
``` 
 

Changes since v1:

- Change the format of short-log to ": "

Changes since v2:

- rename the file from `fit-image` to `fit_image` to successfully export 
the class functions.
- adding new sanity checks.
- add missing dependency.
- fix a variable reference in a debug log.

Changes since v3:

- unit-test added
- class updated to support also properties for U-Boot image


Nandor Han (3):
  Add a recipe for `python3-fdt` package
  classes: Add a new bbclass that abstracts the generation of FIT blobs
  selftest: add a unit-test for fit-image bbclass

 .../fit-image-test/files/dt-fake.dtb  |   3 +
 .../fit-image-test/files/zImage-fake  |   3 +
 .../fit-image-test/fit-image-test.bb  |  17 +
 meta/classes/fit_image.bbclass| 387 ++
 meta/lib/oeqa/selftest/cases/fit_image.py | 212 ++
 .../python/python3-fdt_0.2.0.bb   |  14 +
 6 files changed, 636 insertions(+)
 create mode 100644 meta-selftest/recipes-test/fit-image-test/files/dt-fake.dtb
 create mode 100644 meta-selftest/recipes-test/fit-image-test/files/zImage-fake
 create mode 100644 meta-selftest/recipes-test/fit-image-test/fit-image-test.bb
 create mode 100644 meta/classes/fit_image.bbclass
 create mode 100644 meta/lib/oeqa/selftest/cases/fit_image.py
 create mode 100644 meta/recipes-devtools/python/python3-fdt_0.2.0.bb

-- 
2.24.1

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

View/Reply Online (#138727): 
https://lists.openembedded.org/g/openembedded-core/message/138727
Mute This Topic: https://lists.openembedded.org/mt/74483347/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/3] Add a recipe for `python3-fdt` package

[Nandor Han]

The package `python3-fdt` is used for parsing and generating DTBs.

Signed-off-by: Nandor Han 
---
 meta/recipes-devtools/python/python3-fdt_0.2.0.bb | 14 ++
 1 file changed, 14 insertions(+)
 create mode 100644 meta/recipes-devtools/python/python3-fdt_0.2.0.bb

diff --git a/meta/recipes-devtools/python/python3-fdt_0.2.0.bb 
b/meta/recipes-devtools/python/python3-fdt_0.2.0.bb
new file mode 100644
index 00..040ceba980
--- /dev/null
+++ b/meta/recipes-devtools/python/python3-fdt_0.2.0.bb
@@ -0,0 +1,14 @@
+SUMMARY = "Library for manipulation of Device Tree Data"
+HOMEPAGE = "https://github.com/molejar/pyFDT;
+SECTION = "devel/python"
+LICENSE = "Apache-2.0"
+LIC_FILES_CHKSUM = 
"file://PKG-INFO;beginline=8;endline=8;md5=9a6ea5b6c346a830f54cc95f6a2a9245"
+
+SRC_URI[md5sum] = "a91daa36b3216f54feeac74ea8e5a475"
+SRC_URI[sha256sum] = 
"b675139346946115513e27b5eed9aa882628ab74ed500bd5e25e122ee0afa2f6"
+
+PYPI_PACKAGE = "fdt"
+
+inherit pypi setuptools3
+
+BBCLASSEXTEND = "native"
-- 
2.24.1

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

View/Reply Online (#138728): 
https://lists.openembedded.org/g/openembedded-core/message/138728
Mute This Topic: https://lists.openembedded.org/mt/74483348/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] bzip2: Add test suite for bzip2

[Paul Barker]

I'm looking at this after our chat on the call today, picked on this
email in particular just because I needed one to reply to

On Wed, 20 May 2020 at 21:59, Randy MacLeod  wrote:
>
> On 2020-05-19 8:06 p.m., Peter Kjellerstedt wrote:
> >> -Original Message-
> >> From: Randy MacLeod 
> >> Sent: den 19 maj 2020 23:45
> >> To: Peter Kjellerstedt ; Rahul Kumar
> >> 
> >> Cc: Alexander Kanavin ; Richard Purdie
> >> ; OE-core  >> c...@lists.openembedded.org>; Trevor Gamblin
> >> 
> >> Subject: Re: [OE-core] [PATCH v2] bzip2: Add test suite for bzip2
> >>
> >> On 2020-05-19 12:29 p.m., Peter Kjellerstedt wrote:
> >>> The jzlib license is a three clause BSD license, and so is the
> >>> go/LICENSE, so you should be able to set LICENSE as:
> >>>
> >>> LICENSE = "bzip2-1.0.6 & GPLv3+ & Apache-2.0 & MS-PL & BSD-3-Clause & 
> >>> Zlib"
> >>
> >> Peter,
> >>
> >> I respectfully disagree.
> >>
> >> The only source that is _executed_ in normal use by bzip2-test is
> >> the run-tests.sh script that is licensed as GPLv3+
> >
> > Well, I am definitely not a lawyer either,
>
> Phew! :)
>
> > but I am pretty sure that
> > whether something that is distributed under a certain license is
> > executed or not is irrelevant (unless of course the license covers
> > execution of the code).
>
> There's a difference between a legal report and the Yocto LICENSE tag.
> The Yocto tag is meant to be an over-all/community acknowledged license
> for the _code_ in the package that ends up as executable / script on
> the target. We should probably document this in greater detail, perhaps
> in:
>
> https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#var-LICENSE
>
> A more comprehensive analysis usually includes a file by file
> IP report often accompanied by a summary generated by an IP expert.
>
> >
> >> The other files, although they came from source packages,
> >> are *only* used as  test data. The source code has been completely
> >> stripped out, hasn't it?
> >
> > Given that they were originally distributed in an archive together
> > with a LICENSE/COPYING/similar file covering the entire archive,
> > those files are still covered by that license even if they are not
> > source files per se.
>
>
> Licenses describe the terms that apply to items that are covered
> under copyright. Data generally can not be copyrighted.
>
>  From my IP contact:
>
> ---
>
> In order for something to be copyrightable three requirements
> must be satisfied:
>
>   1. The work represents a creative form of expression
>  (basic facts do not represent a creative form of expression)
>
>   2. The work is original (novel) – not copied from someone else.
>  Two different people could come up with similar creative forms
>  of expression. They just can’t copy from someone else.
>
>   3. It must be put in tangible form (e.g., written, digital, …).
>  Someone can’t just claim it resides inside their head.
>
>
>
> Data as a general is not copyrightable because it fails number 1.
> However if someone can argue that a certain compilation of data
> represents some form of creative expression, they might have a case.
> This is discussed in the first two paragraphs here:
>
> https://libguides.library.kent.edu/data-management/copyright
>
>
> Data can be protected under patent or trade secret law but different
> requirements apply and a different license would need to be created.
> Open Source licenses are largely copyright licenses. Although sometimes
> they include patent terms, they are generally not considered patent
> licenses.
>
> ---
>
>
> Most of the files here are clearly just data and
> are therefore neither subject to copyright nor governed by
> typical open source licenses.
>
> Some possible exceptions are:
>
> dotnetzip/dancing-color.ps.bz2
>- This could be considered as software since that's what a PostScript
>  file is. In fact it's the 'Dancing links" paper by Donald Knuth:
>  https://www-cs-faculty.stanford.edu/~knuth/preprints.html
>  Copyright is not asserted but is of course implied for such works.
>  No licensing terms are declared.
>
> go/compress/Isaac.Newton-Opticks.txt.bz2
>- out of copyright since unfortunately the author died long ago :-/
>  It seems that the people who prepared this document:
>"Produced by Suzanne Lybarger, steve harris, Josephine
>Paolucci and the Online Distributed Proofreading Team at
>http://www.pgdp.net. "
>  are interested in:
> "...dedicated to the preservation of written works
>  that are in the Public Domain ..."
>
> https://www.pgdp.net/wiki/DP_Official_Documentation:General/Distributed_Proofreaders_Mission_Statement
>
>
>
> It seems that the README/COPYING/LICENSE.txt/... files
> were left in the repo by people who while well intentioned,
> were misguided. We could try to fix that error upstream.
>
>
> >
> >> If, instead of compressed data,
> >> someone were to give me an image file covered by a 

Re: [OE-core] [PATCH] package_rpm.bbclass: respect package overrides for the main package

[Steve Sakoman]

Does this patch (and the follow-on series) make sense for inclusion in dunfell?

Steve

On Sun, May 24, 2020 at 9:46 PM Michael Ho  wrote:
>
> From: Michael Ho 
>
> Apply ${PN} to OVERRIDES when determining the base package spec variables.
> Without this, there is a mismatch in behaviour where overrides for the base
> package have no effect while overrides for subpackages do. The subpackages
> should not be affected by this override as they apply their own package
> overrides and will by default fetch the base variables and apply them in
> the spec file.
>
> This makes the behaviour for package overrides match the implementation
> in package_deb.bbclass and package_ipk.bbclass.
>
> Signed-off-by: Michael Ho 
> ---
>  meta/classes/package_rpm.bbclass | 22 --
>  1 file changed, 12 insertions(+), 10 deletions(-)
>
> diff --git a/meta/classes/package_rpm.bbclass 
> b/meta/classes/package_rpm.bbclass
> index 9a4be2e..519c22b 100644
> --- a/meta/classes/package_rpm.bbclass
> +++ b/meta/classes/package_rpm.bbclass
> @@ -286,16 +286,18 @@ python write_specfile () {
>
>  # Construct the SPEC file...
>  srcname= d.getVar('PN')
> -srcsummary = (d.getVar('SUMMARY') or d.getVar('DESCRIPTION') or ".")
> -srcversion = d.getVar('PKGV').replace('-', '+')
> -srcrelease = d.getVar('PKGR')
> -srcepoch   = (d.getVar('PKGE') or "")
> -srclicense = d.getVar('LICENSE')
> -srcsection = d.getVar('SECTION')
> -srcmaintainer  = d.getVar('MAINTAINER')
> -srchomepage= d.getVar('HOMEPAGE')
> -srcdescription = d.getVar('DESCRIPTION') or "."
> -srccustomtagschunk = get_package_additional_metadata("rpm", d)
> +localdata = bb.data.createCopy(d)
> +localdata.setVar('OVERRIDES', d.getVar("OVERRIDES", False) + ":" + 
> srcname)
> +srcsummary = (localdata.getVar('SUMMARY') or 
> localdata.getVar('DESCRIPTION') or ".")
> +srcversion = localdata.getVar('PKGV').replace('-', '+')
> +srcrelease = localdata.getVar('PKGR')
> +srcepoch   = (localdata.getVar('PKGE') or "")
> +srclicense = localdata.getVar('LICENSE')
> +srcsection = localdata.getVar('SECTION')
> +srcmaintainer  = localdata.getVar('MAINTAINER')
> +srchomepage= localdata.getVar('HOMEPAGE')
> +srcdescription = localdata.getVar('DESCRIPTION') or "."
> +srccustomtagschunk = get_package_additional_metadata("rpm", localdata)
>
>  srcdepends = d.getVar('DEPENDS')
>  srcrdepends= []
> --
> 2.7.4
>
> 
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138725): 
https://lists.openembedded.org/g/openembedded-core/message/138725
Mute This Topic: https://lists.openembedded.org/mt/74452506/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] multilib/recipes: Use new RecipePostKeyExpansion event

[Jeremy Puhlman]

For master I this looks great. We have been bitten in various edge cases 
by this in the past. You mentioned
pushing it on to dunfell. I a little leary at this point, but if we are 
going to its kind of now or never. My feeling
is there will be some fallout(which is perfectly fine on master, a 
little questionable on a stable release) in other

layers.

On 5/21/2020 4:09 AM, Richard Purdie wrote:

There are issues with multilib due to the ordering of events where some
functions see the remapped multilib dependencies and some do not. A significant
problem is that the multilib class needs to make some changes before key 
expansion
and some afterwards but by using existing event handlers, some code sees things
in a partially translated state, leading to bugs.

This patch changes things to use a new event handler from bitbake which makes 
the
ordering of the changes explcit.

The challenge in doing this is that it breaks some existing anonymous python and
dyanmic assignments. In some cases these used to be translated and no longer 
are,
meaning MLPREFIX has to be added. In some cases these are now translated and the
MLPREFIX can be removed.

This change does now make it very clear when MLPREFIX is required and when it is
not, its just the migration path which is harder. The patch changes the small 
number
of cases where fixes are needed.

This patch also reverts:
base: Revert 'base.bbclass: considering multilib when setting LICENSE_EXCLUSION'

This reverts 6597130256a1609c3e05ec5891aceaf549c37985 as the changes
to multilib datastore handling mean its no longer necessary.

Signed-off-by: Richard Purdie 
---
  meta/classes/base.bbclass |  3 +-
  meta/classes/fontcache.bbclass|  2 +-
  meta/classes/multilib.bbclass | 28 ---
  meta/lib/oe/classextend.py| 35 +--
  meta/recipes-core/glibc/glibc-package.inc |  2 +-
  meta/recipes-core/psplash/psplash_git.bb  |  6 ++--
  meta/recipes-devtools/perl/perl_5.30.2.bb |  2 +-
  meta/recipes-devtools/python/python3_3.8.2.bb | 14 
  meta/recipes-graphics/mesa/mesa.inc   | 10 +++---
  .../alsa/alsa-plugins_1.2.1.bb|  6 ++--
  meta/recipes-support/boost/boost.inc  | 10 --
  11 files changed, 85 insertions(+), 33 deletions(-)

diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index 7aa2e144eb7..4c681cc870d 100644
--- a/meta/classes/base.bbclass
+++ b/meta/classes/base.bbclass
@@ -570,8 +570,7 @@ python () {
  if unskipped_pkgs:
  for pkg in skipped_pkgs:
  bb.debug(1, "Skipping the package %s at do_rootfs because 
of incompatible license(s): %s" % (pkg, ' '.join(skipped_pkgs[pkg])))
-mlprefix = d.getVar('MLPREFIX')
-d.setVar('LICENSE_EXCLUSION-' + mlprefix + pkg, ' 
'.join(skipped_pkgs[pkg]))
+d.setVar('LICENSE_EXCLUSION-' + pkg, ' 
'.join(skipped_pkgs[pkg]))
  for pkg in unskipped_pkgs:
  bb.debug(1, "Including the package %s" % pkg)
  else:
diff --git a/meta/classes/fontcache.bbclass b/meta/classes/fontcache.bbclass
index 97e7f17f00e..624a420a0de 100644
--- a/meta/classes/fontcache.bbclass
+++ b/meta/classes/fontcache.bbclass
@@ -7,7 +7,7 @@ PACKAGE_WRITE_DEPS += "qemu-native"
  inherit qemu
  
  FONT_PACKAGES ??= "${PN}"

-FONT_EXTRA_RDEPENDS ?= "fontconfig-utils"
+FONT_EXTRA_RDEPENDS ?= "${MLPREFIX}fontconfig-utils"
  FONTCONFIG_CACHE_DIR ?= "${localstatedir}/cache/fontconfig"
  FONTCONFIG_CACHE_PARAMS ?= "-v"
  # You can change this to e.g. FC_DEBUG=16 to debug fc-cache issues,
diff --git a/meta/classes/multilib.bbclass b/meta/classes/multilib.bbclass
index ee677da1e20..9f726e45371 100644
--- a/meta/classes/multilib.bbclass
+++ b/meta/classes/multilib.bbclass
@@ -91,13 +91,12 @@ addhandler multilib_virtclass_handler
  multilib_virtclass_handler[eventmask] = "bb.event.RecipePreFinalise"
  
  python __anonymous () {

-variant = d.getVar("BBEXTENDVARIANT")
-
-import oe.classextend
+if bb.data.inherits_class('image', d):
+variant = d.getVar("BBEXTENDVARIANT")
+import oe.classextend
  
-clsextend = oe.classextend.ClassExtender(variant, d)

+clsextend = oe.classextend.ClassExtender(variant, d)
  
-if bb.data.inherits_class('image', d):

  clsextend.map_depends_variable("PACKAGE_INSTALL")
  clsextend.map_depends_variable("LINGUAS_INSTALL")
  clsextend.map_depends_variable("RDEPENDS")
@@ -109,6 +108,22 @@ python __anonymous () {
  bb.build.deltask('do_populate_sdk', d)
  bb.build.deltask('do_populate_sdk_ext', d)
  return
+}
+
+python multilib_virtclass_handler_postkeyexp () {
+cls = d.getVar("BBEXTENDCURR")
+variant = d.getVar("BBEXTENDVARIANT")
+if cls != "multilib" or not variant:
+return
+
+variant = 

[OE-core] Yocto Project Status WW20'21

[Stephen Jolley]

Current Dev Position: YP 3.2 M1

Next Deadline: YP 3.2 M1 build date 2020/6/16

 

Next Team Meetings:

*   Bug Triage meeting Thursday May 28th at 7:30am PDT (
 https://zoom.us/j/454367603)
*   Monthly Project Meeting Tuesday June 2nd at 8am PDT (
 https://zoom.us/j/990892712)
*   Weekly Engineering Sync Tuesday May 26th  at 8am PDT (
 https://zoom.us/j/990892712)
*   Twitch -  See http://www.twitch.tv/letoatreidesthe2nd

 

Key Status/Updates:

*   YP 3.0.3 is in QA result review, there were ptest regressions but
these look intermittent in nature and hence unlikely to block release
*   YP 2.7.4 should be built this week
*   One of the autobuilder issues where workers were hanging was tracked
down to a NFS incompatibility between the NAS and new kernel versions. The
NAS was upgraded to resolve this at a cost of some short notice downtime.
*   There remain a large number of bugs that we'd ideally like to fix in
3.2 M1 (or M2) but they are "unassigned", there is nobody to work on them.
If anyone has time, looking at these bugs would be a great way to help us.
See:

https://wiki.yoctoproject.org/wiki/Bug_Triage#Medium.2B_3.2_Unassigned_Enhan
cements.2FBugs
*   There continue to be other intermittent autobuilder issues in both
master and dunfell which we're trying to track down. These ones look related
to the code rather than infrastructure.
*   The AUH is now implemented as an autobuilder job and will be run
from there in future.

 

YP 3.2 Milestone Dates:

*   YP 3.2 M1 build date 2020/6/16
*   YP 3.2 M1 Release date 2020/6/26
*   YP 3.2 M2 build date 2020/7/27
*   YP 3.2 M2 Release date 2020/8/7
*   YP 3.2 M3 build date 2020/8/31
*   YP 3.2 M3 Release date 2020/9/11
*   YP 3.2 M4 build date 2020/10/5
*   YP 3.2 M4 Release date 2020/10/30

 

Planned upcoming dot releases:

*   YP 3.0.3 is out of QA and the results are being reviewed.
*   YP 3.0.3 release date 2020/5/15
*   YP 2.7.4 build date 2020/5/18
*   YP 2.7.4 release date 2020/5/29
*   YP 3.1.1 build date 2020/6/29
*   YP 3.1.1 release date 2020/7/10
*   YP 3.0.4 build date 2020/8/10
*   YP 3.0.4 release date 2020/8/21
*   YP 3.1.2 build date 2020/9/14
*   YP 3.1.2 release date 2020/9/25

 

Tracking Metrics:

*   WDD 2577 (last week 2577) (

https://wiki.yoctoproject.org/charts/combo.html)
*   Poky Patch Metrics  

*   Total patches found: 1351 (last week 1352)
*   Patches in the Pending State: 535 (40%) [last week 537 (40%)]

 

The Yocto Project's technical governance is through its Technical Steering
Committee, more information is available at:

 
https://wiki.yoctoproject.org/wiki/TSC

 

The Status reports are now stored on the wiki at:

https://wiki.yoctoproject.org/wiki/Weekly_Status

 

[If anyone has suggestions for other information you'd like to see on this
weekly status update, let us know!]

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

*Cell:(208) 244-4460

* Email:  sjolley.yp...@gmail.com
 

 

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

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

Re: [OE-core][dunfell 14/17] newlib: Upgrade to latest yearly release 3.3.0

[Steve Sakoman]

On Mon, May 25, 2020 at 10:31 PM Paul Barker  wrote:
>
> On Mon, 25 May 2020 at 23:37, Steve Sakoman  wrote:
> >
> > From: Alejandro Hernandez 
> >
> > Upgrade to the latest snapshot, also drop md5sum while were at it.
> >
> > (From OE-Core rev: d73aa359e42e707dbc7cfa29c55a2fc8e6bb938a)
> >
> > Signed-off-by: Alejandro Hernandez Samaniego 
> > Signed-off-by: Alejandro Hernandez Samaniego 
> > Signed-off-by: Richard Purdie 
> > Signed-off-by: Steve Sakoman 
> > ---
> >  .../newlib/{libgloss_3.2.0.bb => libgloss_3.3.0.bb}| 0
> >  meta/recipes-core/newlib/newlib.inc| 3 +--
> >  meta/recipes-core/newlib/{newlib_3.2.0.bb => newlib_3.3.0.bb}  | 0
> >  3 files changed, 1 insertion(+), 2 deletions(-)
> >  rename meta/recipes-core/newlib/{libgloss_3.2.0.bb => libgloss_3.3.0.bb} 
> > (100%)
> >  rename meta/recipes-core/newlib/{newlib_3.2.0.bb => newlib_3.3.0.bb} (100%)
> >
> > diff --git a/meta/recipes-core/newlib/libgloss_3.2.0.bb 
> > b/meta/recipes-core/newlib/libgloss_3.3.0.bb
> > similarity index 100%
> > rename from meta/recipes-core/newlib/libgloss_3.2.0.bb
> > rename to meta/recipes-core/newlib/libgloss_3.3.0.bb
> > diff --git a/meta/recipes-core/newlib/newlib.inc 
> > b/meta/recipes-core/newlib/newlib.inc
> > index 5edea8aba1..96e230f985 100644
> > --- a/meta/recipes-core/newlib/newlib.inc
> > +++ b/meta/recipes-core/newlib/newlib.inc
> > @@ -16,8 +16,7 @@ LIC_FILES_CHKSUM = " \
> > "
> >
> >  SRC_URI = "https://sourceware.org/pub/newlib/newlib-${PV}.tar.gz;
> > -SRC_URI[md5sum] = "afb3a01c8c82b6717ea55659a4de30ec"
> > -SRC_URI[sha256sum] = 
> > "f7b2322964a1e3b37bec0768da20f50dfb62247d729110974dd95756a53bb6d4"
> > +SRC_URI[sha256sum] = 
> > "58dd9e3eaedf519360d92d84205c3deef0b3fc286685d1c562e245914ef72c66"
> >
> >  INHIBIT_DEFAULT_DEPS = "1"
> >  DEPENDS = "virtual/${TARGET_PREFIX}gcc"
> > diff --git a/meta/recipes-core/newlib/newlib_3.2.0.bb 
> > b/meta/recipes-core/newlib/newlib_3.3.0.bb
> > similarity index 100%
> > rename from meta/recipes-core/newlib/newlib_3.2.0.bb
> > rename to meta/recipes-core/newlib/newlib_3.3.0.bb
> > --
> > 2.17.1
>
> NACK: https://lists.openembedded.org/g/openembedded-core/message/137847

Thanks Paul!  I agree of course ;-)

I'll drop this patch in my final merge request.

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

View/Reply Online (#138722): 
https://lists.openembedded.org/g/openembedded-core/message/138722
Mute This Topic: https://lists.openembedded.org/mt/74467818/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 6/6] perf: drop 'include' copy

[Bruce Ashfield]

On Tue, May 26, 2020 at 1:44 AM Andrey Zhizhikin  wrote:
>
> On Mon, Oct 21, 2019 at 10:58 PM Bruce Ashfield
>  wrote:
> >
> > On Mon, Oct 21, 2019 at 4:24 PM Martin Jansa  wrote:
> > >
> > > On Mon, Oct 21, 2019 at 04:16:18PM -0400, bruce.ashfi...@gmail.com wrote:
> > > > From: Bruce Ashfield 
> > > >
> > > > The copy of the kernel's top level include directory is not
> > > > required to build perf. We have both the linux-libc-headers and
> > > > perf's captured/copied headers for what it requires.
> > > >
> > > > The copy of the kernel's headers is leading us to multiple smaller
> > > > fixes to ensure that the various .h files are in sync. We can
> > > > remove the copy and all of the sync checks, and perf still builds
> > > > and executes correctly.
> > >
> > > Maybe reorder this before "[OE-core] [PATCH 3/6] perf: fix v5.4+ builds"
> > > as it removes most of what was possibly incorrectly added there (see 2nd
> > > review)
> > >
> >
> > I left this here on purpose, since it is only RFC. The other patches
> > as they appear in the series are required to build against 5.4+, but
> > this is optional.
>
> Look like this patch causes issues with building perf for 4.4.y kernel...
>
> I've recently started to upgrade some of BSPs from zeus to dunfell,
> and kernel 4.4.y fails to build with this patch applied. When I
> applied changes from Martin in commit
> [f3515d2d2545cae6b88fe5e86d081f4ef6133bf6] - build went through.
>
> I have now the bbappend in the layer, which sets the PERF_SRC to add
> the "include" folder back but I don't think this is a clean approach.
>
> Should this be reverted, or those who has a "dunfell+4.4.y kernel"
> setup need to use appends to override the PERF_SRC?

If you revert it, you might be trading warnings and breakages for
newer kernels to fix 4.4. That's the issue with perf, since it builds
right from the kernel source, it has to serve many different versions
(and we juggle breaking/fixing that from time to time).

So any revert would have to then build all of the different kernel
versions and perf to make sure that we don't trade one breakage for
another .. and being LTS we need to be extra careful. Since we don't
have an active 4.4 kernel in that branch, it would have to be ad-hoc
testing to confirm.

What exactly was the build error that you saw ?

Bruce



Bruce

>
> >
> > Bruce
> >
> > > > Signed-off-by: Bruce Ashfield 
> > > > ---
> > > >  meta/recipes-kernel/perf/perf.bb | 9 -
> > > >  1 file changed, 9 deletions(-)
> > > >
> > > > diff --git a/meta/recipes-kernel/perf/perf.bb 
> > > > b/meta/recipes-kernel/perf/perf.bb
> > > > index 191305969c..5f0ba7c180 100644
> > > > --- a/meta/recipes-kernel/perf/perf.bb
> > > > +++ b/meta/recipes-kernel/perf/perf.bb
> > > > @@ -106,7 +106,6 @@ EXTRA_OEMAKE += "\
> > > >  EXTRA_OEMAKE_append_task-configure = " JOBS=1"
> > > >
> > > >  PERF_SRC ?= "Makefile \
> > > > - include \
> > > >   tools/arch \
> > > >   tools/build \
> > > >   tools/include \
> > > > @@ -248,14 +247,6 @@ do_configure_prepend () {
> > > >  # so we copy it from the sysroot unistd.h to the perf unistd.h
> > > >  install -D -m0644 ${STAGING_INCDIR}/asm-generic/unistd.h 
> > > > ${S}/tools/include/uapi/asm-generic/unistd.h
> > > >  install -D -m0644 ${STAGING_INCDIR}/asm-generic/unistd.h 
> > > > ${S}/include/uapi/asm-generic/unistd.h
> > > > -
> > > > -# bits.h can have the same issue as unistd.h, so we make the tools 
> > > > variant take precedence
> > > > -[ -e ${S}/tools/include/linux/bits.h ] && install -D -m0644 
> > > > ${S}/tools/include/linux/bits.h ${S}/include/linux/bits.h
> > > > -
> > > > -[ -e ${S}/tools/perf/util/include/linux/ctype.h ] && install -D 
> > > > -m0644 ${S}/include/linux/ctype.h 
> > > > ${S}/tools/perf/util/include/linux/ctype.h
> > > > -
> > > > -[ -e ${S}/include/uapi/linux/kvm.h ] && install -D -m0644 
> > > > ${S}/include/uapi/linux/kvm.h  ${S}/tools/include/uapi/linux/kvm.h
> > > > -[ -e ${S}/include/uapi/linux/sched.h ] && install -D -m0644 
> > > > ${S}/include/uapi/linux/sched.h  ${S}/tools/include/uapi/linux/sched.h
> > > >  }
> > > >
> > > >  python do_package_prepend() {
> > > > --
> > > > 2.19.1
> > > >
> > > > --
> > > > ___
> > > > Openembedded-core mailing list
> > > > Openembedded-core@lists.openembedded.org
> > > > http://lists.openembedded.org/mailman/listinfo/openembedded-core
> > >
> > > --
> > > Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
> >
> >
> >
> > --
> > - Thou shalt not follow the NULL pointer, for chaos and madness await
> > thee at its end
> > - "Use the force Harry" - Gandalf, Star Trek II
> > --
> > ___
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
>
>
> --
> Regards,
> Andrey.



--
- Thou shalt not follow the 

Re: [OE-core] [PATCH] armv8/tunes: Set TUNE_PKGARCH_64 based on ARMPKGARCH

[Adrian Bunk]

On Thu, May 21, 2020 at 06:30:50PM -0700, Khem Raj wrote:
>...
> This lets higher up tune files for arm64 SOCs override them if needed,
> this can help building multiple armv8 machines with different tunes in
> same workspace.
>...

I am getting code for cortexa53-crypto built in a directory
cortexa53-tmp-linux, but the code might not run on cortexa53
without the crypto extension.

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

View/Reply Online (#138720): 
https://lists.openembedded.org/g/openembedded-core/message/138720
Mute This Topic: https://lists.openembedded.org/mt/74390340/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 Qt5 Qt 5.6.3 compatibility with Yocto 2.4(poky)

[Quentin Schulz]

Hi Ramakanth,

On Tue, May 26, 2020 at 04:39:26PM +0530, Ramakanth Kesireddy wrote:
> Hi,
> 
> Thanks for your mail.
> Do we have
>  Meta Qt5.6.3 recipes for Yocto 2.4 Rocko branch?
> 

As I said, I'm using qt5.6.3 on thud with the krogoth branch of meta-qt5.
So a meta-qt5 meant for krogoth, but used on thud (2.6.4). There aren't
always backward/"upward" compatibility issues, so really, just try and
if there is an issue, ask about it. It takes you less time to try that
to discuss this on the mailing list.

The only change you need is to add rocko to LAYERSERIES_COMPAT in
meta-qt5/conf/layer.conf and a way to do that outside of meta-qt5 (when
you'll want to distribute your layer or commit it) was discussed yesterday
on the ML.

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

View/Reply Online (#138719): 
https://lists.openembedded.org/g/openembedded-core/message/138719
Mute This Topic: https://lists.openembedded.org/mt/74455294/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 3/4] libgcrypt: made libgcrypt-lic license "GPLv2+ & LGPLv2.1+"

[Adrian Bunk]

On Tue, May 26, 2020 at 01:20:50PM +0200, Matthias Schoepfer via 
lists.openembedded.org wrote:
>...
> The question here seems to be, is the GPLv3 License itself GPLv3 licensed.
>...

  Everyone is permitted to copy and distribute verbatim copies
  of this license document, but changing it is not allowed.


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

View/Reply Online (#138718): 
https://lists.openembedded.org/g/openembedded-core/message/138718
Mute This Topic: https://lists.openembedded.org/mt/74473621/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 3/4] libgcrypt: made libgcrypt-lic license "GPLv2+ & LGPLv2.1+"

[Richard Purdie]

On Tue, 2020-05-26 at 13:20 +0200, Matthias Schoepfer wrote:
> Hi Richard,
> 
> On 5/26/20 10:19 AM, Richard Purdie wrote:
> > On Tue, 2020-05-26 at 10:12 +0200, Matthias Schoepfer via
> > lists.openembedded.org wrote:
> > > From: Matthias Schoepfer 
> > > 
> > > With the exception of dumpsexp.c, which is GPLv3, all other parts
> > > of libgcrypt are GPLv2+ & LGPLv2.1+, BSD or MIT or other "permissive"
> > > licenses.
> > > 
> > > If libgcrypt-lic is not set to "GPLv2+ & LGPLv2.1+", image creation
> > > will
> > > fail with settings like
> > > 
> > > INCOMPATIBLE_LICENSE = "GPLv3 LGPLv3 GPLv3+ LGPLv3+ GPL-3.0 LGPL-3.0
> > > AGPL-3.0"
> > > COPY_LIC_MANIFEST = "1"
> > > COPY_LIC_DIRS = "1"
> > > LICENSE_CREATE_PACKAGE = "1"
> > > 
> > > Signed-off-by: Matthias Schoepfer 
> > > ---
> > >   meta/recipes-support/libgcrypt/libgcrypt_1.8.5.bb | 1 +
> > >   1 file changed, 1 insertion(+)
> > > 
> > > diff --git a/meta/recipes-support/libgcrypt/libgcrypt_1.8.5.bb
> > > b/meta/recipes-support/libgcrypt/libgcrypt_1.8.5.bb
> > > index 4e0eb0a169..fd40cdcf83 100644
> > > --- a/meta/recipes-support/libgcrypt/libgcrypt_1.8.5.bb
> > > +++ b/meta/recipes-support/libgcrypt/libgcrypt_1.8.5.bb
> > > @@ -7,6 +7,7 @@ SECTION = "libs"
> > >   LICENSE = "GPLv2+ & LGPLv2.1+ & GPLv3+"
> > >   LICENSE_${PN} = "LGPLv2.1+"
> > >   LICENSE_${PN}-dev = "GPLv2+ & LGPLv2.1+"
> > > +LICENSE_${PN}-lic = "GPLv2+ & LGPLv2.1+"
> > >   LICENSE_dumpsexp-dev = "GPLv3+"
> > 
> > I don't like this approach at all. Its obviously inconvenient if your
> > image uses only the non-GPLv3 pieces but this doesn't change the fact
> > that the main package license does include GLPv3 and ${PN}-lic is right
> > to include it. You're breaking the metadata to fit your use case for
> > convenience.
> > 
> > If you're excluding GPLv3 things from packaging, you could then (and
> > only then) justifiably adjust ${PN}-lic to a different license so the
> > code should be doing that, not changing the underlying metadata to suit
> > you.
> 
> The question here seems to be, is the GPLv3 License itself GPLv3 
> licensed. I followed the approach Khem Raj gave me on the yocto mailing 
> list. I do not like the approach either, but lack a better solution. In 
> this very specific package, only one .c file is licensed GPLv3, even the 
> COPYING file claims, everything is GPLv2 and LGPLv2.1+.
> 
> dumpsexp, the only GPLv3 file, is not even in the package by default. 
> The line
> LICENSE_${PN} = "LGPLv2.1+"
> pretty much tells the tale here.
> 
> Also, LICENSE file states, that there are other licenses also involved, 
> BSD 3 Clause, Public Domain and OCB license...

I think we need to be really clear about what the license of ${PN}-lic
means.

That leads to a really good question, which license is the license text
itself under?

I've asked this on our licensing list to see if anyone knows.

Cheers,

Richard





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

View/Reply Online (#138717): 
https://lists.openembedded.org/g/openembedded-core/message/138717
Mute This Topic: https://lists.openembedded.org/mt/74473621/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 3/4] libgcrypt: made libgcrypt-lic license "GPLv2+ & LGPLv2.1+"

[Matthias Schoepfer via lists.openembedded.org]

Hi Richard,

On 5/26/20 10:19 AM, Richard Purdie wrote:

On Tue, 2020-05-26 at 10:12 +0200, Matthias Schoepfer via
lists.openembedded.org wrote:

From: Matthias Schoepfer 

With the exception of dumpsexp.c, which is GPLv3, all other parts
of libgcrypt are GPLv2+ & LGPLv2.1+, BSD or MIT or other "permissive"
licenses.

If libgcrypt-lic is not set to "GPLv2+ & LGPLv2.1+", image creation
will
fail with settings like

INCOMPATIBLE_LICENSE = "GPLv3 LGPLv3 GPLv3+ LGPLv3+ GPL-3.0 LGPL-3.0
AGPL-3.0"
COPY_LIC_MANIFEST = "1"
COPY_LIC_DIRS = "1"
LICENSE_CREATE_PACKAGE = "1"

Signed-off-by: Matthias Schoepfer 
---
  meta/recipes-support/libgcrypt/libgcrypt_1.8.5.bb | 1 +
  1 file changed, 1 insertion(+)

diff --git a/meta/recipes-support/libgcrypt/libgcrypt_1.8.5.bb
b/meta/recipes-support/libgcrypt/libgcrypt_1.8.5.bb
index 4e0eb0a169..fd40cdcf83 100644
--- a/meta/recipes-support/libgcrypt/libgcrypt_1.8.5.bb
+++ b/meta/recipes-support/libgcrypt/libgcrypt_1.8.5.bb
@@ -7,6 +7,7 @@ SECTION = "libs"
  LICENSE = "GPLv2+ & LGPLv2.1+ & GPLv3+"
  LICENSE_${PN} = "LGPLv2.1+"
  LICENSE_${PN}-dev = "GPLv2+ & LGPLv2.1+"
+LICENSE_${PN}-lic = "GPLv2+ & LGPLv2.1+"
  LICENSE_dumpsexp-dev = "GPLv3+"


I don't like this approach at all. Its obviously inconvenient if your
image uses only the non-GPLv3 pieces but this doesn't change the fact
that the main package license does include GLPv3 and ${PN}-lic is right
to include it. You're breaking the metadata to fit your use case for
convenience.

If you're excluding GPLv3 things from packaging, you could then (and
only then) justifiably adjust ${PN}-lic to a different license so the
code should be doing that, not changing the underlying metadata to suit
you.


The question here seems to be, is the GPLv3 License itself GPLv3 
licensed. I followed the approach Khem Raj gave me on the yocto mailing 
list. I do not like the approach either, but lack a better solution. In 
this very specific package, only one .c file is licensed GPLv3, even the 
COPYING file claims, everything is GPLv2 and LGPLv2.1+.


dumpsexp, the only GPLv3 file, is not even in the package by default. 
The line

LICENSE_${PN} = "LGPLv2.1+"
pretty much tells the tale here.

Also, LICENSE file states, that there are other licenses also involved, 
BSD 3 Clause, Public Domain and OCB license...


Thanks and Regards,

  Matthias

--
Dr.-Ing. Matthias Schöpfer
matthias.schoep...@googlemail.com
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138716): 
https://lists.openembedded.org/g/openembedded-core/message/138716
Mute This Topic: https://lists.openembedded.org/mt/74473621/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 Qt5 Qt 5.6.3 compatibility with Yocto 2.4(poky)

[Ramakanth Kesireddy]

Hi,

Thanks for your mail.
Do we have
 Meta Qt5.6.3 recipes for Yocto 2.4 Rocko branch?

Best Regards,
Ramakanth

On Mon, 25 May, 2020, 18:17 Quentin Schulz, <
quentin.sch...@streamunlimited.com> wrote:

> Hi Ramakanth,
>
> On Mon, May 25, 2020 at 06:06:34PM +0530, Ramakanth Kesireddy wrote:
> > Hi All,
> >
> > Can anyone please  let me know if Qt 5.6.3 LTS is compatible with Yocto
> > project version 2.4 ( poky ) or not to build meta-qt5 recipes of Qt
> 5.6.3 no
> > LTS?
> >
> > If so, where to pick up the meta-15 recipes for Qt 5.6.3 LTS open source?
> >
>
> We're building meta-qt5 from krogoth branch on thud currently. This
> branch has the latest version for qtbase (5.6.3 release).
> We've a few bbappends but they do not seem to exist for fixing build
> issues :)
>
> So, try and check for yourself :)
>
> BR,
> Quentin
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

Re: [OE-core][dunfell 09/17] libubootenv: Depend on zlib

[Stefano Babic]

On 26.05.20 10:57, Paul Barker wrote:
> On Tue, 26 May 2020 at 09:56, Adrian Bunk  wrote:
>>
>> On Tue, May 26, 2020 at 09:24:59AM +0100, Paul Barker wrote:
>>> On Mon, 25 May 2020 at 23:37, Steve Sakoman  wrote:

 From: Marek Vasut 

 The libubootenv depends on zlib as it calls at least crc32() from
 there and links against it. Add the DEPENDS entry.

 Signed-off-by: Marek Vasut 
 Cc: Stefano Babic 
 Signed-off-by: Richard Purdie 
 Signed-off-by: Steve Sakoman 
 (cherry picked from commit db513f9ec59b7ac526b2cdc42b0eb2573e134bc4)
 Signed-off-by: Steve Sakoman 
 ---
  meta/recipes-bsp/u-boot/libubootenv_0.2.bb | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/meta/recipes-bsp/u-boot/libubootenv_0.2.bb 
 b/meta/recipes-bsp/u-boot/libubootenv_0.2.bb
 index 3251d0f05b..fa90a12bf8 100644
 --- a/meta/recipes-bsp/u-boot/libubootenv_0.2.bb
 +++ b/meta/recipes-bsp/u-boot/libubootenv_0.2.bb
 @@ -1,5 +1,5 @@
  SUMMARY = "U-Boot libraries and tools to access environment"
 -DEPENDS += "mtd-utils"
 +DEPENDS += "mtd-utils zlib"

  DESCRIPTION = "This package contains tools and libraries to read \
  and modify U-Boot environment. \
 --
 2.17.1
>>>
>>> Is this actually needed for the u-boot version in dunfell? My
>>> understanding when I saw the original patch was that this is a new
>>> requirement of the latest u-boot.
>>
>> libubootenv (not u-boot) uses zlib also in dunfell,
>> and a direct dependency looks correct to me.
>>
>> I assume the breaking case involves a layer shipping an own mtd-utils
>> recipe that does not pull in zlib.
> 

Yes, it is exactly the case. dunfell builds without issues
libubootenv-bin (fw_setenv / fw_printenv). Users of library have
doscovered the issue because they have not zlib in their own recipe.

> Thanks for the confirmation, I understand now. Looks good for dunfell.
> 

Regards,
Stefano

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

Re: [OE-core][dunfell 09/17] libubootenv: Depend on zlib

[Paul Barker]

On Tue, 26 May 2020 at 09:56, Adrian Bunk  wrote:
>
> On Tue, May 26, 2020 at 09:24:59AM +0100, Paul Barker wrote:
> > On Mon, 25 May 2020 at 23:37, Steve Sakoman  wrote:
> > >
> > > From: Marek Vasut 
> > >
> > > The libubootenv depends on zlib as it calls at least crc32() from
> > > there and links against it. Add the DEPENDS entry.
> > >
> > > Signed-off-by: Marek Vasut 
> > > Cc: Stefano Babic 
> > > Signed-off-by: Richard Purdie 
> > > Signed-off-by: Steve Sakoman 
> > > (cherry picked from commit db513f9ec59b7ac526b2cdc42b0eb2573e134bc4)
> > > Signed-off-by: Steve Sakoman 
> > > ---
> > >  meta/recipes-bsp/u-boot/libubootenv_0.2.bb | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/meta/recipes-bsp/u-boot/libubootenv_0.2.bb 
> > > b/meta/recipes-bsp/u-boot/libubootenv_0.2.bb
> > > index 3251d0f05b..fa90a12bf8 100644
> > > --- a/meta/recipes-bsp/u-boot/libubootenv_0.2.bb
> > > +++ b/meta/recipes-bsp/u-boot/libubootenv_0.2.bb
> > > @@ -1,5 +1,5 @@
> > >  SUMMARY = "U-Boot libraries and tools to access environment"
> > > -DEPENDS += "mtd-utils"
> > > +DEPENDS += "mtd-utils zlib"
> > >
> > >  DESCRIPTION = "This package contains tools and libraries to read \
> > >  and modify U-Boot environment. \
> > > --
> > > 2.17.1
> >
> > Is this actually needed for the u-boot version in dunfell? My
> > understanding when I saw the original patch was that this is a new
> > requirement of the latest u-boot.
>
> libubootenv (not u-boot) uses zlib also in dunfell,
> and a direct dependency looks correct to me.
>
> I assume the breaking case involves a layer shipping an own mtd-utils
> recipe that does not pull in zlib.

Thanks for the confirmation, I understand now. Looks good for dunfell.

-- 
Paul Barker
Konsulko Group
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

Re: [OE-core][dunfell 09/17] libubootenv: Depend on zlib

[Adrian Bunk]

On Tue, May 26, 2020 at 09:24:59AM +0100, Paul Barker wrote:
> On Mon, 25 May 2020 at 23:37, Steve Sakoman  wrote:
> >
> > From: Marek Vasut 
> >
> > The libubootenv depends on zlib as it calls at least crc32() from
> > there and links against it. Add the DEPENDS entry.
> >
> > Signed-off-by: Marek Vasut 
> > Cc: Stefano Babic 
> > Signed-off-by: Richard Purdie 
> > Signed-off-by: Steve Sakoman 
> > (cherry picked from commit db513f9ec59b7ac526b2cdc42b0eb2573e134bc4)
> > Signed-off-by: Steve Sakoman 
> > ---
> >  meta/recipes-bsp/u-boot/libubootenv_0.2.bb | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/meta/recipes-bsp/u-boot/libubootenv_0.2.bb 
> > b/meta/recipes-bsp/u-boot/libubootenv_0.2.bb
> > index 3251d0f05b..fa90a12bf8 100644
> > --- a/meta/recipes-bsp/u-boot/libubootenv_0.2.bb
> > +++ b/meta/recipes-bsp/u-boot/libubootenv_0.2.bb
> > @@ -1,5 +1,5 @@
> >  SUMMARY = "U-Boot libraries and tools to access environment"
> > -DEPENDS += "mtd-utils"
> > +DEPENDS += "mtd-utils zlib"
> >
> >  DESCRIPTION = "This package contains tools and libraries to read \
> >  and modify U-Boot environment. \
> > --
> > 2.17.1
> 
> Is this actually needed for the u-boot version in dunfell? My
> understanding when I saw the original patch was that this is a new
> requirement of the latest u-boot.

libubootenv (not u-boot) uses zlib also in dunfell,
and a direct dependency looks correct to me.

I assume the breaking case involves a layer shipping an own mtd-utils 
recipe that does not pull in zlib.

> Thanks,

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

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

Re: [OE-core][dunfell 14/17] newlib: Upgrade to latest yearly release 3.3.0

[Paul Barker]

On Mon, 25 May 2020 at 23:37, Steve Sakoman  wrote:
>
> From: Alejandro Hernandez 
>
> Upgrade to the latest snapshot, also drop md5sum while were at it.
>
> (From OE-Core rev: d73aa359e42e707dbc7cfa29c55a2fc8e6bb938a)
>
> Signed-off-by: Alejandro Hernandez Samaniego 
> Signed-off-by: Alejandro Hernandez Samaniego 
> Signed-off-by: Richard Purdie 
> Signed-off-by: Steve Sakoman 
> ---
>  .../newlib/{libgloss_3.2.0.bb => libgloss_3.3.0.bb}| 0
>  meta/recipes-core/newlib/newlib.inc| 3 +--
>  meta/recipes-core/newlib/{newlib_3.2.0.bb => newlib_3.3.0.bb}  | 0
>  3 files changed, 1 insertion(+), 2 deletions(-)
>  rename meta/recipes-core/newlib/{libgloss_3.2.0.bb => libgloss_3.3.0.bb} 
> (100%)
>  rename meta/recipes-core/newlib/{newlib_3.2.0.bb => newlib_3.3.0.bb} (100%)
>
> diff --git a/meta/recipes-core/newlib/libgloss_3.2.0.bb 
> b/meta/recipes-core/newlib/libgloss_3.3.0.bb
> similarity index 100%
> rename from meta/recipes-core/newlib/libgloss_3.2.0.bb
> rename to meta/recipes-core/newlib/libgloss_3.3.0.bb
> diff --git a/meta/recipes-core/newlib/newlib.inc 
> b/meta/recipes-core/newlib/newlib.inc
> index 5edea8aba1..96e230f985 100644
> --- a/meta/recipes-core/newlib/newlib.inc
> +++ b/meta/recipes-core/newlib/newlib.inc
> @@ -16,8 +16,7 @@ LIC_FILES_CHKSUM = " \
> "
>
>  SRC_URI = "https://sourceware.org/pub/newlib/newlib-${PV}.tar.gz;
> -SRC_URI[md5sum] = "afb3a01c8c82b6717ea55659a4de30ec"
> -SRC_URI[sha256sum] = 
> "f7b2322964a1e3b37bec0768da20f50dfb62247d729110974dd95756a53bb6d4"
> +SRC_URI[sha256sum] = 
> "58dd9e3eaedf519360d92d84205c3deef0b3fc286685d1c562e245914ef72c66"
>
>  INHIBIT_DEFAULT_DEPS = "1"
>  DEPENDS = "virtual/${TARGET_PREFIX}gcc"
> diff --git a/meta/recipes-core/newlib/newlib_3.2.0.bb 
> b/meta/recipes-core/newlib/newlib_3.3.0.bb
> similarity index 100%
> rename from meta/recipes-core/newlib/newlib_3.2.0.bb
> rename to meta/recipes-core/newlib/newlib_3.3.0.bb
> --
> 2.17.1

NACK: https://lists.openembedded.org/g/openembedded-core/message/137847


--
Paul Barker
Konsulko Group
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

Re: [OE-core][dunfell 09/17] libubootenv: Depend on zlib

[Paul Barker]

On Mon, 25 May 2020 at 23:37, Steve Sakoman  wrote:
>
> From: Marek Vasut 
>
> The libubootenv depends on zlib as it calls at least crc32() from
> there and links against it. Add the DEPENDS entry.
>
> Signed-off-by: Marek Vasut 
> Cc: Stefano Babic 
> Signed-off-by: Richard Purdie 
> Signed-off-by: Steve Sakoman 
> (cherry picked from commit db513f9ec59b7ac526b2cdc42b0eb2573e134bc4)
> Signed-off-by: Steve Sakoman 
> ---
>  meta/recipes-bsp/u-boot/libubootenv_0.2.bb | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/recipes-bsp/u-boot/libubootenv_0.2.bb 
> b/meta/recipes-bsp/u-boot/libubootenv_0.2.bb
> index 3251d0f05b..fa90a12bf8 100644
> --- a/meta/recipes-bsp/u-boot/libubootenv_0.2.bb
> +++ b/meta/recipes-bsp/u-boot/libubootenv_0.2.bb
> @@ -1,5 +1,5 @@
>  SUMMARY = "U-Boot libraries and tools to access environment"
> -DEPENDS += "mtd-utils"
> +DEPENDS += "mtd-utils zlib"
>
>  DESCRIPTION = "This package contains tools and libraries to read \
>  and modify U-Boot environment. \
> --
> 2.17.1

Is this actually needed for the u-boot version in dunfell? My
understanding when I saw the original patch was that this is a new
requirement of the latest u-boot.

Thanks,

-- 
Paul Barker
Konsulko Group
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138710): 
https://lists.openembedded.org/g/openembedded-core/message/138710
Mute This Topic: https://lists.openembedded.org/mt/74467807/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 3/4] libgcrypt: made libgcrypt-lic license "GPLv2+ & LGPLv2.1+"

[Richard Purdie]

On Tue, 2020-05-26 at 10:12 +0200, Matthias Schoepfer via
lists.openembedded.org wrote:
> From: Matthias Schoepfer 
> 
> With the exception of dumpsexp.c, which is GPLv3, all other parts
> of libgcrypt are GPLv2+ & LGPLv2.1+, BSD or MIT or other "permissive"
> licenses.
> 
> If libgcrypt-lic is not set to "GPLv2+ & LGPLv2.1+", image creation
> will
> fail with settings like
> 
> INCOMPATIBLE_LICENSE = "GPLv3 LGPLv3 GPLv3+ LGPLv3+ GPL-3.0 LGPL-3.0
> AGPL-3.0"
> COPY_LIC_MANIFEST = "1"
> COPY_LIC_DIRS = "1"
> LICENSE_CREATE_PACKAGE = "1"
> 
> Signed-off-by: Matthias Schoepfer 
> ---
>  meta/recipes-support/libgcrypt/libgcrypt_1.8.5.bb | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/meta/recipes-support/libgcrypt/libgcrypt_1.8.5.bb
> b/meta/recipes-support/libgcrypt/libgcrypt_1.8.5.bb
> index 4e0eb0a169..fd40cdcf83 100644
> --- a/meta/recipes-support/libgcrypt/libgcrypt_1.8.5.bb
> +++ b/meta/recipes-support/libgcrypt/libgcrypt_1.8.5.bb
> @@ -7,6 +7,7 @@ SECTION = "libs"
>  LICENSE = "GPLv2+ & LGPLv2.1+ & GPLv3+"
>  LICENSE_${PN} = "LGPLv2.1+"
>  LICENSE_${PN}-dev = "GPLv2+ & LGPLv2.1+"
> +LICENSE_${PN}-lic = "GPLv2+ & LGPLv2.1+"
>  LICENSE_dumpsexp-dev = "GPLv3+"

I don't like this approach at all. Its obviously inconvenient if your
image uses only the non-GPLv3 pieces but this doesn't change the fact
that the main package license does include GLPv3 and ${PN}-lic is right
to include it. You're breaking the metadata to fit your use case for
convenience.

If you're excluding GPLv3 things from packaging, you could then (and
only then) justifiably adjust ${PN}-lic to a different license so the
code should be doing that, not changing the underlying metadata to suit
you.

Cheers,

Richard

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

View/Reply Online (#138709): 
https://lists.openembedded.org/g/openembedded-core/message/138709
Mute This Topic: https://lists.openembedded.org/mt/74473621/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 4/4] libksba: made libksba-lic "GPLv2+ | LGPLv3+"

[Matthias Schoepfer via lists.openembedded.org]

From: Matthias Schoepfer 

If not set manually to "GPLv2+ | LGPLv3+", install of non GPLv3 parts (the
library in this case) will be prevented in a setup that has

INCOMPATIBLE_LICENSE = "GPLv3 LGPLv3 GPLv3+ LGPLv3+ GPL-3.0 LGPL-3.0 AGPL-3.0"
COPY_LIC_MANIFEST = "1"
COPY_LIC_DIRS = "1"
LICENSE_CREATE_PACKAGE = "1"

set, because during image creation, libksba-lic will have incompatible
license.

Signed-off-by: Matthias Schoepfer 
---
 meta/recipes-support/libksba/libksba_1.3.5.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-support/libksba/libksba_1.3.5.bb 
b/meta/recipes-support/libksba/libksba_1.3.5.bb
index 336d7f8177..1a8f18a9ef 100644
--- a/meta/recipes-support/libksba/libksba_1.3.5.bb
+++ b/meta/recipes-support/libksba/libksba_1.3.5.bb
@@ -3,6 +3,7 @@ HOMEPAGE = "http://www.gnupg.org/related_software/libksba/;
 LICENSE = "GPLv3+ & (GPLv2+ | LGPLv3+)"
 LICENSE_${PN} = "GPLv2+ | LGPLv3+"
 LICENSE_${PN}-doc = "GPLv3+"
+LICENSE_${PN}-lic = "GPLv2+ | LGPLv3+"
 LIC_FILES_CHKSUM = "file://COPYING;md5=fd541d83f75d038c4e0617b672ed8bda \
 file://COPYING.GPLv2;md5=b234ee4d69f5fce4486a80fdaf4a4263 \
 file://COPYING.GPLv3;md5=2f31b266d3440dd7ee50f92cf67d8e6c \
-- 
2.26.2

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

View/Reply Online (#138708): 
https://lists.openembedded.org/g/openembedded-core/message/138708
Mute This Topic: https://lists.openembedded.org/mt/74473622/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 3/4] libgcrypt: made libgcrypt-lic license "GPLv2+ & LGPLv2.1+"

[Matthias Schoepfer via lists.openembedded.org]

From: Matthias Schoepfer 

With the exception of dumpsexp.c, which is GPLv3, all other parts
of libgcrypt are GPLv2+ & LGPLv2.1+, BSD or MIT or other "permissive"
licenses.

If libgcrypt-lic is not set to "GPLv2+ & LGPLv2.1+", image creation will
fail with settings like

INCOMPATIBLE_LICENSE = "GPLv3 LGPLv3 GPLv3+ LGPLv3+ GPL-3.0 LGPL-3.0 AGPL-3.0"
COPY_LIC_MANIFEST = "1"
COPY_LIC_DIRS = "1"
LICENSE_CREATE_PACKAGE = "1"

Signed-off-by: Matthias Schoepfer 
---
 meta/recipes-support/libgcrypt/libgcrypt_1.8.5.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-support/libgcrypt/libgcrypt_1.8.5.bb 
b/meta/recipes-support/libgcrypt/libgcrypt_1.8.5.bb
index 4e0eb0a169..fd40cdcf83 100644
--- a/meta/recipes-support/libgcrypt/libgcrypt_1.8.5.bb
+++ b/meta/recipes-support/libgcrypt/libgcrypt_1.8.5.bb
@@ -7,6 +7,7 @@ SECTION = "libs"
 LICENSE = "GPLv2+ & LGPLv2.1+ & GPLv3+"
 LICENSE_${PN} = "LGPLv2.1+"
 LICENSE_${PN}-dev = "GPLv2+ & LGPLv2.1+"
+LICENSE_${PN}-lic = "GPLv2+ & LGPLv2.1+"
 LICENSE_dumpsexp-dev = "GPLv3+"
 
 LIC_FILES_CHKSUM = "file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f \
-- 
2.26.2

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

View/Reply Online (#138707): 
https://lists.openembedded.org/g/openembedded-core/message/138707
Mute This Topic: https://lists.openembedded.org/mt/74473621/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 2/4] elfutils: made elfutils-lic "GPLv2 | LGPLv3+"

[Matthias Schoepfer via lists.openembedded.org]

From: Matthias Schoepfer 

If not set manually to "GPLv2 | LGPLv3+", install of non GPLv3 parts
of elfutils will be prevented in a setup that has

INCOMPATIBLE_LICENSE = "GPLv3 LGPLv3 GPLv3+ LGPLv3+ GPL-3.0 LGPL-3.0 AGPL-3.0"
COPY_LIC_MANIFEST = "1"
COPY_LIC_DIRS = "1"
LICENSE_CREATE_PACKAGE = "1"

set, because during image creation, elfutils-lic will have incompatible
license.

Signed-off-by: Matthias Schoepfer 
---
 meta/recipes-devtools/elfutils/elfutils_0.179.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-devtools/elfutils/elfutils_0.179.bb 
b/meta/recipes-devtools/elfutils/elfutils_0.179.bb
index 1da95ec1de..ea185abd83 100644
--- a/meta/recipes-devtools/elfutils/elfutils_0.179.bb
+++ b/meta/recipes-devtools/elfutils/elfutils_0.179.bb
@@ -105,6 +105,7 @@ PACKAGES =+ "${PN}-binutils libelf libasm libdw"
 # submit patches."
 LICENSE_${PN}-binutils = "GPLv3+"
 LICENSE_${PN} = "GPLv3+"
+LICENSE_${PN}-lic = "GPLv2 | LGPLv3+"
 LICENSE_libelf = "GPLv2 | LGPLv3+"
 LICENSE_libasm = "GPLv2 | LGPLv3+"
 LICENSE_libdw = "GPLv2 | LGPLv3+"
-- 
2.26.2

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

View/Reply Online (#138706): 
https://lists.openembedded.org/g/openembedded-core/message/138706
Mute This Topic: https://lists.openembedded.org/mt/74473619/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 1/4] libgcc: made libgcc-lic "GPL-3.0-with-GCC-exception"

[Matthias Schoepfer via lists.openembedded.org]

From: Matthias Schoepfer 

libgcc LICENSE_${PN} is "GPL-3.0-with-GCC-exception". If libgcc-lic
is not also set to the same license, creating of image with

INCOMPATIBLE_LICENSE = "GPLv3 LGPLv3 GPLv3+ LGPLv3+ GPL-3.0 LGPL-3.0 AGPL-3.0"
COPY_LIC_MANIFEST = "1"
COPY_LIC_DIRS = "1"
LICENSE_CREATE_PACKAGE = "1"

will fail because libgcc-lic will have incompatible license.

Signed-off-by: Matthias Schoepfer 
---
 meta/recipes-devtools/gcc/libgcc.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/gcc/libgcc.inc 
b/meta/recipes-devtools/gcc/libgcc.inc
index 6d48ec9809..2e5b1fe492 100644
--- a/meta/recipes-devtools/gcc/libgcc.inc
+++ b/meta/recipes-devtools/gcc/libgcc.inc
@@ -35,7 +35,7 @@ PACKAGES = "\
 LICENSE_${PN} = "GPL-3.0-with-GCC-exception"
 LICENSE_${PN}-dev = "GPL-3.0-with-GCC-exception"
 LICENSE_${PN}-dbg = "GPL-3.0-with-GCC-exception"
-
+LICENSE_${PN}-lic = "GPL-3.0-with-GCC-exception"
 
 FILES_${PN}-dev = "\
 ${base_libdir}/libgcc*.so \
-- 
2.26.2

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

View/Reply Online (#138705): 
https://lists.openembedded.org/g/openembedded-core/message/138705
Mute This Topic: https://lists.openembedded.org/mt/74473616/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] features_check: Factorize code for checking features

[Jacob Kroon]

The DISTRO/MACHINE/COMBINED features should be treated identically, so
convert the expanded code to a loop. This fixes some of the COMBINED error
messages which were previously referring to MACHINE features. There
should be no functional changes.

Signed-off-by: Jacob Kroon 
---
 meta/classes/features_check.bbclass | 110 
 1 file changed, 32 insertions(+), 78 deletions(-)

diff --git a/meta/classes/features_check.bbclass 
b/meta/classes/features_check.bbclass
index 876d32e315..4ba827d4ab 100644
--- a/meta/classes/features_check.bbclass
+++ b/meta/classes/features_check.bbclass
@@ -1,23 +1,13 @@
-# Allow checking of required and conflicting DISTRO_FEATURES
+# Allow checking of required and conflicting features
 #
-# ANY_OF_DISTRO_FEATURES: ensure at least one item on this list is included
-# in DISTRO_FEATURES.
-# REQUIRED_DISTRO_FEATURES:   ensure every item on this list is included
-# in DISTRO_FEATURES.
-# CONFLICT_DISTRO_FEATURES:   ensure no item in this list is included in
-# DISTRO_FEATURES.
-# ANY_OF_MACHINE_FEATURES:ensure at least one item on this list is included
-# in MACHINE_FEATURES.
-# REQUIRED_MACHINE_FEATURES:  ensure every item on this list is included
-# in MACHINE_FEATURES.
-# CONFLICT_MACHINE_FEATURES:  ensure no item in this list is included in
-# MACHINE_FEATURES.
-# ANY_OF_COMBINED_FEATURES:   ensure at least one item on this list is included
-# in COMBINED_FEATURES.
-# REQUIRED_COMBINED_FEATURES: ensure every item on this list is included
-# in COMBINED_FEATURES.
-# CONFLICT_COMBINED_FEATURES: ensure no item in this list is included in
-# COMBINED_FEATURES.
+# xxx = [DISTRO,MACHINE,COMBINED]
+#
+# ANY_OF_xxx_FEATURES:ensure at least one item on this list is included
+# in xxx_FEATURES.
+# REQUIRED_xxx_FEATURES:  ensure every item on this list is included
+# in xxx_FEATURES.
+# CONFLICT_xxx_FEATURES:  ensure no item in this list is included in
+# xxx_FEATURES.
 #
 # Copyright 2019 (C) Texas Instruments Inc.
 # Copyright 2013 (C) O.S. Systems Software LTDA.
@@ -26,63 +16,27 @@ python () {
 if d.getVar('PARSE_ALL_RECIPES', False):
 return
 
-# Assume at least one var is set.
-distro_features = set((d.getVar('DISTRO_FEATURES') or '').split())
-
-any_of_distro_features = set((d.getVar('ANY_OF_DISTRO_FEATURES') or 
'').split())
-if any_of_distro_features:
-if set.isdisjoint(any_of_distro_features, distro_features):
-raise bb.parse.SkipRecipe("one of '%s' needs to be in 
DISTRO_FEATURES" % ' '.join(any_of_distro_features))
-
-required_distro_features = set((d.getVar('REQUIRED_DISTRO_FEATURES') or 
'').split())
-if required_distro_features:
-missing = set.difference(required_distro_features, distro_features)
-if missing:
-raise bb.parse.SkipRecipe("missing required distro feature%s '%s' 
(not in DISTRO_FEATURES)" % ('s' if len(missing) > 1 else '', ' 
'.join(missing)))
-
-conflict_distro_features = set((d.getVar('CONFLICT_DISTRO_FEATURES') or 
'').split())
-if conflict_distro_features:
-conflicts = set.intersection(conflict_distro_features, distro_features)
-if conflicts:
-raise bb.parse.SkipRecipe("conflicting distro feature%s '%s' (in 
DISTRO_FEATURES)" % ('s' if len(conflicts) > 1 else '', ' '.join(conflicts)))
-
-# Assume at least one var is set.
-machine_features = set((d.getVar('MACHINE_FEATURES') or '').split())
-
-any_of_machine_features = set((d.getVar('ANY_OF_MACHINE_FEATURES') or 
'').split())
-if any_of_machine_features:
-if set.isdisjoint(any_of_machine_features, machine_features):
-raise bb.parse.SkipRecipe("one of '%s' needs to be in 
MACHINE_FEATURES" % ' '.join(any_of_machine_features))
-
-required_machine_features = set((d.getVar('REQUIRED_MACHINE_FEATURES') or 
'').split())
-if required_machine_features:
-missing = set.difference(required_machine_features, machine_features)
-if missing:
-raise bb.parse.SkipRecipe("missing required machine feature%s '%s' 
(not in MACHINE_FEATURES)" % ('s' if len(missing) > 1 else '', ' 
'.join(missing)))
-
-conflict_machine_features = set((d.getVar('CONFLICT_MACHINE_FEATURES') or 
'').split())
-if conflict_machine_features:
-conflicts = set.intersection(conflict_machine_features, 
machine_features)
-if conflicts:
-raise bb.parse.SkipRecipe("conflicting machine feature%s '%s' (in 
MACHINE_FEATURES)" % ('s' if len(conflicts) > 1 else '', ' '.join(conflicts)))
-
-# Assume at least one var is set.
-combined_features =