[OE-core] [PATCH] base.bbclass: improve wording when skipping recipes with incompatible licenses

2017-03-03 Thread Andre McCurdy 
The previous wording, e.g.

  ERROR: wget was skipped: incompatible with license GPLv3

isn't very clear and could be taken to imply that the recipe is
incompatible with its own license.

Signed-off-by: Andre McCurdy 
---
 meta/classes/base.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index edac18b..14293f8 100644
--- a/meta/classes/base.bbclass
+++ b/meta/classes/base.bbclass
@@ -533,7 +533,7 @@ python () {
 bb.debug(1, "INCLUDING the package " + pkg)
 elif all_skipped or incompatible_license(d, bad_licenses):
 bb.debug(1, "SKIPPING recipe %s because it's %s" % (pn, 
license))
-raise bb.parse.SkipPackage("incompatible with license %s" 
% license)
+raise bb.parse.SkipPackage("it has an incompatible 
license: %s" % license)
 elif pn in whitelist:
 if pn in incompatwl:
 bb.note("INCLUDING " + pn + " as buildable despite 
INCOMPATIBLE_LICENSE because it has been whitelisted")
-- 
1.9.1

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

[OE-core] [PATCH V7] go: Add recipes for golang compilers and tools

2017-03-03 Thread Khem Raj 
* This is converging the recipes for go from
  meta-virtualization and oe-meta-go

* Add recipes for go 1.7

* go.bbclass is added to ease out writing
  recipes for go packages

* go-examples: Add an example, helloworld written in go
  This should serve as temlate for writing go recipes

Signed-off-by: Khem Raj 
---
 meta/classes/go.bbclass|  72 +++
 meta/classes/goarch.bbclass|  46 +
 meta/recipes-devtools/go/go-1.4.inc|  16 ++
 ...alignment-for-the-.rel.plt-section-on-32-.patch |  30 +++
 .../go/go-1.4/016-armhf-elf-header.patch   |  24 +++
 ...ckport-cmd-link-support-new-386-amd64-rel.patch | 225 +
 meta/recipes-devtools/go/go-1.4/syslog.patch   |  62 ++
 meta/recipes-devtools/go/go-1.6.inc|  19 ++
 .../go/go-1.6/armhf-elf-header.patch   |  23 +++
 .../go/go-1.6/fix-cc-handling.patch|  50 +
 .../go/go-1.6/fix-target-cc-for-build.patch|  17 ++
 meta/recipes-devtools/go/go-1.6/gotooldir.patch|  30 +++
 .../go/go-1.6/split-host-and-target-build.patch|  63 ++
 meta/recipes-devtools/go/go-1.6/syslog.patch   |  62 ++
 meta/recipes-devtools/go/go-1.7.inc|  19 ++
 .../go/go-1.7/armhf-elf-header.patch   |  23 +++
 .../go/go-1.7/fix-cc-handling.patch|  50 +
 .../go/go-1.7/fix-target-cc-for-build.patch|  17 ++
 meta/recipes-devtools/go/go-1.7/gotooldir.patch|  30 +++
 .../go/go-1.7/split-host-and-target-build.patch|  62 ++
 meta/recipes-devtools/go/go-1.7/syslog.patch   |  62 ++
 meta/recipes-devtools/go/go-common.inc |  22 ++
 meta/recipes-devtools/go/go-cross.inc  |  10 +
 meta/recipes-devtools/go/go-cross_1.7.bb   |   5 +
 meta/recipes-devtools/go/go-native.inc |  54 +
 meta/recipes-devtools/go/go-native_1.4.bb  |   2 +
 meta/recipes-devtools/go/go.inc|  80 
 meta/recipes-devtools/go/go_1.6.bb |   4 +
 meta/recipes-devtools/go/go_1.7.bb |   2 +
 .../go-examples/files/helloworld.go|  10 +
 meta/recipes-extended/go-examples/go-examples.inc  |  10 +
 .../go-examples/go-helloworld_0.1.bb   |  13 ++
 32 files changed, 1214 insertions(+)
 create mode 100644 meta/classes/go.bbclass
 create mode 100644 meta/classes/goarch.bbclass
 create mode 100644 meta/recipes-devtools/go/go-1.4.inc
 create mode 100644 
meta/recipes-devtools/go/go-1.4/0001-cmd-ld-set-alignment-for-the-.rel.plt-section-on-32-.patch
 create mode 100644 meta/recipes-devtools/go/go-1.4/016-armhf-elf-header.patch
 create mode 100644 
meta/recipes-devtools/go/go-1.4/go-cross-backport-cmd-link-support-new-386-amd64-rel.patch
 create mode 100644 meta/recipes-devtools/go/go-1.4/syslog.patch
 create mode 100644 meta/recipes-devtools/go/go-1.6.inc
 create mode 100644 meta/recipes-devtools/go/go-1.6/armhf-elf-header.patch
 create mode 100644 meta/recipes-devtools/go/go-1.6/fix-cc-handling.patch
 create mode 100644 
meta/recipes-devtools/go/go-1.6/fix-target-cc-for-build.patch
 create mode 100644 meta/recipes-devtools/go/go-1.6/gotooldir.patch
 create mode 100644 
meta/recipes-devtools/go/go-1.6/split-host-and-target-build.patch
 create mode 100644 meta/recipes-devtools/go/go-1.6/syslog.patch
 create mode 100644 meta/recipes-devtools/go/go-1.7.inc
 create mode 100644 meta/recipes-devtools/go/go-1.7/armhf-elf-header.patch
 create mode 100644 meta/recipes-devtools/go/go-1.7/fix-cc-handling.patch
 create mode 100644 
meta/recipes-devtools/go/go-1.7/fix-target-cc-for-build.patch
 create mode 100644 meta/recipes-devtools/go/go-1.7/gotooldir.patch
 create mode 100644 
meta/recipes-devtools/go/go-1.7/split-host-and-target-build.patch
 create mode 100644 meta/recipes-devtools/go/go-1.7/syslog.patch
 create mode 100644 meta/recipes-devtools/go/go-common.inc
 create mode 100644 meta/recipes-devtools/go/go-cross.inc
 create mode 100644 meta/recipes-devtools/go/go-cross_1.7.bb
 create mode 100644 meta/recipes-devtools/go/go-native.inc
 create mode 100644 meta/recipes-devtools/go/go-native_1.4.bb
 create mode 100644 meta/recipes-devtools/go/go.inc
 create mode 100644 meta/recipes-devtools/go/go_1.6.bb
 create mode 100644 meta/recipes-devtools/go/go_1.7.bb
 create mode 100644 meta/recipes-extended/go-examples/files/helloworld.go
 create mode 100644 meta/recipes-extended/go-examples/go-examples.inc
 create mode 100644 meta/recipes-extended/go-examples/go-helloworld_0.1.bb

diff --git a/meta/classes/go.bbclass b/meta/classes/go.bbclass
new file mode 100644
index 000..e6ea996
--- /dev/null
+++ b/meta/classes/go.bbclass
@@ -0,0 +1,72 @@
+inherit goarch
+
+GOROOT_class-native = "${STAGING_LIBDIR_NATIVE}/go"
+GOROOT = "${STAGING_LIBDIR_NATIVE}/${TARGET_SYS}/go"
+GOBIN_FINAL_class-native = "${GOROOT_FINAL}/bin"
+GOBIN_FINAL =

[OE-core] [PATCH V6] go: Add recipes for golang compilers and tools

2017-03-03 Thread Khem Raj 
* This is converging the recipes for go from
  meta-virtualization and oe-meta-go

* Add recipes for go 1.7

* go.bbclass is added to ease out writing
  recipes for go packages

* go-examples: Add an example, helloworld written in go
  This should serve as temlate for writing go recipes

Signed-off-by: Khem Raj 
---
 meta/classes/go.bbclass|  72 +++
 meta/classes/goarch.bbclass|  46 +
 meta/recipes-devtools/go/go-1.4.inc|  16 ++
 ...alignment-for-the-.rel.plt-section-on-32-.patch |  30 +++
 .../go/go-1.4/016-armhf-elf-header.patch   |  24 +++
 ...ckport-cmd-link-support-new-386-amd64-rel.patch | 225 +
 meta/recipes-devtools/go/go-1.4/syslog.patch   |  62 ++
 meta/recipes-devtools/go/go-1.6.inc|  19 ++
 .../go/go-1.6/armhf-elf-header.patch   |  23 +++
 .../go/go-1.6/fix-cc-handling.patch|  50 +
 .../go/go-1.6/fix-target-cc-for-build.patch|  17 ++
 meta/recipes-devtools/go/go-1.6/gotooldir.patch|  30 +++
 .../go/go-1.6/split-host-and-target-build.patch|  63 ++
 meta/recipes-devtools/go/go-1.6/syslog.patch   |  62 ++
 meta/recipes-devtools/go/go-1.7.inc|  19 ++
 .../go/go-1.7/armhf-elf-header.patch   |  23 +++
 .../go/go-1.7/fix-cc-handling.patch|  50 +
 .../go/go-1.7/fix-target-cc-for-build.patch|  17 ++
 meta/recipes-devtools/go/go-1.7/gotooldir.patch|  30 +++
 .../go/go-1.7/split-host-and-target-build.patch|  62 ++
 meta/recipes-devtools/go/go-1.7/syslog.patch   |  62 ++
 meta/recipes-devtools/go/go-common.inc |  22 ++
 meta/recipes-devtools/go/go-cross.inc  |  10 +
 meta/recipes-devtools/go/go-cross_1.7.bb   |   5 +
 meta/recipes-devtools/go/go-native.inc |  54 +
 meta/recipes-devtools/go/go-native_1.4.bb  |   2 +
 meta/recipes-devtools/go/go.inc|  80 
 meta/recipes-devtools/go/go_1.6.bb |   4 +
 meta/recipes-devtools/go/go_1.7.bb |   2 +
 .../go-examples/files/helloworld.go|  10 +
 meta/recipes-extended/go-examples/go-examples.inc  |  10 +
 .../go-examples/go-helloworld_0.1.bb   |  13 ++
 32 files changed, 1214 insertions(+)
 create mode 100644 meta/classes/go.bbclass
 create mode 100644 meta/classes/goarch.bbclass
 create mode 100644 meta/recipes-devtools/go/go-1.4.inc
 create mode 100644 
meta/recipes-devtools/go/go-1.4/0001-cmd-ld-set-alignment-for-the-.rel.plt-section-on-32-.patch
 create mode 100644 meta/recipes-devtools/go/go-1.4/016-armhf-elf-header.patch
 create mode 100644 
meta/recipes-devtools/go/go-1.4/go-cross-backport-cmd-link-support-new-386-amd64-rel.patch
 create mode 100644 meta/recipes-devtools/go/go-1.4/syslog.patch
 create mode 100644 meta/recipes-devtools/go/go-1.6.inc
 create mode 100644 meta/recipes-devtools/go/go-1.6/armhf-elf-header.patch
 create mode 100644 meta/recipes-devtools/go/go-1.6/fix-cc-handling.patch
 create mode 100644 
meta/recipes-devtools/go/go-1.6/fix-target-cc-for-build.patch
 create mode 100644 meta/recipes-devtools/go/go-1.6/gotooldir.patch
 create mode 100644 
meta/recipes-devtools/go/go-1.6/split-host-and-target-build.patch
 create mode 100644 meta/recipes-devtools/go/go-1.6/syslog.patch
 create mode 100644 meta/recipes-devtools/go/go-1.7.inc
 create mode 100644 meta/recipes-devtools/go/go-1.7/armhf-elf-header.patch
 create mode 100644 meta/recipes-devtools/go/go-1.7/fix-cc-handling.patch
 create mode 100644 
meta/recipes-devtools/go/go-1.7/fix-target-cc-for-build.patch
 create mode 100644 meta/recipes-devtools/go/go-1.7/gotooldir.patch
 create mode 100644 
meta/recipes-devtools/go/go-1.7/split-host-and-target-build.patch
 create mode 100644 meta/recipes-devtools/go/go-1.7/syslog.patch
 create mode 100644 meta/recipes-devtools/go/go-common.inc
 create mode 100644 meta/recipes-devtools/go/go-cross.inc
 create mode 100644 meta/recipes-devtools/go/go-cross_1.7.bb
 create mode 100644 meta/recipes-devtools/go/go-native.inc
 create mode 100644 meta/recipes-devtools/go/go-native_1.4.bb
 create mode 100644 meta/recipes-devtools/go/go.inc
 create mode 100644 meta/recipes-devtools/go/go_1.6.bb
 create mode 100644 meta/recipes-devtools/go/go_1.7.bb
 create mode 100644 meta/recipes-extended/go-examples/files/helloworld.go
 create mode 100644 meta/recipes-extended/go-examples/go-examples.inc
 create mode 100644 meta/recipes-extended/go-examples/go-helloworld_0.1.bb

diff --git a/meta/classes/go.bbclass b/meta/classes/go.bbclass
new file mode 100644
index 000..e6ea996
--- /dev/null
+++ b/meta/classes/go.bbclass
@@ -0,0 +1,72 @@
+inherit goarch
+
+GOROOT_class-native = "${STAGING_LIBDIR_NATIVE}/go"
+GOROOT = "${STAGING_LIBDIR_NATIVE}/${TARGET_SYS}/go"
+GOBIN_FINAL_class-native = "${GOROOT_FINAL}/bin"
+GOBIN_FINAL =

Re: [OE-core] [PATCH] gcc-runtime: Add libmpx supprt for x86

2017-03-03 Thread Khem Raj 
On Fri, Mar 3, 2017 at 2:54 PM, Burton, Ross  wrote:
>
> On 3 March 2017 at 21:39, Khem Raj  wrote:
>>
>> > Enabling building the Intel Memory Protection Extension library for x86.
>> >
>>
>> hope this works on amd chips as well ?
>
>
> https://en.wikipedia.org/wiki/Intel_MPX
>
> It depends on new instructions, so you'll have to ask AMD. :)

OK if its not so then perhaps a bbappend in meta-intel is more appropriate.

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

[OE-core] [PATCH] buildhistory.bbclass: Only execute get_extra_sdkinfo when sdk is enabled

2017-03-03 Thread Aníbal Limón 
If sdk ins't in BUILDHISTORY_FEATURES the get_extra_sdkinfo fails
because no information about sdk is generated in buildhistory repo.

Signed-off-by: Aníbal Limón 
---
 meta/classes/buildhistory.bbclass | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/meta/classes/buildhistory.bbclass 
b/meta/classes/buildhistory.bbclass
index 7251a2c..babcf57 100644
--- a/meta/classes/buildhistory.bbclass
+++ b/meta/classes/buildhistory.bbclass
@@ -550,7 +550,9 @@ END
 python buildhistory_get_extra_sdkinfo() {
 import operator
 import math
-if d.getVar('BB_CURRENTTASK') == 'populate_sdk_ext':
+
+if d.getVar('BB_CURRENTTASK') == 'populate_sdk_ext' and \
+"sdk" in (d.getVar('BUILDHISTORY_FEATURES') or "").split():
 tasksizes = {}
 filesizes = {}
 for root, _, files in 
os.walk(d.expand('${SDK_OUTPUT}/${SDKPATH}/sstate-cache')):
-- 
2.1.4

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

Re: [OE-core] [PATCH] gcc-runtime: Add libmpx supprt for x86

2017-03-03 Thread Burton, Ross 
On 3 March 2017 at 21:39, Khem Raj  wrote:

> > Enabling building the Intel Memory Protection Extension library for x86.
> >
>
> hope this works on amd chips as well ?


https://en.wikipedia.org/wiki/Intel_MPX

It depends on new instructions, so you'll have to ask AMD. :)

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

[OE-core] [PATCH V5] go: Add recipes for golang compilers and tools

2017-03-03 Thread Khem Raj 
* This is converging the recipes for go from
  meta-virtualization and oe-meta-go

* Add recipes for go 1.7

* go.bbclass is added to ease out writing
  recipes for go packages

* go-examples: Add an example, helloworld written in go
  This should serve as temlate for writing go recipes

Signed-off-by: Khem Raj 
---
 meta/classes/go.bbclass|  72 +++
 meta/classes/goarch.bbclass|  46 +
 meta/recipes-devtools/go/go-1.4.inc|  16 ++
 ...alignment-for-the-.rel.plt-section-on-32-.patch |  30 +++
 .../go/go-1.4/016-armhf-elf-header.patch   |  24 +++
 ...ckport-cmd-link-support-new-386-amd64-rel.patch | 225 +
 meta/recipes-devtools/go/go-1.4/syslog.patch   |  62 ++
 meta/recipes-devtools/go/go-1.6.inc|  19 ++
 .../go/go-1.6/armhf-elf-header.patch   |  23 +++
 .../go/go-1.6/fix-cc-handling.patch|  50 +
 .../go/go-1.6/fix-target-cc-for-build.patch|  17 ++
 meta/recipes-devtools/go/go-1.6/gotooldir.patch|  30 +++
 .../go/go-1.6/split-host-and-target-build.patch|  63 ++
 meta/recipes-devtools/go/go-1.6/syslog.patch   |  62 ++
 meta/recipes-devtools/go/go-1.7.inc|  19 ++
 .../go/go-1.7/armhf-elf-header.patch   |  23 +++
 .../go/go-1.7/fix-cc-handling.patch|  50 +
 .../go/go-1.7/fix-target-cc-for-build.patch|  17 ++
 meta/recipes-devtools/go/go-1.7/gotooldir.patch|  30 +++
 .../go/go-1.7/split-host-and-target-build.patch|  62 ++
 meta/recipes-devtools/go/go-1.7/syslog.patch   |  62 ++
 meta/recipes-devtools/go/go-common.inc |  22 ++
 meta/recipes-devtools/go/go-cross.inc  |  10 +
 meta/recipes-devtools/go/go-cross_1.7.bb   |   5 +
 meta/recipes-devtools/go/go-native.inc |  51 +
 meta/recipes-devtools/go/go-native_1.4.bb  |   2 +
 meta/recipes-devtools/go/go.inc|  76 +++
 meta/recipes-devtools/go/go_1.6.bb |   4 +
 meta/recipes-devtools/go/go_1.7.bb |   2 +
 .../go-examples/files/helloworld.go|  10 +
 meta/recipes-extended/go-examples/go-examples.inc  |  10 +
 .../go-examples/go-helloworld_0.1.bb   |  13 ++
 32 files changed, 1207 insertions(+)
 create mode 100644 meta/classes/go.bbclass
 create mode 100644 meta/classes/goarch.bbclass
 create mode 100644 meta/recipes-devtools/go/go-1.4.inc
 create mode 100644 
meta/recipes-devtools/go/go-1.4/0001-cmd-ld-set-alignment-for-the-.rel.plt-section-on-32-.patch
 create mode 100644 meta/recipes-devtools/go/go-1.4/016-armhf-elf-header.patch
 create mode 100644 
meta/recipes-devtools/go/go-1.4/go-cross-backport-cmd-link-support-new-386-amd64-rel.patch
 create mode 100644 meta/recipes-devtools/go/go-1.4/syslog.patch
 create mode 100644 meta/recipes-devtools/go/go-1.6.inc
 create mode 100644 meta/recipes-devtools/go/go-1.6/armhf-elf-header.patch
 create mode 100644 meta/recipes-devtools/go/go-1.6/fix-cc-handling.patch
 create mode 100644 
meta/recipes-devtools/go/go-1.6/fix-target-cc-for-build.patch
 create mode 100644 meta/recipes-devtools/go/go-1.6/gotooldir.patch
 create mode 100644 
meta/recipes-devtools/go/go-1.6/split-host-and-target-build.patch
 create mode 100644 meta/recipes-devtools/go/go-1.6/syslog.patch
 create mode 100644 meta/recipes-devtools/go/go-1.7.inc
 create mode 100644 meta/recipes-devtools/go/go-1.7/armhf-elf-header.patch
 create mode 100644 meta/recipes-devtools/go/go-1.7/fix-cc-handling.patch
 create mode 100644 
meta/recipes-devtools/go/go-1.7/fix-target-cc-for-build.patch
 create mode 100644 meta/recipes-devtools/go/go-1.7/gotooldir.patch
 create mode 100644 
meta/recipes-devtools/go/go-1.7/split-host-and-target-build.patch
 create mode 100644 meta/recipes-devtools/go/go-1.7/syslog.patch
 create mode 100644 meta/recipes-devtools/go/go-common.inc
 create mode 100644 meta/recipes-devtools/go/go-cross.inc
 create mode 100644 meta/recipes-devtools/go/go-cross_1.7.bb
 create mode 100644 meta/recipes-devtools/go/go-native.inc
 create mode 100644 meta/recipes-devtools/go/go-native_1.4.bb
 create mode 100644 meta/recipes-devtools/go/go.inc
 create mode 100644 meta/recipes-devtools/go/go_1.6.bb
 create mode 100644 meta/recipes-devtools/go/go_1.7.bb
 create mode 100644 meta/recipes-extended/go-examples/files/helloworld.go
 create mode 100644 meta/recipes-extended/go-examples/go-examples.inc
 create mode 100644 meta/recipes-extended/go-examples/go-helloworld_0.1.bb

diff --git a/meta/classes/go.bbclass b/meta/classes/go.bbclass
new file mode 100644
index 000..e6ea996
--- /dev/null
+++ b/meta/classes/go.bbclass
@@ -0,0 +1,72 @@
+inherit goarch
+
+GOROOT_class-native = "${STAGING_LIBDIR_NATIVE}/go"
+GOROOT = "${STAGING_LIBDIR_NATIVE}/${TARGET_SYS}/go"
+GOBIN_FINAL_class-native = "${GOROOT_FINAL}/bin"
+GOBIN_FINAL =

Re: [OE-core] [PATCH 2/2] aor: fix rss+perf+gold failure on do_compile_ptest_base

2017-03-03 Thread Martin Jansa 
Typo in summary, but thanks for taking care of this!

On Fri, Mar 3, 2017 at 10:36 PM, Andreas Müller <
schnitzelt...@googlemail.com> wrote:

> Was detected in Martin's world build
>
> Signed-off-by: Andreas Müller 
> ---
>  ...link-libapr-against-phtread-to-make-gold-.patch | 50
> ++
>  meta/recipes-support/apr/apr_1.5.2.bb  |  1 +
>  2 files changed, 51 insertions(+)
>  create mode 100644 meta/recipes-support/apr/apr/
> 0002-explicitly-link-libapr-against-phtread-to-make-gold-.patch
>
> diff --git a/meta/recipes-support/apr/apr/0002-explicitly-link-
> libapr-against-phtread-to-make-gold-.patch b/meta/recipes-support/apr/
> apr/0002-explicitly-link-libapr-against-phtread-to-make-gold-.patch
> new file mode 100644
> index 000..7d0dddc
> --- /dev/null
> +++ b/meta/recipes-support/apr/apr/0002-explicitly-link-
> libapr-against-phtread-to-make-gold-.patch
> @@ -0,0 +1,50 @@
> +From 94d1ca0266a0f9c0446f1299b54f752e87b8a695 Mon Sep 17 00:00:00 2001
> +From: =?UTF-8?q?Andreas=20M=C3=BCller?= 
> +Date: Fri, 3 Mar 2017 22:24:17 +0100
> +Subject: [PATCH] explicitly link libapr against phtread to make gold
> happy on
> + test
> +MIME-Version: 1.0
> +Content-Type: text/plain; charset=UTF-8
> +Content-Transfer-Encoding: 8bit
> +
> +| ../.libs/libapr-1.so: error: undefined reference to
> 'pthread_mutexattr_init'
> +| ../.libs/libapr-1.so: error: undefined reference to
> 'pthread_mutexattr_settype'
> +| ../.libs/libapr-1.so: error: undefined reference to
> 'pthread_mutexattr_destroy'
> +| ../.libs/libapr-1.so: error: undefined reference to
> 'pthread_mutex_trylock'
> +| ../.libs/libapr-1.so: error: undefined reference to
> 'pthread_attr_setstacksize'
> +| ../.libs/libapr-1.so: error: undefined reference to 'pthread_create'
> +| ../.libs/libapr-1.so: error: undefined reference to 'pthread_join'
> +| ../.libs/libapr-1.so: error: undefined reference to 'pthread_detach'
> +| ../.libs/libapr-1.so: error: undefined reference to 'pthread_sigmask'
> +| ../.libs/libapr-1.so: error: undefined reference to 'pthread_once'
> +| ../.libs/libapr-1.so: error: undefined reference to 'pthread_key_create'
> +| ../.libs/libapr-1.so: error: undefined reference to
> 'pthread_getspecific'
> +| ../.libs/libapr-1.so: error: undefined reference to 'pthread_key_delete'
> +| ../.libs/libapr-1.so: error: undefined reference to
> 'pthread_setspecific'
> +| collect2: error: ld returned 1 exit status
> +| Makefile:114: recipe for target 'globalmutexchild' failed
> +| make[1]: *** [globalmutexchild] Error 1
> +| make[1]: Leaving directory '/home/superandy/tmp/oe-core-
> glibc/work/cortexa7t2hf-neon-vfpv4-angstrom-linux-gnueabi/
> apr/1.5.2-r0/apr-1.5.2/test'
> +
> +Upstream-Status: Pending
> +
> +Signed-off-by: Andreas Müller 
> +---
> + configure.in | 1 +
> + 1 file changed, 1 insertion(+)
> +
> +diff --git a/configure.in b/configure.in
> +index 5b19940..cdf4d58 100644
> +--- a/configure.in
>  b/configure.in
> +@@ -766,6 +766,7 @@ else
> +   APR_PTHREADS_CHECK_RESTORE ] )
> + fi
> + if test "$pthreadh" = "1"; then
> ++APR_ADDTO(LIBS,[-lpthread])
> + APR_CHECK_PTHREAD_GETSPECIFIC_TWO_ARGS
> + APR_CHECK_PTHREAD_ATTR_GETDETACHSTATE_ONE_ARG
> + APR_CHECK_PTHREAD_RECURSIVE_MUTEX
> +--
> +2.9.3
> +
> diff --git a/meta/recipes-support/apr/apr_1.5.2.bb
> b/meta/recipes-support/apr/apr_1.5.2.bb
> index 079f8cd..992b561 100644
> --- a/meta/recipes-support/apr/apr_1.5.2.bb
> +++ b/meta/recipes-support/apr/apr_1.5.2.bb
> @@ -18,6 +18,7 @@ SRC_URI = "${APACHE_MIRROR}/apr/${BPN}-${PV}.tar.bz2 \
> file://Fix-packet-discards-HTTP-redirect.patch \
> file://configure.in-fix-LTFLAGS-to-make-it-work-with-ccache.patch
> \
> 
> file://0001-apr-fix-off_t-size-doesn-t-match-in-glibc-when-cross.patch
> \
> +   
> file://0002-explicitly-link-libapr-against-phtread-to-make-gold-.patch
> \
>  "
>
>  SRC_URI[md5sum] = "4e9769f3349fe11fc0a5e1b224c236aa"
> --
> 2.9.3
>
> --
> ___
> 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 V4] go: Add recipes for golang compilers and tools

2017-03-03 Thread Khem Raj 
* This is converging the recipes for go from
  meta-virtualization and oe-meta-go

* Add recipes for go 1.7

* go.bbclass is added to ease out writing
  recipes for go packages

* go-examples: Add an example, helloworld written in go
  This should serve as temlate for writing go recipes

Signed-off-by: Khem Raj 
---
 meta/classes/go.bbclass|  72 +++
 meta/classes/goarch.bbclass|  46 +
 meta/recipes-devtools/go/go-1.4.inc|  16 ++
 ...alignment-for-the-.rel.plt-section-on-32-.patch |  30 +++
 .../go/go-1.4/016-armhf-elf-header.patch   |  24 +++
 ...ckport-cmd-link-support-new-386-amd64-rel.patch | 225 +
 meta/recipes-devtools/go/go-1.4/syslog.patch   |  62 ++
 meta/recipes-devtools/go/go-1.6.inc|  19 ++
 .../go/go-1.6/armhf-elf-header.patch   |  23 +++
 .../go/go-1.6/fix-cc-handling.patch|  50 +
 .../go/go-1.6/fix-target-cc-for-build.patch|  17 ++
 meta/recipes-devtools/go/go-1.6/gotooldir.patch|  30 +++
 .../go/go-1.6/split-host-and-target-build.patch|  63 ++
 meta/recipes-devtools/go/go-1.6/syslog.patch   |  62 ++
 meta/recipes-devtools/go/go-1.7.inc|  19 ++
 .../go/go-1.7/armhf-elf-header.patch   |  23 +++
 .../go/go-1.7/fix-cc-handling.patch|  50 +
 .../go/go-1.7/fix-target-cc-for-build.patch|  17 ++
 meta/recipes-devtools/go/go-1.7/gotooldir.patch|  30 +++
 .../go/go-1.7/split-host-and-target-build.patch|  62 ++
 meta/recipes-devtools/go/go-1.7/syslog.patch   |  62 ++
 meta/recipes-devtools/go/go-common.inc |  22 ++
 meta/recipes-devtools/go/go-cross.inc  |  10 +
 meta/recipes-devtools/go/go-cross_1.7.bb   |   5 +
 meta/recipes-devtools/go/go-native.inc |  51 +
 meta/recipes-devtools/go/go-native_1.4.bb  |   2 +
 meta/recipes-devtools/go/go.inc|  76 +++
 meta/recipes-devtools/go/go_1.6.bb |   4 +
 meta/recipes-devtools/go/go_1.7.bb |   2 +
 .../go-examples/files/helloworld.go|  10 +
 meta/recipes-extended/go-examples/go-examples.inc  |  10 +
 .../go-examples/go-helloworld_0.1.bb   |  15 ++
 32 files changed, 1209 insertions(+)
 create mode 100644 meta/classes/go.bbclass
 create mode 100644 meta/classes/goarch.bbclass
 create mode 100644 meta/recipes-devtools/go/go-1.4.inc
 create mode 100644 
meta/recipes-devtools/go/go-1.4/0001-cmd-ld-set-alignment-for-the-.rel.plt-section-on-32-.patch
 create mode 100644 meta/recipes-devtools/go/go-1.4/016-armhf-elf-header.patch
 create mode 100644 
meta/recipes-devtools/go/go-1.4/go-cross-backport-cmd-link-support-new-386-amd64-rel.patch
 create mode 100644 meta/recipes-devtools/go/go-1.4/syslog.patch
 create mode 100644 meta/recipes-devtools/go/go-1.6.inc
 create mode 100644 meta/recipes-devtools/go/go-1.6/armhf-elf-header.patch
 create mode 100644 meta/recipes-devtools/go/go-1.6/fix-cc-handling.patch
 create mode 100644 
meta/recipes-devtools/go/go-1.6/fix-target-cc-for-build.patch
 create mode 100644 meta/recipes-devtools/go/go-1.6/gotooldir.patch
 create mode 100644 
meta/recipes-devtools/go/go-1.6/split-host-and-target-build.patch
 create mode 100644 meta/recipes-devtools/go/go-1.6/syslog.patch
 create mode 100644 meta/recipes-devtools/go/go-1.7.inc
 create mode 100644 meta/recipes-devtools/go/go-1.7/armhf-elf-header.patch
 create mode 100644 meta/recipes-devtools/go/go-1.7/fix-cc-handling.patch
 create mode 100644 
meta/recipes-devtools/go/go-1.7/fix-target-cc-for-build.patch
 create mode 100644 meta/recipes-devtools/go/go-1.7/gotooldir.patch
 create mode 100644 
meta/recipes-devtools/go/go-1.7/split-host-and-target-build.patch
 create mode 100644 meta/recipes-devtools/go/go-1.7/syslog.patch
 create mode 100644 meta/recipes-devtools/go/go-common.inc
 create mode 100644 meta/recipes-devtools/go/go-cross.inc
 create mode 100644 meta/recipes-devtools/go/go-cross_1.7.bb
 create mode 100644 meta/recipes-devtools/go/go-native.inc
 create mode 100644 meta/recipes-devtools/go/go-native_1.4.bb
 create mode 100644 meta/recipes-devtools/go/go.inc
 create mode 100644 meta/recipes-devtools/go/go_1.6.bb
 create mode 100644 meta/recipes-devtools/go/go_1.7.bb
 create mode 100644 meta/recipes-extended/go-examples/files/helloworld.go
 create mode 100644 meta/recipes-extended/go-examples/go-examples.inc
 create mode 100644 meta/recipes-extended/go-examples/go-helloworld_0.1.bb

diff --git a/meta/classes/go.bbclass b/meta/classes/go.bbclass
new file mode 100644
index 000..e6ea996
--- /dev/null
+++ b/meta/classes/go.bbclass
@@ -0,0 +1,72 @@
+inherit goarch
+
+GOROOT_class-native = "${STAGING_LIBDIR_NATIVE}/go"
+GOROOT = "${STAGING_LIBDIR_NATIVE}/${TARGET_SYS}/go"
+GOBIN_FINAL_class-native = "${GOROOT_FINAL}/bin"
+GOBIN_FINAL =

Re: [OE-core] [PATCH] gcc-runtime: Add libmpx supprt for x86

2017-03-03 Thread Khem Raj 
On Fri, Mar 3, 2017 at 3:54 AM, Richard Purdie
 wrote:
> Enabling building the Intel Memory Protection Extension library for x86.
>

hope this works on amd chips as well ?

> Signed-off-by: Richard Purdie 
> ---
>  meta/recipes-devtools/gcc/gcc-runtime.inc | 20 +++-
>  1 file changed, 19 insertions(+), 1 deletion(-)
>
> diff --git a/meta/recipes-devtools/gcc/gcc-runtime.inc 
> b/meta/recipes-devtools/gcc/gcc-runtime.inc
> index 745cf74..614b070 100644
> --- a/meta/recipes-devtools/gcc/gcc-runtime.inc
> +++ b/meta/recipes-devtools/gcc/gcc-runtime.inc
> @@ -24,8 +24,8 @@ RUNTIMELIBITM_microblaze = ""
>  RUNTIMETARGET = "libssp libstdc++-v3 libgomp libatomic ${RUNTIMELIBITM} \
>  ${@bb.utils.contains_any('FORTRAN', [',fortran',',f77'], 'libquadmath', 
> '', d)} \
>  "
> +RUNTIMETARGET_append_x86 = " libmpx"
>
> -#  ?
>  # libiberty
>  # libmudflap
>  # libgfortran needs separate recipe due to libquadmath dependency
> @@ -139,6 +139,11 @@ PACKAGES = "\
>  libitm-dev \
>  libitm-staticdev \
>  "
> +PACKAGES_append_x86 = "\
> +libmpx \
> +libmpx-dev \
> +libmpx-staticdev \
> +"
>
>  # The base package doesn't exist, so we clear the recommends.
>  RRECOMMENDS_${PN}-dbg = ""
> @@ -243,6 +248,19 @@ SUMMARY_libitm-dev = "GNU transactional memory support 
> library - development fil
>  FILES_libitm-staticdev = "${libdir}/libitm.a"
>  SUMMARY_libitm-staticdev = "GNU transactional memory support library - 
> static development files"
>
> +
> +FILES_libmpx = "${libdir}/libmpx.so.* ${libdir}/libmpxwrappers.so.*"
> +SUMMARY_libmpx = "Intel Memory Protection Extension library"
> +FILES_libmpx-dev = "\
> +${libdir}/libmpxwrappers.so \
> +${libdir}/libmpx.so \
> +${libdir}/libmpx.la \
> +${libdir}/libmpx.spec \
> +"
> +SUMMARY_libmpx-dev = "Intel Memory Protection Extension library - 
> development files"
> +FILES_libmpx-staticdev = "${libdir}/libmpx.a ${libdir}/libmpxwrappers.a"
> +SUMMARY_libmpx-staticdev = "Intel Memory Protection Extension library - 
> static development files"
> +
>  do_package_write_ipk[depends] += "virtual/${MLPREFIX}libc:do_packagedata"
>  do_package_write_deb[depends] += "virtual/${MLPREFIX}libc:do_packagedata"
>  do_package_write_rpm[depends] += "virtual/${MLPREFIX}libc:do_packagedata"
> --
> 2.7.4
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCHv4 0/6] Add dummy tools to help identify needed dependencies

