[OE-core] [PATCH] acl: Fix re pattern in test cases

[zhe.he]

From: He Zhe 

ls adds a '.' at the end of the permission field list on SELinux
machines, filter this out so root tests work on SELinux machines.
And backport one patch for other tests.

Signed-off-by: He Zhe 
---
 meta/recipes-support/attr/acl.inc  |   2 +
 .../acl/test-fix-insufficient-quoting-of.patch | 108 +
 ...ps-on-SELinux-machines-for-root-testcases.patch |  84 
 3 files changed, 194 insertions(+)
 create mode 100644 
meta/recipes-support/attr/acl/test-fix-insufficient-quoting-of.patch
 create mode 100644 
meta/recipes-support/attr/acl/test-fixups-on-SELinux-machines-for-root-testcases.patch

diff --git a/meta/recipes-support/attr/acl.inc 
b/meta/recipes-support/attr/acl.inc
index b2bc8ba..198fb4f 100644
--- a/meta/recipes-support/attr/acl.inc
+++ b/meta/recipes-support/attr/acl.inc
@@ -12,6 +12,8 @@ DEPENDS = "attr"
 SRC_URI = "${SAVANNAH_GNU_MIRROR}/acl/${BP}.src.tar.gz \
file://run-ptest \
file://acl-fix-the-order-of-expected-output-of-getfacl.patch \
+   file://test-fix-insufficient-quoting-of.patch \
+   file://test-fixups-on-SELinux-machines-for-root-testcases.patch \
 "

 require ea-acl.inc
diff --git 
a/meta/recipes-support/attr/acl/test-fix-insufficient-quoting-of.patch 
b/meta/recipes-support/attr/acl/test-fix-insufficient-quoting-of.patch
new file mode 100644
index 000..59e4629
--- /dev/null
+++ b/meta/recipes-support/attr/acl/test-fix-insufficient-quoting-of.patch
@@ -0,0 +1,108 @@
+From e98ce8acf84d12ea67a3ac76bf63c6d87d9af86d Mon Sep 17 00:00:00 2001
+From: Kamil Dudka 
+Date: Mon, 20 May 2013 16:38:06 +0200
+Subject: [PATCH] test: fix insufficient quoting of '\'
+
+This is a follow-up to 7f2c91b8369242a8dbc2b304a5b71b2a85f5b855, which
+caused sbits-restore.test to fail in the following way in case SELinux
+was disabled:
+
+*** sbits-restore.test ***
+[3] $ umask 022 -- ok
+[4] $ mkdir d -- ok
+[5] $ touch d/g -- ok
+[6] $ touch d/u -- ok
+[7] $ chmod u+s d/u -- ok
+[8] $ chmod g+s d/g -- ok
+[9] $ chmod +t d -- ok
+[10] $ getfacl -R d > d.acl -- ok
+[11] $ rm -R d -- ok
+[12] $ mkdir d -- ok
+[13] $ touch d/g -- ok
+[14] $ touch d/u -- ok
+[15] $ setfacl --restore d.acl -- ok
+[16] $ ls -dl d | awk '{print $1}' | sed 's/.$//g' -- failed
+drwxr-xr- != drwxr-xr-t
+[18] $ ls -dl d/u | awk '{print $1}' | sed 's/.$//g' -- failed
+-rwSr--r- != -rwSr--r--
+[20] $ ls -dl d/g | awk '{print $1}' | sed 's/.$//g' -- failed
+-rw-r-Sr- != -rw-r-Sr--
+[22] $ rm -Rf d -- ok
+17 commands (14 passed, 3 failed)
+
+Upstream-Status: Backport
+http://git.savannah.gnu.org/cgit/acl.git/commit/?id=e98ce8acf84d12ea67a3ac76bf63c6d87d9af86d
+
+Signed-off-by: Kamil Dudka 
+Signed-off-by: He Zhe 
+---
+ test/cp.test| 2 +-
+ test/misc.test  | 6 +++---
+ test/sbits-restore.test | 6 +++---
+ 3 files changed, 7 insertions(+), 7 deletions(-)
+
+diff --git a/test/cp.test b/test/cp.test
+index 0867f63..a927195 100644
+--- a/test/cp.test
 b/test/cp.test
