date:20160907

Some of the meta-data from the 4.4 kernel was missing from the 4.8
branch. This resulted in some functionality drops and also a size/time
increase in the kernel build (due to debug being turned on).

With this resync, we now have the missing config restored.

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

diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_4.8.bb 
b/meta/recipes-kernel/linux/linux-yocto-rt_4.8.bb
index c602bd3b2c9c..9fe0112fff4f 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_4.8.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_4.8.bb
@@ -12,7 +12,7 @@ python () {
 }
 
 SRCREV_machine ?= "a7d71794e4e38d2f861c1b1dbff761ae0b0836b3"
-SRCREV_meta ?= "8cb7317502c2577f8c83eaf1c061603023824313"
+SRCREV_meta ?= "dd820fa5f7079ac75338f0484151e6454db06951"
 
 SRC_URI = 
"git://git.yoctoproject.org/linux-yocto-4.8.git;branch=${KBRANCH};name=machine \

git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.8;destsuffix=${KMETA}"
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_4.8.bb 
b/meta/recipes-kernel/linux/linux-yocto-tiny_4.8.bb
index ea89eebe6617..7ef5e7e83484 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_4.8.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_4.8.bb
@@ -10,7 +10,7 @@ KMETA = "kernel-meta"
 KCONF_BSP_AUDIT_LEVEL = "2"
 
 SRCREV_machine ?= "3eab887a55424fc2c27553b7bfe32330df83f7b8"
-SRCREV_meta ?= "8cb7317502c2577f8c83eaf1c061603023824313"
+SRCREV_meta ?= "dd820fa5f7079ac75338f0484151e6454db06951"
 
 PV = "${LINUX_VERSION}+git${SRCPV}"
 
diff --git a/meta/recipes-kernel/linux/linux-yocto_4.8.bb 
b/meta/recipes-kernel/linux/linux-yocto_4.8.bb
index cf31d3c846bd..279c0db924fa 100644
--- a/meta/recipes-kernel/linux/linux-yocto_4.8.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_4.8.bb
@@ -19,7 +19,7 @@ SRCREV_machine_qemux86 ?= 
"a7d71794e4e38d2f861c1b1dbff761ae0b0836b3"
 SRCREV_machine_qemux86-64 ?= "a7d71794e4e38d2f861c1b1dbff761ae0b0836b3"
 SRCREV_machine_qemumips64 ?= "a4793b209b32964533e37ebd28a72b757c0f651a"
 SRCREV_machine ?= "a7d71794e4e38d2f861c1b1dbff761ae0b0836b3"
-SRCREV_meta ?= "8cb7317502c2577f8c83eaf1c061603023824313"
+SRCREV_meta ?= "dd820fa5f7079ac75338f0484151e6454db06951"
 
 SRC_URI = 
"git://git.yoctoproject.org/linux-yocto-4.8.git;name=machine;branch=${KBRANCH}; 
\

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

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

[OE-core] [PATCH 4/5] linux-yocto: update to 4.8-rc5

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

diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_4.8.bb 
b/meta/recipes-kernel/linux/linux-yocto-rt_4.8.bb
index 9fe0112fff4f..84699ef70908 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_4.8.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_4.8.bb
@@ -11,8 +11,8 @@ python () {
 raise bb.parse.SkipPackage("Set PREFERRED_PROVIDER_virtual/kernel to 
linux-yocto-rt to enable it")
 }
 
-SRCREV_machine ?= "a7d71794e4e38d2f861c1b1dbff761ae0b0836b3"
-SRCREV_meta ?= "dd820fa5f7079ac75338f0484151e6454db06951"
+SRCREV_machine ?= "9e7ee5155e3466824abe94eebb641c63ab5cd5f2"
+SRCREV_meta ?= "25fb74eaaef249519f25e243e7f9bf0cab0e1781"
 
 SRC_URI = 
"git://git.yoctoproject.org/linux-yocto-4.8.git;branch=${KBRANCH};name=machine \

git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.8;destsuffix=${KMETA}"
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_4.8.bb 
b/meta/recipes-kernel/linux/linux-yocto-tiny_4.8.bb
index 7ef5e7e83484..58d3fea6c95d 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_4.8.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_4.8.bb
@@ -9,8 +9,8 @@ LINUX_VERSION ?= "4.8-rc4"
 KMETA = "kernel-meta"
 KCONF_BSP_AUDIT_LEVEL = "2"
 
-SRCREV_machine ?= "3eab887a55424fc2c27553b7bfe32330df83f7b8"
-SRCREV_meta ?= "dd820fa5f7079ac75338f0484151e6454db06951"
+SRCREV_machine ?= "9e7ee5155e3466824abe94eebb641c63ab5cd5f2"
+SRCREV_meta ?= "25fb74eaaef249519f25e243e7f9bf0cab0e1781"
 
 PV = "${LINUX_VERSION}+git${SRCPV}"
 
diff --git a/meta/recipes-kernel/linux/linux-yocto_4.8.bb 
b/meta/recipes-kernel/linux/linux-yocto_4.8.bb
index 279c0db924fa..d6837d8a1827 100644
--- a/meta/recipes-kernel/linux/linux-yocto_4.8.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_4.8.bb
@@ -11,15 +11,15 @@ KBRANCH_qemux86  ?= "standard/base"
 KBRANCH_qemux86-64 ?= "standard/base"
 KBRANCH_qemumips64 ?= "standard/mti-malta64"
 
-SRCREV_machine_qemuarm ?= "20544507201f870a365c43759e5dea1ab49a2d68"
-SRCREV_machine_qemuarm64 ?= "3eab887a55424fc2c27553b7bfe32330df83f7b8"
-SRCREV_machine_qemumips ?= "03d4caf37d133a923e49b8ad6d814ee299cf92c7"
-SRCREV_machine_qemuppc ?= "3eab887a55424fc2c27553b7bfe32330df83f7b8"
-SRCREV_machine_qemux86 ?= "a7d71794e4e38d2f861c1b1dbff761ae0b0836b3"
-SRCREV_machine_qemux86-64 ?= "a7d71794e4e38d2f861c1b1dbff761ae0b0836b3"
-SRCREV_machine_qemumips64 ?= "a4793b209b32964533e37ebd28a72b757c0f651a"
-SRCREV_machine ?= "a7d71794e4e38d2f861c1b1dbff761ae0b0836b3"
-SRCREV_meta ?= "dd820fa5f7079ac75338f0484151e6454db06951"
+SRCREV_machine_qemuarm ?= "9a91ef47f85a741d842b876267b29f8ded751f68"
+SRCREV_machine_qemuarm64 ?= "9e7ee5155e3466824abe94eebb641c63ab5cd5f2"
+SRCREV_machine_qemumips ?= "40c7a721efe2822fdb7df4b2902a1994add40a77"
+SRCREV_machine_qemuppc ?= "9e7ee5155e3466824abe94eebb641c63ab5cd5f2"
+SRCREV_machine_qemux86 ?= "9e7ee5155e3466824abe94eebb641c63ab5cd5f2"
+SRCREV_machine_qemux86-64 ?= "9e7ee5155e3466824abe94eebb641c63ab5cd5f2"
+SRCREV_machine_qemumips64 ?= "fe4805532e149324939bf9d8415ed43dac357709"
+SRCREV_machine ?= "9e7ee5155e3466824abe94eebb641c63ab5cd5f2"
+SRCREV_meta ?= "25fb74eaaef249519f25e243e7f9bf0cab0e1781"
 
 SRC_URI = 
"git://git.yoctoproject.org/linux-yocto-4.8.git;name=machine;branch=${KBRANCH}; 
\

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

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

[OE-core] [PATCH 5/5] linux-yocto/4.4/4.8: uvesafb: provide option to specify timeout for task completion

Integrating the following patch:

[
   We try to make this change a generic extension, but it is
   actually for a corner case. When a VM (qemu) gets a very limited
   cpu bandwidth from host, which could be under a heavy load, the
   existing 5000 ms timeout could occur and trigger error messages
   in the task function's callers.

   This change adds a new timeout parameter so that we can tweak
   the value as a workaround or for troubleshooting purposes. In
   the infinite wait case, A warning message is printed at 5000ms
   interval.

   In real world, the current 5 sec is generous enough for a video
   request in my opinion, so this change could not be very useful.

   Upstream Status: Inappropriate

   Signed-off-by: Jianxun Zhang 
]

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

diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_4.4.bb 
b/meta/recipes-kernel/linux/linux-yocto-rt_4.4.bb
index fc0e2a431e0a..e7057005d115 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_4.4.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_4.4.bb
@@ -11,8 +11,8 @@ python () {
 raise bb.parse.SkipPackage("Set PREFERRED_PROVIDER_virtual/kernel to 
linux-yocto-rt to enable it")
 }
 
-SRCREV_machine ?= "9135adcfb01432abe4a95a50fca5d0395239f798"
-SRCREV_meta ?= "698835841165b68089604398f68fd8bc3f79cb65"
+SRCREV_machine ?= "a52822c864c50cc5e42939d217a8559fbf853fde"
+SRCREV_meta ?= "59290c5f6192da2eccf478d37a8f9f88134822b3"
 
 SRC_URI = 
"git://git.yoctoproject.org/linux-yocto-4.4.git;branch=${KBRANCH};name=machine \

git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.4;destsuffix=${KMETA}"
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_4.4.bb 
b/meta/recipes-kernel/linux/linux-yocto-tiny_4.4.bb
index 1334a8606e34..e73754519c6a 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_4.4.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_4.4.bb
@@ -9,8 +9,8 @@ LINUX_VERSION ?= "4.4.18"
 KMETA = "kernel-meta"
 KCONF_BSP_AUDIT_LEVEL = "2"
 
-SRCREV_machine ?= "0a0c93f29c0d65c00abdd2f6d1eb89134fae9525"
-SRCREV_meta ?= "698835841165b68089604398f68fd8bc3f79cb65"
+SRCREV_machine ?= "a67e1ae4bf3570e93f8d8fe33b1830de058c1b72"
+SRCREV_meta ?= "59290c5f6192da2eccf478d37a8f9f88134822b3"
 
 PV = "${LINUX_VERSION}+git${SRCPV}"
 
diff --git a/meta/recipes-kernel/linux/linux-yocto_4.4.bb 
b/meta/recipes-kernel/linux/linux-yocto_4.4.bb
index 8661452c74fa..6e5a7c7920ab 100644
--- a/meta/recipes-kernel/linux/linux-yocto_4.4.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_4.4.bb
@@ -11,15 +11,15 @@ KBRANCH_qemux86  ?= "standard/base"
 KBRANCH_qemux86-64 ?= "standard/base"
 KBRANCH_qemumips64 ?= "standard/mti-malta64"
 
-SRCREV_machine_qemuarm ?= "81cae0bb962c278b7fd616ce94b0a1ea21b9a938"
-SRCREV_machine_qemuarm64 ?= "0a0c93f29c0d65c00abdd2f6d1eb89134fae9525"
-SRCREV_machine_qemumips ?= "92bae966ed0bdf4bd8c8343978f83b80b8fa9981"
-SRCREV_machine_qemuppc ?= "0a0c93f29c0d65c00abdd2f6d1eb89134fae9525"
-SRCREV_machine_qemux86 ?= "0a0c93f29c0d65c00abdd2f6d1eb89134fae9525"
-SRCREV_machine_qemux86-64 ?= "0a0c93f29c0d65c00abdd2f6d1eb89134fae9525"
-SRCREV_machine_qemumips64 ?= "aa125473aef74e7731b14f6b56c1b50589fcd668"
-SRCREV_machine ?= "0a0c93f29c0d65c00abdd2f6d1eb89134fae9525"
-SRCREV_meta ?= "698835841165b68089604398f68fd8bc3f79cb65"
+SRCREV_machine_qemuarm ?= "2505d9c2441eb638d55b330144988d1730065074"
+SRCREV_machine_qemuarm64 ?= "a67e1ae4bf3570e93f8d8fe33b1830de058c1b72"
+SRCREV_machine_qemumips ?= "544caf9c03c40c2de6b93db9a767e568e0baaa8f"
+SRCREV_machine_qemuppc ?= "a67e1ae4bf3570e93f8d8fe33b1830de058c1b72"
+SRCREV_machine_qemux86 ?= "a67e1ae4bf3570e93f8d8fe33b1830de058c1b72"
+SRCREV_machine_qemux86-64 ?= "a67e1ae4bf3570e93f8d8fe33b1830de058c1b72"
+SRCREV_machine_qemumips64 ?= "c1b45251a5fabfb0f2aba3a0168d8a952a2cd827"
+SRCREV_machine ?= "a67e1ae4bf3570e93f8d8fe33b1830de058c1b72"
+SRCREV_meta ?= "59290c5f6192da2eccf478d37a8f9f88134822b3"
 
 SRC_URI = 
"git://git.yoctoproject.org/linux-yocto-4.4.git;name=machine;branch=${KBRANCH}; 
\

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

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

[OE-core] [PATCH 1/5] kernel-yocto: restore kernel-meta data detection for SRC_URI elements

Before the kernel tools were simplified and streamlined, there was code
which not only migrated a patch/cfg/scc to the kernel build tree, it
also migrated any subdirectories of those patches.

The effect of this data migration was that any other meta data in
a patch's directory structure would be available for processing.

While we don't want to do this migration anymore, it is possible to
check the path of any SRC_URI patches, and if they include a "kernel-meta"
subdirectory add it to the search path.

This restores the functionality without the old complexity.

Signed-off-by: Bruce Ashfield 
---
 meta/classes/kernel-yocto.bbclass | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/meta/classes/kernel-yocto.bbclass 
b/meta/classes/kernel-yocto.bbclass
index 068378f06796..f991f0219b1f 100644
--- a/meta/classes/kernel-yocto.bbclass
+++ b/meta/classes/kernel-yocto.bbclass
@@ -124,14 +124,19 @@ do_kernel_metadata() {
# for the update part of the process
for f in ${feat_dirs}; do
if [ -d "${WORKDIR}/$f/meta" ]; then
-   includes="$includes -I${WORKDIR}/$f/meta"
-   elif [ -d "${WORKDIR}/$f" ]; then
+   includes="$includes -I${WORKDIR}/$f/kernel-meta"
+   elif [ -d "${WORKDIR}/$f" ]; then
includes="$includes -I${WORKDIR}/$f"
fi
done
-   for s in ${sccs}; do
+   for s in ${sccs} ${patches}; do
sdir=$(dirname $s)
includes="$includes -I${sdir}"
+# if a SRC_URI passed patch or .scc has a subdir of 
"kernel-meta",
+# then we add it to the search path
+if [ -d "${sdir}/kernel-meta" ]; then
+   includes="$includes -I${sdir}/kernel-meta"
+fi
done
 
# expand kernel features into their full path equivalents
-- 
2.5.0

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

[OE-core] [PATCH 2/5] kernel-yocto: allow --allnoconfig and --alldefconfig as KCONFIG_MODES

Previously merge_config.sh was wrapped by the configme script, configme
took the different KCONFIG_MODES as options, and used --allnoconfig
or --alldefconfig.

With the switch to merge_config.sh no longer being wrapped, the new
processing wasn't matching the existing values and only supported
allnoconfig or alldefconfig.

To avoid breaking existing layers, and also keep any working that
have already switched, we can make the case statement match both.

Signed-off-by: Bruce Ashfield 
---
 meta/classes/kernel-yocto.bbclass | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/classes/kernel-yocto.bbclass 
b/meta/classes/kernel-yocto.bbclass
index f991f0219b1f..82b9210b0f58 100644
--- a/meta/classes/kernel-yocto.bbclass
+++ b/meta/classes/kernel-yocto.bbclass
@@ -239,10 +239,10 @@ do_kernel_configme() {
# translate the kconfig_mode into something that merge_config.sh
# understands
case ${KCONFIG_MODE} in
-   allnoconfig)
+   *allnoconfig)
config_flags="-n"
;;
-   alldefconfig)
+   *alldefconfig)
config_flags=""
;;
*)
-- 
2.5.0

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

[OE-core] [PATCH 0/5] kernel-yocto: consolidated pull request

Hi all,

Here are some fixes for the minor issues cased by the kern-tools update
and the recent 4.8 kernel introduction.

RP reported a build and footprint time increase for 4.8, that was due to
some missing kernel meta data that (re)enabled DEBUG and for the standard
kernel. commit [kernel-yocto: restore missing configuration meta data]
deals with that issue.

