date:20160831

[OE-core] [PATCH] ruby: 2.2.5 -> 2.3.1

2016-08-31 Thread Wang Xin

1) Upgrade ruby from 2.2.5 to 2.3.1.
2) Modify LIC_FILES_CHKSUM, since the date in it has been changed, But the 
LICENSE has not been changed.

Signed-off-by: Wang Xin 
---
 meta/recipes-devtools/ruby/ruby.inc | 2 +-
 meta/recipes-devtools/ruby/{ruby_2.2.5.bb => ruby_2.3.1.bb} | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)
 rename meta/recipes-devtools/ruby/{ruby_2.2.5.bb => ruby_2.3.1.bb} (89%)

diff --git a/meta/recipes-devtools/ruby/ruby.inc 
b/meta/recipes-devtools/ruby/ruby.inc
index fde67e9..f38ebb0 100644
--- a/meta/recipes-devtools/ruby/ruby.inc
+++ b/meta/recipes-devtools/ruby/ruby.inc
@@ -11,7 +11,7 @@ LIC_FILES_CHKSUM = "\
 file://COPYING;md5=837b32593517ae48b9c3b5c87a5d288c \
 file://BSDL;md5=19aaf65c88a40b508d17ae4be539c4b5\
 file://GPL;md5=b234ee4d69f5fce4486a80fdaf4a4263\
-file://LEGAL;md5=c440adb575ba4e6e2344c2630b6a5584\
+file://LEGAL;md5=78e8a29b8cc93e042990dbbb5572b1e1\
 "
 
 DEPENDS = "ruby-native zlib openssl tcl libyaml db gdbm readline"
diff --git a/meta/recipes-devtools/ruby/ruby_2.2.5.bb 
b/meta/recipes-devtools/ruby/ruby_2.3.1.bb
similarity index 89%
rename from meta/recipes-devtools/ruby/ruby_2.2.5.bb
rename to meta/recipes-devtools/ruby/ruby_2.3.1.bb
index 5a64582..f9f5b33 100644
--- a/meta/recipes-devtools/ruby/ruby_2.2.5.bb
+++ b/meta/recipes-devtools/ruby/ruby_2.3.1.bb
@@ -1,7 +1,7 @@
 require ruby.inc
 
-SRC_URI[md5sum] = "bd8e349d4fb2c75d90817649674f94be"
-SRC_URI[sha256sum] = 
"30c4b31697a4ca4ea0c8db8ad30cf45e6690a0f09687e5d483c933c03ca335e3"
+SRC_URI[md5sum] = "0d896c2e7fd54f722b399f407e48a4c6"
+SRC_URI[sha256sum] = 
"b87c738cb2032bf4920fef8e3864dc5cf8eae9d89d8d523ce0236945c5797dcd"
 
 # it's unknown to configure script, but then passed to extconf.rb
 # maybe it's not really needed as we're hardcoding the result with
-- 
2.7.4



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

Re: [OE-core] Replacement for tslib?

2016-08-31 Thread Mike Looijmans


On 31-08-16 18:57, Richard Purdie wrote:

On Wed, 2016-08-31 at 17:42 +0200, Enrico Scholz wrote:

Hello,

tslib is more or less mandatory for resistive touchscreens but it was
removed some days ago.  This breaks e.g. meta-qt5 layer which depends
on it.

Is this removal really final (which would be really bad, because
resistive
touchscreens are used e.g. in industrial environments)?


The underlying pressure was from xcalibrate never having been merged
into x11 and hence needing to replace xtscal by xinput-calibrate. With
that change, the need for tslib wasn't clear.

Its was also frustrating having two sets of pointercal files, one for
xinput-calibrate and one for tslib.

That said, I can see the need for tslib and if that is the only way to
support these touchscreens in qt5/qt4 we might have to reconsider that.

Are you sure the kernel interfaces that xinput is using don't work for
qt4/qt5? If not, we may need to reconsider tslib...


Once reason to use Qt is the fact that you don't need X11 for it. And tslib is 
the only calibration tool that seems to work properly with resistive touchscreens.

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

[OE-core] [PATCH] default-distrovars.inc: remove libidn from LGPLv2_WHITELIST_GPL-3.0

2016-08-31 Thread jackie.huang

From: Jackie Huang 

The libidn recipe is now buildable in distros which blacklist
GPL-3.0 without needing to be explicitly whitelisted (since it
provides at least one non GPLv3 package).

Signed-off-by: Jackie Huang 
---
 meta/conf/distro/include/default-distrovars.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/conf/distro/include/default-distrovars.inc 
b/meta/conf/distro/include/default-distrovars.inc
index fac4deb..f7ed943 100644
--- a/meta/conf/distro/include/default-distrovars.inc
+++ b/meta/conf/distro/include/default-distrovars.inc
@@ -23,7 +23,7 @@ DISTRO_FEATURES ?= "${DISTRO_FEATURES_DEFAULT} 
${DISTRO_FEATURES_LIBC}"
 IMAGE_FEATURES ?= ""
 
 WHITELIST_GPL-3.0 ?= ""
-LGPLv2_WHITELIST_GPL-3.0 ?= "libidn"
+LGPLv2_WHITELIST_GPL-3.0 ?= ""
 
 COMMERCIAL_AUDIO_PLUGINS ?= ""
 # COMMERCIAL_AUDIO_PLUGINS ?= "gst-plugins-ugly-mad 
gst-plugins-ugly-mpegaudioparse"
-- 
2.8.1

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

Re: [OE-core] Replacement for tslib?

2016-08-31 Thread Enrico Scholz

Richard Purdie  writes:

>> tslib is more or less mandatory for resistive touchscreens but it was
>> removed some days ago.  This breaks e.g. meta-qt5 layer which depends 
>> on it.
>> 
>> Is this removal really final (which would be really bad, because
>> resistive touchscreens are used e.g. in industrial environments)?
> [...]
> Are you sure the kernel interfaces that xinput is using don't work for
> qt4/qt5?

I am not aware of any way how /dev/input/eventX values can be calibrated
within the kernel.

Most capacitive touchscreens are doing this calibration in hardware
so that values correspond 1:1 to screen coordinates.  But resistive
touchscreens return usually only the raw 10-12 bit ADC values in
ABS_X/Y.

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

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

2016-08-31 Thread Ian Geiser


Can this get backported to krogoth?  For now i am just putting my kernel in 
RM_WORK_EXCLUDE and that seems to be working properly.  Thanks for the hint!

  On Wed, 31 Aug 2016 15:07:16 -0400 Martin Jansa  
wrote  
 > You're not alone, this might be the same issue (fixed only in 
 > master):https://bugzilla.yoctoproject.org/show_bug.cgi?id=9352
 > 
 > On Wed, Aug 31, 2016 at 8:38 PM, Ian Geiser  wrote:
 > 
 >    On Tue, 30 Aug 2016 10:13:52 -0400 Ian Geiser 
 >  wrote 
 >   > Greetings,  I have an issue where I cannot seem to build any external 
 > kernel module recipes.  The one in particular is iscsitarget, but it seems 
 > none of them build now.
 >   >
 >   > It seems that what is happening is that the 
 > "work-shared/*/kernel-build-artifacts" is getting erased right before the 
 > module recipe tries to use them.  Has anyone seen this before?
 >   >
 >   > As a key point, I am also using my own kernel recipe that only uses the 
 > kernel.bbclass, not the kernel-yocto.bbclass.  Is there magic I am missing 
 > that will not allow me to build modules unless I am using the yocto kernels?
 >   >
 >  
 >  Looking at this further it looks like this is a normal issue with all 
 > kernels.  There is a race condition that will cause the kernel to rebuild 
 > everytime you build a module.  During this process the build artifacts are 
 > always cleared out and sometimes it wont actually populate the shared 
 > workdir.  I tested with most kernels and found all modules suffer this 
 > issue.  Am I the only one seeing this?
 >  
 >  --
 >  ___
 >  Openembedded-core mailing list
 >  Openembedded-core@lists.openembedded.org
 >  http://lists.openembedded.org/mailman/listinfo/openembedded-core
 >  
 >  


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

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

2016-08-31 Thread Bruce Ashfield


On 2016-08-31 4:54 AM, André Draszik wrote:

On Di, 2016-08-30 at 14:35 -0400, Bruce Ashfield wrote:

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


I do both:

in the 1st layer, my kernel recipe boils down to:

SRC_URI = "\

git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git;protocol=git;nocheckout=1;branch=${KBRANCH}
 \
file://0001-a-patch.patch \
file://kernel-meta;type=kmeta;destsuffix=${KMETA} \
"

KERNEL_FEATURES_append = " patches/some-patches.scc"
KERNEL_FEATURES_append = " patches/more-patches.scc"
KERNEL_FEATURES_append = " patches/even-more-patches.scc"

some of the above in turn include additional .scc items recursively.


In the 2nd layer, my .bbappend boils down to:

FILESEXTRAPATHS_prepend := "${THISDIR}/${BPN}-4.4:"

KERNEL_FEATURES_append_tgm = " patches/tgm.scc"

2nd-layer.scc is located in ${THISDIR}/kernel-meta/patches/ in the 2nd
layer. I don't specifically add another SRC_URI item tagged with 'kmeta' (or
any other explicit SRC_URI item for that matter).


One more clarification. From our problem description, are you saying
that in your runs, only the meta data from layer2 is getting copied
and not that from layer1 ?

I ran my sanity test, and saw meta data from both my layers copied ..
so I'm worried that I misunderstood the issue you are seeing.

But looking at the code, I can definitely do some minor tweaks in this
area .. I'm just trying to get the reproducer nailed down.

Bruce




Andre'



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

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

2016-08-31 Thread Paul Eggleton

On Wed, 31 Aug 2016 11:55:44 Richard Purdie wrote:
> On Wed, 2016-08-31 at 13:48 +1200, Paul Eggleton wrote:
> > We should always shut down tinfoil when we're finished with it,
> > either
> > by explicitly calling the shutdown() method or by using it as a
> > context manager ("with ...").
> 
> Could I trouble you to rebase this onto master-next please? It
> currently has conflicts which didn't seem immediately obvious to me to
> resolve.

Done - I've pushed a new paule/tinfoil-fixes-oe branch.

Cheers,
Paul

-- 

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

[OE-core] [PATCH 2/2] gtk-doc: patch the scripts to not hardcode the full paths to interpreters

2016-08-31 Thread Alexander Kanavin

Signed-off-by: Alexander Kanavin 
---
 ...hardocode-paths-to-perl-python-in-scripts.patch | 139 +
 meta/recipes-gnome/gtk-doc/gtk-doc_1.25.bb |   3 +
 2 files changed, 142 insertions(+)
 create mode 100644 
meta/recipes-gnome/gtk-doc/files/0001-Do-not-hardocode-paths-to-perl-python-in-scripts.patch

diff --git 
a/meta/recipes-gnome/gtk-doc/files/0001-Do-not-hardocode-paths-to-perl-python-in-scripts.patch
 
b/meta/recipes-gnome/gtk-doc/files/0001-Do-not-hardocode-paths-to-perl-python-in-scripts.patch
new file mode 100644
index 000..3c8f2a2
--- /dev/null
+++ 
b/meta/recipes-gnome/gtk-doc/files/0001-Do-not-hardocode-paths-to-perl-python-in-scripts.patch
@@ -0,0 +1,139 @@
+From 6fab82b93c7bd301eb42448515b02f7cb3306897 Mon Sep 17 00:00:00 2001
+From: Alexander Kanavin 
+Date: Wed, 31 Aug 2016 16:44:46 +0300
+Subject: [PATCH] Do not hardocode paths to perl/python in scripts.
+
+Doing so when the interpreters are somewhere deep in a sysroot directory
+can reach the shebang line limit, and resulting scripts wouldn't work
+on targets either.
+
+Upstream-Status: Inappropriate [oe-core specific]
+Signed-off-by: Alexander Kanavin 
+---
+ gtkdoc-check.in | 2 +-
+ gtkdoc-common.pl.in | 2 +-
+ gtkdoc-depscan.in   | 2 +-
+ gtkdoc-fixxref.in   | 2 +-
+ gtkdoc-mkdb.in  | 2 +-
+ gtkdoc-mktmpl.in| 2 +-
+ gtkdoc-rebase.in| 2 +-
+ gtkdoc-scan.in  | 2 +-
+ gtkdoc-scangobj.in  | 2 +-
+ tests/tools.sh.in   | 4 ++--
+ 10 files changed, 11 insertions(+), 11 deletions(-)
+
+diff --git a/gtkdoc-check.in b/gtkdoc-check.in
+index 560d69b..b60857f 100755
+--- a/gtkdoc-check.in
 b/gtkdoc-check.in
