date:20160830

[OE-core] [PATCH] perl: correct the path of perl used by ptest

2016-08-30 Thread Zhenbo Gao

some files from perl-ptest depends on perl, which is located at /usr/bin/

Signed-off-by: Zhenbo Gao 
---
 meta/recipes-devtools/perl/perl-ptest.inc | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/meta/recipes-devtools/perl/perl-ptest.inc 
b/meta/recipes-devtools/perl/perl-ptest.inc
index d136c5c..94e40e6 100644
--- a/meta/recipes-devtools/perl/perl-ptest.inc
+++ b/meta/recipes-devtools/perl/perl-ptest.inc
@@ -24,6 +24,12 @@ do_install_ptest () {
 
ln -sf ${bindir}/perl ${D}${PTEST_PATH}/t/perl
 
+   # perl is located at /usr/bin/
+   p='^#![/.]*perl'
+   files=`grep -E ${p} ${D} -nr | grep -v -E 'Binary|win32' | cut -d ':' 
-f 1`
+   for f in ${files}; do
+   sed -i -e "s:${p}:#! ${USRBINPATH}/perl:g" ${f}
+   done
 }
 
 python populate_packages_prepend() {
-- 
1.9.1

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

Re: [OE-core] [PATCH 00/17] control ipv6 support based on DISTRO_FEATURES

2016-08-30 Thread Huang, Jie (Jackie)

Ping.

I don't see a comment or rejection on these, will these be merged soon?

Thanks,
Jackie

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org 
> [mailto:openembedded-core-
> boun...@lists.openembedded.org] On Behalf Of jackie.hu...@windriver.com
> Sent: Monday, August 22, 2016 5:06 PM
> To: openembedded-core@lists.openembedded.org
> Subject: [OE-core] [PATCH 00/17] control ipv6 support based on DISTRO_FEATURES
> 
> From: Jackie Huang 
> 
> There is ipv6 configure option for these packages, and we need to them
> to be controled by DISTRO_FEATURES.
> 
> Tested with and without ipv6 in DISTRO_FEATURES on qemux86-64 and qemuarm.
> 
> --
> The following changes since commit f078ccf1ac60488169853724c35126cc056f975d:
> 
>   bitbake: siggen: Fix file variable typo in compare_sigfiles (2016-08-20 
> 16:11:29 +0100)
> 
> are available in the git repository at:
> 
>   git://git.pokylinux.org/poky-contrib.git jhuang0/r_ipv6_160822_0
>   http://git.pokylinux.org/cgit.cgi//log/?h=jhuang0/r_ipv6_160822_0
> 
> Jackie Huang (17):
>   apr: control ipv6 support based on DISTRO_FEATURES
>   libice: control ipv6 support based on DISTRO_FEATURES
>   libpcap: control ipv6 support based on DISTRO_FEATURES
>   libsm: control ipv6 support based on DISTRO_FEATURES
>   libxfont: control ipv6 support based on DISTRO_FEATURES
>   libxml2: control ipv6 support based on DISTRO_FEATURES
>   libxmu: control ipv6 support based on DISTRO_FEATURES
>   lighttpd: control ipv6 support based on DISTRO_FEATURES
>   nfs-utils: control ipv6 support based on DISTRO_FEATURES
>   nspr: control ipv6 support based on DISTRO_FEATURES
>   psmisc: control ipv6 support based on DISTRO_FEATURES
>   pulseaudio: control ipv6 support based on DISTRO_FEATURES
>   rsync: use rsync.inc to avoid duplicated codes
>   rsync: control ipv6 support based on DISTRO_FEATURES
>   wget: control ipv6 support based on DISTRO_FEATURES
>   xauth: control ipv6 support based on DISTRO_FEATURES
>   xhost: control ipv6 support based on DISTRO_FEATURES
> 
>  meta/recipes-connectivity/libpcap/libpcap.inc  |  5 -
>  .../nfs-utils/nfs-utils_1.3.3.bb   |  5 -
>  meta/recipes-core/libxml/libxml2_2.9.4.bb  |  5 -
>  meta/recipes-devtools/rsync/rsync.inc  |  7 ++
>  meta/recipes-devtools/rsync/rsync_2.6.9.bb | 25 
> ++
>  meta/recipes-devtools/rsync/rsync_3.1.2.bb |  8 ++-
>  meta/recipes-extended/lighttpd/lighttpd_1.4.39.bb  |  5 -
>  meta/recipes-extended/psmisc/psmisc.inc|  3 +++
>  meta/recipes-extended/wget/wget.inc|  5 +++--
>  meta/recipes-graphics/xorg-app/xauth_1.0.9.bb  |  3 +++
>  meta/recipes-graphics/xorg-app/xhost_1.0.7.bb  |  3 +++
>  meta/recipes-graphics/xorg-lib/libice_1.0.9.bb |  3 ++-
>  meta/recipes-graphics/xorg-lib/libsm_1.2.2.bb  |  3 +++
>  meta/recipes-graphics/xorg-lib/libxfont_1.5.1.bb   |  3 +++
>  meta/recipes-graphics/xorg-lib/libxmu_1.1.2.bb |  3 +++
>  meta/recipes-multimedia/pulseaudio/pulseaudio.inc  |  2 ++
>  meta/recipes-support/apr/apr_1.5.2.bb  |  3 +++
>  meta/recipes-support/nspr/nspr_4.12.bb |  3 +++
>  18 files changed, 62 insertions(+), 32 deletions(-)
> 
> --
> 2.8.1
> 
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] ltp: remove useless script STPfailure_report.pl

2016-08-30 Thread mingli.yu

From: Mingli Yu 

* Remove useless script STPfailure_report.pl to
  avoid confusing about this script fails to run
  as it lacks dependency on some perl module such
  as LWP::Simple

  - The script STPfailure_report.pl previously is
added as a tool to analyze failures from LTP
runs on the OSDL's Scaleable Test Platform (STP) as below:

commit f0573facbbbf14798cc5b7d4653a5e46b4b95fa5
Author: robbiew 
Date: Wed Apr 28 19:21:39 2004 +

Added tool for analyzing failures from LTP runs on
the OSDL's Scaleable Test Platform (STP)

  - And the script STPfailure_report.pl mainly accesses
http://khack.osdl.org to retrieve ltp test results
run on OSDL's Scaleable Test Platform (STP) and prints
the reports, and now the website http://khack.osdl.org
not accessible, so the script is useless and drop it
and not ship it on target system

Signed-off-by: Mingli Yu 
---
 meta/recipes-extended/ltp/ltp_20160126.bb | 8 
 1 file changed, 8 insertions(+)

diff --git a/meta/recipes-extended/ltp/ltp_20160126.bb 
b/meta/recipes-extended/ltp/ltp_20160126.bb
index 278f492..7631e0e 100644
--- a/meta/recipes-extended/ltp/ltp_20160126.bb
+++ b/meta/recipes-extended/ltp/ltp_20160126.bb
@@ -92,6 +92,14 @@ do_install(){
 install -d ${D}/opt/ltp/
 oe_runmake DESTDIR=${D} SKIP_IDCHECK=1 install
 
+# fixup not deploy STPfailure_report.pl to avoid confusing about it fails 
to run
+# as it lacks dependency on some perl moudle such as LWP::Simple
+# And this script previously works as a tool for analyzing failures from 
LTP
+# runs on the OSDL's Scaleable Test Platform (STP) and it mainly accesses
+# http://khack.osdl.org to retrieve ltp test results run on
+# OSDL's Scaleable Test Platform, but now http://khack.osdl.org 
unaccessible
+rm -rf ${D}/opt/ltp/bin/STPfailure_report.pl
+
 # Copy POSIX test suite into ${D}/opt/ltp/testcases by manual
 cp -r testcases/open_posix_testsuite ${D}/opt/ltp/testcases
 }
-- 
2.8.1

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

[OE-core] [PATCH 1/2] scripts: ensure tinfoil is shut down correctly

2016-08-30 Thread Paul Eggleton

We should always shut down tinfoil when we're finished with it, either
by explicitly calling the shutdown() method or by using it as a
context manager ("with ...").

Signed-off-by: Paul Eggleton 
---
 scripts/contrib/list-packageconfig-flags.py |  28 +--
 scripts/contrib/verify-homepage.py  |  12 +-
 scripts/devtool |  10 +-
 scripts/lib/devtool/build_image.py  | 124 +-
 scripts/lib/devtool/deploy.py   | 141 ++--
 scripts/lib/devtool/runqemu.py  |   8 +-
 scripts/lib/devtool/standard.py | 341 ++--
 scripts/lib/devtool/upgrade.py  |  85 +++
 scripts/oe-pkgdata-util |   5 +-
 scripts/recipetool  |  63 ++---
 10 files changed, 423 insertions(+), 394 deletions(-)

diff --git a/scripts/contrib/list-packageconfig-flags.py 
b/scripts/contrib/list-packageconfig-flags.py
index b8327e4..1af7de3 100755
--- a/scripts/contrib/list-packageconfig-flags.py
+++ b/scripts/contrib/list-packageconfig-flags.py
@@ -160,20 +160,20 @@ def main():
 
 options, args = parser.parse_args(sys.argv)
 
-bbhandler = bb.tinfoil.Tinfoil()
-bbhandler.prepare()
-print("Gathering recipe data...")
-data_dict = get_recipesdata(bbhandler, options.preferred)
-
-if options.listtype == 'flags':
-pkg_dict = collect_pkgs(data_dict)
-flag_dict = collect_flags(pkg_dict)
-display_flags(flag_dict)
-elif options.listtype == 'recipes':
-pkg_dict = collect_pkgs(data_dict)
-display_pkgs(pkg_dict)
-elif options.listtype == 'all':
-display_all(data_dict)
+with bb.tinfoil.Tinfoil() as bbhandler:
+bbhandler.prepare()
+print("Gathering recipe data...")
+data_dict = get_recipesdata(bbhandler, options.preferred)
+
+if options.listtype == 'flags':
+pkg_dict = collect_pkgs(data_dict)
+flag_dict = collect_flags(pkg_dict)
+display_flags(flag_dict)
+elif options.listtype == 'recipes':
+pkg_dict = collect_pkgs(data_dict)
+display_pkgs(pkg_dict)
+elif options.listtype == 'all':
+display_all(data_dict)
 
 if __name__ == "__main__":
 main()
diff --git a/scripts/contrib/verify-homepage.py 
b/scripts/contrib/verify-homepage.py
index 61a047c4..04917e8 100755
--- a/scripts/contrib/verify-homepage.py
+++ b/scripts/contrib/verify-homepage.py
@@ -54,9 +54,9 @@ def verifyHomepage(bbhandler):
 return count
 
 if __name__=='__main__':
-bbhandler = bb.tinfoil.Tinfoil()
-bbhandler.prepare()
-logger.info("Start verifying HOMEPAGE:")
-failcount = verifyHomepage(bbhandler)
-logger.info("Finished verifying HOMEPAGE.")
-logger.info("Summary: %s failed" % failcount)
+with bb.tinfoil.Tinfoil() as bbhandler:
+bbhandler.prepare()
+logger.info("Start verifying HOMEPAGE:")
+failcount = verifyHomepage(bbhandler)
+logger.info("Finished verifying HOMEPAGE.")
+logger.info("Summary: %s failed" % failcount)
diff --git a/scripts/devtool b/scripts/devtool
index b1274d6..91e3954 100755
--- a/scripts/devtool
+++ b/scripts/devtool
@@ -289,17 +289,15 @@ def main():
 
 if global_args.bbpath is None:
 tinfoil = setup_tinfoil(config_only=True, basepath=basepath)
-global_args.bbpath = tinfoil.config_data.getVar('BBPATH', True)
-else:
-tinfoil = None
+try:
+global_args.bbpath = tinfoil.config_data.getVar('BBPATH', True)
+finally:
+tinfoil.shutdown()
 
 for path in [scripts_path] + global_args.bbpath.split(':'):
 pluginpath = os.path.join(path, 'lib', 'devtool')
 scriptutils.load_plugins(logger, plugins, pluginpath)
 
-if tinfoil:
-tinfoil.shutdown()
-
 subparsers = parser.add_subparsers(dest="subparser_name", 
title='subcommands', metavar='')
 subparsers.required = True
 
