[oe] [meta-oe] gitpkgv.bbclass: fix versioning with multiple repos

2017-02-17 Thread S. Lockwood-Childs 
gitpkgv class is supposed to use SRCREV_FORMAT variable to define
how to smoosh together revision info from multiple repos that are
used in a single recipe. It is incorrectly repeating the rev hash
for the first repo instead of including the rev from each listed repo.

Example:

  SRC_URI = "git://some-server/purple.git;destsuffix=git/purple;name=purple"
  SRC_URI += "git://other-server/blue.git;destsuffix=git/blue;name=blue"
  SRCREV_purple = "${AUTOREV}"
  SRCREV_blue = "${AUTOREV}"
  SRCREV_FORMAT = "purple_blue"

Suppose gitpkgv calculates "67+ea121ea" for purple repo,
and "123+feef001" for blue repo. This should result in a
package version with them joined together like so:

"67+ea121ea_123+feef001"

It didn't. Instead the git hash part for the first repo got repeated:

"67+ea121ea_123+ea121ea"

Fix this by looking in the right place for the git revisions of 2nd
(and following) repos when assembling the full version string.

Signed-off-by: S. Lockwood-Childs 
---
 meta-oe/classes/gitpkgv.bbclass | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta-oe/classes/gitpkgv.bbclass b/meta-oe/classes/gitpkgv.bbclass
index 8cd4bfd..26a758f 100644
--- a/meta-oe/classes/gitpkgv.bbclass
+++ b/meta-oe/classes/gitpkgv.bbclass
@@ -110,9 +110,9 @@ def get_git_pkgv(d, use_tags):
 d, quiet=True).strip()
 ver = gitpkgv_drop_tag_prefix(output)
 except Exception:
-ver = "0.0-%s-g%s" % (commits, rev[:7])
+ver = "0.0-%s-g%s" % (commits, vars['rev'][:7])
 else:
-ver = "%s+%s" % (commits, rev[:7])
+ver = "%s+%s" % (commits, vars['rev'][:7])
 
 format = format.replace(name, ver)
 
-- 
1.9.4

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

Re: [oe] State of bitbake world, Failed tasks 2017-02-14

2017-02-17 Thread Martin Jansa 
On Thu, Feb 16, 2017 at 11:08:25PM +0100, Martin Jansa wrote:
> There are 2 more issues in oe-core once I enable ptest (together with
> already enabled gold):

Both issues still exist in master:

apr: http://errors.yoctoproject.org/Errors/Details/133693/
parted: http://errors.yoctoproject.org/Errors/Details/133692/

> oe-core/meta/recipes-support/apr/apr_1.5.2.bb:do_compile_ptest_base
> 
> | ../.libs/libapr-1.so: error: undefined reference to 'pthread_mutexattr_init'
> | ../.libs/libapr-1.so: error: undefined reference to
> 'pthread_mutexattr_settype'
> | ../.libs/libapr-1.so: error: undefined reference to
> 'pthread_mutexattr_destroy'
> | ../.libs/libapr-1.so: error: undefined reference to 'pthread_mutex_trylock'
> | ../.libs/libapr-1.so: error: undefined reference to 'pthread_sigmask'
> | ../.libs/libapr-1.so: error: undefined reference to
> 'pthread_attr_setstacksize'
> | ../.libs/libapr-1.so: error: undefined reference to 'pthread_create'
> | ../.libs/libapr-1.so: error: undefined reference to 'pthread_join'
> | ../.libs/libapr-1.so: error: undefined reference to 'pthread_detach'
> | ../.libs/libapr-1.so: error: undefined reference to 'pthread_once'
> | ../.libs/libapr-1.so: error: undefined reference to 'pthread_key_create'
> | ../.libs/libapr-1.so: error: undefined reference to 'pthread_getspecific'
> | ../.libs/libapr-1.so: error: undefined reference to 'pthread_setspecific'
> | ../.libs/libapr-1.so: error: undefined reference to 'pthread_key_delete'
> | collect2: error: ld returned 1 exit status
> | make[1]: *** [globalmutexchild] Error 1
> 
> 
> oe-core/meta/recipes-extended/parted/parted_3.2.bb:do_compile_ptest_base
> 
> | ../libparted/fs/.libs/libparted-fs-resize.so: error: undefined
> reference to 'uuid_generate'
> | collect2: error: ld returned 1 exit status
> | make: *** [fs-resize] Error 1
> 
> 
> Once my morty builds are finished I'll try to reproduce this in
> master, but I think I've seen this failure with ptest before yesterday
> for master as well.
> 
> 
> On Thu, Feb 16, 2017 at 1:44 PM, Martin Jansa 
> wrote:
> 
> > Another run with couple unblacklists
> >
> > == Number of issues - stats ==
> > {| class='wikitable'
> > !|Date   !!colspan='3'|Failed tasks
> >  !!colspan='6'|Failed depencencies!!|Signatures
> > !!colspan='12'|QA !!Comment
> > |-
> > ||  ||qemuarm   ||qemux86   ||qemux86_64
> > ||qemuarm||max||min ||qemux86||max||min ||all   ||already-stripped
> > ||libdir||textrel   ||build-deps||file-rdeps
> > ||version-going-backwards   ||host-user-contaminated
> > ||installed-vs-shipped  ||unknown-configure-option
> > ||symlink-to-sysroot||invalid-pkgconfig ||pkgname   ||
> > |-
> > ||2017-02-14||0 ||1 ||0 ||N/A   ||N/A   ||N/A   ||N/A
> >  ||N/A   ||N/A   ||0 ||0 ||0 ||0
> >  ||0 ||0 ||198   ||0 ||0
> >  ||0 ||0 ||0 ||0 ||
> > |}
> >
> > http://www.openembedded.org/wiki/Bitbake_World_Status
> >
> > == Failed tasks 2017-02-14 ==
> >
> > INFO: jenkins-job.sh-1.8.17 Complete log available at
> > http://logs.nslu2-linux.org/buildlogs/oe/world/pyro/log.
> > report.20170214_164708.log
> >
> > === common () ===
> >
> > === common-x86 (0) ===
> >
> > === qemuarm (0) ===
> >
> > === qemux86 (1) ===
> > * meta-browser/recipes-browser/chromium/chromium-wayland_53.
> > 0.2785.143.bb:do_compile
> >
> > === qemux86_64 (0) ===
> >
> > === Number of failed tasks (1) ===
> > {| class=wikitable
> > |-
> > || qemuarm  || 0 || http://logs.nslu2-linux.org/
> > buildlogs/oe/world/pyro/log.world.qemuarm.20170214_135645.log/ ||
> > |-
> > || qemux86  || 1 || http://logs.nslu2-linux.org/
> > buildlogs/oe/world/pyro/log.world.qemux86.20170214_135710.log/ ||
> > http://errors.yoctoproject.org/Errors/Build/32480/
> > |-
> > || qemux86_64   || 0 || http://logs.nslu2-linux.org/
> > buildlogs/oe/world/pyro/log.world.qemux86-64.20170214_151408.log/ ||
> > |}
> >
> > === PNBLACKLISTs (445) ===
> >
> > === QA issues (198) ===
> > {| class=wikitable
> > !| Count||Issue
> > |-
> > ||0 ||already-stripped
> > |-
> > ||0 ||build-deps
> > |-
> > ||0 ||file-rdeps
> > |-
> > ||0 ||host-user-contaminated
> > |-
> > ||0 ||installed-vs-shipped
> > |-
> > ||0 ||invalid-pkgconfig
> > |-
> > ||0 ||libdir
> > |-
> > ||0 ||pkgname
> > |-
> > ||0 ||symlink-to-sysroot
> > |-
> > ||0 ||textrel
> > |-
> > ||0 ||unknown-configure-option
> > |-
> > ||198   ||version-going-backwards
> > |}
> >
> >
> >
> > === Incorrect PACKAGE_ARCH or sstate signatures (0) ===
> >
> > Complete log: http://logs.nslu2-linux.org/buildlogs/oe/world/pyro/log.
> > signatures.20170214_151247.log/
> >
> > No issues detected
> >

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


signature.asc
Description:

[oe] [meta-oe][PATCH 2/8] lvm2: Make sure odirect is always enabled

2017-02-17 Thread Peter Kjellerstedt 
Make sure that even if PACKAGECONFIG is modified in a bbappend,
odirect will still be enabled.

Signed-off-by: Peter Kjellerstedt 
---
 meta-oe/recipes-support/lvm2/lvm2.inc | 15 ++-
 1 file changed, 6 insertions(+), 9 deletions(-)

diff --git a/meta-oe/recipes-support/lvm2/lvm2.inc 
b/meta-oe/recipes-support/lvm2/lvm2.inc
index 333223a..f69acde 100644
--- a/meta-oe/recipes-support/lvm2/lvm2.inc
+++ b/meta-oe/recipes-support/lvm2/lvm2.inc
@@ -19,21 +19,18 @@ inherit autotools-brokensep pkgconfig systemd
 PACKAGECONFIG_class-target ??= " \
${@bb.utils.contains('DISTRO_FEATURES', 'selinux', 
'selinux', '', d)} \
thin-provisioning-tools \
-   odirect \
 "
 