+@@ -1,4 +1,4 @@
+-#!@PERL@ -w
++#!/usr/bin/env perl -w
+ # -*- cperl -*-
+ #
+ # gtk-doc - GTK DocBook documentation generator.
+diff --git a/gtkdoc-common.pl.in b/gtkdoc-common.pl.in
+index 4747396..cfadb78 100644
+--- a/gtkdoc-common.pl.in
 b/gtkdoc-common.pl.in
+@@ -1,4 +1,4 @@
+-#!@PERL@ -w
++#!/usr/bin/env perl -w
+ # -*- cperl -*-
+ #
+ # gtk-doc - GTK DocBook documentation generator.
+diff --git a/gtkdoc-depscan.in b/gtkdoc-depscan.in
+index 83af01b..917e247 100644
+--- a/gtkdoc-depscan.in
 b/gtkdoc-depscan.in
+@@ -1,4 +1,4 @@
+-#!@PYTHON@
++#!/usr/bin/env python
+ 
+ import gzip, os.path, re
+ 
+diff --git a/gtkdoc-fixxref.in b/gtkdoc-fixxref.in
+index 3d9e8d0..d55190b 100755
+--- a/gtkdoc-fixxref.in
 b/gtkdoc-fixxref.in
+@@ -1,4 +1,4 @@
+-#!@PERL@ -w
++#!/usr/bin/env perl -w
+ # -*- cperl -*-
+ #
+ # gtk-doc - GTK DocBook documentation generator.
+diff --git a/gtkdoc-mkdb.in b/gtkdoc-mkdb.in
+index 8dd6d5e..d808750 100755
+--- a/gtkdoc-mkdb.in
 b/gtkdoc-mkdb.in
+@@ -1,4 +1,4 @@
+-#!@PERL@ -w
++#!/usr/bin/env perl -w
+ # -*- cperl -*-
+ #
+ # gtk-doc - GTK DocBook documentation generator.
+diff --git a/gtkdoc-mktmpl.in b/gtkdoc-mktmpl.in
+index c64dfd3..2f46c18 100755
+--- a/gtkdoc-mktmpl.in
 b/gtkdoc-mktmpl.in
+@@ -1,4 +1,4 @@
+-#!@PERL@ -w
++#!/usr/bin/env perl -w
+ # -*- cperl -*-
+ #
+ # gtk-doc - GTK DocBook documentation generator.
+diff --git a/gtkdoc-rebase.in b/gtkdoc-rebase.in
+index 375482d..cf05b45 100644
+--- a/gtkdoc-rebase.in
 b/gtkdoc-rebase.in
+@@ -1,4 +1,4 @@
+-#!@PERL@ -w
++#!/usr/bin/env perl -w
+ # -*- cperl -*-
+ #
+ # gtk-doc - GTK DocBook documentation generator.
+diff --git a/gtkdoc-scan.in b/gtkdoc-scan.in
+index 048e5c9..78c6136 100755
+--- a/gtkdoc-scan.in
 b/gtkdoc-scan.in
+@@ -1,4 +1,4 @@
+-#!@PERL@ -w
++#!/usr/bin/env perl -w
+ # -*- cperl -*-
+ #
+ # gtk-doc - GTK DocBook documentation generator.
+diff --git a/gtkdoc-scangobj.in b/gtkdoc-scangobj.in
+index fb66b76..67ee8f7 100644
+--- a/gtkdoc-scangobj.in
 b/gtkdoc-scangobj.in
+@@ -1,4 +1,4 @@
+-#!@PERL@ -w
++#!/usr/bin/env perl -w
+ # -*- cperl -*-
+ #
+ # gtk-doc - GTK DocBook documentation generator.
+diff --git a/tests/tools.sh.in b/tests/tools.sh.in
+index a114a42..7073883 100644
+--- a/tests/tools.sh.in
 b/tests/tools.sh.in
+@@ -11,7 +11,7 @@ echo "Running suite(s): gtk-doc-$suite";
+ 
+ # test perl scripts
+ for file in gtkdoc-check gtkdoc-fixxref gtkdoc-mkdb gtkdoc-mktmpl 
gtkdoc-rebase gtkdoc-scan gtkdoc-scangobj ; do
+-  @PERL@ -cwT `which $file`
++  perl -cwT `which $file`
+   if test $? = 1 ; then failed=`expr $failed + 1`; fi
+   tested=`expr $tested + 1`
+ done
+@@ -34,7 +34,7 @@ done
+ 
+ 
+ # test python scripts
+-@PYTHON@ -m py_compile `which gtkdoc-depscan`
++python -m py_compile `which gtkdoc-depscan`
+ if test $? != 0 ; then failed=`expr $failed + 1`; fi
+ tested=`expr $tested + 1`
+ 
+-- 
+2.9.3
+
diff --git a/meta/recipes-gnome/gtk-doc/gtk-doc_1.25.bb 
b/meta/recipes-gnome/gtk-doc/gtk-doc_1.25.bb
index 0585ca9..6587800 100644
--- a/meta/recipes-gnome/gtk-doc/gtk-doc_1.25.bb
+++ b/meta/recipes-gnome/gtk-doc/gtk-doc_1.25.bb
@@ -10,6 +10,9 @@ DEPENDS_append = "libxslt xmlto source-highlight-native"
 EXTRA_OECONF_append = " --with-highlight=source-highlight"

[OE-core] [PATCH 1/2] Revert "gtk-doc: do not inherit perlnative and pythonnative"

2016-08-31 Thread Alexander Kanavin

gtk-doc requires Perl to be at least 5.18 which is more than some
distros provide (CentOS 7 in particular).

Signed-off-by: Alexander Kanavin 
---
 meta/recipes-gnome/gtk-doc/gtk-doc_1.25.bb | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-gnome/gtk-doc/gtk-doc_1.25.bb 
b/meta/recipes-gnome/gtk-doc/gtk-doc_1.25.bb
index 79d4e43..0585ca9 100644
--- a/meta/recipes-gnome/gtk-doc/gtk-doc_1.25.bb
+++ b/meta/recipes-gnome/gtk-doc/gtk-doc_1.25.bb
@@ -5,8 +5,8 @@ HOMEPAGE = "http://www.gtk.org/gtk-doc/;
 LICENSE = "GPLv2"
 LIC_FILES_CHKSUM = "file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f"
 
-inherit gnomebase
-DEPENDS_append = " libxslt xmlto source-highlight-native"
+inherit gnomebase pythonnative perlnative
+DEPENDS_append = "libxslt xmlto source-highlight-native"
 EXTRA_OECONF_append = " --with-highlight=source-highlight"
 EXTRA_OECONF_append_class-native = " 
--with-xml-catalog=${sysconfdir}/xml/catalog.xml"
 
-- 
2.9.3

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

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

2016-08-31 Thread Martin Jansa

You're not alone, this might be the same issue (fixed only in master):
https://bugzilla.yoctoproject.org/show_bug.cgi?id=9352

On Wed, Aug 31, 2016 at 8:38 PM, Ian Geiser  wrote:

>
>   On Tue, 30 Aug 2016 10:13:52 -0400 Ian Geiser
>  wrote 
>  > Greetings,  I have an issue where I cannot seem to build any external
> kernel module recipes.  The one in particular is iscsitarget, but it seems
> none of them build now.
>  >
>  > It seems that what is happening is that the 
> "work-shared/*/kernel-build-artifacts"
> is getting erased right before the module recipe tries to use them.  Has
> anyone seen this before?
>  >
>  > As a key point, I am also using my own kernel recipe that only uses the
> kernel.bbclass, not the kernel-yocto.bbclass.  Is there magic I am missing
> that will not allow me to build modules unless I am using the yocto kernels?
>  >
>
> Looking at this further it looks like this is a normal issue with all
> kernels.  There is a race condition that will cause the kernel to rebuild
> everytime you build a module.  During this process the build artifacts are
> always cleared out and sometimes it wont actually populate the shared
> workdir.  I tested with most kernels and found all modules suffer this
> issue.  Am I the only one seeing this?
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

2016-08-31 Thread Ian Geiser


  On Tue, 30 Aug 2016 10:13:52 -0400 Ian Geiser  
wrote  
 > Greetings,  I have an issue where I cannot seem to build any external kernel 
 > module recipes.  The one in particular is iscsitarget, but it seems none of 
 > them build now. 
 >  
 > It seems that what is happening is that the 
 > "work-shared/*/kernel-build-artifacts" is getting erased right before the 
 > module recipe tries to use them.  Has anyone seen this before? 
 >  
 > As a key point, I am also using my own kernel recipe that only uses the 
 > kernel.bbclass, not the kernel-yocto.bbclass.  Is there magic I am missing 
 > that will not allow me to build modules unless I am using the yocto kernels? 
 >  
 
Looking at this further it looks like this is a normal issue with all kernels.  
There is a race condition that will cause the kernel to rebuild everytime you 
build a module.  During this process the build artifacts are always cleared out 
and sometimes it wont actually populate the shared workdir.  I tested with most 
kernels and found all modules suffer this issue.  Am I the only one seeing this?

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

Re: [OE-core] Replacement for tslib?

2016-08-31 Thread Richard Purdie

On Wed, 2016-08-31 at 17:42 +0200, Enrico Scholz wrote:
> Hello,
> 
> tslib is more or less mandatory for resistive touchscreens but it was
> removed some days ago.  This breaks e.g. meta-qt5 layer which depends 
> on it.
> 
> Is this removal really final (which would be really bad, because
> resistive
> touchscreens are used e.g. in industrial environments)?

The underlying pressure was from xcalibrate never having been merged
into x11 and hence needing to replace xtscal by xinput-calibrate. With
that change, the need for tslib wasn't clear.

Its was also frustrating having two sets of pointercal files, one for
xinput-calibrate and one for tslib.

That said, I can see the need for tslib and if that is the only way to
support these touchscreens in qt5/qt4 we might have to reconsider that.

Are you sure the kernel interfaces that xinput is using don't work for
qt4/qt5? If not, we may need to reconsider tslib...

Cheers,

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

Re: [OE-core] pseudo 1.8.1 doesn't work with docker & dumb-init

2016-08-31 Thread Seebs


On 31 Aug 2016, at 4:21, wenzong fan wrote:


Finally I narrowed it down to pseudo commit:


Yes, that makes sense, we expect that there'd be potential issues, but I 
didn't have a reproducer for any. Thanks! I'll see whether it reproduces 
for me now. Any specific version of docker I might need?


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

[OE-core] Replacement for tslib?

2016-08-31 Thread Enrico Scholz

Hello,

tslib is more or less mandatory for resistive touchscreens but it was
removed some days ago.  This breaks e.g. meta-qt5 layer which depends on
it.

Is this removal really final (which would be really bad, because resistive
touchscreens are used e.g. in industrial environments)?


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

Re: [OE-core] State of bitbake world 2016-08-24

2016-08-31 Thread Trevor Woerner

I performed a verbose build on my build machine to see how it compares to
yours.

