[OE-core] [PATCH] gcc-6: Sync gcc stddef.h with musl stddef.h

[Khem Raj]

GCC provides some of std* headers including stddef.h
and it syncs with glibc definitions via __needed* defines
to find which datatypes are expected to be defined on top
of glibc. we need same for musl.

Drop unused 0048-ARM-PR-target-71056-Don-t-use-vectorized-builtins-wh.patch

Signed-off-by: Khem Raj 
---
 meta/recipes-devtools/gcc/gcc-6.3.inc  |  1 +
 ...et-71056-Don-t-use-vectorized-builtins-wh.patch | 92 --
 .../gcc-6.3/0048-sync-gcc-stddef.h-with-musl.patch | 91 +
 3 files changed, 92 insertions(+), 92 deletions(-)
 delete mode 100644 
meta/recipes-devtools/gcc/gcc-6.3/0048-ARM-PR-target-71056-Don-t-use-vectorized-builtins-wh.patch
 create mode 100644 
meta/recipes-devtools/gcc/gcc-6.3/0048-sync-gcc-stddef.h-with-musl.patch

diff --git a/meta/recipes-devtools/gcc/gcc-6.3.inc 
b/meta/recipes-devtools/gcc/gcc-6.3.inc
index 0b84597a42..0f1b88bea7 100644
--- a/meta/recipes-devtools/gcc/gcc-6.3.inc
+++ b/meta/recipes-devtools/gcc/gcc-6.3.inc
@@ -78,6 +78,7 @@ SRC_URI = "\
file://0045-libgcc-Add-knob-to-use-ldbl-128-on-ppc.patch \
file://0046-Link-libgcc-using-LDFLAGS-not-just-SHLIB_LDFLAGS.patch \

file://0047-libgcc_s-Use-alias-for-__cpu_indicator_init-instead-.patch \
+   file://0048-sync-gcc-stddef.h-with-musl.patch \
${BACKPORTS} \
 "
 BACKPORTS = ""
diff --git 
a/meta/recipes-devtools/gcc/gcc-6.3/0048-ARM-PR-target-71056-Don-t-use-vectorized-builtins-wh.patch
 
b/meta/recipes-devtools/gcc/gcc-6.3/0048-ARM-PR-target-71056-Don-t-use-vectorized-builtins-wh.patch
deleted file mode 100644
index 9c39c7f7ad..00
--- 
a/meta/recipes-devtools/gcc/gcc-6.3/0048-ARM-PR-target-71056-Don-t-use-vectorized-builtins-wh.patch
+++ /dev/null
@@ -1,92 +0,0 @@
-From 84d2a5509892b65ed60d39e6e2f9719e3762e40e Mon Sep 17 00:00:00 2001
-From: ktkachov 
-Date: Tue, 31 May 2016 08:29:39 +
-Subject: [PATCH] [ARM] PR target/71056: Don't use vectorized builtins when
- NEON is not available
-
-   PR target/71056
-   * config/arm/arm-builtins.c (arm_builtin_vectorized_function): Return
-   NULL_TREE early if NEON is not available.  Remove now redundant check
-   in ARM_CHECK_BUILTIN_MODE.
-
-   * gcc.target/arm/pr71056.c: New test.
-
-
-
-git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-6-branch@236910 
138bc75d-0d04-0410-961f-82ee72b054a4

-Upstream-Status: Backport
-Signed-off-by: Khem Raj 
-
- gcc/ChangeLog  |  7 +++
- gcc/config/arm/arm-builtins.c  |  6 +-
- gcc/testsuite/ChangeLog|  5 +
- gcc/testsuite/gcc.target/arm/pr71056.c | 32 
- 4 files changed, 49 insertions(+), 1 deletion(-)
- create mode 100644 gcc/testsuite/gcc.target/arm/pr71056.c
-
-diff --git a/gcc/config/arm/arm-builtins.c b/gcc/config/arm/arm-builtins.c
-index 90fb40f..68b2839 100644
 a/gcc/config/arm/arm-builtins.c