2017-03-03 Thread Peter Kjellerstedt 
After the introduction of RSS, I still found it hard to get
dependencies on some common tools that are typically installed on the
build host correct. Using the wrong version of tools like pkg-config,
gdbus-codegen and dbus-binding-tool can cause build failures.

To circumvent this, I created dummy versions of the tools that always
fail and placed them in the scripts directory. Thus, if the real tool
has not been installed in the RSS, the dummy version is used and the
build fails. For good measures I even output a message that says what
needs to be corrected in the recipe.

Included is also an update to linux-libc-headers as it apparently
needs to inherit pkgconfig, which the introduction of the dummy
version of pkg-config showed.

PATCHv2: Also inherit pkgconfig in module.bbclass since pkg-config
is needed for the make_scripts task.

PATCHv3: Add a missing Signed-off-by footer.

PATCHv4: Move the dummy scripts to scripts/blacklisted and add it to
PATH in bitbake.conf.

//Peter

The following changes since commit 2e5181e510f3fffee53cfeab0380e8ad9b5ae60c:

  testsdk: Fix lockfile patch (2017-03-03 12:21:09 +)

are available in the git repository at:

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

Peter Kjellerstedt (6):
  module.bbclass: Add inherit of pkgconfig
  linux-libc-headers: Add inherit of pkgconfig
  blacklisted/dbus-binding-tool: Add a dummy version that always fails
  blacklisted/gdbus-codegen: Add a dummy version that always fails
  blacklisted/pkg-config: Add a dummy version that always fails
  bitbake.conf: Add ${COREBASE}/scripts/blacklisted to ${PATH}

 meta/classes/module.bbclass  |  2 +-
 meta/conf/bitbake.conf   |  2 +-
 .../linux-libc-headers/linux-libc-headers.inc|  2 +-
 scripts/blacklisted/dbus-binding-tool| 11 +++
 scripts/blacklisted/gdbus-codegen| 11 +++
 scripts/blacklisted/pkg-config   | 16 
 6 files changed, 41 insertions(+), 3 deletions(-)
 create mode 100755 scripts/blacklisted/dbus-binding-tool
 create mode 100755 scripts/blacklisted/gdbus-codegen
 create mode 100755 scripts/blacklisted/pkg-config