On Wed 2016-08-31 @ 05:41:06 AM, Trevor Woerner wrote:
> On Fri 2016-08-26 @ 05:51:54 PM, Martin Jansa wrote:
> | [2278/20239] CXX obj.host/third_party/icu/source/common/icuuc.servrbf.o
> | FAILED: obj.host/third_party/icu/source/common/icuuc.servrbf.o
> | g++  -MMD -MF obj.host/third_party/icu/source/common/icuuc.servrbf.o.d 
> -DU_USING_ICU_NAMESPACE=0 -DHAVE_DLOPEN=0 -DUCONFIG_ONLY_HTML_CONVERSION=1 
> -DU_CHARSET_IS_UTF8=1 -DV8_DEPRECATION_WARNINGS -D_FILE_OFFSET_BITS=64 
> -DDISABLE_NACL -DU_STATIC_IMPLEMENTATION -DCHROMIUM_BUILD 
> -DUI_COMPOSITOR_IMAGE_TRANSPORT -DUSE_AURA=1 -DUSE_PANGO=1 -DUSE_CAIRO=1 
> -DUSE_DEFAULT_RENDER_THEME=1 -DUSE_LIBJPEG_TURBO=1 -DUSE_X11=1 
> -DUSE_CLIPBOARD_AURAX11=1 -DENABLE_WEBRTC=1 -DENABLE_MEDIA_ROUTER=1 
> -DENABLE_PEPPER_CDMS -DENABLE_NOTIFICATIONS -DENABLE_TOPCHROME_MD=1 
> -DUSE_UDEV -DFIELDTRIAL_TESTING_ENABLED -DENABLE_TASK_MANAGER=1 
> -DENABLE_EXTENSIONS=1 -DENABLE_PDF=1 -DENABLE_PLUGINS=1 
> -DENABLE_SESSION_SERVICE=1 -DENABLE_THEMES=1 -DENABLE_PRINTING=1 
> -DENABLE_BASIC_PRINTING=1 -DENABLE_PRINT_PREVIEW=1 -DENABLE_SPELLCHECK=1 
> -DENABLE_CAPTIVE_PORTAL_DETECTION=1 -DENABLE_SUPERVISED_USERS=1 
> -DENABLE_MDNS=1 -DENABLE_SERVICE_DISCOVERY=1 -DFULL_SAFE_BROWSING 
> -DSAFE_BROWSING_CSD -DSAFE_BROWSING_DB_LOCAL -DU_CO
 MMON_IMPLEMENTATION -DU_ICUDATAENTRY_IN_COMMON -DU_ENABLE_DYLOAD=0 
-DU_NOEXCEPT= -DUSE_LIBPCI=1 -DUSE_GLIB=1 -DUSE_NSS_CERTS=1 -DNDEBUG 
-DNVALGRIND -DDYNAMIC_ANNOTATIONS_ENABLED=0 
-I../../third_party/icu/source/common -I../../third_party/icu/source/i18n -Igen 
-fstack-protector --param=ssp-buffer-size=4  -pthread -fno-strict-aliasing 
-Wno-extra -Wno-unused-parameter -Wno-missing-field-initializers 
-fvisibility=hidden -pipe -fPIC -Wno-unused-local-typedefs 
-Wno-deprecated-declarations -Wno-unused-function -m32 -O2 -fno-ident 
-fdata-sections -ffunction-sections -funwind-tables -fno-exceptions -fno-rtti 
-fno-threadsafe-statics -fvisibility-inlines-hidden -frtti -Wno-deprecated 
-std=gnu++11 -Wno-narrowing  -c ../../third_party/icu/source/common/servrbf.cpp 
-o obj.host/third_party/icu/source/common/icuuc.servrbf.o

Buried deep in all your compiler options is "-m32". On my machine all these
options are exactly the same except for this one; in my case my build has
"-m64".

Are you doing your world builds on a 32-bit machine?

Could this one change account for my build success and your build failure?
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] pseudo 1.8.1 doesn't work with docker & dumb-init

2016-08-31 Thread Joshua Lock

On Wed, 2016-08-31 at 17:21 +0800, wenzong fan wrote:
> Hi Experts,
> 
> While I trying to build Yocto in Docker Container which using dumb-
> init 
> as init system, I found the build always be stopped at some point
> and 
> the container was terminated as well with below errors:
> 
>  Child process timeout after 2 seconds.
>  Child process exit status 4: lock_held
> 
> Sometimes there's not any obvious error message.
> 
> After some `git bisect` testing, I believe the issue was started
> since 
> commit:
> 
> --
> 9df3cdf42d8c1216682f497f0b166a43ef9f4184 is the first bad commit
> commit 9df3cdf42d8c1216682f497f0b166a43ef9f4184
> Author: Richard Purdie 
> Date: Tue Jul 5 13:18:31 2016 +0100
> 
>  pseudo: Upgrade to 1.8.1
> 
>  * Drop patches where the changes exist upstream
>  * Fetch from git as no tarball is available for 1.8.1
>  * Move common code to pseudo.inc
>  * Update patchset in git recipe
> 
>  (From OE-Core rev: 0c36984d4c501d12fa91cf7371511641585cc256)
> ---
> 
> Finally I narrowed it down to pseudo commit:
> 
> 
> commit 77ee254a6c974aad9bcab2c58c9ee9e0880c9718
> Author: Peter Seebach 
> Date: Tue Mar 1 16:21:15 2016 -0600
> 
>  Server launch reworking.
> 
>  This is the big overhaul to have the server provide meaningful
> exit 
> status
>  to clients.
> 
>  In the process, I discovered that the server was running with 
> signals blocked
>  if launched by a client, which is not a good thing, and
> prevented 
> this from
>  working as intended.
> 
>  Still looking to see why more than one server spawn seems to
> happen.
> 
> 
> I also created a testcase for reproducing the issue at:
> 
>  https://github.com/WenzongFan/docker-build-yocto

Thanks for providing a detailed reproducer. I'm trying to configure a
container behind my proxy here.

> 
> For dumb-init please refer to:
> 
>  https://github.com/Yelp/dumb-init
> 
> Could anyone help to fix the signal handling in pseudo?

It may not actually be pseudo at fault here. I've only skimmed the
dumb-init README but it looks like there might be a strange interaction
between the newly fixed signal handling in pseudo and dumb-init's
signal handling.

Should dumb-init be running in single-child/non-setsid mode so that
signals are only forwarded to the direct child rather than all child
processes in the dumb-init session? Is this a scenario you've tested?

Regards,

Joshua

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

[OE-core] [PATCH] qemuarm/qa: whitelist amba and jitter

2016-08-31 Thread Bruce Ashfield

With the update to the 4.8 kernel the versatile platform (and hence
qemuarm) has switched to a device tree boot.

We are using an ummodified mainline kernel versatilepb device tree,
which includes definitions of multiple amba devices. These devices
are not present in the qemu system emulation, hence throw warnings
during boot.

These warnings are not unique to oe-core, and rather than carry kernel
patches to the device tree (for now), we whitelist the known warnings
so qa testing will pass. We also can't turn amba off completely, since
it is providing valid devices (like the serial port) and AMBA is
force selected by other kconfig values.

We also have a jitterentropy warning that shows up on some hosts.
This warning is harmless, and like amba we can't turn it off in a
fragment since it is force selected by crypto (and we'd rather not
turn all crypto off). So we add it to the whitelist while investigations
continue into what is needed in the host to support this fully.

Signed-off-by: Bruce Ashfield 
---
 meta/lib/oeqa/runtime/parselogs.py | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/meta/lib/oeqa/runtime/parselogs.py 