The commits:

  kernel-yocto: restore kernel-meta data detection for SRC_URI elements
  kernel-yocto: allow --allnoconfig and --alldefconfig as KCONFIG_MODES

Fix some issues with the compatibility of existing layers and config
fragment users. I was luckily able to fix the issues without bringing
the complexity that I was removing.

There's a small change to uvesafb to have a longer timeout on some
machines (or virtual machines) to avoid issues when performing QA
testing.

And finally, we have the 4.8-rc5 content update. I'll do one of these
a week until we get to the full 4.8 release. This can be pended for
the M3 build, but it did pass my local sanity testing.

Cheers,

Bruce

The following changes since commit ce4ea7a730a7bec257218533b7c1fcb31134e25b:

  recipetool: create: avoid extra blank lines in output recipe (2016-09-08 
00:36:49 +0100)

are available in the git repository at:

  git://git.pokylinux.org/poky-contrib zedd/kernel
  http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=zedd/kernel

Bruce Ashfield (5):
  kernel-yocto: restore kernel-meta data detection for SRC_URI elements
  kernel-yocto: allow --allnoconfig and --alldefconfig as KCONFIG_MODES
  kernel-yocto: restore missing configuration meta data
  linux-yocto: update to 4.8-rc5
  linux-yocto/4.4/4.8: uvesafb: provide option to specify timeout for
task completion

 meta/classes/kernel-yocto.bbclass | 15 ++-
 meta/recipes-kernel/linux/linux-yocto-rt_4.4.bb   |  4 ++--
 meta/recipes-kernel/linux/linux-yocto-rt_4.8.bb   |  4 ++--
 meta/recipes-kernel/linux/linux-yocto-tiny_4.4.bb |  4 ++--
 meta/recipes-kernel/linux/linux-yocto-tiny_4.8.bb |  4 ++--
 meta/recipes-kernel/linux/linux-yocto_4.4.bb  | 18 +-
 meta/recipes-kernel/linux/linux-yocto_4.8.bb  | 18 +-
 7 files changed, 36 insertions(+), 31 deletions(-)

-- 
2.5.0

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

[OE-core] [PATCH 2/2] runqemu: fixes for when invoked during a bitbake run

When runqemu is invoked from a running bitbake instance it will be
unable to call `bitbake -e` due to the lock held by the calling
bitbake instance.

Our test code sets an OE_TMPDIR environment variable from which we
can infer/guess paths. Add code to do so when self.bitbake_e can't
be set, much as the sh version of runqemu did.

[YOCTO #10240]

Signed-off-by: Joshua Lock 
---
 scripts/runqemu | 28 ++--
 1 file changed, 22 insertions(+), 6 deletions(-)

diff --git a/scripts/runqemu b/scripts/runqemu
index cbc5cc6..7919564 100755
--- a/scripts/runqemu
+++ b/scripts/runqemu
@@ -570,12 +570,28 @@ class BaseConfig(object):
 if not havenative:
 if not self.bitbake_e:
 self.load_bitbake_env()
-native_vars = ['STAGING_DIR_NATIVE', 'STAGING_BINDIR_NATIVE']
-for nv in native_vars:
-s = re.search('^%s="(.*)"' % nv, self.bitbake_e, re.M)
-if s and s.group(1) != self.get(nv):
-logger.info('Overriding conf file setting of %s to %s from 
Bitbake environment' % (nv, s.group(1)))
-self.set(nv, s.group(1))
+
+if self.bitbake_e:
+native_vars = ['STAGING_DIR_NATIVE', 'STAGING_BINDIR_NATIVE']
+for nv in native_vars:
+s = re.search('^%s="(.*)"' % nv, self.bitbake_e, re.M)
+if s and s.group(1) != self.get(nv):
+logger.info('Overriding conf file setting of %s to %s 
from Bitbake environment' % (nv, s.group(1)))
+self.set(nv, s.group(1))
+else:
+# when we're invoked from a running bitbake instance we won't
+# be able to call `bitbake -e` but should have OE_TMPDIR set in
+# the environment and can guess paths based on it
+tmpdir = os.environ.get('OE_TMPDIR', None)
+if tmpdir:
+logger.info('Setting STAGING_DIR_NATIVE and 
STAGING_BINDIR_NATIVE relative to OE_TMPDIR (%s)' % tmpdir)
+hostos, _, _, _, machine = os.uname()
+buildsys = '%s-%s' % (machine, hostos.lower())
+staging_dir_native = '%s/sysroots/%s' % (tmpdir, buildsys)
+self.set('STAGING_DIR_NATIVE', staging_dir_native)
+# we have to assume that STAGING_BINDIR_NATIVE is at 
usr/bin
+staging_bindir_native = '%s/usr/bin' % staging_dir_native
+self.set('STAGING_BINDIR_NATIVE', staging_bindir_native)
 
 def print_config(self):
 logger.info('Continuing with the following parameters:\n')
-- 
2.7.4

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

[OE-core] [PATCH 1/2] runqemu: remove use of subprocess.run()

We aim to support Python 3.4+ whereas subprocess.run() was added
in Python 3.5.
Replace subprocess.run() with subprocess.check_output().

Signed-off-by: Joshua Lock 
---
 scripts/runqemu | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/scripts/runqemu b/scripts/runqemu
index 0a56c60..cbc5cc6 100755
--- a/scripts/runqemu
+++ b/scripts/runqemu
@@ -858,10 +858,11 @@ class BaseConfig(object):
 cmd = 'bitbake -e'
 
 logger.info('Running %s...' % cmd)
-proc = subprocess.run(cmd, shell=True, stdout=subprocess.PIPE)
-if proc.returncode != 0:
-logger.warn("Couldn't run 'bitbake -e' to gather environment 
information")
-self.bitbake_e = proc.stdout.decode('utf-8')
+try:
+self.bitbake_e = subprocess.check_output(cmd, 
shell=True).decode('utf-8')
+except subprocess.CalledProcessError as err:
+self.bitbake_e = ''
+logger.warn("Couldn't run 'bitbake -e' to gather environment 
information:\n%s" % err.output.decode('utf-8'))
 
 def main():
 if len(sys.argv) == 1 or "help" in sys.argv:
-- 
2.7.4

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

[OE-core] [PATCH 0/2] Python 3 runqemu fixes

Note: This patch is against master-next, as the Python 3 runqemu hasn't made it
to master yet.
This supercedes my earlier one patch series "Python3 runqemu: remove use of 
subprocess.run()" (both versions)

Two fixes for the Python3 runqemu:
* Use of subprocess.run() in recent runqemu changes (by me) elevates the Python
  3 requirement from 3.4+ to 3.5+. Replace subprocess.run() with
  subprocess.check_output(), as that is available in Python 3.1+
* testimage calls runqemu from within a bitbake run, which prevents us from 
  using `bitbake -e` to determine bitbake environment variables. The test code
  exports an OE_TMPDIR variable which was used by the shell runqemu to 
  infer/guess paths into the sysroot. This patch does the equivalent.

Changes since "Python3 runqemu: remove use of subprocess.run()" v2:
* Fix typo in exception handler log message.
* Add extra fix to support testimage

Changes since "Python3 runqemu: remove use of subprocess.run()" v1:
* Fix printing of error message in exception handler

The following changes since commit 3df3462d81216d8b26a87d9915abd9de1b2c2faa:

  bitbake: cooker: record events on cooker exit (2016-09-06 23:18:06 +0100)

are available in the git repository at:

  git://git.yoctoproject.org/poky-contrib joshuagl/runqemu
  http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=joshuagl/runqemu

Joshua Lock (2):
  runqemu: remove use of subprocess.run()
  runqemu: fixes for when invoked during a bitbake run

 scripts/runqemu | 37 +++--
 1 file changed, 27 insertions(+), 10 deletions(-)

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

[OE-core] [oe-core][PATCH 1/1][v2] libwebp: sepcify neon availability for arm

2016-09-07 Thread Joe Slater

Defeat automatic neon detection.

Signed-off-by: Joe Slater 
---
 meta/recipes-multimedia/webp/libwebp_0.5.1.bb |5 +
 1 file changed, 5 insertions(+)

diff --git a/meta/recipes-multimedia/webp/libwebp_0.5.1.bb 
b/meta/recipes-multimedia/webp/libwebp_0.5.1.bb
index 222bd56..b882db7 100644
--- a/meta/recipes-multimedia/webp/libwebp_0.5.1.bb
+++ b/meta/recipes-multimedia/webp/libwebp_0.5.1.bb
@@ -26,6 +26,11 @@ EXTRA_OECONF = " \
 --enable-libwebpdemux \
 --enable-threading \
 "
+# Do not trust configure to determine if neon is available.
+#
+EXTRA_OECONF_append_arm = " \
+
${@bb.utils.contains("TUNE_FEATURES","neon","--enable-neon","--disable-neon",d)}
 \
+"
 
 inherit autotools lib_package
 
-- 
1.7.9.5

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

[OE-core] [PATCH 2/2][PROPOSED] libcap: remove dependency on attr

2016-09-07 Thread Jianxun Zhang

85f38a573fc47472ab792e813b6f6b6f0b1df112 in libcap drops
this dependency. Not seeing much necessity of using
EXTRA_OECONF (which doesn't seem effective) for the left,
we purge these code in libcap recipe.

Signed-off-by: Jianxun Zhang 
---
Limited test is performed by building this recipe individually.
Refer to the cover letter before merge.

 meta/recipes-support/libcap/libcap_2.25.bb | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/meta/recipes-support/libcap/libcap_2.25.bb 
b/meta/recipes-support/libcap/libcap_2.25.bb
index bc29310..3b7876a 100644
--- a/meta/recipes-support/libcap/libcap_2.25.bb
+++ b/meta/recipes-support/libcap/libcap_2.25.bb
@@ -27,11 +27,8 @@ do_configure() {
sed -e '/shell gperf/cifeq (,yes)' -i libcap/Makefile
 }
 
-PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'xattr', 'attr', 
'', d)}"
 PACKAGECONFIG_class-native ??= ""
 
-PACKAGECONFIG[attr] = "LIBATTR=yes,LIBATTR=no,attr"
-
 EXTRA_OEMAKE = " \
   INDENT=  \
   lib=${@os.path.basename('${libdir}')} \
@@ -46,12 +43,11 @@ EXTRA_OEMAKE_append_class-target = " 
SYSTEM_HEADERS=${STAGING_INCDIR}"
 CFLAGS += "-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64"
 
 do_compile() {
-   oe_runmake ${EXTRA_OECONF}
+   oe_runmake
 }
 
 do_install() {
oe_runmake install \
-   ${EXTRA_OECONF} \
DESTDIR="${D}" \
prefix="${prefix}" \
SBINDIR="${sbindir}"
-- 
2.7.4

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

[OE-core] [PATCH 0/2][PROPOSED] libcap fix and update

2016-09-07 Thread Jianxun Zhang

Need some experts to review this patch series. I am not really
sure for if what I fixed is a valid case or if fix is the best
answer. The validation before submission is very limited too.

I ran into the compiling issue when build an application and
found this recipe cannot be built without specifying anything.
I don't feel the existing options are passed to make with test,
and guess EXTRA_CONF won't work with this makefile-based project.

The second patch is a following-up when I saw there is another
option in the similar situation and seems to be obsolete now.

Jianxun Zhang (2):
  libcap: fix compiling issue when not having libpam
  libcap: remove dependency on attr

 meta/recipes-support/libcap/libcap_2.25.bb | 11 +++
 1 file changed, 3 insertions(+), 8 deletions(-)

-- 
2.7.4

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

[OE-core] [PATCH 1/2][PROPOSED] libcap: fix compiling issue when not having libpam

2016-09-07 Thread Jianxun Zhang

Select a genericx86-64 target and run
bitbake libcap

This error shows up:
-
pam_cap.c:19:34: fatal error: security/pam_modules.h:
No such file or directory
 #include 
  ^
compilation terminated.
Makefile:23: recipe for target 'pam_cap.o' failed
make[1]: *** [pam_cap.o] Error 1
-

The option PAM_CAP=yes/no is not effectively passed to make.
We change to EXTRA_OEMAKE, instead of EXTRA_OECONF which
PACKAGECONFIG deals with, for this Makefile-based project.

Signed-off-by: Jianxun Zhang 
---
Limited test is performed by building this recipe only.
Refer to the cover letter before merge.

 meta/recipes-support/libcap/libcap_2.25.bb | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/meta/recipes-support/libcap/libcap_2.25.bb 
b/meta/recipes-support/libcap/libcap_2.25.bb
index 8f3f11e..bc29310 100644
--- a/meta/recipes-support/libcap/libcap_2.25.bb
+++ b/meta/recipes-support/libcap/libcap_2.25.bb
@@ -5,7 +5,7 @@ HOMEPAGE = "http://sites.google.com/site/fullycapable/;
 LICENSE = "BSD | GPLv2"
 LIC_FILES_CHKSUM = "file://License;md5=3f84fd6f29d453a56514cb7e4ead25f1"
 
-DEPENDS = "hostperl-runtime-native"
+DEPENDS = "hostperl-runtime-native ${@bb.utils.contains('DISTRO_FEATURES', 
'pam', 'libpam', '', d)}"
 
 SRC_URI = 
"${KERNELORG_MIRROR}/linux/libs/security/linux-privs/${BPN}2/${BPN}-${PV}.tar.xz
 \

file://0001-ensure-the-XATTR_NAME_CAPS-is-defined-when-it-is-use.patch \
@@ -27,18 +27,17 @@ do_configure() {
sed -e '/shell gperf/cifeq (,yes)' -i libcap/Makefile
 }
 
-PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'pam', 'pam', '', 
d)} \
-   ${@bb.utils.contains('DISTRO_FEATURES', 'xattr', 'attr', 
'', d)}"
+PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'xattr', 'attr', 
'', d)}"
 PACKAGECONFIG_class-native ??= ""
 
 PACKAGECONFIG[attr] = "LIBATTR=yes,LIBATTR=no,attr"
-PACKAGECONFIG[pam] = "PAM_CAP=yes,PAM_CAP=no,libpam"
 
 EXTRA_OEMAKE = " \
   INDENT=  \
   lib=${@os.path.basename('${libdir}')} \
   RAISE_SETFCAP=no \
   DYNAMIC=yes \
+  ${@bb.utils.contains('DISTRO_FEATURES', 'pam', 'PAM_CAP=yes', 'PAM_CAP=no', 
d)} \
 "
 
 EXTRA_OEMAKE_append_class-target = " SYSTEM_HEADERS=${STAGING_INCDIR}"
-- 
2.7.4

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

[OE-core] [PATCH 2/2 v2] utils.bbclass: Added error checking for oe_soinstall

2016-09-07 Thread Henry Bruce