+@@ -9,7 +9,7 @@ The cp utility should only copy ACLs if `-p' is given.
+   > -rw-rw-r--+
+
+   $ cp f g
+-  $ ls -l g | awk -- '{ print $1 }' | sed 's/\.$//g'
++  $ ls -l g | awk -- '{ print $1 }' | sed 's/\\.$//g'
+   > -rw-r--r--
+
+   $ rm g
+diff --git a/test/misc.test b/test/misc.test
+index 6e98053..29372b7 100644
+--- a/test/misc.test
 b/test/misc.test
+@@ -254,7 +254,7 @@ Add some users and groups
+ Symlink in directory with default ACL?
+
+   $ ln -s d d/l
+-  $ ls -dl d/l | awk '{print $1}' | sed 's/\.$//g'
++  $ ls -dl d/l | awk '{print $1}' | sed 's/\\.$//g'
+   > lrwxrwxrwx
+
+   $ ls -dl -L d/l | awk '{print $1}'
+@@ -343,7 +343,7 @@ Remove the default ACL
+ Reset to base entries
+
+   $ setfacl -b d
+-  $ ls -dl d | awk '{print $1}' | sed 's/\.$//g'
++  $ ls -dl d | awk '{print $1}' | sed 's/\\.$//g'
+   > drwxr-x---
+
+   $ getfacl --omit-header d
+@@ -355,7 +355,7 @@ Reset to base entries
+ Now, chmod should change the group_obj entry
+
+   $ chmod 775 d
+-  $ ls -dl d | awk '{print $1}' | sed 's/\.$//g'
++  $ ls -dl d | awk '{print $1}' | sed 's/\\.$//g'
+   > drwxrwxr-x
+
+   $ getfacl --omit-header d
+diff --git a/test/sbits-restore.test b/test/sbits-restore.test
+index de21340..5899b0a 100644
+--- a/test/sbits-restore.test
 b/test/sbits-restore.test
+@@ -13,10 +13,10 @@ Ensure setting of SUID/SGID/sticky via --restore works
+   $ touch d/g
+   $ touch d/u
+   $ setfacl --restore d.acl
+-  $ ls -dl d | awk '{print $1}' | sed 's/\.$//g'
++  $ ls -dl d | awk '{print $1}' | sed 's/\\.$//g'
+   > drwxr-xr-t
+-  $ ls -dl d/u | awk '{print $1}' | sed 's/\.$//g'
++  $ ls -dl d/u | awk '{print $1}' | sed 's/\\.$//g'
+   > 

Re: [OE-core] [PATCH][master][Drown] openssl: Security fix Drown via 1.0.1g update

[Andre McCurdy]

On Wed, Mar 2, 2016 at 12:06 PM, Andre McCurdy  wrote:
> On Wed, Mar 2, 2016 at 11:14 AM, akuster  wrote:
>>
>> On 03/02/2016 10:06 AM, Andre McCurdy wrote:
>>> On Tue, Mar 1, 2016 at 11:38 PM, Armin Kuster  wrote:
 From: Armin Kuster 

 CVE-2016-0800
 CVE-2016-0705
 CVE-2016-0798
 CVE-2016-0797
 CVE-2016-0799
 CVE-2016-0702
 CVE-2016-0703
 CVE-2016-0704

 https://www.openssl.org/news/secadv/20160301.txt

 Updated 2 debian patches to match changes in 1.0.1g

That should be 1.0.2g (and the commit summary has the same typo too).

>>> Could you give some details on why the linker version script is now
>>> required
>>
>> it has been part of openssl for over a year.
>>
>> See commit ( Better call Saul )
>>
>> http://cgit.openembedded.org/openembedded-core/commit/meta/recipes-connectivity/openssl?id=10b689033551c37d6cafa284d82bdccd43f6113e
>>
 and how it was generated?
>>
>> This is just an update from debian to support 1.0.2g. Have no idea how
>> they create that file.
>
> OK, yes, I see it now in the Debian openssl 1.0.2g patches:
>
>   
> http://http.debian.net/debian/pool/main/o/openssl/openssl_1.0.2g-1.debian.tar.xz
>
> It seems that Debian have been versioning openssl symbols for quite
> some time and we've inherited that via the Debian patches.
>
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=49
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=180725
>   ...
>
> Perhaps some comments in the openssl recipe would be useful to make it
> a little clearer that we are providing Debian openssl and not the
> vanilla upstream version. Maybe even use Debian version numbers (ie
> 1.0.2g-1 in this case) and apply the complete set of Debian patches
> for each new release instead of keeping our own local copies?
>
>> If you don't have it this package wont build.
>>
>> It was there when you updated to 1.0.2f, which I suspect you did not
>> realize.
>>
>> Sorry I don't have a better answer.
>>
>> - Armin
>>
>>>
 Signed-off-by: Armin Kuster 
 ---
  .../openssl/debian1.0.2/block_diginotar.patch  |   17 +-
  .../openssl/debian1.0.2/version-script.patch   | 4656 
 
  .../{openssl_1.0.2f.bb => openssl_1.0.2g.bb}   |6 +-
  3 files changed, 4668 insertions(+), 11 deletions(-)
  create mode 100644 
 meta/recipes-connectivity/openssl/openssl/debian1.0.2/version-script.patch
  rename meta/recipes-connectivity/openssl/{openssl_1.0.2f.bb => 
 openssl_1.0.2g.bb} (91%)

 diff --git 
 a/meta/recipes-connectivity/openssl/openssl/debian1.0.2/block_diginotar.patch
  
 b/meta/recipes-connectivity/openssl/openssl/debian1.0.2/block_diginotar.patch
 index 0c1a0b6..d81e22c 100644
 --- 
 a/meta/recipes-connectivity/openssl/openssl/debian1.0.2/block_diginotar.patch
 +++ 
 b/meta/recipes-connectivity/openssl/openssl/debian1.0.2/block_diginotar.patch
 @@ -9,14 +9,15 @@ Reviewed-by: Kurt Roeckx 
  Reviewed-by: Dr Stephen N Henson 

  This is not meant as final patch.
 -
 +
  Upstream-Status: Backport [debian]

 +Signed-off-by: Armin Kuster 

 -Index: openssl-1.0.2/crypto/x509/x509_vfy.c
 +Index: openssl-1.0.2g/crypto/x509/x509_vfy.c
  ===
  openssl-1.0.2.orig/crypto/x509/x509_vfy.c
 -+++ openssl-1.0.2/crypto/x509/x509_vfy.c
 +--- openssl-1.0.2g.orig/crypto/x509/x509_vfy.c
  openssl-1.0.2g/crypto/x509/x509_vfy.c
  @@ -119,6 +119,7 @@ static int check_trust(X509_STORE_CTX *c
   static int check_revocation(X509_STORE_CTX *ctx);
   static int check_cert(X509_STORE_CTX *ctx);
 @@ -25,17 +26,17 @@ Index: openssl-1.0.2/crypto/x509/x509_vfy.c

   static int get_crl_score(X509_STORE_CTX *ctx, X509 **pissuer,
unsigned int *preasons, X509_CRL *crl, X509 *x);
 -@@ -438,6 +439,9 @@ int X509_verify_cert(X509_STORE_CTX *ctx
 +@@ -489,6 +490,9 @@ int X509_verify_cert(X509_STORE_CTX *ctx
   if (!ok)
 - goto end;
 + goto err;

  +  ok = check_ca_blacklist(ctx);
 -+  if(!ok) goto end;
 ++  if(!ok) goto err;
  +
   #ifndef OPENSSL_NO_RFC3779
   /* RFC 3779 path validation, now that CRL check has been done */
   ok = v3_asid_validate_path(ctx);
 -@@ -938,6 +942,29 @@ static int check_crl_time(X509_STORE_CTX
 +@@ -996,6 +1000,29 @@ static int check_crl_time(X509_STORE_CTX
   return 1;
   }

 diff --git 
 a/meta/recipes-connectivity/openssl/openssl/debian1.0.2/version-script.patch
  
 b/meta/recipes-connectivity/openssl/openssl/debian1.0.2/version-script.patch
 new file mode 100644

Re: [OE-core] [PATCH] gcc-runtime.inc: disable libitm for little endian MIPS too

[Andre McCurdy]

On Wed, Mar 2, 2016 at 10:24 PM, Khem Raj  wrote:
> On Wed, Mar 2, 2016 at 10:04 PM, Mark Hatle  wrote:
>> On 3/2/16 11:07 PM, Andre McCurdy wrote:
>>> libitm is already disabled for big endian MIPS, but needs to be
>>> disabled for little endian MIPS targets too.
>>
>> No objection to the patch, but do we have any little endian MIPS currently
>> defined or buildable to test?
>
> most of mips based set-top boxes are mipsel.
>
>> All of the samples I've seen are all big endian these days.  (QEMU or actual
>> boards.)

Of the MIPS boards supported by OpenWRT, there seem to be an even
mixture of big and little endian:

  https://dev.openwrt.org/wiki/platforms

I don't know how many (if any) of these boards are supported by OE though...


>> --Mark
>>
>>> Signed-off-by: Andre McCurdy 
>>> ---
>>>  meta/recipes-devtools/gcc/gcc-runtime.inc | 2 ++
>>>  1 file changed, 2 insertions(+)
>>>
>>> diff --git a/meta/recipes-devtools/gcc/gcc-runtime.inc 
>>> b/meta/recipes-devtools/gcc/gcc-runtime.inc
>>> index 707db37..1c3dd54 100644
>>> --- a/meta/recipes-devtools/gcc/gcc-runtime.inc
>>> +++ b/meta/recipes-devtools/gcc/gcc-runtime.inc
>>> @@ -12,7 +12,9 @@ EXTRA_OECONF_append_linuxstdbase = " --enable-clocale=gnu"
>>>
>>>  RUNTIMELIBITM = "libitm"
>>>  RUNTIMELIBITM_mips = ""
>>> +RUNTIMELIBITM_mipsel = ""
>>>  RUNTIMELIBITM_mips64 = ""
>>> +RUNTIMELIBITM_mips64el = ""
>>>
>>>  RUNTIMETARGET = "libssp libstdc++-v3 libgomp libatomic ${RUNTIMELIBITM} \
>>>  ${@bb.utils.contains_any('FORTRAN', [',fortran',',f77'], 
>>> 'libquadmath', '', d)} \
>>>
>>
>> --
>> ___
>> 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
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] gcc-runtime.inc: disable libitm for little endian MIPS too

[Khem Raj]

On Wed, Mar 2, 2016 at 10:04 PM, Mark Hatle  wrote:
> On 3/2/16 11:07 PM, Andre McCurdy wrote:
>> libitm is already disabled for big endian MIPS, but needs to be
>> disabled for little endian MIPS targets too.
>
> No objection to the patch, but do we have any little endian MIPS currently
> defined or buildable to test?
>

most of mips based set-top boxes are mipsel.

> All of the samples I've seen are all big endian these days.  (QEMU or actual
> boards.)
>
> --Mark
>
>> Signed-off-by: Andre McCurdy 
>> ---
>>  meta/recipes-devtools/gcc/gcc-runtime.inc | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/meta/recipes-devtools/gcc/gcc-runtime.inc 
>> b/meta/recipes-devtools/gcc/gcc-runtime.inc
>> index 707db37..1c3dd54 100644
>> --- a/meta/recipes-devtools/gcc/gcc-runtime.inc
>> +++ b/meta/recipes-devtools/gcc/gcc-runtime.inc
>> @@ -12,7 +12,9 @@ EXTRA_OECONF_append_linuxstdbase = " --enable-clocale=gnu"
>>
>>  RUNTIMELIBITM = "libitm"
>>  RUNTIMELIBITM_mips = ""
>> +RUNTIMELIBITM_mipsel = ""
>>  RUNTIMELIBITM_mips64 = ""
>> +RUNTIMELIBITM_mips64el = ""
>>
>>  RUNTIMETARGET = "libssp libstdc++-v3 libgomp libatomic ${RUNTIMELIBITM} \
>>  ${@bb.utils.contains_any('FORTRAN', [',fortran',',f77'], 'libquadmath', 
>> '', d)} \
>>
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] gcc-runtime.inc: disable libitm for little endian MIPS too

[Mark Hatle]

On 3/2/16 11:07 PM, Andre McCurdy wrote:
> libitm is already disabled for big endian MIPS, but needs to be
> disabled for little endian MIPS targets too.

No objection to the patch, but do we have any little endian MIPS currently
defined or buildable to test?

All of the samples I've seen are all big endian these days.  (QEMU or actual
boards.)

--Mark

> Signed-off-by: Andre McCurdy 
> ---
>  meta/recipes-devtools/gcc/gcc-runtime.inc | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/meta/recipes-devtools/gcc/gcc-runtime.inc 
> b/meta/recipes-devtools/gcc/gcc-runtime.inc
> index 707db37..1c3dd54 100644
> --- a/meta/recipes-devtools/gcc/gcc-runtime.inc
> +++ b/meta/recipes-devtools/gcc/gcc-runtime.inc
> @@ -12,7 +12,9 @@ EXTRA_OECONF_append_linuxstdbase = " --enable-clocale=gnu"
>  
>  RUNTIMELIBITM = "libitm"
>  RUNTIMELIBITM_mips = ""
> +RUNTIMELIBITM_mipsel = ""
>  RUNTIMELIBITM_mips64 = ""
> +RUNTIMELIBITM_mips64el = ""
>  
>  RUNTIMETARGET = "libssp libstdc++-v3 libgomp libatomic ${RUNTIMELIBITM} \
>  ${@bb.utils.contains_any('FORTRAN', [',fortran',',f77'], 'libquadmath', 
> '', d)} \
> 

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

[OE-core] [PATCH] gcc-runtime.inc: disable libitm for little endian MIPS too

[Andre McCurdy]

libitm is already disabled for big endian MIPS, but needs to be
disabled for little endian MIPS targets too.

Signed-off-by: Andre McCurdy 
---
 meta/recipes-devtools/gcc/gcc-runtime.inc | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-devtools/gcc/gcc-runtime.inc 
b/meta/recipes-devtools/gcc/gcc-runtime.inc
index 707db37..1c3dd54 100644
--- a/meta/recipes-devtools/gcc/gcc-runtime.inc
+++ b/meta/recipes-devtools/gcc/gcc-runtime.inc
@@ -12,7 +12,9 @@ EXTRA_OECONF_append_linuxstdbase = " --enable-clocale=gnu"
 
 RUNTIMELIBITM = "libitm"
 RUNTIMELIBITM_mips = ""
+RUNTIMELIBITM_mipsel = ""
 RUNTIMELIBITM_mips64 = ""
+RUNTIMELIBITM_mips64el = ""
 
 RUNTIMETARGET = "libssp libstdc++-v3 libgomp libatomic ${RUNTIMELIBITM} \
 ${@bb.utils.contains_any('FORTRAN', [',fortran',',f77'], 'libquadmath', 
'', d)} \
-- 
1.9.1

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

[OE-core] [PATCH] eudev: recipe formatting improvements

[Andre McCurdy]

Formatting improvements only, no functional changes.

Signed-off-by: Andre McCurdy 
---
 meta/recipes-core/udev/eudev_3.1.5.bb | 124 --
 1 file changed, 60 insertions(+), 64 deletions(-)

diff --git a/meta/recipes-core/udev/eudev_3.1.5.bb 
b/meta/recipes-core/udev/eudev_3.1.5.bb
index 8a23e6c..c15dd89 100644
--- a/meta/recipes-core/udev/eudev_3.1.5.bb
+++ b/meta/recipes-core/udev/eudev_3.1.5.bb
@@ -1,33 +1,66 @@
 SUMMARY = "eudev is a fork of systemd's udev"
 HOMEPAGE = "https://wiki.gentoo.org/wiki/Eudev;
-SRC_URI = "https://github.com/gentoo/${PN}/archive/v${PV}.tar.gz \
-   file://init \
-   file://local.rules \
-   file://udev-cache \
-   file://udev-cache.default \
-file://run.rules \
-file://udev.rules \
-file://devfs-udev.rules \
-file://links.conf \
-file://permissions.rules \
-   "
-
 LICENSE = "GPLv2.0+"
+LIC_FILES_CHKSUM = "file://COPYING;md5=751419260aa954499f7abaabaa882bbe"
 
-inherit autotools update-rc.d
+DEPENDS = "glib-2.0 glib-2.0-native gperf-native kmod libxslt-native 
util-linux"
+
+PROVIDES = "udev"
+
+SRC_URI = "https://github.com/gentoo/${BPN}/archive/v${PV}.tar.gz \
+   file://devfs-udev.rules \
+   file://init \
+   file://links.conf \
+   file://local.rules \
+   file://permissions.rules \
+   file://run.rules \
+   file://udev-cache \
+   file://udev-cache.default \
+   file://udev.rules \
+"
 
 SRC_URI[md5sum] = "e130f892d8744e292cb855db79935f68"
 SRC_URI[sha256sum] = 
"ce9d5fa91e3a42c7eb95512ca0fa2a631e89833053066bb6cdf42046b2a88553"
 
-LIC_FILES_CHKSUM="file://COPYING;md5=751419260aa954499f7abaabaa882bbe"
+inherit autotools update-rc.d
 
-DEPENDS = "glib-2.0-native glib-2.0 util-linux libxslt-native gperf-native 
kmod"
+EXTRA_OECONF = " \
+--sbindir=${base_sbindir} \
+--libexecdir=${nonarch_base_libdir} \
+--with-rootlibdir=${base_libdir} \
+--with-rootprefix= \
+"
 
-PROVIDES = "udev"
-RPROVIDES_${PN} = "hotplug udev"
+do_install_append() {
+   install -d ${D}${sysconfdir}/init.d
+   install -m 0755 ${WORKDIR}/init ${D}${sysconfdir}/init.d/udev
+   install -m 0755 ${WORKDIR}/udev-cache 
${D}${sysconfdir}/init.d/udev-cache
+   sed -i s%@UDEVD@%${base_sbindir}/udevd% ${D}${sysconfdir}/init.d/udev
+   sed -i s%@UDEVD@%${base_sbindir}/udevd% 
${D}${sysconfdir}/init.d/udev-cache
 
-PACKAGES =+ "udev-cache"
-PACKAGES =+ "libudev"
+   install -d ${D}${sysconfdir}/default
+   install -m 0755 ${WORKDIR}/udev-cache.default 
${D}${sysconfdir}/default/udev-cache
+
+   touch ${D}${sysconfdir}/udev/cache.data
+
+   install -d ${D}${sysconfdir}/udev/rules.d
+   install -m 0644 ${WORKDIR}/local.rules 
${D}${sysconfdir}/udev/rules.d/local.rules
+
+   # Use classic network interface naming scheme
+   touch ${D}${sysconfdir}/udev/rules.d/80-net-name-slot.rules
+
+   # Fix for multilib systems where libs along with confs are installed 
incorrectly
+   if ! [ -d ${D}${nonarch_base_libdir}/udev ]
+   then
+   install -d ${D}${nonarch_base_libdir}/udev
+   mv ${D}${base_libdir}/udev ${D}${nonarch_base_libdir}
+   fi
+
+   # hid2hci has moved to bluez4. removed in udev as of version 169
+   rm -f ${D}${base_libdir}/udev/hid2hci
+
+   echo 'udev_run="/var/run/udev"' >> ${D}${sysconfdir}/udev/udev.conf
+}
 
 INITSCRIPT_PACKAGES = "eudev udev-cache"
 INITSCRIPT_NAME_eudev = "udev"
@@ -35,59 +68,22 @@ INITSCRIPT_PARAMS_eudev = "start 04 S ."
 INITSCRIPT_NAME_udev-cache = "udev-cache"
 INITSCRIPT_PARAMS_udev-cache = "start 36 S ."
 
-RRECOMMENDS_${PN} += "udev-cache"
-
-
-FILES_libudev = "${base_libdir}/libudev.so.*"
+PACKAGES =+ "libudev"
+PACKAGES =+ "udev-cache"
 
 FILES_${PN} += "${libexecdir} ${nonarch_base_libdir}/udev ${bindir}/udevadm"
-
-
 FILES_${PN}-dev = "${datadir}/pkgconfig/udev.pc \
${includedir}/libudev.h ${libdir}/libudev.so \
${includedir}/udev.h ${libdir}/libudev.la \
-   ${libdir}/libudev.a ${libdir}/pkgconfig/libudev.pc \
-  "
+   ${libdir}/libudev.a ${libdir}/pkgconfig/libudev.pc"
+FILES_libudev = "${base_libdir}/libudev.so.*"
 FILES_udev-cache = "${sysconfdir}/init.d/udev-cache 
${sysconfdir}/default/udev-cache"
 
-EXTRA_OECONF = "--with-rootlibdir=${base_libdir} \
---sbindir=${base_sbindir} \
---libexecdir=${nonarch_base_libdir} \
---with-rootprefix= \
-"
-do_install_append(){
-   install -d ${D}${sysconfdir}/init.d
-install -m 0755 ${WORKDIR}/init ${D}${sysconfdir}/init.d/udev
-install -m 0755 ${WORKDIR}/udev-cache 
${D}${sysconfdir}/init.d/udev-cache
-sed -i s%@UDEVD@%${base_sbindir}/udevd% ${D}${sysconfdir}/init.d/udev
-sed -i s%@UDEVD@%${base_sbindir}/udevd% 
${D}${sysconfdir}/init.d/udev-cache
-
-install -d 

Re: [OE-core] [PATCH][master][Drown] openssl: Security fix Drown via 1.0.1g update

[Andre McCurdy]

On Wed, Mar 2, 2016 at 11:14 AM, akuster  wrote:
>
> On 03/02/2016 10:06 AM, Andre McCurdy wrote:
>> On Tue, Mar 1, 2016 at 11:38 PM, Armin Kuster  wrote:
>>> From: Armin Kuster 
>>>
>>> CVE-2016-0800
>>> CVE-2016-0705
>>> CVE-2016-0798
>>> CVE-2016-0797
>>> CVE-2016-0799
>>> CVE-2016-0702
>>> CVE-2016-0703
>>> CVE-2016-0704
>>>
>>> https://www.openssl.org/news/secadv/20160301.txt
>>>
>>> Updated 2 debian patches to match changes in 1.0.1g
>>
>> Could you give some details on why the linker version script is now
>> required
>
> it has been part of openssl for over a year.
>
> See commit ( Better call Saul )
>
> http://cgit.openembedded.org/openembedded-core/commit/meta/recipes-connectivity/openssl?id=10b689033551c37d6cafa284d82bdccd43f6113e
>
>>> and how it was generated?
>
> This is just an update from debian to support 1.0.2g. Have no idea how
> they create that file.

OK, yes, I see it now in the Debian openssl 1.0.2g patches:

  
http://http.debian.net/debian/pool/main/o/openssl/openssl_1.0.2g-1.debian.tar.xz

It seems that Debian have been versioning openssl symbols for quite
some time and we've inherited that via the Debian patches.

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=49
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=180725
  ...

Perhaps some comments in the openssl recipe would be useful to make it
a little clearer that we are providing Debian openssl and not the
vanilla upstream version. Maybe even use Debian version numbers (ie
1.0.2g-1 in this case) and apply the complete set of Debian patches
for each new release instead of keeping our own local copies?

> If you don't have it this package wont build.
>
> It was there when you updated to 1.0.2f, which I suspect you did not
> realize.
>
> Sorry I don't have a better answer.
>
> - Armin
>
>>
>>> Signed-off-by: Armin Kuster 
>>> ---
>>>  .../openssl/debian1.0.2/block_diginotar.patch  |   17 +-
>>>  .../openssl/debian1.0.2/version-script.patch   | 4656 
>>> 
>>>  .../{openssl_1.0.2f.bb => openssl_1.0.2g.bb}   |6 +-
>>>  3 files changed, 4668 insertions(+), 11 deletions(-)
>>>  create mode 100644 
>>> meta/recipes-connectivity/openssl/openssl/debian1.0.2/version-script.patch
>>>  rename meta/recipes-connectivity/openssl/{openssl_1.0.2f.bb => 
>>> openssl_1.0.2g.bb} (91%)
>>>
>>> diff --git 
>>> a/meta/recipes-connectivity/openssl/openssl/debian1.0.2/block_diginotar.patch
>>>  
>>> b/meta/recipes-connectivity/openssl/openssl/debian1.0.2/block_diginotar.patch
>>> index 0c1a0b6..d81e22c 100644
>>> --- 
>>> a/meta/recipes-connectivity/openssl/openssl/debian1.0.2/block_diginotar.patch
>>> +++ 
>>> b/meta/recipes-connectivity/openssl/openssl/debian1.0.2/block_diginotar.patch
>>> @@ -9,14 +9,15 @@ Reviewed-by: Kurt Roeckx 
>>>  Reviewed-by: Dr Stephen N Henson 
>>>
>>>  This is not meant as final patch.
>>> -
>>> +
>>>  Upstream-Status: Backport [debian]
>>>
>>> +Signed-off-by: Armin Kuster 
>>>
>>> -Index: openssl-1.0.2/crypto/x509/x509_vfy.c
>>> +Index: openssl-1.0.2g/crypto/x509/x509_vfy.c
>>>  ===
>>>  openssl-1.0.2.orig/crypto/x509/x509_vfy.c
>>> -+++ openssl-1.0.2/crypto/x509/x509_vfy.c
>>> +--- openssl-1.0.2g.orig/crypto/x509/x509_vfy.c
>>>  openssl-1.0.2g/crypto/x509/x509_vfy.c
>>>  @@ -119,6 +119,7 @@ static int check_trust(X509_STORE_CTX *c
>>>   static int check_revocation(X509_STORE_CTX *ctx);
>>>   static int check_cert(X509_STORE_CTX *ctx);
>>> @@ -25,17 +26,17 @@ Index: openssl-1.0.2/crypto/x509/x509_vfy.c
>>>
>>>   static int get_crl_score(X509_STORE_CTX *ctx, X509 **pissuer,
>>>unsigned int *preasons, X509_CRL *crl, X509 *x);
>>> -@@ -438,6 +439,9 @@ int X509_verify_cert(X509_STORE_CTX *ctx
>>> +@@ -489,6 +490,9 @@ int X509_verify_cert(X509_STORE_CTX *ctx
>>>   if (!ok)
>>> - goto end;
>>> + goto err;
>>>
>>>  +  ok = check_ca_blacklist(ctx);
>>> -+  if(!ok) goto end;
>>> ++  if(!ok) goto err;
>>>  +
>>>   #ifndef OPENSSL_NO_RFC3779
>>>   /* RFC 3779 path validation, now that CRL check has been done */
>>>   ok = v3_asid_validate_path(ctx);
>>> -@@ -938,6 +942,29 @@ static int check_crl_time(X509_STORE_CTX
>>> +@@ -996,6 +1000,29 @@ static int check_crl_time(X509_STORE_CTX
>>>   return 1;
>>>   }
>>>
>>> diff --git 
>>> a/meta/recipes-connectivity/openssl/openssl/debian1.0.2/version-script.patch
>>>  
>>> b/meta/recipes-connectivity/openssl/openssl/debian1.0.2/version-script.patch
>>> new file mode 100644
>>> index 000..29f11a2
>>> --- /dev/null
>>> +++ 
>>> b/meta/recipes-connectivity/openssl/openssl/debian1.0.2/version-script.patch
>>> @@ -0,0 +1,4656 @@
>>> +Index: openssl-1.0.2~beta1.obsolete.0.0498436515490575/Configure
>>> 

[OE-core] [PATCH 2/2] sdk_update.py: Enable local sdk-update tests

[Juro Bystricky]

Testing of local sdk updates was commented out.
Local sdk updates are functional now, so the tests should be re-enabled.

Signed-off-by: Juro Bystricky 
---
 meta/lib/oeqa/sdkext/sdk_update.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/lib/oeqa/sdkext/sdk_update.py 
b/meta/lib/oeqa/sdkext/sdk_update.py
index 16f5b10..7a2a6fe 100644
--- a/meta/lib/oeqa/sdkext/sdk_update.py
+++ b/meta/lib/oeqa/sdkext/sdk_update.py
@@ -30,8 +30,8 @@ class SdkUpdateTest(oeSDKExtTest):
 def test_sdk_update_http(self):
 output = self._run("devtool sdk-update \"%s\"" % self.http_url)
 
-#def test_sdk_update_local(self):
-#output = self._run("devtool sdk-update \"%s\"" % self.publish_dir)
+def test_sdk_update_local(self):
+output = self._run("devtool sdk-update \"%s\"" % self.publish_dir)
 
 @classmethod
 def tearDownClass(self):
-- 
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] sdk.py: Fix undefined variable

[Juro Bystricky]

"sdk_update" uses a variable newsdk_path, which was never declared.
This would cause the command:

devtool sdk-update 

to fail with an error:
NameError: global name 'newsdk_path' is not defined

The remedy is to declare newsdk_path as it was no doubt intended,
corresponding to the argument specifying .

[YOCTO#9042]

Signed-off-by: Juro Bystricky 
---
 scripts/lib/devtool/sdk.py | 1 +
 1 file changed, 1 insertion(+)

diff --git a/scripts/lib/devtool/sdk.py b/scripts/lib/devtool/sdk.py
index fbf2e79..22c5279 100644
--- a/scripts/lib/devtool/sdk.py
+++ b/scripts/lib/devtool/sdk.py
@@ -133,6 +133,7 @@ def sdk_update(args, config, basepath, workspace):
 logger.debug("Found conf/locked-sigs.inc in %s" % updateserver)
 update_dict = generate_update_dict(new_locked_sig_file_path, 
old_locked_sig_file_path)
 logger.debug("update_dict = %s" % update_dict)
+newsdk_path = updateserver
 sstate_dir = os.path.join(newsdk_path, 'sstate-cache')
 if not os.path.exists(sstate_dir):
 logger.error("sstate-cache directory not found under %s" % 
newsdk_path)
-- 
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] yocto-bsp: Set linux-yocto-4.1 as default for x86-64

[Lopez, Mariano]

On 3/2/2016 11:37 AM, Saul Wold wrote:

On Wed, 2016-03-02 at 08:14 +, mariano.lo...@linux.intel.com wrote:

From: Mariano Lopez 

Setting default kernel to linux-yocto-4.1 now that
3.19 bbappend is no longer in the tree.


This should default to 4.4 for 2.1, correct? 4.1 is the LSB/LTS kernel
for 2.1.


I was setting the default to the same as the other archs in order to fix 
the error with x86-64. If it's okay to change to version 4.4 at this 
point in the release I can send a v2 patch with all the archs updated.


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

Re: [OE-core] [PATCH][master][Drown] openssl: Security fix Drown via 1.0.1g update

[Andre McCurdy]

On Tue, Mar 1, 2016 at 11:38 PM, Armin Kuster  wrote:
> From: Armin Kuster 
>
> CVE-2016-0800
> CVE-2016-0705
> CVE-2016-0798
> CVE-2016-0797
> CVE-2016-0799
> CVE-2016-0702
> CVE-2016-0703
> CVE-2016-0704
>
> https://www.openssl.org/news/secadv/20160301.txt
>
> Updated 2 debian patches to match changes in 1.0.1g

Could you give some details on why the linker version script is now
required and how it was generated?

> Signed-off-by: Armin Kuster 
> ---
>  .../openssl/debian1.0.2/block_diginotar.patch  |   17 +-
>  .../openssl/debian1.0.2/version-script.patch   | 4656 
> 
>  .../{openssl_1.0.2f.bb => openssl_1.0.2g.bb}   |6 +-
>  3 files changed, 4668 insertions(+), 11 deletions(-)
>  create mode 100644 
> meta/recipes-connectivity/openssl/openssl/debian1.0.2/version-script.patch
>  rename meta/recipes-connectivity/openssl/{openssl_1.0.2f.bb => 
> openssl_1.0.2g.bb} (91%)
>
> diff --git 
> a/meta/recipes-connectivity/openssl/openssl/debian1.0.2/block_diginotar.patch 
> b/meta/recipes-connectivity/openssl/openssl/debian1.0.2/block_diginotar.patch
> index 0c1a0b6..d81e22c 100644
> --- 
> a/meta/recipes-connectivity/openssl/openssl/debian1.0.2/block_diginotar.patch
> +++ 
> b/meta/recipes-connectivity/openssl/openssl/debian1.0.2/block_diginotar.patch
> @@ -9,14 +9,15 @@ Reviewed-by: Kurt Roeckx 
>  Reviewed-by: Dr Stephen N Henson 
>
>  This is not meant as final patch.
> -
> +
>  Upstream-Status: Backport [debian]
>
> +Signed-off-by: Armin Kuster 
>
> -Index: openssl-1.0.2/crypto/x509/x509_vfy.c
> +Index: openssl-1.0.2g/crypto/x509/x509_vfy.c
>  ===
>  openssl-1.0.2.orig/crypto/x509/x509_vfy.c
> -+++ openssl-1.0.2/crypto/x509/x509_vfy.c
> +--- openssl-1.0.2g.orig/crypto/x509/x509_vfy.c
>  openssl-1.0.2g/crypto/x509/x509_vfy.c
>  @@ -119,6 +119,7 @@ static int check_trust(X509_STORE_CTX *c
>   static int check_revocation(X509_STORE_CTX *ctx);
>   static int check_cert(X509_STORE_CTX *ctx);
> @@ -25,17 +26,17 @@ Index: openssl-1.0.2/crypto/x509/x509_vfy.c
>
>   static int get_crl_score(X509_STORE_CTX *ctx, X509 **pissuer,
>unsigned int *preasons, X509_CRL *crl, X509 *x);
> -@@ -438,6 +439,9 @@ int X509_verify_cert(X509_STORE_CTX *ctx
> +@@ -489,6 +490,9 @@ int X509_verify_cert(X509_STORE_CTX *ctx
>   if (!ok)
> - goto end;
> + goto err;
>
>  +  ok = check_ca_blacklist(ctx);
> -+  if(!ok) goto end;
> ++  if(!ok) goto err;
>  +
>   #ifndef OPENSSL_NO_RFC3779
>   /* RFC 3779 path validation, now that CRL check has been done */
>   ok = v3_asid_validate_path(ctx);
> -@@ -938,6 +942,29 @@ static int check_crl_time(X509_STORE_CTX
> +@@ -996,6 +1000,29 @@ static int check_crl_time(X509_STORE_CTX
>   return 1;
>   }
>
> diff --git 
> a/meta/recipes-connectivity/openssl/openssl/debian1.0.2/version-script.patch 
> b/meta/recipes-connectivity/openssl/openssl/debian1.0.2/version-script.patch
> new file mode 100644
> index 000..29f11a2
> --- /dev/null
> +++ 
> b/meta/recipes-connectivity/openssl/openssl/debian1.0.2/version-script.patch
> @@ -0,0 +1,4656 @@
> +Index: openssl-1.0.2~beta1.obsolete.0.0498436515490575/Configure
> +===
> +--- openssl-1.0.2~beta1.obsolete.0.0498436515490575.orig/Configure 
> 2014-02-24 21:02:30.0 +0100
>  openssl-1.0.2~beta1.obsolete.0.0498436515490575/Configure  2014-02-24 
> 21:02:30.0 +0100
> +@@ -1651,6 +1651,8 @@
> +   }
> +   }
> +
> ++$shared_ldflag .= " -Wl,--version-script=openssl.ld";
> ++
> + open(IN,' + unlink("$Makefile.new") || die "unable to remove old $Makefile.new:$!\n" if 
> -e "$Makefile.new";
> + open(OUT,">$Makefile.new") || die "unable to create $Makefile.new:$!\n";
> +Index: openssl-1.0.2~beta1.obsolete.0.0498436515490575/openssl.ld
> +===
> +--- /dev/null  1970-01-01 00:00:00.0 +
>  openssl-1.0.2~beta1.obsolete.0.0498436515490575/openssl.ld 2014-02-24 
> 22:19:08.601827266 +0100
> +@@ -0,0 +1,4608 @@
> ++OPENSSL_1.0.2d {
> ++  global:
> ++  BIO_f_ssl;
> ++  BIO_new_buffer_ssl_connect;
> ++  BIO_new_ssl;
> ++  BIO_new_ssl_connect;
> ++  BIO_proxy_ssl_copy_session_id;
> ++  BIO_ssl_copy_session_id;
> ++  BIO_ssl_shutdown;
> ++  d2i_SSL_SESSION;
> ++ ...
> ++ ...
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/1] yocto-bsp: Set linux-yocto-4.1 as default for x86-64

[Saul Wold]

On Wed, 2016-03-02 at 08:14 +, mariano.lo...@linux.intel.com wrote:
> From: Mariano Lopez 
> 
> Setting default kernel to linux-yocto-4.1 now that
> 3.19 bbappend is no longer in the tree.
> 
This should default to 4.4 for 2.1, correct? 4.1 is the LSB/LTS kernel
for 2.1.

Sau!

> [YOCTO #9047]
> 
> Signed-off-by: Mariano Lopez 
> ---
>  .../target/arch/x86_64/recipes-kernel/linux/kernel-
> list.noinstall   | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/scripts/lib/bsp/substrate/target/arch/x86_64/recipes-
> kernel/linux/kernel-list.noinstall
> b/scripts/lib/bsp/substrate/target/arch/x86_64/recipes-
> kernel/linux/kernel-list.noinstall
> index dbbe934..7676ca8 100644
> --- a/scripts/lib/bsp/substrate/target/arch/x86_64/recipes-
> kernel/linux/kernel-list.noinstall
> +++ b/scripts/lib/bsp/substrate/target/arch/x86_64/recipes-
> kernel/linux/kernel-list.noinstall
> @@ -2,4 +2,4 @@
>  {{ input type:"boolean" name:"use_default_kernel" prio:"10"
> msg:"Would you like to use the default (4.1) kernel? (y/n)"
> default:"y"}}
>  
>  {{ if kernel_choice != "custom" and use_default_kernel == "n": }}
> -{{ input type:"choicelist" name:"kernel_choice"
> gen:"bsp.kernel.kernels" prio:"10" msg:"Please choose the kernel to
> use in this BSP:" default:"linux-yocto_3.19"}}
> +{{ input type:"choicelist" name:"kernel_choice"
> gen:"bsp.kernel.kernels" prio:"10" msg:"Please choose the kernel to
> use in this BSP:" default:"linux-yocto_4.1"}}
> -- 
> 2.6.2
> 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 1/1] yocto-bsp: Set linux-yocto-4.1 as default for x86-64

[mariano . lopez]

From: Mariano Lopez 

Setting default kernel to linux-yocto-4.1 now that
3.19 bbappend is no longer in the tree.

[YOCTO #9047]

Signed-off-by: Mariano Lopez 
---
 .../target/arch/x86_64/recipes-kernel/linux/kernel-list.noinstall   | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/scripts/lib/bsp/substrate/target/arch/x86_64/recipes-kernel/linux/kernel-list.noinstall
 
b/scripts/lib/bsp/substrate/target/arch/x86_64/recipes-kernel/linux/kernel-list.noinstall
index dbbe934..7676ca8 100644
--- 
a/scripts/lib/bsp/substrate/target/arch/x86_64/recipes-kernel/linux/kernel-list.noinstall
+++ 
b/scripts/lib/bsp/substrate/target/arch/x86_64/recipes-kernel/linux/kernel-list.noinstall
@@ -2,4 +2,4 @@
 {{ input type:"boolean" name:"use_default_kernel" prio:"10" msg:"Would you 
like to use the default (4.1) kernel? (y/n)" default:"y"}}
 
 {{ if kernel_choice != "custom" and use_default_kernel == "n": }}
-{{ input type:"choicelist" name:"kernel_choice" gen:"bsp.kernel.kernels" 
prio:"10" msg:"Please choose the kernel to use in this BSP:" 
default:"linux-yocto_3.19"}}
+{{ input type:"choicelist" name:"kernel_choice" gen:"bsp.kernel.kernels" 
prio:"10" msg:"Please choose the kernel to use in this BSP:" 
default:"linux-yocto_4.1"}}
-- 
2.6.2

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

Re: [OE-core] [PATCH 04/19] nspr: update to 4.12

[Martin Jansa]

On Wed, Mar 02, 2016 at 03:23:25PM +, Richard Purdie wrote:
> On Wed, 2016-03-02 at 06:30 -0800, Khem Raj wrote:
> > On Wed, Mar 2, 2016 at 6:18 AM, Alexander Kanavin
> >  wrote:
> > > his probably could be however OE-Core supports musl and poky
> > > > -tiny
> > > > defaults to it. It will be good to test
> > > > changes for it when changing OE-Core at the least bitbake -cpatch
> > > > 
> > > 
> > > 
> > > Yes, but that's a job for autobuilder,
> > 
> > There is a musl job on autobuilder. Not sure if its run daily. Ross ?
> 
> Its run manually at the moment. We've been working to get to the point
> where its reliable, then we'll add it to the list of build tests we
> run. I think we're now at that point actually.
> 
> Beth: Should we enable musl and no-x11 by default?

Can someone enable also read-only and thumb on one of qemuarm builds?

You can probably just change current qemuarm builds to do read-only and
thumb, because this combination will catch more issues that read-write
and without-thumb. See:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=9155
https://bugzilla.yoctoproject.org/show_bug.cgi?id=9155

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

-- 
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com


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

Re: [OE-core] [PATCHv2] Add tune for 32-bit ARMv8-a

[Andrei Gherzan]

On Wed, Mar 2, 2016 at 11:35 AM, Dragomir Daniel <
daniel.drago...@windriver.com> wrote:

> Hi Andrei,
>
>
> On 03/02/2016 02:17 AM, Andrei Gherzan wrote:
>
> Hi Daniel,
>
> On Sat, Feb 27, 2016 at 1:44 PM, Daniel Dragomir <
> daniel.drago...@windriver.com> wrote:
>
>> This patch adds tunes for 32-bit armv8 platforms. The user can select
>> the vector floating-point instruction set: vfpv3, vfpv4 or fp-armv8
>> and the Neon, crc and crypto extensions.
>>
>> Also, fix some parsing failures for armv7a*-neon-vfpv4 tunes.
>>
>> Signed-off-by: Daniel Dragomir < 
>> daniel.drago...@windriver.com>
>> Signed-off-by: Cristian Bercaru 
>> ---
>>  meta/conf/machine/include/arm/arch-armv7a.inc |  4 +-
>>  meta/conf/machine/include/arm/arch-armv8a.inc | 75
>> +++
>>  2 files changed, 77 insertions(+), 2 deletions(-)
>>  create mode 100644 meta/conf/machine/include/arm/arch-armv8a.inc
>>
>> diff --git a/meta/conf/machine/include/arm/arch-armv7a.inc
>> b/meta/conf/machine/include/arm/arch-armv7a.inc
>> index d3b6f64..ff6bc29 100644
>> --- a/meta/conf/machine/include/arm/arch-armv7a.inc
>> +++ b/meta/conf/machine/include/arm/arch-armv7a.inc
>> @@ -65,8 +65,8 @@ PACKAGE_EXTRA_ARCHS_tune-armv7ahf-vfpv3 =
>> "${PACKAGE_EXTRA_ARCHS_tune-armv7ahf-v
>>  PACKAGE_EXTRA_ARCHS_tune-armv7athf-vfpv3 =
>> "${PACKAGE_EXTRA_ARCHS_tune-armv7athf-vfpv3d16} armv7ahf-vfp-vfpv3d16-vfpv3
>> armv7at2hf-vfp-vfpv3d16-vfpv3"
>>  PACKAGE_EXTRA_ARCHS_tune-armv7ahf-neon =
>> "${PACKAGE_EXTRA_ARCHS_tune-armv7ahf} armv7ahf-vfp-neon"
>>  PACKAGE_EXTRA_ARCHS_tune-armv7athf-neon =
>> "${PACKAGE_EXTRA_ARCHS_tune-armv7athf} armv7ahf-vfp-neon
>> armv7at2hf-vfp-neon"
>> -PACKAGE_EXTRA_ARCHS_tune-armv7ahf-neon-vfpv4 =
>> "${PACKAGE_EXTRA_ARCHS_tune-armv7ahf-neon} armv7ahf-vfp-neon-vfpv4"
>> -PACKAGE_EXTRA_ARCHS_tune-armv7athf-neon-vfpv4 =
>> "${PACKAGE_EXTRA_ARCHS_tune-armv7athf-neon} armv7ahf-vfp-neon-vfpv4
>> armv7at2hf-vfp-neon-vfpv4"
>> +PACKAGE_EXTRA_ARCHS_tune-armv7ahf-neon-vfpv4 =
>> "${PACKAGE_EXTRA_ARCHS_tune-armv7ahf-neon} armv7ahf-vfp-vfpv4-neon"
>> +PACKAGE_EXTRA_ARCHS_tune-armv7athf-neon-vfpv4 =
>> "${PACKAGE_EXTRA_ARCHS_tune-armv7athf-neon} armv7ahf-vfp-vfpv4-neon
>> armv7at2hf-vfp-neon-vfpv4"
>>
>>  # Big Endian
>>  AVAILTUNES += "armv7ab armv7atb armv7ab-vfpv3d16 armv7atb-vfpv3d16
>> armv7ab-vfpv3 armv7atb-vfpv3 armv7ab-neon armv7atb-neon"
>> diff --git a/meta/conf/machine/include/arm/arch-armv8a.inc
>> b/meta/conf/machine/include/arm/arch-armv8a.inc
>> new file mode 100644
>> index 000..2d8dd73
>> --- /dev/null
>> +++ b/meta/conf/machine/include/arm/arch-armv8a.inc
>> @@ -0,0 +1,75 @@
>> +DEFAULTTUNE ?= "armv8a"
>> +
>> +TUNEVALID[armv8a] = "Enable instructions for ARMv8-a"
>> +TUNECONFLICTS[armv8a] = "armv4 armv5 armv6 armv7 armv7a"
>> +
>> +TUNEVALID[crc] = "Enable CRC instrucitons for ARMv8-a"
>>
>
> Small typo here: instrucitons .
>
>
> Thanks! Didn't noticed :)
>
>
Welcome.


>
>
>
>> +ARMPKGSFX_FPU .= "${@bb.utils.contains(" 
>> <$%7B@bb.utils.contains(>TUNE_FEATURES",
>> "crc", "-crc", "", d)}"
>> +
>> +TUNEVALID[crypto] = "Enable ARMv8 crypto extension."
>> +ARMPKGSFX_FPU .= "${@bb.utils.contains(" 
>> <$%7B@bb.utils.contains(>TUNE_FEATURES",
>> "crypto", "-crypto", "", d)}"
>> +
>> +TUNEVALID[fp-armv8] = "Enable ARMv8 Vector Floating Point unit."
>> +ARMPKGSFX_FPU .= "${@bb.utils.contains(" 
>> <$%7B@bb.utils.contains(>TUNE_FEATURES",
>> "fp-armv8", "-fp-armv8", "", d)}"
>> +
>> +TUNE_CCARGS .= "${@bb.utils.contains(" 
>> <$%7B@bb.utils.contains(>TUNE_FEATURES",
>> "armv8a", bb.utils.contains("TUNE_FEATURES", "crc", " -march=armv8-a+crc",
>> " -march=armv8-a", d), "", d)}"
>> +
>> +TUNE_CCARGS .= "${@bb.utils.contains(" 
>> <$%7B@bb.utils.contains(>TUNE_FEATURES",
>> "fp-armv8", bb.utils.contains("TUNE_FEATURES", "neon",
>> bb.utils.contains("TUNE_FEATURES", "crypto", " -mfpu=crypto-neon-fp-armv8",
>> " -mfpu=neon-fp-armv8", d), " -mfpu=fp-armv8", d), "", d)}"
>> +
>> +MACHINEOVERRIDES =. "${@bb.utils.contains(" 
>> <$%7B@bb.utils.contains(>TUNE_FEATURES",
>> "armv8a", "armv8a:", "" ,d)}"
>> +
>> +require conf/machine/include/arm/arch-armv7a.inc
>> +
>> +# Little Endian base configs
>> +AVAILTUNES += "armv8a armv8a-vfpv3 armv8a-neon armv8a-vfpv4
>> armv8a-vfpv4-neon armv8a-fp-armv8 armv8a-fp-armv8-neon
>> armv8a-crypto-fp-armv8-neon"
>> +ARMPKGARCH_tune-armv8a ?= "armv8a"
>> +ARMPKGARCH_tune-armv8a-vfpv3 ?= "armv8a"
>> +ARMPKGARCH_tune-armv8a-neon ?= "armv8a"
>> +ARMPKGARCH_tune-armv8a-vfpv4 ?= "armv8a"
>> +ARMPKGARCH_tune-armv8a-vfpv4-neon ?= "armv8a"
>> +ARMPKGARCH_tune-armv8a-fp-armv8 ?= "armv8a"
>> +ARMPKGARCH_tune-armv8a-fp-armv8-neon ?= "armv8a"
>> +ARMPKGARCH_tune-armv8a-crypto-fp-armv8-neon ?= "armv8a"
>> +TUNE_FEATURES_tune-armv8a ?= "arm armv8a vfp"
>> +TUNE_FEATURES_tune-armv8a-vfpv3 ?= "${TUNE_FEATURES_tune-armv8a} vfpv3"
>> +TUNE_FEATURES_tune-armv8a-neon ?= "${TUNE_FEATURES_tune-armv8a} neon"
>> +TUNE_FEATURES_tune-armv8a-vfpv4 ?= 

Re: [OE-core] [PATCH 04/19] nspr: update to 4.12

[Richard Purdie]

On Wed, 2016-03-02 at 06:30 -0800, Khem Raj wrote:
> On Wed, Mar 2, 2016 at 6:18 AM, Alexander Kanavin
>  wrote:
> > his probably could be however OE-Core supports musl and poky
> > > -tiny
> > > defaults to it. It will be good to test
> > > changes for it when changing OE-Core at the least bitbake -cpatch
> > > 
> > 
> > 
> > Yes, but that's a job for autobuilder,
> 
> There is a musl job on autobuilder. Not sure if its run daily. Ross ?

Its run manually at the moment. We've been working to get to the point
where its reliable, then we'll add it to the list of build tests we
run. I think we're now at that point actually.

Beth: Should we enable musl and no-x11 by default?

Cheers,

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

[OE-core] [PATCH v7 1/5] gpg_sign: add local ipk package signing functionality

[Ioan-Adrian Ratiu]

Implement ipk signing inside the sign_ipk bbclass using the gpg_sign
module and configure signing similar to how rpm does it. sign_ipk uses
gpg_sign's detach_sign because its functionality is identical to package
feed signing.

IPK signing process is a bit different from rpm:
- Signatures are stored outside ipk files; opkg connects to a feed
server and downloads them to verify a package.
- Signatures are of two types (both supported by opkg): binary or
ascii armoured. By default we sign using ascii armoured.
- Public keys are stored on targets to verify ipks using the
opkg-keyrings recipe.

Signed-off-by: Ioan-Adrian Ratiu 
---
 meta/classes/package_ipk.bbclass |  5 
 meta/classes/sign_ipk.bbclass| 52 
 meta/lib/oe/gpg_sign.py  | 41 +--
 3 files changed, 86 insertions(+), 12 deletions(-)
 create mode 100644 meta/classes/sign_ipk.bbclass

diff --git a/meta/classes/package_ipk.bbclass b/meta/classes/package_ipk.bbclass
index 51bee28..f1ad1d5 100644
--- a/meta/classes/package_ipk.bbclass
+++ b/meta/classes/package_ipk.bbclass
@@ -246,6 +246,11 @@ python do_package_ipk () {
 bb.utils.unlockfile(lf)
 raise bb.build.FuncFailed("opkg-build execution failed")
 
+if d.getVar('IPK_SIGN_PACKAGES', True) == '1':
+ipkver = "%s-%s" % (d.getVar('PKGV', True), d.getVar('PKGR', True))
+ipk_to_sign = "%s/%s_%s_%s.ipk" % (pkgoutdir, pkgname, ipkver, 
d.getVar('PACKAGE_ARCH', True))
+sign_ipk(d, ipk_to_sign)
+
 cleanupcontrol(root)
 bb.utils.unlockfile(lf)
 
diff --git a/meta/classes/sign_ipk.bbclass b/meta/classes/sign_ipk.bbclass
new file mode 100644
index 000..a481f6d
--- /dev/null
+++ b/meta/classes/sign_ipk.bbclass
@@ -0,0 +1,52 @@
+# Class for generating signed IPK packages.
+#
+# Configuration variables used by this class:
+# IPK_GPG_PASSPHRASE_FILE
+#   Path to a file containing the passphrase of the signing key.
+# IPK_GPG_NAME
+#   Name of the key to sign with.
+# IPK_GPG_BACKEND
+#   Optional variable for specifying the backend to use for signing.
+#   Currently the only available option is 'local', i.e. local signing
+#   on the build host.
+# IPK_GPG_SIGNATURE_TYPE
+#   Optional variable for specifying the type of gpg signatures, can 
be:
+# 1. Ascii armored (ASC), default if not set
+# 2. Binary (BIN)
+# GPG_BIN
+#   Optional variable for specifying the gpg binary/wrapper to use for
+#   signing.
+# GPG_PATH
+#   Optional variable for specifying the gnupg "home" directory:
+#
+
+inherit sanity
+
+IPK_SIGN_PACKAGES = '1'
+IPK_GPG_BACKEND ?= 'local'
+IPK_GPG_SIGNATURE_TYPE ?= 'ASC'
+
+python () {
+# Check configuration
+for var in ('IPK_GPG_NAME', 'IPK_GPG_PASSPHRASE_FILE'):
+if not d.getVar(var, True):
+raise_sanity_error("You need to define %s in the config" % var, d)
+
+sigtype = d.getVar("IPK_GPG_SIGNATURE_TYPE", True)
+if sigtype.upper() != "ASC" and sigtype.upper() != "BIN":
+raise_sanity_error("Bad value for IPK_GPG_SIGNATURE_TYPE (%s), use 
either ASC or BIN" % sigtype)
+}
+
+def sign_ipk(d, ipk_to_sign):
+from oe.gpg_sign import get_signer
+
+bb.debug(1, 'Signing ipk: %s' % ipk_to_sign)
+
+signer = get_signer(d, d.getVar('IPK_GPG_BACKEND', True))
+sig_type = d.getVar('IPK_GPG_SIGNATURE_TYPE', True)
+is_ascii_sig = (sig_type.upper() != "BIN")
+
+signer.detach_sign(ipk_to_sign,
+   d.getVar('IPK_GPG_NAME', True),
+   d.getVar('IPK_GPG_PASSPHRASE_FILE', True),
+   armor=is_ascii_sig)
diff --git a/meta/lib/oe/gpg_sign.py b/meta/lib/oe/gpg_sign.py
index ada1b2f..1406f17 100644
--- a/meta/lib/oe/gpg_sign.py
+++ b/meta/lib/oe/gpg_sign.py
@@ -1,5 +1,6 @@
 """Helper module for GPG signing"""
 import os
+import sys
 
 import bb
 import oe.utils
@@ -50,6 +51,7 @@ class LocalSigner(object):
 bb.error('rpmsign failed: %s' % proc.before.strip())
 raise bb.build.FuncFailed("Failed to sign RPM packages")
 
+
 def detach_sign(self, input_file, keyid, passphrase_file, passphrase=None, 
armor=True):
 """Create a detached signature of a file"""
 import subprocess
@@ -58,22 +60,37 @@ class LocalSigner(object):
 raise Exception("You should use either passphrase_file of 
passphrase, not both")
 
 cmd = [self.gpg_bin, '--detach-sign', '--batch', '--no-tty', '--yes',
-   '-u', keyid]
-if passphrase_file:
-cmd += ['--passphrase-file', passphrase_file]
-else:
-cmd += ['--passphrase-fd', '0']
+   '--passphrase-fd', '0', '-u', keyid]
+
 if self.gpg_path:
 cmd += ['--homedir', self.gpg_path]
 if armor:
 cmd += ['--armor']
-

[OE-core] [PATCH v7 3/5] gpg_sign: export_pubkey: add signature type support

[Ioan-Adrian Ratiu]

Add support for multiple types of signatures (binary or ascii)
in export_pubkey(). There is no change in behaviour for the function,
the previous implicit default is the new parameter "armor" default.

Signed-off-by: Ioan-Adrian Ratiu 
---
 meta/lib/oe/gpg_sign.py | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/meta/lib/oe/gpg_sign.py b/meta/lib/oe/gpg_sign.py
index 5d9ad49..1caba50 100644
--- a/meta/lib/oe/gpg_sign.py
+++ b/meta/lib/oe/gpg_sign.py
@@ -13,12 +13,14 @@ class LocalSigner(object):
 self.gpg_path = d.getVar('GPG_PATH', True)
 self.rpm_bin = bb.utils.which(os.getenv('PATH'), "rpm")
 
-def export_pubkey(self, output_file, keyid):
+def export_pubkey(self, output_file, keyid, armor=True):
 """Export GPG public key to a file"""
-cmd = '%s --batch --yes --export --armor -o %s ' % \
+cmd = '%s --batch --yes --export -o %s ' % \
 (self.gpg_bin, output_file)
 if self.gpg_path:
 cmd += "--homedir %s " % self.gpg_path
+if armor:
+cmd += "--armor "
 cmd += keyid
 status, output = oe.utils.getstatusoutput(cmd)
 if status:
-- 
2.7.1

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

[OE-core] [PATCH v7 5/5] package_manager: sign IPK package feeds

[Ioan-Adrian Ratiu]

Create gpg signed ipk package feeds using the gpg backend if configured.

Signed-off-by: Ioan-Adrian Ratiu 
---
 meta/classes/sign_package_feed.bbclass | 17 -
 meta/lib/oe/package_manager.py | 17 +++--
 2 files changed, 31 insertions(+), 3 deletions(-)

diff --git a/meta/classes/sign_package_feed.bbclass 
b/meta/classes/sign_package_feed.bbclass
index e1ec82e..ddb6ac5 100644
--- a/meta/classes/sign_package_feed.bbclass
+++ b/meta/classes/sign_package_feed.bbclass
@@ -10,6 +10,12 @@
 #   Optional variable for specifying the backend to use for signing.
 #   Currently the only available option is 'local', i.e. local signing
 #   on the build host.
+# PACKAGE_FEED_GPG_SIGNATURE_TYPE
+#   Optional variable for specifying the type of gpg signature, can be:
+#   1. Ascii armored (ASC), default if not set
+#   2. Binary (BIN)
+#   This variable is only available for IPK feeds. It is ignored on
+#   other packaging backends.
 # GPG_BIN
 #   Optional variable for specifying the gpg binary/wrapper to use for
 #   signing.
@@ -20,13 +26,22 @@ inherit sanity
 
 PACKAGE_FEED_SIGN = '1'
 PACKAGE_FEED_GPG_BACKEND ?= 'local'
-
+PACKAGE_FEED_GPG_SIGNATURE_TYPE ?= 'ASC'
 
 python () {
 # Check sanity of configuration
 for var in ('PACKAGE_FEED_GPG_NAME', 'PACKAGE_FEED_GPG_PASSPHRASE_FILE'):
 if not d.getVar(var, True):
 raise_sanity_error("You need to define %s in the config" % var, d)
+
+sigtype = d.getVar("PACKAGE_FEED_GPG_SIGNATURE_TYPE", True)
+if sigtype.upper() != "ASC" and sigtype.upper() != "BIN":
+raise_sanity_error("Bad value for PACKAGE_FEED_GPG_SIGNATURE_TYPE 
(%s), use either ASC or BIN" % sigtype)
+
+# Set expected location of the public key
+d.setVar('PACKAGE_FEED_GPG_PUBKEY',
+ os.path.join(d.getVar('STAGING_ETCDIR_NATIVE', False),
+   'PACKAGE-FEED-GPG-PUBKEY'))
 }
 
 do_package_index[depends] += "signing-keys:do_deploy"
diff --git a/meta/lib/oe/package_manager.py b/meta/lib/oe/package_manager.py
index 5cd43e9..7e3baef 100644
--- a/meta/lib/oe/package_manager.py
+++ b/meta/lib/oe/package_manager.py
@@ -153,11 +153,16 @@ class OpkgIndexer(Indexer):
  "MULTILIB_ARCHS"]
 
 opkg_index_cmd = bb.utils.which(os.getenv('PATH'), "opkg-make-index")
+if self.d.getVar('PACKAGE_FEED_SIGN', True) == '1':
+signer = get_signer(self.d, 
self.d.getVar('PACKAGE_FEED_GPG_BACKEND', True))
+else:
+signer = None
 
 if not os.path.exists(os.path.join(self.deploy_dir, "Packages")):
 open(os.path.join(self.deploy_dir, "Packages"), "w").close()
 
 index_cmds = []
+index_sign_files = []
 for arch_var in arch_vars:
 archs = self.d.getVar(arch_var, True)
 if archs is None:
@@ -176,6 +181,8 @@ class OpkgIndexer(Indexer):
 index_cmds.append('%s -r %s -p %s -m %s' %
   (opkg_index_cmd, pkgs_file, pkgs_file, 
pkgs_dir))
 
+index_sign_files.append(pkgs_file)
+
 if len(index_cmds) == 0:
 bb.note("There are no packages in %s!" % self.deploy_dir)
 return
@@ -183,9 +190,15 @@ class OpkgIndexer(Indexer):
 result = oe.utils.multiprocess_exec(index_cmds, create_index)
 if result:
 bb.fatal('%s' % ('\n'.join(result)))
-if self.d.getVar('PACKAGE_FEED_SIGN', True) == '1':
-raise NotImplementedError('Package feed signing not implementd for 
ipk')
 
+if signer:
+feed_sig_type = self.d.getVar('PACKAGE_FEED_GPG_SIGNATURE_TYPE', 
True)
+is_ascii_sig = (feed_sig_type.upper() != "BIN")
+for f in index_sign_files:
+signer.detach_sign(f,
+   self.d.getVar('PACKAGE_FEED_GPG_NAME', 
True),
+   
self.d.getVar('PACKAGE_FEED_GPG_PASSPHRASE_FILE', True),
+   armor=is_ascii_sig)
 
 
 class DpkgIndexer(Indexer):
-- 
2.7.1

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

[OE-core] [PATCH v7 4/5] signing-keys: create ipk package

[Ioan-Adrian Ratiu]

Store the ascii armored pubkey generated using gpg_sign.export_pubkey()
in its own package.

Signed-off-by: Ioan-Adrian Ratiu 
---
 meta/recipes-core/meta/signing-keys.bb | 15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-core/meta/signing-keys.bb 
b/meta/recipes-core/meta/signing-keys.bb
index 1d0e834..e843301 100644
--- a/meta/recipes-core/meta/signing-keys.bb
+++ b/meta/recipes-core/meta/signing-keys.bb
@@ -12,9 +12,10 @@ inherit allarch deploy
 EXCLUDE_FROM_WORLD = "1"
 INHIBIT_DEFAULT_DEPS = "1"
 
-PACKAGES =+ "${PN}-rpm ${PN}-packagefeed"
+PACKAGES =+ "${PN}-ipk ${PN}-rpm ${PN}-packagefeed"
 
 FILES_${PN}-rpm = "${sysconfdir}/pki/rpm-gpg"
+FILES_${PN}-ipk = "${sysconfdir}/pki/ipk-gpg"
 FILES_${PN}-packagefeed = "${sysconfdir}/pki/packagefeed-gpg"
 
 python do_get_public_keys () {
@@ -26,6 +27,12 @@ python do_get_public_keys () {
 signer.export_pubkey(os.path.join(d.expand('${B}'), 'rpm-key'),
  d.getVar('RPM_GPG_NAME', True))
 
+if d.getVar("IPK_SIGN_PACKAGES", True):
+# Export public key of the ipk signing key
+signer = get_signer(d, d.getVar('IPK_GPG_BACKEND', True))
+signer.export_pubkey(os.path.join(d.expand('${B}'), 'ipk-key'),
+ d.getVar('IPK_GPG_NAME', True))
+
 if d.getVar('PACKAGE_FEED_SIGN', True) == '1':
 # Export public key of the feed signing key
 signer = get_signer(d, d.getVar('PACKAGE_FEED_GPG_BACKEND', True))
@@ -39,6 +46,9 @@ do_install () {
 if [ -f "${B}/rpm-key" ]; then
 install -D -m 0644 "${B}/rpm-key" 
"${D}${sysconfdir}/pki/rpm-gpg/RPM-GPG-KEY-${DISTRO_VERSION}"
 fi
+if [ -f "${B}/ipk-key" ]; then
+install -D -m 0644 "${B}/ipk-key" 
"${D}${sysconfdir}/pki/ipk-gpg/IPK-GPG-KEY-${DISTRO_VERSION}"
+fi
 if [ -f "${B}/pf-key" ]; then
 install -D -m 0644 "${B}/pf-key" 
"${D}${sysconfdir}/pki/packagefeed-gpg/PACKAGEFEED-GPG-KEY-${DISTRO_VERSION}"
 fi
@@ -52,6 +62,9 @@ do_deploy () {
 if [ -f "${B}/rpm-key" ]; then
 install -D -m 0644 "${B}/rpm-key" 
"${DEPLOYDIR}/RPM-GPG-KEY-${DISTRO_VERSION}"
 fi
+if [ -f "${B}/ipk-key" ]; then
+install -D -m 0644 "${B}/ipk-key" 
"${DEPLOYDIR}/IPK-GPG-KEY-${DISTRO_VERSION}"
+fi
 if [ -f "${B}/pf-key" ]; then
 install -D -m 0644 "${B}/pf-key" 
"${DEPLOYDIR}/PACKAGEFEED-GPG-KEY-${DISTRO_VERSION}"
 fi
-- 
2.7.1

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

[OE-core] [PATCH v7 0/5] IPK signing for the gpg_sign module

[Ioan-Adrian Ratiu]

This patch series extends the gpg_sign module to support ipk signing.

Changes since v6:
  * Added pubkey to signing_keys.bb and rebased on top of Randy's work
  * Made gpg version detection logic more robust
  * Simplified detach_sign() gpg communication (no more os.pipe)

Ioan-Adrian Ratiu (5):
  gpg_sign: add local ipk package signing functionality
  gpg_sign: detach_sign: fix gpg > 2.1 STDIN file descriptor
  gpg_sign: export_pubkey: add signature type support
  signing-keys: create ipk package
  package_manager: sign IPK package feeds

 meta/classes/package_ipk.bbclass   |  5 +++
 meta/classes/sign_ipk.bbclass  | 52 
 meta/classes/sign_package_feed.bbclass | 17 -
 meta/lib/oe/gpg_sign.py| 63 ++
 meta/lib/oe/package_manager.py | 17 +++--
 meta/recipes-core/meta/signing-keys.bb | 15 +++-
 6 files changed, 151 insertions(+), 18 deletions(-)
 create mode 100644 meta/classes/sign_ipk.bbclass

-- 
2.7.1

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

[OE-core] [PATCH v7 2/5] gpg_sign: detach_sign: fix gpg > 2.1 STDIN file descriptor

[Ioan-Adrian Ratiu]

Starting from v2.1 passing passwords directly to gpg does not work
anymore [1], instead a loopback interface must be used otherwise
gpg >2.1 will error out with:
"gpg: signing failed: Inappropriate ioctl for device"

gpg <2.1 does not work with the new --pinentry-mode arg and gives an
invalid option error, so we detect what is the running version of gpg
and pass it accordingly.

[1] https://wiki.archlinux.org/index.php/GnuPG#Unattended_passphrase

Signed-off-by: Ioan-Adrian Ratiu 
---
 meta/lib/oe/gpg_sign.py | 16 
 1 file changed, 16 insertions(+)

diff --git a/meta/lib/oe/gpg_sign.py b/meta/lib/oe/gpg_sign.py
index 1406f17..5d9ad49 100644
--- a/meta/lib/oe/gpg_sign.py
+++ b/meta/lib/oe/gpg_sign.py
@@ -67,6 +67,13 @@ class LocalSigner(object):
 if armor:
 cmd += ['--armor']
 
+#gpg > 2.1 supports password pipes only through the loopback interface
+#gpg < 2.1 errors out if given unknown parameters
+dots = self.get_gpg_version().split('.')
+assert len(dots) >= 2
+if int(dots[0]) >= 2 and int(dots[1]) >= 1:
+cmd += ['--pinentry-mode', 'loopback']
+
 cmd += [input_file]
 
 try:
@@ -92,6 +99,15 @@ class LocalSigner(object):
 raise Exception("Failed to sign '%s'" % input_file)
 
 
+def get_gpg_version(self):
+"""Return the gpg version"""
+import subprocess
+try:
+return subprocess.check_output((self.gpg_bin, 
"--version")).split()[2]
+except subprocess.CalledProcessError as e:
+raise bb.build.FuncFailed("Could not get gpg version: %s" % e)
+
+
 def verify(self, sig_file):
 """Verify signature"""
 cmd = self.gpg_bin + " --verify "
-- 
2.7.1

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

Re: [OE-core] [PATCH 04/19] nspr: update to 4.12

[Khem Raj]

On Wed, Mar 2, 2016 at 6:18 AM, Alexander Kanavin
 wrote:
> On 03/01/2016 04:58 PM, Khem Raj wrote:
>
>>> The failing patch is applied only when musl is in use (and so the
>>> regression
>>> went unnoticed). Can you rework it so that it can be applied
>>> unconditionally?
>>
>>
>> This probably could be however OE-Core supports musl and poky-tiny
>> defaults to it. It will be good to test
>> changes for it when changing OE-Core at the least bitbake -cpatch 
>
>
> Yes, but that's a job for autobuilder,

There is a musl job on autobuilder. Not sure if its run daily. Ross ?

I'm afraid. When doing local changes,
> I have to draw the line somewhere about what I test, and what I don't, and
> testing builds against various libc providers is outside of that.

Thats good to please mention that in your patch submissions especially
when you touch a recipe which is using such overrides for anything so
maintainers know testing it has received.

>
> Generally, patches should be unconditional, because a) we should be able to
> send them upstream, b) conditional patches create several slightly different
> versions of source code, which is a maintenance headache.
>

We understand that, sometimes its not possible.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 04/19] nspr: update to 4.12

[Alexander Kanavin]

On 03/01/2016 04:58 PM, Khem Raj wrote:


The failing patch is applied only when musl is in use (and so the regression
went unnoticed). Can you rework it so that it can be applied
unconditionally?


This probably could be however OE-Core supports musl and poky-tiny
defaults to it. It will be good to test
changes for it when changing OE-Core at the least bitbake -cpatch 


Yes, but that's a job for autobuilder, I'm afraid. When doing local 
changes, I have to draw the line somewhere about what I test, and what I 
don't, and testing builds against various libc providers is outside of that.


Generally, patches should be unconditional, because a) we should be able 
to send them upstream, b) conditional patches create several slightly 
different versions of source code, which is a maintenance headache.



Alex

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

Re: [OE-core] [PATCH][RFC] base.bbclass: Introduce EXTRA_CONF_PACKAGECONFIG variable

[Martin Jansa]

On Wed, Mar 02, 2016 at 01:11:45PM +, Richard Purdie wrote:
> On Wed, 2016-03-02 at 13:38 +0100, Martin Jansa wrote:
> > On Sat, Feb 27, 2016 at 11:09:47PM +0100, Martin Jansa wrote:
> > > * add separate variable for configuration options generated from
> > >   PACKAGECONFIG setting, this helps other bbclasses and recipes
> > >   to take advantage of PACKAGECONFIG mechanism, without including
> > >   other options from EXTRA_OECONF
> > > * e.g. meta-qt5 recipes are abusing EXTRA_OECONF to get options
> > >   from PACKAGECONFIG:
> > >   EXTRA_QMAKEVARS_PRE +=
> > >   but with
> > >   conf/distro/include/no-static-libs.inc
> > >   it means getting --disable-static as invalid option inside
> > >   EXTRA_QMAKEVARS_PRE as reported by Alexandre Belloni who tried
> > >   to use poky with meta-qt5.
> > > * once we migrate all bbclasses and recipes to
> > > EXTRA_CONF_PACKAGECONFIG
> > >   we should also restrict EXTRA_OECONF append only to
> > > autotools.bbclass
> > >   like I did for cmake.bbclass
> > 
> > No comments? Should I resend without [RFC] tag?
> > 
> > This is needed to fix couple components when
> > conf/distro/include/no-static-libs.inc is used.
> 
> I can see the need for it, I'm just not 100% sure I like the form of
> the patch. No one particular thing is doing that, just a general
> feeling of unease which I can't quite put into words :(.
> 
> We continue to have a need to differentiate between "proper" autotools
> recipes and non-autotools recipes which would make this kind of issue
> easier. I guess I'm trying to weigh up whether we should consider
> something a bit more invasive to try and improve things and if we do
> that whether this patch helps or hinders that (it probably does help).

I've considered the invasive part of moving EXTRA_OECONF append to
autotools.bbclass (like I did for cmake.bbclass) but after grepping for
EXTRA_OECONF I've decided to leave it for separate step (e.g.
waf-samba.bbclass and meta-oe/recipes-benchmark/fio/fio_2.2.6.bb are
abusing EXTRA_OECONF and would break if we remove this).

EXTRA_OECMAKE wasn't afaik abused anywhere and fix for qt5 was
relatively simple:
http://patchwork.openembedded.org/patch/116981/

so I went with compromise to fix what's really failing now and leave
future cleanup/improvement for later when more recipes adapt
EXTRA_CONF_PACKAGECONFIG variable.

> I'm also not 100% convinced EXTRA_CONF_PACKAGECONFIG is the right name,
> but I can see how you got here and I'm not sure I have a better
> suggestion (PACKAGECONFIG_CONFPARAMS? _CONFARGS?)

I was expecting this discussion, I have no strong opinion either way.
Namespacing with with PACKAGECONFIG_ prefix is good idea though.

-- 
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com


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

Re: [OE-core] [PATCH][RFC] base.bbclass: Introduce EXTRA_CONF_PACKAGECONFIG variable

[Richard Purdie]

On Wed, 2016-03-02 at 13:38 +0100, Martin Jansa wrote:
> On Sat, Feb 27, 2016 at 11:09:47PM +0100, Martin Jansa wrote:
> > * add separate variable for configuration options generated from
> >   PACKAGECONFIG setting, this helps other bbclasses and recipes
> >   to take advantage of PACKAGECONFIG mechanism, without including
> >   other options from EXTRA_OECONF
> > * e.g. meta-qt5 recipes are abusing EXTRA_OECONF to get options
> >   from PACKAGECONFIG:
> >   EXTRA_QMAKEVARS_PRE +=
> >   but with
> >   conf/distro/include/no-static-libs.inc
> >   it means getting --disable-static as invalid option inside
> >   EXTRA_QMAKEVARS_PRE as reported by Alexandre Belloni who tried
> >   to use poky with meta-qt5.
> > * once we migrate all bbclasses and recipes to
> > EXTRA_CONF_PACKAGECONFIG
> >   we should also restrict EXTRA_OECONF append only to
> > autotools.bbclass
> >   like I did for cmake.bbclass
> 
> No comments? Should I resend without [RFC] tag?
> 
> This is needed to fix couple components when
> conf/distro/include/no-static-libs.inc is used.

I can see the need for it, I'm just not 100% sure I like the form of
the patch. No one particular thing is doing that, just a general
feeling of unease which I can't quite put into words :(.

We continue to have a need to differentiate between "proper" autotools
recipes and non-autotools recipes which would make this kind of issue
easier. I guess I'm trying to weigh up whether we should consider
something a bit more invasive to try and improve things and if we do
that whether this patch helps or hinders that (it probably does help).

I'm also not 100% convinced EXTRA_CONF_PACKAGECONFIG is the right name,
but I can see how you got here and I'm not sure I have a better
suggestion (PACKAGECONFIG_CONFPARAMS? _CONFARGS?)

Cheers,

Richard


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

Re: [OE-core] [PATCH][RFC] base.bbclass: Introduce EXTRA_CONF_PACKAGECONFIG variable

[Burton, Ross]

On 27 February 2016 at 22:09, Martin Jansa  wrote:

> * add separate variable for configuration options generated from
>   PACKAGECONFIG setting, this helps other bbclasses and recipes
>   to take advantage of PACKAGECONFIG mechanism, without including
>   other options from EXTRA_OECONF
> * e.g. meta-qt5 recipes are abusing EXTRA_OECONF to get options
>   from PACKAGECONFIG:
>   EXTRA_QMAKEVARS_PRE +=
>   but with
>   conf/distro/include/no-static-libs.inc
>   it means getting --disable-static as invalid option inside
>   EXTRA_QMAKEVARS_PRE as reported by Alexandre Belloni who tried
>   to use poky with meta-qt5.
> * once we migrate all bbclasses and recipes to EXTRA_CONF_PACKAGECONFIG
>   we should also restrict EXTRA_OECONF append only to autotools.bbclass
>   like I did for cmake.bbclass
>

Sorry, some of us have been a bit busy trying to get M3 stable.  This does
look good and I'm for squeezing it into M3.

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

Re: [OE-core] [PATCH][RFC] base.bbclass: Introduce EXTRA_CONF_PACKAGECONFIG variable

[Martin Jansa]

On Sat, Feb 27, 2016 at 11:09:47PM +0100, Martin Jansa wrote:
> * add separate variable for configuration options generated from
>   PACKAGECONFIG setting, this helps other bbclasses and recipes
>   to take advantage of PACKAGECONFIG mechanism, without including
>   other options from EXTRA_OECONF
> * e.g. meta-qt5 recipes are abusing EXTRA_OECONF to get options
>   from PACKAGECONFIG:
>   EXTRA_QMAKEVARS_PRE +=
>   but with
>   conf/distro/include/no-static-libs.inc
>   it means getting --disable-static as invalid option inside
>   EXTRA_QMAKEVARS_PRE as reported by Alexandre Belloni who tried
>   to use poky with meta-qt5.
> * once we migrate all bbclasses and recipes to EXTRA_CONF_PACKAGECONFIG
>   we should also restrict EXTRA_OECONF append only to autotools.bbclass
>   like I did for cmake.bbclass

No comments? Should I resend without [RFC] tag?

This is needed to fix couple components when
conf/distro/include/no-static-libs.inc is used.

Cheers,


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

Re: [OE-core] [PATCH] packagegroup-core-tools-profile: Enable valgrind on ARM

[Felipe Ferreri Tonello]

On 15/02/16 12:37, Burton, Ross wrote:
> On 13 February 2016 at 04:31, Andre McCurdy  > wrote:
> 
> $ cd openembedded-core
> $ git show af1ddab5c
> fatal: ambiguous argument 'af1ddab5c': unknown revision or path not in
> the working tree.
> 
> 
> That was a poky reference, the correct oe-core ref was e5f41c22.
> 
> But yes, what Andre said.  Felipe, can you revise the patch?
>

Right, I just read his email. Yes, I will revise that.

-- 
Felipe


0x92698E6A.asc
Description: application/pgp-keys
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] packagegroup-core-tools-profile: Enable valgrind on ARM

[Felipe Ferreri Tonello]

Hi Ross,

On 15/02/16 12:37, Burton, Ross wrote:
> On 13 February 2016 at 04:31, Andre McCurdy  > wrote:
> 
> $ cd openembedded-core
> $ git show af1ddab5c
> fatal: ambiguous argument 'af1ddab5c': unknown revision or path not in
> the working tree.
> 
> 
> That was a poky reference, the correct oe-core ref was e5f41c22.
> 
> But yes, what Andre said.  Felipe, can you revise the patch?
> 

Revise in a sense to update the commit reference?

-- 
Felipe


0x92698E6A.asc
Description: application/pgp-keys
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 0/3] Extensible SDK improvements

[Paul Eggleton]

Add ability to build derivative extensible SDK and fix up an issue with
the earlier patch introducing oe-workdir and oe-logs symlinks.


The following changes since commit 390bad905537820f49add855c95d726b5b55c8fa:

  sanity: Fix int verses string reference (2016-02-28 22:54:06 +)

are available in the git repository at:

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

Paul Eggleton (3):
  classes/externalsrc: fix symlinking if symlink exists pointing to another path
  devtool: build-image: rename module
  devtool: add build-sdk subcommand

 meta/classes/externalsrc.bbclass   |   1 +
 meta/classes/populate_sdk_ext.bbclass  | 148 +
 meta/lib/oe/copy_buildsystem.py|  59 +++-
 .../lib/devtool/{build-image.py => build_image.py} |  79 ---
 scripts/lib/devtool/build_sdk.py   |  65 +
 5 files changed, 265 insertions(+), 87 deletions(-)
 rename scripts/lib/devtool/{build-image.py => build_image.py} (67%)
 create mode 100644 scripts/lib/devtool/build_sdk.py

-- 
2.5.0

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

[OE-core] [PATCH 2/3] devtool: build-image: rename module

[Paul Eggleton]

Hyphens aren't allowed in python identifiers, so you shouldn't use them
in module names or they are more difficult to import.

Signed-off-by: Paul Eggleton 
---
 scripts/lib/devtool/{build-image.py => build_image.py} | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename scripts/lib/devtool/{build-image.py => build_image.py} (100%)

diff --git a/scripts/lib/devtool/build-image.py 
b/scripts/lib/devtool/build_image.py
similarity index 100%
rename from scripts/lib/devtool/build-image.py
rename to scripts/lib/devtool/build_image.py
-- 
2.5.0

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

[OE-core] [PATCH 1/3] classes/externalsrc: fix symlinking if symlink exists pointing to another path

[Paul Eggleton]

If the oe-workdir / oe-logs symlink exists and points to a different
path then the symlink needs to be removed before calling os.symlink() or
it'll fail.

Signed-off-by: Paul Eggleton 
---
 meta/classes/externalsrc.bbclass | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/classes/externalsrc.bbclass b/meta/classes/externalsrc.bbclass
index b608bd0..0ec338c 100644
--- a/meta/classes/externalsrc.bbclass
+++ b/meta/classes/externalsrc.bbclass
@@ -115,6 +115,7 @@ python externalsrc_configure_prefunc() {
 # Link already exists, leave it if it points to the right 
location already
 if os.readlink(lnkfile) == target:
 continue
+os.unlink(lnkfile)
 elif os.path.exists(lnkfile):
 # File/dir exists with same name as link, just leave it alone
 continue
-- 
2.5.0

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

[OE-core] [PATCH 3/3] devtool: add build-sdk subcommand

[Paul Eggleton]

Add a build-sdk command which is only available within the extensible
SDK that builds a derivative extensible SDK. The idea is recipes in the
workspace become a part of the new SDK - for example, this allows taking
a vendor provided SDK, adding a few libs and then producing a new SDK
with those included.

When normally building the extensible SDK, the workspace is excluded;
here we need to copy into the new SDK (renaming it in the process); the
recipes' task signatures become locked and thus the sources are no
longer needed, so they are removed along with the workspace bbappends
which would interfere with the locked signatures. Additionally we need
to just copy the configuration files (i.e. local.conf and auto.conf)
rather than filtering and appending to them since that work has already
been done when constructing the original SDK. The extra sstate artifacts
from workspace recipes are also determined and copied into the new SDK
in minimal mode (on the assumption that you won't set up a new sstate
mirror).

This reuses some code from build-image, so that needed to be
generalised to allow that.

Implements [YOCTO #8892].

Signed-off-by: Paul Eggleton 
---
 meta/classes/populate_sdk_ext.bbclass | 148 --
 meta/lib/oe/copy_buildsystem.py   |  59 --
 scripts/lib/devtool/build_image.py|  79 +-
 scripts/lib/devtool/build_sdk.py  |  65 +++
 4 files changed, 264 insertions(+), 87 deletions(-)
 create mode 100644 scripts/lib/devtool/build_sdk.py

diff --git a/meta/classes/populate_sdk_ext.bbclass 
b/meta/classes/populate_sdk_ext.bbclass
index 9e2fc61..192eef2 100644
--- a/meta/classes/populate_sdk_ext.bbclass
+++ b/meta/classes/populate_sdk_ext.bbclass
@@ -89,7 +89,14 @@ python copy_buildsystem () {
 # Copy in all metadata layers + bitbake (as repositories)
 buildsystem = oe.copy_buildsystem.BuildSystem('extensible SDK', d)
 baseoutpath = d.getVar('SDK_OUTPUT', True) + '/' + d.getVar('SDKPATH', 
True)
-layers_copied = buildsystem.copy_bitbake_and_layers(baseoutpath + 
'/layers')
+
+# Determine if we're building a derivative extensible SDK (from devtool 
build-sdk)
+derivative = (d.getVar('SDK_DERIVATIVE', True) or '') == '1'
+if derivative:
+workspace_name = 'orig-workspace'
+else:
+workspace_name = None
+layers_copied = buildsystem.copy_bitbake_and_layers(baseoutpath + 
'/layers', workspace_name)
 
 sdkbblayers = []
 corebase = os.path.basename(d.getVar('COREBASE', True))
@@ -153,75 +160,81 @@ python copy_buildsystem () {
 f.write('"\n')
 
 # Create local.conf
-local_conf_whitelist = (d.getVar('SDK_LOCAL_CONF_WHITELIST', True) or 
'').split()
-local_conf_blacklist = (d.getVar('SDK_LOCAL_CONF_BLACKLIST', True) or 
'').split()
-def handle_var(varname, origvalue, op, newlines):
-if varname in local_conf_blacklist or 
(origvalue.strip().startswith('/') and not varname in local_conf_whitelist):
-newlines.append('# Removed original setting of %s\n' % varname)
-return None, op, 0, True
-else:
-return origvalue, op, 0, True
-varlist = ['[^#=+ ]*']
 builddir = d.getVar('TOPDIR', True)
-with open(builddir + '/conf/local.conf', 'r') as f:
-oldlines = f.readlines()
-(updated, newlines) = bb.utils.edit_metadata(oldlines, varlist, handle_var)
+if derivative:
+shutil.copyfile(builddir + '/conf/local.conf', baseoutpath + 
'/conf/local.conf')
+else:
+local_conf_whitelist = (d.getVar('SDK_LOCAL_CONF_WHITELIST', True) or 
'').split()
+local_conf_blacklist = (d.getVar('SDK_LOCAL_CONF_BLACKLIST', True) or 
'').split()
+def handle_var(varname, origvalue, op, newlines):
+if varname in local_conf_blacklist or 
(origvalue.strip().startswith('/') and not varname in local_conf_whitelist):
+newlines.append('# Removed original setting of %s\n' % varname)
+return None, op, 0, True
+else:
+return origvalue, op, 0, True
+varlist = ['[^#=+ ]*']
+with open(builddir + '/conf/local.conf', 'r') as f:
+oldlines = f.readlines()
+(updated, newlines) = bb.utils.edit_metadata(oldlines, varlist, 
handle_var)
 
-with open(baseoutpath + '/conf/local.conf', 'w') as f:
-f.write('# WARNING: this configuration has been automatically 
generated and in\n')
-f.write('# most cases should not be edited. If you need more 
flexibility than\n')
-f.write('# this configuration provides, it is strongly suggested that 
you set\n')
-f.write('# up a proper instance of the full build system and use that 
instead.\n\n')
-for line in newlines:
-if line.strip() and not line.startswith('#'):
-f.write(line)
-# Write a newline just in case there's none at the end of the original
-   

Re: [OE-core] [PATCHv2] Add tune for 32-bit ARMv8-a

[Dragomir Daniel]

Hi Andrei,

On 03/02/2016 02:17 AM, Andrei Gherzan wrote:

Hi Daniel,

On Sat, Feb 27, 2016 at 1:44 PM, Daniel Dragomir 
> 
wrote:


This patch adds tunes for 32-bit armv8 platforms. The user can select
the vector floating-point instruction set: vfpv3, vfpv4 or fp-armv8
and the Neon, crc and crypto extensions.

Also, fix some parsing failures for armv7a*-neon-vfpv4 tunes.

Signed-off-by: Daniel Dragomir >
Signed-off-by: Cristian Bercaru http://windriver.com>>
---
 meta/conf/machine/include/arm/arch-armv7a.inc |  4 +-
 meta/conf/machine/include/arm/arch-armv8a.inc | 75
+++
 2 files changed, 77 insertions(+), 2 deletions(-)
 create mode 100644 meta/conf/machine/include/arm/arch-armv8a.inc

diff --git a/meta/conf/machine/include/arm/arch-armv7a.inc
b/meta/conf/machine/include/arm/arch-armv7a.inc
index d3b6f64..ff6bc29 100644
--- a/meta/conf/machine/include/arm/arch-armv7a.inc
+++ b/meta/conf/machine/include/arm/arch-armv7a.inc
@@ -65,8 +65,8 @@ PACKAGE_EXTRA_ARCHS_tune-armv7ahf-vfpv3 =
"${PACKAGE_EXTRA_ARCHS_tune-armv7ahf-v
 PACKAGE_EXTRA_ARCHS_tune-armv7athf-vfpv3 =
"${PACKAGE_EXTRA_ARCHS_tune-armv7athf-vfpv3d16}
armv7ahf-vfp-vfpv3d16-vfpv3 armv7at2hf-vfp-vfpv3d16-vfpv3"
 PACKAGE_EXTRA_ARCHS_tune-armv7ahf-neon =
"${PACKAGE_EXTRA_ARCHS_tune-armv7ahf} armv7ahf-vfp-neon"
 PACKAGE_EXTRA_ARCHS_tune-armv7athf-neon =
"${PACKAGE_EXTRA_ARCHS_tune-armv7athf} armv7ahf-vfp-neon
armv7at2hf-vfp-neon"
-PACKAGE_EXTRA_ARCHS_tune-armv7ahf-neon-vfpv4 =
"${PACKAGE_EXTRA_ARCHS_tune-armv7ahf-neon} armv7ahf-vfp-neon-vfpv4"
-PACKAGE_EXTRA_ARCHS_tune-armv7athf-neon-vfpv4 =
"${PACKAGE_EXTRA_ARCHS_tune-armv7athf-neon}
armv7ahf-vfp-neon-vfpv4 armv7at2hf-vfp-neon-vfpv4"
+PACKAGE_EXTRA_ARCHS_tune-armv7ahf-neon-vfpv4 =
"${PACKAGE_EXTRA_ARCHS_tune-armv7ahf-neon} armv7ahf-vfp-vfpv4-neon"
+PACKAGE_EXTRA_ARCHS_tune-armv7athf-neon-vfpv4 =
"${PACKAGE_EXTRA_ARCHS_tune-armv7athf-neon}
armv7ahf-vfp-vfpv4-neon armv7at2hf-vfp-neon-vfpv4"

 # Big Endian
 AVAILTUNES += "armv7ab armv7atb armv7ab-vfpv3d16
armv7atb-vfpv3d16 armv7ab-vfpv3 armv7atb-vfpv3 armv7ab-neon
armv7atb-neon"
diff --git a/meta/conf/machine/include/arm/arch-armv8a.inc
b/meta/conf/machine/include/arm/arch-armv8a.inc
new file mode 100644
index 000..2d8dd73
--- /dev/null
+++ b/meta/conf/machine/include/arm/arch-armv8a.inc
@@ -0,0 +1,75 @@
+DEFAULTTUNE ?= "armv8a"
+
+TUNEVALID[armv8a] = "Enable instructions for ARMv8-a"
+TUNECONFLICTS[armv8a] = "armv4 armv5 armv6 armv7 armv7a"
+
+TUNEVALID[crc] = "Enable CRC instrucitons for ARMv8-a"


Small typo here: instrucitons .


Thanks! Didn't noticed :)


+ARMPKGSFX_FPU .= "${@bb.utils.contains("TUNE_FEATURES", "crc",
"-crc", "", d)}"
+
+TUNEVALID[crypto] = "Enable ARMv8 crypto extension."
+ARMPKGSFX_FPU .= "${@bb.utils.contains("TUNE_FEATURES", "crypto",
"-crypto", "", d)}"
+
+TUNEVALID[fp-armv8] = "Enable ARMv8 Vector Floating Point unit."
+ARMPKGSFX_FPU .= "${@bb.utils.contains("TUNE_FEATURES",
"fp-armv8", "-fp-armv8", "", d)}"
+
+TUNE_CCARGS .= "${@bb.utils.contains("TUNE_FEATURES", "armv8a",
bb.utils.contains("TUNE_FEATURES", "crc", " -march=armv8-a+crc", "
-march=armv8-a", d), "", d)}"
+
+TUNE_CCARGS .= "${@bb.utils.contains("TUNE_FEATURES", "fp-armv8",
bb.utils.contains("TUNE_FEATURES", "neon",
bb.utils.contains("TUNE_FEATURES", "crypto", "
-mfpu=crypto-neon-fp-armv8", " -mfpu=neon-fp-armv8", d), "
-mfpu=fp-armv8", d), "", d)}"
+
+MACHINEOVERRIDES =. "${@bb.utils.contains("TUNE_FEATURES",
"armv8a", "armv8a:", "" ,d)}"
+
+require conf/machine/include/arm/arch-armv7a.inc
+
+# Little Endian base configs
+AVAILTUNES += "armv8a armv8a-vfpv3 armv8a-neon armv8a-vfpv4
armv8a-vfpv4-neon armv8a-fp-armv8 armv8a-fp-armv8-neon
armv8a-crypto-fp-armv8-neon"
+ARMPKGARCH_tune-armv8a ?= "armv8a"
+ARMPKGARCH_tune-armv8a-vfpv3 ?= "armv8a"
+ARMPKGARCH_tune-armv8a-neon ?= "armv8a"
+ARMPKGARCH_tune-armv8a-vfpv4 ?= "armv8a"
+ARMPKGARCH_tune-armv8a-vfpv4-neon ?= "armv8a"
+ARMPKGARCH_tune-armv8a-fp-armv8 ?= "armv8a"
+ARMPKGARCH_tune-armv8a-fp-armv8-neon ?= "armv8a"
+ARMPKGARCH_tune-armv8a-crypto-fp-armv8-neon ?= "armv8a"
+TUNE_FEATURES_tune-armv8a ?= "arm armv8a vfp"
+TUNE_FEATURES_tune-armv8a-vfpv3 ?= "${TUNE_FEATURES_tune-armv8a}
vfpv3"
+TUNE_FEATURES_tune-armv8a-neon ?= "${TUNE_FEATURES_tune-armv8a} neon"
+TUNE_FEATURES_tune-armv8a-vfpv4 ?= "${TUNE_FEATURES_tune-armv8a}
vfpv4"
+TUNE_FEATURES_tune-armv8a-vfpv4-neon ?=
"${TUNE_FEATURES_tune-armv8a} neon vfpv4"
+TUNE_FEATURES_tune-armv8a-fp-armv8 ?=
  

Re: [OE-core] [PATCHv2] Add tune for 32-bit ARMv8-a

[Dragomir Daniel]

On 03/01/2016 09:12 PM, Andre McCurdy wrote:

On Tue, Mar 1, 2016 at 8:33 AM, Dragomir Daniel
 wrote:

On 03/01/2016 02:02 AM, Andre McCurdy wrote:

On Sat, Feb 27, 2016 at 4:44 AM, Daniel Dragomir
 wrote:

This patch adds tunes for 32-bit armv8 platforms. The user can select
the vector floating-point instruction set: vfpv3, vfpv4 or fp-armv8
and the Neon, crc and crypto extensions.

Why vfpv3? Are there really any armv8a CPUs which have vfpv3 but not
vfpv4?


Hello Andre,

I didn't checked before, I simply follow armv7a example and add the new
features.
But it seams that you're right, all armv8a CPU support both vfp versions,
so, I will remove armv8a-vfpv3 tune and keep just vfpv4 one.


Also, fix some parsing failures for armv7a*-neon-vfpv4 tunes.

If you find any issues in arch-armv7a.inc then please double check
arch-armv7ve.inc too. These two files are very closely related.


Signed-off-by: Daniel Dragomir 
Signed-off-by: Cristian Bercaru 
---
   meta/conf/machine/include/arm/arch-armv7a.inc |  4 +-
   meta/conf/machine/include/arm/arch-armv8a.inc | 75
+++
   2 files changed, 77 insertions(+), 2 deletions(-)
   create mode 100644 meta/conf/machine/include/arm/arch-armv8a.inc

diff --git a/meta/conf/machine/include/arm/arch-armv7a.inc
b/meta/conf/machine/include/arm/arch-armv7a.inc
index d3b6f64..ff6bc29 100644
--- a/meta/conf/machine/include/arm/arch-armv7a.inc
+++ b/meta/conf/machine/include/arm/arch-armv7a.inc
@@ -65,8 +65,8 @@ PACKAGE_EXTRA_ARCHS_tune-armv7ahf-vfpv3 =
"${PACKAGE_EXTRA_ARCHS_tune-armv7ahf-v
   PACKAGE_EXTRA_ARCHS_tune-armv7athf-vfpv3 =
"${PACKAGE_EXTRA_ARCHS_tune-armv7athf-vfpv3d16} armv7ahf-vfp-vfpv3d16-vfpv3
armv7at2hf-vfp-vfpv3d16-vfpv3"
   PACKAGE_EXTRA_ARCHS_tune-armv7ahf-neon =
"${PACKAGE_EXTRA_ARCHS_tune-armv7ahf} armv7ahf-vfp-neon"
   PACKAGE_EXTRA_ARCHS_tune-armv7athf-neon =
"${PACKAGE_EXTRA_ARCHS_tune-armv7athf} armv7ahf-vfp-neon
armv7at2hf-vfp-neon"
-PACKAGE_EXTRA_ARCHS_tune-armv7ahf-neon-vfpv4 =
"${PACKAGE_EXTRA_ARCHS_tune-armv7ahf-neon} armv7ahf-vfp-neon-vfpv4"
-PACKAGE_EXTRA_ARCHS_tune-armv7athf-neon-vfpv4 =
"${PACKAGE_EXTRA_ARCHS_tune-armv7athf-neon} armv7ahf-vfp-neon-vfpv4
armv7at2hf-vfp-neon-vfpv4"
+PACKAGE_EXTRA_ARCHS_tune-armv7ahf-neon-vfpv4 =
"${PACKAGE_EXTRA_ARCHS_tune-armv7ahf-neon} armv7ahf-vfp-vfpv4-neon"
+PACKAGE_EXTRA_ARCHS_tune-armv7athf-neon-vfpv4 =
"${PACKAGE_EXTRA_ARCHS_tune-armv7athf-neon} armv7ahf-vfp-vfpv4-neon
armv7at2hf-vfp-neon-vfpv4"

Is this patch against jethro? Master seems to have a different fix:


http://git.openembedded.org/openembedded-core/commit/?id=6661718158f8fdcdf63b0d48e8fe72d3ac4778f2


Yes, against jethro branch. That's why I didn't saw this fix and also didn't
saw the arch-armv7ve.inc file.
How do I proceed if I want to have armv8a support in jethro? Should I
checkout the master branch and add my changes there and resend the patch
with the note to be backported to jethro?
But this patch (with the fix for armv7a) and the one that add
arch-armv7ve.inc will be back-ported to jethro too, or how is the process?

The process is always to get changes merged to master first.

Support for new CPU tuning options is unlikely to get backported to
the official jethro release, so you'll need to keep these changes in
your own branch or distro until you update to the OE release which
includes them.

(If you don't maintain your own distro then a simpler approach may be
just to set the required TUNE_CCARGS etc directly from your machine
config file).


I'll rework this patch against master and resend for OE and we'll keep 
also the tunes in our layer 
(http://git.yoctoproject.org/cgit/cgit.cgi/meta-axxia/) for jethro branch.


Thanks Andre!




   # Big Endian
   AVAILTUNES += "armv7ab armv7atb armv7ab-vfpv3d16 armv7atb-vfpv3d16
armv7ab-vfpv3 armv7atb-vfpv3 armv7ab-neon armv7atb-neon"
diff --git a/meta/conf/machine/include/arm/arch-armv8a.inc
b/meta/conf/machine/include/arm/arch-armv8a.inc
new file mode 100644
index 000..2d8dd73
--- /dev/null
+++ b/meta/conf/machine/include/arm/arch-armv8a.inc
@@ -0,0 +1,75 @@
+DEFAULTTUNE ?= "armv8a"
+
+TUNEVALID[armv8a] = "Enable instructions for ARMv8-a"
+TUNECONFLICTS[armv8a] = "armv4 armv5 armv6 armv7 armv7a"
+
+TUNEVALID[crc] = "Enable CRC instrucitons for ARMv8-a"
+ARMPKGSFX_FPU .= "${@bb.utils.contains("TUNE_FEATURES", "crc", "-crc",
"", d)}"
+
+TUNEVALID[crypto] = "Enable ARMv8 crypto extension."
+ARMPKGSFX_FPU .= "${@bb.utils.contains("TUNE_FEATURES", "crypto",
"-crypto", "", d)}"
+
+TUNEVALID[fp-armv8] = "Enable ARMv8 Vector Floating Point unit."
+ARMPKGSFX_FPU .= "${@bb.utils.contains("TUNE_FEATURES", "fp-armv8",
"-fp-armv8", "", d)}"
+
+TUNE_CCARGS .= "${@bb.utils.contains("TUNE_FEATURES", "armv8a",
bb.utils.contains("TUNE_FEATURES", "crc", " -march=armv8-a+crc", "
-march=armv8-a", d), "", d)}"
+
+TUNE_CCARGS .= "${@bb.utils.contains("TUNE_FEATURES", "fp-armv8",

[OE-core] [meta-intel][master][jethro][PATCH 1/1] tune-corei7.inc: Fix PACKAGE_EXTRA_ARCHS for corei7-32

[Anuj Mittal]

From: Chang Rebecca Swee Fun 

Change the name to core2-32 from core2.

There's no AVAILTUNES with the name core2. Make sure that we specify
the correct TUNE name so PACKAGE_EXTRA_ARCHS is expanded correctly.

[ YOCTO #9197 ]

Signed-off-by: Chang Rebecca Swee Fun 
Signed-off-by: Anuj Mittal 
---
 meta/conf/machine/include/tune-corei7.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/conf/machine/include/tune-corei7.inc 
b/meta/conf/machine/include/tune-corei7.inc
index 153a21b..6edfb68 100644
--- a/meta/conf/machine/include/tune-corei7.inc
+++ b/meta/conf/machine/include/tune-corei7.inc
@@ -21,7 +21,7 @@ AVAILTUNES += "corei7-32"
 TUNE_FEATURES_tune-corei7-32 = "${TUNE_FEATURES_tune-x86} corei7"
 BASE_LIB_tune-corei7-32 = "lib"
 TUNE_PKGARCH_tune-corei7-32 = "corei7-32"
-PACKAGE_EXTRA_ARCHS_tune-corei7-32 = "${PACKAGE_EXTRA_ARCHS_tune-core2} 
corei7-32"
+PACKAGE_EXTRA_ARCHS_tune-corei7-32 = "${PACKAGE_EXTRA_ARCHS_tune-core2-32} 
corei7-32"
 QEMU_EXTRAOPTIONS_corei7-32 = " -cpu Nehalem,check=false"
 
 AVAILTUNES += "corei7-64"
-- 
1.9.1

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

[OE-core] [meta-intel][master][jethro][PATCH 0/1] Fix tune name in tune-corei7.inc

[Anuj Mittal]

There's no AVAILTUNES with the name "core2" while tune-corei7.inc seems to
have a reference to it.

$ grep -r core2 tune-corei7.inc
require conf/machine/include/tune-core2.inc
PACKAGE_EXTRA_ARCHS_tune-corei7-32 = "${PACKAGE_EXTRA_ARCHS_tune-core2} 
corei7-32"

$ grep -r AVAILTUNES tune-core2.inc
AVAILTUNES += "core2-32"
AVAILTUNES += "core2-64"
AVAILTUNES += "core2-64-x32"

This patch changes the name of tune in tune-corei7.inc so PACKAGE_EXTRA_ARCHS
is expanded correctly.

Please consider backporting it to Jethro too.

Thank you,

Chang Rebecca Swee Fun (1):
  tune-corei7.inc: Fix PACKAGE_EXTRA_ARCHS for corei7-32

 meta/conf/machine/include/tune-corei7.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
1.9.1

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

Re: [OE-core] How to integrate third party application software to yocto image

[winiston]

Hi,

I am new to this community.What does mean top post? Please see my 
bblayers.conf file content.


# LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf
# changes incompatibly
LCONF_VERSION = "6"

BBPATH = "${TOPDIR}"
BBFILES ?= ""

BBLAYERS ?= " \
 /home/winiston/poky/meta \
 /home/winiston/poky/meta-yocto \
 /home/winiston/poky/meta-yocto-bsp \
 /home/winiston/poky/meta-ti \
 /home/winiston/poky/meta-oe \
 /home/winiston/poky/meta-multimedia \
 /home/winiston/poky/meta-qt5 \
 "
BBLAYERS_NON_REMOVABLE ?= " \
 /home/winiston/poky/meta \
 /home/winiston/poky/meta-yocto \
 "
#added by hob
BBFILES += "${TOPDIR}/recipes/images/custom/*.bb"
#added by hob
BBFILES += "${TOPDIR}/recipes/images/*.bb"


I have copied  meta-oe , meta-multimedia and meta-qt5 from meta-openembedded 
to  /home/winiston/poky.


It spits out the same error. Log output as given below.

winiston@winiston-VirtualBox:~/poky/build$ bitbake core-image-base
Parsing recipes: 100% || Time: 19:17:59
Parsing of 1760 .bb files complete (0 cached, 1760 parsed). 2285 targets, 
196 skipped, 0 masked, 0 errors.

NOTE: Resolving any missing task queue dependencies
ERROR: Nothing RPROVIDES 'navit' (but 
/home/winiston/poky/meta/recipes-core/images/core-image-base.bb RDEPENDS on 
or otherwise requires it)
ERROR: navit was skipped: Recipe is blacklisted: bluez5 conflicts with 
bluez4 and bluez5 is selected in DISTRO_FEATURES

NOTE: Runtime target 'navit' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['navit']
ERROR: Required build target 'core-image-base' has no buildable providers.
Missing or unbuildable dependency chain was: ['core-image-base', 'navit']

Summary: There were 2 ERROR messages shown, returning a non-zero exit code.
winiston@winiston-VirtualBox:~/poky/build$


1. What could be the problem? Since I could not proceed my project, Kindly 
help me to solve this issue.




Regards,
Winiston.P
Futura Automation Pvt Ltd.

Ph :91-80-28375290 / 28375295
Fax :91-80-28375291
-Original Message- 
From: Anders Darander

Sent: Friday, February 26, 2016 3:03 PM
To: openembedded-core@lists.openembedded.org ; yocto texas ; Yocto layer
Subject: Re: [OE-core] How to integrate third party application software to 
yocto image


Hi,

Please, don't top post.

* winis...@futuraautomation.com  [160226 
06:41]:
I copied "recipes-navigation" folder from meta-oe (Open embedded build 
tree) to "/poky/meta "



I have appended  in “conf/local.conf”  as given below



IMAGE_INSTALL_append = " navit"



While creating the image, it spits out the following error,



winiston@winiston-VirtualBox:~/poky/build$ bitbake qt4e-demo-image
Loading cache: 100% |##| ETA:  00:00:00
Loaded 1510 entries from dependency cache.
NOTE: Resolving any missing task queue dependencies
ERROR: Nothing RPROVIDES 'navit' (but 
/home/winiston/poky/meta/recipes-qt/images/qt4e-demo-image.bb RDEPENDS on 
or otherwise requires it)
ERROR: navit was skipped: Recipe is blacklisted: bluez5 conflicts with 
bluez4 and bluez5 is selected in DISTRO_FEATURES


This is the error. You have bluez5 in your DITRO_FEATURES, and I assume
that navit requires bluez4? Anywya, it's blacklisted.


NOTE: Runtime target 'navit' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['navit']
ERROR: Required build target 'qt4e-demo-image' has no buildable providers.
Missing or unbuildable dependency chain was: ['qt4e-demo-image', 'navit']


Summary: There were 2 ERROR messages shown, returning a non-zero exit 
code.

winiston@winiston-VirtualBox:~/poky/build$



Should I make any other setting to add the “navit” recipe to my image?
Is this the correct method of copying  "recipes-navigation" folder  to
"/poky/meta "  ?


Well, it works. If you don't mind the rest of meta-oe, I'd rather add
that layer to conf/bblayers.conf. That would make it easier to get
updates to e.g. navit.

Cheers,
Anders

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


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