diff --git a/scripts/lib/devtool/build_image.py 
b/scripts/lib/devtool/build_image.py
index 14c646a..ae75511 100644
--- a/scripts/lib/devtool/build_image.py
+++ b/scripts/lib/devtool/build_image.py
@@ -86,70 +86,76 @@ def build_image_task(config, basepath, workspace, image, 
add_packages=None, task
 raise
 
 tinfoil = setup_tinfoil(basepath=basepath)
-rd = parse_recipe(config, tinfoil, image, True)
-if not rd:
-# Error already shown
-return (1, None)
-if not bb.data.inherits_class('image', rd):
-raise TargetNotImageError()
-
-# Get the actual filename used and strip the .bb and full path
-target_basename = rd.getVar('FILE', True)
-target_basename = os.path.splitext(os.path.basename(target_basename))[0]
-config.set('SDK', 'target_basename', target_basename)
-config.write()
-
-appendfile = os.path.join(config.workspace_path, 'appends',
-

[OE-core] [PATCH 0/2] Tinfoil usage fixes

2016-08-30 Thread Paul Eggleton

NOTE: the scripts/contrib/* patch requires the bitbake series I just
sent. We may wish to consider a bitbake version and required bitbake
version bump soon.


The following changes since commit 384cf92ca9c3e66763c2c1ff2776c53d47ae25d6:

  init-install: Fixes the install script failing when not finding any mmcblk 
devices (2016-08-30 07:57:46 +0100)

are available in the git repository at:

  git://git.openembedded.org/openembedded-core-contrib paule/tinfoil-fixes-oe
  
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=paule/tinfoil-fixes-oe

Paul Eggleton (2):
  scripts: ensure tinfoil is shut down correctly
  scripts/contrib: update scripts for changes to internal API

 scripts/contrib/devtool-stress.py   |   6 +-
 scripts/contrib/list-packageconfig-flags.py |  35 ++-
 scripts/contrib/verify-homepage.py  |  18 +-
 scripts/devtool |  10 +-
 scripts/lib/devtool/build_image.py  | 124 +-
 scripts/lib/devtool/deploy.py   | 141 ++--
 scripts/lib/devtool/runqemu.py  |   8 +-
 scripts/lib/devtool/standard.py | 341 ++--
 scripts/lib/devtool/upgrade.py  |  85 +++
 scripts/oe-pkgdata-util |   5 +-
 scripts/recipetool  |  63 ++---
 11 files changed, 432 insertions(+), 404 deletions(-)

-- 
2.5.5

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

[OE-core] [PATCH 2/2] scripts/contrib: update scripts for changes to internal API

2016-08-30 Thread Paul Eggleton

The multiconfig changes altered some of the functions being called here,
so update the calls. Make use of the new Tinfoil.parse_recipe_file()
function to make parsing easier.

Signed-off-by: Paul Eggleton 
---
 scripts/contrib/devtool-stress.py   | 6 +++---
 scripts/contrib/list-packageconfig-flags.py | 7 +++
 scripts/contrib/verify-homepage.py  | 6 +++---
 3 files changed, 9 insertions(+), 10 deletions(-)

diff --git a/scripts/contrib/devtool-stress.py 
b/scripts/contrib/devtool-stress.py
index 7ba0984..d555c51 100755
--- a/scripts/contrib/devtool-stress.py
+++ b/scripts/contrib/devtool-stress.py
@@ -43,15 +43,15 @@ def select_recipes(args):
 tinfoil = bb.tinfoil.Tinfoil()
 tinfoil.prepare(False)
 
-pkg_pn = tinfoil.cooker.recipecache.pkg_pn
-(latest_versions, preferred_versions) = 
bb.providers.findProviders(tinfoil.config_data, tinfoil.cooker.recipecache, 
pkg_pn)
+pkg_pn = tinfoil.cooker.recipecaches[''].pkg_pn
+(latest_versions, preferred_versions) = 
bb.providers.findProviders(tinfoil.config_data, 
tinfoil.cooker.recipecaches[''], pkg_pn)
 
 skip_classes = args.skip_classes.split(',')
 
 recipelist = []
 for pn in sorted(pkg_pn):
 pref = preferred_versions[pn]
-inherits = [os.path.splitext(os.path.basename(f))[0] for f in 
tinfoil.cooker.recipecache.inherits[pref[1]]]
+inherits = [os.path.splitext(os.path.basename(f))[0] for f in 
tinfoil.cooker.recipecaches[''].inherits[pref[1]]]
 for cls in skip_classes:
 if cls in inherits:
 break
diff --git a/scripts/contrib/list-packageconfig-flags.py 
b/scripts/contrib/list-packageconfig-flags.py
index 1af7de3..389fb97 100755
--- a/scripts/contrib/list-packageconfig-flags.py
+++ b/scripts/contrib/list-packageconfig-flags.py
@@ -37,7 +37,6 @@ if not bitbakepath:
 sys.stderr.write("Unable to find bitbake by searching parent directory of 
this script or PATH\n")
 sys.exit(1)
 
-import bb.cache
 import bb.cooker
 import bb.providers
 import bb.tinfoil
@@ -45,7 +44,7 @@ import bb.tinfoil
 def get_fnlist(bbhandler, pkg_pn, preferred):
 ''' Get all recipe file names '''
 if preferred:
-(latest_versions, preferred_versions) = 
bb.providers.findProviders(bbhandler.config_data, bbhandler.cooker.recipecache, 
pkg_pn)
+(latest_versions, preferred_versions) = 
bb.providers.findProviders(bbhandler.config_data, 
bbhandler.cooker.recipecaches[''], pkg_pn)
 
 fn_list = []
 for pn in sorted(pkg_pn):
@@ -58,11 +57,11 @@ def get_fnlist(bbhandler, pkg_pn, preferred):
 
 def get_recipesdata(bbhandler, preferred):
 ''' Get data of all available recipes which have PACKAGECONFIG flags '''
-pkg_pn = bbhandler.cooker.recipecache.pkg_pn
+pkg_pn = bbhandler.cooker.recipecaches[''].pkg_pn
 
 data_dict = {}
 for fn in get_fnlist(bbhandler, pkg_pn, preferred):
-data = bb.cache.Cache.loadDataFull(fn, 
bbhandler.cooker.collection.get_file_appends(fn), bbhandler.config_data)
+data = bbhandler.parse_recipe_file(fn)
 flags = data.getVarFlags("PACKAGECONFIG")
 flags.pop('doc', None)
 if flags:
diff --git a/scripts/contrib/verify-homepage.py 
b/scripts/contrib/verify-homepage.py
index 04917e8..d39dd1d 100755
--- a/scripts/contrib/verify-homepage.py
+++ b/scripts/contrib/verify-homepage.py
@@ -33,17 +33,17 @@ def wgetHomepage(pn, homepage):
 return 0
 
 def verifyHomepage(bbhandler):
-pkg_pn = bbhandler.cooker.recipecache.pkg_pn
+pkg_pn = bbhandler.cooker.recipecaches[''].pkg_pn
 pnlist = sorted(pkg_pn)
 count = 0
 checked = []
 for pn in pnlist:
 for fn in pkg_pn[pn]:
 # There's no point checking multiple BBCLASSEXTENDed variants of 
the same recipe
-realfn, _ = bb.cache.Cache.virtualfn2realfn(fn)
+realfn, _, _ = bb.cache.virtualfn2realfn(fn)
 if realfn in checked:
 continue
-data = bb.cache.Cache.loadDataFull(realfn, 
bbhandler.cooker.collection.get_file_appends(realfn), bbhandler.config_data)
+data = bbhandler.parse_recipe_file(realfn)
 homepage = data.getVar("HOMEPAGE", True)
 if homepage:
 try:
-- 
2.5.5

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

Re: [OE-core] [PATCH V5 00/10] runqemu: refactor it and remove machine knowledge

2016-08-30 Thread Robert Yang




On 08/31/2016 07:01 AM, Richard Purdie wrote:

On Thu, 2016-08-25 at 21:59 +, Randle, William C wrote:

On Thu, 2016-08-25 at 22:45 +0100, Burton, Ross wrote:

Hi Robert,

So close!  qemuarm64 is breaking on the AB:

https://autobuilder.yoctoproject.org/main/builders/nightly-arm64/bu
ilds/536/steps/Running%20Sanity%20Tests/logs/stdio

I suspect we're passing some options to runqemu that you didn't
cover in your testing.

Ross


It looks like it's just a missing space between the -m arg and
-device:
  -m 512-device


I added an attempt at a fix for this into -next FWIW


Thanks, I had fixed this in the repo, and the fix is the same as RP's,
I should reply to this thread, too, but sorry I replied to another thread:

Re: [OE-core] [PATCH V4 00/11] runqemu: refactor it and remove machine knowledge

// Robert



Cheers,

Richard


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

Re: [OE-core] [PATCH v2 2/3] oe.path: preserve xattr in copytree() and copyhardlinktree()

2016-08-30 Thread Mark Hatle

On 8/30/16 9:05 PM, Joshua Lock wrote:
> Pass appropriate options to tar invocations in copytree() and
> copyhardlinktree() to ensure that any extended attributes on the files
> are preserved during the copy.
> 
> We have to drop the use cpio in "Copy-pass" mode in copyhardlinktree()
> because cpio doesn't support extended attributes on files. Instead we
> revert back to using cp with different patterns depending on whether
> or not the directory contains dot files.
> 
> Signed-off-by: Joshua Lock 
> ---
>  meta/lib/oe/path.py | 11 ---
>  1 file changed, 8 insertions(+), 3 deletions(-)
> 
> diff --git a/meta/lib/oe/path.py b/meta/lib/oe/path.py
> index 3c07df3..631c3b4 100644
> --- a/meta/lib/oe/path.py
> +++ b/meta/lib/oe/path.py
> @@ -65,7 +65,7 @@ def copytree(src, dst):
>  # This way we also preserve hardlinks between files in the tree.
>  
>  bb.utils.mkdirhier(dst)
> -cmd = 'tar -cf - -C %s -p . | tar -xf - -C %s' % (src, dst)
> +cmd = "tar --xattrs --xattrs-include='*' -cf - -C %s -p . | tar --xattrs 
> --xattrs-include='*' -xf - -C %s" % (src, dst)
>  subprocess.check_output(cmd, shell=True, stderr=subprocess.STDOUT)
>  
>  def copyhardlinktree(src, dst):
> @@ -77,9 +77,14 @@ def copyhardlinktree(src, dst):
>  if (os.stat(src).st_dev ==  os.stat(dst).st_dev):
>  # Need to copy directories only with tar first since cp will error 
> if two 
>  # writers try and create a directory at the same time
> -cmd = 'cd %s; find . -type d -print | tar -cf - -C %s -p 
> --no-recursion --files-from - | tar -xf - -C %s' % (src, src, dst)
> +cmd = "cd %s; find . -type d -print | tar --xattrs 
> --xattrs-include='*' -cf - -C %s -p --no-recursion --files-from - | tar 
> --xattrs --xattrs-include='*' -xf - -C %s" % (src, src, dst)
>  subprocess.check_output(cmd, shell=True, stderr=subprocess.STDOUT)
> -cmd = 'cd %s; find . -print0 | cpio --null -pdlu %s' % (src, dst)
> +if os.path.isdir(src):
> +import glob
> +if len(glob.glob('%s/.??*' % src)) > 0:
> +src = src + '/.??* '
> +src = src + '/*'
> +cmd = 'cp -afl --preserve=xattr %s %s' % (src, dst)

'cp -a' is a gnu-ism.  I'm not sure if this will cause any problems, but it has
in the past when people have used non coreutils 'cp'.

(I'm not sure if we're using 'cp -a' anywhere, but I know most of the time we
try to use the discrete set of arguments instead as they're more POSIX.)

(Otherwise the change looks good to me.)

>  subprocess.check_output(cmd, shell=True, stderr=subprocess.STDOUT)
>  else:
>  copytree(src, dst)
> 

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

Re: [OE-core] [PATCH 0/9] linux-yocto: v4.8 + fixes + configuration updates + RFC

2016-08-30 Thread Cal Sullivan

I've built an intel-corei7-64 image with the new kernel. Looks good so 
far - booted on a MinnowBoard Turbot immediately with no new errors or 
warnings!


For anyone curious, preliminary recipes for meta-intel are available at 
meta-intel-contrib -b clsulliv/auto-srcrevs.


---
Cal

On 08/30/2016 09:48 AM, Bruce Ashfield wrote:

Hi all,

Here's the latest updates to the linux-yoco* baseline support. There are
three distinct blocks in the consolidated pull request, with the biggest
being the introduction of a 4.8 named kernel and 4.8 based libc-headers.

The others are fixes to the kernel-yocto processing and kernel meta data
updates. As such, these commits can be taken in isolation to the 4.8
update that I've included in the pull request.

   kernel-yocto: test for empty artifacts
   linux-yocto/4.x: configuration updates
   kernel-yocto: do_kernel_configme: Fix silent sysroot poisoning error

On the topic of the version 4.8:

   - This is the intended 'newest' kernel for the upcoming fall release
 cycle. We will have a shiny new one this time around.
 
   - yes it is a -rc4 release, but the version wasn't chosen by mistake

 (or lightly). It was the typical balancing act.
 
- It is nice to work through the development cycle of the

  upstream kernel, since we can send fixes in realtime to the
  mainline tree .. but this is the side effect of the choice,
  not the reason

- This version balances a new enough kernel, LTS/LTSI, -rt,
  platform updates (ARM/x86) and the timing of the release.

  The LTS/LTSI kernels are either too old at the moment, and
  won't get a port of major patch series like -rt. Hence why
  v4.8 shoots the difference between the options and gives us
  a good baseline to update in the upcoming months, and one that
  we can compliment with other kernel versions later.

   - The delta between any -rcX releases is small, so following this
 through until its release is not a big issue.

build/boot testing:

   - I've built and booted qemu* with core-image-sato, so it is known
 to build and have a sane runtime for all arches. I've also built
 the typical packages that misbehave (lttng, perf, etc).

   - The versatile platform switched to a device tree boot in the 4.7
 timeframe. As such, I had to patch runqemu to use a device tree
 .. and use that device tree conditionally, since we have to support
 older kernels at the same time as 4.7+

   - I know that there are pending changes to the way runqemu works, but
 I patched what I had in master .. these can be updated/adjusted if
 need be.

libc-headers update:

   - Since there are milestone builds coming up, I wanted to get the 4.8
 libc headers in place. Which meant that I had to do some different
 things to use the testing kernel tarball, and to get the version of
 the package right.

 This might cause us version stepping issues .. so anyone looking at
 this can suggest what I need to do to avoid them, and I can update
 and rebase the series with the proper fix.

The linux-yocto-4.8 repository:

   - There have been comments about the linux-yocto* repos filling up

 download directories, and consuming people's bandwidth.  Since we
 don't have a shallow clone or reference clone way to deal with the
 amount of shared kernel blobs, I've simultaneously generated a v4.8
 kernel in a repository that could be re-used over time.

   http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto/

 The proposal is that if we really want to avoid separate kernel trees,
 and keep the ability to rebase/remove/amend old commits to keep the
 tree clean, that I can insert the version number into the branches
 as a marker. Comments on this approach are welcome, since if we go this
 way, I need to adjust all the KBRANCH variables.

I'll follow up with commits to change the default qemu version to 4.8 once
there's general agreement about the options on this.

Cheers,

Bruce

The following changes since commit 2fedd226c3385f1ac160b3aa0bfadbded85e288c:

   ref-manual: Fixed small wording in PKGR in the glossary (2016-08-25 23:09:29 
+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 (8):
   linux-yocto: introduce v4.8 recipes
   perf: adapt to Makefile.config
   qemuarm: add device tree support
   linux-yocto-dev: bump to v4.8+
   libc-headers: update to v4.8
   linux-yocto/4.8: add qemuarm device tree specification
   kernel-yocto: test for empty artifacts
   linux-yocto/4.x: configuration updates

Ioan-Adrian Ratiu (1):
   kernel-yocto: do_kernel_configme: Fix silent sysroot poisoning error

  meta/classes/kernel-yocto.bbclass  | 12 --
  meta/conf/distro/include/tcmode-default.inc|  2 +-

Re: [OE-core] [PATCH] provide better error message when runqemu-ifup fails

2016-08-30 Thread Richard Purdie

On Mon, 2016-08-29 at 15:24 -0700, Stephano Cetola wrote:
> If runqemu-ifup fails hen running testimage, a rather cryptic error
> regarding "no tty present" is displayed. If this step fails, we
> should at least point the user at runqemu-gen-tapdevs. A quick search
> of this term in the manual will lead them to "Enabling Runtime Tests
> on QEMU" which should give them all the info they need.
> 
> Signed-off-by: Stephano Cetola 
> ---
>  scripts/runqemu-internal | 1 +
>  1 file changed, 1 insertion(+)

The shortlog needs a prefix, e.g. "scripts/runqemu:" and this patch
will likely need adapting on top of Robert's changes (see master-next).

Cheers,

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

Re: [OE-core] [PATCH V5 00/10] runqemu: refactor it and remove machine knowledge

2016-08-30 Thread Richard Purdie

On Thu, 2016-08-25 at 21:59 +, Randle, William C wrote:
> On Thu, 2016-08-25 at 22:45 +0100, Burton, Ross wrote:
> > Hi Robert,
> > 
> > So close!  qemuarm64 is breaking on the AB:
> > 
> > https://autobuilder.yoctoproject.org/main/builders/nightly-arm64/bu
> > ilds/536/steps/Running%20Sanity%20Tests/logs/stdio
> > 
> > I suspect we're passing some options to runqemu that you didn't
> > cover in your testing.
> > 
> > Ross
> > 
> It looks like it's just a missing space between the -m arg and 
> -device:
>   -m 512-device

I added an attempt at a fix for this into -next FWIW

Cheers,

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

Re: [OE-core] [PATCH v4] kernel.bbclass: include signing keys when copying files required for module builds

2016-08-30 Thread Richard Purdie

On Fri, 2016-08-26 at 20:58 +0200, Mattias Waldo wrote:
> The absence of certs/signing_key.* in $kerneldir made signing of
> out-of-tree kernel modules fail (silently). Add copying of these
> files during the shared_workdir task.
> 
> Signed-off-by: Mattias Waldo 
> ---
>  meta/classes/kernel.bbclass | 2 ++
>  1 file changed, 2 insertions(+)

Sadly this breaks the build when you don't have any keys:

e.g.: https://autobuilder.yoctoproject.org/main/builders/build-applianc
e/builds/892/steps/BuildImages_1/logs/stdio

but there were many many other failures :(

Cheers,

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

Re: [OE-core] [PATCH 08/15] gnutls: update to 3.5.3

2016-08-30 Thread Richard Purdie

On Mon, 2016-08-29 at 17:30 +0300, Alexander Kanavin wrote:
> Signed-off-by: Alexander Kanavin 
> ---
>  meta/recipes-support/gnutls/{gnutls_3.5.1.bb => gnutls_3.5.3.bb} | 4
> ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>  rename meta/recipes-support/gnutls/{gnutls_3.5.1.bb =>
> gnutls_3.5.3.bb} (60%)

http://errors.yoctoproject.org/Errors/Details/81202/

Cheers,

Richard

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

Re: [OE-core] Build of u-boot with gold is broken

2016-08-30 Thread Manjukumar Harthikote Matha


Hi All,

On 08/30/2016 02:57 AM, Andrew Goodbody wrote:

*From:*Burton, Ross 

On 19 August 2016 at 10:33, Andrew Goodbody
>
wrote:

The sed at line 70 fails as it is being executed in an empty build
directory and so there is no config.mk .



For fame and glory, can you send a tested patch to fix this?



Ross


Sorry but I am not sure about the best way to fix this.

Andrew



PS This is a resend (with additions below) as I neglected to copy the
list, sorry – I was out of the office at the time.

It would be possible to simply cd into the source directory, apply the
sed, then cd back to the build directory. However this seems to go
against the point of having a separate build directory in that you are
attempting to leave the source tree alone, or so I assume.


Can we do ${S}/config.mk ? Meaning
sed -i 's/$(CROSS_COMPILE)ld$/$(CROSS_COMPILE)ld.bfd/g' ${S}/config.mk
I dont have a setup for gold linker, If you can send the instructions I 
will give it a try


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

Re: [OE-core] gcc 6.1+ and isystem

2016-08-30 Thread Khem Raj

> On Aug 30, 2016, at 8:37 AM, Jack Mitchell  wrote:
> 
> Some of the headers shipped with gcc 6.1 and above now use #include_next to 
> try to and do clever things with munging system header files. Our injection 
> of isystem into the build at 'meta/conf/bitbake.conf' seems to be causing 
> some programs to fail to compile. A full explanation can be found at [1], a 
> bug report from GCC specifying that it should only be used in extreme cases 
> at [2].

you can say with isystem gcc let its users play smart things with its internal 
header search path order.

> 
> Since we seem to be adding -isystem unconditionally to BUILD_CFLAGS from 
> bitbake, and that the default behavior has now changed should this be 
> revisited? I'll admit that I am no where near experienced enough with GCC and 
> friends internals to make a call on this one, I'm just looking for some input.
> 

Yes, I am aware of this fact and there has been a change to remove -isystem 
from BUILDSDK_CPPFLAGS, the problem with
BUILD_CPPFLAGS is different since it was added intentionally to override the 
system headers is in direct conflict with
what -isystem use is recommended for. If we were just complementing the default 
system includedirs it would be different
however. Should be not use -isystem by default systemwide ? may be. but we need 
to understand the effects
where, we now more or less build host packages against our own staged headers 
and link/run them using the hosts
libraries and this combination has been working however ugly it may look like. 
It also means we are using same headers
across all host distros which is good but then we run the host apps against the 
host libraries, causing another combination
more than often host systems have injected bugs into tools ( e.g. cross 
compilers ) which have shown to exhibit on target
very hard to trace issues like such have happened.

Can we then just act as a fallback to provide missing headers, after system 
headers, it falls into same problems or ordering
and while the header might be found in build sysroot, another header that this 
header needs may be needed from system

may be some tests by removing this from build options could be tried out, 
native packages like qt5 and  python3
should be tested since those definitely play their own games with headers.

> Regards,
> Jack.
> 
> [1] 
> http://stackoverflow.com/questions/37218953/isystem-on-a-system-include-directory-causes-errors
> [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70129

signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] linux-firmware: Bump revision to 7534e19

2016-08-30 Thread Fabio Berton

Signed-off-by: Fabio Berton 
---
 meta/recipes-kernel/linux-firmware/linux-firmware_git.bb | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb 
b/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
index ed0c6ec..5314ff9 100644
--- a/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
+++ b/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
@@ -112,7 +112,7 @@ LIC_FILES_CHKSUM = "\
 file://LICENCE.xc4000;md5=0ff51d2dc49fce04814c9155081092f0 \
 file://LICENCE.xc5000;md5=1e170c13175323c32c7f4d0998d53f66 \
 file://LICENCE.xc5000c;md5=12b02efa3049db65d524aeb418dd87ca \
-file://WHENCE;md5=fc7f8a9fce11037078e90df415baad71 \
+file://WHENCE;md5=0eb5bc029ecbe85c54524114cf17ed0e \
 "
 
 # These are not common licenses, set NO_GENERIC_LICENSE for them
@@ -172,7 +172,7 @@ NO_GENERIC_LICENSE[Firmware-xc5000] = "LICENCE.xc5000"
 NO_GENERIC_LICENSE[Firmware-xc5000c] = "LICENCE.xc5000c"
 NO_GENERIC_LICENSE[WHENCE] = "WHENCE"
 
-SRCREV = "cccb6a0da98372bd66787710249727ad6b0aaf72"
+SRCREV = "7534e191256629a20c02e04d5f6d0439c48de80a"
 PE = "1"
 PV = "0.0+git${SRCPV}"
 
-- 
2.1.4

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

Re: [OE-core] gcc 6.1+ and isystem

2016-08-30 Thread Philip Balister

On 08/30/2016 11:37 AM, Jack Mitchell wrote:
> Some of the headers shipped with gcc 6.1 and above now use #include_next
> to try to and do clever things with munging system header files. Our
> injection of isystem into the build at 'meta/conf/bitbake.conf' seems to
> be causing some programs to fail to compile. A full explanation can be
> found at [1], a bug report from GCC specifying that it should only be
> used in extreme cases at [2].
> 
> Since we seem to be adding -isystem unconditionally to BUILD_CFLAGS from
> bitbake, and that the default behavior has now changed should this be
> revisited? I'll admit that I am no where near experienced enough with
> GCC and friends internals to make a call on this one, I'm just looking
> for some input.

I think this issue is casuing me trouble building GNU Radio with qt5
support also. I'll try and verify this. I never did figure out where the
-isystem came from. Thanks for the email Jack!

Philip


> 
> Regards,
> Jack.
> 
> [1]
> http://stackoverflow.com/questions/37218953/isystem-on-a-system-include-directory-causes-errors
> 
> [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70129
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 5/6] kernel-yocto: streamline patch, configuration and audit phases

2016-08-30 Thread Bruce Ashfield


On 2016-08-30 10:19 AM, André Draszik wrote:

On Di, 2016-08-30 at 09:05 -0400, Bruce Ashfield wrote:

On 2016-08-30 05:05 AM, André Draszik wrote:


My kmeta stuff is located directly inside two meta-* layers (i.e. not in
an
extra git repo), where the 2nd layer's kernel recipes .bbappends to the
1st
one with additional kmeta things.

This used to work fine, but since this commit it doesn't anymore as only
the
kmeta stuff from the 2nd layer is being copied into workdir.

Have I been doing something that wasn't guaranteed / supposed to work in
the
first place? Or should that still work? Is it worth fixing or should I
rethink my approach?


That was complexity that I had tried to remove, but thinking on it a
bit, I think I can restore that without adding much complexity.

I'm just finishing work on the 4.8 kernel today, and can look at this
tomorrow.


Thank you Bruce!


Can you clarify for me if you are are using SRC_URI items tagged with
'kmeta', i.e. a directory of fragments, or are you just adding .cfg/.scc
items directly to the SRC_URI ?

Bruce




Do you have any public layers that I can reference to pull together a
test case ?


Unfortunately not :-(

But I'm happy to test and report back!


Cheers,
Andre'



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

[OE-core] [RFC][PATCH] cmake-native: work around gcc6's '-isystem'-allergy

2016-08-30 Thread Andreas Müller

since gcc6 we see many cmake/c++ based packets failing with:

| fatal error: stdlib.h: No such file or directory

a fix from gcc is not to expect [1] so work around by replacing '-isystem' by
'-I' for c++.

Build tested with many recipes in meta-qt5-extra / meta-oe inheriting cmake.

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70129

Signed-off-by: Andreas Müller 
---
 meta/recipes-devtools/cmake/cmake-native_3.6.1.bb  |  1 +
 .../0001-GNU.cmake-replace-isystem-by-I.patch  | 42 ++
 2 files changed, 43 insertions(+)
 create mode 100644 
meta/recipes-devtools/cmake/cmake/0001-GNU.cmake-replace-isystem-by-I.patch

diff --git a/meta/recipes-devtools/cmake/cmake-native_3.6.1.bb 
b/meta/recipes-devtools/cmake/cmake-native_3.6.1.bb
index 33930fb..900091e 100644
--- a/meta/recipes-devtools/cmake/cmake-native_3.6.1.bb
+++ b/meta/recipes-devtools/cmake/cmake-native_3.6.1.bb
@@ -6,6 +6,7 @@ DEPENDS += "bzip2-native zlib-native"
 
 SRC_URI += "\
 file://cmlibarchive-disable-ext2fs.patch \
+file://0001-GNU.cmake-replace-isystem-by-I.patch \
 "
 
 # Disable ccmake since we don't depend on ncurses
diff --git 
a/meta/recipes-devtools/cmake/cmake/0001-GNU.cmake-replace-isystem-by-I.patch 
b/meta/recipes-devtools/cmake/cmake/0001-GNU.cmake-replace-isystem-by-I.patch
new file mode 100644
index 000..4c06490
--- /dev/null
+++ 
b/meta/recipes-devtools/cmake/cmake/0001-GNU.cmake-replace-isystem-by-I.patch
@@ -0,0 +1,42 @@
+From a84d20abe6bc68f8d1a597a22af1ca98d62a5ce4 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Andreas=20M=C3=BCller?= 
+Date: Fri, 26 Aug 2016 12:14:12 +0200
+Subject: [PATCH] GNU.cmake: replace -isystem by -I
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+since gcc6 we see many c++ based packes failing with:
+
+| fatal error: stdlib.h: No such file or directory
+
+a fix from gcc is not to expect [1] so work around
+
+[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70129
+
+Upstream-Status: Pending
+
+Signed-off-by: Andreas Müller 
+---
+ Modules/Compiler/GNU.cmake | 6 +-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+diff --git a/Modules/Compiler/GNU.cmake b/Modules/Compiler/GNU.cmake
+index c2d393d..9d1477d 100644
+--- a/Modules/Compiler/GNU.cmake
 b/Modules/Compiler/GNU.cmake
+@@ -53,6 +53,10 @@ macro(__compiler_gnu lang)
+   set(CMAKE_${lang}_CREATE_PREPROCESSED_SOURCE " 
   -E  > ")
+   set(CMAKE_${lang}_CREATE_ASSEMBLY_SOURCE " 
   -S  -o ")
+   if(NOT APPLE OR NOT CMAKE_${lang}_COMPILER_VERSION VERSION_LESS 4) # work 
around #4462
+-set(CMAKE_INCLUDE_SYSTEM_FLAG_${lang} "-isystem ")
++if("${lang}" STREQUAL "CXX")
++  set(CMAKE_INCLUDE_SYSTEM_FLAG_${lang} "-I ")
++else()
++  set(CMAKE_INCLUDE_SYSTEM_FLAG_${lang} "-isystem ")
++endif()
+   endif()
+ endmacro()
+-- 
+2.5.5
+
-- 
2.5.5

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

Re: [OE-core] gcc 6.1+ and isystem

2016-08-30 Thread Andreas Müller

On Tue, Aug 30, 2016 at 7:00 PM, Richard Purdie
 wrote:
> On Tue, 2016-08-30 at 16:37 +0100, Jack Mitchell wrote:
>> Some of the headers shipped with gcc 6.1 and above now use
>> #include_next
>> to try to and do clever things with munging system header files. Our
>> injection of isystem into the build at 'meta/conf/bitbake.conf' seems
>> to
>> be causing some programs to fail to compile. A full explanation can
>> be
>> found at [1], a bug report from GCC specifying that it should only be
>> used in extreme cases at [2].
>>
>> Since we seem to be adding -isystem unconditionally to BUILD_CFLAGS
>> from
>> bitbake, and that the default behavior has now changed should this be
>> revisited? I'll admit that I am no where near experienced enough with
>> GCC and friends internals to make a call on this one, I'm just
>> looking
>> for some input.
>
If I read the bug correct, the error occurs only for c++ when
including STL headers (and for us on native recipes). As this
combination is not that common (meta-qtx?) we have not seen fallout so
far.
> Its been a long time since we've looked at the native build flags and
> the world is a different place from when they were first implemented
> around a decade ago. I did cull some bits occasionally but more cleanup
> remains and it could be we can change it. A build of all the native
> recipes trying to replace it with a -I flag would likely be the first
> step...
>
a bit off topic: I did prepare similar for cmake-native. I saw much
fallout and helped myself by patching cmake-native. Will send out a
patch as RFC.

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

Re: [OE-core] gcc 6.1+ and isystem

2016-08-30 Thread Richard Purdie

On Tue, 2016-08-30 at 16:37 +0100, Jack Mitchell wrote:
> Some of the headers shipped with gcc 6.1 and above now use
> #include_next 
> to try to and do clever things with munging system header files. Our 
> injection of isystem into the build at 'meta/conf/bitbake.conf' seems
> to 
> be causing some programs to fail to compile. A full explanation can
> be 
> found at [1], a bug report from GCC specifying that it should only be
> used in extreme cases at [2].
> 
> Since we seem to be adding -isystem unconditionally to BUILD_CFLAGS
> from 
> bitbake, and that the default behavior has now changed should this be
> revisited? I'll admit that I am no where near experienced enough with
> GCC and friends internals to make a call on this one, I'm just
> looking 
> for some input.

Its been a long time since we've looked at the native build flags and
the world is a different place from when they were first implemented
around a decade ago. I did cull some bits occasionally but more cleanup
remains and it could be we can change it. A build of all the native
recipes trying to replace it with a -I flag would likely be the first
step...

Cheers,

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

[OE-core] [PATCH 9/9] linux-yocto/4.x: configuration updates

2016-08-30 Thread Bruce Ashfield

Integrating a series to expliclity set the quark build to 32 bits
and avoid 64 bit x86 defaults.

We also have a series of commits that fix configuration warnings on
x86 platforms:

 intel-quark.cfg: Explicitly disable CONFIG_64BIT
 common-pc-drivers.cfg: Remove I2O configs
 features: Fix dependencies and =m vs =y discrepancies for corei7
 intel-core2-32.cfg: Explicitly disable CONFIG_64BIT
 features: Add 6lowpan feature and add it where necessary

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

diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb 
b/meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb
index c31692614d01..9a4a2ff7897e 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb
@@ -12,7 +12,7 @@ python () {
 }
 
 SRCREV_machine ?= "b88e2b5805213daeb0136fdd8c840dc0254a3d21"
-SRCREV_meta ?= "3e7c4fbbbc0ca217ddb3d3ee5235d5ad582e0c56"
+SRCREV_meta ?= "f7984d610b3e0dcffc52db019400ebce53ae28d7"
 
 SRC_URI = 
"git://git.yoctoproject.org/linux-yocto-4.1.git;branch=${KBRANCH};name=machine \

git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.1;destsuffix=${KMETA}"
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 9b0a44b79166..fc0e2a431e0a 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_4.4.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_4.4.bb
@@ -12,7 +12,7 @@ python () {
 }
 
 SRCREV_machine ?= "9135adcfb01432abe4a95a50fca5d0395239f798"
-SRCREV_meta ?= "6a12efcabe8d48e323afd277fa672eae9b7e12c2"
+SRCREV_meta ?= "698835841165b68089604398f68fd8bc3f79cb65"
 
 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.1.bb 
b/meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb
index 72aac116905e..7fe2bde3a96f 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb
@@ -10,7 +10,7 @@ KMETA = "kernel-meta"
 KCONF_BSP_AUDIT_LEVEL = "2"
 
 SRCREV_machine ?= "0847ed67f89b5a8bbaaa0a7b6cfa2a99ef34834f"
-SRCREV_meta ?= "3e7c4fbbbc0ca217ddb3d3ee5235d5ad582e0c56"
+SRCREV_meta ?= "f7984d610b3e0dcffc52db019400ebce53ae28d7"
 
 PV = "${LINUX_VERSION}+git${SRCPV}"
 
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 114bd746d64b..1334a8606e34 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_4.4.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_4.4.bb
@@ -10,7 +10,7 @@ KMETA = "kernel-meta"
 KCONF_BSP_AUDIT_LEVEL = "2"
 
 SRCREV_machine ?= "0a0c93f29c0d65c00abdd2f6d1eb89134fae9525"
-SRCREV_meta ?= "6a12efcabe8d48e323afd277fa672eae9b7e12c2"
+SRCREV_meta ?= "698835841165b68089604398f68fd8bc3f79cb65"
 
 PV = "${LINUX_VERSION}+git${SRCPV}"
 
diff --git a/meta/recipes-kernel/linux/linux-yocto_4.1.bb 
b/meta/recipes-kernel/linux/linux-yocto_4.1.bb
index 6b75a8a6892b..b7e7e7d4fa65 100644
--- a/meta/recipes-kernel/linux/linux-yocto_4.1.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_4.1.bb
@@ -19,7 +19,7 @@ SRCREV_machine_qemux86 ?= 
"0847ed67f89b5a8bbaaa0a7b6cfa2a99ef34834f"
 SRCREV_machine_qemux86-64 ?= "0847ed67f89b5a8bbaaa0a7b6cfa2a99ef34834f"
 SRCREV_machine_qemumips64 ?= "106ed721d21c595dfb993a8990c3a29830dfc166"
 SRCREV_machine ?= "0847ed67f89b5a8bbaaa0a7b6cfa2a99ef34834f"
-SRCREV_meta ?= "3e7c4fbbbc0ca217ddb3d3ee5235d5ad582e0c56"
+SRCREV_meta ?= "f7984d610b3e0dcffc52db019400ebce53ae28d7"
 
 SRC_URI = 
"git://git.yoctoproject.org/linux-yocto-4.1.git;name=machine;branch=${KBRANCH}; 
\

git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.1;destsuffix=${KMETA}"
diff --git a/meta/recipes-kernel/linux/linux-yocto_4.4.bb 
b/meta/recipes-kernel/linux/linux-yocto_4.4.bb
index f45007a361f2..8661452c74fa 100644
--- a/meta/recipes-kernel/linux/linux-yocto_4.4.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_4.4.bb
@@ -19,7 +19,7 @@ SRCREV_machine_qemux86 ?= 
"0a0c93f29c0d65c00abdd2f6d1eb89134fae9525"
 SRCREV_machine_qemux86-64 ?= "0a0c93f29c0d65c00abdd2f6d1eb89134fae9525"
 SRCREV_machine_qemumips64 ?= "aa125473aef74e7731b14f6b56c1b50589fcd668"
 SRCREV_machine ?= "0a0c93f29c0d65c00abdd2f6d1eb89134fae9525"
-SRCREV_meta ?= "6a12efcabe8d48e323afd277fa672eae9b7e12c2"
+SRCREV_meta ?= "698835841165b68089604398f68fd8bc3f79cb65"
 
 SRC_URI =

[OE-core] [PATCH 5/9] libc-headers: update to v4.8

2016-08-30 Thread Bruce Ashfield

Updating the libc-headers to use the 4.8 kernel as the default.

Signed-off-by: Bruce Ashfield 
---
 meta/conf/distro/include/tcmode-default.inc |  2 +-
 .../linux-libc-headers/linux-libc-headers_4.8.bb| 13 +
 2 files changed, 14 insertions(+), 1 deletion(-)
 create mode 100644 
meta/recipes-kernel/linux-libc-headers/linux-libc-headers_4.8.bb

diff --git a/meta/conf/distro/include/tcmode-default.inc 
b/meta/conf/distro/include/tcmode-default.inc
index 7c73411de0a2..79855963282b 100644
--- a/meta/conf/distro/include/tcmode-default.inc
+++ b/meta/conf/distro/include/tcmode-default.inc
@@ -28,7 +28,7 @@ BINUVERSION ?= "2.27%"
 GDBVERSION ?= "7.11%"
 GLIBCVERSION ?= "2.24"
 UCLIBCVERSION ?= "1.0%"
-LINUXLIBCVERSION ?= "4.4"
+LINUXLIBCVERSION ?= "4.8%"
 
 PREFERRED_VERSION_gcc ?= "${GCCVERSION}"
 PREFERRED_VERSION_gcc-cross-${TARGET_ARCH} ?= "${GCCVERSION}"
diff --git a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_4.8.bb 
b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_4.8.bb
new file mode 100644
index ..f80f02cb1896
--- /dev/null
+++ b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_4.8.bb
@@ -0,0 +1,13 @@
+require linux-libc-headers.inc
+
+SRC_URI_forcevariable = 
"${KERNELORG_MIRROR}/linux/kernel/v${HEADER_FETCH_VER}/testing/linux-4.8-rc4.tar.${KORG_ARCHIVE_COMPRESSION}"
+PV = "4.8-rc4"
+
+SRC_URI_append_libc-musl = "\
+file://0001-libc-compat.h-fix-some-issues-arising-from-in6.h.patch \
+file://0002-libc-compat.h-prevent-redefinition-of-struct-ethhdr.patch \
+file://0003-remove-inclusion-of-sysinfo.h-in-kernel.h.patch \
+   "
+
+SRC_URI[md5sum] = "269067213995c7742730ce53b8140c90"
+SRC_URI[sha256sum] = 
"8f07a0d76a7d1a30490582ba9642b7f28370102bc4acc4bb4b2586c8eabf4447"
-- 
2.5.0

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

[OE-core] [PATCH 8/9] kernel-yocto: do_kernel_configme: Fix silent sysroot poisoning error

2016-08-30 Thread Bruce Ashfield

From: Ioan-Adrian Ratiu 

do_kernel_configme calls merge_config.sh (installed in the sysroot by
the kern-tools-native recipe) which may invoke the compiler to complete
the configuration process.

Depending on the build (and dependencies), this may error due to sysroot 
poisoning [1].

The errors are similar to:

  make[1]: Entering directory 
'4.1+gitAUTOINC+a7e53ecc27-r0/linux-x64-standard-build' HOSTCC  
scripts/basic/fixdep
  work-shared/x64/kernel-source/scripts/basic/fixdep.c:106:23: fatal error: 
sys/types.h: No such file or directory
  compilation terminated.
  make[2]: *** [work-shared/x64/kernel-source/scripts/basic/Makefile:22: 
scripts/basic/x86_64-nilrt-linux-fixdep] Error 1

Adding $TOOLCHAIN_OPTIONS to $CFLAGS before calling merge_configs.sh
fixes the error because $TOOLCHAIN_OPTIONS defines the sysroot and make
uses it to correctly compile & fill all missing kernel config options.

[1] 
http://lists.openembedded.org/pipermail/openembedded-core/2014-October/098253.html

Signed-off-by: Ioan-Adrian Ratiu 
Signed-off-by: Bruce Ashfield 
---
 meta/classes/kernel-yocto.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/kernel-yocto.bbclass 
b/meta/classes/kernel-yocto.bbclass
index 9b8bab63ca09..068378f06796 100644
--- a/meta/classes/kernel-yocto.bbclass
+++ b/meta/classes/kernel-yocto.bbclass
@@ -255,7 +255,7 @@ do_kernel_configme() {
bbfatal_log "Could not find configuration queue 
(${meta_dir}/config.queue)"
fi
 
-   ARCH=${ARCH} merge_config.sh -O ${B} ${config_flags} ${configs} > 
${meta_dir}/cfg/merge_config_build.log 2>&1
+   CFLAGS="${CFLAGS} ${TOOLCHAIN_OPTIONS}" ARCH=${ARCH} merge_config.sh -O 
${B} ${config_flags} ${configs} > ${meta_dir}/cfg/merge_config_build.log 2>&1
if [ $? -ne 0 ]; then
bbfatal_log "Could not configure 
${KMACHINE}-${LINUX_KERNEL_TYPE}"
fi
-- 
2.5.0

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

[OE-core] [PATCH 7/9] kernel-yocto: test for empty artifacts

2016-08-30 Thread Bruce Ashfield

With the updated kernel tools, we generate a list of sccs, patches,
configs and BSP definitions as part of the meta data generation.

It is valid if there aren't any of these artifacts found (i.e. you
are just building a branch and a default config), but invoking the
tools with no inputs isn't a good idea.

To avoid this issue, we generate a string based on the artifacts
and skip calling the tools if there's nothing to do.

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

diff --git a/meta/classes/kernel-yocto.bbclass 
b/meta/classes/kernel-yocto.bbclass
index 8650e55de727..9b8bab63ca09 100644
--- a/meta/classes/kernel-yocto.bbclass
+++ b/meta/classes/kernel-yocto.bbclass
@@ -139,10 +139,16 @@ do_kernel_metadata() {
meta_dir=$(kgit --meta)
 
# run1: pull all the configuration fragments, no matter where they come 
from
-   scc --force -o ${S}/${meta_dir}:cfg,meta ${includes} ${bsp_definition} 
${sccs} ${patches} ${KERNEL_FEATURES}
+   elements="`echo -n ${bsp_definition} ${sccs} ${patches} 
${KERNEL_FEATURES}`"
+   if [ -n "${elements}" ]; then
+   scc --force -o ${S}/${meta_dir}:cfg,meta ${includes} 
${bsp_definition} ${sccs} ${patches} ${KERNEL_FEATURES}
+   fi
 
# run2: only generate patches for elements that have been passed on the 
SRC_URI
-   scc --force -o ${S}/${meta_dir}:patch --cmds patch ${includes} ${sccs} 
${patches} ${KERNEL_FEATURES}
+   elements="`echo -n ${sccs} ${patches} ${KERNEL_FEATURES}`"
+   if [ -n "${elements}" ]; then
+   scc --force -o ${S}/${meta_dir}:patch --cmds patch ${includes} 
${sccs} ${patches} ${KERNEL_FEATURES}
+   fi
 }
 
 do_patch() {
-- 
2.5.0

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

[OE-core] [PATCH 6/9] linux-yocto/4.8: add qemuarm device tree specification

2016-08-30 Thread Bruce Ashfield

4.7+ requires a device tree for the arm versatile family of platforms.
We add the definition to our 4.8 linux-yocto recipes so we can continue
to boot!

Signed-off-by: Bruce Ashfield 
---
 meta/recipes-kernel/linux/linux-yocto-dev.bb  | 2 ++
 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 ++
 4 files changed, 8 insertions(+)

diff --git a/meta/recipes-kernel/linux/linux-yocto-dev.bb 
b/meta/recipes-kernel/linux/linux-yocto-dev.bb
index 91c58bfccafa..dbe58477f54e 100644
--- a/meta/recipes-kernel/linux/linux-yocto-dev.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-dev.bb
@@ -43,6 +43,8 @@ PV = "${LINUX_VERSION}+git${SRCPV}"
 
 COMPATIBLE_MACHINE = "(qemuarm|qemux86|qemuppc|qemumips|qemumips64|qemux86-64)"
 
+KERNEL_DEVICETREE_qemuarm = "versatile-pb.dtb"
+
 # Functionality flags
 KERNEL_EXTRA_FEATURES ?= "features/netfilter/netfilter.scc 
features/taskstats/taskstats.scc"
 KERNEL_FEATURES_append = " ${KERNEL_EXTRA_FEATURES}"
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 9adf52322dc0..c602bd3b2c9c 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_4.8.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_4.8.bb
@@ -28,6 +28,8 @@ LINUX_KERNEL_TYPE = "preempt-rt"
 
 COMPATIBLE_MACHINE = "(qemux86|qemux86-64|qemuarm|qemuppc|qemumips)"
 
+KERNEL_DEVICETREE_qemuarm = "versatile-pb.dtb"
+
 # Functionality flags
 KERNEL_EXTRA_FEATURES ?= "features/netfilter/netfilter.scc 
features/taskstats/taskstats.scc"
 KERNEL_FEATURES_append = " ${KERNEL_EXTRA_FEATURES}"
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 a157c2aa80cd..ea89eebe6617 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_4.8.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_4.8.bb
@@ -21,3 +21,5 @@ COMPATIBLE_MACHINE = "(qemux86$)"
 
 # Functionality flags
 KERNEL_FEATURES = ""
+
+KERNEL_DEVICETREE_qemuarm = "versatile-pb.dtb"
diff --git a/meta/recipes-kernel/linux/linux-yocto_4.8.bb 
b/meta/recipes-kernel/linux/linux-yocto_4.8.bb
index c92f7bcd18c2..cf31d3c846bd 100644
--- a/meta/recipes-kernel/linux/linux-yocto_4.8.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_4.8.bb
@@ -31,6 +31,8 @@ PV = "${LINUX_VERSION}+git${SRCPV}"
 KMETA = "kernel-meta"
 KCONF_BSP_AUDIT_LEVEL = "2"
 
+KERNEL_DEVICETREE_qemuarm = "versatile-pb.dtb"
+
 COMPATIBLE_MACHINE = 
"qemuarm|qemuarm64|qemux86|qemuppc|qemumips|qemumips64|qemux86-64"
 
 # Functionality flags
-- 
2.5.0

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

[OE-core] [PATCH 1/9] linux-yocto: introduce v4.8 recipes

2016-08-30 Thread Bruce Ashfield

Signed-off-by: Bruce Ashfield 
---
 meta/recipes-kernel/linux/linux-yocto-rt_4.8.bb   | 36 +++
 meta/recipes-kernel/linux/linux-yocto-tiny_4.8.bb | 23 +
 meta/recipes-kernel/linux/linux-yocto_4.8.bb  | 42 +++
 3 files changed, 101 insertions(+)
 create mode 100644 meta/recipes-kernel/linux/linux-yocto-rt_4.8.bb
 create mode 100644 meta/recipes-kernel/linux/linux-yocto-tiny_4.8.bb
 create mode 100644 meta/recipes-kernel/linux/linux-yocto_4.8.bb

diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_4.8.bb 
b/meta/recipes-kernel/linux/linux-yocto-rt_4.8.bb
new file mode 100644
index ..9adf52322dc0
--- /dev/null
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_4.8.bb
@@ -0,0 +1,36 @@
+KBRANCH ?= "standard/preempt-rt/base"
+
+require recipes-kernel/linux/linux-yocto.inc
+
+# Skip processing of this recipe if it is not explicitly specified as the
+# PREFERRED_PROVIDER for virtual/kernel. This avoids errors when trying
+# to build multiple virtual/kernel providers, e.g. as dependency of
+# core-image-rt-sdk, core-image-rt.
+python () {
+if d.getVar("PREFERRED_PROVIDER_virtual/kernel", True) != "linux-yocto-rt":
+raise bb.parse.SkipPackage("Set PREFERRED_PROVIDER_virtual/kernel to 
linux-yocto-rt to enable it")
+}
+
+SRCREV_machine ?= "a7d71794e4e38d2f861c1b1dbff761ae0b0836b3"
+SRCREV_meta ?= "8cb7317502c2577f8c83eaf1c061603023824313"
+
+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}"
+
+LINUX_VERSION ?= "4.8-rc4"
+
+PV = "${LINUX_VERSION}+git${SRCPV}"
+
+KMETA = "kernel-meta"
+KCONF_BSP_AUDIT_LEVEL = "2"
+
+LINUX_KERNEL_TYPE = "preempt-rt"
+
+COMPATIBLE_MACHINE = "(qemux86|qemux86-64|qemuarm|qemuppc|qemumips)"
+
+# Functionality flags
+KERNEL_EXTRA_FEATURES ?= "features/netfilter/netfilter.scc 
features/taskstats/taskstats.scc"
+KERNEL_FEATURES_append = " ${KERNEL_EXTRA_FEATURES}"
+KERNEL_FEATURES_append_qemuall=" cfg/virtio.scc"
+KERNEL_FEATURES_append_qemux86=" cfg/sound.scc cfg/paravirt_kvm.scc"
+KERNEL_FEATURES_append_qemux86-64=" cfg/sound.scc"
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_4.8.bb 
b/meta/recipes-kernel/linux/linux-yocto-tiny_4.8.bb
new file mode 100644
index ..a157c2aa80cd
--- /dev/null
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_4.8.bb
@@ -0,0 +1,23 @@
+KBRANCH ?= "standard/tiny/common-pc"
+LINUX_KERNEL_TYPE = "tiny"
+KCONFIG_MODE = "--allnoconfig"
+
+require recipes-kernel/linux/linux-yocto.inc
+
+LINUX_VERSION ?= "4.8-rc4"
+
+KMETA = "kernel-meta"
+KCONF_BSP_AUDIT_LEVEL = "2"
+
+SRCREV_machine ?= "3eab887a55424fc2c27553b7bfe32330df83f7b8"
+SRCREV_meta ?= "8cb7317502c2577f8c83eaf1c061603023824313"
+
+PV = "${LINUX_VERSION}+git${SRCPV}"
+
+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}"
+
+COMPATIBLE_MACHINE = "(qemux86$)"
+
+# Functionality flags
+KERNEL_FEATURES = ""
diff --git a/meta/recipes-kernel/linux/linux-yocto_4.8.bb 
b/meta/recipes-kernel/linux/linux-yocto_4.8.bb
new file mode 100644
index ..c92f7bcd18c2
--- /dev/null
+++ b/meta/recipes-kernel/linux/linux-yocto_4.8.bb
@@ -0,0 +1,42 @@
+KBRANCH ?= "standard/base"
+
+require recipes-kernel/linux/linux-yocto.inc
+
+# board specific branches
+KBRANCH_qemuarm  ?= "standard/arm-versatile-926ejs"
+KBRANCH_qemuarm64 ?= "standard/qemuarm64"
+KBRANCH_qemumips ?= "standard/mti-malta32"
+KBRANCH_qemuppc  ?= "standard/qemuppc"
+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 ?= "8cb7317502c2577f8c83eaf1c061603023824313"
+
+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}"
+
+LINUX_VERSION ?= "4.8-rc4"
+
+PV = "${LINUX_VERSION}+git${SRCPV}"
+
+KMETA = "kernel-meta"
+KCONF_BSP_AUDIT_LEVEL = "2"
+
+COMPATIBLE_MACHINE = 
"qemuarm|qemuarm64|qemux86|qemuppc|qemumips|qemumips64|qemux86-64"
+
+# Functionality flags
+KERNEL_EXTRA_FEATURES ?= "features/netfilter/netfilter.scc"

[OE-core] [PATCH 4/9] linux-yocto-dev: bump to v4.8+

2016-08-30 Thread Bruce Ashfield

Signed-off-by: Bruce Ashfield 
---
 meta/recipes-kernel/linux/linux-yocto-dev.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-kernel/linux/linux-yocto-dev.bb 
b/meta/recipes-kernel/linux/linux-yocto-dev.bb
index c7773506a636..91c58bfccafa 100644
--- a/meta/recipes-kernel/linux/linux-yocto-dev.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-dev.bb
@@ -37,7 +37,7 @@ SRC_URI = 
"git://git.yoctoproject.org/linux-yocto-dev.git;branch=${KBRANCH};name
 SRCREV_machine ?= 
'${@oe.utils.conditional("PREFERRED_PROVIDER_virtual/kernel", 
"linux-yocto-dev", "${AUTOREV}", "29594404d7fe73cd80eaa4ee8c43dcc53970c60e", 
d)}'
 SRCREV_meta ?= '${@oe.utils.conditional("PREFERRED_PROVIDER_virtual/kernel", 
"linux-yocto-dev", "${AUTOREV}", "29594404d7fe73cd80eaa4ee8c43dcc53970c60e", 
d)}'
 
-LINUX_VERSION ?= "4.6-rc+"
+LINUX_VERSION ?= "4.8-rc+"
 LINUX_VERSION_EXTENSION ?= "-yoctodev-${LINUX_KERNEL_TYPE}"
 PV = "${LINUX_VERSION}+git${SRCPV}"
 
-- 
2.5.0

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

[OE-core] [PATCH 2/9] perf: adapt to Makefile.config

2016-08-30 Thread Bruce Ashfield

commit 4842576cd857 [perf tools: Move config/Makefile into Makefile.config]
relocated the configuration Makefile of perf. As such, we need to adapt
our fixup routines to work with the Makefile no matter where it is.

Signed-off-by: Bruce Ashfield 
---
 meta/recipes-kernel/perf/perf.bb | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-kernel/perf/perf.bb b/meta/recipes-kernel/perf/perf.bb
index d4855488aeb0..88e3a0a78cd7 100644
--- a/meta/recipes-kernel/perf/perf.bb
+++ b/meta/recipes-kernel/perf/perf.bb
@@ -133,11 +133,17 @@ do_configure_prepend () {
 # with each other if its in the shared source directory
 #
 if [ -e "${S}/tools/perf/config/Makefile" ]; then
+perfconfig="${S}/tools/perf/config/Makefile"
+fi
+if [ -e "${S}/tools/perf/Makefile.config" ]; then
+perfconfig="${S}/tools/perf/Makefile.config"
+fi
+if [ -n "${perfconfig}" ]; then
 # Match $(prefix)/$(lib) and $(prefix)/lib
 sed -i -e 's,^libdir = \($(prefix)/.*lib\),libdir ?= \1,' \
-e 's,^perfexecdir = \(.*\),perfexecdir ?= \1,' \
-e 's,\ .config-detected, $(OUTPUT)/config-detected,g' \
-${S}/tools/perf/config/Makefile
+${perfconfig}
 fi
 # The man pages installation is "$(INSTALL) -d -m 755 $(DESTDIR)$(man1dir)"
 # in ${S}/tools/perf/Documentation/Makefile, if the mandir set to '?=', it
@@ -214,6 +220,7 @@ RDEPENDS_${PN}-tests =+ "python"
 RSUGGESTS_SCRIPTING = "${@perf_feature_enabled('perf-scripting', '${PN}-perl 
${PN}-python', '',d)}"
 RSUGGESTS_${PN} += "${PN}-archive ${PN}-tests ${RSUGGESTS_SCRIPTING}"
 
+#FILES_${PN} += "${libexecdir}/perf-core ${exec_prefix}/libexec/perf-core 
/usr/lib64/traceevent ${libdir}/traceevent"
 FILES_${PN} += "${libexecdir}/perf-core ${exec_prefix}/libexec/perf-core 
${libdir}/traceevent"
 FILES_${PN}-archive = "${libdir}/perf/perf-core/perf-archive"
 FILES_${PN}-tests = "${libdir}/perf/perf-core/tests 
${libexecdir}/perf-core/tests"
-- 
2.5.0

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

[OE-core] [PATCH 0/9] linux-yocto: v4.8 + fixes + configuration updates + RFC

2016-08-30 Thread Bruce Ashfield

Hi all,

Here's the latest updates to the linux-yoco* baseline support. There are
three distinct blocks in the consolidated pull request, with the biggest
being the introduction of a 4.8 named kernel and 4.8 based libc-headers.

The others are fixes to the kernel-yocto processing and kernel meta data
updates. As such, these commits can be taken in isolation to the 4.8
update that I've included in the pull request.

  kernel-yocto: test for empty artifacts
  linux-yocto/4.x: configuration updates
  kernel-yocto: do_kernel_configme: Fix silent sysroot poisoning error

On the topic of the version 4.8:

  - This is the intended 'newest' kernel for the upcoming fall release
cycle. We will have a shiny new one this time around.

  - yes it is a -rc4 release, but the version wasn't chosen by mistake
(or lightly). It was the typical balancing act.

   - It is nice to work through the development cycle of the
 upstream kernel, since we can send fixes in realtime to the
 mainline tree .. but this is the side effect of the choice,
 not the reason

   - This version balances a new enough kernel, LTS/LTSI, -rt,
 platform updates (ARM/x86) and the timing of the release.

 The LTS/LTSI kernels are either too old at the moment, and
 won't get a port of major patch series like -rt. Hence why
 v4.8 shoots the difference between the options and gives us
 a good baseline to update in the upcoming months, and one that
 we can compliment with other kernel versions later.

  - The delta between any -rcX releases is small, so following this
through until its release is not a big issue.

build/boot testing:

  - I've built and booted qemu* with core-image-sato, so it is known
to build and have a sane runtime for all arches. I've also built
the typical packages that misbehave (lttng, perf, etc).

  - The versatile platform switched to a device tree boot in the 4.7
timeframe. As such, I had to patch runqemu to use a device tree
.. and use that device tree conditionally, since we have to support
older kernels at the same time as 4.7+

  - I know that there are pending changes to the way runqemu works, but
I patched what I had in master .. these can be updated/adjusted if
need be.

libc-headers update:

  - Since there are milestone builds coming up, I wanted to get the 4.8
libc headers in place. Which meant that I had to do some different
things to use the testing kernel tarball, and to get the version of
the package right.

This might cause us version stepping issues .. so anyone looking at
this can suggest what I need to do to avoid them, and I can update
and rebase the series with the proper fix.

The linux-yocto-4.8 repository:
   
  - There have been comments about the linux-yocto* repos filling up
download directories, and consuming people's bandwidth.  Since we
don't have a shallow clone or reference clone way to deal with the
amount of shared kernel blobs, I've simultaneously generated a v4.8
kernel in a repository that could be re-used over time.

  http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto/

The proposal is that if we really want to avoid separate kernel trees,
and keep the ability to rebase/remove/amend old commits to keep the
tree clean, that I can insert the version number into the branches
as a marker. Comments on this approach are welcome, since if we go this
way, I need to adjust all the KBRANCH variables.

I'll follow up with commits to change the default qemu version to 4.8 once
there's general agreement about the options on this.

Cheers,

Bruce

The following changes since commit 2fedd226c3385f1ac160b3aa0bfadbded85e288c:

  ref-manual: Fixed small wording in PKGR in the glossary (2016-08-25 23:09:29 
+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 (8):
  linux-yocto: introduce v4.8 recipes
  perf: adapt to Makefile.config
  qemuarm: add device tree support
  linux-yocto-dev: bump to v4.8+
  libc-headers: update to v4.8
  linux-yocto/4.8: add qemuarm device tree specification
  kernel-yocto: test for empty artifacts
  linux-yocto/4.x: configuration updates

Ioan-Adrian Ratiu (1):
  kernel-yocto: do_kernel_configme: Fix silent sysroot poisoning error

 meta/classes/kernel-yocto.bbclass  | 12 --
 meta/conf/distro/include/tcmode-default.inc|  2 +-
 .../linux-libc-headers/linux-libc-headers_4.8.bb   | 13 +++
 meta/recipes-kernel/linux/linux-yocto-dev.bb   |  4 +-
 meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb|  2 +-
 meta/recipes-kernel/linux/linux-yocto-rt_4.4.bb|  2 +-
 meta/recipes-kernel/linux/linux-yocto-rt_4.8.bb| 38 +++
 meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb  |  2 +-

[OE-core] [PATCH 3/9] qemuarm: add device tree support

2016-08-30 Thread Bruce Ashfield

As of the 4.7 kernel qemuarm must be booted with a dtb. To allow
older and recent kernels to both boot qemuarm, we add the device
tree definitions only to recipes that need it (linux-yocto-dev)
and make runqemu detect and use the dtb if present.

Signed-off-by: Bruce Ashfield 
---
 scripts/runqemu-internal | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/scripts/runqemu-internal b/scripts/runqemu-internal
index d10466d35cce..e74a9150cbd7 100755
--- a/scripts/runqemu-internal
+++ b/scripts/runqemu-internal
@@ -298,6 +298,9 @@ config_qemuarm() {
 KERNCMDLINE="root=/dev/nfs nfsroot=$NFS_SERVER:$NFS_DIR,$UNFS_OPTS rw 
console=ttyAMA0,115200 $KERNEL_NETWORK_CMD mem=$QEMU_MEMORY"
 QEMUOPTIONS="$QEMU_NETWORK_CMD -M ${MACHINE_SUBTYPE} --no-reboot 
$QEMU_UI_OPTIONS"
 fi
+if [ -e "$DEPLOY_DIR_IMAGE/zImage-versatile-pb.dtb" ]; then
+QEMUOPTIONS="$QEMUOPTIONS -dtb 
$DEPLOY_DIR_IMAGE/zImage-versatile-pb.dtb"
+fi
 if [ "$MACHINE" = "qemuarmv6" ]; then
 QEMUOPTIONS="$QEMUOPTIONS -cpu arm1136"
 fi
-- 
2.5.0

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

[OE-core] gcc 6.1+ and isystem

2016-08-30 Thread Jack Mitchell

Some of the headers shipped with gcc 6.1 and above now use #include_next 
to try to and do clever things with munging system header files. Our 
injection of isystem into the build at 'meta/conf/bitbake.conf' seems to 
be causing some programs to fail to compile. A full explanation can be 
found at [1], a bug report from GCC specifying that it should only be 
used in extreme cases at [2].


Since we seem to be adding -isystem unconditionally to BUILD_CFLAGS from 
bitbake, and that the default behavior has now changed should this be 
revisited? I'll admit that I am no where near experienced enough with 
GCC and friends internals to make a call on this one, I'm just looking 
for some input.


Regards,
Jack.

[1] 
http://stackoverflow.com/questions/37218953/isystem-on-a-system-include-directory-causes-errors

[2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70129
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v2 0/3] boost mips16e and soft-float fixes

2016-08-30 Thread André Draszik

On Di, 2016-08-30 at 17:00 +0100, Richard Purdie wrote:
> 1472572721.0863695: "g++"  -ftemplate-depth-128
> > -isystem/media/build1/poky/build/tmp/sysroots/x86_64-linux/usr/include
> > -O2 -pipe -D_GLIBCXX_USE_CXX11_ABI=0 -O3 -finline-functions -Wno-inline
> > -Wall -pthread -fPIC -m64 -fno-strict-aliasing -ftemplate-depth-1024
> > -fvisibility=hidden -DBOOST_ALL_NO_LIB=1 -DBOOST_ATOMIC_DYN_LINK=1
> > -DBOOST_CHRONO_DYN_LINK=1 -DBOOST_DATE_TIME_DYN_LINK=1
> > -DBOOST_FILESYSTEM_DYN_LINK=1 -DBOOST_LOG_BUILDING_THE_LIB=1
> > -DBOOST_LOG_DLL -DBOOST_LOG_USE_AVX2 -DBOOST_LOG_USE_NATIVE_SYSLOG
> > -DBOOST_LOG_USE_SSSE3 -DBOOST_LOG_WITHOUT_EVENT_LOG
> > -DBOOST_SPIRIT_USE_PHOENIX_V3=1 -DBOOST_SYSTEM_DYN_LINK=1
> > -DBOOST_SYSTEM_NO_DEPRECATED -DBOOST_THREAD_BUILD_DLL=1
> > -DBOOST_THREAD_DONT_USE_CHRONO=1 -DBOOST_THREAD_POSIX
> > -DBOOST_THREAD_USE_DLL=1 -DDATE_TIME_INLINE -DNDEBUG -D_GNU_SOURCE=1
> > -D_XOPEN_SOURCE=600 -D__STDC_CONSTANT_MACROS  -I"." -c -o
> > "/media/build1/poky/build/tmp/work/x86_64-linux/boost-native/1.61.0-
> > r0/boost_1_61_0/x86_64-linux/boost/bin.v2/libs/log/build/gcc-
> > 4.3.1/release/log-api-unix/threading-multi/text_file_backend.o"
> > "libs/log/src/text_file_backend.cpp"
> > 1472572721.0863695:
> > 1472572721.0863695: In file included from
> > ./boost/config/compiler/gcc.hpp:271:0,
> > 1472572721.0863695:  from ./boost/config.hpp:39,
> > 1472572721.0863695:  from
> > ./boost/log/detail/config.hpp:34,
> > 1472572721.0863695:  from
> > libs/log/src/text_file_backend.cpp:16:
> > 1472572721.0863695: /usr/include/x86_64-linux-gnu/bits/fenv.h:19:3:
> > error: #error "Never use  directly; include 
> > instead."
> > 1472572721.0863695:  # error "Never use  directly; include
> >  instead."
> > 1472572721.0863695:^
> > 1472572721.0863695: ...failed updating 68 targets...
> 
> and many similar errors.

I will send a version 3, taking in some comments from the boost bug tracker
as well.

Sorry for that!
Andre'

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

[OE-core] [PATCH] flex: fix gcc-6 failure

2016-08-30 Thread Andreas Müller

Gcc-6 does not allow c++ comments withing c-code. Files generated by flex
can fail with:

| error: C++ style comments are not allowed in ISO C90
| num_to_alloc = 1; // After all that talk, this was set to 1 anyways...

Signed-off-by: Andreas Müller 
---
 ...oid-c-comments-in-c-code-fails-with-gcc-6.patch | 64 ++
 meta/recipes-devtools/flex/flex_2.6.0.bb   |  1 +
 2 files changed, 65 insertions(+)
 create mode 100644 
meta/recipes-devtools/flex/flex/0002-avoid-c-comments-in-c-code-fails-with-gcc-6.patch

diff --git 
a/meta/recipes-devtools/flex/flex/0002-avoid-c-comments-in-c-code-fails-with-gcc-6.patch
 
b/meta/recipes-devtools/flex/flex/0002-avoid-c-comments-in-c-code-fails-with-gcc-6.patch
new file mode 100644
index 000..438ca5f
--- /dev/null
+++ 
b/meta/recipes-devtools/flex/flex/0002-avoid-c-comments-in-c-code-fails-with-gcc-6.patch
@@ -0,0 +1,64 @@
+From 7072befe1397af4eb01c3ff7edf99f0cd5076089 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Andreas=20M=C3=BCller?= 
+Date: Tue, 30 Aug 2016 14:25:32 +0200
+Subject: [PATCH] avoid c++ comments in c-code - fails with gcc-6
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+fixes:
+
+| error: C++ style comments are not allowed in ISO C90
+| num_to_alloc = 1; // After all that talk, this was set to 1 anyways...
+
+Upstream-Status: Pending
+
+Signed-off-by: Andreas Müller 
+---
+ src/flex.skl | 2 +-
+ src/scan.c   | 2 +-
+ src/skel.c   | 2 +-
+ 3 files changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/src/flex.skl b/src/flex.skl
+index 73a0b9e..ed71627 100644
+--- a/src/flex.skl
 b/src/flex.skl
+@@ -2350,7 +2350,7 @@ void yyFlexLexer::yyensure_buffer_stack(void)
+* scanner will even need a stack. We use 2 instead of 1 to 
avoid an
+* immediate realloc on the next call.
+  */
+-  num_to_alloc = 1; // After all that talk, this was set to 1 
anyways...
++  num_to_alloc = 1; /* After all that talk, this was set to 1 
anyways... */
+   YY_G(yy_buffer_stack) = (struct yy_buffer_state**)yyalloc
+   (num_to_alloc * 
sizeof(struct yy_buffer_state*)
+   
M4_YY_CALL_LAST_ARG);
+diff --git a/src/scan.c b/src/scan.c
+index b55df2d..f1dce75 100644
+--- a/src/scan.c
 b/src/scan.c
+@@ -4672,7 +4672,7 @@ static void yyensure_buffer_stack (void)
+* scanner will even need a stack. We use 2 instead of 1 to 
avoid an
+* immediate realloc on the next call.
+  */
+-  num_to_alloc = 1; // After all that talk, this was set to 1 
anyways...
++  num_to_alloc = 1; /* After all that talk, this was set to 1 
anyways...*/
+   (yy_buffer_stack) = (struct yy_buffer_state**)yyalloc
+   (num_to_alloc * 
sizeof(struct yy_buffer_state*)
+   );
+diff --git a/src/skel.c b/src/skel.c
+index ef657d3..26cc889 100644
+--- a/src/skel.c
 b/src/skel.c
+@@ -2561,7 +2561,7 @@ const char *skel[] = {
+   "* scanner will even need a stack. We use 2 instead of 1 to 
avoid an",
+   "* immediate realloc on the next call.",
+   " */",
+-  "   num_to_alloc = 1; // After all that talk, this was set to 1 
anyways...",
++  "   num_to_alloc = 1; /* After all that talk, this was set to 1 
anyways... */",
+   "   YY_G(yy_buffer_stack) = (struct yy_buffer_state**)yyalloc",
+   "   (num_to_alloc * 
sizeof(struct yy_buffer_state*)",
+   "   
M4_YY_CALL_LAST_ARG);",
+-- 
+2.5.5
+
diff --git a/meta/recipes-devtools/flex/flex_2.6.0.bb 
b/meta/recipes-devtools/flex/flex_2.6.0.bb
index f6d136c..db2cf1c 100644
--- a/meta/recipes-devtools/flex/flex_2.6.0.bb
+++ b/meta/recipes-devtools/flex/flex_2.6.0.bb
@@ -14,6 +14,7 @@ SRC_URI = "${SOURCEFORGE_MIRROR}/flex/flex-${PV}.tar.bz2 \
file://run-ptest \
file://do_not_create_pdf_doc.patch \

file://0001-tests-add-a-target-for-building-tests-without-runnin.patch \
+   file://0002-avoid-c-comments-in-c-code-fails-with-gcc-6.patch \
${@bb.utils.contains('PTEST_ENABLED', '1', '', 
'file://disable-tests.patch', d)} \
"
 
-- 
2.5.5

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

Re: [OE-core] [PATCH v2 0/3] boost mips16e and soft-float fixes

2016-08-30 Thread Richard Purdie

On Mon, 2016-08-29 at 12:55 +0100, André Draszik wrote:
> An error crept into the previous series :-(, fixed now.

bitbake boost-native blew up in my local build with these applied :(

| 1472572721.0863695: "g++"  -ftemplate-depth-128 
-isystem/media/build1/poky/build/tmp/sysroots/x86_64-linux/usr/include -O2 
-pipe -D_GLIBCXX_USE_CXX11_ABI=0 -O3 -finline-functions -Wno-inline -Wall 
-pthread -fPIC -m64 -fno-strict-aliasing -ftemplate-depth-1024 
-fvisibility=hidden -DBOOST_ALL_NO_LIB=1 -DBOOST_ATOMIC_DYN_LINK=1 
-DBOOST_CHRONO_DYN_LINK=1 -DBOOST_DATE_TIME_DYN_LINK=1 
-DBOOST_FILESYSTEM_DYN_LINK=1 -DBOOST_LOG_BUILDING_THE_LIB=1 -DBOOST_LOG_DLL 
-DBOOST_LOG_USE_AVX2 -DBOOST_LOG_USE_NATIVE_SYSLOG -DBOOST_LOG_USE_SSSE3 
-DBOOST_LOG_WITHOUT_EVENT_LOG -DBOOST_SPIRIT_USE_PHOENIX_V3=1 
-DBOOST_SYSTEM_DYN_LINK=1 -DBOOST_SYSTEM_NO_DEPRECATED 
-DBOOST_THREAD_BUILD_DLL=1 -DBOOST_THREAD_DONT_USE_CHRONO=1 
-DBOOST_THREAD_POSIX -DBOOST_THREAD_USE_DLL=1 -DDATE_TIME_INLINE -DNDEBUG 
-D_GNU_SOURCE=1 -D_XOPEN_SOURCE=600 -D__STDC_CONSTANT_MACROS  -I"." -c -o 
"/media/build1/poky/build/tmp/work/x86_64-linux/boost-native/1.61.0-r0/boost_1_61_0/x86_64-linux/boost/bin.v2/libs/log/build/gcc-4.3.1/release/log-api-unix/threading-multi/text_file_backend.o"
 "libs/log/src/text_file_backend.cpp"
| 1472572721.0863695:
| 1472572721.0863695: In file included from 
./boost/config/compiler/gcc.hpp:271:0,
| 1472572721.0863695:  from ./boost/config.hpp:39,
| 1472572721.0863695:  from ./boost/log/detail/config.hpp:34,
| 1472572721.0863695:  from 
libs/log/src/text_file_backend.cpp:16:
| 1472572721.0863695: /usr/include/x86_64-linux-gnu/bits/fenv.h:19:3: error: 
#error "Never use  directly; include  instead."
| 1472572721.0863695:  # error "Never use  directly; include 
 instead."
| 1472572721.0863695:^
| 1472572721.0863695: ...failed updating 68 targets...

and many similar errors.

Cheers,

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

Re: [OE-core] [PATCH 1/1] gcc-runtime.inc: add CPP support for mips64-n32 tune

2016-08-30 Thread Bystricky, Juro

The way I see it, there are basically three ways to fix this issue:
1. Modify gcc configuration so a different CPP path is searched, one that 
actually exists
2. "Create" the folder CPP assumes in the configured search path (via symlinks)
3. Use environment variable CPP_INCLUDE_PATH (in modified environment scripts)

Obviously, option #1 is the cleanest solution, but it is a bit more invasive
(would require configuring gcc with different --target=xxx). 
Maybe this should be addressed in the next Yocto release, I think it is too 
late to do this for this release.

As for option #2:
mip64 multilib creates three distinct toolchains, two of them work fine, but 
only because they have already adopted option #2. So using similar approach to 
fix the third toolchain is also a matter of consistency. If you install the 
generated SDK, you will see there are three symlinks now (i.e. folder 
/c++/6.2.0)instead of two.

Using option #3 would fix the problem, but if we use it, we should use it 
consistently for all toolchains.

Juro

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of Mark
> Hatle
> Sent: Monday, August 29, 2016 7:24 PM
> To: openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH 1/1] gcc-runtime.inc: add CPP support for
> mips64-n32 tune
> 
> On 8/30/16 6:45 AM, Juro Bystricky wrote:
> > This patch fixes the problem where the CPP compiler cannot find include
> files.
> > The compiler is configured to look for the files in places that do not
> exist.
> > When querying the CPP for search paths, we observe messages such as
> these:
> >
> > multilib configuration:
> >
> > MACHINE="qemumips64"
> > require conf/multilib.conf
> > MULTILIBS = "multilib:lib64 multilib:lib32"
> > DEFAULTTUNE = "mips64-n32"
> > DEFAULTTUNE_virtclass-multilib-lib64 = "mips64"
> > DEFAULTTUNE_virtclass-multilib-lib32 = "mips32r2"
> >
> > ignoring nonexistent directory "/sysroots/mips64-n32-poky-linux-
> gnun32/usr/include/c++/6.2.0/mips64-poky-linux/32
> >
> > single lib configuration:
> > MACHINE="qemumips64"
> > DEFAULTTUNE = "mips64-n32"
> > ignoring nonexistent directory "/sysroots/mips64-n32-poky-linux-
> gnun32/usr/include/c++/6.2.0/mips64-poky-linux/
> >
> > To fix this, create a symlink of the name CPP expects and point it to the
> corresponding "gnun32" directory.
> >
> > [YOCTO#10142]
> >
> > Signed-off-by: Juro Bystricky 
> > ---
> >  meta/recipes-devtools/gcc/gcc-runtime.inc | 10 ++
> >  1 file changed, 10 insertions(+)
> >
> > diff --git a/meta/recipes-devtools/gcc/gcc-runtime.inc b/meta/recipes-
> devtools/gcc/gcc-runtime.inc
> > index 526be55..9791e21 100644
> > --- a/meta/recipes-devtools/gcc/gcc-runtime.inc
> > +++ b/meta/recipes-devtools/gcc/gcc-runtime.inc
> > @@ -82,6 +82,16 @@ do_install_append_class-target () {
> > if [ "${TARGET_OS}" = "linux-gnuspe" ]; then
> > ln -s ${TARGET_SYS}
> ${D}${includedir}/c++/${BINV}/${TARGET_ARCH}${TARGET_VENDOR}-linux
> > fi
> > +
> > +   if [ "${TARGET_OS}" = "linux-gnun32" ]; then
> > +   if [ "${MULTILIBS}" != "" ]; then
> > +   mkdir ${D}${includedir}/c++/${BINV}/${TARGET_ARCH}-
> pokymllib64-linux
> > +   ln -s ../${TARGET_SYS}
> ${D}${includedir}/c++/${BINV}/${TARGET_ARCH}-pokymllib64-linux/32
> > +   else
> > +   ln -s ${TARGET_SYS}
> ${D}${includedir}/c++/${BINV}/${TARGET_ARCH}${TARGET_VENDOR}-linux
> > +   fi
> > +   fi
> > +
> 
> It would be better if you can query the compiler that was produced for the
> path
> it is expecting.  (Often you can run it and capture the result with a
> specific
> command.  Then use that path as the input.  Simply verify if the expected
> C++
> path and the compiler path are the same, if not setup the link -- they are
> the
> same continue on.)
> 
> There may be a more simple solution however then all of this.
> 
> In the environment file for the SDK, you can add the CPP_INCLUDE variable
> and
> set it to the right value... this will require a change to the environment
> setup
> and a way to known the right value and the end location.
> 
> BTW I believe the problem is the difference between the SDK view and the
> host/cross compile view of the multilibs and such.  Something gets out of
> sync
> and needs to be manually fixed.
> 
> --Mark
> 
> > if [ "${TCLIBC}" != "glibc" ]; then
> > case "${TARGET_OS}" in
> > "linux-musl" | "linux-uclibc" | "linux-*spe")
> extra_target_os="linux";;
> >
> 
> --
> ___
> 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

Re: [OE-core] [PATCH V1] unzip: fixes strange output

2016-08-30 Thread Jussi Kukkonen

On 30 August 2016 at 10:21, Jussi Kukkonen  wrote:

> On 30 August 2016 at 05:17, Edwin Plauchu  intel.com> wrote:
> >
> > From: Edwin Plauchu 
> >
> > This fixes commit 763a3d424bccf559a8d6add3dc1f2746c82f2933
> >
> > Output was strange when using unzip to extract zip file.
> > This patch fixed so.
> >
> > [YOCTO #9551]
> >
> > Signed-off-by: Edwin Plauchu 
> > ---
> >  .../unzip/unzip/fix-security-format.patch  | 198
> -
> >  1 file changed, 78 insertions(+), 120 deletions(-)
> >
> > diff --git a/meta/recipes-extended/unzip/unzip/fix-security-format.patch
> b/meta/recipes-extended/unzip/unzip/fix-security-format.patch
> > index c82f502..8e9b06c 100644
> > --- a/meta/recipes-extended/unzip/unzip/fix-security-format.patch
> > +++ b/meta/recipes-extended/unzip/unzip/fix-security-format.patch
> > @@ -9,131 +9,89 @@ Upstream-Status: Pending
> >
> >  Signed-off-by: Edwin Plauchu 
> >
> > -diff --git a/unzpriv.h b/unzpriv.h
> > -index c8d3eab..85e693a 100644
> >  a/unzpriv.h
> > -+++ b/unzpriv.h
> > -@@ -1006,7 +1006,7 @@
> > - #define LoadFarStringSmall(x)   Qstrfix(x)
> > - #define LoadFarStringSmall2(x)  Qstrfix(x)
> > - #  else
> > --#define LoadFarString(x)(char *)(x)
> > -+#define LoadFarString(x)"%s",(char *)(x)
>
> LoadFarString is used a _lot_ in various different ways, usually as
> argument to another macro or function. This sort of macro change seems
> potentially very dangerous in C, have you checked this is ok in every case?.
>

Edwin just pointed out to me that the patch actually removes this macro
change, and he's correct. My patch-of-patch reading failure.

So I'm fine with this patch, sorry for noise.
  Jussi
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] Cannot build any external kernel modules in krogoth

2016-08-30 Thread Ian Geiser

Greetings,  I have an issue where I cannot seem to build any external kernel 
module recipes.  The one in particular is iscsitarget, but it seems none of 
them build now.

It seems that what is happening is that the 
"work-shared/*/kernel-build-artifacts" is getting erased right before the 
module recipe tries to use them.  Has anyone seen this before?

As a key point, I am also using my own kernel recipe that only uses the 
kernel.bbclass, not the kernel-yocto.bbclass.  Is there magic I am missing that 
will not allow me to build modules unless I am using the yocto kernels?

Thanks!






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

[OE-core] [PATCH] base, autotools: Append PACKAGECONFIG_CONFARGS to EXTRA_OECONF only in autotools.bbclass

2016-08-30 Thread Martin Jansa

* recipes which don't inherit autotools or cmake bbclass and want to
  use the configure options from PACKAGECONFIG need to handle
  PACKAGECONFIG_CONFARGS themselves.

Signed-off-by: Martin Jansa 
---
 meta/classes/autotools.bbclass | 2 ++
 meta/classes/base.bbclass  | 6 --
 2 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/meta/classes/autotools.bbclass b/meta/classes/autotools.bbclass
index 076899c..47a0190 100644
--- a/meta/classes/autotools.bbclass
+++ b/meta/classes/autotools.bbclass
@@ -131,6 +131,8 @@ autotools_postconfigure(){
 
 EXTRACONFFUNCS ??= ""
 
+EXTRA_OECONF_append = " ${PACKAGECONFIG_CONFARGS}"
+
 do_configure[prefuncs] += "autotools_preconfigure autotools_copy_aclocals 
${EXTRACONFFUNCS}"
 do_configure[postfuncs] += "autotools_postconfigure"
 
diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index 79edfe5..a31a53f 100644
--- a/meta/classes/base.bbclass
+++ b/meta/classes/base.bbclass
@@ -431,12 +431,6 @@ python () {
 appendVar('RDEPENDS_${PN}', extrardeps)
 appendVar('PACKAGECONFIG_CONFARGS', extraconf)
 
-# TODO: once all recipes/classes abusing EXTRA_OECONF
-# to get PACKAGECONFIG options are fixed to use PACKAGECONFIG_CONFARGS
-# move this appendVar to autotools.bbclass.
-if not bb.data.inherits_class('cmake', d):
-appendVar('EXTRA_OECONF', extraconf)
-
 pn = d.getVar('PN', True)
 license = d.getVar('LICENSE', True)
 if license == "INVALID":
-- 
2.9.2

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

Re: [OE-core] [PATCH 5/6] kernel-yocto: streamline patch, configuration and audit phases

2016-08-30 Thread André Draszik

On Di, 2016-08-30 at 09:05 -0400, Bruce Ashfield wrote:
> On 2016-08-30 05:05 AM, André Draszik wrote:
> > 
> > My kmeta stuff is located directly inside two meta-* layers (i.e. not in
> > an
> > extra git repo), where the 2nd layer's kernel recipes .bbappends to the
> > 1st
> > one with additional kmeta things.
> > 
> > This used to work fine, but since this commit it doesn't anymore as only
> > the
> > kmeta stuff from the 2nd layer is being copied into workdir.
> > 
> > Have I been doing something that wasn't guaranteed / supposed to work in
> > the
> > first place? Or should that still work? Is it worth fixing or should I
> > rethink my approach?
> 
> That was complexity that I had tried to remove, but thinking on it a
> bit, I think I can restore that without adding much complexity.
> 
> I'm just finishing work on the 4.8 kernel today, and can look at this
> tomorrow.

Thank you Bruce!

> Do you have any public layers that I can reference to pull together a
> test case ?

Unfortunately not :-(

But I'm happy to test and report back!


Cheers,
Andre'

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

Re: [OE-core] [PATCH 00/18] Provide list of deployment artifacts

2016-08-30 Thread Richard Purdie

On Tue, 2016-08-30 at 10:36 -0300, Otavio Salvador wrote:
> On Tue, Aug 30, 2016 at 8:21 AM, Ed Bartosh <
> ed.bart...@linux.intel.com> wrote:
> > > So it is always going to be skipped?
> > Yes it is for do_image_complete and do_populate_sdk tasks for now.
> 
> Oh ok.

Its a performance issue. I can see the attraction of putting these into
sstate however it would add significant time to the builds which many
people would find unacceptable.

Having manifests of deployed files is a huge win for a whole variety of
reasons and it standardises our output tasks. This compromise gives us
that without the performance hit of compressing everything into an
sstate artefact.

Cheers,

Richard

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

[OE-core] [PATCH v2] gstreamer1.0: upgrade to 1.8.3

2016-08-30 Thread Maxin B. John

1.8.2 -> 1.8.3

Remove backported patch from 1.8.3:
0007-glplugin-gleffects-fix-little-rectangel-appears-at-t.patch

v2:
Revert the PR changes in gstreamer1.0-omx

Signed-off-by: Maxin B. John 
---
 ...-libav_1.8.2.bb => gstreamer1.0-libav_1.8.3.bb} |  4 +-
 ...effects-fix-little-rectangel-appears-at-t.patch | 46 --
 ..._1.8.2.bb => gstreamer1.0-plugins-bad_1.8.3.bb} |  5 +--
 ...1.8.2.bb => gstreamer1.0-plugins-base_1.8.3.bb} |  4 +-
 ...1.8.2.bb => gstreamer1.0-plugins-good_1.8.3.bb} |  4 +-
 ...1.8.2.bb => gstreamer1.0-plugins-ugly_1.8.3.bb} |  4 +-
 .../gstreamer/gstreamer1.0-rtsp-server_1.8.2.bb|  6 ---
 .../gstreamer/gstreamer1.0-rtsp-server_1.8.3.bb|  6 +++
 ...gstreamer1.0_1.8.2.bb => gstreamer1.0_1.8.3.bb} |  4 +-
 9 files changed, 18 insertions(+), 65 deletions(-)
 rename meta/recipes-multimedia/gstreamer/{gstreamer1.0-libav_1.8.2.bb => 
gstreamer1.0-libav_1.8.3.bb} (87%)
 delete mode 100755 
meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad/0007-glplugin-gleffects-fix-little-rectangel-appears-at-t.patch
 rename meta/recipes-multimedia/gstreamer/{gstreamer1.0-plugins-bad_1.8.2.bb => 
gstreamer1.0-plugins-bad_1.8.3.bb} (93%)
 rename meta/recipes-multimedia/gstreamer/{gstreamer1.0-plugins-base_1.8.2.bb 
=> gstreamer1.0-plugins-base_1.8.3.bb} (84%)
 rename meta/recipes-multimedia/gstreamer/{gstreamer1.0-plugins-good_1.8.2.bb 
=> gstreamer1.0-plugins-good_1.8.3.bb} (83%)
 rename meta/recipes-multimedia/gstreamer/{gstreamer1.0-plugins-ugly_1.8.2.bb 
=> gstreamer1.0-plugins-ugly_1.8.3.bb} (72%)
 delete mode 100644 
meta/recipes-multimedia/gstreamer/gstreamer1.0-rtsp-server_1.8.2.bb
 create mode 100644 
meta/recipes-multimedia/gstreamer/gstreamer1.0-rtsp-server_1.8.3.bb
 rename meta/recipes-multimedia/gstreamer/{gstreamer1.0_1.8.2.bb => 
gstreamer1.0_1.8.3.bb} (69%)

diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav_1.8.2.bb 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav_1.8.3.bb
similarity index 87%
rename from meta/recipes-multimedia/gstreamer/gstreamer1.0-libav_1.8.2.bb
rename to meta/recipes-multimedia/gstreamer/gstreamer1.0-libav_1.8.3.bb
index 57e8785..3d86221 100644
--- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav_1.8.2.bb
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav_1.8.3.bb
@@ -14,7 +14,7 @@ SRC_URI = " \
 file://workaround-to-build-gst-libav-for-i586-with-gcc.patch \
 "
 
-SRC_URI[md5sum] = "95bc3dd0ea2dc664b4f3a96897005013"
-SRC_URI[sha256sum] = 
"b5f3c7a27b39b5f5c2f0bfd546b0c655020faf6b38d27b64b346c43e5ebf687a"
+SRC_URI[md5sum] = "b51a736147bacb40f85827a4e0ae0d2c"
+SRC_URI[sha256sum] = 
"9006a05990089f7155ee0e848042f6bb24e52ab1d0a59ff8d1b5d7e33001a495"
 
 S = "${WORKDIR}/gst-libav-${PV}"
diff --git 
a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad/0007-glplugin-gleffects-fix-little-rectangel-appears-at-t.patch
 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad/0007-glplugin-gleffects-fix-little-rectangel-appears-at-t.patch
deleted file mode 100755
index 90bfba9..000
--- 
a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad/0007-glplugin-gleffects-fix-little-rectangel-appears-at-t.patch
+++ /dev/null
@@ -1,46 +0,0 @@
-From 43549773608b4f58dc664b7115a1ef0dcb32f251 Mon Sep 17 00:00:00 2001
-From: Haihua Hu 
-Date: Tue, 14 Jun 2016 13:48:09 +0800
-Subject: [PATCH 1/2] [glplugin]gleffects: fix little rectangel appears at the
- center when use squeeze and tunnel effects
-
-These two shader will calculate the verctor length and use it as denominator.
-But length could be zero which will cause undefine behaviour. Add protection 
for
-this condition
-
-Upstream-Status: Backport [1.8.3]
-
-https://bugzilla.gnome.org/show_bug.cgi?id=767635
-
-Signed-off-by: Haihua Hu 

- ext/gl/effects/gstgleffectssources.c | 6 --
- 1 file changed, 4 insertions(+), 2 deletions(-)
-
-diff --git a/ext/gl/effects/gstgleffectssources.c 
b/ext/gl/effects/gstgleffectssources.c
-index 6bdc155..3e87b8b 100644
 a/ext/gl/effects/gstgleffectssources.c
-+++ b/ext/gl/effects/gstgleffectssources.c
-@@ -100,7 +100,8 @@ const gchar *squeeze_fragment_source_gles2 =
-   "void main () {"
-   "  vec2 texturecoord = v_texcoord.xy;"
-   "  vec2 normcoord = texturecoord - 0.5;"
--  "  float r = length (normcoord);"
-+  /* Add a very small value to length otherwise it could be 0 */
-+  "  float r = length (normcoord)+0.01;"
-   "  r = pow(r, 0.40)*1.3;"
-   "  normcoord = normcoord / r;"
-   "  texturecoord = (normcoord + 0.5);"
-@@ -136,7 +137,8 @@ const gchar *tunnel_fragment_source_gles2 =
-* rect textures */
-   "  normcoord = (texturecoord - 0.5);"
-   "  float r = length(normcoord);"
--  "  normcoord *= clamp (r, 0.0, 0.275) / r;"
-+  "  if (r > 0.0)"
-+  "normcoord *= clamp (r, 0.0, 0.275) / r;"
-   "  texturecoord = normcoord + 0.5;"
-   "  gl_FragColor = texture2D (tex, texturecoord);"
-   "}";
--- 
-1.9.1
-
diff --git

Re: [OE-core] [PATCH v2] python-3.5-manifest.inc: the core module RDEPENDS on misc

2016-08-30 Thread Ricardo Ribalda Delgado

Hi Fabio

Thanks for your the reply. Yes I was using krogoth. There is no need
for my patch in master.

Thanks for your help!
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 00/18] Provide list of deployment artifacts

