date:20190123

Re: [OE-core] How to include fitImage-initramfs in rootfs image

2019-01-23 Thread Richard Leitner



On 24/01/2019 08:52, Robert Yang wrote:



On 1/24/19 3:31 PM, Robert Yang wrote:

Hi Richard.L,

On 1/24/19 3:09 PM, Richard Leitner wrote:

Hi,
I'm currently facing issues on how to include a fitImage with 
devicetrees and a INITRAMFS_IMAGE in my rootfs image.



I think that set both INITRAMFS_IMAGE and INITRAMFS_IMAGE_BUNDLE should 
work,

you have set INITRAMFS_IMAGE, so also set:

INITRAMFS_IMAGE_BUNDLE = "1"


That was also my first thought, but unfortunately this doesn't work. 
There's still one fitImage and one fitImage-initramfs-mine in the deploy 
dir and the one included in the rootfs image has the same checksum and 
size as the fitImage without the initramfs.




// Robert




My config is something like:

KERNEL_IMAGETYPE = "fitImage"
KERNEL_CLASSES  = "kernel-fitimage"
KERNEL_DEVICETREE = "a.dtb b.dtb c.dtb"
INITRAMFS_IMAGE = "initramfs-mine"

To include the "normal" fitImage without the initramfs in the rootfs 
the following works:


IMAGE_INSTALL_append += " kernel-image"


When digging around a little bit I found that the 
fitImage-initramfs-mine is
deployed to tmp/deploy/images but there's no package including that 
file.


fitImage-initramfs-mine is an image, so it is not in any package, it is
handled by kernel.bbclass, you can check it for more info.

// Robert



Therefore I'm unable to include it via IMAGE_INSTALL.

Am I missing something?
Is anybody of you aware of a solution?
Does kernel-fitimage and kernel.bbclass offer this at all?

Any help would be greatly appreciated! Thanks!

regards;Richard.L

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

Re: [OE-core] How to include fitImage-initramfs in rootfs image

2019-01-23 Thread Robert Yang




On 1/24/19 3:31 PM, Robert Yang wrote:

Hi Richard.L,

On 1/24/19 3:09 PM, Richard Leitner wrote:

Hi,
I'm currently facing issues on how to include a fitImage with devicetrees and 
a INITRAMFS_IMAGE in my rootfs image.



I think that set both INITRAMFS_IMAGE and INITRAMFS_IMAGE_BUNDLE should work,
you have set INITRAMFS_IMAGE, so also set:

INITRAMFS_IMAGE_BUNDLE = "1"

// Robert




My config is something like:

KERNEL_IMAGETYPE = "fitImage"
KERNEL_CLASSES  = "kernel-fitimage"
KERNEL_DEVICETREE = "a.dtb b.dtb c.dtb"
INITRAMFS_IMAGE = "initramfs-mine"

To include the "normal" fitImage without the initramfs in the rootfs the 
following works:


IMAGE_INSTALL_append += " kernel-image"


When digging around a little bit I found that the fitImage-initramfs-mine is
deployed to tmp/deploy/images but there's no package including that file.


fitImage-initramfs-mine is an image, so it is not in any package, it is
handled by kernel.bbclass, you can check it for more info.

// Robert



Therefore I'm unable to include it via IMAGE_INSTALL.

Am I missing something?
Is anybody of you aware of a solution?
Does kernel-fitimage and kernel.bbclass offer this at all?

Any help would be greatly appreciated! Thanks!

regards;Richard.L

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

Re: [OE-core] How to include fitImage-initramfs in rootfs image

2019-01-23 Thread Richard Leitner




On 24/01/2019 08:31, Robert Yang wrote:

Hi Richard.L,

On 1/24/19 3:09 PM, Richard Leitner wrote:

Hi,
I'm currently facing issues on how to include a fitImage with 
devicetrees and a INITRAMFS_IMAGE in my rootfs image.


My config is something like:

KERNEL_IMAGETYPE = "fitImage"
KERNEL_CLASSES  = "kernel-fitimage"
KERNEL_DEVICETREE = "a.dtb b.dtb c.dtb"
INITRAMFS_IMAGE = "initramfs-mine"

To include the "normal" fitImage without the initramfs in the rootfs 
the following works:


IMAGE_INSTALL_append += " kernel-image"


When digging around a little bit I found that the 
fitImage-initramfs-mine is

deployed to tmp/deploy/images but there's no package including that file.


fitImage-initramfs-mine is an image, so it is not in any package, it is
handled by kernel.bbclass, you can check it for more info.


Ok. I saw how it's generated in the kernel-fitimage.bbclass and 
kernel.bbclass... But is there any "clean" way of adding it to my rootfs 
image like the fitImage?




// Robert



Therefore I'm unable to include it via IMAGE_INSTALL.

Am I missing something?
Is anybody of you aware of a solution?
Does kernel-fitimage and kernel.bbclass offer this at all?

Any help would be greatly appreciated! Thanks!

regards;Richard.L

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

Re: [OE-core] How to include fitImage-initramfs in rootfs image

2019-01-23 Thread Robert Yang


Hi Richard.L,

On 1/24/19 3:09 PM, Richard Leitner wrote:

Hi,
I'm currently facing issues on how to include a fitImage with devicetrees and a 
INITRAMFS_IMAGE in my rootfs image.


My config is something like:

KERNEL_IMAGETYPE = "fitImage"
KERNEL_CLASSES  = "kernel-fitimage"
KERNEL_DEVICETREE = "a.dtb b.dtb c.dtb"
INITRAMFS_IMAGE = "initramfs-mine"

To include the "normal" fitImage without the initramfs in the rootfs the 
following works:


IMAGE_INSTALL_append += " kernel-image"


When digging around a little bit I found that the fitImage-initramfs-mine is
deployed to tmp/deploy/images but there's no package including that file.


fitImage-initramfs-mine is an image, so it is not in any package, it is
handled by kernel.bbclass, you can check it for more info.

// Robert



Therefore I'm unable to include it via IMAGE_INSTALL.

Am I missing something?
Is anybody of you aware of a solution?
Does kernel-fitimage and kernel.bbclass offer this at all?

Any help would be greatly appreciated! Thanks!

regards;Richard.L

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

[OE-core] How to include fitImage-initramfs in rootfs image

2019-01-23 Thread Richard Leitner


Hi,
I'm currently facing issues on how to include a fitImage with 
devicetrees and a INITRAMFS_IMAGE in my rootfs image.


My config is something like:

KERNEL_IMAGETYPE = "fitImage"
KERNEL_CLASSES  = "kernel-fitimage"
KERNEL_DEVICETREE = "a.dtb b.dtb c.dtb"
INITRAMFS_IMAGE = "initramfs-mine"

To include the "normal" fitImage without the initramfs in the rootfs the 
following works:


IMAGE_INSTALL_append += " kernel-image"


When digging around a little bit I found that the 
fitImage-initramfs-mine is deployed to tmp/deploy/images but there's no 
package including that file.


Therefore I'm unable to include it via IMAGE_INSTALL.

Am I missing something?
Is anybody of you aware of a solution?
Does kernel-fitimage and kernel.bbclass offer this at all?

Any help would be greatly appreciated! Thanks!

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

[OE-core] [PATCH 3/3] gcc-runtime: Add --cache-file to EXTRA_OECONF

2019-01-23 Thread Robert Yang

This can save configure time since it runs configure multiple times:
$ time bitbake gcc-runtime -cconfigure
  60s -> 54s

  Saved 6s

Signed-off-by: Robert Yang 
---
 meta/recipes-devtools/gcc/gcc-runtime.inc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-devtools/gcc/gcc-runtime.inc 
b/meta/recipes-devtools/gcc/gcc-runtime.inc
index 50ecc81..3d03d8e 100644
--- a/meta/recipes-devtools/gcc/gcc-runtime.inc
+++ b/meta/recipes-devtools/gcc/gcc-runtime.inc
@@ -15,6 +15,7 @@ EXTRA_OECONF_PATHS = "\
 "
 
 EXTRA_OECONF_append_linuxstdbase = " --enable-clocale=gnu"
+EXTRA_OECONF_append = " --cache-file=${B}/config.cache"
 
 RUNTIMELIBITM = "libitm"
 RUNTIMELIBITM_arc = ""
-- 
2.10.2

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

[OE-core] [PATCH 0/3] meta: Add --cache-file for 3 core recipes

2019-01-23 Thread Robert Yang

The following changes since commit a4edfa4cf451bf412525887b5b24b9db6486ae97:

  remove unused distutils-tools.bbclass (2019-01-23 07:57:02 +)

are available in the git repository at:

  git://git.openembedded.org/openembedded-core-contrib rbt/cf
  http://cgit.openembedded.org/openembedded-core-contrib/log/?h=rbt/cf

Robert Yang (3):
  gettext: Add --cache-file to EXTRA_OECONF
  ncurses: Add --cache-file to EXTRA_OECONF
  gcc-runtime: Add --cache-file to EXTRA_OECONF

 meta/recipes-core/gettext/gettext_0.19.8.1.bb | 1 +
 meta/recipes-core/ncurses/ncurses_6.1+20181013.bb | 2 +-
 meta/recipes-devtools/gcc/gcc-runtime.inc | 1 +
 3 files changed, 3 insertions(+), 1 deletion(-)

-- 
2.10.2

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

[OE-core] [PATCH 1/3] gettext: Add --cache-file to EXTRA_OECONF

2019-01-23 Thread Robert Yang

This can save configure time since it runs configure multiple times:
$ time bitbake gettext-native -cconfigure
  2m22s -> 2m2s

  Saved 20s

Signed-off-by: Robert Yang 
---
 meta/recipes-core/gettext/gettext_0.19.8.1.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-core/gettext/gettext_0.19.8.1.bb 
b/meta/recipes-core/gettext/gettext_0.19.8.1.bb
index 933bacc..4049724 100644
--- a/meta/recipes-core/gettext/gettext_0.19.8.1.bb
+++ b/meta/recipes-core/gettext/gettext_0.19.8.1.bb
@@ -39,6 +39,7 @@ EXTRA_OECONF += "--without-lispdir \
  --without-emacs \
  --without-cvs \
  --without-git \
+ --cache-file=${B}/config.cache \
 "
 EXTRA_OECONF_append_class-target = " \
  --with-bisonlocaledir=${datadir}/locale \
-- 
2.10.2

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

[OE-core] [PATCH 2/3] ncurses: Add --cache-file to EXTRA_OECONF

2019-01-23 Thread Robert Yang

This can save configure time since it runs configure multiple times:
$ time bitbake ncurses-native -cconfigure
  35s -> 25s

  Saved 10s

Signed-off-by: Robert Yang 
---
 meta/recipes-core/ncurses/ncurses_6.1+20181013.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-core/ncurses/ncurses_6.1+20181013.bb 
b/meta/recipes-core/ncurses/ncurses_6.1+20181013.bb
index b462b14..ef6ca98 100644
--- a/meta/recipes-core/ncurses/ncurses_6.1+20181013.bb
+++ b/meta/recipes-core/ncurses/ncurses_6.1+20181013.bb
@@ -7,5 +7,5 @@ SRC_URI += "file://0001-tic-hang.patch \
 # commit id corresponds to the revision in package version
 SRCREV = "7a97a7f937762ba342d5b2fd7cd090885a809835"
 S = "${WORKDIR}/git"
-EXTRA_OECONF += "--with-abi-version=5"
+EXTRA_OECONF += "--with-abi-version=5 --cache-file=${B}/config.cache"
 UPSTREAM_CHECK_GITTAGREGEX = "(?P\d+(\.\d+)+(\+\d+)*)"
-- 
2.10.2

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

[OE-core] [PATCH 2/2] bitbake.conf: Add DEBUG_BUILD to vardeps

2019-01-23 Thread Robert Yang

Otherwise the recipe would not be rebuilt when enable/disable DEBUG_BUILD.

Signed-off-by: Robert Yang 
---
 meta/conf/bitbake.conf | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 0bdcd04..b00a52b 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -609,8 +609,9 @@ DEBUG_FLAGS ?= "-g -feliminate-unused-debug-types 
${DEBUG_PREFIX_MAP}"
 FULL_OPTIMIZATION = "-O2 -pipe ${DEBUG_FLAGS}"
 DEBUG_OPTIMIZATION = "-O -fno-omit-frame-pointer ${DEBUG_FLAGS} -pipe"
 SELECTED_OPTIMIZATION = "${@d.getVar(oe.utils.vartrue('DEBUG_BUILD', 
'DEBUG_OPTIMIZATION', 'FULL_OPTIMIZATION', d))}"
-SELECTED_OPTIMIZATION[vardeps] += "FULL_OPTIMIZATION DEBUG_OPTIMIZATION"
+SELECTED_OPTIMIZATION[vardeps] += "FULL_OPTIMIZATION DEBUG_OPTIMIZATION 
DEBUG_BUILD"
 BUILD_OPTIMIZATION = "${@oe.utils.vartrue('DEBUG_BUILD', '-O -g 
-feliminate-unused-debug-types -fno-omit-frame-pointer', '-O2', d)} -pipe"
+BUILD_OPTIMIZATION[vardeps] += "DEBUG_BUILD"
 
 ##
 # Settings used by bitbake-layers.
-- 
2.10.2

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

[OE-core] [PATCH 0/2] Fixes for DEBUG_BUILD

2019-01-23 Thread Robert Yang

The following changes since commit a4edfa4cf451bf412525887b5b24b9db6486ae97:

  remove unused distutils-tools.bbclass (2019-01-23 07:57:02 +)

are available in the git repository at:

  git://git.openembedded.org/openembedded-core-contrib rbt/debug
  http://cgit.openembedded.org/openembedded-core-contrib/log/?h=rbt/debug

Robert Yang (2):
  native.bbclass/cross.bbclass: No strip sysroot when DEBUG_BUILD
  bitbake.conf: Add DEBUG_BUILD to vardeps

 meta/classes/cross.bbclass  | 3 +++
 meta/classes/native.bbclass | 3 +++
 meta/conf/bitbake.conf  | 3 ++-
 3 files changed, 8 insertions(+), 1 deletion(-)

-- 
2.10.2

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

[OE-core] [PATCH 1/2] native.bbclass/cross.bbclass: No strip sysroot when DEBUG_BUILD

2019-01-23 Thread Robert Yang

This makes dbg work for native tools, and makes debug native tools problem
easier, otherwise, there is no symbol since trippped.

Signed-off-by: Robert Yang 
---
 meta/classes/cross.bbclass  | 3 +++
 meta/classes/native.bbclass | 3 +++
 2 files changed, 6 insertions(+)

diff --git a/meta/classes/cross.bbclass b/meta/classes/cross.bbclass
index 34d7951..f832561 100644
--- a/meta/classes/cross.bbclass
+++ b/meta/classes/cross.bbclass
@@ -17,6 +17,9 @@ HOST_CC_ARCH = "${BUILD_CC_ARCH}"
 HOST_LD_ARCH = "${BUILD_LD_ARCH}"
 HOST_AS_ARCH = "${BUILD_AS_ARCH}"
 
+# No strip sysroot when DEBUG_BUILD is enabled
+INHIBIT_SYSROOT_STRIP ?= "${@oe.utils.vartrue('DEBUG_BUILD', '1', '', d)}"
+
 export lt_cv_sys_lib_dlsearch_path_spec = "${libdir} ${base_libdir} /lib 
/lib64 /usr/lib /usr/lib64"
 
 STAGING_DIR_HOST = "${RECIPE_SYSROOT_NATIVE}"
diff --git a/meta/classes/native.bbclass b/meta/classes/native.bbclass
index ddccfe2e1..30a30f9 100644
--- a/meta/classes/native.bbclass
+++ b/meta/classes/native.bbclass
@@ -119,6 +119,9 @@ PATH_prepend = "${COREBASE}/scripts/native-intercept:"
 # reused if we manipulate the paths.
 SSTATE_SCAN_CMD ?= "${SSTATE_SCAN_CMD_NATIVE}"
 