-# odirect is enabled by default also for native compilation because
-# there's currently a bug in lib/device/dev-io.c which prevents
-# compiling without it. It is better to stick to configurations that
-# were actually tested by upstream...
-PACKAGECONFIG ??= " \
-   odirect \
-"
+# odirect is always enabled because there currently is a bug in
+# lib/device/dev-io.c which prevents compiling without it. It is
+# better to stick to configurations that were actually tested by
+# upstream...
+PACKAGECONFIG_append = " odirect"
 
+PACKAGECONFIG[odirect] = "--enable-o_direct,--disable-o_direct"
 PACKAGECONFIG[readline] = "--enable-readline,--disable-readline,readline"
 PACKAGECONFIG[selinux] = "--enable-selinux,--disable-selinux,libselinux"
 PACKAGECONFIG[thin-provisioning-tools] = 
"--with-thin=internal,--with-thin=none,,thin-provisioning-tools"
-PACKAGECONFIG[odirect] = "--enable-o_direct,--disable-o_direct"
 
 # Unset user/group to unbreak install.
 EXTRA_OECONF = "--with-user= \
-- 
2.9.0

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

[oe] [meta-oe][PATCH 7/8] lvm2: Move bash scripts to a separate package

2017-02-17 Thread Peter Kjellerstedt 
By putting the bash scripts in a separate package (lvm2-scripts), the
lvm2 package no longer needs to depend on bash. For backwards
compatibility, the lvm2 package recommends the lvm2-scripts package.

Also remove the adding of ${libdir}/device-mapper/.debug to
FILES_${PN}-dbg as it has not been needed since Krogoth.

Signed-off-by: Peter Kjellerstedt 
---
 meta-oe/recipes-support/lvm2/lvm2.inc | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/meta-oe/recipes-support/lvm2/lvm2.inc 
b/meta-oe/recipes-support/lvm2/lvm2.inc
index 438ea7b..1462841 100644
--- a/meta-oe/recipes-support/lvm2/lvm2.inc
+++ b/meta-oe/recipes-support/lvm2/lvm2.inc
@@ -73,6 +73,8 @@ do_install_append() {
 fi
 }
 
+PACKAGE_BEFORE_PN = "${PN}-scripts"
+
 SYSTEMD_PACKAGES = "${PN}"
 SYSTEMD_SERVICE_${PN} = "${@bb.utils.contains('PACKAGECONFIG', 'dmeventd', 
'lvm2-monitor.service dm-event.socket dm-event.service', '', d)} \
  ${@bb.utils.contains('PACKAGECONFIG', 'lvmetad', 
'lvm2-lvmetad.socket lvm2-pvscan@.service', '', d)} \
@@ -82,8 +84,14 @@ SYSTEMD_AUTO_ENABLE = "disable"
 TARGET_CC_ARCH += "${LDFLAGS}"
 
 FILES_${PN} += "${libdir}/device-mapper/*.so ${base_libdir}/udev"
-FILES_${PN}-dbg += "${libdir}/device-mapper/.debug"
+FILES_${PN}-scripts = " \
+${sbindir}/blkdeactivate \
+${sbindir}/fsadm \
+${sbindir}/lvmconf \
+${sbindir}/lvmdump \
+"
 
-RDEPENDS_${PN} = "bash"
+RDEPENDS_${PN}-scripts = "${PN} (= ${EXTENDPKGV}) bash"
+RRECOMMENDS_${PN} = "${PN}-scripts (= ${EXTENDPKGV})"
 
 CONFFILES_${PN} += "${sysconfdir}/lvm/lvm.conf"
-- 
2.9.0

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

[oe] [meta-oe][PATCH 1/8] lvm2: Depend on autoconf-archive-native instead of autoconf-archive

2017-02-17 Thread Peter Kjellerstedt 
This still satisfies the dependency, and allows lvm2 to be built when
packages that use GPL-3.0 have been disabled via INCOMPATIBLE_LICENSE.

Signed-off-by: Peter Kjellerstedt 
---
 meta-oe/recipes-support/lvm2/lvm2_2.02.166.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta-oe/recipes-support/lvm2/lvm2_2.02.166.bb 
b/meta-oe/recipes-support/lvm2/lvm2_2.02.166.bb
index 6983bca..c81faa7 100644
--- a/meta-oe/recipes-support/lvm2/lvm2_2.02.166.bb
+++ b/meta-oe/recipes-support/lvm2/lvm2_2.02.166.bb
@@ -3,6 +3,6 @@ require lvm2.inc
 SRC_URI[md5sum] = "c5a54ee0b86703daaad6e856439e115a"
 SRC_URI[sha256sum] = 
"e120b066b85b224552efda40204488c5123de068725676fd6e5c8bc655051b94"
 
-DEPENDS += "autoconf-archive"
+DEPENDS += "autoconf-archive-native"
 
 BBCLASSEXTEND = "native nativesdk"
-- 
2.9.0

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

[oe] [meta-oe][PATCH 4/8] lvm2: Add a PACKAGECONFIG for udev support

2017-02-17 Thread Peter Kjellerstedt 
The added dependency on util-linux is necessary to avoid the following
QA warning which appears when the dependency on udev is removed:

  WARNING: lvm2-2.02.166-r0 do_package_qa: QA Issue: lvm2 rdepends on
  util-linux-libblkid, but it isn't a build dependency, missing
  util-linux in DEPENDS or PACKAGECONFIG? [build-deps]

Signed-off-by: Peter Kjellerstedt 
---
 meta-oe/recipes-support/lvm2/lvm2.inc | 16 
 1 file changed, 4 insertions(+), 12 deletions(-)

diff --git a/meta-oe/recipes-support/lvm2/lvm2.inc 
b/meta-oe/recipes-support/lvm2/lvm2.inc
index 7c4bbb9..5d228ea 100644
--- a/meta-oe/recipes-support/lvm2/lvm2.inc
+++ b/meta-oe/recipes-support/lvm2/lvm2.inc
@@ -1,10 +1,11 @@
 SECTION = "utils"
 DESCRIPTION = "LVM2 is a set of utilities to manage logical volumes in Linux."
-DEPENDS_append_class-target = " udev"
 LICENSE = "GPLv2 & LGPLv2"
 LIC_FILES_CHKSUM = "file://COPYING;md5=12713b4d9386533feeb07d6e4831765a \
 file://COPYING.LIB;md5=fbc093901857fcd118f065f900982c24"
 
+DEPENDS += "util-linux"
+
 SRC_URI = "ftp://sources.redhat.com/pub/lvm2/old/LVM2.${PV}.tgz \
file://lvm.conf \
file://0001-implement-libc-specific-reopen_stream.patch \
@@ -20,6 +21,7 @@ LVM2_PACKAGECONFIG = ""
 LVM2_PACKAGECONFIG_append_class-target = " \
 ${@bb.utils.contains('DISTRO_FEATURES', 'selinux', 'selinux', '', d)} \
 thin-provisioning-tools \
+udev \
 "
 
 PACKAGECONFIG ??= "${LVM2_PACKAGECONFIG}"
@@ -34,6 +36,7 @@ PACKAGECONFIG[odirect] = 
"--enable-o_direct,--disable-o_direct"
 PACKAGECONFIG[readline] = "--enable-readline,--disable-readline,readline"
 PACKAGECONFIG[selinux] = "--enable-selinux,--disable-selinux,libselinux"
 PACKAGECONFIG[thin-provisioning-tools] = 
"--with-thin=internal,--with-thin=none,,thin-provisioning-tools"
+PACKAGECONFIG[udev] = "--enable-udev_sync --enable-udev_rules 
--with-udev-prefix=,--disable-udev_sync --disable-udev_rules,udev"
 
 # Unset user/group to unbreak install.
 EXTRA_OECONF = "--with-user= \
@@ -51,17 +54,6 @@ EXTRA_OECONF = "--with-user= \
 --with-thin-dump=${sbindir}/thin_dump \
 --with-thin-repair=${sbindir}/thin_repair \
 --with-thin-restore=${sbindir}/thin_restore \
-${EXTRA_OECONF_UDEV} \
-"
-
-EXTRA_OECONF_UDEV = " \
---disable-udev_sync \
---disable-udev_rules \
-"
-EXTRA_OECONF_UDEV_class-target = " \
---enable-udev_sync \
---enable-udev_rules \
---with-udev-prefix= \
 "
 
 CACHED_CONFIGUREVARS += "MODPROBE_CMD=${base_sbindir}/modprobe"
-- 
2.9.0

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

[oe] [meta-oe][PATCH 5/8] lvm2: Add a PACKAGECONFIG for dmeventd

2017-02-17 Thread Peter Kjellerstedt 
This allows the support for dmeventd to be disabled.