2016-08-30 Thread Otavio Salvador

On Tue, Aug 30, 2016 at 8:21 AM, Ed Bartosh  wrote:
>> So it is always going to be skipped?
> Yes it is for do_image_complete and do_populate_sdk tasks for now.

Oh ok.

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 2/2] gstreamer1.0: upgrade to 1.8.3

2016-08-30 Thread Maxin B. John

1.8.2 -> 1.8.3

Remove backported patch from 1.8.3:
0007-glplugin-gleffects-fix-little-rectangel-appears-at-t.patch

Signed-off-by: Maxin B. John 
---
 ...-libav_1.8.2.bb => gstreamer1.0-libav_1.8.3.bb} |  4 +-
 .../gstreamer/gstreamer1.0-omx.inc |  1 -
 ...effects-fix-little-rectangel-appears-at-t.patch | 46 --
 ..._1.8.2.bb => gstreamer1.0-plugins-bad_1.8.3.bb} |  5 +--
 ...1.8.2.bb => gstreamer1.0-plugins-base_1.8.3.bb} |  4 +-
 ...1.8.2.bb => gstreamer1.0-plugins-good_1.8.3.bb} |  4 +-
 ...1.8.2.bb => gstreamer1.0-plugins-ugly_1.8.3.bb} |  4 +-
 .../gstreamer/gstreamer1.0-rtsp-server_1.8.2.bb|  6 ---
 .../gstreamer/gstreamer1.0-rtsp-server_1.8.3.bb|  6 +++
 ...gstreamer1.0_1.8.2.bb => gstreamer1.0_1.8.3.bb} |  4 +-
 10 files changed, 18 insertions(+), 66 deletions(-)
 rename meta/recipes-multimedia/gstreamer/{gstreamer1.0-libav_1.8.2.bb => 
gstreamer1.0-libav_1.8.3.bb} (87%)
 delete mode 100755 
meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad/0007-glplugin-gleffects-fix-little-rectangel-appears-at-t.patch
 rename meta/recipes-multimedia/gstreamer/{gstreamer1.0-plugins-bad_1.8.2.bb => 
gstreamer1.0-plugins-bad_1.8.3.bb} (93%)
 rename meta/recipes-multimedia/gstreamer/{gstreamer1.0-plugins-base_1.8.2.bb 
=> gstreamer1.0-plugins-base_1.8.3.bb} (84%)
 rename meta/recipes-multimedia/gstreamer/{gstreamer1.0-plugins-good_1.8.2.bb 
=> gstreamer1.0-plugins-good_1.8.3.bb} (83%)
 rename meta/recipes-multimedia/gstreamer/{gstreamer1.0-plugins-ugly_1.8.2.bb 
=> gstreamer1.0-plugins-ugly_1.8.3.bb} (72%)
 delete mode 100644 
meta/recipes-multimedia/gstreamer/gstreamer1.0-rtsp-server_1.8.2.bb
 create mode 100644 
meta/recipes-multimedia/gstreamer/gstreamer1.0-rtsp-server_1.8.3.bb
 rename meta/recipes-multimedia/gstreamer/{gstreamer1.0_1.8.2.bb => 
gstreamer1.0_1.8.3.bb} (69%)

diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav_1.8.2.bb 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav_1.8.3.bb
similarity index 87%
rename from meta/recipes-multimedia/gstreamer/gstreamer1.0-libav_1.8.2.bb
rename to meta/recipes-multimedia/gstreamer/gstreamer1.0-libav_1.8.3.bb
index 57e8785..3d86221 100644
--- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav_1.8.2.bb
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav_1.8.3.bb
@@ -14,7 +14,7 @@ SRC_URI = " \
 file://workaround-to-build-gst-libav-for-i586-with-gcc.patch \
 "
 
-SRC_URI[md5sum] = "95bc3dd0ea2dc664b4f3a96897005013"
-SRC_URI[sha256sum] = 
"b5f3c7a27b39b5f5c2f0bfd546b0c655020faf6b38d27b64b346c43e5ebf687a"
+SRC_URI[md5sum] = "b51a736147bacb40f85827a4e0ae0d2c"
+SRC_URI[sha256sum] = 
"9006a05990089f7155ee0e848042f6bb24e52ab1d0a59ff8d1b5d7e33001a495"
 
 S = "${WORKDIR}/gst-libav-${PV}"
diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-omx.inc 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-omx.inc
index 0fff612..aa3e820 100644
--- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-omx.inc
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-omx.inc
@@ -11,7 +11,6 @@ inherit autotools pkgconfig gettext
 
 acpaths = "-I ${S}/common/m4 -I ${S}/m4"
 
-PR = "r1"
 
 GSTREAMER_1_0_OMX_TARGET ?= "bellagio"
 GSTREAMER_1_0_OMX_CORE_NAME ?= "${libdir}/libomxil-bellagio.so.0"
diff --git 
a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad/0007-glplugin-gleffects-fix-little-rectangel-appears-at-t.patch
 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad/0007-glplugin-gleffects-fix-little-rectangel-appears-at-t.patch
deleted file mode 100755
index 90bfba9..000
--- 
a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad/0007-glplugin-gleffects-fix-little-rectangel-appears-at-t.patch
+++ /dev/null
@@ -1,46 +0,0 @@
-From 43549773608b4f58dc664b7115a1ef0dcb32f251 Mon Sep 17 00:00:00 2001
-From: Haihua Hu 
-Date: Tue, 14 Jun 2016 13:48:09 +0800
-Subject: [PATCH 1/2] [glplugin]gleffects: fix little rectangel appears at the
- center when use squeeze and tunnel effects
-
-These two shader will calculate the verctor length and use it as denominator.
-But length could be zero which will cause undefine behaviour. Add protection 
for
-this condition
-
-Upstream-Status: Backport [1.8.3]
-
-https://bugzilla.gnome.org/show_bug.cgi?id=767635
-
-Signed-off-by: Haihua Hu 

- ext/gl/effects/gstgleffectssources.c | 6 --
- 1 file changed, 4 insertions(+), 2 deletions(-)
-
-diff --git a/ext/gl/effects/gstgleffectssources.c 
b/ext/gl/effects/gstgleffectssources.c
-index 6bdc155..3e87b8b 100644
 a/ext/gl/effects/gstgleffectssources.c
-+++ b/ext/gl/effects/gstgleffectssources.c
-@@ -100,7 +100,8 @@ const gchar *squeeze_fragment_source_gles2 =
-   "void main () {"
-   "  vec2 texturecoord = v_texcoord.xy;"
-   "  vec2 normcoord = texturecoord - 0.5;"
--  "  float r = length (normcoord);"
-+  /* Add a very small value to length otherwise it could be 0 */
-+  "  float r = length (normcoord)+0.01;"
-   "  r =

[OE-core] [PATCH 1/2] sqlite3: upgrade to 3.14.1

2016-08-30 Thread Maxin B. John

Signed-off-by: Maxin B. John 
---
 meta/recipes-support/sqlite/{sqlite3_3.14.0.bb => sqlite3_3.14.1.bb} | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-support/sqlite/{sqlite3_3.14.0.bb => sqlite3_3.14.1.bb} 
(58%)

diff --git a/meta/recipes-support/sqlite/sqlite3_3.14.0.bb 
b/meta/recipes-support/sqlite/sqlite3_3.14.1.bb
similarity index 58%
rename from meta/recipes-support/sqlite/sqlite3_3.14.0.bb
rename to meta/recipes-support/sqlite/sqlite3_3.14.1.bb
index 6b815c8..3af0d2f 100644
--- a/meta/recipes-support/sqlite/sqlite3_3.14.0.bb
+++ b/meta/recipes-support/sqlite/sqlite3_3.14.1.bb
@@ -5,5 +5,5 @@ LIC_FILES_CHKSUM = 
"file://sqlite3.h;endline=11;md5=65f0a57ca6928710b418c094b357
 
 SRC_URI = "http://www.sqlite.org/2016/sqlite-autoconf-${SQLITE_PV}.tar.gz;
 
-SRC_URI[md5sum] = "1813c764b0ee422adcd1978ea73a3445"
-SRC_URI[sha256sum] = 
"742db0ebbd9cc91ed6a41857f50aa9795fc859c994a256125135cd07f6cdfd76"
+SRC_URI[md5sum] = "3634a90a3f49541462bcaed3474b2684"
+SRC_URI[sha256sum] = 
"bc7182476900017becb81565ecea7775d46ab747a97281aa610f4f45881c47a6"
-- 
2.4.0

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

[OE-core] [PATCH v2 3/3] oeqa.selftest.liboe: add test for xattr in copytree

2016-08-30 Thread Joshua Lock

