[OE-core] ✗ patchtest: failure for glibc: don't ignore global LDFLAGS settings

2020-01-19 Thread Patchwork
== Series Details ==

Series: glibc: don't ignore global LDFLAGS settings
Revision: 1
URL   : https://patchwork.openembedded.org/series/22148/
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 1098fdf360)



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

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH] libva: upgrade 2.6.0 -> 2.6.1

2020-01-19 Thread Anuj Mittal
Also switch back to using the released tarballs.

Signed-off-by: Anuj Mittal 
---
 .../libva/{libva_2.6.0.bb => libva_2.6.1.bb}| 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
 rename meta/recipes-graphics/libva/{libva_2.6.0.bb => libva_2.6.1.bb} (87%)

diff --git a/meta/recipes-graphics/libva/libva_2.6.0.bb 
b/meta/recipes-graphics/libva/libva_2.6.1.bb
similarity index 87%
rename from meta/recipes-graphics/libva/libva_2.6.0.bb
rename to meta/recipes-graphics/libva/libva_2.6.1.bb
index d14e1911ad..92cea83bc1 100644
--- a/meta/recipes-graphics/libva/libva_2.6.0.bb
+++ b/meta/recipes-graphics/libva/libva_2.6.1.bb
@@ -17,9 +17,9 @@ SECTION = "x11"
 LICENSE = "MIT"
 LIC_FILES_CHKSUM = "file://COPYING;md5=2e48940f94acb0af582e5ef03537800f"
 
-SRC_URI = "git://github.com/intel/libva.git;branch=v2.6-branch"
-SRCREV = "5f693d9e603e0e83928cec67c30b6ac902d7aa85"
-S = "${WORKDIR}/git"
+SRC_URI = 
"https://github.com/intel/${BPN}/releases/download/${PV}/${BP}.tar.bz2;
+SRC_URI[md5sum] = "aef13eb48e01a47d1416d97462a22a11"
+SRC_URI[sha256sum] = 
"6c57eb642d828af2411aa38f55dc10111e8c98976dbab8fd62e48629401eaea5"
 
 UPSTREAM_CHECK_URI = "https://github.com/intel/libva/releases;
 
-- 
2.21.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH] glibc: don't ignore global LDFLAGS settings

2020-01-19 Thread Rasmus Villemoes
Two things: The -Wl,-rpath-link comment is stale (due to per-recipe
staging), so we no longer need to set our own LDFLAGS to avoid
-Wl,-rpath-link being in there. Second, overriding LDFLAGS should be
done at the recipe level so "bitbake -e" can show what is going on.
Otherwise debugging why one's global LDFLAGS tweaks are being ignored
is needlessly painful.

So pull out the LDFLAGS setting from do_compile, and change it to an
append instead of assignment.

For the benefit of future git blame: the -fuse-ld=bfd setting was
added by ac64c3b96b (glibc: always use bfd linker).

Signed-off-by: Rasmus Villemoes 
---
 meta/recipes-core/glibc/glibc_2.30.bb | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/meta/recipes-core/glibc/glibc_2.30.bb 
b/meta/recipes-core/glibc/glibc_2.30.bb
index 7913bc2812..c6dd78ca8b 100644
--- a/meta/recipes-core/glibc/glibc_2.30.bb
+++ b/meta/recipes-core/glibc/glibc_2.30.bb
@@ -93,9 +93,8 @@ do_configure () {
 CPPFLAGS="" oe_runconf
 }
 