Signed-off-by: Peter Kjellerstedt 
---
 meta-oe/recipes-support/lvm2/lvm2.inc | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/meta-oe/recipes-support/lvm2/lvm2.inc 
b/meta-oe/recipes-support/lvm2/lvm2.inc
index 5d228ea..2c0ad29 100644
--- a/meta-oe/recipes-support/lvm2/lvm2.inc
+++ b/meta-oe/recipes-support/lvm2/lvm2.inc
@@ -17,7 +17,7 @@ S = "${WORKDIR}/LVM2.${PV}"
 
 inherit autotools-brokensep pkgconfig systemd
 
-LVM2_PACKAGECONFIG = ""
+LVM2_PACKAGECONFIG = "dmeventd"
 LVM2_PACKAGECONFIG_append_class-target = " \
 ${@bb.utils.contains('DISTRO_FEATURES', 'selinux', 'selinux', '', d)} \
 thin-provisioning-tools \
@@ -32,6 +32,7 @@ PACKAGECONFIG ??= "${LVM2_PACKAGECONFIG}"
 # upstream...
 PACKAGECONFIG_append = " odirect"
 
+PACKAGECONFIG[dmeventd] = "--enable-dmeventd,--disable-dmeventd"
 PACKAGECONFIG[odirect] = "--enable-o_direct,--disable-o_direct"
 PACKAGECONFIG[readline] = "--enable-readline,--disable-readline,readline"
 PACKAGECONFIG[selinux] = "--enable-selinux,--disable-selinux,libselinux"
@@ -45,7 +46,6 @@ EXTRA_OECONF = "--with-user= \
 --enable-applib \
 --enable-cmdlib \
 --enable-pkgconfig \
---enable-dmeventd \
 --enable-lvmetad \
 --with-usrlibdir=${libdir} \
 --with-systemdsystemunitdir=${systemd_system_unitdir} \
@@ -74,8 +74,9 @@ do_install_append() {
 }
 
 SYSTEMD_PACKAGES = "${PN}"
-SYSTEMD_SERVICE_${PN} = "lvm2-monitor.service dm-event.socket dm-event.service 
lvm2-lvmetad.socket \
- lvm2-pvscan@.service blk-availability.service"
+SYSTEMD_SERVICE_${PN} = "${@bb.utils.contains('PACKAGECONFIG', 'dmeventd', 
'lvm2-monitor.service dm-event.socket dm-event.service', '', d)} \
+ lvm2-lvmetad.socket lvm2-pvscan@.service \
+ blk-availability.service"
 SYSTEMD_AUTO_ENABLE = "disable"
 
 TARGET_CC_ARCH += "${LDFLAGS}"
-- 
2.9.0

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

[oe] [meta-oe][PATCH 6/8] lvm2: Add a PACKAGECONFIG for lvmetad

2017-02-17 Thread Peter Kjellerstedt 
This allows the support for lvmetad to be disabled.

Signed-off-by: Peter Kjellerstedt 
---
 meta-oe/recipes-support/lvm2/lvm2.inc | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/meta-oe/recipes-support/lvm2/lvm2.inc 
b/meta-oe/recipes-support/lvm2/lvm2.inc
index 2c0ad29..438ea7b 100644
--- a/meta-oe/recipes-support/lvm2/lvm2.inc
+++ b/meta-oe/recipes-support/lvm2/lvm2.inc
@@ -17,7 +17,7 @@ S = "${WORKDIR}/LVM2.${PV}"
 
 inherit autotools-brokensep pkgconfig systemd
 
-LVM2_PACKAGECONFIG = "dmeventd"
+LVM2_PACKAGECONFIG = "dmeventd lvmetad"
 LVM2_PACKAGECONFIG_append_class-target = " \
 ${@bb.utils.contains('DISTRO_FEATURES', 'selinux', 'selinux', '', d)} \
 thin-provisioning-tools \
@@ -33,6 +33,7 @@ PACKAGECONFIG ??= "${LVM2_PACKAGECONFIG}"
 PACKAGECONFIG_append = " odirect"
 
 PACKAGECONFIG[dmeventd] = "--enable-dmeventd,--disable-dmeventd"
+PACKAGECONFIG[lvmetad] = "--enable-lvmetad,--disable-lvmetad"
 PACKAGECONFIG[odirect] = "--enable-o_direct,--disable-o_direct"
 PACKAGECONFIG[readline] = "--enable-readline,--disable-readline,readline"
 PACKAGECONFIG[selinux] = "--enable-selinux,--disable-selinux,libselinux"
@@ -46,7 +47,6 @@ EXTRA_OECONF = "--with-user= \
 --enable-applib \
 --enable-cmdlib \
 --enable-pkgconfig \
---enable-lvmetad \
 --with-usrlibdir=${libdir} \
 --with-systemdsystemunitdir=${systemd_system_unitdir} \
 --disable-thin_check_needs_check \
@@ -75,7 +75,7 @@ do_install_append() {
 
 SYSTEMD_PACKAGES = "${PN}"
 SYSTEMD_SERVICE_${PN} = "${@bb.utils.contains('PACKAGECONFIG', 'dmeventd', 
'lvm2-monitor.service dm-event.socket dm-event.service', '', d)} \
- lvm2-lvmetad.socket lvm2-pvscan@.service \
+ ${@bb.utils.contains('PACKAGECONFIG', 'lvmetad', 
'lvm2-lvmetad.socket lvm2-pvscan@.service', '', d)} \
  blk-availability.service"
 SYSTEMD_AUTO_ENABLE = "disable"
 
-- 
2.9.0

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

[oe] [meta-oe][PATCH 8/8] lvm2: Move libdevmapper to a separate package

2017-02-17 Thread Peter Kjellerstedt 
This allows, e.g., cryptsetup to use libdevmapper without having to
pull in all of lvm2.

Signed-off-by: Peter Kjellerstedt 
---
 meta-oe/recipes-support/lvm2/lvm2.inc | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/meta-oe/recipes-support/lvm2/lvm2.inc 
b/meta-oe/recipes-support/lvm2/lvm2.inc
index 1462841..e0a126e 100644
--- a/meta-oe/recipes-support/lvm2/lvm2.inc
+++ b/meta-oe/recipes-support/lvm2/lvm2.inc
@@ -73,7 +73,7 @@ do_install_append() {
 fi
 }
 
-PACKAGE_BEFORE_PN = "${PN}-scripts"
+PACKAGE_BEFORE_PN = "${PN}-scripts libdevmapper libdevmapper-dev"
 
 SYSTEMD_PACKAGES = "${PN}"
 SYSTEMD_SERVICE_${PN} = "${@bb.utils.contains('PACKAGECONFIG', 'dmeventd', 
'lvm2-monitor.service dm-event.socket dm-event.service', '', d)} \
@@ -90,8 +90,15 @@ FILES_${PN}-scripts = " \
 ${sbindir}/lvmconf \
 ${sbindir}/lvmdump \
 "
+FILES_libdevmapper = "${libdir}/libdevmapper.so.*"
+FILES_libdevmapper-dev = " \
+${libdir}/libdevmapper.so \
+${libdir}/pkgconfig/devmapper.pc \
+${includedir}/libdevmapper.h \
+"
 
 RDEPENDS_${PN}-scripts = "${PN} (= ${EXTENDPKGV}) bash"
+RDEPENDS_libdevmapper-dev = "libdevmapper (= ${EXTENDPKGV})"
 RRECOMMENDS_${PN} = "${PN}-scripts (= ${EXTENDPKGV})"
 
 CONFFILES_${PN} += "${sysconfdir}/lvm/lvm.conf"
-- 
2.9.0

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

[oe] [meta-oe][PATCH 3/8] lvm2: Standardize how PACKAGECONFIG is defined

2017-02-17 Thread Peter Kjellerstedt 
The change in 4071e6b4b0 broke support for redefining PACKAGECONFIG in
a bbappend without having to resort to use PACKAGECONFIG_class-target.

Signed-off-by: Peter Kjellerstedt 
---
 meta-oe/recipes-support/lvm2/lvm2.inc | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/meta-oe/recipes-support/lvm2/lvm2.inc 
b/meta-oe/recipes-support/lvm2/lvm2.inc
index f69acde..7c4bbb9 100644
--- a/meta-oe/recipes-support/lvm2/lvm2.inc
+++ b/meta-oe/recipes-support/lvm2/lvm2.inc
@@ -16,11 +16,14 @@ S = "${WORKDIR}/LVM2.${PV}"
 
 inherit autotools-brokensep pkgconfig systemd
 
-PACKAGECONFIG_class-target ??= " \
-   ${@bb.utils.contains('DISTRO_FEATURES', 'selinux', 
'selinux', '', d)} \
-   thin-provisioning-tools \
+LVM2_PACKAGECONFIG = ""
+LVM2_PACKAGECONFIG_append_class-target = " \
+${@bb.utils.contains('DISTRO_FEATURES', 'selinux', 'selinux', '', d)} \
+thin-provisioning-tools \
 "
 
