Re: [OE-core] [PATCH] libxml2: 2.9.4 -> 2.9.5

2017-09-05 Thread Andrej Valek
I have created a PR:
https://github.com/openembedded/openembedded-core/pull/23 as last time.

Andrej

On 09/05/2017 08:52 PM, Burton, Ross wrote:
> Also the patch has been corrupted by SMTP.  Is it in a branch somewhere?
> 
> Ross
> 
> On 5 September 2017 at 18:28, Andrej Valek  > wrote:
> 
> Hi Ross,
> 
> There are not any CVEs fixes which has not been already merged. There
> are only general changes. Of course, we can "clean" a lot of patches by
> accepting this.
> 
> Regards,
> Andrej
> 
> On 09/05/2017 11:19 AM, Burton, Ross wrote:
> > On 5 September 2017 at 07:35, Andrej Valek  
> > >> 
> wrote:
> >
> > Signed-off-by: Andrej Valek  
>  >  >>
>  >
>  >
>  > We're past freeze to the upgrade will have to wait until 2.4 releases.
> Does this
>  > fix any outstanding CVEs that we should be cherry-picking?
>  >
>  > Ross
>  >
> 
> 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH 2/2] python3-setuptools: extend to nativesdk

2017-09-05 Thread Chen Qi
Extend python3-setuptools to nativesdk because nativesdk-python3-pip needs
it.

Also, adjust RDEPENDS variable setting to keep the runtime dependencies
for nativesdk package the same with the target one. The native package and
the target package's dependencies remain the same as before.

Signed-off-by: Chen Qi 
---
 meta/recipes-devtools/python/python3-setuptools_36.2.7.bb | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-devtools/python/python3-setuptools_36.2.7.bb 
b/meta/recipes-devtools/python/python3-setuptools_36.2.7.bb
index 65af6f0..63f2418 100644
--- a/meta/recipes-devtools/python/python3-setuptools_36.2.7.bb
+++ b/meta/recipes-devtools/python/python3-setuptools_36.2.7.bb
@@ -2,6 +2,7 @@ require python-setuptools.inc
 
 DEPENDS += "python3"
 DEPENDS_class-native += "python3-native"
+DEPENDS_class-nativesdk += "nativesdk-python3"
 
 inherit distutils3
 
@@ -14,11 +15,11 @@ do_install_append() {
 echo "./${SRCNAME}-${PV}-py${PYTHON_BASEVERSION}.egg" > 
${D}${PYTHON_SITEPACKAGES_DIR}/setuptools.pth
 }
 
-RDEPENDS_${PN} = "\
+RDEPENDS_${PN}_class-native = "\
   python3-distutils \
   python3-compression \
 "
-RDEPENDS_${PN}_class-target = "\
+RDEPENDS_${PN} = "\
   python3-ctypes \
   python3-distutils \
   python3-email \
@@ -34,4 +35,4 @@ RDEPENDS_${PN}_class-target = "\
   python3-unittest \
   python3-xml \
 "
-BBCLASSEXTEND = "native"
+BBCLASSEXTEND = "native nativesdk"
-- 
1.9.1

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


[OE-core] [PATCH 1/2] python3-pip: extend to nativesdk

2017-09-05 Thread Chen Qi
Extend python3-pip to nativesdk because some nativesdk python3 packages
need it, e.g. nativesdk-python3-django from meta-python layer.

Signed-off-by: Chen Qi 
---
 meta/recipes-devtools/python/python3-pip_9.0.1.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/python/python3-pip_9.0.1.bb 
b/meta/recipes-devtools/python/python3-pip_9.0.1.bb
index 4456b9b..9b907a2 100644
--- a/meta/recipes-devtools/python/python3-pip_9.0.1.bb
+++ b/meta/recipes-devtools/python/python3-pip_9.0.1.bb
@@ -53,4 +53,4 @@ RDEPENDS_${PN} = "\
   python3-xmlrpc \
 "
 
-BBCLASSEXTEND = "native"
+BBCLASSEXTEND = "native nativesdk"
-- 
1.9.1

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


[OE-core] [PATCH 0/2] python3-pip & python3-setuptools: extend to nativesdk

2017-09-05 Thread Chen Qi
The following changes since commit 8b4f16a9cbbaf521461f699b7264fac2ac872581:

  mesa-gl: Fix build after recent mesa PACKAGECONFIG changes (2017-09-05 
15:01:02 +0100)

are available in the git repository at:

  git://git.pokylinux.org/poky-contrib ChenQi/python3-nativesdk
  http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=ChenQi/python3-nativesdk

Chen Qi (2):
  python3-pip: extend to nativesdk
  python3-setuptools: extend to nativesdk

 meta/recipes-devtools/python/python3-pip_9.0.1.bb | 2 +-
 meta/recipes-devtools/python/python3-setuptools_36.2.7.bb | 7 ---
 2 files changed, 5 insertions(+), 4 deletions(-)

-- 
1.9.1

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


Re: [OE-core] [PATCH 1/1] dbus: fix ptest runtime failures

2017-09-05 Thread Kang Kai

On 2017年09月05日 18:01, Burton, Ross wrote:
On 5 September 2017 at 04:13, > wrote:


+PACKAGECONFIG[ptest] = "--enable-embedded-tests --enable-asserts
--enable-verbose-mode,--disable-embedded-tests --disable-asserts
--disable-verbose-mode"


Same question with V2: does enabling ptest change the dbus daemon in 
ways that make it slower/less secure/etc.


Unfortunately, yes, it affects performace of dbus-daemon. It checks 
macro DBUS_ENABLE_EMBEDDED_TESTS to add some test codes.
I doubt whether has someone deploy image with ptest feature to 
production environment.


It seems dbus is so fundamental that affect too much. But without them, 
ptest cases can not PASS. Confusing.



--Kai



Ross



--
Regards,
Neil | Kai Kang

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


Re: [OE-core] [PATCH 6/7] go.bbclass: Enable parallel build

2017-09-05 Thread Otavio Salvador
On Tue, Sep 5, 2017 at 5:06 PM, Matt Madison  wrote:
> I thought that GO_PARALLEL_BUILD still needs to be added to
> BB_HASHBASE_WHITELIST like PARALLEL_MAKE is,
> or the task signatures will be different between builds done on
> systems with different CPU counts?

You're right. Added it to v3 but will wait until tomorrow to see if
someone provides any more feedback before sending the changes.

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


[OE-core] [PATCH v2] systemtap: Bump SRCREV for 4.12 Linux kernel support

2017-09-05 Thread Saul Wold
This SRCREV bump brings in support for the 4.12 Linux Kernel, this kernel
also has some newer CONFIG settings. The newer DEBUG_INFO and DEBUG_INFO_DWARF4
settings can be used with systemtap to get the full information.  We do not
normally enabled these for a 'production' (standard) kernel, but can be
enabled via menuconfig.

When installing staprun and stapbpf on the target and native ensure we
don't try to create a new group and chown it.  There is no need since we
will be running as root, so we add a patch to comment that code out.

Signed-off-by: Saul Wold 
---
 ...apbpf-don-t-support-installing-a-non-root.patch | 62 ++
 meta/recipes-kernel/systemtap/systemtap_git.inc|  5 +-
 2 files changed, 65 insertions(+), 2 deletions(-)
 create mode 100644 
meta/recipes-kernel/systemtap/systemtap/0001-staprun-stapbpf-don-t-support-installing-a-non-root.patch

diff --git 
a/meta/recipes-kernel/systemtap/systemtap/0001-staprun-stapbpf-don-t-support-installing-a-non-root.patch
 
b/meta/recipes-kernel/systemtap/systemtap/0001-staprun-stapbpf-don-t-support-installing-a-non-root.patch
new file mode 100644
index 000..9f11648fefd
--- /dev/null
+++ 
b/meta/recipes-kernel/systemtap/systemtap/0001-staprun-stapbpf-don-t-support-installing-a-non-root.patch
@@ -0,0 +1,62 @@
+From 3e13a006fe3dff9489269274093bf868532036e2 Mon Sep 17 00:00:00 2001
+From: Saul Wold 
+Date: Tue, 5 Sep 2017 16:02:55 -0700
+Subject: [PATCH] staprun/stapbpf: don't support installing a non-root
+
+Since we are in a known environment and installing as root and
+expect to be running as root, don't create the group or chmod
+the binaries.
+
+Upstream-Status: Inappropriate [Embedded]
+Signed-off-by: Saul Wold 
+---
+ stapbpf/Makefile.am | 14 +++---
+ staprun/Makefile.am | 12 ++--
+ 2 files changed, 13 insertions(+), 13 deletions(-)
+
+diff --git a/stapbpf/Makefile.am b/stapbpf/Makefile.am
+index 421b044ef..f7daeb2b2 100644
+--- a/stapbpf/Makefile.am
 b/stapbpf/Makefile.am
+@@ -39,11 +39,11 @@ git_version.stamp ../git_version.h:
+ 
+ # Why the "id -u" condition?  This way, an unprivileged user can run
+ # make install, and have "sudo stap " or "sudo stapbpf " work later.
+-install-exec-hook:
+-  if [ `id -u` -eq 0 ]; then \
+-  getent group stapusr >/dev/null || groupadd -g 156 -r stapusr 
2>/dev/null || groupadd -r stapusr; \
+-  getent group stapusr >/dev/null \
+-  && chgrp stapusr "$(DESTDIR)$(bindir)/stapbpf" \
+-  && chmod 04110 "$(DESTDIR)$(bindir)/stapbpf"; \
+-  fi
++#install-exec-hook:
++# if [ `id -u` -eq 0 ]; then \
++# getent group stapusr >/dev/null || groupadd -g 156 -r stapusr 
2>/dev/null || groupadd -r stapusr; \
++# getent group stapusr >/dev/null \
++# && chgrp stapusr "$(DESTDIR)$(bindir)/stapbpf" \
++# && chmod 04110 "$(DESTDIR)$(bindir)/stapbpf"; \
++# fi
+ endif
+diff --git a/staprun/Makefile.am b/staprun/Makefile.am
+index 4073aa01c..2925e34c3 100644
+--- a/staprun/Makefile.am
 b/staprun/Makefile.am
+@@ -72,9 +72,9 @@ git_version.stamp ../git_version.h:
+ 
+ # Why the "id -u" condition?  This way, an unprivileged user can run
+ # make install, and have "sudo stap " or "sudo staprun " work later.
+-install-exec-hook:
+-  if [ `id -u` -eq 0 ]; then \
+-  getent group stapusr >/dev/null || groupadd -g 156 -r stapusr 
2>/dev/null || groupadd -r stapusr; \
+-  getent group stapusr >/dev/null && chgrp stapusr 
"$(DESTDIR)$(bindir)/staprun"; \
+-  chmod 04110 "$(DESTDIR)$(bindir)/staprun"; \
+-  fi
++#install-exec-hook:
++# if [ `id -u` -eq 0 ]; then \
++# getent group stapusr >/dev/null || groupadd -g 156 -r stapusr 
2>/dev/null || groupadd -r stapusr; \
++# getent group stapusr >/dev/null && chgrp stapusr 
"$(DESTDIR)$(bindir)/staprun"; \
++# chmod 04110 "$(DESTDIR)$(bindir)/staprun"; \
++# fi
+-- 
+2.11.0
+
diff --git a/meta/recipes-kernel/systemtap/systemtap_git.inc 
b/meta/recipes-kernel/systemtap/systemtap_git.inc
index a6aedd38a6e..3dc688a18fe 100644
--- a/meta/recipes-kernel/systemtap/systemtap_git.inc
+++ b/meta/recipes-kernel/systemtap/systemtap_git.inc
@@ -1,6 +1,6 @@
 LICENSE = "GPLv2"
 LIC_FILES_CHKSUM = "file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263"
-SRCREV = "b8ea350dc13adb6190d9044a5b80110a4c441270"
+SRCREV = "45d0e7a09a15a21078d0ebf2db5175ed9e87014e"
 PV = "3.1"
 
 SRC_URI = "git://sourceware.org/git/systemtap.git \
@@ -12,7 +12,8 @@ SRC_URI = "git://sourceware.org/git/systemtap.git \

file://0001-Do-not-let-configure-write-a-python-location-into-th.patch \
file://0001-Install-python-modules-to-correct-library-dir.patch \
file://0001-buildrun-remove-quotes-around-I-include-line.patch \
-  "
+   
file://0001-staprun-stapbpf-don-t-support-installing-a-non-root.patch \
+   "
 
 # systemtap doesn

Re: [OE-core] [yocto] Yocto Project Status WW35’17

2017-09-05 Thread Philip Balister
And do not forget the OpenEmbedded Developer Meeting in Prague before ELCE:

https://www.openembedded.org/wiki/OEDEM_2017

Philip

On 08/28/2017 10:42 AM, Jolley, Stephen K wrote:
> Current Dev Position: YP 2.4 M3
> 
> Next Deadline: YP 2.4 M3 (In QA)
> 
> 
> SWAT team rotation: Paul -> Todor on Aug. 25, 2017.
> 
> SWAT team rotation: Todor -> Tracy on Aug. 18, 2017.
> 
> https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team
> 
> 
> Key Status/Updates:
> 
> ·We’ve reached feature freeze for 2.4 and the M3 rc1 build is in QA.  
> See: https://wiki.yoctoproject.org/wiki/2.4_QA_Status
> 
> ·Some things did not make 2.4. In particular, the python manifest 
> rework didn’t, nor did the multiple kernels work or the switch to pkgconf by 
> default. These patchsets were too late in the cycle and potentially caused 
> too many issues. I’ve started queueing some things on master-next-2.5 in the 
> meantime.
> 
> ·We’ve continued to struggle with various autobuilder reported 
> failures although current master appears to be working better than we’ve had 
> things for a while.
> 
> ·Some fixes were merged for the bitbake server reconnection issues 
> and this should remove the traceback many people were seeing and generally 
> clean up some of the behavior for reconnections.
> 
> ·There were some staging.bbclass fixes that have recently merged 
> which allow the system to cope much better with changing things like the 
> pkgconfig provider.
> 
> 
> Planned upcoming dot releases:
> 
> YP 2.2.2 Cut off June 5, 2017 - Not ready to do an rc2 yet.
> 
> YP 2.2.2 Release by June, 16 2017
> 
> YP 2.3.2 Cut off Sept. 1, 2017
> 
> YP 2.3.2 Release by Sept. 15, 2017
> 
> 
> Key YP 2.4 Dates are:
> 
> YP 2.4 M3 Cut off is Aug. 21, 2017 (In QA)
> 
> YP 2.4 M3 Release by Sept. 1, 2017
> 
> YP 2.4 M4 (Final) Cut off is Sept. 18, 2017
> 
> YP 2.4 M4 (Final) Release by Oct. 20, 2017
> 
> 
> Tracking Metrics:
> 
> WDD 2504 (last week 2476)
> 
> (https://wiki.yoctoproject.org/charts/combo.html)
> 
> 
> Key Status Links for YP:
> 
> https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.4_Status
> 
> https://wiki.yoctoproject.org/wiki/Yocto_2.4_Schedule
> 
> https://wiki.yoctoproject.org/wiki/Yocto_2.4_Features
> 
> 
> [If anyone has suggestions for other information you’d like to see on this 
> weekly status update, let us know!]
> 
> 
> Thanks,
> 
> Stephen K. Jolley
> Yocto Project Program Manager
> INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124
> •   Work Telephone:(503) 712-0534
> •Cell:   (208) 244-4460
> • Email:  stephen.k.jol...@intel.com
> 
> 
> 
> 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] iproute2 - meta-openembedded/libmnl and Yocto Project compat

2017-09-05 Thread Mark Hatle
The patch to oe-core:

commit 944ef0de241de77429ab0e5cb1dd4a7f355cf3fd
Author: Yi Zhao 
Date:   Tue Aug 15 15:38:36 2017 +0800

iproute2: add tipc support

added tipc support.  This is part of the work that originated in
meta-openembedded.  However, the default of enabling tipc was not done as it
requires libmnl, which is only available meta-networking... and we didn't catch
this until after feature freeze.

So in meta-openembedded -- there is a single .bbappend to iproute2 that sets
PACKAGECONFIG_append = " tipc"

(Without this change, the tipc-utils fails to build, because it requires
iproute2-tipc.  Unfortunately there is no way for tipc-utils to check the
configuration of iproute2 to make this dependency required or not.)

This works -- but this type of thing is forbidden in the yocto-compat-layer.py
script.

The only way I can see to resolve this issue is to move libmnl into oe-core, as
well as make the tipc setting the default for iproute2.

I'm open to alternatives, but I'm kind of stuck here otherwise.

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


Re: [OE-core] [PATCH] systemtap: Bump SRCREV for 4.12 Linux kernel support

2017-09-05 Thread Wold, Saul
On Tue, 2017-09-05 at 13:22 -0700, Saul Wold wrote:
> This SRCREV bump brings in support for the 4.12 Linux Kernel, this
> kernel
> also has some newer CONFIG settings. The newer DEBUG_INFO and
> DEBUG_INFO_DWARF4
> settings can be used with systemtap to get the full information.  We
> do not
> normally enabled these for a 'production' (standard) kernel, but can
> be
> enabled via menuconfig.
> 
> Signed-off-by: Saul Wold 
Put a hold on this patch, I found an issue with a partial failure
during the install phase which did not cause an error to be thrown so
it completed!

Sau!

> ---
>  meta/recipes-kernel/systemtap/systemtap_git.inc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meta/recipes-kernel/systemtap/systemtap_git.inc
> b/meta/recipes-kernel/systemtap/systemtap_git.inc
> index a6aedd38a6..ea2d2c0d1d 100644
> --- a/meta/recipes-kernel/systemtap/systemtap_git.inc
> +++ b/meta/recipes-kernel/systemtap/systemtap_git.inc
> @@ -1,6 +1,6 @@
>  LICENSE = "GPLv2"
>  LIC_FILES_CHKSUM =
> "file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263"
> -SRCREV = "b8ea350dc13adb6190d9044a5b80110a4c441270"
> +SRCREV = "45d0e7a09a15a21078d0ebf2db5175ed9e87014e"
>  PV = "3.1"
>  
>  SRC_URI = "git://sourceware.org/git/systemtap.git \
> -- 
> 2.11.0
> 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH] systemtap: Bump SRCREV for 4.12 Linux kernel support

2017-09-05 Thread Saul Wold
This SRCREV bump brings in support for the 4.12 Linux Kernel, this kernel
also has some newer CONFIG settings. The newer DEBUG_INFO and DEBUG_INFO_DWARF4
settings can be used with systemtap to get the full information.  We do not
normally enabled these for a 'production' (standard) kernel, but can be
enabled via menuconfig.

Signed-off-by: Saul Wold 
---
 meta/recipes-kernel/systemtap/systemtap_git.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-kernel/systemtap/systemtap_git.inc 
b/meta/recipes-kernel/systemtap/systemtap_git.inc
index a6aedd38a6..ea2d2c0d1d 100644
--- a/meta/recipes-kernel/systemtap/systemtap_git.inc
+++ b/meta/recipes-kernel/systemtap/systemtap_git.inc
@@ -1,6 +1,6 @@
 LICENSE = "GPLv2"
 LIC_FILES_CHKSUM = "file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263"
-SRCREV = "b8ea350dc13adb6190d9044a5b80110a4c441270"
+SRCREV = "45d0e7a09a15a21078d0ebf2db5175ed9e87014e"
 PV = "3.1"
 
 SRC_URI = "git://sourceware.org/git/systemtap.git \
-- 
2.11.0

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


Re: [OE-core] [PATCH 6/7] go.bbclass: Enable parallel build

2017-09-05 Thread Matt Madison
On Tue, Sep 5, 2017 at 7:49 AM, Otavio Salvador
 wrote:
> On Tue, Sep 5, 2017 at 7:50 AM, Matt Madison  wrote:
>> On Mon, Sep 4, 2017 at 2:06 PM, Otavio Salvador  
>> wrote:
>>> The parallel build is based on PARALLEL_MAKE variable but can be
>>> overriden setting the GO_PARALLEL_BUILD one.
>>>
>>> This change is based on the meta-golang[1] layer. Thanks to Matt
>>> Madison  for his work on this.
>>>
>>> 1. https://github.com/madisongh/meta-golang
>>>
>>> Signed-off-by: Otavio Salvador 
>>> ---
>>>
>>>  meta/classes/go.bbclass | 20 
>>>  1 file changed, 20 insertions(+)
>>>
>>> diff --git a/meta/classes/go.bbclass b/meta/classes/go.bbclass
>>> index 45f2add810..f80134bf8e 100644
>>> --- a/meta/classes/go.bbclass
>>> +++ b/meta/classes/go.bbclass
>>> @@ -1,11 +1,31 @@
>>>  inherit goarch
>>>
>>> +def get_go_parallel_make(d):
>>> +pm = (d.getVar('PARALLEL_MAKE') or '').split()
>>> +# look for '-j' and throw other options (e.g. '-l') away
>>> +# because they might have a different meaning in golang
>>> +while pm:
>>> +opt = pm.pop(0)
>>> +if opt == '-j':
>>> +v = pm.pop(0)
>>> +elif opt.startswith('-j'):
>>> +v = opt[2:].strip()
>>> +else:
>>> +continue
>>> +
>>> +return '-p %d' % int(v)
>>> +
>>> +return ""
>>> +
>>> +GO_PARALLEL_BUILD ?= "${@get_go_parallel_make(d)}"
>>
>> This added variable should be appended to BB_HASHBASE_WHITELIST.
>
> I think should not use new variables. We base it on PARALLEL_MAKE so
> the user can control it in local.conf if needed.

I thought that GO_PARALLEL_BUILD still needs to be added to
BB_HASHBASE_WHITELIST like PARALLEL_MAKE is,
or the task signatures will be different between builds done on
systems with different CPU counts?

-Matt

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


Re: [OE-core] [PATCH] libxml2: 2.9.4 -> 2.9.5

2017-09-05 Thread Burton, Ross
Also the patch has been corrupted by SMTP.  Is it in a branch somewhere?

Ross

On 5 September 2017 at 18:28, Andrej Valek  wrote:

> Hi Ross,
>
> There are not any CVEs fixes which has not been already merged. There
> are only general changes. Of course, we can "clean" a lot of patches by
> accepting this.
>
> Regards,
> Andrej
>
> On 09/05/2017 11:19 AM, Burton, Ross wrote:
> > On 5 September 2017 at 07:35, Andrej Valek  > > wrote:
> >
> > Signed-off-by: Andrej Valek  > >
> >
> >
> > We're past freeze to the upgrade will have to wait until 2.4 releases.
> Does this
> > fix any outstanding CVEs that we should be cherry-picking?
> >
> > Ross
> >
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH] libxml2: 2.9.4 -> 2.9.5

2017-09-05 Thread Andrej Valek
Hi Ross,

There are not any CVEs fixes which has not been already merged. There
are only general changes. Of course, we can "clean" a lot of patches by
accepting this.

Regards,
Andrej

On 09/05/2017 11:19 AM, Burton, Ross wrote:
> On 5 September 2017 at 07:35, Andrej Valek  > wrote:
> 
> Signed-off-by: Andrej Valek  >
> 
> 
> We're past freeze to the upgrade will have to wait until 2.4 releases. Does 
> this 
> fix any outstanding CVEs that we should be cherry-picking?
> 
> Ross
> 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH] shared-mime-info: enable nativesdk builds

2017-09-05 Thread Ross Burton
Also remove the redundant DEPENDS_class-native, as the native class generates
this value automatically.

Signed-off-by: Ross Burton 
---
 meta/recipes-support/shared-mime-info/shared-mime-info.inc | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/meta/recipes-support/shared-mime-info/shared-mime-info.inc 
b/meta/recipes-support/shared-mime-info/shared-mime-info.inc
index 6eedb6d3fdb..1f51225b0ee 100644
--- a/meta/recipes-support/shared-mime-info/shared-mime-info.inc
+++ b/meta/recipes-support/shared-mime-info/shared-mime-info.inc
@@ -6,7 +6,6 @@ LICENSE = "LGPLv2+"
 LIC_FILES_CHKSUM = "file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263"
 
 DEPENDS = "libxml2 intltool-native glib-2.0 shared-mime-info-native"
-DEPENDS_class-native = "libxml2-native intltool-native glib-2.0-native"
 
 SRC_URI = "http://freedesktop.org/~hadess/shared-mime-info-${PV}.tar.xz";
 
@@ -33,4 +32,4 @@ do_install_class-native () {
autotools_do_install
 }
 
-BBCLASSEXTEND = "native"
+BBCLASSEXTEND = "native nativesdk"
-- 
2.11.0

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


[OE-core] Yocto Project Status WW36’17

2017-09-05 Thread Jolley, Stephen K
Current Dev Position: YP 2.4 M4

Next Deadline: YP 2.4 Final Cut off is Sept. 18, 2017


SWAT team rotation: Todor -> Tracy on Sept. 1, 2017.

SWAT team rotation: Tracy -> Alejandro on Sept. 8, 2017

https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team


Key Status/Updates:

·M3 rc1 was released, there were some issues found but nothing which 
couldn’t be addressed in M4 so we’re on track for release.

·We’ve found and fixed a number of BB_SERVER_TIMEOUT issues to the 
point that it can now be used with oe-selftest which gives us a good confidence 
level in the functionality for release. If anyone does see issues with the 
bitbake server changes please report them as we’ve resolved most of the known 
issues (the remaining ones are with the xmlrpc server).

·We are seeing intermittent qemu issues on the autobuilder and also 
intermittent failures particularly on qemuppc. We’re doing what we can to 
investigate these.

·Huge thanks to Armin for finding out the issues we were seeing on the 
autobuilder for morty. We continue to see some issues with one of the newest 
autobuilder workers but believe that many of the other issues we were seeing 
have been resolved and hope that the 2.2.2 release can proceed soon and be 
given to QA.

·Pyro has also seen many patches recently and is likely heading to a 
new point release once these have been tested and merged.


Planned upcoming dot releases:

YP 2.2.2 Cut off June 5, 2017 - Not ready to do an rc2 yet.

YP 2.2.2 Release by June, 16 2017

YP 2.3.2 Cut off Sept. 1, 2017

YP 2.3.2 Release by Sept. 15, 2017


Key YP 2.4 Dates are:

YP 2.4 M4 (Final) Cut off is Sept. 18, 2017

YP 2.4 M4 (Final) Release by Oct. 20, 2017


Tracking Metrics:

WDD 2529 (last week 2504)

(https://wiki.yoctoproject.org/charts/combo.html)


Key Status Links for YP:

https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.4_Status

https://wiki.yoctoproject.org/wiki/Yocto_2.4_Schedule

https://wiki.yoctoproject.org/wiki/Yocto_2.4_Features


[If anyone has suggestions for other information you’d like to see on this 
weekly status update, let us know!]


Thanks,

Stephen K. Jolley
Yocto Project Program Manager
INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124
•   Work Telephone:(503) 712-0534
•Cell:   (208) 244-4460
• Email:  stephen.k.jol...@intel.com

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


[OE-core] [PATCH] glib-2.0: recommend shared-mime-info

2017-09-05 Thread Ross Burton
Large portions of GIO are not that useful without the MIME database.  Add a
recommends to shared-mime-info so that GIO works out of the box, but can be
removed (using BAD_RECOMMENDATIONS) if shared-mime-info is too large and isn't
required.

[ YOCTO #11792 ]

Signed-off-by: Ross Burton 
---
 meta/recipes-core/glib-2.0/glib.inc | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-core/glib-2.0/glib.inc 
b/meta/recipes-core/glib-2.0/glib.inc
index d6ef4dfc0b0..ce15ccefc39 100644
--- a/meta/recipes-core/glib-2.0/glib.inc
+++ b/meta/recipes-core/glib-2.0/glib.inc
@@ -73,6 +73,8 @@ FILES_${PN}-codegen = "${datadir}/glib-2.0/codegen/*.py \
${bindir}/gdbus-codegen"
 FILES_${PN}-utils = "${bindir}/*"
 
+RRECOMMENDS_${PN} += "shared-mime-info"
+
 ARM_INSTRUCTION_SET_armv4 = "arm"
 ARM_INSTRUCTION_SET_armv5 = "arm"
 # Valgrind runtime detection works using hand-written assembly, which
-- 
2.11.0

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


Re: [OE-core] [PATCH 0/7] kernel-yocto: conslidated pull request

2017-09-05 Thread Bruce Ashfield

On 09/05/2017 10:59 AM, Richard Purdie wrote:

On Tue, 2017-09-05 at 10:24 -0400, Bruce Ashfield wrote:

On 09/05/2017 10:13 AM, Richard Purdie wrote:


Hi Bruce,

We had a locked up qemuppc lsb image and I was able to find
backtraces
from the serial console log (/home/pokybuild/yocto-
autobuilder/yocto-
worker/nightly-ppc-lsb/build/build/tmp/work/qemuppc-poky-
linux/core-
image-lsb/1.0-r0/target_logs/dmesg_output.log in case anyone ever
needs
to find that). The log is below, this one is for the 4.9 kernel.

Failure as seen on the AB:
https://autobuilder.yoctoproject.org/main/builders/nightly-ppc-lsb/
buil
ds/1189/steps/Running%20Sanity%20Tests/logs/stdio

Not sure what it means, perhaps you can make more sense of it? :)

Very interesting.

I'm (un)fortunately familiar with RCU issues, and obviously, this is
only happening under load. There's clearly a driver issue as it
interacts with whatever is running in userspace.

  From the log, it looks like this is running over NFS and pinning the
CPU and the qemu ethernet isn't handling it gracefully.


Looking at the logs I've seen I don't think this is over NFS, it should
be over virtio:

"Kernel command line: root=/dev/vda"


But exactly what it is, I can't say from that trace. I'll try and do
a cpu-pinned test on qemuppc (over NFS) and see if I can trigger the
same trace.


I'm also not sure what this might be. I did a bit more staring at the
log and I think the system did come back:

NOTE: core-image-lsb-1.0-r0 do_testimage:   test_dnf_install_from_disk 
(dnf.DnfRepoTest)
NOTE: core-image-lsb-1.0-r0 do_testimage:  ... OK (249.929s)
NOTE: core-image-lsb-1.0-r0 do_testimage:   test_dnf_install_from_http 
(dnf.DnfRepoTest)
NOTE: core-image-lsb-1.0-r0 do_testimage:  ... OK (212.547s)
NOTE: core-image-lsb-1.0-r0 do_testimage:   test_dnf_reinstall (dnf.DnfRepoTest)
NOTE: core-image-lsb-1.0-r0 do_testimage:  ... FAIL (1501.682s)
NOTE: core-image-lsb-1.0-r0 do_testimage:   test_dnf_repoinfo (dnf.DnfRepoTest)
NOTE: core-image-lsb-1.0-r0 do_testimage:  ... FAIL (15.952s)
NOTE: core-image-lsb-1.0-r0 do_testimage:   test_syslog_running 
(oe_syslog.SyslogTest)
NOTE: core-image-lsb-1.0-r0 do_testimage:  ... FAIL (3.039s)
NOTE: core-image-lsb-1.0-r0 do_testimage:   test_syslog_logger 
(oe_syslog.SyslogTestConfig)
NOTE: core-image-lsb-1.0-r0 do_testimage:  ... SKIP (0.001s)
NOTE: core-image-lsb-1.0-r0 do_testimage:   test_syslog_restart 
(oe_syslog.SyslogTestConfig)
NOTE: core-image-lsb-1.0-r0 do_testimage:  ... SKIP (0.001s)
NOTE: core-image-lsb-1.0-r0 do_testimage:   test_syslog_startup_config 
(oe_syslog.SyslogTestConfig)
NOTE: core-image-lsb-1.0-r0 do_testimage:  ... SKIP (0.001s)
NOTE: core-image-lsb-1.0-r0 do_testimage:   test_pam (pam.PamBasicTest)
NOTE: core-image-lsb-1.0-r0 do_testimage:  ... FAIL (3.003s)
NOTE: core-image-lsb-1.0-r0 do_testimage:   test_parselogs 
(parselogs.ParseLogsTest)
NOTE: core-image-lsb-1.0-r0 do_testimage:  ... OK (39.675s)
NOTE: core-image-lsb-1.0-r0 do_testimage:   test_rpm_help (rpm.RpmBasicTest)
NOTE: core-image-lsb-1.0-r0 do_testimage:  ... OK (2.590s)
NOTE: core-image-lsb-1.0-r0 do_testimage:   test_rpm_query (rpm.RpmBasicTest)
NOTE: core-image-lsb-1.0-r0 do_testimage:  ... OK (2.295s)
NOTE: core-image-lsb-1.0-r0 do_testimage:   test_rpm_instal

So for a while there the system "locked up":

AssertionError: 255 != 0 : dnf 
--repofrompath=oe-testimage-repo-noarch,http://192.168.7.1:38838/noarch 
--repofrompath=oe-testimage-repo-qemuppc,http://192.168.7.1:38838/qemuppc 
--repofrompath=oe-testimage-repo-ppc7400,http://192.168.7.1:38838/ppc7400 
--nogpgcheck reinstall -y run-postinsts-dev

Process killed - no output for 1500 seconds. Total running time: 1501 seconds.

AssertionError: 255 != 0 : dnf 
--repofrompath=oe-testimage-repo-noarch,http://192.168.7.1:38838/noarch 
--repofrompath=oe-testimage-repo-qemuppc,http://192.168.7.1:38838/qemuppc 
--repofrompath=oe-testimage-repo-ppc7400,http://192.168.7.1:38838/ppc7400 
--nogpgcheck repoinfo
ssh: connect to host 192.168.7.2 port 22: No route to host

self.assertEqual(status, 1, msg = msg)
AssertionError: 255 != 1 : login command does not work as expected. Status and 
output:255 and ssh: connect to host 192.168.7.2 port 22: No route to host

then the system seems to have come back. All very odd...


I'd expect after the stall that it would come back. But it
is good news that it isn't over NFS, since that would make things
harder to reproduce.

There's some sort of cpu intensive task -> virtio that is not
allowing softIRQd to run within limits.

We could back off the warning and increase the limit, but that
can cause more serious problems down the road.

Bruce



Cheers,

Richard



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


Re: [OE-core] [PATCH 0/7] kernel-yocto: conslidated pull request

2017-09-05 Thread Richard Purdie
On Tue, 2017-09-05 at 10:24 -0400, Bruce Ashfield wrote:
> On 09/05/2017 10:13 AM, Richard Purdie wrote:
> > 
> > Hi Bruce,
> > 
> > We had a locked up qemuppc lsb image and I was able to find
> > backtraces
> > from the serial console log (/home/pokybuild/yocto-
> > autobuilder/yocto-
> > worker/nightly-ppc-lsb/build/build/tmp/work/qemuppc-poky-
> > linux/core-
> > image-lsb/1.0-r0/target_logs/dmesg_output.log in case anyone ever
> > needs
> > to find that). The log is below, this one is for the 4.9 kernel.
> > 
> > Failure as seen on the AB:
> > https://autobuilder.yoctoproject.org/main/builders/nightly-ppc-lsb/
> > buil
> > ds/1189/steps/Running%20Sanity%20Tests/logs/stdio
> > 
> > Not sure what it means, perhaps you can make more sense of it? :)
> Very interesting.
> 
> I'm (un)fortunately familiar with RCU issues, and obviously, this is
> only happening under load. There's clearly a driver issue as it
> interacts with whatever is running in userspace.
> 
>  From the log, it looks like this is running over NFS and pinning the
> CPU and the qemu ethernet isn't handling it gracefully.

Looking at the logs I've seen I don't think this is over NFS, it should
be over virtio:

"Kernel command line: root=/dev/vda"

> But exactly what it is, I can't say from that trace. I'll try and do
> a cpu-pinned test on qemuppc (over NFS) and see if I can trigger the
> same trace.

I'm also not sure what this might be. I did a bit more staring at the
log and I think the system did come back:

NOTE: core-image-lsb-1.0-r0 do_testimage:   test_dnf_install_from_disk 
(dnf.DnfRepoTest)
NOTE: core-image-lsb-1.0-r0 do_testimage:  ... OK (249.929s)
NOTE: core-image-lsb-1.0-r0 do_testimage:   test_dnf_install_from_http 
(dnf.DnfRepoTest)
NOTE: core-image-lsb-1.0-r0 do_testimage:  ... OK (212.547s)
NOTE: core-image-lsb-1.0-r0 do_testimage:   test_dnf_reinstall (dnf.DnfRepoTest)
NOTE: core-image-lsb-1.0-r0 do_testimage:  ... FAIL (1501.682s)
NOTE: core-image-lsb-1.0-r0 do_testimage:   test_dnf_repoinfo (dnf.DnfRepoTest)
NOTE: core-image-lsb-1.0-r0 do_testimage:  ... FAIL (15.952s)
NOTE: core-image-lsb-1.0-r0 do_testimage:   test_syslog_running 
(oe_syslog.SyslogTest)
NOTE: core-image-lsb-1.0-r0 do_testimage:  ... FAIL (3.039s)
NOTE: core-image-lsb-1.0-r0 do_testimage:   test_syslog_logger 
(oe_syslog.SyslogTestConfig)
NOTE: core-image-lsb-1.0-r0 do_testimage:  ... SKIP (0.001s)
NOTE: core-image-lsb-1.0-r0 do_testimage:   test_syslog_restart 
(oe_syslog.SyslogTestConfig)
NOTE: core-image-lsb-1.0-r0 do_testimage:  ... SKIP (0.001s)
NOTE: core-image-lsb-1.0-r0 do_testimage:   test_syslog_startup_config 
(oe_syslog.SyslogTestConfig)
NOTE: core-image-lsb-1.0-r0 do_testimage:  ... SKIP (0.001s)
NOTE: core-image-lsb-1.0-r0 do_testimage:   test_pam (pam.PamBasicTest)
NOTE: core-image-lsb-1.0-r0 do_testimage:  ... FAIL (3.003s)
NOTE: core-image-lsb-1.0-r0 do_testimage:   test_parselogs 
(parselogs.ParseLogsTest)
NOTE: core-image-lsb-1.0-r0 do_testimage:  ... OK (39.675s)
NOTE: core-image-lsb-1.0-r0 do_testimage:   test_rpm_help (rpm.RpmBasicTest)
NOTE: core-image-lsb-1.0-r0 do_testimage:  ... OK (2.590s)
NOTE: core-image-lsb-1.0-r0 do_testimage:   test_rpm_query (rpm.RpmBasicTest)
NOTE: core-image-lsb-1.0-r0 do_testimage:  ... OK (2.295s)
NOTE: core-image-lsb-1.0-r0 do_testimage:   test_rpm_instal

So for a while there the system "locked up":

AssertionError: 255 != 0 : dnf 
--repofrompath=oe-testimage-repo-noarch,http://192.168.7.1:38838/noarch 
--repofrompath=oe-testimage-repo-qemuppc,http://192.168.7.1:38838/qemuppc 
--repofrompath=oe-testimage-repo-ppc7400,http://192.168.7.1:38838/ppc7400 
--nogpgcheck reinstall -y run-postinsts-dev

Process killed - no output for 1500 seconds. Total running time: 1501 seconds.

AssertionError: 255 != 0 : dnf 
--repofrompath=oe-testimage-repo-noarch,http://192.168.7.1:38838/noarch 
--repofrompath=oe-testimage-repo-qemuppc,http://192.168.7.1:38838/qemuppc 
--repofrompath=oe-testimage-repo-ppc7400,http://192.168.7.1:38838/ppc7400 
--nogpgcheck repoinfo
ssh: connect to host 192.168.7.2 port 22: No route to host

self.assertEqual(status, 1, msg = msg)
AssertionError: 255 != 1 : login command does not work as expected. Status and 
output:255 and ssh: connect to host 192.168.7.2 port 22: No route to host

then the system seems to have come back. All very odd...

Cheers,

Richard

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