Add a test to ensure that oe.path.copytree() preserves extended
attributes on files.

Signed-off-by: Joshua Lock 
---
 meta/lib/oeqa/selftest/liboe.py | 32 +++-
 1 file changed, 31 insertions(+), 1 deletion(-)

diff --git a/meta/lib/oeqa/selftest/liboe.py b/meta/lib/oeqa/selftest/liboe.py
index 454b92a..2aeab61 100644
--- a/meta/lib/oeqa/selftest/liboe.py
+++ b/meta/lib/oeqa/selftest/liboe.py
@@ -1,5 +1,5 @@
 from oeqa.selftest.base import oeSelfTest
-from oeqa.utils.commands import get_bb_var
+from oeqa.utils.commands import get_bb_var, bitbake, runCmd
 import oe.path
 import glob
 import os
@@ -31,3 +31,33 @@ class LibOE(oeSelfTest):
 self.assertTrue(fileindst, "File with spaces doesn't exist in dst")
 
 oe.path.remove(testloc)
+
+def test_copy_tree_xattr(self):
+"""
+Summary:oe.path.copytree() should preserve xattr on copied files
+Expected:   testxattr file in destination should have user.oetest
+extended attribute
+Product:OE-Core
+Author: Joshua Lock 
+"""
+tmp_dir = get_bb_var('TMPDIR')
+testloc = oe.path.join(tmp_dir, 'liboetests')
+src = oe.path.join(testloc, 'src')
+dst = oe.path.join(testloc, 'dst')
+bb.utils.mkdirhier(testloc)
+bb.utils.mkdirhier(src)
+testfilename = 'testxattr'
+
+# ensure we have setfattr available
+bitbake("attr-native")
+
+# create a file with xattr and copy it
+open(oe.path.join(src, testfilename), 'w+b').close()
+runCmd('setfattr -n user.oetest -v "testing liboe" %s' % 
oe.path.join(src, testfilename))
+oe.path.copytree(src, dst)
+
+# ensure file in dest has user.oetest xattr
+result = runCmd('getfattr -n user.oetest %s' % oe.path.join(dst, 
testfilename))
+self.assertIn('user.oetest="testing liboe"', result.output, 'Extended 
attribute not sert in dst')
+
+oe.path.remove(testloc)
-- 
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/6] kernel-yocto: streamline patch, configuration and audit phases

2016-08-30 Thread Bruce Ashfield


On 2016-08-30 05:05 AM, André Draszik wrote:

My kmeta stuff is located directly inside two meta-* layers (i.e. not in an
extra git repo), where the 2nd layer's kernel recipes .bbappends to the 1st
one with additional kmeta things.

This used to work fine, but since this commit it doesn't anymore as only the
kmeta stuff from the 2nd layer is being copied into workdir.

Have I been doing something that wasn't guaranteed / supposed to work in the
first place? Or should that still work? Is it worth fixing or should I
rethink my approach?


That was complexity that I had tried to remove, but thinking on it a
bit, I think I can restore that without adding much complexity.

I'm just finishing work on the 4.8 kernel today, and can look at this
tomorrow.

Do you have any public layers that I can reference to pull together a
test case ?

Bruce





Cheers,
Andre'


On Mo, 2016-08-15 at 14:26 -0400, Bruce Ashfield wrote:

We've been running with a set of kern-tools that were designed to work
with build systems that knew nothing about git, trees, commits, etc.

As such, there's been a set of shims/wrappers in place to work with
within bitbake/oe-core. These were the *me scripts: createme, updateme,
patchme and configme.

With this commit, we strip that legacy code and use the tools directly.
This means less complexity, fewer corner cases .. and no surprises
when the tools are arunning. As another benefit, the tools consume
much less time during a typical build and have no noticeable impact
on the overall build time.

Existing .scc files, features, and processing are not impacted as
these tools are compatible with existing feature descriptions and
kerne configuration fragments.

The audit of kernel configuration fragments is now detached
from the linux-yocto build structure and process. This means that
they can eventually be tweaked to offer kernel audit to any type of
kernel build and configuration process.

Additionally, the kernel symbol audit phase can now resolve symbol
dependencies and offer guidance when a symbol is missing:

   WARNING: linux-yocto-4.4.15+gitAUTOINC+b030d96c7b_f5e2c49d58-r0
do_kernel_configcheck: [kernel config]: specified values did not make it
into the kernel's final configuration:

   -- CONFIG_BT_6LOWPAN -
   Config: CONFIG_BT_6LOWPAN
   From: /home/bruce/poky/build/tmp/work-shared/qemux86-64/kernel-
source/.kernel-meta/configs/standard/features/bluetooth/bluetooth.cfg
   Requested value:  CONFIG_BT_6LOWPAN=y
   Actual value:

   Config 'BT_6LOWPAN' has the following conditionals:
 BT_LE && 6LOWPAN (value: "n")
   Dependency values are:
 BT_LE [y] 6LOWPAN [n]

Signed-off-by: Bruce Ashfield 
---
 meta/classes/kernel-yocto.bbclass  | 143 --
---
 .../kern-tools/kern-tools-native_git.bb|   4 +-
 2 files changed, 55 insertions(+), 92 deletions(-)

diff --git a/meta/classes/kernel-yocto.bbclass b/meta/classes/kernel-
yocto.bbclass
index a9d4205..8650e55 100644
--- a/meta/classes/kernel-yocto.bbclass
+++ b/meta/classes/kernel-yocto.bbclass
@@ -119,77 +119,42 @@ do_kernel_metadata() {
patches="${@" ".join(find_patches(d))}"
feat_dirs="${@" ".join(find_kernel_feature_dirs(d))}"

-   # add any explicitly referenced features onto the end of the
feature
-   # list that is passed to the kernel build scripts.
-   if [ -n "${KERNEL_FEATURES}" ]; then
-   for feat in ${KERNEL_FEATURES}; do
-   addon_features="$addon_features --feature $feat"
-   done
-   fi
-
# check for feature directories/repos/branches that were part of
the
# SRC_URI. If they were supplied, we convert them into include
directives
# for the update part of the process
-   if [ -n "${feat_dirs}" ]; then
-   for f in ${feat_dirs}; do
+   for f in ${feat_dirs}; do
if [ -d "${WORKDIR}/$f/meta" ]; then
-   includes="$includes -I${WORKDIR}/$f/meta"
+   includes="$includes -I${WORKDIR}/$f/meta"
elif [ -d "${WORKDIR}/$f" ]; then
-   includes="$includes -I${WORKDIR}/$f"
+   includes="$includes -I${WORKDIR}/$f"
fi
-   done
-   fi
+   done
+   for s in ${sccs}; do
+   sdir=$(dirname $s)
+   includes="$includes -I${sdir}"
+   done

-   # updates or generates the target description
-   updateme ${updateme_flags}
-DKDESC=${KMACHINE}:${LINUX_KERNEL_TYPE} \
- ${includes} ${addon_features} ${ARCH}
${KMACHINE} ${sccs} ${patches}
-   if [ $? -ne 0 ]; then
-   bbfatal_log "Could not update ${machine_branch}"
-   fi
+   # expand kernel features into their full path equivalents
+   bsp_definition=$(spp ${includes} --find -DKMACHINE=${KMACHINE}
-DKTYPE=${LINUX_KERNEL_TYPE})
+   meta_dir=$(kgit --meta)
+
+   #

[OE-core] [PATCH v2 2/3] oe.path: preserve xattr in copytree() and copyhardlinktree()

2016-08-30 Thread Joshua Lock

Pass appropriate options to tar invocations in copytree() and
copyhardlinktree() to ensure that any extended attributes on the files
are preserved during the copy.

We have to drop the use cpio in "Copy-pass" mode in copyhardlinktree()
because cpio doesn't support extended attributes on files. Instead we
revert back to using cp with different patterns depending on whether
or not the directory contains dot files.

Signed-off-by: Joshua Lock 
---
 meta/lib/oe/path.py | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/meta/lib/oe/path.py b/meta/lib/oe/path.py
index 3c07df3..631c3b4 100644
--- a/meta/lib/oe/path.py
+++ b/meta/lib/oe/path.py
@@ -65,7 +65,7 @@ def copytree(src, dst):
 # This way we also preserve hardlinks between files in the tree.
 
 bb.utils.mkdirhier(dst)
-cmd = 'tar -cf - -C %s -p . | tar -xf - -C %s' % (src, dst)
+cmd = "tar --xattrs --xattrs-include='*' -cf - -C %s -p . | tar --xattrs 
--xattrs-include='*' -xf - -C %s" % (src, dst)
 subprocess.check_output(cmd, shell=True, stderr=subprocess.STDOUT)
 
 def copyhardlinktree(src, dst):
@@ -77,9 +77,14 @@ def copyhardlinktree(src, dst):
 if (os.stat(src).st_dev ==  os.stat(dst).st_dev):
 # Need to copy directories only with tar first since cp will error if 
two 
 # writers try and create a directory at the same time
-cmd = 'cd %s; find . -type d -print | tar -cf - -C %s -p 
--no-recursion --files-from - | tar -xf - -C %s' % (src, src, dst)
+cmd = "cd %s; find . -type d -print | tar --xattrs 
--xattrs-include='*' -cf - -C %s -p --no-recursion --files-from - | tar 
--xattrs --xattrs-include='*' -xf - -C %s" % (src, src, dst)
 subprocess.check_output(cmd, shell=True, stderr=subprocess.STDOUT)
-cmd = 'cd %s; find . -print0 | cpio --null -pdlu %s' % (src, dst)
+if os.path.isdir(src):
+import glob
+if len(glob.glob('%s/.??*' % src)) > 0:
+src = src + '/.??* '
+src = src + '/*'
+cmd = 'cp -afl --preserve=xattr %s %s' % (src, dst)
 subprocess.check_output(cmd, shell=True, stderr=subprocess.STDOUT)
 else:
 copytree(src, dst)
-- 
2.7.4

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

[OE-core] [PATCH v2 1/3] oeqa.selftest: add a test for oe.path.copytree()

2016-08-30 Thread Joshua Lock

One motivation for the use of cpio in oe.path.copytree() was to
ensure that files with spaces in their names were copied. Add a new
unittest module to test the OE module with a test case for copytree
with a spaces in a filename.

Signed-off-by: Joshua Lock 
---
 meta/lib/oeqa/selftest/liboe.py | 33 +
 1 file changed, 33 insertions(+)
 create mode 100644 meta/lib/oeqa/selftest/liboe.py

diff --git a/meta/lib/oeqa/selftest/liboe.py b/meta/lib/oeqa/selftest/liboe.py
new file mode 100644
index 000..454b92a
--- /dev/null
+++ b/meta/lib/oeqa/selftest/liboe.py
@@ -0,0 +1,33 @@
+from oeqa.selftest.base import oeSelfTest
+from oeqa.utils.commands import get_bb_var
+import oe.path
+import glob
+import os
+import os.path
+
+class LibOE(oeSelfTest):
+def test_copy_tree_special(self):
+"""
+Summary:oe.path.copytree() should copy files with special character
+Expected:   'test file with sp£c!al @nd spaces' should exist in
+copy destination
+Product:OE-Core
+Author: Joshua Lock 
+"""
+tmp_dir = get_bb_var('TMPDIR')
+testloc = oe.path.join(tmp_dir, 'liboetests')
+src = oe.path.join(testloc, 'src')
+dst = oe.path.join(testloc, 'dst')
+bb.utils.mkdirhier(testloc)
+bb.utils.mkdirhier(src)
+testfilename = 'test file with sp£c!al @nd spaces'
+
+# create the test file and copy it
+open(oe.path.join(src, testfilename), 'w+b').close()
+oe.path.copytree(src, dst)
+
+# ensure path exists in dest
+fileindst = os.path.isfile(oe.path.join(dst, testfilename))
+self.assertTrue(fileindst, "File with spaces doesn't exist in dst")
+
+oe.path.remove(testloc)
-- 
2.7.4

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

[OE-core] [PATCH v2 0/3] Preserve extended attributes in sstate objects

2016-08-30 Thread Joshua Lock

This small series is part of a larger, on-going, effort to better support  
extended attributes (xattr).

The goal of sending these three patches before the whole is complete is to 
improve support for distros with features that rely on xattr that wish to use 
meta-swupd.

meta-swupd creates sstate objects of update artefacts so that an OS update 
delta can be generated against a previous OS release without having to have the 
full build history in TMPDIR — this is especially useful for CI workflows.
Without these changes sstate objects don't preserve xattr and thus swupd 
updates artefacts are incorrect/incomplete.

Changes since v1:
* Drop extra addition of tar to buildtools tarball, it's already included
* Add two tests for oe.path.copytree(); one to ensure files with spaces and 
special characters are copied and one to ensure extended attributes are 
preserved.

Regards,

Joshua

The following changes since commit 384cf92ca9c3e66763c2c1ff2776c53d47ae25d6:

  init-install: Fixes the install script failing when not finding any mmcblk 
devices (2016-08-30 07:57:46 +0100)

are available in the git repository at:

  git://git.openembedded.org/openembedded-core-contrib joshuagl/xattr
  
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=joshuagl/xattr

Joshua Lock (3):
  oeqa.selftest: add a test for oe.path.copytree()
  oe.path: preserve xattr in copytree() and copyhardlinktree()
  oeqa.selftest.liboe: add test for xattr in copytree

 meta/lib/oe/path.py | 11 +--
 meta/lib/oeqa/selftest/liboe.py | 63 +
 2 files changed, 71 insertions(+), 3 deletions(-)
 create mode 100644 meta/lib/oeqa/selftest/liboe.py

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

[OE-core] [PATCH 3/3] libyaml: update to 0.1.7

2016-08-30 Thread Alexander Kanavin

Drop backported libyaml-CVE-2014-9130.patch

Signed-off-by: Alexander Kanavin 
---
 .../libyaml/files/libyaml-CVE-2014-9130.patch  | 33 --
 .../libyaml/{libyaml_0.1.6.bb => libyaml_0.1.7.bb} |  5 ++--
 2 files changed, 2 insertions(+), 36 deletions(-)
 delete mode 100644 
meta/recipes-support/libyaml/files/libyaml-CVE-2014-9130.patch
 rename meta/recipes-support/libyaml/{libyaml_0.1.6.bb => libyaml_0.1.7.bb} 
(72%)

diff --git a/meta/recipes-support/libyaml/files/libyaml-CVE-2014-9130.patch 
b/meta/recipes-support/libyaml/files/libyaml-CVE-2014-9130.patch
deleted file mode 100644
index 61fa7e5..000
--- a/meta/recipes-support/libyaml/files/libyaml-CVE-2014-9130.patch
+++ /dev/null
@@ -1,33 +0,0 @@
-# HG changeset patch
-# User Kirill Simonov 
-# Date 1417197312 21600
-# Node ID 2b9156756423e967cfd09a61d125d883fca6f4f2
-# Parent  053f53a381ff6adbbc93a31ab7fdee06a16c8a33
-Removed invalid simple key assertion (thank to Jonathan Gray).
-
-The patch comes from 
-
-https://bitbucket.org/xi/libyaml/commits/2b9156756423e967cfd09a61d125d883fca6f4f2
-
-Upstream-Status: Backport
-CVE: CVE-2014-9130
-
-Signed-off-by: Yue Tao 
-
-diff -r 053f53a381ff -r 2b9156756423 src/scanner.c
 a/src/scanner.cWed Mar 26 13:55:54 2014 -0500
-+++ b/src/scanner.cFri Nov 28 11:55:12 2014 -0600
-@@ -1106,13 +1106,6 @@
- && parser->indent == (ptrdiff_t)parser->mark.column);
- 
- /*
-- * A simple key is required only when it is the first token in the current
-- * line.  Therefore it is always allowed.  But we add a check anyway.
-- */
--
--assert(parser->simple_key_allowed || !required);/* Impossible. */
--
--/*
-  * If the current position may start a simple key, save it.
-  */
- 
diff --git a/meta/recipes-support/libyaml/libyaml_0.1.6.bb 
b/meta/recipes-support/libyaml/libyaml_0.1.7.bb
similarity index 72%
rename from meta/recipes-support/libyaml/libyaml_0.1.6.bb
rename to meta/recipes-support/libyaml/libyaml_0.1.7.bb
index b015577..5c422ef 100644
--- a/meta/recipes-support/libyaml/libyaml_0.1.6.bb
+++ b/meta/recipes-support/libyaml/libyaml_0.1.7.bb
@@ -8,11 +8,10 @@ LICENSE = "MIT"
 LIC_FILES_CHKSUM = "file://LICENSE;md5=6015f088759b10e0bc2bf64898d4ae17"
 
 SRC_URI = "http://pyyaml.org/download/libyaml/yaml-${PV}.tar.gz \
-   file://libyaml-CVE-2014-9130.patch \
   "
 
-SRC_URI[md5sum] = "5fe00cda18ca5daeb43762b80c38e06e"
-SRC_URI[sha256sum] = 
"7da6971b4bd08a986dd2a61353bc422362bd0edcc67d7ebaac68c95f74182749"
+SRC_URI[md5sum] = "1abf45bd3a96374fa55ca63b32f9f2f9"
+SRC_URI[sha256sum] = 
"8088e457264a98ba451a90b8661fcb4f9d6f478f7265d48322a196cec2480729"
 
 S = "${WORKDIR}/yaml-${PV}"
 
-- 
2.9.3

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

[OE-core] [PATCH 1/3] iso-codes: update to 3.70

2016-08-30 Thread Alexander Kanavin

Signed-off-by: Alexander Kanavin 
---
 .../iso-codes/{iso-codes_3.69.bb => iso-codes_3.70.bb}| 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-support/iso-codes/{iso-codes_3.69.bb => iso-codes_3.70.bb} 
(76%)

diff --git a/meta/recipes-support/iso-codes/iso-codes_3.69.bb 
b/meta/recipes-support/iso-codes/iso-codes_3.70.bb
similarity index 76%
rename from meta/recipes-support/iso-codes/iso-codes_3.69.bb
rename to meta/recipes-support/iso-codes/iso-codes_3.70.bb
index 105949f..7edd8b7 100644
--- a/meta/recipes-support/iso-codes/iso-codes_3.69.bb
+++ b/meta/recipes-support/iso-codes/iso-codes_3.70.bb
@@ -3,8 +3,8 @@ LICENSE = "LGPLv2.1"
 LIC_FILES_CHKSUM = "file://COPYING;md5=4fbd65380cdd255951079008b364516c"
 
 SRC_URI = 
"https://pkg-isocodes.alioth.debian.org/downloads/iso-codes-${PV}.tar.xz;
-SRC_URI[md5sum] = "33ed5ea7eed84a7609f041c838fc96d7"
-SRC_URI[sha256sum] = 
"3f285d3c13f4dccfbdb9e432f172403ac1a54ab432616f10556eb18c23a1c0b2"
+SRC_URI[md5sum] = "c61f8f02eecf978d3710ff594e43ca7e"
+SRC_URI[sha256sum] = 
"41e2fbaec2ed57e767b94f175d0dcd31b627aeb23b75cd604605a6fb6109d61f"
 
 # inherit gettext cannot be used, because it adds gettext-native to 
BASEDEPENDS which
 # are inhibited by allarch
-- 
2.9.3

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

[OE-core] [PATCH 2/3] ffmpeg: update to 3.1.3

2016-08-30 Thread Alexander Kanavin

Signed-off-by: Alexander Kanavin 
---
 meta/recipes-multimedia/ffmpeg/{ffmpeg_3.1.2.bb => ffmpeg_3.1.3.bb} | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-multimedia/ffmpeg/{ffmpeg_3.1.2.bb => ffmpeg_3.1.3.bb} 
(97%)

diff --git a/meta/recipes-multimedia/ffmpeg/ffmpeg_3.1.2.bb 
b/meta/recipes-multimedia/ffmpeg/ffmpeg_3.1.3.bb
similarity index 97%
rename from meta/recipes-multimedia/ffmpeg/ffmpeg_3.1.2.bb
rename to meta/recipes-multimedia/ffmpeg/ffmpeg_3.1.3.bb
index 6aad18e..050f1ee 100644
--- a/meta/recipes-multimedia/ffmpeg/ffmpeg_3.1.2.bb
+++ b/meta/recipes-multimedia/ffmpeg/ffmpeg_3.1.3.bb
@@ -16,8 +16,8 @@ LIC_FILES_CHKSUM = 
"file://COPYING.GPLv2;md5=b234ee4d69f5fce4486a80fdaf4a4263 \
 SRC_URI = "https://www.ffmpeg.org/releases/${BP}.tar.xz \
file://mips64_cpu_detection.patch \
   "
-SRC_URI[md5sum] = "cf030109b066a336fc4f7d3a123abf66"
-SRC_URI[sha256sum] = 
"58d2a2b69f0f46fe8aacd45e582c62e380ba611b5baf6a4dfcf2906eb2b9bd61"
+SRC_URI[md5sum] = "72769316a4b2b8809c7f6d5a8b6766f4"
+SRC_URI[sha256sum] = 
"f8575c071e2a64437aeb70c8c030b385cddbe0b5cde20c9b18a6def840128822"
 
 # Build fails when thumb is enabled: 
https://bugzilla.yoctoproject.org/show_bug.cgi?id=7717
 ARM_INSTRUCTION_SET = "arm"
-- 
2.9.3

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

Re: [OE-core] [PATCH 1/2] buildtools-tarball: add tar

2016-08-30 Thread Paul Eggleton

On Fri, 26 Aug 2016 16:43:05 Joshua Lock wrote:
> We'd like to make use of features which aren't available in tar
> versions prior to 1.27, therefore add tar to the buildtools-tarball
> so that older distributions can still perform builds.
> 
> Signed-off-by: Joshua Lock 
> ---
>  meta/recipes-core/meta/buildtools-tarball.bb | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/meta/recipes-core/meta/buildtools-tarball.bb
> b/meta/recipes-core/meta/buildtools-tarball.bb index 34df531..f28a8c3
> 100644
> --- a/meta/recipes-core/meta/buildtools-tarball.bb
> +++ b/meta/recipes-core/meta/buildtools-tarball.bb
> @@ -24,6 +24,7 @@ TOOLCHAIN_HOST_TASK ?= "\
>  nativesdk-ca-certificates \
>  nativesdk-texinfo \
>  nativesdk-locale-base-en-us \
> +nativesdk-tar \
>  "
> 
>  SDK_PACKAGE_ARCHS += "buildtools-dummy-${SDKPKGSUFFIX}"

Er, tar is already in buildtools-tarball... right?

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] [PATCH 2/2] oe.path: preserve xattr in copytree() and copyhardlinktree()

2016-08-30 Thread Richard Purdie

On Fri, 2016-08-26 at 10:48 -0500, Mark Hatle wrote:
> The reason why cpio was originally used had to do with filenames that
> had spaces
> or other special characters in them.  (this is why the -print0 was
> used)
> 
> I don't object to the change, but we need to make sure that that will
> still work
> properly.
> 
> (Also I thought CPIO -could- do xattrs in the current versions...)

FWIW cpio itself doesn't appear to support xattrs, nor is it likely to
any time soon. It seems people had to use bsdcpio to get that
support...

Cheers,

Richard

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

Re: [OE-core] [PATCH 2/2] oe.path: preserve xattr in copytree() and copyhardlinktree()

2016-08-30 Thread Joshua Lock

On Fri, 2016-08-26 at 10:48 -0500, Mark Hatle wrote:
> On 8/26/16 10:43 AM, Joshua Lock wrote:
> > 
> > Pass appropriate options to tar invocations in copytree() and
> > copyhardlinktree() to ensure that any extended attributes on the
> > files
> > are preserved during the copy.
> > 
> > We have to drop the use cpio in "Copy-pass" mode in
> > copyhardlinktree()
> > because cpio doesn't support extended attributes on files. Instead
> > we
> > revert back to using cp with different patterns depending on
> > whether
> > or not the directory contains dot files.
> > 
> > [YOCTO #9857]
> > 
> > Signed-off-by: Joshua Lock 
> > ---
> >  meta/lib/oe/path.py | 11 ---
> >  1 file changed, 8 insertions(+), 3 deletions(-)
> > 
> > diff --git a/meta/lib/oe/path.py b/meta/lib/oe/path.py
> > index 3c07df3..631c3b4 100644
> > --- a/meta/lib/oe/path.py
> > +++ b/meta/lib/oe/path.py
> > @@ -65,7 +65,7 @@ def copytree(src, dst):
> >  # This way we also preserve hardlinks between files in the
> > tree.
> >  
> >  bb.utils.mkdirhier(dst)
> > -cmd = 'tar -cf - -C %s -p . | tar -xf - -C %s' % (src, dst)
> > +cmd = "tar --xattrs --xattrs-include='*' -cf - -C %s -p . |
> > tar --xattrs --xattrs-include='*' -xf - -C %s" % (src, dst)
> >  subprocess.check_output(cmd, shell=True,
> > stderr=subprocess.STDOUT)
> >  
> >  def copyhardlinktree(src, dst):
> > @@ -77,9 +77,14 @@ def copyhardlinktree(src, dst):
> >  if (os.stat(src).st_dev ==  os.stat(dst).st_dev):
> >  # Need to copy directories only with tar first since cp
> > will error if two 
> >  # writers try and create a directory at the same time
> > -cmd = 'cd %s; find . -type d -print | tar -cf - -C %s -p
> > --no-recursion --files-from - | tar -xf - -C %s' % (src, src, dst)
> > +cmd = "cd %s; find . -type d -print | tar --xattrs --
> > xattrs-include='*' -cf - -C %s -p --no-recursion --files-from - |
> > tar --xattrs --xattrs-include='*' -xf - -C %s" % (src, src, dst)
> >  subprocess.check_output(cmd, shell=True,
> > stderr=subprocess.STDOUT)
> > -cmd = 'cd %s; find . -print0 | cpio --null -pdlu %s' %
> > (src, dst)
> 
> The reason why cpio was originally used had to do with filenames that
> had spaces
> or other special characters in them.  (this is why the -print0 was
> used)
> 
> I don't object to the change, but we need to make sure that that will
> still work
> properly.
> 
> (Also I thought CPIO -could- do xattrs in the current versions...)

It doesn't preserve xattrs the way we currently invoke it and I can't
see anything about xattrs in the man pages on Ubuntu or Fedora (which
both have different man pages for cpio)

I'm going to submit a v2 of this series that:

a) adds a test to ensure files with spaces and other special characters
are correctly copied.
b) adds a test to ensure that xattr on a file are preserved.

Regards,

Joshua

> 
> --Mark
> 
> > 
> > +if os.path.isdir(src):
> > +import glob
> > +if len(glob.glob('%s/.??*' % src)) > 0:
> > +src = src + '/.??* '
> > +src = src + '/*'
> > +cmd = 'cp -afl --preserve=xattr %s %s' % (src, dst)
> >  subprocess.check_output(cmd, shell=True,
> > stderr=subprocess.STDOUT)
> >  else:
> >  copytree(src, dst)
> > 
> 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 00/18] Provide list of deployment artifacts

2016-08-30 Thread Ed Bartosh