+LDFLAGS += "-fuse-ld=bfd"
 do_compile () {
-   # -Wl,-rpath-link /lib in LDFLAGS can cause breakage if 
another glibc is in staging
-   LDFLAGS="-fuse-ld=bfd"
base_do_compile
echo "Adjust ldd script"
if [ -n "${RTLDLIST}" ]
-- 
2.23.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [zeus 5/5] license.bbclass: Introduce AVAILABLE_LICENSES that lists all licenses

2020-01-19 Thread Armin Kuster
From: Peter Kjellerstedt 

Previously, there was SRC_DISTRIBUTE_LICENSES, an undocumented
variable that contained a static list of licenses. It was used by
expand_wildcard_licenses() to expand any wildcards used in, e.g.,
INCOMPATIBLE_LICENSE. However, since this static list of licenses has
not been kept up-to-date, many licenses were missing, with the result
that if one tried to use any of those licenses with a wildcard, no
licenses would be found, effectively ignoring that they should be
marked as incompatible.

This introduces a new (documented) variable, AVAILABLE_LICENSES, that
is automatically updated to contain all licenses found in any
directories specified by ${COMMON_LICENSE_DIR} and ${LICENSE_PATH},
and uses it instead of SRC_DISTRIBUTE_LICENSES when expanding
wildcards.

Signed-off-by: Peter Kjellerstedt 
Signed-off-by: Richard Purdie 
(cherry picked from commit 8c9ef587fe499c612a878a1ab42092eb79b334ef)
Signed-off-by: Anuj Mittal 
---
 meta/classes/license.bbclass  | 27 ---
 meta/conf/documentation.conf  |  1 +
 .../oeqa/selftest/cases/incompatible_lic.py   |  6 ++---
 3 files changed, 27 insertions(+), 7 deletions(-)

diff --git a/meta/classes/license.bbclass b/meta/classes/license.bbclass
index adca881c85..b0d37b119c 100644
--- a/meta/classes/license.bbclass
+++ b/meta/classes/license.bbclass
@@ -252,7 +252,7 @@ def canonical_license(d, license):
 """
 Return the canonical (SPDX) form of the license if available (so GPLv3
 becomes GPL-3.0), for the license named 'X+', return canonical form of
-'X' if availabel and the tailing '+' (so GPLv3+ becomes GPL-3.0+), 
+'X' if available and the tailing '+' (so GPLv3+ becomes GPL-3.0+),
 or the passed license if there is no canonical form.
 """
 lic = d.getVarFlag('SPDXLICENSEMAP', license) or ""
@@ -262,10 +262,29 @@ def canonical_license(d, license):
 lic += '+'
 return lic or license
 
+def available_licenses(d):
+"""
+Return the available licenses by searching the directories specified by
+COMMON_LICENSE_DIR and LICENSE_PATH.
+"""
+lic_dirs = ((d.getVar('COMMON_LICENSE_DIR') or '') + ' ' +
+(d.getVar('LICENSE_PATH') or '')).split()
+
+licenses = []
+for lic_dir in lic_dirs:
+licenses += os.listdir(lic_dir)
+
+licenses = sorted(licenses)
+return licenses
+
+# Only determine the list of all available licenses once. This assumes that any
+# additions to LICENSE_PATH have been done before this file is parsed.
+AVAILABLE_LICENSES := "${@' '.join(available_licenses(d))}"
+
 def expand_wildcard_licenses(d, wildcard_licenses):
 """
-Return actual spdx format license names if wildcard used. We expand
-wildcards from SPDXLICENSEMAP flags and SRC_DISTRIBUTE_LICENSES values.
+Return actual spdx format license names if wildcards are used. We expand
+wildcards from SPDXLICENSEMAP flags and AVAILABLE_LICENSES.
 """
 import fnmatch
 licenses = wildcard_licenses[:]
@@ -274,7 +293,7 @@ def expand_wildcard_licenses(d, wildcard_licenses):
 spdxflags = fnmatch.filter(spdxmapkeys, wld_lic)
 licenses += [d.getVarFlag('SPDXLICENSEMAP', flag) for flag in 
spdxflags]
 
-spdx_lics = (d.getVar('SRC_DISTRIBUTE_LICENSES', False) or '').split()
+spdx_lics = d.getVar('AVAILABLE_LICENSES').split()
 for wld_lic in wildcard_licenses:
 licenses += fnmatch.filter(spdx_lics, wld_lic)
 
diff --git a/meta/conf/documentation.conf b/meta/conf/documentation.conf
index 550df20b0f..ce2a37e0e5 100644
--- a/meta/conf/documentation.conf
+++ b/meta/conf/documentation.conf
@@ -69,6 +69,7 @@ ASSUME_SHLIBS[doc] = "List of shlib:package[_version] 
mappings. Useful for lib p
 AUTHOR[doc] = "Email address used to contact the original author(s) in order 
to send patches and forward bugs."
 AUTO_SYSLINUXMENU[doc] = "Enables creating an automatic menu for the syslinux 
bootloader."
 AUTOREV[doc] = "When SRCREV is set to the value of this variable, it specifies 
to use the latest source revision in the repository."
+AVAILABLE_LICENSES[doc] = "List of licenses found in the directories specified 
by COMMON_LICENSE_DIR and LICENSE_PATH."
 
 #B
 
diff --git a/meta/lib/oeqa/selftest/cases/incompatible_lic.py 
b/meta/lib/oeqa/selftest/cases/incompatible_lic.py
index 8fb93af8a8..3cc5bbc35c 100644
--- a/meta/lib/oeqa/selftest/cases/incompatible_lic.py
+++ b/meta/lib/oeqa/selftest/cases/incompatible_lic.py
@@ -12,12 +12,12 @@ class IncompatibleLicenseTests(OESelftestTestCase):
 if error_msg not in result.output:
 raise AssertionError(result.output)
 
-# Verify that a package with an SPDX license (from SRC_DISTRIBUTE_LICENSES)
+# Verify that a package with an SPDX license (from AVAILABLE_LICENSES)
 # cannot be built when INCOMPATIBLE_LICENSE contains this SPDX license
 def test_incompatible_spdx_license(self):
 self.lic_test('incompatible-license', 

[OE-core] [zeus 4/5] licenses.conf: Remove the SRC_DISTRIBUTE_LICENSES variable

2020-01-19 Thread Armin Kuster
From: Peter Kjellerstedt 

The SRC_DISTRIBUTE_LICENSES variable and its static list of licenses
has been replaced by AVAILABLE_LICENSES, which automatically contains
all available licenses.

Signed-off-by: Peter Kjellerstedt 
Signed-off-by: Richard Purdie 
(cherry picked from commit 64daaf29e2c12c8b587bafdebf9409433187ddf7)
Signed-off-by: Anuj Mittal 
---
 meta/conf/licenses.conf | 43 -
 1 file changed, 43 deletions(-)

diff --git a/meta/conf/licenses.conf b/meta/conf/licenses.conf
index 7b01c57632..1c586a3bc6 100644
--- a/meta/conf/licenses.conf
+++ b/meta/conf/licenses.conf
@@ -1,44 +1,3 @@
-# These aren't actually used anywhere that I can tell
-# They may be in the future (or are used by someone else
-# For completion sake, I've updated them
-SRC_DISTRIBUTE_LICENSES += "AAL Adobe AFL-1.2 AFL-2.0 AFL-2.1 AFL-3.0"
-SRC_DISTRIBUTE_LICENSES += "AGPL-3.0 ANTLR-PD Apache-1.0 Apache-1.1 Apache-2.0"
-SRC_DISTRIBUTE_LICENSES += "APL-1.0 APSL-1.0 APSL-1.1 APSL-1.2 APSL-2.0"
-SRC_DISTRIBUTE_LICENSES += "Artistic-1.0 Artistic-2.0 BitstreamVera BSD"
-SRC_DISTRIBUTE_LICENSES += "BSD-2-Clause BSD-3-Clause BSD-4-Clause BSL-1.0"
-SRC_DISTRIBUTE_LICENSES += "CATOSL-1.1 CC0-1.0 CC-BY-1.0 CC-BY-2.0 CC-BY-2.5"
-SRC_DISTRIBUTE_LICENSES += "CC-BY-3.0 CC-BY-NC-1.0 CC-BY-NC-2.0 CC-BY-NC-2.5"
-SRC_DISTRIBUTE_LICENSES += "CC-BY-NC-3.0 CC-BY-NC-ND-1.0 CC-BY-NC-ND-2.0"
-SRC_DISTRIBUTE_LICENSES += "CC-BY-NC-ND-2.5 CC-BY-NC-ND-3.0 CC-BY-NC-SA-1.0"
-SRC_DISTRIBUTE_LICENSES += "CC-BY-NC-SA-2.0 CC-BY-NC-SA-2.5 CC-BY-NC-SA-3.0"
-SRC_DISTRIBUTE_LICENSES += "CC-BY-ND-1.0 CC-BY-ND-2.0 CC-BY-ND-2.5 
CC-BY-ND-3.0"
-SRC_DISTRIBUTE_LICENSES += "CC-BY-SA-1.0 CC-BY-SA-2.0 CC-BY-SA-2.5 
CC-BY-SA-3.0 CC-BY-SA-4.0"
-SRC_DISTRIBUTE_LICENSES += "CDDL-1.0 CECILL-1.0 CECILL-2.0 CECILL-B CECILL-C"
-SRC_DISTRIBUTE_LICENSES += "ClArtistic CPAL-1.0 CPL-1.0 CUA-OPL-1.0 DSSSL"
-SRC_DISTRIBUTE_LICENSES += "ECL-1.0 ECL-2.0 eCos-2.0 EDL-1.0 EFL-1.0 EFL-2.0"
-SRC_DISTRIBUTE_LICENSES += "Entessa EPL-1.0 EPL-2.0 ErlPL-1.1"
-SRC_DISTRIBUTE_LICENSES += "EUDatagrid EUPL-1.0 EUPL-1.1 Fair Frameworx-1.0"
-SRC_DISTRIBUTE_LICENSES += "FreeType GFDL-1.1 GFDL-1.2 GFDL-1.3 GPL-1.0"
-SRC_DISTRIBUTE_LICENSES += "GPL-2.0 GPL-2.0-with-autoconf-exception"
-SRC_DISTRIBUTE_LICENSES += "GPL-2.0-with-classpath-exception"
-SRC_DISTRIBUTE_LICENSES += "GPL-2.0-with-font-exception"
-SRC_DISTRIBUTE_LICENSES += "GPL-2.0-with-GCC-exception"
-SRC_DISTRIBUTE_LICENSES += "GPL-2-with-bison-exception GPL-3.0"
-SRC_DISTRIBUTE_LICENSES += "GPL-3.0-with-autoconf-exception"
-SRC_DISTRIBUTE_LICENSES += "GPL-3.0-with-GCC-exception"
-SRC_DISTRIBUTE_LICENSES += "gSOAP-1 gSOAP-1.3b HPND IPA IPL-1.0 ISC LGPL-2.0"
-SRC_DISTRIBUTE_LICENSES += "LGPL-2.1 LGPL-3.0 Libpng LPL-1.02 LPPL-1.0 
LPPL-1.1"
-SRC_DISTRIBUTE_LICENSES += "LPPL-1.2 LPPL-1.3c MirOS MIT Motosoto MPL-1.0"
-SRC_DISTRIBUTE_LICENSES += "MPL-1.1 MS-PL MS-RL Multics NASA-1.3 Nauman NCSA"
-SRC_DISTRIBUTE_LICENSES += "NGPL Nokia NPOSL-3.0 NTP OASIS OCLC-2.0 ODbL-1.0"
-SRC_DISTRIBUTE_LICENSES += "OFL-1.1 OGTSL OLDAP-2.8 OpenSSL OSL-1.0 OSL-2.0"
-SRC_DISTRIBUTE_LICENSES += "OSL-3.0 PD PHP-3.0 PostgreSQL Proprietary"
-SRC_DISTRIBUTE_LICENSES += "Python-2.0 QPL-1.0 RHeCos-1 RHeCos-1.1 RPL-1.5"
-SRC_DISTRIBUTE_LICENSES += "RPSL-1.0 RSCPL Ruby SAX-PD SGI-1 Simple-2.0 
Sleepycat"
-SRC_DISTRIBUTE_LICENSES += "SPL-1.0 SugarCRM-1 SugarCRM-1.1.3 UCB VSL-1.0 W3C"
-SRC_DISTRIBUTE_LICENSES += "Watcom-1.0 WXwindows XFree86-1.0 XFree86-1.1 Xnet 
XSL YPL-1.1"
-SRC_DISTRIBUTE_LICENSES += "Zimbra-1.3 Zlib ZPL-1.1 ZPL-2.0 ZPL-2.1"
-
 # Standards are great! Everyone has their own. In an effort to standardize 
licensing
 # names, common-licenses will use the SPDX standard license names. In order to 
not
 # break the non-standardized license names that we find in LICENSE, we'll set
@@ -188,5 +147,3 @@ FOSS_BASE_URL = 
"http://localhost/repo/?mod=spdx_license_once;
 FOSS_SERVER = 
"${FOSS_BASE_URL}=${FOSS_FULL_SPDX}=${FOSS_NO_COPYRIGHT}=${FOSS_RECURSIVE_UNPACK}"
 
 FOSS_WGET_FLAGS = "-qO - --no-check-certificate --timeout=0"
-
-
-- 
2.17.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [zeus 3/5] sanity.bbclass: Move sanity_info from conf to cache

2020-01-19 Thread Armin Kuster
From: Peter Kjellerstedt 

Since this file is written during recipe parsing, having it in the
${BUILDDIR}/conf directory, which is covered by an inotify watcher,
will trigger a re-parse the next time bitbake is run and the resident
bitbake server is enabled. This causes the sanity_info file to be
updated again, which triggers a new parse the next time bitbake is run
ad infinitum. Moving it to ${BUILDDIR}/cache should avoid this.

Signed-off-by: Peter Kjellerstedt 
Signed-off-by: Richard Purdie 
(cherry picked from commit f98103b548aa7dba6b1be6c8e02ef41858a8e85c)
Signed-off-by: Anuj Mittal 
---
 meta/classes/sanity.bbclass | 2 +-
 meta/lib/oeqa/buildperf/base.py | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/classes/sanity.bbclass b/meta/classes/sanity.bbclass
index 9d0c784032..936fe913b4 100644
--- a/meta/classes/sanity.bbclass
+++ b/meta/classes/sanity.bbclass
@@ -927,7 +927,7 @@ def check_sanity(sanity_data):
 last_tmpdir = ""
 last_sstate_dir = ""
 last_nativelsbstr = ""
-sanityverfile = sanity_data.expand("${TOPDIR}/conf/sanity_info")
+sanityverfile = sanity_data.expand("${TOPDIR}/cache/sanity_info")
 if os.path.exists(sanityverfile):
 with open(sanityverfile, 'r') as f:
 for line in f:
diff --git a/meta/lib/oeqa/buildperf/base.py b/meta/lib/oeqa/buildperf/base.py
index 3b2fed549f..5f1805d86c 100644
--- a/meta/lib/oeqa/buildperf/base.py
+++ b/meta/lib/oeqa/buildperf/base.py
@@ -462,7 +462,7 @@ class BuildPerfTestCase(unittest.TestCase):
 def rm_tmp(self):
 """Cleanup temporary/intermediate files and directories"""
 log.debug("Removing temporary and cache files")
-for name in ['bitbake.lock', 'conf/sanity_info',
+for name in ['bitbake.lock', 'cache/sanity_info',
  self.bb_vars['TMPDIR']]:
 oe.path.remove(name, recurse=True)
 
-- 
2.17.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [zeus 0/5] More patches for review.

2020-01-19 Thread Armin Kuster
Here are somemore patches that where also tested and needing review.
Please have feedback by Tuesday.


The following changes since commit f9739e0f58f5d8a5dc01fdb0efaa778af4edd671:

  kernel: Make symbol link to vmlinux.64 in boot directory (2020-01-08 20:33:12 
-0800)

are available in the Git repository at:

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

Peter Kjellerstedt (5):
  toaster.bbclass: Correct pkgdatadir path in toaster_package_dumpdata()
  populate_sdk_ext.bbclass: No longer needed to clean away
conf/sanity_info
  sanity.bbclass: Move sanity_info from conf to cache
  licenses.conf: Remove the SRC_DISTRIBUTE_LICENSES variable
  license.bbclass: Introduce AVAILABLE_LICENSES that lists all licenses

 meta/classes/license.bbclass  | 27 ++--
 meta/classes/populate_sdk_ext.bbclass |  2 +-
 meta/classes/sanity.bbclass   |  2 +-
 meta/classes/toaster.bbclass  | 15 +--
 meta/conf/documentation.conf  |  1 +
 meta/conf/licenses.conf   | 43 ---
 meta/lib/oeqa/buildperf/base.py   |  2 +-
 .../oeqa/selftest/cases/incompatible_lic.py   |  6 +--
 8 files changed, 41 insertions(+), 57 deletions(-)

-- 
2.17.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [zeus 1/5] toaster.bbclass: Correct pkgdatadir path in toaster_package_dumpdata()

2020-01-19 Thread Armin Kuster
From: Peter Kjellerstedt 

In commit 692b2046 (package: Fix race between do_package and
do_packagedata), the path used for do_packagedata[sstate-inputdirs]
was changed from "${PKGDESTWORK}" to "${WORKDIR}/pkgdata-pdata-input".
This commit adapts the path used for pkgdatadir in
toaster_package_dumpdata() accordingly to avoid setscene errors like:

  ERROR: libgcc-9.2.0-r0 do_packagedata_setscene: Error executing a
  python function in exec_python_func() autogenerated:

  The stack trace of python calls that resulted in this
  exception/failure was:
  File: 'exec_python_func() autogenerated', lineno: 2, function:
  
   0001:
   *** 0002:toaster_package_dumpdata(d)
   0003:
  File: 'meta/classes/toaster.bbclass', lineno: 130, function:
  toaster_package_dumpdata
   0126:lpkgdata = {}
   0127:datadir = os.path.join(pkgdatadir, 'runtime')
   0128:
   0129:# scan and send data for each generated package
   *** 0130:for datafile in os.listdir(datadir):
   0131:if not datafile.endswith('.packaged'):
   0132:lpkgdata = _toaster_load_pkgdatafile(datadir,
   0133:# Fire an event containing the pkg data
   0134:bb.event.fire(bb.event.MetadataEvent(
  Exception: FileNotFoundError: [Errno 2] No such file or directory:
  'tmp/work/mips32r2el-nf-poky-linux/libgcc/9.2.0-r0/pkgdata/runtime'

Signed-off-by: Peter Kjellerstedt 
Signed-off-by: Richard Purdie 
(cherry picked from commit 5a0f6f631b86f7107aa72453b6d23f32ba39f713)
Signed-off-by: Anuj Mittal 
---
 meta/classes/toaster.bbclass | 15 +++
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/meta/classes/toaster.bbclass b/meta/classes/toaster.bbclass
index 6cef0b8f6e..6a65ecb957 100644
--- a/meta/classes/toaster.bbclass
+++ b/meta/classes/toaster.bbclass
@@ -113,7 +113,7 @@ def _toaster_load_pkgdatafile(dirpath, filepath):
 pass# ignore lines without valid key: value pairs
 return pkgdata
 
-python toaster_package_dumpdata() {
+def _toaster_dumpdata(pkgdatadir, d):
 """
 Dumps the data about the packages created by a recipe
 """
@@ -122,7 +122,6 @@ python toaster_package_dumpdata() {
 if not d.getVar('PACKAGES'):
 return
 
-pkgdatadir = d.getVar('PKGDESTWORK')
 lpkgdata = {}
 datadir = os.path.join(pkgdatadir, 'runtime')
 
@@ -132,6 +131,14 @@ python toaster_package_dumpdata() {
 lpkgdata = _toaster_load_pkgdatafile(datadir, datafile)
 # Fire an event containing the pkg data
 bb.event.fire(bb.event.MetadataEvent("SinglePackageInfo", 
lpkgdata), d)
+
+python toaster_package_dumpdata() {
+_toaster_dumpdata(d.getVar('PKGDESTWORK'), d)
+}
+
+python toaster_packagedata_dumpdata() {
+# This path needs to match do_packagedata[sstate-inputdirs]
+_toaster_dumpdata(os.path.join(d.getVar('WORKDIR'), 
'pkgdata-pdata-input'), d)
 }
 
 # 2. Dump output image files information
@@ -366,8 +373,8 @@ toaster_buildhistory_dump[eventmask] = 
"bb.event.BuildCompleted"
 addhandler toaster_artifacts
 toaster_artifacts[eventmask] = "bb.runqueue.runQueueTaskSkipped 
bb.runqueue.runQueueTaskCompleted"
 
-do_packagedata_setscene[postfuncs] += "toaster_package_dumpdata "
-do_packagedata_setscene[vardepsexclude] += "toaster_package_dumpdata "
+do_packagedata_setscene[postfuncs] += "toaster_packagedata_dumpdata "
+do_packagedata_setscene[vardepsexclude] += "toaster_packagedata_dumpdata "
 
 do_package[postfuncs] += "toaster_package_dumpdata "
 do_package[vardepsexclude] += "toaster_package_dumpdata "
-- 
2.17.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [zeus 2/5] populate_sdk_ext.bbclass: No longer needed to clean away conf/sanity_info

2020-01-19 Thread Armin Kuster
From: Peter Kjellerstedt 

Since the sanity_info file has moved from the conf directory to the
cache directory, there is no longer any need to clean it away
explicitly in clean_esdk_builddir() since the whole cache directory is
already cleaned away anyway.

Signed-off-by: Peter Kjellerstedt 
Signed-off-by: Richard Purdie 
(cherry picked from commit 40c30990e1be72130819c040fe471e2bdc0c6e7d)
Signed-off-by: Anuj Mittal 
---
 meta/classes/populate_sdk_ext.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/populate_sdk_ext.bbclass 
b/meta/classes/populate_sdk_ext.bbclass
index 9fda1c9e78..5657af4b6a 100644
--- a/meta/classes/populate_sdk_ext.bbclass
+++ b/meta/classes/populate_sdk_ext.bbclass
@@ -122,7 +122,7 @@ SDK_TITLE_task-populate-sdk-ext = 
"${@d.getVar('DISTRO_NAME') or d.getVar('DISTR
 def clean_esdk_builddir(d, sdkbasepath):
 """Clean up traces of the fake build for create_filtered_tasklist()"""
 import shutil
-cleanpaths = 'cache conf/sanity_info tmp'.split()
+cleanpaths = ['cache', 'tmp']
 for pth in cleanpaths:
 fullpth = os.path.join(sdkbasepath, pth)
 if os.path.isdir(fullpth):
-- 
2.17.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] WiFi network failure after updating thud to zeus

2020-01-19 Thread JH
Hi,

I sent following message several days ago, the problem is that connman
sent DHCP request messages but no DHCP response received, something is
got wrong in network, could anyone advise what have been changed in
zeus?

I saw another email of eth failure after updating from thud to zeus, I
am not clear if it is the same problem of DHCP response or not, but
seems something is going on in zeus, appreciate your kindly advice.

Thank you.

Kind regards,

- jh

On 1/16/20, JH  wrote:
> Hi,
>
> I was using thud version to build image to run on imx6, it was working
> perfectly except I was told a bug in connman version 3.15, I need to
> build connman version 3.17. I could hot use thud to build connman
> 3.17, so I upgraded Yocto to zeus.
>
> After installing new image built from zeus, now I have a very weird
> WiFi network problem, it could not get IP address from WiFi router
> DHCP initially, after a while, the WiFi got an IP address
> 169.254.203.142 which is not my WiFi router subnet 192.168.0.x, it
> could not connect to the Internet either.
>
> My first suspicion was the new updated connman version 3.17, but when
> replaced connman 3.17 to connman 3.15 in an old version system which
> image was built from thud, it was no problem at all. Apparently
> something got wrong in the image built from zeus. Has anyone aware of
> that issue?
>
> Thank you.
>
> Kind regards,
>
> - jh
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH 04/12] gstreamer1.0-plugins-good: Transition to meson based builds

2020-01-19 Thread Mittal, Anuj
On Sun, 2020-01-12 at 14:59 +0100, Carlos Rafael Giani wrote:
>  # qt5 support is disabled, because it is not present in OE core, and
> requires more work than
>  # just adding a packageconfig (it requires access to moc, uic, rcc,
> and qmake paths).
> @@ -58,19 +56,18 @@ PACKAGECONFIG[zlib]   = "--enable-zlib,
> --disable-zlib,zlib"
>  # in a gstreamer1.0-plugins-good bbappend).
>  
>  EXTRA_OECONF += " \

This should have been EXTRA_OEMESON.

> ---enable-oss \
> ---disable-aalib \
> ---disable-aalibtest \
> ---disable-directsound \
> ---disable-libcaca \
> ---disable-libdv \
> ---disable-oss4 \
> ---disable-osx_audio \
> ---disable-osx_video \
> ---disable-qt \
> ---disable-shout2 \
> ---disable-twolame \
> ---disable-waveform \
> +-Daalib=disabled \
> +-Ddirectsound=disabled \
> +-Ddv=disabled \
> +-Dlibcaca=disabled \
> +-Doss=enabled \
> +-Doss4=disabled \
> +-Dosxaudio=disabled \
> +-Dosxvideo=disabled \
> +-Dqt=disabled \

and this should be qt5?

Thanks,

Anuj
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] ✗ patchtest: failure for Open file with O_CLOEXEC to avoid fd leak (rev3)

2020-01-19 Thread Yu, Mingli



On 01/20/20 11:15, Peter Kjellerstedt wrote:

-Original Message-
From: Yu, Mingli 
Sent: den 20 januari 2020 04:04
To: Peter Kjellerstedt ; Paul Eggleton

Cc: openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] ✗ patchtest: failure for Open file with O_CLOEXEC
to avoid fd leak (rev3)

On 01/20/20 10:28, Peter Kjellerstedt wrote:

-Original Message-
From: openembedded-core-boun...@lists.openembedded.org 
core-

boun...@lists.openembedded.org> On Behalf Of Yu, Mingli
Sent: den 20 januari 2020 02:34
To: Paul Eggleton 
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] ✗ patchtest: failure for Open file with

O_CLOEXEC

to avoid fd leak (rev3)

On 01/20/20 09:29, Paul Eggleton wrote:

Hi Mingli

On Sunday, 19 January 2020 6:41:49 PM NZDT Yu, Mingli wrote:

On 01/19/20 13:32, Patchwork wrote:

== Series Details ==

Series: Open file with O_CLOEXEC to avoid fd leak (rev3)
Revision: 3
URL   : https://patchwork.openembedded.org/series/22123/
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 9d7a521971)


Have already rebased on the master branch of
http://git.yoctoproject.org/cgit/cgit.cgi/pseudo/, why still issue

out

the above issue? Any hint?


It's assuming that patches sent to this list are for OE-Core (which

they

generally are). I wasn't aware but apparently the documented place to
send pseudo patches is this list, so I think in this case you can just
ignore patchtest.


Okay, many thanks Paul for your hint!

Thanks,



Cheers,
Paul


But it is probably a good idea to include a "[pseudo]" tag in the

subject

when sending patches related to pseudo to this list, as the expectation
otherwise is that they are for OE-Core.


Thanks Peter! And already add the "pseudo_util.c" tag in the subject in
the v3, please check the mail with the subject "[OE-core] [PATCH v3]
pseudo_util.c: Open file with O_CLOEXEC to avoid fd leak".


That is not the same. The "pseudo_util.c:" is part of the commit subject
and will end up in the Git repository. A "[pseudo]" tag is for anyone
seeing the mail (possibly including patchwork and patchtest), letting
them know that this commit is about pseudo, not OE-Core (similar to the
"[PATCH v3]" tag, which is also information about the commit).


Got it! V4 is incoming.

Thanks,




Thanks,


//Peter


//Peter


--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [pseudo v4] pseudo_util.c: Open file with O_CLOEXEC to avoid fd leak

2020-01-19 Thread mingli.yu
From: Pavel Modilaynen 

Use close-on-exec (O_CLOEXEC) flag when open log file to
make sure its file descriptor is not leaked to parent
process on fork/exec.

Signed-off-by: Mingli Yu 
---
 pseudo_util.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/pseudo_util.c b/pseudo_util.c
index c867ed6..0ec527b 100644
--- a/pseudo_util.c
+++ b/pseudo_util.c
@@ -1594,7 +1594,7 @@ pseudo_logfile(char *filename, char *defname, int 
prefer_fd) {
}
free(filename);
}   
-   fd = open(pseudo_path, O_WRONLY | O_APPEND | O_CREAT, 0644);
+   fd = open(pseudo_path, O_WRONLY | O_APPEND | O_CREAT | O_CLOEXEC, 0644);
if (fd == -1) {
pseudo_diag("help: can't open log file %s: %s\n", pseudo_path, 
strerror(errno));
} else {
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] ✗ patchtest: failure for Open file with O_CLOEXEC to avoid fd leak (rev3)