+# No strip sysroot when DEBUG_BUILD is enabled
+INHIBIT_SYSROOT_STRIP ?= "${@oe.utils.vartrue('DEBUG_BUILD', '1', '', d)}"
+
 python native_virtclass_handler () {
 pn = e.data.getVar("PN")
 if not pn.endswith("-native"):
-- 
2.10.2

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

[OE-core] [PATCH 0/1] native.bbclass: remove invalid CONFIG_SITE

2019-01-23 Thread Robert Yang

The following changes since commit a4edfa4cf451bf412525887b5b24b9db6486ae97:

  remove unused distutils-tools.bbclass (2019-01-23 07:57:02 +)

are available in the git repository at:

  git://git.openembedded.org/openembedded-core-contrib rbt/native
  http://cgit.openembedded.org/openembedded-core-contrib/log/?h=rbt/native

Robert Yang (1):
  native.bbclass: remove invalid CONFIG_SITE

 meta/classes/native.bbclass | 3 ---
 meta/site/native| 1 -
 2 files changed, 4 deletions(-)
 delete mode 100644 meta/site/native

-- 
2.7.4

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

[OE-core] [PATCH 1/1] native.bbclass: remove invalid CONFIG_SITE

2019-01-23 Thread Robert Yang

This CONFIG_SITE has no effect since autotools.bbclass handles it. And the
comment line is out of date, it was for "CONFIG_SITE = ''", so remove them.

Signed-off-by: Robert Yang 
---
 meta/classes/native.bbclass | 3 ---
 meta/site/native| 1 -
 2 files changed, 4 deletions(-)
 delete mode 100644 meta/site/native

diff --git a/meta/classes/native.bbclass b/meta/classes/native.bbclass
index ddccfe2..c20c6dc 100644
--- a/meta/classes/native.bbclass
+++ b/meta/classes/native.bbclass
@@ -54,9 +54,6 @@ TOOLCHAIN_OPTIONS = ""
 # Don't build ptest natively
 PTEST_ENABLED = "0"
 
-# Don't use site files for native builds
-export CONFIG_SITE = "${COREBASE}/meta/site/native"
-
 # set the compiler as well. It could have been set to something else
 export CC = "${BUILD_CC}"
 export CXX = "${BUILD_CXX}"
diff --git a/meta/site/native b/meta/site/native
deleted file mode 100644
index 7dfb1cb..000
--- a/meta/site/native
+++ /dev/null
@@ -1 +0,0 @@
-ac_cv_path_SED=sed
-- 
2.7.4

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

[OE-core] [PATCH 0/1] fontconfig: Fix define for HAVE_POSIX_FADVISE

2019-01-23 Thread Robert Yang

The following changes since commit a4edfa4cf451bf412525887b5b24b9db6486ae97:

  remove unused distutils-tools.bbclass (2019-01-23 07:57:02 +)

are available in the git repository at:

  git://git.openembedded.org/openembedded-core-contrib rbt/ft
  http://cgit.openembedded.org/openembedded-core-contrib/log/?h=rbt/ft

Robert Yang (1):
  fontconfig: Fix define for HAVE_POSIX_FADVISE

 ...cache.c-Fix-define-for-HAVE_POSIX_FADVISE.patch | 33 ++
 .../fontconfig/fontconfig_2.12.6.bb|  1 +
 2 files changed, 34 insertions(+)
 create mode 100644 
meta/recipes-graphics/fontconfig/fontconfig/0001-src-fccache.c-Fix-define-for-HAVE_POSIX_FADVISE.patch

-- 
2.7.4

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

[OE-core] [PATCH 1/1] fontconfig: Fix define for HAVE_POSIX_FADVISE

2019-01-23 Thread Robert Yang

Otherwise, there would be build errors in the following 2 cases:
* define HAVE_POSIX_FADVISE
Or:
* undef HAVE_POSIX_FADVISE

Signed-off-by: Robert Yang 
---
 ...cache.c-Fix-define-for-HAVE_POSIX_FADVISE.patch | 33 ++
 .../fontconfig/fontconfig_2.12.6.bb|  1 +
 2 files changed, 34 insertions(+)
 create mode 100644 
meta/recipes-graphics/fontconfig/fontconfig/0001-src-fccache.c-Fix-define-for-HAVE_POSIX_FADVISE.patch

diff --git 
a/meta/recipes-graphics/fontconfig/fontconfig/0001-src-fccache.c-Fix-define-for-HAVE_POSIX_FADVISE.patch
 
b/meta/recipes-graphics/fontconfig/fontconfig/0001-src-fccache.c-Fix-define-for-HAVE_POSIX_FADVISE.patch
new file mode 100644
index 000..07b2d65
--- /dev/null
+++ 
b/meta/recipes-graphics/fontconfig/fontconfig/0001-src-fccache.c-Fix-define-for-HAVE_POSIX_FADVISE.patch
@@ -0,0 +1,33 @@
+From ab9522177a8396a51812fdbebb6387df451a8499 Mon Sep 17 00:00:00 2001
+From: Robert Yang 
+Date: Mon, 24 Dec 2018 11:03:58 +0800
+Subject: [PATCH] src/fccache.c: Fix define for HAVE_POSIX_FADVISE
+
+Otherwise, there would be build errors in the following 2 cases:
+* define HAVE_POSIX_FADVISE
+Or:
+* undef HAVE_POSIX_FADVISE
+
+Upstream-Status: Pending
+
+Signed-off-by: Robert Yang 
+---
+ fccache.c |2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/fccache.c b/src/fccache.c
+index 6f3c68a..85cc4b4 100644
+--- a/src/fccache.c
 b/src/fccache.c
+@@ -700,7 +700,7 @@ FcDirCacheMapFd (FcConfig *config, int fd, struct stat 
*fd_stat, struct stat *di
+ {
+ #if defined(HAVE_MMAP) || defined(__CYGWIN__)
+   cache = mmap (0, fd_stat->st_size, PROT_READ, MAP_SHARED, fd, 0);
+-#if (HAVE_POSIX_FADVISE) && defined(POSIX_FADV_WILLNEED)
++#if defined(HAVE_POSIX_FADVISE) && defined(POSIX_FADV_WILLNEED)
+   posix_fadvise (fd, 0, fd_stat->st_size, POSIX_FADV_WILLNEED);
+ #endif
+   if (cache == MAP_FAILED)
+-- 
+2.7.4
+
diff --git a/meta/recipes-graphics/fontconfig/fontconfig_2.12.6.bb 
b/meta/recipes-graphics/fontconfig/fontconfig_2.12.6.bb
index 6128d5e..beeae7f 100644
--- a/meta/recipes-graphics/fontconfig/fontconfig_2.12.6.bb
+++ b/meta/recipes-graphics/fontconfig/fontconfig_2.12.6.bb
@@ -23,6 +23,7 @@ DEPENDS = "expat freetype zlib gperf-native"
 SRC_URI = "http://fontconfig.org/release/fontconfig-${PV}.tar.gz \
file://revert-static-pkgconfig.patch \
file://0001-src-fcxml.c-avoid-double-free-of-filename.patch \
+   file://0001-src-fccache.c-Fix-define-for-HAVE_POSIX_FADVISE.patch \
"
 
 SRC_URI[md5sum] = "00e748c67fad11e7057a71ed385e8bdb"
-- 
2.7.4

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

[OE-core] [PATCH 1/1] packagegroup.bbclass: Set INHIBIT_DEFAULT_DEPS

2019-01-23 Thread Robert Yang

It doesn't need them since no compile happens.

Signed-off-by: Robert Yang 
---
 meta/classes/packagegroup.bbclass | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/classes/packagegroup.bbclass 
b/meta/classes/packagegroup.bbclass
index d540d42..94a59e0 100644
--- a/meta/classes/packagegroup.bbclass
+++ b/meta/classes/packagegroup.bbclass
@@ -48,6 +48,8 @@ deltask do_compile
 deltask do_install
 deltask do_populate_sysroot
 
+INHIBIT_DEFAULT_DEPS = "1"
+
 python () {
 if bb.data.inherits_class('nativesdk', d):
 return
-- 
2.7.4

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

[OE-core] [PATCH 0/1] packagegroup.bbclass: Set INHIBIT_DEFAULT_DEPS

2019-01-23 Thread Robert Yang

The following changes since commit a4edfa4cf451bf412525887b5b24b9db6486ae97:

  remove unused distutils-tools.bbclass (2019-01-23 07:57:02 +)

are available in the git repository at:

  git://git.openembedded.org/openembedded-core-contrib rbt/package
  http://cgit.openembedded.org/openembedded-core-contrib/log/?h=rbt/package

Robert Yang (1):
  packagegroup.bbclass: Set INHIBIT_DEFAULT_DEPS

 meta/classes/packagegroup.bbclass | 2 ++
 1 file changed, 2 insertions(+)

-- 
2.7.4

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

[OE-core] [PATCH 5/5] ccache: Fix Segmentation fault error when gcc -o /dev/null

2019-01-23 Thread Robert Yang

Fixed:
$ export CCACHE_DEBUG=1
$ ccache gcc -c hello.c -o /dev/null

Segmentation fault (core dumped)

This is because failed to open /dev/null.foo (Permission denied), check file
stream before write to it can fix the problem.

Signed-off-by: Robert Yang 
---
 meta/recipes-devtools/ccache/ccache_3.6.bb |  1 +
 ...mentation-fault-error-when-gcc-o-dev-null.patch | 79 ++
 2 files changed, 80 insertions(+)
 create mode 100644 
meta/recipes-devtools/ccache/files/0003-Fix-Segmentation-fault-error-when-gcc-o-dev-null.patch

diff --git a/meta/recipes-devtools/ccache/ccache_3.6.bb 
b/meta/recipes-devtools/ccache/ccache_3.6.bb
index a12306e..60807be 100644
--- a/meta/recipes-devtools/ccache/ccache_3.6.bb
+++ b/meta/recipes-devtools/ccache/ccache_3.6.bb
@@ -8,4 +8,5 @@ SRC_URI[sha256sum] = 
"a3f2b91a2353b65a863c5901251efe48060ecdebec46b5eaec8ea8e092
 
 SRC_URI += " \
 file://0002-dev.mk.in-fix-file-name-too-long.patch \
+file://0003-Fix-Segmentation-fault-error-when-gcc-o-dev-null.patch 
\
 "
diff --git 
a/meta/recipes-devtools/ccache/files/0003-Fix-Segmentation-fault-error-when-gcc-o-dev-null.patch
 
b/meta/recipes-devtools/ccache/files/0003-Fix-Segmentation-fault-error-when-gcc-o-dev-null.patch
new file mode 100644
index 000..b3012b7
--- /dev/null
+++ 
b/meta/recipes-devtools/ccache/files/0003-Fix-Segmentation-fault-error-when-gcc-o-dev-null.patch
@@ -0,0 +1,79 @@
+From c51b63758e95247e3c1e2f06e5f5bfb49849e66d Mon Sep 17 00:00:00 2001
+From: Robert Yang 
+Date: Tue, 22 Jan 2019 16:30:52 +0800
+Subject: [PATCH] Fix Segmentation fault error when gcc -o /dev/null
+
+Fixed:
+$ export CCACHE_DEBUG=1
+$ ccache gcc -c hello.c -o /dev/null
+
+Segmentation fault (core dumped)
+
+This is because failed to open /dev/null.foo (Permission denied), check file
+stream before write to it can fix the problem.
+
+Upstream-Status: Backport 
[https://github.com/ccache/ccache/commit/4d86e884d07ba1853a0c70507cc4d04107f57c29]
+
+Signed-off-by: Robert Yang 
+---
+ src/ccache.c | 15 ---
+ src/util.c   |  8 ++--
+ 2 files changed, 18 insertions(+), 5 deletions(-)
+
+diff --git a/src/ccache.c b/src/ccache.c
+index b4cdb86..8c227df 100644
+--- a/src/ccache.c
 b/src/ccache.c
+@@ -521,9 +521,13 @@ init_hash_debug(struct hash *hash, const char *obj_path, 
char type,
+ 
+   char *path = format("%s.ccache-input-%c", obj_path, type);
+   FILE *debug_binary_file = fopen(path, "wb");
+-  hash_enable_debug(hash, section_name, debug_binary_file, 
debug_text_file);
++  if (debug_binary_file) {
++  hash_enable_debug(hash, section_name, debug_binary_file, 
debug_text_file);
++  exitfn_add(fclose_exitfn, debug_binary_file);
++  } else {
++  cc_log("Failed to open %s: %s", path, strerror(errno));
++  }
+   free(path);
+-  exitfn_add(fclose_exitfn, debug_binary_file);
+ }
+ 
+ static enum guessed_compiler
+@@ -3670,8 +3674,13 @@ ccache(int argc, char *argv[])
+   if (conf->debug) {
+   char *path = format("%s.ccache-input-text", output_obj);
+   debug_text_file = fopen(path, "w");
++  if (debug_text_file) {
++  exitfn_add(fclose_exitfn, debug_text_file);
++  }
++  else {
++  cc_log("Failed to open %s: %s", path, strerror(errno));
++  }
+   free(path);
+-  exitfn_add(fclose_exitfn, debug_text_file);
+   }
+ 
+   struct hash *common_hash = hash_init();
+diff --git a/src/util.c b/src/util.c
+index e442cc4..a49fb4c 100644
+--- a/src/util.c
 b/src/util.c
+@@ -219,8 +219,12 @@ void
+ cc_dump_log_buffer(const char *path)
+ {
+   FILE *file = fopen(path, "w");
+-  (void) fwrite(logbuffer, 1, logsize, file);
+-  fclose(file);
++  if (file) {
++  (void) fwrite(logbuffer, 1, logsize, file);
++  fclose(file);
++  } else {
++  cc_log("Failed to open %s: %s", path, strerror(errno));
++  }
+ }
+ 
+ // Something went badly wrong!
+-- 
+2.7.4
+
-- 
2.7.4

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

[OE-core] [PATCH 2/5] bitbake.conf: Add CCACHE_TOP_DIR to BB_HASHBASE_WHITELIST

2019-01-23 Thread Robert Yang

As we did for SSTATE_DIR.

Signed-off-by: Robert Yang 
---
 meta/conf/bitbake.conf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 0bdcd04..4ee14c6 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -866,7 +866,7 @@ BB_HASHBASE_WHITELIST ?= "TMPDIR FILE PATH PWD BB_TASKHASH 
BBPATH BBSERVER DL_DI
 WARN_QA ERROR_QA WORKDIR STAMPCLEAN PKGDATA_DIR BUILD_ARCH SSTATE_PKGARCH \
 BB_WORKERCONTEXT BB_LIMITEDDEPS BB_UNIHASH extend_recipe_sysroot 
DEPLOY_DIR \
 SSTATE_HASHEQUIV_METHOD SSTATE_HASHEQUIV_SERVER 
SSTATE_HASHEQUIV_REPORT_TASKDATA \
-SSTATE_HASHEQUIV_OWNER"
+SSTATE_HASHEQUIV_OWNER CCACHE_TOP_DIR"
 BB_HASHCONFIG_WHITELIST ?= "${BB_HASHBASE_WHITELIST} DATE TIME SSH_AGENT_PID \
 SSH_AUTH_SOCK PSEUDO_BUILD BB_ENV_EXTRAWHITE DISABLE_SANITY_CHECKS \
 PARALLEL_MAKE BB_NUMBER_THREADS BB_ORIGENV BB_INVALIDCONF BBINCLUDED \
-- 
2.7.4

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

[OE-core] [PATCH 4/5] ccache: 3.5 -> 3.6

2019-01-23 Thread Robert Yang

* Rebased 0002-dev.mk.in-fix-file-name-too-long.patch and sent it to upstream,
  and got merged.
* The LIC_FILES_CHKSUM is changed because of year updated.

Signed-off-by: Robert Yang 
---
 meta/recipes-devtools/ccache/ccache_3.5.bb| 11 ---
 meta/recipes-devtools/ccache/ccache_3.6.bb| 11 +++
 .../ccache/files/0002-dev.mk.in-fix-file-name-too-long.patch  |  8 
 3 files changed, 15 insertions(+), 15 deletions(-)
 delete mode 100644 meta/recipes-devtools/ccache/ccache_3.5.bb
 create mode 100644 meta/recipes-devtools/ccache/ccache_3.6.bb

diff --git a/meta/recipes-devtools/ccache/ccache_3.5.bb 
b/meta/recipes-devtools/ccache/ccache_3.5.bb
deleted file mode 100644
index 89062c4..000
--- a/meta/recipes-devtools/ccache/ccache_3.5.bb
+++ /dev/null
@@ -1,11 +0,0 @@
-require ccache.inc
-
-LICENSE = "GPLv3+"
-LIC_FILES_CHKSUM = "file://LICENSE.adoc;md5=39f34d6ff4df51ed718fd7d243fc4e51"
-
-SRC_URI[md5sum] = "6e62bf2fd2c8fdc749efdca74868da41"
-SRC_URI[sha256sum] = 
"8094f9bc186be4c9db9b480eeac280926bd44039502d1e596f45371b05a85918"
-
-SRC_URI += " \
-file://0002-dev.mk.in-fix-file-name-too-long.patch \
-"
diff --git a/meta/recipes-devtools/ccache/ccache_3.6.bb 
b/meta/recipes-devtools/ccache/ccache_3.6.bb
new file mode 100644
index 000..a12306e
--- /dev/null
+++ b/meta/recipes-devtools/ccache/ccache_3.6.bb
@@ -0,0 +1,11 @@
+require ccache.inc
+
+LICENSE = "GPLv3+"
+LIC_FILES_CHKSUM = "file://LICENSE.adoc;md5=70762511f9c509cc2a4e4ba2ef687ae3"
+
+SRC_URI[md5sum] = "bd6fd69db28426baf22ec0acdd5c4b2a"
+SRC_URI[sha256sum] = 
"a3f2b91a2353b65a863c5901251efe48060ecdebec46b5eaec8ea8e092b9e871"
+
+SRC_URI += " \
+file://0002-dev.mk.in-fix-file-name-too-long.patch \
+"
diff --git 
a/meta/recipes-devtools/ccache/files/0002-dev.mk.in-fix-file-name-too-long.patch
 
b/meta/recipes-devtools/ccache/files/0002-dev.mk.in-fix-file-name-too-long.patch
index 68c2371..16a6e9d 100644
--- 
a/meta/recipes-devtools/ccache/files/0002-dev.mk.in-fix-file-name-too-long.patch
+++ 
b/meta/recipes-devtools/ccache/files/0002-dev.mk.in-fix-file-name-too-long.patch
@@ -1,13 +1,13 @@
 From 7dab2995ed8eeccd7b0acd79668bc28f3a2427d5 Mon Sep 17 00:00:00 2001
 From: Robert Yang 
 Date: Wed, 16 Sep 2015 19:45:40 -0700
-Subject: [PATCH] dev.mk.in: fix file name too long
+Subject: [PATCH] dev.mk.in: fix file name too long error
 
-The all_cppflags change paths to filename which cause file name too long
+The all_cppflags changes path to filename which causes file name too long
 error when the path is longer than NAME_MAX (usually 255). Strip srcdir
 to fix the problem.
 
-Upstream-Status: Pending
+Upstream-Status: Backport 
[https://github.com/ccache/ccache/commit/4d86e884d07ba1853a0c70507cc4d04107f57c29]
 
 Signed-off-by: Robert Yang 
 
@@ -22,7 +22,7 @@ index 91b0a57..583ade0 100644
 @@ -1,7 +1,7 @@
  # GNU make syntax reigns in this file.
  
- all_cflags += -Werror
+ all_cflags += -Werror @more_warnings@
 -all_cppflags += -MD -MP -MF .deps/$(subst .._,,$(subst /,_,$<)).d
 +all_cppflags += -MD -MP -MF .deps/$(subst .._,,$(subst /,_,$(subst 
$(srcdir)/,,$<))).d
  
-- 
2.7.4

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

[OE-core] [PATCH 1/5] cmake-native: Add --enable-ccache to configure options

2019-01-23 Thread Robert Yang

cmake-native requires --enable-ccache to enable ccache, target recipe doesn't
need this since it is already handled by cmake.bbclass.

Signed-off-by: Robert Yang 
---
 meta/recipes-devtools/cmake/cmake-native_3.12.2.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-devtools/cmake/cmake-native_3.12.2.bb 
b/meta/recipes-devtools/cmake/cmake-native_3.12.2.bb
index 2f4ecc4..fedcf3d 100644
--- a/meta/recipes-devtools/cmake/cmake-native_3.12.2.bb
+++ b/meta/recipes-devtools/cmake/cmake-native_3.12.2.bb
@@ -29,6 +29,7 @@ CMAKE_EXTRACONF = "\
 do_configure () {
${S}/configure --verbose --prefix=${prefix} \
${@oe.utils.parallel_make_argument(d, '--parallel=%d')} \
+   ${@bb.utils.contains('CCACHE', 'ccache ', '--enable-ccache', 
'', d)} \
-- ${CMAKE_EXTRACONF}
 }
 
-- 
2.7.4

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

[OE-core] [PATCH 3/5] ccache.bbclass: Only let native recipes depend on ccache-native

2019-01-23 Thread Robert Yang

Make native recipes depend on ccache-native should be enough since native
recipes are on target/nativesdk recipes' dependency chain, this can reduce the
size of DEPENDS.

Signed-off-by: Robert Yang 
---
 meta/classes/ccache.bbclass | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/meta/classes/ccache.bbclass b/meta/classes/ccache.bbclass
index b545735..6caaca7 100644
--- a/meta/classes/ccache.bbclass
+++ b/meta/classes/ccache.bbclass
@@ -47,8 +47,11 @@ python() {
 # quilt-native doesn't need ccache since no c files
 if not (pn in ('ccache-native', 'quilt-native') or
 bb.utils.to_boolean(d.getVar('CCACHE_DISABLE'))):
-d.appendVar('DEPENDS', ' ccache-native')
 d.setVar('CCACHE', 'ccache ')
+# Make native recipes depend on ccache-native should be enough since
+# native recipes are on target recipes' dependency chain.
+if bb.data.inherits_class('native', d):
+d.appendVar('DEPENDS', ' ccache-native')
 }
 
 addtask cleanccache after do_clean
-- 
2.7.4

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

[OE-core] [PATCH 0/5] Fixes for ccache

2019-01-23 Thread Robert Yang

The following changes since commit a4edfa4cf451bf412525887b5b24b9db6486ae97:

  remove unused distutils-tools.bbclass (2019-01-23 07:57:02 +)

are available in the git repository at:

  git://git.openembedded.org/openembedded-core-contrib rbt/ccache
  http://cgit.openembedded.org/openembedded-core-contrib/log/?h=rbt/ccache

Robert Yang (5):
  cmake-native: Add --enable-ccache to configure options
  bitbake.conf: Add CCACHE_TOP_DIR to BB_HASHBASE_WHITELIST
  ccache.bbclass: Only let native recipes depend on ccache-native
  ccache: 3.5 -> 3.6
  ccache: Fix Segmentation fault error when gcc -o /dev/null

 meta/classes/ccache.bbclass|  5 +-
 meta/conf/bitbake.conf |  2 +-
 meta/recipes-devtools/ccache/ccache_3.5.bb | 11 ---
 meta/recipes-devtools/ccache/ccache_3.6.bb | 12 
 .../0002-dev.mk.in-fix-file-name-too-long.patch|  8 +--
 ...mentation-fault-error-when-gcc-o-dev-null.patch | 79 ++
 meta/recipes-devtools/cmake/cmake-native_3.12.2.bb |  1 +
 7 files changed, 101 insertions(+), 17 deletions(-)
 delete mode 100644 meta/recipes-devtools/ccache/ccache_3.5.bb
 create mode 100644 meta/recipes-devtools/ccache/ccache_3.6.bb
 create mode 100644 
meta/recipes-devtools/ccache/files/0003-Fix-Segmentation-fault-error-when-gcc-o-dev-null.patch

-- 
2.7.4

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

[OE-core] [PATCH 1/1] perl: Make install.perl depend on install.sym

2019-01-23 Thread Robert Yang

Fixed a race issue when do_install:
Generating wrapper script for
/path/to/8.1-r0/image/path/to/8.1-r0/recipe-sysroot-native/usr/bin/perl-native/perl5.28.1
mv: cannot stat
/path/to/8.1-r0/image/path/to/8.1-r0/recipe-sysroot-native/usr/bin/perl-native/perl5.28.1:
No such file or directory

Signed-off-by: Robert Yang 
---
 ...e-Make-install.perl-depend-on-install.sym.patch | 32 ++
 meta/recipes-devtools/perl-sanity/perl_5.28.1.bb   |  1 +
 2 files changed, 33 insertions(+)
 create mode 100644 
meta/recipes-devtools/perl-sanity/files/0001-Makefile-Make-install.perl-depend-on-install.sym.patch

diff --git 
a/meta/recipes-devtools/perl-sanity/files/0001-Makefile-Make-install.perl-depend-on-install.sym.patch
 
b/meta/recipes-devtools/perl-sanity/files/0001-Makefile-Make-install.perl-depend-on-install.sym.patch
new file mode 100644
index 000..1267339
--- /dev/null
+++ 
b/meta/recipes-devtools/perl-sanity/files/0001-Makefile-Make-install.perl-depend-on-install.sym.patch
@@ -0,0 +1,32 @@
+From a0a2fcac3735ca90017976d2b87f550d051a969b Mon Sep 17 00:00:00 2001
+From: Robert Yang 
+Date: Tue, 22 Jan 2019 19:21:27 -0800
+Subject: [PATCH] Makefile: Make install.perl depend on install.sym
+
+Fix a race issue when install, there might be no
+$(installbin)/$(perlname)$(version) when install.sym runs after install.perl
+since install.sym removes it.
+
+Upstream-Status: Submitted [https://github.com/arsv/perl-cross/pull/73]
+
+Signed-off-by: Robert Yang 
+---
+ Makefile | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/Makefile b/Makefile
+index cd8d75f..1aa8ef2 100644
+--- a/Makefile
 b/Makefile
+@@ -406,7 +406,7 @@ META.yml: Porting/makemeta Porting/Maintainers.pl 
Porting/Maintainers.pm miniper
+ 
+ install: install.perl install.sym install.man
+ 
+-install.perl: installperl | miniperl$X
++install.perl: installperl install.sym | miniperl$X
+   ./miniperl_top installperl --destdir=$(DESTDIR) $(INSTALLFLAGS) 
$(STRIPFLAGS)
+   -@test ! -s extras.lst || $(MAKE) extras.install
+ 
+-- 
+2.10.2
+
diff --git a/meta/recipes-devtools/perl-sanity/perl_5.28.1.bb 
b/meta/recipes-devtools/perl-sanity/perl_5.28.1.bb
index 176980e..a2ec264 100644
--- a/meta/recipes-devtools/perl-sanity/perl_5.28.1.bb
+++ b/meta/recipes-devtools/perl-sanity/perl_5.28.1.bb
@@ -23,6 +23,7 @@ SRC_URI = 
"https://www.cpan.org/src/5.0/perl-${PV}.tar.gz;name=perl \
file://fix-race-failures-2.patch \

file://0001-Also-build-dynaloader-separately-as-race-failures-ha.patch \
file://0001-Make-sure-install.perl-runs-before-install.man.patch \
+   file://0001-Makefile-Make-install.perl-depend-on-install.sym.patch \
"
 
 SRC_URI[perl.md5sum] = "838198c43d4f39d7af797e2f59c2bee5"
-- 
2.10.2

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

[OE-core] [PATCH 0/1] perl: Make install.perl depend on install.sym

2019-01-23 Thread Robert Yang

The following changes since commit a4edfa4cf451bf412525887b5b24b9db6486ae97:

  remove unused distutils-tools.bbclass (2019-01-23 07:57:02 +)

are available in the git repository at:

  git://git.openembedded.org/openembedded-core-contrib rbt/perl
  http://cgit.openembedded.org/openembedded-core-contrib/log/?h=rbt/perl

Robert Yang (1):
  perl: Make install.perl depend on install.sym

 ...e-Make-install.perl-depend-on-install.sym.patch | 32 ++
 meta/recipes-devtools/perl-sanity/perl_5.28.1.bb   |  1 +
 2 files changed, 33 insertions(+)
 create mode 100644 
meta/recipes-devtools/perl-sanity/files/0001-Makefile-Make-install.perl-depend-on-install.sym.patch

-- 
2.10.2

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

Re: [OE-core] [PATCH 1/2 v5] resultstool: enable merge, store, report and regression analysis

2019-01-23 Thread Yeoh, Ee Peng

RP,

The current patch allow files based regression, meaning if you have file#1 and 
file#2, the regression will select result instances for regression based on the 
configuration data available. 

There are 2 more regression use cases that I have in mind:
Use case#1: directory based regression - Assumed that there are 2 directories 
storing list of result files. User shall provide these 2 directories for 
regression, regression scripts will first parse through all the available files 
inside each directories, then perform regression based on available 
configuration data to determine the regression pair (eg. select result_set_1 
from directory#1 and result_set_x from directory#2 if they both have matching 
configurations). 

Use case#2: git branch based regression - Assumed that result files are stored 
inside git repository with specific git branch storing result files for single 
commit. User shall provide the 2 specific git branches for regression, 
regression scripts will first parse through all the available files inside each 
git branch, then perform regression based on available configuration data to 
determine the regression pair (eg. select result_set_1 from git_branch_1 and 
result_set_x from git_branch_2 if they both have matching configurations).

Any idea which regression use cases above was needed? We shall develop the next 
regression functionalities based on your inputs. 

Best regards,
Yeoh Ee Peng 

-Original Message-
From: Yeoh, Ee Peng 
Sent: Tuesday, January 22, 2019 5:42 PM
To: openembedded-core@lists.openembedded.org
Cc: Yeoh, Ee Peng 
Subject: [PATCH 1/2 v5] resultstool: enable merge, store, report and regression 
analysis

OEQA outputs test results into json files and these files were archived by 
Autobuilder during QA releases. Example: each oe-selftest run by Autobuilder 
for different host distro generate a testresults.json file.

These scripts were developed as a test result tools to manage these 
testresults.json file.

Using the "store" operation, user can store multiple testresults.json files as 
well as the pre-configured directories used to hold those files.

Using the "merge" operation, user can merge multiple testresults.json files to 
a target file.

Using the "report" operation, user can view the test result summary for all 
available testresults.json files inside a ordinary directory or a git 
repository.

Using the "regression" operation, user can perform regression analysis on 
testresults.json files specified.

These resultstool operations expect the testresults.json file to use the json 
format below.
{
"": {
"configuration": {
"": "",
"": "",
...
"": "",
},
"result": {
"": {
"status": "",
"log": ""
},
"": {
"status": "",
"log": ""
},
...
"": {
"status": "",
"log": ""
},
}
},
...
"": {
"configuration": {
"": "",
"": "",
...
"": "",
},
"result": {
"": {
"status": "",
"log": ""
},
"": {
"status": "",
"log": ""
},
...
"": {
"status": "",
"log": ""
},
}
},
}

To use these scripts, first source oe environment, then run the entry point 
script to look for help.
$ resultstool

To store test result from oeqa automated tests, execute the below
$ resultstool store  

To merge multiple testresults.json files, execute the below
$ resultstool merge  

To report test report, execute the below
$ resultstool report 

To perform regression analysis, execute the below
$ resultstool regression  

[YOCTO# 13012]
[YOCTO# 12654]

Signed-off-by: Yeoh Ee Peng 
---
 meta/lib/oeqa/files/testresults/testresults.json   |  40 ++
 meta/lib/oeqa/selftest/cases/resultstooltests.py   | 104 
 scripts/lib/resultstool/__init__.py|   0
 scripts/lib/resultstool/merge.py   |  71 +++
 scripts/lib/resultstool/regression.py  | 134 +
 scripts/lib/resultstool/report.py  | 122 +++
 scripts/lib/resultstool/resultsutils.py|  47 
 scripts/lib/resultstool/store.py   | 110 +
 .../resultstool/template/test_report_full_text.txt |  35 ++
 scripts/resultstool|  84 +
 10 files changed, 747 insertions(+)
 create mode 100644 meta/lib/oeqa/files/testresults/testresults.json
 create mode 100644 meta/lib/oeqa/selftest/cases/resultstooltests.py
 create mode 100644 scripts/lib/resultstool/__init__.py
 create mode 100644 scripts/lib/resultstool/mer

[OE-core] [PATCH V2] arch-arm: Do not add -march options for arm architecture along with -mcpu

2019-01-23 Thread Khem Raj

tune files which inherit the arch definitions already define appropriate
-mcpu option, which is equivalent of right -march and -mtune combination
and is preferred since gcc is getting stricter and stricter with option
check semantics and can now find incompatible -march and -mcpu options
better with every release. It does internal feature consistency check
and if it finds out discrepency between what -mcpu would expand to as
compared to -march it will flag the options to be incompatible, for
naked eye it sounds wrong but gcc would translate -mcpu to a given
-march internally and it might not match to what we set in these arch
files.

The effects are quite subtle, where this can result in configure test
failing to compile due to these incompatible options and a feature
option getting disabled for a recipe for no reason.

e.g. with gcc9 which can now detect that -mcpu=cortex-a5 and
-march=armv7-a are incompatible, many features in libstdc++ ends up
disabled due to configure check failures e.g. size_t size, ptrdiff_t
sizes, which inturn results in compiling libstdc++ with unwanted
disabled features.

If user has machine definitions which do not inherit the arm tune files
then they can still use the -march switch as such

Signed-off-by: Khem Raj 
---
v2: Only delete -march if -mcpu is set

 meta/conf/machine/include/arm/arch-armv4.inc | 3 ++-
 meta/conf/machine/include/arm/arch-armv5.inc | 3 ++-
 meta/conf/machine/include/arm/arch-armv6.inc | 3 ++-
 meta/conf/machine/include/arm/arch-armv7a.inc| 3 ++-
 meta/conf/machine/include/arm/arch-armv7ve.inc   | 3 ++-
 meta/conf/machine/include/tune-arm1136jf-s.inc   | 2 ++
 meta/conf/machine/include/tune-arm920t.inc   | 2 ++
 meta/conf/machine/include/tune-arm926ejs.inc | 2 ++
 meta/conf/machine/include/tune-arm9tdmi.inc  | 2 ++
 meta/conf/machine/include/tune-cortexa15.inc | 2 ++
 meta/conf/machine/include/tune-cortexa17.inc | 2 ++
 meta/conf/machine/include/tune-cortexa5.inc  | 2 ++
 meta/conf/machine/include/tune-cortexa7.inc  | 2 ++
 meta/conf/machine/include/tune-cortexa8.inc  | 2 ++
 meta/conf/machine/include/tune-cortexa9.inc  | 2 ++
 meta/conf/machine/include/tune-ep9312.inc| 4 +++-
 meta/conf/machine/include/tune-iwmmxt.inc| 4 +++-
 meta/conf/machine/include/tune-strongarm1100.inc | 2 ++
 meta/conf/machine/include/tune-thunderx.inc  | 2 ++
 meta/conf/machine/include/tune-xscale.inc| 2 ++
 20 files changed, 42 insertions(+), 7 deletions(-)

diff --git a/meta/conf/machine/include/arm/arch-armv4.inc 
b/meta/conf/machine/include/arm/arch-armv4.inc
index 47a7ad2830..d31b67623c 100644
--- a/meta/conf/machine/include/arm/arch-armv4.inc
+++ b/meta/conf/machine/include/arm/arch-armv4.inc
@@ -2,7 +2,8 @@ DEFAULTTUNE ?= "armv4"
 
 TUNEVALID[arm] = "Enable ARM instruction set"
 TUNEVALID[armv4] = "Enable instructions for ARMv4"
-TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'armv4', ' 
-march=armv4t', '', d)}"
+TUNE_MARCH ?= "-march=armv4t"
+TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'armv4', ' 
${TUNE_MARCH}', '', d)}"
 # enable --fix-v4bx when we have armv4 in TUNE_FEATURES, but then disable it 
when we have also armv5 or thumb
 # maybe we should extend bb.utils.contains to support check for any 
checkvalues in value, now it does 
 # checkvalues.issubset(val) which cannot be used for negative test of foo 
neither bar in value
diff --git a/meta/conf/machine/include/arm/arch-armv5.inc 
b/meta/conf/machine/include/arm/arch-armv5.inc
index f9068af9de..868694a44c 100644
--- a/meta/conf/machine/include/arm/arch-armv5.inc
+++ b/meta/conf/machine/include/arm/arch-armv5.inc
@@ -2,7 +2,8 @@ DEFAULTTUNE ?= "armv5"
 
 TUNEVALID[armv5] = "Enable instructions for ARMv5"
 TUNECONFLICTS[armv5] = "armv4"
-TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'armv5', ' 
-march=armv5t${ARMPKGSFX_DSP}', '', d)}"
+TUNE_MARCH ?= "-march=armv5t${ARMPKGSFX_DSP}"
+TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'armv5', ' 
${TUNE_MARCH}', '', d)}"
 MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'armv5', 'armv5:', 
'' ,d)}"
 
 require conf/machine/include/arm/arch-armv4.inc
diff --git a/meta/conf/machine/include/arm/arch-armv6.inc 
b/meta/conf/machine/include/arm/arch-armv6.inc
index 6c838e999c..e5d3ecec06 100644
--- a/meta/conf/machine/include/arm/arch-armv6.inc
+++ b/meta/conf/machine/include/arm/arch-armv6.inc
@@ -2,7 +2,8 @@ DEFAULTTUNE ?= "armv6hf"
 
 TUNEVALID[armv6] = "Enable instructions for ARMv6"
 TUNECONFLICTS[armv6] = "armv4 armv5"
-TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'armv6', ' 
-march=armv6', '', d)}"
+TUNE_MARCH ?= "-march=armv6"
+TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'armv6', ' 
${TUNE_MARCH}', '', d)}"
 MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'armv6', 'armv6:', 
'' ,d)}"
 
 require conf/machine/include/arm/arch-armv5-dsp.inc
diff --git a/meta/conf/machine/include/arm/arch-armv7a.inc 
b/meta/conf/machine/include

Re: [OE-core] [PATCH 10/10] devtool: add a command to print an overall list of recipes that can be updated

2019-01-23 Thread akuster808




On 1/23/19 8:17 AM, Alexander Kanavin wrote:
> A sample portion of the output:
>
> $ devtool check-upgrade-status
> ...
> NOTE: acpid 2.0.30  2.0.31  Ross Burton 
> 
> NOTE: u-boot-fw-utils   2018.11 2019.01 Marek Vasut 
>  d3689267f92c5956e09cc7d1baa4700141662bff
> NOTE: u-boot-tools  2018.11 2019.01 Marek Vasut 
>  d3689267f92c5956e09cc7d1baa4700141662bff
> NOTE: u-boot2018.11 2019.01 Marek Vasut 
>  d3689267f92c5956e09cc7d1baa4700141662bff
> NOTE: bind  9.11.5  9.13.5  Armin Kuster 
>   cannot be updated due to: 9.11 is LTS 2021
> NOTE: iproute2  4.19.0  4.20.0  Changhyeok 
> Bae 
> NOTE: ofono 1.251.27Ross Burton 
> 
> NOTE: wpa-supplicant2.6 2.7 Changhyeok 
> Bae 
> NOTE: base-passwd   3.5.29  3.5.45  Anuj Mittal 
>   cannot be updated due to: Version 3.5.38 requires 
> cdebconf for update-passwd utility
> NOTE: busybox   1.29.2  1.30.0  Andrej Valek 
> 
> NOTE: dbus-test 1.12.10 1.12.12 Chen Qi 
> 
> NOTE: dbus  1.12.10 1.12.12 Chen Qi 
> 
> NOTE: glib-2.0  2.58.0  2.58.3  Anuj Mittal 
> 
> NOTE: glib-networking   2.54.1  2.58.0  Anuj Mittal 
> 

this looks great.

thanks.

- armin
> ...
>
> Signed-off-by: Alexander Kanavin 
> ---
>  scripts/lib/devtool/upgrade.py | 20 
>  1 file changed, 20 insertions(+)
>
> diff --git a/scripts/lib/devtool/upgrade.py b/scripts/lib/devtool/upgrade.py
> index 202007793b2..42a4c0e4bff 100644
> --- a/scripts/lib/devtool/upgrade.py
> +++ b/scripts/lib/devtool/upgrade.py
> @@ -600,6 +600,20 @@ def latest_version(args, config, basepath, workspace):
>  tinfoil.shutdown()
>  return 0
>  
> +def check_upgrade_status(args, config, basepath, workspace):
> +if not args.recipe:
> +logger.info("Checking the upstream status for all recipes may take a 
> few minutes")
> +results = oe.recipeutils.get_recipe_upgrade_status(args.recipe)
> +for result in results:
> +# pn, update_status, current, latest, maintainer, latest_commit, 
> no_update_reason
> +if result[1] != 'MATCH':
> +logger.info("{:25} {:15} {:15} {} {} {}".format(   result[0],
> +   result[2],
> +   result[1] if 
> result[1] != 'UPDATE' else (result[3] if not 
> result[3].endswith("new-commits-available") else "new commits"),
> +   result[4],
> +   result[5] if 
> result[5] != 'N/A' else "",
> +   "cannot be 
> updated due to: %s" %(result[6]) if result[6] else ""))
> +
>  def register_commands(subparsers, context):
>  """Register devtool subcommands from this plugin"""
>  
> @@ -627,3 +641,9 @@ def register_commands(subparsers, context):
>group='info')
>  parser_latest_version.add_argument('recipename', help='Name of recipe to 
> query (just name - no version, path or extension)')
>  parser_latest_version.set_defaults(func=latest_version)
> +
> +parser_check_upgrade_status = 
> subparsers.add_parser('check-upgrade-status', help="Report upgradability for 
> multiple (or all) recipes",
> +description="Prints 
> a table of recipes together with versions currently provided by recipes, and 
> latest upstream versions, when there is a later version available",
> +group='info')
> +parser_check_upgrade_status.add_argument('recipe', help='Name of the 
> recipe to report (omit to report upgrade info for all recipes)', nargs='*')
> +parser_check_upgrade_status.set_defaults(func=check_upgrade_status)

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

Re: [OE-core] [PATCH] arch-arm: Do not add -march options for arm architecture

2019-01-23 Thread Andre McCurdy

On Wed, Jan 23, 2019 at 2:50 PM Khem Raj  wrote:
>
> On Wed, Jan 23, 2019 at 5:27 PM Andre McCurdy  wrote:
> >
> > On Wed, Jan 23, 2019 at 12:05 PM Khem Raj  wrote:
> > >
> > > tune files which inherit the arch definitions already define appropriate
> > > -mcpu option, which is equivalent of right -march and -mtune combination
> >
> > And what about machines which inherit an arch definition instead of a
> > cpu definition? Is that no longer supported?
>
> I could not find such a machine configuration in several BSP layers I looked 
> at.
> Do you know of machine definitions where these files are included
> directly in machine configs ?

Using a CPU specific include but then leaving the generic DEFAULTTUNE
(ie not enabling any CPU specific TUNE_CCARGS) is equivalent, and I
guess quite common.

> if so, then we have to either use _remove or introduce a weak variable
> to set march only if
> mcpu is not set which

I think the solution is to ensure that the CPU specific tuning options
are always compatible with any architecture specific options which may
be active.

In general our CPU specific tuning files are a little sloppy (e.g.
defaulting to combinations of VFP versions and architecture levels
which never exist in the real world). If newer versions of gcc are
making those issues more apparent then why not take the opportunity to
fix them properly?

> > > and is preferred since gcc is getting stricter and stricter with option
> > > check semantics and can now find incompatible -march and -mcpu options
> > > better with every release. It does internal feature consistency check
> > > and if it finds out discrepency between what -mcpu would expand to as
> > > compared to -march it will flag the options to be incompatible, for
> > > naked eye it sounds wrong but gcc would translate -mcpu to a given
> > > -march internally and it might not match to what we set in these arch
> > > files.
> > >
> > > The effects are quite subtle, where this can result in configure test
> > > failing to compile due to these incompatible options and a feature
> > > option getting disabled for a recipe for no reason.
> > >
> > > e.g. with gcc9 which can now detect that -mcpu=cortex-a5 and
> > > -march=armv7-a are incompatible, many features in libstdc++ ends up
> > > disabled due to configure check failures e.g. size_t size, ptrdiff_t
> > > sizes, which inturn results in compiling libstdc++ with unwanted
> > > disabled features.
> >
> > It would be interesting to see more specific details of this.
>
> These are configure tests which fail when -Werror is in use and is not
> limited to libstdc++
> it can happen in any package. Since the diagnostic about incompatible
> march mcpu pair
> is a warning in general, it does not matter, but when we have -Werror
> enabled this turns
> into error, You can simply try a small helloworld example to see the effects.
>
> >
> > > Signed-off-by: Khem Raj 
> > > ---
> > >  meta/conf/machine/include/arm/arch-armv4.inc   | 1 -
> > >  meta/conf/machine/include/arm/arch-armv5.inc   | 1 -
> > >  meta/conf/machine/include/arm/arch-armv6.inc   | 1 -
> > >  meta/conf/machine/include/arm/arch-armv7a.inc  | 1 -
> > >  meta/conf/machine/include/arm/arch-armv7ve.inc | 1 -
> > >  meta/conf/machine/include/tune-iwmmxt.inc  | 2 +-
> > >  6 files changed, 1 insertion(+), 6 deletions(-)
> > >
> > > diff --git a/meta/conf/machine/include/arm/arch-armv4.inc 
> > > b/meta/conf/machine/include/arm/arch-armv4.inc
> > > index 47a7ad2830..52d8ab1e8f 100644
> > > --- a/meta/conf/machine/include/arm/arch-armv4.inc
> > > +++ b/meta/conf/machine/include/arm/arch-armv4.inc
> > > @@ -2,7 +2,6 @@ DEFAULTTUNE ?= "armv4"
> > >
> > >  TUNEVALID[arm] = "Enable ARM instruction set"
> > >  TUNEVALID[armv4] = "Enable instructions for ARMv4"
> > > -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'armv4', ' 
> > > -march=armv4t', '', d)}"
> > >  # enable --fix-v4bx when we have armv4 in TUNE_FEATURES, but then 
> > > disable it when we have also armv5 or thumb
> > >  # maybe we should extend bb.utils.contains to support check for any 
> > > checkvalues in value, now it does
> > >  # checkvalues.issubset(val) which cannot be used for negative test of 
> > > foo neither bar in value
> > > diff --git a/meta/conf/machine/include/arm/arch-armv5.inc 
> > > b/meta/conf/machine/include/arm/arch-armv5.inc
> > > index f9068af9de..1fe1b6b8e4 100644
> > > --- a/meta/conf/machine/include/arm/arch-armv5.inc
> > > +++ b/meta/conf/machine/include/arm/arch-armv5.inc
> > > @@ -2,7 +2,6 @@ DEFAULTTUNE ?= "armv5"
> > >
> > >  TUNEVALID[armv5] = "Enable instructions for ARMv5"
> > >  TUNECONFLICTS[armv5] = "armv4"
> > > -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'armv5', ' 
> > > -march=armv5t${ARMPKGSFX_DSP}', '', d)}"
> > >  MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'armv5', 
> > > 'armv5:', '' ,d)}"
> > >
> > >  require conf/machine/include/arm/arch-armv4.inc
> > > diff --git a/meta/conf/machine/include/arm/arch-armv6.in

Re: [OE-core] [PATCH] arch-arm: Do not add -march options for arm architecture

2019-01-23 Thread Khem Raj

On Wed, Jan 23, 2019 at 5:27 PM Andre McCurdy  wrote:
>
> On Wed, Jan 23, 2019 at 12:05 PM Khem Raj  wrote:
> >
> > tune files which inherit the arch definitions already define appropriate
> > -mcpu option, which is equivalent of right -march and -mtune combination
>
> And what about machines which inherit an arch definition instead of a
> cpu definition? Is that no longer supported?

I could not find such a machine configuration in several BSP layers I looked at.
Do you know of machine definitions where these files are included
directly in machine configs ?
if so, then we have to either use _remove or introduce a weak variable
to set march only if
mcpu is not set which

>
> > and is preferred since gcc is getting stricter and stricter with option
> > check semantics and can now find incompatible -march and -mcpu options
> > better with every release. It does internal feature consistency check
> > and if it finds out discrepency between what -mcpu would expand to as
> > compared to -march it will flag the options to be incompatible, for
> > naked eye it sounds wrong but gcc would translate -mcpu to a given
> > -march internally and it might not match to what we set in these arch
> > files.
> >
> > The effects are quite subtle, where this can result in configure test
> > failing to compile due to these incompatible options and a feature
> > option getting disabled for a recipe for no reason.
> >
> > e.g. with gcc9 which can now detect that -mcpu=cortex-a5 and
> > -march=armv7-a are incompatible, many features in libstdc++ ends up
> > disabled due to configure check failures e.g. size_t size, ptrdiff_t
> > sizes, which inturn results in compiling libstdc++ with unwanted
> > disabled features.
>
> It would be interesting to see more specific details of this.

These are configure tests which fail when -Werror is in use and is not
limited to libstdc++
it can happen in any package. Since the diagnostic about incompatible
march mcpu pair
is a warning in general, it does not matter, but when we have -Werror
enabled this turns
into error, You can simply try a small helloworld example to see the effects.

>
> > Signed-off-by: Khem Raj 
> > ---
> >  meta/conf/machine/include/arm/arch-armv4.inc   | 1 -
> >  meta/conf/machine/include/arm/arch-armv5.inc   | 1 -
> >  meta/conf/machine/include/arm/arch-armv6.inc   | 1 -
> >  meta/conf/machine/include/arm/arch-armv7a.inc  | 1 -
> >  meta/conf/machine/include/arm/arch-armv7ve.inc | 1 -
> >  meta/conf/machine/include/tune-iwmmxt.inc  | 2 +-
> >  6 files changed, 1 insertion(+), 6 deletions(-)
> >
> > diff --git a/meta/conf/machine/include/arm/arch-armv4.inc 
> > b/meta/conf/machine/include/arm/arch-armv4.inc
> > index 47a7ad2830..52d8ab1e8f 100644
> > --- a/meta/conf/machine/include/arm/arch-armv4.inc
> > +++ b/meta/conf/machine/include/arm/arch-armv4.inc
> > @@ -2,7 +2,6 @@ DEFAULTTUNE ?= "armv4"
> >
> >  TUNEVALID[arm] = "Enable ARM instruction set"
> >  TUNEVALID[armv4] = "Enable instructions for ARMv4"
> > -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'armv4', ' 
> > -march=armv4t', '', d)}"
> >  # enable --fix-v4bx when we have armv4 in TUNE_FEATURES, but then disable 
> > it when we have also armv5 or thumb
> >  # maybe we should extend bb.utils.contains to support check for any 
> > checkvalues in value, now it does
> >  # checkvalues.issubset(val) which cannot be used for negative test of foo 
> > neither bar in value
> > diff --git a/meta/conf/machine/include/arm/arch-armv5.inc 
> > b/meta/conf/machine/include/arm/arch-armv5.inc
> > index f9068af9de..1fe1b6b8e4 100644
> > --- a/meta/conf/machine/include/arm/arch-armv5.inc
> > +++ b/meta/conf/machine/include/arm/arch-armv5.inc
> > @@ -2,7 +2,6 @@ DEFAULTTUNE ?= "armv5"
> >
> >  TUNEVALID[armv5] = "Enable instructions for ARMv5"
> >  TUNECONFLICTS[armv5] = "armv4"
> > -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'armv5', ' 
> > -march=armv5t${ARMPKGSFX_DSP}', '', d)}"
> >  MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'armv5', 
> > 'armv5:', '' ,d)}"
> >
> >  require conf/machine/include/arm/arch-armv4.inc
> > diff --git a/meta/conf/machine/include/arm/arch-armv6.inc 
> > b/meta/conf/machine/include/arm/arch-armv6.inc
> > index 6c838e999c..adb9be8050 100644
> > --- a/meta/conf/machine/include/arm/arch-armv6.inc
> > +++ b/meta/conf/machine/include/arm/arch-armv6.inc
> > @@ -2,7 +2,6 @@ DEFAULTTUNE ?= "armv6hf"
> >
> >  TUNEVALID[armv6] = "Enable instructions for ARMv6"
> >  TUNECONFLICTS[armv6] = "armv4 armv5"
> > -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'armv6', ' 
> > -march=armv6', '', d)}"
> >  MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'armv6', 
> > 'armv6:', '' ,d)}"
> >
> >  require conf/machine/include/arm/arch-armv5-dsp.inc
> > diff --git a/meta/conf/machine/include/arm/arch-armv7a.inc 
> > b/meta/conf/machine/include/arm/arch-armv7a.inc
> > index a2663d8008..09d2c03a5d 100644
> > --- a/meta/conf/machine/include/arm/arch-armv7a.inc
> > +++ b/met

Re: [OE-core] [PATCH] arch-arm: Do not add -march options for arm architecture

2019-01-23 Thread Andre McCurdy

On Wed, Jan 23, 2019 at 12:05 PM Khem Raj  wrote:
>
> tune files which inherit the arch definitions already define appropriate
> -mcpu option, which is equivalent of right -march and -mtune combination

And what about machines which inherit an arch definition instead of a
cpu definition? Is that no longer supported?

> and is preferred since gcc is getting stricter and stricter with option
> check semantics and can now find incompatible -march and -mcpu options
> better with every release. It does internal feature consistency check
> and if it finds out discrepency between what -mcpu would expand to as
> compared to -march it will flag the options to be incompatible, for
> naked eye it sounds wrong but gcc would translate -mcpu to a given
> -march internally and it might not match to what we set in these arch
> files.
>
> The effects are quite subtle, where this can result in configure test
> failing to compile due to these incompatible options and a feature
> option getting disabled for a recipe for no reason.
>
> e.g. with gcc9 which can now detect that -mcpu=cortex-a5 and
> -march=armv7-a are incompatible, many features in libstdc++ ends up
> disabled due to configure check failures e.g. size_t size, ptrdiff_t
> sizes, which inturn results in compiling libstdc++ with unwanted
> disabled features.

It would be interesting to see more specific details of this.

> Signed-off-by: Khem Raj 
> ---
>  meta/conf/machine/include/arm/arch-armv4.inc   | 1 -
>  meta/conf/machine/include/arm/arch-armv5.inc   | 1 -
>  meta/conf/machine/include/arm/arch-armv6.inc   | 1 -
>  meta/conf/machine/include/arm/arch-armv7a.inc  | 1 -
>  meta/conf/machine/include/arm/arch-armv7ve.inc | 1 -
>  meta/conf/machine/include/tune-iwmmxt.inc  | 2 +-
>  6 files changed, 1 insertion(+), 6 deletions(-)
>
> diff --git a/meta/conf/machine/include/arm/arch-armv4.inc 
> b/meta/conf/machine/include/arm/arch-armv4.inc
> index 47a7ad2830..52d8ab1e8f 100644
> --- a/meta/conf/machine/include/arm/arch-armv4.inc
> +++ b/meta/conf/machine/include/arm/arch-armv4.inc
> @@ -2,7 +2,6 @@ DEFAULTTUNE ?= "armv4"
>
>  TUNEVALID[arm] = "Enable ARM instruction set"
>  TUNEVALID[armv4] = "Enable instructions for ARMv4"
> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'armv4', ' 
> -march=armv4t', '', d)}"
>  # enable --fix-v4bx when we have armv4 in TUNE_FEATURES, but then disable it 
> when we have also armv5 or thumb
>  # maybe we should extend bb.utils.contains to support check for any 
> checkvalues in value, now it does
>  # checkvalues.issubset(val) which cannot be used for negative test of foo 
> neither bar in value
> diff --git a/meta/conf/machine/include/arm/arch-armv5.inc 
> b/meta/conf/machine/include/arm/arch-armv5.inc
> index f9068af9de..1fe1b6b8e4 100644
> --- a/meta/conf/machine/include/arm/arch-armv5.inc
> +++ b/meta/conf/machine/include/arm/arch-armv5.inc
> @@ -2,7 +2,6 @@ DEFAULTTUNE ?= "armv5"
>
>  TUNEVALID[armv5] = "Enable instructions for ARMv5"
>  TUNECONFLICTS[armv5] = "armv4"
> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'armv5', ' 
> -march=armv5t${ARMPKGSFX_DSP}', '', d)}"
>  MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'armv5', 
> 'armv5:', '' ,d)}"
>
>  require conf/machine/include/arm/arch-armv4.inc
> diff --git a/meta/conf/machine/include/arm/arch-armv6.inc 
> b/meta/conf/machine/include/arm/arch-armv6.inc
> index 6c838e999c..adb9be8050 100644
> --- a/meta/conf/machine/include/arm/arch-armv6.inc
> +++ b/meta/conf/machine/include/arm/arch-armv6.inc
> @@ -2,7 +2,6 @@ DEFAULTTUNE ?= "armv6hf"
>
>  TUNEVALID[armv6] = "Enable instructions for ARMv6"
>  TUNECONFLICTS[armv6] = "armv4 armv5"
> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'armv6', ' 
> -march=armv6', '', d)}"
>  MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'armv6', 
> 'armv6:', '' ,d)}"
>
>  require conf/machine/include/arm/arch-armv5-dsp.inc
> diff --git a/meta/conf/machine/include/arm/arch-armv7a.inc 
> b/meta/conf/machine/include/arm/arch-armv7a.inc
> index a2663d8008..09d2c03a5d 100644
> --- a/meta/conf/machine/include/arm/arch-armv7a.inc
> +++ b/meta/conf/machine/include/arm/arch-armv7a.inc
> @@ -3,7 +3,6 @@ ARM_INSTRUCTION_SET ?= "thumb"
>
>  TUNEVALID[armv7a] = "Enable instructions for ARMv7-a"
>  TUNECONFLICTS[armv7a] = "armv4 armv5 armv6 armv7"
> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'armv7a', ' 
> -march=armv7-a', '', d)}"
>  MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'armv7a', 
> 'armv7a:', '' ,d)}"
>
>  require conf/machine/include/arm/arch-armv6.inc
> diff --git a/meta/conf/machine/include/arm/arch-armv7ve.inc 
> b/meta/conf/machine/include/arm/arch-armv7ve.inc
> index 4d9260fecb..31e334f645 100644
> --- a/meta/conf/machine/include/arm/arch-armv7ve.inc
> +++ b/meta/conf/machine/include/arm/arch-armv7ve.inc
> @@ -2,7 +2,6 @@ DEFAULTTUNE ?= "armv7vethf"
>
>  TUNEVALID[armv7ve] = "Enable instructions for ARMv7ve"
>  TUNECONFLICTS[armv7ve] = "armv4 armv5 armv6 armv7 arm