+PACKAGECONFIG ??= "${LVM2_PACKAGECONFIG}"
+
 # odirect is always enabled because there currently is a bug in
 # lib/device/dev-io.c which prevents compiling without it. It is
 # better to stick to configurations that were actually tested by
-- 
2.9.0

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

Re: [oe] Splitting meta-oe?

2017-02-17 Thread Khem Raj 
On Fri, Feb 17, 2017 at 9:07 AM, Burton, Ross  wrote:
> The recent storm of breakage in meta-oe caused by recipe specific sysroots
> was quite dramatic:
>
> ross@flashheart ~/Yocto/meta-oe ((044e518...))
> $ git grep PNBLACKLIST| wc -l
> 320
>
> Is it time to talk about splitting meta-oe into smaller real repositories
> so they can be maintained at their own pace by more maintainers?
>

I think thats a fine idea, however, it needs maintainers to sign up
first before any of this can be sustained. I think it was forewarned
that such a change is coming. recipe maintainers or users should have
risen up and sent patches. This can not be solved even if you divide
the layer into smaller layers. Problems still remains. Whats required
is to look other way, where we have
faster infrastructure to test meta-openemebedded layers and ease out
maintainer's job by testing and working though the changes. Blacklist
is infact the better way to disable the recipes instead of shuffling
layers. One still has a good base to start and fix it.
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [PATCH 1/2] libtdb: fix SRC_URI - http has gone

2017-02-17 Thread Martin Jansa 
It's not lost, at least not completely, it waits in master-next for Joe to
merge it, because it's for meta-networking.

Maybe Joe missed it because he scans for [meta-networking] and your patches
are missing that in subject (I've noticed that you also often if not always
don't use [meta-oe] or [meta-xfce] which usually doesn't cause me troubles
to notice your patches, because I sort them all on patchwork, but it's
easier to miss for Joe.

Adding Joe to CC.

On Fri, Feb 17, 2017 at 9:37 AM, Andreas Müller <
schnitzelt...@googlemail.com> wrote:

> On Mon, Feb 6, 2017 at 9:00 PM, Andreas Müller
>  wrote:
> > Signed-off-by: Andreas Müller 
> > ---
> >  meta-networking/recipes-support/libtdb/libtdb_1.3.12.bb | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> ping - seems this series got lost - shall I resend?
>
> Andreas
> --
> ___
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
>
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] Splitting meta-oe?

2017-02-17 Thread akuster808 



On 02/17/2017 09:07 AM, Burton, Ross wrote:

The recent storm of breakage in meta-oe caused by recipe specific sysroots
was quite dramatic:

ross@flashheart ~/Yocto/meta-oe ((044e518...))
$ git grep PNBLACKLIST| wc -l
320


If I recall correctly we gave Martin the thumbs up to use "blacklisting" 
to  get to a point where master builds cleanly and not expect the 
meta-openbedded layer maintainer's to do that work. The hope was if a 
person needed a blacklisted recipe, they would jump in a correct the 
issue. I think that has worked to some success.

Is it time to talk about splitting meta-oe into smaller real repositories
so they can be maintained at their own pace by more maintainers?
If I am not mistaken, each sub meta layer has its own maintainer, if 
someone want to be a package maintainer, go for it.  I would prefer that 
"We" the community help the maintainers.


- armin


Ross


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

Re: [oe] [meta-webserver][PATCH] apache2: Correct the SRC_URI

2017-02-17 Thread Derek Straka 
Thanks for this one.  I must have neglected to do a clean all first.

-Derek

On Feb 17, 2017 4:37 PM, "Peter Kjellerstedt" 
wrote:

> The change to use ${APACHE_MIRROR} in the SRC_URI in dfbe6cf214 did
> not take into account that ${APACHE_MIRROR} already contains "/dist".
>
> Signed-off-by: Peter Kjellerstedt 
> ---
>  meta-webserver/recipes-httpd/apache2/apache2-native_2.4.25.bb | 2 +-
>  meta-webserver/recipes-httpd/apache2/apache2_2.4.25.bb| 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/meta-webserver/recipes-httpd/apache2/apache2-native_2.4.25.bb
> b/meta-webserver/recipes-httpd/apache2/apache2-native_2.4.25.bb
> index fc84872..99717d2 100644
> --- a/meta-webserver/recipes-httpd/apache2/apache2-native_2.4.25.bb
> +++ b/meta-webserver/recipes-httpd/apache2/apache2-native_2.4.25.bb
> @@ -8,7 +8,7 @@ LICENSE = "Apache-2.0"
>
>  inherit autotools pkgconfig native
>
> -SRC_URI = "${APACHE_MIRROR}/dist/httpd/httpd-${PV}.tar.bz2 \
> +SRC_URI = "${APACHE_MIRROR}/httpd/httpd-${PV}.tar.bz2 \
> file://0001-configure-use-pkg-config-for-PCRE-detection.patch
> \
>"
>
> diff --git a/meta-webserver/recipes-httpd/apache2/apache2_2.4.25.bb
> b/meta-webserver/recipes-httpd/apache2/apache2_2.4.25.bb
> index b3a2dfd..60f6fb9 100644
> --- a/meta-webserver/recipes-httpd/apache2/apache2_2.4.25.bb
> +++ b/meta-webserver/recipes-httpd/apache2/apache2_2.4.25.bb
> @@ -6,7 +6,7 @@ DEPENDS = "libtool-native apache2-native openssl expat
> pcre apr apr-util"
>  SECTION = "net"
>  LICENSE = "Apache-2.0"
>
> -SRC_URI = "${APACHE_MIRROR}/dist/httpd/httpd-${PV}.tar.bz2 \
> +SRC_URI = "${APACHE_MIRROR}/httpd/httpd-${PV}.tar.bz2 \
> file://server-makefile.patch \
> file://httpd-2.4.1-corelimit.patch \
> file://httpd-2.4.4-export.patch \
> --
> 2.9.0
>
> --
> ___
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
>
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

[oe] [meta-webserver][PATCH] apache2: Correct the SRC_URI

2017-02-17 Thread Peter Kjellerstedt 
The change to use ${APACHE_MIRROR} in the SRC_URI in dfbe6cf214 did
not take into account that ${APACHE_MIRROR} already contains "/dist".

Signed-off-by: Peter Kjellerstedt 
---
 meta-webserver/recipes-httpd/apache2/apache2-native_2.4.25.bb | 2 +-
 meta-webserver/recipes-httpd/apache2/apache2_2.4.25.bb| 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta-webserver/recipes-httpd/apache2/apache2-native_2.4.25.bb 
b/meta-webserver/recipes-httpd/apache2/apache2-native_2.4.25.bb
index fc84872..99717d2 100644
--- a/meta-webserver/recipes-httpd/apache2/apache2-native_2.4.25.bb
+++ b/meta-webserver/recipes-httpd/apache2/apache2-native_2.4.25.bb
@@ -8,7 +8,7 @@ LICENSE = "Apache-2.0"
 
 inherit autotools pkgconfig native
 
-SRC_URI = "${APACHE_MIRROR}/dist/httpd/httpd-${PV}.tar.bz2 \
+SRC_URI = "${APACHE_MIRROR}/httpd/httpd-${PV}.tar.bz2 \
file://0001-configure-use-pkg-config-for-PCRE-detection.patch \
   "
 
diff --git a/meta-webserver/recipes-httpd/apache2/apache2_2.4.25.bb 
b/meta-webserver/recipes-httpd/apache2/apache2_2.4.25.bb
index b3a2dfd..60f6fb9 100644
--- a/meta-webserver/recipes-httpd/apache2/apache2_2.4.25.bb
+++ b/meta-webserver/recipes-httpd/apache2/apache2_2.4.25.bb
@@ -6,7 +6,7 @@ DEPENDS = "libtool-native apache2-native openssl expat pcre apr 
apr-util"
 SECTION = "net"
 LICENSE = "Apache-2.0"
 
-SRC_URI = "${APACHE_MIRROR}/dist/httpd/httpd-${PV}.tar.bz2 \
+SRC_URI = "${APACHE_MIRROR}/httpd/httpd-${PV}.tar.bz2 \
file://server-makefile.patch \
file://httpd-2.4.1-corelimit.patch \
file://httpd-2.4.4-export.patch \
-- 
2.9.0

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

Re: [oe] Splitting meta-oe?