-- 
2.9.0

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

[OE-core] [PATCHv4 5/6] blacklisted/pkg-config: Add a dummy version that always fails

2017-03-03 Thread Peter Kjellerstedt 
This is intended to catch missing dependencies on the real version.

Signed-off-by: Peter Kjellerstedt 
---
 scripts/blacklisted/pkg-config | 16 
 1 file changed, 16 insertions(+)
 create mode 100755 scripts/blacklisted/pkg-config

diff --git a/scripts/blacklisted/pkg-config b/scripts/blacklisted/pkg-config
new file mode 100755
index 000..c6376ec
--- /dev/null
+++ b/scripts/blacklisted/pkg-config
@@ -0,0 +1,16 @@
+#!/bin/sh
+
+# This is a dummy version that always fails. It is intended to catch
+# missing dependencies on the real version.
+
+myname=${0##*/}
+
+echo "The correct version of $myname is not being used!" >&2
+echo "Make sure the recipe inherits 'pkgconfig'." >&2
+
+# Return something that will make the compiler barf. This is for when
+# pkg-config is used directly in a Makefile in a construct like:
+# CFLAGS += $(shell pkg-config --cflags glib-2.0)
+echo "The-correct-version-of-$myname-is-not-being-used"
+
+exit 1
-- 
2.9.0

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

[OE-core] [PATCHv4 3/6] blacklisted/dbus-binding-tool: Add a dummy version that always fails

2017-03-03 Thread Peter Kjellerstedt 
This is intended to catch missing dependencies on the real version.

Signed-off-by: Peter Kjellerstedt 
---
 scripts/blacklisted/dbus-binding-tool | 11 +++
 1 file changed, 11 insertions(+)
 create mode 100755 scripts/blacklisted/dbus-binding-tool

diff --git a/scripts/blacklisted/dbus-binding-tool 
b/scripts/blacklisted/dbus-binding-tool
new file mode 100755
index 000..2e85987
--- /dev/null
+++ b/scripts/blacklisted/dbus-binding-tool
@@ -0,0 +1,11 @@
+#!/bin/sh
+
+# This is a dummy version that always fails. It is intended to catch
+# missing dependencies on the real version.
+
+myname=${0##*/}
+
+echo "The correct version of $myname is not being used!" >&2
+echo "Make sure the recipe DEPENDS on 'dbus-glib-native'." >&2
+
+exit 1
-- 
2.9.0

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

[OE-core] [PATCHv4 6/6] bitbake.conf: Add ${COREBASE}/scripts/blacklisted to ${PATH}

2017-03-03 Thread Peter Kjellerstedt 
The scripts/blacklisted directory contains dummy tools that blocks out
the corresponding tool from the host installation. It is excpected
that the correct version of the tools are instead built and installed
to the RSS for recipes that need any of these tools.

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

diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index ade0eff..a6c44d1 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -446,7 +446,7 @@ EXTRA_IMAGEDEPENDS = ""
 # Toolchain info.
 ##
 
-PATH_prepend = 
"${COREBASE}/scripts:${STAGING_BINDIR_TOOLCHAIN}:${STAGING_BINDIR_CROSS}:${STAGING_DIR_NATIVE}${sbindir_native}:${STAGING_BINDIR_NATIVE}:${STAGING_DIR_NATIVE}${base_sbindir_native}:${STAGING_DIR_NATIVE}${base_bindir_native}:"
+PATH_prepend = 
"${COREBASE}/scripts:${STAGING_BINDIR_TOOLCHAIN}:${STAGING_BINDIR_CROSS}:${STAGING_DIR_NATIVE}${sbindir_native}:${STAGING_BINDIR_NATIVE}:${STAGING_DIR_NATIVE}${base_sbindir_native}:${STAGING_DIR_NATIVE}${base_bindir_native}:${COREBASE}/scripts/blacklisted:"
 export PATH
 
 ##
-- 
2.9.0

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

[OE-core] [PATCHv4 4/6] blacklisted/gdbus-codegen: Add a dummy version that always fails

2017-03-03 Thread Peter Kjellerstedt 
This is intended to catch missing dependencies on the real version.

Signed-off-by: Peter Kjellerstedt 
---
 scripts/blacklisted/gdbus-codegen | 11 +++
 1 file changed, 11 insertions(+)
 create mode 100755 scripts/blacklisted/gdbus-codegen

diff --git a/scripts/blacklisted/gdbus-codegen 
b/scripts/blacklisted/gdbus-codegen
new file mode 100755
index 000..d91386b
--- /dev/null
+++ b/scripts/blacklisted/gdbus-codegen
@@ -0,0 +1,11 @@
+#!/bin/sh
+
+# This is a dummy version that always fails. It is intended to catch
+# missing dependencies on the real version.
+
+myname=${0##*/}
+
+echo "The correct version of $myname is not being used!" >&2
+echo "Make sure the recipe DEPENDS on 'glib-2.0-native'." >&2
+
+exit 1
-- 
2.9.0

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

[OE-core] [PATCHv4 1/6] module.bbclass: Add inherit of pkgconfig

2017-03-03 Thread Peter Kjellerstedt 
This is needed for the make_scripts task.

Signed-off-by: Peter Kjellerstedt 
---
 meta/classes/module.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/module.bbclass b/meta/classes/module.bbclass
index a588873..99b7ebc 100644
--- a/meta/classes/module.bbclass
+++ b/meta/classes/module.bbclass
@@ -1,4 +1,4 @@
-inherit module-base kernel-module-split
+inherit module-base kernel-module-split pkgconfig
 
 addtask make_scripts after do_prepare_recipe_sysroot before do_compile
 do_make_scripts[lockfiles] = "${TMPDIR}/kernel-scripts.lock"
-- 
2.9.0

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

[OE-core] [PATCHv4 2/6] linux-libc-headers: Add inherit of pkgconfig

2017-03-03 Thread Peter Kjellerstedt 
pkg-config is used by the kernel build system when creating the
configuration tools.

Signed-off-by: Peter Kjellerstedt 
---
 meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc 
b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
index 30d2243..653a470 100644
--- a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
+++ b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
@@ -42,7 +42,7 @@ python __anonymous () {
 d.setVar("HEADER_FETCH_VER", "2.6")
 }
 
-inherit kernel-arch
+inherit kernel-arch pkgconfig
 
 KORG_ARCHIVE_COMPRESSION ?= "xz"
 
-- 
2.9.0

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

[OE-core] [PATCH 2/2] aor: fix rss+perf+gold failure on do_compile_ptest_base

2017-03-03 Thread Andreas Müller 
Was detected in Martin's world build

Signed-off-by: Andreas Müller 
---
 ...link-libapr-against-phtread-to-make-gold-.patch | 50 ++
 meta/recipes-support/apr/apr_1.5.2.bb  |  1 +
 2 files changed, 51 insertions(+)
 create mode 100644 
meta/recipes-support/apr/apr/0002-explicitly-link-libapr-against-phtread-to-make-gold-.patch

diff --git 
a/meta/recipes-support/apr/apr/0002-explicitly-link-libapr-against-phtread-to-make-gold-.patch
 
b/meta/recipes-support/apr/apr/0002-explicitly-link-libapr-against-phtread-to-make-gold-.patch
new file mode 100644
index 000..7d0dddc
--- /dev/null
+++ 
b/meta/recipes-support/apr/apr/0002-explicitly-link-libapr-against-phtread-to-make-gold-.patch
@@ -0,0 +1,50 @@
+From 94d1ca0266a0f9c0446f1299b54f752e87b8a695 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Andreas=20M=C3=BCller?= 
+Date: Fri, 3 Mar 2017 22:24:17 +0100
+Subject: [PATCH] explicitly link libapr against phtread to make gold happy on
+ test
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+| ../.libs/libapr-1.so: error: undefined reference to 'pthread_mutexattr_init'
+| ../.libs/libapr-1.so: error: undefined reference to 
'pthread_mutexattr_settype'
+| ../.libs/libapr-1.so: error: undefined reference to 
'pthread_mutexattr_destroy'
+| ../.libs/libapr-1.so: error: undefined reference to 'pthread_mutex_trylock'
+| ../.libs/libapr-1.so: error: undefined reference to 
'pthread_attr_setstacksize'
+| ../.libs/libapr-1.so: error: undefined reference to 'pthread_create'
+| ../.libs/libapr-1.so: error: undefined reference to 'pthread_join'
+| ../.libs/libapr-1.so: error: undefined reference to 'pthread_detach'
+| ../.libs/libapr-1.so: error: undefined reference to 'pthread_sigmask'
+| ../.libs/libapr-1.so: error: undefined reference to 'pthread_once'
+| ../.libs/libapr-1.so: error: undefined reference to 'pthread_key_create'
+| ../.libs/libapr-1.so: error: undefined reference to 'pthread_getspecific'
+| ../.libs/libapr-1.so: error: undefined reference to 'pthread_key_delete'
+| ../.libs/libapr-1.so: error: undefined reference to 'pthread_setspecific'
+| collect2: error: ld returned 1 exit status
+| Makefile:114: recipe for target 'globalmutexchild' failed
+| make[1]: *** [globalmutexchild] Error 1
+| make[1]: Leaving directory 
'/home/superandy/tmp/oe-core-glibc/work/cortexa7t2hf-neon-vfpv4-angstrom-linux-gnueabi/apr/1.5.2-r0/apr-1.5.2/test'
+
+Upstream-Status: Pending
+
+Signed-off-by: Andreas Müller 
+---
+ configure.in | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/configure.in b/configure.in
+index 5b19940..cdf4d58 100644
+--- a/configure.in
 b/configure.in
+@@ -766,6 +766,7 @@ else
+   APR_PTHREADS_CHECK_RESTORE ] )
+ fi
+ if test "$pthreadh" = "1"; then
++APR_ADDTO(LIBS,[-lpthread])
+ APR_CHECK_PTHREAD_GETSPECIFIC_TWO_ARGS
+ APR_CHECK_PTHREAD_ATTR_GETDETACHSTATE_ONE_ARG
+ APR_CHECK_PTHREAD_RECURSIVE_MUTEX
+-- 
+2.9.3
+
diff --git a/meta/recipes-support/apr/apr_1.5.2.bb 
b/meta/recipes-support/apr/apr_1.5.2.bb
index 079f8cd..992b561 100644
--- a/meta/recipes-support/apr/apr_1.5.2.bb
+++ b/meta/recipes-support/apr/apr_1.5.2.bb
@@ -18,6 +18,7 @@ SRC_URI = "${APACHE_MIRROR}/apr/${BPN}-${PV}.tar.bz2 \
file://Fix-packet-discards-HTTP-redirect.patch \
file://configure.in-fix-LTFLAGS-to-make-it-work-with-ccache.patch \

file://0001-apr-fix-off_t-size-doesn-t-match-in-glibc-when-cross.patch \
+   
file://0002-explicitly-link-libapr-against-phtread-to-make-gold-.patch \
 "
 
 SRC_URI[md5sum] = "4e9769f3349fe11fc0a5e1b224c236aa"
-- 
2.9.3

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

[OE-core] [PATCH 1/2] parted: fix rss+perf+gold failure on do_compile_ptest_base

2017-03-03 Thread Andreas Müller 
Was detected in Martin's world build

Signed-off-by: Andreas Müller 
---
 ...s_resize-link-against-libuuid-explicitly-.patch | 34 ++
 meta/recipes-extended/parted/parted_3.2.bb |  1 +
 2 files changed, 35 insertions(+)
 create mode 100644 
meta/recipes-extended/parted/files/0002-libparted_fs_resize-link-against-libuuid-explicitly-.patch

diff --git 
a/meta/recipes-extended/parted/files/0002-libparted_fs_resize-link-against-libuuid-explicitly-.patch
 
b/meta/recipes-extended/parted/files/0002-libparted_fs_resize-link-against-libuuid-explicitly-.patch
new file mode 100644
index 000..bd2b5c5
--- /dev/null
+++ 
b/meta/recipes-extended/parted/files/0002-libparted_fs_resize-link-against-libuuid-explicitly-.patch
@@ -0,0 +1,34 @@
+From 5c99d7e4c2b5e7a957dc922aff03debfebbd6154 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Andreas=20M=C3=BCller?= 
+Date: Fri, 3 Mar 2017 21:49:15 +0100
+Subject: [PATCH] libparted_fs_resize: link against libuuid explicitly to
+ unbreak gold linking on test
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+| ../libparted/fs/.libs/libparted-fs-resize.so: error: undefined reference to 
'uuid_generate'
+
+Upstream-Status: Pending
+
+Signed-off-by: Andreas Müller 
+---
+ libparted/fs/Makefile.am | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/libparted/fs/Makefile.am b/libparted/fs/Makefile.am
+index d3cc8bc..c301b0b 100644
+--- a/libparted/fs/Makefile.am
 b/libparted/fs/Makefile.am
+@@ -113,6 +113,8 @@ libparted_fs_resize_la_SOURCES = \
+   r/hfs/reloc_plus.c  \
+   r/hfs/reloc_plus.h
+ 
++libparted_fs_resize_la_LIBADD   = $(UUID_LIBS)
++
+ AM_CPPFLAGS = \
+   -I$(top_srcdir)/libparted/labels\
+   $(partedincludedir) \
+-- 
+2.9.3
+
diff --git a/meta/recipes-extended/parted/parted_3.2.bb 
b/meta/recipes-extended/parted/parted_3.2.bb
index edc4bd3..9ce2dfe 100644
--- a/meta/recipes-extended/parted/parted_3.2.bb
+++ b/meta/recipes-extended/parted/parted_3.2.bb
@@ -13,6 +13,7 @@ SRC_URI = "${GNU_MIRROR}/parted/parted-${PV}.tar.xz \
file://fix-compile-failure-while-dis.patch \
file://0001-Include-fcntl.h-in-platform_defs.h.patch \
file://0001-Unset-need_charset_alias-when-building-for-musl.patch \
+   
file://0002-libparted_fs_resize-link-against-libuuid-explicitly-.patch \
   file://parted-3.2-sysmacros.patch \
file://run-ptest \
file://Makefile \
-- 
2.9.3

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

Re: [OE-core] [meta-clang] clang/LLVM versioning

2017-03-03 Thread Khem Raj 
That's reasonable I think

On Fri, Mar 3, 2017 at 12:36 PM Martin Kelly  wrote:

> On 03/03/2017 12:23 PM, Khem Raj wrote:
> > On Fri, Mar 3, 2017 at 12:15 PM, Martin Kelly  wrote:
> >> On 03/03/2017 12:12 PM, Khem Raj wrote:
> >>>
> >>> with  meta-clang there is no desire to support multiple versions of
> >>> llvm and thats why versioning was dropped however, I would still like
> >>> to fix the versioning if that makes it more useful.
> >>>
> >>
> >> OK, keeping a single version is certainly simpler. Could you clarify "I
> >> would still like to fix the versioning if that makes it more useful." ?
> >>
> >
> > say if there are other apps which depend on the versioning and
> > otherwise would need patching to work with llvm from meta-clang, then
> > lets fix it in meta-clang.
> >
>
>  From my investigation, it looks like the real (unwrapped) llvm-config
> is in the PATH for any recipe depending on clang-native. This means that
> when an app looks for llvm-config, it will find the real version and
> won't know that the wrapper went anywhere. Of course, if the app truly
> depends on a specific LLVM version -- due to LLVM's unstable ABI -- then
> that app will break when the meta-clang version changes. However, if we
> don't maintain multiple versions of LLVM in meta-clang, that's unavoidable.
>
> So AFAICT we could safely remove the wrapper and have apps that set
> WANT_LLVM_RELEASE still work correctly, if they compile against our
> version of meta-clang. Since it appears the wrapper has been broken for
> for some time anyway, I'm guessing there aren't many such apps anyway.
>
> Does that sound reasonable to you?
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [meta-clang] clang/LLVM versioning

2017-03-03 Thread Martin Kelly 

On 03/03/2017 12:12 PM, Khem Raj wrote:

with  meta-clang there is no desire to support multiple versions of
llvm and thats why versioning was dropped however, I would still like
to fix the versioning if that makes it more useful.



OK, keeping a single version is certainly simpler. Could you clarify "I 
would still like to fix the versioning if that makes it more useful." ?


I may be missing something, but it seems like the llvm-config wrapper 
script's only job is to point to a versioned installed via 
WANT_LLVM_RELEASE. If that's the case, and if we don't intend to support 
multiple versions, wouldn't it be best simply to remove the wrapper? We 
could fix the wrapper instead, but I think that would have to involve 
reintroducing versioning.

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

Re: [OE-core] [meta-clang] clang/LLVM versioning

2017-03-03 Thread Martin Kelly 

On 03/03/2017 12:23 PM, Khem Raj wrote:

On Fri, Mar 3, 2017 at 12:15 PM, Martin Kelly  wrote:

On 03/03/2017 12:12 PM, Khem Raj wrote:


with  meta-clang there is no desire to support multiple versions of
llvm and thats why versioning was dropped however, I would still like
to fix the versioning if that makes it more useful.



OK, keeping a single version is certainly simpler. Could you clarify "I
would still like to fix the versioning if that makes it more useful." ?



say if there are other apps which depend on the versioning and
otherwise would need patching to work with llvm from meta-clang, then
lets fix it in meta-clang.



From my investigation, it looks like the real (unwrapped) llvm-config 
is in the PATH for any recipe depending on clang-native. This means that 
when an app looks for llvm-config, it will find the real version and 
won't know that the wrapper went anywhere. Of course, if the app truly 
depends on a specific LLVM version -- due to LLVM's unstable ABI -- then 
that app will break when the meta-clang version changes. However, if we 
don't maintain multiple versions of LLVM in meta-clang, that's unavoidable.


So AFAICT we could safely remove the wrapper and have apps that set 
WANT_LLVM_RELEASE still work correctly, if they compile against our 
version of meta-clang. Since it appears the wrapper has been broken for 
for some time anyway, I'm guessing there aren't many such apps anyway.


Does that sound reasonable to you?
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [meta-clang] clang/LLVM versioning

2017-03-03 Thread Martin Kelly 

Hi,

I'm attempting to build a recipe using the LLVM/clang cross toolchain 
provided in meta-clang. However, I'm hitting issues with the llvm-config 
wrapper in llvm-common. Specifically, it looks like the wrapper was 
copied over from the LLVM recipe in meta-oe, but the versioning logic 
was not updated, so when the wrapper attempts to exec the versioned 
llvm-config-${WANT_LLVM_RELEASE}, it fails. Notably, LLVM_RELEASE is not 
set in meta-clang/recipes-devtools/clang/clang.inc.


I'm looking into fixing the wrapper, but before I go too far down that 
path, I wanted to get clarification as to the intention of how 
versioning is handled in meta-clang. Specifically, the original LLVM 
recipe was clearly built to support multiple side-by-side LLVM versions 
on the same system. Do we have the same goal for meta-clang? IOW, should 
I make sure that the versioning logic works for meta-clang, or should we 
instead just abandon the versioning (and the wrapper) and support a 
single version of clang/LLVM?


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

Re: [OE-core] [meta-clang] clang/LLVM versioning

2017-03-03 Thread Khem Raj 
On Fri, Mar 3, 2017 at 12:15 PM, Martin Kelly  wrote:
> On 03/03/2017 12:12 PM, Khem Raj wrote:
>>
>> with  meta-clang there is no desire to support multiple versions of
>> llvm and thats why versioning was dropped however, I would still like
>> to fix the versioning if that makes it more useful.
>>
>
> OK, keeping a single version is certainly simpler. Could you clarify "I
> would still like to fix the versioning if that makes it more useful." ?
>

say if there are other apps which depend on the versioning and
otherwise would need patching to work with llvm from meta-clang, then
lets fix it in meta-clang.

> I may be missing something, but it seems like the llvm-config wrapper
> script's only job is to point to a versioned installed via
> WANT_LLVM_RELEASE. If that's the case, and if we don't intend to support
> multiple versions, wouldn't it be best simply to remove the wrapper? We
> could fix the wrapper instead, but I think that would have to involve
> reintroducing versioning.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [meta-clang] clang/LLVM versioning

2017-03-03 Thread Khem Raj 
On Fri, Mar 3, 2017 at 10:44 AM, Martin Kelly  wrote:
> Hi,
>
> I'm attempting to build a recipe using the LLVM/clang cross toolchain
> provided in meta-clang. However, I'm hitting issues with the llvm-config
> wrapper in llvm-common. Specifically, it looks like the wrapper was copied
> over from the LLVM recipe in meta-oe, but the versioning logic was not
> updated, so when the wrapper attempts to exec the versioned
> llvm-config-${WANT_LLVM_RELEASE}, it fails. Notably, LLVM_RELEASE is not set
> in meta-clang/recipes-devtools/clang/clang.inc.
>
> I'm looking into fixing the wrapper, but before I go too far down that path,
> I wanted to get clarification as to the intention of how versioning is
> handled in meta-clang. Specifically, the original LLVM recipe was clearly
> built to support multiple side-by-side LLVM versions on the same system. Do
> we have the same goal for meta-clang? IOW, should I make sure that the
> versioning logic works for meta-clang, or should we instead just abandon the
> versioning (and the wrapper) and support a single version of clang/LLVM?
>
with  meta-clang there is no desire to support multiple versions of
llvm and thats why versioning was dropped however, I would still like
to fix the versioning if that makes it more useful.

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

Re: [OE-core] [meta-clang] LLVM shared library support

2017-03-03 Thread Khem Raj 
On Fri, Mar 3, 2017 at 11:15 AM, Martin Kelly  wrote:
> Hi,
>
> I noticed that meta-clang builds only static LLVM libraries, unlike the
> meta-oe version of LLVM 3.3, which builds shared libraries. In fact, this
> appears to be the LLVM upstream default as well.
>
> What is the reason for the difference? Shared versions of LLVM would be
> useful for reducing the size of programs linked to it and making smaller
> filesystem images.

meta-clang has only provided static compiler thus far, so using shared
or static did not matter as much in fact it could be helping with
faster compile
times that we see with clang. However, there is no binding to keep it static
link. Feel free to send a pull request to change it.

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

Re: [OE-core] [PATCHv3 0/5] Add dummy tools to help identify needed dependencies

2017-03-03 Thread Peter Kjellerstedt 
> -Original Message-
> From: Max Krummenacher [mailto:max.oss...@gmail.com]
> Sent: den 3 mars 2017 17:24
> To: Peter Kjellerstedt
> Cc: OE-core
> Subject: Re: [OE-core] [PATCHv3 0/5] Add dummy tools to help identify
> needed dependencies
> 
> Hi
> 
> 2017-03-03 12:17 GMT+01:00 Peter Kjellerstedt
> :
> 
> > To circumvent this, I created dummy versions of the tools that always
> > fail and placed them in the scripts directory. Thus, if the real tool
> > has not been installed in the RSS, the dummy version is used and the
> > build fails. For good measures I even output a message that says what
> > needs to be corrected in the recipe.
> >
> > Included is also an update to linux-libc-headers as it apparently
> > needs to inherit pkgconfig, which the introduction of the dummy
> > version of pkg-config showed.
> >
> 
> I tried the whole series, i.e. applied on top of openembedded-core,
> 20c6e87 and bitbake 6fe07ed.
> 
> The resulting build failed in linux-libc-headers because it picked up
> the dummy script instead of the real pkg-config binary which actually
> is installed in the RSS.
> 
> run.do_configure has a PATH setting with first ...meta/scripts and
> only then the paths to the different RSS directories.
> 
> Changing that order in meta/conf/bitbake.conf line 450 fixed this for
> me, however I'm unsure of posible sideeffects of that reordering.
> 
> Max

Bah, you are correct. That is what I get for not testing exactly 
what I sent for integration. Shame on me.

Anyway, I see a couple of possible solutions:

* Put the scripts in bitbake/bin instead. This should work as it 
  is only added to $PATH by oe-buildenv-internal (contrary to 
  ${COREBASE}/scripts which is added to $PATH both by 
  oe-buildenv-internal and bitbake.conf). However, I do not like 
  this idea as it feels wrong to put them there.
* Put the scripts in a subdirectory of ${COREBASE}/scripts, e.g., 
  ${COREBASE}/scripts/blacklisted, and add that path to $PATH in 
  bitbake.conf, but at the other end of it so that the RSS paths 
  appear before it. This sounds a lot more appealing to me.
* Implement the whitelist solution Patrick Ohly mentioned instead.
  Although this is probably the best solution, prioritizing it 
  for 2.3 does not sound likely to happen.

I have implemented solution two above (properly tested this time), 
and will send that along in a little while.

//Peter

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

[OE-core] [meta-clang] LLVM shared library support

2017-03-03 Thread Martin Kelly 

Hi,

I noticed that meta-clang builds only static LLVM libraries, unlike the 
meta-oe version of LLVM 3.3, which builds shared libraries. In fact, 
this appears to be the LLVM upstream default as well.


What is the reason for the difference? Shared versions of LLVM would be 
useful for reducing the size of programs linked to it and making smaller 
filesystem images.


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

Re: [OE-core] [PATCHv3 0/5] Add dummy tools to help identify needed dependencies

2017-03-03 Thread Max Krummenacher 
Hi

2017-03-03 12:17 GMT+01:00 Peter Kjellerstedt :

> To circumvent this, I created dummy versions of the tools that always
> fail and placed them in the scripts directory. Thus, if the real tool
> has not been installed in the RSS, the dummy version is used and the
> build fails. For good measures I even output a message that says what
> needs to be corrected in the recipe.
>
> Included is also an update to linux-libc-headers as it apparently
> needs to inherit pkgconfig, which the introduction of the dummy
> version of pkg-config showed.
>

I tried the whole series, i.e. applied on top of openembedded-core,
20c6e87 and bitbake 6fe07ed.

The resulting build failed in linux-libc-headers because it picked up
the dummy script instead of the real pkg-config binary which actually
is installed in the RSS.

run.do_configure has a PATH setting with first ...meta/scripts and
only then the paths to the different RSS directories.

Changing that order in meta/conf/bitbake.conf line 450 fixed this for
me, however I'm unsure of posible sideeffects of that reordering.

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

Re: [OE-core] [PATCH 0/4] linux-yocto: kernel version updates

2017-03-03 Thread Burton, Ross 
On 3 March 2017 at 14:41, Burton, Ross  wrote:

> This appears to be causing cryptodev-module to fail:
> http://errors.yoctoproject.org/Errors/Details/134637/
>
> TOPDIR/tmp/work/qemux86_64-poky-linux/cryptodev-module/1.
> 8-r0/cryptodev-linux-1.8/zc.c:63:8: error: too few arguments to function
> 'get_user_pages_remote'
>   ret = get_user_pages_remote(
> ^
>

Never mind, found a fix upstream and sent a patch.

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

[OE-core] [PATCH] cryptodev: update to handle 4.10 kernel API

2017-03-03 Thread Ross Burton 
Signed-off-by: Ross Burton 
---
 meta/recipes-kernel/cryptodev/cryptodev.inc|  3 +-
 .../cryptodev/files/kernel-4-10-changes.patch  | 57 ++
 2 files changed, 59 insertions(+), 1 deletion(-)
 create mode 100644 
meta/recipes-kernel/cryptodev/files/kernel-4-10-changes.patch

diff --git a/meta/recipes-kernel/cryptodev/cryptodev.inc 
b/meta/recipes-kernel/cryptodev/cryptodev.inc
index 6241238..24b3227 100644
--- a/meta/recipes-kernel/cryptodev/cryptodev.inc
+++ b/meta/recipes-kernel/cryptodev/cryptodev.inc
@@ -6,7 +6,8 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263"
 SRC_URI = 
"http://download.gna.org/cryptodev-linux/cryptodev-linux-${PV}.tar.gz \
file://06d6b560c6e45dc317dae47c74706fa43f4a31d8.patch \
file://cb186f682679383e8b5806240927903730ce85d9.patch \
-   file://0001-Adjust-to-another-change-in-the-user-page-API.patch"
+   file://0001-Adjust-to-another-change-in-the-user-page-API.patch \
+   file://kernel-4-10-changes.patch"
 
 SRC_URI[md5sum] = "02644cc4cd02301e0b503a332eb2f0b5"
 SRC_URI[sha256sum] = 
"67fabde9fb67b286a96c4f45b594b0eccd0f761b495705c18f2ae9461b831376"
diff --git a/meta/recipes-kernel/cryptodev/files/kernel-4-10-changes.patch 
b/meta/recipes-kernel/cryptodev/files/kernel-4-10-changes.patch
new file mode 100644
index 000..93d608b
--- /dev/null
+++ b/meta/recipes-kernel/cryptodev/files/kernel-4-10-changes.patch
@@ -0,0 +1,57 @@
+Upstream-Status: Backport
+Signed-off-by: Ross Burton 
+
+From 2b29be8ac41414ed19cb4f5d5626d9bd0d7b11a8 Mon Sep 17 00:00:00 2001
+From: Cristian Stoica 
+Date: Wed, 8 Feb 2017 12:11:04 +0200
+Subject: [PATCH] adjust to API changes in kernel >=4.10
+
+There are many changes related to get_user_pages and the code is rewritten
+for clarity.
+
+Signed-off-by: Cristian Stoica 
+---
+ zc.c | 28 +---
+ 1 file changed, 17 insertions(+), 11 deletions(-)
+
+diff --git a/zc.c b/zc.c
+index e766ee3..2f4ea99 100644
+--- a/zc.c
 b/zc.c
+@@ -59,19 +59,25 @@ int __get_userbuf(uint8_t __user *addr, uint32_t len, int 
write,
+   }
+ 
+   down_read(>mmap_sem);
+-#if (LINUX_VERSION_CODE >= KERNEL_VERSION(4, 6, 0))
+-  ret = get_user_pages_remote(
++#if (LINUX_VERSION_CODE < KERNEL_VERSION(4, 6, 0))
++  ret = get_user_pages(task, mm,
++  (unsigned long)addr, pgcount, write, 0, pg, NULL);
+ #else
+-  ret = get_user_pages(
+-#endif
+-  task, mm,
+-  (unsigned long)addr, pgcount,
+-#if (LINUX_VERSION_CODE >= KERNEL_VERSION(4, 9, 0))
+-  write ? FOLL_WRITE : 0,
+-#else
+-  write, 0,
+-#endif
++#  if (LINUX_VERSION_CODE < KERNEL_VERSION(4, 9, 0))
++  ret = get_user_pages_remote(task, mm,
++  (unsigned long)addr, pgcount, write, 0, pg, NULL);
++#  else
++#if (LINUX_VERSION_CODE < KERNEL_VERSION(4, 10, 0))
++  ret = get_user_pages_remote(task, mm,
++  (unsigned long)addr, pgcount, write ? FOLL_WRITE : 0,
+   pg, NULL);
++#else
++  ret = get_user_pages_remote(task, mm,
++  (unsigned long)addr, pgcount, write ? FOLL_WRITE : 0,
++  pg, NULL, NULL);
++#endif
++#  endif
++#endif
+   up_read(>mmap_sem);
+   if (ret != pgcount)
+   return -EINVAL;
-- 
2.8.1

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

Re: [OE-core] [PATCH 0/4] linux-yocto: kernel version updates

2017-03-03 Thread Burton, Ross 
Hi Bruce,

On 27 February 2017 at 03:10, Bruce Ashfield 
wrote:
> Here is the latest updates to the linux-yocto kernel versions, and
represents
> the versions that we'd like to be included in the upcoming release.

This appears to be causing cryptodev-module to fail:
http://errors.yoctoproject.org/Errors/Details/134637/

TOPDIR/tmp/work/qemux86_64-poky-linux/cryptodev-module/1.8-r0/cryptodev-linux-1.8/zc.c:63:8:
error: too few arguments to function 'get_user_pages_remote'
  ret = get_user_pages_remote(
^

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

[OE-core] [PATCH v4] deprecated.bbclass: Add a PNDEPRECATED variable for recipes

2017-03-03 Thread Joe MacDonald 
Based on the blacklist behaviour, recipes can be tagged as deprecated.
Such recipes will produce a warning message when included in a build but
unlike blacklisted recipes, the build will continue.

Signed-off-by: Joe MacDonald 
---

Literally no different than v1, differs from v3 in that the doccumentation for
PNDEPRECATED has been removed again, since updates to documentation have to go
to a different list.

 meta/classes/deprecated.bbclass| 16 
 meta/conf/distro/defaultsetup.conf |  3 ++-
 2 files changed, 18 insertions(+), 1 deletion(-)
 create mode 100644 meta/classes/deprecated.bbclass

diff --git a/meta/classes/deprecated.bbclass b/meta/classes/deprecated.bbclass
new file mode 100644
index 000..3dcdadb
--- /dev/null
+++ b/meta/classes/deprecated.bbclass
@@ -0,0 +1,16 @@
+# To use the deprecated recipe check, a distribution should
+# include this class in the INHERIT_DISTRO
+#
+# Features:
+#
+# * To add a package to the deprecated list, set:
+#   PNDEPRECATED[pn] = "message"
+#
+
+addtask check_deprecated before do_fetch
+python do_check_deprecated () {
+deprecated = d.getVarFlag('PNDEPRECATED', d.getVar('PN', True), False)
+
+if deprecated:
+bb.warn("Recipe is deprecated: ", (deprecated))
+}
diff --git a/meta/conf/distro/defaultsetup.conf 
b/meta/conf/distro/defaultsetup.conf
index ca2f917..16ece3a 100644
--- a/meta/conf/distro/defaultsetup.conf
+++ b/meta/conf/distro/defaultsetup.conf
@@ -20,5 +20,6 @@ CACHE = "${TMPDIR}/cache/${TCMODE}-${TCLIBC}${@['', '/' + 
str(d.getVar('MACHINE'
 USER_CLASSES ?= ""
 PACKAGE_CLASSES ?= "package_ipk"
 INHERIT_BLACKLIST = "blacklist"
+INHERIT_DEPRECATED = "deprecated"
 INHERIT_DISTRO ?= "debian devshell sstate license remove-libtool"
-INHERIT += "${PACKAGE_CLASSES} ${USER_CLASSES} ${INHERIT_DISTRO} 
${INHERIT_BLACKLIST}"
+INHERIT += "${PACKAGE_CLASSES} ${USER_CLASSES} ${INHERIT_DISTRO} 
${INHERIT_BLACKLIST} ${INHERIT_DEPRECATED}"
-- 
1.9.1

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

Re: [OE-core] [PATCH] wic: Prevent duplicate entries on fstab

2017-03-03 Thread Burton, Ross 
On 3 March 2017 at 12:12, Fabio Berton 
wrote:

> Sorry for delay. This error for qemux86 is because common.wks.inc and
> directdisk-gpt.wks files in scripts/lib/wic/canned-wks directory doesn't
> have option --fstype= for part /boot.
>
> For qemuarm machines I get the error:
>
> | DEBUG: Executing python function set_image_size
> | DEBUG: Python function set_image_size finished
> | DEBUG: Executing shell function do_image_wic
> | Error: Please build syslinux first
>

There's patches queued that will change the behaviour here and likely cause
your patch to not apply - can you rebase on top of poky-contrib:ed/wic/wip
and see what happens?  The build dependency is now wic-tools.

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

[OE-core] [morty][PATCH 3/4] lib/oe/gpg_sign: make gpg version a property of the signer

2017-03-03 Thread Markus Lehtonen 
Signed-off-by: Markus Lehtonen 
Signed-off-by: Ross Burton 
(cherry picked from commit a00a362e3dc18ba04230cbbd6f91264e5d76f40d)
---
 meta/lib/oe/gpg_sign.py | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/meta/lib/oe/gpg_sign.py b/meta/lib/oe/gpg_sign.py
index 683ae5b..16eb7f8 100644
--- a/meta/lib/oe/gpg_sign.py
+++ b/meta/lib/oe/gpg_sign.py
@@ -10,6 +10,7 @@ class LocalSigner(object):
 self.gpg_bin = d.getVar('GPG_BIN', True) or \
   bb.utils.which(os.getenv('PATH'), 'gpg')
 self.gpg_path = d.getVar('GPG_PATH', True)
+self.gpg_version = self.get_gpg_version()
 self.rpm_bin = bb.utils.which(os.getenv('PATH'), "rpm")
 
 def export_pubkey(self, output_file, keyid, armor=True):
@@ -59,9 +60,7 @@ class LocalSigner(object):
 
 #gpg > 2.1 supports password pipes only through the loopback interface
 #gpg < 2.1 errors out if given unknown parameters
-dots = self.get_gpg_version().split('.')
-assert len(dots) >= 2
-if int(dots[0]) >= 2 and int(dots[1]) >= 1:
+if self.gpg_version > (2,1,):
 cmd += ['--pinentry-mode', 'loopback']
 
 cmd += [input_file]
@@ -88,10 +87,11 @@ class LocalSigner(object):
 
 
 def get_gpg_version(self):
-"""Return the gpg version"""
+"""Return the gpg version as a tuple of ints"""
 import subprocess
 try:
-return subprocess.check_output((self.gpg_bin, 
"--version")).split()[2].decode("utf-8")
+ver_str = subprocess.check_output((self.gpg_bin, 
"--version")).split()[2].decode("utf-8")
+return tuple([int(i) for i in ver_str.split('.')])
 except subprocess.CalledProcessError as e:
 raise bb.build.FuncFailed("Could not get gpg version: %s" % e)
 
-- 
2.6.6

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

[OE-core] [morty][PATCH 1/4] lib/oe/gpg_sign: sign rpm packages in chunks of 100

2017-03-03 Thread Markus Lehtonen 
Split the file list into chunks in order to avoid
"OSError: [Errno 7] Argument list too long"

This would happend when a package has huge amount of subpackages, e.g.
glibc-locale.

[YOCTO #11069]

Signed-off-by: Markus Lehtonen 
Signed-off-by: Ross Burton 
(cherry picked from commit 874f5016fd4dc76bc867b68470297fe59e78a9e6)
---
 meta/lib/oe/gpg_sign.py | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/meta/lib/oe/gpg_sign.py b/meta/lib/oe/gpg_sign.py
index 38eb0cb..683ae5b 100644
--- a/meta/lib/oe/gpg_sign.py
+++ b/meta/lib/oe/gpg_sign.py
@@ -35,11 +35,12 @@ class LocalSigner(object):
 cmd += "--define '%%__gpg %s' " % self.gpg_bin
 if self.gpg_path:
 cmd += "--define '_gpg_path %s' " % self.gpg_path
-cmd += ' '.join(files)
 
-status, output = oe.utils.getstatusoutput(cmd)
-if status:
-raise bb.build.FuncFailed("Failed to sign RPM packages: %s" % 
output)
+# Sign in chunks of 100 packages
+for i in range(0, len(files), 100):
+status, output = oe.utils.getstatusoutput(cmd + ' 
'.join(files[i:i+100]))
+if status:
+raise bb.build.FuncFailed("Failed to sign RPM packages: %s" % 
output)
 
 def detach_sign(self, input_file, keyid, passphrase_file, passphrase=None, 
armor=True):
 """Create a detached signature of a file"""
-- 
2.6.6

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

[OE-core] [morty][PATCH 0/4] rpm signing fixes

2017-03-03 Thread Markus Lehtonen 
This patchset backports two fixes to gpg signing of rpm packages. The first
patch fixes signing of packages with a large amount of subpackages (e.g.
glibc-locale). The last three patches makes rpm package signing possible with
gpg version > 2.1.


The following changes since commit 55c835c73cc41b6fc809c941c295d62a612e49e0:

  build-appliance-image: Update to morty head revision (2017-02-08 12:00:29 
+)

are available in the git repository at:

  git://git.openembedded.org/openembedded-core-contrib marquiz/morty
  http://git.openembedded.org/openembedded-core-contrib/log/?h=marquiz/morty


Markus Lehtonen (4):
  lib/oe/gpg_sign: sign rpm packages in chunks of 100
  rpm: support customizing gpg command line
  lib/oe/gpg_sign: make gpg version a property of the signer
  lib/oe/gpg_sign: fix rpm signing with gpg > 2.1

 meta/lib/oe/gpg_sign.py| 21 ++-
 .../0001-macros-add-_gpg_sign_cmd_extra_args.patch | 43 ++
 meta/recipes-devtools/rpm/rpm_5.4.16.bb|  1 +
 3 files changed, 56 insertions(+), 9 deletions(-)
 create mode 100644 
meta/recipes-devtools/rpm/rpm/0001-macros-add-_gpg_sign_cmd_extra_args.patch

-- 
2.6.6

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

[OE-core] [morty][PATCH 4/4] lib/oe/gpg_sign: fix rpm signing with gpg > 2.1

2017-03-03 Thread Markus Lehtonen 
We need to check the gpg version and alter its command line options
accordingly.

[YOCTO #11054]

Signed-off-by: Markus Lehtonen 
Signed-off-by: Ross Burton 
(cherry picked from commit 44a44b7e582a5a654baf21829d168568481c13d9)
---
 meta/lib/oe/gpg_sign.py | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/lib/oe/gpg_sign.py b/meta/lib/oe/gpg_sign.py
index 16eb7f8..ba61f98 100644
--- a/meta/lib/oe/gpg_sign.py
+++ b/meta/lib/oe/gpg_sign.py
@@ -32,6 +32,8 @@ class LocalSigner(object):
 
 cmd = self.rpm_bin + " --addsign --define '_gpg_name %s'  " % keyid
 cmd += "--define '_gpg_passphrase %s' " % passphrase
+if self.gpg_version > (2,1,):
+cmd += "--define '_gpg_sign_cmd_extra_args 
--pinentry-mode=loopback' "
 if self.gpg_bin:
 cmd += "--define '%%__gpg %s' " % self.gpg_bin
 if self.gpg_path:
-- 
2.6.6

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

[OE-core] [morty][PATCH 2/4] rpm: support customizing gpg command line

2017-03-03 Thread Markus Lehtonen 
Add a new %_gpg_sign_cmd_extra_args macro that allows customizing the
gpg options used when signing rpm packages. This is needed to be able to
sign packages with gpg 2.1 which requires "--pinentry-mode loopback" to
allow non-interactive signing.

[YOCTO #11054]

Signed-off-by: Markus Lehtonen 
Signed-off-by: Ross Burton 
(cherry picked from commit 373a7146d596d27376a003014df0d06f3df5348d)
---
 .../0001-macros-add-_gpg_sign_cmd_extra_args.patch | 43 ++
 meta/recipes-devtools/rpm/rpm_5.4.16.bb|  1 +
 2 files changed, 44 insertions(+)
 create mode 100644 
meta/recipes-devtools/rpm/rpm/0001-macros-add-_gpg_sign_cmd_extra_args.patch

diff --git 
a/meta/recipes-devtools/rpm/rpm/0001-macros-add-_gpg_sign_cmd_extra_args.patch 
b/meta/recipes-devtools/rpm/rpm/0001-macros-add-_gpg_sign_cmd_extra_args.patch
new file mode 100644
index 000..eb43a87
--- /dev/null
+++ 
b/meta/recipes-devtools/rpm/rpm/0001-macros-add-_gpg_sign_cmd_extra_args.patch
@@ -0,0 +1,43 @@
+From fa9726ff69f86d6a87c4c4bd7e3d2881999a872a Mon Sep 17 00:00:00 2001
+From: Markus Lehtonen 
+Date: Thu, 23 Feb 2017 11:14:20 +0200
+Subject: [PATCH] macros: add %_gpg_sign_cmd_extra_args
+
+Similar to what rpm4 has. This macro can be used to customize the
+gpg command line options when signing packages. This is needed for
+gpg 2.1 which requires "--pinentry-mode loopback" to allow
+non-interactive signing.
+
+Upstream-Status: Pending
+
+Signed-off-by: Markus Lehtonen 
+---
+ macros/macros.in | 5 -
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+diff --git a/macros/macros.in b/macros/macros.in
+index 8bc5840..fda3c66 100644
+--- a/macros/macros.in
 b/macros/macros.in
+@@ -524,7 +524,9 @@ $_arbitrary_tags_tests Foo:Bar
+ %_gpg_passphrase_way %{?_gpg_passphrase:--passphrase 
"%{_gpg_passphrase}"}%{!?_gpg_passphrase:--passphrase-fd 3}
+ 
+ %__gpg_check_password_cmd %{__gpg} \
+-  gpg --batch --no-verbose %{_gpg_passphrase_way} -u "%{_gpg_name}" -so -
++  gpg --batch --no-verbose %{_gpg_passphrase_way} \
++  %{?_gpg_sign_cmd_extra_args:%{_gpg_sign_cmd_extra_args}} \
++  -u "%{_gpg_name}" -so -
+ #%__pgp_check_password_cmd%{__pgp} \
+ # pgp +batchmode=on +verbose=0 "%{_pgp_name}" -sf
+ #%__pgp5_check_password_cmd   %{__pgp} \
+@@ -532,6 +534,7 @@ $_arbitrary_tags_tests Foo:Bar
+ 
+ %__gpg_sign_cmd   %{__gpg} \
+   gpg --batch --no-verbose --no-armor %{_gpg_passphrase_way}  
--no-secmem-warning \
++  %{?_gpg_sign_cmd_extra_args:%{_gpg_sign_cmd_extra_args}} \
+   -u "%{_gpg_name}" -sbo %{__signature_filename} %{__plaintext_filename}
+ #%__pgp_sign_cmd  %{__pgp} \
+ # pgp +batchmode=on +verbose=0 +armor=off \
+-- 
+2.10.2
+
diff --git a/meta/recipes-devtools/rpm/rpm_5.4.16.bb 
b/meta/recipes-devtools/rpm/rpm_5.4.16.bb
index 85eb5fe..497af8e 100644
--- a/meta/recipes-devtools/rpm/rpm_5.4.16.bb
+++ b/meta/recipes-devtools/rpm/rpm_5.4.16.bb
@@ -119,6 +119,7 @@ SRC_URI += " \
   file://gcc6-stdlib.patch \
   file://0001-system.h-query.c-support-nosignature.patch \
   file://rpm-ensure-rpm2cpio-call-rpm-relocation-code.patch \
+  file://0001-macros-add-_gpg_sign_cmd_extra_args.patch \
 "
 
 # OE specific changes
-- 
2.6.6

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

[OE-core] [OE-Core][PATCH v3] lsb: Make use of appropriate bitbake variables.

2017-03-03 Thread Amarnath Valluri 
Using of bitbake environment variables in-place of hardcoded strings makes this
recipe portable to all environments.

Signed-off-by: Amarnath Valluri 
---
 meta/recipes-extended/lsb/lsb_4.1.bb | 40 +---
 1 file changed, 19 insertions(+), 21 deletions(-)

diff --git a/meta/recipes-extended/lsb/lsb_4.1.bb 
b/meta/recipes-extended/lsb/lsb_4.1.bb
index b4e8832..39cb544 100644
--- a/meta/recipes-extended/lsb/lsb_4.1.bb
+++ b/meta/recipes-extended/lsb/lsb_4.1.bb
@@ -34,14 +34,13 @@ S = "${WORKDIR}/lsb-release-1.4"
 CLEANBROKEN = "1"
 
 do_install(){
-   oe_runmake install prefix=${D}  mandir=${D}/${datadir}/man/ DESTDIR=${D}
+   oe_runmake install prefix=${D}/${base_prefix}  
mandir=${D}/${datadir}/man/ DESTDIR=${D}
 
# this 2 dirs are needed by package lsb-dist-checker
mkdir -p ${D}${sysconfdir}/opt
mkdir -p ${D}${localstatedir}/opt
 
-   mkdir -p ${D}${base_bindir}
-   mkdir -p ${D}/${baselib}
+   mkdir -p ${D}${base_libdir}
mkdir -p ${D}${sysconfdir}/lsb-release.d
printf "LSB_VERSION=\"core-4.1-noarch:" > ${D}${sysconfdir}/lsb-release
 
@@ -87,47 +86,46 @@ do_install_append(){
install -m 0755 ${WORKDIR}/${i} ${D}${sysconfdir}/core-lsb
done
 
-   install -d ${D}/lib/lsb
-   install -m 0755 ${WORKDIR}/init-functions ${D}/lib/lsb
+   install -d ${D}/${nonarch_base_libdir}/lsb
+   install -m 0755 ${WORKDIR}/init-functions 
${D}/${nonarch_base_libdir}/lsb
 
# creat links for LSB test
-   install -d ${D}/usr/lib/lsb
-   ln -sf ${sbindir}/chkconfig ${D}/usr/lib/lsb/install_initd
-   ln -sf ${sbindir}/chkconfig ${D}/usr/lib/lsb/remove_initd
+   if [ "${nonarch_base_libdir}" != "${nonarch_libdir}" ] ; then
+   install -d ${D}/${nonarch_libdir}/lsb
+   fi
+   ln -sf ${sbindir}/chkconfig ${D}/${nonarch_libdir}/lsb/install_initd
+   ln -sf ${sbindir}/chkconfig ${D}/${nonarch_libdir}/lsb/remove_initd
 
if [ "${TARGET_ARCH}" = "x86_64" ];then
-  cd ${D}
if [ "${baselib}" != "lib64" ]; then
-   ln -sf ${baselib} lib64
+   lnr ${D}${base_libdir} ${D}/lib64
fi
-  cd ${D}/${baselib}
+  cd ${D}/${base_libdir}
ln -sf ld-linux-x86-64.so.2 ld-lsb-x86-64.so.2
ln -sf ld-linux-x86-64.so.2 ld-lsb-x86-64.so.3
fi
if [ "${TARGET_ARCH}" = "i586" ] || [ "${TARGET_ARCH}" = "i686" ];then
-  cd ${D}/${baselib}
+  cd ${D}/${base_libdir}
ln -sf ld-linux.so.2 ld-lsb.so.2
ln -sf ld-linux.so.2 ld-lsb.so.3
fi
 
if [ "${TARGET_ARCH}" = "powerpc64" ];then
-   cd ${D}
if [ "${baselib}" != "lib64" ]; then
-   ln -sf ${baselib} lib64
+   lnr  ${D}${base_libdir} ${D}/lib64
fi
-   cd ${D}/${baselib}
+   cd ${D}/${base_libdir}
ln -sf ld64.so.1 ld-lsb-ppc64.so.2
ln -sf ld64.so.1 ld-lsb-ppc64.so.3
fi
if [ "${TARGET_ARCH}" = "powerpc" ];then
-  cd ${D}/${baselib}
+  cd ${D}/${base_libdir}
ln -sf ld.so.1 ld-lsb-ppc32.so.2
ln -sf ld.so.1 ld-lsb-ppc32.so.3
fi
 }
-FILES_${PN} += "/lib64 \
+FILES_${PN} += "${@'/lib64' if d.getVar('TARGET_ARCH')  == ('x86_64' or 
'powerpc64') and '${baselib}' != 'lib64' else ''} \
 ${base_libdir} \
-/usr/lib/lsb \
-${base_libdir}/lsb/* \
-/lib/lsb/* \
-   "
+${nonarch_libdir}/lsb \
+${nonarch_base_libdir}/lsb/* \
+"
-- 
2.7.4

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

[OE-core] [OE-Core[[PATCH v3 19/25] mdadm: Avoid using hardocded sbin path

2017-03-03 Thread Amarnath Valluri 
Use appropriate bitbake variable inplace of hardcoded sbin path in Makefile

Signed-off-by: Amarnath Valluri 
---
 meta/recipes-extended/mdadm/mdadm_4.0.bb | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-extended/mdadm/mdadm_4.0.bb 
b/meta/recipes-extended/mdadm/mdadm_4.0.bb
index c228899..62614f0 100644
--- a/meta/recipes-extended/mdadm/mdadm_4.0.bb
+++ b/meta/recipes-extended/mdadm/mdadm_4.0.bb
@@ -33,6 +33,8 @@ CFLAGS_append_mipsarchn64 = ' -D__SANE_USERSPACE_TYPES__'
 CFLAGS_append_mipsarchn32 = ' -D__SANE_USERSPACE_TYPES__'
 
 do_compile() {
+   # Point to right sbindir
+   sed -i -e "s;BINDIR  = /sbin;BINDIR = $base_sbindir;" ${S}/Makefile
oe_runmake SYSROOT="${STAGING_DIR_TARGET}"
 }
 
@@ -51,7 +53,7 @@ do_install_ptest() {
cp -a ${S}/tests ${D}${PTEST_PATH}/tests
cp ${S}/test ${D}${PTEST_PATH}
sed -e 's!sleep 0.*!sleep 1!g; s!/var/tmp!/!g' -i ${D}${PTEST_PATH}/test
-   ln -s /sbin/mdadm ${D}${PTEST_PATH}/mdadm
+   ln -s ${base_sbindir}/mdadm ${D}${PTEST_PATH}/mdadm
for prg in test_stripe swap_super raid6check
do
install -D -m 755 $prg ${D}${PTEST_PATH}/
-- 
2.7.4

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

Re: [OE-core] [PATCH] wic: Prevent duplicate entries on fstab

2017-03-03 Thread Fabio Berton 

Hi Ross,

Sorry for delay. This error for qemux86 is because common.wks.inc and 
directdisk-gpt.wks files in scripts/lib/wic/canned-wks directory doesn't 
have option --fstype= for part /boot.


For qemuarm machines I get the error:

| DEBUG: Executing python function set_image_size
| DEBUG: Python function set_image_size finished
| DEBUG: Executing shell function do_image_wic
| Error: Please build syslinux first

On 02/24/2017 08:02 PM, Burton, Ross wrote:


On 23 February 2017 at 18:13, Fabio Berton 
> 
wrote:

>
> Add function to read fstab and return all mount points. This function
> is useful to _update_fstab doesn't duplicate entries in /etc/fstab.


The AB just failed all over with this error message:

| Traceback (most recent call last):
|   File 
"/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-x86/build/scripts/wic", 
line 327, in 

| sys.exit(main(sys.argv[1:]))
|   File 
"/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-x86/build/scripts/wic", 
line 322, in main
| return hlp.invoke_subcommand(args, parser, hlp.wic_help_usage, 
subcommands)
|   File 
"/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-x86/build/scripts/lib/wic/help.py", 
line 95, in invoke_subcommand

| subcommands.get(args[0], subcommand_error)[0](args[1:], usage)
|   File 
"/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-x86/build/scripts/wic", 
line 255, in wic_create_subcommand

| native_sysroot, options)
|   File 
"/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-x86/build/scripts/lib/wic/engine.py", 
line 199, in wic_create

| plugin.do_create()
|   File 
"/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-x86/build/scripts/lib/wic/plugins/imager/direct.py", 
line 93, in do_create

| self.create()
|   File 
"/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-x86/build/scripts/lib/wic/plugins/imager/direct.py", 
line 176, in create

| fstab_path = self._write_fstab(self.rootfs_dir.get("ROOTFS_DIR"))
|   File 
"/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-x86/build/scripts/lib/wic/plugins/imager/direct.py", 
line 134, in _write_fstab

| if self._update_fstab(fstab_lines, self.parts):
|   File 
"/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-x86/build/scripts/lib/wic/plugins/imager/direct.py", 
line 156, in _update_fstab

| opts, "0", "0"]) + "\n"
| TypeError: sequence item 2: expected str instance, NoneType found

Ross


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

[OE-core] [PATCH] gcc-runtime: Add libmpx supprt for x86

2017-03-03 Thread Richard Purdie 
Enabling building the Intel Memory Protection Extension library for x86.

Signed-off-by: Richard Purdie 
---
 meta/recipes-devtools/gcc/gcc-runtime.inc | 20 +++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/gcc/gcc-runtime.inc 
b/meta/recipes-devtools/gcc/gcc-runtime.inc
index 745cf74..614b070 100644
--- a/meta/recipes-devtools/gcc/gcc-runtime.inc
+++ b/meta/recipes-devtools/gcc/gcc-runtime.inc
@@ -24,8 +24,8 @@ RUNTIMELIBITM_microblaze = ""
 RUNTIMETARGET = "libssp libstdc++-v3 libgomp libatomic ${RUNTIMELIBITM} \
 ${@bb.utils.contains_any('FORTRAN', [',fortran',',f77'], 'libquadmath', 
'', d)} \
 "
+RUNTIMETARGET_append_x86 = " libmpx"
 
-#  ?
 # libiberty
 # libmudflap
 # libgfortran needs separate recipe due to libquadmath dependency
@@ -139,6 +139,11 @@ PACKAGES = "\
 libitm-dev \
 libitm-staticdev \
 "
+PACKAGES_append_x86 = "\
+libmpx \
+libmpx-dev \
+libmpx-staticdev \
+"
 
 # The base package doesn't exist, so we clear the recommends.
 RRECOMMENDS_${PN}-dbg = ""
@@ -243,6 +248,19 @@ SUMMARY_libitm-dev = "GNU transactional memory support 
library - development fil
 FILES_libitm-staticdev = "${libdir}/libitm.a"
 SUMMARY_libitm-staticdev = "GNU transactional memory support library - static 
development files"
 
+
+FILES_libmpx = "${libdir}/libmpx.so.* ${libdir}/libmpxwrappers.so.*"
+SUMMARY_libmpx = "Intel Memory Protection Extension library"
+FILES_libmpx-dev = "\
+${libdir}/libmpxwrappers.so \
+${libdir}/libmpx.so \
+${libdir}/libmpx.la \
+${libdir}/libmpx.spec \
+"
+SUMMARY_libmpx-dev = "Intel Memory Protection Extension library - development 
files"
+FILES_libmpx-staticdev = "${libdir}/libmpx.a ${libdir}/libmpxwrappers.a"
+SUMMARY_libmpx-staticdev = "Intel Memory Protection Extension library - static 
development files"
+
 do_package_write_ipk[depends] += "virtual/${MLPREFIX}libc:do_packagedata"
 do_package_write_deb[depends] += "virtual/${MLPREFIX}libc:do_packagedata"
 do_package_write_rpm[depends] += "virtual/${MLPREFIX}libc:do_packagedata"
-- 
2.7.4

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

[OE-core] [PATCH] perf.bb: Fix dependency while building kernel using externalsrc

2017-03-03 Thread Manjukumar Matha 
Having dependency on do_patch will fail while building kernel using
externalsrc. Depend on do_configure instead of do_patch to bypass the
compilation error.

Signed-off-by: Manjukumar Matha 
---
 meta/classes/kernelsrc.bbclass   | 2 +-
 meta/recipes-kernel/perf/perf.bb | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/classes/kernelsrc.bbclass b/meta/classes/kernelsrc.bbclass
index 675d40e..35cf49e 100644
--- a/meta/classes/kernelsrc.bbclass
+++ b/meta/classes/kernelsrc.bbclass
@@ -1,7 +1,7 @@
 S = "${STAGING_KERNEL_DIR}"
 deltask do_fetch
 deltask do_unpack
-do_patch[depends] += "virtual/kernel:do_patch"
+do_patch[depends] += "virtual/kernel:do_configure"
 do_patch[noexec] = "1"
 do_package[depends] += "virtual/kernel:do_populate_sysroot"
 KERNEL_VERSION = "${@get_kernelversion_file("${STAGING_KERNEL_BUILDDIR}")}"
diff --git a/meta/recipes-kernel/perf/perf.bb b/meta/recipes-kernel/perf/perf.bb
index ffaa5f6..b13f8e4 100644
--- a/meta/recipes-kernel/perf/perf.bb
+++ b/meta/recipes-kernel/perf/perf.bb
@@ -45,7 +45,7 @@ export PYTHON_SITEPACKAGES_DIR
 #kernel 3.1+ supports WERROR to disable warnings as errors
 export WERROR = "0"
 
-do_populate_lic[depends] += "virtual/kernel:do_patch"
+do_populate_lic[depends] += "virtual/kernel:do_configure"
 
 # needed for building the tools/perf Perl binding
 inherit perlnative cpan-base
-- 
2.7.4

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

[OE-core] [PATCH 2/2] Qemu: display: CVE-2016-9912

2017-03-03 Thread Sona Sarmadi 
virtio-gpu: memory leakage when destroying gpu resource

Reference:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-9912

Reference to upstream patch:
http://git.qemu-project.org/?p=qemu.git;a=patch;h=b8e23926c568f2e963af39028b71c472e3023793

Signed-off-by: Sona Sarmadi 
---
 .../recipes-devtools/qemu/qemu/CVE-2016-9912.patch | 45 ++
 meta/recipes-devtools/qemu/qemu_2.8.0.bb   |  1 +
 2 files changed, 46 insertions(+)
 create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2016-9912.patch

diff --git a/meta/recipes-devtools/qemu/qemu/CVE-2016-9912.patch 
b/meta/recipes-devtools/qemu/qemu/CVE-2016-9912.patch
new file mode 100644
index 000..c009ffd
--- /dev/null
+++ b/meta/recipes-devtools/qemu/qemu/CVE-2016-9912.patch
@@ -0,0 +1,45 @@
+From b8e23926c568f2e963af39028b71c472e3023793 Mon Sep 17 00:00:00 2001
+From: Li Qiang 
+Date: Mon, 28 Nov 2016 21:29:25 -0500
+Subject: [PATCH] virtio-gpu: call cleanup mapping function in resource destroy
+
+If the guest destroy the resource before detach banking, the 'iov'
+and 'addrs' field in resource is not freed thus leading memory
+leak issue. This patch avoid this.
+
+CVE: CVE-2016-9912
+Upstream-Status: Backport
+
+Signed-off-by: Li Qiang 
+Reviewed-by: Marc-André Lureau 
+Message-id: 1480386565-10077-1-git-send-email-liq...@gmail.com
+Signed-off-by: Gerd Hoffmann 
+Signed-off-by: Sona Sarmadi 
+---
+ hw/display/virtio-gpu.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/hw/display/virtio-gpu.c b/hw/display/virtio-gpu.c
+index ed2b6d3..6a26258 100644
+--- a/hw/display/virtio-gpu.c
 b/hw/display/virtio-gpu.c
+@@ -28,6 +28,8 @@
+ static struct virtio_gpu_simple_resource*
+ virtio_gpu_find_resource(VirtIOGPU *g, uint32_t resource_id);
+ 
++static void virtio_gpu_cleanup_mapping(struct virtio_gpu_simple_resource 
*res);
++
+ #ifdef CONFIG_VIRGL
+ #include 
+ #define VIRGL(_g, _virgl, _simple, ...) \
+@@ -364,6 +366,7 @@ static void virtio_gpu_resource_destroy(VirtIOGPU *g,
+ struct virtio_gpu_simple_resource 
*res)
+ {
+ pixman_image_unref(res->image);
++virtio_gpu_cleanup_mapping(res);
+ QTAILQ_REMOVE(>reslist, res, next);
+ g->hostmem -= res->hostmem;
+ g_free(res);
+-- 
+1.9.1
+
diff --git a/meta/recipes-devtools/qemu/qemu_2.8.0.bb 
b/meta/recipes-devtools/qemu/qemu_2.8.0.bb
index 75928c6..d0f9fab 100644
--- a/meta/recipes-devtools/qemu/qemu_2.8.0.bb
+++ b/meta/recipes-devtools/qemu/qemu_2.8.0.bb
@@ -18,6 +18,7 @@ SRC_URI += " \
 
file://0003-Introduce-condition-in-TPM-backend-for-notification.patch \
 file://0004-Add-support-for-VM-suspend-resume-for-TPM-TIS.patch \
 file://CVE-2016-9908.patch \
+file://CVE-2016-9912.patch \
 "
 
 SRC_URI =+ "http://wiki.qemu-project.org/download/${BP}.tar.bz2;
-- 
2.7.4

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

[OE-core] [PATCH 1/2] Qemu: display: CVE-2016-9908

2017-03-03 Thread Sona Sarmadi 
virtio-gpu: information leakage in virgl_cmd_get_capset

References:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-9908

Signed-off-by: Sona Sarmadi 
---
 .../recipes-devtools/qemu/qemu/CVE-2016-9908.patch | 44 ++
 meta/recipes-devtools/qemu/qemu_2.8.0.bb   |  1 +
 2 files changed, 45 insertions(+)
 create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2016-9908.patch

diff --git a/meta/recipes-devtools/qemu/qemu/CVE-2016-9908.patch 
b/meta/recipes-devtools/qemu/qemu/CVE-2016-9908.patch
new file mode 100644
index 000..e0f7a1a
--- /dev/null
+++ b/meta/recipes-devtools/qemu/qemu/CVE-2016-9908.patch
@@ -0,0 +1,44 @@
+From 7139ccbc907441337b4b59cde2c5b5a54cb5b2cc Mon Sep 17 00:00:00 2001
+From: Sona Sarmadi 
+
+virtio-gpu: fix information leak in capset get dispatch
+
+In virgl_cmd_get_capset function, it uses g_malloc to allocate
+a response struct to the guest. As the 'resp'struct hasn't been full
+initialized it will lead the 'resp->padding' field to the guest.
+Use g_malloc0 to avoid this.
+
+Signed-off-by: Li Qiang 
+Reviewed-by: Marc-André Lureau 
+Message-id: 58188cae.4a6ec20a.3d2d1.a...@mx.google.com
+
+[Sona: backported from master to v2.8.0 and resolved conflict]
+
+Reference to upstream patch:
+http://git.qemu-project.org/?p=qemu.git;a=commit;h=85d9d044471f93c48c5c396f7e217b4ef12f69f8
+
+CVE: CVE-2016-9908
+Upstream-Status: Backport
+
+Signed-off-by: Gerd Hoffmann 
+Signed-off-by: Sona Sarmadi 
+---
+ hw/display/virtio-gpu-3d.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/hw/display/virtio-gpu-3d.c b/hw/display/virtio-gpu-3d.c
+index 23f39de..d98b140 100644
+--- a/hw/display/virtio-gpu-3d.c
 b/hw/display/virtio-gpu-3d.c
+@@ -371,7 +371,7 @@ static void virgl_cmd_get_capset(VirtIOGPU *g,
+ 
+ virgl_renderer_get_cap_set(gc.capset_id, _ver,
+_size);
+-resp = g_malloc(sizeof(*resp) + max_size);
++resp = g_malloc0(sizeof(*resp) + max_size);
+ 
+ resp->hdr.type = VIRTIO_GPU_RESP_OK_CAPSET;
+ virgl_renderer_fill_caps(gc.capset_id,
+-- 
+1.9.1
+
diff --git a/meta/recipes-devtools/qemu/qemu_2.8.0.bb 
b/meta/recipes-devtools/qemu/qemu_2.8.0.bb
index ce475e0..75928c6 100644
--- a/meta/recipes-devtools/qemu/qemu_2.8.0.bb
+++ b/meta/recipes-devtools/qemu/qemu_2.8.0.bb
@@ -17,6 +17,7 @@ SRC_URI += " \
 
file://0002-Introduce-condition-to-notify-waiters-of-completed-c.patch \
 
file://0003-Introduce-condition-in-TPM-backend-for-notification.patch \
 file://0004-Add-support-for-VM-suspend-resume-for-TPM-TIS.patch \
+file://CVE-2016-9908.patch \
 "
 
 SRC_URI =+ "http://wiki.qemu-project.org/download/${BP}.tar.bz2;
-- 
2.7.4

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

[OE-core] [PATCHv3 5/5] scripts/pkg-config: Add a dummy version that always fails

2017-03-03 Thread Peter Kjellerstedt 
This is intended to catch missing dependencies on the real version.

Signed-off-by: Peter Kjellerstedt 
---
 scripts/pkg-config | 16 
 1 file changed, 16 insertions(+)
 create mode 100755 scripts/pkg-config

diff --git a/scripts/pkg-config b/scripts/pkg-config
new file mode 100755
index 000..c6376ec
--- /dev/null
+++ b/scripts/pkg-config
@@ -0,0 +1,16 @@
+#!/bin/sh
+
+# This is a dummy version that always fails. It is intended to catch
+# missing dependencies on the real version.
+
+myname=${0##*/}
+
+echo "The correct version of $myname is not being used!" >&2
+echo "Make sure the recipe inherits 'pkgconfig'." >&2
+
+# Return something that will make the compiler barf. This is for when
+# pkg-config is used directly in a Makefile in a construct like:
+# CFLAGS += $(shell pkg-config --cflags glib-2.0)
+echo "The-correct-version-of-$myname-is-not-being-used"
+
+exit 1
-- 
2.9.0

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

[OE-core] [PATCHv3 2/5] linux-libc-headers: Add inherit of pkgconfig

2017-03-03 Thread Peter Kjellerstedt 
pkg-config is used by the kernel build system when creating the
configuration tools.

Signed-off-by: Peter Kjellerstedt 
---
 meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc 
b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
index 30d2243..653a470 100644
--- a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
+++ b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
@@ -42,7 +42,7 @@ python __anonymous () {
 d.setVar("HEADER_FETCH_VER", "2.6")
 }
 
-inherit kernel-arch
+inherit kernel-arch pkgconfig
 
 KORG_ARCHIVE_COMPRESSION ?= "xz"
 
-- 
2.9.0

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

[OE-core] [PATCHv3 1/5] module.bbclass: Add inherit of pkgconfig

2017-03-03 Thread Peter Kjellerstedt 
This is needed for the make_scripts task.

Signed-off-by: Peter Kjellerstedt 
---
 meta/classes/module.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/module.bbclass b/meta/classes/module.bbclass
index a588873..99b7ebc 100644
--- a/meta/classes/module.bbclass
+++ b/meta/classes/module.bbclass
@@ -1,4 +1,4 @@
-inherit module-base kernel-module-split
+inherit module-base kernel-module-split pkgconfig
 
 addtask make_scripts after do_prepare_recipe_sysroot before do_compile
 do_make_scripts[lockfiles] = "${TMPDIR}/kernel-scripts.lock"
-- 
2.9.0

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

[OE-core] [PATCHv3 3/5] scripts/dbus-binding-tool: Add a dummy version that always fails

2017-03-03 Thread Peter Kjellerstedt 
This is intended to catch missing dependencies on the real version.

Signed-off-by: Peter Kjellerstedt 
---
 scripts/dbus-binding-tool | 11 +++
 1 file changed, 11 insertions(+)
 create mode 100755 scripts/dbus-binding-tool

diff --git a/scripts/dbus-binding-tool b/scripts/dbus-binding-tool
new file mode 100755
index 000..2e85987
--- /dev/null
+++ b/scripts/dbus-binding-tool
@@ -0,0 +1,11 @@
+#!/bin/sh
+
+# This is a dummy version that always fails. It is intended to catch
+# missing dependencies on the real version.
+
+myname=${0##*/}
+
+echo "The correct version of $myname is not being used!" >&2
+echo "Make sure the recipe DEPENDS on 'dbus-glib-native'." >&2
+
+exit 1
-- 
2.9.0

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

[OE-core] [PATCHv3 0/5] Add dummy tools to help identify needed dependencies

2017-03-03 Thread Peter Kjellerstedt 
After the introduction of RSS, I still found it hard to get
dependencies on some common tools that are typically installed on the
build host correct. Using the wrong version of tools like pkg-config,
gdbus-codegen and dbus-binding-tool can cause build failures.

To circumvent this, I created dummy versions of the tools that always
fail and placed them in the scripts directory. Thus, if the real tool
has not been installed in the RSS, the dummy version is used and the
build fails. For good measures I even output a message that says what
needs to be corrected in the recipe.

Included is also an update to linux-libc-headers as it apparently
needs to inherit pkgconfig, which the introduction of the dummy
version of pkg-config showed.

PATCHv2: Also inherit pkgconfig in module.bbclass since pkg-config
is needed for the make_scripts task.

PATCHv3: Add a missing Signed-off-by footer.

//Peter

The following changes since commit 8f1ed1758748e4c00eaa6b4b3528e79f36d62c19:

  bitbake: fetch2: add initial Amazon AWS S3 fetcher (2017-03-03 00:19:37 +)

are available in the git repository at:

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

Peter Kjellerstedt (5):
  module.bbclass: Add inherit of pkgconfig
  linux-libc-headers: Add inherit of pkgconfig
  scripts/dbus-binding-tool: Add a dummy version that always fails
  scripts/gdbus-codegen: Add a dummy version that always fails
  scripts/pkg-config: Add a dummy version that always fails

 meta/classes/module.bbclass  |  2 +-
 .../linux-libc-headers/linux-libc-headers.inc|  2 +-
 scripts/dbus-binding-tool| 11 +++
 scripts/gdbus-codegen| 11 +++
 scripts/pkg-config   | 16 
 5 files changed, 40 insertions(+), 2 deletions(-)
 create mode 100755 scripts/dbus-binding-tool
 create mode 100755 scripts/gdbus-codegen
 create mode 100755 scripts/pkg-config

-- 
2.9.0

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

[OE-core] [PATCHv3 4/5] scripts/gdbus-codegen: Add a dummy version that always fails

2017-03-03 Thread Peter Kjellerstedt 
This is intended to catch missing dependencies on the real version.

Signed-off-by: Peter Kjellerstedt 
---
 scripts/gdbus-codegen | 11 +++
 1 file changed, 11 insertions(+)
 create mode 100755 scripts/gdbus-codegen

diff --git a/scripts/gdbus-codegen b/scripts/gdbus-codegen
new file mode 100755
index 000..d91386b
--- /dev/null
+++ b/scripts/gdbus-codegen
@@ -0,0 +1,11 @@
+#!/bin/sh
+
+# This is a dummy version that always fails. It is intended to catch
+# missing dependencies on the real version.
+
+myname=${0##*/}
+
+echo "The correct version of $myname is not being used!" >&2
+echo "Make sure the recipe DEPENDS on 'glib-2.0-native'." >&2
+
+exit 1
-- 
2.9.0

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

[OE-core] [PATCH 4/4] populate_ext_sdk: Merge auto.conf into local.conf

2017-03-03 Thread Richard Purdie 
auto.conf is included before local.conf. Instead of keeping them separate, merge
them into the extsdk local.conf. As it happens we can do this quite neatly, more
neatly than the current code IMO and it makes the configuration easier for the 
end
user to understand too.

This means auto.conf is then available for the testsdk code to use for testing
purposes.

Signed-off-by: Richard Purdie 
---
 meta/classes/populate_sdk_ext.bbclass | 24 +++-
 1 file changed, 7 insertions(+), 17 deletions(-)

diff --git a/meta/classes/populate_sdk_ext.bbclass 
b/meta/classes/populate_sdk_ext.bbclass
index fb38ebc..3bccb14 100644
--- a/meta/classes/populate_sdk_ext.bbclass
+++ b/meta/classes/populate_sdk_ext.bbclass
@@ -253,6 +253,8 @@ python copy_buildsystem () {
 
 # Create local.conf
 builddir = d.getVar('TOPDIR')
+if derivative and os.path.exists(builddir + '/conf/auto.conf'):
+shutil.copyfile(builddir + '/conf/auto.conf', baseoutpath + 
'/conf/auto.conf')
 if derivative:
 shutil.copyfile(builddir + '/conf/local.conf', baseoutpath + 
'/conf/local.conf')
 else:
@@ -267,8 +269,12 @@ python copy_buildsystem () {
 env_whitelist_values[varname] = origvalue
 return origvalue, op, 0, True
 varlist = ['[^#=+ ]*']
+oldlines = []
+if os.path.exists(builddir + '/conf/auto.conf'):
+with open(builddir + '/conf/auto.conf', 'r') as f:
+oldlines += f.readlines()
 with open(builddir + '/conf/local.conf', 'r') as f:
-oldlines = f.readlines()
+oldlines += f.readlines()
 (updated, newlines) = bb.utils.edit_metadata(oldlines, varlist, 
handle_var)
 
 with open(baseoutpath + '/conf/local.conf', 'w') as f:
@@ -332,22 +338,6 @@ python copy_buildsystem () {
 f.write('require conf/locked-sigs.inc\n')
 f.write('require conf/unlocked-sigs.inc\n')
 
-if os.path.exists(builddir + '/conf/auto.conf'):
-if derivative:
-shutil.copyfile(builddir + '/conf/auto.conf', baseoutpath + 
'/conf/auto.conf')
-else:
-with open(builddir + '/conf/auto.conf', 'r') as f:
-oldlines = f.readlines()
-(updated, newlines) = bb.utils.edit_metadata(oldlines, varlist, 
handle_var)
-with open(baseoutpath + '/conf/auto.conf', 'w') as f:
-f.write('# WARNING: this configuration has been automatically 
generated and in\n')
-f.write('# most cases should not be edited. If you need more 
flexibility than\n')
-f.write('# this configuration provides, it is strongly 
suggested that you set\n')
-f.write('# up a proper instance of the full build system and 
use that instead.\n\n')
-for line in newlines:
-if line.strip() and not line.startswith('#'):
-f.write(line)
-
 # Write a templateconf.cfg
 with open(baseoutpath + '/conf/templateconf.cfg', 'w') as f:
 f.write('meta/conf\n')
-- 
2.7.4

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

[OE-core] [PATCH 2/4] testsdk: Drop lockfile usage

2017-03-03 Thread Richard Purdie 
We should be able to test sdks in parallel. As far as I can tell, this
restriction crept in for no good reason, based on locks that testimage used
for the non-qemu case.

Therefore remove the lock and allow sdks to test in parallel.

Signed-off-by: Richard Purdie 
---
 meta/classes/testsdk.bbclass | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/meta/classes/testsdk.bbclass b/meta/classes/testsdk.bbclass
index d566b43..29db5e8 100644
--- a/meta/classes/testsdk.bbclass
+++ b/meta/classes/testsdk.bbclass
@@ -14,8 +14,6 @@
 #
 # where "" is an image like core-image-sato.
 
-TESTSDKLOCK = "${TMPDIR}/testsdk.lock"
-
 def testsdk_main(d):
 import os
 import subprocess
@@ -194,4 +192,4 @@ python do_testsdkext() {
 }
 addtask testsdkext
 do_testsdkext[nostamp] = "1"
-do_testsdkext[lockfiles] += "${TESTSDKEXTLOCK}"
+
-- 
2.7.4

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

[OE-core] [PATCH 3/4] populate_ext_sdk: Append to SSTATE_MIRRORS

2017-03-03 Thread Richard Purdie 
We need to appent to SSTATE_MIRRORS in case other areas of code are also
setting the variable.

Signed-off-by: Richard Purdie 
---
 meta/classes/populate_sdk_ext.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/populate_sdk_ext.bbclass 
b/meta/classes/populate_sdk_ext.bbclass
index 51b98a8..fb38ebc 100644
--- a/meta/classes/populate_sdk_ext.bbclass
+++ b/meta/classes/populate_sdk_ext.bbclass
@@ -312,7 +312,7 @@ python copy_buildsystem () {
 f.write('BUILDCFG_HEADER = ""\n\n')
 
 # Map gcc-dependent uninative sstate cache for installer usage
-f.write('SSTATE_MIRRORS = "file://universal/(.*) 
file://universal-4.9/\\1\\nfile://universal-4.9/(.*) 
file://universal-4.8/\\1"\n\n')
+f.write('SSTATE_MIRRORS += " file://universal/(.*) 
file://universal-4.9/\\1 file://universal-4.9/(.*) 
file://universal-4.8/\\1"\n\n')
 
 # Allow additional config through sdk-extra.conf
 fn = bb.cookerdata.findConfigFile('sdk-extra.conf', d)
-- 
2.7.4

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

[OE-core] [PATCH 1/4] oeqa/sdkext/devtool: Ensure dependencies for test_extend_autotools_recipe_creation are present

2017-03-03 Thread Richard Purdie 
test_extend_autotools_recipe_creation needs libxml2 so ensure this is
installed/present as it may not be in the minimal eSDK case.

Signed-off-by: Richard Purdie 
---
 meta/lib/oeqa/sdkext/cases/devtool.py | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/lib/oeqa/sdkext/cases/devtool.py 
b/meta/lib/oeqa/sdkext/cases/devtool.py
index 1072fb6..a01bc0b 100644
--- a/meta/lib/oeqa/sdkext/cases/devtool.py
+++ b/meta/lib/oeqa/sdkext/cases/devtool.py
@@ -68,6 +68,7 @@ class DevtoolTest(OESDKExtTestCase):
 def test_extend_autotools_recipe_creation(self):
 req = 'https://github.com/rdfa/librdfa'
 recipe = "librdfa"
+self._run('devtool sdk-install libxml2')
 self._run('devtool add %s %s' % (recipe, req) )
 try:
 self._run('devtool build %s' % recipe)
-- 
2.7.4

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

Re: [OE-core] "inherit setuptools" versus "inherit pypi" -- a python style question

2017-03-03 Thread Robert P. J. Day 
On Fri, 3 Mar 2017, Jack Mitchell wrote:

> On 03/03/17 10:06, Robert P. J. Day wrote:
> > On Fri, 3 Mar 2017, Anders Darander wrote:
> >
> >> * Robert P. J. Day  [170302 12:33]:
> >>
> >>> On Thu, 2 Mar 2017, Robert P. J. Day wrote:
> >>
>    inherit pypi setuptools
>    require python-psutil.inc
> >>
>  and the corresponding .inc file contains:
> >>
>    RDEPENDS_${PN} += " \
>  ${PYTHON_PN}-shell \
>  ${PYTHON_PN}-subprocess \
>  ${PYTHON_PN}-threading \
>    "
> >>
>  so the first recipe inherits pypi, the second one inherits setuptools,
>  and the third inherits *both*. what is the *preferred* style?
> >>
> >> Well, different purposes... If you take a look at pypi.bbclass, it's all
> >> about how to retrieve the module (source code). setuptools.bbclass is
> >> about how to install the module...
> >>
> >> Ie retrieving and installing...
> >
> >   yes, i finally twigged to that, but is there a *preferred* style?
> > from what i've seen, if there is a pair of files for a python module:
> >
> >   * foo.bb (which includes ...)
> >   * foo.inc
> >
> > the common style seems to be that:
> >
> >   * foo.bb inherits setuptools, while
> >   * foo.inc inherits pypi (if necessary, of course)
> >
> > at least i think that was the common style. obviously, there are
> > perfectly acceptable variations, i'd just like to know if there is a
> > recommended style.
>
> One reason for this is for py2/py3 reciepes. python-foo.bb will
> inherit setuptools, while python3-foo has to inherit setuptools3. So
> I would imagine that setuptools should always go in the bb. While
> pypi is python version agnostic I believe.

  right, which suggests that even if one has a recipe for which there
is only one version (python2 or python3), it's still a good idea to
break it as above just in case, some day, you want to support both
versions. that's all i mean by "style." thanks.

rday

-- 


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

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


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

Re: [OE-core] npm thoughts

2017-03-03 Thread Alexander Kanavin 

On 03/03/2017 12:45 PM, Josef Holzmayr wrote:

- Given the current situation, the best practise seems to be to have
package.json take care of the needed modules, and have it handle that.
Means in my opinion that there should be as little npm-based stuff
installed as possible. Exactly one, in the optimal case. Downside: this
means a second dependency tracking is layered under bitbake. No good
that sounds


I've been looking into this for the past few days. Unfortunately, it 
looks like we do need a generic, extensible mechanism for dealing with 
the likes of npm, cargo (i.e. rust), and 'go get' and similar things.


I've just set up a minimal MEAN project on my machine, and npm pulled in 
1087 dependencies just so it could run. This is not 'wrong', it's simply 
where the world of software development is heading. It's just so much 
nicer to get a project started and running this way, than the old way of 
writing Makefiles and installing development dependencies by hand into 
the system. But it does create a headache for distributions, and those 
who need reproducible builds.


I'll write down my ideas (and maybe even a design proposal!) in a few 
days about this.


Alex

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

[OE-core] [PATCHv2 0/5] Add dummy tools to help identify needed dependencies

2017-03-03 Thread Peter Kjellerstedt 
After the introduction of RSS, I still found it hard to get
dependencies on some common tools that are typically installed on the
build host correct. Using the wrong version of tools like pkg-config,
gdbus-codegen and dbus-binding-tool can cause build failures.

To circumvent this, I created dummy versions of the tools that always
fail and placed them in the scripts directory. Thus, if the real tool
has not been installed in the RSS, the dummy version is used and the
build fails. For good measures I even output a message that says what
needs to be corrected in the recipe.

Included is also an update to linux-libc-headers as it apparently
needs to inherit pkgconfig, which the introduction of the dummy
version of pkg-config showed.

PATCHv2: Also inherit pkgconfig in module.bbclass since pkg-config
is needed for the make_scripts task.

//Peter

The following changes since commit 8f1ed1758748e4c00eaa6b4b3528e79f36d62c19:

  bitbake: fetch2: add initial Amazon AWS S3 fetcher (2017-03-03 00:19:37 +)

are available in the git repository at:

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

Peter Kjellerstedt (5):
  module.bbclass: Add inherit of pkgconfig
  linux-libc-headers: Add inherit of pkgconfig
  scripts/dbus-binding-tool: Add a dummy version that always fails
  scripts/gdbus-codegen: Add a dummy version that always fails
  scripts/pkg-config: Add a dummy version that always fails

 meta/classes/module.bbclass  |  2 +-
 .../linux-libc-headers/linux-libc-headers.inc|  2 +-
 scripts/dbus-binding-tool| 11 +++
 scripts/gdbus-codegen| 11 +++
 scripts/pkg-config   | 16 
 5 files changed, 40 insertions(+), 2 deletions(-)
 create mode 100755 scripts/dbus-binding-tool
 create mode 100755 scripts/gdbus-codegen
 create mode 100755 scripts/pkg-config

-- 
2.9.0

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

[OE-core] [PATCHv2 4/5] scripts/gdbus-codegen: Add a dummy version that always fails

2017-03-03 Thread Peter Kjellerstedt 
This is intended to catch missing dependencies on the real version.

Signed-off-by: Peter Kjellerstedt 
---
 scripts/gdbus-codegen | 11 +++
 1 file changed, 11 insertions(+)
 create mode 100755 scripts/gdbus-codegen

diff --git a/scripts/gdbus-codegen b/scripts/gdbus-codegen
new file mode 100755
index 000..d91386b
--- /dev/null
+++ b/scripts/gdbus-codegen
@@ -0,0 +1,11 @@
+#!/bin/sh
+
+# This is a dummy version that always fails. It is intended to catch
+# missing dependencies on the real version.
+
+myname=${0##*/}
+
+echo "The correct version of $myname is not being used!" >&2
+echo "Make sure the recipe DEPENDS on 'glib-2.0-native'." >&2
+
+exit 1
-- 
2.9.0

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

[OE-core] [PATCHv2 2/5] linux-libc-headers: Add inherit of pkgconfig

2017-03-03 Thread Peter Kjellerstedt 
pkg-config is used by the kernel build system when creating the
configuration tools.

Signed-off-by: Peter Kjellerstedt 
---
 meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc 
b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
index 30d2243..653a470 100644
--- a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
+++ b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
@@ -42,7 +42,7 @@ python __anonymous () {
 d.setVar("HEADER_FETCH_VER", "2.6")
 }
 
-inherit kernel-arch
+inherit kernel-arch pkgconfig
 
 KORG_ARCHIVE_COMPRESSION ?= "xz"
 
-- 
2.9.0

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

[OE-core] [PATCHv2 5/5] scripts/pkg-config: Add a dummy version that always fails

2017-03-03 Thread Peter Kjellerstedt 
This is intended to catch missing dependencies on the real version.

Signed-off-by: Peter Kjellerstedt 
---
 scripts/pkg-config | 16 
 1 file changed, 16 insertions(+)
 create mode 100755 scripts/pkg-config

diff --git a/scripts/pkg-config b/scripts/pkg-config
new file mode 100755
index 000..c6376ec
--- /dev/null
+++ b/scripts/pkg-config
@@ -0,0 +1,16 @@
+#!/bin/sh
+
+# This is a dummy version that always fails. It is intended to catch
+# missing dependencies on the real version.
+
+myname=${0##*/}
+
+echo "The correct version of $myname is not being used!" >&2
+echo "Make sure the recipe inherits 'pkgconfig'." >&2
+
+# Return something that will make the compiler barf. This is for when
+# pkg-config is used directly in a Makefile in a construct like:
+# CFLAGS += $(shell pkg-config --cflags glib-2.0)
+echo "The-correct-version-of-$myname-is-not-being-used"
+
+exit 1
-- 
2.9.0

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

[OE-core] [PATCHv2 1/5] module.bbclass: Add inherit of pkgconfig

2017-03-03 Thread Peter Kjellerstedt 
This is needed for the make_scripts task.
---
 meta/classes/module.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/module.bbclass b/meta/classes/module.bbclass
index a588873..99b7ebc 100644
--- a/meta/classes/module.bbclass
+++ b/meta/classes/module.bbclass
@@ -1,4 +1,4 @@
-inherit module-base kernel-module-split
+inherit module-base kernel-module-split pkgconfig
 
 addtask make_scripts after do_prepare_recipe_sysroot before do_compile
 do_make_scripts[lockfiles] = "${TMPDIR}/kernel-scripts.lock"
-- 
2.9.0

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

[OE-core] [PATCHv2 3/5] scripts/dbus-binding-tool: Add a dummy version that always fails

2017-03-03 Thread Peter Kjellerstedt 
This is intended to catch missing dependencies on the real version.

Signed-off-by: Peter Kjellerstedt 
---
 scripts/dbus-binding-tool | 11 +++
 1 file changed, 11 insertions(+)
 create mode 100755 scripts/dbus-binding-tool

diff --git a/scripts/dbus-binding-tool b/scripts/dbus-binding-tool
new file mode 100755
index 000..2e85987
--- /dev/null
+++ b/scripts/dbus-binding-tool
@@ -0,0 +1,11 @@
+#!/bin/sh
+
+# This is a dummy version that always fails. It is intended to catch
+# missing dependencies on the real version.
+
+myname=${0##*/}
+
+echo "The correct version of $myname is not being used!" >&2
+echo "Make sure the recipe DEPENDS on 'dbus-glib-native'." >&2
+
+exit 1
-- 
2.9.0

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

Re: [OE-core] "inherit setuptools" versus "inherit pypi" -- a python style question

2017-03-03 Thread Jack Mitchell 


On 03/03/17 10:06, Robert P. J. Day wrote:
> On Fri, 3 Mar 2017, Anders Darander wrote:
> 
>> * Robert P. J. Day  [170302 12:33]:
>>
>>> On Thu, 2 Mar 2017, Robert P. J. Day wrote:
>>
   inherit pypi setuptools
   require python-psutil.inc
>>
 and the corresponding .inc file contains:
>>
   RDEPENDS_${PN} += " \
 ${PYTHON_PN}-shell \
 ${PYTHON_PN}-subprocess \
 ${PYTHON_PN}-threading \
   "
>>
 so the first recipe inherits pypi, the second one inherits setuptools,
 and the third inherits *both*. what is the *preferred* style?
>>
>> Well, different purposes... If you take a look at pypi.bbclass, it's all
>> about how to retrieve the module (source code). setuptools.bbclass is
>> about how to install the module...
>>
>> Ie retrieving and installing...
> 
>   yes, i finally twigged to that, but is there a *preferred* style?
> from what i've seen, if there is a pair of files for a python module:
> 
>   * foo.bb (which includes ...)
>   * foo.inc
> 
> the common style seems to be that:
> 
>   * foo.bb inherits setuptools, while
>   * foo.inc inherits pypi (if necessary, of course)
> 
> at least i think that was the common style. obviously, there are
> perfectly acceptable variations, i'd just like to know if there is a
> recommended style.
> 

One reason for this is for py2/py3 reciepes. python-foo.bb will inherit
setuptools, while python3-foo has to inherit setuptools3. So I would
imagine that setuptools should always go in the bb. While pypi is python
version agnostic I believe.

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

Re: [OE-core] npm thoughts

2017-03-03 Thread Josef Holzmayr 

Additional packaging/dependency thoughts:

Using the devtool mechanism to create a recipe basically packs up all 
dependencies. While this is a relatively easy solution to make sure that 
the resulting package is functional, I can see some issues:
- Dependency tracking via bitbake is virtually nonexistent. How would 
one package a npm thing to use other, already packaged dependencies?
- I see problems in the reproductibility of the builds when relying on 
npmjs as upstream server. Packages come and go there sometimes. Is there 
a way to redirect dependencies to a custom hosted mirror?
- Given the current situation, the best practise seems to be to have 
package.json take care of the needed modules, and have it handle that. 
Means in my opinion that there should be as little npm-based stuff 
installed as possible. Exactly one, in the optimal case. Downside: this 
means a second dependency tracking is layered under bitbake. No good 
that sounds


my $.02
--
Josef Holzmayr
Software Developer Embedded Systems

Tel: +49 8444 9204-48
Fax: +49 8444 9204-50

R-S-I Elektrotechnik GmbH & Co. KG
Woelkestrasse 11
D-85301 Schweitenkirchen
www.rsi-elektrotechnik.de
———
Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393
Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
Ust-IdNr: DE 128592548

_
Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363
Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
USt-IdNr.: DE 128592548

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

Re: [OE-core] npm thoughts

2017-03-03 Thread Josef Holzmayr 

Hi Trevor,

On 28.02.2017 19:00, Trevor Woerner wrote:

Ideally "devtool add ..." wouldn't choke and crash when it encounters a
LICENSE string it doesn't understand. When parsing license strings from random
places on The Internet it's inevitable odd things will come up :-)


Yeah, it even seems to get very upset for rather non-obscure things like 
lodash or redux. I ran into that too and will try to have a look.


Greetz
--
Josef Holzmayr
Software Developer Embedded Systems

Tel: +49 8444 9204-48
Fax: +49 8444 9204-50

R-S-I Elektrotechnik GmbH & Co. KG
Woelkestrasse 11
D-85301 Schweitenkirchen
www.rsi-elektrotechnik.de
———
Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393
Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
Ust-IdNr: DE 128592548

_
Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363
Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
USt-IdNr.: DE 128592548

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

Re: [OE-core] "inherit setuptools" versus "inherit pypi" -- a python style question

2017-03-03 Thread Robert P. J. Day 
On Fri, 3 Mar 2017, Anders Darander wrote:

> * Robert P. J. Day  [170302 12:33]:
>
> > On Thu, 2 Mar 2017, Robert P. J. Day wrote:
>
> > >   inherit pypi setuptools
> > >   require python-psutil.inc
>
> > > and the corresponding .inc file contains:
>
> > >   RDEPENDS_${PN} += " \
> > > ${PYTHON_PN}-shell \
> > > ${PYTHON_PN}-subprocess \
> > > ${PYTHON_PN}-threading \
> > >   "
>
> > > so the first recipe inherits pypi, the second one inherits setuptools,
> > > and the third inherits *both*. what is the *preferred* style?
>
> Well, different purposes... If you take a look at pypi.bbclass, it's all
> about how to retrieve the module (source code). setuptools.bbclass is
> about how to install the module...
>
> Ie retrieving and installing...

  yes, i finally twigged to that, but is there a *preferred* style?
from what i've seen, if there is a pair of files for a python module:

  * foo.bb (which includes ...)
  * foo.inc

the common style seems to be that:

  * foo.bb inherits setuptools, while
  * foo.inc inherits pypi (if necessary, of course)

at least i think that was the common style. obviously, there are
perfectly acceptable variations, i'd just like to know if there is a
recommended style.

rday

-- 


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

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


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

Re: [OE-core] "inherit setuptools" versus "inherit pypi" -- a python style question

2017-03-03 Thread Anders Darander 
* Robert P. J. Day  [170302 12:33]:

> On Thu, 2 Mar 2017, Robert P. J. Day wrote:

> >   inherit pypi setuptools
> >   require python-psutil.inc

> > and the corresponding .inc file contains:

> >   RDEPENDS_${PN} += " \
> > ${PYTHON_PN}-shell \
> > ${PYTHON_PN}-subprocess \
> > ${PYTHON_PN}-threading \
> >   "

> > so the first recipe inherits pypi, the second one inherits setuptools,
> > and the third inherits *both*. what is the *preferred* style?

Well, different purposes... If you take a look at pypi.bbclass, it's all
about how to retrieve the module (source code). setuptools.bbclass is
about how to install the module...

Ie retrieving and installing...

Cheers,
Anders

> >   i'm assuming that if a python module is availably via pypi, then
> > you'd go with that; otherwise, just use regular setuptools. and not
> > being a python guru, why does that third recipe need to inherit both?

> >   i did a quick grep of the current meta-python layer to see the
> > frequency of each, and got:

>   grr ... i just looked more closely and it appears that all of
> the "recipe" files under meta-python that inherit only pypi are all
> ".inc" files, being included by recipe files that first inherit
> setuptools. so, again, clarification on the proper way to do this
> would be nice.


-- 
Anders Darander, Senior System Architect
ChargeStorm AB / eStorm AB
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core