On Tue, Aug 30, 2016 at 07:58:31AM -0300, Otavio Salvador wrote:
> On Tue, Aug 30, 2016 at 7:35 AM, Ed Bartosh  
> wrote:
> > On Tue, Aug 30, 2016 at 07:21:20AM -0300, Otavio Salvador wrote:
> >> On Tue, Aug 30, 2016 at 6:29 AM, Ed Bartosh  
> >> wrote:
> >> > Hi,
> >> >
> >> > This is a fix for Bug #9869 - Provide a per-target manifest of files 
> >> > which were, or would have been, produced
> >> >
> >> > The list of artifacts produced by deployment tasks (do_deploy, 
> >> > do_image_complete and do_populate_sdk[_ext] is
> >> > obtained from sstate manifests and fired as a TaskArtifacts metadata 
> >> > event. This should allow Toaster to
> >> > handle artifacts in simple way and remove a lot of current Toaster code 
> >> > doing guess work.
> >> >
> >> > To generate manifests for do_image_complete and do_populate_sdk they 
> >> > have been put under sstate control.
> >> >
> >> > To avoid storing big files(images and sdk installer) in sstate new 
> >> > variable SSTATE_SKIP_CREATION has been
> >> > set in image.bbclass and populate_sdk_base.bbclass and sstate code was 
> >> > modified to avoid adding files
> >> > to sstate if SSTATE_SKIP_CREATION is set.
> >>
> >> SKIP creation of what?
> > SKIP creation of SSTATE entity.
> 
> I know but of WHAT?
Of anything we don't want to put to sstate. In this patchset it's set
for do_image_complete and do_populate_sdk, so it's for images and sdk
installer.

> SSTATE_SKIP_IMAGE_CREATION would be a clearer name for me.
I'm not sure about it. I'd need one more variable
SSTATE_SKIP_SDK_INSTALLER if I go this way.

> >> Variable name seems a little vague for me. Even
> >> needing the manifest, does it makes sense to store the image and SDK
> >> on sstate?
> > It doesn't and skipping this is a purpose of introducing 
> > SSTATE_SKIP_CREATION variable.
>
> So it is always going to be skipped?
Yes it is for do_image_complete and do_populate_sdk tasks for now.

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

Re: [OE-core] [PATCH 00/18] Provide list of deployment artifacts

2016-08-30 Thread Otavio Salvador

On Tue, Aug 30, 2016 at 7:35 AM, Ed Bartosh  wrote:
> On Tue, Aug 30, 2016 at 07:21:20AM -0300, Otavio Salvador wrote:
>> On Tue, Aug 30, 2016 at 6:29 AM, Ed Bartosh  
>> wrote:
>> > Hi,
>> >
>> > This is a fix for Bug #9869 - Provide a per-target manifest of files which 
>> > were, or would have been, produced
>> >
>> > The list of artifacts produced by deployment tasks (do_deploy, 
>> > do_image_complete and do_populate_sdk[_ext] is
>> > obtained from sstate manifests and fired as a TaskArtifacts metadata 
>> > event. This should allow Toaster to
>> > handle artifacts in simple way and remove a lot of current Toaster code 
>> > doing guess work.
>> >
>> > To generate manifests for do_image_complete and do_populate_sdk they have 
>> > been put under sstate control.
>> >
>> > To avoid storing big files(images and sdk installer) in sstate new 
>> > variable SSTATE_SKIP_CREATION has been
>> > set in image.bbclass and populate_sdk_base.bbclass and sstate code was 
>> > modified to avoid adding files
>> > to sstate if SSTATE_SKIP_CREATION is set.
>>
>> SKIP creation of what?
> SKIP creation of SSTATE entity.

I know but of WHAT?

SSTATE_SKIP_IMAGE_CREATION would be a clearer name for me.

>> Variable name seems a little vague for me. Even
>> needing the manifest, does it makes sense to store the image and SDK
>> on sstate?
> It doesn't and skipping this is a purpose of introducing SSTATE_SKIP_CREATION 
> variable.

So it is always going to be skipped?

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 00/18] Provide list of deployment artifacts

2016-08-30 Thread Ed Bartosh

On Tue, Aug 30, 2016 at 07:21:20AM -0300, Otavio Salvador wrote:
> On Tue, Aug 30, 2016 at 6:29 AM, Ed Bartosh  
> wrote:
> > Hi,
> >
> > This is a fix for Bug #9869 - Provide a per-target manifest of files which 
> > were, or would have been, produced
> >
> > The list of artifacts produced by deployment tasks (do_deploy, 
> > do_image_complete and do_populate_sdk[_ext] is
> > obtained from sstate manifests and fired as a TaskArtifacts metadata event. 
> > This should allow Toaster to
> > handle artifacts in simple way and remove a lot of current Toaster code 
> > doing guess work.
> >
> > To generate manifests for do_image_complete and do_populate_sdk they have 
> > been put under sstate control.
> >
> > To avoid storing big files(images and sdk installer) in sstate new variable 
> > SSTATE_SKIP_CREATION has been
> > set in image.bbclass and populate_sdk_base.bbclass and sstate code was 
> > modified to avoid adding files
> > to sstate if SSTATE_SKIP_CREATION is set.
> 
> SKIP creation of what?
SKIP creation of SSTATE entity.

> Variable name seems a little vague for me. Even
> needing the manifest, does it makes sense to store the image and SDK
> on sstate?
It doesn't and skipping this is a purpose of introducing SSTATE_SKIP_CREATION 
variable.

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

Re: [OE-core] [PATCH 00/18] Provide list of deployment artifacts

2016-08-30 Thread Otavio Salvador

On Tue, Aug 30, 2016 at 6:29 AM, Ed Bartosh  wrote:
> Hi,
>
> This is a fix for Bug #9869 - Provide a per-target manifest of files which 
> were, or would have been, produced
>
> The list of artifacts produced by deployment tasks (do_deploy, 
> do_image_complete and do_populate_sdk[_ext] is
> obtained from sstate manifests and fired as a TaskArtifacts metadata event. 
> This should allow Toaster to
> handle artifacts in simple way and remove a lot of current Toaster code doing 
> guess work.
>
> To generate manifests for do_image_complete and do_populate_sdk they have 
> been put under sstate control.
>
> To avoid storing big files(images and sdk installer) in sstate new variable 
> SSTATE_SKIP_CREATION has been
> set in image.bbclass and populate_sdk_base.bbclass and sstate code was 
> modified to avoid adding files
> to sstate if SSTATE_SKIP_CREATION is set.

SKIP creation of what? Variable name seems a little vague for me. Even
needing the manifest, does it makes sense to store the image and SDK
on sstate?

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 00/18] Provide list of deployment artifacts

2016-08-30 Thread Richard Purdie

Hi Ed,

On Tue, 2016-08-30 at 12:29 +0300, Ed Bartosh wrote:
> This is a fix for Bug #9869 - Provide a per-target manifest of files
> which were, or would have been, produced
> 
> The list of artifacts produced by deployment tasks (do_deploy,
> do_image_complete and do_populate_sdk[_ext] is
> obtained from sstate manifests and fired as a TaskArtifacts metadata
> event. This should allow Toaster to
> handle artifacts in simple way and remove a lot of current Toaster
> code doing guess work.
> 
> To generate manifests for do_image_complete and do_populate_sdk they
> have been put under sstate control.
> 
> To avoid storing big files(images and sdk installer) in sstate new
> variable SSTATE_SKIP_CREATION has been
> set in image.bbclass and populate_sdk_base.bbclass and sstate code
> was modified to avoid adding files
> to sstate if SSTATE_SKIP_CREATION is set.

I'd like to see this series reordered to:

a) Set DEPLOYDIR in image.bbclass/populate_sdk_base.bbclass to point at
DEPLOY_DIR_IMAGE
b) Add SSTATE_SKIP_CREATION support
c) Make all the DEPLOY_DIR_IMAGE -> DEPLOYDIR changes in one patch
d) Enable sstate for images (change DEPLOYDIR definition, add the flags
including cleandirs, stamp-extra, set SSTATE_SKIP_CREATION)
e) As per d but for populate_sdk_base

That way it applies incrementally and like changes are all grouped
together. It will mean some commit messages are longer and squashed
together but I think that is fine.

Cheers,

Richard

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

Re: [OE-core] Build of u-boot with gold is broken

2016-08-30 Thread Andrew Goodbody

From: Burton, Ross 
On 19 August 2016 at 10:33, Andrew Goodbody 
> wrote:
The sed at line 70 fails as it is being executed in an empty build directory 
and so there is no config.mk.

For fame and glory, can you send a tested patch to fix this?

Ross

Sorry but I am not sure about the best way to fix this.

Andrew

PS This is a resend (with additions below) as I neglected to copy the list, 
sorry - I was out of the office at the time.
It would be possible to simply cd into the source directory, apply the sed, 
then cd back to the build directory. However this seems to go against the point 
of having a separate build directory in that you are attempting to leave the 
source tree alone, or so I assume.
In my local tree I simply revert

commit 36f110594506fbee5dc18de3a04981f019f2024d
Author: Manjukumar Matha 
Date:   Tue Aug 9 10:15:07 2016 -0700

u-boot.inc: Enable out-of-tree builds

This patch enabled out-of-tree builds for u-boot. This also helps building
u-boot using EXTERNALSRC flow

Signed-off-by: Manjukumar Matha 
Signed-off-by: Ross Burton 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 18/18] toaster: fire TaskArtifacts event

2016-08-30 Thread Ed Bartosh

Fire TaskArtifact MetaData event for deployment tasks when task
either completed or skipped. Event contains full task id
(recipe+task) and list of deployment artifacts from sstate
manifest.

This should allow Toaster to always get notified about deployment
artifacts produced by the build.

