[OE-core] [PATCH v2] uclibc: fix undefinition of '_dl_strchr' in libdl.a
The orign_path.patch introduced '_dl_strchr' in ldso/ldso/dl-elf.c, and
caused the following undefined referencing compiling error:
| .../libdl.a(libdl.os): In function `search_for_named_library':
| .../dl-elf.c:156: undefined reference to `_dl_strchr'
| collect2: error: ld returned 1 exit status
I found this problem when compiling gdb in static mode using uclibc.
So, add the definition of '_dl_strchr' to fix it. The '_dl_strstr' is
added as well.
And I regenerated a patch to replace the original one.
Signed-off-by: Junling Zheng zhengjunl...@huawei.com
---
meta/recipes-core/uclibc/uclibc-git.inc| 2 +-
...ldso-limited-support-for-ORIGIN-in-rpath.patch} | 92 --
2 files changed, 69 insertions(+), 25 deletions(-)
rename meta/recipes-core/uclibc/uclibc-git/{orign_path.patch =
0001-ldso-limited-support-for-ORIGIN-in-rpath.patch} (63%)
diff --git a/meta/recipes-core/uclibc/uclibc-git.inc
b/meta/recipes-core/uclibc/uclibc-git.inc
index a2b2353..8308e60 100644
--- a/meta/recipes-core/uclibc/uclibc-git.inc
+++ b/meta/recipes-core/uclibc/uclibc-git.inc
@@ -15,7 +15,7 @@ SRC_URI = git://uclibc.org/uClibc.git;branch=master \
file://argp-headers.patch \
file://remove_attribute_optimize_Os.patch \
file://compile-arm-fork-with-O2.patch \
- file://orign_path.patch \
+ file://0001-ldso-limited-support-for-ORIGIN-in-rpath.patch \
file://0001-atexit_old-Do-not-add-it-to-shared-libc.patch \
file://0001-nptl-arm-Move-aeabi_read_tp-to-uclibc_nonshared.a.patch \
file://0001-nptl-atfork-Hide-pthread_atfork-in-shared-versions.patch \
diff --git a/meta/recipes-core/uclibc/uclibc-git/orign_path.patch
b/meta/recipes-core/uclibc/uclibc-git/0001-ldso-limited-support-for-ORIGIN-in-rpath.patch
similarity index 63%
rename from meta/recipes-core/uclibc/uclibc-git/orign_path.patch
rename to
meta/recipes-core/uclibc/uclibc-git/0001-ldso-limited-support-for-ORIGIN-in-rpath.patch
index 81bb8f8..7479ec3 100644
--- a/meta/recipes-core/uclibc/uclibc-git/orign_path.patch
+++
b/meta/recipes-core/uclibc/uclibc-git/0001-ldso-limited-support-for-ORIGIN-in-rpath.patch
@@ -1,13 +1,56 @@
-Patch is backported from
+From 32eaf738faafad2b16e1f3f5beb91736b3c27a3b Mon Sep 17 00:00:00 2001
+From: Junling Zheng zhengjunl...@huawei.com
+Date: Fri, 3 Apr 2015 05:02:27 +
+Subject: [PATCH] ldso: limited support for $ORIGIN in rpath
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+Derived from:
http://lists.busybox.net/pipermail/uclibc/2011-March/045003.html
-Upstream-Status: Pending
+However, the above patch introduced '_dl_strchr' in ldso/ldso/dl-elf.c,
+and caused the following undefined referencing compiling error:
+
+ | .../libdl.a(libdl.os): In function `search_for_named_library':
+ | .../dl-elf.c:156: undefined reference to `_dl_strchr'
+ | collect2: error: ld returned 1 exit status
+
+This problem would be reproduced through compiling gdb in static mode
+using uclibc.
+
+So, add the definition of '_dl_strchr' to fix it. The '_dl_strstr' is
+added as well.
-Index: git/ldso/ldso/dl-elf.c
-===
git.orig/ldso/ldso/dl-elf.c2012-06-19 18:29:08.629931662 -0700
-+++ git/ldso/ldso/dl-elf.c 2012-06-19 21:21:14.798431393 -0700
-@@ -133,56 +133,60 @@
+Upstream-Status: Submitted
+
+Signed-off-by: Timo Teräs timo.teras at iki.fi
+Signed-off-by: Junling Zheng zhengjunl...@huawei.com
+---
+ ldso/include/dl-string.h | 2 ++
+ ldso/ldso/dl-elf.c | 79 +---
+ ldso/ldso/ldso.c | 18 +--
+ 3 files changed, 59 insertions(+), 40 deletions(-)
+
+diff --git a/ldso/include/dl-string.h b/ldso/include/dl-string.h
+index aacad10..14ae617 100644
+--- a/ldso/include/dl-string.h
b/ldso/include/dl-string.h
+@@ -204,7 +204,9 @@ static __always_inline char *
_dl_get_last_path_component(char *path)
+ # define _dl_strcat strcat
+ # define _dl_strcpy strcpy
+ # define _dl_strcmp strcmp
++# define _dl_strchr strchr
+ # define _dl_strrchr strrchr
++# define _dl_strstr strstr
+ # define _dl_memcpy memcpy
+ # define _dl_memcmp memcmp
+ # define _dl_memset memset
+diff --git a/ldso/ldso/dl-elf.c b/ldso/ldso/dl-elf.c
+index 1b06bc1..b323c90 100644
+--- a/ldso/ldso/dl-elf.c
b/ldso/ldso/dl-elf.c
+@@ -133,56 +133,60 @@ _dl_protect_relro (struct elf_resolve *l)
* in uClibc/ldso/util/ldd.c */
static struct elf_resolve *
search_for_named_library(const char *name, unsigned rflags, const char
*path_list,
@@ -16,9 +59,9 @@ Index: git/ldso/ldso/dl-elf.c
{
- char *path, *path_n, *mylibname;
+ char *mylibname;
++ const char *p, *pn;
struct elf_resolve *tpnt;
- int done;
-+ const char *p, *pn;
+ int plen;
if (path_list==NULL)
@@ -100,7 +143,7 @@ Index: git/ldso/ldso/dl-elf.c
return NULL;
}
-@@ -234,8 +238,10 @@
+@@
Re: [OE-core] [PATCH] valgrind: Add INSANE_SKIP of arch for valgrind and valgrind-dbg
On 4/3/15 9:57 AM, Krishnanjanappa, Jagadeesh wrote:
what is the point of packaging files for which there won’t be any runtime
environment. You are just better of removing them.
IMO unless you have multilib environment working
this patch is just relaxing the QA
With compilers supporting generation of multilib and yocto framework
supporting generation of multilib rootfs, one can have this environment
often. Instead of removing them, as said we can disable them from generation
using configure options. Also the valgrind rpm package do include this files
in its package.
Link:
http://www.rpmfind.net//linux/RPM/opensuse/13.2/x86_64/valgrind-3.10.0-1.1.x86_64.html
With a multilib configuration, these things should be packaged per-multilib and
then only the installed multilib components are available on the device. It
saves space and preserves the checking in place to catch situations where you
may accidentally provide software that isn't runnable.
The other problem with permitting the system to query the compiler is the output
of the build is no longer deterministic. If the toolchain configuration
changes, then the output of valgrind changes. That should not happen.
--Mark
Regards,
Jagadeesh
From: Khem Raj raj.k...@gmail.com
Sent: Friday, April 3, 2015 8:28 AM
To: Krishnanjanappa, Jagadeesh
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [PATCH] valgrind: Add INSANE_SKIP of arch for valgrind
and valgrind-dbg
On Apr 2, 2015, at 11:47 AM, Krishnanjanappa, Jagadeesh
jagadeesh.krishnanjana...@caviumnetworks.com wrote:
From: Krishnanjanappa, Jagadeesh
jagadeesh.krishnanjana...@caviumnetworks.com
If a complier supports generating 32-bit and 64-bit binaries, then
while building valgrind we have two sets of binaries (32-bit and 64-bit)
being generated.
Example: With compiler supporting generation of both 32-bit and 64-bit
binaries, and building valgrind in 64-bit mode, we come across following
QA Issue (listing only few of them),
(snip)
ERROR: QA Issue: Architecture did not match (62 to 3) on
${WORKDIR}/valgrind/3.10.1-r0/packages-split/valgrind-dbg/usr/lib64/valgrind/.debug/vgpreload_exp-sgcheck-x86-linux.so
ERROR: QA Issue: Architecture did not match (62 to 3) on
${WORKDIR}/valgrind/3.10.1-r0/packages-split/valgrind-dbg/usr/lib64/valgrind/.debug/getoff-x86-linux
ERROR: QA Issue: Architecture did not match (62 to 3) on
${WORKDIR}/valgrind/3.10.1-r0/packages-split/valgrind-dbg/usr/lib64/valgrind/.debug/vgpreload_core-x86-linux.so
ERROR: QA Issue: Architecture did not match (62 to 3) on
${WORKDIR}/valgrind/3.10.1-r0/packages-split/valgrind-dbg/usr/lib64/valgrind/.debug/vgpreload_memcheck-x86-linux.so
-- CUT --
However, we can build only 64-bit or 32-bit binaries in valgrind using
--enable-only64bit and --enable-only32bit configure options respectively.
And the required configure option can be selected based on SITEINFO_BITS, but
feel that if a compiler supports generation of both type of binaries and it
may be useful for users to have/execute both type of binaries on multilib
environment. So choosing to pack both types of binaries and skip errors if
the
architecture type are different using INSANE_SKIP.
what is the point of packaging files for which there won’t be any runtime
environment. You are just better of removing them.
IMO unless you have multilib environment working
this patch is just relaxing the QA
Signed-off-by: Krishnanjanappa, Jagadeesh
jagadeesh.krishnanjana...@caviumnetworks.com
---
meta/recipes-devtools/valgrind/valgrind_3.10.1.bb | 9 +
1 file changed, 9 insertions(+)
diff --git a/meta/recipes-devtools/valgrind/valgrind_3.10.1.bb
b/meta/recipes-devtools/valgrind/valgrind_3.10.1.bb
index bf80b16..eaa64c4 100644
--- a/meta/recipes-devtools/valgrind/valgrind_3.10.1.bb
+++ b/meta/recipes-devtools/valgrind/valgrind_3.10.1.bb
@@ -32,6 +32,8 @@ SRC_URI[sha256sum] =
fa253dc26ddb661b6269df58144eff607ea3f76a9bcfe574b0c7726e1d
COMPATIBLE_HOST = '(i.86|x86_64|mips|powerpc|powerpc64).*-linux'
COMPATIBLE_HOST_armv7a = 'arm.*-linux'
+PR = r1
+
inherit autotools ptest
EXTRA_OECONF = --enable-tls --without-mpicc
@@ -52,6 +54,13 @@ RRECOMMENDS_${PN} += ${TCLIBC}-dbg
RDEPENDS_${PN}-ptest += sed perl glibc-utils perl-module-file-glob
+# skip checking of the Executable and Linkable Format (ELF) type, bit
+# size, and endianness of any binaries. If a compiler supports
+# generating 32-bit, 64-bit binaries, then we have two sets of
+# binaries i.e 32-bit and 64-bit.
+INSANE_SKIP_${PN} += arch
+INSANE_SKIP_${PN}-dbg += arch
+
do_compile_ptest() {
oe_runmake check
}
--
1.8.2.3
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
___
Re: [OE-core] [PATCH] valgrind: Add INSANE_SKIP of arch for valgrind and valgrind-dbg
what is the point of packaging files for which there won’t be any runtime
environment. You are just better of removing them.
IMO unless you have multilib environment working
this patch is just relaxing the QA
With compilers supporting generation of multilib and yocto framework supporting
generation of multilib rootfs, one can have this environment often. Instead of
removing them, as said we can disable them from generation using configure
options. Also the valgrind rpm package do include this files in its package.
Link:
http://www.rpmfind.net//linux/RPM/opensuse/13.2/x86_64/valgrind-3.10.0-1.1.x86_64.html
Regards,
Jagadeesh
From: Khem Raj raj.k...@gmail.com
Sent: Friday, April 3, 2015 8:28 AM
To: Krishnanjanappa, Jagadeesh
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [PATCH] valgrind: Add INSANE_SKIP of arch for valgrind
and valgrind-dbg
On Apr 2, 2015, at 11:47 AM, Krishnanjanappa, Jagadeesh
jagadeesh.krishnanjana...@caviumnetworks.com wrote:
From: Krishnanjanappa, Jagadeesh
jagadeesh.krishnanjana...@caviumnetworks.com
If a complier supports generating 32-bit and 64-bit binaries, then
while building valgrind we have two sets of binaries (32-bit and 64-bit)
being generated.
Example: With compiler supporting generation of both 32-bit and 64-bit
binaries, and building valgrind in 64-bit mode, we come across following
QA Issue (listing only few of them),
(snip)
ERROR: QA Issue: Architecture did not match (62 to 3) on
${WORKDIR}/valgrind/3.10.1-r0/packages-split/valgrind-dbg/usr/lib64/valgrind/.debug/vgpreload_exp-sgcheck-x86-linux.so
ERROR: QA Issue: Architecture did not match (62 to 3) on
${WORKDIR}/valgrind/3.10.1-r0/packages-split/valgrind-dbg/usr/lib64/valgrind/.debug/getoff-x86-linux
ERROR: QA Issue: Architecture did not match (62 to 3) on
${WORKDIR}/valgrind/3.10.1-r0/packages-split/valgrind-dbg/usr/lib64/valgrind/.debug/vgpreload_core-x86-linux.so
ERROR: QA Issue: Architecture did not match (62 to 3) on
${WORKDIR}/valgrind/3.10.1-r0/packages-split/valgrind-dbg/usr/lib64/valgrind/.debug/vgpreload_memcheck-x86-linux.so
-- CUT --
However, we can build only 64-bit or 32-bit binaries in valgrind using
--enable-only64bit and --enable-only32bit configure options respectively.
And the required configure option can be selected based on SITEINFO_BITS, but
feel that if a compiler supports generation of both type of binaries and it
may be useful for users to have/execute both type of binaries on multilib
environment. So choosing to pack both types of binaries and skip errors if the
architecture type are different using INSANE_SKIP.
what is the point of packaging files for which there won’t be any runtime
environment. You are just better of removing them.
IMO unless you have multilib environment working
this patch is just relaxing the QA
Signed-off-by: Krishnanjanappa, Jagadeesh
jagadeesh.krishnanjana...@caviumnetworks.com
---
meta/recipes-devtools/valgrind/valgrind_3.10.1.bb | 9 +
1 file changed, 9 insertions(+)
diff --git a/meta/recipes-devtools/valgrind/valgrind_3.10.1.bb
b/meta/recipes-devtools/valgrind/valgrind_3.10.1.bb
index bf80b16..eaa64c4 100644
--- a/meta/recipes-devtools/valgrind/valgrind_3.10.1.bb
+++ b/meta/recipes-devtools/valgrind/valgrind_3.10.1.bb
@@ -32,6 +32,8 @@ SRC_URI[sha256sum] =
fa253dc26ddb661b6269df58144eff607ea3f76a9bcfe574b0c7726e1d
COMPATIBLE_HOST = '(i.86|x86_64|mips|powerpc|powerpc64).*-linux'
COMPATIBLE_HOST_armv7a = 'arm.*-linux'
+PR = r1
+
inherit autotools ptest
EXTRA_OECONF = --enable-tls --without-mpicc
@@ -52,6 +54,13 @@ RRECOMMENDS_${PN} += ${TCLIBC}-dbg
RDEPENDS_${PN}-ptest += sed perl glibc-utils perl-module-file-glob
+# skip checking of the Executable and Linkable Format (ELF) type, bit
+# size, and endianness of any binaries. If a compiler supports
+# generating 32-bit, 64-bit binaries, then we have two sets of
+# binaries i.e 32-bit and 64-bit.
+INSANE_SKIP_${PN} += arch
+INSANE_SKIP_${PN}-dbg += arch
+
do_compile_ptest() {
oe_runmake check
}
--
1.8.2.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] [PATCH 1/5] bluez5: upgrade to 5.29
On 03/04/2015 15:13, Cristian Iorga wrote:
- Large release with over a month and 475 commits since 5.28;
- Internal GATT library received lots of updates;
- Fix for AVCTP key repeat timeout;
- Added support for the Multi Profile Specification (MPS).
Signed-off-by: Cristian Iorga cristian.io...@intel.com
---
meta/recipes-connectivity/bluez5/{bluez5_5.28.bb = bluez5_5.29.bb} | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
rename meta/recipes-connectivity/bluez5/{bluez5_5.28.bb = bluez5_5.29.bb}
(88%)
diff --git a/meta/recipes-connectivity/bluez5/bluez5_5.28.bb
b/meta/recipes-connectivity/bluez5/bluez5_5.29.bb
similarity index 88%
rename from meta/recipes-connectivity/bluez5/bluez5_5.28.bb
rename to meta/recipes-connectivity/bluez5/bluez5_5.29.bb
index e816998..0fe8e7f 100644
--- a/meta/recipes-connectivity/bluez5/bluez5_5.28.bb
+++ b/meta/recipes-connectivity/bluez5/bluez5_5.29.bb
@@ -1,6 +1,6 @@
require bluez5.inc
-SRC_URI[md5sum] = bc20a8285530758c68f6a60e4ca62a15
-SRC_URI[sha256sum] =
85bab48f4b47a158739028682c1e09cf30099c8ea9dfe63360055f8e06fc18a9
+SRC_URI[md5sum] = aa9dc91689695a486c78c131cd68673e
+SRC_URI[sha256sum] =
df216a6d5ec6133355e5d4ed6b5e7a188a940940d337374e166758513246f0e4
# noinst programs in Makefile.tools that are conditional on READLINE
# support
5.30 is available now I think
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] meta/lib/oe/utils.py: Corrected the return value of both_contain()
On Fri, Apr 3, 2015 at 11:34 AM, Jun Zhu r01...@freescale.com wrote: oe.utils.both_contain() should return the result as checkvalue or , but the latest implement returns as set(['checkvalue']) or ; It causes that bitbake.conf generates the wrong result of COMBINED_FEATURES, which contains the common components in both DISTRO_FEATURE and MACHINE_FEATURES. For example, build in Dizzy branch, COMBINED_FEATURES is alsa usbhost ..., but recently, COMBINED_FEATURES is like set(['alsa']) set(['usbhost']) Signed-off-by: Jun Zhu r01...@freescale.com Tested-by: Otavio Salvador ota...@ossystems.com.br Acked-by: Otavio Salvador ota...@ossystems.com.br -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2] valgrind: add configure option to build only 32-bit or 64-bit components
From: Krishnanjanappa, Jagadeesh
jagadeesh.krishnanjana...@caviumnetworks.com
Building both 32-bit and 64-bit binaries in valgrind at a time would
lead to following QA issue as below,
(snip)
ERROR: QA Issue: Architecture did not match (62 to 3) on
${WORKDIR}/valgrind/3.10.1-r0/packages-split/valgrind-dbg/usr/lib64/valgrind/.debug/vgpreload_exp-sgcheck-x86-linux.so
ERROR: QA Issue: Architecture did not match (62 to 3) on
${WORKDIR}/valgrind/3.10.1-r0/packages-split/valgrind-dbg/usr/lib64/valgrind/.debug/getoff-x86-linux
ERROR: QA Issue: Architecture did not match (62 to 3) on
${WORKDIR}/valgrind/3.10.1-r0/packages-split/valgrind-dbg/usr/lib64/valgrind/.debug/vgpreload_core-x86-linux.so
ERROR: QA Issue: Architecture did not match (62 to 3) on
${WORKDIR}/valgrind/3.10.1-r0/packages-split/valgrind-dbg/usr/lib64/valgrind/.debug/vgpreload_memcheck-x86-linux.so
-- CUT --
hence perform only one type of build 32-bit or 64-bit, but not both.
Signed-off-by: Krishnanjanappa, Jagadeesh
jagadeesh.krishnanjana...@caviumnetworks.com
---
meta/recipes-devtools/valgrind/valgrind_3.10.1.bb | 3 +++
1 file changed, 3 insertions(+)
diff --git a/meta/recipes-devtools/valgrind/valgrind_3.10.1.bb
b/meta/recipes-devtools/valgrind/valgrind_3.10.1.bb
index bf80b16..ac50d2e 100644
--- a/meta/recipes-devtools/valgrind/valgrind_3.10.1.bb
+++ b/meta/recipes-devtools/valgrind/valgrind_3.10.1.bb
@@ -32,10 +32,13 @@ SRC_URI[sha256sum] =
fa253dc26ddb661b6269df58144eff607ea3f76a9bcfe574b0c7726e1d
COMPATIBLE_HOST = '(i.86|x86_64|mips|powerpc|powerpc64).*-linux'
COMPATIBLE_HOST_armv7a = 'arm.*-linux'
+PR = r1
+
inherit autotools ptest
EXTRA_OECONF = --enable-tls --without-mpicc
EXTRA_OECONF_armv7a = --enable-tls -host=armv7-none-linux-gnueabi
--without-mpicc
+EXTRA_OECONF +=
${@['--enable-only32bit','--enable-only64bit'][d.getVar('SITEINFO_BITS', True)
!= '32']}
EXTRA_OEMAKE = -w
do_install_append () {
--
1.8.2.3
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] oe.sstatesig: align swspec handling with sstate.bbclass
The logic tries to remove the -native suffix from pn to handle this (though it
doesn't succeed, as it doesn't assign the new pn to the variable), but we need
to do more for the swspec tasks than just not set the extrapath, we also need
to change from SSTATE_PKGSPEC to SSTATE_SWSPEC. Alter to correct the spec for
these cases, and also add preconfigure to align with the current logic in
sstate.bbclass, which includes that task as well in the list of tasks to
adjust to use swspec.
[YOCTO #7563]
Signed-off-by: Christopher Larson kerg...@gmail.com
---
meta/lib/oe/sstatesig.py | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/meta/lib/oe/sstatesig.py b/meta/lib/oe/sstatesig.py
index 62e75c2..9d6d7c4 100644
--- a/meta/lib/oe/sstatesig.py
+++ b/meta/lib/oe/sstatesig.py
@@ -206,9 +206,6 @@ def find_siginfo(pn, taskname, taskhashlist, d):
if key.startswith('virtual:native:'):
pn = pn + '-native'
-if taskname in ['do_fetch', 'do_unpack', 'do_patch', 'do_populate_lic']:
-pn.replace(-native, )
-
filedates = {}
# First search in stamps dir
@@ -249,7 +246,10 @@ def find_siginfo(pn, taskname, taskhashlist, d):
localdata.setVar('PV', '*')
localdata.setVar('PR', '*')
localdata.setVar('BB_TASKHASH', hashval)
-if pn.endswith('-native') or -cross- in pn or -crosssdk- in pn:
+swspec = localdata.getVar('SSTATE_SWSPEC', True)
+if taskname in ['do_fetch', 'do_unpack', 'do_patch',
'do_populate_lic', 'do_preconfigure'] and swspec:
+localdata.setVar('SSTATE_PKGSPEC', '${SSTATE_SWSPEC}')
+elif pn.endswith('-native') or -cross- in pn or -crosssdk- in
pn:
localdata.setVar('SSTATE_EXTRAPATH', ${NATIVELSBSTRING}/)
sstatename = taskname[3:]
filespec = '%s_%s.*.siginfo' % (localdata.getVar('SSTATE_PKG',
True), sstatename)
--
2.2.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/2] libevent: update 2.0.21 - 2.0.22
Signed-off-by: Andre McCurdy armccu...@gmail.com
---
.../libevent/libevent-2.0.21/disable_tests.patch | 15 ---
.../libevent-2.0.21/obsolete_automake_macros.patch| 15 ---
.../libevent/{libevent_2.0.21.bb = libevent_2.0.22.bb} | 11 +++
3 files changed, 3 insertions(+), 38 deletions(-)
delete mode 100644
meta/recipes-support/libevent/libevent-2.0.21/disable_tests.patch
delete mode 100644
meta/recipes-support/libevent/libevent-2.0.21/obsolete_automake_macros.patch
rename meta/recipes-support/libevent/{libevent_2.0.21.bb =
libevent_2.0.22.bb} (61%)
diff --git a/meta/recipes-support/libevent/libevent-2.0.21/disable_tests.patch
b/meta/recipes-support/libevent/libevent-2.0.21/disable_tests.patch
deleted file mode 100644
index 5d2c690..000
--- a/meta/recipes-support/libevent/libevent-2.0.21/disable_tests.patch
+++ /dev/null
@@ -1,15 +0,0 @@
-Upstream-Status: Inappropriate [disable feature]
-
-Signed-off-by: Marko Lindqvist cazf...@gmail.com
-diff -Nurd libevent-2.0.21-stable/test/Makefile.am
libevent-2.0.21-stable/test/Makefile.am
libevent-2.0.21-stable/test/Makefile.am2012-05-31 07:08:19.0
+0300
-+++ libevent-2.0.21-stable/test/Makefile.am2013-02-08 02:06:20.227475872
+0200
-@@ -19,8 +19,6 @@
- EXTRA_PROGRAMS = regress
- noinst_HEADERS = tinytest.h tinytest_macros.h regress.h tinytest_local.h
-
--TESTS = $(top_srcdir)/test/test.sh
--
- BUILT_SOURCES =
- if BUILD_REGRESS
- BUILT_SOURCES += regress.gen.c regress.gen.h
diff --git
a/meta/recipes-support/libevent/libevent-2.0.21/obsolete_automake_macros.patch
b/meta/recipes-support/libevent/libevent-2.0.21/obsolete_automake_macros.patch
deleted file mode 100644
index b559232..000
---
a/meta/recipes-support/libevent/libevent-2.0.21/obsolete_automake_macros.patch
+++ /dev/null
@@ -1,15 +0,0 @@
-Upstream-Status: Submitted
[https://sourceforge.net/tracker/?func=detailaid=3603774group_id=50884atid=461322]
-
-Signed-off-by: Marko Lindqvist cazf...@gmail.com
-diff -Nurd libevent-2.0.21-stable/configure.in
libevent-2.0.21-stable/configure.in
libevent-2.0.21-stable/configure.in2012-11-18 08:34:13.0
+0200
-+++ libevent-2.0.21-stable/configure.in2013-02-08 02:03:58.403476183
+0200
-@@ -12,7 +12,7 @@
- AC_CONFIG_MACRO_DIR([m4])
-
- AM_INIT_AUTOMAKE(libevent,2.0.21-stable)
--AM_CONFIG_HEADER(config.h)
-+AC_CONFIG_HEADERS(config.h)
- AC_DEFINE(NUMERIC_VERSION, 0x02001500, [Numeric representation of the
version])
-
- dnl Initialize prefix.
diff --git a/meta/recipes-support/libevent/libevent_2.0.21.bb
b/meta/recipes-support/libevent/libevent_2.0.22.bb
similarity index 61%
rename from meta/recipes-support/libevent/libevent_2.0.21.bb
rename to meta/recipes-support/libevent/libevent_2.0.22.bb
index e198f09..3f9475e 100644
--- a/meta/recipes-support/libevent/libevent_2.0.21.bb
+++ b/meta/recipes-support/libevent/libevent_2.0.22.bb
@@ -6,15 +6,10 @@ SECTION = libs
LICENSE = BSD
LIC_FILES_CHKSUM = file://LICENSE;md5=45c5316ff684bcfe2f9f86d8b1279559
-PR = r1
+SRC_URI = ${SOURCEFORGE_MIRROR}/levent/${BP}-stable.tar.gz
-SRC_URI = ${SOURCEFORGE_MIRROR}/levent/${BP}-stable.tar.gz \
- file://obsolete_automake_macros.patch \
- file://disable_tests.patch \
-
-
-SRC_URI[md5sum] = b2405cc9ebf264aa47ff615d9de527a2
-SRC_URI[sha256sum] =
22a530a8a5ba1cb9c080cba033206b17dacd21437762155c6d30ee6469f574f5
+SRC_URI[md5sum] = c4c56f986aa985677ca1db89630a2e11
+SRC_URI[sha256sum] =
71c2c49f0adadacfdbe6332a372c38cf9c8b7895bb73dabeaa53cdcc1d4e1fa3
S = ${WORKDIR}/${BPN}-${PV}-stable
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/2] libevent: control openssl support via PACKAGECONFIG
Signed-off-by: Andre McCurdy armccu...@gmail.com
---
meta/recipes-support/libevent/libevent_2.0.21.bb | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-support/libevent/libevent_2.0.21.bb
b/meta/recipes-support/libevent/libevent_2.0.21.bb
index 1230e92..e198f09 100644
--- a/meta/recipes-support/libevent/libevent_2.0.21.bb
+++ b/meta/recipes-support/libevent/libevent_2.0.21.bb
@@ -18,7 +18,8 @@ SRC_URI[sha256sum] =
22a530a8a5ba1cb9c080cba033206b17dacd21437762155c6d30ee6469
S = ${WORKDIR}/${BPN}-${PV}-stable
-EXTRA_OECONF = --disable-openssl
+PACKAGECONFIG ??=
+PACKAGECONFIG[openssl] = --enable-openssl,--disable-openssl,openssl
inherit autotools
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/3] piglit: add PACKAGECONFIG for freeglut
On 04/02/2015 07:10 PM, Burton, Ross wrote: On 2 April 2015 at 04:24, Robert Yang liezhi.y...@windriver.com mailto:liezhi.y...@windriver.com wrote: I'm afraid not since it depends on virtual/libx11. So what's gained by disabling freeglut? Shouldn't we be enabling it if possible? There is no freeglut in oe-core, so I think that we need disable it by default. // Robert Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 5/5] bluetooth.bbclass: set bluez5 as the default BT stack
For a distro that contains bluetooth feature, set bluez5
as the default Bluetooth stack, while still allowing the
use of bluez4 as an alternative Bluetooth stack.
Signed-off-by: Cristian Iorga cristian.io...@intel.com
---
meta/classes/bluetooth.bbclass | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/meta/classes/bluetooth.bbclass b/meta/classes/bluetooth.bbclass
index f88b4ae..3816e7d 100644
--- a/meta/classes/bluetooth.bbclass
+++ b/meta/classes/bluetooth.bbclass
@@ -1,14 +1,20 @@
# Avoid code duplication in bluetooth-dependent recipes.
-# Define a variable that expands to the recipe (package) providing core
-# bluetooth support on the platform:
+# Define a variable that expands to the recipe (package) providing
+# core bluetooth support on the platform:
# if bluetooth is not in DISTRO_FEATURES
-# else bluez5 if bluez5 is in DISTRO_FEATURES
-# else bluez4
+# else bluez4 if bluez4 is in DISTRO_FEATURES
+# else bluez5
# Use this with:
# inherit bluetooth
# PACKAGECONFIG ??= ${@bb.utils.contains('DISTRO_FEATURES', 'bluetooth',
'${BLUEZ}', '', d)}
# PACKAGECONFIG[bluez4] = --enable-bluez4,--disable-bluez4,bluez4
+# if the obsolete, but still supported bluez4 BT stack is used
+# or
+# inherit bluetooth
+# PACKAGECONFIG ??= ${@bb.utils.contains('DISTRO_FEATURES', 'bluetooth',
'${BLUEZ}', '', d)}
+# PACKAGECONFIG[bluez5] = --enable-bluez5,--disable-bluez5,bluez5
+# if the default bluez5 BT stack is used
-BLUEZ ?= ${@bb.utils.contains('DISTRO_FEATURES', 'bluetooth',
bb.utils.contains('DISTRO_FEATURES', 'bluez5', 'bluez5', 'bluez4', d), '', d)}
+BLUEZ ?= ${@bb.utils.contains('DISTRO_FEATURES', 'bluetooth',
bb.utils.contains('DISTRO_FEATURES', 'bluez4', 'bluez4', 'bluez5', d), '', d)}
--
2.1.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/5] bluez: remove recipes collection
BlueZ 4.x and associated recipes are now obsolete
(bluez4, bluez-hcidump, gst-plugin-bluetooth).
Will be moved into networking collection of meta-oe.
BlueZ 4.x is still usable in oe-core as alternative Bluetooth stack.
Signed-off-by: Cristian Iorga cristian.io...@intel.com
---
.../obsolete_automake_macros.patch | 14 ---
.../bluez/bluez-hcidump_2.5.bb | 22 ---
.../bluez/bluez4-4.101/bluetooth.conf | 16
.../bluez/bluez4-4.101/fix-udev-paths.patch| 37 -
.../bluez/bluez4-4.101/install-test-script.patch | 26
...ork-fix-network-Connect-method-parameters.patch | 30 --
.../bluez4-4.101/obsolete_automake_macros.patch| 14 ---
.../bluez/bluez4-4.101/sbc_mmx.patch | 24 ---
...pygobject-instead-ofgobject-introspection.patch | 27 -
meta/recipes-connectivity/bluez/bluez4.inc | 46 --
meta/recipes-connectivity/bluez/bluez4_4.101.bb| 46 --
.../bluez/gst-plugin-bluetooth_4.101.bb| 39 --
12 files changed, 341 deletions(-)
delete mode 100644
meta/recipes-connectivity/bluez/bluez-hcidump-2.5/obsolete_automake_macros.patch
delete mode 100644 meta/recipes-connectivity/bluez/bluez-hcidump_2.5.bb
delete mode 100644 meta/recipes-connectivity/bluez/bluez4-4.101/bluetooth.conf
delete mode 100644
meta/recipes-connectivity/bluez/bluez4-4.101/fix-udev-paths.patch
delete mode 100644
meta/recipes-connectivity/bluez/bluez4-4.101/install-test-script.patch
delete mode 100644
meta/recipes-connectivity/bluez/bluez4-4.101/network-fix-network-Connect-method-parameters.patch
delete mode 100644
meta/recipes-connectivity/bluez/bluez4-4.101/obsolete_automake_macros.patch
delete mode 100644 meta/recipes-connectivity/bluez/bluez4-4.101/sbc_mmx.patch
delete mode 100644
meta/recipes-connectivity/bluez/bluez4-4.101/use-legacy-pygobject-instead-ofgobject-introspection.patch
delete mode 100644 meta/recipes-connectivity/bluez/bluez4.inc
delete mode 100644 meta/recipes-connectivity/bluez/bluez4_4.101.bb
delete mode 100644
meta/recipes-connectivity/bluez/gst-plugin-bluetooth_4.101.bb
diff --git
a/meta/recipes-connectivity/bluez/bluez-hcidump-2.5/obsolete_automake_macros.patch
b/meta/recipes-connectivity/bluez/bluez-hcidump-2.5/obsolete_automake_macros.patch
deleted file mode 100644
index 0c77f1a..000
---
a/meta/recipes-connectivity/bluez/bluez-hcidump-2.5/obsolete_automake_macros.patch
+++ /dev/null
@@ -1,14 +0,0 @@
-Upstream-Status: Pending [package obsolete/not maintained by upstream]
-
-Signed-off-by: Marko Lindqvist cazf...@gmail.com
-diff -Nurd bluez-hcidump-2.5/configure.ac bluez-hcidump-2.5/configure.ac
bluez-hcidump-2.5/configure.ac 2012-11-30 10:29:41.0 +0200
-+++ bluez-hcidump-2.5/configure.ac 2013-01-12 10:02:10.609511463 +0200
-@@ -2,7 +2,7 @@
- AC_INIT(bluez-hcidump, 2.5)
-
- AM_INIT_AUTOMAKE([foreign subdir-objects])
--AM_CONFIG_HEADER(config.h)
-+AC_CONFIG_HEADERS(config.h)
-
- m4_ifdef([AM_SILENT_RULES], [AM_SILENT_RULES([yes])])
diff --git a/meta/recipes-connectivity/bluez/bluez-hcidump_2.5.bb
b/meta/recipes-connectivity/bluez/bluez-hcidump_2.5.bb
deleted file mode 100644
index 3950630..000
--- a/meta/recipes-connectivity/bluez/bluez-hcidump_2.5.bb
+++ /dev/null
@@ -1,22 +0,0 @@
-SUMMARY = Linux Bluetooth Stack HCI Debugger Tool
-DESCRIPTION = The hcidump tool reads raw HCI data coming from and going to a
Bluetooth device \
-and displays the commands, events and data in a human-readable form.
-
-SECTION = console
-# hcidump was integrated into bluez5
-DEPENDS = bluez4
-RCONFLICTS_${PN} = bluez5
-LICENSE = GPLv2+
-LIC_FILES_CHKSUM = file://COPYING;md5=eb723b61539feef013de476e68b5c50a \
-
file://src/hcidump.c;beginline=1;endline=23;md5=3bee3a162dff43a5be7470710b99fbcf
-PR = r1
-
-SRC_URI =
http://www.kernel.org/pub/linux/bluetooth/bluez-hcidump-${PV}.tar.gz \
- file://obsolete_automake_macros.patch \
-
-
-SRC_URI[md5sum] = 2eab54bbd2b59a2ed4274ebb9390cf18
-SRC_URI[sha256sum] =
9b7c52b375081883738cf049ecabc103b97d094b19c6544fb241267905d1
-S = ${WORKDIR}/bluez-hcidump-${PV}
-
-inherit autotools
diff --git a/meta/recipes-connectivity/bluez/bluez4-4.101/bluetooth.conf
b/meta/recipes-connectivity/bluez/bluez4-4.101/bluetooth.conf
deleted file mode 100644
index ca5e9e4..000
--- a/meta/recipes-connectivity/bluez/bluez4-4.101/bluetooth.conf
+++ /dev/null
@@ -1,16 +0,0 @@
-!-- This configuration file specifies the required security policies
- for Bluetooth core daemon to work. --
-
-!DOCTYPE busconfig PUBLIC -//freedesktop//DTD D-BUS Bus Configuration
1.0//EN
- http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd;
-busconfig
-
- !-- ../system.conf have denied everything, so we just punch some holes --
-
- policy context=default
-allow own=org.bluez/
-allow send_destination=org.bluez/
-
[OE-core] [PATCH 0/5] Switch to BlueZ 5.x as default Bluetooth stack
BlueZ 5.x is now the default Bluetooth stack.
BlueZ 4.x is moved to meta-oe networking collection
and still supported in oe-core.
The following changes since commit d6d2dd5c9e06c54ff336b44d54f01b4fe24903ed:
tools: A real fix for thos mega-manual.sed file for Toaster. (2015-04-02
20:30:46 +0100)
are available in the git repository at:
git://git.yoctoproject.org/poky-contrib ciorga/YB7479_refinement
http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=ciorga/YB7479_refinement
Cristian Iorga (5):
bluez5: upgrade to 5.29
bluez: remove recipes collection
maintainers.inc: remove info related to bluez4
upstream_tracking.inc: bluez4 removed from oe-core
bluetooth.bbclass: set bluez5 as the default BT stack
meta-yocto/conf/distro/include/maintainers.inc | 3 --
.../conf/distro/include/upstream_tracking.inc | 1 -
meta/classes/bluetooth.bbclass | 16 +---
.../obsolete_automake_macros.patch | 14 ---
.../bluez/bluez-hcidump_2.5.bb | 22 ---
.../bluez/bluez4-4.101/bluetooth.conf | 16
.../bluez/bluez4-4.101/fix-udev-paths.patch| 37 -
.../bluez/bluez4-4.101/install-test-script.patch | 26
...ork-fix-network-Connect-method-parameters.patch | 30 --
.../bluez4-4.101/obsolete_automake_macros.patch| 14 ---
.../bluez/bluez4-4.101/sbc_mmx.patch | 24 ---
...pygobject-instead-ofgobject-introspection.patch | 27 -
meta/recipes-connectivity/bluez/bluez4.inc | 46 --
meta/recipes-connectivity/bluez/bluez4_4.101.bb| 46 --
.../bluez/gst-plugin-bluetooth_4.101.bb| 39 --
.../bluez5/{bluez5_5.28.bb = bluez5_5.29.bb} | 4 +-
16 files changed, 13 insertions(+), 352 deletions(-)
delete mode 100644
meta/recipes-connectivity/bluez/bluez-hcidump-2.5/obsolete_automake_macros.patch
delete mode 100644 meta/recipes-connectivity/bluez/bluez-hcidump_2.5.bb
delete mode 100644 meta/recipes-connectivity/bluez/bluez4-4.101/bluetooth.conf
delete mode 100644
meta/recipes-connectivity/bluez/bluez4-4.101/fix-udev-paths.patch
delete mode 100644
meta/recipes-connectivity/bluez/bluez4-4.101/install-test-script.patch
delete mode 100644
meta/recipes-connectivity/bluez/bluez4-4.101/network-fix-network-Connect-method-parameters.patch
delete mode 100644
meta/recipes-connectivity/bluez/bluez4-4.101/obsolete_automake_macros.patch
delete mode 100644 meta/recipes-connectivity/bluez/bluez4-4.101/sbc_mmx.patch
delete mode 100644
meta/recipes-connectivity/bluez/bluez4-4.101/use-legacy-pygobject-instead-ofgobject-introspection.patch
delete mode 100644 meta/recipes-connectivity/bluez/bluez4.inc
delete mode 100644 meta/recipes-connectivity/bluez/bluez4_4.101.bb
delete mode 100644
meta/recipes-connectivity/bluez/gst-plugin-bluetooth_4.101.bb
rename meta/recipes-connectivity/bluez5/{bluez5_5.28.bb = bluez5_5.29.bb}
(88%)
--
2.1.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/5] bluez5: upgrade to 5.29
- Large release with over a month and 475 commits since 5.28;
- Internal GATT library received lots of updates;
- Fix for AVCTP key repeat timeout;
- Added support for the Multi Profile Specification (MPS).
Signed-off-by: Cristian Iorga cristian.io...@intel.com
---
meta/recipes-connectivity/bluez5/{bluez5_5.28.bb = bluez5_5.29.bb} | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
rename meta/recipes-connectivity/bluez5/{bluez5_5.28.bb = bluez5_5.29.bb}
(88%)
diff --git a/meta/recipes-connectivity/bluez5/bluez5_5.28.bb
b/meta/recipes-connectivity/bluez5/bluez5_5.29.bb
similarity index 88%
rename from meta/recipes-connectivity/bluez5/bluez5_5.28.bb
rename to meta/recipes-connectivity/bluez5/bluez5_5.29.bb
index e816998..0fe8e7f 100644
--- a/meta/recipes-connectivity/bluez5/bluez5_5.28.bb
+++ b/meta/recipes-connectivity/bluez5/bluez5_5.29.bb
@@ -1,6 +1,6 @@
require bluez5.inc
-SRC_URI[md5sum] = bc20a8285530758c68f6a60e4ca62a15
-SRC_URI[sha256sum] =
85bab48f4b47a158739028682c1e09cf30099c8ea9dfe63360055f8e06fc18a9
+SRC_URI[md5sum] = aa9dc91689695a486c78c131cd68673e
+SRC_URI[sha256sum] =
df216a6d5ec6133355e5d4ed6b5e7a188a940940d337374e166758513246f0e4
# noinst programs in Makefile.tools that are conditional on READLINE
# support
--
2.1.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 4/5] upstream_tracking.inc: bluez4 removed from oe-core
info updated accordingly. Signed-off-by: Cristian Iorga cristian.io...@intel.com --- meta-yocto/conf/distro/include/upstream_tracking.inc | 1 - 1 file changed, 1 deletion(-) diff --git a/meta-yocto/conf/distro/include/upstream_tracking.inc b/meta-yocto/conf/distro/include/upstream_tracking.inc index 15f6a18..2c6a074 100644 --- a/meta-yocto/conf/distro/include/upstream_tracking.inc +++ b/meta-yocto/conf/distro/include/upstream_tracking.inc @@ -50,7 +50,6 @@ RECIPE_UPSTREAM_DATE_pn-pseudo = Jan 23, 2015 CHECK_DATE_pseudo = Feb 12, 2015 # NO UPDATE REASONS -RECIPE_NO_UPDATE_REASON_pn-bluez4 = BlueZ 5.x is not backward-compatible; components that interact with bluez not updated RECIPE_NO_UPDATE_REASON_pn-build-appliance = Always reports behind RECIPE_NO_UPDATE_REASON_pn-cdrtools = v3.x uses incompatible CDDL license RECIPE_NO_UPDATE_REASON_pn-createrepo = Versions after 0.9.* use YUM, so we hold at 0.4.11 -- 2.1.0 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 3/5] maintainers.inc: remove info related to bluez4
bluez4, bluez-hcidump, gst-plugin-bluetooth recipes will be removed from oe-core, maintainers removed. Signed-off-by: Cristian Iorga cristian.io...@intel.com --- meta-yocto/conf/distro/include/maintainers.inc | 3 --- 1 file changed, 3 deletions(-) diff --git a/meta-yocto/conf/distro/include/maintainers.inc b/meta-yocto/conf/distro/include/maintainers.inc index c4e281e..e1b2f0d 100644 --- a/meta-yocto/conf/distro/include/maintainers.inc +++ b/meta-yocto/conf/distro/include/maintainers.inc @@ -64,9 +64,7 @@ RECIPE_MAINTAINER_pn-binutils = Robert Yang liezhi.y...@windriver.com RECIPE_MAINTAINER_pn-bison = Chong Lu chong...@windriver.com RECIPE_MAINTAINER_pn-blktool = Paul Eggleton paul.eggle...@linux.intel.com RECIPE_MAINTAINER_pn-blktrace = Tom Zanussi tom.zanu...@intel.com -RECIPE_MAINTAINER_pn-bluez4 = Cristian Iorga cristian.io...@intel.com RECIPE_MAINTAINER_pn-bluez5 = Cristian Iorga cristian.io...@intel.com -RECIPE_MAINTAINER_pn-bluez-hcidump = Cristian Iorga cristian.io...@intel.com RECIPE_MAINTAINER_pn-boost = Saul Wold s...@linux.intel.com RECIPE_MAINTAINER_pn-btrfs-tools = Richard Purdie richard.pur...@linuxfoundation.org RECIPE_MAINTAINER_pn-build-appliance-image = Saul Wold s...@linux.intel.com @@ -216,7 +214,6 @@ RECIPE_MAINTAINER_pn-gst-fluendo-mp3 = Cristian Iorga cristian.io...@intel.com RECIPE_MAINTAINER_pn-gst-fluendo-mpegdemux = Cristian Iorga cristian.io...@intel.com RECIPE_MAINTAINER_pn-gst-meta-base = Cristian Iorga cristian.io...@intel.com RECIPE_MAINTAINER_pn-gst-openmax = Cristian Iorga cristian.io...@intel.com -RECIPE_MAINTAINER_pn-gst-plugin-bluetooth = Cristian Iorga cristian.io...@intel.com RECIPE_MAINTAINER_pn-gst-plugins-bad = Cristian Iorga cristian.io...@intel.com RECIPE_MAINTAINER_pn-gst-plugins-base = Cristian Iorga cristian.io...@intel.com RECIPE_MAINTAINER_pn-gst-plugins-good = Cristian Iorga cristian.io...@intel.com -- 2.1.0 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] combo-layer issue
Morning all,
I am trying to replicate how Poky is created using combo-layer. I have
referenced https://wiki.yoctoproject.org/wiki/Combo-layer
The issue seems to be related when I define branch. Not defining it
works fine (ie, master default). I suspect I am doing something
incorrectly or a compatibility issue with my local git version 1.9.1.
can someone poke to go in the right direction.
kind regards,
Armin
combo-layer.conf:
[bitbake]
src_uri = git://git.openembedded.org/bitbake
local_repo_dir = /tmp/src/test/bitbake
dest_dir = bitbake
branch = 1.26
last_revision =
[oe-core]
src_uri = git://git.openembedded.org/openembedded-core
local_repo_dir = /tmp/src/test/oecore
dest_dir = .
branch = fido
last_revision =
Error message:
[07:22:26] fatal: ambiguous argument 'fido': unknown revision or path
not in the working tree.
Use '--' to separate paths from revisions, like this:
'git command [revision...] -- [file...]'
fido
Traceback (most recent call last):
File ./scripts/combo-layer, line 869, in module
ret = main()
File ./scripts/combo-layer, line 865, in main
actions.get(args[1], action_error)(confdata, args[1:])
File ./scripts/combo-layer, line 220, in action_init
rev = runcmd('git rev-parse %s' % initialrev, ldir).strip()
File ./scripts/combo-layer, line 179, in runcmd
raise e
CalledProcessError: Command 'git rev-parse fido' returned non-zero exit
status 128
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] valgrind: Add INSANE_SKIP of arch for valgrind and valgrind-dbg
With a multilib configuration, these things should be packaged per-multilib and
then only the installed multilib components are available on the device. It
saves space and preserves the checking in place to catch situations where you
may accidentally provide software that isn't runnable.
The other problem with permitting the system to query the compiler is the
output
of the build is no longer deterministic. If the toolchain configuration
changes, then the output of valgrind changes. That should not happen.
Ok, got it.
Then disabling the generation of other set of binaries via configure options is
needed here, i.e install only 32-bit and 64-bit binaries when 32-bit
and 64-bit valgrind applications are built respectively.
Thanks,
Jagadeesh
From: openembedded-core-boun...@lists.openembedded.org
openembedded-core-boun...@lists.openembedded.org on behalf of Mark Hatle
mark.ha...@windriver.com
Sent: Friday, April 3, 2015 8:42 PM
To: openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [PATCH] valgrind: Add INSANE_SKIP of arch for valgrind
and valgrind-dbg
On 4/3/15 9:57 AM, Krishnanjanappa, Jagadeesh wrote:
what is the point of packaging files for which there won’t be any runtime
environment. You are just better of removing them.
IMO unless you have multilib environment working
this patch is just relaxing the QA
With compilers supporting generation of multilib and yocto framework
supporting generation of multilib rootfs, one can have this environment
often. Instead of removing them, as said we can disable them from generation
using configure options. Also the valgrind rpm package do include this files
in its package.
Link:
http://www.rpmfind.net//linux/RPM/opensuse/13.2/x86_64/valgrind-3.10.0-1.1.x86_64.html
With a multilib configuration, these things should be packaged per-multilib and
then only the installed multilib components are available on the device. It
saves space and preserves the checking in place to catch situations where you
may accidentally provide software that isn't runnable.
The other problem with permitting the system to query the compiler is the output
of the build is no longer deterministic. If the toolchain configuration
changes, then the output of valgrind changes. That should not happen.
--Mark
Regards,
Jagadeesh
From: Khem Raj raj.k...@gmail.com
Sent: Friday, April 3, 2015 8:28 AM
To: Krishnanjanappa, Jagadeesh
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [PATCH] valgrind: Add INSANE_SKIP of arch for valgrind
and valgrind-dbg
On Apr 2, 2015, at 11:47 AM, Krishnanjanappa, Jagadeesh
jagadeesh.krishnanjana...@caviumnetworks.com wrote:
From: Krishnanjanappa, Jagadeesh
jagadeesh.krishnanjana...@caviumnetworks.com
If a complier supports generating 32-bit and 64-bit binaries, then
while building valgrind we have two sets of binaries (32-bit and 64-bit)
being generated.
Example: With compiler supporting generation of both 32-bit and 64-bit
binaries, and building valgrind in 64-bit mode, we come across following
QA Issue (listing only few of them),
(snip)
ERROR: QA Issue: Architecture did not match (62 to 3) on
${WORKDIR}/valgrind/3.10.1-r0/packages-split/valgrind-dbg/usr/lib64/valgrind/.debug/vgpreload_exp-sgcheck-x86-linux.so
ERROR: QA Issue: Architecture did not match (62 to 3) on
${WORKDIR}/valgrind/3.10.1-r0/packages-split/valgrind-dbg/usr/lib64/valgrind/.debug/getoff-x86-linux
ERROR: QA Issue: Architecture did not match (62 to 3) on
${WORKDIR}/valgrind/3.10.1-r0/packages-split/valgrind-dbg/usr/lib64/valgrind/.debug/vgpreload_core-x86-linux.so
ERROR: QA Issue: Architecture did not match (62 to 3) on
${WORKDIR}/valgrind/3.10.1-r0/packages-split/valgrind-dbg/usr/lib64/valgrind/.debug/vgpreload_memcheck-x86-linux.so
-- CUT --
However, we can build only 64-bit or 32-bit binaries in valgrind using
--enable-only64bit and --enable-only32bit configure options respectively.
And the required configure option can be selected based on SITEINFO_BITS, but
feel that if a compiler supports generation of both type of binaries and it
may be useful for users to have/execute both type of binaries on multilib
environment. So choosing to pack both types of binaries and skip errors if
the
architecture type are different using INSANE_SKIP.
what is the point of packaging files for which there won’t be any runtime
environment. You are just better of removing them.
IMO unless you have multilib environment working
this patch is just relaxing the QA
Signed-off-by: Krishnanjanappa, Jagadeesh
jagadeesh.krishnanjana...@caviumnetworks.com
---
meta/recipes-devtools/valgrind/valgrind_3.10.1.bb | 9 +
1 file changed, 9 insertions(+)
diff --git a/meta/recipes-devtools/valgrind/valgrind_3.10.1.bb
b/meta/recipes-devtools/valgrind/valgrind_3.10.1.bb
index bf80b16..eaa64c4 100644
---