2017-02-17 Thread Andreas Müller 
On Fri, Feb 17, 2017 at 7:28 PM, Joe MacDonald  wrote:
> [Re: [oe] Splitting meta-oe?] On 17.02.17 (Fri 19:02) Martin Jansa wrote:
>
>> On Fri, Feb 17, 2017 at 06:24:09PM +0100, Andreas Müller wrote:
>> > On Fri, Feb 17, 2017 at 6:07 PM, Burton, Ross  
>> > wrote:
>> > > The recent storm of breakage in meta-oe caused by recipe specific 
>> > > sysroots
>> > > was quite dramatic:
>> > >
>> > > ross@flashheart ~/Yocto/meta-oe ((044e518...))
>> > > $ git grep PNBLACKLIST| wc -l
>> > > 320
>> > >
>> > > Is it time to talk about splitting meta-oe into smaller real repositories
>> > > so they can be maintained at their own pace by more maintainers?
>> > >
>> > > Ross
>> > What exactly gets better by splitting?
>>
>> I agree with Andreas.
>
> And I agree with both of you.
>
>> 1) RSS is good thing.
>>
>> 2) The breakage wasn't caused by lack of maintainers (at least I don't
>>think that I or Joe were the bottleneck for integrating the fixes).
>
> My schedule is highly variable but I do try to be responsive to
> breakages and I do my best to watch and digest the state of the world
> messages, those are extremely valuable IMO.
>
>> 3) More maintainers doesn't mean more contributions from people actually
>>using now broken components, it's actually easier to just send a fix
>>than to be a maintainer of some layer just to be able to also merge
>>your fix yourself.
>>
>> 4) It doesn't look so dramatic if it turns out that 200 of those
>>blacklisted recipes weren't actually used by anyone still active in
>>OE ecosystem.
>
> Agreed.  And if those blacklisted recipes are something that someone
> in the ecosystem cares about, they really should be sending fixes back
> upstream.  Breaking meta-oe up into smaller parts doesn't seem likely to
> make them more likely to send patches, AFAICT.  Probably won't make them
> less-so, either, but I don't see changing the structure to be a
> significant win.
>
> And do note that when we first created meta-networking I was proposing
> it be separate from meta-oe, I'm now completely on the other side of
> that argument, for what that's worth.
>
>> 5) If someone wants to replace me as meta-oe maintainer, go ahead, it
>>stopped being fun for me long time ago, now it's just slightly annoying
>>routine which takes my free time I would rather invest in something
>>cooler
>
> I frankly think that'd be a loss for everyone, but it's understandable.
> That's a big, largely thankless job you've taken on.  Obviously I can't
> offer to take on more of the job than I already have with
> meta-networking or I would, but maybe someone else with a similarly "big
> picture" view will be able to share some of the workload.
Agreed. Martin you are doing a great job and without you projects
would break into 'private' layers. This cannot be the target. Coming
to blacklisting: This is the only way for you to force people start
fixing things. Nobody expects you fixing things out of your interest.

From my personal perspective as 'maintainer' of e.g
meta-xfce/meta-office/meta-qt5-extra:

* there is only very limited community - I take care for these layers
more or less myself (ok meta-xfce has seen more than the others)

* due to many oddities as
* Cmake is cross mess
* Qt-people write small C++ tools for each and every build-job
* libreoffice has more or less tailored build system and builds take ages
  caused me to use dirty hacks. Most of those are terribly broken now
- I need to rethink a lot and that takes time.

Coming back to Ross' suggestion: Why panic and break things apart? As
soon as somebody needs an environment requiring current oe-core and
blacklisted recipes in meta-openembedded that person will (hopefully)
send patches. If that lasts - so be it. If there is some pressing for
release cycle - feel free to send patches.

One final note on splitting - has anybody taken a look on layer index
in recent past? I think that shows what will happen if we split.
People come 'yeah I have a great layer', publish that in layer index
and leave after a while. How shall a newbie get into that?

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

Re: [oe] Splitting meta-oe?

2017-02-17 Thread Philip Balister 
On 02/17/2017 01:28 PM, Joe MacDonald wrote:
> [Re: [oe] Splitting meta-oe?] On 17.02.17 (Fri 19:02) Martin Jansa wrote:
> 
>> On Fri, Feb 17, 2017 at 06:24:09PM +0100, Andreas Müller wrote:
>>> On Fri, Feb 17, 2017 at 6:07 PM, Burton, Ross  wrote:
 The recent storm of breakage in meta-oe caused by recipe specific sysroots
 was quite dramatic:

 ross@flashheart ~/Yocto/meta-oe ((044e518...))
 $ git grep PNBLACKLIST| wc -l
 320

 Is it time to talk about splitting meta-oe into smaller real repositories
 so they can be maintained at their own pace by more maintainers?

 Ross
>>> What exactly gets better by splitting?
>>
>> I agree with Andreas.
> 
> And I agree with both of you.
> 
>> 1) RSS is good thing.
>>
>> 2) The breakage wasn't caused by lack of maintainers (at least I don't
>>think that I or Joe were the bottleneck for integrating the fixes).
> 
> My schedule is highly variable but I do try to be responsive to
> breakages and I do my best to watch and digest the state of the world
> messages, those are extremely valuable IMO.
> 
>> 3) More maintainers doesn't mean more contributions from people actually
>>using now broken components, it's actually easier to just send a fix
>>than to be a maintainer of some layer just to be able to also merge
>>your fix yourself.
>>
>> 4) It doesn't look so dramatic if it turns out that 200 of those
>>blacklisted recipes weren't actually used by anyone still active in
>>OE ecosystem.
> 
> Agreed.  And if those blacklisted recipes are something that someone
> in the ecosystem cares about, they really should be sending fixes back
> upstream.  Breaking meta-oe up into smaller parts doesn't seem likely to
> make them more likely to send patches, AFAICT.  Probably won't make them
> less-so, either, but I don't see changing the structure to be a
> significant win.
> 
> And do note that when we first created meta-networking I was proposing
> it be separate from meta-oe, I'm now completely on the other side of
> that argument, for what that's worth.
> 
>> 5) If someone wants to replace me as meta-oe maintainer, go ahead, it
>>stopped being fun for me long time ago, now it's just slightly annoying
>>routine which takes my free time I would rather invest in something
>>cooler
> 
> I frankly think that'd be a loss for everyone, but it's understandable.
> That's a big, largely thankless job you've taken on.  Obviously I can't
> offer to take on more of the job than I already have with
> meta-networking or I would, but maybe someone else with a similarly "big
> picture" view will be able to share some of the workload.

And I'm with these gyus. Splitting the git repository doesn't solve any
underlying problems. The real problem from my point of view is very few
of use are actually paid to maintain the layers we maintain.

Employers want to pay things they profit from, and that is not paying
someone to maintain "core infrastructure".

Layer maintainers interests change over time, and you burn out
supporting people who get to do all the cool stuff with the layers you
maintain. In the end, you get all the crap and non of the glory. Within
this list, most people appreciate your work. Outside the community,
people completely underestimate the amount of work required to keep the
ecosystem running.

Yeah, add my name to the list of cranky people.

Philip

> 
> -J.
> 
>>
>> Regards,
>>
>>> Splitting = Rotting to death due to unmanageable maintenance burden
>>> caused by oe? Don't misunderstand me recipe specific sysroot is
>>> basically a good thing. But I am tired of this game. As you can see in
>>> meta-qt5-extra: I am interested in having cool images not in a cool
>>> build system. Long live core-image-sato!
>>>
>>> Andreas
>>> -- 
>>> ___
>>> Openembedded-devel mailing list
>>> Openembedded-devel@lists.openembedded.org
>>> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
>>
>> -- 
>> Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
> 
> 
> 
> 
> 



signature.asc
Description: OpenPGP digital signature
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] Splitting meta-oe?

2017-02-17 Thread Joe MacDonald 
[Re: [oe] Splitting meta-oe?] On 17.02.17 (Fri 19:02) Martin Jansa wrote:

> On Fri, Feb 17, 2017 at 06:24:09PM +0100, Andreas Müller wrote:
> > On Fri, Feb 17, 2017 at 6:07 PM, Burton, Ross  wrote:
> > > The recent storm of breakage in meta-oe caused by recipe specific sysroots
> > > was quite dramatic:
> > >
> > > ross@flashheart ~/Yocto/meta-oe ((044e518...))
> > > $ git grep PNBLACKLIST| wc -l
> > > 320
> > >
> > > Is it time to talk about splitting meta-oe into smaller real repositories
> > > so they can be maintained at their own pace by more maintainers?
> > >
> > > Ross
> > What exactly gets better by splitting?
> 
> I agree with Andreas.

And I agree with both of you.

> 1) RSS is good thing.
> 
> 2) The breakage wasn't caused by lack of maintainers (at least I don't
>think that I or Joe were the bottleneck for integrating the fixes).

My schedule is highly variable but I do try to be responsive to
breakages and I do my best to watch and digest the state of the world
messages, those are extremely valuable IMO.

> 3) More maintainers doesn't mean more contributions from people actually
>using now broken components, it's actually easier to just send a fix
>than to be a maintainer of some layer just to be able to also merge
>your fix yourself.
> 
> 4) It doesn't look so dramatic if it turns out that 200 of those
>blacklisted recipes weren't actually used by anyone still active in
>OE ecosystem.

Agreed.  And if those blacklisted recipes are something that someone
in the ecosystem cares about, they really should be sending fixes back
upstream.  Breaking meta-oe up into smaller parts doesn't seem likely to
make them more likely to send patches, AFAICT.  Probably won't make them
less-so, either, but I don't see changing the structure to be a
significant win.