[YOCTO #9869]

Signed-off-by: Ed Bartosh 
---
 meta/classes/toaster.bbclass | 17 +
 1 file changed, 17 insertions(+)

diff --git a/meta/classes/toaster.bbclass b/meta/classes/toaster.bbclass
index 972efb9..4bddf34 100644
--- a/meta/classes/toaster.bbclass
+++ b/meta/classes/toaster.bbclass
@@ -324,6 +324,20 @@ python toaster_buildhistory_dump() {
 
 }
 
+# get list of artifacts from sstate manifest
+python toaster_artifacts() {
+if e.taskname in ["do_deploy", "do_image_complete", "do_populate_sdk", 
"do_populate_sdk_ext"]:
+d2 = d.createCopy()
+d2.setVar('FILE', e.taskfile)
+d2.setVar('SSTATE_MANMACH', d2.expand("${MACHINE}"))
+manifest = oe.sstatesig.sstate_get_manifest_filename(e.taskname[3:], 
d2)[0]
+if os.access(manifest, os.R_OK):
+with open(manifest) as fmanifest:
+artifacts = [fname.strip() for fname in fmanifest]
+data = {"task": e.taskid, "artifacts": artifacts}
+bb.event.fire(bb.event.MetadataEvent("TaskArtifacts", data), 
d2)
+}
+
 # set event handlers
 addhandler toaster_layerinfo_dumpdata
 toaster_layerinfo_dumpdata[eventmask] = "bb.event.TreeDataPreparationCompleted"
@@ -334,6 +348,9 @@ toaster_collect_task_stats[eventmask] = 
"bb.event.BuildCompleted bb.build.TaskSu
 addhandler toaster_buildhistory_dump
 toaster_buildhistory_dump[eventmask] = "bb.event.BuildCompleted"
 
+addhandler toaster_artifacts
+toaster_artifacts[eventmask] = "bb.runqueue.runQueueTaskSkipped 
bb.runqueue.runQueueTaskCompleted"
+
 do_packagedata_setscene[postfuncs] += "toaster_package_dumpdata "
 do_packagedata_setscene[vardepsexclude] += "toaster_package_dumpdata "
 
-- 
2.1.4

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

[OE-core] [PATCH 17/18] image: populate_sdk_base: set stamp-extra-info flag

2016-08-30 Thread Ed Bartosh

This flag is used in the name of sstate manifest.

Setting it to predetermined value for image_complete and populate_sdk
tasks should help to get correct manifest filenames when processing
runQueueTask events.

Signed-off-by: Ed Bartosh 
---
 meta/classes/image.bbclass | 1 +
 meta/classes/populate_sdk_base.bbclass | 1 +
 2 files changed, 2 insertions(+)

diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index 8e84b1b..49fe500 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -280,6 +280,7 @@ do_image_complete[dirs] = "${TOPDIR}"
 do_image_complete[umask] = "022"
 do_image_complete[sstate-inputdirs] = "${DEPLOYDIR}"
 do_image_complete[sstate-outputdirs] = "${DEPLOY_DIR_IMAGE}"
+do_image_complete[stamp-extra-info] = "${MACHINE}"
 addtask do_image_complete after do_image before do_build
 
 # Add image-level QA/sanity checks to IMAGE_QA_COMMANDS
diff --git a/meta/classes/populate_sdk_base.bbclass 
b/meta/classes/populate_sdk_base.bbclass
index 1914a3b..ede3a7b 100644
--- a/meta/classes/populate_sdk_base.bbclass
+++ b/meta/classes/populate_sdk_base.bbclass
@@ -122,6 +122,7 @@ fakeroot python do_populate_sdk() {
 
 do_populate_sdk[sstate-inputdirs] = "${DEPLOYDIR}"
 do_populate_sdk[sstate-outputdirs] = "${SDK_DEPLOY}"
+do_populate_sdk[stamp-extra-info] = "${MACHINE}"
 
 fakeroot create_sdk_files() {
cp ${COREBASE}/scripts/relocate_sdk.py ${SDK_OUTPUT}/${SDKPATH}/
-- 
2.1.4

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

[OE-core] [PATCH 16/18] image: populate_sdk_base: skip sstate creation

2016-08-30 Thread Ed Bartosh

Set SSTATE_SKIP_CREATION variable to '1' for image_complete and
populate_sdk tasks as we don't want to put images and sdk installer
into sstate due to their big size. We added these tasks under sstate
control only for two reasons:
 - to generate sstate manifest
 - to make final deployments

Signed-off-by: Ed Bartosh 
---
 meta/classes/image.bbclass | 1 +
 meta/classes/populate_sdk_base.bbclass | 1 +
 2 files changed, 2 insertions(+)

diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index bbdfd8a..8e84b1b 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -267,6 +267,7 @@ addtask do_image after do_rootfs before do_build
 
 DEPLOYDIR = "${WORKDIR}/deploy-${PN}"
 SSTATETASKS += "do_image_complete"
+SSTATE_SKIP_CREATION_task-image-complete = '1'
 
 fakeroot python do_image_complete () {
 from oe.utils import execute_pre_post_process
diff --git a/meta/classes/populate_sdk_base.bbclass 
b/meta/classes/populate_sdk_base.bbclass
index c1dac39..1914a3b 100644
--- a/meta/classes/populate_sdk_base.bbclass
+++ b/meta/classes/populate_sdk_base.bbclass
@@ -28,6 +28,7 @@ SDK_DEPLOY = "${DEPLOY_DIR}/sdk"
 
 DEPLOYDIR = "${WORKDIR}/deploy-${PN}"
 SSTATETASKS += "do_populate_sdk"
+SSTATE_SKIP_CREATION_task-populate-sdk = '1'
 
 B_task-populate-sdk = "${SDK_DIR}"
 
-- 
2.1.4

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

[OE-core] [PATCH 15/18] sstate.bbclass: skip packaging if SSTATE_SKIP_CREATION is set

2016-08-30 Thread Ed Bartosh

SSTATE_SKIP_CREATION variable will be used to skip creation of
sstate .tgz files. It makes sense for image creation tasks as
tarring images and keeping them in sstate would consume a lot of
disk space.

Signed-off-by: Ed Bartosh 
---
 meta/classes/sstate.bbclass | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/classes/sstate.bbclass b/meta/classes/sstate.bbclass
index 2496928..0f0baeb 100644
--- a/meta/classes/sstate.bbclass
+++ b/meta/classes/sstate.bbclass
@@ -566,6 +566,8 @@ def sstate_package(ss, d):
 for state in ss['dirs']:
 if not os.path.exists(state[1]):
 continue
+if d.getVar('SSTATE_SKIP_CREATION', True) == '1':
+continue
 srcbase = state[0].rstrip("/").rsplit('/', 1)[0]
 for walkroot, dirs, files in os.walk(state[1]):
 for file in files:
-- 
2.1.4

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

[OE-core] [PATCH 11/18] rootfs.py: use DEPLOYDIR instead of DEPLOY_DIR_IMAGE

2016-08-30 Thread Ed Bartosh

Updated the code of Rootfs class to use DEPLOYDIR variable
as it's now used as a new deployment destination.

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

diff --git a/meta/lib/oe/rootfs.py b/meta/lib/oe/rootfs.py
index 7c620e9..076bc33 100644
--- a/meta/lib/oe/rootfs.py
+++ b/meta/lib/oe/rootfs.py
@@ -19,7 +19,7 @@ class Rootfs(object, metaclass=ABCMeta):
 self.d = d
 self.pm = None
 self.image_rootfs = self.d.getVar('IMAGE_ROOTFS', True)
-self.deploy_dir_image = self.d.getVar('DEPLOY_DIR_IMAGE', True)
+self.deploydir = self.d.getVar('DEPLOYDIR', True)
 self.progress_reporter = progress_reporter
 
 self.install_order = Manifest.INSTALL_ORDER
@@ -182,12 +182,12 @@ class Rootfs(object, metaclass=ABCMeta):
 
 bb.utils.mkdirhier(self.image_rootfs)
 
-bb.utils.mkdirhier(self.deploy_dir_image)
+bb.utils.mkdirhier(self.deploydir)
 
 shutil.copytree(postinst_intercepts_dir, intercepts_dir)
 
 
shutil.copy(self.d.expand("${COREBASE}/meta/files/deploydir_readme.txt"),
-self.deploy_dir_image +
+self.deploydir +
 "/README_-_DO_NOT_DELETE_FILES_IN_THIS_DIRECTORY.txt")
 
 execute_pre_post_process(self.d, pre_process_cmds)
-- 
2.1.4

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

[OE-core] [PATCH 14/18] populate_sdk_base: put populate_sdk under sstate control

2016-08-30 Thread Ed Bartosh

Adding populate_sdk task to SSTATE_TASKS should make sstate machinery
to generate manifest for deployed sdk artifacts and do final deployment
to SDK_DEPLOY.

Signed-off-by: Ed Bartosh 
---
 meta/classes/populate_sdk_base.bbclass | 4 
 1 file changed, 4 insertions(+)

diff --git a/meta/classes/populate_sdk_base.bbclass 
b/meta/classes/populate_sdk_base.bbclass
index 4d2bc9a..c1dac39 100644
--- a/meta/classes/populate_sdk_base.bbclass
+++ b/meta/classes/populate_sdk_base.bbclass
@@ -27,6 +27,7 @@ SDK_OUTPUT = "${SDK_DIR}/image"
 SDK_DEPLOY = "${DEPLOY_DIR}/sdk"
 
 DEPLOYDIR = "${WORKDIR}/deploy-${PN}"
+SSTATETASKS += "do_populate_sdk"
 
 B_task-populate-sdk = "${SDK_DIR}"
 
@@ -118,6 +119,9 @@ fakeroot python do_populate_sdk() {
 populate_sdk(d)
 }
 
+do_populate_sdk[sstate-inputdirs] = "${DEPLOYDIR}"
+do_populate_sdk[sstate-outputdirs] = "${SDK_DEPLOY}"
+
 fakeroot create_sdk_files() {
cp ${COREBASE}/scripts/relocate_sdk.py ${SDK_OUTPUT}/${SDKPATH}/
 
-- 
2.1.4

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

[OE-core] [PATCH 13/18] image.bbclass: cleanup DEPLOYDIR

2016-08-30 Thread Ed Bartosh

Make sure DEPLOYDIR doesn't contain images from past deployments
to prevent them to be included into sstate manifests.

Signed-off-by: Ed Bartosh 
---
 meta/classes/image.bbclass | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index 3bfc328..bbdfd8a 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -262,6 +262,7 @@ fakeroot python do_image () {
 }
 do_image[dirs] = "${TOPDIR}"
 do_image[umask] = "022"
+do_image[cleandirs] = "${DEPLOYDIR}"
 addtask do_image after do_rootfs before do_build
 
 DEPLOYDIR = "${WORKDIR}/deploy-${PN}"
-- 
2.1.4

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

[OE-core] [PATCH 12/18] image.bbclass: put image_complete under sstate control

2016-08-30 Thread Ed Bartosh

Adding image_complete task should make sstate machinery
to generate manifest for deployed images and do final
deployment to DEPLOY_DIR_IMAGE.

Signed-off-by: Ed Bartosh 
---
 meta/classes/image.bbclass | 5 +
 1 file changed, 5 insertions(+)

diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index ea3792a7..3bfc328 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -264,6 +264,9 @@ do_image[dirs] = "${TOPDIR}"
 do_image[umask] = "022"
 addtask do_image after do_rootfs before do_build
 
+DEPLOYDIR = "${WORKDIR}/deploy-${PN}"
+SSTATETASKS += "do_image_complete"
+
 fakeroot python do_image_complete () {
 from oe.utils import execute_pre_post_process
 
@@ -273,6 +276,8 @@ fakeroot python do_image_complete () {
 }
 do_image_complete[dirs] = "${TOPDIR}"
 do_image_complete[umask] = "022"
+do_image_complete[sstate-inputdirs] = "${DEPLOYDIR}"
+do_image_complete[sstate-outputdirs] = "${DEPLOY_DIR_IMAGE}"
 addtask do_image_complete after do_image before do_build
 
 # Add image-level QA/sanity checks to IMAGE_QA_COMMANDS
-- 
2.1.4

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

[OE-core] [PATCH 10/18] selftest: renamed variable

2016-08-30 Thread Ed Bartosh

Renamed variable deploy_dir to deploy_dir_image to avoid
confusion with DEPLOYDIR variable.

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

diff --git a/meta/lib/oeqa/selftest/imagefeatures.py 
b/meta/lib/oeqa/selftest/imagefeatures.py
index 08e382f..d015c49 100644
--- a/meta/lib/oeqa/selftest/imagefeatures.py
+++ b/meta/lib/oeqa/selftest/imagefeatures.py
@@ -113,9 +113,9 @@ class ImageFeatures(oeSelfTest):
 image_name = 'core-image-minimal'
 bitbake(image_name)
 
-deploy_dir = get_bb_var('DEPLOY_DIR_IMAGE')
+deploy_dir_image = get_bb_var('DEPLOY_DIR_IMAGE')
 link_name = get_bb_var('IMAGE_LINK_NAME', image_name)
-image_path = os.path.join(deploy_dir, "%s.ext4" % link_name)
+image_path = os.path.join(deploy_dir_image, "%s.ext4" % link_name)
 bmap_path = "%s.bmap" % image_path
 
 # check if result image and bmap file are in deploy directory
-- 
2.1.4

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

[OE-core] [PATCH 08/18] populate_sdk_base.bbclass: deploy sdk artifacts to DEPLOYDIR

2016-08-30 Thread Ed Bartosh

Changed deployment directory from SDK_DEPLOY to DEPLOYDIR
to make sstate machinery to do final deployment and generate
manifest.

Signed-off-by: Ed Bartosh 
---
 meta/classes/populate_sdk_base.bbclass | 22 --
 1 file changed, 12 insertions(+), 10 deletions(-)

diff --git a/meta/classes/populate_sdk_base.bbclass 
b/meta/classes/populate_sdk_base.bbclass
index 645a7f4..4d2bc9a 100644
--- a/meta/classes/populate_sdk_base.bbclass
+++ b/meta/classes/populate_sdk_base.bbclass
@@ -26,6 +26,8 @@ SDK_DIR = "${WORKDIR}/sdk"
 SDK_OUTPUT = "${SDK_DIR}/image"
 SDK_DEPLOY = "${DEPLOY_DIR}/sdk"
 
+DEPLOYDIR = "${WORKDIR}/deploy-${PN}"
+
 B_task-populate-sdk = "${SDK_DIR}"
 
 SDKTARGETSYSROOT = "${SDKPATH}/sysroots/${REAL_MULTIMACH_TARGET_SYS}"
@@ -58,8 +60,8 @@ SDK_RELOCATE_AFTER_INSTALL ?= "1"
 SDKEXTPATH ?= "~/${@d.getVar('DISTRO', True)}_sdk"
 SDK_TITLE ?= "${@d.getVar('DISTRO_NAME', True) or d.getVar('DISTRO', True)} 
SDK"
 
-SDK_TARGET_MANIFEST = "${SDK_DEPLOY}/${TOOLCHAIN_OUTPUTNAME}.target.manifest"
-SDK_HOST_MANIFEST = "${SDK_DEPLOY}/${TOOLCHAIN_OUTPUTNAME}.host.manifest"
+SDK_TARGET_MANIFEST = "${DEPLOYDIR}/${TOOLCHAIN_OUTPUTNAME}.target.manifest"
+SDK_HOST_MANIFEST = "${DEPLOYDIR}/${TOOLCHAIN_OUTPUTNAME}.host.manifest"
 python write_target_sdk_manifest () {
 from oe.sdk import sdk_list_installed_packages
 from oe.utils import format_pkg_list
@@ -180,14 +182,14 @@ SDKTAROPTS = "--owner=root --group=root"
 
 fakeroot tar_sdk() {
# Package it up
-   mkdir -p ${SDK_DEPLOY}
+   mkdir -p ${DEPLOYDIR}
cd ${SDK_OUTPUT}/${SDKPATH}
-   tar ${SDKTAROPTS} -cf - . | pixz > 
${SDK_DEPLOY}/${TOOLCHAIN_OUTPUTNAME}.tar.xz
+   tar ${SDKTAROPTS} -cf - . | pixz > 
${DEPLOYDIR}/${TOOLCHAIN_OUTPUTNAME}.tar.xz
 }
 
 fakeroot create_shar() {
# copy in the template shar extractor script
-   cp ${COREBASE}/meta/files/toolchain-shar-extract.sh 
${SDK_DEPLOY}/${TOOLCHAIN_OUTPUTNAME}.sh
+   cp ${COREBASE}/meta/files/toolchain-shar-extract.sh 
${DEPLOYDIR}/${TOOLCHAIN_OUTPUTNAME}.sh
 
rm -f ${T}/pre_install_command ${T}/post_install_command
 
@@ -203,7 +205,7 @@ ${SDK_POST_INSTALL_COMMAND}
 EOF
sed -i -e '/@SDK_PRE_INSTALL_COMMAND@/r ${T}/pre_install_command' \
-e '/@SDK_POST_INSTALL_COMMAND@/r ${T}/post_install_command' \
-   ${SDK_DEPLOY}/${TOOLCHAIN_OUTPUTNAME}.sh
+   ${DEPLOYDIR}/${TOOLCHAIN_OUTPUTNAME}.sh
 
# substitute variables
sed -i -e 's#@SDK_ARCH@#${SDK_ARCH}#g' \
@@ -215,16 +217,16 @@ EOF
-e 's#@SDK_VERSION@#${SDK_VERSION}#g' \
-e '/@SDK_PRE_INSTALL_COMMAND@/d' \
-e '/@SDK_POST_INSTALL_COMMAND@/d' \
-   ${SDK_DEPLOY}/${TOOLCHAIN_OUTPUTNAME}.sh
+   ${DEPLOYDIR}/${TOOLCHAIN_OUTPUTNAME}.sh
 
# add execution permission
-   chmod +x ${SDK_DEPLOY}/${TOOLCHAIN_OUTPUTNAME}.sh
+   chmod +x ${DEPLOYDIR}/${TOOLCHAIN_OUTPUTNAME}.sh
 
# append the SDK tarball
-   cat ${SDK_DEPLOY}/${TOOLCHAIN_OUTPUTNAME}.tar.xz >> 
${SDK_DEPLOY}/${TOOLCHAIN_OUTPUTNAME}.sh
+   cat ${DEPLOYDIR}/${TOOLCHAIN_OUTPUTNAME}.tar.xz >> 
${DEPLOYDIR}/${TOOLCHAIN_OUTPUTNAME}.sh
 
# delete the old tarball, we don't need it anymore
-   rm ${SDK_DEPLOY}/${TOOLCHAIN_OUTPUTNAME}.tar.xz
+   rm ${DEPLOYDIR}/${TOOLCHAIN_OUTPUTNAME}.tar.xz
 }
 
 populate_sdk_log_check() {
-- 
2.1.4

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

[OE-core] [PATCH 06/18] syslinux.bbclass: deploy bootloader to DEPLOYDIR

2016-08-30 Thread Ed Bartosh

Changed deployment directory from DEPLOY_DIR_IMAGE to DEPLOYDIR
to make sstate machinery to do final deployment and generate
manifest.

Signed-off-by: Ed Bartosh 
---
 meta/classes/syslinux.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/syslinux.bbclass b/meta/classes/syslinux.bbclass
index 35d9eed..fd4c32e 100644
--- a/meta/classes/syslinux.bbclass
+++ b/meta/classes/syslinux.bbclass
@@ -72,7 +72,7 @@ syslinux_hddimg_populate() {
 }
 
 syslinux_hddimg_install() {
-   syslinux ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.hddimg
+   syslinux ${DEPLOYDIR}/${IMAGE_NAME}.hddimg
 }
 
 syslinux_hdddirect_install() {
-- 
2.1.4

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

[OE-core] [PATCH 09/18] rootfs-postcommands.bbclass: generate manifest in DEPLOYDIR

2016-08-30 Thread Ed Bartosh

Updated manifest path as deployment directory is changed
from DEPLOY_DIR_IMAGE to DEPLOYDIR.

Signed-off-by: Ed Bartosh 
---
 meta/classes/rootfs-postcommands.bbclass | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/classes/rootfs-postcommands.bbclass 
b/meta/classes/rootfs-postcommands.bbclass
index b38b6a5..f8a63b0 100644
--- a/meta/classes/rootfs-postcommands.bbclass
+++ b/meta/classes/rootfs-postcommands.bbclass
@@ -15,7 +15,7 @@ ROOTFS_POSTPROCESS_COMMAND += "rootfs_update_timestamp ; "
 ROOTFS_POSTPROCESS_COMMAND += '${@bb.utils.contains("IMAGE_FEATURES", 
"read-only-rootfs", "read_only_rootfs_hook; ", "",d)}'
 
 # Write manifest
-IMAGE_MANIFEST = "${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.manifest"
+IMAGE_MANIFEST = "${DEPLOYDIR}/${IMAGE_NAME}.rootfs.manifest"
 ROOTFS_POSTUNINSTALL_COMMAND =+ "write_image_manifest ; "
 # Set default postinst log file
 POSTINST_LOGFILE ?= "${localstatedir}/log/postinstall.log"
@@ -217,7 +217,7 @@ python write_image_manifest () {
 from oe.rootfs import image_list_installed_packages
 from oe.utils import format_pkg_list
 
-deploy_dir = d.getVar('DEPLOY_DIR_IMAGE', True)
+deploy_dir = d.getVar('DEPLOYDIR', True)
 link_name = d.getVar('IMAGE_LINK_NAME', True)
 manifest_name = d.getVar('IMAGE_MANIFEST', True)
 
-- 
2.1.4

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

[OE-core] [PATCH 07/18] build-appliance-image: process images in DEPLOYDIR

2016-08-30 Thread Ed Bartosh

Updated path to images as deployment directory is changed
from DEPLOY_DIR_IMAGE to DEPLOYDIR.

Signed-off-by: Ed Bartosh 
---
 meta/recipes-core/images/build-appliance-image_15.0.0.bb | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/meta/recipes-core/images/build-appliance-image_15.0.0.bb 
b/meta/recipes-core/images/build-appliance-image_15.0.0.bb
index dc621d6..f7d57a8 100644
--- a/meta/recipes-core/images/build-appliance-image_15.0.0.bb
+++ b/meta/recipes-core/images/build-appliance-image_15.0.0.bb
@@ -32,7 +32,7 @@ BA_INCLUDE_SOURCES ??= "0"
 
 IMAGE_CMD_ext4_append () {
# We don't need to reserve much space for root, 0.5% is more than enough
-   tune2fs -m 0.5 ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.ext4
+   tune2fs -m 0.5 ${DEPLOYDIR}/${IMAGE_NAME}.rootfs.ext4
 }
 
 fakeroot do_populate_poky_src () {
@@ -101,9 +101,9 @@ create_bundle_files () {
cd ${WORKDIR}
mkdir -p Yocto_Build_Appliance
cp *.vmx* Yocto_Build_Appliance
-   ln -sf ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.vmdk 
Yocto_Build_Appliance/Yocto_Build_Appliance.vmdk
-   zip -r ${DEPLOY_DIR_IMAGE}/Yocto_Build_Appliance-${DATETIME}.zip 
Yocto_Build_Appliance
-   ln -sf Yocto_Build_Appliance-${DATETIME}.zip 
${DEPLOY_DIR_IMAGE}/Yocto_Build_Appliance.zip 
+   ln -sf ${DEPLOYDIR}/${IMAGE_NAME}.vmdk 
Yocto_Build_Appliance/Yocto_Build_Appliance.vmdk
+   zip -r ${DEPLOYDIR}/Yocto_Build_Appliance-${DATETIME}.zip 
Yocto_Build_Appliance
+   ln -sf Yocto_Build_Appliance-${DATETIME}.zip 
${DEPLOYDIR}/Yocto_Build_Appliance.zip
 }
 create_bundle_files[vardepsexclude] = "DATETIME"
 
-- 
2.1.4

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

[OE-core] [PATCH 02/18] image-vm.bbclass: deploy images to DEPLOYDIR

2016-08-30 Thread Ed Bartosh

Changed deployment directory from DEPLOY_DIR_IMAGE to DEPLOYDIR
to make sstate machinery to do final deployment and generate
manifest.

Signed-off-by: Ed Bartosh 
---
 meta/classes/image-vm.bbclass | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/meta/classes/image-vm.bbclass b/meta/classes/image-vm.bbclass
index bf57e2c..2a86b40 100644
--- a/meta/classes/image-vm.bbclass
+++ b/meta/classes/image-vm.bbclass
@@ -33,14 +33,14 @@ IMAGE_TYPEDEP_hdddirect = "${VM_ROOTFS_TYPE}"
 IMAGE_TYPES_MASKED += "vmdk vdi qcow2 hdddirect"
 
 VM_ROOTFS_TYPE ?= "ext4"
-ROOTFS ?= "${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.${VM_ROOTFS_TYPE}"
+ROOTFS ?= "${DEPLOYDIR}/${IMAGE_LINK_NAME}.${VM_ROOTFS_TYPE}"
 
 # Used by bootloader
 LABELS_VM ?= "boot"
 ROOT_VM ?= "root=/dev/sda2"
 # Using an initramfs is optional. Enable it by setting INITRD_IMAGE_VM.
 INITRD_IMAGE_VM ?= ""
-INITRD_VM ?= "${@'${DEPLOY_DIR_IMAGE}/${INITRD_IMAGE_VM}-${MACHINE}.cpio.gz' 
if '${INITRD_IMAGE_VM}' else ''}"
+INITRD_VM ?= "${@'${DEPLOYDIR}/${INITRD_IMAGE_VM}-${MACHINE}.cpio.gz' if 
'${INITRD_IMAGE_VM}' else ''}"
 do_bootdirectdisk[depends] += "${@'${INITRD_IMAGE_VM}:do_image_complete' if 
'${INITRD_IMAGE_VM}' else ''}"
 
 BOOTDD_VOLUME_ID   ?= "boot"
@@ -52,7 +52,7 @@ DISK_SIGNATURE[vardepsexclude] = "DISK_SIGNATURE_GENERATED"
 build_boot_dd() {
HDDDIR="${S}/hdd/boot"
HDDIMG="${S}/hdd.image"
-   IMAGE=${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.hdddirect
+   IMAGE=${DEPLOYDIR}/${IMAGE_NAME}.hdddirect
 
populate_kernel $HDDDIR
 
@@ -104,13 +104,13 @@ build_boot_dd() {
dd if=$HDDIMG of=$IMAGE conv=notrunc seek=1 bs=512
dd if=${ROOTFS} of=$IMAGE conv=notrunc seek=$OFFSET bs=512
 
-   cd ${DEPLOY_DIR_IMAGE}
+   cd ${DEPLOYDIR}
 
-   if [ "${RM_OLD_IMAGE}" = "1" ] && [ -L 
${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.hdddirect ]; then
-   rm -f $(readlink -f 
${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.hdddirect)
+   if [ "${RM_OLD_IMAGE}" = "1" ] && [ -L 
${DEPLOYDIR}/${IMAGE_LINK_NAME}.hdddirect ]; then
+   rm -f $(readlink -f ${DEPLOYDIR}/${IMAGE_LINK_NAME}.hdddirect)
fi
 
-   ln -sf ${IMAGE_NAME}.hdddirect 
${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.hdddirect
+   ln -sf ${IMAGE_NAME}.hdddirect ${DEPLOYDIR}/${IMAGE_LINK_NAME}.hdddirect
 } 
 
 python do_bootdirectdisk() {
@@ -145,13 +145,13 @@ DISK_SIGNATURE_GENERATED := 
"${@generate_disk_signature()}"
 
 run_qemu_img (){
 type="$1"
-qemu-img convert -O $type ${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.hdddirect 
${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.$type
+qemu-img convert -O $type ${DEPLOYDIR}/${IMAGE_LINK_NAME}.hdddirect 
${DEPLOYDIR}/${IMAGE_NAME}.$type
 
-if [ "${RM_OLD_IMAGE}" = "1" ] && [ -L 
${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.$type ]; then
-rm -f $(readlink -f ${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.$type)
+if [ "${RM_OLD_IMAGE}" = "1" ] && [ -L 
${DEPLOYDIR}/${IMAGE_LINK_NAME}.$type ]; then
+rm -f $(readlink -f ${DEPLOYDIR}/${IMAGE_LINK_NAME}.$type)
 fi
 
-ln -sf ${IMAGE_NAME}.$type ${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.$type
+ln -sf ${IMAGE_NAME}.$type ${DEPLOYDIR}/${IMAGE_LINK_NAME}.$type
 }
 create_vmdk_image () {
 run_qemu_img vmdk
-- 
2.1.4

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

[OE-core] [PATCH 05/18] image_types_uboot.bbclass: deploy images to DEPLOYDIR

2016-08-30 Thread Ed Bartosh

Changed deployment directory from DEPLOY_DIR_IMAGE to DEPLOYDIR
to make sstate machinery to do final deployment and generate
manifest.

Signed-off-by: Ed Bartosh 
---
 meta/classes/image_types_uboot.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/image_types_uboot.bbclass 
b/meta/classes/image_types_uboot.bbclass
index f72d9b2..b8a281e 100644
--- a/meta/classes/image_types_uboot.bbclass
+++ b/meta/classes/image_types_uboot.bbclass
@@ -2,7 +2,7 @@ inherit image_types kernel-arch
 
 oe_mkimage () {
 mkimage -A ${UBOOT_ARCH} -O linux -T ramdisk -C $2 -n ${IMAGE_NAME} \
--d ${DEPLOY_DIR_IMAGE}/$1 ${DEPLOY_DIR_IMAGE}/$1.u-boot
+-d ${DEPLOYDIR}/$1 ${DEPLOYDIR}/$1.u-boot
 if [ x$3 = x"clean" ]; then
 rm $1
 fi
-- 
2.1.4

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

[OE-core] [PATCH 04/18] image.bbclass: deploy images to DEPLOYDIR

2016-08-30 Thread Ed Bartosh

Changed deployment directory from DEPLOY_DIR_IMAGE to DEPLOYDIR
to make sstate machinery to do final deployment and generate
manifest.

Signed-off-by: Ed Bartosh 
---
 meta/classes/image.bbclass   |  2 +-
 meta/classes/image_types.bbclass | 44 
 2 files changed, 23 insertions(+), 23 deletions(-)

diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index 82a07d5..ea3792a7 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -118,7 +118,7 @@ def rootfs_variables(d):
  
'IMAGE_ROOTFS_MAXSIZE','IMAGE_NAME','IMAGE_LINK_NAME','IMAGE_MANIFEST','DEPLOY_DIR_IMAGE','RM_OLD_IMAGE','IMAGE_FSTYPES','IMAGE_INSTALL_COMPLEMENTARY','IMAGE_LINGUAS',
  
'MULTILIBRE_ALLOW_REP','MULTILIB_TEMP_ROOTFS','MULTILIB_VARIANTS','MULTILIBS','ALL_MULTILIB_PACKAGE_ARCHS','MULTILIB_GLOBAL_VARIANTS','BAD_RECOMMENDATIONS','NO_RECOMMENDATIONS',
  
'PACKAGE_ARCHS','PACKAGE_CLASSES','TARGET_VENDOR','TARGET_ARCH','TARGET_OS','OVERRIDES','BBEXTENDVARIANT','FEED_DEPLOYDIR_BASE_URI','INTERCEPT_DIR','USE_DEVFS',
- 'CONVERSIONTYPES', 'IMAGE_GEN_DEBUGFS', 'ROOTFS_RO_UNNEEDED']
+ 'CONVERSIONTYPES', 'IMAGE_GEN_DEBUGFS', 'ROOTFS_RO_UNNEEDED', 
'DEPLOYDIR']
 variables.extend(rootfs_command_variables(d))
 variables.extend(variable_depends(d))
 return " ".join(variables)
diff --git a/meta/classes/image_types.bbclass b/meta/classes/image_types.bbclass
index 2e852af..6e6fbd7 100644
--- a/meta/classes/image_types.bbclass
+++ b/meta/classes/image_types.bbclass
@@ -41,9 +41,9 @@ XZ_THREADS ?= "-T 0"
 ZIP_COMPRESSION_LEVEL ?= "-9"
 
 JFFS2_SUM_EXTRA_ARGS ?= ""
-IMAGE_CMD_jffs2 = "mkfs.jffs2 --root=${IMAGE_ROOTFS} --faketime 
--output=${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.jffs2 
${EXTRA_IMAGECMD}"
+IMAGE_CMD_jffs2 = "mkfs.jffs2 --root=${IMAGE_ROOTFS} --faketime 
--output=${DEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.jffs2 ${EXTRA_IMAGECMD}"
 
-IMAGE_CMD_cramfs = "mkfs.cramfs ${IMAGE_ROOTFS} 
${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.cramfs ${EXTRA_IMAGECMD}"
+IMAGE_CMD_cramfs = "mkfs.cramfs ${IMAGE_ROOTFS} 
${DEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.cramfs ${EXTRA_IMAGECMD}"
 
 oe_mkext234fs () {
fstype=$1
@@ -63,8 +63,8 @@ oe_mkext234fs () {
eval COUNT=\"$MIN_COUNT\"
fi
# Create a sparse image block
-   dd if=/dev/zero 
of=${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.$fstype 
seek=$ROOTFS_SIZE count=$COUNT bs=1024
-   mkfs.$fstype -F $extra_imagecmd 
${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.$fstype -d ${IMAGE_ROOTFS}
+   dd if=/dev/zero 
of=${DEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.$fstype seek=$ROOTFS_SIZE 
count=$COUNT bs=1024
+   mkfs.$fstype -F $extra_imagecmd 
${DEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.$fstype -d ${IMAGE_ROOTFS}
 }
 
 IMAGE_CMD_ext2 = "oe_mkext234fs ext2 ${EXTRA_IMAGECMD}"
@@ -74,16 +74,16 @@ IMAGE_CMD_ext4 = "oe_mkext234fs ext4 ${EXTRA_IMAGECMD}"
 MIN_BTRFS_SIZE ?= "16384"
 IMAGE_CMD_btrfs () {
if [ ${ROOTFS_SIZE} -gt ${MIN_BTRFS_SIZE} ]; then
-   dd if=/dev/zero 
of=${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.btrfs 
count=${ROOTFS_SIZE} bs=1024
-   mkfs.btrfs ${EXTRA_IMAGECMD} -r ${IMAGE_ROOTFS} 
${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.btrfs
+   dd if=/dev/zero 
of=${DEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.btrfs count=${ROOTFS_SIZE} 
bs=1024
+   mkfs.btrfs ${EXTRA_IMAGECMD} -r ${IMAGE_ROOTFS} 
${DEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.btrfs
else
bbfatal "Rootfs is too small for BTRFS (Rootfs Actual Size: 
${ROOTFS_SIZE}, BTRFS Minimum Size: ${MIN_BTRFS_SIZE})"
fi
 }
 
-IMAGE_CMD_squashfs = "mksquashfs ${IMAGE_ROOTFS} 
${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.squashfs 
${EXTRA_IMAGECMD} -noappend"
-IMAGE_CMD_squashfs-xz = "mksquashfs ${IMAGE_ROOTFS} 
${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.squashfs-xz 
${EXTRA_IMAGECMD} -noappend -comp xz"
-IMAGE_CMD_squashfs-lzo = "mksquashfs ${IMAGE_ROOTFS} 
${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.squashfs-lzo 
${EXTRA_IMAGECMD} -noappend -comp lzo"
+IMAGE_CMD_squashfs = "mksquashfs ${IMAGE_ROOTFS} 
${DEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.squashfs ${EXTRA_IMAGECMD} 
-noappend"
+IMAGE_CMD_squashfs-xz = "mksquashfs ${IMAGE_ROOTFS} 
${DEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.squashfs-xz ${EXTRA_IMAGECMD} 
-noappend -comp xz"
+IMAGE_CMD_squashfs-lzo = "mksquashfs ${IMAGE_ROOTFS} 
${DEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.squashfs-lzo ${EXTRA_IMAGECMD} 
-noappend -comp lzo"
 
 # By default, tar from the host is used, which can be quite old. If
 # you need special parameters (like --xattrs) which are only supported
@@ -96,11 +96,11 @@ IMAGE_CMD_squashfs-lzo = "mksquashfs ${IMAGE_ROOTFS} 
${DEPLOY_DIR_IMAGE}/${IMAGE

[OE-core] [PATCH 03/18] image.bbclass: deploy images to DEPLOYDIR

2016-08-30 Thread Ed Bartosh

Changed deployment directory from DEPLOY_DIR_IMAGE to DEPLOYDIR
to make sstate machinery to do final deployment and generate
manifest.

Signed-off-by: Ed Bartosh 
---
 meta/classes/image.bbclass | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index c06dee2..82a07d5 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -440,7 +440,7 @@ python () {
 cmds.append("\t" + image_cmd)
 else:
 bb.fatal("No IMAGE_CMD defined for IMAGE_FSTYPES entry '%s' - 
possibly invalid type name or missing support class" % t)
-cmds.append(localdata.expand("\tcd ${DEPLOY_DIR_IMAGE}"))
+cmds.append(localdata.expand("\tcd ${DEPLOYDIR}"))
 
 # Since a copy of IMAGE_CMD_xxx will be inlined within do_image_xxx,
 # prevent a redundant copy of IMAGE_CMD_xxx being emitted as a 
function.
@@ -558,7 +558,7 @@ python set_image_size () {
 #
 python create_symlinks() {
 
-deploy_dir = d.getVar('DEPLOY_DIR_IMAGE', True)
+deploy_dir = d.getVar('DEPLOYDIR', True)
 img_name = d.getVar('IMAGE_NAME', True)
 link_name = d.getVar('IMAGE_LINK_NAME', True)
 manifest_name = d.getVar('IMAGE_MANIFEST', True)
-- 
2.1.4

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

[OE-core] [PATCH 00/18] Provide list of deployment artifacts

2016-08-30 Thread Ed Bartosh

Hi,

This is a fix for Bug #9869 - Provide a per-target manifest of files which 
were, or would have been, produced

The list of artifacts produced by deployment tasks (do_deploy, 
do_image_complete and do_populate_sdk[_ext] is
obtained from sstate manifests and fired as a TaskArtifacts metadata event. 
This should allow Toaster to
handle artifacts in simple way and remove a lot of current Toaster code doing 
guess work.

To generate manifests for do_image_complete and do_populate_sdk they have been 
put under sstate control.

To avoid storing big files(images and sdk installer) in sstate new variable 
SSTATE_SKIP_CREATION has been
set in image.bbclass and populate_sdk_base.bbclass and sstate code was modified 
to avoid adding files
to sstate if SSTATE_SKIP_CREATION is set.

The following changes since commit 087c580b286816265f487e02746bfa6e26081554:

  init-install: Fixes the install script failing when not finding any mmcblk 
devices (2016-08-30 07:57:50 +0100)

are available in the git repository at:

  git://git.yoctoproject.org/poky-contrib ed/oe-core/artifacts-9869
  
http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=ed/oe-core/artifacts-9869

Ed Bartosh (18):
  image-live.bbclass: deploy images to DEPLOYDIR
  image-vm.bbclass: deploy images to DEPLOYDIR
  image.bbclass: deploy images to DEPLOYDIR
  image.bbclass: deploy images to DEPLOYDIR
  image_types_uboot.bbclass: deploy images to DEPLOYDIR
  syslinux.bbclass: deploy bootloader to DEPLOYDIR
  build-appliance-image: process images in DEPLOYDIR
  populate_sdk_base.bbclass: deploy sdk artifacts to DEPLOYDIR
  rootfs-postcommands.bbclass: generate manifest in DEPLOYDIR
  selftest: renamed variable
  rootfs.py: use DEPLOYDIR instead of DEPLOY_DIR_IMAGE
  image.bbclass: put image_complete under sstate control
  image.bbclass: cleanup DEPLOYDIR
  populate_sdk_base: put populate_sdk under sstate control
  sstate.bbclass: skip packaging if SSTATE_SKIP_CREATION is set
  image: populate_sdk_base: skip sstate creation
  image: populate_sdk_base: set stamp-extra-info flag
  toaster: fire TaskArtifacts event

 meta/classes/image-live.bbclass| 12 +++---
 meta/classes/image-vm.bbclass  | 22 +--
 meta/classes/image.bbclass | 14 +--
 meta/classes/image_types.bbclass   | 44 +++---
 meta/classes/image_types_uboot.bbclass |  2 +-
 meta/classes/populate_sdk_base.bbclass | 28 +-
 meta/classes/rootfs-postcommands.bbclass   |  4 +-
 meta/classes/sstate.bbclass|  2 +
 meta/classes/syslinux.bbclass  |  2 +-
 meta/classes/toaster.bbclass   | 17 +
 meta/lib/oe/rootfs.py  |  6 +--
 meta/lib/oeqa/selftest/imagefeatures.py|  4 +-
 .../images/build-appliance-image_15.0.0.bb |  8 ++--
 13 files changed, 100 insertions(+), 65 deletions(-)

--
Regards,
Ed

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

[OE-core] [PATCH 01/18] image-live.bbclass: deploy images to DEPLOYDIR

2016-08-30 Thread Ed Bartosh

Changed deployment directory from DEPLOY_DIR_IMAGE to DEPLOYDIR
to make sstate machinery to do final deployment and generate
manifest.

Signed-off-by: Ed Bartosh 
---
 meta/classes/image-live.bbclass | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/meta/classes/image-live.bbclass b/meta/classes/image-live.bbclass
index f0e6647..1294b11 100644
--- a/meta/classes/image-live.bbclass
+++ b/meta/classes/image-live.bbclass
@@ -43,7 +43,7 @@ ROOT_LIVE ?= "root=/dev/ram0"
 INITRD_IMAGE_LIVE ?= "core-image-minimal-initramfs"
 INITRD_LIVE ?= "${DEPLOY_DIR_IMAGE}/${INITRD_IMAGE_LIVE}-${MACHINE}.cpio.gz"
 
-ROOTFS ?= "${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.ext4"
+ROOTFS ?= "${DEPLOYDIR}/${IMAGE_LINK_NAME}.ext4"
 
 IMAGE_TYPEDEP_live = "ext4"
 IMAGE_TYPEDEP_iso = "ext4"
@@ -144,14 +144,14 @@ build_iso() {
if [ "${PCBIOS}" = "1" ] && [ "${EFI}" != "1" ] ; then
# PCBIOS only media
mkisofs -V ${BOOTIMG_VOLUME_ID} \
-   -o ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.iso \
+   -o ${DEPLOYDIR}/${IMAGE_NAME}.iso \
-b ${ISO_BOOTIMG} -c ${ISO_BOOTCAT} \
$mkisofs_compress_opts \
${MKISOFS_OPTIONS} $mkisofs_iso_level ${ISODIR}
else
# EFI only OR EFI+PCBIOS
mkisofs -A ${BOOTIMG_VOLUME_ID} -V ${BOOTIMG_VOLUME_ID} \
-   -o ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.iso \
+   -o ${DEPLOYDIR}/${IMAGE_NAME}.iso \
-b ${ISO_BOOTIMG} -c ${ISO_BOOTCAT} \
$mkisofs_compress_opts ${MKISOFS_OPTIONS} 
$mkisofs_iso_level \
-eltorito-alt-boot -eltorito-platform efi \
@@ -160,7 +160,7 @@ build_iso() {
isohybrid_args="-u"
fi
 
-   isohybrid $isohybrid_args ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.iso
+   isohybrid $isohybrid_args ${DEPLOYDIR}/${IMAGE_NAME}.iso
 }
 
 build_fat_img() {
@@ -252,13 +252,13 @@ build_hddimg() {
fi
fi
 
-   build_fat_img ${HDDDIR} ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.hddimg
+   build_fat_img ${HDDDIR} ${DEPLOYDIR}/${IMAGE_NAME}.hddimg
 
if [ "${PCBIOS}" = "1" ]; then
syslinux_hddimg_install
fi
 
-   chmod 644 ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.hddimg
+   chmod 644 ${DEPLOYDIR}/${IMAGE_NAME}.hddimg
fi
 }
 
-- 
2.1.4

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

[OE-core] [PATCH v2] meta-ide-support: inherit nopackages

2016-08-30 Thread jackie.huang

From: Jackie Huang 

The recipe is to generate an environment script in
do_populate_ide_support for using an IDE and it
doesn't generate packages at all, so inherit nopackages

Signed-off-by: Jackie Huang 
---
 meta/recipes-core/meta/meta-ide-support.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-core/meta/meta-ide-support.bb 
b/meta/recipes-core/meta/meta-ide-support.bb
index 86c57cd..c4ddcfc 100644
--- a/meta/recipes-core/meta/meta-ide-support.bb
+++ b/meta/recipes-core/meta/meta-ide-support.bb
@@ -7,7 +7,7 @@ LIC_FILES_CHKSUM = 
"file://${COREBASE}/LICENSE;md5=4d92cd373abda3937c2bc47fbc49d
 DEPENDS = "virtual/libc gdb-cross-${TARGET_ARCH} qemu-native 
qemu-helper-native unfs3-native"
 PR = "r3"
 
-inherit meta toolchain-scripts
+inherit meta toolchain-scripts nopackages
 
 do_populate_ide_support () {
   toolchain_create_tree_env_script
-- 
2.8.1

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

Re: [OE-core] [PATCH] meta-ide-support: set noexec for tasks

2016-08-30 Thread Huang, Jie (Jackie)



> -Original Message-
> From: Richard Purdie [mailto:richard.pur...@linuxfoundation.org]
> Sent: Tuesday, August 30, 2016 4:41 PM
> To: Huang, Jie (Jackie); openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH] meta-ide-support: set noexec for tasks
> 
> On Tue, 2016-08-30 at 16:08 +0800, jackie.hu...@windriver.com wrote:
> > From: Jackie Huang 
> >
> > The recipe is to generate an environment script in
> > do_populate_ide_support for using an IDE, the tasks
> > listed are not needed, so set 'noexec' for them.
> 
> Would "inherit nopackage" help here and simplify this patch a bit?

Ah, sorry I didn't know there is such a bbclass. Yes, it works and simplify the 
patch.
I will send v2 for this.

Thanks,
Jackie

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

Re: [OE-core] [PATCH 5/6] kernel-yocto: streamline patch, configuration and audit phases

2016-08-30 Thread André Draszik

My kmeta stuff is located directly inside two meta-* layers (i.e. not in an
extra git repo), where the 2nd layer's kernel recipes .bbappends to the 1st
one with additional kmeta things.

This used to work fine, but since this commit it doesn't anymore as only the
kmeta stuff from the 2nd layer is being copied into workdir.

Have I been doing something that wasn't guaranteed / supposed to work in the
first place? Or should that still work? Is it worth fixing or should I
rethink my approach?


Cheers,
Andre'


On Mo, 2016-08-15 at 14:26 -0400, Bruce Ashfield wrote:
> We've been running with a set of kern-tools that were designed to work
> with build systems that knew nothing about git, trees, commits, etc.
> 
> As such, there's been a set of shims/wrappers in place to work with
> within bitbake/oe-core. These were the *me scripts: createme, updateme,
> patchme and configme.
> 
> With this commit, we strip that legacy code and use the tools directly.
> This means less complexity, fewer corner cases .. and no surprises
> when the tools are arunning. As another benefit, the tools consume
> much less time during a typical build and have no noticeable impact
> on the overall build time.
> 
> Existing .scc files, features, and processing are not impacted as
> these tools are compatible with existing feature descriptions and
> kerne configuration fragments.
> 
> The audit of kernel configuration fragments is now detached
> from the linux-yocto build structure and process. This means that
> they can eventually be tweaked to offer kernel audit to any type of
> kernel build and configuration process.
> 
> Additionally, the kernel symbol audit phase can now resolve symbol
> dependencies and offer guidance when a symbol is missing:
> 
>    WARNING: linux-yocto-4.4.15+gitAUTOINC+b030d96c7b_f5e2c49d58-r0
> do_kernel_configcheck: [kernel config]: specified values did not make it
> into the kernel's final configuration:
> 
>    -- CONFIG_BT_6LOWPAN -
>    Config: CONFIG_BT_6LOWPAN
>    From: /home/bruce/poky/build/tmp/work-shared/qemux86-64/kernel-
> source/.kernel-meta/configs/standard/features/bluetooth/bluetooth.cfg
>    Requested value:  CONFIG_BT_6LOWPAN=y
>    Actual value:
> 
>    Config 'BT_6LOWPAN' has the following conditionals:
>  BT_LE && 6LOWPAN (value: "n")
>    Dependency values are:
>  BT_LE [y] 6LOWPAN [n]
> 
> Signed-off-by: Bruce Ashfield 
> ---
>  meta/classes/kernel-yocto.bbclass  | 143 --
> ---
>  .../kern-tools/kern-tools-native_git.bb|   4 +-
>  2 files changed, 55 insertions(+), 92 deletions(-)
> 
> diff --git a/meta/classes/kernel-yocto.bbclass b/meta/classes/kernel-
> yocto.bbclass
> index a9d4205..8650e55 100644
> --- a/meta/classes/kernel-yocto.bbclass
> +++ b/meta/classes/kernel-yocto.bbclass
> @@ -119,77 +119,42 @@ do_kernel_metadata() {
>   patches="${@" ".join(find_patches(d))}"
>   feat_dirs="${@" ".join(find_kernel_feature_dirs(d))}"
>  
> - # add any explicitly referenced features onto the end of the
> feature
> - # list that is passed to the kernel build scripts.
> - if [ -n "${KERNEL_FEATURES}" ]; then
> - for feat in ${KERNEL_FEATURES}; do
> - addon_features="$addon_features --feature $feat"
> - done
> - fi
> -
>   # check for feature directories/repos/branches that were part of
> the
>   # SRC_URI. If they were supplied, we convert them into include
> directives
>   # for the update part of the process
> - if [ -n "${feat_dirs}" ]; then
> - for f in ${feat_dirs}; do
> + for f in ${feat_dirs}; do
>   if [ -d "${WORKDIR}/$f/meta" ]; then
> - includes="$includes -I${WORKDIR}/$f/meta"
> + includes="$includes -I${WORKDIR}/$f/meta"
>   elif [ -d "${WORKDIR}/$f" ]; then
> - includes="$includes -I${WORKDIR}/$f"
> + includes="$includes -I${WORKDIR}/$f"
>   fi
> - done
> - fi
> + done
> + for s in ${sccs}; do
> + sdir=$(dirname $s)
> + includes="$includes -I${sdir}"
> + done
>  
> - # updates or generates the target description
> - updateme ${updateme_flags}
> -DKDESC=${KMACHINE}:${LINUX_KERNEL_TYPE} \
> - ${includes} ${addon_features} ${ARCH}
> ${KMACHINE} ${sccs} ${patches}
> - if [ $? -ne 0 ]; then
> - bbfatal_log "Could not update ${machine_branch}"
> - fi
> + # expand kernel features into their full path equivalents
> + bsp_definition=$(spp ${includes} --find -DKMACHINE=${KMACHINE}
> -DKTYPE=${LINUX_KERNEL_TYPE})
> + meta_dir=$(kgit --meta)
> +
> + # run1: pull all the configuration fragments, no matter where
> they come from
> + scc --force -o ${S}/${meta_dir}:cfg,meta ${includes}
> ${bsp_definition} ${sccs} ${patches} ${KERNEL_FEATURES}
> +
> + # run2: only

Re: [OE-core] [PATCH] meta-ide-support: set noexec for tasks

2016-08-30 Thread Richard Purdie

On Tue, 2016-08-30 at 16:08 +0800, jackie.hu...@windriver.com wrote:
> From: Jackie Huang 
> 
> The recipe is to generate an environment script in
> do_populate_ide_support for using an IDE, the tasks
> listed are not needed, so set 'noexec' for them.

Would "inherit nopackage" help here and simplify this patch a bit?

Cheers,

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

[OE-core] [PATCH 3/3] x11-common: Remove Xserver script

2016-08-30 Thread Jussi Kukkonen

X startup is now handled in xserver-nodm-init.

Signed-off-by: Jussi Kukkonen 
---
 meta/recipes-graphics/x11-common/x11-common/Xserver.in | 12 
 meta/recipes-graphics/x11-common/x11-common_0.1.bb | 10 +-
 2 files changed, 1 insertion(+), 21 deletions(-)
 delete mode 100644 meta/recipes-graphics/x11-common/x11-common/Xserver.in

diff --git a/meta/recipes-graphics/x11-common/x11-common/Xserver.in 
b/meta/recipes-graphics/x11-common/x11-common/Xserver.in
deleted file mode 100644
index b8eed76..000
--- a/meta/recipes-graphics/x11-common/x11-common/Xserver.in
+++ /dev/null
@@ -1,12 +0,0 @@
-#!/bin/sh
-#
-
-XSERVER=/usr/bin/Xorg
-
-. /etc/profile
-
-ARGS=" -br -pn @BLANK_ARGS@"
-
-DISPLAY=':0'
-
-exec xinit /etc/X11/Xsession -- $XSERVER $DISPLAY $ARGS $*
diff --git a/meta/recipes-graphics/x11-common/x11-common_0.1.bb 
b/meta/recipes-graphics/x11-common/x11-common_0.1.bb
index 2bc0d33..ab9a939 100644
--- a/meta/recipes-graphics/x11-common/x11-common_0.1.bb
+++ b/meta/recipes-graphics/x11-common/x11-common_0.1.bb
@@ -9,22 +9,14 @@ inherit distro_features_check
 REQUIRED_DISTRO_FEATURES = "x11"
 
 SRC_URI = "file://etc \
-   file://Xserver.in \
file://gplv2-license.patch"
 
 S = "${WORKDIR}"
 
-PACKAGECONFIG ??= "blank"
-# dpms and screen saver will be on only if 'blank' is in PACKAGECONFIG
-PACKAGECONFIG[blank] = ""
-
 do_install() {
cp -R ${S}/etc ${D}${sysconfdir}
-   sed -e 's/@BLANK_ARGS@/${@bb.utils.contains('PACKAGECONFIG', 'blank', 
'', '-s 0 -dpms', d)}/' \
-   ${S}/Xserver.in > ${D}${sysconfdir}/X11/Xserver
-
chmod -R 755 ${D}${sysconfdir}
 }
 
-RDEPENDS_${PN} = "dbus-x11 xmodmap xdpyinfo xinput-calibrator xinit formfactor"
+RDEPENDS_${PN} = "dbus-x11 xmodmap xdpyinfo xinput-calibrator formfactor"
 
-- 
2.1.4

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

[OE-core] [PATCH 2/3] xserver-nodm-init: Deprecate /etc/X11/Xserver

2016-08-30 Thread Jussi Kukkonen

This commit should provide the same functionality as before, but
should make meta-oe xserver-nodm-init-2.0 obsolete as well as
keep systemd and sysvinit startup better in sync.

/etc/X11/Xserver is not called anymore: it is provided by both
x11-common and xserver-common with no useful differences (but some
annoying ones). Instead xserver-nodm-init provides
/etc/xserver-nodm/Xserver as the startup script and
/etc/default/xserver-nodm as the default settings file. These are
used by both init systems.

The Xserver script could be completely removed (with sysv and
systemd calling xinit directly), but to keep compatibility with
meta-oes xserver-nodm-init-2.0 the Xserver script sources
/etc/X11/xserver-common if one exists -- and systemd EnvironmentFile
cannot do that.

x11-common used to have a packageconfig to easily control screen
blanking. Move this to xserver-nodm-init.

Signed-off-by: Jussi Kukkonen 
---
 .../x11-common/xserver-nodm-init.bb| 47 +-
 .../x11-common/xserver-nodm-init/Xserver   | 25 
 .../x11-common/xserver-nodm-init/Xusername |  1 -
 .../x11-common/xserver-nodm-init/xserver-nodm  | 10 +++--
 .../x11-common/xserver-nodm-init/xserver-nodm.conf |  1 -
 .../xserver-nodm-init/xserver-nodm.conf.in |  7 
 ...server-nodm.service => xserver-nodm.service.in} |  4 +-
 7 files changed, 67 insertions(+), 28 deletions(-)
 create mode 100644 meta/recipes-graphics/x11-common/xserver-nodm-init/Xserver
 delete mode 100644 meta/recipes-graphics/x11-common/xserver-nodm-init/Xusername
 delete mode 100644 
meta/recipes-graphics/x11-common/xserver-nodm-init/xserver-nodm.conf
 create mode 100644 
meta/recipes-graphics/x11-common/xserver-nodm-init/xserver-nodm.conf.in
 rename 
meta/recipes-graphics/x11-common/xserver-nodm-init/{xserver-nodm.service => 
xserver-nodm.service.in} (76%)

diff --git a/meta/recipes-graphics/x11-common/xserver-nodm-init.bb 
b/meta/recipes-graphics/x11-common/xserver-nodm-init.bb
index b68d40e..6057248 100644
--- a/meta/recipes-graphics/x11-common/xserver-nodm-init.bb
+++ b/meta/recipes-graphics/x11-common/xserver-nodm-init.bb
@@ -5,10 +5,10 @@ SECTION = "x11"
 PR = "r31"
 
 SRC_URI = "file://xserver-nodm \
-   file://Xusername \
+   file://Xserver \
file://gplv2-license.patch \
-   file://xserver-nodm.service \
-   file://xserver-nodm.conf \
+   file://xserver-nodm.service.in \
+   file://xserver-nodm.conf.in \
 "
 
 S = "${WORKDIR}"
@@ -18,33 +18,40 @@ PACKAGE_ARCH = "${MACHINE_ARCH}"
 
 inherit update-rc.d systemd
 
+PACKAGECONFIG ??= "blank"
+# dpms and screen saver will be on only if 'blank' is in PACKAGECONFIG
+PACKAGECONFIG[blank] = ""
+
 do_install() {
-install -d ${D}${sysconfdir}/init.d
-install xserver-nodm ${D}${sysconfdir}/init.d
+install -d ${D}${sysconfdir}/default
+install xserver-nodm.conf.in ${D}${sysconfdir}/default/xserver-nodm
+install -d ${D}${sysconfdir}/xserver-nodm
+install Xserver ${D}${sysconfdir}/xserver-nodm/Xserver
+
+BLANK_ARGS="${@bb.utils.contains('PACKAGECONFIG', 'blank', '', '-s 0 
-dpms', d)}"
+if [ "${ROOTLESS_X}" = "1" ] ; then
+XUSER_HOME="/home/xuser"
+XUSER="xuser"
+else
+XUSER_HOME=${ROOT_HOME}
+XUSER="root"
+fi
+sed -i "s:@HOME@:${XUSER_HOME}:; s:@USER@:${XUSER}:; 
s:@BLANK_ARGS@:${BLANK_ARGS}:" \
+${D}${sysconfdir}/default/xserver-nodm
 
 if ${@bb.utils.contains('DISTRO_FEATURES','systemd','true','false',d)}; 
then
-install -d ${D}${sysconfdir}/default
-install xserver-nodm.conf ${D}${sysconfdir}/default/xserver-nodm
 install -d ${D}${systemd_unitdir}/system
-install -m 0644 ${WORKDIR}/xserver-nodm.service 
${D}${systemd_unitdir}/system
-if [ "${ROOTLESS_X}" = "1" ] ; then
-sed -i 's!^HOME=.*!HOME=/home/xuser!' 
${D}${sysconfdir}/default/xserver-nodm
-sed -i 's!^User=.*!User=xuser!' 
${D}${systemd_unitdir}/system/xserver-nodm.service
-else
-sed -i 's!^HOME=.*!HOME=${ROOT_HOME}!' 
${D}${sysconfdir}/default/xserver-nodm
-sed -i '/^User=/d' 
${D}${systemd_unitdir}/system/xserver-nodm.service
-fi
+install -m 0644 ${WORKDIR}/xserver-nodm.service.in 
${D}${systemd_unitdir}/system/xserver-nodm.service
+sed -i "s:@USER@:${XUSER}:" 
${D}${systemd_unitdir}/system/xserver-nodm.service
 fi
 
 if ${@bb.utils.contains('DISTRO_FEATURES','sysvinit','true','false',d)}; 
then
-if [ "${ROOTLESS_X}" = "1" ] ; then
-install -d ${D}${sysconfdir}/X11
-install Xusername ${D}${sysconfdir}/X11
-fi
+install -d ${D}${sysconfdir}/init.d
+install xserver-nodm ${D}${sysconfdir}/init.d
 fi
 }
 
-RDEPENDS_${PN} = "${@base_conditional('ROOTLESS_X', '1', 'xuser-account', '', 
d)}"
+RDEPENDS_${PN} = "xinit ${@base_conditional('ROOTLESS_X', '1',

[OE-core] [PATCH 0/3] Clean up X init (oe-core vs meta-oe)

2016-08-30 Thread Jussi Kukkonen

Goals:
* Less confusing duplication between oe-core and meta-oe
  (currently just adding meta-oe to BBLAYERS completely
  changes X init because meta-oe provides another version of
  xserver-nodm-init)
* Make it easier to keep X init in sync between systemd and sysvinit

The xserver-nodm-init patch merges in functionality from
xserver-nodm-init-2.0 from meta-oe: The combined "Xserver" script
deprecates the ones in x11-common (oe-core) and xserver-common
(meta-oe), and should work with other parts of either x11-common
or xserver-common. In particular these differences still exist:
 * Xsession files are different
 * xserver-common generates X binary name and arguments at runtime

I believe the xserver-nodm-init-2.0 recipe can be removed after this
patch with one caveat: The people who assume they will get
xserver-common (meta-oe) without explicitly asking for it will be
surprised. The x11 packagegroup has "VIRTUAL-RUNTIME_xserver_common"
selection which will work but it does not seem to be commonly used.

I'd be happy to take advice on how to minimize problems from the above as
well as on how to handle the version problems: should I bump the recipe
version above 2.0?

Sorry about the timing wrt M3 freeze: This consumed much more time
than planned. We can postpone if it looks too scary at this point.

Jussi



The following changes since commit 2fedd226c3385f1ac160b3aa0bfadbded85e288c:

  ref-manual: Fixed small wording in PKGR in the glossary (2016-08-25 23:09:29 
+0100)

are available in the git repository at:

  git://git.yoctoproject.org/poky-contrib jku/xserver-nodm
  http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=jku/xserver-nodm

Jussi Kukkonen (3):
  base-files: Add shell test quoting
  xserver-nodm-init: Deprecate /etc/X11/Xserver
  x11-common: Remove Xserver script

 meta/recipes-core/base-files/base-files/profile|  2 +-
 .../x11-common/x11-common/Xserver.in   | 12 --
 meta/recipes-graphics/x11-common/x11-common_0.1.bb | 10 +
 .../x11-common/xserver-nodm-init.bb| 47 +-
 .../x11-common/xserver-nodm-init/Xserver   | 25 
 .../x11-common/xserver-nodm-init/Xusername |  1 -
 .../x11-common/xserver-nodm-init/xserver-nodm  | 10 +++--
 .../x11-common/xserver-nodm-init/xserver-nodm.conf |  1 -
 .../xserver-nodm-init/xserver-nodm.conf.in |  7 
 ...server-nodm.service => xserver-nodm.service.in} |  4 +-
 10 files changed, 69 insertions(+), 50 deletions(-)
 delete mode 100644 meta/recipes-graphics/x11-common/x11-common/Xserver.in
 create mode 100644 meta/recipes-graphics/x11-common/xserver-nodm-init/Xserver
 delete mode 100644 meta/recipes-graphics/x11-common/xserver-nodm-init/Xusername
 delete mode 100644 
meta/recipes-graphics/x11-common/xserver-nodm-init/xserver-nodm.conf
 create mode 100644 
meta/recipes-graphics/x11-common/xserver-nodm-init/xserver-nodm.conf.in
 rename 
meta/recipes-graphics/x11-common/xserver-nodm-init/{xserver-nodm.service => 
xserver-nodm.service.in} (76%)

-- 
2.1.4

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

[OE-core] [PATCH 1/3] base-files: Add shell test quoting

2016-08-30 Thread Jussi Kukkonen

tty can return "not a tt" which results in warnings when /etc/profile
is executed.

Signed-off-by: Jussi Kukkonen 
---
 meta/recipes-core/base-files/base-files/profile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-core/base-files/base-files/profile 
b/meta/recipes-core/base-files/base-files/profile
index ba1b9ba..a52bf89 100644
--- a/meta/recipes-core/base-files/base-files/profile
+++ b/meta/recipes-core/base-files/base-files/profile
@@ -31,7 +31,7 @@ fi
 if [ -x /usr/bin/resize ];then
   # Make sure we are on a serial console (i.e. the device used starts with 
/dev/tty),
   # otherwise we confuse e.g. the eclipse launcher which tries do use ssh
-  test `tty | cut -c1-8` = "/dev/tty" && resize >/dev/null
+  test "`tty | cut -c1-8`" = "/dev/tty" && resize >/dev/null
 fi
 
 export PATH PS1 OPIEDIR QPEDIR QTDIR EDITOR TERM
-- 
2.1.4

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

[OE-core] [PATCH] meta-ide-support: set noexec for tasks

2016-08-30 Thread jackie.huang

From: Jackie Huang 

The recipe is to generate an environment script in
do_populate_ide_support for using an IDE, the tasks
listed are not needed, so set 'noexec' for them.

Signed-off-by: Jackie Huang 
---
 meta/recipes-core/meta/meta-ide-support.bb | 13 +
 1 file changed, 13 insertions(+)

diff --git a/meta/recipes-core/meta/meta-ide-support.bb 
b/meta/recipes-core/meta/meta-ide-support.bb
index 86c57cd..ee87a45 100644
--- a/meta/recipes-core/meta/meta-ide-support.bb
+++ b/meta/recipes-core/meta/meta-ide-support.bb
@@ -9,6 +9,19 @@ PR = "r3"
 
 inherit meta toolchain-scripts
 
+do_fetch[noexec] = "1"
+do_unpack[noexec] = "1"
+do_patch[noexec] = "1"
+do_configure[noexec] = "1"
+do_compile[noexec] = "1"
+do_install[noexec] = "1"
+do_package[noexec] = "1"
+do_packagedata[noexec] = "1"
+do_package_write_ipk[noexec] = "1"
+do_package_write_rpm[noexec] = "1"
+do_package_write_deb[noexec] = "1"
+do_populate_sysroot[noexec] = "1"
+
 do_populate_ide_support () {
   toolchain_create_tree_env_script
 }
-- 
2.7.4

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

Re: [OE-core] [PATCH V1] unzip: fixes strange output

2016-08-30 Thread Jussi Kukkonen

On 30 August 2016 at 05:17, Edwin Plauchu <
edwin.plauchu.cama...@linux.intel.com> wrote:
>
> From: Edwin Plauchu 
>
> This fixes commit 763a3d424bccf559a8d6add3dc1f2746c82f2933
>
> Output was strange when using unzip to extract zip file.
> This patch fixed so.
>
> [YOCTO #9551]
>
> Signed-off-by: Edwin Plauchu 
> ---
>  .../unzip/unzip/fix-security-format.patch  | 198
-
>  1 file changed, 78 insertions(+), 120 deletions(-)
>
> diff --git a/meta/recipes-extended/unzip/unzip/fix-security-format.patch
b/meta/recipes-extended/unzip/unzip/fix-security-format.patch
> index c82f502..8e9b06c 100644
> --- a/meta/recipes-extended/unzip/unzip/fix-security-format.patch
> +++ b/meta/recipes-extended/unzip/unzip/fix-security-format.patch
> @@ -9,131 +9,89 @@ Upstream-Status: Pending
>
>  Signed-off-by: Edwin Plauchu 
>
> -diff --git a/unzpriv.h b/unzpriv.h
> -index c8d3eab..85e693a 100644
>  a/unzpriv.h
> -+++ b/unzpriv.h
> -@@ -1006,7 +1006,7 @@
> - #define LoadFarStringSmall(x)   Qstrfix(x)
> - #define LoadFarStringSmall2(x)  Qstrfix(x)
> - #  else
> --#define LoadFarString(x)(char *)(x)
> -+#define LoadFarString(x)"%s",(char *)(x)

LoadFarString is used a _lot_ in various different ways, usually as
argument to another macro or function. This sort of macro change seems
potentially very dangerous in C, have you checked this is ok in every case?.

I gave an example from extract.c in the bug report:

Info(slide, 0x201, ((char *)slide,
LoadFarString(SymLnkWarnInvalid), FnFilter1(linkfname)))

may end up calling sprintf like this:

sprintf ((char *)slide,
LoadFarString(SymLnkWarnInvalid), FnFilter1(linkfname))

That still seems unlikely to work with the proposed LoadFarString change.

another example below.

> - #define LoadFarStringSmall(x)   (char *)(x)
> - #define LoadFarStringSmall2(x)  (char *)(x)
> - #  endif
> -diff --git a/fileio.c b/fileio.c
> -index 36bfea3..ca779c2 100644
>  a/fileio.c
> -+++ b/fileio.c
> -@@ -588,8 +588,8 @@ unsigned readbuf(__G__ buf, size)   /* return number
of bytes read into buf */
> - else if (G.incnt < 0) {
> - /* another hack, but no real harm copying same thing
twice */
> - (*G.message)((zvoid *),
> --  (uch *)LoadFarString(ReadError),  /* CANNOT use slide
*/
> --  (ulg)strlen(LoadFarString(ReadError)), 0x401);
> -+  (uch *)(char*)(ReadError),  /* CANNOT use slide */
> -+  (ulg)strlen((char*)(ReadError)), 0x401);
> - return 0;  /* discarding some data; better than lock-up
*/
> - }
> - /* buffer ALWAYS starts on a block boundary:  */
> -@@ -631,8 +631,8 @@ int readbyte(__G)   /* refill inbuf and return a
byte if available, else EOF */
> - } else if (G.incnt < 0) {  /* "fail" (abort, retry, ...)
returns this */
> - /* another hack, but no real harm copying same thing twice
*/
> - (*G.message)((zvoid *),
> --  (uch *)LoadFarString(ReadError),
> --  (ulg)strlen(LoadFarString(ReadError)), 0x401);
> -+  (uch *)(char*)(ReadError),
> -+  (ulg)strlen((char*)(ReadError)), 0x401);
> - echon();
> - #ifdef WINDLL
> - longjmp(dll_error_return, 1);
> -@@ -1356,7 +1356,7 @@ int UZ_EXP UzpMessagePrnt(pG, buf, size, flag)
> - ++((Uz_Globs *)pG)->lines;
> - if (((Uz_Globs *)pG)->lines >= ((Uz_Globs *)pG)->height)
> - (*((Uz_Globs *)pG)->mpause)((zvoid *)pG,
> --  LoadFarString(MorePrompt), 1);
> -+  (char*)(MorePrompt), 1);
> - }
> - #endif /* MORE */
> - if (MSG_STDERR(flag) && ((Uz_Globs *)pG)->UzO.tflag &&
> -@@ -1416,7 +1416,7 @@ int UZ_EXP UzpMessagePrnt(pG, buf, size, flag)
> - ((Uz_Globs *)pG)->sol = TRUE;
> - q = p + 1;
> - (*((Uz_Globs *)pG)->mpause)((zvoid *)pG,
> --  LoadFarString(MorePrompt), 1);
> -+  (char*)(MorePrompt), 1);
> +diff --git a/extract.c b/extract.c
> +index 7cd9123..25c5a62 100644
> +--- a/extract.c
>  b/extract.c
> +@@ -475,7 +475,7 @@ int extract_or_test_files(__G)/* return PK-type
error code */
> + Info(slide, 0x401, ((char *)slide,
> +   LoadFarString(CentSigMsg), j + blknum*DIR_BLKSIZ
+ 1));
> + Info(slide, 0x401, ((char *)slide,
> +-  LoadFarString(ReportMsg)));
> ++  "%s",LoadFarString(ReportMsg)));

AFAICS this may end up as:
sprintf ((char *)slide, "%s", LoadFarString(ReportMsg))
which with the new macro definition would mean:
sprintf ((char *)slide, "%s", "%s", (char *)(ReportMsg))

This also seems

Re: [OE-core] [PATCH] init-install*: only pick root mmc devices

2016-08-30 Thread Belal, Awais

Hi Saul,

> Please review the bug and try to test with genericx86 likely without an
> MMC device.

Alejandro came up with a quick fix 
https://patchwork.openembedded.org/patch/130547/.

BR,
Awais


From: Saul Wold [saul.w...@intel.com]
Sent: Tuesday, August 30, 2016 10:34 AM
To: Belal, Awais; openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [PATCH] init-install*: only pick root mmc devices

On Wed, 2016-08-10 at 13:14 +0500, Awais Belal wrote:
> Some eMMC devices show special sub-devices such as mmcblk0boot0
> etc. The installation script currently pick all of them up and
> displays it to the user which makes some confusions because these
> sub-devices are pretty small and complete installation including
> rootfs won't be possible in most cases.
> We simply now drop these sub-devices and only present the user
> with the root of such mmc devices.
>
Hi Awais:

We recently ran a full QA pass and found a problem with installing
genericx86* machines files as Bug #10189 [1].  It appears it might be
related to this or another of your init-install patches.

Since we are approaching M3 closure today this would be a bad issue to
have following us into M3.

Please review the bug and try to test with genericx86 likely without an
MMC device.

Thanks
  Sau!

[1] https://bugzilla.yoctoproject.org/show_bug.cgi?id=10189

> Signed-off-by: Awais Belal 
> ---
>  meta/recipes-core/initrdscripts/files/init-install-efi.sh | 8
> +++-
>  meta/recipes-core/initrdscripts/files/init-install.sh | 8
> +++-
>  2 files changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/meta/recipes-core/initrdscripts/files/init-install-
> efi.sh b/meta/recipes-core/initrdscripts/files/init-install-efi.sh
> index f564f4e..776dcbb 100644
> --- a/meta/recipes-core/initrdscripts/files/init-install-efi.sh
> +++ b/meta/recipes-core/initrdscripts/files/init-install-efi.sh
> @@ -29,7 +29,13 @@ esac
>
>  echo "Searching for hard drives ..."
>
> -for device in `ls /sys/block/`; do
> +# Some eMMC devices have special sub devices such as mmcblk0boot0
> etc
> +# we're currently only interested in the root device so pick them
> wisely
> +devices=`ls /sys/block/ | grep -v mmcblk`
> +mmc_devices=`ls /sys/block/ | grep "mmcblk[0-9]\{1,\}$"`
> +devices="$devices $mmc_devices"
> +
> +for device in $devices; do
>  case $device in
>  loop*)
>  # skip loop device
> diff --git a/meta/recipes-core/initrdscripts/files/init-install.sh
> b/meta/recipes-core/initrdscripts/files/init-install.sh
> index 72ce92b..9c4189b 100644
> --- a/meta/recipes-core/initrdscripts/files/init-install.sh
> +++ b/meta/recipes-core/initrdscripts/files/init-install.sh
> @@ -28,7 +28,13 @@ esac
>
>  echo "Searching for hard drives ..."
>
> -for device in `ls /sys/block/`; do
> +# Some eMMC devices have special sub devices such as mmcblk0boot0
> etc
> +# we're currently only interested in the root device so pick them
> wisely
> +devices=`ls /sys/block/ | grep -v mmcblk`
> +mmc_devices=`ls /sys/block/ | grep "mmcblk[0-9]\{1,\}$"`
> +devices="$devices $mmc_devices"
> +
> +for device in $devices; do
>  case $device in
>  loop*)
>  # skip loop device
> --
> 1.9.1
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Review request 0/21: ltp: add libwww-perl-perl to RDEPENDS

2016-08-30 Thread Yu, Mingli




On 2016年08月29日 19:52, Alexander Kanavin wrote:

On 08/29/2016 05:16 AM, mingli...@windriver.com wrote:

The series add libwww-perl-perl to RDEPENDS for ltp as
STPfailure_report.pl provided by ltp depends
on LWP/Simple.pm which is provided by libwww-perl-perl


You are adding 20 new recipes, just to support something in a single
perl script in a single project. Please investigate, what is that
something, is it truly needed in oe-core context, and can it be
disabled, patched out or rewritten so that it doesn't pull in this
massive list of dependencies.


Thanks Alex for your comments!
1, Have double checked the script STPfailure_report.pl history from the 
ltp repo(git://github.com/linux-test-project/ltp.git), it is added as
a tool to analyze failures from LTP runs on the OSDL's Scaleable Test 
Platform (STP) as below:


commit f0573facbbbf14798cc5b7d4653a5e46b4b95fa5
Author: robbiew 
Date:   Wed Apr 28 19:21:39 2004 +

Added tool for analyzing failures from LTP runs on the OSDL's 
Scaleable Test Platform (STP)


2, And go through the contents of the script STPfailure_report.pl and it 
mainly needs to access http://khack.osdl.org to retrieve ltp test 
results run on OSDL's Scaleable Test Platform (STP) and print the 
reports, and now the website http://khack.osdl.org not accessible.


So we don't need to add so many new recipes for dependencies for this 
script STPfailure_report.pl.


Sorry for noise, please ignore it.

And will reorganize the logic to resend another patch not deploy this 
script to our system to avoid confusing about this script fails to run.


Thanks,
Grace



Alex


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

94 matches

Mail list logo