-+++ b/gcc/config/arm/arm-builtins.c
-@@ -2861,6 +2861,10 @@ arm_builtin_vectorized_function (unsigned int fn, tree 
type_out, tree type_in)
-   int in_n, out_n;
-   bool out_unsigned_p = TYPE_UNSIGNED (type_out);
- 
-+  /* Can't provide any vectorized builtins when we can't use NEON.  */
-+  if (!TARGET_NEON)
-+return NULL_TREE;
-+
-   if (TREE_CODE (type_out) != VECTOR_TYPE
-   || TREE_CODE (type_in) != VECTOR_TYPE)
- return NULL_TREE;
-@@ -2875,7 +2879,7 @@ arm_builtin_vectorized_function (unsigned int fn, tree 
type_out, tree type_in)
-NULL_TREE is returned if no such builtin is available.  */
- #undef ARM_CHECK_BUILTIN_MODE
- #define ARM_CHECK_BUILTIN_MODE(C)\
--  (TARGET_NEON && TARGET_FPU_ARMV8   \
-+  (TARGET_FPU_ARMV8   \
-&& flag_unsafe_math_optimizations \
-&& ARM_CHECK_BUILTIN_MODE_1 (C))
- 
-diff --git a/gcc/testsuite/gcc.target/arm/pr71056.c 
b/gcc/testsuite/gcc.target/arm/pr71056.c
-new file mode 100644
-index 000..136754e
 /dev/null
-+++ b/gcc/testsuite/gcc.target/arm/pr71056.c
-@@ -0,0 +1,32 @@
-+/* PR target/71056.  */
-+/* { dg-do compile } */
-+/* { dg-require-effective-target arm_vfp3_ok } */
-+/* { dg-options "-O3 -mfpu=vfpv3" } */
-+
-+/* Check that compiling for a non-NEON target doesn't try to introduce
-+   a NEON vectorized builtin.  */
-+
-+extern char *buff;
-+int f2 ();
-+struct T1
-+{
-+  int reserved[2];
-+  unsigned int ip;
-+  unsigned short cs;
-+  unsigned short rsrv2;
-+};
-+void
-+f3 (const char *p)
-+{
-+  struct T1 x;
-+  __builtin_memcpy (&x, p, sizeof (struct T1));
-+  x.reserved[0] = __builtin_bswap32 (x.reserved[0]);
-+  x.reserved[1] = __builtin_bswap32 (x.reserved[1]);
-+  x.ip = __builtin_bswap32 (x.ip);
-+  x.cs = x.cs << 8 | x.cs >> 8;
-+  x.rsrv2 = x.rsrv2 << 8 | x.rsrv2 >> 8;
-+  if (f2 ())
-+{
-+  __builtin_memcpy (buff, "\n", 1);
-+}
-+}
--- 
-2.9.0
-
diff --git 
a/meta/recipes-devtools/gcc/gcc-6.3/0048-sync-gcc-stddef.h-with-musl.patch 
b/meta/recipes-devtools/gcc/gcc-6.3/0048-sync-gcc-stddef.h-with-musl.patch
n

Re: [OE-core] whatever happened to a proposal for "read-only" sstate?

[Patrick Ohly]

On Fri, 2017-02-03 at 16:24 -0500, Robert P. J. Day wrote:
> On Fri, 3 Feb 2017, Patrick Ohly wrote:
> 
> > On Fri, 2017-02-03 at 14:14 -0500, Robert P. J. Day wrote:
> > >   is there a command that will tell you how much shared state info a
> > > given build would be able to take advantage of?
> >
> > INHERIT += "buildstats-summary" in local.conf will print that
> > information after a build is done.
> 
>   but not before? ok, that will do for now.

It might do that also for a "bitbake --dry-run", but I am not sure, and
my build directory is currently busy, so I can't test it.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.



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

Re: [OE-core] whatever happened to a proposal for "read-only" sstate?

[Robert P. J. Day]

On Fri, 3 Feb 2017, Patrick Ohly wrote:

> On Fri, 2017-02-03 at 14:14 -0500, Robert P. J. Day wrote:
> >   is there a command that will tell you how much shared state info a
> > given build would be able to take advantage of?
>
> INHERIT += "buildstats-summary" in local.conf will print that
> information after a build is done.

  but not before? ok, that will do for now.

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

Re: [OE-core] whatever happened to a proposal for "read-only" sstate?

[Patrick Ohly]

On Fri, 2017-02-03 at 14:14 -0500, Robert P. J. Day wrote:
>   is there a command that will tell you how much shared state info a
> given build would be able to take advantage of?

INHERIT += "buildstats-summary" in local.conf will print that
information after a build is done.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.



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

[OE-core] [PATCH] wic: flatten imager class hierarchy

[Ed Bartosh]

wic code is hard to follow due to deep and twiggy class
inheritance tree.

Flatten imager tree:
 wic -> wic_create -> Creator -> DirectPlugin -> DirectImageCreator
to
 wic -> wic_create -> DirectPlugin
by
 removing Creator class and creator module
 merging DirectImageCreator into DirectPlugin

Changed APIs to use the same parameters names.

Passed parsed command line options as an object down the stack.

Signed-off-by: Ed Bartosh 
---
 scripts/lib/wic/creator.py   | 106 --
 scripts/lib/wic/engine.py|  32 -
 scripts/lib/wic/plugins/imager/direct.py | 108 +++
 scripts/wic  |   3 +-
 4 files changed, 56 insertions(+), 193 deletions(-)
 delete mode 100644 scripts/lib/wic/creator.py

diff --git a/scripts/lib/wic/creator.py b/scripts/lib/wic/creator.py
deleted file mode 100644
index 74db83c..000
--- a/scripts/lib/wic/creator.py
+++ /dev/null
@@ -1,106 +0,0 @@
-#!/usr/bin/env python -tt
-#
-# Copyright (c) 2011 Intel, Inc.
-#
-# This program is free software; you can redistribute it and/or modify it
-# under the terms of the GNU General Public License as published by the Free
-# Software Foundation; version 2 of the License
-#
-# This program is distributed in the hope that it will be useful, but
-# WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
-# or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
-# for more details.
-#
-# You should have received a copy of the GNU General Public License along
-# with this program; if not, write to the Free Software Foundation, Inc., 59
-# Temple Place - Suite 330, Boston, MA 02111-1307, USA.
-
-import os, sys
-from optparse import OptionParser, SUPPRESS_HELP
-
-from wic import msger
-from wic.utils import errors
-from wic.plugin import pluginmgr
-
-class Creator():
-"""${name}: create an image
-
-Usage:
-${name} SUBCOMMAND  [OPTS]
-
-${command_list}
-${option_list}
-"""
-
-name = 'wic create(cr)'
-
-def __init__(self, *args, **kwargs):
-self._subcmds = {}
-
-# get cmds from pluginmgr
-# mix-in do_subcmd interface
-for subcmd, klass in pluginmgr.get_plugins('imager').items():
-if not hasattr(klass, 'do_create'):
-msger.warning("Unsupported subcmd: %s" % subcmd)
-continue
-
-func = getattr(klass, 'do_create')
-self._subcmds[subcmd] = func
-
-def get_optparser(self):
-optparser = OptionParser()
-optparser.add_option('-d', '--debug', action='store_true',
- dest='debug',
- help=SUPPRESS_HELP)
-optparser.add_option('-v', '--verbose', action='store_true',
- dest='verbose',
- help=SUPPRESS_HELP)
-optparser.add_option('', '--logfile', type='string', dest='logfile',
- default=None,
- help='Path of logfile')
-optparser.add_option('-c', '--config', type='string', dest='config',
- default=None,
- help='Specify config file for wic')
-optparser.add_option('-o', '--outdir', type='string', action='store',
- dest='outdir', default=None,
- help='Output directory')
-optparser.add_option('', '--tmpfs', action='store_true', 
dest='enabletmpfs',
- help='Setup tmpdir as tmpfs to accelerate, 
experimental'
-  ' feature, use it if you have more than 4G 
memory')
-optparser.add_option('', '--bmap', action='store_true', help='generate 
.bmap')
-return optparser
-
-def postoptparse(self, options):
-abspath = lambda pth: os.path.abspath(os.path.expanduser(pth))
-
-if options.verbose:
-msger.set_loglevel('verbose')
-if options.debug:
-msger.set_loglevel('debug')
-
-if options.logfile:
-logfile_abs_path = abspath(options.logfile)
-if os.path.isdir(logfile_abs_path):
-raise errors.Usage("logfile's path %s should be file"
-   % options.logfile)
-if not os.path.exists(os.path.dirname(logfile_abs_path)):
-os.makedirs(os.path.dirname(logfile_abs_path))
-msger.set_interactive(False)
-msger.set_logfile(logfile_abs_path)
-
-def main(self, argv=None):
-if argv is None:
-argv = sys.argv
-else:
-argv = argv[:] # don't modify caller's list
-
-pname = argv[0]
-if pname not in self._subcmds:
-msger.error('Unknown plugin: %s' % pname)
-
-optparser = self.get_optparser()
-options, args = optparser.parse_args(argv)
-
-self.postoptparse(op

Re: [OE-core] whatever happened to a proposal for "read-only" sstate?

[Robert P. J. Day]

On Fri, 3 Feb 2017, Richard Purdie wrote:

> On Fri, 2017-02-03 at 06:45 -0500, Robert P. J. Day wrote:
> >   for purposes of teaching, i wanted to check into the feasibility of
> > having students take advantage of a single shared state cache, but
> > still have the option of building whatever source they needed in
> > their
> > own *personal* sstate cache.
> >
> >   i found this reference from 2014:
> >
> > http://lists.openembedded.org/pipermail/openembedded-core/2014-August
> > /096486.html
> >
> > but it seems clear nothing became of it; there's certainly no
> > .bbclass
> > file that matches that.
> >
> >   what are the options for setting up something like this? or is that
> > already supported and i'm just not seeing it?
>
> It was never merged as its not really necessary, you can do this with
> existing functionality.
>
> Just point SSTATE_MIRRORS at the common shared directory and SSTATE_DIR
> at the directory you want to be the personal one.

  is there a command that will tell you how much shared state info a
given build would be able to take advantage of?

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] [RFC]kernel-yocto.bbclass: ensure repatching when HEAD is checked out

[Bruce Ashfield]

Here's the patch that I came up with based on your change. The only
difference
is that I modified the patching script to have a --clean option .. and used
that
instead. That way we keep the internals hidden.

If this works for you, I can send it in my next kernel pull request.

Bruce

On Fri, Feb 3, 2017 at 9:16 AM, Bruce Ashfield 
wrote:

>
>
> On Fri, Feb 3, 2017 at 5:49 AM, Awais Belal 
> wrote:
>
>> In some cases it is seen that kernel_checkout and
>> validate_branches are run again in simultaneous builds.
>> During do_patch the kgit-s2q mechanism creates and
>> checks for the kgit-s2q.last file inside the .git
>> directory, finds a fence post and starts picking up
>> patches after that. This can create trouble as
>> validate_branches checks out the HEAD of the branch
>> and so the patches should be reapplied rather than
>> skipped due to finding of the fence post.
>>
>
> Indeed. I can see how this could happen. I added the mechanism to ensure
> that multiple runs (forced or not) didn't re-patch the tree (since the
> tools no
> longer do an auto-resume detection).
>
> At that time, I tried to run the paths and make sure that the sentinel file
> couldn't cause this sort of problem, but clearly there is a case.
>
> I'll grab this patch and modify it a bit so the script can clear the file
> itself
> (that way if the format changes again, we don't have to tweak the bbclass).
>
> I'll float that patch by you, if that is ok, so you can add a
> Signed-off-by
> (since the work on finding the issue deserves credit on the patch itself).
>
> Cheers,
>
> Bruce
>
>
>>
>> Signed-off-by: Awais Belal 
>> ---
>>  meta/classes/kernel-yocto.bbclass | 4 
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/meta/classes/kernel-yocto.bbclass b/meta/classes/
>> kernel-yocto.bbclass
>> index 5cfd8af..131c48a 100644
>> --- a/meta/classes/kernel-yocto.bbclass
>> +++ b/meta/classes/kernel-yocto.bbclass
>> @@ -350,6 +350,10 @@ do_validate_branches() {
>> current_branch=`git rev-parse --abbrev-ref HEAD`
>> git branch "$current_branch-orig"
>> git reset --hard ${force_srcrev}
>> +   # We've checked out HEAD, make sure we cleanup
>> kgit-s2q fence post check
>> +   # so the patches are applied as expected
>> otherwise no patching
>> +   # would be done in some corner cases.
>> +   rm -rf ${S}/.git/kgit-s2q.last
>> fi
>> fi
>>  }
>> --
>> 1.9.1
>>
>> --
>> ___
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>>
>
>
>
> --
> "Thou shalt not follow the NULL pointer, for chaos and madness await thee
> at its end"
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end"
From ce7587f444d652bd9bccc1064faa2389d7982575 Mon Sep 17 00:00:00 2001
From: Awais Belal 
Date: Fri, 3 Feb 2017 15:49:36 +0500
Subject: [PATCH] kernel-yocto.bbclass: ensure repatching when HEAD is checked
 out

In some cases it is seen that kernel_checkout and validate_branches are
run again in simultaneous builds. During do_patch the kgit-s2q mechanism
looks for a sentinel file inside the .git directory, finds a fence post
and starts picking up patches after that.

This can create trouble as validate_branches checks out the HEAD of the
branch and so the patches should be reapplied rather than skipped due to
finding of the fence post.

We can call kgit-s2q --clean to remove the sentinel file when the
branches are checked out.

Signed-off-by: Awais Belal 
Signed-off-by: Bruce Ashfield 
---
 meta/classes/kernel-yocto.bbclass   | 4 
 meta/recipes-kernel/kern-tools/kern-tools-native_git.bb | 2 +-
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/meta/classes/kernel-yocto.bbclass b/meta/classes/kernel-yocto.bbclass
index ee0a4d8d9d37..0bf64886e367 100644
--- a/meta/classes/kernel-yocto.bbclass
+++ b/meta/classes/kernel-yocto.bbclass
@@ -388,6 +388,10 @@ do_validate_branches() {
 			current_branch=`git rev-parse --abbrev-ref HEAD`
 			git branch "$current_branch-orig"
 			git reset --hard ${force_srcrev}
+			# We've checked out HEAD, make sure we cleanup kgit-s2q fence post check
+			# so the patches are applied as expected otherwise no patching
+			# would be done in some corner cases.
+			kgit-s2q --clean
 		fi
 	fi
 }
diff --git a/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb b/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
index 4b1de5752c93..03f8ce3cc253 100644
--- a/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
+++ b/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
@@ -4,7 +4,7 @@ LIC_FILES_CHKSUM = "file://git/tools/kgit;beginline=5;endline=9;md5=a6c2fa8aef1b
 
 DEPENDS = "git-native"
 
-SRCREV = "c14440d4e7ae0160c260ed65c3e123be5dc97ae8"
+SRCRE

[OE-core] [PATCH] wic: fix call of serial_console_form_kargs

[Ed Bartosh]

As syslinux module has been recently removed and
serial_consloe_form_kargs became local API in rootfs_pcbios_ext plugin
it should be called without syslinux. prefix.

Signed-off-by: Ed Bartosh 
---
 scripts/lib/wic/plugins/source/rootfs_pcbios_ext.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/lib/wic/plugins/source/rootfs_pcbios_ext.py 
b/scripts/lib/wic/plugins/source/rootfs_pcbios_ext.py
index bd6fd6c..cb1da93 100644
--- a/scripts/lib/wic/plugins/source/rootfs_pcbios_ext.py
+++ b/scripts/lib/wic/plugins/source/rootfs_pcbios_ext.py
@@ -122,7 +122,7 @@ class RootfsPlugin(SourcePlugin):
 syslinux_conf += "ALLOWOPTIONS 1\n"
 
 # Derive SERIAL... line from from kernel boot parameters
-syslinux_conf += syslinux.serial_console_form_kargs(options) + "\n"
+syslinux_conf += serial_console_form_kargs(options) + "\n"
 
 syslinux_conf += "DEFAULT linux\n"
 syslinux_conf += "LABEL linux\n"
-- 
2.1.4

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

[OE-core] [PATCH] selftest: wic: stop using iso image type

[Ed Bartosh]

Removed 'IMAGE_FSTYPES = "iso" as this functionality depends on
do_bootimg, which is going to be obsoleted soon.

As wic doesn't depend on bootimg it's safe to remove this.

Signed-off-by: Ed Bartosh 
---
 meta/lib/oeqa/selftest/wic.py | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/meta/lib/oeqa/selftest/wic.py b/meta/lib/oeqa/selftest/wic.py
index 07b8312..417ba3d 100644
--- a/meta/lib/oeqa/selftest/wic.py
+++ b/meta/lib/oeqa/selftest/wic.py
@@ -42,8 +42,7 @@ class Wic(oeSelfTest):
 
 def setUpLocal(self):
 """This code is executed before each test method."""
-self.write_config('IMAGE_FSTYPES = "iso"\n'
-  'MACHINE_FEATURES_append = " efi"\n')
+self.write_config('MACHINE_FEATURES_append = " efi"\n')
 
 # Do this here instead of in setUpClass as the base setUp does some
 # clean up which can result in the native tools built earlier in
@@ -151,7 +150,8 @@ class Wic(oeSelfTest):
 @testcase(1346)
 def test_iso_image(self):
 """Test creation of hybrid iso image with legacy and EFI boot"""
-config = 'MACHINE_FEATURES_append = " efi"\n'
+config = 'INITRAMFS_IMAGE = "core-image-minimal-initramfs"\n'\
+ 'MACHINE_FEATURES_append = " efi"\n'
 self.append_config(config)
 bitbake('core-image-minimal')
 self.remove_config(config)
-- 
2.1.4

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

Re: [OE-core] Want to strip rootfs

[Mark Hatle]

On 2/3/17 6:25 AM, ANDANI PRASHANT wrote:
> Hi,
> 
> I build rootfs which size is 100MB+
> As i look in to filesystem, there are 14mb libc-2.23.so ,
> 12mb libstdc++.so.6.0.22,..etc.
> Is there any flag or option during build to strip all library and binary to
> optimise size of rootfs.

The default is that everything is stripped (actually split into stripped
executable and debug addition).  The stripped pieces are installed into your
rootfs, and the debug pieces are not.  (Unless you've added dbg-pkgs to your
configuration.)

The default optimization flag should be more then enough to get a consistent
well optimized system.

Where you will run into issues is if you, or one of the layers you are using
disables the splitting or enables global debug optimizations (lower optimization
levels.)

This is what you want to check for:

# Uncomment this to change the optimization to make debugging easer, at the
# possible cost of performance.
# DEBUG_BUILD = "1"
#
# Uncomment this to disable the stripping of the installed binaries
# INHIBIT_PACKAGE_STRIP = "1"
#
# Uncomment this to disable the split of the debug information into -dbg files
# INHIBIT_PACKAGE_DEBUG_SPLIT = "1"

You can use bitbake -e to investigate the values for the system as a whole, or
specify a recipe to look at a specific item.

--Mark

> Regards,
> Prashant
> 
> 

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

[OE-core] [PATCH] selftest: wic: use wic-tools recipe to get STAGING_DIR

[Ed Bartosh]

STAGING_DIR variable is used to get path to a boot dir.
It's better to use wic-tools recipe to it as it contains
all bootloader artifacts.

Modified test_build_artifacts and test_rootfs_artifacts to
use wic-tools target to get STAGING_DIR.

Signed-off-by: Ed Bartosh 
---
 meta/lib/oeqa/selftest/wic.py | 18 --
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/meta/lib/oeqa/selftest/wic.py b/meta/lib/oeqa/selftest/wic.py
index 39ec5a2..417ba3d 100644
--- a/meta/lib/oeqa/selftest/wic.py
+++ b/meta/lib/oeqa/selftest/wic.py
@@ -212,9 +212,12 @@ class Wic(oeSelfTest):
 @testcase(1212)
 def test_build_artifacts(self):
 """Test wic create directdisk providing all artifacts."""
-bbvars = dict((var.lower(), get_bb_var(var, 'core-image-minimal'))
-  for var in ('STAGING_DATADIR', 'DEPLOY_DIR_IMAGE', 
'IMAGE_ROOTFS'))
-bbvars['recipe_sysroot_native'] = get_bb_var('RECIPE_SYSROOT_NATIVE', 
'wic-tools')
+variables = (('STAGING_DATADIR', 'wic-tools'),
+ ('RECIPE_SYSROOT_NATIVE', 'wic-tools'),
+ ('DEPLOY_DIR_IMAGE', 'core-image-minimal'),
+ ('IMAGE_ROOTFS', 'core-image-minimal'))
+bbvars = {var.lower(): get_bb_var(var, recipe) \
+  for var, recipe in variables}
 bbvars['resultdir'] = self.resultdir
 status = runCmd("wic create directdisk "
 "-b %(staging_datadir)s "
@@ -318,9 +321,12 @@ class Wic(oeSelfTest):
 @testcase(1269)
 def test_rootfs_artifacts(self):
 """Test usage of rootfs plugin with rootfs paths"""
-bbvars = dict((var.lower(), get_bb_var(var, 'core-image-minimal'))
-  for var in ('STAGING_DATADIR', 'DEPLOY_DIR_IMAGE', 
'IMAGE_ROOTFS'))
-bbvars['recipe_sysroot_native'] = get_bb_var('RECIPE_SYSROOT_NATIVE', 
'wic-tools')
+variables = (('STAGING_DATADIR', 'wic-tools'),
+ ('RECIPE_SYSROOT_NATIVE', 'wic-tools'),
+ ('DEPLOY_DIR_IMAGE', 'core-image-minimal'),
+ ('IMAGE_ROOTFS', 'core-image-minimal'))
+bbvars = {var.lower(): get_bb_var(var, recipe) \
+  for var, recipe in variables}
 bbvars['wks'] = "directdisk-multi-rootfs"
 bbvars['resultdir'] = self.resultdir
 status = runCmd("wic create %(wks)s "
-- 
2.1.4

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

Re: [OE-core] whatever happened to a proposal for "read-only" sstate?

[Robert P. J. Day]

On Fri, 3 Feb 2017, Richard Purdie wrote:

> On Fri, 2017-02-03 at 06:45 -0500, Robert P. J. Day wrote:
> >   for purposes of teaching, i wanted to check into the feasibility of
> > having students take advantage of a single shared state cache, but
> > still have the option of building whatever source they needed in
> > their
> > own *personal* sstate cache.
> >
> >   i found this reference from 2014:
> >
> > http://lists.openembedded.org/pipermail/openembedded-core/2014-August
> > /096486.html
> >
> > but it seems clear nothing became of it; there's certainly no
> > .bbclass
> > file that matches that.
> >
> >   what are the options for setting up something like this? or is that
> > already supported and i'm just not seeing it?
>
> It was never merged as its not really necessary, you can do this with
> existing functionality.
>
> Just point SSTATE_MIRRORS at the common shared directory and
> SSTATE_DIR at the directory you want to be the personal one.

  ah, and that solves my problem entirely. thanks.

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] whatever happened to a proposal for "read-only" sstate?

[Richard Purdie]

On Fri, 2017-02-03 at 06:45 -0500, Robert P. J. Day wrote:
>   for purposes of teaching, i wanted to check into the feasibility of
> having students take advantage of a single shared state cache, but
> still have the option of building whatever source they needed in
> their
> own *personal* sstate cache.
> 
>   i found this reference from 2014:
> 
> http://lists.openembedded.org/pipermail/openembedded-core/2014-August
> /096486.html
> 
> but it seems clear nothing became of it; there's certainly no
> .bbclass
> file that matches that.
> 
>   what are the options for setting up something like this? or is that
> already supported and i'm just not seeing it?

It was never merged as its not really necessary, you can do this with
existing functionality.

Just point SSTATE_MIRRORS at the common shared directory and SSTATE_DIR
at the directory you want to be the personal one.

Cheers,

Richard

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

Re: [OE-core] [PATCH] [RFC]kernel-yocto.bbclass: ensure repatching when HEAD is checked out

[Bruce Ashfield]

On Fri, Feb 3, 2017 at 5:49 AM, Awais Belal  wrote:

> In some cases it is seen that kernel_checkout and
> validate_branches are run again in simultaneous builds.
> During do_patch the kgit-s2q mechanism creates and
> checks for the kgit-s2q.last file inside the .git
> directory, finds a fence post and starts picking up
> patches after that. This can create trouble as
> validate_branches checks out the HEAD of the branch
> and so the patches should be reapplied rather than
> skipped due to finding of the fence post.
>

Indeed. I can see how this could happen. I added the mechanism to ensure
that multiple runs (forced or not) didn't re-patch the tree (since the
tools no
longer do an auto-resume detection).

At that time, I tried to run the paths and make sure that the sentinel file
couldn't cause this sort of problem, but clearly there is a case.

I'll grab this patch and modify it a bit so the script can clear the file
itself
(that way if the format changes again, we don't have to tweak the bbclass).

I'll float that patch by you, if that is ok, so you can add a Signed-off-by
(since the work on finding the issue deserves credit on the patch itself).

Cheers,

Bruce


>
> Signed-off-by: Awais Belal 
> ---
>  meta/classes/kernel-yocto.bbclass | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/meta/classes/kernel-yocto.bbclass b/meta/classes/
> kernel-yocto.bbclass
> index 5cfd8af..131c48a 100644
> --- a/meta/classes/kernel-yocto.bbclass
> +++ b/meta/classes/kernel-yocto.bbclass
> @@ -350,6 +350,10 @@ do_validate_branches() {
> current_branch=`git rev-parse --abbrev-ref HEAD`
> git branch "$current_branch-orig"
> git reset --hard ${force_srcrev}
> +   # We've checked out HEAD, make sure we cleanup
> kgit-s2q fence post check
> +   # so the patches are applied as expected otherwise
> no patching
> +   # would be done in some corner cases.
> +   rm -rf ${S}/.git/kgit-s2q.last
> fi
> fi
>  }
> --
> 1.9.1
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end"
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] wic: isoimage-isohybrid: use wic-tools to get syslinux path

[Ed Bartosh]

wic-tools recipe specific sysroot contains syslinux as wic-tools
depends on it. Used wic-tools target to get syslinux path should
guarantee that syslinux is installed there and can be used.

Signed-off-by: Ed Bartosh 
---
 scripts/lib/wic/plugins/source/isoimage-isohybrid.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/lib/wic/plugins/source/isoimage-isohybrid.py 
b/scripts/lib/wic/plugins/source/isoimage-isohybrid.py
index 56bb62d..ca28bc0 100644
--- a/scripts/lib/wic/plugins/source/isoimage-isohybrid.py
+++ b/scripts/lib/wic/plugins/source/isoimage-isohybrid.py
@@ -410,7 +410,7 @@ class IsoImagePlugin(SourcePlugin):
 exec_cmd(chmod_cmd)
 
 # Prepare files for legacy boot
-syslinux_dir = get_bitbake_var("STAGING_DATADIR")
+syslinux_dir = get_bitbake_var("STAGING_DATADIR", "wic-tools")
 if not syslinux_dir:
 msger.error("Couldn't find STAGING_DATADIR, exiting.\n")
 
-- 
2.1.4

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

Re: [OE-core] [PATCH 4/4] libgcrypt.inc: Enable use of binconfig

[Nathan Rossi]

On 3 February 2017 at 00:17, Burton, Ross  wrote:
>
> On 30 January 2017 at 07:47, Nathan Rossi  wrote:
>>
>> Due to pkg-config support for libgcrypt being un-available for upstream
>> libgcrypt, some packages that depend on libgcrypt rely on the use of
>> libgcrypt-config (e.g. QEMU).
>
>
> We disable those scripts for a good reason: they're generally either broken
> entirely in a cross-environment, or fail badly if sstate is used.A
> better solution really is to just patch qemu's configure (yes, I know this
> sucks).
>

Agreed, at first that was the approach I went for, even went so far as
to sending a patch upstream for QEMU (before realizing that libgcrypt
upstream doesn't have pkgconfig). But upstream QEMU are not to
interested in having such change.

https://patchwork.ozlabs.org/patch/711018/

However since this is not really required for the QEMU in oe-core,
this patch can be dropped from the series and I will sort this out by
patching the configure in the QEMU recipe that needs this.

Should I send a v2 of this series which removes this patch?

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

Re: [OE-core] RSS difficulties

[Phil Blundell]

On Fri, 2017-02-03 at 11:20 +, Richard Purdie wrote:
> 
> It comes down to what setscene_depvalid() in sstate.bbclass returns.
> If
> that returns False a given dependency is installed, it if returns
> True,
> it is skipped and not installed.
> 
> Reading that function should give some clues as to the logic it
> applies. It operates not on a full task graph but on version
> collapsed
> only to sstate tasks.

Ah, right, thanks.  The particular piece of magic I was missing was:

# Nothing need depend on libc-initial/gcc-cross-initial
if "-initial" in taskdependees[task][0]:
continue

which I think explains all the difficulties I was having.

p.

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

[OE-core] Want to strip rootfs

[ANDANI PRASHANT]

Hi,

I build rootfs which size is 100MB+
As i look in to filesystem, there are 14mb libc-2.23.so, 12mb
libstdc++.so.6.0.22,..etc.
Is there any flag or option during build to strip all library and binary to
optimise size of rootfs.

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

Re: [OE-core] [PATCH] pulseaudio: 9.0 -> 10.0

[Tanu Kaskinen]

On Fri, 2017-02-03 at 13:42 +0200, Alexander Kanavin wrote:
> On 02/03/2017 09:06 AM, Tanu Kaskinen wrote:
> > 
> > Dropped json-c and gdbm from DEPENDS. The new release doesn't use json-c
> > any more. gdbm isn't used when --with-database=simple is passed to
> > configure, so it should have been removed from DEPENDS a long time ago.
> 
> Does anything else in oe-core still use json-c? We're generally trying 
> to trim such dangling recipes.

According to "git grep json-c", the only thing still using it is
systemtap.

-- 
Tanu

https://www.patreon.com/tanuk
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] whatever happened to a proposal for "read-only" sstate?

[Robert P. J. Day]

  for purposes of teaching, i wanted to check into the feasibility of
having students take advantage of a single shared state cache, but
still have the option of building whatever source they needed in their
own *personal* sstate cache.

  i found this reference from 2014:

http://lists.openembedded.org/pipermail/openembedded-core/2014-August/096486.html

but it seems clear nothing became of it; there's certainly no .bbclass
file that matches that.

  what are the options for setting up something like this? or is that
already supported and i'm just not seeing it?

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

Re: [OE-core] [PATCH] pulseaudio: 9.0 -> 10.0

[Alexander Kanavin]

On 02/03/2017 09:06 AM, Tanu Kaskinen wrote:


Dropped json-c and gdbm from DEPENDS. The new release doesn't use json-c
any more. gdbm isn't used when --with-database=simple is passed to
configure, so it should have been removed from DEPENDS a long time ago.


Does anything else in oe-core still use json-c? We're generally trying 
to trim such dangling recipes.



Alex

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

Re: [OE-core] RSS difficulties

[Richard Purdie]

On Fri, 2017-02-03 at 11:10 +, Phil Blundell wrote:
> I'm having a few problems adapting our build setup to work with
> recipe specific sysroots.  More specifically, I am finding it
> difficult to get the correct set of components installed into the
> recipe-sysroot in all cases.  In some cases I am getting too much
> (which causes build failures if oe attempts to stage two things that
> install the same file) and in other cases I am not getting enough.
> 
> Could somebody explain, ideally using only small words, how the set
> of things to populate in the recipe-sysroot is determined?  I assume
> it is based on the task dependency graph somehow but I'm not quite
> sure which relationships I ought to be looking at.

It comes down to what setscene_depvalid() in sstate.bbclass returns. If
that returns False a given dependency is installed, it if returns True,
it is skipped and not installed.

Reading that function should give some clues as to the logic it
applies. It operates not on a full task graph but on version collapsed
only to sstate tasks.

The logic should mirror what would get installed from sstate if that
sstate were available, hence the logic is somewhat tested and not just
new for RSS. That doesn't mean its right in all cases though!

If that doesn't help, perhaps some specific examples of what you think
should be being installed and isn't or things which are being installed
and shouldn't might help.

Cheers,

Richard


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

[OE-core] RSS difficulties

[Phil Blundell]

I'm having a few problems adapting our build setup to work with recipe
specific sysroots.  More specifically, I am finding it difficult to get
the correct set of components installed into the recipe-sysroot in all
cases.  In some cases I am getting too much (which causes build
failures if oe attempts to stage two things that install the same file)
and in other cases I am not getting enough.

Could somebody explain, ideally using only small words, how the set of
things to populate in the recipe-sysroot is determined?  I assume it is
based on the task dependency graph somehow but I'm not quite sure which
relationships I ought to be looking at.

thanks

p.

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

[OE-core] [PATCH] [RFC]kernel-yocto.bbclass: ensure repatching when HEAD is checked out

[Awais Belal]

In some cases it is seen that kernel_checkout and
validate_branches are run again in simultaneous builds.
During do_patch the kgit-s2q mechanism creates and
checks for the kgit-s2q.last file inside the .git
directory, finds a fence post and starts picking up
patches after that. This can create trouble as
validate_branches checks out the HEAD of the branch
and so the patches should be reapplied rather than
skipped due to finding of the fence post.

Signed-off-by: Awais Belal 
---
 meta/classes/kernel-yocto.bbclass | 4 
 1 file changed, 4 insertions(+)

diff --git a/meta/classes/kernel-yocto.bbclass 
b/meta/classes/kernel-yocto.bbclass
index 5cfd8af..131c48a 100644
--- a/meta/classes/kernel-yocto.bbclass
+++ b/meta/classes/kernel-yocto.bbclass
@@ -350,6 +350,10 @@ do_validate_branches() {
current_branch=`git rev-parse --abbrev-ref HEAD`
git branch "$current_branch-orig"
git reset --hard ${force_srcrev}
+   # We've checked out HEAD, make sure we cleanup kgit-s2q 
fence post check
+   # so the patches are applied as expected otherwise no 
patching
+   # would be done in some corner cases.
+   rm -rf ${S}/.git/kgit-s2q.last
fi
fi
 }
-- 
1.9.1

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

[OE-core] [PATCH 2/2] oeqa/buildproject: Run gnu-configize by default

[Richard Purdie]

The runtime oeqa tests were failing in the on-target case, only for
aarch64. This was because an old config.sub was being used.

Similar to the SDK testing, call gnu-configize in the on-target
case too to resolve the failing tests.

Signed-off-by: Richard Purdie 
---
 meta/lib/oeqa/sdk/utils/sdkbuildproject.py | 2 +-
 meta/lib/oeqa/utils/buildproject.py| 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/lib/oeqa/sdk/utils/sdkbuildproject.py 
b/meta/lib/oeqa/sdk/utils/sdkbuildproject.py
index 4e4e507..4e25114 100644
--- a/meta/lib/oeqa/sdk/utils/sdkbuildproject.py
+++ b/meta/lib/oeqa/sdk/utils/sdkbuildproject.py
@@ -29,7 +29,7 @@ class SDKBuildProject(BuildProject):
 #Change targetdir to project folder
 self.targetdir = os.path.join(self.targetdir, self.fname)
 
-def run_configure(self, configure_args='', extra_cmds=' gnu-configize; '):
+def run_configure(self, configure_args='', extra_cmds=''):
 return super(SDKBuildProject, 
self).run_configure(configure_args=(configure_args or '$CONFIGURE_FLAGS'), 
extra_cmds=extra_cmds)
 
 def run_install(self, install_args=''):
diff --git a/meta/lib/oeqa/utils/buildproject.py 
b/meta/lib/oeqa/utils/buildproject.py
index b3c487b..fc8879c 100644
--- a/meta/lib/oeqa/utils/buildproject.py
+++ b/meta/lib/oeqa/utils/buildproject.py
@@ -39,7 +39,7 @@ class BuildProject(metaclass=ABCMeta):
 # The timeout parameter of target.run is set to 0 to make the ssh command
 # run with no timeout.
 def run_configure(self, configure_args='', extra_cmds=''):
-return self._run('cd %s; %s ./configure %s' % (self.targetdir, 
extra_cmds, configure_args))
+return self._run('cd %s; gnu-configize; %s ./configure %s' % 
(self.targetdir, extra_cmds, configure_args))
 
 def run_make(self, make_args=''):
 return self._run('cd %s; make %s' % (self.targetdir, make_args))
-- 
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] oeqa/runtime: Improve failure log output

[Richard Purdie]

Printing a message which says "configure failed" without the log output
is effectively useless. If a command fails, print the output by default
and simplify the calling code which makes debugging any of these failures
much easier.

Signed-off-by: Richard Purdie 
---
 meta/lib/oeqa/runtime/cases/buildcvs.py   | 11 +++
 meta/lib/oeqa/runtime/cases/buildgalculator.py|  7 ++-
 meta/lib/oeqa/runtime/cases/buildiptables.py  | 11 +++
 meta/lib/oeqa/runtime/utils/targetbuildproject.py |  6 +-
 4 files changed, 13 insertions(+), 22 deletions(-)

diff --git a/meta/lib/oeqa/runtime/cases/buildcvs.py 
b/meta/lib/oeqa/runtime/cases/buildcvs.py
index 341eb49..c3f3acc 100644
--- a/meta/lib/oeqa/runtime/cases/buildcvs.py
+++ b/meta/lib/oeqa/runtime/cases/buildcvs.py
@@ -25,11 +25,6 @@ class BuildCvsTest(OERuntimeTestCase):
   'Test requires tools-sdk to be in IMAGE_FEATURES')
 @OETestDepends(['ssh.SSHTest.test_ssh'])
 def test_cvs(self):