2020-01-19 Thread Peter Kjellerstedt
> -Original Message-
> From: Yu, Mingli 
> Sent: den 20 januari 2020 04:04
> To: Peter Kjellerstedt ; Paul Eggleton
> 
> Cc: openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] ✗ patchtest: failure for Open file with O_CLOEXEC
> to avoid fd leak (rev3)
> 
> On 01/20/20 10:28, Peter Kjellerstedt wrote:
> >> -Original Message-
> >> From: openembedded-core-boun...@lists.openembedded.org  core-
> >> boun...@lists.openembedded.org> On Behalf Of Yu, Mingli
> >> Sent: den 20 januari 2020 02:34
> >> To: Paul Eggleton 
> >> Cc: openembedded-core@lists.openembedded.org
> >> Subject: Re: [OE-core] ✗ patchtest: failure for Open file with
> O_CLOEXEC
> >> to avoid fd leak (rev3)
> >>
> >> On 01/20/20 09:29, Paul Eggleton wrote:
> >>> Hi Mingli
> >>>
> >>> On Sunday, 19 January 2020 6:41:49 PM NZDT Yu, Mingli wrote:
>  On 01/19/20 13:32, Patchwork wrote:
> > == Series Details ==
> >
> > Series: Open file with O_CLOEXEC to avoid fd leak (rev3)
> > Revision: 3
> > URL   : https://patchwork.openembedded.org/series/22123/
> > 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 9d7a521971)
> 
>  Have already rebased on the master branch of
>  http://git.yoctoproject.org/cgit/cgit.cgi/pseudo/, why still issue
> out
>  the above issue? Any hint?
> >>>
> >>> It's assuming that patches sent to this list are for OE-Core (which
> they
> >>> generally are). I wasn't aware but apparently the documented place to
> >>> send pseudo patches is this list, so I think in this case you can just
> >>> ignore patchtest.
> >>
> >> Okay, many thanks Paul for your hint!
> >>
> >> Thanks,
> >>
> >>>
> >>> Cheers,
> >>> Paul
> >
> > But it is probably a good idea to include a "[pseudo]" tag in the
> subject
> > when sending patches related to pseudo to this list, as the expectation
> > otherwise is that they are for OE-Core.
> 
> Thanks Peter! And already add the "pseudo_util.c" tag in the subject in
> the v3, please check the mail with the subject "[OE-core] [PATCH v3]
> pseudo_util.c: Open file with O_CLOEXEC to avoid fd leak".

That is not the same. The "pseudo_util.c:" is part of the commit subject 
and will end up in the Git repository. A "[pseudo]" tag is for anyone 
seeing the mail (possibly including patchwork and patchtest), letting 
them know that this commit is about pseudo, not OE-Core (similar to the 
"[PATCH v3]" tag, which is also information about the commit).

> Thanks,
> 
> > //Peter

//Peter

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] ✗ patchtest: failure for Open file with O_CLOEXEC to avoid fd leak (rev3)

2020-01-19 Thread Yu, Mingli



On 01/20/20 10:28, Peter Kjellerstedt wrote:

-Original Message-
From: openembedded-core-boun...@lists.openembedded.org  On Behalf Of Yu, Mingli
Sent: den 20 januari 2020 02:34
To: Paul Eggleton 
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] ✗ patchtest: failure for Open file with O_CLOEXEC
to avoid fd leak (rev3)

On 01/20/20 09:29, Paul Eggleton wrote:

Hi Mingli

On Sunday, 19 January 2020 6:41:49 PM NZDT Yu, Mingli wrote:

On 01/19/20 13:32, Patchwork wrote:

== Series Details ==

Series: Open file with O_CLOEXEC to avoid fd leak (rev3)
Revision: 3
URL   : https://patchwork.openembedded.org/series/22123/
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 9d7a521971)


Have already rebased on the master branch of
http://git.yoctoproject.org/cgit/cgit.cgi/pseudo/, why still issue out
the above issue? Any hint?


It's assuming that patches sent to this list are for OE-Core (which they
generally are). I wasn't aware but apparently the documented place to
send pseudo patches is this list, so I think in this case you can just
ignore patchtest.


Okay, many thanks Paul for your hint!

Thanks,



Cheers,
Paul


But it is probably a good idea to include a "[pseudo]" tag in the subject
when sending patches related to pseudo to this list, as the expectation
otherwise is that they are for OE-Core.


Thanks Peter! And already add the "pseudo_util.c" tag in the subject in 
the v3, please check the mail with the subject "[OE-core] [PATCH v3] 
pseudo_util.c: Open file with O_CLOEXEC to avoid fd leak".


Thanks,



//Peter


--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] ✗ patchtest: failure for Open file with O_CLOEXEC to avoid fd leak (rev3)

2020-01-19 Thread Peter Kjellerstedt
> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org  boun...@lists.openembedded.org> On Behalf Of Yu, Mingli
> Sent: den 20 januari 2020 02:34
> To: Paul Eggleton 
> Cc: openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] ✗ patchtest: failure for Open file with O_CLOEXEC
> to avoid fd leak (rev3)
> 
> On 01/20/20 09:29, Paul Eggleton wrote:
> > Hi Mingli
> >
> > On Sunday, 19 January 2020 6:41:49 PM NZDT Yu, Mingli wrote:
> >> On 01/19/20 13:32, Patchwork wrote:
> >>> == Series Details ==
> >>>
> >>> Series: Open file with O_CLOEXEC to avoid fd leak (rev3)
> >>> Revision: 3
> >>> URL   : https://patchwork.openembedded.org/series/22123/
> >>> 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 9d7a521971)
> >>
> >> Have already rebased on the master branch of
> >> http://git.yoctoproject.org/cgit/cgit.cgi/pseudo/, why still issue out
> >> the above issue? Any hint?
> >
> > It's assuming that patches sent to this list are for OE-Core (which they
> > generally are). I wasn't aware but apparently the documented place to
> > send pseudo patches is this list, so I think in this case you can just
> > ignore patchtest.
> 
> Okay, many thanks Paul for your hint!
> 
> Thanks,
> 
> >
> > Cheers,
> > Paul

But it is probably a good idea to include a "[pseudo]" tag in the subject 
when sending patches related to pseudo to this list, as the expectation 
otherwise is that they are for OE-Core.

//Peter
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] ✗ patchtest: failure for Open file with O_CLOEXEC to avoid fd leak (rev3)

2020-01-19 Thread Paul Eggleton
Hi Mingli

On Sunday, 19 January 2020 6:41:49 PM NZDT Yu, Mingli wrote:
> On 01/19/20 13:32, Patchwork wrote:
> > == Series Details ==
> >
> > Series: Open file with O_CLOEXEC to avoid fd leak (rev3)
> > Revision: 3
> > URL   : https://patchwork.openembedded.org/series/22123/
> > 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 9d7a521971)
> 
> Have already rebased on the master branch of 
> http://git.yoctoproject.org/cgit/cgit.cgi/pseudo/, why still issue out 
> the above issue? Any hint?

It's assuming that patches sent to this list are for OE-Core (which they
generally are). I wasn't aware but apparently the documented place to
send pseudo patches is this list, so I think in this case you can just ignore
patchtest.