And do note that when we first created meta-networking I was proposing
it be separate from meta-oe, I'm now completely on the other side of
that argument, for what that's worth.

> 5) If someone wants to replace me as meta-oe maintainer, go ahead, it
>stopped being fun for me long time ago, now it's just slightly annoying
>routine which takes my free time I would rather invest in something
>cooler

I frankly think that'd be a loss for everyone, but it's understandable.
That's a big, largely thankless job you've taken on.  Obviously I can't
offer to take on more of the job than I already have with
meta-networking or I would, but maybe someone else with a similarly "big
picture" view will be able to share some of the workload.

-J.

> 
> Regards,
> 
> > Splitting = Rotting to death due to unmanageable maintenance burden
> > caused by oe? Don't misunderstand me recipe specific sysroot is
> > basically a good thing. But I am tired of this game. As you can see in
> > meta-qt5-extra: I am interested in having cool images not in a cool
> > build system. Long live core-image-sato!
> > 
> > Andreas
> > -- 
> > ___
> > Openembedded-devel mailing list
> > Openembedded-devel@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-devel
> 
> -- 
> Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com



-- 
-Joe MacDonald.
:wq


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

Re: [oe] Splitting meta-oe?

2017-02-17 Thread Martin Jansa 
On Fri, Feb 17, 2017 at 06:24:09PM +0100, Andreas Müller wrote:
> On Fri, Feb 17, 2017 at 6:07 PM, Burton, Ross  wrote:
> > The recent storm of breakage in meta-oe caused by recipe specific sysroots
> > was quite dramatic:
> >
> > ross@flashheart ~/Yocto/meta-oe ((044e518...))
> > $ git grep PNBLACKLIST| wc -l
> > 320
> >
> > Is it time to talk about splitting meta-oe into smaller real repositories
> > so they can be maintained at their own pace by more maintainers?
> >
> > Ross
> What exactly gets better by splitting?

I agree with Andreas.

1) RSS is good thing.

2) The breakage wasn't caused by lack of maintainers (at least I don't
   think that I or Joe were the bottleneck for integrating the fixes).

3) More maintainers doesn't mean more contributions from people actually
   using now broken components, it's actually easier to just send a fix
   than to be a maintainer of some layer just to be able to also merge
   your fix yourself.

4) It doesn't look so dramatic if it turns out that 200 of those
   blacklisted recipes weren't actually used by anyone still active in
   OE ecosystem.

5) If someone wants to replace me as meta-oe maintainer, go ahead, it
   stopped being fun for me long time ago, now it's just slightly annoying
   routine which takes my free time I would rather invest in something
   cooler

Regards,

> Splitting = Rotting to death due to unmanageable maintenance burden
> caused by oe? Don't misunderstand me recipe specific sysroot is
> basically a good thing. But I am tired of this game. As you can see in
> meta-qt5-extra: I am interested in having cool images not in a cool
> build system. Long live core-image-sato!
> 
> Andreas
> -- 
> ___
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel

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


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

Re: [oe] Splitting meta-oe?

2017-02-17 Thread Andreas Müller 
On Fri, Feb 17, 2017 at 6:07 PM, Burton, Ross  wrote:
> The recent storm of breakage in meta-oe caused by recipe specific sysroots
> was quite dramatic:
>
> ross@flashheart ~/Yocto/meta-oe ((044e518...))
> $ git grep PNBLACKLIST| wc -l
> 320
>
> Is it time to talk about splitting meta-oe into smaller real repositories
> so they can be maintained at their own pace by more maintainers?
>
> Ross
What exactly gets better by splitting?

Splitting = Rotting to death due to unmanageable maintenance burden
caused by oe? Don't misunderstand me recipe specific sysroot is
basically a good thing. But I am tired of this game. As you can see in
meta-qt5-extra: I am interested in having cool images not in a cool
build system. Long live core-image-sato!

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

[oe] Splitting meta-oe?

2017-02-17 Thread Burton, Ross 
The recent storm of breakage in meta-oe caused by recipe specific sysroots
was quite dramatic:

ross@flashheart ~/Yocto/meta-oe ((044e518...))
$ git grep PNBLACKLIST| wc -l
320

Is it time to talk about splitting meta-oe into smaller real repositories
so they can be maintained at their own pace by more maintainers?

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

Re: [oe] SUMMARY/DESCRIPTION for "libmodule-build-perl_0.31.bb" refers to "tiny" version

2017-02-17 Thread Tim Orling 

> On Feb 17, 2017, at 3:12 AM, Robert P. J. Day  wrote:
> 
> 
>  just noticed that in meta-openembedded/meta-perl layer, there are
> two recipes for perl module building:
> 
>  * libmodule-build-perl_0.31.bb
>  * libmodule-build-tiny-perl_0.036.bb
> 
> but the SUMMARY and DESCRIPTION for the first (non-tiny) version
> clearly was copied and pasted from the second (tiny) version:
> 
> SUMMARY = "Module::Build::Tiny - A tiny replacement for Module::Build"
> DESCRIPTION = "Many Perl distributions use a Build.PL file instead of a \
> Makefile.PL file to drive distribution configuration, build, test and \
> installation. Traditionally, Build.PL uses Module::Build as the underlying \
> build system. This module provides a simple, lightweight, drop-in 
> replacement. \
> Whereas Module::Build has over 6,700 lines of code; this module has less than 
> \
> 120, yet supports the features needed by most distributions.”
> 

I authored the libmodule-build-tiny-perl recipe. I can’t speak for the 
libmodule-build-perl recipe’s creation process, but it does seem your 
hypothesis is likely.

>  i'm going to let someone higher up the food chain deal with that.
> 

Perhaps you should consider submitting a patch? Here is where the data should 
come from:
https://metacpan.org/pod/Module::Build#DESCRIPTION 




> rday
> 
> -- 
> 
> 
> Robert P. J. Day Ottawa, Ontario, CANADA
>http://crashcourse.ca
> 
> Twitter:   http://twitter.com/rpjday
> LinkedIn:   http://ca.linkedin.com/in/rpjday
> 
> 
> 
> -- 
> ___
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel

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

Re: [oe] DEPENDS += "module-build-perl-native" versus "libmodule-build-perl-native"?

2017-02-17 Thread Tim Orling 

> On Feb 17, 2017, at 2:39 AM, Robert P. J. Day  wrote:

> and, predictably, the meta-cpan layer provides that very recipe:
> 
>  module-build-perl_0.4216.bb
> 

The meta-perl layer follows Debian naming of perl modules:
https://www.debian.org/doc/packaging-manuals/perl-policy/ch-module_packages.html
 


> 
>  thoughts? should some names be cleaned up to prevent this?
> 

There are many other places in the wild where the metadata is not consistent. 
The meta-openembedded/meta-perl layer-- being moderated on a mailing list — has 
some consistency. The meta-cpan layer — being authored by a NetBSD contributor 
and perl module author, on his own — does not follow the same guidelines. This 
by no means diminishes the value of the work Jens has done. But it is still 
Jen’s layer, not an officially supported OpenEmbedded layer.

IMHO, the best solution is to add perl module support to the recipetool so that 
we have an easier way to generate consistent metadata. And then try to convince 
everyone else to use the tool and follow the guidelines. We should also take a 
look at the existing metadata and clean it up.

Another option would be to have the OE community get involved in support of the 
meta-cpan layer and change the module generation code there appropriately to be 
in sync with the Debian naming guidelines.

The challenge for me personally is the same one I always have: TIME.

—Tim


> rday
> 
> -- 
> 
> 
> Robert P. J. Day Ottawa, Ontario, CANADA
>http://crashcourse.ca
> 
> Twitter:   http://twitter.com/rpjday
> LinkedIn:   http://ca.linkedin.com/in/rpjday
> 
> 
> -- 
> ___
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel

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

Re: [oe] [meta-oe][PATCH v2 2/2] meson.bbclass: Add meson.bbclass

2017-02-17 Thread Burton, Ross 
On 16 February 2017 at 15:23, Khem Raj  wrote:

> Perhaps inehriting  pkgconfig would be required too
>

Unless Meson *always* uses pkgconfig, I think this should be something done
in the recipe instead.

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

Re: [oe] [meta-oe][PATCH 1/2] meson: Add recipe for the meson build system

2017-02-17 Thread Burton, Ross 
On 15 February 2017 at 13:43, Martin Jansa  wrote:

> > SRC_URI = "https://github.com/mesonbuild/meson/releases/
> download/${PV}/${BP}.tar.gz"
>
> I'm still not persuaded that the github tarballs aren't regenerated from
> time to time.
>

Upstream also uploads pregenerated tarballs:

https://github.com/mesonbuild/meson/releases/download/0.38.1/meson-0.38.1.tar.gz

That would be preferable IMHO.

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

[oe] [meta-oe][PATCH v2] multipath-tools: fix ARM build failure