-self.assertEqual(self.project.run_configure(), 0,
-msg="Running configure failed")
-
-self.assertEqual(self.project.run_make(), 0,
-msg="Running make failed")
-
-self.assertEqual(self.project.run_install(), 0,
-msg="Running make install failed")
+self.project.run_configure()
+self.project.run_make()
+self.project.run_install()
diff --git a/meta/lib/oeqa/runtime/cases/buildgalculator.py 
b/meta/lib/oeqa/runtime/cases/buildgalculator.py
index 0bd76f9..7c9d4a3 100644
--- a/meta/lib/oeqa/runtime/cases/buildgalculator.py
+++ b/meta/lib/oeqa/runtime/cases/buildgalculator.py
@@ -24,8 +24,5 @@ class GalculatorTest(OERuntimeTestCase):
   'Test requires tools-sdk to be in IMAGE_FEATURES')
 @OETestDepends(['ssh.SSHTest.test_ssh'])
 def test_galculator(self):
-self.assertEqual(self.project.run_configure(), 0,
-msg="Running configure failed")
-
-self.assertEqual(self.project.run_make(), 0,
-msg="Running make failed")
+self.project.run_configure()
+self.project.run_make()
diff --git a/meta/lib/oeqa/runtime/cases/buildiptables.py 
b/meta/lib/oeqa/runtime/cases/buildiptables.py
index bae8039..002b16c 100644
--- a/meta/lib/oeqa/runtime/cases/buildiptables.py
+++ b/meta/lib/oeqa/runtime/cases/buildiptables.py
@@ -25,14 +25,9 @@ class BuildIptablesTest(OERuntimeTestCase):
   'Test requires tools-sdk to be in IMAGE_FEATURES')
 @OETestDepends(['ssh.SSHTest.test_ssh'])
 def test_iptables(self):