b/meta/lib/oeqa/runtime/parselogs.py
index 8a13554cc5da..2424da127422 100644
--- a/meta/lib/oeqa/runtime/parselogs.py
+++ b/meta/lib/oeqa/runtime/parselogs.py
@@ -92,7 +92,16 @@ ignore_errors = {
 'qemuarm' : [
 'mmci-pl18x: probe of fpga:05 failed with error -22',
 'mmci-pl18x: probe of fpga:0b failed with error -22',
-'Failed to load module "glx"'
+'Failed to load module "glx"',
+'OF: amba_device_add() failed (-19) for /amba/smc@1010',
+'OF: amba_device_add() failed (-19) for /amba/mpmc@1011',
+'OF: amba_device_add() failed (-19) for /amba/sctl@101e',
+'OF: amba_device_add() failed (-19) for /amba/watchdog@101e1000',
+'OF: amba_device_add() failed (-19) for /amba/sci@101f',
+'OF: amba_device_add() failed (-19) for /amba/ssp@101f4000',
+'OF: amba_device_add() failed (-19) for /amba/fpga/sci@a000',
+'Failed to initialize \'/amba/timer@101e3000\': -22',
+'jitterentropy: Initialization failed with host not compliant with 
requirements: 2',
 ] + common_errors,
 'qemuarm64' : [
 'Fatal server error:',
-- 
2.5.0

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

[OE-core] [PATCH] kernel.bbclass: add user output to savedefconfig

2016-08-31 Thread Stefan Müller-Klieser

In a similar manner to diffconfig, tell the bitbake user where the
defconfig will be saved to.

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

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index db42744..ed41125 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -434,6 +434,7 @@ kernel_do_configure() {
 }
 
 do_savedefconfig() {
+   bbplain "Saving defconfig to:\n${B}/defconfig"
oe_runmake -C ${B} savedefconfig
 }
 do_savedefconfig[nostamp] = "1"
-- 
1.9.1

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

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

2016-08-31 Thread Bill Randle

Under what conditions is the explicit path to /usr/bin/perl required? Just
before your added code, it creates a symlink from the installed perl
location to the "t" directory where the tests are run. What if the perl
that was built was an alternate version and installed in /usr/local/bin?

-Bill

On Tue, Aug 30, 2016 at 10:37 PM, Zhenbo Gao 
wrote:

> some files from perl-ptest depends on perl, which is located at /usr/bin/
>
> Signed-off-by: Zhenbo Gao 
> ---
>  meta/recipes-devtools/perl/perl-ptest.inc | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/meta/recipes-devtools/perl/perl-ptest.inc
> b/meta/recipes-devtools/perl/perl-ptest.inc
> index d136c5c..94e40e6 100644
> --- a/meta/recipes-devtools/perl/perl-ptest.inc
> +++ b/meta/recipes-devtools/perl/perl-ptest.inc
> @@ -24,6 +24,12 @@ do_install_ptest () {
>
> ln -sf ${bindir}/perl ${D}${PTEST_PATH}/t/perl
>
> +   # perl is located at /usr/bin/
> +   p='^#![/.]*perl'
> +   files=`grep -E ${p} ${D} -nr | grep -v -E 'Binary|win32' | cut -d
> ':' -f 1`
> +   for f in ${files}; do
> +   sed -i -e "s:${p}:#! ${USRBINPATH}/perl:g" ${f}
> +   done
>  }
>
>  python populate_packages_prepend() {
> --
> 1.9.1
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

2016-08-31 Thread Andrew Goodbody

> From: Manjukumar Harthikote Matha [mailto:manjukumar.harthikote-
> ma...@xilinx.com]
> 
> Can we do ${S}/config.mk ? Meaning
> sed -i 's/$(CROSS_COMPILE)ld$/$(CROSS_COMPILE)ld.bfd/g' ${S}/config.mk I
> dont have a setup for gold linker, If you can send the instructions I will 
> give it
> a try
> 
> Thanks
> Manju

That works. I have sent a patch.

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

[OE-core] [PATCH] Fix out of tree builds of u-boot with gold linker

2016-08-31 Thread Andrew Goodbody

Need to reference config.mk file in source tree which is no longer
the current directory when using out of tree builds.

Signed-off-by: Andrew Goodbody 
---
 meta/recipes-bsp/u-boot/u-boot.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-bsp/u-boot/u-boot.inc 
b/meta/recipes-bsp/u-boot/u-boot.inc
index 9e19c4f..915da8e 100644
--- a/meta/recipes-bsp/u-boot/u-boot.inc
+++ b/meta/recipes-bsp/u-boot/u-boot.inc
@@ -67,7 +67,7 @@ UBOOT_ENV_SYMLINK ?= 
"${UBOOT_ENV}-${MACHINE}.${UBOOT_ENV_SUFFIX}"
 
 do_compile () {
if [ "${@bb.utils.contains('DISTRO_FEATURES', 'ld-is-gold', 
'ld-is-gold', '', d)}" = "ld-is-gold" ] ; then
-   sed -i 's/$(CROSS_COMPILE)ld$/$(CROSS_COMPILE)ld.bfd/g' 
config.mk
+   sed -i 's/$(CROSS_COMPILE)ld$/$(CROSS_COMPILE)ld.bfd/g' 
${S}/config.mk
fi
 
unset LDFLAGS
-- 
2.7.4

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

Re: [OE-core] [PATCH] initscripts: Start devpts at 06 instead of 38

2016-08-31 Thread Mike Looijmans


On 31-08-16 15:22, Mike Looijmans wrote:

For example bootlogd needs devpts to be running, but bootlogd starts
at 07. Starting bootlogd early makes perfect sense, so the best option
here is to move devpts up to 06 to prevent this error message at boot:
cannot allocate pseudo tty: No such file or directory

Systems that have CONFIG_LEGACY_PTYS in the kernel will not see this
message. Since it is called "LEGACY" for a reason, fixing this in
userspace appears to be the better option here.

The devpts script does not need anything except a mounted "/dev" which
has been arranged in "S02sysfs.sh" already.


A second thought here: I was looking into the other scripts and I think it 
would make sense to just integrate the "devpts" script into "sysfs". The sysfs 
description already claims to "Mount initial set of virtual filesystems the 
kernel provides and that are required by everything." and devpts fits that 
description quite well.



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

[OE-core] [PATCH] initscripts: Start devpts at 06 instead of 38

2016-08-31 Thread Mike Looijmans

For example bootlogd needs devpts to be running, but bootlogd starts
at 07. Starting bootlogd early makes perfect sense, so the best option
here is to move devpts up to 06 to prevent this error message at boot:
cannot allocate pseudo tty: No such file or directory

Systems that have CONFIG_LEGACY_PTYS in the kernel will not see this
message. Since it is called "LEGACY" for a reason, fixing this in
userspace appears to be the better option here.

The devpts script does not need anything except a mounted "/dev" which
has been arranged in "S02sysfs.sh" already.

Signed-off-by: Mike Looijmans 
---
 meta/recipes-core/initscripts/initscripts_1.0.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-core/initscripts/initscripts_1.0.bb 
b/meta/recipes-core/initscripts/initscripts_1.0.bb
index 148491f..8f110b0 100644
--- a/meta/recipes-core/initscripts/initscripts_1.0.bb
+++ b/meta/recipes-core/initscripts/initscripts_1.0.bb
@@ -138,7 +138,7 @@ do_install () {
update-rc.d -r ${D} sysfs.sh start 02 S .
update-rc.d -r ${D} populate-volatile.sh start 37 S .
update-rc.d -r ${D} read-only-rootfs-hook.sh start 29 S .
-   update-rc.d -r ${D} devpts.sh start 38 S .
+   update-rc.d -r ${D} devpts.sh start 06 S .
if [ "${TARGET_ARCH}" = "arm" ]; then
update-rc.d -r ${D} alignment.sh start 06 S .
fi
-- 
1.9.1

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

[OE-core] cryptodev: Add backported patches for 4.6+ kernels

2016-08-31 Thread Richard Purdie

This allows 4.6 onward kernels to build, backported from upstream
master.

Signed-off-by: Richard Purdie 

diff --git a/meta/recipes-kernel/cryptodev/cryptodev.inc 
b/meta/recipes-kernel/cryptodev/cryptodev.inc
index ade7ef9..160ab30 100644
--- a/meta/recipes-kernel/cryptodev/cryptodev.inc
+++ b/meta/recipes-kernel/cryptodev/cryptodev.inc
@@ -3,7 +3,9 @@ HOMEPAGE = "http://cryptodev-linux.org/;
 LICENSE = "GPLv2"
 LIC_FILES_CHKSUM = "file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263"
 
-SRC_URI = 
"http://download.gna.org/cryptodev-linux/cryptodev-linux-${PV}.tar.gz;
+SRC_URI = 
"http://download.gna.org/cryptodev-linux/cryptodev-linux-${PV}.tar.gz \
+   file://06d6b560c6e45dc317dae47c74706fa43f4a31d8.patch \
+   file://cb186f682679383e8b5806240927903730ce85d9.patch"
 
 SRC_URI[md5sum] = "02644cc4cd02301e0b503a332eb2f0b5"
 SRC_URI[sha256sum] = 
"67fabde9fb67b286a96c4f45b594b0eccd0f761b495705c18f2ae9461b831376"
diff --git 
a/meta/recipes-kernel/cryptodev/files/06d6b560c6e45dc317dae47c74706fa43f4a31d8.patch
 
b/meta/recipes-kernel/cryptodev/files/06d6b560c6e45dc317dae47c74706fa43f4a31d8.patch
new file mode 100644
index 000..cb556e1
--- /dev/null
+++ 
b/meta/recipes-kernel/cryptodev/files/06d6b560c6e45dc317dae47c74706fa43f4a31d8.patch
@@ -0,0 +1,54 @@
+From f14b4706b0d04988e7e5bc8c4d2aefef9f029d9d Mon Sep 17 00:00:00 2001
+From: Michael Weiser 
+Date: Fri, 5 Aug 2016 18:43:55 +0200
+Subject: [PATCH] Adjust to recent user page API changes
+
+4.6.0 basically renamed get_user_pages() to get_user_pages_remote() and
+introduced a new get_user_pages() that always works on the current
+task.[1] Distinguish the two APIs based on kernel version we're
+compiling for.
+
+Also, there seems to have been a massive cleansing of
+page_cache_release(page) in favour of put_page(page)[2] which was an
+alias for put_page(page)[3] since 2.6.0. Before that beginning with
+2.4.0 both page_cache_release(page) and put_page(page) have been aliases
+for __free_page(page). So using put_page() instead of
+page_cache_release(page) will produce identical code for anything after
+2.4.0.
+
+[1] https://lkml.org/lkml/2016/2/10/555
+[2] https://www.spinics.net/lists/linux-fsdevel/msg95923.html
+[3] https://www.spinics.net/lists/linux-fsdevel/msg95922.html
+---
+ zc.c | 9 +++--
+ 1 file changed, 7 insertions(+), 2 deletions(-)
+
+Upstream-Status: Backport [from master for 4.8 kernels]
+
+Index: cryptodev-linux-1.8/zc.c
+===
+--- cryptodev-linux-1.8.orig/zc.c
 cryptodev-linux-1.8/zc.c
+@@ -59,7 +59,12 @@ int __get_userbuf(uint8_t __user *addr,
+   }
+ 
+   down_read(>mmap_sem);
+-  ret = get_user_pages(task, mm,
++#if (LINUX_VERSION_CODE >= KERNEL_VERSION(4, 6, 0))
++  ret = get_user_pages_remote(
++#else
++  ret = get_user_pages(
++#endif
++  task, mm,
+   (unsigned long)addr, pgcount, write, 0, pg, NULL);
+   up_read(>mmap_sem);
+   if (ret != pgcount)
+@@ -119,7 +124,7 @@ void release_user_pages(struct csession
+   else
+   ses->readonly_pages--;
+ 
+-  page_cache_release(ses->pages[i]);
++  put_page(ses->pages[i]);
+   }
+   ses->used_pages = 0;
+ }
diff --git 
a/meta/recipes-kernel/cryptodev/files/cb186f682679383e8b5806240927903730ce85d9.patch
 
b/meta/recipes-kernel/cryptodev/files/cb186f682679383e8b5806240927903730ce85d9.patch
new file mode 100644
index 000..eb0eab6
--- /dev/null
+++ 
b/meta/recipes-kernel/cryptodev/files/cb186f682679383e8b5806240927903730ce85d9.patch
@@ -0,0 +1,279 @@
+From cb186f682679383e8b5806240927903730ce85d9 Mon Sep 17 00:00:00 2001
+From: Michael Weiser 
+Date: Fri, 5 Aug 2016 17:26:27 +0200
+Subject: [PATCH] Support skcipher in addition to ablkcipher API
+
+The ablkcipher API is being phased out[1]. The unified skcipher API
+seems to have made its entry with 4.3.[3, 4] By what can be seen from
+migration patches[1.ff.], it's a drop-in replacement.
+
+Also, deallocators such as crypto_free_skcipher() are NULL-safe now[2].
+
+Add a new header cipherapi.h to aid migration from ablkcipher to skcipher and
+retain support for old kernels. Make it decide which API to use and provide
+appropriate function calls and type definitions. Since the ablkcipher and
+skcipher APIs are so similar, those are mainly defines for corresponding
+pseudo-functions in namespace cryptodev_ derived directly from their API
+counterparts.
+
+Compiles and works (i.e. checks pass) with Debian testing 4.6.4 kernel
+as well as 4.8-rc2+ Linus git tree as of today. (Both require a fix for
+changed page access API[5].)
+
+[1] https://www.spinics.net/lists/linux-crypto/msg18133.html
+[2] https://www.spinics.net/lists/linux-crypto/msg18154.html, line 120
+[3] https://www.spinics.net/lists/linux-crypto/msg16373.html
+[4]

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

2016-08-31 Thread Bruce Ashfield

On Wed, Aug 31, 2016 at 3:22 AM, Richard Purdie <
richard.pur...@linuxfoundation.org> wrote:

> On Tue, 2016-08-30 at 12:49 -0400, Bruce Ashfield wrote:
> > As of the 4.7 kernel qemuarm must be booted with a dtb. To allow
> > older and recent kernels to both boot qemuarm, we add the device
> > tree definitions only to recipes that need it (linux-yocto-dev)
> > and make runqemu detect and use the dtb if present.
> >
> > Signed-off-by: Bruce Ashfield 
> > ---
> >  scripts/runqemu-internal | 3 +++
> >  1 file changed, 3 insertions(+)
>
> This doesn't work with Roberts runqemu conversion to python.
>
> I did try adding http://git.yoctoproject.org/cgit.cgi/poky/commit/?h=ma
> ster-next=e91d7bf00bfab5142bc290425103971b897c208b however this
> requires the use of the dtb file and doesn't work with older kernels.
> I'll see if I can come up with something better based on kernel
> PREFERRED_VERSION...
>

Yah. I mentioned this one in my 0/N, I was working against the current
master
(I should just work against master-next for these .. mental note for next
time).


Bruce


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



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

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

2016-08-31 Thread Bruce Ashfield

On Wed, Aug 31, 2016 at 7:00 AM, Richard Purdie <
richard.pur...@linuxfoundation.org> wrote:

> Just to update I have:
>
> * Put a runqemu patch in master-next that works with new and old
>   kernels to handle the dtb issue
>

Hmm. I tested 4.4 and 4.8 with the ones that I did.


> * Updated the musl patches in libc-headers
>

ok. Ignore my previous email on this one!


> * Updated lttng-* to avoid build failures with 4.8
>

What were you seeing here ? I built lttng and didn't see the failure ..
I'm wondering if I was held back on 4.4 when I did those builds. I'll go
investigate,
since that is rather annoying as I was explicitly covering perf/lttng to
rule that out.

Bruce


> * Switched the default qemu kernel 4.4 -> 4.8 in poky so we get
>   testing of 4.8
>
> I'm waiting on the next build so see what issues remain from here.
>
> Cheers,
>
> Richard
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>



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

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

2016-08-31 Thread Bruce Ashfield

On Wed, Aug 31, 2016 at 3:19 AM, Richard Purdie <
richard.pur...@linuxfoundation.org> wrote:

> On Tue, 2016-08-30 at 12:49 -0400, Bruce Ashfield wrote:
> > Updating the libc-headers to use the 4.8 kernel as the default.
> >
> > Signed-off-by: Bruce Ashfield 
> > ---
> >  meta/conf/distro/include/tcmode-default.inc |  2 +-
> >  .../linux-libc-headers/linux-libc-headers_4.8.bb| 13
> > +
> >  2 files changed, 14 insertions(+), 1 deletion(-)
> >  create mode 100644 meta/recipes-kernel/linux-libc-headers/linux-libc
> > -headers_4.8.bb
>
> The musl patches fail to apply on the new version:
>
> https://autobuilder.yoctoproject.org/main/builders/poky-tiny/builds/928
> /steps/BuildImages/logs/stdio


I can drop those patches, but that's all that I can really offer, since
even if
I ported them, I don't build or test with musl.

What's the preference ? I do a "they apply" port, or just drop them until
someone
else who knows musl can do the port ?

Bruce


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



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

[OE-core] [PATCH v2 3/6] image: populate_sdk: deploy images to DEPLOYDIR

2016-08-31 Thread Ed Bartosh

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

Renamed variable deploy_dir to deploy_dir_image in selftest code
to avoid confusion with DEPLOYDIR variable.

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

Signed-off-by: Ed Bartosh 
---
 meta/classes/image-live.bbclass| 12 +++---
 meta/classes/image-vm.bbclass  | 22 +--
 meta/classes/image.bbclass |  6 +--
 meta/classes/image_types.bbclass   | 44 +++---
 meta/classes/image_types_uboot.bbclass |  2 +-
 meta/classes/populate_sdk_base.bbclass | 20 +-
 meta/classes/rootfs-postcommands.bbclass   |  4 +-
 meta/classes/syslinux.bbclass  |  2 +-
 meta/lib/oe/rootfs.py  |  6 +--
 meta/lib/oeqa/selftest/imagefeatures.py|  4 +-
 .../images/build-appliance-image_15.0.0.bb |  8 ++--
 11 files changed, 65 insertions(+), 65 deletions(-)

diff --git a/meta/classes/image-live.bbclass b/meta/classes/image-live.bbclass
index f0e6647..1294b11 100644
--- a/meta/classes/image-live.bbclass
+++ b/meta/classes/image-live.bbclass
@@ -43,7 +43,7 @@ ROOT_LIVE ?= "root=/dev/ram0"
 INITRD_IMAGE_LIVE ?= "core-image-minimal-initramfs"
 INITRD_LIVE ?= "${DEPLOY_DIR_IMAGE}/${INITRD_IMAGE_LIVE}-${MACHINE}.cpio.gz"
 
-ROOTFS ?= "${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.ext4"
+ROOTFS ?= "${DEPLOYDIR}/${IMAGE_LINK_NAME}.ext4"
 
 IMAGE_TYPEDEP_live = "ext4"
 IMAGE_TYPEDEP_iso = "ext4"
@@ -144,14 +144,14 @@ build_iso() {
if [ "${PCBIOS}" = "1" ] && [ "${EFI}" != "1" ] ; then
# PCBIOS only media
mkisofs -V ${BOOTIMG_VOLUME_ID} \
-   -o ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.iso \
+   -o ${DEPLOYDIR}/${IMAGE_NAME}.iso \
-b ${ISO_BOOTIMG} -c ${ISO_BOOTCAT} \
$mkisofs_compress_opts \
${MKISOFS_OPTIONS} $mkisofs_iso_level ${ISODIR}
else
# EFI only OR EFI+PCBIOS
mkisofs -A ${BOOTIMG_VOLUME_ID} -V ${BOOTIMG_VOLUME_ID} \
-   -o ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.iso \
+   -o ${DEPLOYDIR}/${IMAGE_NAME}.iso \
-b ${ISO_BOOTIMG} -c ${ISO_BOOTCAT} \
$mkisofs_compress_opts ${MKISOFS_OPTIONS} 
$mkisofs_iso_level \
-eltorito-alt-boot -eltorito-platform efi \
@@ -160,7 +160,7 @@ build_iso() {
isohybrid_args="-u"
fi
 
-   isohybrid $isohybrid_args ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.iso
+   isohybrid $isohybrid_args ${DEPLOYDIR}/${IMAGE_NAME}.iso
 }
 
 build_fat_img() {
@@ -252,13 +252,13 @@ build_hddimg() {
fi
fi
 
-   build_fat_img ${HDDDIR} ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.hddimg
+   build_fat_img ${HDDDIR} ${DEPLOYDIR}/${IMAGE_NAME}.hddimg
 
if [ "${PCBIOS}" = "1" ]; then
syslinux_hddimg_install
fi
 
-   chmod 644 ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.hddimg
+   chmod 644 ${DEPLOYDIR}/${IMAGE_NAME}.hddimg
fi
 }
 
diff --git a/meta/classes/image-vm.bbclass b/meta/classes/image-vm.bbclass
index bf57e2c..2a86b40 100644
--- a/meta/classes/image-vm.bbclass
+++ b/meta/classes/image-vm.bbclass
@@ -33,14 +33,14 @@ IMAGE_TYPEDEP_hdddirect = "${VM_ROOTFS_TYPE}"
 IMAGE_TYPES_MASKED += "vmdk vdi qcow2 hdddirect"
 
 VM_ROOTFS_TYPE ?= "ext4"
-ROOTFS ?= "${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.${VM_ROOTFS_TYPE}"
+ROOTFS ?= "${DEPLOYDIR}/${IMAGE_LINK_NAME}.${VM_ROOTFS_TYPE}"
 
 # Used by bootloader
 LABELS_VM ?= "boot"
 ROOT_VM ?= "root=/dev/sda2"
 # Using an initramfs is optional. Enable it by setting INITRD_IMAGE_VM.
 INITRD_IMAGE_VM ?= ""
-INITRD_VM ?= "${@'${DEPLOY_DIR_IMAGE}/${INITRD_IMAGE_VM}-${MACHINE}.cpio.gz' 
if '${INITRD_IMAGE_VM}' else ''}"
+INITRD_VM ?= "${@'${DEPLOYDIR}/${INITRD_IMAGE_VM}-${MACHINE}.cpio.gz' if 
'${INITRD_IMAGE_VM}' else ''}"
 do_bootdirectdisk[depends] += "${@'${INITRD_IMAGE_VM}:do_image_complete' if 
'${INITRD_IMAGE_VM}' else ''}"
 
 BOOTDD_VOLUME_ID   ?= "boot"
@@ -52,7 +52,7 @@ DISK_SIGNATURE[vardepsexclude] = "DISK_SIGNATURE_GENERATED"
 build_boot_dd() {
HDDDIR="${S}/hdd/boot"
HDDIMG="${S}/hdd.image"
-   IMAGE=${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.hdddirect
+   IMAGE=${DEPLOYDIR}/${IMAGE_NAME}.hdddirect
 
populate_kernel $HDDDIR
 
@@ -104,13 +104,13 @@ build_boot_dd() {
dd if=$HDDIMG of=$IMAGE conv=notrunc seek=1 bs=512
dd if=${ROOTFS} of=$IMAGE conv=notrunc seek=$OFFSET bs=512
 
-   cd ${DEPLOY_DIR_IMAGE}
+   cd ${DEPLOYDIR}
 
-   if [ "${RM_OLD_IMAGE}" = "1" ] &&

[OE-core] [PATCH v2 5/6] populate_sdk_base: put populate_sdk under sstate control

2016-08-31 Thread Ed Bartosh

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

Set stamp-extra-info flag for do_populate_sdk task. This flag is used
in the name of sstate manifest. Setting it to predetermined value for
populate_sdk task should help to get correct manifest filenames when
processing runQueueTask events.

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

diff --git a/meta/classes/populate_sdk_base.bbclass 
b/meta/classes/populate_sdk_base.bbclass
index 1b9aafc..40743a2 100644
--- a/meta/classes/populate_sdk_base.bbclass
+++ b/meta/classes/populate_sdk_base.bbclass
@@ -26,7 +26,7 @@ SDK_DIR = "${WORKDIR}/sdk"
 SDK_OUTPUT = "${SDK_DIR}/image"
 SDK_DEPLOY = "${DEPLOY_DIR}/sdk"
 
-DEPLOYDIR = "${SDK_DEPLOY}"
+DEPLOYDIR = "${WORKDIR}/deploy-${PN}-populate-sdk"
 
 B_task-populate-sdk = "${SDK_DIR}"
 
@@ -117,6 +117,11 @@ fakeroot python do_populate_sdk() {
 
 populate_sdk(d)
 }
+SSTATETASKS += "do_populate_sdk"
+SSTATE_SKIP_CREATION_task-populate-sdk = '1'
+do_populate_sdk[sstate-inputdirs] = "${DEPLOYDIR}"
+do_populate_sdk[sstate-outputdirs] = "${SDK_DEPLOY}"
+do_populate_sdk[stamp-extra-info] = "${MACHINE}"
 
 fakeroot create_sdk_files() {
cp ${COREBASE}/scripts/relocate_sdk.py ${SDK_OUTPUT}/${SDKPATH}/
-- 
2.1.4

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

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

2016-08-31 Thread Ed Bartosh

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

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

[YOCTO #9869]

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

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

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

[OE-core] [PATCH v2 4/6] image.bbclass: put image_complete under sstate control

2016-08-31 Thread Ed Bartosh

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

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

Set stamp-extra-info flag for do_image_complete task. This flag
is used in the name of sstate manifest. Setting it to predetermined
value for image_complete should help to get correct manifest
filenames when processing runQueueTask events.

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

diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index 2e75e70..9b6c739 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -74,7 +74,7 @@ IMAGE_INSTALL[type] = "list"
 export PACKAGE_INSTALL ?= "${IMAGE_INSTALL} ${ROOTFS_BOOTSTRAP_INSTALL} 
${FEATURE_INSTALL}"
 PACKAGE_INSTALL_ATTEMPTONLY ?= "${FEATURE_INSTALL_OPTIONAL}"
 
-DEPLOYDIR = "${DEPLOY_DIR_IMAGE}"
+DEPLOYDIR = "${WORKDIR}/deploy-${PN}-image-complete"
 
 # Images are generally built explicitly, do not need to be part of world.
 EXCLUDE_FROM_WORLD = "1"
@@ -264,6 +264,7 @@ fakeroot python do_image () {
 }
 do_image[dirs] = "${TOPDIR}"
 do_image[umask] = "022"
+do_image[cleandirs] = "${DEPLOYDIR}"
 addtask do_image after do_rootfs before do_build
 
 fakeroot python do_image_complete () {
@@ -275,6 +276,11 @@ fakeroot python do_image_complete () {
 }
 do_image_complete[dirs] = "${TOPDIR}"
 do_image_complete[umask] = "022"
+SSTATETASKS += "do_image_complete"
+SSTATE_SKIP_CREATION_task-image-complete = '1'
+do_image_complete[sstate-inputdirs] = "${DEPLOYDIR}"
+do_image_complete[sstate-outputdirs] = "${DEPLOY_DIR_IMAGE}"
+do_image_complete[stamp-extra-info] = "${MACHINE}"
 addtask do_image_complete after do_image before do_build
 
 # Add image-level QA/sanity checks to IMAGE_QA_COMMANDS
-- 
2.1.4

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

[OE-core] [PATCH v2 2/6] sstate.bbclass: skip packaging if SSTATE_SKIP_CREATION is set

2016-08-31 Thread Ed Bartosh

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

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

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

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

[OE-core] [PATCH v2 1/6] image: populate_sdk_base: add DEPLOYDIR variable

2016-08-31 Thread Ed Bartosh

This is a preparation for changing deployment directory for image
and populate_sdk targets.

Introduced new variable DEPLOYDIR. Set it to current image/sdk
deployment locations.

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

diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index c06dee2..b3dc689 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -74,6 +74,8 @@ IMAGE_INSTALL[type] = "list"
 export PACKAGE_INSTALL ?= "${IMAGE_INSTALL} ${ROOTFS_BOOTSTRAP_INSTALL} 
${FEATURE_INSTALL}"
 PACKAGE_INSTALL_ATTEMPTONLY ?= "${FEATURE_INSTALL_OPTIONAL}"
 
+DEPLOYDIR = "${DEPLOY_DIR_IMAGE}"
+
 # Images are generally built explicitly, do not need to be part of world.
 EXCLUDE_FROM_WORLD = "1"
 
diff --git a/meta/classes/populate_sdk_base.bbclass 
b/meta/classes/populate_sdk_base.bbclass
index 645a7f4..be731c0 100644
--- a/meta/classes/populate_sdk_base.bbclass
+++ b/meta/classes/populate_sdk_base.bbclass
@@ -26,6 +26,8 @@ SDK_DIR = "${WORKDIR}/sdk"
 SDK_OUTPUT = "${SDK_DIR}/image"
 SDK_DEPLOY = "${DEPLOY_DIR}/sdk"
 
+DEPLOYDIR = "${SDK_DEPLOY}"
+
 B_task-populate-sdk = "${SDK_DIR}"
 
 SDKTARGETSYSROOT = "${SDKPATH}/sysroots/${REAL_MULTIMACH_TARGET_SYS}"
-- 
2.1.4

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

[OE-core] [PATCH v2 0/6] Provide list of deployment artifacts

2016-08-31 Thread Ed Bartosh

Hi,

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

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

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

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

Changes in v2: Reorganized patchset to make it bisectable (Thanks Richard)
   Used task in the name of DEPLOYDIR to avoid using the same 
directory for different tasks of the same recipe

The following changes since commit 087c580b286816265f487e02746bfa6e26081554:

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

are available in the git repository at:

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

Ed Bartosh (6):
  image: populate_sdk_base: add DEPLOYDIR variable
  sstate.bbclass: skip packaging if SSTATE_SKIP_CREATION is set
  image: populate_sdk: deploy images to DEPLOYDIR
  image.bbclass: put image_complete under sstate control
  populate_sdk_base: put populate_sdk under sstate control
  toaster: fire TaskArtifacts event

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

-- 
2.1.4

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

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

2016-08-31 Thread Richard Purdie

Just to update I have:

* Put a runqemu patch in master-next that works with new and old 
  kernels to handle the dtb issue
* Updated the musl patches in libc-headers
* Updated lttng-* to avoid build failures with 4.8
* Switched the default qemu kernel 4.4 -> 4.8 in poky so we get 
  testing of 4.8

I'm waiting on the next build so see what issues remain from here.

Cheers,

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

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

2016-08-31 Thread Richard Purdie

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

We have a number of cp -a calls around. I'm not against fixing that but
for now I'm going to take the patch as I have bigger problems to deal
with.

Cheers,

Richard


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

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

2016-08-31 Thread Richard Purdie

On Wed, 2016-08-31 at 13:48 +1200, Paul Eggleton wrote:
> We should always shut down tinfoil when we're finished with it,
> either
> by explicitly calling the shutdown() method or by using it as a
> context manager ("with ...").

Could I trouble you to rebase this onto master-next please? It
currently has conflicts which didn't seem immediately obvious to me to
resolve.

Cheers,

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

[OE-core] [PATCH] gtk-doc: do not inherit perlnative and pythonnative

2016-08-31 Thread Alexander Kanavin

This avoids having the full paths of perl and python written
into gtk-doc scripts, which can trigger build failures and doesn't
work at all on targets.

Signed-off-by: Alexander Kanavin 
---
 meta/recipes-gnome/gtk-doc/gtk-doc_1.25.bb | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-gnome/gtk-doc/gtk-doc_1.25.bb 
b/meta/recipes-gnome/gtk-doc/gtk-doc_1.25.bb
index 0585ca9..79d4e43 100644
--- a/meta/recipes-gnome/gtk-doc/gtk-doc_1.25.bb
+++ b/meta/recipes-gnome/gtk-doc/gtk-doc_1.25.bb
@@ -5,8 +5,8 @@ HOMEPAGE = "http://www.gtk.org/gtk-doc/;
 LICENSE = "GPLv2"
 LIC_FILES_CHKSUM = "file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f"
 
-inherit gnomebase pythonnative perlnative
-DEPENDS_append = "libxslt xmlto source-highlight-native"
+inherit gnomebase
+DEPENDS_append = " libxslt xmlto source-highlight-native"
 EXTRA_OECONF_append = " --with-highlight=source-highlight"
 EXTRA_OECONF_append_class-native = " 
--with-xml-catalog=${sysconfdir}/xml/catalog.xml"
 
-- 
2.9.3

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

[OE-core] [PATCH] lttng-modules: Update 2.7.3 -> 2.8.0+master

2016-08-31 Thread Richard Purdie

We need master for the changes to work with 4.8 kernels.

Signed-off-by: Richard Purdie 

diff --git a/meta/recipes-kernel/lttng/lttng-modules_git.bb 
b/meta/recipes-kernel/lttng/lttng-modules_git.bb
index d8a7d36..96bd945 100644
--- a/meta/recipes-kernel/lttng/lttng-modules_git.bb
+++ b/meta/recipes-kernel/lttng/lttng-modules_git.bb
@@ -8,12 +8,12 @@ LIC_FILES_CHKSUM = 
"file://LICENSE;md5=362844633a08753bd96ab322a6c7f9f6 \
 
 inherit module
 
-SRCREV = "5362a1f26060e0d64464bb35cdd285c914ae6171"
-PV = "2.7.3+git${SRCPV}"
+SRCREV = "e36de50dd09527901339797a61a0a40d241c1a6d"
+PV = "2.8.0+git${SRCPV}"
 
 COMPATIBLE_HOST = '(x86_64|i.86|powerpc|aarch64|mips|nios2|arm).*-linux'
 
-SRC_URI = "git://git.lttng.org/lttng-modules.git;branch=stable-2.7"
+SRC_URI = "git://git.lttng.org/lttng-modules.git;branch=master"
 
 export INSTALL_MOD_DIR="kernel/lttng-modules"
 


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

[OE-core] [PATCH] lttng-tools: Update 2.7.1 -> 2.8.1

2016-08-31 Thread Richard Purdie

Drop backported patch.
Update ust configure option.
Update location of xml m4 file.

Signed-off-by: Richard Purdie 

diff --git a/meta/recipes-kernel/lttng/lttng-tools/stop-using-SIGUNUSED.patch 
b/meta/recipes-kernel/lttng/lttng-tools/stop-using-SIGUNUSED.patch
deleted file mode 100644
index bd4f7d1..000
--- a/meta/recipes-kernel/lttng/lttng-tools/stop-using-SIGUNUSED.patch
+++ /dev/null
@@ -1,51 +0,0 @@
-From 1f54181c2df1fb92c3323a6dbf8273fb66b883b6 Mon Sep 17 00:00:00 2001
-From: =?UTF-8?q?J=C3=A9r=C3=A9mie=20Galarneau?=
- 
-Date: Sat, 17 Oct 2015 19:41:47 -0400
-Subject: [PATCH] Port: Don't use SIGUNUSED which is not defined on Solaris
-MIME-Version: 1.0
-Content-Type: text/plain; charset=UTF-8
-Content-Transfer-Encoding: 8bit
-Organization: O.S. Systems Software LTDA.
-
-Upstream-Status: Backport [2.8.0]
-
-Signed-off-by: Jérémie Galarneau 

- src/common/runas.c | 18 +-
- 1 file changed, 5 insertions(+), 13 deletions(-)
-
-diff --git a/src/common/runas.c b/src/common/runas.c
-index 57f7382..0825470 100644
 a/src/common/runas.c
-+++ b/src/common/runas.c
-@@ -530,21 +530,13 @@ int run_as_rmdir_recursive(const char *path, uid_t uid, 
gid_t gid)
- static
- int reset_sighandler(void)
- {
--  int sig, ret = 0;
-+  int sig;
- 
--  for (sig = SIGHUP; sig <= SIGUNUSED; sig++) {
--  /* Skip unblockable signals. */
--  if (sig == SIGKILL || sig == SIGSTOP) {
--  continue;
--  }
--  if (signal(sig, SIG_DFL) == SIG_ERR) {
--  PERROR("reset signal %d", sig);
--  ret = -1;
--  goto end;
--  }
-+  DBG("Resetting run_as worker signal handlers to default");
-+  for (sig = 1; sig <= 31; sig++) {
-+  (void) signal(sig, SIG_DFL);
-   }
--end:
--  return ret;
-+  return 0;
- }
- 
- static
--- 
-2.6.2
-
diff --git a/meta/recipes-kernel/lttng/lttng-tools_git.bb 
b/meta/recipes-kernel/lttng/lttng-tools_git.bb
index fe1e2a3..e2f3032 100644
--- a/meta/recipes-kernel/lttng/lttng-tools_git.bb
+++ b/meta/recipes-kernel/lttng/lttng-tools_git.bb
@@ -13,8 +13,8 @@ DEPENDS = "liburcu popt libxml2"
 RDEPENDS_${PN} = "libgcc"
 RDEPENDS_${PN}-ptest += "make perl bash"
 
-SRCREV = "a90f2c1e10b759782653a81815625e9d1bbb75ca"
-PV = "2.7.1+git${SRCPV}"
+SRCREV = "d11e0dba0df9024b8613c51e167a379b91e8b20b"
+PV = "2.8.1+git${SRCPV}"
 
 PYTHON_OPTION = "am_cv_python_pyexecdir='${PYTHON_SITEPACKAGES_DIR}' \
  am_cv_python_pythondir='${PYTHON_SITEPACKAGES_DIR}' \
@@ -22,12 +22,11 @@ PYTHON_OPTION = 
"am_cv_python_pyexecdir='${PYTHON_SITEPACKAGES_DIR}' \
 "
 PACKAGECONFIG ??= "lttng-ust"
 PACKAGECONFIG[python] = "--enable-python-bindings ${PYTHON_OPTION},,python3 
swig-native"
-PACKAGECONFIG[lttng-ust] = "--enable-lttng-ust, --disable-lttng-ust, lttng-ust"
+PACKAGECONFIG[lttng-ust] = "--with-lttng-ust, --without-lttng-ust, lttng-ust"
 PACKAGECONFIG[kmod] = "--enable-kmod, --disable-kmod, kmod"
 PACKAGECONFIG_remove_libc-musl = "lttng-ust"
 
-SRC_URI = "git://git.lttng.org/lttng-tools.git;branch=stable-2.7 \
-   file://stop-using-SIGUNUSED.patch \
+SRC_URI = "git://git.lttng.org/lttng-tools.git;branch=stable-2.8 \
file://runtest-2.4.0.patch \
file://run-ptest"
 
@@ -51,7 +50,7 @@ INSANE_SKIP_${PN}-dbg = "libexec"
 
 do_configure_prepend () {
# Delete a shipped m4 file that overrides our patched one
-   rm -f ${S}/config/libxml.m4
+   rm -f ${S}/m4/libxml.m4
 }
 
 do_install_ptest () {


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

[OE-core] [PATCH] lttng-ust: Update 2.7.1 -> 2.8.1

2016-08-31 Thread Richard Purdie

Drop aarch64_be patch which is now upstream.
Update doc patch to apply to latest version.

Signed-off-by: Richard Purdie 

diff --git 
a/meta/recipes-kernel/lttng/lttng-ust/lttng-ust-add-support-for-aarch64_be.patch
 
b/meta/recipes-kernel/lttng/lttng-ust/lttng-ust-add-support-for-aarch64_be.patch
deleted file mode 100644
index 9b37a4a..000
--- 
a/meta/recipes-kernel/lttng/lttng-ust/lttng-ust-add-support-for-aarch64_be.patch
+++ /dev/null
@@ -1,17 +0,0 @@
-lttng-ust: add support for aarch64_be
-
-Upstream-Status: Pending
-
-Signed-off-by: Tudor Florea 
-
-diff --ruN a/configure.ac b/configure.ac
 a/configure.ac 2016-02-18 14:54:54.651713647 +0100
-+++ b/configure.ac 2016-02-18 14:56:11.057865297 +0100
-@@ -240,6 +240,7 @@
-   s390x) NO_UNALIGNED_ACCESS=1 ;;
- arm*) NO_UNALIGNED_ACCESS=1 ;;
-   aarch64) NO_UNALIGNED_ACCESS=1 ;;
-+aarch64_be) NO_UNALIGNED_ACCESS=1 ;;
-   mips*) NO_UNALIGNED_ACCESS=1 ;;
-   tile*) NO_UNALIGNED_ACCESS=1 ;;
-   *)
diff --git 
a/meta/recipes-kernel/lttng/lttng-ust/lttng-ust-doc-examples-disable.patch 
b/meta/recipes-kernel/lttng/lttng-ust/lttng-ust-doc-examples-disable.patch
index b68a989..caf0b8b 100644
--- a/meta/recipes-kernel/lttng/lttng-ust/lttng-ust-doc-examples-disable.patch
+++ b/meta/recipes-kernel/lttng/lttng-ust/lttng-ust-doc-examples-disable.patch
@@ -11,7 +11,7 @@ Index: doc/Makefile.am
 --- a/doc/Makefile.am
 +++ b/doc/Makefile.am
 @@ -1,4 +1,4 @@
--SUBDIRS = . examples
+-SUBDIRS = . man examples
 +SUBDIRS = .
  
  dist_man_MANS = man/lttng-gen-tp.1 \
diff --git a/meta/recipes-kernel/lttng/lttng-ust_git.bb 
b/meta/recipes-kernel/lttng/lttng-ust_git.bb
index f5a12b1..a642a32 100644
--- a/meta/recipes-kernel/lttng/lttng-ust_git.bb
+++ b/meta/recipes-kernel/lttng/lttng-ust_git.bb
@@ -18,13 +18,12 @@ RPROVIDES_${PN} = "lttng2-ust"
 RREPLACES_${PN} = "lttng2-ust"
 RCONFLICTS_${PN} = "lttng2-ust"
 
-SRCREV = "f89c1a3cf2b06a4970b9154c00ff6409870aefb5"
+SRCREV = "514a87f3b64181e384399935a5708a8f85b0cc83"
 PE = "2"
-PV = "2.7.1+git${SRCPV}"
+PV = "2.8.1+git${SRCPV}"
 
-SRC_URI = "git://git.lttng.org/lttng-ust.git;branch=stable-2.7 \
+SRC_URI = "git://git.lttng.org/lttng-ust.git;branch=stable-2.8 \
file://lttng-ust-doc-examples-disable.patch \
-   file://lttng-ust-add-support-for-aarch64_be.patch \
   "
 
 do_install_append() {


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

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

2016-08-31 Thread Andreas Müller

On Wed, Aug 31, 2016 at 11:25 AM, Jack Mitchell  wrote:
> On 30/08/16 18:14, Andreas Müller wrote:
>>
>> since gcc6 we see many cmake/c++ based packets failing with:
>>
>> | fatal error: stdlib.h: No such file or directory
>>
>> a fix from gcc is not to expect [1] so work around by replacing '-isystem'
>> by
>> '-I' for c++.
>>
>> Build tested with many recipes in meta-qt5-extra / meta-oe inheriting
>> cmake.
>>
>> [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70129
>>
>> Signed-off-by: Andreas Müller 
>> ---
>>  meta/recipes-devtools/cmake/cmake-native_3.6.1.bb  |  1 +
>>  .../0001-GNU.cmake-replace-isystem-by-I.patch  | 42
>> ++
>>  2 files changed, 43 insertions(+)
>>  create mode 100644
>> meta/recipes-devtools/cmake/cmake/0001-GNU.cmake-replace-isystem-by-I.patch
>>
>> diff --git a/meta/recipes-devtools/cmake/cmake-native_3.6.1.bb
>> b/meta/recipes-devtools/cmake/cmake-native_3.6.1.bb
>> index 33930fb..900091e 100644
>> --- a/meta/recipes-devtools/cmake/cmake-native_3.6.1.bb
>> +++ b/meta/recipes-devtools/cmake/cmake-native_3.6.1.bb
>> @@ -6,6 +6,7 @@ DEPENDS += "bzip2-native zlib-native"
>>
>>  SRC_URI += "\
>>  file://cmlibarchive-disable-ext2fs.patch \
>> +file://0001-GNU.cmake-replace-isystem-by-I.patch \
>>  "
>>
>>  # Disable ccmake since we don't depend on ncurses
>> diff --git
>> a/meta/recipes-devtools/cmake/cmake/0001-GNU.cmake-replace-isystem-by-I.patch
>> b/meta/recipes-devtools/cmake/cmake/0001-GNU.cmake-replace-isystem-by-I.patch
>> new file mode 100644
>> index 000..4c06490
>> --- /dev/null
>> +++
>> b/meta/recipes-devtools/cmake/cmake/0001-GNU.cmake-replace-isystem-by-I.patch
>> @@ -0,0 +1,42 @@
>> +From a84d20abe6bc68f8d1a597a22af1ca98d62a5ce4 Mon Sep 17 00:00:00 2001
>> +From: =?UTF-8?q?Andreas=20M=C3=BCller?= 
>> +Date: Fri, 26 Aug 2016 12:14:12 +0200
>> +Subject: [PATCH] GNU.cmake: replace -isystem by -I
>> +MIME-Version: 1.0
>> +Content-Type: text/plain; charset=UTF-8
>> +Content-Transfer-Encoding: 8bit
>> +
>> +since gcc6 we see many c++ based packes failing with:
>> +
>> +| fatal error: stdlib.h: No such file or directory
>> +
>> +a fix from gcc is not to expect [1] so work around
>> +
>> +[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70129
>> +
>> +Upstream-Status: Pending
>> +
>> +Signed-off-by: Andreas Müller 
>> +---
>> + Modules/Compiler/GNU.cmake | 6 +-
>> + 1 file changed, 5 insertions(+), 1 deletion(-)
>> +
>> +diff --git a/Modules/Compiler/GNU.cmake b/Modules/Compiler/GNU.cmake
>> +index c2d393d..9d1477d 100644
>> +--- a/Modules/Compiler/GNU.cmake
>>  b/Modules/Compiler/GNU.cmake
>> +@@ -53,6 +53,10 @@ macro(__compiler_gnu lang)
>> +   set(CMAKE_${lang}_CREATE_PREPROCESSED_SOURCE "
>>-E  > ")
>> +   set(CMAKE_${lang}_CREATE_ASSEMBLY_SOURCE "
>>-S  -o ")
>> +   if(NOT APPLE OR NOT CMAKE_${lang}_COMPILER_VERSION VERSION_LESS 4) #
>> work around #4462
>> +-set(CMAKE_INCLUDE_SYSTEM_FLAG_${lang} "-isystem ")
>> ++if("${lang}" STREQUAL "CXX")
>> ++  set(CMAKE_INCLUDE_SYSTEM_FLAG_${lang} "-I ")
>> ++else()
>> ++  set(CMAKE_INCLUDE_SYSTEM_FLAG_${lang} "-isystem ")
>> ++endif()
>> +   endif()
>> + endmacro()
>> +--
>> +2.5.5
>> +
>>
>
> Thanks for the patch Andreas, this fixes my build for now but as you
> mentioned is a bit of a hack to get round the issue. As this fixes my
> problem does it mean that it's not bitbake which is injecting the isystem,
> but instead a CMake recipe somewhere?
>
> Regards,
> Jack.
> --
I don't know your recipe but I think -isystem in bitbake.conf would
only cause trouble for native recipes.

As a heavy cmake-qt5 user (kde/lxqt/hawaii) I had many failing
cross-recipes not finding stdlib.h. After reading the gcc-bug I check
compile logs and they were full of -isystem on sysroot/usr/include -
had no idea where they came from.
First I grepped oe-core but did not find suspicious (e.g bitbake.conf
- see above). Then I grepped cmake sources and found GNU.cmake,
patched it to affect c++ only and my build errors were gone.

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

Re: [OE-core] State of bitbake world 2016-08-24

2016-08-31 Thread Trevor Woerner

On Fri 2016-08-26 @ 05:51:54 PM, Martin Jansa wrote:
> === common-x86 (1) ===
> * 
> meta-browser/recipes-browser/chromium/chromium-wayland_48.0.2548.0.bb:do_patch

It was pointed out to me that while re-organizing the chromium recipes I
dropped an important line in chromium-wayland. However this recipe didn't
succeed before and my goal was to make chromium (on x11) succeed. So even with
the fix I'm not sure chromium-wayland is going to be okay.

> === qemux86 (1) ===
> * 
> meta-browser/recipes-browser/chromium/chromium_52.0.2743.76.bb:do_compile

This one surprised me since I perform a chromium build every night on my CI
farm. Looking at your build logs I find:

| [2278/20239] CXX obj.host/third_party/icu/source/common/icuuc.servrbf.o
| FAILED: obj.host/third_party/icu/source/common/icuuc.servrbf.o
| g++  -MMD -MF obj.host/third_party/icu/source/common/icuuc.servrbf.o.d 
-DU_USING_ICU_NAMESPACE=0 -DHAVE_DLOPEN=0 -DUCONFIG_ONLY_HTML_CONVERSION=1 
-DU_CHARSET_IS_UTF8=1 -DV8_DEPRECATION_WARNINGS -D_FILE_OFFSET_BITS=64 
-DDISABLE_NACL -DU_STATIC_IMPLEMENTATION -DCHROMIUM_BUILD 
-DUI_COMPOSITOR_IMAGE_TRANSPORT -DUSE_AURA=1 -DUSE_PANGO=1 -DUSE_CAIRO=1 
-DUSE_DEFAULT_RENDER_THEME=1 -DUSE_LIBJPEG_TURBO=1 -DUSE_X11=1 
-DUSE_CLIPBOARD_AURAX11=1 -DENABLE_WEBRTC=1 -DENABLE_MEDIA_ROUTER=1 
-DENABLE_PEPPER_CDMS -DENABLE_NOTIFICATIONS -DENABLE_TOPCHROME_MD=1 -DUSE_UDEV 
-DFIELDTRIAL_TESTING_ENABLED -DENABLE_TASK_MANAGER=1 -DENABLE_EXTENSIONS=1 
-DENABLE_PDF=1 -DENABLE_PLUGINS=1 -DENABLE_SESSION_SERVICE=1 -DENABLE_THEMES=1 
-DENABLE_PRINTING=1 -DENABLE_BASIC_PRINTING=1 -DENABLE_PRINT_PREVIEW=1 
-DENABLE_SPELLCHECK=1 -DENABLE_CAPTIVE_PORTAL_DETECTION=1 
-DENABLE_SUPERVISED_USERS=1 -DENABLE_MDNS=1 -DENABLE_SERVICE_DISCOVERY=1 
-DFULL_SAFE_BROWSING -DSAFE_BROWSING_CSD -DSAFE_BROWSING_DB_LOCAL -DU_COMM
 ON_IMPLEMENTATION -DU_ICUDATAENTRY_IN_COMMON -DU_ENABLE_DYLOAD=0 -DU_NOEXCEPT= 
-DUSE_LIBPCI=1 -DUSE_GLIB=1 -DUSE_NSS_CERTS=1 -DNDEBUG -DNVALGRIND 
-DDYNAMIC_ANNOTATIONS_ENABLED=0 -I../../third_party/icu/source/common 
-I../../third_party/icu/source/i18n -Igen -fstack-protector 
--param=ssp-buffer-size=4  -pthread -fno-strict-aliasing -Wno-extra 
-Wno-unused-parameter -Wno-missing-field-initializers -fvisibility=hidden -pipe 
-fPIC -Wno-unused-local-typedefs -Wno-deprecated-declarations 
-Wno-unused-function -m32 -O2 -fno-ident -fdata-sections -ffunction-sections 
-funwind-tables -fno-exceptions -fno-rtti -fno-threadsafe-statics 
-fvisibility-inlines-hidden -frtti -Wno-deprecated -std=gnu++11 -Wno-narrowing  
-c ../../third_party/icu/source/common/servrbf.cpp -o 
obj.host/third_party/icu/source/common/icuuc.servrbf.o
| In file included from 
../../third_party/icu/source/common/unicode/std_string.h:33:0,
|  from ../../third_party/icu/source/common/unicode/unistr.h:31,
|  from 
../../third_party/icu/source/common/unicode/strenum.h:14,
|  from ../../third_party/icu/source/common/unicode/uenum.h:24,
|  from ../../third_party/icu/source/common/unicode/uloc.h:25,
|  from ../../third_party/icu/source/common/unicode/ures.h:27,
|  from 
../../third_party/icu/source/common/unicode/resbund.h:51,
|  from ../../third_party/icu/source/common/servrbf.cpp:13:
| /usr/include/c++/4.8/string:38:28: fatal error: bits/c++config.h: No such 
file or directory
|  #include 

Odd. It looks like your build is picking up your host's c++ compiler version
4.8 (?). The odd thing is, my build machine also does not have a
/usr/include/bits/c++config.h but my compile succeeds.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

2016-08-31 Thread Jack Mitchell


On 30/08/16 18:14, Andreas Müller wrote:

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

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

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

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

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

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

diff --git a/meta/recipes-devtools/cmake/cmake-native_3.6.1.bb 
b/meta/recipes-devtools/cmake/cmake-native_3.6.1.bb
index 33930fb..900091e 100644
--- a/meta/recipes-devtools/cmake/cmake-native_3.6.1.bb
+++ b/meta/recipes-devtools/cmake/cmake-native_3.6.1.bb
@@ -6,6 +6,7 @@ DEPENDS += "bzip2-native zlib-native"

 SRC_URI += "\
 file://cmlibarchive-disable-ext2fs.patch \
+file://0001-GNU.cmake-replace-isystem-by-I.patch \
 "

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



Thanks for the patch Andreas, this fixes my build for now but as you 
mentioned is a bit of a hack to get round the issue. As this fixes my 
problem does it mean that it's not bitbake which is injecting the 
isystem, but instead a CMake recipe somewhere?


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

[OE-core] pseudo 1.8.1 doesn't work with docker & dumb-init

2016-08-31 Thread wenzong fan


Hi Experts,

While I trying to build Yocto in Docker Container which using dumb-init 
as init system, I found the build always be stopped at some point and 
the container was terminated as well with below errors:


Child process timeout after 2 seconds.
Child process exit status 4: lock_held

Sometimes there's not any obvious error message.

After some `git bisect` testing, I believe the issue was started since 
commit:


--
9df3cdf42d8c1216682f497f0b166a43ef9f4184 is the first bad commit
commit 9df3cdf42d8c1216682f497f0b166a43ef9f4184
Author: Richard Purdie 
Date: Tue Jul 5 13:18:31 2016 +0100

pseudo: Upgrade to 1.8.1

* Drop patches where the changes exist upstream
* Fetch from git as no tarball is available for 1.8.1
* Move common code to pseudo.inc
* Update patchset in git recipe

(From OE-Core rev: 0c36984d4c501d12fa91cf7371511641585cc256)
---

Finally I narrowed it down to pseudo commit:


commit 77ee254a6c974aad9bcab2c58c9ee9e0880c9718
Author: Peter Seebach 
Date: Tue Mar 1 16:21:15 2016 -0600

Server launch reworking.

This is the big overhaul to have the server provide meaningful exit 
status

to clients.

In the process, I discovered that the server was running with 
signals blocked
if launched by a client, which is not a good thing, and prevented 
this from

working as intended.

Still looking to see why more than one server spawn seems to happen.


I also created a testcase for reproducing the issue at:

https://github.com/WenzongFan/docker-build-yocto

For dumb-init please refer to:

https://github.com/Yelp/dumb-init

Could anyone help to fix the signal handling in pseudo?


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

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

2016-08-31 Thread André Draszik

On Di, 2016-08-30 at 14:35 -0400, Bruce Ashfield wrote:
> Can you clarify for me if you are are using SRC_URI items tagged with
> 'kmeta', i.e. a directory of fragments, or are you just adding .cfg/.scc
> items directly to the SRC_URI ?

I do both:

in the 1st layer, my kernel recipe boils down to:

SRC_URI = "\

git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git;protocol=git;nocheckout=1;branch=${KBRANCH}
 \
file://0001-a-patch.patch \
file://kernel-meta;type=kmeta;destsuffix=${KMETA} \
"

KERNEL_FEATURES_append = " patches/some-patches.scc"
KERNEL_FEATURES_append = " patches/more-patches.scc"
KERNEL_FEATURES_append = " patches/even-more-patches.scc"

some of the above in turn include additional .scc items recursively.


In the 2nd layer, my .bbappend boils down to:

FILESEXTRAPATHS_prepend := "${THISDIR}/${BPN}-4.4:"

KERNEL_FEATURES_append_tgm = " patches/tgm.scc"

2nd-layer.scc is located in ${THISDIR}/kernel-meta/patches/ in the 2nd
layer. I don't specifically add another SRC_URI item tagged with 'kmeta' (or
any other explicit SRC_URI item for that matter).


Andre'

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

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

2016-08-31 Thread Jussi Kukkonen

Add patch to fix compile without libtasn headers.

Signed-off-by: Jussi Kukkonen 
---

Changes since v1:
* Add patch to fix compile without libtasn headers

Thanks,
 Jussi


 ...001-Use-correct-include-dir-with-minitasn.patch | 31 ++
 .../gnutls/{gnutls_3.5.1.bb => gnutls_3.5.3.bb}|  5 ++--
 2 files changed, 34 insertions(+), 2 deletions(-)
 create mode 100644 
meta/recipes-support/gnutls/gnutls/0001-Use-correct-include-dir-with-minitasn.patch
 rename meta/recipes-support/gnutls/{gnutls_3.5.1.bb => gnutls_3.5.3.bb} (50%)

diff --git 
a/meta/recipes-support/gnutls/gnutls/0001-Use-correct-include-dir-with-minitasn.patch
 
b/meta/recipes-support/gnutls/gnutls/0001-Use-correct-include-dir-with-minitasn.patch
new file mode 100644
index 000..d7dd7cf
--- /dev/null
+++ 
b/meta/recipes-support/gnutls/gnutls/0001-Use-correct-include-dir-with-minitasn.patch
@@ -0,0 +1,31 @@
+From 2651b08477f42dd7a05ea7d6df410fb2c46de4fb Mon Sep 17 00:00:00 2001
+From: Jussi Kukkonen 
+Date: Wed, 31 Aug 2016 11:04:06 +0300
+Subject: [PATCH] Use correct include dir with minitasn
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+This allows compiling certtool-cfg without libtasn headers.
+
+Upstream-Status: Submitted [https://gitlab.com/gnutls/gnutls/merge_requests/54]
+Signed-off-by: Jussi Kukkonen 
+---
+ src/Makefile.am | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/src/Makefile.am b/src/Makefile.am
+index 182f3a5..cf65388 100644
+--- a/src/Makefile.am
 b/src/Makefile.am
+@@ -146,6 +146,7 @@ libcmd_cli_debug_la_SOURCES = cli-debug-args.def 
cli-debug-args.c cli-debug-args
+ COMMON_LIBS = $(LIBOPTS) $(LTLIBINTL)
+ if ENABLE_MINITASN1
+ COMMON_LIBS += ../lib/minitasn1/libminitasn1.la ../gl/libgnu.la 
++AM_CPPFLAGS += -I$(top_srcdir)/lib/minitasn1
+ else
+ COMMON_LIBS += $(LIBTASN1_LIBS)
+ endif
+-- 
+2.9.3
+
diff --git a/meta/recipes-support/gnutls/gnutls_3.5.1.bb 
b/meta/recipes-support/gnutls/gnutls_3.5.3.bb
similarity index 50%
rename from meta/recipes-support/gnutls/gnutls_3.5.1.bb
rename to meta/recipes-support/gnutls/gnutls_3.5.3.bb
index 85d9904..1bdca6a 100644
--- a/meta/recipes-support/gnutls/gnutls_3.5.1.bb
+++ b/meta/recipes-support/gnutls/gnutls_3.5.3.bb
@@ -3,6 +3,7 @@ require gnutls.inc
 SRC_URI += "file://correct_rpl_gettimeofday_signature.patch \
 file://0001-configure.ac-fix-sed-command.patch \
 file://use-pkg-config-to-locate-zlib.patch \
+file://0001-Use-correct-include-dir-with-minitasn.patch \
"
-SRC_URI[md5sum] = "cb48bb0cf36d329f7321c6cdc0d7ae36"
-SRC_URI[sha256sum] = 
"bc4a0f80a627c3aca6e7ea59d30e50cda118c61e0e3fab367ff1451d6ec8bdbd"
+SRC_URI[md5sum] = "6c2c7f40ddf52933ee3ca474cb8cb63c"
+SRC_URI[sha256sum] = 
"92c4bc999a10a1b95299ebefaeea8333f19d8a98d957a35b5eae74881bdb1fef"
-- 
2.1.4

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

Re: [OE-core] [PATCH 00/28] Enable gtk-doc

2016-08-31 Thread Richard Purdie

On Fri, 2016-08-26 at 17:28 +0300, Alexander Kanavin wrote:
> This patchset adds gtk-doc support to OE-core. It requires running
> transient binaries during build time, which is achieved via qemu,
> and so there are all the same caveats as with gobject-introspection.
> 
> Gtk-doc generation happens if 'api-documentation' distro feature is
> enabled
> (it is by default), and 'qemu-usermode' is in machine features.
> Disable
> the former if api documentation is not needed in your distro; disable
> the latter
> if qemu does not work correctly for your target machine.
> 
> Gtk-doc support is a part of a broader task to enable API
> documentation
> support in OE-core; later on I will add support for doxygen and
> docbook, enable
> more manpages, and clean up the legacy SGML stack if possible.

There were a lot of similar look failures on the autobuilder:

http://errors.yoctoproject.org/Errors/Details/81392/
http://errors.yoctoproject.org/Errors/Details/81397/
http://errors.yoctoproject.org/Errors/Details/81393/
http://errors.yoctoproject.org/Errors/Details/81390/
http://errors.yoctoproject.org/Errors/Details/81391/
http://errors.yoctoproject.org/Errors/Details/81383/

Cheers,

Richard


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

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

2016-08-31 Thread sujith h

On Mon, Aug 29, 2016 at 6:17 PM, Alexander Kanavin <
alexander.kana...@linux.intel.com> wrote:

> On 08/29/2016 03:47 PM, Sujith H wrote:
>
>> From: Christopher Larson 
>>
>> rdoc gets unhappy if this already exists, so remove it before building.
>>
>> Without this, it's possible to hit this error:
>>
>> Directory .ext/rdoc already exists, but it looks like it isn't an RDoc
>> directory.
>>
>
> +
>> +do_compile_prepend () {
>> +rm -rf .ext/rdoc
>> +}
>>
>>
> The fix may be fixing the symptom and masking a different issue, have you
> checked when and how the error occurs?
>

Sorry for the confusion. We can ignore this patch. I did consulted with
Chris regarding the same. Again extremely sorry for confusion.


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



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

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

2016-08-31 Thread Richard Purdie

On Tue, 2016-08-30 at 12:49 -0400, Bruce Ashfield wrote:
> As of the 4.7 kernel qemuarm must be booted with a dtb. To allow
> older and recent kernels to both boot qemuarm, we add the device
> tree definitions only to recipes that need it (linux-yocto-dev)
> and make runqemu detect and use the dtb if present.
> 
> Signed-off-by: Bruce Ashfield 
> ---
>  scripts/runqemu-internal | 3 +++
>  1 file changed, 3 insertions(+)

This doesn't work with Roberts runqemu conversion to python.

I did try adding http://git.yoctoproject.org/cgit.cgi/poky/commit/?h=ma
ster-next=e91d7bf00bfab5142bc290425103971b897c208b however this
requires the use of the dtb file and doesn't work with older kernels.
I'll see if I can come up with something better based on kernel
PREFERRED_VERSION...

Cheers,

Richard

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

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

2016-08-31 Thread Richard Purdie

On Tue, 2016-08-30 at 12:49 -0400, Bruce Ashfield wrote:
> Updating the libc-headers to use the 4.8 kernel as the default.
> 
> Signed-off-by: Bruce Ashfield 
> ---
>  meta/conf/distro/include/tcmode-default.inc |  2 +-
>  .../linux-libc-headers/linux-libc-headers_4.8.bb| 13
> +
>  2 files changed, 14 insertions(+), 1 deletion(-)
>  create mode 100644 meta/recipes-kernel/linux-libc-headers/linux-libc
> -headers_4.8.bb

The musl patches fail to apply on the new version:

https://autobuilder.yoctoproject.org/main/builders/poky-tiny/builds/928
/steps/BuildImages/logs/stdio

Cheers,

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

Re: [OE-core] [PATCH 09/15] kexec-tools: update to 2.0.13

2016-08-31 Thread Robert Yang


Hello,

It seems that this one causes build errors on arm AFAIK:

https://autobuilder.yoctoproject.org/main/builders/nightly-arm/builds/933/steps/BuildImages/logs/stdio

// Robert

On 08/29/2016 10:30 PM, Alexander Kanavin wrote:

Signed-off-by: Alexander Kanavin 
---
 .../kexec/{kexec-tools_2.0.12.bb => kexec-tools_2.0.13.bb}| 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-kernel/kexec/{kexec-tools_2.0.12.bb => 
kexec-tools_2.0.13.bb} (88%)

diff --git a/meta/recipes-kernel/kexec/kexec-tools_2.0.12.bb 
b/meta/recipes-kernel/kexec/kexec-tools_2.0.13.bb
similarity index 88%
rename from meta/recipes-kernel/kexec/kexec-tools_2.0.12.bb
rename to meta/recipes-kernel/kexec/kexec-tools_2.0.13.bb
index 59376c8..338a7d9 100644
--- a/meta/recipes-kernel/kexec/kexec-tools_2.0.12.bb
+++ b/meta/recipes-kernel/kexec/kexec-tools_2.0.13.bb
@@ -10,8 +10,8 @@ SRC_URI += " \
 file://0001-vmcore-dmesg-Define-_GNU_SOURCE.patch \
  "

-SRC_URI[md5sum] = "10ddaae0e86af54407b164a1f5a39cc3"
-SRC_URI[sha256sum] = 
"cc7b60dad0da202004048a6179d8a53606943062dd627a2edba45a8ea3a85135"
+SRC_URI[md5sum] = "b7595eb4705e482ee6fc1121a5b6131b"
+SRC_URI[sha256sum] = 
"70df562d76213e54833228379710ada1afd98a86ee1ce5644eaa68c54e102e25"

 PACKAGES =+ "kexec kdump vmcore-dmesg"



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

52 matches

Mail list logo