Cheers,
Paul

-- 

Paul Eggleton
Intel System Software Products


-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] ✗ patchtest: failure for Open file with O_CLOEXEC to avoid fd leak (rev3)

2020-01-19 Thread Yu, Mingli




On 01/20/20 09:29, Paul Eggleton wrote:

Hi Mingli

On Sunday, 19 January 2020 6:41:49 PM NZDT Yu, Mingli wrote:

On 01/19/20 13:32, Patchwork wrote:

== Series Details ==

Series: Open file with O_CLOEXEC to avoid fd leak (rev3)
Revision: 3
URL   : https://patchwork.openembedded.org/series/22123/
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 9d7a521971)


Have already rebased on the master branch of
http://git.yoctoproject.org/cgit/cgit.cgi/pseudo/, why still issue out
the above issue? Any hint?


It's assuming that patches sent to this list are for OE-Core (which they
generally are). I wasn't aware but apparently the documented place to
send pseudo patches is this list, so I think in this case you can just ignore
patchtest.


Okay, many thanks Paul for your hint!

Thanks,



Cheers,
Paul


--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH] gcc-configure: Enable the use of different symbol versioning

2020-01-19 Thread Alejandro Enedino Hernandez Samaniego
Hey Khem,

On Sun, Jan 19, 2020, 4:22 PM Khem Raj  wrote:

> On Sat, Jan 18, 2020 at 7:02 PM Alejandro Enedino Hernandez Samaniego
>  wrote:
> >
> > While the gnu style for symbol versioning is the most usual,
> > --enable-symvers[=style] can be provided several values,
> > gnu, gnu-versioned-namespace, darwin, darwin-export, and sun,
> > depending on users needs.
> >
> > Introduce the SYMVERS_CONF variable to allow the user to
> > configure the symbol versioning in shared libraries.
> >
> > Signed-off-by: Alejandro Enedino Hernandez Samaniego <
> alejan...@enedino.org>
> > ---
> >  meta/recipes-devtools/gcc/gcc-configure-common.inc | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/meta/recipes-devtools/gcc/gcc-configure-common.inc
> b/meta/recipes-devtools/gcc/gcc-configure-common.inc
> > index 24ba8ce..bb4f692 100644
> > --- a/meta/recipes-devtools/gcc/gcc-configure-common.inc
> > +++ b/meta/recipes-devtools/gcc/gcc-configure-common.inc
> > @@ -17,6 +17,8 @@ GCCTHREADS ?= "posix"
> >
> >  GCCPIE ??= ""
> >
> > +SYMVERS_CONF ?= "--enable-symvers=gnu"
> > +
>
> just turn the RHS into variable not full option
>

I did think about that, and I can do it, but I think I would have to also
create a PACKAGECONFIG and since AFAIC no one is changing the style I'm not
sure it's worth the complication of the code, and this still allows us to
remove the enablement entirely, not just changing the style.

Alejandro


> >  EXTRA_OECONF = "\
> >  ${@['--enable-clocale=generic', ''][d.getVar('USE_NLS') != 'no']} \
> >  --with-gnu-ld \
> > @@ -27,7 +29,7 @@ EXTRA_OECONF = "\
> >  ${GCCPIE} \
> >  --enable-c99 \
> >  --enable-long-long \
> > ---enable-symvers=gnu \
> > +${SYMVERS_CONF} \
> >  --enable-libstdcxx-pch \
> >  --program-prefix=${TARGET_PREFIX} \
> >  --without-local-prefix \
> > --
> > 2.7.4
> >
> > --
> > ___
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH] gcc-configure: Enable the use of different symbol versioning

2020-01-19 Thread Khem Raj
On Sat, Jan 18, 2020 at 7:02 PM Alejandro Enedino Hernandez Samaniego
 wrote:
>
> While the gnu style for symbol versioning is the most usual,
> --enable-symvers[=style] can be provided several values,
> gnu, gnu-versioned-namespace, darwin, darwin-export, and sun,
> depending on users needs.
>
> Introduce the SYMVERS_CONF variable to allow the user to
> configure the symbol versioning in shared libraries.
>
> Signed-off-by: Alejandro Enedino Hernandez Samaniego 
> ---
>  meta/recipes-devtools/gcc/gcc-configure-common.inc | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/meta/recipes-devtools/gcc/gcc-configure-common.inc 
> b/meta/recipes-devtools/gcc/gcc-configure-common.inc
> index 24ba8ce..bb4f692 100644
> --- a/meta/recipes-devtools/gcc/gcc-configure-common.inc
> +++ b/meta/recipes-devtools/gcc/gcc-configure-common.inc
> @@ -17,6 +17,8 @@ GCCTHREADS ?= "posix"
>
>  GCCPIE ??= ""
>
> +SYMVERS_CONF ?= "--enable-symvers=gnu"
> +

just turn the RHS into variable not full option

>  EXTRA_OECONF = "\
>  ${@['--enable-clocale=generic', ''][d.getVar('USE_NLS') != 'no']} \
>  --with-gnu-ld \
> @@ -27,7 +29,7 @@ EXTRA_OECONF = "\
>  ${GCCPIE} \
>  --enable-c99 \
>  --enable-long-long \
> ---enable-symvers=gnu \
> +${SYMVERS_CONF} \
>  --enable-libstdcxx-pch \
>  --program-prefix=${TARGET_PREFIX} \
>  --without-local-prefix \
> --
> 2.7.4
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] ✗ patchtest: failure for "vim: Add missing xgd-mime inhe..." and 1 more

2020-01-19 Thread Patchwork
== Series Details ==

Series: "vim: Add missing xgd-mime inhe..." and 1 more
Revision: 1
URL   : https://patchwork.openembedded.org/series/22142/
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 1098fdf360)



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

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH 1/2] vim: Add missing xgd-mime inherit

2020-01-19 Thread Richard Purdie
Resolves:
WARNING: vim-8.2-r0 do_package_qa: QA Issue: package contains desktop
file with key 'MimeType' but does not inhert mime-xdg: vim path
'/work/core2-32-poky-linux/vim/8.2-r0/packages-split/vim/usr/share/applications/vim.desktop'

Signed-off-by: Richard Purdie 
---
 meta/recipes-support/vim/vim.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-support/vim/vim.inc b/meta/recipes-support/vim/vim.inc
index e0673a7810e..78e3f9528d2 100644
--- a/meta/recipes-support/vim/vim.inc
+++ b/meta/recipes-support/vim/vim.inc
@@ -21,7 +21,7 @@ S = "${WORKDIR}/git"
 
 VIMDIR = "vim${@d.getVar('PV').split('.')[0]}${@d.getVar('PV').split('.')[1]}"
 
-inherit autotools-brokensep update-alternatives
+inherit autotools-brokensep update-alternatives mime-xdg
 
 CLEANBROKEN = "1"
 
-- 
2.20.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH 2/2] epiphany: Add missing xgd-mime inherit

2020-01-19 Thread Richard Purdie
Resolves:
ARNING: epiphany-3.34.2-r0 do_package_qa: QA Issue: package contains desktop
file with key 'MimeType' but does not inhert mime-xdg: epiphany path
'/work/core2-32-poky-linux/epiphany/3.34.2-r0/packages-split/epiphany
/usr/share/applications/org.gnome.Epiphany.desktop' [mime-xdg]

Signed-off-by: Richard Purdie 
---
 meta/recipes-gnome/epiphany/epiphany_3.34.2.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-gnome/epiphany/epiphany_3.34.2.bb 
b/meta/recipes-gnome/epiphany/epiphany_3.34.2.bb
index a196a217dcc..c6105b97066 100644
--- a/meta/recipes-gnome/epiphany/epiphany_3.34.2.bb
+++ b/meta/recipes-gnome/epiphany/epiphany_3.34.2.bb
@@ -8,7 +8,7 @@ DEPENDS = "libsoup-2.4 webkitgtk gtk+3 iso-codes avahi 
libnotify gcr \
   glib-2.0 glib-2.0-native json-glib libdazzle"
 
 GNOMEBASEBUILDCLASS = "meson"
-inherit gnomebase gsettings features_check upstream-version-is-even gettext
+inherit gnomebase gsettings features_check upstream-version-is-even gettext 
mime-xdg
 REQUIRED_DISTRO_FEATURES = "x11 opengl"
 
 SRC_URI = 
"${GNOME_MIRROR}/${GNOMEBN}/${@gnome_verdir("${PV}")}/${GNOMEBN}-${PV}.tar.${GNOME_COMPRESS_TYPE};name=archive
 \
-- 
2.20.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] libsolv giving opkg wrong hint about dependency issue

2020-01-19 Thread Yann Dirson
I was hit this week by opkg giving me a cryptic hint to resolve a problem:

- * Problem 1/2:
 *   - package packagegroup-core-boot-1.0-r17.6.shadow_ghost requires
sysvinit, but none of the providers can be installed
 *
 * Solution 1:
 *   - do not ask to install a package providing packagegroup-core-boot

Digging a bit into how it does things, I saw it's making use of
solver_problem2str(), which in
turn calls solver_findproblemrule(), which is documented as:

 * search for a rule that describes the problem to the
 * user. Actually a pretty hopeless task that may leave the user
 * puzzled. To get all of the needed information use
 * solver_findallproblemrules() instead.

So I ended up patching opkg to call the latter (patch below), yielding the
following output:

- * Problem 1/2:
 *   - package packagegroup-core-boot-1.0-r17.6.shadow_ghost requires
sysvinit, but none of the providers can be installed
 *   - complete list of reasons:
 * - package sysvinit-2.88dsf-r14.6.aarch64 requires sysvinit-inittab,
but none of the providers can be installed
 * - package packagegroup-core-boot-1.0-r17.6.shadow_ghost requires
sysvinit, but none of the providers can be installed
 * - package sysvinit-inittab-2.88dsf-r10.16.shadow_ghost requires
o-usb, but none of the providers can be installed
 * - conflicting requests
 * - nothing provides openssl11 >= 1.1.0i needed by
o-usb-0.0.0+git6+2c2d1e6fe3-r1.7.aarch64
 *
 * Solution 1:
 *   - do not ask to install a package providing packagegroup-core-boot

Here I do find the expected information  (openssl11 was a hack I hadded in
sumo, which poluted my first warrior builds, thus polluted my shard-state,
as there were 2 providers of this libssl soversion).  So now I can solve my
problem.

Where do we go from now ?  I'd argue libsolv selects the wrong message, but
its doc does say this API asks for the impossible, so we may not want to
spend time fixing it.
Is it reasonable to include the full list of reasons, maybe flagging those
that solver_findproblemrule() think are the most relevant ?
Or should this be seen as "extended diag" and conditioned by a new opkg
flag, maybe for backward-compatibility of some sort ?
It may make sense to push a function like this to libsolv itself ?


@@ -0,0 +1,38 @@
+Index: opkg-0.4.0/libopkg/solvers/libsolv/opkg_solver_libsolv.c
+===
+--- opkg-0.4.0.orig/libopkg/solvers/libsolv/opkg_solver_libsolv.c
 opkg-0.4.0/libopkg/solvers/libsolv/opkg_solver_libsolv.c