2017-02-17 Thread Patrick Ohly 
Updating to 0.6.4 introduced a build failure on ARM when thumb was
enabled because of the embedded valgrind.h macro calls. The easiest
solution and thus the one used here is to disable thumb for this
particular recipe for affected machines.

The more elaborate solution would be to patch the macro calls out of
the code when compiling for ARM with thumb.

Signed-off-by: Patrick Ohly 
---
 meta-oe/recipes-support/multipath-tools/multipath-tools_git.bb | 10 +--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/meta-oe/recipes-support/multipath-tools/multipath-tools_git.bb 
b/meta-oe/recipes-support/multipath-tools/multipath-tools_git.bb
index 6706bec..effd92e 100644
--- a/meta-oe/recipes-support/multipath-tools/multipath-tools_git.bb
+++ b/meta-oe/recipes-support/multipath-tools/multipath-tools_git.bb
@@ -27,6 +27,14 @@ PV = "0.6.4+git${@'${SRCPV}'.split('+')[-1]}"
 
 TARGET_CC_ARCH += "${LDFLAGS}"
 
+# multipath-tools includes a copy of the valgrind.h header
+# file and uses the macros to suppress some false positives. However,
+# that only works on ARM when thumb is disabled. Otherwise one gets:
+#   Error: shifts in CMP/MOV instructions are only supported in unified syntax 
-- `mov r12,r12,ror#3'
+#   ../Makefile.inc:66: recipe for target 'debug.o' failed
+ARM_INSTRUCTION_SET_armv4 = "arm"
+ARM_INSTRUCTION_SET_armv5 = "arm"
+
 # The exact version of SYSTEMD does not matter but should be greater than 209.
 #
 EXTRA_OEMAKE = 'MULTIPATH_VERSION=${PV} DESTDIR=${D} syslibdir=${base_libdir} \
@@ -59,5 +67,3 @@ FILES_kpartx = "${base_sbindir}/kpartx \
"
 
 RDEPENDS_${PN} += "kpartx"
-
-PNBLACKLIST[multipath-tools] ?= "Fails to build with RSS 
http://errors.yoctoproject.org/Errors/Details/130529/;

base-commit: 044e5189549de11b2a94efd29a6009a76162b8f1
-- 
git-series 0.9.1
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

[oe] [meta-python][PATCH] python-pymongo: update to version 3.4.0

2017-02-17 Thread Derek Straka 
Signed-off-by: Derek Straka 
---
 meta-python/recipes-devtools/python/python-pymongo.inc   | 5 +++--
 .../python/{python-pymongo_3.3.1.bb => python-pymongo_3.4.0.bb}  | 0
 .../python/{python3-pymongo_3.3.1.bb => python3-pymongo_3.4.0.bb}| 3 +++
 3 files changed, 6 insertions(+), 2 deletions(-)
 rename meta-python/recipes-devtools/python/{python-pymongo_3.3.1.bb => 
python-pymongo_3.4.0.bb} (100%)
 rename meta-python/recipes-devtools/python/{python3-pymongo_3.3.1.bb => 
python3-pymongo_3.4.0.bb} (58%)

diff --git a/meta-python/recipes-devtools/python/python-pymongo.inc 
b/meta-python/recipes-devtools/python/python-pymongo.inc
index 347c497..e709a36 100644
--- a/meta-python/recipes-devtools/python/python-pymongo.inc
+++ b/meta-python/recipes-devtools/python/python-pymongo.inc
@@ -8,11 +8,12 @@ HOMEPAGE = "http://github.com/mongodb/mongo-python-driver;
 LICENSE = "Apache-2.0"
 LIC_FILES_CHKSUM = "file://LICENSE;md5=2a944942e1496af1886903d274dedb13"
 
-SRC_URI[md5sum] = "0a21c939d66d2459062a4333dab4301b"
-SRC_URI[sha256sum] = 
"4601cd3120e88fb532478f79f29f8f6deab380343d55ad7702a5aa1af27555b1"
+SRC_URI[md5sum] = "aa77f88e51e281c9f328cea701bb6f3e"
+SRC_URI[sha256sum] = 
"d359349c6c9ff9f482805f89e66e476846317dc7b1eea979d7da9c0857ee2721"
 
 RDEPENDS_${PN} += " \
 ${PYTHON_PN}-datetime \
 ${PYTHON_PN}-netclient \
+${PYTHON_PN}-numbers \
 ${PYTHON_PN}-threading \
 "
diff --git a/meta-python/recipes-devtools/python/python-pymongo_3.3.1.bb 
b/meta-python/recipes-devtools/python/python-pymongo_3.4.0.bb
similarity index 100%
rename from meta-python/recipes-devtools/python/python-pymongo_3.3.1.bb
rename to meta-python/recipes-devtools/python/python-pymongo_3.4.0.bb
diff --git a/meta-python/recipes-devtools/python/python3-pymongo_3.3.1.bb 
b/meta-python/recipes-devtools/python/python3-pymongo_3.4.0.bb
similarity index 58%
rename from meta-python/recipes-devtools/python/python3-pymongo_3.3.1.bb
rename to meta-python/recipes-devtools/python/python3-pymongo_3.4.0.bb
index 55b3b55..3b250a1 100644
--- a/meta-python/recipes-devtools/python/python3-pymongo_3.3.1.bb
+++ b/meta-python/recipes-devtools/python/python3-pymongo_3.4.0.bb
@@ -1,7 +1,10 @@
 inherit pypi setuptools3
 require python-pymongo.inc
 
+# Requires _pydecimal which is in misc
 RDEPENDS_${PN} += " \
 ${PYTHON_PN}-enum \
+${PYTHON_PN}-misc \
 ${PYTHON_PN}-selectors \
+${PYTHON_PN}-subprocess \
 "
-- 
2.7.4

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

Re: [oe] [meta-oe][PATCH] multipath-tools: fix ARM build failure

2017-02-17 Thread Patrick Ohly 
On Thu, 2017-02-16 at 02:42 -0800, Andre McCurdy wrote:
> On Thu, Feb 16, 2017 at 2:29 AM, Patrick Ohly  wrote:
> > Updating to 0.6.4 introduced a build failure on ARM when thumb was
> > enabled because of the embedded valgrind.h macro calls. The easiest
> > solution and thus the one used here is to disable thumb for this
> > particular recipe.
> >
> > The more elaborate solution would be to patch the macro calls out of
> > the code when compiling for ARM with thumb.
> >
> > Signed-off-by: Patrick Ohly 
> > ---
> >  meta-oe/recipes-support/multipath-tools/multipath-tools_git.bb |  9 +--
> >  1 file changed, 7 insertions(+), 2 deletions(-)
> >
> > diff --git a/meta-oe/recipes-support/multipath-tools/multipath-tools_git.bb 
> > b/meta-oe/recipes-support/multipath-tools/multipath-tools_git.bb
> > index 6706bec..a3b33b6 100644
> > --- a/meta-oe/recipes-support/multipath-tools/multipath-tools_git.bb
> > +++ b/meta-oe/recipes-support/multipath-tools/multipath-tools_git.bb
> > @@ -27,6 +27,13 @@ PV = "0.6.4+git${@'${SRCPV}'.split('+')[-1]}"
> >
> >  TARGET_CC_ARCH += "${LDFLAGS}"
> >
> > +# multipath-tools includes a copy of the valgrind.h header
> > +# file and uses the macros to suppress some false positives. However,
> > +# that only works on ARM when thumb is disabled. Otherwise one gets:
> > +#   Error: shifts in CMP/MOV instructions are only supported in unified 
> > syntax -- `mov r12,r12,ror#3'
> > +#   ../Makefile.inc:66: recipe for target 'debug.o' failed
> > +ARM_INSTRUCTION_SET = "arm"
> 
> Since the problem is presumably Thumb1 specific, you should only force
> the ARM instruction set for ARM cores which don't support Thumb2, ie
> use:
> 
> ARM_INSTRUCTION_SET_armv4 = "arm"
> ARM_INSTRUCTION_SET_armv5 = "arm"

I'm no ARM expert, so I'm not certain which ARM cores are affected, but
I'll follow your suggestion and send a V2 of the patch.

-- 
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-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

[oe] SUMMARY/DESCRIPTION for "libmodule-build-perl_0.31.bb" refers to "tiny" version

2017-02-17 Thread Robert P. J. Day 

  just noticed that in meta-openembedded/meta-perl layer, there are
two recipes for perl module building:

  * libmodule-build-perl_0.31.bb
  * libmodule-build-tiny-perl_0.036.bb

but the SUMMARY and DESCRIPTION for the first (non-tiny) version
clearly was copied and pasted from the second (tiny) version:

SUMMARY = "Module::Build::Tiny - A tiny replacement for Module::Build"
DESCRIPTION = "Many Perl distributions use a Build.PL file instead of a \
Makefile.PL file to drive distribution configuration, build, test and \
installation. Traditionally, Build.PL uses Module::Build as the underlying \
build system. This module provides a simple, lightweight, drop-in replacement. \
Whereas Module::Build has over 6,700 lines of code; this module has less than \
120, yet supports the features needed by most distributions."

  i'm going to let someone higher up the food chain deal with that.

rday

-- 


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

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



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

[oe] DEPENDS += "module-build-perl-native" versus "libmodule-build-perl-native"?

2017-02-17 Thread Robert P. J. Day 

  i'm sure i asked about this before, but i currently have a hacky
workaround in a build because of the mixture of DEPENDS mentioned in
the subject line.

  first, i've pulled down the meta-cpan layer, where you can see the
consistency of recipes that depend on a native build of the perl build
module:

$ grep -rh "DEPENDS.*module-build-perl-native" *
DEPENDS += "module-build-perl-native"
DEPENDS += "module-build-perl-native"
DEPENDS += "module-build-perl-native"
DEPENDS += "module-build-perl-native"
DEPENDS += "module-build-perl-native"
DEPENDS += "module-build-perl-native"
DEPENDS += "module-build-perl-native"
DEPENDS += "module-build-perl-native"
DEPENDS += "module-build-perl-native"
DEPENDS += "module-build-perl-native"
DEPENDS += "module-build-perl-native"
DEPENDS += "module-build-perl-native"
DEPENDS += "module-build-perl-native"
DEPENDS += "module-build-perl-native"
DEPENDS += "module-build-perl-native"
DEPENDS += "module-build-perl-native"
DEPENDS += "module-build-perl-native"
DEPENDS += "module-build-perl-native"
DEPENDS += "module-build-perl-native"
$

and, predictably, the meta-cpan layer provides that very recipe:

  module-build-perl_0.4216.bb

OTOH, the meta-openembedded/meta-perl layer takes a slightly
different approach:

$ grep -r "DEPENDS.*module-build-perl-native" *
recipes-perl/libhtml/libhtml-tree-perl_5.03.bb:DEPENDS += 
"libmodule-build-perl-native \
$

and provides the equivalent(?) recipe:

  libmodule-build-perl_0.31.bb

the last time i checked, trying to mix those two layers verbatim
generated a build error, since i include recipes which combine the two
dependencies, and try to install the identical content at the same
location. clearly(?), i should restrict the build-time dependencies to one or
the other of those recipes for the native perl build module.

  is this even considered an issue that should be resolved? it seems
that if layers are catalogued at the https://layers.openembedded.org/,
they should be compatible and play nicely together. in this case, it's
just a naming convention incompatibility -- as i recall, the OE naming
convention for perl modules is "lib-perl", while the meta-cpan
does something different; hence, the problem.

  thoughts? should some names be cleaned up to prevent this?

rday

-- 


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

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


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

Re: [oe] [PATCH 1/2] libtdb: fix SRC_URI - http has gone

2017-02-17 Thread Andreas Müller 
On Mon, Feb 6, 2017 at 9:00 PM, Andreas Müller
 wrote:
> Signed-off-by: Andreas Müller 
> ---
>  meta-networking/recipes-support/libtdb/libtdb_1.3.12.bb | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
ping - seems this series got lost - shall I resend?

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

[oe] [meta-oe][PATCH] efivar: update to 0.30 to fix readdir* issues

2017-02-17 Thread Koen Kooi 
Drop patches with upstream fixes.

Signed-off-by: Koen Kooi 
---
 .../efivar/efivar/0002-disable-static-build.patch  | 33 
 .../0004-fix-unknow-option-for-gold-linker.patch   | 38 --
 .../fix-compile-failure-with-host-gcc-4.6.patch| 45 --
 .../efivar/{efivar_0.24.bb => efivar_0.30.bb}  |  8 +---
 4 files changed, 2 insertions(+), 122 deletions(-)
 delete mode 100644 
meta-oe/recipes-extended/efivar/efivar/0002-disable-static-build.patch
 delete mode 100644 
meta-oe/recipes-extended/efivar/efivar/0004-fix-unknow-option-for-gold-linker.patch
 delete mode 100644 
meta-oe/recipes-extended/efivar/efivar/fix-compile-failure-with-host-gcc-4.6.patch
 rename meta-oe/recipes-extended/efivar/{efivar_0.24.bb => efivar_0.30.bb} (72%)

diff --git 
a/meta-oe/recipes-extended/efivar/efivar/0002-disable-static-build.patch 
b/meta-oe/recipes-extended/efivar/efivar/0002-disable-static-build.patch
deleted file mode 100644
index 951b159..000
--- a/meta-oe/recipes-extended/efivar/efivar/0002-disable-static-build.patch
+++ /dev/null
@@ -1,33 +0,0 @@
-From 126e0d3c1ad74cf5b0abe9e98ec444bcc3c83159 Mon Sep 17 00:00:00 2001
-From: Koen Kooi 
-Date: Fri, 4 Mar 2016 14:53:55 +0100
-Subject: [PATCH 2/2] disable static build
-
-Signed-off-by: Koen Kooi 
-
-Upstream-Status: Inappropriate [meta-oe specific]
-Signed-off-by: Hongxu Jia 
-

- src/Makefile | 4 ++--
- 1 file changed, 2 insertions(+), 2 deletions(-)
-
-diff --git a/src/Makefile b/src/Makefile
-index 1829d22..c7a0ca3 100644
 a/src/Makefile
-+++ b/src/Makefile
-@@ -8,9 +8,9 @@ include $(TOPDIR)/Make.defaults
- 
- LIBTARGETS=libefivar.so libefiboot.so
- STATICLIBTARGETS=libefivar.a libefiboot.a
--BINTARGETS=efivar efivar-static
-+BINTARGETS=efivar
- PCTARGETS=efivar.pc efiboot.pc
--TARGETS=$(LIBTARGETS) $(STATICLIBTARGETS) $(BINTARGETS) $(PCTARGETS)
-+TARGETS=$(LIBTARGETS) $(BINTARGETS) $(PCTARGETS)
- 
- LIBEFIBOOT_SOURCES = crc32.c creator.c disk.c gpt.c linux.c loadopt.c
- LIBEFIBOOT_OBJECTS = $(patsubst %.c,%.o,$(LIBEFIBOOT_SOURCES))
--- 
-2.4.3
-
diff --git 
a/meta-oe/recipes-extended/efivar/efivar/0004-fix-unknow-option-for-gold-linker.patch
 
b/meta-oe/recipes-extended/efivar/efivar/0004-fix-unknow-option-for-gold-linker.patch
deleted file mode 100644
index 5d50c19..000
--- 
a/meta-oe/recipes-extended/efivar/efivar/0004-fix-unknow-option-for-gold-linker.patch
+++ /dev/null
@@ -1,38 +0,0 @@
-From b3d35e7dd27a755df5acbe050837885914dbb28b Mon Sep 17 00:00:00 2001
-From: Hongxu Jia 
-Date: Tue, 10 May 2016 11:34:50 -0400
-Subject: [PATCH]  fix unknow option for gold linker
-
-- Revert the following patch, since oe-core work with gcc 5
-...
-commit 3055a3797f16693dfdd855fa68bc57fd900dc408
-Author: Peter Jones 
-Date:   Mon Feb 15 14:15:40 2016 -0500
-
-Make gcc.specs work with gcc 6 / binutils 2.26
-
-Apparently binutils 2.26 gets real picky about "ld -PIC" vs "ld -fPIC".
-
-Signed-off-by: Peter Jones 
-...
-
-- Remove unknown option '--add-needed'
-
-Signed-off-by: Hongxu Jia 

- gcc.specs | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/gcc.specs b/gcc.specs
-index 24fabc2..5b0fdef 100644
 a/gcc.specs
-+++ b/gcc.specs
-@@ -14,4 +14,4 @@
- + %{!shared:%{!static:%{!r:-pie}}} %{static:-Wl,-no-fatal-warnings 
-Wl,-static -static -Wl,-z,relro,-z,now}
- 
- *link:
--+ %{!static:--fatal-warnings} --no-undefined-version 
--no-allow-shlib-undefined --add-needed -z now --build-id 
%{!static:%{!shared:-PIE}} %{shared:-z relro -PIC} %{static:%
-Date: Thu, 26 May 2016 21:50:01 -0400
-Subject: [PATCH] fix compile failure with older host gcc (<=4.6)
-
-While host gcc version is 4.6.3 in ubuntu 1204, it
-did not recognize -std=gnu11 and -Wmaybe-uninitialized.
-
-While host gcc version is 4.4.7 in centos6, it
-did not recognize -std=gnu11, -Wmaybe-uninitialized,
-and -flto.
-
-For native build, use -std=gnu99 to replace -std=gnu11,
-and directly remove -Wmaybe-uninitialized and -flto.
-
-Upstream-Status: Pending
-
-Signed-off-by: Hongxu Jia 

- gcc.specs | 4 ++--
- 1 file changed, 2 insertions(+), 2 deletions(-)
-
-diff