Fixes [YOCTO #10146]

Signed-off-by: Henry Bruce 
---
 meta/classes/utils.bbclass | 15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/meta/classes/utils.bbclass b/meta/classes/utils.bbclass
index d56f51e..3c2a14f 100644
--- a/meta/classes/utils.bbclass
+++ b/meta/classes/utils.bbclass
@@ -62,15 +62,18 @@ def is_machine_specific(d):
 oe_soinstall() {
# Purpose: Install shared library file and
#  create the necessary links
-   # Example:
-   #
-   # oe_
-   #
-   #bbnote installing shared library $1 to $2
-   #
+   # Example: oe_soinstall libfoo.so.1.2.3 ${D}${libdir}
libname=`basename $1`
+   case "$libname" in
+   *.so)
+   bbfatal "oe_soinstall: Shared library must haved versioned 
filename (e.g. libfoo.so.1.2.3)"
+   ;;
+   esac
install -m 755 $1 $2/$libname
sonamelink=`${HOST_PREFIX}readelf -d $1 |grep 'Library soname:' |sed -e 
's/.*\[\(.*\)\].*/\1/'`
+   if [ -z $sonamelink ]; then
+   bbfatal "oe_soinstall: $libname is missing ELF tag 'SONAME'."
+   fi
solink=`echo $libname | sed -e 's/\.so\..*/.so/'`
ln -sf $libname $2/$sonamelink
ln -sf $libname $2/$solink
-- 
2.7.4

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

Re: [OE-core] [PATCH 5/9] recipetool: create: support git submodules

2016-09-07 Thread Paul Eggleton

Hi Ola,

On Wed, 07 Sep 2016 06:23:15 Ola x Nilsson wrote:
> > From: openembedded-core-boun...@lists.openembedded.org
> > [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf
> > Of Paul Eggleton
> > Sent: den 6 september 2016 12:03
> > 
> > Ensure we fetch submodules and set SRC_URI correctly when pointing to a
> > git repository that contains submodules.
> > 
> > Signed-off-by: Paul Eggleton 
> > ---
> > 
> >  scripts/lib/recipetool/create.py | 12 ++--
> >  1 file changed, 10 insertions(+), 2 deletions(-)
> > 
> > diff --git a/scripts/lib/recipetool/create.py
> > b/scripts/lib/recipetool/create.py index a08352e..7cbd614 100644
> > --- a/scripts/lib/recipetool/create.py
> > +++ b/scripts/lib/recipetool/create.py
> > 
> > @@ -399,6 +399,11 @@ def create_recipe(args):
> >  if ' >  logger.error('Fetching "%s" returned a single
> >  HTML page - check
> > 
> > the URL is correct and functional' % fetchuri)
> > 
> >  sys.exit(1)
> > 
> > +if os.path.exists(os.path.join(srctree, '.gitmodules')) and
> > srcuri.startswith('git://'):
> > +srcuri = 'gitsm://' + srcuri[6:]
> > +logger.info('Fetching submodules...')
> > +bb.process.run('git submodule init', cwd=srctree)
> > +bb.process.run('git submodule update', cwd=srctree)
> 
> This is not how the gitsm fetcher does it.
> 
> git submodule update --init --recursive
> 
> will actually fetch all submodules recursively.

Right, we should indeed be doing that. I've pushed a new commit to the branch.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Speed regression in the 4.8 kernel?


On 2016-09-07 10:15 AM, Bruce Ashfield wrote:

On 2016-09-07 10:00 AM, Markus Lehtonen wrote:

On Wed, 2016-09-07 at 08:44 -0400, Bruce Ashfield wrote:

On 2016-09-07 8:33 AM, Markus Lehtonen wrote:

On Wed, 2016-09-07 at 07:56 -0400, Bruce Ashfield wrote:

On 2016-09-07 5:27 AM, Richard Purdie wrote:

Hi Bruce,

I deliberately spaced out the merges of various things so we could
get
performance measurements of the system as it happened.
Unfortunately
the 4.8 kernel appears to regress the kernel build time quite
significantly:

The raw data:

ypperf02,master:9428b19a7dd1d265d9f3211004391abe33ea0224,uninative
-1.3
-414
-g9428b19,1:01:32,4:21.16,1:00:32,2:10.86,0:16.19,0:11.21,0:01.20,5
:34.
73,26701616,6445160,1477762,5446116
ypperf02,master:9428b19a7dd1d265d9f3211004391abe33ea0224,uninative
-1.3
-414
-g9428b19,1:04:14,4:23.82,1:00:40,2:13.70,0:16.18,0:11.28,0:01.22,5
:45.
48,26697516,6445724,1478048,5446490
ypperf02,master:b9d90ace005597ba35b59adcd8106a1c52e40c1a,uninative
-1.3
-438
-gb9d90ac,1:03:16,7:22.13,1:02:46,2:16.60,0:16.32,0:11.04,0:01.21,5
:42.
11,30852876,10550952,1707255,5912282
ypperf02,master:f7ca989ddc6d470429b547647d3fbaad83a982d9,uninative
-1.3
-446
-gf7ca989,1:04:42,7:29.05,1:03:04,2:19.71,0:16.21,0:11.05,0:01.24,5
:52.
83,30845748,10551316,1707615,5912122

which shows the time for "bitbake virtual/kernel -c cleansstate;
time
bitbake virtual/kernel" goes from 4:20 to 7:22. The disk footprint
of
the build went from 26GB to 30GB. The build with rm_work size went
from
6.4GB to 10.5GB. The overall build time went up 2-3 minutes which
looks
like the increased kernel build time. The increased time may well
be
from the increased data being generated/processed.


Is it the actual compile itself ? What's the trick to actually get
individual task

For the disk footprint, I can check the refs in the tree and purge
anything that may be dangling. That being said, I can't do that to
the repository on the git server, so we may need someone that can
issue a git gc directly on the repository.



We can't ship M3 with this much of a performance degradation and
increased space usage :(. Any idea what changed?


Nope. I can only focus on one thing at a time. I was worried about
a functionally correct kernel (which I still am) and haven't looked
at anything in the peripheral yet.

If I can get individual task timings, I can look at it more.

I'm seeing significantly faster meta data phases, etc, so I'm
interested
to know if this is purely in the build steps.


In my own test setup I'm seeing similar increase in kernel build time.

Comparing the buildstats of kernel builds from before and after the 4.8
I
got the following numbers (these are cpu times consumed by the tasks

TASK  ABSDIFF   RELDIFF  CPUTIME1CPUTIME2
do_package +17.5s   +133.1% 13.1s -> 30.6s
do_deploy  +19.9s  +1449.4%  1.4s -> 21.3s
do_package_write_rpm   +86.8s   +714.7% 12.1s -> 98.9s
do_compile_kernelmodules  +139.4s+35.9%388.2s -> 527.6s
do_compile+201.1s+30.0%670.3s -> 871.4s


ok. So as long as the significant increases aren't in do_kernel_metadata
or do_patch (those two I've measured), we are dealing with something
in the kernel build itself. I can deal with the footprint by inspecting
the repo, but Kbuild is a tougher nut to crack.


I took a look at the kernel build directory size and there was a huge
difference (500M vs. 3.5G). Seeing that significant change I took a
look at
the kconfigs and found out that CONFIG_DEBUG_KERNEL and CONFIG_DEBUG_INFO
are enabled, among other things. Looking at the kernel metadata I can see
that these are enabled in ktypes/base/base.cfg.

I guess this is not intended?


Sure enough, there's a missing series in the 4.8 and master branches
of the kernel meta repo.

I'm going to do a full audit and will send meta data updates once I've
ensured nothing else is missing.


I've sorted out the meta data issues and will send a series out shortly.

Bruce



Bruce



Thanks,
  Markus



Out of curiosity, is the 4.4 kernel on master showing a significantly
shorter build time ? I'm assuming the before is the 4.4 kernel .. but
I just wanted to be sure, so we can rule out something else that might
be pathologically reacting to the sheer amount of I/O in a kernel build.

Bruce




I haven't tried to analyze what is causing this yet, though.


Thanks,
  Markus









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

[OE-core] [v2][oe-core][PATCH 1/1] libwebp: sepcify neon availability for arm

2016-09-07 Thread Joe Slater

Defeat automatic neon detection.

Signed-off-by: Joe Slater 
---
 meta/recipes-multimedia/webp/libwebp_0.5.1.bb |5 +
 1 file changed, 5 insertions(+)

diff --git a/meta/recipes-multimedia/webp/libwebp_0.5.1.bb 
b/meta/recipes-multimedia/webp/libwebp_0.5.1.bb
index 222bd56..b882db7 100644
--- a/meta/recipes-multimedia/webp/libwebp_0.5.1.bb
+++ b/meta/recipes-multimedia/webp/libwebp_0.5.1.bb
@@ -26,6 +26,11 @@ EXTRA_OECONF = " \
 --enable-libwebpdemux \
 --enable-threading \
 "
+# Do not trust configure to determine if neon is available.
+#
+EXTRA_OECONF_append_arm = " \
+
${@bb.utils.contains("TUNE_FEATURES","neon","--enable-neon","--disable-neon",d)}
 \
+"
 
 inherit autotools lib_package
 
-- 
1.7.9.5

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

Re: [OE-core] [PATCH 2/2] utils.bbclass: Added error checking for oe_soinstall

2016-09-07 Thread Christopher Larson

On Wed, Sep 7, 2016 at 9:27 AM, Burton, Ross  wrote:

> On 6 September 2016 at 23:11, Henry Bruce  wrote:
>
>> +   if [[ "$libname" == *.so ]]; then
>>
>
> That's a lot of bashisms in one place ;)
>
> [ not [[
> = not ==
> *.so will need to be escaped in case it matches anything in cwd and
> expands.
>

Good catch, I expect what he really needs is a case statement, since he
doesn’t want an exact match, but to check if the wildcard matches.

case “$libname” in
*.so)
…
;;
esac
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 2/2] utils.bbclass: Added error checking for oe_soinstall

2016-09-07 Thread Burton, Ross

On 6 September 2016 at 23:11, Henry Bruce  wrote:

> +   if [[ "$libname" == *.so ]]; then
>

That's a lot of bashisms in one place ;)

[ not [[
= not ==
*.so will need to be escaped in case it matches anything in cwd and expands.

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

[OE-core] [PATCH 1/1] runqemu: remove use of subprocess.run()

We aim to support Python 3.4+ whereas subprocess.run() was added
in Python 3.5.
Replace subprocess.run() with subprocess.check_output().

Signed-off-by: Joshua Lock 
---
 scripts/runqemu | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/scripts/runqemu b/scripts/runqemu
index 0a56c60..27108ee 100755
--- a/scripts/runqemu
+++ b/scripts/runqemu
@@ -858,10 +858,11 @@ class BaseConfig(object):
 cmd = 'bitbake -e'
 
 logger.info('Running %s...' % cmd)
-proc = subprocess.run(cmd, shell=True, stdout=subprocess.PIPE)
-if proc.returncode != 0:
-logger.warn("Couldn't run 'bitbake -e' to gather environment 
information")
-self.bitbake_e = proc.stdout.decode('utf-8')
+try:
+self.bitbake_e = subprocess.check_output(cmd, 
shell=True).decode('utf-8')
+except subprocess.CalledProcessError as err:
+self.bitbake_e = ''
+logger.warn("Couldn't run 'bitbake -e' to gather environment 
information/\n%s" % err.output.decode('utf-8'))
 
 def main():
 if len(sys.argv) == 1 or "help" in sys.argv:
-- 
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] Python3 runqemu: remove use of subprocess.run()

Note: This patch is against master-next, as the Python 3 runqemu hasn't made it
to master yet.

Use of subprocess.run() in recent runqemu changes (by me) elevates the Python 3
requirement from 3.4+ to 3.5+. Replace subprocess.run() with 
subprocess.check_output(), as that is available in Python 3.1+

Changes since v1:
* Fix printing of error message in exception handler

The following changes since commit 3df3462d81216d8b26a87d9915abd9de1b2c2faa:

  bitbake: cooker: record events on cooker exit (2016-09-06 23:18:06 +0100)

are available in the git repository at:

  git://git.yoctoproject.org/poky-contrib joshuagl/runqemu
  http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=joshuagl/runqemu

Joshua Lock (1):
  runqemu: remove use of subprocess.run()

 scripts/runqemu | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

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

[OE-core] [PATCH] python: recompile _sysconfigdata.py after modifying it

2016-09-07 Thread Ross Burton

We sed this file after the .pyc has been generated, so re-compile the .pyc to
ensure that it is up to date.

Signed-off-by: Ross Burton 
---
 meta/recipes-devtools/python/python_2.7.12.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-devtools/python/python_2.7.12.bb 
b/meta/recipes-devtools/python/python_2.7.12.bb
index 3ee1e38..65b57171 100644
--- a/meta/recipes-devtools/python/python_2.7.12.bb
+++ b/meta/recipes-devtools/python/python_2.7.12.bb
@@ -132,6 +132,7 @@ py_package_preprocess () {
sed -i -e 's:--sysroot=${STAGING_DIR_TARGET}::g' -e 
s:'--with-libtool-sysroot=${STAGING_DIR_TARGET}'::g \
${PKGD}/${libdir}/python${PYTHON_MAJMIN}/config/Makefile \
${PKGD}/${libdir}/python${PYTHON_MAJMIN}/_sysconfigdata.py
+python -m py_compile 
${PKGD}/${libdir}/python${PYTHON_MAJMIN}/_sysconfigdata.py
 }
 
 require python-${PYTHON_MAJMIN}-manifest.inc
-- 
2.8.1

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

Re: [OE-core] [PATCH 1/1] runqemu: remove use of subprocess.run()

On Wed, 2016-09-07 at 15:10 +0100, Joshua Lock wrote:
> We aim to support Python 3.4+ whereas subprocess.run() was added
> in Python 3.5.
> Replace subprocess.run() with subprocess.check_output().
> 
> Signed-off-by: Joshua Lock 
> ---
>  scripts/runqemu | 9 +
>  1 file changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/scripts/runqemu b/scripts/runqemu
> index 0a56c60..3ffd87a 100755
> --- a/scripts/runqemu
> +++ b/scripts/runqemu
> @@ -858,10 +858,11 @@ class BaseConfig(object):
>  cmd = 'bitbake -e'
>  
>  logger.info('Running %s...' % cmd)
> -proc = subprocess.run(cmd, shell=True,
> stdout=subprocess.PIPE)
> -if proc.returncode != 0:
> -logger.warn("Couldn't run 'bitbake -e' to gather
> environment information")
> -self.bitbake_e = proc.stdout.decode('utf-8')
> +try:
> +out = subprocess.check_output(cmd,
> shell=True).decode('utf-8')
> +self.bitbake_e = out
> +except subprocess.CalledProcessError as err:
> +logger.warn("Couldn't run 'bitbake -e' to gather
> environment information/\n%s" % out)

I'm trying to access out when it's unassigned here, v2 coming soon.

Regards,

Joshua

>  
>  def main():
>  if len(sys.argv) == 1 or "help" in sys.argv:
> -- 
> 2.7.4
> 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Speed regression in the 4.8 kernel?


On 2016-09-07 10:00 AM, Markus Lehtonen wrote:

On Wed, 2016-09-07 at 08:44 -0400, Bruce Ashfield wrote:

On 2016-09-07 8:33 AM, Markus Lehtonen wrote:

On Wed, 2016-09-07 at 07:56 -0400, Bruce Ashfield wrote:

On 2016-09-07 5:27 AM, Richard Purdie wrote:

Hi Bruce,

I deliberately spaced out the merges of various things so we could
get
performance measurements of the system as it happened.
Unfortunately
the 4.8 kernel appears to regress the kernel build time quite
significantly:

The raw data:

ypperf02,master:9428b19a7dd1d265d9f3211004391abe33ea0224,uninative
-1.3
-414
-g9428b19,1:01:32,4:21.16,1:00:32,2:10.86,0:16.19,0:11.21,0:01.20,5
:34.
73,26701616,6445160,1477762,5446116
ypperf02,master:9428b19a7dd1d265d9f3211004391abe33ea0224,uninative
-1.3
-414
-g9428b19,1:04:14,4:23.82,1:00:40,2:13.70,0:16.18,0:11.28,0:01.22,5
:45.
48,26697516,6445724,1478048,5446490
ypperf02,master:b9d90ace005597ba35b59adcd8106a1c52e40c1a,uninative
-1.3
-438
-gb9d90ac,1:03:16,7:22.13,1:02:46,2:16.60,0:16.32,0:11.04,0:01.21,5
:42.
11,30852876,10550952,1707255,5912282
ypperf02,master:f7ca989ddc6d470429b547647d3fbaad83a982d9,uninative
-1.3
-446
-gf7ca989,1:04:42,7:29.05,1:03:04,2:19.71,0:16.21,0:11.05,0:01.24,5
:52.
83,30845748,10551316,1707615,5912122

which shows the time for "bitbake virtual/kernel -c cleansstate;
time
bitbake virtual/kernel" goes from 4:20 to 7:22. The disk footprint
of
the build went from 26GB to 30GB. The build with rm_work size went
from
6.4GB to 10.5GB. The overall build time went up 2-3 minutes which
looks
like the increased kernel build time. The increased time may well
be
from the increased data being generated/processed.


Is it the actual compile itself ? What's the trick to actually get
individual task

For the disk footprint, I can check the refs in the tree and purge
anything that may be dangling. That being said, I can't do that to
the repository on the git server, so we may need someone that can
issue a git gc directly on the repository.



We can't ship M3 with this much of a performance degradation and
increased space usage :(. Any idea what changed?


Nope. I can only focus on one thing at a time. I was worried about
a functionally correct kernel (which I still am) and haven't looked
at anything in the peripheral yet.

If I can get individual task timings, I can look at it more.

I'm seeing significantly faster meta data phases, etc, so I'm
interested
to know if this is purely in the build steps.


In my own test setup I'm seeing similar increase in kernel build time.

Comparing the buildstats of kernel builds from before and after the 4.8
I
got the following numbers (these are cpu times consumed by the tasks

TASK  ABSDIFF   RELDIFF  CPUTIME1CPUTIME2
do_package +17.5s   +133.1% 13.1s -> 30.6s
do_deploy  +19.9s  +1449.4%  1.4s -> 21.3s
do_package_write_rpm   +86.8s   +714.7% 12.1s -> 98.9s
do_compile_kernelmodules  +139.4s+35.9%388.2s -> 527.6s
do_compile+201.1s+30.0%670.3s -> 871.4s


ok. So as long as the significant increases aren't in do_kernel_metadata
or do_patch (those two I've measured), we are dealing with something
in the kernel build itself. I can deal with the footprint by inspecting
the repo, but Kbuild is a tougher nut to crack.


I took a look at the kernel build directory size and there was a huge
difference (500M vs. 3.5G). Seeing that significant change I took a look at
the kconfigs and found out that CONFIG_DEBUG_KERNEL and CONFIG_DEBUG_INFO
are enabled, among other things. Looking at the kernel metadata I can see
that these are enabled in ktypes/base/base.cfg.

I guess this is not intended?


Sure enough, there's a missing series in the 4.8 and master branches
of the kernel meta repo.

I'm going to do a full audit and will send meta data updates once I've
ensured nothing else is missing.

Bruce



Thanks,
  Markus



Out of curiosity, is the 4.4 kernel on master showing a significantly
shorter build time ? I'm assuming the before is the 4.4 kernel .. but
I just wanted to be sure, so we can rule out something else that might
be pathologically reacting to the sheer amount of I/O in a kernel build.

Bruce




I haven't tried to analyze what is causing this yet, though.


Thanks,
  Markus







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

[OE-core] [PATCH 1/1] runqemu: remove use of subprocess.run()

We aim to support Python 3.4+ whereas subprocess.run() was added
in Python 3.5.
Replace subprocess.run() with subprocess.check_output().

Signed-off-by: Joshua Lock 
---
 scripts/runqemu | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/scripts/runqemu b/scripts/runqemu
index 0a56c60..3ffd87a 100755
--- a/scripts/runqemu
+++ b/scripts/runqemu
@@ -858,10 +858,11 @@ class BaseConfig(object):
 cmd = 'bitbake -e'
 
 logger.info('Running %s...' % cmd)
-proc = subprocess.run(cmd, shell=True, stdout=subprocess.PIPE)
-if proc.returncode != 0:
-logger.warn("Couldn't run 'bitbake -e' to gather environment 
information")
-self.bitbake_e = proc.stdout.decode('utf-8')
+try:
+out = subprocess.check_output(cmd, shell=True).decode('utf-8')
+self.bitbake_e = out
+except subprocess.CalledProcessError as err:
+logger.warn("Couldn't run 'bitbake -e' to gather environment 
information/\n%s" % out)
 
 def main():
 if len(sys.argv) == 1 or "help" in sys.argv:
-- 
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] Python3 runqemu: remove use of subprocess.run()

Note: This patch is against master-next, as the Python 3 runqemu hasn't made it
to master yet.

Use of subprocess.run() in recent runqemu changes (by me) elevates the Python 3
requirement from 3.4+ to 3.5+. Replace subprocess.run() with 
subprocess.check_output(), as that is available in Python 3.1+

The following changes since commit 3df3462d81216d8b26a87d9915abd9de1b2c2faa:

  bitbake: cooker: record events on cooker exit (2016-09-06 23:18:06 +0100)

are available in the git repository at:

  git://git.yoctoproject.org/poky-contrib joshuagl/runqemu
  http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=joshuagl/runqemu

Joshua Lock (1):
  runqemu: remove use of subprocess.run()

 scripts/runqemu | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

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

Re: [OE-core] Speed regression in the 4.8 kernel?


On 2016-09-07 10:00 AM, Markus Lehtonen wrote:

On Wed, 2016-09-07 at 08:44 -0400, Bruce Ashfield wrote:

On 2016-09-07 8:33 AM, Markus Lehtonen wrote:

On Wed, 2016-09-07 at 07:56 -0400, Bruce Ashfield wrote:

On 2016-09-07 5:27 AM, Richard Purdie wrote:

Hi Bruce,

I deliberately spaced out the merges of various things so we could
get
performance measurements of the system as it happened.
Unfortunately
the 4.8 kernel appears to regress the kernel build time quite
significantly:

The raw data:

ypperf02,master:9428b19a7dd1d265d9f3211004391abe33ea0224,uninative
-1.3
-414
-g9428b19,1:01:32,4:21.16,1:00:32,2:10.86,0:16.19,0:11.21,0:01.20,5
:34.
73,26701616,6445160,1477762,5446116
ypperf02,master:9428b19a7dd1d265d9f3211004391abe33ea0224,uninative
-1.3
-414
-g9428b19,1:04:14,4:23.82,1:00:40,2:13.70,0:16.18,0:11.28,0:01.22,5
:45.
48,26697516,6445724,1478048,5446490
ypperf02,master:b9d90ace005597ba35b59adcd8106a1c52e40c1a,uninative
-1.3
-438
-gb9d90ac,1:03:16,7:22.13,1:02:46,2:16.60,0:16.32,0:11.04,0:01.21,5
:42.
11,30852876,10550952,1707255,5912282
ypperf02,master:f7ca989ddc6d470429b547647d3fbaad83a982d9,uninative
-1.3
-446
-gf7ca989,1:04:42,7:29.05,1:03:04,2:19.71,0:16.21,0:11.05,0:01.24,5
:52.
83,30845748,10551316,1707615,5912122

which shows the time for "bitbake virtual/kernel -c cleansstate;
time
bitbake virtual/kernel" goes from 4:20 to 7:22. The disk footprint
of
the build went from 26GB to 30GB. The build with rm_work size went
from
6.4GB to 10.5GB. The overall build time went up 2-3 minutes which
looks
like the increased kernel build time. The increased time may well
be
from the increased data being generated/processed.


Is it the actual compile itself ? What's the trick to actually get
individual task

For the disk footprint, I can check the refs in the tree and purge
anything that may be dangling. That being said, I can't do that to
the repository on the git server, so we may need someone that can
issue a git gc directly on the repository.



We can't ship M3 with this much of a performance degradation and
increased space usage :(. Any idea what changed?


Nope. I can only focus on one thing at a time. I was worried about
a functionally correct kernel (which I still am) and haven't looked
at anything in the peripheral yet.

If I can get individual task timings, I can look at it more.

I'm seeing significantly faster meta data phases, etc, so I'm
interested
to know if this is purely in the build steps.


In my own test setup I'm seeing similar increase in kernel build time.

Comparing the buildstats of kernel builds from before and after the 4.8
I
got the following numbers (these are cpu times consumed by the tasks

TASK  ABSDIFF   RELDIFF  CPUTIME1CPUTIME2
do_package +17.5s   +133.1% 13.1s -> 30.6s
do_deploy  +19.9s  +1449.4%  1.4s -> 21.3s
do_package_write_rpm   +86.8s   +714.7% 12.1s -> 98.9s
do_compile_kernelmodules  +139.4s+35.9%388.2s -> 527.6s
do_compile+201.1s+30.0%670.3s -> 871.4s


ok. So as long as the significant increases aren't in do_kernel_metadata
or do_patch (those two I've measured), we are dealing with something
in the kernel build itself. I can deal with the footprint by inspecting
the repo, but Kbuild is a tougher nut to crack.


I took a look at the kernel build directory size and there was a huge
difference (500M vs. 3.5G). Seeing that significant change I took a look at
the kconfigs and found out that CONFIG_DEBUG_KERNEL and CONFIG_DEBUG_INFO
are enabled, among other things. Looking at the kernel metadata I can see
that these are enabled in ktypes/base/base.cfg.

I guess this is not intended?


There's no mystery, since everything is tracked in git :D It could
be that some commits didn't come forward from 4.4 -> master, which
became the 4.8 meta data branch.

I'll do a bit of forensics and see what might have happened.

Bruce



Thanks,
  Markus



Out of curiosity, is the 4.4 kernel on master showing a significantly
shorter build time ? I'm assuming the before is the 4.4 kernel .. but
I just wanted to be sure, so we can rule out something else that might
be pathologically reacting to the sheer amount of I/O in a kernel build.

Bruce




I haven't tried to analyze what is causing this yet, though.


Thanks,
  Markus







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

Re: [OE-core] Speed regression in the 4.8 kernel?

On Wed, 2016-09-07 at 08:44 -0400, Bruce Ashfield wrote:
> On 2016-09-07 8:33 AM, Markus Lehtonen wrote:
> > On Wed, 2016-09-07 at 07:56 -0400, Bruce Ashfield wrote:
> > > On 2016-09-07 5:27 AM, Richard Purdie wrote:
> > > > Hi Bruce,
> > > > 
> > > > I deliberately spaced out the merges of various things so we could
> > > > get
> > > > performance measurements of the system as it happened.
> > > > Unfortunately
> > > > the 4.8 kernel appears to regress the kernel build time quite
> > > > significantly:
> > > > 
> > > > The raw data:
> > > > 
> > > > ypperf02,master:9428b19a7dd1d265d9f3211004391abe33ea0224,uninative
> > > > -1.3
> > > > -414
> > > > -g9428b19,1:01:32,4:21.16,1:00:32,2:10.86,0:16.19,0:11.21,0:01.20,5
> > > > :34.
> > > > 73,26701616,6445160,1477762,5446116
> > > > ypperf02,master:9428b19a7dd1d265d9f3211004391abe33ea0224,uninative
> > > > -1.3
> > > > -414
> > > > -g9428b19,1:04:14,4:23.82,1:00:40,2:13.70,0:16.18,0:11.28,0:01.22,5
> > > > :45.
> > > > 48,26697516,6445724,1478048,5446490
> > > > ypperf02,master:b9d90ace005597ba35b59adcd8106a1c52e40c1a,uninative
> > > > -1.3
> > > > -438
> > > > -gb9d90ac,1:03:16,7:22.13,1:02:46,2:16.60,0:16.32,0:11.04,0:01.21,5
> > > > :42.
> > > > 11,30852876,10550952,1707255,5912282
> > > > ypperf02,master:f7ca989ddc6d470429b547647d3fbaad83a982d9,uninative
> > > > -1.3
> > > > -446
> > > > -gf7ca989,1:04:42,7:29.05,1:03:04,2:19.71,0:16.21,0:11.05,0:01.24,5
> > > > :52.
> > > > 83,30845748,10551316,1707615,5912122
> > > > 
> > > > which shows the time for "bitbake virtual/kernel -c cleansstate;
> > > > time
> > > > bitbake virtual/kernel" goes from 4:20 to 7:22. The disk footprint
> > > > of
> > > > the build went from 26GB to 30GB. The build with rm_work size went
> > > > from
> > > > 6.4GB to 10.5GB. The overall build time went up 2-3 minutes which
> > > > looks
> > > > like the increased kernel build time. The increased time may well
> > > > be
> > > > from the increased data being generated/processed.
> > > 
> > > Is it the actual compile itself ? What's the trick to actually get
> > > individual task
> > > 
> > > For the disk footprint, I can check the refs in the tree and purge
> > > anything that may be dangling. That being said, I can't do that to
> > > the repository on the git server, so we may need someone that can
> > > issue a git gc directly on the repository.
> > > 
> > > > 
> > > > We can't ship M3 with this much of a performance degradation and
> > > > increased space usage :(. Any idea what changed?
> > > 
> > > Nope. I can only focus on one thing at a time. I was worried about
> > > a functionally correct kernel (which I still am) and haven't looked
> > > at anything in the peripheral yet.
> > > 
> > > If I can get individual task timings, I can look at it more.
> > > 
> > > I'm seeing significantly faster meta data phases, etc, so I'm
> > > interested
> > > to know if this is purely in the build steps.
> > 
> > In my own test setup I'm seeing similar increase in kernel build time.
> > 
> > Comparing the buildstats of kernel builds from before and after the 4.8
> > I
> > got the following numbers (these are cpu times consumed by the tasks
> > 
> > TASK  ABSDIFF   RELDIFF  CPUTIME1CPUTIME2
> > do_package +17.5s   +133.1% 13.1s -> 30.6s
> > do_deploy  +19.9s  +1449.4%  1.4s -> 21.3s
> > do_package_write_rpm   +86.8s   +714.7% 12.1s -> 98.9s
> > do_compile_kernelmodules  +139.4s+35.9%388.2s -> 527.6s
> > do_compile+201.1s+30.0%670.3s -> 871.4s
> 
> ok. So as long as the significant increases aren't in do_kernel_metadata
> or do_patch (those two I've measured), we are dealing with something
> in the kernel build itself. I can deal with the footprint by inspecting
> the repo, but Kbuild is a tougher nut to crack.

I took a look at the kernel build directory size and there was a huge
difference (500M vs. 3.5G). Seeing that significant change I took a look at
the kconfigs and found out that CONFIG_DEBUG_KERNEL and CONFIG_DEBUG_INFO
are enabled, among other things. Looking at the kernel metadata I can see
that these are enabled in ktypes/base/base.cfg.

I guess this is not intended?

Thanks,
  Markus


> Out of curiosity, is the 4.4 kernel on master showing a significantly
> shorter build time ? I'm assuming the before is the 4.4 kernel .. but
> I just wanted to be sure, so we can rule out something else that might
> be pathologically reacting to the sheer amount of I/O in a kernel build.
> 
> Bruce
> 
> > 
> > 
> > I haven't tried to analyze what is causing this yet, though.
> > 
> > 
> > Thanks,
> >   Markus
> > 
> 

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

Re: [OE-core] [OE-Core][PATCH 3/4] libffi: Add patch for MIPS soft float

2016-09-07 Thread Zubair Lutfullah Kakakhel


Hi,

On 09/06/2016 12:35 PM, André Draszik wrote:

On Sa, 2016-09-03 at 15:33 +0100, André Draszik wrote:

It looks like you are a few days to late - a slightly different patch was
applied upstream:

https://github.com/libffi/libffi/pull/272

It'd be good if you could update your OE patch to reference that one
instead, so that we get a real backport (unless it has problems of
course...)


I took the liberty to do just that
http://lists.openembedded.org/pipermail/openembedded-core/2016-September/126
183.html



Thanks!

ZubairLK


Thank you for starting this thread :-)

Cheers,
Andre'






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

Re: [OE-core] Speed regression in the 4.8 kernel?

On Wed, 2016-09-07 at 08:44 -0400, Bruce Ashfield wrote:
> On 2016-09-07 8:33 AM, Markus Lehtonen wrote:
> > On Wed, 2016-09-07 at 07:56 -0400, Bruce Ashfield wrote:
> > > On 2016-09-07 5:27 AM, Richard Purdie wrote:
> > > > Hi Bruce,
> > > > 
> > > > I deliberately spaced out the merges of various things so we could
> > > > get
> > > > performance measurements of the system as it happened.
> > > > Unfortunately
> > > > the 4.8 kernel appears to regress the kernel build time quite
> > > > significantly:
> > > > 
> > > > The raw data:
> > > > 
> > > > ypperf02,master:9428b19a7dd1d265d9f3211004391abe33ea0224,uninative
> > > > -1.3
> > > > -414
> > > > -g9428b19,1:01:32,4:21.16,1:00:32,2:10.86,0:16.19,0:11.21,0:01.20,5
> > > > :34.
> > > > 73,26701616,6445160,1477762,5446116
> > > > ypperf02,master:9428b19a7dd1d265d9f3211004391abe33ea0224,uninative
> > > > -1.3
> > > > -414
> > > > -g9428b19,1:04:14,4:23.82,1:00:40,2:13.70,0:16.18,0:11.28,0:01.22,5
> > > > :45.
> > > > 48,26697516,6445724,1478048,5446490
> > > > ypperf02,master:b9d90ace005597ba35b59adcd8106a1c52e40c1a,uninative
> > > > -1.3
> > > > -438
> > > > -gb9d90ac,1:03:16,7:22.13,1:02:46,2:16.60,0:16.32,0:11.04,0:01.21,5
> > > > :42.
> > > > 11,30852876,10550952,1707255,5912282
> > > > ypperf02,master:f7ca989ddc6d470429b547647d3fbaad83a982d9,uninative
> > > > -1.3
> > > > -446
> > > > -gf7ca989,1:04:42,7:29.05,1:03:04,2:19.71,0:16.21,0:11.05,0:01.24,5
> > > > :52.
> > > > 83,30845748,10551316,1707615,5912122
> > > > 
> > > > which shows the time for "bitbake virtual/kernel -c cleansstate;
> > > > time
> > > > bitbake virtual/kernel" goes from 4:20 to 7:22. The disk footprint
> > > > of
> > > > the build went from 26GB to 30GB. The build with rm_work size went
> > > > from
> > > > 6.4GB to 10.5GB. The overall build time went up 2-3 minutes which
> > > > looks
> > > > like the increased kernel build time. The increased time may well
> > > > be
> > > > from the increased data being generated/processed.
> > > 
> > > Is it the actual compile itself ? What's the trick to actually get
> > > individual task
> > > 
> > > For the disk footprint, I can check the refs in the tree and purge
> > > anything that may be dangling. That being said, I can't do that to
> > > the repository on the git server, so we may need someone that can
> > > issue a git gc directly on the repository.
> > > 
> > > > 
> > > > We can't ship M3 with this much of a performance degradation and
> > > > increased space usage :(. Any idea what changed?
> > > 
> > > Nope. I can only focus on one thing at a time. I was worried about
> > > a functionally correct kernel (which I still am) and haven't looked
> > > at anything in the peripheral yet.
> > > 
> > > If I can get individual task timings, I can look at it more.
> > > 
> > > I'm seeing significantly faster meta data phases, etc, so I'm
> > > interested
> > > to know if this is purely in the build steps.
> > 
> > In my own test setup I'm seeing similar increase in kernel build time.
> > 
> > Comparing the buildstats of kernel builds from before and after the 4.8
> > I
> > got the following numbers (these are cpu times consumed by the tasks
> > 
> > TASK  ABSDIFF   RELDIFF  CPUTIME1CPUTIME2
> > do_package +17.5s   +133.1% 13.1s -> 30.6s
> > do_deploy  +19.9s  +1449.4%  1.4s -> 21.3s
> > do_package_write_rpm   +86.8s   +714.7% 12.1s -> 98.9s
> > do_compile_kernelmodules  +139.4s+35.9%388.2s -> 527.6s
> > do_compile+201.1s+30.0%670.3s -> 871.4s
> 
> ok. So as long as the significant increases aren't in do_kernel_metadata
> or do_patch (those two I've measured), we are dealing with something
> in the kernel build itself. I can deal with the footprint by inspecting
> the repo, but Kbuild is a tougher nut to crack.
> 
> Out of curiosity, is the 4.4 kernel on master showing a significantly
> shorter build time ? I'm assuming the before is the 4.4 kernel .. but
> I just wanted to be sure, so we can rule out something else that might
> be pathologically reacting to the sheer amount of I/O in a kernel build.

I was comparing:
  commit b9d90ace005597ba35b59adcd8106a1c52e40c1a
  Author: Richard Purdie 
  Date:   Wed Aug 31 10:01:46 2016 +0100
  poky: Update to linux-yocto 4.8 for qemu* machines


and the commit right before that so I guess all other sources of regression
are ruled out.


Thanks,
  Markus




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

Re: [OE-core] Speed regression in the 4.8 kernel?


On 2016-09-07 8:33 AM, Markus Lehtonen wrote:

On Wed, 2016-09-07 at 07:56 -0400, Bruce Ashfield wrote:

On 2016-09-07 5:27 AM, Richard Purdie wrote:

Hi Bruce,

I deliberately spaced out the merges of various things so we could get
performance measurements of the system as it happened. Unfortunately
the 4.8 kernel appears to regress the kernel build time quite
significantly:

The raw data:

ypperf02,master:9428b19a7dd1d265d9f3211004391abe33ea0224,uninative-1.3
-414
-g9428b19,1:01:32,4:21.16,1:00:32,2:10.86,0:16.19,0:11.21,0:01.20,5:34.
73,26701616,6445160,1477762,5446116
ypperf02,master:9428b19a7dd1d265d9f3211004391abe33ea0224,uninative-1.3
-414
-g9428b19,1:04:14,4:23.82,1:00:40,2:13.70,0:16.18,0:11.28,0:01.22,5:45.
48,26697516,6445724,1478048,5446490
ypperf02,master:b9d90ace005597ba35b59adcd8106a1c52e40c1a,uninative-1.3
-438
-gb9d90ac,1:03:16,7:22.13,1:02:46,2:16.60,0:16.32,0:11.04,0:01.21,5:42.
11,30852876,10550952,1707255,5912282
ypperf02,master:f7ca989ddc6d470429b547647d3fbaad83a982d9,uninative-1.3
-446
-gf7ca989,1:04:42,7:29.05,1:03:04,2:19.71,0:16.21,0:11.05,0:01.24,5:52.
83,30845748,10551316,1707615,5912122

which shows the time for "bitbake virtual/kernel -c cleansstate; time
bitbake virtual/kernel" goes from 4:20 to 7:22. The disk footprint of
the build went from 26GB to 30GB. The build with rm_work size went from
6.4GB to 10.5GB. The overall build time went up 2-3 minutes which looks
like the increased kernel build time. The increased time may well be
from the increased data being generated/processed.


Is it the actual compile itself ? What's the trick to actually get
individual task

For the disk footprint, I can check the refs in the tree and purge
anything that may be dangling. That being said, I can't do that to
the repository on the git server, so we may need someone that can
issue a git gc directly on the repository.



We can't ship M3 with this much of a performance degradation and
increased space usage :(. Any idea what changed?


Nope. I can only focus on one thing at a time. I was worried about
a functionally correct kernel (which I still am) and haven't looked
at anything in the peripheral yet.

If I can get individual task timings, I can look at it more.

I'm seeing significantly faster meta data phases, etc, so I'm interested
to know if this is purely in the build steps.


In my own test setup I'm seeing similar increase in kernel build time.

Comparing the buildstats of kernel builds from before and after the 4.8 I
got the following numbers (these are cpu times consumed by the tasks

TASK  ABSDIFF   RELDIFF  CPUTIME1CPUTIME2
do_package +17.5s   +133.1% 13.1s -> 30.6s
do_deploy  +19.9s  +1449.4%  1.4s -> 21.3s
do_package_write_rpm   +86.8s   +714.7% 12.1s -> 98.9s
do_compile_kernelmodules  +139.4s+35.9%388.2s -> 527.6s
do_compile+201.1s+30.0%670.3s -> 871.4s


ok. So as long as the significant increases aren't in do_kernel_metadata
or do_patch (those two I've measured), we are dealing with something
in the kernel build itself. I can deal with the footprint by inspecting
the repo, but Kbuild is a tougher nut to crack.

Out of curiosity, is the 4.4 kernel on master showing a significantly
shorter build time ? I'm assuming the before is the 4.4 kernel .. but
I just wanted to be sure, so we can rule out something else that might
be pathologically reacting to the sheer amount of I/O in a kernel build.

Bruce




I haven't tried to analyze what is causing this yet, though.


Thanks,
  Markus



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

Re: [OE-core] Speed regression in the 4.8 kernel?

On Wed, 2016-09-07 at 07:56 -0400, Bruce Ashfield wrote:
> On 2016-09-07 5:27 AM, Richard Purdie wrote:
> > Hi Bruce,
> > 
> > I deliberately spaced out the merges of various things so we could get
> > performance measurements of the system as it happened. Unfortunately
> > the 4.8 kernel appears to regress the kernel build time quite
> > significantly:
> > 
> > The raw data:
> > 
> > ypperf02,master:9428b19a7dd1d265d9f3211004391abe33ea0224,uninative-1.3
> > -414
> > -g9428b19,1:01:32,4:21.16,1:00:32,2:10.86,0:16.19,0:11.21,0:01.20,5:34.
> > 73,26701616,6445160,1477762,5446116
> > ypperf02,master:9428b19a7dd1d265d9f3211004391abe33ea0224,uninative-1.3
> > -414
> > -g9428b19,1:04:14,4:23.82,1:00:40,2:13.70,0:16.18,0:11.28,0:01.22,5:45.
> > 48,26697516,6445724,1478048,5446490
> > ypperf02,master:b9d90ace005597ba35b59adcd8106a1c52e40c1a,uninative-1.3
> > -438
> > -gb9d90ac,1:03:16,7:22.13,1:02:46,2:16.60,0:16.32,0:11.04,0:01.21,5:42.
> > 11,30852876,10550952,1707255,5912282
> > ypperf02,master:f7ca989ddc6d470429b547647d3fbaad83a982d9,uninative-1.3
> > -446
> > -gf7ca989,1:04:42,7:29.05,1:03:04,2:19.71,0:16.21,0:11.05,0:01.24,5:52.
> > 83,30845748,10551316,1707615,5912122
> > 
> > which shows the time for "bitbake virtual/kernel -c cleansstate; time
> > bitbake virtual/kernel" goes from 4:20 to 7:22. The disk footprint of
> > the build went from 26GB to 30GB. The build with rm_work size went from
> > 6.4GB to 10.5GB. The overall build time went up 2-3 minutes which looks
> > like the increased kernel build time. The increased time may well be
> > from the increased data being generated/processed.
> 
> Is it the actual compile itself ? What's the trick to actually get
> individual task
> 
> For the disk footprint, I can check the refs in the tree and purge
> anything that may be dangling. That being said, I can't do that to
> the repository on the git server, so we may need someone that can
> issue a git gc directly on the repository.
> 
> > 
> > We can't ship M3 with this much of a performance degradation and
> > increased space usage :(. Any idea what changed?
> 
> Nope. I can only focus on one thing at a time. I was worried about
> a functionally correct kernel (which I still am) and haven't looked
> at anything in the peripheral yet.
> 
> If I can get individual task timings, I can look at it more.
> 
> I'm seeing significantly faster meta data phases, etc, so I'm interested
> to know if this is purely in the build steps.

In my own test setup I'm seeing similar increase in kernel build time.

Comparing the buildstats of kernel builds from before and after the 4.8 I
got the following numbers (these are cpu times consumed by the tasks):

TASK  ABSDIFF   RELDIFF  CPUTIME1CPUTIME2
do_package +17.5s   +133.1% 13.1s -> 30.6s
do_deploy  +19.9s  +1449.4%  1.4s -> 21.3s
do_package_write_rpm   +86.8s   +714.7% 12.1s -> 98.9s
do_compile_kernelmodules  +139.4s+35.9%388.2s -> 527.6s
do_compile+201.1s+30.0%670.3s -> 871.4s


I haven't tried to analyze what is causing this yet, though.


Thanks,
  Markus

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

Re: [OE-core] [PATCH 2/3] systemd.bbclass: add support to manage user services

2016-09-07 Thread Pau Espin Pedrol

2016-09-07 11:22 GMT+02:00 Chen Qi :

> Add new variable SYSTEMD_USER_SERVICE and SYSTEM_USER_AUTO_ENABLE
> to manage user services. Their usage is like SYSTEMD_SERVICE and
> SYSTEMD_AUTO_ENABLE.
>
> [YOCTO #7800]
>
> Signed-off-by: Chen Qi 
> ---
>  meta/classes/systemd.bbclass | 17 +
>  1 file changed, 13 insertions(+), 4 deletions(-)
>
> diff --git a/meta/classes/systemd.bbclass b/meta/classes/systemd.bbclass
> index db7873f..78cec97 100644
> --- a/meta/classes/systemd.bbclass
> +++ b/meta/classes/systemd.bbclass
> @@ -7,6 +7,7 @@ SYSTEMD_PACKAGES_class-nativesdk ?= ""
>
>  # Whether to enable or disable the services on installation.
>  SYSTEMD_AUTO_ENABLE ??= "enable"
> +SYSTEMD_USER_AUTO_ENABLE ??= "enable"
>
>  # This class will be included in any recipe that supports systemd init
> scripts,
>  # even if systemd is not in DISTRO_FEATURES.  As such don't make any
> changes
> @@ -30,10 +31,14 @@ fi
>
>  if type systemctl >/dev/null 2>/dev/null; then
> systemctl $OPTS ${SYSTEMD_AUTO_ENABLE} ${SYSTEMD_SERVICE}
> +   systemctl $OPTS --global ${SYSTEMD_USER_AUTO_ENABLE}
> ${SYSTEMD_USER_SERVICE}
>

I'm not sure having these 2 systemctl being executed together everytime is
a good idea. What if a recipe has a user service and no system service? We
are calling the first one with an empty system service? Or we are may be
enabling a systemd system service which should not be enabled according to
the recipe? I have the feeling this kind of cases are not being catch in
here and other pkg scripts in this commit.

It is far from perfect, but in case you didn't, you may want to have a look
at my initial/previous commit to try to fix the issue:
https://www.mail-archive.com/openembedded-devel@lists.openembedded.org/msg42187.html


>
> if [ -z "$D" -a "${SYSTEMD_AUTO_ENABLE}" = "enable" ]; then
> systemctl restart ${SYSTEMD_SERVICE}
> fi
> +   if [ -z "$D" -a "${SYSTEMD_USER_AUTO_ENABLE}" = "enable" ]; then
> +   systemctl --global restart ${SYSTEMD_USER_SERVICE}
> +   fi
>  fi
>  }
>
> @@ -47,9 +52,11 @@ fi
>  if type systemctl >/dev/null 2>/dev/null; then
> if [ -z "$D" ]; then
> systemctl stop ${SYSTEMD_SERVICE}
> +   systemctl --global stop ${SYSTEMD_USER_SERVICE}
>

I think this is not gonna work, you cannot call --global with stop afair.
I'm not sure which is the good solution for this though, but you should
ideally go through all systemd user sessions and call "systemctl --user
stop". No idea if that's actually easily feasible.


> fi
>
> systemctl $OPTS disable ${SYSTEMD_SERVICE}
> +   systemctl $OPTS --global disable ${SYSTEMD_USER_SERVICE}
>  fi
>  }
>
> @@ -139,12 +146,14 @@ python systemd_populate_packages() {
>  def systemd_check_services():
>  searchpaths = [oe.path.join(d.getVar("sysconfdir", True),
> "systemd", "system"),]
>  searchpaths.append(d.getVar("systemd_system_unitdir", True))
> +searchpaths.append(oe.path.join(d.getVar("sysconfdir", True),
> "systemd", "user"))
> +searchpaths.append(d.getVar("systemd_user_unitdir", True))
>  systemd_packages = d.getVar('SYSTEMD_PACKAGES', True)
>
>  keys = 'Also'
>  # scan for all in SYSTEMD_SERVICE[]
>  for pkg_systemd in systemd_packages.split():
> -for service in get_package_var(d, 'SYSTEMD_SERVICE',
> pkg_systemd).split():
> +for service in (get_package_var(d, 'SYSTEMD_SERVICE',
> pkg_systemd) + get_package_var(d, 'SYSTEMD_USER_SERVICE',
> pkg_systemd)).split():
>  path_found = ''
>
>  # Deal with adding, for example, 'ifplugd@eth0.service'
> from
> @@ -165,14 +174,14 @@ python systemd_populate_packages() {
>  if path_found != '':
>  systemd_add_files_and_parse(pkg_systemd, path_found,
> service, keys)
>  else:
> -raise bb.build.FuncFailed("SYSTEMD_SERVICE_%s value
> %s does not exist" % \
> -(pkg_systemd, service))
> +raise bb.build.FuncFailed("SYSTEMD_SERVICE_%s or
> SYSTEMD_USER_SERVICE_%s value %s does not exist" % \
> +(pkg_systemd, pkg_systemd, service))
>
>  # Run all modifications once when creating package
>  if os.path.exists(d.getVar("D", True)):
>  for pkg in d.getVar('SYSTEMD_PACKAGES', True).split():
>  systemd_check_package(pkg)
> -if d.getVar('SYSTEMD_SERVICE_' + pkg, True):
> +if d.getVar('SYSTEMD_SERVICE_' + pkg, True) or
> d.getVar('SYSTEMD_USER_SERVICE_' + pkg, True):
>  systemd_generate_package_scripts(pkg)
>  systemd_check_services()
>  }
> --
> 1.9.1
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
>

Re: [OE-core] Speed regression in the 4.8 kernel?

On 2016-09-07 5:27 AM, Richard Purdie wrote:

Hi Bruce,

I deliberately spaced out the merges of various things so we could get
performance measurements of the system as it happened. Unfortunately
the 4.8 kernel appears to regress the kernel build time quite
significantly:

The raw data:

ypperf02,master:9428b19a7dd1d265d9f3211004391abe33ea0224,uninative-1.3-414-g9428b19,1:01:32,4:21.16,1:00:32,2:10.86,0:16.19,0:11.21,0:01.20,5:34.73,26701616,6445160,1477762,5446116
ypperf02,master:9428b19a7dd1d265d9f3211004391abe33ea0224,uninative-1.3-414-g9428b19,1:04:14,4:23.82,1:00:40,2:13.70,0:16.18,0:11.28,0:01.22,5:45.48,26697516,6445724,1478048,5446490
ypperf02,master:b9d90ace005597ba35b59adcd8106a1c52e40c1a,uninative-1.3-438-gb9d90ac,1:03:16,7:22.13,1:02:46,2:16.60,0:16.32,0:11.04,0:01.21,5:42.11,30852876,10550952,1707255,5912282
ypperf02,master:f7ca989ddc6d470429b547647d3fbaad83a982d9,uninative-1.3-446-gf7ca989,1:04:42,7:29.05,1:03:04,2:19.71,0:16.21,0:11.05,0:01.24,5:52.83,30845748,10551316,1707615,5912122

which shows the time for "bitbake virtual/kernel -c cleansstate; time
bitbake virtual/kernel" goes from 4:20 to 7:22. The disk footprint of
the build went from 26GB to 30GB. The build with rm_work size went from
6.4GB to 10.5GB. The overall build time went up 2-3 minutes which looks
like the increased kernel build time. The increased time may well be
from the increased data being generated/processed.

Is it the actual compile itself ? What's the trick to actually get
individual task

For the disk footprint, I can check the refs in the tree and purge
anything that may be dangling. That being said, I can't do that to
the repository on the git server, so we may need someone that can
issue a git gc directly on the repository.

We can't ship M3 with this much of a performance degradation and
increased space usage :(. Any idea what changed?

Nope. I can only focus on one thing at a time. I was worried about
a functionally correct kernel (which I still am) and haven't looked
at anything in the peripheral yet.

If I can get individual task timings, I can look at it more.

I'm seeing significantly faster meta data phases, etc, so I'm interested
to know if this is purely in the build steps.

Cheers,

Bruce

Cheers,

Richard

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

[OE-core] [PATCHv2] file: build with c std as c99

2016-09-07 Thread Jack Mitchell

From: Jack Mitchell 

when using a toolchain not shipped by OE core such as linaro we
can't be sure what the std will be set to. Set to compile as c99
which is the lowest version supported.

Signed-off-by: Jack Mitchell 
---
 meta/recipes-devtools/file/file_5.28.bb | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-devtools/file/file_5.28.bb 
b/meta/recipes-devtools/file/file_5.28.bb
index 516c8c5..e64a89c 100644
--- a/meta/recipes-devtools/file/file_5.28.bb
+++ b/meta/recipes-devtools/file/file_5.28.bb
@@ -27,6 +27,8 @@ inherit autotools
 EXTRA_OEMAKE_append_class-target = "-e 
FILE_COMPILE=${STAGING_BINDIR_NATIVE}/file-native/file"
 EXTRA_OEMAKE_append_class-nativesdk = "-e 
FILE_COMPILE=${STAGING_BINDIR_NATIVE}/file-native/file"
 
+CFLAGS_append = " -std=c99"
+
 FILES_${PN} += "${datadir}/misc/*.mgc"
 
 do_install_append_class-native() {
-- 
2.9.3

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

Re: [OE-core] [PATCH 3/3] pulseaudio: fix to manage user services corretly

2016-09-07 Thread Pau Espin Pedrol

Pau Espin Pedrol

2016-09-07 11:22 GMT+02:00 Chen Qi :

> Make use of the new SYSTEMD_USER_SERVICE variable added in systemd.bbclass
> to manage user services in pulseaudio-server package.
>
> Signed-off-by: Chen Qi 
> ---
>  meta/recipes-multimedia/pulseaudio/pulseaudio.inc | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
> b/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
> index 6ed79ef..f3754d7 100644
> --- a/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
> +++ b/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
> @@ -124,8 +124,8 @@ FILES_${PN}-conf = "${sysconfdir}"
>  FILES_${PN}-bin += "${sysconfdir}/default/volatiles/volatiles.04_pulse"
>  FILES_${PN}-server = "${bindir}/pulseaudio ${bindir}/start-*
> ${sysconfdir} ${bindir}/pactl */udev/rules.d/*.rules
> */*/udev/rules.d/*.rules ${systemd_user_unitdir}/*"
>
> -#SYSTEMD_PACKAGES = "${PN}-server"
> -SYSTEMD_SERVICE_${PN}-server = "pulseaudio.service"
> +SYSTEMD_PACKAGES = "${PN}-server"
> +SYSTEMD_USER_SERVICE_${PN}-server = "pulseaudio.service
> pulseaudio.socket"
>
> I think specifying "pulseaudio.socket" for SYSTEMD_USER_SERVICE_${PN}-server
should be enough, systemd.bbclass is going to add the .service file afair.


>  FILES_${PN}-misc = "${bindir}/* ${libdir}/pulseaudio/libpulsedsp.so"
>
> --
> 1.9.1
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/9] lib/oe/patch: handle non-UTF8 encoding when reading patches

2016-09-07 Thread Enrico Scholz

Paul Eggleton  writes:

>> I would read the file as a binary ('rb' instead of 'r') and make the
>> GitApplyTree.* strings a 'bytes' type.
>
> The code is not just passing the data through, it is actually processing
> it.  If we did what you propose wouldn't it make that processing more
> difficult?

Should not be very much... You have to write b'foo' instead of 'foo' at
some places, but things like 'file.readline()' or 'line.startswith()'
are still working with 'bytes' resp. binary files.

Only when trying to print them on stdout, things can get nasty.  But
this should not be needed for patches.

Enrico
-- 
SIGMA Chemnitz GmbH   Registergericht:   Amtsgericht Chemnitz HRB 1750
Am Erlenwald 13   Geschaeftsfuehrer: Grit Freitag, Frank Pyritz
09128 Chemnitz
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] cmake.bbclass: avoid treating imports as system includes

2016-09-07 Thread Jack Mitchell


On 06/09/16 22:41, Andreas Müller wrote:

CMake sets all imported headers as system headers. This causes trouble for c++
projects [1].

Thanks to Jack Mitchell for pointing to the setting [2]. Build tested upon
meta-qt5-extra-world which had lots of fallout before.

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70129
[2] 
http://lists.openembedded.org/pipermail/openembedded-core/2016-September/126067.html

Signed-off-by: Andreas Müller 
---
 meta/classes/cmake.bbclass | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/classes/cmake.bbclass b/meta/classes/cmake.bbclass
index 5203d8a..7091f8b 100644
--- a/meta/classes/cmake.bbclass
+++ b/meta/classes/cmake.bbclass
@@ -120,6 +120,7 @@ cmake_do_configure() {
  -DCMAKE_INSTALL_SO_NO_EXE=0 \
  -DCMAKE_TOOLCHAIN_FILE=${WORKDIR}/toolchain.cmake \
  -DCMAKE_VERBOSE_MAKEFILE=1 \
+ -DCMAKE_NO_SYSTEM_FROM_IMPORTED=1 \
  ${EXTRA_OECMAKE} \
  -Wno-dev
 }



This is cleaner than my implementation.

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

Re: [OE-core] [PATCH 0/3] systemd: add support to manage user units

It's probably worth updating the documentation too... this is a usefull 
feature and it deserves the exposure



Regards

Jeremy Rosen


On 07/09/2016 11:22, Chen Qi wrote:

The following changes since commit 55bb6816aca39bfa25d4f7e2158a57a5f0ac1cca:

   oeqa.buildperf: correct globalres time format (2016-09-06 10:24:00 +0100)

are available in the git repository at:

   git://git.openembedded.org/openembedded-core-contrib 
ChenQi/systemd-user-units
   
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=ChenQi/systemd-user-units

Chen Qi (3):
   systemd-systemctl: add option to manage user services
   systemd.bbclass: add support to manage user services
   pulseaudio: fix to manage user services corretly

  meta/classes/systemd.bbclass   | 17 ++--
  .../systemd/systemd-systemctl/systemctl| 45 ++
  meta/recipes-multimedia/pulseaudio/pulseaudio.inc  |  4 +-
  3 files changed, 43 insertions(+), 23 deletions(-)



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

[OE-core] Speed regression in the 4.8 kernel?

2016-09-07 Thread Richard Purdie

Hi Bruce,

I deliberately spaced out the merges of various things so we could get
performance measurements of the system as it happened. Unfortunately
the 4.8 kernel appears to regress the kernel build time quite
significantly:

The raw data:

ypperf02,master:9428b19a7dd1d265d9f3211004391abe33ea0224,uninative-1.3-414-g9428b19,1:01:32,4:21.16,1:00:32,2:10.86,0:16.19,0:11.21,0:01.20,5:34.73,26701616,6445160,1477762,5446116
ypperf02,master:9428b19a7dd1d265d9f3211004391abe33ea0224,uninative-1.3-414-g9428b19,1:04:14,4:23.82,1:00:40,2:13.70,0:16.18,0:11.28,0:01.22,5:45.48,26697516,6445724,1478048,5446490
ypperf02,master:b9d90ace005597ba35b59adcd8106a1c52e40c1a,uninative-1.3-438-gb9d90ac,1:03:16,7:22.13,1:02:46,2:16.60,0:16.32,0:11.04,0:01.21,5:42.11,30852876,10550952,1707255,5912282
ypperf02,master:f7ca989ddc6d470429b547647d3fbaad83a982d9,uninative-1.3-446-gf7ca989,1:04:42,7:29.05,1:03:04,2:19.71,0:16.21,0:11.05,0:01.24,5:52.83,30845748,10551316,1707615,5912122

which shows the time for "bitbake virtual/kernel -c cleansstate; time
bitbake virtual/kernel" goes from 4:20 to 7:22. The disk footprint of
the build went from 26GB to 30GB. The build with rm_work size went from
6.4GB to 10.5GB. The overall build time went up 2-3 minutes which looks
like the increased kernel build time. The increased time may well be
from the increased data being generated/processed.

We can't ship M3 with this much of a performance degradation and
increased space usage :(. Any idea what changed?

Cheers,

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

[OE-core] [PATCH 0/3] systemd: add support to manage user units

The following changes since commit 55bb6816aca39bfa25d4f7e2158a57a5f0ac1cca:

  oeqa.buildperf: correct globalres time format (2016-09-06 10:24:00 +0100)

are available in the git repository at:

  git://git.openembedded.org/openembedded-core-contrib ChenQi/systemd-user-units
  
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=ChenQi/systemd-user-units

Chen Qi (3):
  systemd-systemctl: add option to manage user services
  systemd.bbclass: add support to manage user services
  pulseaudio: fix to manage user services corretly

 meta/classes/systemd.bbclass   | 17 ++--
 .../systemd/systemd-systemctl/systemctl| 45 ++
 meta/recipes-multimedia/pulseaudio/pulseaudio.inc  |  4 +-
 3 files changed, 43 insertions(+), 23 deletions(-)

-- 
1.9.1

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

[OE-core] [PATCH 1/3] systemd-systemctl: add option to manage user services

Add '--global' option to our own systemctl script to manage user services.

[YOCTO #7800]

Signed-off-by: Chen Qi 
---
 .../systemd/systemd-systemctl/systemctl| 45 ++
 1 file changed, 28 insertions(+), 17 deletions(-)

diff --git a/meta/recipes-core/systemd/systemd-systemctl/systemctl 
b/meta/recipes-core/systemd/systemd-systemctl/systemctl
index efad14c..17a7277 100755
--- a/meta/recipes-core/systemd/systemd-systemctl/systemctl
+++ b/meta/recipes-core/systemd/systemd-systemctl/systemctl
@@ -2,7 +2,8 @@
 echo "Started $0 $*"
 
 ROOT=
-
+USER_SERVICE=no
+location=system
 # parse command line params
 action=
 while [ $# != 0 ]; do
@@ -46,6 +47,11 @@ while [ $# != 0 ]; do
cmd_args="0"
shift
;;
+   --global)
+   USER_SERVICE=yes
+   cmd_args="0"
+   shift
+   ;;
*)
if [ "$cmd_args" = "1" ]; then
services="$services $opt" 
@@ -57,8 +63,13 @@ while [ $# != 0 ]; do
;;
esac
 done
+
+if [ "$USER_SERVICE" = "yes" ]; then
+   location=user
+fi
+
 if [ "$action" = "preset" -a "$service_file" = "" ]; then
-   services=$(for f in `find $ROOT/etc/systemd/system 
$ROOT/lib/systemd/system $ROOT/usr/lib/systemd/system -type f 2>1`; do basename 
$f; done)
+   services=$(for f in `find $ROOT/etc/systemd/$location 
$ROOT/lib/systemd/$location $ROOT/usr/lib/systemd/$location -type f 2>1`; do 
basename $f; done)
services="$services $opt"
presetall=1
 fi
@@ -68,10 +79,10 @@ for service in $services; do
action="preset"
fi
if [ "$action" = "mask" ]; then
-   if [ ! -d $ROOT/etc/systemd/system/ ]; then
-   mkdir -p $ROOT/etc/systemd/system/
+   if [ ! -d $ROOT/etc/systemd/$location/ ]; then
+   mkdir -p $ROOT/etc/systemd/$location/
fi
-   cmd="ln -s /dev/null $ROOT/etc/systemd/system/$service"
+   cmd="ln -s /dev/null $ROOT/etc/systemd/$location/$service"
echo "$cmd"
$cmd
exit 0
@@ -92,9 +103,9 @@ for service in $services; do
fi
 
# find service file
-   for p in $ROOT/etc/systemd/system \
-$ROOT/lib/systemd/system \
-$ROOT/usr/lib/systemd/system; do
+   for p in $ROOT/etc/systemd/$location \
+$ROOT/lib/systemd/$location \
+$ROOT/usr/lib/systemd/$location; do
if [ -e $p/$service_base_file ]; then
service_file=$p/$service_base_file
service_file=${service_file##$ROOT}
@@ -151,18 +162,18 @@ for service in $services; do
enable_service=$(echo $service 
| sed "s/@/@$(echo $default_instance | sed 's/\\//g')/")
fi
fi
-   mkdir -p $ROOT/etc/systemd/system/$r.$suffix
-   ln -s $service_file 
$ROOT/etc/systemd/system/$r.$suffix/$enable_service
+   mkdir -p $ROOT/etc/systemd/$location/$r.$suffix
+   ln -s $service_file 
$ROOT/etc/systemd/$location/$r.$suffix/$enable_service
echo "Enabled $enable_service for $r."
else
if [ "$service_template" = true -a 
"$instance_specified" = false ]; then
-   
disable_service="$ROOT/etc/systemd/system/$r.$suffix/`echo $service | sed 
's/@/@*/'`"
+   
disable_service="$ROOT/etc/systemd/$location/$r.$suffix/`echo $service | sed 
's/@/@*/'`"
else
-   
disable_service="$ROOT/etc/systemd/system/$r.$suffix/$service"
+   
disable_service="$ROOT/etc/systemd/$location/$r.$suffix/$service"
fi
rm -f $disable_service
-   [ -d $ROOT/etc/systemd/system/$r.$suffix ] && 
rmdir --ignore-fail-on-non-empty -p $ROOT/etc/systemd/system/$r.$suffix
-   echo "Disabled 
${disable_service##$ROOT/etc/systemd/system/$r.$suffix/} for $r."
+   [ -d $ROOT/etc/systemd/$location/$r.$suffix ] 
&& rmdir --ignore-fail-on-non-empty -p $ROOT/etc/systemd/$location/$r.$suffix
+   echo "Disabled 
${disable_service##$ROOT/etc/systemd/$location/$r.$suffix/} for $r."
fi
done
done
@@ -174,11 +185,11 @@ for service in $services; do
 
for r in $alias; do

[OE-core] [PATCH 3/3] pulseaudio: fix to manage user services corretly

Make use of the new SYSTEMD_USER_SERVICE variable added in systemd.bbclass
to manage user services in pulseaudio-server package.

Signed-off-by: Chen Qi 
---
 meta/recipes-multimedia/pulseaudio/pulseaudio.inc | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-multimedia/pulseaudio/pulseaudio.inc 
b/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
index 6ed79ef..f3754d7 100644
--- a/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
+++ b/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
@@ -124,8 +124,8 @@ FILES_${PN}-conf = "${sysconfdir}"
 FILES_${PN}-bin += "${sysconfdir}/default/volatiles/volatiles.04_pulse"
 FILES_${PN}-server = "${bindir}/pulseaudio ${bindir}/start-* ${sysconfdir} 
${bindir}/pactl */udev/rules.d/*.rules */*/udev/rules.d/*.rules 
${systemd_user_unitdir}/*"
 
-#SYSTEMD_PACKAGES = "${PN}-server"
-SYSTEMD_SERVICE_${PN}-server = "pulseaudio.service"
+SYSTEMD_PACKAGES = "${PN}-server"
+SYSTEMD_USER_SERVICE_${PN}-server = "pulseaudio.service pulseaudio.socket"
 
 FILES_${PN}-misc = "${bindir}/* ${libdir}/pulseaudio/libpulsedsp.so"
 
-- 
1.9.1

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

[OE-core] [PATCH 2/3] systemd.bbclass: add support to manage user services

Add new variable SYSTEMD_USER_SERVICE and SYSTEM_USER_AUTO_ENABLE
to manage user services. Their usage is like SYSTEMD_SERVICE and
SYSTEMD_AUTO_ENABLE.

[YOCTO #7800]

Signed-off-by: Chen Qi 
---
 meta/classes/systemd.bbclass | 17 +
 1 file changed, 13 insertions(+), 4 deletions(-)

diff --git a/meta/classes/systemd.bbclass b/meta/classes/systemd.bbclass
index db7873f..78cec97 100644
--- a/meta/classes/systemd.bbclass
+++ b/meta/classes/systemd.bbclass
@@ -7,6 +7,7 @@ SYSTEMD_PACKAGES_class-nativesdk ?= ""
 
 # Whether to enable or disable the services on installation.
 SYSTEMD_AUTO_ENABLE ??= "enable"
+SYSTEMD_USER_AUTO_ENABLE ??= "enable"
 
 # This class will be included in any recipe that supports systemd init scripts,
 # even if systemd is not in DISTRO_FEATURES.  As such don't make any changes
@@ -30,10 +31,14 @@ fi
 
 if type systemctl >/dev/null 2>/dev/null; then
systemctl $OPTS ${SYSTEMD_AUTO_ENABLE} ${SYSTEMD_SERVICE}
+   systemctl $OPTS --global ${SYSTEMD_USER_AUTO_ENABLE} 
${SYSTEMD_USER_SERVICE}
 
if [ -z "$D" -a "${SYSTEMD_AUTO_ENABLE}" = "enable" ]; then
systemctl restart ${SYSTEMD_SERVICE}
fi
+   if [ -z "$D" -a "${SYSTEMD_USER_AUTO_ENABLE}" = "enable" ]; then
+   systemctl --global restart ${SYSTEMD_USER_SERVICE}
+   fi
 fi
 }
 
@@ -47,9 +52,11 @@ fi
 if type systemctl >/dev/null 2>/dev/null; then
if [ -z "$D" ]; then
systemctl stop ${SYSTEMD_SERVICE}
+   systemctl --global stop ${SYSTEMD_USER_SERVICE}
fi
 
systemctl $OPTS disable ${SYSTEMD_SERVICE}
+   systemctl $OPTS --global disable ${SYSTEMD_USER_SERVICE}
 fi
 }
 
@@ -139,12 +146,14 @@ python systemd_populate_packages() {
 def systemd_check_services():
 searchpaths = [oe.path.join(d.getVar("sysconfdir", True), "systemd", 
"system"),]
 searchpaths.append(d.getVar("systemd_system_unitdir", True))
+searchpaths.append(oe.path.join(d.getVar("sysconfdir", True), 
"systemd", "user"))
+searchpaths.append(d.getVar("systemd_user_unitdir", True))
 systemd_packages = d.getVar('SYSTEMD_PACKAGES', True)
 
 keys = 'Also'
 # scan for all in SYSTEMD_SERVICE[]
 for pkg_systemd in systemd_packages.split():
-for service in get_package_var(d, 'SYSTEMD_SERVICE', 
pkg_systemd).split():
+for service in (get_package_var(d, 'SYSTEMD_SERVICE', pkg_systemd) 
+ get_package_var(d, 'SYSTEMD_USER_SERVICE', pkg_systemd)).split():
 path_found = ''
 
 # Deal with adding, for example, 'ifplugd@eth0.service' from
@@ -165,14 +174,14 @@ python systemd_populate_packages() {
 if path_found != '':
 systemd_add_files_and_parse(pkg_systemd, path_found, 
service, keys)
 else:
-raise bb.build.FuncFailed("SYSTEMD_SERVICE_%s value %s 
does not exist" % \
-(pkg_systemd, service))
+raise bb.build.FuncFailed("SYSTEMD_SERVICE_%s or 
SYSTEMD_USER_SERVICE_%s value %s does not exist" % \
+(pkg_systemd, pkg_systemd, service))
 
 # Run all modifications once when creating package
 if os.path.exists(d.getVar("D", True)):
 for pkg in d.getVar('SYSTEMD_PACKAGES', True).split():
 systemd_check_package(pkg)
-if d.getVar('SYSTEMD_SERVICE_' + pkg, True):
+if d.getVar('SYSTEMD_SERVICE_' + pkg, True) or 
d.getVar('SYSTEMD_USER_SERVICE_' + pkg, True):
 systemd_generate_package_scripts(pkg)
 systemd_check_services()
 }
-- 
1.9.1

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

[OE-core] [PATCH v2 8/8] libpcre: explicitely specify CCLD_FOR_BUILD for this recipe

libpcre uses CCLD_FOR_BUILD as the name of the host command to use for
linking. This is not a standard autotools symbol but particular to this
recipe. We need to set it explicitely

Signed-off-by: Jérémy Rosen 
---
 meta/recipes-support/libpcre/libpcre_8.39.bb | 2 ++
 1 file changed, 2 insertions(+), 0 deletions(-)

diff --git a/meta/recipes-support/libpcre/libpcre_8.39.bb 
b/meta/recipes-support/libpcre/libpcre_8.39.bb
index 129076a..2d4668b 100644
--- a/meta/recipes-support/libpcre/libpcre_8.39.bb
+++ b/meta/recipes-support/libpcre/libpcre_8.39.bb
@@ -48,6 +48,8 @@ BUILD_CFLAGS =+ "-DLINK_SIZE=2 -I${B}"
 CFLAGS += "-D_REENTRANT"
 CXXFLAGS_append_powerpc = " -lstdc++"
 
+export CCLD_FOR_BUILD ="${BUILD_CCLD}"
+
 PACKAGES =+ "libpcrecpp libpcreposix pcregrep pcregrep-doc pcretest 
pcretest-doc"
 
 SUMMARY_libpcrecpp = "${SUMMARY} - C++ wrapper functions"
-- 
git-series 0.8.9
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v2 6/8] glibc: remove hard-coded reference to gcc -E

Signed-off-by: Jérémy Rosen 
---
 
meta/recipes-core/glibc/glibc/0001-locale-fix-hard-coded-reference-to-gcc-E.patch
 | 39 +++
 meta/recipes-core/glibc/glibc_2.24.bb  
   |  3 ++-
 2 files changed, 41 insertions(+), 1 deletion(-)
 create mode 100644 
meta/recipes-core/glibc/glibc/0001-locale-fix-hard-coded-reference-to-gcc-E.patch

diff --git 
a/meta/recipes-core/glibc/glibc/0001-locale-fix-hard-coded-reference-to-gcc-E.patch
 
b/meta/recipes-core/glibc/glibc/0001-locale-fix-hard-coded-reference-to-gcc-E.patch
new file mode 100644
index 000..d5fce73
--- /dev/null
+++ 
b/meta/recipes-core/glibc/glibc/0001-locale-fix-hard-coded-reference-to-gcc-E.patch
@@ -0,0 +1,39 @@
+From 2c0ab83eb54c0e0fccbf261726dc03803b236079 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?J=C3=A9r=C3=A9my=20Rosen?= 
+Date: Mon, 22 Aug 2016 16:09:25 +0200
+Subject: [PATCH] locale: fix hard-coded reference to gcc -E
+
+When new version of compilers are published, they may not be compatible with 
+older versions of software. This is particularly common when software is built
+with -Werror.
+
+Autotools provides a way for a user to specify the name of his compiler using a
+set of variables ($CC $CXX $CPP etc.). Those variables are used correctly when
+compiling glibc but the script used to generate transliterations in the locale/
+subdirectory directly calls the gcc binary to get the output of the 
+preprocessor instead of using the $CPP variable provided by the build 
+environment. 
+
+This patch replaces the hard-coded reference to the gcc binary with the proper
+environment variable, thus allowing a user to override it.
+
+Upstream-Status : Submitted 
[https://sourceware.org/ml/libc-alpha/2016-08/msg00746.html]
+
+---
+ locale/gen-translit.pl | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/locale/gen-translit.pl b/locale/gen-translit.pl
+index 30d3f2f..7b287fa 100644
+--- a/locale/gen-translit.pl
 b/locale/gen-translit.pl
+@@ -1,5 +1,5 @@
+ #!/usr/bin/perl -w
+-open F, "cat C-translit.h.in | gcc -E - |" || die "Cannot preprocess input 
file";
++open F, 'cat C-translit.h.in | ${CPP:-gcc -E} - |' || die "Cannot preprocess 
input file";
+ 
+ 
+ sub cstrlen {
+-- 
+2.9.3
+
diff --git a/meta/recipes-core/glibc/glibc_2.24.bb 
b/meta/recipes-core/glibc/glibc_2.24.bb
index a3ac738..f5a21b2 100644
--- a/meta/recipes-core/glibc/glibc_2.24.bb
+++ b/meta/recipes-core/glibc/glibc_2.24.bb
@@ -42,7 +42,8 @@ SRC_URI = "${GLIBC_GIT_URI};branch=${SRCBRANCH};name=glibc \
 SRC_URI += "\
file://etc/ld.so.conf \
file://generate-supported.mk \
-"
+   file://0001-locale-fix-hard-coded-reference-to-gcc-E.patch \
+   "
 
 SRC_URI_append_class-nativesdk = "\

file://0001-nativesdk-glibc-Look-for-host-system-ld.so.cache-as-.patch \
-- 
git-series 0.8.9
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v2 7/8] rpm: manually cleanup sysck

version 5.4.1 of rpm was not properly distclean before release, which
causes problems when cross-compiling.

The previous version this recipe called make distclean, but that would
trigger a call to ./configure which would fail when no gcc is
available and make the whole do_configure fail further down the line

This patch manually removes the files from the recipe.

Signed-off-by: Jérémy Rosen 
---
 meta/recipes-devtools/rpm/rpm_5.4.16.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/rpm/rpm_5.4.16.bb 
b/meta/recipes-devtools/rpm/rpm_5.4.16.bb
index 55acd25..9f78dee 100644
--- a/meta/recipes-devtools/rpm/rpm_5.4.16.bb
+++ b/meta/recipes-devtools/rpm/rpm_5.4.16.bb
@@ -527,7 +527,7 @@ do_configure() {
sed -e 's/pkg-config --exists uuid/pkg-config --exists ossp-uuid/g' \
-e 's/pkg-config uuid/pkg-config ossp-uuid/g' -i ${S}/configure
 
-   ( cd ${S}/syck ; set +e ; rm -- -l* ; make distclean ) || :
+   ( cd ${S}/syck ; set +e ; rm -- -l* ; rm Makefile config.h 
config.status lib/Makefile libtool stamp-h1 tests/.deps tests/Makefile  ) || :
 
export varprefix=${localstatedir}
oe_runconf
-- 
git-series 0.8.9
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v2 4/8] busybox: allow overriding compiler name in KConfig

The KConfig infrastructure needs to build HOST binaries in order to
provide its infratstructure. Yocto needs to force the HOSTCC and HOSTCPP
variables to BUILD_CC and BUILD_CPP to make sure that the proper compiler
is used when compiling host binaries
---
 meta/recipes-core/busybox/busybox.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-core/busybox/busybox.inc 
b/meta/recipes-core/busybox/busybox.inc
index 39c2eef..f67bbbc 100644
--- a/meta/recipes-core/busybox/busybox.inc
+++ b/meta/recipes-core/busybox/busybox.inc
@@ -19,7 +19,7 @@ export EXTRA_CFLAGS = "${CFLAGS}"
 export EXTRA_LDFLAGS = "${LDFLAGS}"
 
 # We don't want '-e MAKEFLAGS=' in EXTRA_OEMAKE
-EXTRA_OEMAKE = "CC='${CC}' LD='${CCLD}' V=1 ARCH=${TARGET_ARCH} 
CROSS_COMPILE=${TARGET_PREFIX} SKIP_STRIP=y"
+EXTRA_OEMAKE = "CC='${CC}' LD='${CCLD}' V=1 ARCH=${TARGET_ARCH} 
CROSS_COMPILE=${TARGET_PREFIX} SKIP_STRIP=y HOSTCC='${BUILD_CC}' 
HOSTCPP='${BUILD_CPP}'"
 
 PACKAGES =+ "${PN}-httpd ${PN}-udhcpd ${PN}-udhcpc ${PN}-syslog ${PN}-mdev 
${PN}-hwclock"
 
-- 
git-series 0.8.9
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v2 5/8] sanity: fix hardcoded references to gcc

Signed-off-by: Jérémy Rosen 
---
 meta/classes/sanity.bbclass | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/meta/classes/sanity.bbclass b/meta/classes/sanity.bbclass
index 202b5db..f17e2d4 100644
--- a/meta/classes/sanity.bbclass
+++ b/meta/classes/sanity.bbclass
@@ -459,19 +459,19 @@ def check_gcc_march(sanity_data):
 
 # Check if GCC could work without march
 if not result:
-status,res = 
oe.utils.getstatusoutput(sanity_data.expand("${BUILD_PREFIX}gcc gcc_test.c -o 
gcc_test"))
+status,res = 
oe.utils.getstatusoutput(sanity_data.expand("${BUILD_CC} gcc_test.c -o 
gcc_test"))
 if status == 0:
 result = True;
 
 if not result:
-status,res = 
oe.utils.getstatusoutput(sanity_data.expand("${BUILD_PREFIX}gcc -march=native 
gcc_test.c -o gcc_test"))
+status,res = 
oe.utils.getstatusoutput(sanity_data.expand("${BUILD_CC} -march=native 
gcc_test.c -o gcc_test"))
 if status == 0:
 message = "BUILD_CFLAGS_append = \" -march=native\""
 result = True;
 
 if not result:
 build_arch = sanity_data.getVar('BUILD_ARCH', True)
-status,res = 
oe.utils.getstatusoutput(sanity_data.expand("${BUILD_PREFIX}gcc -march=%s 
gcc_test.c -o gcc_test" % build_arch))
+status,res = 
oe.utils.getstatusoutput(sanity_data.expand("${BUILD_CC} -march=%s gcc_test.c 
-o gcc_test" % build_arch))
 if status == 0:
 message = "BUILD_CFLAGS_append = \" -march=%s\"" % build_arch
 result = True;
@@ -673,11 +673,11 @@ def check_sanity_version_change(status, d):
 if not check_app_exists("${MAKE}", d):
 missing = missing + "GNU make,"
 
-if not check_app_exists('${BUILD_PREFIX}gcc', d):
-missing = missing + "C Compiler (%sgcc)," % d.getVar("BUILD_PREFIX", 
True)
+if not check_app_exists('${BUILD_CC}', d):
+missing = missing + "C Compiler (%s)," % d.getVar("BUILD_CC", True)
 
-if not check_app_exists('${BUILD_PREFIX}g++', d):
-missing = missing + "C++ Compiler (%sg++)," % d.getVar("BUILD_PREFIX", 
True)
+if not check_app_exists('${BUILD_CXX}', d):
+missing = missing + "C++ Compiler (%s)," % d.getVar("BUILD_CXX", True)
 
 required_utilities = d.getVar('SANITY_REQUIRED_UTILITIES', True)
 
-- 
git-series 0.8.9
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v2 3/8] linux-libc-headers: allow overriding compiler name in KConfig

The KConfig infrastructure needs to build HOST binaries in order to
provide its infratstructure. Yocto needs to force the HOSTCC and HOSTCPP
variables to BUILD_CC and BUILD_CPP to make sure that the proper compiler
is used when compiling host binaries
---
 meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc | 2 ++
 1 file changed, 2 insertions(+), 0 deletions(-)

diff --git a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc 
b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
index c701b39..078d752 100644
--- a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
+++ b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
@@ -50,6 +50,8 @@ SRC_URI = 
"${KERNELORG_MIRROR}/linux/kernel/v${HEADER_FETCH_VER}/linux-${PV}.tar
 
 S = "${WORKDIR}/linux-${PV}"
 
+EXTRA_OEMAKE = " HOSTCC="${BUILD_CC}" HOSTCPP="${BUILD_CPP}""
+
 do_configure() {
oe_runmake allnoconfig
 }
-- 
git-series 0.8.9
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v2 0/8] Fix BUILD_* family of variables

The BUILD_* family of variables allow the user to specify the name of the host
compiler to use at build time. This feature is particularly important for long
term maintainance. Future versions of gcc might not be compatible with old
yocto distributions and we can't assume that "gcc" is the correct name for the
compiler.

This problem is already an issue with Jethro which can't be compiled on a
machine wher gcc-6 is the default compiler. pkgconfig-native will refuse to
compile because it uses -Werror and gcc-6 has new warnings compared to gcc-5

This patch serie fixes multiple hard-coded references to gcc in various recipes
and build infrastructure

This patch was tested by building core-image-minimal for qemu-x86_64 with a
directory with the following content added to the PATH

 g++ -> /bin/false
 gcc -> /bin/false
 myg++ -> /usr/bin/g++
 mygcc -> /usr/bin/gcc

And the following variables added to local.conf

export BUILD_CC = "mygcc"
export BUILD_CXX = "myg++"
export BUILD_CPP = "mygcc -E"
export BUILD_CCLD = "mygcc"

---
V2
* rewording in some commits messages
* no need for a patch to KConfig, use OE_RUNMAKE_FLAGS instead
* change all patch titles to use : in the short commit message
* rpm : manually remove files instead of calling make distclean
* libpcre : explicitely set CCLD_FOR_BUILD in the recipe since it's the only
  recipe using it.
* glibc patch has been submited upstream

It would be interesting to modify yocto's builders to use the BUILD_*
variable in order to have some early warning wrt gcc polution in recipes, but
seeing the various recipes I had to patch, I would expect such a change to
trigger a high number of build failures.

Jérémy Rosen (8):
  cross: export CC family from BUILD_* for cross compilers
  linux-yocto: allow overriding compiler name in KConfig
  linux-libc-headers: allow overriding compiler name in KConfig
  busybox: allow overriding compiler name in KConfig
  sanity: fix hardcoded references to gcc
  glibc: remove hard-coded reference to gcc -E
  rpm: manually cleanup sysck
  libpcre: explicitely specify CCLD_FOR_BUILD for this recipe

 meta/classes/cross.bbclass 
   | 12 
 meta/classes/kernel.bbclass
   |  1 +
 meta/classes/sanity.bbclass
   | 14 +++---
 meta/recipes-core/busybox/busybox.inc  
   |  2 +-
 
meta/recipes-core/glibc/glibc/0001-locale-fix-hard-coded-reference-to-gcc-E.patch
 | 39 +++
 meta/recipes-core/glibc/glibc_2.24.bb  
   |  3 ++-
 meta/recipes-devtools/rpm/rpm_5.4.16.bb
   |  2 +-
 meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc  
   |  2 ++
 meta/recipes-support/libpcre/libpcre_8.39.bb   
   |  2 ++
 9 files changed, 67 insertions(+), 10 deletions(-)
 create mode 100644 
meta/recipes-core/glibc/glibc/0001-locale-fix-hard-coded-reference-to-gcc-E.patch

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

[OE-core] [PATCH v2 1/8] cross: export CC family from BUILD_* for cross compilers

cross-compilers are native recipes that need to be compiled by the host's
compiler. However they do not use native.bbclass

As a consequence, the various CC, CXX etc environment variables are not
correctly set and they will not honor the host compiler name provided
by the BUILD_* variables.

Signed-off-by: Jérémy Rosen 
---
 meta/classes/cross.bbclass | 12 
 1 file changed, 12 insertions(+), 0 deletions(-)

diff --git a/meta/classes/cross.bbclass b/meta/classes/cross.bbclass
index 81d1c9d..8d1e779 100644
--- a/meta/classes/cross.bbclass
+++ b/meta/classes/cross.bbclass
@@ -68,4 +68,16 @@ do_install () {
 
 USE_NLS = "no"
 
+export CC = "${BUILD_CC}"
+export CXX = "${BUILD_CXX}"
+export FC = "${BUILD_FC}"
+export CPP = "${BUILD_CPP}"
+export LD = "${BUILD_LD}"
+export CCLD = "${BUILD_CCLD}"
+export AR = "${BUILD_AR}"
+export AS = "${BUILD_AS}"
+export RANLIB = "${BUILD_RANLIB}"
+export STRIP = "${BUILD_STRIP}"
+export NM = "${BUILD_NM}"
+
 inherit nopackages
-- 
git-series 0.8.9
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v2 2/8] linux-yocto: allow overriding compiler name in KConfig

The KConfig infrastructure needs to build HOST binaries in order to
provide its infratstructure. Yocto needs to force the HOSTCC and HOSTCPP
variables to BUILD_CC and BUILD_CPP to make sure that the proper compiler
is used when compiling host binaries
---
 meta/classes/kernel.bbclass | 1 +
 1 file changed, 1 insertion(+), 0 deletions(-)

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index d6a0ca8..e4e8ee4 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -156,6 +156,7 @@ UBOOT_LOADADDRESS ?= "${UBOOT_ENTRYPOINT}"
 # Some Linux kernel configurations need additional parameters on the command 
line
 KERNEL_EXTRA_ARGS ?= ""
 
+EXTRA_OEMAKE = " HOSTCC="${BUILD_CC}" HOSTCPP="${BUILD_CPP}""
 KERNEL_ALT_IMAGETYPE ??= ""
 
 copy_initramfs() {
-- 
git-series 0.8.9
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 3/3] pciutils: fix PACKAGECONFIG

The PACKAGECONFIG's value doens't go into EXTRA_OECONF, but
PACKAGECONFIG_CONFARGS.

Fixed:
pciutils-3.5.1: libpci rdepends on libudev, but it isn't a build dependency, 
missing eudev in DEPENDS or PACKAGECONFIG? [build-deps]
pciutils-3.5.1: pciutils rdepends on libudev, but it isn't a build dependency, 
missing eudev in DEPENDS or PACKAGECONFIG? [build-deps]

Signed-off-by: Robert Yang 
---
 meta/recipes-bsp/pciutils/pciutils_3.5.1.bb | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-bsp/pciutils/pciutils_3.5.1.bb 
b/meta/recipes-bsp/pciutils/pciutils_3.5.1.bb
index a84efd9..d32b119 100644
--- a/meta/recipes-bsp/pciutils/pciutils_3.5.1.bb
+++ b/meta/recipes-bsp/pciutils/pciutils_3.5.1.bb
@@ -27,9 +27,9 @@ PCI_CONF_FLAG = "ZLIB=yes DNS=yes SHARED=yes"
 do_configure () {
(
  cd lib && \
- # EXTRA_OECONF for this recipe could only possibly contain 
'HWDB=yes/no', so we put it
- # before ./configure
- ${PCI_CONF_FLAG} ${EXTRA_OECONF} ./configure ${PV} ${datadir} 
${TARGET_OS} ${TARGET_ARCH}
+ # PACKAGECONFIG_CONFARGS for this recipe could only possibly contain 
'HWDB=yes/no',
+ # so we put it before ./configure
+ ${PCI_CONF_FLAG} ${PACKAGECONFIG_CONFARGS} ./configure ${PV} 
${datadir} ${TARGET_OS} ${TARGET_ARCH}
)
 }
 
-- 
2.9.0

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

[OE-core] [PATCH 0/3] fix lighttpd pciutils and apt

The following changes since commit 55bb6816aca39bfa25d4f7e2158a57a5f0ac1cca:

  oeqa.buildperf: correct globalres time format (2016-09-06 10:24:00 +0100)

are available in the git repository at:

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

Robert Yang (3):
  lighttpd: without-memcache -> without-memcached
  apt: add PACKAGECONFIG for lz4
  pciutils: fix PACKAGECONFIG

 meta/recipes-bsp/pciutils/pciutils_3.5.1.bb   | 6 +++---
 meta/recipes-devtools/apt/apt_1.2.12.bb   | 1 +
 meta/recipes-extended/lighttpd/lighttpd_1.4.41.bb | 2 +-
 3 files changed, 5 insertions(+), 4 deletions(-)

-- 
2.9.0

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

[OE-core] [PATCH 1/3] lighttpd: without-memcache -> without-memcached

Fixed:
WARNING: QA Issue: lighttpd: configure was passed unrecognised options: 
--without-memcache [unknown-configure-option]

Signed-off-by: Robert Yang 
---
 meta/recipes-extended/lighttpd/lighttpd_1.4.41.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-extended/lighttpd/lighttpd_1.4.41.bb 
b/meta/recipes-extended/lighttpd/lighttpd_1.4.41.bb
index bba90cf..1a3f323 100644
--- a/meta/recipes-extended/lighttpd/lighttpd_1.4.41.bb
+++ b/meta/recipes-extended/lighttpd/lighttpd_1.4.41.bb
@@ -36,7 +36,7 @@ EXTRA_OECONF = " \
  --without-bzip2 \
  --without-ldap \
  --without-lua \
- --without-memcache \
+ --without-memcached \
  --with-pcre \
  --without-webdav-props \
  --without-webdav-locks \
-- 
2.9.0

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

[OE-core] [PATCH 2/3] apt: add PACKAGECONFIG for lz4

Fixed:
apt-1.2.12: apt rdepends on lz4, but it isn't a build dependency, missing lz4 
in DEPENDS or PACKAGECONFIG? [build-deps]

Signed-off-by: Robert Yang 
---
 meta/recipes-devtools/apt/apt_1.2.12.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-devtools/apt/apt_1.2.12.bb 
b/meta/recipes-devtools/apt/apt_1.2.12.bb
index 85c0d56..ae0bce9 100644
--- a/meta/recipes-devtools/apt/apt_1.2.12.bb
+++ b/meta/recipes-devtools/apt/apt_1.2.12.bb
@@ -7,6 +7,7 @@ require apt-package.inc
 PACKAGECONFIG ??= "lzma"
 PACKAGECONFIG[lzma] = 
"ac_cv_lib_lzma_lzma_easy_encoder=yes,ac_cv_lib_lzma_lzma_easy_encoder=no,xz"
 PACKAGECONFIG[bz2] = 
"ac_cv_lib_bz2_BZ2_bzopen=yes,ac_cv_lib_bz2_BZ2_bzopen=no,bzip2"
+PACKAGECONFIG[lz4] = 
"ac_cv_lib_lz4_LZ4F_createCompressionContext=yes,ac_cv_lib_lz4_LZ4F_createCompressionContext=no,lz4"
 
 FILES_${PN} += "${bindir}/apt-key"
 apt-manpages += "doc/apt-key.8"
-- 
2.9.0

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

Re: [OE-core] [yocto] [PATCH] ruby: ensure that .ext/rdoc is gone in compile

2016-09-07 Thread sujith h

On Tue, Sep 6, 2016 at 10:23 PM, Khem Raj  wrote:

>
> > On Aug 29, 2016, at 5:45 AM, Sujith H  wrote:
> >
> > From: Christopher Larson 
> >
> > rdoc gets unhappy if this already exists, so remove it before building.
> >
> > Without this, it's possible to hit this error:
> >
> >Directory .ext/rdoc already exists, but it looks like it isn't an RDoc
> >directory.
> >
>
> patch is fine, please post it to openembedded-core mailing list.
>

I have already posted it in the openembedded-core mailing list :
http://lists.openembedded.org/pipermail/openembedded-core/2016-August/125836.html

>
> > Signed-off-by: Christopher Larson 
> > Signed-off-by: Sujith Haridasan 
> > ---
> > meta/recipes-devtools/ruby/ruby.inc | 4 
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/meta/recipes-devtools/ruby/ruby.inc
> b/meta/recipes-devtools/ruby/ruby.inc
> > index fde67e9..d8f6882 100644
> > --- a/meta/recipes-devtools/ruby/ruby.inc
> > +++ b/meta/recipes-devtools/ruby/ruby.inc
> > @@ -37,3 +37,7 @@ do_configure_prepend() {
> > sed -i "s#%%TARGET_CFLAGS%%#$TARGET_CFLAGS#;
> s#%%TARGET_LDFLAGS%%#$TARGET_LDFLAGS#" ${S}/common.mk
> > rm -rf ${S}/ruby/
> > }
> > +
> > +do_compile_prepend () {
> > +rm -rf .ext/rdoc
> > +}
> > --
> > 1.9.1
> >
> > --
> > ___
> > yocto mailing list
> > yo...@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
>
>


-- 
സുജിത് ഹരിദാസന്
Bangalore
Contributor to KDE project
Contributor to Yocto project
http://fci.wikia.com/wiki/Anti-DRM-Campaign
 http://sujithh.info
C-x C-c
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] wayland: 1.11.0 -> 1.11.93

2016-09-07 Thread Burton, Ross

On 7 September 2016 at 03:58, Wang Xin 
wrote:

> 1) Upgrade wayland from 1.11.0 to 1.11.93.
> 2) Delete one patch, since it is no use.
> 0001-scanner-Use-unit32_t-instead-of-uint.patch
>

1.11.93 is a release candidate, not a release, so we'd go straight from
1.11.0 to 1.12.0.

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

[OE-core] [PATCH 1/2] oeqa.buildperf: try harder when splitting 'nevr' string

Try to be more intelligent when splitting out recipe name, epoch,
version and revision from the buildstat directory name. Previous
assumption was that package versions never contain a dash but obviously
that is not necessarily true. The new assumption is that the package
version starts with a number.

Signed-off-by: Markus Lehtonen 
---
 meta/lib/oeqa/buildperf/base.py | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/meta/lib/oeqa/buildperf/base.py b/meta/lib/oeqa/buildperf/base.py
index 2325cd1..7dfb2bf 100644
--- a/meta/lib/oeqa/buildperf/base.py
+++ b/meta/lib/oeqa/buildperf/base.py
@@ -425,8 +425,10 @@ class BuildPerfTestCase(unittest.TestCase):
 """Save buildstats"""
 def split_nevr(nevr):
 """Split name and version information from recipe "nevr" string"""
-name, e_v, revision = nevr.rsplit('-', 2)
-match = re.match(r'^((?P[0-9]{1,5})_)?(?P.*)$', 
e_v)
+n_e_v, revision = nevr.rsplit('-', 1)
+match = 
re.match(r'^(?P\S+)-((?P[0-9]{1,5})_)?(?P[0-9]\S*)$',
+ n_e_v)
+name = match.group('name')
 version = match.group('version')
 epoch = match.group('epoch')
 return name, epoch, version, revision
-- 
2.6.6

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

[OE-core] [PATCH 2/2] oeqa.buildperf: be sure to use the latest buildstats

Be sure to take the latest buildstats if multiple buildstats are found.

Signed-off-by: Markus Lehtonen 
---
 meta/lib/oeqa/buildperf/base.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/lib/oeqa/buildperf/base.py b/meta/lib/oeqa/buildperf/base.py
index 7dfb2bf..9700c05 100644
--- a/meta/lib/oeqa/buildperf/base.py
+++ b/meta/lib/oeqa/buildperf/base.py
@@ -466,7 +466,7 @@ class BuildPerfTestCase(unittest.TestCase):
 return bs_json
 
 log.info('Saving buildstats in JSON format')
-bs_dirs = os.listdir(self.bb_vars['BUILDSTATS_BASE'])
+bs_dirs = sorted(os.listdir(self.bb_vars['BUILDSTATS_BASE']))
 if len(bs_dirs) > 1:
 log.warning("Multiple buildstats found for test %s, only "
 "archiving the last one", self.name)
-- 
2.6.6

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

[OE-core] [PATCH 0/2] Fixes for oe-build-perf-test