+@@ -795,6 +795,25 @@ static void libsolv_solver_add_job(libso
+ }
+ }
+
++static libsolv_print_all_problem_rules(libsolv_solver_t *libsolv_solver,
Id problem)
++{
++Queue rules;
++int i;
++
++opkg_message(ERROR, "  - complete list of reasons:\n");
++queue_init();
++solver_findallproblemrules(libsolv_solver->solver, problem, );
++for (i = 0; i < rules.count; i++) {
++Id type, source, target, dep;
++Id r = rules.elements[i];
++type = solver_ruleinfo(libsolv_solver->solver, r, ,
, );
++opkg_message(ERROR, "- %s\n",
++ solver_problemruleinfo2str(libsolv_solver->solver,
++type, source, target,
dep));
++}
++queue_free();
++}
++
+ static int libsolv_solver_solve(libsolv_solver_t *libsolv_solver)
+ {
+ int problem_count = solver_solve(libsolv_solver->solver,
+@@ -810,6 +829,7 @@ static int libsolv_solver_solve(libsolv_
+ opkg_message(ERROR, "Problem %d/%d:\n", problem,
problem_count);
+ opkg_message(ERROR, "  - %s\n",
+  solver_problem2str(libsolv_solver->solver,
problem));
++libsolv_print_all_problem_rules(libsolv_solver, problem);
+ opkg_message(ERROR, "\n");
+
+ int solution_count =
solver_solution_count(libsolv_solver->solver,

-- 
Yann Dirson 
Blade / Shadow -- http://shadow.tech
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [zeus 5/6] scripts/oe-build-perf-report: Avoid buildstats warning

2020-01-19 Thread Armin Kuster
From: Richard Purdie 

When a comparision branch is set we see warnings. If two branches are used,
look for buildstats information from both to avoid this kind of warning:

INFO: Parsing buildstats from 
'refs/notes/buildstats/perf-centos7.yoctoproject.org/master-next/qemux86'
WARNING: Buildstats not found for 
perf-centos7.yoctoproject.org/master/qemux86/56808-g08220028e52992dcba667fc97bf3afe8be1949fb/0
WARNING: Buildstats not found for 
perf-centos7.yoctoproject.org/master/qemux86/56808-g08220028e52992dcba667fc97bf3afe8be1949fb/1
INFO: Buildstats were missing for some test runs, please run 'git fetch origin 
refs/notes/buildstats/perf-centos7.yoctoproject.org/master-next/qemux86:refs/notes/buildstats/perf-centos7.yoctoproject.org/master-next/qemux86'
 and try again

(the warning is due to stats being looked for in both branches, choose
the other branch and different warnings would be shown)

Signed-off-by: Richard Purdie 
(cherry picked from commit af58c18fcd0451540dd77ee862956b2b9dee17c4)
Signed-off-by: Armin Kuster 
---
 scripts/oe-build-perf-report | 20 ++--
 1 file changed, 14 insertions(+), 6 deletions(-)

diff --git a/scripts/oe-build-perf-report b/scripts/oe-build-perf-report
index 21bde7e156..e781f4f03f 100755
--- a/scripts/oe-build-perf-report
+++ b/scripts/oe-build-perf-report
@@ -372,7 +372,7 @@ def print_html_report(data, id_comp, buildstats):
chart_opts=chart_opts))
 
 
-def get_buildstats(repo, notes_ref, revs, outdir=None):
+def get_buildstats(repo, notes_ref, notes_ref2, revs, outdir=None):
 """Get the buildstats from git notes"""
 full_ref = 'refs/notes/' + notes_ref
 if not repo.rev_parse(full_ref):
@@ -391,8 +391,13 @@ def get_buildstats(repo, notes_ref, revs, outdir=None):
 for tag in rev.tags:
 log.debug('%s', tag)
 try:
-bs_all = json.loads(repo.run_cmd(['notes', '--ref', notes_ref,
-  'show', tag + '^0']))
+try:
+bs_all = json.loads(repo.run_cmd(['notes', '--ref', 
notes_ref, 'show', tag + '^0']))
+except GitError:
+if notes_ref2:
+bs_all = json.loads(repo.run_cmd(['notes', '--ref', 
notes_ref2, 'show', tag + '^0']))
+else:
+raise
 except GitError:
 log.warning("Buildstats not found for %s", tag)
 bs_all = {}
@@ -589,9 +594,12 @@ def main(argv=None):
 buildstats = None
 if args.dump_buildstats or args.html:
 outdir = 'oe-build-perf-buildstats' if args.dump_buildstats else None
-notes_ref = 'buildstats/{}/{}/{}'.format(args.hostname, args.branch,
- args.machine)
-buildstats = get_buildstats(repo, notes_ref, [rev_l, rev_r], outdir)
+notes_ref = 'buildstats/{}/{}/{}'.format(args.hostname, args.branch, 
args.machine)
+notes_ref2 = None
+if args.branch2:
+notes_ref = 'buildstats/{}/{}/{}'.format(args.hostname, 
args.branch2, args.machine)
+notes_ref2 = 'buildstats/{}/{}/{}'.format(args.hostname, 
args.branch, args.machine)
+buildstats = get_buildstats(repo, notes_ref, notes_ref2, [rev_l, 
rev_r], outdir)
 
 # Print report
 if not args.html:
-- 
2.17.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [zeus 3/6] wic/filemap: If FIGETBSZ iotctl fail, failback to os.stat

2020-01-19 Thread Armin Kuster
From: Kalle Lampila 

Some file systems don't support fetching the block size (notably the
file system Docker uses for containers), so if iotctl() fail, try to use
failback via os.stat() to get block size.

Signed-off-by: Kalle lampila 
Signed-off-by: Richard Purdie 
(cherry picked from commit e219f5175177a640dd62833082ea19adc1c13d42)
Signed-off-by: Armin Kuster 
---
 scripts/lib/wic/filemap.py | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/scripts/lib/wic/filemap.py b/scripts/lib/wic/filemap.py
index a3919fbcad..c53147c2f1 100644
--- a/scripts/lib/wic/filemap.py
+++ b/scripts/lib/wic/filemap.py
@@ -34,9 +34,11 @@ def get_block_size(file_obj):
 # the FIGETBSZ ioctl (number 2).
 try:
 binary_data = fcntl.ioctl(file_obj, 2, struct.pack('I', 0))
+bsize = struct.unpack('I', binary_data)[0]
 except OSError:
-raise IOError("Unable to determine block size")
-bsize = struct.unpack('I', binary_data)[0]
+bsize = None
+
+# If ioctl causes OSError or give bsize to zero failback to os.fstat
 if not bsize:
 import os
 stat = os.fstat(file_obj.fileno())
-- 
2.17.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [zeus 1/6] linuxloader: Correct loader for glibc on armhf

2020-01-19 Thread Armin Kuster
From: Alex Kiernan 

Fix the naming of the loader on armhf to match what glibc expects:

  #define GLIBC_DYNAMIC_LINKER_SOFT_FLOAT SYSTEMLIBS_DIR "ld-linux.so.3"
  #define GLIBC_DYNAMIC_LINKER_HARD_FLOAT SYSTEMLIBS_DIR "ld-linux-armhf.so.3"

Signed-off-by: Alex Kiernan 
Signed-off-by: Richard Purdie 
(cherry picked from commit 7ad531093d620f18c04d487d79e9dad9f5a96232)
Signed-off-by: Armin Kuster 
---
 meta/classes/linuxloader.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/linuxloader.bbclass b/meta/classes/linuxloader.bbclass
index c0fbf26836..e2876cec7a 100644
--- a/meta/classes/linuxloader.bbclass
+++ b/meta/classes/linuxloader.bbclass
@@ -41,7 +41,7 @@ def get_glibc_loader(d):
 elif re.search("i.86", targetarch):
 dynamic_loader = "${base_libdir}/ld-linux.so.2"
 elif targetarch == "arm":
-dynamic_loader = "${base_libdir}/ld-linux.so.3"
+dynamic_loader = "${base_libdir}/ld-linux${@['-armhf', 
''][d.getVar('TARGET_FPU') == 'soft']}.so.3"
 elif targetarch.startswith("aarch64"):
 dynamic_loader = 
"${base_libdir}/ld-linux-aarch64${ARMPKGSFX_ENDIAN_64}.so.1"
 elif targetarch.startswith("riscv64"):
-- 
2.17.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [zeus 4/6] sstatesig: Test cross/native hashserv method extension

2020-01-19 Thread Armin Kuster
From: Richard Purdie 

We can have one taskhash which represents multiple native/cross sstate objects
since they're stored by BUILD_ARCH or possibly host distro (or host gcc 
version).
We need to put these into separate namespaces on hashserv since their outhashes
will never match and we need deterministic lookups for the different namespaces.

Use this extramethod option to handle this. This fixes several problematic
failures on the autobuilder.

Signed-off-by: Richard Purdie 
(cherry picked from commit 2a76082363d189880613765ad339718e3614049d)
Signed-off-by: Armin Kuster 
---
 meta/lib/oe/sstatesig.py | 9 +
 1 file changed, 9 insertions(+)

diff --git a/meta/lib/oe/sstatesig.py b/meta/lib/oe/sstatesig.py
index c566ce5a0c..24a221eb1a 100644
--- a/meta/lib/oe/sstatesig.py
+++ b/meta/lib/oe/sstatesig.py
@@ -103,6 +103,7 @@ class SignatureGeneratorOEBasicHashMixIn(object):
 self.unlockedrecipes = (data.getVar("SIGGEN_UNLOCKED_RECIPES") or
 "").split()
 self.unlockedrecipes = { k: "" for k in self.unlockedrecipes }
+self.buildarch = data.getVar('BUILD_ARCH')
 pass
 
 def tasks_resolved(self, virtmap, virtpnmap, dataCache):
@@ -140,6 +141,14 @@ class SignatureGeneratorOEBasicHashMixIn(object):
 self.dump_lockedsigs(sigfile)
 return super(bb.siggen.SignatureGeneratorBasicHash, 
self).dump_sigs(dataCache, options)
 
+def prep_taskhash(self, tid, deps, dataCache):
+super().prep_taskhash(tid, deps, dataCache)
+if hasattr(self, "extramethod"):
+(_, _, _, fn) = bb.runqueue.split_tid_mcfn(tid)
+inherits = " ".join(dataCache.inherits[fn])
+if inherits.find("/native.bbclass") != -1 or 
inherits.find("/cross.bbclass") != -1:
+self.extramethod[tid] = ":" + self.buildarch
+
 def get_taskhash(self, tid, deps, dataCache):
 h = super(bb.siggen.SignatureGeneratorBasicHash, 
self).get_taskhash(tid, deps, dataCache)
 
-- 
2.17.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [zeus 6/6] sstatesig: Improve debug output if getpwuid() fails

2020-01-19 Thread Armin Kuster
From: Richard Purdie 

If getpwduid fails, we don't see which file it failed on which is key 
information
to aid debugging. Print this information when exceptions are raised.

Signed-off-by: Richard Purdie 
(cherry picked from commit 9d7a5219713af8117eda145052c6d9abdf577d8f)
Signed-off-by: Armin Kuster 
---
 meta/lib/oe/sstatesig.py | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/meta/lib/oe/sstatesig.py b/meta/lib/oe/sstatesig.py
index 24a221eb1a..b2316b12b8 100644
--- a/meta/lib/oe/sstatesig.py
+++ b/meta/lib/oe/sstatesig.py
@@ -521,8 +521,12 @@ def OEOuthashBasic(path, sigfile, task, d):
 add_perm(stat.S_IXOTH, 'x')
 
 if include_owners:
-update_hash(" %10s" % pwd.getpwuid(s.st_uid).pw_name)
-update_hash(" %10s" % grp.getgrgid(s.st_gid).gr_name)
+try:
+update_hash(" %10s" % pwd.getpwuid(s.st_uid).pw_name)
+update_hash(" %10s" % grp.getgrgid(s.st_gid).gr_name)
+except KeyError:
+bb.warn("KeyError in %s" % path)
+raise
 
 update_hash(" ")
 if stat.S_ISBLK(s.st_mode) or stat.S_ISCHR(s.st_mode):
-- 
2.17.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [zeus 2/6] multilib.conf: Ensure that RECIPE_SYSROOT is unchanged for native

2020-01-19 Thread Armin Kuster
From: Mike Crowe 

Ensure that RECIPE_SYSROOT is the same for -native recipes whether
multilib.conf is included or not.

Without this change task signatures for -native recipes change when
switching between MACHINEs that require multilib.conf and those that
don't.

This fix was one of the ones suggested by Khem Raj in
http://lists.openembedded.org/pipermail/openembedded-core/2019-December/290303.html

Add test_sstate_multilib_or_not_native_samesigs test case to
sstatetests.py to ensure that this stays fixed.

Signed-off-by: Mike Crowe 
Signed-off-by: Richard Purdie 
(cherry picked from commit aa05f1ded71366b86eda7fce24d8b5395e85ada2)
Signed-off-by: Armin Kuster 
---
 meta/conf/multilib.conf |  1 +
 meta/lib/oeqa/selftest/cases/sstatetests.py | 40 +
 2 files changed, 41 insertions(+)

diff --git a/meta/conf/multilib.conf b/meta/conf/multilib.conf
index cfed3fbbd0..58f2ac5c86 100644
--- a/meta/conf/multilib.conf
+++ b/meta/conf/multilib.conf
@@ -9,6 +9,7 @@ MULTILIBS ??= "multilib:lib32"
 STAGING_DIR_HOST = "${WORKDIR}/${MLPREFIX}recipe-sysroot"
 STAGING_DIR_TARGET = "${WORKDIR}/${MLPREFIX}recipe-sysroot"
 RECIPE_SYSROOT = "${WORKDIR}/${MLPREFIX}recipe-sysroot"
+RECIPE_SYSROOT_class-native = "${WORKDIR}/recipe-sysroot"
 
 INHERIT += "multilib_global"
 
diff --git a/meta/lib/oeqa/selftest/cases/sstatetests.py 
b/meta/lib/oeqa/selftest/cases/sstatetests.py
index 6757a0ec68..9adb511960 100644
--- a/meta/lib/oeqa/selftest/cases/sstatetests.py
+++ b/meta/lib/oeqa/selftest/cases/sstatetests.py
@@ -446,6 +446,46 @@ BB_SIGNATURE_HANDLER = "OEBasicHash"
 self.assertCountEqual(files1, files2)
 
 