[OE-core] [PATCH] arch-arm: Do not add -march options for arm architecture

2019-01-23 Thread Khem Raj

tune files which inherit the arch definitions already define appropriate
-mcpu option, which is equivalent of right -march and -mtune combination
and is preferred since gcc is getting stricter and stricter with option
check semantics and can now find incompatible -march and -mcpu options
better with every release. It does internal feature consistency check
and if it finds out discrepency between what -mcpu would expand to as
compared to -march it will flag the options to be incompatible, for
naked eye it sounds wrong but gcc would translate -mcpu to a given
-march internally and it might not match to what we set in these arch
files.

The effects are quite subtle, where this can result in configure test
failing to compile due to these incompatible options and a feature
option getting disabled for a recipe for no reason.

e.g. with gcc9 which can now detect that -mcpu=cortex-a5 and
-march=armv7-a are incompatible, many features in libstdc++ ends up
disabled due to configure check failures e.g. size_t size, ptrdiff_t
sizes, which inturn results in compiling libstdc++ with unwanted
disabled features.

Signed-off-by: Khem Raj 
---
 meta/conf/machine/include/arm/arch-armv4.inc   | 1 -
 meta/conf/machine/include/arm/arch-armv5.inc   | 1 -
 meta/conf/machine/include/arm/arch-armv6.inc   | 1 -
 meta/conf/machine/include/arm/arch-armv7a.inc  | 1 -
 meta/conf/machine/include/arm/arch-armv7ve.inc | 1 -
 meta/conf/machine/include/tune-iwmmxt.inc  | 2 +-
 6 files changed, 1 insertion(+), 6 deletions(-)