-self.assertEqual(self.project.run_configure(), 0,
-msg="Running configure failed")
-
-self.assertEqual(self.project.run_make(), 0,
-msg="Running make failed")
-
-self.assertEqual(self.project.run_install(), 0,
-msg="Running make install failed")
+self.project.run_configure()
+self.project.run_make()
+self.project.run_install()
 
 @classmethod
 def tearDownClass(self):
diff --git a/meta/lib/oeqa/runtime/utils/targetbuildproject.py 
b/meta/lib/oeqa/runtime/utils/targetbuildproject.py
index 1ed5789..551b0b6 100644
--- a/meta/lib/oeqa/runtime/utils/targetbuildproject.py
+++ b/meta/lib/oeqa/runtime/utils/targetbuildproject.py
@@ -33,4 +33,8 @@ class TargetBuildProject(BuildProject):
 # The timeout parameter of target.run is set to 0
 # to make the ssh command run with no timeout.
 def _run(self, cmd):
-return self.target.run(cmd, 0)[0]
+ret = self.target.run(cmd, 0)
+msg = "Command %s failed with exit code %s: %s" % (cmd, ret[0], ret[1])
+if ret[0] != 0:
+raise Exception(msg)
+return ret[0]
-- 
2.7.4

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

[OE-core] [PATCH] oeqa.buildperf: reword test descriptions

