[OE-core] [PATCH 1/2] gstreamer1.0-plugins-bad: Upgrade to 1.8.1

[Khem Raj]

Signed-off-by: Khem Raj 
---
 .../gstreamer/gstreamer1.0-plugins-bad_1.6.3.bb| 28 
 .../gstreamer/gstreamer1.0-plugins-bad_1.8.1.bb| 52 ++
 2 files changed, 52 insertions(+), 28 deletions(-)
 delete mode 100644 
meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.6.3.bb
 create mode 100644 
meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.8.1.bb

diff --git 
a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.6.3.bb 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.6.3.bb
deleted file mode 100644
index 8eb47c2..000
--- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.6.3.bb
+++ /dev/null
@@ -1,28 +0,0 @@
-include gstreamer1.0-plugins-bad.inc
-
-LIC_FILES_CHKSUM = "file://COPYING;md5=73a5855a8119deb017f5f13cf327095d \
-file://COPYING.LIB;md5=21682e4e8fea52413fd26c60acb907e5 \
-
file://gst/tta/crc32.h;beginline=12;endline=29;md5=27db269c575d1e5317fffca2d33b3b50
 \
-
file://gst/tta/filters.h;beginline=12;endline=29;md5=8a08270656f2f8ad7bb3655b83138e5a"
-
-# Note: The mpg123 plugin was moved to gst-plugins-ugly prior to the 1.7.2
-# release, so this line should be removed during the update to 1.8.x
-# 
https://cgit.freedesktop.org/gstreamer/gst-plugins-bad/commit/?id=08d8aefcdaaf89ecb6dd53ec1e4f95cd42d01664
-PACKAGECONFIG[mpg123] = "--enable-mpg123,--disable-mpg123,mpg123"
-
-# Note: The gsettings plug-in was dropped prior to the 1.7.2 release,
-# so this line should be removed during the update to 1.8.x
-# 
https://cgit.freedesktop.org/gstreamer/gst-plugins-bad/commit/?id=914291808ad10621d6a74031f3d46d45eef5a3a3
-EXTRA_OECONF += "--disable-gsettings"
-
-SRC_URI = " \
-
http://gstreamer.freedesktop.org/src/gst-plugins-bad/gst-plugins-bad-${PV}.tar.xz
 \
-file://configure-allow-to-disable-libssh2.patch \
-file://0001-glimagesink-Downrank-to-marginal.patch \
-file://0002-glplugin-glwindow-fix-memory-leak-of-navigation-thre.patch \
-"
-
-SRC_URI[md5sum] = "4857adcafe41e4b9b8805cf88303bd55"
-SRC_URI[sha256sum] = 
"971b29101d6a9c5e3fe94d99d977a227f58f0b2d29b6ca2c7f292052542b3a61"
-
-S = "${WORKDIR}/gst-plugins-bad-${PV}"
diff --git 
a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.8.1.bb 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.8.1.bb
new file mode 100644
index 000..a240bcb
--- /dev/null
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.8.1.bb
@@ -0,0 +1,52 @@
+include gstreamer1.0-plugins-bad.inc
+
+LIC_FILES_CHKSUM = "file://COPYING;md5=73a5855a8119deb017f5f13cf327095d \
+file://COPYING.LIB;md5=21682e4e8fea52413fd26c60acb907e5 \
+
file://gst/tta/crc32.h;beginline=12;endline=29;md5=27db269c575d1e5317fffca2d33b3b50
 \
+
file://gst/tta/filters.h;beginline=12;endline=29;md5=8a08270656f2f8ad7bb3655b83138e5a"
+
+SRC_URI = " \
+
http://gstreamer.freedesktop.org/src/gst-plugins-bad/gst-plugins-bad-${PV}.tar.xz
 \
+file://configure-allow-to-disable-libssh2.patch \
+file://fix-maybe-uninitialized-warnings-when-compiling-with-Os.patch \
+file://avoid-including-sys-poll.h-directly.patch \
+file://ensure-valid-sentinels-for-gst_structure_get-etc.patch \
+file://0001-gstreamer-gl.pc.in-don-t-append-GL_CFLAGS-to-CFLAGS.patch \
+"
+SRC_URI[md5sum] = "e508da2a8a5c3d12264fe3415be2f451"
+SRC_URI[sha256sum] = 
"0bbd58f363734fc0c4a620b2d6fb01d427fdafdbda7b90b4e15d03b751ca40f5"
+
+S = "${WORKDIR}/gst-plugins-bad-${PV}"
+
+# over-ride the default hls PACKAGECONFIG in gstreamer1.0-plugins-bad.inc to
+# pass an additional --with-hls-crypto=XXX option (new in 1.7.x) and switch HLS
+# AES decryption from nettle to openssl (ie a shared dependency with dtls).
+# This should move back to the common .inc once the main recipe updates to 
1.8.x
+PACKAGECONFIG[hls] = "--enable-hls 
--with-hls-crypto=openssl,--disable-hls,openssl"
+
+# The tinyalsa plugin was added prior to the 1.7.2 release
+# 
https://cgit.freedesktop.org/gstreamer/gst-plugins-bad/commit/?id=c8bd74fa9a81398f57d976c478d2043f30188684
+PACKAGECONFIG[tinyalsa] = "--enable-tinyalsa,--disable-tinyalsa,tinyalsa"
+
+# The vulkan based video sink plugin was added prior to the 1.7.2 release
+# 
https://cgit.freedesktop.org/gstreamer/gst-plugins-bad/commit/?id=5de6dd9f40629562acf90e35e1fa58464d66617d
+PACKAGECONFIG[vulkan] = "--enable-vulkan,--disable-vulkan,libxcb"
+
+# The dependency-less netsim plugin was added prior to the 1.7.2 release
+# 
https://cgit.freedesktop.org/gstreamer/gst-plugins-bad/commit/?id=e3f9e854f08e82bfab11182c5a2aa6f9a0c73cd5
+EXTRA_OECONF += " \
+--enable-netsim \
+"
+
+# In 1.6.2, the "--enable-hls" configure option generated an installable 
package
+# called "gstreamer1.0-plugins-bad-fragmented". In 1.7.1 that HLS plugin 
package
+# has become "gstreamer1.0-plugins-bad-hls". See:
+# 

[OE-core] [PATCH 2/2] gstreamer1.0-plugins-ugly: Add mpg123 PACKAGECONFIG

[Khem Raj]

mpg123 plugin moved from bad collection to ugly in 1.8
since mpg123 has commercial licence implications its best
to keep it with a knob.

Signed-off-by: Khem Raj 
---
 meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-ugly_1.8.1.bb | 2 ++
 1 file changed, 2 insertions(+)

diff --git 
a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-ugly_1.8.1.bb 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-ugly_1.8.1.bb
index 7c0d206..137f535 100644
--- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-ugly_1.8.1.bb
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-ugly_1.8.1.bb
@@ -11,3 +11,5 @@ SRC_URI[md5sum] = "b6f47bcb3d924f7ef8a8b33ac4d037ab"
 SRC_URI[sha256sum] = 
"8e656a9a3be60d7e7ed3fb8e2a22d070b1f54f95d0b22accd876360e659446ce"
 
 S = "${WORKDIR}/gst-plugins-ugly-${PV}"
+
+PACKAGECONFIG[mpg123] = "--enable-mpg123,--disable-mpg123,mpg123"
-- 
2.8.3

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

Re: [OE-core] [PATCH 3/4] systemd-bootchart: add recipe

[Khem Raj]

> On Jun 16, 2016, at 8:36 PM, Chen Qi  wrote:
> 
> Signed-off-by: Chen Qi 
> ---
> .../systemd-bootchart/systemd-bootchart_230.bb | 30 ++
> 1 file changed, 30 insertions(+)
> create mode 100644 
> meta/recipes-devtools/systemd-bootchart/systemd-bootchart_230.bb
> 
> diff --git a/meta/recipes-devtools/systemd-bootchart/systemd-bootchart_230.bb 
> b/meta/recipes-devtools/systemd-bootchart/systemd-bootchart_230.bb
> new file mode 100644
> index 000..7c135cb
> --- /dev/null
> +++ b/meta/recipes-devtools/systemd-bootchart/systemd-bootchart_230.bb
> @@ -0,0 +1,30 @@
> +LICENSE = "LGPLv2.1 & GPLv2"
> +LIC_FILES_CHKSUM = 
> "file://LICENSE.LGPL2.1;md5=4fbd65380cdd255951079008b364516c \
> +file://LICENSE.GPL2;md5=751419260aa954499f7abaabaa882bbe"
> +
> +SRC_URI = "git://github.com/systemd/systemd-bootchart.git;protocol=https"
> +
> +# Modify these as desired
> +PV = "230+git${SRCPV}"
> +SRCREV = "dcb246b46239259ec99b3c6e6ab7d27e1a5a8a84"
> +
> +S = "${WORKDIR}/git"
> +
> +DEPENDS = "libxslt-native libxslt-native xmlto-native 
> docbook-xml-dtd4-native docbook-xsl-stylesheets-native intltool"
> +RDEPENDS_${PN} += "systemd"
> +
> +inherit pkgconfig autotools systemd
> +
> +SYSTEMD_SERVICE_${PN} = "systemd-bootchart.service"
> +SYSTEMD_AUTO_ENABLE_${PN} = “disable"

why disable the service by default

> +
> +do_configure_prepend() {
> +# intltool.m4 is a soft link to /usr/share/aclocal/m4, delete it and use 
> the one in our sysroot
> +rm ${S}/m4/intltool.m4
> +cp ${STAGING_DIR_TARGET}${datadir}/aclocal/intltool.m4 
> ${S}/m4/intltool.m4
> +}
> +
> +FILES_${PN} += "${systemd_unitdir}/systemd-bootchart"
> +
> +EXTRA_OECONF = " --with-rootprefix=${base_prefix} \
> + --with-rootlibdir=${base_libdir}"
> --
> 1.9.1
> 
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core



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

Re: [OE-core] [PATCH 2/4] systemd: upgrade to 230

[Khem Raj]

> On Jun 16, 2016, at 8:36 PM, Chen Qi  wrote:
> 
> diff --git a/meta/recipes-core/systemd/systemd_229.bb 
> b/meta/recipes-core/systemd/systemd_230.bb
> similarity index 99%
> rename from meta/recipes-core/systemd/systemd_229.bb
> rename to meta/recipes-core/systemd/systemd_230.bb
> index 4b726f3..9afdfa8 100644
> --- a/meta/recipes-core/systemd/systemd_229.bb
> +++ b/meta/recipes-core/systemd/systemd_230.bb
> @@ -35,7 +35,6 @@ SRC_URI += " \
>file://0020-check-for-uchar.h-in-configure.patch \
>
> file://0021-include-missing.h-for-getting-secure_getenv-definiti.patch \
>
> file://0022-socket-util-don-t-fail-if-libc-doesn-t-support-IDN.patch \
> -   file://0023-build-sys-fix-build-with-libgrcypt-disabled.patch \
>file://udev-re-enable-mount-propagation-for-udevd.patch \
> "

0023* patch is removed from SRC_URI but not deleted.


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

[OE-core] [PATCH 2/4] systemd: upgrade to 230

[Chen Qi]

Patches are rebased or removed for the latest version.

'python' is added to RDEPENDS of systemd-ptest.

systemd-bootchart is now seprated from systemd, thus removing the
related configuration items.

Signed-off-by: Chen Qi 
---
 meta/recipes-core/systemd/systemd.inc  |  4 +-
 .../systemd/0003-define-exp10-if-missing.patch | 15 +++--
 ...4-Make-root-s-home-directory-configurable.patch | 62 ++--
 ...0015-systemd-user-avoid-using-system-auth.patch | 13 ++---
 ...-remove-userspace-firmware-loading-suppor.patch | 68 +-
 .../systemd/0018-make-test-dir-configurable.patch  | 32 +-
 .../systemd/{systemd_229.bb => systemd_230.bb} |  5 +-
 7 files changed, 90 insertions(+), 109 deletions(-)
 rename meta/recipes-core/systemd/{systemd_229.bb => systemd_230.bb} (99%)

diff --git a/meta/recipes-core/systemd/systemd.inc 
b/meta/recipes-core/systemd/systemd.inc
index 8247130..f800f42 100644
--- a/meta/recipes-core/systemd/systemd.inc
+++ b/meta/recipes-core/systemd/systemd.inc
@@ -14,11 +14,11 @@ LICENSE = "GPLv2 & LGPLv2.1"
 LIC_FILES_CHKSUM = "file://LICENSE.GPL2;md5=751419260aa954499f7abaabaa882bbe \
 
file://LICENSE.LGPL2.1;md5=4fbd65380cdd255951079008b364516c"
 
-SRCREV = "714c62b46379abb7558c544665522aca91691e10"
+SRCREV = "3a74d4fc90cb322a4784a3515bef7118c8f8c5ba"
 
 SRC_URI = "git://github.com/systemd/systemd.git;protocol=git"
 
-PV = "229+git${SRCPV}"
+PV = "230+git${SRCPV}"
 
 S = "${WORKDIR}/git"
 
diff --git 
a/meta/recipes-core/systemd/systemd/0003-define-exp10-if-missing.patch 
b/meta/recipes-core/systemd/systemd/0003-define-exp10-if-missing.patch
index f183261..e62d580 100644
--- a/meta/recipes-core/systemd/systemd/0003-define-exp10-if-missing.patch
+++ b/meta/recipes-core/systemd/systemd/0003-define-exp10-if-missing.patch
@@ -1,6 +1,3 @@
-From 699893a05edac5194f9670529bacfaeb67252edb Mon Sep 17 00:00:00 2001
-From: Khem Raj 
-Date: Mon, 14 Dec 2015 00:42:49 +
 Subject: [PATCH 03/36] define exp10 if missing
 
 Inspired by: 
http://peter.korsgaard.com/patches/alsa-utils/alsamixer-fix-build-on-uClibc-exp10.patch
@@ -11,23 +8,25 @@ Upstream-Status: Pending
 
 Signed-off-by: Samuel Martin 
 Signed-off-by: Khem Raj 
+
 ---
  src/basic/missing.h | 5 +
  1 file changed, 5 insertions(+)
 
 diff --git a/src/basic/missing.h b/src/basic/missing.h
-index f3d3236..ee7e7ea 100644
+index 651e414..fafa233 100644
 --- a/src/basic/missing.h
 +++ b/src/basic/missing.h