diff --git a/meta/conf/machine/include/arm/arch-armv4.inc 
b/meta/conf/machine/include/arm/arch-armv4.inc
index 47a7ad2830..52d8ab1e8f 100644
--- a/meta/conf/machine/include/arm/arch-armv4.inc
+++ b/meta/conf/machine/include/arm/arch-armv4.inc
@@ -2,7 +2,6 @@ DEFAULTTUNE ?= "armv4"
 
 TUNEVALID[arm] = "Enable ARM instruction set"
 TUNEVALID[armv4] = "Enable instructions for ARMv4"
-TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'armv4', ' 
-march=armv4t', '', d)}"
 # enable --fix-v4bx when we have armv4 in TUNE_FEATURES, but then disable it 
when we have also armv5 or thumb
 # maybe we should extend bb.utils.contains to support check for any 
checkvalues in value, now it does 
 # checkvalues.issubset(val) which cannot be used for negative test of foo 
neither bar in value
diff --git a/meta/conf/machine/include/arm/arch-armv5.inc 
b/meta/conf/machine/include/arm/arch-armv5.inc
index f9068af9de..1fe1b6b8e4 100644
--- a/meta/conf/machine/include/arm/arch-armv5.inc
+++ b/meta/conf/machine/include/arm/arch-armv5.inc
@@ -2,7 +2,6 @@ DEFAULTTUNE ?= "armv5"
 
 TUNEVALID[armv5] = "Enable instructions for ARMv5"
 TUNECONFLICTS[armv5] = "armv4"
-TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'armv5', ' 
-march=armv5t${ARMPKGSFX_DSP}', '', d)}"
 MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'armv5', 'armv5:', 
'' ,d)}"
 
 require conf/machine/include/arm/arch-armv4.inc
diff --git a/meta/conf/machine/include/arm/arch-armv6.inc 
b/meta/conf/machine/include/arm/arch-armv6.inc
index 6c838e999c..adb9be8050 100644
--- a/meta/conf/machine/include/arm/arch-armv6.inc
+++ b/meta/conf/machine/include/arm/arch-armv6.inc
@@ -2,7 +2,6 @@ DEFAULTTUNE ?= "armv6hf"
 
 TUNEVALID[armv6] = "Enable instructions for ARMv6"
 TUNECONFLICTS[armv6] = "armv4 armv5"
-TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'armv6', ' 
-march=armv6', '', d)}"
 MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'armv6', 'armv6:', 
'' ,d)}"
 
 require conf/machine/include/arm/arch-armv5-dsp.inc
diff --git a/meta/conf/machine/include/arm/arch-armv7a.inc 
b/meta/conf/machine/include/arm/arch-armv7a.inc
index a2663d8008..09d2c03a5d 100644
--- a/meta/conf/machine/include/arm/arch-armv7a.inc
+++ b/meta/conf/machine/include/arm/arch-armv7a.inc
@@ -3,7 +3,6 @@ ARM_INSTRUCTION_SET ?= "thumb"
 
 TUNEVALID[armv7a] = "Enable instructions for ARMv7-a"
 TUNECONFLICTS[armv7a] = "armv4 armv5 armv6 armv7"
-TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'armv7a', ' 
-march=armv7-a', '', d)}"
 MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'armv7a', 
'armv7a:', '' ,d)}"
 
 require conf/machine/include/arm/arch-armv6.inc
diff --git a/meta/conf/machine/include/arm/arch-armv7ve.inc 
b/meta/conf/machine/include/arm/arch-armv7ve.inc
index 4d9260fecb..31e334f645 100644
--- a/meta/conf/machine/include/arm/arch-armv7ve.inc
+++ b/meta/conf/machine/include/arm/arch-armv7ve.inc
@@ -2,7 +2,6 @@ DEFAULTTUNE ?= "armv7vethf"
 
 TUNEVALID[armv7ve] = "Enable instructions for ARMv7ve"
 TUNECONFLICTS[armv7ve] = "armv4 armv5 armv6 armv7 armv7a"
-TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'armv7ve', ' 
-march=armv7ve', '', d)}"
 MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'armv7ve', 
'armv7ve:', '' ,d)}"
 
 require conf/machine/include/arm/arch-armv7a.inc
diff --git a/meta/conf/machine/include/tune-iwmmxt.inc 
b/meta/conf/machine/include/tune-iwmmxt.inc
index f27423cb2e..6e577697cc 100644
--- a/meta/conf/machine/include/t

[OE-core] [PATCH] linux-yocto/4.19: riscv: enable serial

2019-01-23 Thread Bruce Ashfield

Integrating the following configuration change for riscv serial:

  Author: Alistair Francis 
  Date:   Tue Jan 22 18:55:04 2019 +

qemuriscv64: Enable the 8250 serial driver

Signed-off-by: Alistair Francis 

Signed-off-by: Bruce Ashfield 
---
 meta/recipes-kernel/linux/linux-yocto-rt_4.19.bb   | 2 +-
 meta/recipes-kernel/linux/linux-yocto-tiny_4.19.bb | 2 +-
 meta/recipes-kernel/linux/linux-yocto_4.19.bb  | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_4.19.bb 
b/meta/recipes-kernel/linux/linux-yocto-rt_4.19.bb
index bfce9aa76935..9784607cd67a 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_4.19.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_4.19.bb
@@ -12,7 +12,7 @@ python () {
 }
 
 SRCREV_machine ?= "7a0b04e5a8d036cd9dcc6ee64a838e8d8d5cdd56"