+def test_sstate_multilib_or_not_native_samesigs(self):
+"""The sstate checksums of two native recipes (and their dependencies)
+where the target is using multilib in one but not the other
+should be the same. We use the qemux86copy machine to test
+this.
+"""
+
+self.write_config("""
+TMPDIR = \"${TOPDIR}/tmp-sstatesamehash\"
+TCLIBCAPPEND = \"\"
+MACHINE = \"qemux86\"
+require conf/multilib.conf
+MULTILIBS = "multilib:lib32"
+DEFAULTTUNE_virtclass-multilib-lib32 = "x86"
+BB_SIGNATURE_HANDLER = "OEBasicHash"
+""")
+self.track_for_cleanup(self.topdir + "/tmp-sstatesamehash")
+bitbake("binutils-native  -S none")
+self.write_config("""
+TMPDIR = \"${TOPDIR}/tmp-sstatesamehash2\"
+TCLIBCAPPEND = \"\"
+MACHINE = \"qemux86copy\"
+BB_SIGNATURE_HANDLER = "OEBasicHash"
+""")
+self.track_for_cleanup(self.topdir + "/tmp-sstatesamehash2")
+bitbake("binutils-native -S none")
+
+def get_files(d):
+f = []
+for root, dirs, files in os.walk(d):
+for name in files:
+f.append(os.path.join(root, name))
+return f
+files1 = get_files(self.topdir + "/tmp-sstatesamehash/stamps")
+files2 = get_files(self.topdir + "/tmp-sstatesamehash2/stamps")
+files2 = [x.replace("tmp-sstatesamehash2", "tmp-sstatesamehash") for x 
in files2]
+self.maxDiff = None
+self.assertCountEqual(files1, files2)
+
+
 def test_sstate_noop_samesigs(self):
 """
 The sstate checksums of two builds with these variables changed or
-- 
2.17.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [zeus 0/6] Patch review

2020-01-19 Thread Armin Kuster
Please review and provide feedback by Tuesday.

Passed on AB via A-full

The following changes since commit 5ed714139f91eb03871e01b68a4370784071234d:

  license.bbclass: Introduce AVAILABLE_LICENSES that lists all licenses 
(2020-01-15 11:58:08 +0800)

are available in the Git repository at:

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

Alex Kiernan (1):
  linuxloader: Correct loader for glibc on armhf

Kalle Lampila (1):
  wic/filemap: If FIGETBSZ iotctl fail, failback to os.stat

Mike Crowe (1):
  multilib.conf: Ensure that RECIPE_SYSROOT is unchanged for native

Richard Purdie (3):
  sstatesig: Test cross/native hashserv method extension
  scripts/oe-build-perf-report: Avoid buildstats warning
  sstatesig: Improve debug output if getpwuid() fails

 meta/classes/linuxloader.bbclass|  2 +-
 meta/conf/multilib.conf |  1 +
 meta/lib/oe/sstatesig.py| 17 +++--
 meta/lib/oeqa/selftest/cases/sstatetests.py | 40 +
 scripts/lib/wic/filemap.py  |  6 ++--
 scripts/oe-build-perf-report| 20 +++
 6 files changed, 75 insertions(+), 11 deletions(-)

-- 
2.17.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH V2] qemu: Enable ppc64le support for qemu-usermode

2020-01-19 Thread Khem Raj
glibc defines minimum kernel needed to be 3.10.0 for LE ppc64

Signed-off-by: Khem Raj 
---
v2: Exclude ppc64le from system-qemu target list, its usermode only
option

 meta/classes/qemu.bbclass   | 3 +++
 meta/conf/bitbake.conf  | 1 +
 meta/recipes-devtools/qemu/qemu-targets.inc | 2 +-
 meta/recipes-devtools/qemu/qemu.inc | 2 +-
 4 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/meta/classes/qemu.bbclass b/meta/classes/qemu.bbclass
index f5c5780125..55bdff816b 100644
--- a/meta/classes/qemu.bbclass
+++ b/meta/classes/qemu.bbclass
@@ -16,6 +16,8 @@ def qemu_target_binary(data):
 target_arch = "ppc"
 elif target_arch == "powerpc64":
 target_arch = "ppc64"
+elif target_arch == "powerpc64le":
+target_arch = "ppc64le"
 
 return "qemu-" + target_arch
 
@@ -62,3 +64,4 @@ QEMU_EXTRAOPTIONS_ppc64e5500 = " -cpu e500mc"
 QEMU_EXTRAOPTIONS_ppce6500 = " -cpu e500mc"
 QEMU_EXTRAOPTIONS_ppc64e6500 = " -cpu e500mc"
 QEMU_EXTRAOPTIONS_ppc7400 = " -cpu 7400"
+QEMU_EXTRAOPTIONS_powerpc64le = " -cpu POWER8"
diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index ce89b80ade..2da7c5849a 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -430,6 +430,7 @@ SDKPATHNATIVE = "${SDKPATH}/sysroots/${SDK_SYS}"
 OLDEST_KERNEL = "3.2.0"
 OLDEST_KERNEL_aarch64 = "3.14"
 OLDEST_KERNEL_nios2 = "3.19"
+OLDEST_KERNEL_powerpc64le = "3.10.0"
 OLDEST_KERNEL_riscv32 = "4.15"
 OLDEST_KERNEL_riscv64 = "4.15"
 
diff --git a/meta/recipes-devtools/qemu/qemu-targets.inc 
b/meta/recipes-devtools/qemu/qemu-targets.inc
index 8184ef5781..24f9a03948 100644
--- a/meta/recipes-devtools/qemu/qemu-targets.inc
+++ b/meta/recipes-devtools/qemu/qemu-targets.inc
@@ -13,7 +13,7 @@ def get_qemu_target_list(d):
 softmmuonly += arch + "-softmmu,"
 archs.remove(arch)
 linuxuseronly = ""
-for arch in ['armeb', 'alpha', 'ppc64abi32', 'sparc32plus', 'aarch64_be']:
+for arch in ['armeb', 'alpha', 'ppc64abi32', 'ppc64le', 'sparc32plus', 
'aarch64_be']:
 if arch in archs:
 linuxuseronly += arch + "-linux-user,"
 archs.remove(arch)
diff --git a/meta/recipes-devtools/qemu/qemu.inc 
b/meta/recipes-devtools/qemu/qemu.inc
index dff5762b80..eb9f060997 100644
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtools/qemu/qemu.inc
@@ -59,7 +59,7 @@ do_install_ptest() {
 }
 
 # QEMU_TARGETS is overridable variable
-QEMU_TARGETS ?= "arm aarch64 i386 mips mipsel mips64 mips64el ppc ppc64 
riscv32 riscv64 sh4 x86_64"
+QEMU_TARGETS ?= "arm aarch64 i386 mips mipsel mips64 mips64el ppc ppc64 
ppc64le riscv32 riscv64 sh4 x86_64"
 
 EXTRA_OECONF = " \
 --prefix=${prefix} \
-- 
2.25.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH 1/3] oeqa: reproducible: Add flag for building from sstate

2020-01-19 Thread Joshua Watt
Adds a flag to control if the reproducible QA test should allow building
from sstate or not. Building from sstate may not be reproducible
depending on how the sstate is populated.

Signed-off-by: Joshua Watt 
---
 meta/lib/oeqa/selftest/cases/reproducible.py | 66 +++-
 1 file changed, 35 insertions(+), 31 deletions(-)

diff --git a/meta/lib/oeqa/selftest/cases/reproducible.py 
b/meta/lib/oeqa/selftest/cases/reproducible.py
index db538a4f891..b7484f3e10e 100644
--- a/meta/lib/oeqa/selftest/cases/reproducible.py
+++ b/meta/lib/oeqa/selftest/cases/reproducible.py
@@ -80,6 +80,13 @@ class ReproducibleTests(OESelftestTestCase):
 package_classes = ['deb', 'ipk']
 images = ['core-image-minimal', 'core-image-sato', 
'core-image-full-cmdline']
 save_results = False
+# This variable controls if one of the test builds is allowed to pull from
+# an sstate cache/mirror. The other build is always done clean as a point 
of
+# comparison.
+# If you know that your sstate archives are reproducible, enabling this
+# will test that and also make the test run faster. If your sstate is not
+# reproducible, disable this in your derived test class
+build_from_sstate = True
 
 def setUpLocal(self):
 super().setUpLocal()
@@ -127,7 +134,7 @@ class ReproducibleTests(OESelftestTestCase):
 bb.utils.mkdirhier(os.path.dirname(dest))
 shutil.copyfile(source, dest)
 
-def test_reproducible_builds(self):
+def do_test_build(self, name, use_sstate):
 capture_vars = ['DEPLOY_DIR_' + c.upper() for c in 
self.package_classes]
 
 if self.save_results:
@@ -135,41 +142,38 @@ class ReproducibleTests(OESelftestTestCase):
 os.chmod(save_dir, stat.S_IRWXU | stat.S_IRGRP | stat.S_IXGRP | 
stat.S_IROTH | stat.S_IXOTH)
 self.logger.info('Non-reproducible packages will be copied to %s', 
save_dir)
 
-# Build native utilities
-self.write_config('')
-bitbake("diffutils-native -c addto_recipe_sysroot")
-diffutils_sysroot = get_bb_var("RECIPE_SYSROOT_NATIVE", 
"diffutils-native")
+tmpdir = os.path.join(self.topdir, name, 'tmp')
+if os.path.exists(tmpdir):
+bb.utils.remove(tmpdir, recurse=True)
 
-# Reproducible builds should not pull from sstate or mirrors, but
-# sharing DL_DIR is fine
-common_config = textwrap.dedent('''\
+config = textwrap.dedent('''\
 INHERIT += "reproducible_build"
-PACKAGE_CLASSES = "%s"
-SSTATE_DIR = "${TMPDIR}/sstate"
-''') % (' '.join('package_%s' % c for c in self.package_classes))
-
-# Perform a build.
-reproducibleA_tmp = os.path.join(self.topdir, 'reproducibleA', 'tmp')
-if os.path.exists(reproducibleA_tmp):
-bb.utils.remove(reproducibleA_tmp, recurse=True)
-
-self.write_config((textwrap.dedent('''\
-TMPDIR = "%s"
-''') % reproducibleA_tmp) + common_config)
-vars_A = get_bb_vars(capture_vars)
+PACKAGE_CLASSES = "{package_classes}"
+TMPDIR = "{tmpdir}"
+''').format(package_classes=' '.join('package_%s' % c for c in 
self.package_classes),
+tmpdir=tmpdir)
+
+if not use_sstate:
+# This config fragment will disable using shared and the sstate
+# mirror, forcing a complete build from scratch
+config += textwrap.dedent('''\
+SSTATE_DIR = "${TMPDIR}/sstate"
+SSTATE_MIRROR = ""
+''')
+
+self.write_config(config)
+d = get_bb_vars(capture_vars)
 bitbake(' '.join(self.images))
+return d
 
-# Perform another build.
-reproducibleB_tmp = os.path.join(self.topdir, 'reproducibleB', 'tmp')
-if os.path.exists(reproducibleB_tmp):
-bb.utils.remove(reproducibleB_tmp, recurse=True)
+def test_reproducible_builds(self):
+# Build native utilities
+self.write_config('')
+bitbake("diffutils-native -c addto_recipe_sysroot")
+diffutils_sysroot = get_bb_var("RECIPE_SYSROOT_NATIVE", 
"diffutils-native")
 
-self.write_config((textwrap.dedent('''\
-SSTATE_MIRROR = ""
-TMPDIR = "%s"
-''') % reproducibleB_tmp) + common_config)
-vars_B = get_bb_vars(capture_vars)
-bitbake(' '.join(self.images))
+vars_A = self.do_test_build('reproducibleA', self.build_from_sstate)
+vars_B = self.do_test_build('reproducibleB', False)
 
 # NOTE: The temp directories from the reproducible build are purposely
 # kept after the build so it can be diffed for debugging.
-- 
2.24.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH 0/3] selftest: reproducible: Various improvements

2020-01-19 Thread Joshua Watt
Adds improvements and bug fixes to reproducible builds to make it easier
to diagnose reproducibility problems.

Joshua Watt (3):
  oeqa: reproducible: Add flag for building from sstate
  oeqa: reproducible: Fix extra data reporting
  oeqa: reproducible: Do not strip packages

 meta/lib/oeqa/selftest/cases/reproducible.py | 77 +++-
 1 file changed, 41 insertions(+), 36 deletions(-)

-- 
2.24.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH 3/3] oeqa: reproducible: Do not strip packages

2020-01-19 Thread Joshua Watt
Do not strip packages when testing reproducible builds. In some cases,
stripped data differs between builds, but then gets removed. However,
the contents affect the generation of the GCC build-id, which then
differs in the resulting ELF files, even though the data that caused
this is no longer there. Inhibit stripping so that their causes can be
evaluated.

Signed-off-by: Joshua Watt 
---
 meta/lib/oeqa/selftest/cases/reproducible.py | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/lib/oeqa/selftest/cases/reproducible.py 
b/meta/lib/oeqa/selftest/cases/reproducible.py
index c00b92d2e90..34462a0b3a4 100644
--- a/meta/lib/oeqa/selftest/cases/reproducible.py
+++ b/meta/lib/oeqa/selftest/cases/reproducible.py
@@ -149,6 +149,7 @@ class ReproducibleTests(OESelftestTestCase):
 config = textwrap.dedent('''\
 INHERIT += "reproducible_build"
 PACKAGE_CLASSES = "{package_classes}"
+INHIBIT_PACKAGE_STRIP = "1"
 TMPDIR = "{tmpdir}"
 ''').format(package_classes=' '.join('package_%s' % c for c in 
self.package_classes),
 tmpdir=tmpdir)
-- 
2.24.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH 2/3] oeqa: reproducible: Fix extra data reporting

2020-01-19 Thread Joshua Watt
A typo was preventing the extra data about the reproducible build from
being reported in the test results

Signed-off-by: Joshua Watt 
---
 meta/lib/oeqa/selftest/cases/reproducible.py | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/meta/lib/oeqa/selftest/cases/reproducible.py 
b/meta/lib/oeqa/selftest/cases/reproducible.py
index b7484f3e10e..c00b92d2e90 100644
--- a/meta/lib/oeqa/selftest/cases/reproducible.py
+++ b/meta/lib/oeqa/selftest/cases/reproducible.py
@@ -95,12 +95,12 @@ class ReproducibleTests(OESelftestTestCase):
 for v in needed_vars:
 setattr(self, v.lower(), bb_vars[v])
 
-self.extrasresults = {}
-self.extrasresults.setdefault('reproducible.rawlogs', {})['log'] = ''
-self.extrasresults.setdefault('reproducible', {}).setdefault('files', 
{})
+self.extraresults = {}
+self.extraresults.setdefault('reproducible.rawlogs', {})['log'] = ''
+self.extraresults.setdefault('reproducible', {}).setdefault('files', 
{})
 
 def append_to_log(self, msg):
-self.extrasresults['reproducible.rawlogs']['log'] += msg
+self.extraresults['reproducible.rawlogs']['log'] += msg
 
 def compare_packages(self, reference_dir, test_dir, diffutils_sysroot):
 result = PackageCompareResults()
@@ -127,7 +127,7 @@ class ReproducibleTests(OESelftestTestCase):
 return result
 
 def write_package_list(self, package_class, name, packages):
-self.extrasresults['reproducible']['files'].setdefault(package_class, 
{})[name] = [
+self.extraresults['reproducible']['files'].setdefault(package_class, 
{})[name] = [
 {'reference': p.reference, 'test': p.test} for p in packages]
 
 def copy_file(self, source, dest):
-- 
2.24.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH] qemu: Enable ppc64le support for qemu-usermode

2020-01-19 Thread Richard Purdie
On Sun, 2020-01-19 at 02:06 -0800, Khem Raj wrote:
> glibc defines minimum kernel needed to be 3.10.0 for LE ppc64
> 
> Signed-off-by: Khem Raj 
> ---
>  meta/classes/qemu.bbclass   | 3 +++
>  meta/conf/bitbake.conf  | 1 +
>  meta/recipes-devtools/qemu/qemu.inc | 2 +-
>  3 files changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/meta/classes/qemu.bbclass b/meta/classes/qemu.bbclass
> index f5c5780125..55bdff816b 100644
> --- a/meta/classes/qemu.bbclass
> +++ b/meta/classes/qemu.bbclass
> @@ -16,6 +16,8 @@ def qemu_target_binary(data):
>  target_arch = "ppc"
>  elif target_arch == "powerpc64":
>  target_arch = "ppc64"
> +elif target_arch == "powerpc64le":
> +target_arch = "ppc64le"
>  
>  return "qemu-" + target_arch
>  
> @@ -62,3 +64,4 @@ QEMU_EXTRAOPTIONS_ppc64e5500 = " -cpu e500mc"
>  QEMU_EXTRAOPTIONS_ppce6500 = " -cpu e500mc"
>  QEMU_EXTRAOPTIONS_ppc64e6500 = " -cpu e500mc"
>  QEMU_EXTRAOPTIONS_ppc7400 = " -cpu 7400"
> +QEMU_EXTRAOPTIONS_powerpc64le = " -cpu POWER8"
> diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
> index ce89b80ade..2da7c5849a 100644
> --- a/meta/conf/bitbake.conf
> +++ b/meta/conf/bitbake.conf
> @@ -430,6 +430,7 @@ SDKPATHNATIVE = "${SDKPATH}/sysroots/${SDK_SYS}"
>  OLDEST_KERNEL = "3.2.0"
>  OLDEST_KERNEL_aarch64 = "3.14"
>  OLDEST_KERNEL_nios2 = "3.19"
> +OLDEST_KERNEL_powerpc64le = "3.10.0"
>  OLDEST_KERNEL_riscv32 = "4.15"
>  OLDEST_KERNEL_riscv64 = "4.15"
>  
> diff --git a/meta/recipes-devtools/qemu/qemu.inc b/meta/recipes-
> devtools/qemu/qemu.inc
> index dff5762b80..eb9f060997 100644
> --- a/meta/recipes-devtools/qemu/qemu.inc
> +++ b/meta/recipes-devtools/qemu/qemu.inc
> @@ -59,7 +59,7 @@ do_install_ptest() {
>  }
>  
>  # QEMU_TARGETS is overridable variable
> -QEMU_TARGETS ?= "arm aarch64 i386 mips mipsel mips64 mips64el ppc
> ppc64 riscv32 riscv64 sh4 x86_64"
> +QEMU_TARGETS ?= "arm aarch64 i386 mips mipsel mips64 mips64el ppc
> ppc64 ppc64le riscv32 riscv64 sh4 x86_64"
> 


https://autobuilder.yoctoproject.org/typhoon/#/builders/65/builds/1482

(and most other builds unfortunately)

Cheers,

Richard

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [OE-Core][PATCH] lib/oe/package_manager: Improve locale-archive reproducibility

2020-01-19 Thread Alex Kiernan
The generation of locale-archive depends on the order of the input
files. Fix the order by sorting the file list.

Signed-off-by: Alex Kiernan 
---

 meta/lib/oe/package_manager.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/lib/oe/package_manager.py b/meta/lib/oe/package_manager.py
index e15e3c4a315d..d3444c99bc07 100644
--- a/meta/lib/oe/package_manager.py
+++ b/meta/lib/oe/package_manager.py
@@ -131,7 +131,7 @@ def generate_locale_archive(d, rootfs, target_arch, 
localedir):
 env = dict(os.environ)
 env["LOCALEARCHIVE"] = oe.path.join(localedir, "locale-archive")
 
-for name in os.listdir(localedir):
+for name in sorted(os.listdir(localedir)):
 path = os.path.join(localedir, name)
 if os.path.isdir(path):
 cmd = ["cross-localedef", "--verbose"]
-- 
2.17.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH] logrotate.py: improve oeqa test implementation

2020-01-19 Thread Trevor Gamblin

On 1/19/20 7:15 AM, Richard Purdie wrote:


On Sat, 2020-01-18 at 23:16 +, Richard Purdie wrote:

On Thu, 2020-01-16 at 15:19 -0500, Trevor Gamblin wrote:

From: Trevor Gamblin 

See bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=13632

Autobuilder tests occasionally fail, reporting that a new logfile
could not be created. While this failure did occur multiple times,
it
could not be manually reproduced. However, there are issues with
the
implementation of the logrotate.py script that can be fixed. These
changes will help make the failures clearer, should they continue
to
occur.

Previously, the test_2_logrotate test would, after running the
logrotate tool, use "ls -al $HOME/logrotate_dir | wc -l" to count
the number of files in the rotation directory and determine if the
rotation was successful. The test to see if there are at least
three
files is problematic, because depending on the version of ls used,
it
may report the target value of 3 even when there are only hidden
files
in the directory, potentially reporting a pass for the test when it
should actually fail. An example with coreutils:

root@qemux86-64:~# ls -al emptydir/
total 2
drwxr-xr-x 2 root root 1024 Jan 14 19:50 .
drwx-- 3 root root 1024 Jan 14 19:50 ..
root@qemux86-64:~#

Where "total" is the number of blocks used. Compare with busybox
ls:

root@qemux86-64:~# ls -al emptydir/
drwxr-xr-x2 root root  1024 Jan 14 19:54 .
drwx--3 root root  1024 Jan 14 19:54 ..
root@qemux86-64:~#

Instead of using ls to verify that a certain number of files exists
in $HOME/logrotate_dir, the tests have been changed to rotate two
specific logs: the log for wtmp and a new logrotate_testfile
created
during the second test. Both tests check that the logs are
correctly
rotated into $HOME/logrotate_dir by using find and grep on the
expected filename (e.g. "wtmp" when rotated becomes "wtmp.1", so we
check to see that wtmp.1 is present in $HOME/logrotate_dir). In
addition, should the test fail, the directory listing is included
in
the log to aid debugging.

Finally, note that while the autobuilder failures that this patch
addresses were only seen during core-image-full-cmdline tests,
these
changes were successfully tested on core-image-minimal and
core-image-sato with the manual addition of logrotate and openssh-
sshd
to the images.

Signed-off-by: Trevor Gamblin 

Thanks for this, I haven't looked in detail but test builds came back
with:

https://autobuilder.yoctoproject.org/typhoon/#/builders/64/builds/1464

Also:

https://autobuilder.yoctoproject.org/typhoon/#/builders/64/builds/1467
https://autobuilder.yoctoproject.org/typhoon/#/builders/45/builds/1471
(but there was a pass for the above target too:
https://autobuilder.yoctoproject.org/typhoon/#/builders/45/builds/1468)
https://autobuilder.yoctoproject.org/typhoon/#/builders/76/builds/1464
(interesting 1c and 2c failed)
https://autobuilder.yoctoproject.org/typhoon/#/builders/102/builds/216
(may be related, systemd logrotate failure)

This is promising. I'll dig into it tonight/tomorrow.


Cheers,

Richard



--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH] logrotate.py: improve oeqa test implementation

2020-01-19 Thread Trevor Gamblin

On 1/19/20 7:15 AM, Richard Purdie wrote:


On Sat, 2020-01-18 at 23:16 +, Richard Purdie wrote:

On Thu, 2020-01-16 at 15:19 -0500, Trevor Gamblin wrote:

From: Trevor Gamblin 

See bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=13632

Autobuilder tests occasionally fail, reporting that a new logfile
could not be created. While this failure did occur multiple times,
it
could not be manually reproduced. However, there are issues with
the
implementation of the logrotate.py script that can be fixed. These
changes will help make the failures clearer, should they continue
to
occur.

Previously, the test_2_logrotate test would, after running the
logrotate tool, use "ls -al $HOME/logrotate_dir | wc -l" to count
the number of files in the rotation directory and determine if the
rotation was successful. The test to see if there are at least
three
files is problematic, because depending on the version of ls used,
it
may report the target value of 3 even when there are only hidden
files
in the directory, potentially reporting a pass for the test when it
should actually fail. An example with coreutils:

root@qemux86-64:~# ls -al emptydir/
total 2
drwxr-xr-x 2 root root 1024 Jan 14 19:50 .
drwx-- 3 root root 1024 Jan 14 19:50 ..
root@qemux86-64:~#

Where "total" is the number of blocks used. Compare with busybox
ls:

root@qemux86-64:~# ls -al emptydir/
drwxr-xr-x2 root root  1024 Jan 14 19:54 .
drwx--3 root root  1024 Jan 14 19:54 ..
root@qemux86-64:~#

Instead of using ls to verify that a certain number of files exists
in $HOME/logrotate_dir, the tests have been changed to rotate two
specific logs: the log for wtmp and a new logrotate_testfile
created
during the second test. Both tests check that the logs are
correctly
rotated into $HOME/logrotate_dir by using find and grep on the
expected filename (e.g. "wtmp" when rotated becomes "wtmp.1", so we
check to see that wtmp.1 is present in $HOME/logrotate_dir). In
addition, should the test fail, the directory listing is included
in
the log to aid debugging.

Finally, note that while the autobuilder failures that this patch
addresses were only seen during core-image-full-cmdline tests,
these
changes were successfully tested on core-image-minimal and
core-image-sato with the manual addition of logrotate and openssh-
sshd
to the images.

Signed-off-by: Trevor Gamblin 

Thanks for this, I haven't looked in detail but test builds came back
with:

https://autobuilder.yoctoproject.org/typhoon/#/builders/64/builds/1464

Also:

https://autobuilder.yoctoproject.org/typhoon/#/builders/64/builds/1467
https://autobuilder.yoctoproject.org/typhoon/#/builders/45/builds/1471
(but there was a pass for the above target too:
https://autobuilder.yoctoproject.org/typhoon/#/builders/45/builds/1468)
https://autobuilder.yoctoproject.org/typhoon/#/builders/76/builds/1464
(interesting 1c and 2c failed)
https://autobuilder.yoctoproject.org/typhoon/#/builders/102/builds/216
(may be related, systemd logrotate failure)

This is promising. I'll dig into it tonight/tomorrow.


Cheers,

Richard



--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH] pcmanfm: Inherit mime-xdg

2020-01-19 Thread Richard Purdie
Inherit the new class to avoid warnings about desktop file.

Signed-off-by: Richard Purdie 
---
 meta/recipes-sato/pcmanfm/pcmanfm_1.3.1.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-sato/pcmanfm/pcmanfm_1.3.1.bb 
b/meta/recipes-sato/pcmanfm/pcmanfm_1.3.1.bb
index c88e1ed8d6a..7885e0abaed 100644
--- a/meta/recipes-sato/pcmanfm/pcmanfm_1.3.1.bb
+++ b/meta/recipes-sato/pcmanfm/pcmanfm_1.3.1.bb
@@ -21,7 +21,7 @@ SRC_URI[sha256sum] = 
"6804043b3ee3a703edde41c724946174b505fe958703eadbd7e0876ece
 
 UPSTREAM_CHECK_URI = 
"http://sourceforge.net/projects/pcmanfm/files/PCManFM%20%2B%20Libfm%20%28tarball%20release%29/PCManFM/;
 
-inherit autotools pkgconfig features_check
+inherit autotools pkgconfig features_check mime-xdg
 
 # The startup-notification requires x11 in DISTRO_FEATURES
 REQUIRED_DISTRO_FEATURES = "x11"
-- 
2.20.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH] logrotate.py: improve oeqa test implementation

2020-01-19 Thread Richard Purdie
On Sat, 2020-01-18 at 23:16 +, Richard Purdie wrote:
> On Thu, 2020-01-16 at 15:19 -0500, Trevor Gamblin wrote:
> > From: Trevor Gamblin 
> > 
> > See bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=13632
> > 
> > Autobuilder tests occasionally fail, reporting that a new logfile
> > could not be created. While this failure did occur multiple times,
> > it
> > could not be manually reproduced. However, there are issues with
> > the
> > implementation of the logrotate.py script that can be fixed. These
> > changes will help make the failures clearer, should they continue
> > to
> > occur.
> > 
> > Previously, the test_2_logrotate test would, after running the
> > logrotate tool, use "ls -al $HOME/logrotate_dir | wc -l" to count
> > the number of files in the rotation directory and determine if the
> > rotation was successful. The test to see if there are at least
> > three
> > files is problematic, because depending on the version of ls used,
> > it
> > may report the target value of 3 even when there are only hidden
> > files
> > in the directory, potentially reporting a pass for the test when it
> > should actually fail. An example with coreutils:
> > 
> > root@qemux86-64:~# ls -al emptydir/
> > total 2
> > drwxr-xr-x 2 root root 1024 Jan 14 19:50 .
> > drwx-- 3 root root 1024 Jan 14 19:50 ..
> > root@qemux86-64:~#
> > 
> > Where "total" is the number of blocks used. Compare with busybox
> > ls:
> > 
> > root@qemux86-64:~# ls -al emptydir/
> > drwxr-xr-x2 root root  1024 Jan 14 19:54 .
> > drwx--3 root root  1024 Jan 14 19:54 ..
> > root@qemux86-64:~#
> > 
> > Instead of using ls to verify that a certain number of files exists
> > in $HOME/logrotate_dir, the tests have been changed to rotate two
> > specific logs: the log for wtmp and a new logrotate_testfile
> > created
> > during the second test. Both tests check that the logs are
> > correctly
> > rotated into $HOME/logrotate_dir by using find and grep on the
> > expected filename (e.g. "wtmp" when rotated becomes "wtmp.1", so we
> > check to see that wtmp.1 is present in $HOME/logrotate_dir). In
> > addition, should the test fail, the directory listing is included
> > in
> > the log to aid debugging.
> > 
> > Finally, note that while the autobuilder failures that this patch
> > addresses were only seen during core-image-full-cmdline tests,
> > these
> > changes were successfully tested on core-image-minimal and
> > core-image-sato with the manual addition of logrotate and openssh-
> > sshd
> > to the images.
> > 
> > Signed-off-by: Trevor Gamblin 
> 
> Thanks for this, I haven't looked in detail but test builds came back
> with:
> 
> https://autobuilder.yoctoproject.org/typhoon/#/builders/64/builds/1464

Also:

https://autobuilder.yoctoproject.org/typhoon/#/builders/64/builds/1467
https://autobuilder.yoctoproject.org/typhoon/#/builders/45/builds/1471
(but there was a pass for the above target too:
https://autobuilder.yoctoproject.org/typhoon/#/builders/45/builds/1468)
https://autobuilder.yoctoproject.org/typhoon/#/builders/76/builds/1464
(interesting 1c and 2c failed)
https://autobuilder.yoctoproject.org/typhoon/#/builders/102/builds/216
(may be related, systemd logrotate failure)

Cheers,

Richard


-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH] qemu: Enable ppc64le support for qemu-usermode

2020-01-19 Thread Khem Raj
glibc defines minimum kernel needed to be 3.10.0 for LE ppc64

Signed-off-by: Khem Raj 
---
 meta/classes/qemu.bbclass   | 3 +++
 meta/conf/bitbake.conf  | 1 +
 meta/recipes-devtools/qemu/qemu.inc | 2 +-
 3 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/meta/classes/qemu.bbclass b/meta/classes/qemu.bbclass
index f5c5780125..55bdff816b 100644
--- a/meta/classes/qemu.bbclass
+++ b/meta/classes/qemu.bbclass
@@ -16,6 +16,8 @@ def qemu_target_binary(data):
 target_arch = "ppc"
 elif target_arch == "powerpc64":
 target_arch = "ppc64"
+elif target_arch == "powerpc64le":
+target_arch = "ppc64le"
 
 return "qemu-" + target_arch
 
@@ -62,3 +64,4 @@ QEMU_EXTRAOPTIONS_ppc64e5500 = " -cpu e500mc"
 QEMU_EXTRAOPTIONS_ppce6500 = " -cpu e500mc"
 QEMU_EXTRAOPTIONS_ppc64e6500 = " -cpu e500mc"
 QEMU_EXTRAOPTIONS_ppc7400 = " -cpu 7400"
+QEMU_EXTRAOPTIONS_powerpc64le = " -cpu POWER8"
diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index ce89b80ade..2da7c5849a 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -430,6 +430,7 @@ SDKPATHNATIVE = "${SDKPATH}/sysroots/${SDK_SYS}"
 OLDEST_KERNEL = "3.2.0"
 OLDEST_KERNEL_aarch64 = "3.14"
 OLDEST_KERNEL_nios2 = "3.19"
+OLDEST_KERNEL_powerpc64le = "3.10.0"
 OLDEST_KERNEL_riscv32 = "4.15"
 OLDEST_KERNEL_riscv64 = "4.15"
 
diff --git a/meta/recipes-devtools/qemu/qemu.inc 
b/meta/recipes-devtools/qemu/qemu.inc
index dff5762b80..eb9f060997 100644
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtools/qemu/qemu.inc
@@ -59,7 +59,7 @@ do_install_ptest() {
 }
 
 # QEMU_TARGETS is overridable variable
-QEMU_TARGETS ?= "arm aarch64 i386 mips mipsel mips64 mips64el ppc ppc64 
riscv32 riscv64 sh4 x86_64"
+QEMU_TARGETS ?= "arm aarch64 i386 mips mipsel mips64 mips64el ppc ppc64 
ppc64le riscv32 riscv64 sh4 x86_64"
 
 EXTRA_OECONF = " \
 --prefix=${prefix} \
-- 
2.25.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH] dnf: upgrade 4.2.2 -> 4.2.18

2020-01-19 Thread Alexander Kanavin
I would upgrade this in tandem with libdnf and rpm. Both are known to have 
issues unfortunately.

Alex

> On 19 Jan 2020, at 6.08, Wang Mingyu  wrote:
> 
> Signed-off-by: Wang Mingyu 
> ---
> meta/recipes-devtools/dnf/{dnf_4.2.2.bb => dnf_4.2.18.bb} | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> rename meta/recipes-devtools/dnf/{dnf_4.2.2.bb => dnf_4.2.18.bb} (98%)
> 
> diff --git a/meta/recipes-devtools/dnf/dnf_4.2.2.bb 
> b/meta/recipes-devtools/dnf/dnf_4.2.18.bb
> similarity index 98%
> rename from meta/recipes-devtools/dnf/dnf_4.2.2.bb
> rename to meta/recipes-devtools/dnf/dnf_4.2.18.bb
> index f38167f1ad..fd4380723e 100644
> --- a/meta/recipes-devtools/dnf/dnf_4.2.2.bb
> +++ b/meta/recipes-devtools/dnf/dnf_4.2.18.bb
> @@ -15,7 +15,7 @@ SRC_URI = "git://github.com/rpm-software-management/dnf.git 
> \
>file://0030-Run-python-scripts-using-env.patch \
>"
> 
> -SRCREV = "9947306a55271b8b7c9e2b6e3b7d582885b6045d"
> +SRCREV = "ff1972b52007ccb701c43e3c2bf2bd2e40ac32ac"
> UPSTREAM_CHECK_GITTAGREGEX = "(?P\d+(\.\d+)+)"
> 
> S = "${WORKDIR}/git"
> -- 
> 2.17.1
> 
> 
> 
> -- 
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH] ltp: Fix nm01 faliure

2020-01-19 Thread zhe.he
From: He Zhe 

Backport a patch from upstream to fix the following runtime failure.

The latest nm v2.33.1 outputs symbols addresses without prefix zeros
for "nm -f posix", which causes the following error.
nm01 5 TFAIL: Got wrong format with -f bsd

Signed-off-by: He Zhe 
---
 ...ix-zeros-of-the-addresses-output-by-.patch | 43 +++
 meta/recipes-extended/ltp/ltp_20190930.bb |  1 +
 2 files changed, 44 insertions(+)
 create mode 100644 
meta/recipes-extended/ltp/ltp/0001-nm01-Remove-prefix-zeros-of-the-addresses-output-by-.patch

diff --git 
a/meta/recipes-extended/ltp/ltp/0001-nm01-Remove-prefix-zeros-of-the-addresses-output-by-.patch
 
b/meta/recipes-extended/ltp/ltp/0001-nm01-Remove-prefix-zeros-of-the-addresses-output-by-.patch
new file mode 100644
index 00..fe5e7314e0
--- /dev/null
+++ 
b/meta/recipes-extended/ltp/ltp/0001-nm01-Remove-prefix-zeros-of-the-addresses-output-by-.patch
@@ -0,0 +1,43 @@
+From 59cb0dd9f8e65b2d398fcaf4d163cbc8e1d0ae45 Mon Sep 17 00:00:00 2001
+From: He Zhe 
+Date: Tue, 31 Dec 2019 15:02:48 +0800
+Subject: [PATCH] nm01: Remove prefix zeros of the addresses output by nm
+ before comparing
+
+The latest nm v2.33.1 outputs symbols addresses without prefix zeros
+for "nm -f posix", which causes the following error.
+nm01 5 TFAIL: Got wrong format with -f bsd
+
+Let's remove the prefix zeros before comparing.
+
+Upstream-Status: Backport [59cb0dd9f8e65b2d398fcaf4d163cbc8e1d0ae45]
+
+Signed-off-by: He Zhe 
+Reviewed-by: Li Wang 
+Reviewed-by: Petr Vorel 
+Tested-by: Petr Vorel 
+---
+ testcases/commands/nm/nm01.sh | 7 +--
+ 1 file changed, 5 insertions(+), 2 deletions(-)
+
+diff --git a/testcases/commands/nm/nm01.sh b/testcases/commands/nm/nm01.sh
+index 30c41bd..fd9d3d9 100755
+--- a/testcases/commands/nm/nm01.sh
 b/testcases/commands/nm/nm01.sh
+@@ -84,8 +84,11 @@ test5()
+   EXPECT_PASS $NM -f bsd $TST_DATAROOT/f1 \> nm_bsd.out
+   EXPECT_PASS $NM -f posix $TST_DATAROOT/f1 \> nm_posix.out
+ 
+-  ROD awk '{print $3 $2 $1}' nm_bsd.out \> nm1.out
+-  ROD awk '{print $1 $2 $3}' nm_posix.out \> nm2.out
++  ROD awk '{print gensub(/\y(0+)([0-9a-fA-F]+)\y/, "\\2", "g")}' 
nm_bsd.out \> trimmed_nm_bsd.out
++  ROD awk '{print gensub(/\y(0+)([0-9a-fA-F]+)\y/, "\\2", "g")}' 
nm_posix.out \> trimmed_nm_posix.out
++
++  ROD awk '{print $3 $2 $1}' trimmed_nm_bsd.out \> nm1.out
++  ROD awk '{print $1 $2 $3}' trimmed_nm_posix.out \> nm2.out
+ 
+   if diff nm1.out nm2.out > /dev/null; then
+   tst_res TPASS "Got BSD format with -f bsd"
+-- 
+2.7.4
+
diff --git a/meta/recipes-extended/ltp/ltp_20190930.bb 
b/meta/recipes-extended/ltp/ltp_20190930.bb
index e56bb575d2..2853b1c819 100644
--- a/meta/recipes-extended/ltp/ltp_20190930.bb
+++ b/meta/recipes-extended/ltp/ltp_20190930.bb
@@ -41,6 +41,7 @@ SRC_URI = "git://github.com/linux-test-project/ltp.git \

file://0001-mkswap01.sh-Add-udevadm-trigger-before-swap-verifica.patch \
file://0001-testcases-fix-an-absent-format-string-issue.patch \
file://0001-Add-more-musl-exclusions.patch \
+   
file://0001-nm01-Remove-prefix-zeros-of-the-addresses-output-by-.patch \
"
 
 S = "${WORKDIR}/git"
-- 
2.17.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] ✗ patchtest: failure for ltp: Fix nm01 faliure

2020-01-19 Thread Patchwork
== Series Details ==

Series: ltp: Fix nm01 faliure
Revision: 1
URL   : https://patchwork.openembedded.org/series/22131/
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 Added patch file is missing Upstream-Status in the header 
[test_upstream_status_presence_format] 
  Suggested fixAdd Upstream-Status:  to the header of 
meta/recipes-extended/ltp/ltp/0001-nm01-Remove-prefix-zeros-of-the-addresses-output-by-.patch
  Standard format  Upstream-Status: 
  Valid status Pending, Accepted, Backport, Denied, Inappropriate [reason], 
Submitted [where]



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

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core