-@@ -1169,3 +1169,8 @@ static inline key_serial_t request_key(const char *type, 
const char *description
- #endif
+@@ -1013,4 +1013,9 @@ typedef int32_t key_serial_t;
  
  #endif
-+
+ 
 +#ifdef __UCLIBC__
 +/* 10^x = 10^(log e^x) = (e^x)^log10 = e^(x * log 10) */
 +#define exp10(x) (exp((x) * log(10)))
 +#endif /* __UCLIBC__ */
++
+ #include "missing_syscall.h"
 -- 
-1.8.3.1
+2.8.3
 
diff --git 
a/meta/recipes-core/systemd/systemd/0014-Make-root-s-home-directory-configurable.patch
 
b/meta/recipes-core/systemd/systemd/0014-Make-root-s-home-directory-configurable.patch
index 4a576aa..2eea0ff 100644
--- 
a/meta/recipes-core/systemd/systemd/0014-Make-root-s-home-directory-configurable.patch
+++ 
b/meta/recipes-core/systemd/systemd/0014-Make-root-s-home-directory-configurable.patch
@@ -1,6 +1,3 @@
-From 786883cfa13e21f060ee6da6cabb94845f4349a0 Mon Sep 17 00:00:00 2001
-From: Khem Raj 
-Date: Mon, 14 Dec 2015 05:18:20 +
 Subject: [PATCH 14/36] Make root's home directory configurable
 
 OpenEmbedded has a configurable home directory for root. Allow
@@ -14,6 +11,7 @@ https://github.com/systemd/systemd/issues/541
 
 Signed-off-by: Dan McGregor 
 Signed-off-by: Khem Raj 
+
 ---
  Makefile.am   | 2 ++
  configure.ac  | 7 +++
@@ -26,10 +24,10 @@ Signed-off-by: Khem Raj 
  8 files changed, 20 insertions(+), 11 deletions(-)
 
 diff --git a/Makefile.am b/Makefile.am
-index b3f3343..a99e8eb 100644
+index 305099a..88c1250 100644
 --- a/Makefile.am
 +++ b/Makefile.am
-@@ -202,6 +202,7 @@ AM_CPPFLAGS = \
+@@ -206,6 +206,7 @@ AM_CPPFLAGS = \
-DLIBDIR=\"$(libdir)\" \
-DROOTLIBDIR=\"$(rootlibdir)\" \
-DROOTLIBEXECDIR=\"$(rootlibexecdir)\" \
@@ -37,7 +35,7 @@ index b3f3343..a99e8eb 100644
-DTEST_DIR=\"$(abs_top_srcdir)/test\" \
-I $(top_srcdir)/src \
-I $(top_builddir)/src/basic \
-@@ -5713,6 +5714,7 @@ EXTRA_DIST += \
+@@ -5863,6 +5864,7 @@ EXTRA_DIST += \
  substitutions = \
 '|rootlibexecdir=$(rootlibexecdir)|' \
 '|rootbindir=$(rootbindir)|' \
@@ -46,10 +44,10 @@ index b3f3343..a99e8eb 100644
 '|SYSTEMCTL=$(rootbindir)/systemctl|' \
 '|SYSTEMD_NOTIFY=$(rootbindir)/systemd-notify|' \
 diff --git a/configure.ac b/configure.ac
-index c5ab9d0..16c83bb 100644
+index 329861a..01764f5 100644
 --- 

[OE-core] [PATCH 1/4] dbus/dbus-test: upgrade to 1.10.8

[Chen Qi]

0001-configure.ac-support-large-file-for-stat64.patch is removed as it's
a backported patch and is already in the latest codes.

Signed-off-by: Chen Qi 
---
 .../{dbus-test_1.10.6.bb => dbus-test_1.10.8.bb}   |  4 +-
 ...onfigure.ac-support-large-file-for-stat64.patch | 53 --
 .../dbus/{dbus_1.10.6.bb => dbus_1.10.8.bb}|  5 +-
 3 files changed, 4 insertions(+), 58 deletions(-)
 rename meta/recipes-core/dbus/{dbus-test_1.10.6.bb => dbus-test_1.10.8.bb} 
(93%)
 delete mode 100644 
meta/recipes-core/dbus/dbus/0001-configure.ac-support-large-file-for-stat64.patch
 rename meta/recipes-core/dbus/{dbus_1.10.6.bb => dbus_1.10.8.bb} (96%)

diff --git a/meta/recipes-core/dbus/dbus-test_1.10.6.bb 
b/meta/recipes-core/dbus/dbus-test_1.10.8.bb
similarity index 93%
rename from meta/recipes-core/dbus/dbus-test_1.10.6.bb
rename to meta/recipes-core/dbus/dbus-test_1.10.8.bb
index af99976..87dcd37 100644
--- a/meta/recipes-core/dbus/dbus-test_1.10.6.bb
+++ b/meta/recipes-core/dbus/dbus-test_1.10.8.bb
@@ -17,8 +17,8 @@ SRC_URI = 
"http://dbus.freedesktop.org/releases/dbus/dbus-${PV}.tar.gz \
file://clear-guid_from_server-if-send_negotiate_unix_f.patch \
"
 
-SRC_URI[md5sum] = "26d0cf3a1c9782cb0e342101f0450440"
-SRC_URI[sha256sum] = 
"b5fefa08a77edd76cd64d872db949eebc02cf6f3f8be82e4bbc641742af5d35f"
+SRC_URI[md5sum] = "e912e930f249454752512aa7ac864d43"
+SRC_URI[sha256sum] = 
"baf3d22baa26d3bdd9edc587736cd5562196ce67996d65b82103bedbe1f0c014"
 
 S="${WORKDIR}/dbus-${PV}"
 FILESEXTRAPATHS =. "${FILE_DIRNAME}/dbus:"
diff --git 
a/meta/recipes-core/dbus/dbus/0001-configure.ac-support-large-file-for-stat64.patch
 
b/meta/recipes-core/dbus/dbus/0001-configure.ac-support-large-file-for-stat64.patch
deleted file mode 100644
index c6eac2b..000
--- 
a/meta/recipes-core/dbus/dbus/0001-configure.ac-support-large-file-for-stat64.patch
+++ /dev/null
@@ -1,53 +0,0 @@
-From e18bd3a571be716d90bedc835a014472470ae7bd Mon Sep 17 00:00:00 2001
-From: Hongxu Jia 
-Date: Wed, 30 Dec 2015 10:58:39 +0800
-Subject: [PATCH] configure.ac: support large-file for stat64
-
-While starting dbus-daemon on a 32-bit linux host and it invokes
-fstat to load /etc/dbus-1/system.conf through NFS. If system.conf
-was created with a large indoe number on 64-bit host. The above
-fstat invoking failed. Here is the log of strace:
-
-$ ls -i /etc/dbus-1/system.conf
-53778558109 /etc/dbus-1/system.conf
-
-$ strace /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile 
--systemd-activation
-|open("/etc/dbus-1/system.conf", O_RDONLY) = 4
-|fstat64(4, {st_mode=S_IFREG|0644, st_size=3340, ...}) = 0
-|close(4) = 0
-|close(3) = 0
-|write(2, "Failed to start message bus: Fai"..., 109Failed to start message 
bus:
-Failed to stat "/etc/dbus-1/system.conf": Value too large for defined data type
-|) = 109
-|exit_group(1) = ?
-|+++ exited with 1 +++
-
-
-In this situation, we should support large-file for stat64. Add marco
-AC_SYS_LARGEFILE to do the detection at configure time. It can be disabled
-by configuring with the `--disable-largefile' option.
-
-Upstream-Status: Backport
-
-Bug: https://bugs.freedesktop.org/show_bug.cgi?id=93545
-https://bugs.freedesktop.org/attachment.cgi?id=120747
-Signed-off-by: Hongxu Jia 

- configure.ac | 1 +
- 1 file changed, 1 insertion(+)
-
-diff --git a/configure.ac b/configure.ac
-index 82806ba..cb5a60b 100644
 a/configure.ac
-+++ b/configure.ac
-@@ -64,6 +64,7 @@ AC_SUBST(DBUS_VERSION)
- AC_PROG_CC
- AM_PROG_CC_C_O
- AC_PROG_CXX
- AC_USE_SYSTEM_EXTENSIONS
-+AC_SYS_LARGEFILE
- AC_ISC_POSIX
- AC_HEADER_STDC
--- 
-1.9.1
-
diff --git a/meta/recipes-core/dbus/dbus_1.10.6.bb 
b/meta/recipes-core/dbus/dbus_1.10.8.bb
similarity index 96%
rename from meta/recipes-core/dbus/dbus_1.10.6.bb
rename to meta/recipes-core/dbus/dbus_1.10.8.bb
index 245798a..bfaf65a 100644
--- a/meta/recipes-core/dbus/dbus_1.10.6.bb
+++ b/meta/recipes-core/dbus/dbus_1.10.8.bb
@@ -17,11 +17,10 @@ SRC_URI = 
"http://dbus.freedesktop.org/releases/dbus/dbus-${PV}.tar.gz \
file://dbus-1.init \
file://os-test.patch \
file://clear-guid_from_server-if-send_negotiate_unix_f.patch \
-   file://0001-configure.ac-support-large-file-for-stat64.patch \
 "
 
-SRC_URI[md5sum] = "26d0cf3a1c9782cb0e342101f0450440"
-SRC_URI[sha256sum] = 
"b5fefa08a77edd76cd64d872db949eebc02cf6f3f8be82e4bbc641742af5d35f"
+SRC_URI[md5sum] = "e912e930f249454752512aa7ac864d43"
+SRC_URI[sha256sum] = 
"baf3d22baa26d3bdd9edc587736cd5562196ce67996d65b82103bedbe1f0c014"
 
 inherit useradd autotools pkgconfig gettext update-rc.d 
upstream-version-is-even
 
-- 
1.9.1

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

[OE-core] [PATCH 3/4] systemd-bootchart: add recipe

[Chen Qi]

Signed-off-by: Chen Qi 
---
 .../systemd-bootchart/systemd-bootchart_230.bb | 30 ++
 1 file changed, 30 insertions(+)
 create mode 100644 
meta/recipes-devtools/systemd-bootchart/systemd-bootchart_230.bb

diff --git a/meta/recipes-devtools/systemd-bootchart/systemd-bootchart_230.bb 
b/meta/recipes-devtools/systemd-bootchart/systemd-bootchart_230.bb
new file mode 100644
index 000..7c135cb
--- /dev/null
+++ b/meta/recipes-devtools/systemd-bootchart/systemd-bootchart_230.bb
@@ -0,0 +1,30 @@
+LICENSE = "LGPLv2.1 & GPLv2"
+LIC_FILES_CHKSUM = 
"file://LICENSE.LGPL2.1;md5=4fbd65380cdd255951079008b364516c \
+file://LICENSE.GPL2;md5=751419260aa954499f7abaabaa882bbe"
+
+SRC_URI = "git://github.com/systemd/systemd-bootchart.git;protocol=https"
+
+# Modify these as desired
+PV = "230+git${SRCPV}"
+SRCREV = "dcb246b46239259ec99b3c6e6ab7d27e1a5a8a84"
+
+S = "${WORKDIR}/git"
+
+DEPENDS = "libxslt-native libxslt-native xmlto-native docbook-xml-dtd4-native 
docbook-xsl-stylesheets-native intltool"
+RDEPENDS_${PN} += "systemd"
+
+inherit pkgconfig autotools systemd
+
+SYSTEMD_SERVICE_${PN} = "systemd-bootchart.service"
+SYSTEMD_AUTO_ENABLE_${PN} = "disable"
+
+do_configure_prepend() {
+# intltool.m4 is a soft link to /usr/share/aclocal/m4, delete it and use 
the one in our sysroot
+rm ${S}/m4/intltool.m4
+cp ${STAGING_DIR_TARGET}${datadir}/aclocal/intltool.m4 ${S}/m4/intltool.m4
+}
+
+FILES_${PN} += "${systemd_unitdir}/systemd-bootchart"
+
+EXTRA_OECONF = " --with-rootprefix=${base_prefix} \
+ --with-rootlibdir=${base_libdir}"
-- 
1.9.1

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

[OE-core] [PATCH 0/4] Upgrade systemd, dbus and util-linux

[Chen Qi]

===


Note that I've removed ptest support for util-linux because the codes have 
changed a lot.
If you think that ptest support is necessary for util-linux, I'll try to add it 
back for the new version.


===


The following changes since commit 7c1f1fc3d739d778886208d6833c34e6ca1dc148:

  build-appliance-image: Add LC_ALL setting and drop pseudo pieces (2016-06-16 
22:43:57 +0100)

are available in the git repository at:

  git://git.openembedded.org/openembedded-core-contrib ChenQi/PU-20160617
  
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=ChenQi/PU-20160617

Chen Qi (4):
  dbus/dbus-test: upgrade to 1.10.8
  systemd: upgrade to 230
  systemd-bootchart: add recipe
  util-linux: upgrade to 2.28

 .../{dbus-test_1.10.6.bb => dbus-test_1.10.8.bb}   |  4 +-
 ...onfigure.ac-support-large-file-for-stat64.patch | 53 -
 .../dbus/{dbus_1.10.6.bb => dbus_1.10.8.bb}|  5 +-
 meta/recipes-core/systemd/systemd.inc  |  4 +-
 .../systemd/0003-define-exp10-if-missing.patch | 15 ++--
 ...4-Make-root-s-home-directory-configurable.patch | 62 +++
 ...0015-systemd-user-avoid-using-system-auth.patch | 13 ++-
 ...-remove-userspace-firmware-loading-suppor.patch | 68 +++-
 .../systemd/0018-make-test-dir-configurable.patch  | 32 
 .../systemd/{systemd_229.bb => systemd_230.bb} |  5 +-
 meta/recipes-core/util-linux/util-linux.inc| 31 +---
 .../util-linux/avoid_parallel_tests.patch  | 19 -
 .../util-linux/avoid_unsupported_grep_opts.patch   | 57 --
 .../util-linux/avoid_unsupported_sleep_param.patch | 20 -
 .../util-linux/display_testname_for_subtest.patch  | 18 -
 .../recipes-core/util-linux/util-linux/ptest.patch | 17 
 meta/recipes-core/util-linux/util-linux/run-ptest  | 25 --
 .../util-linux/util-linux/util-linux-native.patch  | 57 --
 .../util-linux-ng-2.16-mount_lock_path.patch   | 27 ---
 .../util-linux/uuid-test-error-api.patch   | 92 --
 .../{util-linux_2.27.1.bb => util-linux_2.28.bb}   | 20 ++---
 .../systemd-bootchart/systemd-bootchart_230.bb | 30 +++
 22 files changed, 130 insertions(+), 544 deletions(-)
 rename meta/recipes-core/dbus/{dbus-test_1.10.6.bb => dbus-test_1.10.8.bb} 
(93%)
 delete mode 100644 
meta/recipes-core/dbus/dbus/0001-configure.ac-support-large-file-for-stat64.patch
 rename meta/recipes-core/dbus/{dbus_1.10.6.bb => dbus_1.10.8.bb} (96%)
 rename meta/recipes-core/systemd/{systemd_229.bb => systemd_230.bb} (99%)
 delete mode 100644 
meta/recipes-core/util-linux/util-linux/avoid_parallel_tests.patch
 delete mode 100644 
meta/recipes-core/util-linux/util-linux/avoid_unsupported_grep_opts.patch
 delete mode 100644 
meta/recipes-core/util-linux/util-linux/avoid_unsupported_sleep_param.patch
 delete mode 100644 
meta/recipes-core/util-linux/util-linux/display_testname_for_subtest.patch
 delete mode 100644 meta/recipes-core/util-linux/util-linux/ptest.patch
 delete mode 100644 meta/recipes-core/util-linux/util-linux/run-ptest
 delete mode 100644 
meta/recipes-core/util-linux/util-linux/util-linux-native.patch
 delete mode 100644 
meta/recipes-core/util-linux/util-linux/util-linux-ng-2.16-mount_lock_path.patch
 delete mode 100644 
meta/recipes-core/util-linux/util-linux/uuid-test-error-api.patch
 rename meta/recipes-core/util-linux/{util-linux_2.27.1.bb => 
util-linux_2.28.bb} (44%)
 create mode 100644 
meta/recipes-devtools/systemd-bootchart/systemd-bootchart_230.bb

-- 
1.9.1

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

[OE-core] [PATCH 4/4] util-linux: upgrade to 2.28

[Chen Qi]

ptest is disabled as the related codes are changed a lot, and the
related patches are removed.

util-linux-ng-2.16-mount_lock_path.patch is removed because there's
no _PATH_MOUNTED_LOCK in the latest codes.

util-linux-native.patch is removed because 2.28 version of util-linux
has taken mkostemp into consideration and provide fallback if mkostemp
fails.

Signed-off-by: Chen Qi 
---
 meta/recipes-core/util-linux/util-linux.inc| 31 +---
 .../util-linux/avoid_parallel_tests.patch  | 19 -
 .../util-linux/avoid_unsupported_grep_opts.patch   | 57 --
 .../util-linux/avoid_unsupported_sleep_param.patch | 20 -
 .../util-linux/display_testname_for_subtest.patch  | 18 -
 .../recipes-core/util-linux/util-linux/ptest.patch | 17 
 meta/recipes-core/util-linux/util-linux/run-ptest  | 25 --
 .../util-linux/util-linux/util-linux-native.patch  | 57 --
 .../util-linux-ng-2.16-mount_lock_path.patch   | 27 ---
 .../util-linux/uuid-test-error-api.patch   | 92 --
 .../{util-linux_2.27.1.bb => util-linux_2.28.bb}   | 20 ++---
 11 files changed, 6 insertions(+), 377 deletions(-)
 delete mode 100644 
meta/recipes-core/util-linux/util-linux/avoid_parallel_tests.patch
 delete mode 100644 
meta/recipes-core/util-linux/util-linux/avoid_unsupported_grep_opts.patch
 delete mode 100644 
meta/recipes-core/util-linux/util-linux/avoid_unsupported_sleep_param.patch
 delete mode 100644 
meta/recipes-core/util-linux/util-linux/display_testname_for_subtest.patch
 delete mode 100644 meta/recipes-core/util-linux/util-linux/ptest.patch
 delete mode 100644 meta/recipes-core/util-linux/util-linux/run-ptest
 delete mode 100644 
meta/recipes-core/util-linux/util-linux/util-linux-native.patch
 delete mode 100644 
meta/recipes-core/util-linux/util-linux/util-linux-ng-2.16-mount_lock_path.patch
 delete mode 100644 
meta/recipes-core/util-linux/util-linux/uuid-test-error-api.patch
 rename meta/recipes-core/util-linux/{util-linux_2.27.1.bb => 
util-linux_2.28.bb} (44%)

diff --git a/meta/recipes-core/util-linux/util-linux.inc 
b/meta/recipes-core/util-linux/util-linux.inc
index c0f2540..c2a5b63 100644
--- a/meta/recipes-core/util-linux/util-linux.inc
+++ b/meta/recipes-core/util-linux/util-linux.inc
@@ -17,7 +17,7 @@ LIC_FILES_CHKSUM = 
"file://README.licensing;md5=1715f5ee3e01203ca1e1e0b9ee65918c
 
file://libmount/COPYING;md5=fb93f01d4361069c5616327705373b16 \
 
file://libblkid/COPYING;md5=fb93f01d4361069c5616327705373b16"
 
-inherit autotools gettext pkgconfig systemd update-alternatives python3-dir 
ptest bash-completion
+inherit autotools gettext pkgconfig systemd update-alternatives python3-dir 
bash-completion
 DEPENDS = "zlib ncurses"
 DEPENDS_append_class-native = " lzo-native"
 DEPENDS_append_class-nativesdk = " lzo-native"
@@ -281,32 +281,3 @@ python populate_packages_prepend() {
   description='util-linux lib%s',
   extra_depends='', prepend=True, allow_links=True)
 }
-
-RDEPENDS_${PN}-ptest = "bash"
-
-do_compile_ptest() {
-oe_runmake buildtest-TESTS
-}
-
-do_install_ptest() {
-mkdir -p ${D}${PTEST_PATH}/tests/ts
-find . -maxdepth 1 -type f -perm -111 -exec cp {} ${D}${PTEST_PATH} \;
-cp ${S}/tests/functions.sh ${D}${PTEST_PATH}/tests/
-cp ${S}/tests/commands.sh ${D}${PTEST_PATH}/tests/
-cp ${S}/tests/run.sh ${D}${PTEST_PATH}/tests/
-cp -pR ${S}/tests/expected ${D}${PTEST_PATH}/tests/expected
-
-list="bitops build-sys cal col colrm column dmesg fsck hexdump hwclock 
ipcs isosize login look md5 misc more namei paths schedutils script swapon 
tailf"
-# The following tests are not installed  yet:
-# blkid scsi_debug module dependent
-# cramfs gcc dependent
-# eject gcc dependent
-# fdisk scsi_debug module and gcc dependent
-# lscpu gcc dependant
-# libmount uuidgen dependent
-# mount gcc dependant
-# partx blkid dependant
-for d in $list; do
-cp -pR ${S}/tests/ts/$d ${D}${PTEST_PATH}/tests/ts/
-done
-}
diff --git a/meta/recipes-core/util-linux/util-linux/avoid_parallel_tests.patch 
b/meta/recipes-core/util-linux/util-linux/avoid_parallel_tests.patch
deleted file mode 100644
index 46d4d37..000
--- a/meta/recipes-core/util-linux/util-linux/avoid_parallel_tests.patch
+++ /dev/null
@@ -1,19 +0,0 @@
-Ptest needs buildtest-TESTS and runtest-TESTS targets.
-serial-tests is required to generate those targets.
-Revert run.sh script accordingly to serialize running tests 
-
-Signed-off-by: Tudor Florea  
-Upstream-Status: Inappropriate 
-
-diff -ruN a/configure.ac b/configure.ac
 a/configure.ac 2014-05-27 12:37:42.119772658 +0200
-+++ b/configure.ac 2014-05-27 12:41:46.225573272 +0200
-@@ -10,7 +10,7 @@
- dnl AC_USE_SYSTEM_EXTENSIONS must be called before any macros that run
- dnl the compiler (like AC_PROG_LIBTOOL) to avoid autoconf 

[OE-core] [PATCH] expat: CVE-2016-0718

[Yi Zhao]

Fix CVE-2016-0718: expat XML parser crashes on malformed input

External References:
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-0718
https://bugzilla.redhat.com/show_bug.cgi?id=1296102
https://bugzilla.suse.com/show_bug.cgi?id=979441

Patch from:
https://bugzilla.redhat.com/show_bug.cgi?id=1296102

Signed-off-by: Yi Zhao 
---
 meta/recipes-core/expat/expat.inc |   1 +
 meta/recipes-core/expat/expat/CVE-2016-0718.patch | 760 ++
 2 files changed, 761 insertions(+)
 create mode 100644 meta/recipes-core/expat/expat/CVE-2016-0718.patch

diff --git a/meta/recipes-core/expat/expat.inc 
b/meta/recipes-core/expat/expat.inc
index fe9d7e7..3d8429c 100644
--- a/meta/recipes-core/expat/expat.inc
+++ b/meta/recipes-core/expat/expat.inc
@@ -6,6 +6,7 @@ LICENSE = "MIT"
 
 SRC_URI = "${SOURCEFORGE_MIRROR}/expat/expat-${PV}.tar.bz2 \
file://autotools.patch \
+   file://CVE-2016-0718.patch \
  "
 
 inherit autotools lib_package gzipnative
diff --git a/meta/recipes-core/expat/expat/CVE-2016-0718.patch 
b/meta/recipes-core/expat/expat/CVE-2016-0718.patch
new file mode 100644
index 000..3fff5e9
--- /dev/null
+++ b/meta/recipes-core/expat/expat/CVE-2016-0718.patch
@@ -0,0 +1,760 @@
+From cdfcb1b5c95e93b00ae9e9d25708b4a3bee72c15 Mon Sep 17 00:00:00 2001
+From: Sebastian Pipping 
+Date: Mon, 2 May 2016 00:02:44 +0200
+Subject: [PATCH] Address CVE-2016-0718 (/patch/ version 2.2.1)
+
+* Out of bounds memory access when doing text conversion on malformed input
+* Integer overflow related to memory allocation
+
+Reported by Gustavo Grieco
+
+Patch credits go to
+* Christian Heimes
+* Karl Waclawek
+* Gustavo Grieco
+* Sebastian Pipping
+* Pascal Cuoq
+
+CVE: CVE-2016-0718
+Upstream-Status: Backport
+
+Signed-off-by: Yi Zhao 
+---
+ expat/lib/xmlparse.c|  34 +-
+ expat/lib/xmltok.c  | 115 +++-
+ expat/lib/xmltok.h  |  10 -
+ expat/lib/xmltok_impl.c |  62 +-
+ 4 files changed, 146 insertions(+), 75 deletions(-)
+
+diff --git a/lib/xmlparse.c b/lib/xmlparse.c
+index e308c79..13e080d 100644
+--- a/lib/xmlparse.c
 b/lib/xmlparse.c
+@@ -2426,11 +2426,11 @@ doContent(XML_Parser parser,
+   for (;;) {
+ int bufSize;
+ int convLen;
+-XmlConvert(enc,
++const enum XML_Convert_Result convert_res = XmlConvert(enc,
+, rawNameEnd,
+(ICHAR **), (ICHAR *)tag->bufEnd - 1);
+ convLen = (int)(toPtr - (XML_Char *)tag->buf);
+-if (fromPtr == rawNameEnd) {
++if ((convert_res == XML_CONVERT_COMPLETED) || (convert_res == 
XML_CONVERT_INPUT_INCOMPLETE)) {
+   tag->name.strLen = convLen;
+   break;
+ }
+@@ -2651,11 +2651,11 @@ doContent(XML_Parser parser,
+   if (MUST_CONVERT(enc, s)) {
+ for (;;) {
+   ICHAR *dataPtr = (ICHAR *)dataBuf;
+-  XmlConvert(enc, , next, , (ICHAR *)dataBufEnd);
++  const enum XML_Convert_Result convert_res = XmlConvert(enc, , 
next, , (ICHAR *)dataBufEnd);
+   *eventEndPP = s;
+   charDataHandler(handlerArg, dataBuf,
+   (int)(dataPtr - (ICHAR *)dataBuf));
+-  if (s == next)
++  if ((convert_res == XML_CONVERT_COMPLETED) || (convert_res == 
XML_CONVERT_INPUT_INCOMPLETE))
+ break;
+   *eventPP = s;
+ }
+@@ -3261,11 +3261,11 @@ doCdataSection(XML_Parser parser,
+   if (MUST_CONVERT(enc, s)) {
+ for (;;) {
+   ICHAR *dataPtr = (ICHAR *)dataBuf;
+-  XmlConvert(enc, , next, , (ICHAR *)dataBufEnd);
++  const enum XML_Convert_Result convert_res = XmlConvert(enc, , 
next, , (ICHAR *)dataBufEnd);
+   *eventEndPP = next;
+   charDataHandler(handlerArg, dataBuf,
+   (int)(dataPtr - (ICHAR *)dataBuf));
+-  if (s == next)
++  if ((convert_res == XML_CONVERT_COMPLETED) || (convert_res == 
XML_CONVERT_INPUT_INCOMPLETE))
+ break;
+   *eventPP = s;
+ }
+@@ -5342,6 +5342,7 @@ reportDefault(XML_Parser parser, const ENCODING *enc,
+   const char *s, const char *end)
+ {
+   if (MUST_CONVERT(enc, s)) {
++enum XML_Convert_Result convert_res;
+ const char **eventPP;
+ const char **eventEndPP;
+ if (enc == encoding) {
+@@ -5354,11 +5355,11 @@ reportDefault(XML_Parser parser, const ENCODING *enc,
+ }
+ do {
+   ICHAR *dataPtr = (ICHAR *)dataBuf;
+-  XmlConvert(enc, , end, , (ICHAR *)dataBufEnd);
++  convert_res = XmlConvert(enc, , end, , (ICHAR *)dataBufEnd);
+   *eventEndPP = s;
+   defaultHandler(handlerArg, dataBuf, (int)(dataPtr - (ICHAR 

Re: [OE-core] [PATCH v2 2/8] gstreamer1.0: upgrade to version 1.8.1

[Christopher Larson]

On Thu, Jun 16, 2016 at 7:46 PM, Andre McCurdy  wrote:

> On Thu, Apr 28, 2016 at 12:06 PM, Carlos Rafael Giani
>  wrote:
> > The gst-inspect patch no longer applies, and according to upstream, is
> > not needed.
>
> This patch series seems to be missing an update for
> gstreamer1.0-plugins-bad ?


gstreamer1.0-plugins-bad's upgrade was delayed due to the pending gtk3
switch for sato, which has recently happened, so I'd expect that upgrade to
come at some point in the near future. See
https://bugzilla.yoctoproject.org/show_bug.cgi?id=9664.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/5] security_flags.inc: add SECURITY_NO_PIE_CFLAGS to libgcc and gcc-sanitizers

[Andre McCurdy]

On Thu, Jun 16, 2016 at 3:59 AM, Alexander Kanavin
 wrote:
> These recipes no longer seem to need full exclusion from security hardening.

Did you also confirm that for gcc 4.9 and 5.3?

> The rest (glibc, gcc-runtime, valgrind, grub, grub-efi, uclibc) still do.
>
> [YOCTO #9489]
>
> Signed-off-by: Alexander Kanavin 
> ---
>  meta/conf/distro/include/security_flags.inc | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/meta/conf/distro/include/security_flags.inc 
> b/meta/conf/distro/include/security_flags.inc
> index ea1d4e5..cd2b964 100644
> --- a/meta/conf/distro/include/security_flags.inc
> +++ b/meta/conf/distro/include/security_flags.inc
> @@ -43,7 +43,7 @@ SECURITY_CFLAGS_pn-flac = "${SECURITY_NO_PIE_CFLAGS}"
>  SECURITY_CFLAGS_pn-flex = "${SECURITY_NO_PIE_CFLAGS}"
>  SECURITY_CFLAGS_pn-gcc = "${SECURITY_NO_PIE_CFLAGS}"
>  SECURITY_CFLAGS_pn-gcc-runtime = ""
> -SECURITY_CFLAGS_pn-gcc-sanitizers = ""
> +SECURITY_CFLAGS_pn-gcc-sanitizers = "${SECURITY_NO_PIE_CFLAGS}"
>  SECURITY_CFLAGS_pn-gdb = "${SECURITY_NO_PIE_CFLAGS}"
>  SECURITY_CFLAGS_pn-gmp = "${SECURITY_NO_PIE_CFLAGS}"
>  SECURITY_CFLAGS_pn-gnutls = "${SECURITY_NO_PIE_CFLAGS}"
> @@ -62,7 +62,7 @@ SECURITY_CFLAGS_pn-kexec-tools = "${SECURITY_NO_PIE_CFLAGS}"
>  SECURITY_CFLAGS_pn-iptables = "${SECURITY_NO_PIE_CFLAGS}"
>  SECURITY_CFLAGS_pn-libaio = "${SECURITY_NO_PIE_CFLAGS}"
>  SECURITY_CFLAGS_pn-libcap = "${SECURITY_NO_PIE_CFLAGS}"
> -SECURITY_CFLAGS_pn-libgcc = ""
> +SECURITY_CFLAGS_pn-libgcc = "${SECURITY_NO_PIE_CFLAGS}"
>  SECURITY_CFLAGS_pn-libid3tag = "${SECURITY_NO_PIE_CFLAGS}"
>  SECURITY_CFLAGS_pn-libnewt = "${SECURITY_NO_PIE_CFLAGS}"
>  SECURITY_CFLAGS_pn-libglu = "${SECURITY_NO_PIE_CFLAGS}"
> @@ -109,10 +109,8 @@ TARGET_CFLAGS_append_class-target = " ${SECURITY_CFLAGS}"
>  TARGET_LDFLAGS_append_class-target = " ${SECURITY_LDFLAGS}"
>
>  SECURITY_LDFLAGS_remove_pn-gcc-runtime = "-fstack-protector-strong"
> -SECURITY_LDFLAGS_remove_pn-gcc-sanitizers = "-fstack-protector-strong"
>  SECURITY_LDFLAGS_remove_pn-glibc = "-fstack-protector-strong"
>  SECURITY_LDFLAGS_remove_pn-glibc-initial = "-fstack-protector-strong"
> -SECURITY_LDFLAGS_remove_pn-libgcc = "-fstack-protector-strong"
>  SECURITY_LDFLAGS_remove_pn-uclibc = "-fstack-protector-strong"
>  SECURITY_LDFLAGS_remove_pn-uclibc-initial = "-fstack-protector-strong"
>  SECURITY_LDFLAGS_pn-xf86-video-fbdev = "${SECURITY_X_LDFLAGS}"
> --
> 2.8.1
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v2 2/8] gstreamer1.0: upgrade to version 1.8.1

[Andre McCurdy]

On Thu, Apr 28, 2016 at 12:06 PM, Carlos Rafael Giani
 wrote:
> The gst-inspect patch no longer applies, and according to upstream, is
> not needed.

This patch series seems to be missing an update for gstreamer1.0-plugins-bad ?


> Signed-off-by: Carlos Rafael Giani 
> ---
>  meta/recipes-multimedia/gstreamer/gstreamer1.0.inc |  2 ++
>  .../0001-Fix-crash-with-gst-inspect.patch  | 28 
> --
>  ...gstreamer1.0_1.6.3.bb => gstreamer1.0_1.8.1.bb} |  5 ++--
>  .../gstreamer/gstreamer1.0_git.bb  |  5 
>  4 files changed, 4 insertions(+), 36 deletions(-)
>  delete mode 100644 
> meta/recipes-multimedia/gstreamer/gstreamer1.0/0001-Fix-crash-with-gst-inspect.patch
>  rename meta/recipes-multimedia/gstreamer/{gstreamer1.0_1.6.3.bb => 
> gstreamer1.0_1.8.1.bb} (62%)
>
> diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0.inc 
> b/meta/recipes-multimedia/gstreamer/gstreamer1.0.inc
> index 10b4668..86ac10c 100644
> --- a/meta/recipes-multimedia/gstreamer/gstreamer1.0.inc
> +++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0.inc
> @@ -24,6 +24,8 @@ PACKAGECONFIG[check] = "--enable-check,--disable-check"
>  PACKAGECONFIG[debug] = "--enable-debug,--disable-debug"
>  PACKAGECONFIG[tests] = "--enable-tests,--disable-tests"
>  PACKAGECONFIG[valgrind] = "--enable-valgrind,--disable-valgrind,valgrind,"
> +PACKAGECONFIG[gst-tracer-hooks] = 
> "--enable-gst-tracer-hooks,--disable-gst-tracer-hooks,"
> +PACKAGECONFIG[trace-historic] = "--enable-trace,--disable-trace,"
>
>  EXTRA_OECONF = " \
>  --disable-dependency-tracking \
> diff --git 
> a/meta/recipes-multimedia/gstreamer/gstreamer1.0/0001-Fix-crash-with-gst-inspect.patch
>  
> b/meta/recipes-multimedia/gstreamer/gstreamer1.0/0001-Fix-crash-with-gst-inspect.patch
> deleted file mode 100644
> index 94f5cc5..000
> --- 
> a/meta/recipes-multimedia/gstreamer/gstreamer1.0/0001-Fix-crash-with-gst-inspect.patch
> +++ /dev/null
> @@ -1,28 +0,0 @@
> -From 6b26f3dbf9bf577d71534ab7410de66d06e46ba2 Mon Sep 17 00:00:00 2001
> -From: Carlos Rafael Giani 
> -Date: Sat, 6 Apr 2013 23:52:11 +0200
> -Subject: [PATCH] Fix crash with gst-inspect Chris Lord 
> -
> -Upstream-Status: Pending
> -
> -Signed-off-by: Carlos Rafael Giani 
> 
> - tools/gst-inspect.c | 2 +-
> - 1 file changed, 1 insertion(+), 1 deletion(-)
> -
> -diff --git a/tools/gst-inspect.c b/tools/gst-inspect.c
> -index 23b7c44..b79b02e 100644
>  a/tools/gst-inspect.c
> -+++ b/tools/gst-inspect.c
> -@@ -1556,7 +1556,7 @@ main (int argc, char *argv[])
> -   g_option_context_add_main_entries (ctx, options, GETTEXT_PACKAGE);
> -   g_option_context_add_group (ctx, gst_init_get_option_group ());
> -   if (!g_option_context_parse (ctx, , , )) {
> --g_printerr ("Error initializing: %s\n", err->message);
> -+g_printerr ("Error initializing: %s\n", err ? err->message : "(null)");
> - return -1;
> -   }
> -   g_option_context_free (ctx);
> ---
> -1.8.2
> -
> diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0_1.6.3.bb 
> b/meta/recipes-multimedia/gstreamer/gstreamer1.0_1.8.1.bb
> similarity index 62%
> rename from meta/recipes-multimedia/gstreamer/gstreamer1.0_1.6.3.bb
> rename to meta/recipes-multimedia/gstreamer/gstreamer1.0_1.8.1.bb
> index ba1b83b..475ebf9 100644
> --- a/meta/recipes-multimedia/gstreamer/gstreamer1.0_1.6.3.bb
> +++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0_1.8.1.bb
> @@ -5,10 +5,9 @@ LIC_FILES_CHKSUM = 
> "file://COPYING;md5=6762ed442b3822387a51c92d928ead0d \
>
>  SRC_URI = " \
>  http://gstreamer.freedesktop.org/src/gstreamer/gstreamer-${PV}.tar.xz \
> -file://0001-Fix-crash-with-gst-inspect.patch \
>  "
>
> -SRC_URI[md5sum] = "b4cdeb2b9cb20dd6ac022a4f417eae0d"
> -SRC_URI[sha256sum] = 
> "22f9568d67b87cf700a111f381144bd37cb93790a77e4e331db01fe854a37f24"
> +SRC_URI[md5sum] = "711ada79b63e47ac96adb4e5444dc908"
> +SRC_URI[sha256sum] = 
> "5a3722fb9302dd977c17ced4240293dc777cb716dc98c8cca63d75c27e5e3107"
>
>  S = "${WORKDIR}/gstreamer-${PV}"
> diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0_git.bb 
> b/meta/recipes-multimedia/gstreamer/gstreamer1.0_git.bb
> index 7715bb2..f04fc6e 100644
> --- a/meta/recipes-multimedia/gstreamer/gstreamer1.0_git.bb
> +++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0_git.bb
> @@ -20,11 +20,6 @@ SRCREV_FORMAT = "base"
>
>  S = "${WORKDIR}/git"
>
> -# The option to configure tracer hooks was added prior to the 1.7.2 release
> -# 
> https://cgit.freedesktop.org/gstreamer/gstreamer/commit/?id=e5ca47236e4df4683707f0bcf99181a937d358d5
> -PACKAGECONFIG[gst-tracer-hooks] = 
> "--enable-gst-tracer-hooks,--disable-gst-tracer-hooks,"
> -PACKAGECONFIG[trace-historic] = "--enable-trace,--disable-trace,"
> -
>  do_configure_prepend() {
> ${S}/autogen.sh --noconfigure
>  }
> --
> 2.5.0
>
> --
> ___
> 

Re: [OE-core] [PATCH 4/5] security_flags.inc: add epiphany to SECURITY_NO_PIE_CFLAGS

[Andre McCurdy]

On Thu, Jun 16, 2016 at 3:59 AM, Alexander Kanavin
 wrote:
> Otherwise there is a QA warning about relocations in .text

Typically these warnings come from assembler and can't be fixed via
CFLAGS. If this one _can_ be fixed via CFLAGS then it suggests a bug
in the Epiphany build somewhere (e.g. reusing an object file intended
for a static lib in an .so). Maybe it's better to track that down and
fix properly instead of working around it by globally adding -fPIC to
CFLAGS?

> Signed-off-by: Alexander Kanavin 
> ---
>  meta/conf/distro/include/security_flags.inc | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/meta/conf/distro/include/security_flags.inc 
> b/meta/conf/distro/include/security_flags.inc
> index 26804bd..ea00bdd 100644
> --- a/meta/conf/distro/include/security_flags.inc
> +++ b/meta/conf/distro/include/security_flags.inc
> @@ -38,6 +38,7 @@ SECURITY_CFLAGS_pn-glibc = ""
>  SECURITY_CFLAGS_pn-glibc-initial = ""
>  SECURITY_CFLAGS_pn-elfutils = "${SECURITY_NO_PIE_CFLAGS}"
>  SECURITY_CFLAGS_pn-enchant = "${SECURITY_NO_PIE_CFLAGS}"
> +SECURITY_CFLAGS_pn-epiphany = "${SECURITY_NO_PIE_CFLAGS}"
>  SECURITY_CFLAGS_pn-expect = "${SECURITY_NO_PIE_CFLAGS}"
>  SECURITY_CFLAGS_pn-flac = "${SECURITY_NO_PIE_CFLAGS}"
>  SECURITY_CFLAGS_pn-flex = "${SECURITY_NO_PIE_CFLAGS}"
> --
> 2.8.1
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 3/5] security_flags.inc: add -fPIC to SECURITY_NO_PIE_CFLAGS

[Andre McCurdy]

On Thu, Jun 16, 2016 at 3:59 AM, Alexander Kanavin
 wrote:
> The packages that break due to -fpie can be still built with -fPIC.
>
> [YOCTO #9486]
>
> Signed-off-by: Alexander Kanavin 
> ---
>  meta/conf/distro/include/security_flags.inc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/conf/distro/include/security_flags.inc 
> b/meta/conf/distro/include/security_flags.inc
> index a7be185..26804bd 100644
> --- a/meta/conf/distro/include/security_flags.inc
> +++ b/meta/conf/distro/include/security_flags.inc
> @@ -13,7 +13,7 @@ lcl_maybe_fortify = 
> "${@base_conditional('DEBUG_BUILD','1','','-D_FORTIFY_SOURCE
>  SECURITY_STRINGFORMAT ?= "-Wformat -Wformat-security -Werror=format-security"
>
>  SECURITY_CFLAGS ?= "-fstack-protector-strong -pie -fpie ${lcl_maybe_fortify} 
> ${SECURITY_STRINGFORMAT}"
> -SECURITY_NO_PIE_CFLAGS ?= "-fstack-protector-strong ${lcl_maybe_fortify} 
> ${SECURITY_STRINGFORMAT}"
> +SECURITY_NO_PIE_CFLAGS ?= "-fPIC -fstack-protector-strong 
> ${lcl_maybe_fortify} ${SECURITY_STRINGFORMAT}"

I don't think this does anything useful. An executable won't be
position independent unless -pie is passed to the linker, so if
linking with -pie doesn't work, forcing all object code to be position
independent is just adding overhead with no benefit.

>  SECURITY_LDFLAGS ?= "-fstack-protector-strong -Wl,-z,relro,-z,now"
>  SECURITY_X_LDFLAGS ?= "-fstack-protector-strong -Wl,-z,relro"
> --
> 2.8.1
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [RFC][PATCH] vte: bring back old version to support xfce4-terminal

[Andre McCurdy]

On Thu, Jun 16, 2016 at 2:47 PM, Burton, Ross  wrote:
>
> On 16 June 2016 at 21:49, Mark Asselstine 
> wrote:
>>
>> While waiting to hear back about my inquiry I did take some
>> time to put together this patch that allows things that
>> require the older vte to continue to build. Since xfce4-terminal
>> lives in meta-openembedded this might make more sense to carry
>> over there. I am sure folks will have an opinion so sending this
>> out as an RFC.
>
> That's certainly a good argument for putting the old vte in meta-oe.

The meta-oe layers generally have a higher priority than oe-core, so
having an older version in meta-oe and a newer version in oe-core can
lead to unexpected results.

> Ross
>
> --
> ___
> 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] [RFC][PATCH] vte: bring back old version to support xfce4-terminal

[Martin Jansa]

meta-xfce4, right?

On Thu, Jun 16, 2016 at 11:47 PM, Burton, Ross 
wrote:

>
> On 16 June 2016 at 21:49, Mark Asselstine 
> wrote:
>
>> While waiting to hear back about my inquiry I did take some
>> time to put together this patch that allows things that
>> require the older vte to continue to build. Since xfce4-terminal
>> lives in meta-openembedded this might make more sense to carry
>> over there. I am sure folks will have an opinion so sending this
>> out as an RFC.
>>
>
> That's certainly a good argument for putting the old vte in meta-oe.
>
> Ross
>
> --
> ___
> 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] [RFC][PATCH] vte: bring back old version to support xfce4-terminal

[Burton, Ross]

On 16 June 2016 at 21:49, Mark Asselstine 
wrote:

> While waiting to hear back about my inquiry I did take some
> time to put together this patch that allows things that
> require the older vte to continue to build. Since xfce4-terminal
> lives in meta-openembedded this might make more sense to carry
> over there. I am sure folks will have an opinion so sending this
> out as an RFC.
>

That's certainly a good argument for putting the old vte in meta-oe.

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

[OE-core] [PATCH] build-appliance-image: Install network components

[Juro Bystricky]

Explicitly add network components into Build Appliance image,
do not rely on packagegroup-self-hosted to pull them in.
Network related dependencies were removed from packagegroup-self-hosted.

YOCTO #9758

Signed-off-by: Juro Bystricky 
---
 meta/recipes-core/images/build-appliance-image_15.0.0.bb | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-core/images/build-appliance-image_15.0.0.bb 
b/meta/recipes-core/images/build-appliance-image_15.0.0.bb
index 94d4d5d..ffd7867 100644
--- a/meta/recipes-core/images/build-appliance-image_15.0.0.bb
+++ b/meta/recipes-core/images/build-appliance-image_15.0.0.bb
@@ -6,7 +6,8 @@ LICENSE = "MIT"
 LIC_FILES_CHKSUM = 
"file://${COREBASE}/LICENSE;md5=4d92cd373abda3937c2bc47fbc49d690 \
 
file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
 
-IMAGE_INSTALL = "packagegroup-core-boot packagegroup-core-ssh-openssh 
packagegroup-self-hosted kernel-dev kernel-devsrc "
+IMAGE_INSTALL = "packagegroup-core-boot packagegroup-core-ssh-openssh 
packagegroup-self-hosted \
+ kernel-dev kernel-devsrc connman connman-plugin-ethernet 
dhcp-client"
 
 IMAGE_FEATURES += "x11-base package-management splash"
 
-- 
1.9.1

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

[OE-core] [RFC][PATCH] vte: bring back old version to support xfce4-terminal

[Mark Asselstine]

The recent uprev to vte version 0.44.1 as part of commit
commit dc21182ada418cf3917ae8319494d219462c5bfd [vte: Upgrade to 0.44.1]
brought with it an jump in api version, leaving any packages, such as
xfce4-terminal, failing to configure/build. The commit log indicated
that it was a possibility to support the two versions (more
specifically the two api versions) side by side but that this option
was not taken.

Since we now know that this uprev does have fairly significant impact
on some other packages bring back the old version and have it live
side by side with the new. The appended version '0.0' was selected to
match the api version string used by the the upstream vte project.

Signed-off-by: Mark Asselstine 
---

While waiting to hear back about my inquiry I did take some
time to put together this patch that allows things that
require the older vte to continue to build. Since xfce4-terminal
lives in meta-openembedded this might make more sense to carry
over there. I am sure folks will have an opinion so sending this
out as an RFC.

Mark


 .../vte/vte-0.0/cve-2012-2738.patch| 136 +
 .../vte/vte-0.0/obsolete_automake_macros.patch |  14 +++
 meta/recipes-support/vte/vte-0.0_0.28.2.bb |  31 +
 3 files changed, 181 insertions(+)
 create mode 100644 meta/recipes-support/vte/vte-0.0/cve-2012-2738.patch
 create mode 100644 
meta/recipes-support/vte/vte-0.0/obsolete_automake_macros.patch
 create mode 100644 meta/recipes-support/vte/vte-0.0_0.28.2.bb

diff --git a/meta/recipes-support/vte/vte-0.0/cve-2012-2738.patch 
b/meta/recipes-support/vte/vte-0.0/cve-2012-2738.patch
new file mode 100644
index 000..9b99803
--- /dev/null
+++ b/meta/recipes-support/vte/vte-0.0/cve-2012-2738.patch
@@ -0,0 +1,136 @@
+Upstream-Status: Backport
+CVE: CVE-2012-2738
+Signed-off-by: Ross Burton 
+
+From e524b0b3bd8fad844ffa73927c199545b892cdbd Mon Sep 17 00:00:00 2001
+From: Christian Persch 
+Date: Sat, 19 May 2012 19:36:09 +0200
+Subject: [PATCH 1/2] emulation: Limit integer arguments to 65535
+
+To guard against malicious sequences containing excessively big numbers,
+limit all parsed numbers to 16 bit range. Doing this here in the parsing
+routine is a catch-all guard; this doesn't preclude enforcing
+more stringent limits in the handlers themselves.
+
+https://bugzilla.gnome.org/show_bug.cgi?id=676090
+---
+ src/table.c  | 2 +-
+ src/vteseq.c | 2 +-
+ 2 files changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/src/table.c b/src/table.c
+index 140e8c8..85cf631 100644
+--- a/src/table.c
 b/src/table.c
+@@ -550,7 +550,7 @@ _vte_table_extract_numbers(GValueArray **array,
+   if (G_UNLIKELY (*array == NULL)) {
+   *array = g_value_array_new(1);
+   }
+-  g_value_set_long(, total);
++  g_value_set_long(, CLAMP (total, 0, G_MAXUSHORT));
+   g_value_array_append(*array, );
+   } while (i++ < arginfo->length);
+   g_value_unset();
+diff --git a/src/vteseq.c b/src/vteseq.c
+index 7ef4c8c..10991db 100644
+--- a/src/vteseq.c
 b/src/vteseq.c
+@@ -557,7 +557,7 @@ vte_sequence_handler_multiple(VteTerminal *terminal,
+   GValueArray *params,
+   VteTerminalSequenceHandler handler)
+ {
+-vte_sequence_handler_multiple_limited(terminal, params, handler, 
G_MAXLONG);
++vte_sequence_handler_multiple_limited(terminal, params, handler, 
G_MAXUSHORT);
+ }
+ 
+ static void
+-- 
+2.4.9 (Apple Git-60)
+
+
+From cf1ad453a8def873c49cf6d88162593402f32bb2 Mon Sep 17 00:00:00 2001
+From: Christian Persch 
+Date: Sat, 19 May 2012 20:04:12 +0200
+Subject: [PATCH 2/2] emulation: Limit repetitions
+
+Don't allow malicious sequences to cause excessive repetitions.
+
+https://bugzilla.gnome.org/show_bug.cgi?id=676090
+---
+ src/vteseq.c | 25 ++---
+ 1 file changed, 18 insertions(+), 7 deletions(-)
+
+diff --git a/src/vteseq.c b/src/vteseq.c
+index 10991db..209522f 100644
+--- a/src/vteseq.c
 b/src/vteseq.c
+@@ -1392,7 +1392,7 @@ vte_sequence_handler_dc (VteTerminal *terminal, 
GValueArray *params)
+ static void
+ vte_sequence_handler_DC (VteTerminal *terminal, GValueArray *params)
+ {
+-  vte_sequence_handler_multiple(terminal, params, 
vte_sequence_handler_dc);
++  vte_sequence_handler_multiple_r(terminal, params, 
vte_sequence_handler_dc);
+ }
+ 
+ /* Delete a line at the current cursor position. */
+@@ -1785,7 +1785,7 @@ vte_sequence_handler_reverse_index (VteTerminal 
*terminal, GValueArray *params)
+ static void
+ vte_sequence_handler_RI (VteTerminal *terminal, GValueArray *params)
+ {
+-  vte_sequence_handler_multiple(terminal, params, 
vte_sequence_handler_nd);
++  vte_sequence_handler_multiple_r(terminal, params, 
vte_sequence_handler_nd);
+ }
+ 
+ /* Save cursor (position). */
+@@ -2777,8 +2777,7 @@ 

Re: [OE-core] [PATCH] squid: don't build squid-conf-tests binary

[akuster808]

On 06/16/2016 12:07 AM, Alexandru Moise wrote:
> autotools ends up stripping this binary which ends up causing
> QA Errors at do_package. Remove it.

I think you want to send this to openembedded-devel mailing list.

- armin

> Signed-off-by: Alexandru Moise 
> ---
>  ...squid-don-t-build-squid-conf-tests-binary.patch | 30 
> ++
>  .../recipes-daemons/squid/squid_3.5.7.bb   |  1 +
>  2 files changed, 31 insertions(+)
>  create mode 100644 
> meta-networking/recipes-daemons/squid/files/0001-squid-don-t-build-squid-conf-tests-binary.patch
> 
> diff --git 
> a/meta-networking/recipes-daemons/squid/files/0001-squid-don-t-build-squid-conf-tests-binary.patch
>  
> b/meta-networking/recipes-daemons/squid/files/0001-squid-don-t-build-squid-conf-tests-binary.patch
> new file mode 100644
> index 000..82cd0b0
> --- /dev/null
> +++ 
> b/meta-networking/recipes-daemons/squid/files/0001-squid-don-t-build-squid-conf-tests-binary.patch
> @@ -0,0 +1,30 @@
> +From 75f4072e6fc9704713629c87eec750ff708135c4 Mon Sep 17 00:00:00 2001
> +From: Alexandru Moise 
> +Date: Thu, 16 Jun 2016 10:01:41 +0300
> +Subject: [PATCH] squid: don't build squid-conf-tests binary
> +
> +autotools ends up stripping this binary which ends up causing
> +QA Errors at do_package. Remove it.
> +
> +Signed-off-by: Alexandru Moise 
> +---
> + test-suite/Makefile.am | 3 +--
> + 1 file changed, 1 insertion(+), 2 deletions(-)
> +
> +diff --git a/test-suite/Makefile.am b/test-suite/Makefile.am
> +index b9c412d..0471bf0 100644
> +--- a/test-suite/Makefile.am
>  b/test-suite/Makefile.am
> +@@ -43,8 +43,7 @@ TESTS += debug \
> + MemPoolTest\
> + mem_node_test\
> + mem_hdr_test\
> +-$(ESI_TESTS) \
> +-squid-conf-tests
> ++$(ESI_TESTS)
> + 
> + ## Sort by alpha - any build failures are significant.
> + check_PROGRAMS += debug \
> +-- 
> +2.7.4
> +
> diff --git a/meta-networking/recipes-daemons/squid/squid_3.5.7.bb 
> b/meta-networking/recipes-daemons/squid/squid_3.5.7.bb
> index b571e29..2d243fb 100644
> --- a/meta-networking/recipes-daemons/squid/squid_3.5.7.bb
> +++ b/meta-networking/recipes-daemons/squid/squid_3.5.7.bb
> @@ -21,6 +21,7 @@ SRC_URI = 
> "http://www.squid-cache.org/Versions/v${MAJ_VER}/${MIN_VER}/${BPN}-${P
> file://volatiles.03_squid \
> file://CVE-2016-3947.patch \
> file://CVE-2016-4553.patch \
> +   file://0001-squid-don-t-build-squid-conf-tests-binary.patch \
>  "
>  
>  LIC_FILES_CHKSUM = "file://COPYING;md5=c492e2d6d32ec5c1aad0e0609a141ce9 \
> 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v2] linux-firmware: add iwlwifi-8000C-19 version

[Saul Wold]

This version is required for certain iwlwifi hardware
can not use the most recent firmware blob.

[YOCTO #9771]

Signed-off-by: Saul Wold 
---
v2: use kernel.org version of file
removed extra do_install_append

 meta/recipes-kernel/linux-firmware/linux-firmware_git.bb | 9 +
 1 file changed, 9 insertions(+)

diff --git a/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb 
b/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
index 52fd176..2393afb 100644
--- a/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
+++ b/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
@@ -178,6 +178,12 @@ PV = "0.0+git${SRCPV}"
 
 SRC_URI = 
"git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git"
 
+# Some devices need a specific version, not the latest
+SRC_URI += 
"https://git.kernel.org/cgit/linux/kernel/git/iwlwifi/linux-firmware.git/plain/iwlwifi-8000C-19.ucode;name=iwlwifi-19;
+
+SRC_URI[iwlwifi-19.md5sum] = "132fbaee36beec5e98714f0bd66f7a1d"
+SRC_URI[iwlwifi-19.sha256sum] = 
"2034470df64d323b827c4f2d4d0d55be2846b7360179b5574aa28ff77b6c9471"
+
 S = "${WORKDIR}/git"
 
 inherit allarch update-alternatives
@@ -207,6 +213,9 @@ do_install() {
 
# fixup wl12xx location, after 2.6.37 the kernel searches a different 
location for it
( cd ${D}/lib/firmware ; ln -sf ti-connectivity/* . )
+
+# Copy the iwlwifi ucode
+cp ${WORKDIR}/iwlwifi-8000C-19.ucode ${D}/lib/firmware/
 }
 
 
-- 
2.5.0

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

Re: [OE-core] [PATCHv3 10/30] vte: Upgrade to 0.44.1

[Mark Asselstine]

On 14 June 2016 at 11:14, Jussi Kukkonen  > wrote:
> 
> * License change LGPL 2.0 -> LGPL 2.1+
> * vte-termcap is no more
> * API break: current version seems to be parallel installable
>with old one, but I did not opt for that.
> * Add patch to avoid stack protection by default
> * Add SECURITY_NO_PIE_CFLAGS exception until linking failure with
>libc_nonshared.a is resolved (undefined reference to
>__init_array_start)
> 
> 
> Just found out Khem has worked around a similar problem with
> libtool-cross already: I've modified this patch so
> that SECURITY_NO_PIE_CFLAGS is no longer used, but instead libtool-cross
> is used:
> 
> +# libtool adds "-nostdlib" when g++ is used. This breaks PIE builds.
> +# Use libtool-cross (which has a hack to prevent that) instead.
> +EXTRA_OEMAKE_class-target =
> "LIBTOOL=${STAGING_BINDIR_CROSS}/${HOST_SYS}-libtool"
> 
>   - Jussi

Just a heads up this this breaks xfce4-terminal. There is currently no
xfce4-terminal release which will function with vte api 2.91, only
ongoing work on their master branch as far as I can tell. I have no
idea how far reaching the effects of this change will be on
xfce. Before I spend any time on this is this something which folks
are aware of and is there a plan in place? Is there a possibility to
keep the older vte around?

Thanks,
Mark


> 
> 
> Signed-off-by: Jussi Kukkonen  >
> ---
>   meta/conf/distro/include/security_flags.inc|   2 +
>   .../vte/vte-0.28.2/cve-2012-2738.patch | 136
> -
>   .../vte/vte-0.28.2/obsolete_automake_macros.patch  |  14 ---
>   meta/recipes-support/vte/vte.inc   |  15 ---
>   ...-Don-t-enable-stack-protection-by-default.patch |  29 +
>   meta/recipes-support/vte/vte_0.28.2.bb 
> 
>   |  16 ---
> 
>   meta/recipes-support/vte/vte_0.44.1.bb 
> 
>   |  24 
> 
>   7 files changed, 55 insertions(+), 181 deletions(-)
>   delete mode 100644
> meta/recipes-support/vte/vte-0.28.2/cve-2012-2738.patch
>   delete mode 100644
> meta/recipes-support/vte/vte-0.28.2/obsolete_automake_macros.patch
>   delete mode 100644 meta/recipes-support/vte/vte.inc
>   create mode 100644
>
> meta/recipes-support/vte/vte/0001-Don-t-enable-stack-protection-by-default.
> patch delete mode 100644 meta/recipes-support/vte/vte_0.28.2.bb
> 
>   create mode 100644 meta/recipes-support/vte/vte_0.44.1.bb
> 
> 
> diff --git a/meta/conf/distro/include/security_flags.inc
> b/meta/conf/distro/include/security_flags.inc
> index ea1d4e5..0df65e0 100644
> --- a/meta/conf/distro/include/security_flags.inc
> +++ b/meta/conf/distro/include/security_flags.inc
> @@ -95,6 +95,8 @@ SECURITY_CFLAGS_pn-zlib = "${SECURITY_NO_PIE_CFLAGS}"
>   SECURITY_CFLAGS_pn-ltp = "${SECURITY_NO_PIE_CFLAGS}"
>   SECURITY_CFLAGS_pn-pulseaudio = "${SECURITY_NO_PIE_CFLAGS}"
> 
> +SECURITY_CFLAGS_pn-vte = "${SECURITY_NO_PIE_CFLAGS}"
> +
>   # Recipes which fail to compile when elevating -Wformat-security
> to an error
>   SECURITY_STRINGFORMAT_pn-busybox = ""
>   SECURITY_STRINGFORMAT_pn-console-tools = ""
> diff --git a/meta/recipes-support/vte/vte-0.28.2/cve-2012-2738.patch
> b/meta/recipes-support/vte/vte-0.28.2/cve-2012-2738.patch
> deleted file mode 100644
> index 9b99803..000
> --- a/meta/recipes-support/vte/vte-0.28.2/cve-2012-2738.patch
> +++ /dev/null
> @@ -1,136 +0,0 @@
> -Upstream-Status: Backport
> -CVE: CVE-2012-2738
> -Signed-off-by: Ross Burton  >
> -
> -From e524b0b3bd8fad844ffa73927c199545b892cdbd Mon Sep 17 00:00:00 2001
> -From: Christian Persch 

[OE-core] Obtaining a Complete File Manifest for a Given Recipe

[Terry Boese]

I have a Yocto project which contains multiple modules.  Each module is 
released independently, so I have the problem of trying to identify 
changes in the overall git repository that affect the module being 
released, while pruning the changes that are isolated to the other 
modules.  I could pass an explicit file list to my git log, but at the 
moment I don't know how to get the list of files that affect a given 
recipe.  BBINCLUDED gives me all of the input files for parsing the 
current recipe, but is not recursive to the dependencies, and does not 
provide the list of in-repository files (SRC_URI "file://" entries) that 
can change.  Is there a method currently that will allow me to get the 
file list (or the git history directly)?  If not, what would be the best 
path forward to extend bitbake to add such functionality?


--
Terry Boese
Software Developer
Vecima Networks, Inc.
#100, 255 – 2nd Avenue North
Saskatoon, SK S7K 3P2
Phone: (306) 955-7075 x4672
Email: terry.bo...@vecima.com

_Notice of Confidentiality:_

This email is intended only for the person or entity to which it is 
addressed,

is confidential and proprietary, and may contain privileged information. Any
disclosure, copying, review, re-transmission, dissemination or other use of,
or taking of any action in reliance upon, this message or any information
contained herein by persons or entities other than the intended recipient is
prohibited and may be unlawful. If you received this message in error, 
please

notify the sender immediately by return electronic transmission and then
delete this transmission, including all attachments, without saving, 
copying,

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

[OE-core] [PATCH] build-appliance-image: Add LC_ALL setting and drop pseudo pieces

[Richard Purdie]

The pseudo pieces here date from times gone by when bitbake ran in two
phases. Its long since obsolete and can be dropped.

Also set LC_ALL so that bitbake works correctly and uses the local
we're already installing into the image so we have utf-8 available.

Signed-off-by: Richard Purdie 

diff --git a/meta/recipes-core/images/build-appliance-image_15.0.0.bb 
b/meta/recipes-core/images/build-appliance-image_15.0.0.bb
index 9dbfd1b..94d4d5d 100644
--- a/meta/recipes-core/images/build-appliance-image_15.0.0.bb
+++ b/meta/recipes-core/images/build-appliance-image_15.0.0.bb
@@ -56,12 +56,8 @@ fakeroot do_populate_poky_src () {
# Create a symlink, needed for out-of-tree kernel modules build
lnr ${IMAGE_ROOTFS}${KERNEL_SRC_PATH} 
${IMAGE_ROOTFS}/lib/modules/${KERNEL_VERSION}/build
 
-   echo "/usr/bin" > ${IMAGE_ROOTFS}/home/builder/poky/build/pseudodone
echo "INHERIT += \"rm_work\"" >> 
${IMAGE_ROOTFS}/home/builder/poky/build/conf/auto.conf
-   mkdir -p ${IMAGE_ROOTFS}/home/builder/pseudo
-   echo "export PSEUDO_PREFIX=/usr" >> ${IMAGE_ROOTFS}/home/builder/.bashrc
-   echo "export PSEUDO_LOCALSTATEDIR=/home/builder/pseudo" >> 
${IMAGE_ROOTFS}/home/builder/.bashrc
-   echo "export PSEUDO_LIBDIR=/usr/lib/pseudo/lib64" >> 
${IMAGE_ROOTFS}/home/builder/.bashrc
+   echo "export LC_ALL=en_US.utf8" >> ${IMAGE_ROOTFS}/home/builder/.bashrc
 
# Also save (for reference only) the actual SRCREV used to create this 
image
echo "export BA_SRCREV=${SRCREV}" >> 
${IMAGE_ROOTFS}/home/builder/.bashrc
@@ -72,8 +68,6 @@ fakeroot do_populate_poky_src () {
echo "# export ALL_PROXY=https://proxy.example.com:8080; >> 
${IMAGE_ROOTFS}/home/builder/.bashrc
echo "# export ALL_PROXY=socks://socks.example.com:1080" >> 
${IMAGE_ROOTFS}/home/builder/.bashrc
 
-   chown builder.builder ${IMAGE_ROOTFS}/home/builder/pseudo
-
chown -R builder.builder ${IMAGE_ROOTFS}/home/builder/poky
chmod -R ug+rw ${IMAGE_ROOTFS}/home/builder/poky
 


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

Re: [OE-core] [PATCH] The CMake recipes contain a mismatch between the environmental variable which defines where the Modules are installed and the location where they actually are. This patch fixes t

[Alexander Kanavin]

On 06/16/2016 05:45 PM, Christopher Larson wrote:

Thanks for the contribution, though, it's appreciated. Perhaps someone
else can comment on the patch itself.


The idea behind the fix is correct (latest cmake seems to have its 
modules in /usr/share/cmake-/Modules rather than 
/usr/share/cmake/Modules), but the patch is wrong in multiple ways:


1) needs to be rebased against latest master, the line it's patching has 
been changed over a year ago actually.


2) the patch is only adding another patch :) This extra layer needs to go.

3) the commit message should contain a single, short sentence in the 
first paragraph that explains what the patch is doing:


"cmake.bbclass: set the modules directory correctly"

Then the rest of the commit message should explain why that needs to 
happen and also can go into further details of how the problem is fixed.


Alex

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

Re: [OE-core] [PATCH] rootfs-postcommands: generate /var/lib/systemd/clock

[Peter Kjellerstedt]

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> Khem Raj
> Sent: den 16 juni 2016 16:38
> To: Jan Remmet
> Cc: openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH] rootfs-postcommands: generate
> /var/lib/systemd/clock
> 
> 
> > On Jun 16, 2016, at 7:17 AM, Jan Remmet  wrote:
> >
> > On Wed, Jun 15, 2016 at 12:14:17PM -0700, Khem Raj wrote:
> >>
> >>> On Jun 15, 2016, at 6:36 AM, Jan Remmet  wrote:
> >>>
> >>> systemd timesyncd check /var/lib/systemd/clock instead of
> >>> /etc/timestamp.
> >>> If this file is missing it defaults to TIME_EPOCH. It's set while
> >>> configuring systemd.
> >>>
> >>> Signed-off-by: Jan Remmet 
> >>> ---
> >>> meta/classes/rootfs-postcommands.bbclass | 6 ++
> >>> 1 file changed, 6 insertions(+)
> >>>
> >>> diff --git a/meta/classes/rootfs-postcommands.bbclass
> b/meta/classes/rootfs-postcommands.bbclass
> >>> index db8b551..0c7b764 100644
> >>> --- a/meta/classes/rootfs-postcommands.bbclass
> >>> +++ b/meta/classes/rootfs-postcommands.bbclass
> >>> @@ -234,6 +234,12 @@ python write_image_manifest () {
> >>> # sane default time setting
> >>> rootfs_update_timestamp () {
> >>>   date -u +%4Y%2m%2d%2H%2M%2S >${IMAGE_ROOTFS}/etc/timestamp
> >>> +
> >>> + if ${@bb.utils.contains("DISTRO_FEATURES", "systemd", "true",
> "false", d)}; then
> >>> + # touch needs timestamp as [[CC]YY]MMDDhhmm[.ss]
> >>> + TS=$(sed 's/[.]*/&./13' ${IMAGE_ROOTFS}/etc/timestamp)
> >>> + touch -t $TS ${IMAGE_ROOTFS}/var/lib/systemd/clock
> >>> + fi
> >>> }
> >>
> >> i wonder if this will work with read only rootfs.
> > I found no special handling for systemd and /var/lib if
> > IMAGE_FEATURES read-only-rootfs is used.

If read-only-rootfs is used, then /var/lib is a bind mount to 
/var/volatile/lib (which is a tmpfs). This is handled by the
volatile-binds recipe.

> > If timesyncd didn't find /var/lib/systemd/clock it defaults to the
> > configure time value und try to write /var/lib/systemd/clock. On 
> > read-only it will silently fail.
> > So I don't see a problem here.
> 
> It fixes one case when rootfs is r/w but create another behavior when
> its r/o in r/o case /var/lib/systemd must be mounted r/w during boot.
> So the timesyncd service should check for that directory to exist I 
> have a hunch if thats checked then this patch may not be needed
> 
> >
> > Jan

//Peter

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

Re: [OE-core] [PATCH] The CMake recipes contain a mismatch between the environmental variable which defines where the Modules are installed and the location where they actually are. This patch fixes t

[Christopher Larson]

On Thu, Jun 16, 2016 at 7:27 AM, Jose Pardeiro <
jparde...@rapyuta-robotics.com> wrote:

> Signed-off-by: Jose Pardeiro 
>

I can't speak to the content, not knowing cmake very well, but this commit
message violates general git commit message policy and yocto's
specifically.

http://openembedded.org/wiki/Commit_Patch_Message_Guidelines

Thanks for the contribution, though, it's appreciated. Perhaps someone else
can comment on the patch itself.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] couple trivial(?) questions regarding RPM revision/version numbers

[Mark Hatle]

On 6/16/16 6:00 AM, Robert P. J. Day wrote:
> 
>   not at my dev machine at the moment; otherwise, i could just test
> this but i'd probably still want clarification, anyway.
> 
>   so, i'm well aware that a single recipe can generate numerous (in my
> case, rpm) package files. basic case: a recipe can generate the "base"
> package, a "doc" package, a "dev" package, and so on and so on. no
> problem there.
> 
>   first clarification -- regardless of how versioning and revisioning
> is being done, *all* packages generated from a single recipe during
> the same build have to have the same version and revision number, yes?
> i can't imagine how that couldn't be true, but i've been surprised
> before.

This is not required, it is typically true -- but there may be some exceptions.

(I believe this is the same in deb and opkg...)

The final package name, epoch, version, and release come from the following
variables:

name: PKG_ or 'packagename' in the PACKAGES variable
epoch: PKGE_ or PKGE
version: PKGV_ or PKGV
release: PKGR_ or PKGR

PKG_ is often set in the debian.bbclass, but could be set directly in
the recipe itself.

PKGE/V/R are defined in bitbake.conf:
PKGV ?= "${PV}"
PKGR ?= "${PR}${EXTENDPRAUTO}"
PKGE ?= "${@['','${PE}'][int(d.getVar('PE', True) or 0) > 0]}"
EXTENDPKGEVER = "${@['','${PKGE}:'][d.getVar('PKGE', True).strip() != '']}"
EXTENDPKGV ?= "${EXTENDPKGEVER}${PKGV}-${PKGR}"

This gives the recipe author ultimate control over each sub package.

It's -strongly- suggested you don't manually set PKGE, but it is theoretically
there if you did set it, you should use the same type of package extension
code above for the PR server.

>   next question -- if any part of the base content for a recipe
> changes and that recipe is processed again, all generated packages
> have to jump to the next version/revision together, correct? again,
> this seems obvious, but i want to make absolutely sure.

version changes if the upstream source changes (not integration patches),
release changes on integration changes, including rebuilds due to dependent
packages.

>   so if i have a recipe for which i make a tiny change that affects
> the content of only one of the generated packages, if the revision
> number increases from, say, "r4" to "r5", *all* of the generated
> packages go along for the ride, even all the rest of the packages
> whose content did *not* change. so i could end up with a slew of
> generated packages whose revision number increased, even though
> absolutely nothing about the package content actually changed. so far,
> so good?

Yes, they all are revised as a unit, unless someone is playing games directly
with PKGE.

>   and finally, if the above is accurate, at some point, if i get an
> updated recipe, and rebuild never package files from it, and do an
> update, a lot of those "newer" packages might not contain any actual
> changes, and if that happens, does the rpm update operation actually
> do any work?

RPM is "smart" in that when you perform an upgrade activity, say from

foo-1.0-r1 to foo-1.0-r2, it will look at the checksums of the files to be
updated, from the old version to the new version.  It will ONLY unpack and
upgrade the files that have changed.  If none of the files were modified, then
the action is very quick as it simply updates the metadata in the RPM
repository.  (I don't know how deb/ipkg deal with those situations.)

Since other things that require all the way down to the revision level, it's
important that the package is upgraded even if there are no changes from the
previous version in order to deal with dependencies.

This is why the build compare code, when run properly, should be diffing each
sub package, if it encounters any sub package with a change -- then -all- of the
packages in that recipe should be considered to have changed and make it into
the upgrade set.

>   i understand that the end result will be(?) that all of those
> related packages will now have the newer revision number once the
> update is done, but it's entirely possible (even normal) for there to
> have been no change effected by that "update". and in cases like that,
> even if one of my packages was "updated":
> 
>   rday-doc-1.0-r0  --->  rday-doc-1.0-r1
> 
> the content of that package could be unchanged. and if that happens
> (and if everything i've been saying so far is true), is rpm smart
> enough to not do any work in cases like that, and just quietly bump up
> the version number of the installed package and move on?

See above.  Work is minimal, but this is built into the design of RPM.

One downside of this optimization -- the system never actually checks what is on
the disk.  So in the scenario above, if you do:

rpm -U rday-doc-1.0-r0

echo modfied > /usr/share/docs/rday/mydoc

rpm -V rday-doc

(this will show it's been modified)

rpm -U rday-doc-1.0-r1

rpm -V rday-doc

this will again show it's been modified.  As the package 'upgrade' does not
check the on-disk contents, only the 

Re: [OE-core] [PATCH] rootfs-postcommands: generate /var/lib/systemd/clock

[Khem Raj]

> On Jun 16, 2016, at 7:17 AM, Jan Remmet  wrote:
> 
> On Wed, Jun 15, 2016 at 12:14:17PM -0700, Khem Raj wrote:
>> 
>>> On Jun 15, 2016, at 6:36 AM, Jan Remmet  wrote:
>>> 
>>> systemd timesyncd check /var/lib/systemd/clock instead of
>>> /etc/timestamp.
>>> If this file is missing it defaults to TIME_EPOCH. It's set while
>>> configuring systemd.
>>> 
>>> Signed-off-by: Jan Remmet 
>>> ---
>>> meta/classes/rootfs-postcommands.bbclass | 6 ++
>>> 1 file changed, 6 insertions(+)
>>> 
>>> diff --git a/meta/classes/rootfs-postcommands.bbclass 
>>> b/meta/classes/rootfs-postcommands.bbclass
>>> index db8b551..0c7b764 100644
>>> --- a/meta/classes/rootfs-postcommands.bbclass
>>> +++ b/meta/classes/rootfs-postcommands.bbclass
>>> @@ -234,6 +234,12 @@ python write_image_manifest () {
>>> # sane default time setting
>>> rootfs_update_timestamp () {
>>> date -u +%4Y%2m%2d%2H%2M%2S >${IMAGE_ROOTFS}/etc/timestamp
>>> +
>>> +   if ${@bb.utils.contains("DISTRO_FEATURES", "systemd", "true", "false", 
>>> d)}; then
>>> +   # touch needs timestamp as [[CC]YY]MMDDhhmm[.ss]
>>> +   TS=$(sed 's/[.]*/&./13' ${IMAGE_ROOTFS}/etc/timestamp)
>>> +   touch -t $TS ${IMAGE_ROOTFS}/var/lib/systemd/clock
>>> +   fi
>>> }
>> 
>> i wonder if this will work with read only rootfs.
> I found no special handling for systemd and /var/lib if IMAGE_FEATURES
> read-only-rootfs is used.
> If timesyncd didn't find /var/lib/systemd/clock it defaults to the configure
> time value und try to write /var/lib/systemd/clock. On read-only it will
> silently fail.
> So I don't see a problem here.

It fixes one case when rootfs is r/w but create another behavior when its r/o
in r/o case /var/lib/systemd must be mounted r/w during boot. So the timesyncd 
service
should check for that directory to exist I have a hunch if thats checked then 
this patch
may not be needed

> 
> Jan
>> 
>>> 
>>> # Prevent X from being started
>>> --
>>> 1.9.1
>>> 
>>> --
>>> ___
>>> Openembedded-core mailing list
>>> Openembedded-core@lists.openembedded.org
>>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>> 
> 
> 



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

Re: [OE-core] [PATCH] gcc: make sure header path is set correctly

[Khem Raj]

> On Jun 15, 2016, at 10:49 PM, Mittal, AnujX  wrote:
> 
> 
> 
>> -Original Message-
>> From: Khem Raj [mailto:raj.k...@gmail.com]
>> Sent: Thursday, June 16, 2016 10:47 AM
>> To: Mittal, AnujX 
>> Cc: openembedded-core@lists.openembedded.org
>> Subject: Re: [OE-core] [PATCH] gcc: make sure header path is set correctly
>> 
>> 
>>> On Jun 14, 2016, at 2:10 AM, Anuj Mittal  wrote:
>>> 
>>> We're setting the native header paths in do_configure_prepend,
>>> and don't need to set them again here.
>>> 
>>> This results in gcc-target not being able to locate the headers
>>> and not being able to detect glibc version, which in turn
>>> results in SSP support not getting detected even though it's available
>>> in libc.
>>> 
>> 
>> what is this being set to in do_conigure_prepend ?
>> that value may not be right for target recipe. For target we are setting 
>> sysroot to /
>> and if we do not have this option set then it will set native-system-headers 
>> dir to
>> be
>> / relative and not cross sysroot relative. So it will use your build hosts 
>> installation
>> for these headers which is not correct either. Have you looked deeper into 
>> why its
>> not
>> finding ssp support inside the cross sysroot?
> 
> It's being set to /usr/include:
> 
>   # teach gcc to find correct target includedir when checking libc ssp 
> support
>   mkdir -p ${B}/gcc
>   echo "NATIVE_SYSTEM_HEADER_DIR = ${SYSTEMHEADERS}" > ${B}/gcc/t-oe
>   cat ${S}/gcc/defaults.h | grep -v "\#endif.*GCC_DEFAULTS_H" > 
> ${B}/gcc/defaults.h.new
>   cat >>${B}/gcc/defaults.h.new <<_EOF
> #define NATIVE_SYSTEM_HEADER_DIR "${SYSTEMHEADERS}"
> #define STANDARD_STARTFILE_PREFIX_1 "${SYSTEMLIBS}"
> #define STANDARD_STARTFILE_PREFIX_2 "${SYSTEMLIBS1}"
> #define SYSTEMLIBS_DIR "${SYSTEMLIBS}"
> #endif /* ! GCC_DEFAULTS_H */
> _EOF
>   mv ${B}/gcc/defaults.h.new ${B}/gcc/defaults.h

ah yes thats the caveat which invalidates the definition of this configure 
option for OE. In this case the patch
is ok. Although, I would like to know what would be downside of not forcing 
NATIVE_SYSTEM_HEADER_DIR via t-oe

> 
> Having set NATIVE_SYSTEM_HEADER_DIR again in gcc-target just results in gcc 
> not being able to find features.h at all, which is present in the target 
> sysroot.
> 
> Because it's not able to find features.h, it just assumes that glibc version 
> available is 0 and hence disables ssp support. Setting 
> NATIVE_SYSTEM_HEADER_DIR to /usr/include just makes sure that 
> target_system_dir in configure script is set to right header path within 
> target sysroot & it can pick up the right header relative to the sysroot.
> 
> When configure option is passed, gcc detects target_system_dir (where 
> features.h is present) to be //usr/include 
> instead of /usr/include.
> 
> I've made sure that its picking up the header from target sysroot rather than 
> my host. My host machine has glibc 2.19 whereas the target sysroot has 2.22
> 
> Thanks,
> Anuj



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

[OE-core] [PATCH] The CMake recipes contain a mismatch between the environmental variable which defines where the Modules are installed and the location where they actually are. This patch fixes the e

[Jose Pardeiro]

Signed-off-by: Jose Pardeiro 
---
 meta/classes/cmake.patch | 20 
 1 file changed, 20 insertions(+)
 create mode 100644 meta/classes/cmake.patch

diff --git a/meta/classes/cmake.patch b/meta/classes/cmake.patch
new file mode 100644
index 000..c9cc9f2
--- /dev/null
+++ b/meta/classes/cmake.patch
@@ -0,0 +1,20 @@
+The CMake recipes contain a mismatch between the environmental variable
+which defines where the Modules are installed and the location where they
+actually are. This patch fixes the environmental variable to point to the
+proper folder defined according to the cmake version.
+
+Signed-off-by: Jose Pardeiro 
+
+diff --git a/cmake.bbclass b/cmake.bbclass
+index 995ddf1..6de4247 100644
+--- a/meta/classes/cmake.bbclass
 b/meta/classes/cmake.bbclass
+@@ -60,7 +60,7 @@ set( ENV{QT_CONF_PATH} ${WORKDIR}/qt.conf )
+ set( CMAKE_INSTALL_RPATH ${OECMAKE_RPATH} )
+
+ # Use native cmake modules
+-set( CMAKE_MODULE_PATH ${STAGING_DATADIR}/cmake/Modules/ )
++set( CMAKE_MODULE_PATH 
${STAGING_DATADIR}/cmake-\${CMAKE_MAJOR_VERSION}.\${CMAKE_MINOR_VERSION}/Modules/
 )
+
+ # add for non /usr/lib libdir, e.g. /usr/lib64
+ set( CMAKE_LIBRARY_PATH ${libdir} ${base_libdir})
-- 
1.9.1

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

Re: [OE-core] [PATCH] rootfs-postcommands: generate /var/lib/systemd/clock

[Jan Remmet]

On Wed, Jun 15, 2016 at 12:14:17PM -0700, Khem Raj wrote:
> 
> > On Jun 15, 2016, at 6:36 AM, Jan Remmet  wrote:
> > 
> > systemd timesyncd check /var/lib/systemd/clock instead of
> > /etc/timestamp.
> > If this file is missing it defaults to TIME_EPOCH. It's set while
> > configuring systemd.
> > 
> > Signed-off-by: Jan Remmet 
> > ---
> > meta/classes/rootfs-postcommands.bbclass | 6 ++
> > 1 file changed, 6 insertions(+)
> > 
> > diff --git a/meta/classes/rootfs-postcommands.bbclass 
> > b/meta/classes/rootfs-postcommands.bbclass
> > index db8b551..0c7b764 100644
> > --- a/meta/classes/rootfs-postcommands.bbclass
> > +++ b/meta/classes/rootfs-postcommands.bbclass
> > @@ -234,6 +234,12 @@ python write_image_manifest () {
> > # sane default time setting
> > rootfs_update_timestamp () {
> > date -u +%4Y%2m%2d%2H%2M%2S >${IMAGE_ROOTFS}/etc/timestamp
> > +
> > +   if ${@bb.utils.contains("DISTRO_FEATURES", "systemd", "true", "false", 
> > d)}; then
> > +   # touch needs timestamp as [[CC]YY]MMDDhhmm[.ss]
> > +   TS=$(sed 's/[.]*/&./13' ${IMAGE_ROOTFS}/etc/timestamp)
> > +   touch -t $TS ${IMAGE_ROOTFS}/var/lib/systemd/clock
> > +   fi
> > }
> 
> i wonder if this will work with read only rootfs.
I found no special handling for systemd and /var/lib if IMAGE_FEATURES
read-only-rootfs is used.
If timesyncd didn't find /var/lib/systemd/clock it defaults to the configure
time value und try to write /var/lib/systemd/clock. On read-only it will
silently fail.
So I don't see a problem here.

Jan
> 
> > 
> > # Prevent X from being started
> > --
> > 1.9.1
> > 
> > --
> > ___
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-core
> 


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

Re: [OE-core] [PATCH 1/1] useradd-staticids.bbclass: Make sure opened files are closed

[George McCollister]

On Thu, Jun 9, 2016 at 6:07 PM, Peter Kjellerstedt
 wrote:
> This avoids warnings about unclosed files with Python 3.
>
> Signed-off-by: Peter Kjellerstedt 
> ---
>  meta/classes/useradd-staticids.bbclass | 30 +-
>  1 file changed, 17 insertions(+), 13 deletions(-)
>
> diff --git a/meta/classes/useradd-staticids.bbclass 
> b/meta/classes/useradd-staticids.bbclass
> index a9b506d..440c0e3 100644
> --- a/meta/classes/useradd-staticids.bbclass
> +++ b/meta/classes/useradd-staticids.bbclass
> @@ -4,6 +4,7 @@ def update_useradd_static_config(d):
>  import argparse
>  import itertools
>  import re
> +import errno
>
>  class myArgumentParser( argparse.ArgumentParser ):
>  def _print_message(self, message, file=None):
> @@ -30,19 +31,22 @@ def update_useradd_static_config(d):
>  are set)."""
>  id_table = dict()
>  for conf in file_list.split():
> -if os.path.exists(conf):
> -f = open(conf, "r")
> -for line in f:
> -if line.startswith('#'):
> -continue
> -# Make sure there always are at least exp_fields 
> elements in
> -# the field list. This allows for leaving out trailing
> -# colons in the files.
> -fields = list_extend(line.rstrip().split(":"), 
> exp_fields)
> -if fields[0] not in id_table:
> -id_table[fields[0]] = fields
> -else:
> -id_table[fields[0]] = list(itertools.imap(lambda x, 
> y: x or y, fields, id_table[fields[0]]))
> +try:
> +with open(conf, "r") as f:
> +for line in f:
> +if line.startswith('#'):
> +continue
> +# Make sure there always are at least exp_fields
> +# elements in the field list. This allows for leaving
> +# out trailing colons in the files.
> +fields = list_extend(line.rstrip().split(":"), 
> exp_fields)
> +if fields[0] not in id_table:
> +id_table[fields[0]] = fields
> +else:
> +id_table[fields[0]] = list(itertools.imap(lambda 
> x, y: x or y, fields, id_table[fields[0]]))
This is still broken for me. As far as I can tell itertools.imap
doesn't exist in Python 3.

> +except IOError as e:
> +if e.errno == errno.ENOENT:
> +pass
>
>  return id_table
>
> --
> 2.8.3
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] qemuppc kernel doesn't build with GCC 4.9 on korgoth

[Pascal Bach]

>> On Jun 15, 2016, at 5:31 AM, Pascal Bach  wrote:
>>
>> Hi
>>
>> I tried to build qemuppc on the latest korgoth branch using the GCC 4.9.3 
>> from OE-core.
>>
>> The problem is that i get an error when trying to build the kernel.
>> I was able to trace the issue back to this commit:
>> https://github.com/openembedded/openembedded-core/commit/7a51776a830167e43cbd185505f62f328704e271
>>
>> And i can confirm that removing TARGET_CC_KERNEL_ARCH = "-mno-spe" from 
>> qemuppc.conf makes it work again.
>>
>> The question is how to best solve this?
>> Do the changes for GCC 5.3.0 that done in the commit mentioned above also 
>> need to be applied to 4.9?
>> Or is it just not supported to build qemuppc with GCC 4.9?
>>
> back port the gcc patch to 4.9
I just noticed it is already backported to 4.9 as 
0049-Enable-SPE-AltiVec-generation-on-powepc-linux-target.patch
Is anybody else using a powerpc machine with Yocto2.1 and GCC4.9?

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

[OE-core] [PATCH] autotools: ensure Makefile exists in do_compile

[Ross Burton]

If a recipe is using the autotools class then presumably it is using Makefiles.
However the default do_compile() is forgiving and silently handles a missing
makefile, which means that if a recipe is using a hand-coded static Makefile
(e.g. git) but doesn't use brokensep the recipe will fail in do_install.

To make debugging this easier, override do_compile in autotools so that it fails
if a Makefile isn't present.

Signed-off-by: Ross Burton 
---
 meta/classes/autotools.bbclass | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/meta/classes/autotools.bbclass b/meta/classes/autotools.bbclass
index 03a61c3..1c884b4 100644
--- a/meta/classes/autotools.bbclass
+++ b/meta/classes/autotools.bbclass
@@ -312,6 +312,10 @@ autotools_do_configure() {
fi
 }
 
+autotools_do_compile() {
+oe_runmake
+}
+
 autotools_do_install() {
oe_runmake 'DESTDIR=${D}' install
# Info dir listing isn't interesting at this point so remove it if it 
exists.
@@ -322,6 +326,6 @@ autotools_do_install() {
 
 inherit siteconfig
 
-EXPORT_FUNCTIONS do_configure do_install
+EXPORT_FUNCTIONS do_configure do_compile do_install
 
 B = "${WORKDIR}/build"
-- 
2.8.0.rc3

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

Re: [OE-core] [PATCH 4/4] pointercal-xinput: add a dummy calibration file for qemu

[Maxin B. John]

Hi,

On Thu, Jun 16, 2016 at 09:43:40AM +0100, Richard Purdie wrote:
> On Thu, 2016-06-16 at 11:05 +0300, Maxin B. John wrote:
> > Hi RP,
> > 
> > On Wed, Jun 15, 2016 at 05:58:18PM +0100, Richard Purdie wrote:
> > > On Wed, 2016-06-15 at 16:13 +0300, Maxin B. John wrote:
> > > > In qemu, the emulated PS/2 mouse reports itself as an "absolute
> > > > coordinate"
> > > > device and that makes xinput_calibrator think it could be
> > > > calibrated.
> > > > 
> > > > Add a dummy calibration file as a work around to prevent
> > > > xinput_calibrator from
> > > > popping up on every boot in qemu.
> > > > 
> > > > [YOCTO #8380]
> > > > 
> > > > Signed-off-by: Maxin B. John 
> > > > Signed-off-by: Jussi Kukkonen 
> > > 
> > > This doesn't sound right. In qemu, we add a usb touchpad which
> > > allows
> > > absolute coordinate entry, which means qemu doesn't have to grab
> > > the
> > > mouse.
> > > 
> > > Are there two devices? A mouse shouldn't be seen as an absolute
> > > coordinate device.
> > 
> > Yes, both qemu monitor and xinput_calibrator in target shows two
> > devices:
> > 
> > (qemu) info mice
> >   Mouse #2: QEMU PS/2 Mouse
> >   * Mouse #3: QEMU HID Tablet (absolute)
> > 
> > #  xinput_calibrator --list
> >  Device "QEMU QEMU USB Tablet" id=8
> >  Device "ImExPS/2 Generic Explorer Mouse" id=9
> 
> So with these patches, are we still calibrating the tablet input?

We won't be calibrating tablet input in qemu targets.This patch is supposed
to be a work-around to avoid mouse input calibration only in qemu targets.

> pointercal ships default calibrations for that under the current setup
> but those likely aren't compatible with xinput and we'd need the same
> thing but for xinput here?

Yes, the default values shipped by pointercal aren't compatible with xinput.

> Cheers,
> Richard

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

[OE-core] couple trivial(?) questions regarding RPM revision/version numbers

[Robert P. J. Day]

  not at my dev machine at the moment; otherwise, i could just test
this but i'd probably still want clarification, anyway.

  so, i'm well aware that a single recipe can generate numerous (in my
case, rpm) package files. basic case: a recipe can generate the "base"
package, a "doc" package, a "dev" package, and so on and so on. no
problem there.

  first clarification -- regardless of how versioning and revisioning
is being done, *all* packages generated from a single recipe during
the same build have to have the same version and revision number, yes?
i can't imagine how that couldn't be true, but i've been surprised
before.

  next question -- if any part of the base content for a recipe
changes and that recipe is processed again, all generated packages
have to jump to the next version/revision together, correct? again,
this seems obvious, but i want to make absolutely sure.

  so if i have a recipe for which i make a tiny change that affects
the content of only one of the generated packages, if the revision
number increases from, say, "r4" to "r5", *all* of the generated
packages go along for the ride, even all the rest of the packages
whose content did *not* change. so i could end up with a slew of
generated packages whose revision number increased, even though
absolutely nothing about the package content actually changed. so far,
so good?

  and finally, if the above is accurate, at some point, if i get an
updated recipe, and rebuild never package files from it, and do an
update, a lot of those "newer" packages might not contain any actual
changes, and if that happens, does the rpm update operation actually
do any work?

  i understand that the end result will be(?) that all of those
related packages will now have the newer revision number once the
update is done, but it's entirely possible (even normal) for there to
have been no change effected by that "update". and in cases like that,
even if one of my packages was "updated":

  rday-doc-1.0-r0  --->  rday-doc-1.0-r1

the content of that package could be unchanged. and if that happens
(and if everything i've been saying so far is true), is rpm smart
enough to not do any work in cases like that, and just quietly bump up
the version number of the installed package and move on?

  is there anything here i'm missing or misunderstanding? thanks.

rday

-- 


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

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


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

[OE-core] [PATCH 5/5] libmad: replace with mpg123

[Alexander Kanavin]

mpg123 recipe is taken from meta-oe and updated to latest release.
Also audiofile dependency is dropped as it's not actually used anywhere.

[YOCTO #6020]

Signed-off-by: Alexander Kanavin 
---
 .../gstreamer/gstreamer1.0-plugins-ugly.inc|  2 +-
 .../libmad/libmad/add-pkgconfig.patch  | 70 --
 .../libmad/libmad/automake-foreign.patch   | 12 
 .../libmad/fix_for_mips_with_gcc-4.5.0.patch   | 33 --
 .../libmad/libmad/no-force-mem.patch   | 18 --
 .../libmad/libmad/obsolete_automake_macros.patch   | 14 -
 meta/recipes-multimedia/libmad/libmad_0.15.1b.bb   | 36 ---
 meta/recipes-multimedia/mpg123/mpg123_1.23.4.bb| 63 +++
 8 files changed, 64 insertions(+), 184 deletions(-)
 delete mode 100644 meta/recipes-multimedia/libmad/libmad/add-pkgconfig.patch
 delete mode 100644 meta/recipes-multimedia/libmad/libmad/automake-foreign.patch
 delete mode 100644 
meta/recipes-multimedia/libmad/libmad/fix_for_mips_with_gcc-4.5.0.patch
 delete mode 100644 meta/recipes-multimedia/libmad/libmad/no-force-mem.patch
 delete mode 100644 
meta/recipes-multimedia/libmad/libmad/obsolete_automake_macros.patch
 delete mode 100644 meta/recipes-multimedia/libmad/libmad_0.15.1b.bb
 create mode 100644 meta/recipes-multimedia/mpg123/mpg123_1.23.4.bb

diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-ugly.inc 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-ugly.inc
index 4582e5b..708ad7a 100644
--- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-ugly.inc
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-ugly.inc
@@ -9,7 +9,7 @@ inherit gettext
 
 PACKAGECONFIG ??= " \
 ${GSTREAMER_ORC} \
-a52dec lame mad mpeg2dec \
+a52dec lame mpg123 mpeg2dec \
 "
 
 PACKAGECONFIG[a52dec]   = "--enable-a52dec,--disable-a52dec,liba52"
diff --git a/meta/recipes-multimedia/libmad/libmad/add-pkgconfig.patch 
b/meta/recipes-multimedia/libmad/libmad/add-pkgconfig.patch
deleted file mode 100644
index b49dc8c..000
--- a/meta/recipes-multimedia/libmad/libmad/add-pkgconfig.patch
+++ /dev/null
@@ -1,70 +0,0 @@
-Here is a patch for adding pkg-config support to libmad.
-It would make life a bit easier for distro maintainers if this was applied.
-In case you didn't know, pkg-config is a tool for providing LDFLAGS and
-CFLAGS for packages using shared libraries. It's on freedesktop.org.
-Debian has already been distributing the pkg-config file mad.pc with
-libmad for some time, and people developing on debian (notably xmms2 
-developers) have started relying on this support being present, causing
-some confusion for people installing from source and on some BSDs which
-do not provide mad.pc (google: pkgconfig libmad).
-
-EMH
-
-Upstream-Status: Inappropriate [configuration]
-
---h31gzZEtNLTqOjlF
-Content-Type: text/plain; charset=us-ascii
-Content-Disposition: attachment; 
filename=libmad-0.15.1b-pkgconfig.patch
-
-diff -Naur libmad-0.15.1b.old/configure.ac libmad-0.15.1b/configure.ac
 libmad-0.15.1b.old/configure.ac2004-01-23 10:41:32.0 +0100
-+++ libmad-0.15.1b/configure.ac2004-08-07 02:25:24.633462168 +0200
-@@ -429,5 +429,5 @@
- dnl AC_SUBST(LTLIBOBJS)
- 
- AC_CONFIG_FILES([Makefile msvc++/Makefile  \
--  libmad.list])
-+  libmad.list mad.pc])
- AC_OUTPUT
-diff -Naur libmad-0.15.1b.old/mad.pc.in libmad-0.15.1b/mad.pc.in
 libmad-0.15.1b.old/mad.pc.in   1970-01-01 01:00:00.0 +0100
-+++ libmad-0.15.1b/mad.pc.in   2004-08-07 02:04:59.617692872 +0200
-@@ -0,0 +1,14 @@
-+# libmad pkg-config source file
-+
-+prefix=@prefix@
-+exec_prefix=@exec_prefix@
-+libdir=@libdir@
-+includedir=@includedir@
-+
-+Name: mad
-+Description: MPEG Audio Decoder
-+Version: @VERSION@
-+Requires:
-+Conflicts:
-+Libs: -L${libdir} -lmad -lm
-+Cflags: -I${includedir}
-diff -Naur libmad-0.15.1b.old/Makefile.am libmad-0.15.1b/Makefile.am
 libmad-0.15.1b.old/Makefile.am 2004-02-17 03:02:03.0 +0100
-+++ libmad-0.15.1b/Makefile.am 2004-08-07 02:03:19.859858368 +0200
-@@ -24,6 +24,9 @@
- SUBDIRS = 
- DIST_SUBDIRS =msvc++
- 
-+pkgconfigdir =$(libdir)/pkgconfig
-+pkgconfig_DATA =  mad.pc
-+
- lib_LTLIBRARIES = libmad.la
- include_HEADERS = mad.h
- 
-@@ -34,7 +37,8 @@
- minimad_LDADD =   libmad.la
- 
- EXTRA_DIST =  mad.h.sed  \
--  CHANGES COPYRIGHT CREDITS README TODO VERSION
-+  CHANGES COPYRIGHT CREDITS README TODO VERSION \
-+  mad.pc.in
- 
- exported_headers =version.h fixed.h bit.h timer.h stream.h frame.h  \
-   synth.h decoder.h
-
diff --git a/meta/recipes-multimedia/libmad/libmad/automake-foreign.patch 
b/meta/recipes-multimedia/libmad/libmad/automake-foreign.patch
deleted file mode 100644
index 3e54424..000
--- 

[OE-core] [PATCH 2/5] security_flags.inc: add python3-pycairo and libnewt-python to no-pie exception list

[Alexander Kanavin]

Signed-off-by: Alexander Kanavin 
---
 meta/conf/distro/include/security_flags.inc | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/conf/distro/include/security_flags.inc 
b/meta/conf/distro/include/security_flags.inc
index cd2b964..a7be185 100644
--- a/meta/conf/distro/include/security_flags.inc
+++ b/meta/conf/distro/include/security_flags.inc
@@ -65,6 +65,7 @@ SECURITY_CFLAGS_pn-libcap = "${SECURITY_NO_PIE_CFLAGS}"
 SECURITY_CFLAGS_pn-libgcc = "${SECURITY_NO_PIE_CFLAGS}"
 SECURITY_CFLAGS_pn-libid3tag = "${SECURITY_NO_PIE_CFLAGS}"
 SECURITY_CFLAGS_pn-libnewt = "${SECURITY_NO_PIE_CFLAGS}"
+SECURITY_CFLAGS_pn-libnewt-python = "${SECURITY_NO_PIE_CFLAGS}"
 SECURITY_CFLAGS_pn-libglu = "${SECURITY_NO_PIE_CFLAGS}"
 SECURITY_CFLAGS_pn-libpcap = "${SECURITY_NO_PIE_CFLAGS}"
 SECURITY_CFLAGS_pn-libpcre = "${SECURITY_NO_PIE_CFLAGS}"
@@ -80,6 +81,7 @@ SECURITY_CFLAGS_pn-python-pycurl = "${SECURITY_NO_PIE_CFLAGS}"
 SECURITY_CFLAGS_pn-python-smartpm = "${SECURITY_NO_PIE_CFLAGS}"
 SECURITY_CFLAGS_pn-python-numpy = "${SECURITY_NO_PIE_CFLAGS}"
 SECURITY_CFLAGS_pn-python3-numpy = "${SECURITY_NO_PIE_CFLAGS}"
+SECURITY_CFLAGS_pn-python3-pycairo = "${SECURITY_NO_PIE_CFLAGS}"
 SECURITY_CFLAGS_pn-python3 = "${SECURITY_NO_PIE_CFLAGS}"
 # Revert RPM to using internally supported values
 SECURITY_CFLAGS_pn-rpm = "${lcl_maybe_fortify} -fstack-protector"
-- 
2.8.1

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

[OE-core] [PATCH 3/5] security_flags.inc: add -fPIC to SECURITY_NO_PIE_CFLAGS

[Alexander Kanavin]

The packages that break due to -fpie can be still built with -fPIC.

[YOCTO #9486]

Signed-off-by: Alexander Kanavin 
---
 meta/conf/distro/include/security_flags.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/conf/distro/include/security_flags.inc 
b/meta/conf/distro/include/security_flags.inc
index a7be185..26804bd 100644
--- a/meta/conf/distro/include/security_flags.inc
+++ b/meta/conf/distro/include/security_flags.inc
@@ -13,7 +13,7 @@ lcl_maybe_fortify = 
"${@base_conditional('DEBUG_BUILD','1','','-D_FORTIFY_SOURCE
 SECURITY_STRINGFORMAT ?= "-Wformat -Wformat-security -Werror=format-security"
 
 SECURITY_CFLAGS ?= "-fstack-protector-strong -pie -fpie ${lcl_maybe_fortify} 
${SECURITY_STRINGFORMAT}"
-SECURITY_NO_PIE_CFLAGS ?= "-fstack-protector-strong ${lcl_maybe_fortify} 
${SECURITY_STRINGFORMAT}"
+SECURITY_NO_PIE_CFLAGS ?= "-fPIC -fstack-protector-strong ${lcl_maybe_fortify} 
${SECURITY_STRINGFORMAT}"
 
 SECURITY_LDFLAGS ?= "-fstack-protector-strong -Wl,-z,relro,-z,now"
 SECURITY_X_LDFLAGS ?= "-fstack-protector-strong -Wl,-z,relro"
-- 
2.8.1

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

[OE-core] [PATCH 4/5] security_flags.inc: add epiphany to SECURITY_NO_PIE_CFLAGS

[Alexander Kanavin]

Otherwise there is a QA warning about relocations in .text

Signed-off-by: Alexander Kanavin 
---
 meta/conf/distro/include/security_flags.inc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/conf/distro/include/security_flags.inc 
b/meta/conf/distro/include/security_flags.inc
index 26804bd..ea00bdd 100644
--- a/meta/conf/distro/include/security_flags.inc
+++ b/meta/conf/distro/include/security_flags.inc
@@ -38,6 +38,7 @@ SECURITY_CFLAGS_pn-glibc = ""
 SECURITY_CFLAGS_pn-glibc-initial = ""
 SECURITY_CFLAGS_pn-elfutils = "${SECURITY_NO_PIE_CFLAGS}"
 SECURITY_CFLAGS_pn-enchant = "${SECURITY_NO_PIE_CFLAGS}"
+SECURITY_CFLAGS_pn-epiphany = "${SECURITY_NO_PIE_CFLAGS}"
 SECURITY_CFLAGS_pn-expect = "${SECURITY_NO_PIE_CFLAGS}"
 SECURITY_CFLAGS_pn-flac = "${SECURITY_NO_PIE_CFLAGS}"
 SECURITY_CFLAGS_pn-flex = "${SECURITY_NO_PIE_CFLAGS}"
-- 
2.8.1

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

[OE-core] [PATCH 1/5] security_flags.inc: add SECURITY_NO_PIE_CFLAGS to libgcc and gcc-sanitizers

[Alexander Kanavin]

These recipes no longer seem to need full exclusion from security hardening.

The rest (glibc, gcc-runtime, valgrind, grub, grub-efi, uclibc) still do.

[YOCTO #9489]

Signed-off-by: Alexander Kanavin 
---
 meta/conf/distro/include/security_flags.inc | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/meta/conf/distro/include/security_flags.inc 
b/meta/conf/distro/include/security_flags.inc
index ea1d4e5..cd2b964 100644
--- a/meta/conf/distro/include/security_flags.inc
+++ b/meta/conf/distro/include/security_flags.inc
@@ -43,7 +43,7 @@ SECURITY_CFLAGS_pn-flac = "${SECURITY_NO_PIE_CFLAGS}"
 SECURITY_CFLAGS_pn-flex = "${SECURITY_NO_PIE_CFLAGS}"
 SECURITY_CFLAGS_pn-gcc = "${SECURITY_NO_PIE_CFLAGS}"
 SECURITY_CFLAGS_pn-gcc-runtime = ""
-SECURITY_CFLAGS_pn-gcc-sanitizers = ""
+SECURITY_CFLAGS_pn-gcc-sanitizers = "${SECURITY_NO_PIE_CFLAGS}"
 SECURITY_CFLAGS_pn-gdb = "${SECURITY_NO_PIE_CFLAGS}"
 SECURITY_CFLAGS_pn-gmp = "${SECURITY_NO_PIE_CFLAGS}"
 SECURITY_CFLAGS_pn-gnutls = "${SECURITY_NO_PIE_CFLAGS}"
@@ -62,7 +62,7 @@ SECURITY_CFLAGS_pn-kexec-tools = "${SECURITY_NO_PIE_CFLAGS}"
 SECURITY_CFLAGS_pn-iptables = "${SECURITY_NO_PIE_CFLAGS}"
 SECURITY_CFLAGS_pn-libaio = "${SECURITY_NO_PIE_CFLAGS}"
 SECURITY_CFLAGS_pn-libcap = "${SECURITY_NO_PIE_CFLAGS}"
-SECURITY_CFLAGS_pn-libgcc = ""
+SECURITY_CFLAGS_pn-libgcc = "${SECURITY_NO_PIE_CFLAGS}"
 SECURITY_CFLAGS_pn-libid3tag = "${SECURITY_NO_PIE_CFLAGS}"
 SECURITY_CFLAGS_pn-libnewt = "${SECURITY_NO_PIE_CFLAGS}"
 SECURITY_CFLAGS_pn-libglu = "${SECURITY_NO_PIE_CFLAGS}"
@@ -109,10 +109,8 @@ TARGET_CFLAGS_append_class-target = " ${SECURITY_CFLAGS}"
 TARGET_LDFLAGS_append_class-target = " ${SECURITY_LDFLAGS}"
 
 SECURITY_LDFLAGS_remove_pn-gcc-runtime = "-fstack-protector-strong"
-SECURITY_LDFLAGS_remove_pn-gcc-sanitizers = "-fstack-protector-strong"
 SECURITY_LDFLAGS_remove_pn-glibc = "-fstack-protector-strong"
 SECURITY_LDFLAGS_remove_pn-glibc-initial = "-fstack-protector-strong"
-SECURITY_LDFLAGS_remove_pn-libgcc = "-fstack-protector-strong"
 SECURITY_LDFLAGS_remove_pn-uclibc = "-fstack-protector-strong"
 SECURITY_LDFLAGS_remove_pn-uclibc-initial = "-fstack-protector-strong"
 SECURITY_LDFLAGS_pn-xf86-video-fbdev = "${SECURITY_X_LDFLAGS}"
-- 
2.8.1

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

[OE-core] [PATCH 1/1] recipetool/create.py: fix LICENSE value

[Chen Qi]

When there multiple license in a repo, the LICENSE value be created as
something like "LGPLv2.1 GPLv2", which causes the following warning.

LICENSE value "LGPLv2.1 GPLv2" has an invalid format - license names must
be separated by the following characters to indicate the license selection: &|()

Fix it by using '&' to join multiple licenses.

Signed-off-by: Chen Qi 
---
 scripts/lib/recipetool/create.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/lib/recipetool/create.py b/scripts/lib/recipetool/create.py
index 1297428..b3fd78b 100644
--- a/scripts/lib/recipetool/create.py
+++ b/scripts/lib/recipetool/create.py
@@ -504,7 +504,7 @@ def create_recipe(args):
 licenses = [pkg_license]
 else:
 lines_before.append('# NOTE: Original package metadata indicates 
license is: %s' % pkg_license)
-lines_before.append('LICENSE = "%s"' % ' '.join(licenses))
+lines_before.append('LICENSE = "%s"' % ' & '.join(licenses))
 lines_before.append('LIC_FILES_CHKSUM = "%s"' % ' \\\n
'.join(lic_files_chksum))
 lines_before.append('')
 
-- 
1.9.1

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

[OE-core] [PATCH 0/1] recipetool/create.py: fix LICENSE value

[Chen Qi]

The following changes since commit 7b4b67da33beff736dc0286ea24e3860480f9650:

  directfb: fix client->gfx_state initialisation (2016-06-15 18:13:09 +0100)

are available in the git repository at:

  git://git.openembedded.org/openembedded-core-contrib ChenQi/recipetool-license
  
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=ChenQi/recipetool-license

Chen Qi (1):
  recipetool/create.py: fix LICENSE value

 scripts/lib/recipetool/create.py | 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] [PATCH] classes/rm_work: use the idle I/O scheduler class

[Patrick Ohly]

On Tue, 2016-06-14 at 16:18 +0100, Ross Burton wrote:
> As rm_work is just cleanup it shouldn't starve more important tasks such as
> do_compile of I/O, so use BB_TASK_IONICE_LEVEL to run the task in the idle
> scheduler class.

Whether that's desirable depends a lot on the goals for rm_work: when I
tried to use it for TravisCI to get around some pretty tight disk space
constraints, I found that do_rm_work was often not scheduled early
enough because other tasks generating more files had higher priority.

Reducing the IO priority of do_rm_work may have the same effect: it
runs, but then instead of removing files, the system produces more of
them, thus increasing the risk of exhausting the disk space.

I suspect a lot of benchmarking will be needed to determine what really
works well and what doesn't.

I ended up writing a custom scheduler for running under TravisCI:
https://github.com/01org/meta-intel-iot-security/blob/master/scripts/rmwork.py

That orders do_rm_work before any other task and also orders all tasks
related to single recipe so that they run together, thus making it
possible to clean up after do_build sooner. As an additional tweak it
distinguishes between "compile" and "cleanup" tasks and can run
"cleanup" tasks when the normal scheduler wouldn't because
BB_NUMBER_THREADS is reached.

But it has the same problem: not enough benchmarking to really quantify
the effect. All I know is that I stopped running out of disk space under
TravisCI ;-}

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.



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

[OE-core] [PATCH] packagegroup-core-device-devel: add binutils-symlinks

[Ross Burton]

This packagegroup previously included oprofileui-server which indirectly
depended on binutils-symlinks.  Since the removal of oprofileui-server
binutils-symlinks wasn't pulled in, which makes a packagegroup apparently for
development on the target fairly useless (and also broke QA).

Signed-off-by: Ross Burton 
---
 meta/recipes-devtools/packagegroups/packagegroup-core-device-devel.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/meta/recipes-devtools/packagegroups/packagegroup-core-device-devel.bb 
b/meta/recipes-devtools/packagegroups/packagegroup-core-device-devel.bb
index d20eae7..edee474 100644
--- a/meta/recipes-devtools/packagegroups/packagegroup-core-device-devel.bb
+++ b/meta/recipes-devtools/packagegroups/packagegroup-core-device-devel.bb
@@ -12,5 +12,5 @@ RDEPENDS_${PN} = "\
 distcc-config \
 nfs-export-root \
 bash \
+binutils-symlinks \
 "
-
-- 
2.8.0.rc3

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

Re: [OE-core] [PATCH 4/4] pointercal-xinput: add a dummy calibration file for qemu

[Richard Purdie]

On Thu, 2016-06-16 at 11:05 +0300, Maxin B. John wrote:
> Hi RP,
> 
> On Wed, Jun 15, 2016 at 05:58:18PM +0100, Richard Purdie wrote:
> > On Wed, 2016-06-15 at 16:13 +0300, Maxin B. John wrote:
> > > In qemu, the emulated PS/2 mouse reports itself as an "absolute
> > > coordinate"
> > > device and that makes xinput_calibrator think it could be
> > > calibrated.
> > > 
> > > Add a dummy calibration file as a work around to prevent
> > > xinput_calibrator from
> > > popping up on every boot in qemu.
> > > 
> > > [YOCTO #8380]
> > > 
> > > Signed-off-by: Maxin B. John 
> > > Signed-off-by: Jussi Kukkonen 
> > 
> > This doesn't sound right. In qemu, we add a usb touchpad which
> > allows
> > absolute coordinate entry, which means qemu doesn't have to grab
> > the
> > mouse.
> > 
> > Are there two devices? A mouse shouldn't be seen as an absolute
> > coordinate device.
> 
> Yes, both qemu monitor and xinput_calibrator in target shows two
> devices:
> 
> (qemu) info mice
>   Mouse #2: QEMU PS/2 Mouse
>   * Mouse #3: QEMU HID Tablet (absolute)
> 
> #  xinput_calibrator --list
>  Device "QEMU QEMU USB Tablet" id=8
>  Device "ImExPS/2 Generic Explorer Mouse" id=9

So with these patches, are we still calibrating the tablet input?

pointercal ships default calibrations for that under the current setup
but those likely aren't compatible with xinput and we'd need the same
thing but for xinput here?

Cheers,

Richard


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

Re: [OE-core] [PATCH 4/4] pointercal-xinput: add a dummy calibration file for qemu

[Maxin B. John]

Hi RP,

On Wed, Jun 15, 2016 at 05:58:18PM +0100, Richard Purdie wrote:
> On Wed, 2016-06-15 at 16:13 +0300, Maxin B. John wrote:
> > In qemu, the emulated PS/2 mouse reports itself as an "absolute
> > coordinate"
> > device and that makes xinput_calibrator think it could be calibrated.
> > 
> > Add a dummy calibration file as a work around to prevent
> > xinput_calibrator from
> > popping up on every boot in qemu.
> > 
> > [YOCTO #8380]
> > 
> > Signed-off-by: Maxin B. John 
> > Signed-off-by: Jussi Kukkonen 
> 
> This doesn't sound right. In qemu, we add a usb touchpad which allows
> absolute coordinate entry, which means qemu doesn't have to grab the
> mouse.
> 
> Are there two devices? A mouse shouldn't be seen as an absolute
> coordinate device.

Yes, both qemu monitor and xinput_calibrator in target shows two devices:

(qemu) info mice
  Mouse #2: QEMU PS/2 Mouse
  * Mouse #3: QEMU HID Tablet (absolute)

#  xinput_calibrator --list
 Device "QEMU QEMU USB Tablet" id=8
 Device "ImExPS/2 Generic Explorer Mouse" id=9

> Cheers,
> 
> Richard

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

[OE-core] [PATCH] squid: don't build squid-conf-tests binary

[Alexandru Moise]

autotools ends up stripping this binary which ends up causing
QA Errors at do_package. Remove it.

Signed-off-by: Alexandru Moise 
---
 ...squid-don-t-build-squid-conf-tests-binary.patch | 30 ++
 .../recipes-daemons/squid/squid_3.5.7.bb   |  1 +
 2 files changed, 31 insertions(+)
 create mode 100644 
meta-networking/recipes-daemons/squid/files/0001-squid-don-t-build-squid-conf-tests-binary.patch

diff --git 
a/meta-networking/recipes-daemons/squid/files/0001-squid-don-t-build-squid-conf-tests-binary.patch
 
b/meta-networking/recipes-daemons/squid/files/0001-squid-don-t-build-squid-conf-tests-binary.patch
new file mode 100644
index 000..82cd0b0
--- /dev/null
+++ 
b/meta-networking/recipes-daemons/squid/files/0001-squid-don-t-build-squid-conf-tests-binary.patch
@@ -0,0 +1,30 @@
+From 75f4072e6fc9704713629c87eec750ff708135c4 Mon Sep 17 00:00:00 2001
+From: Alexandru Moise 
+Date: Thu, 16 Jun 2016 10:01:41 +0300
+Subject: [PATCH] squid: don't build squid-conf-tests binary
+
+autotools ends up stripping this binary which ends up causing
+QA Errors at do_package. Remove it.
+
+Signed-off-by: Alexandru Moise 
+---
+ test-suite/Makefile.am | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+diff --git a/test-suite/Makefile.am b/test-suite/Makefile.am
+index b9c412d..0471bf0 100644
+--- a/test-suite/Makefile.am
 b/test-suite/Makefile.am
+@@ -43,8 +43,7 @@ TESTS += debug \
+   MemPoolTest\
+   mem_node_test\
+   mem_hdr_test\
+-  $(ESI_TESTS) \
+-  squid-conf-tests
++  $(ESI_TESTS)
+ 
+ ## Sort by alpha - any build failures are significant.
+ check_PROGRAMS += debug \
+-- 
+2.7.4
+
diff --git a/meta-networking/recipes-daemons/squid/squid_3.5.7.bb 
b/meta-networking/recipes-daemons/squid/squid_3.5.7.bb
index b571e29..2d243fb 100644
--- a/meta-networking/recipes-daemons/squid/squid_3.5.7.bb
+++ b/meta-networking/recipes-daemons/squid/squid_3.5.7.bb
@@ -21,6 +21,7 @@ SRC_URI = 
"http://www.squid-cache.org/Versions/v${MAJ_VER}/${MIN_VER}/${BPN}-${P
file://volatiles.03_squid \
file://CVE-2016-3947.patch \
file://CVE-2016-4553.patch \
+   file://0001-squid-don-t-build-squid-conf-tests-binary.patch \
 "
 
 LIC_FILES_CHKSUM = "file://COPYING;md5=c492e2d6d32ec5c1aad0e0609a141ce9 \
-- 
2.7.4

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

Re: [OE-core] [oe-core][PATCH] binutils: fix the incorrect assembling for ppc wait instruction

[Zhenhua Luo]

I will send the patch to binutils upstream. 


Best Regards,

Zhenhua

> -Original Message-
> From: Khem Raj [mailto:raj.k...@gmail.com]
> Sent: Thursday, June 16, 2016 5:13 AM
> To: Zhenhua Luo 
> Cc: Patches and discussions about the oe-core layer  c...@lists.openembedded.org>
> Subject: Re: [OE-core] [oe-core][PATCH] binutils: fix the incorrect assembling
> for ppc wait instruction
> 
> On Sun, Jun 12, 2016 at 2:02 AM, Zhenhua Luo  wrote:
> > The wait mnemonic for ppc targets is incorrectly assembled into
> > 0x7c3c due to duplicated address definition with waitasec
> > instruction. The issue causes kernel boot calltrace for ppc targets when 
> > wait
> instruction is executed.
> >
> > Signed-off-by: Zhenhua Luo 
> > ---
> >  meta/recipes-devtools/binutils/binutils-2.26.inc   |  1 +
> >  ...ncorrect-assembling-for-ppc-wait-mnemonic.patch | 36
> > ++
> >  2 files changed, 37 insertions(+)
> >  create mode 100644
> > meta/recipes-devtools/binutils/binutils/0015-fix-the-incorrect-assembl
> > ing-for-ppc-wait-mnemonic.patch
> >
> > diff --git a/meta/recipes-devtools/binutils/binutils-2.26.inc
> > b/meta/recipes-devtools/binutils/binutils-2.26.inc
> > index 6d535fc..6d77452 100644
> > --- a/meta/recipes-devtools/binutils/binutils-2.26.inc
> > +++ b/meta/recipes-devtools/binutils/binutils-2.26.inc
> > @@ -34,6 +34,7 @@ SRC_URI = "\
> >   file://0012-Add-support-for-Netlogic-XLP.patch \
> >   
> > file://0013-Fix-GOT-address-computations-in-initial-PLT-entries-.patch \
> >   file://0014-Correct-nios2-_gp-address-computation.patch \
> > +
> > + file://0015-fix-the-incorrect-assembling-for-ppc-wait-mnemonic.patch
> > + \
> >  "
> >  S  = "${WORKDIR}/git"
> >
> > diff --git
> > a/meta/recipes-devtools/binutils/binutils/0015-fix-the-incorrect-assem
> > bling-for-ppc-wait-mnemonic.patch
> > b/meta/recipes-devtools/binutils/binutils/0015-fix-the-incorrect-assem
> > bling-for-ppc-wait-mnemonic.patch
> > new file mode 100644
> > index 000..5aa5e31
> > --- /dev/null
> > +++ b/meta/recipes-devtools/binutils/binutils/0015-fix-the-incorrect-a
> > +++ ssembling-for-ppc-wait-mnemonic.patch
> > @@ -0,0 +1,36 @@
> > +From 78decbeb84fb60db4e549ad3e8eb34e030e96d39 Mon Sep 17 00:00:00
> > +2001
> > +From: Zhenhua Luo 
> > +Date: Sat, 11 Jun 2016 22:08:29 -0500
> > +Subject: [PATCH] fix the incorrect assembling for ppc wait mnemonic
> > +
> > +Signed-off-by: Zhenhua Luo 
> > +
> > +Upstream-Status: Pending
> > +---
> > + opcodes/ppc-opc.c | 3 +--
> > + 1 file changed, 1 insertion(+), 2 deletions(-)
> > +
> > +diff --git a/opcodes/ppc-opc.c b/opcodes/ppc-opc.c index
> > +e8c92f6..a9de474 100644
> > +--- a/opcodes/ppc-opc.c
> >  b/opcodes/ppc-opc.c
> > +@@ -4777,7 +4777,6 @@ const struct powerpc_opcode powerpc_opcodes[]
> = {
> > + {"ldepx", X(31,29),   X_MASK,  E500MC|PPCA2|PPCVLE, PPCNONE,
> {RT, RA0, RB}},
> > +
> > + {"waitasec",  X(31,30),   XRTRARB_MASK,POWER8,POWER9, 
> > {0}},
> > +-{"wait",  X(31,30),   XWC_MASK,POWER9,PPCNONE,
> > {WC}},
> > +
> > + {"lwepx", X(31,31),   X_MASK,  E500MC|PPCA2|PPCVLE, PPCNONE,
> {RT, RA0, RB}},
> > +
> > +@@ -4831,7 +4830,7 @@ const struct powerpc_opcode powerpc_opcodes[]
> =
> > +{
> > +
> > + {"waitrsv",   X(31,62)|(1<<21), 0x, E500MC|PPCA2, PPCNONE,
> > {0}},
> > + {"waitimpl",  X(31,62)|(2<<21), 0x, E500MC|PPCA2, PPCNONE,
> > {0}},
> > +-{"wait",  X(31,62),   XWC_MASK,E500MC|PPCA2|PPCVLE, PPCNONE,
> {WC}},
> > ++{"wait",  X(31,62),   XWC_MASK,E500MC|PPCA2|PPCVLE|POWER9,
> PPCNONE, {WC}},
> 
> please submit it to binutils upstream too.
> 
> > +
> > + {"dcbstep",   XRT(31,63,0),   XRT_MASK,E500MC|PPCA2|PPCVLE,
> PPCNONE, {RA0, RB}},
> > +
> > +--
> > +2.5.0
> > +
> > --
> > 2.4.11
> >
> > --
> > ___
> > 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