-SRCREV_meta ?= "7223248023d3d822c8c0227fb65d995ba6b7a351"
+SRCREV_meta ?= "70d33ded25747f73381baff8d8758e86967e4ee2"
 
 SRC_URI = 
"git://git.yoctoproject.org/linux-yocto.git;branch=${KBRANCH};name=machine \

git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.19;destsuffix=${KMETA}"
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_4.19.bb 
b/meta/recipes-kernel/linux/linux-yocto-tiny_4.19.bb
index c734ad840708..f8d60c76c387 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_4.19.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_4.19.bb
@@ -17,7 +17,7 @@ KCONF_BSP_AUDIT_LEVEL = "2"
 
 SRCREV_machine_qemuarm ?= "d11db6c6617f689e6b9e2afaa3d3b2036c6d3d30"
 SRCREV_machine ?= "eebb51300a07804a020ec468b5f8c5bf720198d9"
-SRCREV_meta ?= "7223248023d3d822c8c0227fb65d995ba6b7a351"
+SRCREV_meta ?= "70d33ded25747f73381baff8d8758e86967e4ee2"
 
 PV = "${LINUX_VERSION}+git${SRCPV}"
 
diff --git a/meta/recipes-kernel/linux/linux-yocto_4.19.bb 
b/meta/recipes-kernel/linux/linux-yocto_4.19.bb
index 187437016f23..af0dc9f50c73 100644
--- a/meta/recipes-kernel/linux/linux-yocto_4.19.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_4.19.bb
@@ -19,7 +19,7 @@ SRCREV_machine_qemux86 ?= 
"eebb51300a07804a020ec468b5f8c5bf720198d9"
 SRCREV_machine_qemux86-64 ?= "eebb51300a07804a020ec468b5f8c5bf720198d9"
 SRCREV_machine_qemumips64 ?= "dff23f01307cbab688d9677ecd4b5f350ec435d9"
 SRCREV_machine ?= "eebb51300a07804a020ec468b5f8c5bf720198d9"
-SRCREV_meta ?= "7223248023d3d822c8c0227fb65d995ba6b7a351"
+SRCREV_meta ?= "70d33ded25747f73381baff8d8758e86967e4ee2"
 
 SRC_URI = 
"git://git.yoctoproject.org/linux-yocto.git;name=machine;branch=${KBRANCH}; \

git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.19;destsuffix=${KMETA}"
-- 
2.5.0

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

Re: [OE-core] [PATCHv2] glibc: Separate out AArch64 multilib loader symlink creation

2019-01-23 Thread Mike Crowe