[Markus Lehtonen]

In an attempt to make them more compact and coherent.

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

diff --git a/meta/lib/oeqa/buildperf/test_basic.py 
b/meta/lib/oeqa/buildperf/test_basic.py
index 7a48c1e..4711830 100644
--- a/meta/lib/oeqa/buildperf/test_basic.py
+++ b/meta/lib/oeqa/buildperf/test_basic.py
@@ -22,7 +22,7 @@ class Test1P1(BuildPerfTestCase):
 build_target = 'core-image-sato'
 
 def test1(self):
-"""Measure wall clock of bitbake core-image-sato and size of tmp dir"""
+"""Build core-image-sato"""
 self.rm_tmp()
 self.rm_sstate()
 self.rm_cache()
@@ -36,7 +36,7 @@ class Test1P2(BuildPerfTestCase):
 build_target = 'virtual/kernel'
 
 def test12(self):
-"""Measure bitbake virtual/kernel"""
+"""Build virtual/kernel"""
 # Build and cleans state in order to get all dependencies pre-built
 self.log_cmd_output(['bitbake', self.build_target])
 self.log_cmd_output(['bitbake', self.build_target, '-c', 
'cleansstate'])
@@ -72,7 +72,7 @@ class Test2(BuildPerfTestCase):
 build_target = 'core-image-sato'
 
 def test2(self):
-"""Measure bitbake core-image-sato -c rootfs with sstate"""
+"""Run core-image-sato do_rootfs with sstate"""
 # Build once in order to populate sstate cache
 self.log_cmd_output(['bitbake', self.build_target])
 
@@ -86,7 +86,7 @@ class Test2(BuildPerfTestCase):
 class Test3(BuildPerfTestCase):
 
 def test3(self):
-"""Parsing time metrics (bitbake -p)"""
+"""Bitbake parsing (bitbake -p)"""
 # Drop all caches and parse
 self.rm_cache()
 oe.path.remove(os.path.join(self.bb_vars['TMPDIR'], 'cache'), True)
-- 
2.6.6

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