[OE-core] [PATCH v2 8/8] go.bbclass: Use an auxiliary variable to add the build dependencies

2017-09-05 Thread Otavio Salvador
This is going to easy the addition of nativesdk and virtual providers
in the future.

This change is based on the meta-golang[1] layer. Thanks to Matt
Madison  for his work on this.

1. https://github.com/madisongh/meta-golang

Signed-off-by: Otavio Salvador 
---

Changes in v2: None

 meta/classes/go.bbclass | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/meta/classes/go.bbclass b/meta/classes/go.bbclass
index f64b07fd82..0c9fbbf984 100644
--- a/meta/classes/go.bbclass
+++ b/meta/classes/go.bbclass
@@ -24,6 +24,11 @@ GOROOT = "${STAGING_LIBDIR_NATIVE}/${TARGET_SYS}/go"
 GOBIN_FINAL_class-native = "${GOROOT_FINAL}/bin"
 GOBIN_FINAL = "${GOROOT_FINAL}/${GO_BUILD_BINDIR}"
 
+DEPENDS_GOLANG_class-target = "go-cross-${TARGET_ARCH}"
+DEPENDS_GOLANG_class-native = "go-native"
+
+DEPENDS_append = " ${DEPENDS_GOLANG}"
+
 export GOBUILDFLAGS ?= "-v"
 GOBUILDFLAGS_prepend_task-compile = "${GO_PARALLEL_BUILD} "
 
@@ -43,9 +48,6 @@ export CGO_CPPFLAGS = "${TARGET_CPPFLAGS}"
 export CGO_CXXFLAGS = "${TARGET_CC_ARCH}${TOOLCHAIN_OPTIONS} 
${TARGET_CXXFLAGS}"
 export CGO_LDFLAGS = "${TARGET_CC_ARCH}${TOOLCHAIN_OPTIONS} ${TARGET_LDFLAGS}"
 
-DEPENDS += "go-cross-${TARGET_ARCH}"
-DEPENDS_class-native += "go-native"
-
 FILES_${PN}-staticdev += "${GOSRC_FINAL}/${GO_IMPORT}"
 FILES_${PN}-staticdev += "${GOPKG_FINAL}/${GO_IMPORT}*"
 
-- 
2.14.1

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


[OE-core] [PATCH v2 7/8] go.bbclass: Enable parallel build

2017-09-05 Thread Otavio Salvador
The parallel build is based on PARALLEL_MAKE variable but can be
overriden setting the GO_PARALLEL_BUILD one.

This change is based on the meta-golang[1] layer. Thanks to Matt
Madison  for his work on this.

1. https://github.com/madisongh/meta-golang

Signed-off-by: Otavio Salvador 
---

Changes in v2: None

 meta/classes/go.bbclass | 20 
 1 file changed, 20 insertions(+)

diff --git a/meta/classes/go.bbclass b/meta/classes/go.bbclass
index 720a504cd8..f64b07fd82 100644
--- a/meta/classes/go.bbclass
+++ b/meta/classes/go.bbclass
@@ -1,11 +1,31 @@
 inherit goarch
 
+def get_go_parallel_make(d):
+pm = (d.getVar('PARALLEL_MAKE') or '').split()
+# look for '-j' and throw other options (e.g. '-l') away
+# because they might have a different meaning in golang
+while pm:
+opt = pm.pop(0)
+if opt == '-j':
+v = pm.pop(0)
+elif opt.startswith('-j'):
+v = opt[2:].strip()
+else:
+continue
+
+return '-p %d' % int(v)
+
+return ""
+
+GO_PARALLEL_BUILD ?= "${@get_go_parallel_make(d)}"
+
 GOROOT_class-native = "${STAGING_LIBDIR_NATIVE}/go"
 GOROOT = "${STAGING_LIBDIR_NATIVE}/${TARGET_SYS}/go"
 GOBIN_FINAL_class-native = "${GOROOT_FINAL}/bin"
 GOBIN_FINAL = "${GOROOT_FINAL}/${GO_BUILD_BINDIR}"
 
 export GOBUILDFLAGS ?= "-v"
+GOBUILDFLAGS_prepend_task-compile = "${GO_PARALLEL_BUILD} "
 
 export GOOS = "${TARGET_GOOS}"
 export GOARCH = "${TARGET_GOARCH}"
-- 
2.14.1

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


[OE-core] [PATCH v2 0/8] Revamp the Go support

2017-09-05 Thread Otavio Salvador
This is not yet complete but does improve some parts of
Go support on OE-Core.

We are trying to port as much as possible work done by Matt on
meta-golang back to OE-Core and also to avoid carrying old releases as
there is no need to support more versions of Go toolchain.

The first commits on this serie does fix errors in current
implementation, the others are improvements and clean ups.

Changes in v2:
- New patch
- Remove -x flag (madisongh)
- Remove GO_EXTLDFLAGS for now (madisongh)

Otavio Salvador (8):
  goarch.bbclass: Stop passing True as second argument of d.getVar
  go.bbclass: Fix binary installation path detection
  go-dep: Add 0.3.0 release
  go: Remove Go 1.6 and 1.7 releases
  goarch.bbclass: Add support for ARMv5
  go.bbclass: Use a global Go build flags
  go.bbclass: Enable parallel build
  go.bbclass: Use an auxiliary variable to add the build dependencies

 meta/classes/go.bbclass| 34 ++--
 meta/classes/goarch.bbclass| 20 +++
 meta/recipes-devtools/go/go-1.6.inc| 19 ---
 .../go/go-1.6/armhf-elf-header.patch   | 23 
 .../go/go-1.6/fix-cc-handling.patch| 50 -
 .../go/go-1.6/fix-target-cc-for-build.patch| 17 --
 meta/recipes-devtools/go/go-1.6/gotooldir.patch| 30 ---
 .../go/go-1.6/split-host-and-target-build.patch| 63 --
 meta/recipes-devtools/go/go-1.6/syslog.patch   | 62 -
 meta/recipes-devtools/go/go-1.7.inc| 19 ---
 .../go/go-1.7/armhf-elf-header.patch   | 23 
 .../go/go-1.7/fix-cc-handling.patch| 50 -
 .../go/go-1.7/fix-target-cc-for-build.patch| 17 --
 meta/recipes-devtools/go/go-1.7/gotooldir.patch| 30 ---
 .../go/go-1.7/split-host-and-target-build.patch| 62 -
 meta/recipes-devtools/go/go-1.7/syslog.patch   | 62 -
 meta/recipes-devtools/go/go-cross_1.7.bb   |  5 --
 meta/recipes-devtools/go/go-dep_0.3.0.bb   | 20 +++
 meta/recipes-devtools/go/go_1.6.bb |  4 --
 meta/recipes-devtools/go/go_1.7.bb |  2 -
 20 files changed, 60 insertions(+), 552 deletions(-)
 delete mode 100644 meta/recipes-devtools/go/go-1.6.inc
 delete mode 100644 meta/recipes-devtools/go/go-1.6/armhf-elf-header.patch
 delete mode 100644 meta/recipes-devtools/go/go-1.6/fix-cc-handling.patch
 delete mode 100644 
meta/recipes-devtools/go/go-1.6/fix-target-cc-for-build.patch
 delete mode 100644 meta/recipes-devtools/go/go-1.6/gotooldir.patch
 delete mode 100644 
meta/recipes-devtools/go/go-1.6/split-host-and-target-build.patch
 delete mode 100644 meta/recipes-devtools/go/go-1.6/syslog.patch
 delete mode 100644 meta/recipes-devtools/go/go-1.7.inc
 delete mode 100644 meta/recipes-devtools/go/go-1.7/armhf-elf-header.patch
 delete mode 100644 meta/recipes-devtools/go/go-1.7/fix-cc-handling.patch
 delete mode 100644 
meta/recipes-devtools/go/go-1.7/fix-target-cc-for-build.patch
 delete mode 100644 meta/recipes-devtools/go/go-1.7/gotooldir.patch
 delete mode 100644 
meta/recipes-devtools/go/go-1.7/split-host-and-target-build.patch
 delete mode 100644 meta/recipes-devtools/go/go-1.7/syslog.patch
 delete mode 100644 meta/recipes-devtools/go/go-cross_1.7.bb
 create mode 100644 meta/recipes-devtools/go/go-dep_0.3.0.bb
 delete mode 100644 meta/recipes-devtools/go/go_1.6.bb
 delete mode 100644 meta/recipes-devtools/go/go_1.7.bb

-- 
2.14.1

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


[OE-core] [PATCH v2 1/8] goarch.bbclass: Stop passing True as second argument of d.getVar

2017-09-05 Thread Otavio Salvador
The d.getVar has the second argument as True by default, avoid passing
it here.

Signed-off-by: Otavio Salvador 
---

Changes in v2: None

 meta/classes/goarch.bbclass | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/meta/classes/goarch.bbclass b/meta/classes/goarch.bbclass
index 9cd38b8c48..7960ac5f9e 100644
--- a/meta/classes/goarch.bbclass
+++ b/meta/classes/goarch.bbclass
@@ -1,15 +1,15 @@
-BUILD_GOOS = "${@go_map_os(d.getVar('BUILD_OS', True), d)}"
-BUILD_GOARCH = "${@go_map_arch(d.getVar('BUILD_ARCH', True), d)}"
+BUILD_GOOS = "${@go_map_os(d.getVar('BUILD_OS'), d)}"
+BUILD_GOARCH = "${@go_map_arch(d.getVar('BUILD_ARCH'), d)}"
 BUILD_GOTUPLE = "${BUILD_GOOS}_${BUILD_GOARCH}"
-HOST_GOOS = "${@go_map_os(d.getVar('HOST_OS', True), d)}"
-HOST_GOARCH = "${@go_map_arch(d.getVar('HOST_ARCH', True), d)}"
-HOST_GOARM = "${@go_map_arm(d.getVar('HOST_ARCH', True), 
d.getVar('TUNE_FEATURES', True), d)}"
+HOST_GOOS = "${@go_map_os(d.getVar('HOST_OS'), d)}"
+HOST_GOARCH = "${@go_map_arch(d.getVar('HOST_ARCH'), d)}"
+HOST_GOARM = "${@go_map_arm(d.getVar('HOST_ARCH'), d.getVar('TUNE_FEATURES'), 
d)}"
 HOST_GOTUPLE = "${HOST_GOOS}_${HOST_GOARCH}"
-TARGET_GOOS = "${@go_map_os(d.getVar('TARGET_OS', True), d)}"
-TARGET_GOARCH = "${@go_map_arch(d.getVar('TARGET_ARCH', True), d)}"
-TARGET_GOARM = "${@go_map_arm(d.getVar('TARGET_ARCH', True), 
d.getVar('TUNE_FEATURES', True), d)}"
+TARGET_GOOS = "${@go_map_os(d.getVar('TARGET_OS'), d)}"
+TARGET_GOARCH = "${@go_map_arch(d.getVar('TARGET_ARCH'), d)}"
+TARGET_GOARM = "${@go_map_arm(d.getVar('TARGET_ARCH'), 
d.getVar('TUNE_FEATURES'), d)}"
 TARGET_GOTUPLE = "${TARGET_GOOS}_${TARGET_GOARCH}"
-GO_BUILD_BINDIR = 
"${@['bin/${HOST_GOTUPLE}','bin'][d.getVar('BUILD_GOTUPLE',True) == 
d.getVar('HOST_GOTUPLE',True)]}"
+GO_BUILD_BINDIR = "${@['bin/${HOST_GOTUPLE}','bin'][d.getVar('BUILD_GOTUPLE') 
== d.getVar('HOST_GOTUPLE')]}"
 
 # define here because everybody inherits this class
 #
-- 
2.14.1

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


[OE-core] [PATCH v2 4/8] go: Remove Go 1.6 and 1.7 releases

2017-09-05 Thread Otavio Salvador
The OE-Core has no reason to support multiple versions of Go as this
increases the maintenance work and testing efforts. So we are going to
support just a single version from now on which currently is 1.8.3.

The 1.4 release is kept around as it is used for bootstrap, as such,
it cannot be removed.

Signed-off-by: Otavio Salvador 
---

Changes in v2: None

 meta/recipes-devtools/go/go-1.6.inc| 19 ---
 .../go/go-1.6/armhf-elf-header.patch   | 23 
 .../go/go-1.6/fix-cc-handling.patch| 50 -
 .../go/go-1.6/fix-target-cc-for-build.patch| 17 --
 meta/recipes-devtools/go/go-1.6/gotooldir.patch| 30 ---
 .../go/go-1.6/split-host-and-target-build.patch| 63 --
 meta/recipes-devtools/go/go-1.6/syslog.patch   | 62 -
 meta/recipes-devtools/go/go-1.7.inc| 19 ---
 .../go/go-1.7/armhf-elf-header.patch   | 23 
 .../go/go-1.7/fix-cc-handling.patch| 50 -
 .../go/go-1.7/fix-target-cc-for-build.patch| 17 --
 meta/recipes-devtools/go/go-1.7/gotooldir.patch| 30 ---
 .../go/go-1.7/split-host-and-target-build.patch| 62 -
 meta/recipes-devtools/go/go-1.7/syslog.patch   | 62 -
 meta/recipes-devtools/go/go-cross_1.7.bb   |  5 --
 meta/recipes-devtools/go/go_1.6.bb |  4 --
 meta/recipes-devtools/go/go_1.7.bb |  2 -
 17 files changed, 538 deletions(-)
 delete mode 100644 meta/recipes-devtools/go/go-1.6.inc
 delete mode 100644 meta/recipes-devtools/go/go-1.6/armhf-elf-header.patch
 delete mode 100644 meta/recipes-devtools/go/go-1.6/fix-cc-handling.patch
 delete mode 100644 
meta/recipes-devtools/go/go-1.6/fix-target-cc-for-build.patch
 delete mode 100644 meta/recipes-devtools/go/go-1.6/gotooldir.patch
 delete mode 100644 
meta/recipes-devtools/go/go-1.6/split-host-and-target-build.patch
 delete mode 100644 meta/recipes-devtools/go/go-1.6/syslog.patch
 delete mode 100644 meta/recipes-devtools/go/go-1.7.inc
 delete mode 100644 meta/recipes-devtools/go/go-1.7/armhf-elf-header.patch
 delete mode 100644 meta/recipes-devtools/go/go-1.7/fix-cc-handling.patch
 delete mode 100644 
meta/recipes-devtools/go/go-1.7/fix-target-cc-for-build.patch
 delete mode 100644 meta/recipes-devtools/go/go-1.7/gotooldir.patch
 delete mode 100644 
meta/recipes-devtools/go/go-1.7/split-host-and-target-build.patch
 delete mode 100644 meta/recipes-devtools/go/go-1.7/syslog.patch
 delete mode 100644 meta/recipes-devtools/go/go-cross_1.7.bb
 delete mode 100644 meta/recipes-devtools/go/go_1.6.bb
 delete mode 100644 meta/recipes-devtools/go/go_1.7.bb

diff --git a/meta/recipes-devtools/go/go-1.6.inc 
b/meta/recipes-devtools/go/go-1.6.inc
deleted file mode 100644
index 769c1d8f22..00
--- a/meta/recipes-devtools/go/go-1.6.inc
+++ /dev/null
@@ -1,19 +0,0 @@
-require go-common.inc
-
-PV = "1.6.3"
-GO_BASEVERSION = "1.6"
-FILESEXTRAPATHS_prepend := "${FILE_DIRNAME}/go-${GO_BASEVERSION}:"
-
-LIC_FILES_CHKSUM = "file://LICENSE;md5=591778525c869cdde0ab5a1bf283cd81"
-
-SRC_URI += "\
-   file://armhf-elf-header.patch \
-   file://syslog.patch \
-   file://fix-target-cc-for-build.patch \
-   file://fix-cc-handling.patch \
-   file://split-host-and-target-build.patch \
-   file://gotooldir.patch \
-"
-SRC_URI[md5sum] = "bf3fce6ccaadd310159c9e874220e2a2"
-SRC_URI[sha256sum] = 
"6326aeed5f86cf18f16d6dc831405614f855e2d416a91fd3fdc334f772345b00"
-
diff --git a/meta/recipes-devtools/go/go-1.6/armhf-elf-header.patch 
b/meta/recipes-devtools/go/go-1.6/armhf-elf-header.patch
deleted file mode 100644
index 1e3a16b319..00
--- a/meta/recipes-devtools/go/go-1.6/armhf-elf-header.patch
+++ /dev/null
@@ -1,23 +0,0 @@
-Encode arm EABI ( hard/soft ) calling convention in ELF header
-
-Signed-off-by: Khem Raj 
-Upstream-Status: Pending
-Index: go/src/cmd/link/internal/ld/elf.go
-===
 go.orig/src/cmd/link/internal/ld/elf.go