On Friday 11 January 2019 at 16:59:44 +, Mike Crowe wrote:
> On Friday 11 January 2019 at 16:53:47 +, Richard Purdie wrote:
> > On Fri, 2019-01-11 at 16:49 +, Mike Crowe wrote:
> > > Until now, glibc was responsible for creating an AArch64 dynamic
> > > loader symlink if required for ABI compatibility.
> > > 
> > > Unfortunately, using multilib with AArch64 caused the rmdir in
> > > glibc-package.inc:do_poststash_install_cleanup to fail because that
> > > task did not expect to find the dynamic loader symlink in /lib.
> > > 
> > > Also, although glibc-package.inc:do_install_append_aarch64 made use
> > > of ${nonarch_base_libdir} to create the dynamic loader symlink in a
> > > way that was compatible with usrmerge, it unfortunately explicitly
> > > added only /lib to libc_baselibs, so the symlink was not packaged
> > > correctly when using usrmerge.
> > > 
> > > Attempting to fix both of these problems within glibc-package.inc in
> > > various ways created a bit of a mess. It seemed much simpler to
> > > invent a new package for the symlink and have glibc RDEPEND on that
> > > package if required.
> > > 
> > > Richard Purdie suggested[1] that ${nonarch_base_libdir} should not be
> > > used in this way. I've switched to using ${root_prefix}/lib which
> > > continues to work both with and without usrmerge.
> > > 
> > > Unfortunately, it appears not to be possible to specify the name of
> > > the loader via a variable with an override, since the _aarch64
> > > override is applied even for _aarch64-be.
> > 
> > I wish there was a simpler way to do this. How ugly is the patch to fix
> > this without adding the new recipe? Adding new recipes which are arch
> > specific like this is a pain for world builds and I think this patch
> > will have problems with those :(.
> 
> This is how far I got before deciding that it was too ugly. This patch
> needs some cleaning up, and similar hackery to the separate-recipe patch
> because the aarch64-be override doesn't work. :(
> 
> I tried to make both patches at least slightly generic in case some other
> architecture needs something similar in the future. That's why the code has
> moved into a plain do_install_append. This isn't required though, and
> perhaps it would be clearer if the variable were actually
> AARCH64_DYNAMIC_LOADER anyway.
> 
> Thanks.
> 
> Mike.
> 
> diff --git a/meta/recipes-core/glibc/glibc-package.inc 
> b/meta/recipes-core/glibc/glibc-package.inc
> index a98ae1a29c..0181aa7b32 100644
> --- a/meta/recipes-core/glibc/glibc-package.inc
> +++ b/meta/recipes-core/glibc/glibc-package.inc
> @@ -15,7 +15,13 @@ RPROVIDES_glibc-thread-db = "eglibc-thread-db"
>  RPROVIDES_${PN}-pcprofile = "eglibc-pcprofile"
>  RPROVIDES_${PN}-dbg = "eglibc-dbg"
>  libc_baselibs = "${base_libdir}/libc.so.* ${base_libdir}/libc-*.so 
> ${base_libdir}/libm*.so.* ${base_libdir}/libm-*.so 
> ${base_libdir}/libmvec-*.so ${base_libdir}/ld*.so.* ${base_libdir}/ld-*.so 
> ${base_libdir}/libpthread*.so.* ${base_libdir}/libpthread-*.so 
> ${base_libdir}/libresolv*.so.* ${base_libdir}/libresolv-*.so 
> ${base_libdir}/librt*.so.* ${base_libdir}/librt-*.so 
> ${base_libdir}/libutil*.so.* ${base_libdir}/libutil-*.so 
> ${base_libdir}/libnsl*.so.* ${base_libdir}/libnsl-*.so 
> ${base_libdir}/libnss_files*.so.* ${base_libdir}/libnss_files-*.so 
> ${base_libdir}/libnss_compat*.so.* ${base_libdir}/libnss_compat-*.so 
> ${base_libdir}/libnss_dns*.so.* ${base_libdir}/libnss_dns-*.so 
> ${base_libdir}/libdl*.so.* ${base_libdir}/libdl-*.so 
> ${base_libdir}/libanl*.so.* ${base_libdir}/libanl-*.so 
> ${base_libdir}/libBrokenLocale*.so.* ${base_libdir}/libBrokenLocale-*.so"
> -libc_baselibs_append_aarch64 = " /lib/ld-linux-aarch64*.so.1"
> +ARCH_DYNAMIC_LOADER = ""
> +# The aarch64 ABI says the dynamic linker -must- be
> +# /lib/ld-linux-aarch64[_be].so.1. With usrmerge, that may mean that
> +# we need to install it in /usr/lib.
> +ARCH_DYNAMIC_LOADER_aarch64 = "ld-linux-aarch64.so.1"
> +ARCH_DYNAMIC_LOADER_aarch64_be = "ld-linux-aarch64_be.so.1"
> +libc_baselibs_append = " ${@oe.utils.conditional('ARCH_DYNAMIC_LOADER', '', 
> '', '${root_prefix}/lib/${ARCH_DYNAMIC_LOADER}', d)}"
>  INSANE_SKIP_${PN}_append_aarch64 = " libdir"
> 
>  FILES_${PN} = "${libc_baselibs} ${libexecdir}/* ${base_sbindir}/ldconfig 
> ${sysconfdir}/ld.so.conf"
> @@ -112,20 +118,20 @@ do_install_append () {
>   echo "d root root 0755 /var/run/nscd none" \
>   > ${D}${sysconfdir}/default/volatiles/98_nscd
>   fi
> +
> + # The dynamic loader will have been installed into
> + # ${base_libdir}. However, if that isn't going to end up being
> + # available in the ABI-mandated location, then a symlink must
> +# be created.
> +
> + if [ -n "${ARCH_DYNAMIC_LOADER}" -a ! -e 
> "${D}${root_prefix}/lib/${ARCH_DYNAMIC_LOADER}" ]; then
> + install -d ${D}${root_prefix}/lib
> + ln -s ${@oe.path.relative('${root_prefix}/lib', 
> '${base_libdir}')}/${ARCH

[OE-core] [PATCH 10/10] devtool: add a command to print an overall list of recipes that can be updated

2019-01-23 Thread Alexander Kanavin

A sample portion of the output:

$ devtool check-upgrade-status
...
NOTE: acpid 2.0.30  2.0.31  Ross Burton 

NOTE: u-boot-fw-utils   2018.11 2019.01 Marek Vasut 
 d3689267f92c5956e09cc7d1baa4700141662bff
NOTE: u-boot-tools  2018.11 2019.01 Marek Vasut 
 d3689267f92c5956e09cc7d1baa4700141662bff
NOTE: u-boot2018.11 2019.01 Marek Vasut 
 d3689267f92c5956e09cc7d1baa4700141662bff
NOTE: bind  9.11.5  9.13.5  Armin Kuster 
  cannot be updated due to: 9.11 is LTS 2021
NOTE: iproute2  4.19.0  4.20.0  Changhyeok Bae 

NOTE: ofono 1.251.27Ross Burton 

NOTE: wpa-supplicant2.6 2.7 Changhyeok Bae 

NOTE: base-passwd   3.5.29  3.5.45  Anuj Mittal 
  cannot be updated due to: Version 3.5.38 requires 
cdebconf for update-passwd utility
NOTE: busybox   1.29.2  1.30.0  Andrej Valek 

NOTE: dbus-test 1.12.10 1.12.12 Chen Qi 

NOTE: dbus  1.12.10 1.12.12 Chen Qi 

NOTE: glib-2.0  2.58.0  2.58.3  Anuj Mittal 

NOTE: glib-networking   2.54.1  2.58.0  Anuj Mittal 

...

Signed-off-by: Alexander Kanavin 
---
 scripts/lib/devtool/upgrade.py | 20 
 1 file changed, 20 insertions(+)

diff --git a/scripts/lib/devtool/upgrade.py b/scripts/lib/devtool/upgrade.py
index 202007793b2..42a4c0e4bff 100644
--- a/scripts/lib/devtool/upgrade.py
+++ b/scripts/lib/devtool/upgrade.py
@@ -600,6 +600,20 @@ def latest_version(args, config, basepath, workspace):
 tinfoil.shutdown()
 return 0
 
+def check_upgrade_status(args, config, basepath, workspace):
+if not args.recipe:
+logger.info("Checking the upstream status for all recipes may take a 
few minutes")
+results = oe.recipeutils.get_recipe_upgrade_status(args.recipe)
+for result in results:
+# pn, update_status, current, latest, maintainer, latest_commit, 
no_update_reason
+if result[1] != 'MATCH':
+logger.info("{:25} {:15} {:15} {} {} {}".format(   result[0],
+   result[2],
+   result[1] if 
result[1] != 'UPDATE' else (result[3] if not 
result[3].endswith("new-commits-available") else "new commits"),
+   result[4],
+   result[5] if 
result[5] != 'N/A' else "",
+   "cannot be 
updated due to: %s" %(result[6]) if result[6] else ""))
+
 def register_commands(subparsers, context):
 """Register devtool subcommands from this plugin"""
 
@@ -627,3 +641,9 @@ def register_commands(subparsers, context):
   group='info')
 parser_latest_version.add_argument('recipename', help='Name of recipe to 
query (just name - no version, path or extension)')
 parser_latest_version.set_defaults(func=latest_version)
+
+parser_check_upgrade_status = 
subparsers.add_parser('check-upgrade-status', help="Report upgradability for 
multiple (or all) recipes",
+description="Prints a 
table of recipes together with versions currently provided by recipes, and 
latest upstream versions, when there is a later version available",
+group='info')
+parser_check_upgrade_status.add_argument('recipe', help='Name of the 
recipe to report (omit to report upgrade info for all recipes)', nargs='*')
+parser_check_upgrade_status.set_defaults(func=check_upgrade_status)
-- 
2.17.1

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

[OE-core] [PATCH 09/10] lib/oe/reciputils.py: parallelize upstream version checks

2019-01-23 Thread Alexander Kanavin

Previously this was done via bitbake tasks, and when this
was rewritten to a for loop, performance sufered significantly:
from 90 seconds to about 12 minutes for oe-core. This change
restores the previous run time, and makes it possible
to perform such checks with command line utilities in an
interactive way.

Implementation note: we have to create a copy of the recipe
data, as Tinfoil API can't be used from multiple threads
and only allows one process to access the data at a time.

Signed-off-by: Alexander Kanavin 
---
 meta/lib/oe/recipeutils.py | 77 +++---
 1 file changed, 56 insertions(+), 21 deletions(-)

diff --git a/meta/lib/oe/recipeutils.py b/meta/lib/oe/recipeutils.py
index 39d3de4bb1f..92c0f65257f 100644
--- a/meta/lib/oe/recipeutils.py
+++ b/meta/lib/oe/recipeutils.py
@@ -1020,8 +1020,54 @@ def get_recipe_upstream_version(rd):
 
 return ru
 
+def _get_recipe_upgrade_status(data):
+uv = get_recipe_upstream_version(data)
+
+pn = data.getVar('PN')
+cur_ver = uv['current_version']
+
+upstream_version_unknown = data.getVar('UPSTREAM_VERSION_UNKNOWN')
+if not uv['version']:
+status = "UNKNOWN" if upstream_version_unknown else "UNKNOWN_BROKEN"
+else:
+cmp = vercmp_string(uv['current_version'], uv['version'])
+if cmp == -1:
+status = "UPDATE" if not upstream_version_unknown else 
"KNOWN_BROKEN"
+elif cmp == 0:
+status = "MATCH" if not upstream_version_unknown else 
"KNOWN_BROKEN"
+else:
+status = "UNKNOWN" if upstream_version_unknown else 
"UNKNOWN_BROKEN"
+
+next_ver = uv['version'] if uv['version'] else "N/A"
+revision = uv['revision'] if uv['revision'] else "N/A"
+maintainer = data.getVar('RECIPE_MAINTAINER')
+no_upgrade_reason = data.getVar('RECIPE_NO_UPDATE_REASON')
+
+return (pn, status, cur_ver, next_ver, maintainer, revision, 
no_upgrade_reason)
+
 def get_recipe_upgrade_status(recipes=None):
 pkgs_list = []
+data_copy_list = []
+copy_vars = ('SRC_URI',
+ 'PV',
+ 'GITDIR',
+ 'DL_DIR',
+ 'PN',
+ 'CACHE',
+ 'PERSISTENT_DIR',
+ 'BB_URI_HEADREVS',
+ 'UPSTREAM_CHECK_COMMITS',
+ 'UPSTREAM_CHECK_GITTAGREGEX',
+ 'UPSTREAM_CHECK_REGEX',
+ 'UPSTREAM_CHECK_URI',
+ 'UPSTREAM_VERSION_UNKNOWN',
+ 'RECIPE_MAINTAINER',
+ 'RECIPE_NO_UPDATE_REASON',
+ 'RECIPE_UPSTREAM_VERSION',
+ 'RECIPE_UPSTREAM_DATE',
+ 'CHECK_DATE',
+)
+
 with bb.tinfoil.Tinfoil() as tinfoil:
 tinfoil.prepare(config_only=False)
 
@@ -1043,28 +1089,17 @@ def get_recipe_upgrade_status(recipes=None):
 bb.note(" Skip package %s as upstream check unreliable" % pn)
 continue
 
-uv = get_recipe_upstream_version(data)
-
-pn = data.getVar('PN')
-cur_ver = uv['current_version']
-
-upstream_version_unknown = data.getVar('UPSTREAM_VERSION_UNKNOWN')
-if not uv['version']:
-status = "UNKNOWN" if upstream_version_unknown else 
"UNKNOWN_BROKEN"
-else:
-cmp = vercmp_string(uv['current_version'], uv['version'])
-if cmp == -1:
-status = "UPDATE" if not upstream_version_unknown else 
"KNOWN_BROKEN"
-elif cmp == 0:
-status = "MATCH" if not upstream_version_unknown else 
"KNOWN_BROKEN"
-else:
-status = "UNKNOWN" if upstream_version_unknown else 
"UNKNOWN_BROKEN"
+data_copy = bb.data.init()
+for var in copy_vars:
+data_copy.setVar(var, data.getVar(var))
+for k in data:
+if k.startswith('SRCREV'):
+data_copy.setVar(k, data.getVar(k))
 
-next_ver = uv['version'] if uv['version'] else "N/A"
-revision = uv['revision'] if uv['revision'] else "N/A"
-maintainer = data.getVar('RECIPE_MAINTAINER')
-no_upgrade_reason = data.getVar('RECIPE_NO_UPDATE_REASON')
+data_copy_list.append(data_copy)
 
-pkgs_list.append((pn, status, cur_ver, next_ver, maintainer, 
revision, no_upgrade_reason))
+from concurrent.futures import ProcessPoolExecutor
+with ProcessPoolExecutor(max_workers=utils.cpu_count()) as executor:
+pkgs_list = executor.map(_get_recipe_upgrade_status, data_copy_list)
 
 return pkgs_list
-- 
2.17.1

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

[OE-core] [PATCH 07/10] kmscube: update to latest commit, switch over to meson

2019-01-23 Thread Alexander Kanavin

Signed-off-by: Alexander Kanavin 
---
 meta/recipes-graphics/kmscube/kmscube_git.bb | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-graphics/kmscube/kmscube_git.bb 
b/meta/recipes-graphics/kmscube/kmscube_git.bb
index 46aeeb01795..c6cb1842158 100644
--- a/meta/recipes-graphics/kmscube/kmscube_git.bb
+++ b/meta/recipes-graphics/kmscube/kmscube_git.bb
@@ -6,13 +6,13 @@ DEPENDS = "virtual/libgles2 virtual/egl libdrm gstreamer1.0 
gstreamer1.0-plugins
 
 LIC_FILES_CHKSUM = 
"file://kmscube.c;beginline=1;endline=23;md5=8b309d4ee67b7315ff7381270dd631fb"
 
-SRCREV = "9dcce71e603616ee7a54707e932f962cdf8fb20a"
+SRCREV = "d8da3dcfdfe33ee525cf562e928a5266ac69843c"
 SRC_URI = 
"git://anongit.freedesktop.org/mesa/kmscube;branch=master;protocol=git \
 file://detect-gst_bo_map-_unmap-and-use-it-or-avoid-it.patch"
 UPSTREAM_CHECK_COMMITS = "1"
 
 S = "${WORKDIR}/git"
 
-inherit autotools pkgconfig distro_features_check
+inherit meson pkgconfig distro_features_check
 
 REQUIRED_DISTRO_FEATURES = "opengl"
-- 
2.17.1

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

[OE-core] [PATCH 06/10] testimage.bbclass: add support for passing runqemu params

2019-01-23 Thread Alexander Kanavin

This is particularly useful when setting up GL tests.

Signed-off-by: Alexander Kanavin 
---
 meta/classes/testimage.bbclass| 4 +++-
 meta/lib/oeqa/core/target/qemu.py | 4 ++--
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/meta/classes/testimage.bbclass b/meta/classes/testimage.bbclass
index cb8c12accee..ff1c53b93e1 100644
--- a/meta/classes/testimage.bbclass
+++ b/meta/classes/testimage.bbclass
@@ -32,6 +32,7 @@ TESTIMAGE_AUTO ??= "0"
 # Booting is handled by this class, and it's not a test in itself.
 # TEST_QEMUBOOT_TIMEOUT can be used to set the maximum time in seconds the 
launch code will wait for the login prompt.
 # TEST_QEMUPARAMS can be used to pass extra parameters to qemu, e.g. "-m 1024" 
for setting the amount of ram to 1 GB.
+# TEST_RUNQEMUPARAMS can be used to pass extra parameters to runqemu, e.g. 
"gl" to enable OpenGL acceleration.
 
 TEST_LOG_DIR ?= "${WORKDIR}/testimage"
 
@@ -65,6 +66,7 @@ TEST_SUITES ?= "${DEFAULT_TEST_SUITES}"
 TEST_QEMUBOOT_TIMEOUT ?= "1000"
 TEST_TARGET ?= "qemu"
 TEST_QEMUPARAMS ?= ""
+TEST_RUNQEMUPARAMS ?= ""
 
 TESTIMAGEDEPENDS = ""
 TESTIMAGEDEPENDS_append_qemuall = " qemu-native:do_populate_sysroot 
qemu-helper-native:do_populate_sysroot 
qemu-helper-native:do_addto_recipe_sysroot"
@@ -294,7 +296,7 @@ def testimage_main(d):
 try:
 # We need to check if runqemu ends unexpectedly
 # or if the worker send us a SIGTERM
-tc.target.start(params=d.getVar("TEST_QEMUPARAMS"))
+tc.target.start(params=d.getVar("TEST_QEMUPARAMS"), 
runqemuparams=d.getVar("TEST_RUNQEMUPARAMS"))
 results = tc.runTests()
 except (RuntimeError, BlockingIOError) as err:
 if isinstance(err, RuntimeError):
diff --git a/meta/lib/oeqa/core/target/qemu.py 
b/meta/lib/oeqa/core/target/qemu.py
index f47fd7468ed..7a161a32319 100644
--- a/meta/lib/oeqa/core/target/qemu.py
+++ b/meta/lib/oeqa/core/target/qemu.py
@@ -33,11 +33,11 @@ class OEQemuTarget(OESSHTarget):
  use_kvm=kvm, use_slirp=slirp, 
dump_dir=dump_dir,
  dump_host_cmds=dump_host_cmds, logger=logger)
 
-def start(self, params=None, extra_bootparams=None):
+def start(self, params=None, extra_bootparams=None, runqemuparams=''):
 if self.use_slirp and not self.server_ip:
 self.logger.error("Could not start qemu with slirp without server 
ip - provide 'TEST_SERVER_IP'")
 raise RuntimeError("FAILED to start qemu - check the task log and 
the boot log")
-if self.runner.start(params, extra_bootparams=extra_bootparams):
+if self.runner.start(params, extra_bootparams=extra_bootparams, 
runqemuparams=runqemuparams):
 self.ip = self.runner.ip
 if self.use_slirp:
 target_ip_port = self.runner.ip.split(':')
-- 
2.17.1

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

[OE-core] [PATCH 03/10] qemuwrapper-cross: check qemu usermode only when building a target package

2019-01-23 Thread Alexander Kanavin

When building nativesdk- package, MACHINE_FEATURES do not apply as they are
specified only for target machines, not ones hosting the sdk.

Signed-off-by: Alexander Kanavin 
---
 meta/recipes-devtools/qemu/qemuwrapper-cross_1.0.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/qemu/qemuwrapper-cross_1.0.bb 
b/meta/recipes-devtools/qemu/qemuwrapper-cross_1.0.bb
index 06f15617df5..a0448a18039 100644
--- a/meta/recipes-devtools/qemu/qemuwrapper-cross_1.0.bb
+++ b/meta/recipes-devtools/qemu/qemuwrapper-cross_1.0.bb
@@ -20,7 +20,7 @@ do_install () {
 #!/bin/sh
 set -x
 
-if [ ${@bb.utils.contains('MACHINE_FEATURES', 'qemu-usermode', 'True', 
'False', d)} = False ]; then
+if [ ${@bb.utils.contains('MACHINE_FEATURES', 'qemu-usermode', 'True', 
'False', d)} = False -a "${PN}" != "nativesdk-qemuwrapper-cross" ]; then
echo "qemuwrapper: qemu usermode is not supported"
exit 1
 fi
-- 
2.17.1

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

[OE-core] [PATCH 05/10] cmake: do not look into native sysroot in the nativesdk environment

2019-01-23 Thread Alexander Kanavin

I am not sure why we do this in the first place, but it is causing
cmake to erroneously pick up items from the native sysroot
when building for the target and the target item is missing, for example:

https://autobuilder.yoctoproject.org/typhoon/#/builders/59/builds/198/steps/7/logs/step2c

Note that for executable programs this variable is not referred to,
as set by
 set( CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER )
in the same file.

Signed-off-by: Alexander Kanavin 
---
 meta/recipes-devtools/cmake/cmake/OEToolchainConfig.cmake | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/cmake/cmake/OEToolchainConfig.cmake 
b/meta/recipes-devtools/cmake/cmake/OEToolchainConfig.cmake
index 8a0fb4cb12e..398069eef28 100644
--- a/meta/recipes-devtools/cmake/cmake/OEToolchainConfig.cmake
+++ b/meta/recipes-devtools/cmake/cmake/OEToolchainConfig.cmake
@@ -5,7 +5,7 @@ set( CMAKE_ASM_FLAGS ${CMAKE_C_FLAGS} CACHE STRING "" FORCE )
 set( CMAKE_LDFLAGS_FLAGS ${CMAKE_CXX_FLAGS} CACHE STRING "" FORCE )
 set( CMAKE_SYSROOT $ENV{OECORE_TARGET_SYSROOT} )
 
-set( CMAKE_FIND_ROOT_PATH $ENV{OECORE_TARGET_SYSROOT} 
$ENV{OECORE_NATIVE_SYSROOT} )
+set( CMAKE_FIND_ROOT_PATH $ENV{OECORE_TARGET_SYSROOT} )
 set( CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER )
 set( CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY )
 set( CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY )
-- 
2.17.1

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

[OE-core] [PATCH 04/10] lib/oe/package_manager: turn postinst_intercept warnings into failures for nativesdk

2019-01-23 Thread Alexander Kanavin

The few cases where they failed should be now all fixed. The only allowed
exception is when building mingw32 SDKs, as there is currently no support for 
running
postinst_intercepts through wine.

Signed-off-by: Alexander Kanavin 
---
 meta/lib/oe/package_manager.py | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/meta/lib/oe/package_manager.py b/meta/lib/oe/package_manager.py
index 1087144d47f..f26f597d03d 100644
--- a/meta/lib/oe/package_manager.py
+++ b/meta/lib/oe/package_manager.py
@@ -439,6 +439,11 @@ class PackageManager(object, metaclass=ABCMeta):
 self._postpone_to_first_boot(script_full)
 continue
 
+if populate_sdk == 'host' and self.d.getVar('SDK_OS') == 'mingw32':
+bb.warn("The postinstall intercept hook '%s' could not be 
executed due to missing wine support, details in %s/log.do_%s"
+% (script, self.d.getVar('T'), 
self.d.getVar('BB_CURRENTTASK')))
+continue
+
 bb.note("> Executing %s intercept ..." % script)
 
 try:
@@ -447,7 +452,7 @@ class PackageManager(object, metaclass=ABCMeta):
 except subprocess.CalledProcessError as e:
 bb.note("Exit code %d. Output:\n%s" % (e.returncode, 
e.output.decode("utf-8")))
 if populate_sdk == 'host':
-bb.warn("The postinstall intercept hook '%s' failed, 
details in %s/log.do_%s" % (script, self.d.getVar('T'), 
self.d.getVar('BB_CURRENTTASK')))
+bb.fatal("The postinstall intercept hook '%s' failed, 
details in %s/log.do_%s" % (script, self.d.getVar('T'), 
self.d.getVar('BB_CURRENTTASK')))
 elif populate_sdk == 'target':
 if "qemuwrapper: qemu usermode is not supported" in 
e.output.decode("utf-8"):
 bb.warn("The postinstall intercept hook '%s' could not 
be executed due to missing qemu usermode support, details in %s/log.do_%s"
-- 
2.17.1

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

[OE-core] [PATCH 08/10] kmscube: make gstreamer dependency optional

2019-01-23 Thread Alexander Kanavin

This in particular saves build times for virgl oe-selftest.

Signed-off-by: Alexander Kanavin 
---
 meta/recipes-graphics/kmscube/kmscube_git.bb | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-graphics/kmscube/kmscube_git.bb 
b/meta/recipes-graphics/kmscube/kmscube_git.bb
index c6cb1842158..b2dd6b30b0e 100644
--- a/meta/recipes-graphics/kmscube/kmscube_git.bb
+++ b/meta/recipes-graphics/kmscube/kmscube_git.bb
@@ -2,7 +2,7 @@ DESCRIPTION = "Demo application to showcase 3D graphics using 
kms and gbm"
 HOMEPAGE = "https://cgit.freedesktop.org/mesa/kmscube/";
 LICENSE = "MIT"
 SECTION = "graphics"
-DEPENDS = "virtual/libgles2 virtual/egl libdrm gstreamer1.0 
gstreamer1.0-plugins-base"
+DEPENDS = "virtual/libgles2 virtual/egl libdrm"
 
 LIC_FILES_CHKSUM = 
"file://kmscube.c;beginline=1;endline=23;md5=8b309d4ee67b7315ff7381270dd631fb"
 
@@ -16,3 +16,6 @@ S = "${WORKDIR}/git"
 inherit meson pkgconfig distro_features_check
 
 REQUIRED_DISTRO_FEATURES = "opengl"
+
+PACKAGECONFIG ??= ""
+PACKAGECONFIG[gstreamer] = 
"-Dgstreamer=enabled,-Dgstreamer=disabled,gstreamer1.0 
gstreamer1.0-plugins-base"
-- 
2.17.1

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

[OE-core] [PATCH 02/10] fontcache: fix postinst for nativesdk case

2019-01-23 Thread Alexander Kanavin

Both installing the binary into the correct place, and passing that place
to postinst_intercept were missing.

Signed-off-by: Alexander Kanavin 
---
 meta/classes/fontcache.bbclass| 1 +
 meta/recipes-graphics/fontconfig/fontconfig_2.12.6.bb | 6 ++
 2 files changed, 7 insertions(+)

diff --git a/meta/classes/fontcache.bbclass b/meta/classes/fontcache.bbclass
index f71a754a4dd..13f9df1592f 100644
--- a/meta/classes/fontcache.bbclass
+++ b/meta/classes/fontcache.bbclass
@@ -20,6 +20,7 @@ if [ -n "$D" ] ; then
$INTERCEPT_DIR/postinst_intercept update_font_cache ${PKG} 
mlprefix=${MLPREFIX} binprefix=${MLPREFIX} \
'bindir="${bindir}"' \
'libdir="${libdir}"' \
+'libexecdir="${libexecdir}"' \
'base_libdir="${base_libdir}"' \
'fontconfigcachedir="${FONTCONFIG_CACHE_DIR}"' \
'fontconfigcacheparams="${FONTCONFIG_CACHE_PARAMS}"' \
diff --git a/meta/recipes-graphics/fontconfig/fontconfig_2.12.6.bb 
b/meta/recipes-graphics/fontconfig/fontconfig_2.12.6.bb
index 6128d5e2ae2..311c6454a6e 100644
--- a/meta/recipes-graphics/fontconfig/fontconfig_2.12.6.bb
+++ b/meta/recipes-graphics/fontconfig/fontconfig_2.12.6.bb
@@ -41,6 +41,12 @@ do_install_append_class-target() {
 ln ${D}${bindir}/fc-cache ${D}${libexecdir}/${MLPREFIX}fc-cache
 }
 
+do_install_append_class-nativesdk() {
+# duplicate fc-cache for postinstall script
+mkdir -p ${D}${libexecdir}
+ln ${D}${bindir}/fc-cache ${D}${libexecdir}/${MLPREFIX}fc-cache
+}
+
 PACKAGES =+ "fontconfig-utils"
 FILES_${PN} =+ "${datadir}/xml/*"
 FILES_fontconfig-utils = "${bindir}/* ${libexecdir}/*"
-- 
2.17.1

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

[OE-core] [PATCH 01/10] sstate.bbclass: make sure changes to SSTATE_SCAN_FILES are not ignored

2019-01-23 Thread Alexander Kanavin

When changing the SSTATE_SCAN_FILES variable in a recipe it doesn't cause a 
rebuild,
so if there's a sstate-cache available with "bad" sstate data in it that will 
still
be used even though the recipe is updated to address this.

[YOCTO #13144]

Signed-off-by: Alexander Kanavin 
---
 meta/classes/sstate.bbclass | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/classes/sstate.bbclass b/meta/classes/sstate.bbclass
index 2f0bbd2d7df..6f51d9c1879 100644
--- a/meta/classes/sstate.bbclass
+++ b/meta/classes/sstate.bbclass
@@ -62,6 +62,7 @@ SSTATE_ARCHS = " \
 SSTATE_MANMACH ?= "${SSTATE_PKGARCH}"
 
 SSTATECREATEFUNCS = "sstate_hardcode_path"
+SSTATECREATEFUNCS[vardeps] = "SSTATE_SCAN_FILES"
 SSTATEPOSTCREATEFUNCS = ""
 SSTATEPREINSTFUNCS = ""
 SSTATEPOSTUNPACKFUNCS = "sstate_hardcode_path_unpack"
-- 
2.17.1

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

Re: [OE-core] [PATCH] image-buildinfo: make the build file shell compatible

2019-01-23 Thread Khem Raj

On Wed, Jan 23, 2019 at 7:22 AM nick83ola  wrote:

> sorry here is the correct file
>
>
> 
> # Build Configuration  #
> 
> DISTRO="esw-space-controller"
> DISTRO_VERSION="2.6"
> TARGET_SYS="arm-poky-linux-musleabi"
> MACHINE="bumblebee-cl-imx7"
>
> 
> # Layer Revisions  #
> 
> BBLAYERS_meta="HEAD:eddff2b361928e88e3628ebc22a1a0ebb119e01b:modified"
> BBLAYERS_meta-poky="HEAD:eddff2b361928e88e3628ebc22a1a0ebb119e01b:modified"
> BBLAYERS_meta-freescale="HEAD:15a354ee592866a61a893562760ef84bf8fe5e4d:"


Ending with a colon does seem like we are ending with a separator

>
> BBLAYERS_meta-ti="master:fb8bfa61d74e49d1a436612b07bdb69c1bdd350f:"
>
> BBLAYERS_meta-jci-bsp-bumblebee="HEAD:1e293e40a21840fb42abb6d188d23867afb5e9b2:"
> BBLAYERS_meta-oe="HEAD:ff6bead1624a1e261408516b3d064a04aab5f592:"
> BBLAYERS_meta-networking="HEAD:ff6bead1624a1e261408516b3d064a04aab5f592:"
> BBLAYERS_meta-python="HEAD:ff6bead1624a1e261408516b3d064a04aab5f592:"
> BBLAYERS_meta-webserver="HEAD:ff6bead1624a1e261408516b3d064a04aab5f592:"
> BBLAYERS_meta-swupd="HEAD:ed8911cc40b5164af0715f471ee204ea9a3d3491:"
> BBLAYERS_meta-tpm="HEAD:393db42323515a65e554a6b2ed05f7ffcc958e3f:"
> BBLAYERS_meta-security="HEAD:393db42323515a65e554a6b2ed05f7ffcc958e3f:"
> BBLAYERS_meta-perl="HEAD:ff6bead1624a1e261408516b3d064a04aab5f592:"
> BBLAYERS_meta-gplv2="HEAD:aabc30f3bd03f97326fb8596910b94639fea7575:"
>
> BBLAYERS_meta-jci-app-esw="contrib/nlunghi/SPACE-557:5a8aea37191e603b1bba74222ad236f7a3e5cc93:modified"
>
> BBLAYERS_meta-eclipse-smarthome="HEAD:e91f8808ea1a16f5f03359631c58a782067e7884:"
> BBLAYERS_meta-java="HEAD:99d16707d03898fe9fd5b4fee32f6417825a9e6a:"
>
> BBLAYERS_meta-jci-app-bumblebee="contrib/nlunghi/proxy-rest:57f09dd7147d1dae5caf681114b5087bf7957bbf:"
>
> BBLAYERS_meta-nick="master:3987b1f760a25941168f6c0277a0c49b46f5c723:modified"
> BBLAYERS_workspace="::modified"
> --
> ___
> 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] image-buildinfo: make the build file shell compatible

2019-01-23 Thread nick83ola

sorry here is the correct file



# Build Configuration  #

DISTRO="esw-space-controller"
DISTRO_VERSION="2.6"
TARGET_SYS="arm-poky-linux-musleabi"
MACHINE="bumblebee-cl-imx7"


# Layer Revisions  #

BBLAYERS_meta="HEAD:eddff2b361928e88e3628ebc22a1a0ebb119e01b:modified"
BBLAYERS_meta-poky="HEAD:eddff2b361928e88e3628ebc22a1a0ebb119e01b:modified"
BBLAYERS_meta-freescale="HEAD:15a354ee592866a61a893562760ef84bf8fe5e4d:"
BBLAYERS_meta-ti="master:fb8bfa61d74e49d1a436612b07bdb69c1bdd350f:"
BBLAYERS_meta-jci-bsp-bumblebee="HEAD:1e293e40a21840fb42abb6d188d23867afb5e9b2:"
BBLAYERS_meta-oe="HEAD:ff6bead1624a1e261408516b3d064a04aab5f592:"
BBLAYERS_meta-networking="HEAD:ff6bead1624a1e261408516b3d064a04aab5f592:"
BBLAYERS_meta-python="HEAD:ff6bead1624a1e261408516b3d064a04aab5f592:"
BBLAYERS_meta-webserver="HEAD:ff6bead1624a1e261408516b3d064a04aab5f592:"
BBLAYERS_meta-swupd="HEAD:ed8911cc40b5164af0715f471ee204ea9a3d3491:"
BBLAYERS_meta-tpm="HEAD:393db42323515a65e554a6b2ed05f7ffcc958e3f:"
BBLAYERS_meta-security="HEAD:393db42323515a65e554a6b2ed05f7ffcc958e3f:"
BBLAYERS_meta-perl="HEAD:ff6bead1624a1e261408516b3d064a04aab5f592:"
BBLAYERS_meta-gplv2="HEAD:aabc30f3bd03f97326fb8596910b94639fea7575:"
BBLAYERS_meta-jci-app-esw="contrib/nlunghi/SPACE-557:5a8aea37191e603b1bba74222ad236f7a3e5cc93:modified"
BBLAYERS_meta-eclipse-smarthome="HEAD:e91f8808ea1a16f5f03359631c58a782067e7884:"
BBLAYERS_meta-java="HEAD:99d16707d03898fe9fd5b4fee32f6417825a9e6a:"
BBLAYERS_meta-jci-app-bumblebee="contrib/nlunghi/proxy-rest:57f09dd7147d1dae5caf681114b5087bf7957bbf:"
BBLAYERS_meta-nick="master:3987b1f760a25941168f6c0277a0c49b46f5c723:modified"
BBLAYERS_workspace="::modified"
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] image-buildinfo: make the build file shell compatible

2019-01-23 Thread nick83ola

example of the new format:


# Build Configuration
   #

DISTRO="esw-space-controller"
DISTRO_VERSION="2.6"
TARGET_SYS="arm-poky-linux-musleabi"
MACHINE="bumblebee-cl-imx7"


# Layer Revisions
   #

BBLAYERS_meta:HEAD:eddff2b361928e88e3628ebc22a1a0ebb119e01b:modified"
BBLAYERS_meta-poky:HEAD:eddff2b361928e88e3628ebc22a1a0ebb119e01b:modified"
BBLAYERS_meta-freescale:HEAD:15a354ee592866a61a893562760ef84bf8fe5e4d:"
BBLAYERS_meta-ti:master:fb8bfa61d74e49d1a436612b07bdb69c1bdd350f:"
BBLAYERS_meta-jci-bsp-bumblebee:HEAD:1e293e40a21840fb42abb6d188d23867afb5e9b2:"
BBLAYERS_meta-oe:HEAD:ff6bead1624a1e261408516b3d064a04aab5f592:"
BBLAYERS_meta-networking:HEAD:ff6bead1624a1e261408516b3d064a04aab5f592:"
BBLAYERS_meta-python:HEAD:ff6bead1624a1e261408516b3d064a04aab5f592:"
BBLAYERS_meta-webserver:HEAD:ff6bead1624a1e261408516b3d064a04aab5f592:"
BBLAYERS_meta-swupd:HEAD:ed8911cc40b5164af0715f471ee204ea9a3d3491:"
BBLAYERS_meta-tpm:HEAD:393db42323515a65e554a6b2ed05f7ffcc958e3f:"
BBLAYERS_meta-security:HEAD:393db42323515a65e554a6b2ed05f7ffcc958e3f:"
BBLAYERS_meta-perl:HEAD:ff6bead1624a1e261408516b3d064a04aab5f592:"
BBLAYERS_meta-gplv2:HEAD:aabc30f3bd03f97326fb8596910b94639fea7575:"
BBLAYERS_meta-eclipse-smarthome:HEAD:e91f8808ea1a16f5f03359631c58a782067e7884:"
BBLAYERS_meta-java:HEAD:99d16707d03898fe9fd5b4fee32f6417825a9e6a:"
BBLAYERS_meta-nick:master:3987b1f760a25941168f6c0277a0c49b46f5c723:modified"
BBLAYERS_workspace:::modified"

On Wed, 23 Jan 2019 at 12:14, nick83ola  wrote:
>
> this patch permit to simplify extracting build information from
> the /etc/build file from a script, f ex shell or python.
>
> Signed-off-by: Nicola Lunghi 
> ---
>  meta/classes/image-buildinfo.bbclass | 25 +++--
>  1 file changed, 11 insertions(+), 14 deletions(-)
>
> diff --git a/meta/classes/image-buildinfo.bbclass
> b/meta/classes/image-buildinfo.bbclass
> index 94c585d4cd..3ef6ad129d 100644
> --- a/meta/classes/image-buildinfo.bbclass
> +++ b/meta/classes/image-buildinfo.bbclass
> @@ -23,7 +23,7 @@ def image_buildinfo_outputvars(vars, d):
>  value = d.getVar(var) or ""
>  if (d.getVarFlag(var, 'type') == "list"):
>  value = oe.utils.squashspaces(value)
> -ret += "%s = %s\n" % (var, value)
> +ret += '%s="%s"\n' % (var, value)
>  return ret.rstrip('\n')
>
>  # Gets git branch's status (clean or dirty)
> @@ -40,12 +40,12 @@ def get_layer_git_status(path):
>  # Silently treat errors as "modified", without checking for the
>  # (expected) return code 1 in a modified git repo. For example, we 
> get
>  # output and a 129 return code when a layer isn't a git repo at all.
> -return "-- modified"
> +return "modified"
>
>  # Returns layer revisions along with their respective status
>  def get_layer_revs(d):
>  layers = (d.getVar("BBLAYERS") or "").split()
> -medadata_revs = ["%-17s = %s:%s %s" % (os.path.basename(i), \
> +medadata_revs = ['BBLAYERS_%s="%s:%s:%s"' % (os.path.basename(i), \
>  base_get_metadata_git_branch(i, None).strip(), \
>  base_get_metadata_git_revision(i, None), \
>  get_layer_git_status(i)) \
> @@ -66,19 +66,16 @@ python buildinfo () {
>  return
>  with open(d.expand('${IMAGE_ROOTFS}${IMAGE_BUILDINFO_FILE}'),
> 'w') as build:
>  build.writelines((
> -'''---
> -Build Configuration:  |
> 
> -''',
> +'\n',
> +'# Build Configuration  #\n',
> +'\n',
>  buildinfo_target(d),
> -'''
> 
> -Layer Revisions:  |
> 
> -''',
> +'\n\n',
> +'\n',
> +'# Layer Revisions  #\n',
> +'\n',
>  get_layer_revs(d),
> -'''
> -'''
> +'\n',
> ))
>  }
>
> --
> 2.19.1
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] image-buildinfo: make the build file shell compatible

2019-01-23 Thread nick83ola

this patch permit to simplify extracting build information from
the /etc/build file from a script, f ex shell or python.

Signed-off-by: Nicola Lunghi 
---
 meta/classes/image-buildinfo.bbclass | 25 +++--
 1 file changed, 11 insertions(+), 14 deletions(-)

diff --git a/meta/classes/image-buildinfo.bbclass
b/meta/classes/image-buildinfo.bbclass
index 94c585d4cd..3ef6ad129d 100644
--- a/meta/classes/image-buildinfo.bbclass
+++ b/meta/classes/image-buildinfo.bbclass
@@ -23,7 +23,7 @@ def image_buildinfo_outputvars(vars, d):
 value = d.getVar(var) or ""
 if (d.getVarFlag(var, 'type') == "list"):
 value = oe.utils.squashspaces(value)
-ret += "%s = %s\n" % (var, value)
+ret += '%s="%s"\n' % (var, value)
 return ret.rstrip('\n')

 # Gets git branch's status (clean or dirty)
@@ -40,12 +40,12 @@ def get_layer_git_status(path):
 # Silently treat errors as "modified", without checking for the
 # (expected) return code 1 in a modified git repo. For example, we get
 # output and a 129 return code when a layer isn't a git repo at all.
-return "-- modified"
+return "modified"

 # Returns layer revisions along with their respective status
 def get_layer_revs(d):
 layers = (d.getVar("BBLAYERS") or "").split()
-medadata_revs = ["%-17s = %s:%s %s" % (os.path.basename(i), \
+medadata_revs = ['BBLAYERS_%s="%s:%s:%s"' % (os.path.basename(i), \
 base_get_metadata_git_branch(i, None).strip(), \
 base_get_metadata_git_revision(i, None), \
 get_layer_git_status(i)) \
@@ -66,19 +66,16 @@ python buildinfo () {
 return
 with open(d.expand('${IMAGE_ROOTFS}${IMAGE_BUILDINFO_FILE}'),
'w') as build:
 build.writelines((
-'''---
-Build Configuration:  |

-''',
+'\n',
+'# Build Configuration  #\n',
+'\n',
 buildinfo_target(d),
-'''

-Layer Revisions:  |

-''',
+'\n\n',
+'\n',
+'# Layer Revisions  #\n',
+'\n',
 get_layer_revs(d),
-'''
-'''
+'\n',
))
 }

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

Re: [OE-core] [meta-oe][PATCH] openssl: fix multilib file install conflicts

2019-01-23 Thread Xulin Sun

On 01/22/2019 10:25 PM, Peter Kjellerstedt wrote:

-Original Message-
From: openembedded-core-boun...@lists.openembedded.org  On Behalf Of Randy MacLeod
Sent: den 22 januari 2019 00:01
To: Patches and discussions about the oe-core layer ; Xulin Sun 
Subject: Re: [OE-core] [meta-oe][PATCH] openssl: fix multilib file
install conflicts

Xulin,

Thanks for sending this patch.

On 1/17/19 9:22 PM, Xulin Sun wrote:

To avoid issue like below if run "bitbake lib32-wrlinux-image-glibc-

std"

For future oe-core commits, please use a core-image-minimal
example that will be more familiar to people outside of Wind River.

with series userspace packages(LAMP,krb5...) added:

Error: Transaction check error:
file /usr/bin/c_rehash conflicts between attempted installs of
lib32-openssl-bin-1.1.1-r0.armv7at2hf_neon and openssl-bin-1.1.1-

r0.aarch64
Also, while your commit log explains what you fixed, it
doesn't describe the issue for those who don't know what c_rehash is so
something like:

Add multilib_script support for openssl's c_rehash which is
a perl script.

Followed by the example failure log that you showed.

Since this hasn't been merged to master/master-next,
it would be nice if you sent a v2.

Thanks,
../Randy

Signed-off-by: Xulin Sun 
---
   meta/recipes-connectivity/openssl/openssl_1.1.1a.bb | 4 
   1 file changed, 4 insertions(+)

diff --git a/meta/recipes-connectivity/openssl/openssl_1.1.1a.bb

b/meta/recipes-connectivity/openssl/openssl_1.1.1a.bb

index 5c4e69cfb7..21359fa68a 100644
--- a/meta/recipes-connectivity/openssl/openssl_1.1.1a.bb
+++ b/meta/recipes-connectivity/openssl/openssl_1.1.1a.bb
@@ -206,3 +206,7 @@ RREPLACES_openssl-conf = "openssl10-conf"
   RCONFLICTS_openssl-conf = "openssl10-conf"

   BBCLASSEXTEND = "native nativesdk"
+
+inherit multilib_script
+
+MULTILIB_SCRIPTS = "${PN}:${bindir}/c_rehash"

Shouldn't that be:

MULTILIB_SCRIPTS = "${PN}-bin:${bindir}/c_rehash"

given that openssl inherits lib_package and ${bindir}/c_rehash thus
ends up in the ${PN}-bin package?

It is verified that both these two modification method ( ${PN}  or 
${PN}-bin ) are all working and can fix the building error issue.
Seems that after update to openssl 1.1.1, the file /usr/bin/openssl is 
packaged into openssl-bin.

Thanks
Xulin

//Peter

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

50 matches

Mail list logo