-+++ go/src/cmd/link/internal/ld/elf.go
-@@ -827,7 +827,13 @@
-   // 32-bit architectures
-   case '5':
-   // we use EABI on both linux/arm and freebsd/arm.
--  if HEADTYPE == obj.Hlinux || HEADTYPE == obj.Hfreebsd {
-+  if HEADTYPE == obj.Hlinux {
-+  if Ctxt.Goarm == 7 {
-+  ehdr.flags = 0x5000402 // has entry point, 
Version5 EABI, hard float
-+  } else {
-+  ehdr.flags = 0x5000202 // has entry point, 
Version5 EABI, soft float
-+  }
-+  } else if HEADTYPE == obj.Hfreebsd {
-   // We set a value here that makes no indication of which
-   // float ABI the object uses, because this is 
information
-   // used by the dynamic l

[OE-core] [PATCH v2 5/8] goarch.bbclass: Add support for ARMv5

2017-09-05 Thread Otavio Salvador
This adds support to return the proper ARMv5 format.

This change is based on the meta-golang[1] layer. Thanks to Matt
Madison  for his work on this.

1. https://github.com/madisongh/meta-golang

Signed-off-by: Otavio Salvador 
---

Changes in v2: None

 meta/classes/goarch.bbclass | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/classes/goarch.bbclass b/meta/classes/goarch.bbclass
index 7960ac5f9e..dbec6ee2c8 100644
--- a/meta/classes/goarch.bbclass
+++ b/meta/classes/goarch.bbclass
@@ -47,6 +47,8 @@ def go_map_arm(a, f, d):
 import re
 if re.match('arm.*', a) and re.match('arm.*7.*', f):
 return '7'
+if re.match('arm.*', a) and re.match('arm.*5.*', f):
+return '5'
 return ''
 
 def go_map_os(o, d):
-- 
2.14.1

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


[OE-core] [PATCH v2 6/8] go.bbclass: Use a global Go build flags

2017-09-05 Thread Otavio Salvador
We now use a GOBUILDFLAGS to provide a global variable to control the
build flags to be given to Go.

This change is based on the meta-golang[1] layer. Thanks to Matt
Madison  for his work on this.

1. https://github.com/madisongh/meta-golang

Signed-off-by: Otavio Salvador 
---

Changes in v2:
- Remove -x flag (madisongh)
- Remove GO_EXTLDFLAGS for now (madisongh)

 meta/classes/go.bbclass | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/meta/classes/go.bbclass b/meta/classes/go.bbclass
index e073cb91b5..720a504cd8 100644
--- a/meta/classes/go.bbclass
+++ b/meta/classes/go.bbclass
@@ -5,6 +5,8 @@ GOROOT = "${STAGING_LIBDIR_NATIVE}/${TARGET_SYS}/go"
 GOBIN_FINAL_class-native = "${GOROOT_FINAL}/bin"
 GOBIN_FINAL = "${GOROOT_FINAL}/${GO_BUILD_BINDIR}"
 
+export GOBUILDFLAGS ?= "-v"
+
 export GOOS = "${TARGET_GOOS}"
 export GOARCH = "${TARGET_GOARCH}"
 export GOARM = "${TARGET_GOARM}"
@@ -32,7 +34,7 @@ GO_INSTALL ?= "${GO_IMPORT}/..."
 do_go_compile() {
GOPATH=${S}:${STAGING_LIBDIR}/${TARGET_SYS}/go go env
if [ -n "${GO_INSTALL}" ]; then
-   GOPATH=${S}:${STAGING_LIBDIR}/${TARGET_SYS}/go go install -v 
${GO_INSTALL}
+   GOPATH=${S}:${STAGING_LIBDIR}/${TARGET_SYS}/go go install 
${GOBUILDFLAGS} ${GO_INSTALL}
fi
 }
 
-- 
2.14.1

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


[OE-core] [PATCH v2 3/8] go-dep: Add 0.3.0 release

2017-09-05 Thread Otavio Salvador
This is the Golang dependency management tool under development; it is
ready for production use and intended to be merged onto Golang
1.10. Until that, projects are starting to use it and making it
available on OE-Core reduces the Golang integration work for new
recipes.

Signed-off-by: Otavio Salvador 
---

Changes in v2:
- New patch

 meta/recipes-devtools/go/go-dep_0.3.0.bb | 20 
 1 file changed, 20 insertions(+)
 create mode 100644 meta/recipes-devtools/go/go-dep_0.3.0.bb

diff --git a/meta/recipes-devtools/go/go-dep_0.3.0.bb 
b/meta/recipes-devtools/go/go-dep_0.3.0.bb
new file mode 100644
index 00..66e30acbd3
--- /dev/null
+++ b/meta/recipes-devtools/go/go-dep_0.3.0.bb
@@ -0,0 +1,20 @@
+SUMMARY = "Dependency management tool for Golang"
+HOMEPAGE = "https://github.com/golang/dep";
+LICENSE = "BSD-3-Clause"
+LIC_FILES_CHKSUM = 
"file://src/${GO_IMPORT}/LICENSE;md5=1bad315647751fab0007812f70d42c0d"
+
+GO_IMPORT = "github.com/golang/dep"
+SRC_URI = 
"git://${GO_IMPORT};destsuffix=${BPN}-${PV}/src/${GO_IMPORT};nobranch=1"
+
+# Points to 0.3.0 tag
+SRCREV = "7a91b794bbfbf1f3b8b79823799316451127801b"
+
+inherit go
+
+GO_INSTALL = "${GO_IMPORT}/cmd/dep"
+
+INSANE_SKIP_${PN} += "ldflags"
+
+BBCLASSEXTEND = "native nativesdk"
+
+RDEPENDS_${PN}-staticdev += "bash"
-- 
2.14.1

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


[OE-core] [PATCH v2 2/8] go.bbclass: Fix binary installation path detection

2017-09-05 Thread Otavio Salvador
Go toolchain changes the installation path when building for the same
architecture as the build host. This was already been considered in
the GO_BUILD_BINDIR variable but was not being used by the go class.

This fixes following error:

,
| ERROR: go-dep-0.3.0-r0 do_package: QA Issue: go-dep: Files/directories
| were installed but not shipped in any package:
|   /usr/lib/x86_64-oel-linux/go/bin/dep
| Please set FILES such that these items are packaged. Alternatively if
| they are unneeded, avoid installing them or delete them within
| do_install.
`

Signed-off-by: Otavio Salvador 
---

Changes in v2: None

 meta/classes/go.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/go.bbclass b/meta/classes/go.bbclass
index cedda68c55..e073cb91b5 100644
--- a/meta/classes/go.bbclass
+++ b/meta/classes/go.bbclass
@@ -3,7 +3,7 @@ inherit goarch
 GOROOT_class-native = "${STAGING_LIBDIR_NATIVE}/go"
 GOROOT = "${STAGING_LIBDIR_NATIVE}/${TARGET_SYS}/go"
 GOBIN_FINAL_class-native = "${GOROOT_FINAL}/bin"
-GOBIN_FINAL = "${GOROOT_FINAL}/bin/${GOOS}_${GOARCH}"
+GOBIN_FINAL = "${GOROOT_FINAL}/${GO_BUILD_BINDIR}"
 
 export GOOS = "${TARGET_GOOS}"
 export GOARCH = "${TARGET_GOARCH}"
-- 
2.14.1

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


Re: [OE-core] [PATCH 6/7] go.bbclass: Enable parallel build

2017-09-05 Thread Otavio Salvador
On Tue, Sep 5, 2017 at 7:50 AM, Matt Madison  wrote:
> On Mon, Sep 4, 2017 at 2:06 PM, Otavio Salvador  
> wrote:
>> The parallel build is based on PARALLEL_MAKE variable but can be
>> overriden setting the GO_PARALLEL_BUILD one.
>>
>> This change is based on the meta-golang[1] layer. Thanks to Matt
>> Madison  for his work on this.
>>
>> 1. https://github.com/madisongh/meta-golang
>>
>> Signed-off-by: Otavio Salvador 
>> ---
>>
>>  meta/classes/go.bbclass | 20 
>>  1 file changed, 20 insertions(+)
>>
>> diff --git a/meta/classes/go.bbclass b/meta/classes/go.bbclass
>> index 45f2add810..f80134bf8e 100644
>> --- a/meta/classes/go.bbclass
>> +++ b/meta/classes/go.bbclass
>> @@ -1,11 +1,31 @@
>>  inherit goarch
>>
>> +def get_go_parallel_make(d):
>> +pm = (d.getVar('PARALLEL_MAKE') or '').split()
>> +# look for '-j' and throw other options (e.g. '-l') away
>> +# because they might have a different meaning in golang
>> +while pm:
>> +opt = pm.pop(0)
>> +if opt == '-j':
>> +v = pm.pop(0)
>> +elif opt.startswith('-j'):
>> +v = opt[2:].strip()
>> +else:
>> +continue
>> +
>> +return '-p %d' % int(v)
>> +
>> +return ""
>> +
>> +GO_PARALLEL_BUILD ?= "${@get_go_parallel_make(d)}"
>
> This added variable should be appended to BB_HASHBASE_WHITELIST.

I think should not use new variables. We base it on PARALLEL_MAKE so
the user can control it in local.conf if needed.

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


[OE-core] [PATCH v5 1/3] kernel: Stop using update-alternatives

2017-09-05 Thread Otavio Salvador
The update-alternatives where using relative links so not being really
in use since December 2016 (see OE-Core:c7bc46b9 "kernel: Fix
symlinks") so instead we now generate the relative symlinks during the
do_install task and drop the update-alternatives use at all.

Acked-by: Saul Wold 
Signed-off-by: Otavio Salvador 
---

Changes in v5: None
Changes in v4:
- Fix symlink on deploy directory

Changes in v3: None
Changes in v2: None

 meta/classes/kernel.bbclass | 16 +++
 meta/recipes-kernel/linux/linux-dtb.inc | 36 +
 2 files changed, 8 insertions(+), 44 deletions(-)

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 3cc0432fcf..02a5e961cb 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -2,7 +2,7 @@ inherit linux-kernel-base kernel-module-split
 
 PROVIDES += "virtual/kernel"
 DEPENDS += "virtual/${TARGET_PREFIX}binutils virtual/${TARGET_PREFIX}gcc 
kmod-native bc-native lzop-native"
-PACKAGE_WRITE_DEPS += "depmodwrapper-cross virtual/update-alternatives-native"
+PACKAGE_WRITE_DEPS += "depmodwrapper-cross"
 
 do_deploy[depends] += "depmodwrapper-cross:do_populate_sysroot"
 
@@ -57,7 +57,7 @@ python __anonymous () {
 
 d.appendVar('PACKAGES', ' ' + 'kernel-image-' + typelower)
 
-d.setVar('FILES_kernel-image-' + typelower, '/' + imagedest + '/' + 
type + '-${KERNEL_VERSION_NAME}')
+d.setVar('FILES_kernel-image-' + typelower, '/' + imagedest + '/' + 
type + '-${KERNEL_VERSION_NAME}' + ' /' + imagedest + '/' + type)
 
 d.appendVar('RDEPENDS_kernel-image', ' ' + 'kernel-image-' + typelower)
 
@@ -65,13 +65,6 @@ python __anonymous () {
 
 d.setVar('ALLOW_EMPTY_kernel-image-' + typelower, '1')
 
-priority = d.getVar('KERNEL_PRIORITY')
-postinst = '#!/bin/sh\n' + 'update-alternatives --install /' + 
imagedest + '/' + type + ' ' + type + ' ' + type + '-${KERNEL_VERSION_NAME} ' + 
priority + ' || true' + '\n'
-d.setVar('pkg_postinst_kernel-image-' + typelower, postinst)
-
-postrm = '#!/bin/sh\n' + 'update-alternatives --remove' + ' ' + type + 
' ' + type + '-${KERNEL_VERSION_NAME} || true' + '\n'
-d.setVar('pkg_postrm_kernel-image-' + typelower, postrm)
-
 image = d.getVar('INITRAMFS_IMAGE')
 if image:
 d.appendVarFlag('do_bundle_initramfs', 'depends', ' 
${INITRAMFS_IMAGE}:do_image_complete')
@@ -137,10 +130,6 @@ export CROSS_COMPILE = "${TARGET_PREFIX}"
 export KBUILD_BUILD_USER = "oe-user"
 export KBUILD_BUILD_HOST = "oe-host"
 
-KERNEL_PRIORITY ?= 
"${@int(d.getVar('PV').split('-')[0].split('+')[0].split('.')[0]) * 1 + \
-   
int(d.getVar('PV').split('-')[0].split('+')[0].split('.')[1]) * 100 + \
-   
int(d.getVar('PV').split('-')[0].split('+')[0].split('.')[-1])}"
-
 KERNEL_RELEASE ?= "${KERNEL_VERSION}"
 
 # The directory where built kernel lies in the kernel tree
@@ -350,6 +339,7 @@ kernel_do_install() {
install -d ${D}/boot
for type in ${KERNEL_IMAGETYPES} ; do
install -m 0644 ${KERNEL_OUTPUT_DIR}/${type} 
${D}/${KERNEL_IMAGEDEST}/${type}-${KERNEL_VERSION}
+   ln -sf ${type}-${KERNEL_VERSION} 
${D}/${KERNEL_IMAGEDEST}/${type}
done
install -m 0644 System.map ${D}/boot/System.map-${KERNEL_VERSION}
install -m 0644 .config ${D}/boot/config-${KERNEL_VERSION}
diff --git a/meta/recipes-kernel/linux/linux-dtb.inc 
b/meta/recipes-kernel/linux/linux-dtb.inc
index 0174c80d85..ca92822d25 100644
--- a/meta/recipes-kernel/linux/linux-dtb.inc
+++ b/meta/recipes-kernel/linux/linux-dtb.inc
@@ -1,7 +1,5 @@
 # Support for device tree generation
-FILES_kernel-devicetree = "/${KERNEL_IMAGEDEST}/devicetree*"
-
-PACKAGE_WRITE_DEPS += "virtual/update-alternatives-native"
+FILES_kernel-devicetree = "/${KERNEL_IMAGEDEST}/*.dtb 
/${KERNEL_IMAGEDEST}/*.dtbo"
 
 python __anonymous () {
 d.appendVar("PACKAGES", " kernel-devicetree")
@@ -36,12 +34,13 @@ do_install_append() {
for DTB in ${KERNEL_DEVICETREE}; do
DTB=`normalize_dtb "${DTB}"`
DTB_EXT=${DTB##*.}
+   DTB_PATH=`get_real_dtb_path_in_kernel "${DTB}"`
DTB_BASE_NAME=`basename ${DTB} ."${DTB_EXT}"`
+   install -m 0644 ${DTB_PATH} 
${D}/${KERNEL_IMAGEDEST}/${DTB_BASE_NAME}.${DTB_EXT}
for type in ${KERNEL_IMAGETYPE_FOR_MAKE}; do
symlink_name=${type}"-"${KERNEL_IMAGE_SYMLINK_NAME}
DTB_SYMLINK_NAME=`echo ${symlink_name} | sed 
"s/${MACHINE}/${DTB_BASE_NAME}/g"`
-   DTB_PATH=`get_real_dtb_path_in_kernel "${DTB}"`
-   install -m 0644 ${DTB_PATH} 
${D}/${KERNEL_IMAGEDEST}/devicetree-${DTB_SYMLINK_NAME}.${DTB_EXT}
+   ln -sf ${DTB_BASE_NAME}.${DTB_EXT} 
${D}/${KERNEL_IMAGEDEST}/devicetree-${DTB_SYMLINK_NAME}.${DTB_EXT}
done
done
 }
@@ -60,32 +59,7 @@

[OE-core] [PATCH v5 3/3] kernel-devicetree.bbclass: Add support to generate append to kernel

2017-09-05 Thread Otavio Salvador
The are use cases where the Device Tree appended to the kernel is
convinient, so we generate the bundle concatenating the kernel (and
potentionally the initramfs) and the Device Tree binaries.

To enable it, set KERNEL_DEVICETREE_BUNDLE variable to '1'

Signed-off-by: Otavio Salvador 
---

Changes in v5:
- add support for initramfs bundle

Changes in v4:
- new patch

Changes in v3: None
Changes in v2: None

 meta/classes/kernel-devicetree.bbclass | 49 +-
 1 file changed, 48 insertions(+), 1 deletion(-)

diff --git a/meta/classes/kernel-devicetree.bbclass 
b/meta/classes/kernel-devicetree.bbclass
index 04e2f2695e..1499d2ba43 100644
--- a/meta/classes/kernel-devicetree.bbclass
+++ b/meta/classes/kernel-devicetree.bbclass
@@ -1,6 +1,13 @@
 # Support for device tree generation
-PACKAGES_append = " kernel-devicetree"
+PACKAGES_append = " \
+kernel-devicetree \
+${@['kernel-image-zimage-bundle', ''][d.getVar('KERNEL_DEVICETREE_BUNDLE') 
!= '1']} \
+"
 FILES_kernel-devicetree = "/${KERNEL_IMAGEDEST}/*.dtb 
/${KERNEL_IMAGEDEST}/*.dtbo"
+FILES_kernel-image-zimage-bundle = "/${KERNEL_IMAGEDEST}/zImage-*.dtb.bundle"
+
+# Generate kernel+devicetree bundle
+KERNEL_DEVICETREE_BUNDLE ?= "0"
 
 normalize_dtb () {
DTB="$1"
@@ -20,6 +27,24 @@ get_real_dtb_path_in_kernel () {
echo "${DTB_PATH}"
 }
 
+
+do_configure_devicetree() {
+   if [ "${KERNEL_DEVICETREE_BUNDLE}" = "1" ]; then
+   if echo ${KERNEL_IMAGETYPE_FOR_MAKE} | grep -q 'zImage'; then
+   config="${B}/.config"
+   if ! grep -q 'CONFIG_ARM_APPENDED_DTB=y' $config; then
+   bbwarn 'CONFIG_ARM_APPENDED_DTB is NOT enabled 
in the kernel. Enabling it to allow the kernel to boot with the Device Tree 
appended!'
+   sed -i "/CONFIG_ARM_APPENDED_DTB[ =]/d" $config
+   echo "CONFIG_ARM_APPENDED_DTB=y" >> $config
+   echo "# CONFIG_ARM_ATAG_DTB_COMPAT is not set" 
>> $config
+   fi
+   else
+   bberror 'The KERNEL_DEVICETREE_BUNDLE requires the 
KERNEL_IMAGETYPE to contain zImage.'
+   fi
+   fi
+}
+addtask configure_devicetree after do_configure before do_compile
+
 do_compile_devicetree() {
 DTBS=""
for dtb in ${KERNEL_DEVICETREE}; do
@@ -43,6 +68,12 @@ fakeroot do_install_devicetree() {
symlink_name=${type}"-"${KERNEL_IMAGE_SYMLINK_NAME}
DTB_SYMLINK_NAME=`echo ${symlink_name} | sed 
"s/${MACHINE}/${DTB_BASE_NAME}/g"`
ln -sf ${DTB_BASE_NAME}.${DTB_EXT} 
${D}/${KERNEL_IMAGEDEST}/devicetree-${DTB_SYMLINK_NAME}.${DTB_EXT}
+
+   if [ "$type" = "zImage" ] && [ 
"${KERNEL_DEVICETREE_BUNDLE}" = "1" ]; then
+   cat ${D}/${KERNEL_IMAGEDEST}/$type \
+   
${D}/${KERNEL_IMAGEDEST}/${DTB_BASE_NAME}.${DTB_EXT} \
+   > 
${D}/${KERNEL_IMAGEDEST}/$type-${DTB_BASE_NAME}.${DTB_EXT}.bundle
+   fi
done
done
 }
@@ -63,6 +94,22 @@ do_deploy_append() {
install -m 0644 ${DTB_PATH} 
${DEPLOYDIR}/${DTB_NAME}.${DTB_EXT}
ln -sf ${DTB_NAME}.${DTB_EXT} 
${DEPLOYDIR}/${DTB_SYMLINK_NAME}.${DTB_EXT}
ln -sf ${DTB_NAME}.${DTB_EXT} 
${DEPLOYDIR}/${DTB_BASE_NAME}.${DTB_EXT}
+
+   if [ "$type" = "zImage" ] && [ 
"${KERNEL_DEVICETREE_BUNDLE}" = "1" ]; then
+   cat ${DEPLOYDIR}/$type \
+   ${DEPLOYDIR}/${DTB_NAME}.${DTB_EXT} \
+   > 
${DEPLOYDIR}/${DTB_NAME}.${DTB_EXT}.bundle
+   ln -sf ${DTB_NAME}.${DTB_EXT}.bundle 
${DEPLOYDIR}/$type-${DTB_BASE_NAME}.${DTB_EXT}.bundle
+
+   if [ -e 
"${KERNEL_OUTPUT_DIR}/${type}.initramfs" ]; then
+   
initramfs_base_name=${type}-${INITRAMFS_BASE_NAME}-${DTB_BASE_NAME}.${DTB_EXT}
+   
initramfs_symlink_name=${type}-initramfs-${DTB_BASE_NAME}.${DTB_EXT}-${MACHINE}
+   cat 
${KERNEL_OUTPUT_DIR}/${type}.initramfs \
+   
${DEPLOYDIR}/${DTB_NAME}.${DTB_EXT} \
+   > 
${DEPLOYDIR}/${initramfs_base_name}.bin
+   ln -sf ${initramfs_base_name}.bin 
${DEPLOYDIR}/${initramfs_symlink_name}.bin
+   fi
+   fi
done
done
 }
-- 
2.14.1

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

[OE-core] [PATCH v5 2/3] kernel: Move Device Tree support to kernel.bbclass

2017-09-05 Thread Otavio Salvador
The Device Tree is commonly used but it is still kept as a .inc file
instead of a proper class. Instead now we move the Device Tree code to
a kernel-devicetree class and automatically enable it when the
KERNEL_DEVICETREE variable is set.

While converting to the class, we reworked the compile and install in
tasks as well as run the build of the Device Tree files in parallel,
if possible.

To avoid breakage in existing layers, we kept a linux-dtb.inc file
which raises a warning telling the user about the change so in next
release this can be removed.

Signed-off-by: Otavio Salvador 
---

Changes in v5: None
Changes in v4:
- Rebase on top of 1/3

Changes in v3:
- rework compile and install to tasks
- improve commit log

Changes in v2:
- Wrong version as the changes were not staged. Sorry!

 meta/classes/kernel-devicetree.bbclass  | 68 +
 meta/classes/kernel.bbclass |  4 ++
 meta/recipes-kernel/linux/linux-dtb.inc | 66 +---
 3 files changed, 74 insertions(+), 64 deletions(-)
 create mode 100644 meta/classes/kernel-devicetree.bbclass

diff --git a/meta/classes/kernel-devicetree.bbclass 
b/meta/classes/kernel-devicetree.bbclass
new file mode 100644
index 00..04e2f2695e
--- /dev/null
+++ b/meta/classes/kernel-devicetree.bbclass
@@ -0,0 +1,68 @@
+# Support for device tree generation
+PACKAGES_append = " kernel-devicetree"
+FILES_kernel-devicetree = "/${KERNEL_IMAGEDEST}/*.dtb 
/${KERNEL_IMAGEDEST}/*.dtbo"
+
+normalize_dtb () {
+   DTB="$1"
+   if echo ${DTB} | grep -q '/dts/'; then
+   bbwarn "${DTB} contains the full path to the the dts file, but 
only the dtb name should be used."
+   DTB=`basename ${DTB} | sed 's,\.dts$,.dtb,g'`
+   fi
+   echo "${DTB}"
+}
+
+get_real_dtb_path_in_kernel () {
+   DTB="$1"
+   DTB_PATH="${B}/arch/${ARCH}/boot/dts/${DTB}"
+   if [ ! -e "${DTB_PATH}" ]; then
+   DTB_PATH="${B}/arch/${ARCH}/boot/${DTB}"
+   fi
+   echo "${DTB_PATH}"
+}
+
+do_compile_devicetree() {
+DTBS=""
+   for dtb in ${KERNEL_DEVICETREE}; do
+   dtb=`normalize_dtb "${dtb}"`
+   DTBS="$DTBS $dtb"
+   done
+   oe_runmake -C ${B} ${PARALLEL_MAKE} ${DTBS}
+}
+addtask compile_devicetree after do_compile before do_install
+
+do_install_devicetree[dirs] = "${B}"
+do_install_devicetree[umask] = "022"
+fakeroot do_install_devicetree() {
+   for DTB in ${KERNEL_DEVICETREE}; do
+   DTB=`normalize_dtb "${DTB}"`
+   DTB_EXT=${DTB##*.}
+   DTB_PATH=`get_real_dtb_path_in_kernel "${DTB}"`
+   DTB_BASE_NAME=`basename ${DTB} ."${DTB_EXT}"`
+   install -m 0644 ${DTB_PATH} 
${D}/${KERNEL_IMAGEDEST}/${DTB_BASE_NAME}.${DTB_EXT}
+   for type in ${KERNEL_IMAGETYPE_FOR_MAKE}; do
+   symlink_name=${type}"-"${KERNEL_IMAGE_SYMLINK_NAME}
+   DTB_SYMLINK_NAME=`echo ${symlink_name} | sed 
"s/${MACHINE}/${DTB_BASE_NAME}/g"`
+   ln -sf ${DTB_BASE_NAME}.${DTB_EXT} 
${D}/${KERNEL_IMAGEDEST}/devicetree-${DTB_SYMLINK_NAME}.${DTB_EXT}
+   done
+   done
+}
+addtask install_devicetree after do_install before do_deploy
+
+do_deploy_append() {
+   for DTB in ${KERNEL_DEVICETREE}; do
+   DTB=`normalize_dtb "${DTB}"`
+   DTB_EXT=${DTB##*.}
+   DTB_BASE_NAME=`basename ${DTB} ."${DTB_EXT}"`
+   for type in ${KERNEL_IMAGETYPE_FOR_MAKE}; do
+   base_name=${type}"-"${KERNEL_IMAGE_BASE_NAME}
+   symlink_name=${type}"-"${KERNEL_IMAGE_SYMLINK_NAME}
+   DTB_NAME=`echo ${base_name} | sed 
"s/${MACHINE}/${DTB_BASE_NAME}/g"`
+   DTB_SYMLINK_NAME=`echo ${symlink_name} | sed 
"s/${MACHINE}/${DTB_BASE_NAME}/g"`
+   DTB_PATH=`get_real_dtb_path_in_kernel "${DTB}"`
+   install -d ${DEPLOYDIR}
+   install -m 0644 ${DTB_PATH} 
${DEPLOYDIR}/${DTB_NAME}.${DTB_EXT}
+   ln -sf ${DTB_NAME}.${DTB_EXT} 
${DEPLOYDIR}/${DTB_SYMLINK_NAME}.${DTB_EXT}
+   ln -sf ${DTB_NAME}.${DTB_EXT} 
${DEPLOYDIR}/${DTB_BASE_NAME}.${DTB_EXT}
+   done
+   done
+}
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 02a5e961cb..8c01e90709 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -662,3 +662,7 @@ do_deploy[prefuncs] += "package_get_auto_pr"
 addtask deploy after do_populate_sysroot do_packagedata
 
 EXPORT_FUNCTIONS do_deploy
+
+# If we are using Device Tree support, inherit the class to enable it
+KERNEL_DEVICETREE_CLASS = "${@['kernel-devicetree', 
''][d.getVar('KERNEL_DEVICETREE', False) == None]}"
+inherit ${KERNEL_DEVICETREE_CLASS}
diff --git a/meta/recipes-kernel/linux/linux-dtb.inc 
b/meta/recipes-kernel/linux/linux-dtb.inc
index ca92822d25..f1912775ca 1006

Re: [OE-core] [PATCH 0/7] kernel-yocto: conslidated pull request

2017-09-05 Thread Bruce Ashfield

On 09/05/2017 10:13 AM, Richard Purdie wrote:

Hi Bruce,

We had a locked up qemuppc lsb image and I was able to find backtraces
from the serial console log (/home/pokybuild/yocto-autobuilder/yocto-
worker/nightly-ppc-lsb/build/build/tmp/work/qemuppc-poky-linux/core-
image-lsb/1.0-r0/target_logs/dmesg_output.log in case anyone ever needs
to find that). The log is below, this one is for the 4.9 kernel.

Failure as seen on the AB:
https://autobuilder.yoctoproject.org/main/builders/nightly-ppc-lsb/buil
ds/1189/steps/Running%20Sanity%20Tests/logs/stdio

Not sure what it means, perhaps you can make more sense of it? :)


Very interesting.

I'm (un)fortunately familiar with RCU issues, and obviously, this is
only happening under load. There's clearly a driver issue as it
interacts with whatever is running in userspace.

From the log, it looks like this is running over NFS and pinning the
CPU and the qemu ethernet isn't handling it gracefully.

But exactly what it is, I can't say from that trace. I'll try and do
a cpu-pinned test on qemuppc (over NFS) and see if I can trigger the
same trace.

Bruce



Cheers,

Richard



[0.00] Total memory = 256MB; using 512kB for hash table (at cff8)
[0.00] Linux version 4.9.46-yocto-standard (oe-user@oe-host) (gcc 
version 7.2.0 (GCC) ) #1 PREEMPT Tue Sep 5 00:20:12 GMT 2017
[0.00] Found UniNorth memory controller & host bridge @ 0xf800 
revision: 0x3124be0
[0.00] Mapped at 0xfdfc
[0.00] Found a Keylargo mac-io controller, rev: 0, mapped at 0xfdf4
[0.00] Processor NAP mode on idle enabled.
[0.00] PowerMac motherboard: PowerMac G4 AGP Graphics
[0.00] Using PowerMac machine description
[0.00] bootconsole [udbg0] enabled
[0.00] -
[0.00] Hash_size = 0x8
[0.00] phys_mem_size = 0x1000
[0.00] dcache_bsize  = 0x20
[0.00] icache_bsize  = 0x20
[0.00] cpu_features  = 0x0020047a
[0.00]   possible= 0x05a6fd7f
[0.00]   always  = 0x
[0.00] cpu_user_features = 0x9c01 0x
[0.00] mmu_features  = 0x0001
[0.00] Hash  = 0xcff8
[0.00] Hash_mask = 0x1fff
[0.00] -
[0.00] Found UniNorth PCI host bridge at 0xf200. Firmware bus 
number: 0->0
[0.00] PCI host bridge /pci@f200 (primary) ranges:
[0.00]   IO 0xf200..0xf27f -> 0x
[0.00]  MEM 0x8000..0x8fff -> 0x8000
[0.00] Top of RAM: 0x1000, Total RAM: 0x1000
[0.00] Memory hole size: 0MB
[0.00] Zone ranges:
[0.00]   DMA  [mem 0x-0x0fff]
[0.00]   Normal   empty
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00]   node   0: [mem 0x-0x0fff]
[0.00] Initmem setup node 0 [mem 0x-0x0fff]
[0.00] On node 0 totalpages: 65536
[0.00] free_area_init_node: node 0, pgdat c0acf43c, node_mem_map 
cfd3
[0.00]   DMA zone: 576 pages used for memmap
[0.00]   DMA zone: 0 pages reserved
[0.00]   DMA zone: 65536 pages, LIFO batch:15
[0.00] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
[0.00] pcpu-alloc: [0] 0
[0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total 
pages: 64960
[0.00] Kernel command line: root=/dev/vda rw highres=off  mem=256M 
ip=192.168.7.2::192.168.7.1:255.255.255.0 console=tty console=ttyS0 
console=tty1 console=ttyS0,115200n8 printk.time=1 qemurunner_pid=17112
[0.00] PID hash table entries: 1024 (order: 0, 4096 bytes)
[0.00] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
[0.00] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
[0.00] Sorting __ex_table...
[0.00] Memory: 247220K/262144K available (8164K kernel code, 548K 
rwdata, 1972K rodata, 440K init, 636K bss, 14924K reserved, 0K cma-reserved)
[0.00] Kernel virtual memory layout:
[0.00]   * 0xfffdf000..0xf000  : fixmap
[0.00]   * 0xfd73b000..0xfe00  : early ioremap
[0.00]   * 0xd100..0xfd73b000  : vmalloc & ioremap
[0.00] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[0.00] Preemptible hierarchical RCU implementation.
[0.00]  Build-time adjustment of leaf fanout to 32.
[0.00] NR_IRQS:512 nr_irqs:512 16
[0.00] mpic: Resetting
[0.00] mpic: Setting up MPIC " MPIC 1   " version 1.3 at 8004, max 
1 CPUs
[0.00] mpic: ISU size: 48, shift: 6, mask: 3f
[0.00] mpic: Initializing for 48 sources
[0.00] time_

Re: [OE-core] [PATCH 0/7] kernel-yocto: conslidated pull request

2017-09-05 Thread Richard Purdie
Hi Bruce,

We had a locked up qemuppc lsb image and I was able to find backtraces
from the serial console log (/home/pokybuild/yocto-autobuilder/yocto-
worker/nightly-ppc-lsb/build/build/tmp/work/qemuppc-poky-linux/core-
image-lsb/1.0-r0/target_logs/dmesg_output.log in case anyone ever needs
to find that). The log is below, this one is for the 4.9 kernel.

Failure as seen on the AB:
https://autobuilder.yoctoproject.org/main/builders/nightly-ppc-lsb/buil
ds/1189/steps/Running%20Sanity%20Tests/logs/stdio

Not sure what it means, perhaps you can make more sense of it? :)

Cheers,

Richard



[0.00] Total memory = 256MB; using 512kB for hash table (at cff8)
[0.00] Linux version 4.9.46-yocto-standard (oe-user@oe-host) (gcc 
version 7.2.0 (GCC) ) #1 PREEMPT Tue Sep 5 00:20:12 GMT 2017
[0.00] Found UniNorth memory controller & host bridge @ 0xf800 
revision: 0x3124be0
[0.00] Mapped at 0xfdfc
[0.00] Found a Keylargo mac-io controller, rev: 0, mapped at 0xfdf4
[0.00] Processor NAP mode on idle enabled.
[0.00] PowerMac motherboard: PowerMac G4 AGP Graphics
[0.00] Using PowerMac machine description
[0.00] bootconsole [udbg0] enabled
[0.00] -
[0.00] Hash_size = 0x8
[0.00] phys_mem_size = 0x1000
[0.00] dcache_bsize  = 0x20
[0.00] icache_bsize  = 0x20
[0.00] cpu_features  = 0x0020047a
[0.00]   possible= 0x05a6fd7f
[0.00]   always  = 0x
[0.00] cpu_user_features = 0x9c01 0x
[0.00] mmu_features  = 0x0001
[0.00] Hash  = 0xcff8
[0.00] Hash_mask = 0x1fff
[0.00] -
[0.00] Found UniNorth PCI host bridge at 0xf200. Firmware 
bus number: 0->0
[0.00] PCI host bridge /pci@f200 (primary) ranges:
[0.00]   IO 0xf200..0xf27f -> 0x
[0.00]  MEM 0x8000..0x8fff -> 
0x8000 
[0.00] Top of RAM: 0x1000, Total RAM: 0x1000
[0.00] Memory hole size: 0MB
[0.00] Zone ranges:
[0.00]   DMA  [mem 0x-0x0fff]
[0.00]   Normal   empty
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00]   node   0: [mem 0x-0x0fff]
[0.00] Initmem setup node 0 [mem 0x-0x0fff]
[0.00] On node 0 totalpages: 65536
[0.00] free_area_init_node: node 0, pgdat c0acf43c, node_mem_map 
cfd3
[0.00]   DMA zone: 576 pages used for memmap
[0.00]   DMA zone: 0 pages reserved
[0.00]   DMA zone: 65536 pages, LIFO batch:15
[0.00] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
[0.00] pcpu-alloc: [0] 0 
[0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total 
pages: 64960
[0.00] Kernel command line: root=/dev/vda rw highres=off  mem=256M 
ip=192.168.7.2::192.168.7.1:255.255.255.0 console=tty console=ttyS0 
console=tty1 console=ttyS0,115200n8 printk.time=1 qemurunner_pid=17112
[0.00] PID hash table entries: 1024 (order: 0, 4096 bytes)
[0.00] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
[0.00] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
[0.00] Sorting __ex_table...
[0.00] Memory: 247220K/262144K available (8164K kernel code, 548K 
rwdata, 1972K rodata, 440K init, 636K bss, 14924K reserved, 0K cma-reserved)
[0.00] Kernel virtual memory layout:
[0.00]   * 0xfffdf000..0xf000  : fixmap
[0.00]   * 0xfd73b000..0xfe00  : early ioremap
[0.00]   * 0xd100..0xfd73b000  : vmalloc & ioremap
[0.00] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[0.00] Preemptible hierarchical RCU implementation.
[0.00]  Build-time adjustment of leaf fanout to 32.
[0.00] NR_IRQS:512 nr_irqs:512 16
[0.00] mpic: Resetting
[0.00] mpic: Setting up MPIC " MPIC 1   " version 1.3 at 8004, max 
1 CPUs
[0.00] mpic: ISU size: 48, shift: 6, mask: 3f
[0.00] mpic: Initializing for 48 sources
[0.00] time_init: decrementer frequency = 100.00 MHz
[0.00] time_init: processor frequency   = 266.00 MHz
[0.000867] clocksource: timebase: mask: 0x max_cycles: 
0x171024e7e0, max_idle_ns: 440795205315 ns
[0.001204] clocksource: timebase mult[a00] shift[24] registered
[0.001562] clockevent: decrementer mult[199a] shift[32] cpu[0]
[0.014375] Console: colour dummy device 80x25
[0.030186] console [tty0] enabled
[0.060271] console [ttyS0] enabled
[0.061213] bootconsole [udbg0] 

Re: [OE-core] [PATCH] glibc: Drop obsoleted bits/pthreadtypes-arch.h from multilibbing

2017-09-05 Thread Burton, Ross
The patch does the exact opposite of the commit message, and doesn't
explain why it is doing what it is doing.

Ross

On 5 September 2017 at 09:56, Chunrong Guo  wrote:

> From: Chunrong Guo 
>
> Signed-off-by: Chunrong Guo 
> ---
>  meta/recipes-core/glibc/glibc-package.inc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/recipes-core/glibc/glibc-package.inc
> b/meta/recipes-core/glibc/glibc-package.inc
> index a291148..df3db2c 100644
> --- a/meta/recipes-core/glibc/glibc-package.inc
> +++ b/meta/recipes-core/glibc/glibc-package.inc
> @@ -138,7 +138,7 @@ do_install_append_armeb () {
>  do_install_armmultilib () {
>
> oe_multilib_header bits/endian.h bits/fcntl.h bits/fenv.h
> bits/fp-fast.h bits/hwcap.h bits/ipc.h bits/link.h bits/wordsize.h
> -   oe_multilib_header bits/local_lim.h bits/mman.h bits/msq.h
> bits/pthreadtypes.h  bits/sem.h  bits/semaphore.h bits/setjmp.h
> +   oe_multilib_header bits/local_lim.h bits/mman.h bits/msq.h
> bits/pthreadtypes.h bits/pthreadtypes-arch.h  bits/sem.h  bits/semaphore.h
> bits/setjmp.h
> oe_multilib_header bits/shm.h bits/sigstack.h bits/stat.h
> bits/statfs.h bits/typesizes.h
>
> oe_multilib_header fpu_control.h gnu/lib-names.h gnu/stubs.h
> ieee754.h
> --
> 1.9.0
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH] glibc: Drop obsoleted bits/pthreadtypes-arch.h from multilibbing

2017-09-05 Thread Chunrong Guo
From: Chunrong Guo 

Signed-off-by: Chunrong Guo 
---
 meta/recipes-core/glibc/glibc-package.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-core/glibc/glibc-package.inc 
b/meta/recipes-core/glibc/glibc-package.inc
index a291148..df3db2c 100644
--- a/meta/recipes-core/glibc/glibc-package.inc
+++ b/meta/recipes-core/glibc/glibc-package.inc
@@ -138,7 +138,7 @@ do_install_append_armeb () {
 do_install_armmultilib () {
 
oe_multilib_header bits/endian.h bits/fcntl.h bits/fenv.h 
bits/fp-fast.h bits/hwcap.h bits/ipc.h bits/link.h bits/wordsize.h
-   oe_multilib_header bits/local_lim.h bits/mman.h bits/msq.h 
bits/pthreadtypes.h  bits/sem.h  bits/semaphore.h bits/setjmp.h
+   oe_multilib_header bits/local_lim.h bits/mman.h bits/msq.h 
bits/pthreadtypes.h bits/pthreadtypes-arch.h  bits/sem.h  bits/semaphore.h 
bits/setjmp.h
oe_multilib_header bits/shm.h bits/sigstack.h bits/stat.h bits/statfs.h 
bits/typesizes.h
 
oe_multilib_header fpu_control.h gnu/lib-names.h gnu/stubs.h ieee754.h
-- 
1.9.0

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


Re: [OE-core] [PATCH v2 0/2] Make source code browsable locally - devtool srctree

2017-09-05 Thread Randy MacLeod

On 2017-09-01 08:00 AM, Peter Kjellerstedt wrote:

Well, the most common request we've gotten from the developers is that
they want to be able to search through all the sources, e.g., to find
out where a particular function is used. The tmp directory does not
lend itself very well to this, given that it also contains all build
trees, applied patches and other meta information that bitbake needs.
Thus the idea for the parallel tree with only the source references.

//Peter


A shadow tree of links to the source is "mostly harmless" to experts
and useful for newbies and code browsers as you explained.

The src dir should be under tmp/src though since anything
that can be regenerated shouldn't be in the top level
project directory.

We don't pay that much (enough?) attention to the SECTION tag
and something like half of the oe-core recicpes doen't
have one. I suppose this feature would encourage us to
fix that.

Have you run your script with meta-openembedded and other layers?

--
# Randy MacLeod.  WR Linux
# Wind River an Intel Company
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH 4/7] wic: update help content

2017-09-05 Thread Ed Bartosh
Added ext* partitions to the description of 'wic ls',
'wic cp' and 'wic rm' commands.

Signed-off-by: Ed Bartosh 
---
 scripts/lib/wic/help.py | 64 -
 1 file changed, 32 insertions(+), 32 deletions(-)

diff --git a/scripts/lib/wic/help.py b/scripts/lib/wic/help.py
index ccd33823244..83bd86e7c51 100644
--- a/scripts/lib/wic/help.py
+++ b/scripts/lib/wic/help.py
@@ -288,10 +288,10 @@ wic_ls_usage = """
 
  List content of a partitioned image
 
- usage: wic ls [:[]] [--native-sysroot ]
+ usage: wic ls [:[]] [--native-sysroot ]
 
  This command  outputs either list of image partitions or directory contents
- of vfat partitions.
+ of vfat and ext* partitions.
 
  See 'wic help ls' for more detailed instructions.
 
@@ -300,17 +300,17 @@ wic_ls_usage = """
 wic_ls_help = """
 
 NAME
-wic ls - List contents of partitioned image or vfat partitions
+wic ls - List contents of partitioned image or partition
 
 SYNOPSIS
 wic ls 
-wic ls :
-wic ls :
-wic ls : --native-sysroot 
+wic ls :
+wic ls :
+wic ls : --native-sysroot 
 
 DESCRIPTION
 This command lists either partitions of the image or directory contents
-of vfat partitions.
+of vfat or ext* partitions.
 
 The first form it lists partitions of the image.
 For example:
@@ -319,7 +319,7 @@ DESCRIPTION
 11048576 24438783 23390208  fat16
 2   25165824 50315263 25149440  ext4
 
-Second and third form list directory content of vfat partition:
+Second and third form list directory content of the partition:
 $ wic ls 
tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64.wic:1
 Volume in drive : is boot
  Volume Serial Number is 2DF2-5F02
@@ -351,12 +351,12 @@ DESCRIPTION
 
 wic_cp_usage = """
 
- Copy files and directories to the vfat partitions
+ Copy files and directories to the vfat or ext* partition
 
- usage: wic cp  :[] [--native-sysroot ]
+ usage: wic cp  :[] [--native-sysroot ]
 
- This command  copies local files or directories to the vfat partitions of 
partitioned
- image.
+ This command  copies local files or directories to the vfat or ext* partitions
+of partitioned  image.
 
  See 'wic help cp' for more detailed instructions.
 
@@ -365,19 +365,19 @@ wic_cp_usage = """
 wic_cp_help = """
 
 NAME
-wic cp - copy files and directories to the vfat partitions
+wic cp - copy files and directories to the vfat or ext* partitions
 
 SYNOPSIS
-wic cp  :
-wic cp  :
-wic cp  : --native-sysroot 
+wic cp  :
+wic cp  :
+wic cp  : --native-sysroot 
 
 DESCRIPTION
-This command copies files and directories to the vfat partition of the
-wic image.
+This command copies files and directories to the vfat or ext* partition of
+the partitioned image.
 
 The first form of it copies file or directory to the root directory of
-the vfat partition:
+the partition:
 $ wic cp test.wks 
tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64.wic:1
 $ wic ls 
tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64.wic:1
 Volume in drive : is boot
@@ -393,7 +393,7 @@ DESCRIPTION
  15 677 440 bytes free
 
 The second form of the command copies file or directory to the specified 
directory
-on the vfat partition:
+on the partition:
$ wic cp test 
tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64.wic:1/efi/
$ wic ls 
tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64.wic:1/efi/
Volume in drive : is boot
@@ -413,12 +413,12 @@ DESCRIPTION
 
 wic_rm_usage = """
 
- Remove files or directories from the vfat partitions
+ Remove files or directories from the vfat or ext* partitions
 
- usage: wic rm : [--native-sysroot ]
+ usage: wic rm : [--native-sysroot ]
 
- This command  removes files or directories from the vfat partitions of 
partitioned
- image.
+ This command  removes files or directories from the vfat or ext* partitions of
+ the partitioned image.
 
  See 'wic help rm' for more detailed instructions.
 
@@ -427,15 +427,15 @@ wic_rm_usage = """
 wic_rm_help = """
 
 NAME
-wic rm - remove files or directories from the vfat partitions
+wic rm - remove files or directories from the vfat or ext* partitions
 
 SYNOPSIS
-wic rm  :
-wic rm  : --native-sysroot 
+wic rm  :
+wic rm  : --native-sysroot 
 
 DESCRIPTION
-This command removes files or directories from the vfat partition of the
-wic image:
+This command removes files or directories from the vfat or ext* partition 
of the
+partitioned image:
 
 $ wic ls 
./tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64.wic:1
 Volume in drive : is boot
@@ -474,7 +474,7 @@ wic_write_usage = """
 
  usage: wic write   [--expand [rules]] [--native-sysroot 
]
 
- This command writes wic image to a target device (USB stick, SD card etc).
+ Thi

[OE-core] [PATCH 2/7] wic: implement ext fs support for 'wic cp'

2017-09-05 Thread Ed Bartosh
Implemented copying files to the ext partition
using debugfs tool.

Signed-off-by: Ed Bartosh 
---
 scripts/lib/wic/engine.py | 13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/scripts/lib/wic/engine.py b/scripts/lib/wic/engine.py
index c6a63f2080a..9ebd93ae278 100644
--- a/scripts/lib/wic/engine.py
+++ b/scripts/lib/wic/engine.py
@@ -325,10 +325,15 @@ class Disk:
 
 def copy(self, src, pnum, path):
 """Copy partition image into wic image."""
-cmd = "{} -i {} -snop {} ::{}".format(self.mcopy,
-  self._get_part_image(pnum),
-  src, path)
-exec_cmd(cmd)
+if self.partitions[pnum].fstype.startswith('ext'):
+cmd = "echo -e 'cd {}\nwrite {} {}' | {} -w {}".\
+  format(path, src, os.path.basename(src),
+ self.debugfs, self._get_part_image(pnum))
+else: # fat
+cmd = "{} -i {} -snop {} ::{}".format(self.mcopy,
+  self._get_part_image(pnum),
+  src, path)
+exec_cmd(cmd, as_shell=True)
 self._put_part_image(pnum)
 
 def remove(self, pnum, path):
-- 
2.13.5

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


[OE-core] [PATCH 6/7] wic: selftest: add test_wic_cp_ext test case

2017-09-05 Thread Ed Bartosh
Tested if 'wic cp' correctly copies files to the ext4 partition
of the wic image.

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

diff --git a/meta/lib/oeqa/selftest/cases/wic.py 
b/meta/lib/oeqa/selftest/cases/wic.py
index 95170b946c6..1f0383c091f 100644
--- a/meta/lib/oeqa/selftest/cases/wic.py
+++ b/meta/lib/oeqa/selftest/cases/wic.py
@@ -1007,3 +1007,33 @@ part /etc --source rootfs --ondisk mmcblk0 --fstype=ext4 
--exclude-path bin/ --r
 self.assertEqual(0, result.status)
 self.assertTrue(set(['bin', 'home', 'proc', 'usr', 'var', 'dev', 
'lib', 'sbin']).issubset(
 set(line.split()[-1] for line in 
result.output.split('\n') if line)))
+
+def test_wic_cp_ext(self):
+"""Test copy files and directories to the ext partition."""
+self.assertEqual(0, runCmd("wic create wictestdisk "
+   "--image-name=core-image-minimal "
+   "-D -o %s" % self.resultdir).status)
+images = glob(self.resultdir + "wictestdisk-*.direct")
+self.assertEqual(1, len(images))
+
+sysroot = get_bb_var('RECIPE_SYSROOT_NATIVE', 'wic-tools')
+
+# list directory content of the ext4 partition
+result = runCmd("wic ls %s:2/ -n %s" % (images[0], sysroot))
+self.assertEqual(0, result.status)
+dirs = set(line.split()[-1] for line in result.output.split('\n') if 
line)
+self.assertTrue(set(['bin', 'home', 'proc', 'usr', 'var', 'dev', 
'lib', 'sbin']).issubset(dirs))
+
+with NamedTemporaryFile("w", suffix=".wic-cp") as testfile:
+testfile.write("test")
+
+# copy file to the partition
+result = runCmd("wic cp %s %s:2/ -n %s" % (testfile.name, 
images[0], sysroot))
+self.assertEqual(0, result.status)
+
+# check if file is there
+result = runCmd("wic ls %s:2/ -n %s" % (images[0], sysroot))
+self.assertEqual(0, result.status)
+newdirs = set(line.split()[-1] for line in 
result.output.split('\n') if line)
+self.assertEqual(newdirs.difference(dirs), 
set([os.path.basename(testfile.name)]))
+
-- 
2.13.5

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


[OE-core] [PATCH 7/7] wic: selftest: add test_wic_rm_ext test case

2017-09-05 Thread Ed Bartosh
Tested if 'wic rm' correctly removes files from the ext4 partition
of the wic image.

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

diff --git a/meta/lib/oeqa/selftest/cases/wic.py 
b/meta/lib/oeqa/selftest/cases/wic.py
index 1f0383c091f..e416a3724ab 100644
--- a/meta/lib/oeqa/selftest/cases/wic.py
+++ b/meta/lib/oeqa/selftest/cases/wic.py
@@ -1037,3 +1037,26 @@ part /etc --source rootfs --ondisk mmcblk0 --fstype=ext4 
--exclude-path bin/ --r
 newdirs = set(line.split()[-1] for line in 
result.output.split('\n') if line)
 self.assertEqual(newdirs.difference(dirs), 
set([os.path.basename(testfile.name)]))
 
+def test_wic_rm_ext(self):
+"""Test removing files from the ext partition."""
+self.assertEqual(0, runCmd("wic create mkefidisk "
+   "--image-name=core-image-minimal "
+   "-D -o %s" % self.resultdir).status)
+images = glob(self.resultdir + "mkefidisk-*.direct")
+self.assertEqual(1, len(images))
+
+sysroot = get_bb_var('RECIPE_SYSROOT_NATIVE', 'wic-tools')
+
+# list directory content of the /etc directory on ext4 partition
+result = runCmd("wic ls %s:2/etc/ -n %s" % (images[0], sysroot))
+self.assertEqual(0, result.status)
+self.assertTrue('fstab' in [line.split()[-1] for line in 
result.output.split('\n') if line])
+
+# remove file
+result = runCmd("wic rm %s:2/etc/fstab -n %s" % (images[0], sysroot))
+self.assertEqual(0, result.status)
+
+# check if it's removed
+result = runCmd("wic ls %s:2/etc/ -n %s" % (images[0], sysroot))
+self.assertEqual(0, result.status)
+self.assertTrue('fstab' not in [line.split()[-1] for line in 
result.output.split('\n') if line])
-- 
2.13.5

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


[OE-core] [PATCH 1/7] wic: implement ext fs support for 'wic ls'

2017-09-05 Thread Ed Bartosh
Implemented listing directory contents for ext file
system using debugfs tool.

Signed-off-by: Ed Bartosh 
---
 scripts/lib/wic/engine.py | 15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/scripts/lib/wic/engine.py b/scripts/lib/wic/engine.py
index eafc6c783ec..c6a63f2080a 100644
--- a/scripts/lib/wic/engine.py
+++ b/scripts/lib/wic/engine.py
@@ -234,7 +234,7 @@ def wic_list(args, scripts_path):
 
 
 class Disk:
-def __init__(self, imagepath, native_sysroot, fstypes=('fat',)):
+def __init__(self, imagepath, native_sysroot, fstypes=('fat', 'ext')):
 self.imagepath = imagepath
 self.native_sysroot = native_sysroot
 self.fstypes = fstypes
@@ -280,7 +280,7 @@ class Disk:
 def __getattr__(self, name):
 """Get path to the executable in a lazy way."""
 if name in ("mdir", "mcopy", "mdel", "mdeltree", "sfdisk", "e2fsck",
-"resize2fs", "mkswap", "mkdosfs"):
+"resize2fs", "mkswap", "mkdosfs", "debugfs"):
 aname = "_%s" % name
 if aname not in self.__dict__:
 setattr(self, aname, find_executable(name, self.paths))
@@ -314,9 +314,14 @@ class Disk:
 seek=self.partitions[pnum].start)
 
 def dir(self, pnum, path):
-return exec_cmd("{} -i {} ::{}".format(self.mdir,
-   self._get_part_image(pnum),
-   path))
+if self.partitions[pnum].fstype.startswith('ext'):
+return exec_cmd("{} {} -R 'ls -l {}'".format(self.debugfs,
+ 
self._get_part_image(pnum),
+ path), as_shell=True)
+else: # fat
+return exec_cmd("{} -i {} ::{}".format(self.mdir,
+   self._get_part_image(pnum),
+   path))
 
 def copy(self, src, pnum, path):
 """Copy partition image into wic image."""
-- 
2.13.5

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


[OE-core] [PATCH 3/7] wic: implement ext fs support for 'wic rm'

2017-09-05 Thread Ed Bartosh
Implemented removing files or directories from the ext
partition using debugfs tool.

Signed-off-by: Ed Bartosh 
---
 scripts/lib/wic/engine.py | 27 ---
 1 file changed, 16 insertions(+), 11 deletions(-)

diff --git a/scripts/lib/wic/engine.py b/scripts/lib/wic/engine.py
index 9ebd93ae278..edcfab39ef5 100644
--- a/scripts/lib/wic/engine.py
+++ b/scripts/lib/wic/engine.py
@@ -339,18 +339,23 @@ class Disk:
 def remove(self, pnum, path):
 """Remove files/dirs from the partition."""
 partimg = self._get_part_image(pnum)
-cmd = "{} -i {} ::{}".format(self.mdel, partimg, path)
-try:
-exec_cmd(cmd)
-except WicError as err:
-if "not found" in str(err) or "non empty" in str(err):
-# mdel outputs 'File ... not found' or 'directory .. non empty"
-# try to use mdeltree as path could be a directory
-cmd = "{} -i {} ::{}".format(self.mdeltree,
- partimg, path)
+if self.partitions[pnum].fstype.startswith('ext'):
+exec_cmd("{} {} -wR 'rm {}'".format(self.debugfs,
+self._get_part_image(pnum),
+path), as_shell=True)
+else: # fat
+cmd = "{} -i {} ::{}".format(self.mdel, partimg, path)
+try:
 exec_cmd(cmd)
-else:
-raise err
+except WicError as err:
+if "not found" in str(err) or "non empty" in str(err):
+# mdel outputs 'File ... not found' or 'directory .. non 
empty"
+# try to use mdeltree as path could be a directory
+cmd = "{} -i {} ::{}".format(self.mdeltree,
+ partimg, path)
+exec_cmd(cmd)
+else:
+raise err
 self._put_part_image(pnum)
 
 def write(self, target, expand):
-- 
2.13.5

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


[OE-core] [PATCH 5/7] wic: selftest: add test_wic_ls_ext test case

2017-09-05 Thread Ed Bartosh
Tested if 'wic ls' correctly lists directory contents
of the ext* partition.

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

diff --git a/meta/lib/oeqa/selftest/cases/wic.py 
b/meta/lib/oeqa/selftest/cases/wic.py
index aa73ba4f7ea..95170b946c6 100644
--- a/meta/lib/oeqa/selftest/cases/wic.py
+++ b/meta/lib/oeqa/selftest/cases/wic.py
@@ -991,3 +991,19 @@ part /etc --source rootfs --ondisk mmcblk0 --fstype=ext4 
--exclude-path bin/ --r
 os.unlink(new_image_path)
 if os.path.exists(image_path + '.bak'):
 os.rename(image_path + '.bak', image_path)
+
+def test_wic_ls_ext(self):
+"""Test listing content of the ext partition using 'wic ls'"""
+self.assertEqual(0, runCmd("wic create wictestdisk "
+   "--image-name=core-image-minimal "
+   "-D -o %s" % self.resultdir).status)
+images = glob(self.resultdir + "wictestdisk-*.direct")
+self.assertEqual(1, len(images))
+
+sysroot = get_bb_var('RECIPE_SYSROOT_NATIVE', 'wic-tools')
+
+# list directory content of the second ext4 partition
+result = runCmd("wic ls %s:2/ -n %s" % (images[0], sysroot))
+self.assertEqual(0, result.status)
+self.assertTrue(set(['bin', 'home', 'proc', 'usr', 'var', 'dev', 
'lib', 'sbin']).issubset(
+set(line.split()[-1] for line in 
result.output.split('\n') if line)))
-- 
2.13.5

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


[OE-core] [PATCH 0/7] implement wic ls/cp/rm for ext partitions

2017-09-05 Thread Ed Bartosh
Hi,

This patchset implements listing directory contents, copying and removing
files on ext[2,3,4] partitions of partitioned images.

The following changes since commit ee5bce2d11e783c0921df47b629025a6b67c44bf:

  kernel-dev: Removed bad reference for creating patches. (2017-09-02 00:52:49 
+0100)

are available in the git repository at:

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

Ed Bartosh (7):
  wic: implement ext fs support for 'wic ls'
  wic: implement ext fs support for 'wic cp'
  wic: implement ext fs support for 'wic rm'
  wic: update help content
  wic: selftest: add test_wic_ls_ext test case
  wic: selftest: add test_wic_cp_ext test case
  wic: selftest: add test_wic_rm_ext test case

 meta/lib/oeqa/selftest/cases/wic.py | 69 +
 scripts/lib/wic/engine.py   | 55 ++---
 scripts/lib/wic/help.py | 64 +-
 3 files changed, 136 insertions(+), 52 deletions(-)

--
Regards,
Ed

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


Re: [OE-core] [PATCH 0/7] Revamp the Go support

2017-09-05 Thread Matt Madison
Looks good overall.  Thanks, Otavio.

-Matt

On Mon, Sep 4, 2017 at 2:06 PM, Otavio Salvador  wrote:
> This is not yet complete but does improve some parts of
> Go support on OE-Core.
>
> We are trying to port as much as possible work done by Matt on
> meta-golang back to OE-Core and also to avoid carrying old releases as
> there is no need to support more versions of Go toolchain.
>
> The first commits on this serie does fix errors in current
> implementation, the others are improvements and clean ups.
>
>
> Otavio Salvador (7):
>   goarch.bbclass: Stop passing True as second argument of d.getVar
>   go.bbclass: Fix binary installation path detection
>   go: Remove Go 1.6 and 1.7 releases
>   goarch.bbclass: Add support for ARMv5
>   go.bbclass: Use a global Go build flags
>   go.bbclass: Enable parallel build
>   go.bbclass: Use an auxiliary variable to add the build dependencies
>
>  meta/classes/go.bbclass| 34 ++--
>  meta/classes/goarch.bbclass| 20 +++
>  meta/recipes-devtools/go/go-1.6.inc| 19 ---
>  .../go/go-1.6/armhf-elf-header.patch   | 23 
>  .../go/go-1.6/fix-cc-handling.patch| 50 -
>  .../go/go-1.6/fix-target-cc-for-build.patch| 17 --
>  meta/recipes-devtools/go/go-1.6/gotooldir.patch| 30 ---
>  .../go/go-1.6/split-host-and-target-build.patch| 63 
> --
>  meta/recipes-devtools/go/go-1.6/syslog.patch   | 62 -
>  meta/recipes-devtools/go/go-1.7.inc| 19 ---
>  .../go/go-1.7/armhf-elf-header.patch   | 23 
>  .../go/go-1.7/fix-cc-handling.patch| 50 -
>  .../go/go-1.7/fix-target-cc-for-build.patch| 17 --
>  meta/recipes-devtools/go/go-1.7/gotooldir.patch| 30 ---
>  .../go/go-1.7/split-host-and-target-build.patch| 62 -
>  meta/recipes-devtools/go/go-1.7/syslog.patch   | 62 -
>  meta/recipes-devtools/go/go-cross_1.7.bb   |  5 --
>  meta/recipes-devtools/go/go_1.6.bb |  4 --
>  meta/recipes-devtools/go/go_1.7.bb |  2 -
>  19 files changed, 40 insertions(+), 552 deletions(-)
>  delete mode 100644 meta/recipes-devtools/go/go-1.6.inc
>  delete mode 100644 meta/recipes-devtools/go/go-1.6/armhf-elf-header.patch
>  delete mode 100644 meta/recipes-devtools/go/go-1.6/fix-cc-handling.patch
>  delete mode 100644 
> meta/recipes-devtools/go/go-1.6/fix-target-cc-for-build.patch
>  delete mode 100644 meta/recipes-devtools/go/go-1.6/gotooldir.patch
>  delete mode 100644 
> meta/recipes-devtools/go/go-1.6/split-host-and-target-build.patch
>  delete mode 100644 meta/recipes-devtools/go/go-1.6/syslog.patch
>  delete mode 100644 meta/recipes-devtools/go/go-1.7.inc
>  delete mode 100644 meta/recipes-devtools/go/go-1.7/armhf-elf-header.patch
>  delete mode 100644 meta/recipes-devtools/go/go-1.7/fix-cc-handling.patch
>  delete mode 100644 
> meta/recipes-devtools/go/go-1.7/fix-target-cc-for-build.patch
>  delete mode 100644 meta/recipes-devtools/go/go-1.7/gotooldir.patch
>  delete mode 100644 
> meta/recipes-devtools/go/go-1.7/split-host-and-target-build.patch
>  delete mode 100644 meta/recipes-devtools/go/go-1.7/syslog.patch
>  delete mode 100644 meta/recipes-devtools/go/go-cross_1.7.bb
>  delete mode 100644 meta/recipes-devtools/go/go_1.6.bb
>  delete mode 100644 meta/recipes-devtools/go/go_1.7.bb
>
> --
> 2.14.1
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH 6/7] go.bbclass: Enable parallel build

2017-09-05 Thread Matt Madison
On Mon, Sep 4, 2017 at 2:06 PM, Otavio Salvador  wrote:
> The parallel build is based on PARALLEL_MAKE variable but can be
> overriden setting the GO_PARALLEL_BUILD one.
>
> This change is based on the meta-golang[1] layer. Thanks to Matt
> Madison  for his work on this.
>
> 1. https://github.com/madisongh/meta-golang
>
> Signed-off-by: Otavio Salvador 
> ---
>
>  meta/classes/go.bbclass | 20 
>  1 file changed, 20 insertions(+)
>
> diff --git a/meta/classes/go.bbclass b/meta/classes/go.bbclass
> index 45f2add810..f80134bf8e 100644
> --- a/meta/classes/go.bbclass
> +++ b/meta/classes/go.bbclass
> @@ -1,11 +1,31 @@
>  inherit goarch
>
> +def get_go_parallel_make(d):
> +pm = (d.getVar('PARALLEL_MAKE') or '').split()
> +# look for '-j' and throw other options (e.g. '-l') away
> +# because they might have a different meaning in golang
> +while pm:
> +opt = pm.pop(0)
> +if opt == '-j':
> +v = pm.pop(0)
> +elif opt.startswith('-j'):
> +v = opt[2:].strip()
> +else:
> +continue
> +
> +return '-p %d' % int(v)
> +
> +return ""
> +
> +GO_PARALLEL_BUILD ?= "${@get_go_parallel_make(d)}"

This added variable should be appended to BB_HASHBASE_WHITELIST.

Thanks,
-Matt

> +
>  GOROOT_class-native = "${STAGING_LIBDIR_NATIVE}/go"
>  GOROOT = "${STAGING_LIBDIR_NATIVE}/${TARGET_SYS}/go"
>  GOBIN_FINAL_class-native = "${GOROOT_FINAL}/bin"
>  GOBIN_FINAL = "${GOROOT_FINAL}/${GO_BUILD_BINDIR}"
>
>  export GOBUILDFLAGS ?= "-x -v ${GO_EXTLDFLAGS}"
> +GOBUILDFLAGS_prepend_task-compile = "${GO_PARALLEL_BUILD} "
>
>  export GOOS = "${TARGET_GOOS}"
>  export GOARCH = "${TARGET_GOARCH}"
> --
> 2.14.1
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH 5/7] go.bbclass: Use a global Go build flags

2017-09-05 Thread Matt Madison
On Mon, Sep 4, 2017 at 2:06 PM, Otavio Salvador  wrote:
> We now use a GOBUILDFLAGS to provide a global variable to control the
> build flags to be given to Go.
>
> This change is based on the meta-golang[1] layer. Thanks to Matt
> Madison  for his work on this.
>
> 1. https://github.com/madisongh/meta-golang
>
> Signed-off-by: Otavio Salvador 
> ---
>
>  meta/classes/go.bbclass | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/meta/classes/go.bbclass b/meta/classes/go.bbclass
> index e073cb91b5..45f2add810 100644
> --- a/meta/classes/go.bbclass
> +++ b/meta/classes/go.bbclass
> @@ -5,6 +5,8 @@ GOROOT = "${STAGING_LIBDIR_NATIVE}/${TARGET_SYS}/go"
>  GOBIN_FINAL_class-native = "${GOROOT_FINAL}/bin"
>  GOBIN_FINAL = "${GOROOT_FINAL}/${GO_BUILD_BINDIR}"
>
> +export GOBUILDFLAGS ?= "-x -v ${GO_EXTLDFLAGS}"

You might want to omit the '-x' flag here as a default.  It's useful
when debugging problems with the toolchain, but can make it harder to
find error messages emitted by the compiler.

And I don't think GO_EXTLDFLAGS is being set anywhere (yet)?

Thanks,
-Matt

> +
>  export GOOS = "${TARGET_GOOS}"
>  export GOARCH = "${TARGET_GOARCH}"
>  export GOARM = "${TARGET_GOARM}"
> @@ -32,7 +34,7 @@ GO_INSTALL ?= "${GO_IMPORT}/..."
>  do_go_compile() {
> GOPATH=${S}:${STAGING_LIBDIR}/${TARGET_SYS}/go go env
> if [ -n "${GO_INSTALL}" ]; then
> -   GOPATH=${S}:${STAGING_LIBDIR}/${TARGET_SYS}/go go install -v 
> ${GO_INSTALL}
> +   GOPATH=${S}:${STAGING_LIBDIR}/${TARGET_SYS}/go go install 
> ${GOBUILDFLAGS} ${GO_INSTALL}
> fi
>  }
>
> --
> 2.14.1
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH] rootfs: improve postinst intercept logging

2017-09-05 Thread Ross Burton
Ensure we capture stderr, always write the output to the log, and don't be so
emotional in the warning message.

Signed-off-by: Ross Burton 
---
 meta/lib/oe/rootfs.py | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/meta/lib/oe/rootfs.py b/meta/lib/oe/rootfs.py
index 96591f370e6..9d4727e76c1 100644
--- a/meta/lib/oe/rootfs.py
+++ b/meta/lib/oe/rootfs.py
@@ -302,10 +302,11 @@ class Rootfs(object, metaclass=ABCMeta):
 bb.note("> Executing %s intercept ..." % script)
 
 try:
-subprocess.check_output(script_full)
+output = subprocess.check_output(script_full, 
stderr=subprocess.STDOUT)
+if output: bb.note(output.decode("utf-8"))
 except subprocess.CalledProcessError as e:
-bb.warn("The postinstall intercept hook '%s' failed (exit 
code: %d)! See log for details! (Output: %s)" %
-(script, e.returncode, e.output))
+bb.warn("The postinstall intercept hook '%s' failed, details 
in log.do_rootfs" % script)
+bb.note("Exit code %d. Output:\n%s" % (e.returncode, 
e.output.decode("utf-8")))
 
 with open(script_full) as intercept:
 registered_pkgs = None
-- 
2.11.0

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


Re: [OE-core] [PATCH 1/1] dbus: fix ptest runtime failures

2017-09-05 Thread Burton, Ross
On 5 September 2017 at 04:13,  wrote:

> +PACKAGECONFIG[ptest] = "--enable-embedded-tests --enable-asserts
> --enable-verbose-mode,--disable-embedded-tests --disable-asserts
> --disable-verbose-mode"
>

Same question with V2: does enabling ptest change the dbus daemon in ways
that make it slower/less secure/etc.

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


Re: [OE-core] [PATCH] ell: upgrade SRCREV and move recipes to core

2017-09-05 Thread Burton, Ross
[CC'ing the list]

On 5 September 2017 at 10:52, Ankit Navik  wrote:

> ok, I was not aware of release.
> This library, I use in our project called OMA-DM IMEI Sync.
> It should be fine, If we don't update as well. since initial recipes of
> ELL is already merged in oe-core.
>

Presumably you meant meta-oe, not oe-core.

Being used in a single other package that isn't part of core doesn't count
as sufficient justification for oe-core, so this can stay in meta-oe.

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


[OE-core] [PATCH 2/2] sysklogd: conflict with other syslog daemons

2017-09-05 Thread Chen Qi
Set RCONFLICTS to disallow multiple syslog daemon providers to be installed
on the target, and remove codes that deal with such situation.

Also, set ALTERNATIVE_PRIORITY back to 100. It was set to '10' in case of
systemd because sysklogd didn't have systemd support. For now, if we disallow
multiple syslog daemons to be installed, and it stays '10', then if sysklogd
is installed on target, the /sbin/syslogd would link to /bin/busybox.nosuid,
causing sysklogd service files using busybox's utility.

Signed-off-by: Chen Qi 
---
 meta/recipes-extended/sysklogd/sysklogd.inc | 12 
 1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/meta/recipes-extended/sysklogd/sysklogd.inc 
b/meta/recipes-extended/sysklogd/sysklogd.inc
index 644728a..e9a4a02 100644
--- a/meta/recipes-extended/sysklogd/sysklogd.inc
+++ b/meta/recipes-extended/sysklogd/sysklogd.inc
@@ -32,7 +32,8 @@ SYSTEMD_SERVICE_${PN} = "syslogd.service klogd.service"
 SYSTEMD_AUTO_ENABLE = "enable"
 
 INITSCRIPT_NAME = "syslog"
-CONFFILES_${PN} = "${sysconfdir}/syslog.conf.${BPN}"
+CONFFILES_${PN} = "${sysconfdir}/syslog.conf"
+RCONFLICTS_${PN}-syslog = "rsyslog busybox-syslog syslog-ng"
 
 CFLAGS += "-DSYSV -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE"
 
@@ -57,20 +58,15 @@ do_install () {
 
 FILES_${PN} += 
"${@bb.utils.contains('DISTRO_FEATURES','systemd','${exec_prefix}/lib/tmpfiles.d/sysklogd.conf',
 '', d)}"
 
-# sysklogd package has no internal systemd support, so we weigh busybox's
-# sysklogd utility over it in case of systemd
-ALTERNATIVE_PRIORITY = 
"${@bb.utils.contains('DISTRO_FEATURES','systemd','10','100',d)}"
+ALTERNATIVE_PRIORITY = "100"
 
-ALTERNATIVE_${PN} = "syslogd klogd syslog-conf \
-${@bb.utils.contains('DISTRO_FEATURES','sysvinit','syslog-init','',d)}"
+ALTERNATIVE_${PN} = "syslogd klogd"
 
 ALTERNATIVE_${PN}-doc = "syslogd.8"
 ALTERNATIVE_LINK_NAME[syslogd.8] = "${mandir}/man8/syslogd.8"
 
 ALTERNATIVE_LINK_NAME[syslogd] = "${base_sbindir}/syslogd"
 ALTERNATIVE_LINK_NAME[klogd] = "${base_sbindir}/klogd"
-ALTERNATIVE_LINK_NAME[syslog-init] = "${sysconfdir}/init.d/syslog"
-ALTERNATIVE_LINK_NAME[syslog-conf] = "${sysconfdir}/syslog.conf"
 
 pkg_prerm_${PN} () {
if test "x$D" = "x"; then
-- 
1.9.1

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


[OE-core] [PATCH 0/2] disallow multiple syslog daemons to be installed

2017-09-05 Thread Chen Qi
In OE core, we had the assumption that multiple syslog daemons could be 
installed
at the same time. We did some work to cope with this assumption, including
using update-alternatives to manage syslog related files.

In meta-openembedded, rsyslog and syslog-ng have already set RCONFLICTS to avoid
being installed with other syslog daemons.

Checking Fedora and Ubuntu, they both disallow installation of multiple syslog
daemons. (For other distros, I haven't checked.)

I support forbidding installing multiple syslog daemons. Reasons are below.
1) It makes things simpler and cleaner.
2) It doesn't make much sense to install multiple syslog daemons.
3) Our current implementation has some problems. One of them is that the
   /etc/systemd/system/syslog.service symlink is determined by the installation
   order of syslog daemons, while other syslog related files including syslog
   configuration files are determined by update-alternatives mechanism.
   For more info for the /etc/systemd/system/syslog.service symlink, please
   refer to https://www.freedesktop.org/wiki/Software/systemd/syslog/.

These two patches fix busybox and sysklogd to disallow installing multiple 
syslog
daemons.

The following changes since commit ee5bce2d11e783c0921df47b629025a6b67c44bf:

  kernel-dev: Removed bad reference for creating patches. (2017-09-02 00:52:49 
+0100)

are available in the git repository at:

  git://git.pokylinux.org/poky-contrib ChenQi/syslog-conflicts
  http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=ChenQi/syslog-conflicts

Chen Qi (2):
  busybox: fix syslog related meta data
  sysklogd: conflict with other syslog daemons

 meta/recipes-core/busybox/busybox.inc   | 27 +++
 meta/recipes-extended/sysklogd/sysklogd.inc | 12 
 2 files changed, 11 insertions(+), 28 deletions(-)

-- 
1.9.1

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


[OE-core] [PATCH 1/2] busybox: fix syslog related meta data

2017-09-05 Thread Chen Qi
Set RCONFLICTS to disallow multiple syslog daemon providers to be installed
on the target at the same time,  and remove codes which dealt with such
situation.

Supporting multiple syslog daemons on the same image doesn't have much sense.
rsyslog and syslog-ng in meta-oe have set RCONFLICTS to disallow this. And
we do the same for busybox.

Also, remove the line of creating a meaningless symlink of
/lib/systemd/syslog.service to /dev/null.

Signed-off-by: Chen Qi 
---
 meta/recipes-core/busybox/busybox.inc | 27 +++
 1 file changed, 7 insertions(+), 20 deletions(-)

diff --git a/meta/recipes-core/busybox/busybox.inc 
b/meta/recipes-core/busybox/busybox.inc
index 735b1f6..48910ca 100644
--- a/meta/recipes-core/busybox/busybox.inc
+++ b/meta/recipes-core/busybox/busybox.inc
@@ -41,7 +41,9 @@ INITSCRIPT_NAME_${PN}-udhcpd = "busybox-udhcpd"
 SYSTEMD_PACKAGES = "${PN}-syslog"
 SYSTEMD_SERVICE_${PN}-syslog = "${@bb.utils.contains('SRC_URI', 
'file://syslog.cfg', 'busybox-syslog.service', '', d)}"
 
-CONFFILES_${PN}-syslog = "${sysconfdir}/syslog-startup.conf.${BPN}"
+CONFFILES_${PN}-syslog = "${sysconfdir}/syslog-startup.conf"
+RCONFLICTS_${PN}-syslog = "rsyslog sysklogd syslog-ng"
+
 CONFFILES_${PN}-mdev = "${sysconfdir}/mdev.conf"
 
 RRECOMMENDS_${PN} = "${PN}-syslog ${PN}-udhcpc"
@@ -248,9 +250,9 @@ do_install () {
fi
 
if grep -q "CONFIG_SYSLOGD=y" ${B}/.config; then
-   install -m 0755 ${WORKDIR}/syslog 
${D}${sysconfdir}/init.d/syslog.${BPN}
-   install -m 644 ${WORKDIR}/syslog-startup.conf 
${D}${sysconfdir}/syslog-startup.conf.${BPN}
-   install -m 644 ${WORKDIR}/syslog.conf 
${D}${sysconfdir}/syslog.conf.${BPN}
+   install -m 0755 ${WORKDIR}/syslog 
${D}${sysconfdir}/init.d/syslog
+   install -m 644 ${WORKDIR}/syslog-startup.conf 
${D}${sysconfdir}/syslog-startup.conf
+   install -m 644 ${WORKDIR}/syslog.conf 
${D}${sysconfdir}/syslog.conf
fi
if grep "CONFIG_CROND=y" ${B}/.config; then
install -m 0755 ${WORKDIR}/busybox-cron 
${D}${sysconfdir}/init.d/
@@ -311,7 +313,6 @@ do_install () {
install -d ${D}${sysconfdir}/default
install -m 0644 ${WORKDIR}/busybox-syslog.default 
${D}${sysconfdir}/default/busybox-syslog
 fi
-ln -sf /dev/null ${D}${systemd_unitdir}/system/syslog.service
 fi
 if grep -q "CONFIG_KLOGD=y" ${B}/.config; then
 install -d ${D}${systemd_unitdir}/system
@@ -322,7 +323,7 @@ do_install () {
 
 # Remove the sysvinit specific configuration file for systemd systems to 
avoid confusion
 if ${@bb.utils.contains('DISTRO_FEATURES', 'sysvinit', 'false', 'true', 
d)}; then
-   rm -f ${D}${sysconfdir}/syslog-startup.conf.${BPN}
+   rm -f ${D}${sysconfdir}/syslog-startup.conf
 fi
 }
 
@@ -336,20 +337,6 @@ inherit update-alternatives
 
 ALTERNATIVE_PRIORITY = "50"
 
-ALTERNATIVE_${PN}-syslog += "${@bb.utils.contains('SRC_URI', 
'file://syslog.cfg', 'syslog-conf', '', d)}"
-ALTERNATIVE_LINK_NAME[syslog-conf] = "${@bb.utils.contains('SRC_URI', 
'file://syslog.cfg', "${sysconfdir}/syslog.conf", '', d)}"
-
-python () {
-if bb.utils.contains('DISTRO_FEATURES', 'sysvinit', True, False, d):
-pn = d.getVar('PN')
-d.appendVar('ALTERNATIVE_%s-syslog' % (pn), ' syslog-init')
-d.setVarFlag('ALTERNATIVE_LINK_NAME', 'syslog-init', 
'%s/init.d/syslog' % (d.getVar('sysconfdir')))
-d.setVarFlag('ALTERNATIVE_TARGET', 'syslog-init', 
'%s/init.d/syslog.%s' % (d.getVar('sysconfdir'), d.getVar('BPN')))
-d.appendVar('ALTERNATIVE_%s-syslog' % (pn), ' syslog-startup-conf')
-d.setVarFlag('ALTERNATIVE_LINK_NAME', 'syslog-startup-conf', 
'%s/syslog-startup.conf' % (d.getVar('sysconfdir')))
-d.setVarFlag('ALTERNATIVE_TARGET', 'syslog-startup-conf', 
'%s/syslog-startup.conf.%s' % (d.getVar('sysconfdir'), d.getVar('BPN')))
-}
-
 python do_package_prepend () {
 # We need to load the full set of busybox provides from the 
/etc/busybox.links
 # Use this to see the update-alternatives with the right information
-- 
1.9.1

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


[OE-core] [PATCH] linux-firmware: package qat-firmware

2017-09-05 Thread Liwei Song
Add packages for QAT firmware

Signed-off-by: Liwei Song 
---
 .../linux-firmware/linux-firmware_git.bb   | 27 ++
 1 file changed, 27 insertions(+)

diff --git a/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb 
b/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
index 3b363778f8bf..fc67f2811c08 100644
--- a/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
+++ b/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
@@ -253,6 +253,7 @@ PACKAGES =+ "${PN}-ralink-license ${PN}-ralink \
  ${PN}-ibt-license ${PN}-ibt ${PN}-ibt-misc \
  ${PN}-ibt-11-5 ${PN}-ibt-12-16 ${PN}-ibt-hw-37-7 
${PN}-ibt-hw-37-8 \
  ${PN}-i915-license ${PN}-i915 \
+ ${PN}-qat-license ${PN}-qat_895xcc ${PN}-qat_895xcc_mmp 
${PN}-qat_c3xxx ${PN}-qat_c3xxx_mmp ${PN}-qat_c62x ${PN}-qat_c62x_mmp 
${PN}-qat_mmp \
  ${PN}-adsp-sst-license ${PN}-adsp-sst \
  ${PN}-bnx2-mips \
  ${PN}-netronome-license ${PN}-netronome \
@@ -679,6 +680,32 @@ LICENSE_${PN}-adsp-sst-license= "Firmware-adsp_sst"
 FILES_${PN}-adsp-sst  = 
"${nonarch_base_libdir}/firmware/intel/dsp_fw*"
 RDEPENDS_${PN}-adsp-sst   = "${PN}-adsp-sst-license"
 
+# For qat
+LICENSE_${PN}-qat_895xcc   = "Firmware-qat"
+LICENSE_${PN}-qat_895xcc_mmp   = "Firmware-qat"
+LICENSE_${PN}-qat_c3xxx= "Firmware-qat"
+LICENSE_${PN}-qat_c3xxx_mmp= "Firmware-qat"
+LICENSE_${PN}-qat_c62x = "Firmware-qat"
+LICENSE_${PN}-qat_c62x_mmp = "Firmware-qat"
+LICENSE_${PN}-qat_mmp  = "Firmware-qat"
+
+FILES_${PN}-qat-license= 
"${nonarch_base_libdir}/firmware/LICENCE.qat_firmware"
+FILES_${PN}-qat_895xcc = 
"${nonarch_base_libdir}/firmware/qat_895xcc.bin"
+FILES_${PN}-qat_895xcc_mmp = 
"${nonarch_base_libdir}/firmware/qat_895xcc_mmp.bin"
+FILES_${PN}-qat_c3xxx  = 
"${nonarch_base_libdir}/firmware/qat_c3xxx.bin"
+FILES_${PN}-qat_c3xxx_mmp  = 
"${nonarch_base_libdir}/firmware/qat_c3xxx_mmp.bin"
+FILES_${PN}-qat_c62x   = "${nonarch_base_libdir}/firmware/qat_c62x.bin"
+FILES_${PN}-qat_c62x_mmp   = 
"${nonarch_base_libdir}/firmware/qat_c62x_mmp.bin"
+FILES_${PN}-qat_mmp= "${nonarch_base_libdir}/firmware/qat_mmp.bin"
+
+RDEPENDS_${PN}-qat_895xcc = "${PN}-qat-license"
+RDEPENDS_${PN}-qat_895xcc_mmp = "${PN}-qat-license"
+RDEPENDS_${PN}-qat_c3xxx = "${PN}-qat-license"
+RDEPENDS_${PN}-qat_c3xxx_mmp = "${PN}-qat-license"
+RDEPENDS_${PN}-qat_c62x = "${PN}-qat-license"
+RDEPENDS_${PN}-qat_c62x_mmp = "${PN}-qat-license"
+RDEPENDS_${PN}-qat_mmp = "${PN}-qat-license"
+
 # For other firmwares
 # Maybe split out to separate packages when needed.
 LICENSE_${PN} = "\
-- 
2.7.4

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


Re: [OE-core] [PATCH] libxml2: 2.9.4 -> 2.9.5

2017-09-05 Thread Burton, Ross
On 5 September 2017 at 07:35, Andrej Valek  wrote:

> Signed-off-by: Andrej Valek 
>

We're past freeze to the upgrade will have to wait until 2.4 releases. Does
this fix any outstanding CVEs that we should be cherry-picking?

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


Re: [OE-core] [PATCH] ell: upgrade SRCREV and move recipes to core

2017-09-05 Thread Burton, Ross
On 5 September 2017 at 08:46, Ankit Navik  wrote:

>  7b7c15c build: Include check for xxd binary when in maintainer-mode
>

It's too late to add recipes into oe-core as we're now frozen for the 2.4
release, but if we were not what would the rationale for adding this to
oe-core be?

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


Re: [OE-core] [PATCH] boost: add python to default PACKAGECONFIG options

2017-09-05 Thread Andreas Müller
On Tue, Sep 5, 2017 at 11:02 AM, Andreas Müller
 wrote:
> On Tue, Sep 5, 2017 at 10:44 AM, Andreas Müller
>  wrote:
>> On Wed, Aug 23, 2017 at 11:04 PM, Philip Balister  
>> wrote:
>>> On 08/22/2017 09:26 PM, Randy MacLeod wrote:
 On 2017-08-22 03:55 PM, Richard Purdie wrote:
> On Tue, 2017-08-22 at 12:51 -0700, Andre McCurdy wrote:
>> On Tue, Aug 22, 2017 at 12:42 AM,  
>> wrote:
>>>
>>> From: Jackie Huang 
>>>
>>> We want to provide python libs by default, and some other
>>> popular Linux distributions like redhat/fedora does the same.
>> Has something changed? Is there anything in oe-core or meta-oe which
>> now needs boost python support enabled?
>>>
>>> I'm aware of a package in meta-sdr that will need boost python support.
>>> So there is need for this feature.
>>>
>>> Philip
>>>
>> FWIW: I have an append in metea-qt5-extra enabling python since two years.
>>
Saw that this was applied already. Sorry for the noise..

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


Re: [OE-core] [PATCH] boost: add python to default PACKAGECONFIG options

2017-09-05 Thread Andreas Müller
On Tue, Sep 5, 2017 at 10:44 AM, Andreas Müller
 wrote:
> On Wed, Aug 23, 2017 at 11:04 PM, Philip Balister  wrote:
>> On 08/22/2017 09:26 PM, Randy MacLeod wrote:
>>> On 2017-08-22 03:55 PM, Richard Purdie wrote:
 On Tue, 2017-08-22 at 12:51 -0700, Andre McCurdy wrote:
> On Tue, Aug 22, 2017 at 12:42 AM,  
> wrote:
>>
>> From: Jackie Huang 
>>
>> We want to provide python libs by default, and some other
>> popular Linux distributions like redhat/fedora does the same.
> Has something changed? Is there anything in oe-core or meta-oe which
> now needs boost python support enabled?
>>
>> I'm aware of a package in meta-sdr that will need boost python support.
>> So there is need for this feature.
>>
>> Philip
>>
> FWIW: I have an append in metea-qt5-extra enabling python since two years.
>
> Andreas
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH] boost: add python to default PACKAGECONFIG options

2017-09-05 Thread Andreas Müller
On Wed, Aug 23, 2017 at 11:04 PM, Philip Balister  wrote:
> On 08/22/2017 09:26 PM, Randy MacLeod wrote:
>> On 2017-08-22 03:55 PM, Richard Purdie wrote:
>>> On Tue, 2017-08-22 at 12:51 -0700, Andre McCurdy wrote:
 On Tue, Aug 22, 2017 at 12:42 AM,  
 wrote:
>
> From: Jackie Huang 
>
> We want to provide python libs by default, and some other
> popular Linux distributions like redhat/fedora does the same.
 Has something changed? Is there anything in oe-core or meta-oe which
 now needs boost python support enabled?
>
> I'm aware of a package in meta-sdr that will need boost python support.
> So there is need for this feature.
>
> Philip
>
FWIW: I have an append in metea-qt5-extra enabling python since two years.

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


Re: [OE-core] [PATCH 2/2] package_[deb|ipk]: improve multiprocess logic when creating deb/ipk packages

2017-09-05 Thread Joshua Lock



On 04/09/17 22:35, leonardo.sandoval.gonza...@linux.intel.com wrote:

From: Leonardo Sandoval 

Current implementation does not handle possible exceptions coming from child
processes, the latter responsible for creating packages. With the aim to have 
more
control, use pipes to communicate exceptions and stop package creation in case
of failure.

Helps to debug [YOCTO #12012].

Signed-off-by: Leonardo Sandoval 
---
  meta/classes/package_deb.bbclass | 36 +---
  meta/classes/package_ipk.bbclass | 36 +---
  2 files changed, 66 insertions(+), 6 deletions(-)






diff --git a/meta/classes/package_ipk.bbclass b/meta/classes/package_ipk.bbclass
index ec90996184..8439cda6dd 100644
--- a/meta/classes/package_ipk.bbclass
+++ b/meta/classes/package_ipk.bbclass
@@ -17,7 +17,29 @@ OPKG_ARGS += "${@['', '--add-exclude ' + ' --add-exclude 
'.join((d.getVar('PACKA
  OPKGLIBDIR = "${localstatedir}/lib"
  
  python do_package_ipk () {

-from multiprocessing import Process
+import multiprocessing
+import traceback
+
+class IPKWritePkgProcess(multiprocessing.Process):
+def __init__(self, *args, **kwargs):
+multiprocessing.Process.__init__(self, *args, **kwargs)
+self._pconn, self._cconn = multiprocessing.Pipe()
+self._exception = None
+
+def run(self):
+try:
+multiprocessing.Process.run(self)
+self._cconn.send(None)
+except Exception as e:
+tb = traceback.format_exc()
+self._cconn.send((e, tb))
+
+@property
+def exception(self):
+if self._pconn.poll():
+self._exception = self._pconn.recv()
+return self._exception
+


Other than the name is IPKWritePkgProcess the same as DebianWritePkgProcess?

If so, could we put a single WritePkgProcess class somewhere it can be 
shared in lib/oe ?


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


[OE-core] ✗ patchtest: failure for ell: upgrade SRCREV and move recipes to core (rev3)

2017-09-05 Thread Patchwork
== Series Details ==

Series: ell: upgrade SRCREV and move recipes to core (rev3)
Revision: 3
URL   : https://patchwork.openembedded.org/series/8712/
State : failure

== Summary ==


Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests have been executed on the proposed
series by patchtest resulting in the following failures:



* Issue Series does not apply on top of target branch 
[test_series_merge_on_head] 
  Suggested fixRebase your series on top of targeted branch
  Targeted branch  master (currently at dd75644db2)

* Issue Series sent to the wrong mailing list or some patches from 
the series correspond to different mailing lists [test_target_mailing_list] 
  Suggested fixSend the series again to the correct mailing list (ML)
  Suggested ML openembedded-de...@lists.openembedded.org 
[http://git.openembedded.org/meta-openembedded/]
  Patch's path:meta-oe/recipes-connectivity/ell/ell_git.bb



If you believe any of these test results are incorrect, please reply to the
mailing list (openembedded-core@lists.openembedded.org) raising your concerns.
Otherwise we would appreciate you correcting the issues and submitting a new
version of the patchset if applicable. Please ensure you add/increment the
version number when sending the new version (i.e. [PATCH] -> [PATCH v2] ->
[PATCH v3] -> ...).

---
Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest
Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe

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


[OE-core] [PATCH 0/2] systemd: fix dependency issue related to serial getty

2017-09-05 Thread Chen Qi
The following changes since commit 15eac6befb6c4d16bc1b814e040bd7bf006a5bee:

  linux-yocto: add linux-yocto 4.12 bbappends (2017-08-31 23:37:10 +0100)

are available in the git repository at:

  git://git.pokylinux.org/poky-contrib ChenQi/systemd-serialgetty
  
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=ChenQi/systemd-serialgetty

Chen Qi (2):
  systemd: change some RRECOMMENDS to RDEPENDS
  systemd-serialgetty: remove systemd from RDEPENDS

 meta/recipes-core/systemd/systemd-serialgetty.bb | 2 --
 meta/recipes-core/systemd/systemd_234.bb | 8 
 2 files changed, 4 insertions(+), 6 deletions(-)

-- 
1.9.1

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


[OE-core] [PATCH 1/2] systemd: change some RRECOMMENDS to RDEPENDS

2017-09-05 Thread Chen Qi
Set NO_RECOMMENDATIONS to "1", build and start a systemd image, and we
could not get serial getty spawned, thus causing the user not able to
login via serial port.

E.g.
MACHINE=qemux86-64 bitbake core-image-minimal
runqemu qemux86-64 nographic

And we cannot login onto the system.

Move util-linux-agetty and systemd-serialgetty (determined by PACKAGECONFIG)
from RRECOMMENDS to RDEPENDS to fix the above problem.

Signed-off-by: Chen Qi 
---
 meta/recipes-core/systemd/systemd_234.bb | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/meta/recipes-core/systemd/systemd_234.bb 
b/meta/recipes-core/systemd/systemd_234.bb
index 2736f38..2695e15 100644
--- a/meta/recipes-core/systemd/systemd_234.bb
+++ b/meta/recipes-core/systemd/systemd_234.bb
@@ -492,13 +492,13 @@ FILES_${PN} = " ${base_bindir}/* \
 
 FILES_${PN}-dev += "${base_libdir}/security/*.la ${datadir}/dbus-1/interfaces/ 
${sysconfdir}/rpm/macros.systemd"
 
-RDEPENDS_${PN} += "kmod dbus util-linux-mount udev (= ${EXTENDPKGV})"
+RDEPENDS_${PN} += "kmod dbus util-linux-mount udev (= ${EXTENDPKGV}) 
util-linux-agetty"
+RDEPENDS_${PN} += "${@bb.utils.contains('PACKAGECONFIG', 
'serial-getty-generator', '', 'systemd-serialgetty', d)}"
 RDEPENDS_${PN} += "volatile-binds update-rc.d"
 
-RRECOMMENDS_${PN} += "${@bb.utils.contains('PACKAGECONFIG', 
'serial-getty-generator', '', 'systemd-serialgetty', d)} \
-  systemd-extra-utils \
+RRECOMMENDS_${PN} += "systemd-extra-utils \
   systemd-compat-units udev-hwdb \
-  util-linux-agetty  util-linux-fsck e2fsprogs-e2fsck \
+  util-linux-fsck e2fsprogs-e2fsck \
   kernel-module-autofs4 kernel-module-unix 
kernel-module-ipv6 \
   os-release \
 "
-- 
1.9.1

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


[OE-core] [PATCH 2/2] systemd-serialgetty: remove systemd from RDEPENDS

2017-09-05 Thread Chen Qi
By setting systemd-serialgetty to rdepend on systemd, we are making
configuration files have runtime dependency on the main utility that
uses those configuration files. Applied with the same logic, we should
make any package that provides service files under /etc/init.d/ to have
runtime dependency on sysvinit. And this is not right.

So we should remove systemd from RDEPENDS of systemd-serialgetty.

Besides, as we have changed systemd to have systemd-serialgetty in its
RDEPENDS by default, we should avoid circular dependency issue.

Signed-off-by: Chen Qi 
---
 meta/recipes-core/systemd/systemd-serialgetty.bb | 2 --
 1 file changed, 2 deletions(-)

diff --git a/meta/recipes-core/systemd/systemd-serialgetty.bb 
b/meta/recipes-core/systemd/systemd-serialgetty.bb
index 768b130..8d1ec7c 100644
--- a/meta/recipes-core/systemd/systemd-serialgetty.bb
+++ b/meta/recipes-core/systemd/systemd-serialgetty.bb
@@ -38,8 +38,6 @@ do_install() {
fi
 }
 
-RDEPENDS_${PN} = "systemd"
-
 # This is a machine specific file
 FILES_${PN} = "${systemd_unitdir}/system/*.service ${sysconfdir}"
 PACKAGE_ARCH = "${MACHINE_ARCH}"
-- 
1.9.1

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


[OE-core] [PATCH] ell: upgrade SRCREV and move recipes to core

2017-09-05 Thread Ankit Navik
 7b7c15c build: Include check for xxd binary when in maintainer-mode

Signed-off-by: Ankit Navik 
---
 meta-oe/recipes-connectivity/ell/ell_git.bb | 17 -
 meta-oe/recipes-core/ell/ell.inc| 13 +
 meta-oe/recipes-core/ell/ell_git.bb |  5 +
 3 files changed, 18 insertions(+), 17 deletions(-)
 delete mode 100644 meta-oe/recipes-connectivity/ell/ell_git.bb
 create mode 100644 meta-oe/recipes-core/ell/ell.inc
 create mode 100644 meta-oe/recipes-core/ell/ell_git.bb

diff --git a/meta-oe/recipes-connectivity/ell/ell_git.bb 
b/meta-oe/recipes-connectivity/ell/ell_git.bb
deleted file mode 100644
index d259f52..000
--- a/meta-oe/recipes-connectivity/ell/ell_git.bb
+++ /dev/null
@@ -1,17 +0,0 @@
-SUMMARY  = "Embedded Linux Library"
-DESCRIPTION = "ELL is a DBUS library which provides DBUS bindings."
-LICENSE  = "LGPLv2.1"
-LIC_FILES_CHKSUM = "file://COPYING;md5=fb504b67c50331fc78734fed90fb0e09"
-SECTION = "libs"
-
-inherit autotools pkgconfig
-
-S = "${WORKDIR}/git"
-SRCREV = "399099946abaeb2f3718a0667cc11436a7c0be14"
-SRC_URI = "git://git.kernel.org/pub/scm/libs/ell/ell.git"
-
-do_configure_prepend () {
-mkdir ${S}/build-aux
-}
-
-DEPENDS = "dbus"
diff --git a/meta-oe/recipes-core/ell/ell.inc b/meta-oe/recipes-core/ell/ell.inc
new file mode 100644
index 000..7bed240
--- /dev/null
+++ b/meta-oe/recipes-core/ell/ell.inc
@@ -0,0 +1,13 @@
+SUMMARY  = "Embedded Linux Library"
+DESCRIPTION = "ELL is a DBUS library which provides DBUS bindings."
+LICENSE  = "LGPLv2.1"
+LIC_FILES_CHKSUM = "file://COPYING;md5=fb504b67c50331fc78734fed90fb0e09"
+SECTION = "libs"
+
+inherit autotools pkgconfig
+
+do_configure_prepend () {
+mkdir ${S}/build-aux
+}
+
+DEPENDS = "dbus"
diff --git a/meta-oe/recipes-core/ell/ell_git.bb 
b/meta-oe/recipes-core/ell/ell_git.bb
new file mode 100644
index 000..0589809
--- /dev/null
+++ b/meta-oe/recipes-core/ell/ell_git.bb
@@ -0,0 +1,5 @@
+require ell.inc
+
+S = "${WORKDIR}/git"
+SRCREV = "7b7c15c2e5caff88fc45e7a8b874a47196a0eddd"
+SRC_URI = "git://git.kernel.org/pub/scm/libs/ell/ell.git"
-- 
1.9.1

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


Re: [OE-core] [PATCH] useradd-staticids: don't create username-group if gid is specified

2017-09-05 Thread André Draszik
On Mon, 2017-09-04 at 10:22 +, Peter Kjellerstedt wrote:
> > 
[...]
> > diff --git a/meta/classes/useradd-staticids.bbclass
> > b/meta/classes/useradd-staticids.bbclass
> > index ce4ac62ab5..1b61a8bf9b 100644
> > --- a/meta/classes/useradd-staticids.bbclass
> > +++ b/meta/classes/useradd-staticids.bbclass
> > @@ -102,7 +102,7 @@ def update_useradd_static_config(d):
> >  # So if the implicit username-group creation is on, then
> > the implicit groupname (LOGIN)
> >  # is used, and we disable the user_group option.
> >  #
> > -user_group = uaargs.user_group is None or uaargs.user_group
> > is True
> > +user_group = uaargs.gid is None or uaargs.user_group is
> > True
> 
> Hmm, I believe that should be:
> 
> user_group = uaargs.gid is None and uaargs.user_group is None
> or uaargs.user_group is True
> 
> I.e., if neither --gid nor --user-group is specified, then it should 
> treat it as if --user-group was specified.

Hm, isn't this still the same as 

user_group = uaargs.gid is None or uaargs.user_group is True

? If neither --gid nor --user-group is specified, then gid is None, so it
will do what you want already. IOW, unless the group name (gid) is
specified, a username-group is being created.


Cheers,
Andre'

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


[OE-core] ✗ patchtest: failure for ell: upgrade SRCREV and move recipes to core (rev2)

2017-09-05 Thread Patchwork
== Series Details ==

Series: ell: upgrade SRCREV and move recipes to core (rev2)
Revision: 2
URL   : https://patchwork.openembedded.org/series/8712/
State : failure

== Summary ==


Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests have been executed on the proposed
series by patchtest resulting in the following failures:



* Issue Series does not apply on top of target branch 
[test_series_merge_on_head] 
  Suggested fixRebase your series on top of targeted branch
  Targeted branch  master (currently at dd75644db2)

* Patchell: upgrade SRCREV and move recipes to core
 Issue Patch is missing Signed-off-by [test_signed_off_by_presence] 
  Suggested fixSign off the patch (either manually or with "git commit 
--amend -s")

* Issue Series sent to the wrong mailing list or some patches from 
the series correspond to different mailing lists [test_target_mailing_list] 
  Suggested fixSend the series again to the correct mailing list (ML)
  Suggested ML openembedded-de...@lists.openembedded.org 
[http://git.openembedded.org/meta-openembedded/]
  Patch's path:meta-oe/recipes-connectivity/ell/ell_git.bb



If you believe any of these test results are incorrect, please reply to the
mailing list (openembedded-core@lists.openembedded.org) raising your concerns.
Otherwise we would appreciate you correcting the issues and submitting a new
version of the patchset if applicable. Please ensure you add/increment the
version number when sending the new version (i.e. [PATCH] -> [PATCH v2] ->
[PATCH v3] -> ...).

---
Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest
Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe

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