[OE-core] [PATCH 2/3] runqemu: Explicitly specify MACHINE when calling bitbake
When using runqemu with distros outside oe-core then
MACHINE may not be there in local.conf so use the one
thats available in environment of runqemu which is actually
the correct one.
Signed-off-by: Khem Raj raj.k...@gmail.com
---
scripts/runqemu |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/runqemu b/scripts/runqemu
index a3c3509..e843946 100755
--- a/scripts/runqemu
+++ b/scripts/runqemu
@@ -281,7 +281,7 @@ setup_tmpdir() {
exit 1; }
# We have bitbake in PATH, get OE_TMPDIR from bitbake
-OE_TMPDIR=`bitbake -e | grep ^TMPDIR=\ | cut -d '=' -f2 | cut -d ''
-f2`
+OE_TMPDIR=`MACHINE=$MACHINE bitbake -e | grep ^TMPDIR=\ | cut -d '='
-f2 | cut -d '' -f2`
if [ -z $OE_TMPDIR ]; then
echo Error: this script needs to be run from your build
directory,
echo or you need to explicitly set OE_TMPDIR in your environment
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH V2 1/3] kernel.bbclass, module-base.bbclass: Use CC to form KERNEL_CC
kernel compiler is not special and we currently have it so
we want to pass -march and -mtune options as CFLAGS to kernel
build so that compiler picks the right subarch flags when
compiling assembly files in particular. Otherwise defaults
are chosen which may not be right in many case e.g. when
compiling kernel for collie machine we should use arch=armv4
but it uses toolchain/as defaults which is armv5te
in some case e.g. thumb1 we know that kernel can not be compiled
in thumb1 mode so we can provide that information e.g. -marm
option through KERNEL_HOST_CC_ARCH variable as we do now
Signed-off-by: Khem Raj raj.k...@gmail.com
---
meta/classes/kernel-arch.bbclass | 13 +
meta/classes/kernel.bbclass | 16 +---
meta/classes/module-base.bbclass | 16
3 files changed, 14 insertions(+), 31 deletions(-)
diff --git a/meta/classes/kernel-arch.bbclass b/meta/classes/kernel-arch.bbclass
index 6446504..95a40f2 100644
--- a/meta/classes/kernel-arch.bbclass
+++ b/meta/classes/kernel-arch.bbclass
@@ -42,3 +42,16 @@ def map_uboot_arch(a, d):
export UBOOT_ARCH = ${@map_uboot_arch(d.getVar('ARCH', True), d)}
+# Set TARGET_??_KERNEL_ARCH in the machine .conf to set architecture
+# specific options necessary for building the kernel and modules.
+TARGET_CC_KERNEL_ARCH ?=
+HOST_CC_KERNEL_ARCH ?= ${TARGET_CC_KERNEL_ARCH}
+TARGET_LD_KERNEL_ARCH ?=
+HOST_LD_KERNEL_ARCH ?= ${TARGET_LD_KERNEL_ARCH}
+TARGET_AR_KERNEL_ARCH ?=
+HOST_AR_KERNEL_ARCH ?= ${TARGET_AR_KERNEL_ARCH}
+
+KERNEL_CC = ${CC} ${HOST_CC_KERNEL_ARCH}
+KERNEL_LD = ${LD} ${HOST_LD_KERNEL_ARCH}
+KERNEL_AR = ${AR} ${HOST_AR_KERNEL_ARCH}
+
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index fdef1be..bcb6bd5 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -1,7 +1,7 @@
inherit linux-kernel-base module_strip
PROVIDES += virtual/kernel
-DEPENDS += virtual/${TARGET_PREFIX}gcc kmod-native
virtual/${TARGET_PREFIX}gcc${KERNEL_CCSUFFIX} update-modules
+DEPENDS += virtual/${TARGET_PREFIX}gcc kmod-native update-modules
# we include gcc above, we dont need virtual/libc
INHIBIT_DEFAULT_DEPS = 1
@@ -37,20 +37,6 @@ KERNEL_PRIORITY ?=
${@int(d.getVar('PV',1).split('-')[0].split('+')[0].split('.
KERNEL_RELEASE ?= ${KERNEL_VERSION}
-KERNEL_CCSUFFIX ?=
-KERNEL_LDSUFFIX ?=
-
-# Set TARGET_??_KERNEL_ARCH in the machine .conf to set architecture
-# specific options necessary for building the kernel and modules.
-#FIXME: should be this: TARGET_CC_KERNEL_ARCH ?= ${TARGET_CC_ARCH}
-TARGET_CC_KERNEL_ARCH ?=
-HOST_CC_KERNEL_ARCH ?= ${TARGET_CC_KERNEL_ARCH}
-TARGET_LD_KERNEL_ARCH ?=
-HOST_LD_KERNEL_ARCH ?= ${TARGET_LD_KERNEL_ARCH}
-
-KERNEL_CC = ${CCACHE}${HOST_PREFIX}gcc${KERNEL_CCSUFFIX}
${HOST_CC_KERNEL_ARCH}${TOOLCHAIN_OPTIONS}
-KERNEL_LD = ${HOST_PREFIX}ld${KERNEL_LDSUFFIX}
${HOST_LD_KERNEL_ARCH}${TOOLCHAIN_OPTIONS}
-
# Where built kernel lies in the kernel tree
KERNEL_OUTPUT ?= arch/${ARCH}/boot/${KERNEL_IMAGETYPE}
KERNEL_IMAGEDEST = boot
diff --git a/meta/classes/module-base.bbclass b/meta/classes/module-base.bbclass
index 9379bf8..f4ec2d4 100644
--- a/meta/classes/module-base.bbclass
+++ b/meta/classes/module-base.bbclass
@@ -7,22 +7,6 @@ export CROSS_COMPILE = ${TARGET_PREFIX}
export KERNEL_VERSION =
${@base_read_file('${STAGING_KERNEL_DIR}/kernel-abiversion')}
KERNEL_OBJECT_SUFFIX = .ko
-KERNEL_CCSUFFIX = ${@base_read_file('${STAGING_KERNEL_DIR}/kernel-ccsuffix')}
-KERNEL_LDSUFFIX = ${@base_read_file('${STAGING_KERNEL_DIR}/kernel-ldsuffix')}
-KERNEL_ARSUFFIX = ${@base_read_file('${STAGING_KERNEL_DIR}/kernel-arsuffix')}
-
-# Set TARGET_??_KERNEL_ARCH in the machine .conf to set architecture
-# specific options necessary for building the kernel and modules.
-TARGET_CC_KERNEL_ARCH ?=
-HOST_CC_KERNEL_ARCH ?= ${TARGET_CC_KERNEL_ARCH}
-TARGET_LD_KERNEL_ARCH ?=
-HOST_LD_KERNEL_ARCH ?= ${TARGET_LD_KERNEL_ARCH}
-TARGET_AR_KERNEL_ARCH ?=
-HOST_AR_KERNEL_ARCH ?= ${TARGET_AR_KERNEL_ARCH}
-
-KERNEL_CC = ${CCACHE}${HOST_PREFIX}gcc${KERNEL_CCSUFFIX}
${HOST_CC_KERNEL_ARCH}
-KERNEL_LD = ${HOST_PREFIX}ld${KERNEL_LDSUFFIX} ${HOST_LD_KERNEL_ARCH}
-KERNEL_AR = ${HOST_PREFIX}ar${KERNEL_ARSUFFIX} ${HOST_AR_KERNEL_ARCH}
# kernel modules are generally machine specific
PACKAGE_ARCH = ${MACHINE_ARCH}
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 3/3] uclibc: Revert systemd regressing patch from upsteam uclibc
This patch is causing systemd based systemd to not boot
Signed-off-by: Khem Raj raj.k...@gmail.com
---
meta/recipes-core/uclibc/uclibc-git.inc|5 +-
...nt.c-wtent.c-move-functions-from-utxent.c.patch | 321
2 files changed, 324 insertions(+), 2 deletions(-)
create mode 100644
meta/recipes-core/uclibc/uclibc-git/0001-Revert-utent.c-wtent.c-move-functions-from-utxent.c.patch
diff --git a/meta/recipes-core/uclibc/uclibc-git.inc
b/meta/recipes-core/uclibc/uclibc-git.inc
index eec4ded..4da9c58 100644
--- a/meta/recipes-core/uclibc/uclibc-git.inc
+++ b/meta/recipes-core/uclibc/uclibc-git.inc
@@ -1,9 +1,9 @@
-SRCREV=555ae2e88cd16a83f854634b6c3f35715b11d3d4
+SRCREV=cb43f2afba0633400387fa7c55dda3396517f58a
DEFAULT_PREFERENCE = -1
PV = 0.9.33+git${SRCPV}
-PR = ${INC_PR}.3
+PR = ${INC_PR}.4
FILESPATH = ${@base_set_filespath([ '${FILE_DIRNAME}/uclibc-git' ], d)}
@@ -26,5 +26,6 @@ SRC_URI =
git://uclibc.org/uClibc.git;branch=master;protocol=git \
file://0001-nptl-atfork-Hide-pthread_atfork-in-shared-versions.patch \
file://0001-librt-Use-nodefaultlibs-instead-of-nostdlib.patch \
file://mount.h-update.patch \
+ file://0001-Revert-utent.c-wtent.c-move-functions-from-utxent.c.patch \
S = ${WORKDIR}/git
diff --git
a/meta/recipes-core/uclibc/uclibc-git/0001-Revert-utent.c-wtent.c-move-functions-from-utxent.c.patch
b/meta/recipes-core/uclibc/uclibc-git/0001-Revert-utent.c-wtent.c-move-functions-from-utxent.c.patch
new file mode 100644
index 000..8c202ac
--- /dev/null
+++
b/meta/recipes-core/uclibc/uclibc-git/0001-Revert-utent.c-wtent.c-move-functions-from-utxent.c.patch
@@ -0,0 +1,321 @@
+Upstream-Status: Pending
+
+From 096abf14d2dc978607ccd8a0d7f42da65d8991f3 Mon Sep 17 00:00:00 2001
+From: Khem Raj raj.k...@gmail.com
+Date: Sun, 9 Sep 2012 22:00:04 -0700
+Subject: [PATCH] Revert utent.c, wtent.c: move functions from utxent.c
+
+This reverts commit 84135275cfeebc0b233c1c96eeada4d4178a0b18.
+---
+ include/utmp.h |8 +
+ libc/misc/utmp/utent.c | 80 +++
+ libc/misc/utmp/utxent.c |4 +--
+ libc/misc/utmp/wtent.c | 14 ++---
+ 4 files changed, 30 insertions(+), 76 deletions(-)
+
+diff --git a/include/utmp.h b/include/utmp.h
+index cb8e08f..10b75c9 100644
+--- a/include/utmp.h
b/include/utmp.h
+@@ -57,29 +57,37 @@ extern void logwtmp (__const char *__ut_line, __const char
*__ut_name,
+ /* Append entry UTMP to the wtmp-like file WTMP_FILE. */
+ extern void updwtmp (__const char *__wtmp_file, __const struct utmp *__utmp)
+ __THROW;
++libc_hidden_proto(updwtmp)
+
+ /* Change name of the utmp file to be examined. */
+ extern int utmpname (__const char *__file) __THROW;
++libc_hidden_proto(utmpname)
+
+ /* Read next entry from a utmp-like file. */
+ extern struct utmp *getutent (void) __THROW;
++libc_hidden_proto(getutent)
+
+ /* Reset the input stream to the beginning of the file. */
+ extern void setutent (void) __THROW;
++libc_hidden_proto(setutent)
+
+ /* Close the current open file. */
+ extern void endutent (void) __THROW;
++libc_hidden_proto(endutent)
+
+ /* Search forward from the current point in the utmp file until the
+next entry with a ut_type matching ID-ut_type. */
+ extern struct utmp *getutid (__const struct utmp *__id) __THROW;
++libc_hidden_proto(getutid)
+
+ /* Search forward from the current point in the utmp file until the
+next entry with a ut_line matching LINE-ut_line. */
+ extern struct utmp *getutline (__const struct utmp *__line) __THROW;
++libc_hidden_proto(getutline)
+
+ /* Write out entry pointed to by UTMP_PTR into the utmp file. */
+ extern struct utmp *pututline (__const struct utmp *__utmp_ptr) __THROW;
++libc_hidden_proto(pututline)
+
+
+ #if 0 /* def __USE_MISC */
+diff --git a/libc/misc/utmp/utent.c b/libc/misc/utmp/utent.c
+index a35bb2b..07ca44e 100644
+--- a/libc/misc/utmp/utent.c
b/libc/misc/utmp/utent.c
+@@ -19,9 +19,6 @@
+ #include errno.h
+ #include string.h
+ #include utmp.h
+-#ifdef __UCLIBC_HAS_UTMPX__
+-# include utmpx.h
+-#endif
+ #include not-cancel.h
+
+ #include bits/uClibc_mutex.h
+@@ -34,7 +31,7 @@ static const char default_file_name[] = _PATH_UTMP;
+ static const char *static_ut_name = default_file_name;
+
+ /* This function must be called with the LOCK held */
+-static void __setutent_unlocked(void)
++static void __setutent(void)
+ {
+ if (static_fd 0) {
+ static_fd = open_not_cancel_2(static_ut_name, O_RDWR | O_CLOEXEC);
+@@ -53,24 +50,19 @@ static void __setutent_unlocked(void)
+ lseek(static_fd, 0, SEEK_SET);
+ }
+ #if defined __UCLIBC_HAS_THREADS__
+-static void __setutent(void)
++void setutent(void)
+ {
+ __UCLIBC_MUTEX_LOCK(utmplock);
+-__setutent_unlocked();
++__setutent();
+ __UCLIBC_MUTEX_UNLOCK(utmplock);
+ }
+ #else
+-static void __setutent(void);
+-strong_alias(__setutent_unlocked,__setutent)
+-#endif
+
Re: [OE-core] [PATCH V2 1/3] kernel.bbclass, module-base.bbclass: Use CC to form KERNEL_CC
On Tue, 2012-09-11 at 22:59 -0700, Khem Raj wrote:
kernel compiler is not special and we currently have it so
we want to pass -march and -mtune options as CFLAGS to kernel
build so that compiler picks the right subarch flags when
compiling assembly files in particular.
Historically, the kernel compiler has indeed been special: there have
been some machines where, due to bugs in the kernel or the compiler or
both, we need to use a different version of the compiler for the kernel
than we use for userspace. The most famous example of this were the old
ARM kernels back in the day which needed gcc-2.95 long after everyone
else had stopped using it, but I think there might be a few cases where
the same situation obtains even today.
If you remove ${KERNEL_CCSUFFIX} then we will lose the ability to do
that (easily). I'm not necessarily opposed to such a change but I think
it does need to be justified with clear benefits.
p.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/3] uclibc: Revert systemd regressing patch from upsteam uclibc
On Tue, 2012-09-11 at 22:59 -0700, Khem Raj wrote: This patch is causing systemd based systemd to not boot Signed-off-by: Khem Raj raj.k...@gmail.com --- meta/recipes-core/uclibc/uclibc-git.inc|5 +- ...nt.c-wtent.c-move-functions-from-utxent.c.patch | 321 2 files changed, 324 insertions(+), 2 deletions(-) create mode 100644 meta/recipes-core/uclibc/uclibc-git/0001-Revert-utent.c-wtent.c-move-functions-from-utxent.c.patch diff --git a/meta/recipes-core/uclibc/uclibc-git.inc b/meta/recipes-core/uclibc/uclibc-git.inc index eec4ded..4da9c58 100644 --- a/meta/recipes-core/uclibc/uclibc-git.inc +++ b/meta/recipes-core/uclibc/uclibc-git.inc @@ -1,9 +1,9 @@ -SRCREV=555ae2e88cd16a83f854634b6c3f35715b11d3d4 +SRCREV=cb43f2afba0633400387fa7c55dda3396517f58a Why are you changing SRCREV as well? p. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] eglibc: Restore ${PN} to before ${PN}-dev in PACKAGES
On 09/11/2012 11:36 PM, Phil Blundell wrote:
On Tue, 2012-09-11 at 11:19 -0700, Saul Wold wrote:
On 09/11/2012 11:14 AM, Phil Blundell wrote:
Commit 13544fbc6217fee1731a6da1e2cf94901a500842 changed the ordering
of PACKAGES so that ${PN}-dev came before ${PN}. However, this caused
the FILES matching to go wrong if ${libdir} == ${base_libdir}. Fix this
by moving ${PN} ahead of ${PN}-dev once again.
Signed-off-by: Phil Blundell p...@pbcl.net
---
V2: now with high-tech PR goodness
Did you do a build with BUILD_HISTORY enabled and verified nothing
changes in the standard case?
Yes, see attached.
Sorry, there is way too much in that diff, have you reviewed what
actually changed?
In the FILES and FILESLIST?
Sau!
p.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] eglibc: Restore ${PN} to before ${PN}-dev in PACKAGES
On Wed, 2012-09-12 at 00:07 -0700, Saul Wold wrote:
On 09/11/2012 11:36 PM, Phil Blundell wrote:
On Tue, 2012-09-11 at 11:19 -0700, Saul Wold wrote:
On 09/11/2012 11:14 AM, Phil Blundell wrote:
Commit 13544fbc6217fee1731a6da1e2cf94901a500842 changed the ordering
of PACKAGES so that ${PN}-dev came before ${PN}. However, this caused
the FILES matching to go wrong if ${libdir} == ${base_libdir}. Fix this
by moving ${PN} ahead of ${PN}-dev once again.
Signed-off-by: Phil Blundell p...@pbcl.net
---
V2: now with high-tech PR goodness
Did you do a build with BUILD_HISTORY enabled and verified nothing
changes in the standard case?
Yes, see attached.
Sorry, there is way too much in that diff, have you reviewed what
actually changed?
In the FILES and FILESLIST?
Yes. There are no changes to FILES, and no relevant changes to the
FILELISTs.
p.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [CONSOLIDATED REQUEST v2 00/35] Misc Fixes (CV Only)
Richard,
This contains various fixes from teh community along with a few
updates. The Kernel update seems to have trigged a mpc8315 failure, but
I am sure Bruce will deal with it quickly.
This also include Bruce and my change that now allows us to elimate the
x32 layer and by setting the DEFAULTTUNE enable x32 build for any BSP.
Phil B. has confirmed his change with BUILD_HISTORY.
This is a good change set and should be merged.
There are a couple of meta-yocto changes that I need to pull
together also, but they are minor.
Thanks
Sau!
The following changes since commit 48169c6bc44c546cecaa06207b6c36da558b81f7:
classes/packageinfo: use better method to check if package exists (2012-09-10
21:52:37 +0100)
are available in the git repository at:
git://git.openembedded.org/openembedded-core-contrib sgw/stage
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=sgw/stage
Bruce Ashfield (3):
linux-yocto/3.4: v3.4.10 and uprobes/kprobes configuration updates
linux-yocto*: append to KERNEL_FEATURES
instead of assigning
linux-yocto/3.4: add x32 configuration fragment
Constantin Musca (4):
boost: upgrade to 1.51.0
glew: upgrade to 1.9.0
libexif: upgrade to 0.6.21
sysstat: upgrade to 10.1.1
Jackie Huang (1):
libgnome-keyring: add missing DEPENDS on intltool-native
Khem Raj (2):
gcc-4.7: Fix build for armv4/EABI and ppc/Os
gcc-4.7: Backport libgcc fixes to appease the new build sequence
Laurentiu Palcu (1):
nativesdk-qemu: fix SDK relocation issue
Mark Asselstine (1):
base-files: provide a mechanism to skip creation of the hostname file
Mark Hatle (3):
image.bbclass: Enable the complementary install to be called w/
globbing params
package_rpm.bbclass: Avoid unnecessary installs in complementary pass
qt4: Update qt4.inc to remove staticdev deps in -dbg packages
Martin Ertsaas (1):
gettext: Make gettext 0.16.1 extend native and nativesdk.
Matthew McClintock (1):
sysvinit-inittab_2.88dsf.bb: only run serial checks at boot if we
have items to check
Paul Eggleton (2):
classes/sanity: skip tune checks if machine is invalid
classes/sanity: remove obsolete code
Phil Blundell (4):
perl-native: PROVIDE libmodule-build-perl-native for consistency with
non-native perl
shadow: Fix various invalid assumptions about directory layout
shadow-native: Ensure that ${sbindir} and ${base_sbindir} are
respected
eglibc: Restore ${PN} to before ${PN}-dev in PACKAGES
Richard Purdie (2):
autotools.bbclass: Add functionality to force a clean of ${B} when
reconfiguring (and ${S} != ${B})
libgpg-error: Use the source file for the licence checksum
Ross Burton (2):
webkit-gtk: work around Make bug by re-running make
telepathy-idle: fix parallel build
Saul Wold (2):
quota: add inherit gettext
arch-ia32: Enable x32 KERNEL_FEATURE if tune is x32
Vladimir Zapolskiy (6):
classes/license: define LICENSE_MANIFEST variable
classes/license: check license manifest for double records
classes/license: remove redundant nested if statements
classes/license: account LICENSE_${pkg} values in manifest
classes/license: correct license info in lisense.manifest
classes/license: place all found licenses on one line
meta/classes/autotools.bbclass | 21 +
meta/classes/image.bbclass |4 +-
meta/classes/license.bbclass | 55 +++-
meta/classes/package_rpm.bbclass |9 ++-
meta/classes/sanity.bbclass| 19 ++--
meta/conf/machine/include/ia32/arch-ia32.inc |1 +
.../build-fix-for-make-j-safety.patch | 39
.../fix-svc-gtk-doc.h-target.patch | 24 +-
.../telepathy/telepathy-idle_0.1.12.bb |5 +-
meta/recipes-core/base-files/base-files_3.0.14.bb | 14 ++--
meta/recipes-core/eglibc/eglibc-package.inc|2 +-
meta/recipes-core/eglibc/eglibc_2.16.bb|2 +-
meta/recipes-core/gettext/gettext_0.16.1.bb|2 +
.../sysvinit/sysvinit-inittab_2.88dsf.bb | 10 ++-
meta/recipes-devtools/gcc/gcc-4.7.inc |6 +-
...-vis_hide-gen-hide-list-Do-not-make-defin.patch | 93
...USE_PT_GNU_EH_FRAME-Define-for-systems-us.patch | 49 ++
.../gcc-4.7/gcc-armv4-pass-fix-v4bx-to-ld.patch| 31 +++
.../gcc/gcc-4.7/ppc_no_crtsavres.patch | 72 +++
meta/recipes-devtools/perl/perl-native_5.14.2.bb |3 +
.../qemu/qemu-1.2.0/relocatable_sdk.patch | 34 +++
meta/recipes-devtools/qemu/qemu_1.2.0.bb |6 ++
meta/recipes-extended/quota/quota_4.00.bb |4 +-
.../shadow/shadow-native_4.1.4.3.bb| 11 ++-
meta/recipes-extended/shadow/shadow_4.1.4.3.bb | 17 +++-
meta/recipes-extended/sysstat/sysstat_10.0.5.bb|8 --
Re: [OE-core] [PATCH V2 1/3] kernel.bbclass, module-base.bbclass: Use CC to form KERNEL_CC
On Tue, Sep 11, 2012 at 11:32 PM, Phil Blundell ph...@gnu.org wrote:
On Tue, 2012-09-11 at 22:59 -0700, Khem Raj wrote:
kernel compiler is not special and we currently have it so
we want to pass -march and -mtune options as CFLAGS to kernel
build so that compiler picks the right subarch flags when
compiling assembly files in particular.
Historically, the kernel compiler has indeed been special: there have
been some machines where, due to bugs in the kernel or the compiler or
both, we need to use a different version of the compiler for the kernel
than we use for userspace. The most famous example of this were the old
ARM kernels back in the day which needed gcc-2.95 long after everyone
else had stopped using it, but I think there might be a few cases where
the same situation obtains even today.
I agree with history but we have moved away from 2.9x for long.
moreover v1 of this patch has been posted for weeks no one raised a
concern which I take that such cases are not there anymore with
OE-Core
If you remove ${KERNEL_CCSUFFIX} then we will lose the ability to do
that (easily). I'm not necessarily opposed to such a change but I think
it does need to be justified with clear benefits.
again if there is a usecase with OE-Core of such a kind. I will be
happy to deal with it no one has shown me one.
p.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/3] uclibc: Revert systemd regressing patch from upsteam uclibc
On Tue, Sep 11, 2012 at 11:37 PM, Phil Blundell ph...@gnu.org wrote: Why are you changing SRCREV as well? Well I forgot to mention is in commit about SRCREV bump. I have tested the revert on top of the proposed SRCREV I will send a V2 with more details in commit log ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH V2 3/3] uclibc: Revert systemd regressing patch from upsteam uclibc and uprev SRCREV
This patch is causing systemd based systemd to not boot
Revert of patch has been tested on tip of master hence the new SRCREV
New SRCREV brings in one another regression fix as described here
http://lists.uclibc.org/pipermail/uclibc/2012-August/046993.html
Signed-off-by: Khem Raj raj.k...@gmail.com
---
meta/recipes-core/uclibc/uclibc-git.inc|5 +-
...nt.c-wtent.c-move-functions-from-utxent.c.patch | 321
2 files changed, 324 insertions(+), 2 deletions(-)
create mode 100644
meta/recipes-core/uclibc/uclibc-git/0001-Revert-utent.c-wtent.c-move-functions-from-utxent.c.patch
diff --git a/meta/recipes-core/uclibc/uclibc-git.inc
b/meta/recipes-core/uclibc/uclibc-git.inc
index eec4ded..4da9c58 100644
--- a/meta/recipes-core/uclibc/uclibc-git.inc
+++ b/meta/recipes-core/uclibc/uclibc-git.inc
@@ -1,9 +1,9 @@
-SRCREV=555ae2e88cd16a83f854634b6c3f35715b11d3d4
+SRCREV=cb43f2afba0633400387fa7c55dda3396517f58a
DEFAULT_PREFERENCE = -1
PV = 0.9.33+git${SRCPV}
-PR = ${INC_PR}.3
+PR = ${INC_PR}.4
FILESPATH = ${@base_set_filespath([ '${FILE_DIRNAME}/uclibc-git' ], d)}
@@ -26,5 +26,6 @@ SRC_URI =
git://uclibc.org/uClibc.git;branch=master;protocol=git \
file://0001-nptl-atfork-Hide-pthread_atfork-in-shared-versions.patch \
file://0001-librt-Use-nodefaultlibs-instead-of-nostdlib.patch \
file://mount.h-update.patch \
+ file://0001-Revert-utent.c-wtent.c-move-functions-from-utxent.c.patch \
S = ${WORKDIR}/git
diff --git
a/meta/recipes-core/uclibc/uclibc-git/0001-Revert-utent.c-wtent.c-move-functions-from-utxent.c.patch
b/meta/recipes-core/uclibc/uclibc-git/0001-Revert-utent.c-wtent.c-move-functions-from-utxent.c.patch
new file mode 100644
index 000..8c202ac
--- /dev/null
+++
b/meta/recipes-core/uclibc/uclibc-git/0001-Revert-utent.c-wtent.c-move-functions-from-utxent.c.patch
@@ -0,0 +1,321 @@
+Upstream-Status: Pending
+
+From 096abf14d2dc978607ccd8a0d7f42da65d8991f3 Mon Sep 17 00:00:00 2001
+From: Khem Raj raj.k...@gmail.com
+Date: Sun, 9 Sep 2012 22:00:04 -0700
+Subject: [PATCH] Revert utent.c, wtent.c: move functions from utxent.c
+
+This reverts commit 84135275cfeebc0b233c1c96eeada4d4178a0b18.
+---
+ include/utmp.h |8 +
+ libc/misc/utmp/utent.c | 80 +++
+ libc/misc/utmp/utxent.c |4 +--
+ libc/misc/utmp/wtent.c | 14 ++---
+ 4 files changed, 30 insertions(+), 76 deletions(-)
+
+diff --git a/include/utmp.h b/include/utmp.h
+index cb8e08f..10b75c9 100644
+--- a/include/utmp.h
b/include/utmp.h
+@@ -57,29 +57,37 @@ extern void logwtmp (__const char *__ut_line, __const char
*__ut_name,
+ /* Append entry UTMP to the wtmp-like file WTMP_FILE. */
+ extern void updwtmp (__const char *__wtmp_file, __const struct utmp *__utmp)
+ __THROW;
++libc_hidden_proto(updwtmp)
+
+ /* Change name of the utmp file to be examined. */
+ extern int utmpname (__const char *__file) __THROW;
++libc_hidden_proto(utmpname)
+
+ /* Read next entry from a utmp-like file. */
+ extern struct utmp *getutent (void) __THROW;
++libc_hidden_proto(getutent)
+
+ /* Reset the input stream to the beginning of the file. */
+ extern void setutent (void) __THROW;
++libc_hidden_proto(setutent)
+
+ /* Close the current open file. */
+ extern void endutent (void) __THROW;
++libc_hidden_proto(endutent)
+
+ /* Search forward from the current point in the utmp file until the
+next entry with a ut_type matching ID-ut_type. */
+ extern struct utmp *getutid (__const struct utmp *__id) __THROW;
++libc_hidden_proto(getutid)
+
+ /* Search forward from the current point in the utmp file until the
+next entry with a ut_line matching LINE-ut_line. */
+ extern struct utmp *getutline (__const struct utmp *__line) __THROW;
++libc_hidden_proto(getutline)
+
+ /* Write out entry pointed to by UTMP_PTR into the utmp file. */
+ extern struct utmp *pututline (__const struct utmp *__utmp_ptr) __THROW;
++libc_hidden_proto(pututline)
+
+
+ #if 0 /* def __USE_MISC */
+diff --git a/libc/misc/utmp/utent.c b/libc/misc/utmp/utent.c
+index a35bb2b..07ca44e 100644
+--- a/libc/misc/utmp/utent.c
b/libc/misc/utmp/utent.c
+@@ -19,9 +19,6 @@
+ #include errno.h
+ #include string.h
+ #include utmp.h
+-#ifdef __UCLIBC_HAS_UTMPX__
+-# include utmpx.h
+-#endif
+ #include not-cancel.h
+
+ #include bits/uClibc_mutex.h
+@@ -34,7 +31,7 @@ static const char default_file_name[] = _PATH_UTMP;
+ static const char *static_ut_name = default_file_name;
+
+ /* This function must be called with the LOCK held */
+-static void __setutent_unlocked(void)
++static void __setutent(void)
+ {
+ if (static_fd 0) {
+ static_fd = open_not_cancel_2(static_ut_name, O_RDWR | O_CLOEXEC);
+@@ -53,24 +50,19 @@ static void __setutent_unlocked(void)
+ lseek(static_fd, 0, SEEK_SET);
+ }
+ #if defined __UCLIBC_HAS_THREADS__
+-static void __setutent(void)
++void setutent(void)
+ {
+ __UCLIBC_MUTEX_LOCK(utmplock);
+-
Re: [OE-core] [oe-core] valgrind: fix debug info reading error when do memcheck on ppc targets
-Original Message- From: McClintock Matthew-B29882 Sent: Wednesday, September 12, 2012 12:03 PM diff --git a/meta/recipes-devtools/valgrind/valgrind-3.7.0/valgrind-3.7.0-fix-err or-of-reading-debug-info.patch b/meta/recipes-devtools/valgrind/valgrind-3.7.0/valgrind-3.7.0-fix-err or-of-reading-debug-info.patch Patch needs Upstream-Status: [Luo Zhenhua-B19537] should the status be Pending if the patch has not been sent to upstream? +SRC_URI_append_powerpc = file://valgrind-3.7.0-fix-error-of-reading- debug-info.patch +SRC_URI_append_powerpc64 = file://valgrind-3.7.0-fix-error-of- reading-debug-info.patch [Luo Zhenhua-B19537] I think it is better to keep it for PPC before the issue is reported on targets of other arch. Best Regards, Zhenhua ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [oe-core v2] valgrind: fix debug info reading error when do memcheck on ppc targets
From: Zhenhua Luo b19...@freescale.com
following is the error message:
--2263-- WARNING: Serious error when reading debug info
--2263-- When reading debug info from /lib/ld-2.13.so:
--2263-- Can't make sense of .got section mapping
--2263-- WARNING: Serious error when reading debug info
--2263-- When reading debug info from /home/root/lzh:
--2263-- Can't make sense of .data section mapping
--2263-- WARNING: Serious error when reading debug info
--2263-- When reading debug info from
/usr/lib/valgrind/vgpreload_core-ppc32-linux.so:
--2263-- Can't make sense of .data section mapping
--2263-- WARNING: Serious error when reading debug info
--2263-- When reading debug info from
/usr/lib/valgrind/vgpreload_memcheck-ppc32-linux.so:
--2263-- Can't make sense of .data section mapping
--2263-- WARNING: Serious error when reading debug info
--2263-- When reading debug info from /lib/libc-2.13.so:
--2263-- Can't make sense of .data section mapping
Signed-off-by: Zhenhua Luo b19...@freescale.com
---
...ind-3.7.0-fix-error-of-reading-debug-info.patch | 33
meta/recipes-devtools/valgrind/valgrind_3.7.0.bb |5 ++-
2 files changed, 37 insertions(+), 1 deletion(-)
create mode 100644
meta/recipes-devtools/valgrind/valgrind-3.7.0/valgrind-3.7.0-fix-error-of-reading-debug-info.patch
diff --git
a/meta/recipes-devtools/valgrind/valgrind-3.7.0/valgrind-3.7.0-fix-error-of-reading-debug-info.patch
b/meta/recipes-devtools/valgrind/valgrind-3.7.0/valgrind-3.7.0-fix-error-of-reading-debug-info.patch
new file mode 100644
index 000..b1626f0
--- /dev/null
+++
b/meta/recipes-devtools/valgrind/valgrind-3.7.0/valgrind-3.7.0-fix-error-of-reading-debug-info.patch
@@ -0,0 +1,33 @@
+Upstream-Status: Pending
+
+fix debug info reading error when do memcheck on ppc targets
+following is the error message:
+--2263-- WARNING: Serious error when reading debug info
+--2263-- When reading debug info from /lib/ld-2.13.so:
+--2263-- Can't make sense of .got section mapping
+--2263-- WARNING: Serious error when reading debug info
+--2263-- When reading debug info from /home/root/lzh:
+--2263-- Can't make sense of .data section mapping
+--2263-- WARNING: Serious error when reading debug info
+--2263-- When reading debug info from
/usr/lib/valgrind/vgpreload_core-ppc32-linux.so:
+--2263-- Can't make sense of .data section mapping
+--2263-- WARNING: Serious error when reading debug info
+--2263-- When reading debug info from
/usr/lib/valgrind/vgpreload_memcheck-ppc32-linux.so:
+--2263-- Can't make sense of .data section mapping
+--2263-- WARNING: Serious error when reading debug info
+--2263-- When reading debug info from /lib/libc-2.13.so:
+--2263-- Can't make sense of .data section mapping
+
+Signed-off-by: Zhenhua Luo b19...@freescale.com
+
+--- a/coregrind/m_debuginfo/readelf.c 2012-09-11 21:45:36.696462313 -0500
b/coregrind/m_debuginfo/readelf.c 2012-09-11 21:45:49.913463615 -0500
+@@ -1539,7 +1539,7 @@
+ phdr-p_offset di-fsm.rw_map_foff + di-fsm.rw_map_size
+ phdr-p_offset + phdr-p_filesz
+= di-fsm.rw_map_foff + di-fsm.rw_map_size
+- (phdr-p_flags (PF_R | PF_W | PF_X)) == (PF_R | PF_W)) {
++ (phdr-p_flags (PF_R | PF_W | PF_X)) = (PF_R | PF_W)) {
+if (n_rw == N_RX_RW_AREAS) {
+ ML_(symerr)(di, True,
+ N_RX_RW_AREAS is too low;
diff --git a/meta/recipes-devtools/valgrind/valgrind_3.7.0.bb
b/meta/recipes-devtools/valgrind/valgrind_3.7.0.bb
index abda7a6..651ae60 100644
--- a/meta/recipes-devtools/valgrind/valgrind_3.7.0.bb
+++ b/meta/recipes-devtools/valgrind/valgrind_3.7.0.bb
@@ -9,7 +9,7 @@ LIC_FILES_CHKSUM =
file://COPYING;md5=c46082167a314d785d012a244748d803 \
X11DEPENDS = virtual/libx11
DEPENDS = ${@base_contains('DISTRO_FEATURES', 'x11', '${X11DEPENDS}', '', d)}
-PR = r5
+PR = r6
SRC_URI = http://www.valgrind.org/downloads/valgrind-${PV}.tar.bz2 \
file://fix_issue_caused_by_ccache.patch \
@@ -21,6 +21,9 @@ SRC_URI =
http://www.valgrind.org/downloads/valgrind-${PV}.tar.bz2 \
file://configure-with-glibc-2.16.patch \
+SRC_URI_append_powerpc =
file://valgrind-3.7.0-fix-error-of-reading-debug-info.patch
+SRC_URI_append_powerpc64 =
file://valgrind-3.7.0-fix-error-of-reading-debug-info.patch
+
SRC_URI[md5sum] = a855fda56edf05614f099dca316d1775
SRC_URI[sha256sum] =
5d62c0330f1481fe2c593249192fa68ff454c19c34343978cc9ce91aa324cbf6
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] Bug: LDFLAGS is not cleared for kernel devshell
Hi. I couldn't figure out where to properly patch this, so I'll just raise the issue: LDFLAGS is configured in bitbake.conf as linker flags to be passed to gcc, not to ld. Hence it uses the -Wl prefix. The linux kernel build system inherits LDFLAGS from the environment and passes it directly to 'ld', in conflict with the bitbake view. This problem is avoided by clearing LDFLAGS and some other enviroment variables in kernel.bbclass:kernel_do_compile(). However this clearing is not done for do_devshell, resulting in errors when trying to compile the kernel in devshell: - sestofb10:linuxmake scripts/kconfig/conf --silentoldconfig Kconfig WRAParch/arm/include/generated/asm/auxvec.h WRAParch/arm/include/generated/asm/bitsperlong.h WRAParch/arm/include/generated/asm/cputime.h WRAParch/arm/include/generated/asm/emergency-restart.h WRAParch/arm/include/generated/asm/errno.h WRAParch/arm/include/generated/asm/ioctl.h WRAParch/arm/include/generated/asm/irq_regs.h WRAParch/arm/include/generated/asm/kdebug.h WRAParch/arm/include/generated/asm/local.h WRAParch/arm/include/generated/asm/local64.h WRAParch/arm/include/generated/asm/percpu.h WRAParch/arm/include/generated/asm/poll.h WRAParch/arm/include/generated/asm/resource.h WRAParch/arm/include/generated/asm/sections.h WRAParch/arm/include/generated/asm/siginfo.h WRAParch/arm/include/generated/asm/sizes.h CHK include/linux/version.h UPD include/linux/version.h CHK include/generated/utsrelease.h UPD include/generated/utsrelease.h Generating include/generated/mach-types.h CC kernel/bounds.s GEN include/generated/bounds.h CC arch/arm/kernel/asm-offsets.s GEN include/generated/asm-offsets.h CALLscripts/checksyscalls.sh CC scripts/mod/empty.o HOSTCC scripts/mod/mk_elfconfig MKELF scripts/mod/elfconfig.h HOSTCC scripts/mod/file2alias.o HOSTCC scripts/mod/modpost.o HOSTCC scripts/mod/sumversion.o HOSTLD scripts/mod/modpost HOSTCC scripts/kallsyms HOSTCC scripts/conmakehash CC init/main.o CHK include/generated/compile.h UPD include/generated/compile.h CC init/version.o CC init/do_mounts.o LD init/mounts.o arm-oe-linux-gnueabi-ld: unrecognized option '-Wl,-O1' arm-oe-linux-gnueabi-ld: use the --help option for usage information make[1]: *** [init/mounts.o] Error 1 make: *** [init] Error 2 sestofb10:linux - -- Björn ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] Feature Developement vs. Stablisation and Bug fixing
Hi, I know in the past this has taken some people by surprise. Both OE-Core and the Yocto Project are aiming at release points every six months, roughly October and April. In order to prepare for those there is a period of 6-8 weeks beforehand which is aimed at stabilisation and bug fixing. We are now entering that window where we need to heavily taper off new features and concentrate on the quality and stability of the release which is scheduled for mid October. I'm not saying no new feature patches will get taken but I will be asking questions like why is this being worked on? and shouldn't this wait until after release?. I'd really like to see effort being focused on bugs now, not enhancements. I know there are a couple of things which have been worked on for a while and have been slightly delayed which I'd probably lean towards taking (some offline postinstall work spring to mind). I was asked whether I'd take a binutils update in a couple of weeks and the answer is no, I'd very likely not as we're at the point we need to lock in on the toolchain now (and major kernel version). Does anyone have any questions? Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Feature Developement vs. Stablisation and Bug fixing
On Wed, Sep 12, 2012 at 11:15:16AM +0100, Richard Purdie wrote: Hi, I know in the past this has taken some people by surprise. Both OE-Core and the Yocto Project are aiming at release points every six months, roughly October and April. In order to prepare for those there is a period of 6-8 weeks beforehand which is aimed at stabilisation and bug fixing. We are now entering that window where we need to heavily taper off new features and concentrate on the quality and stability of the release which is scheduled for mid October. I'm not saying no new feature patches will get taken but I will be asking questions like why is this being worked on? and shouldn't this wait until after release?. I'd really like to see effort being focused on bugs now, not enhancements. I know there are a couple of things which have been worked on for a while and have been slightly delayed which I'd probably lean towards taking (some offline postinstall work spring to mind). I was asked whether I'd take a binutils update in a couple of weeks and the answer is no, I'd very likely not as we're at the point we need to lock in on the toolchain now (and major kernel version). Does anyone have any questions? Is stuff discussed in thread: ARM-tuning -- was qemuarm: should it really have TUNE_ARCH armv5te? considered new feature or bug? In other words: should I try to test and send my proposed changes soon, or keep that for next cycle and just stop building qemuarm? Cheers, -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com signature.asc Description: Digital signature ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/2] mesa-dri: remove DEFAULT_PREFERENCE, this is the preferred now
Signed-off-by: Ross Burton ross.bur...@intel.com --- meta/recipes-graphics/mesa/mesa-dri.inc |3 --- 1 file changed, 3 deletions(-) diff --git a/meta/recipes-graphics/mesa/mesa-dri.inc b/meta/recipes-graphics/mesa/mesa-dri.inc index 7a1164b..2d5aa44 100644 --- a/meta/recipes-graphics/mesa/mesa-dri.inc +++ b/meta/recipes-graphics/mesa/mesa-dri.inc @@ -1,9 +1,6 @@ DEPENDS += libdrm expat udev X11_DEPS += dri2proto -# most of our targets do not have DRI so will use mesa-xlib -DEFAULT_PREFERENCE = -1 - DRIDRIVERS = swrast DRIDRIVERS_append_x86 = ,i915,i965 DRIDRIVERS_append_x86-64 = ,i915,i965 -- 1.7.10 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/2] mesa-xlib: remove, it serves no useful purpose
Signed-off-by: Ross Burton ross.bur...@intel.com
---
meta/recipes-graphics/mesa/mesa-xlib.inc |1 -
meta/recipes-graphics/mesa/mesa-xlib_8.0.4.bb |5 -
meta/recipes-graphics/mesa/mesa-xlib_git.bb |8
3 files changed, 14 deletions(-)
delete mode 100644 meta/recipes-graphics/mesa/mesa-xlib.inc
delete mode 100644 meta/recipes-graphics/mesa/mesa-xlib_8.0.4.bb
delete mode 100644 meta/recipes-graphics/mesa/mesa-xlib_git.bb
diff --git a/meta/recipes-graphics/mesa/mesa-xlib.inc
b/meta/recipes-graphics/mesa/mesa-xlib.inc
deleted file mode 100644
index b720e14..000
--- a/meta/recipes-graphics/mesa/mesa-xlib.inc
+++ /dev/null
@@ -1 +0,0 @@
-EXTRA_OECONF += --with-driver=xlib --without-gallium-drivers
diff --git a/meta/recipes-graphics/mesa/mesa-xlib_8.0.4.bb
b/meta/recipes-graphics/mesa/mesa-xlib_8.0.4.bb
deleted file mode 100644
index a89640e..000
--- a/meta/recipes-graphics/mesa/mesa-xlib_8.0.4.bb
+++ /dev/null
@@ -1,5 +0,0 @@
-require mesa-common.inc
-require mesa-${PV}.inc
-require mesa-xlib.inc
-PR = ${INC_PR}.2
-
diff --git a/meta/recipes-graphics/mesa/mesa-xlib_git.bb
b/meta/recipes-graphics/mesa/mesa-xlib_git.bb
deleted file mode 100644
index 6647120..000
--- a/meta/recipes-graphics/mesa/mesa-xlib_git.bb
+++ /dev/null
@@ -1,8 +0,0 @@
-require mesa-common.inc
-require mesa-git.inc
-require mesa-xlib.inc
-
-# this needs to be lower than -1 because all mesa-dri have -1 and git version
has highest PV, but shouldn't be default
-DEFAULT_PREFERENCE = -2
-
-PR = ${INC_PR}.1
--
1.7.10
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC 13/18] libx11-trim: remove, it's the same as libx11 now
This is the only patch in the series that isn't ready for merging as far as I'm concerned. Are there sufficient users of libx11-trim on non-debian-renaming systems that use package feeds to add conflicts/replaces for this? Ross ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] fstab
Hi All, I've created my own /etc/fstab which is perfectly included in base-files_*.ipk as expected. It also shows up in build/tmp-angstrom_v2012_05-eglibc/work/mymachine/myimage*/rootfs/etc But I find a different version of /etc/fstab under build/tmp-angstrom_v2012_05-eglibc/deploy/images/mymachine/myimage*.rootfs.tar.bz2 I can't figure out why! Any ideas or hints? Thanks! Jaap ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] fstab
Sorry Already solved. My bad !!! On 09/12/2012 01:48 PM, Jaap de Jong wrote: Hi All, I've created my own /etc/fstab which is perfectly included in base-files_*.ipk as expected. It also shows up in build/tmp-angstrom_v2012_05-eglibc/work/mymachine/myimage*/rootfs/etc But I find a different version of /etc/fstab under build/tmp-angstrom_v2012_05-eglibc/deploy/images/mymachine/myimage*.rootfs.tar.bz2 I can't figure out why! Any ideas or hints? Thanks! Jaap ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Feature Developement vs. Stablisation and Bug fixing
Hi Richard, On 12.09.2012 13:15, Richard Purdie wrote: Hi, I know in the past this has taken some people by surprise. Both OE-Core and the Yocto Project are aiming at release points every six months, roughly October and April. In order to prepare for those there is a period of 6-8 weeks beforehand which is aimed at stabilisation and bug fixing. We are now entering that window where we need to heavily taper off new features and concentrate on the quality and stability of the release which is scheduled for mid October. I'm not saying no new feature patches will get taken but I will be asking questions like why is this being worked on? and shouldn't this wait until after release?. I'd really like to see effort being focused on bugs now, not enhancements. I know there are a couple of things which have been worked on for a while and have been slightly delayed which I'd probably lean towards taking (some offline postinstall work spring to mind). I was asked whether I'd take a binutils update in a couple of weeks and the answer is no, I'd very likely not as we're at the point we need to lock in on the toolchain now (and major kernel version). Does anyone have any questions? do you expect to have a filed bug in Yocto's bugzilla to attract attention to a problem, or published patchset with problem description and a fix is sufficient? With best wishes, Vladimir ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Feature Developement vs. Stablisation and Bug fixing
On Wed, 2012-09-12 at 14:52 +0300, Vladimir Zapolskiy wrote: Hi Richard, On 12.09.2012 13:15, Richard Purdie wrote: Hi, I know in the past this has taken some people by surprise. Both OE-Core and the Yocto Project are aiming at release points every six months, roughly October and April. In order to prepare for those there is a period of 6-8 weeks beforehand which is aimed at stabilisation and bug fixing. We are now entering that window where we need to heavily taper off new features and concentrate on the quality and stability of the release which is scheduled for mid October. I'm not saying no new feature patches will get taken but I will be asking questions like why is this being worked on? and shouldn't this wait until after release?. I'd really like to see effort being focused on bugs now, not enhancements. I know there are a couple of things which have been worked on for a while and have been slightly delayed which I'd probably lean towards taking (some offline postinstall work spring to mind). I was asked whether I'd take a binutils update in a couple of weeks and the answer is no, I'd very likely not as we're at the point we need to lock in on the toolchain now (and major kernel version). Does anyone have any questions? do you expect to have a filed bug in Yocto's bugzilla to attract attention to a problem, or published patchset with problem description and a fix is sufficient? It doesn't have to have a bug number to be a fix to a valid problem so as long as the problem is described in the patchset, that should be ok. Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Feature Developement vs. Stablisation and Bug fixing
On Wed, 2012-09-12 at 12:25 +0200, Martin Jansa wrote: On Wed, Sep 12, 2012 at 11:15:16AM +0100, Richard Purdie wrote: Hi, I know in the past this has taken some people by surprise. Both OE-Core and the Yocto Project are aiming at release points every six months, roughly October and April. In order to prepare for those there is a period of 6-8 weeks beforehand which is aimed at stabilisation and bug fixing. We are now entering that window where we need to heavily taper off new features and concentrate on the quality and stability of the release which is scheduled for mid October. I'm not saying no new feature patches will get taken but I will be asking questions like why is this being worked on? and shouldn't this wait until after release?. I'd really like to see effort being focused on bugs now, not enhancements. I know there are a couple of things which have been worked on for a while and have been slightly delayed which I'd probably lean towards taking (some offline postinstall work spring to mind). I was asked whether I'd take a binutils update in a couple of weeks and the answer is no, I'd very likely not as we're at the point we need to lock in on the toolchain now (and major kernel version). Does anyone have any questions? Is stuff discussed in thread: ARM-tuning -- was qemuarm: should it really have TUNE_ARCH armv5te? considered new feature or bug? In other words: should I try to test and send my proposed changes soon, or keep that for next cycle and just stop building qemuarm? I'd consider this a bugfix but one we probably need to figure out sooner than later... Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/2] linux-yocto/3.4: add x32 configuration fragment and tuning hook
On Tue, 2012-09-11 at 09:07 -0700, Saul Wold wrote:
On 09/11/2012 08:58 AM, Richard Purdie wrote:
On Tue, 2012-09-11 at 08:41 -0700, Saul Wold wrote:
On 09/11/2012 08:39 AM, Bruce Ashfield wrote:
On 12-09-11 11:33 AM, Saul Wold wrote:
On 09/11/2012 08:17 AM, Bruce Ashfield wrote:
When x32 is the tuning for a x86 MACHINE, the kernel should also have
CONFIG_X86_X32=y.
This can be accomplished by adding the x32 configuraion fragment to the
KERNEL_FEATURES when x32 is the tuning for a given machine.
cc: Saul Wold s...@linux.intel.com
Signed-off-by: Bruce Ashfield bruce.ashfi...@windriver.com
---
meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb | 3 ++-
meta/recipes-kernel/linux/linux-yocto_3.4.bb | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb
b/meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb
index 4fd3845..156fb93 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb
@@ -10,7 +10,7 @@ KMETA = meta
SRCREV_machine ?= a35693b1287c0e50cdca33a1b95af0ff48b43cd0
SRCREV_machine_qemuppc ?= 85a1190530cb5749f5f831670976b163438dc301
-SRCREV_meta ?= d9d5fc63d8b38705036e946ea77d971d95de11ad
+SRCREV_meta ?= e0374ce012e7e6fc8e5bb8b957addb0478950898
PR = ${INC_PR}.0
PV = ${LINUX_VERSION}+git${SRCPV}
@@ -27,3 +27,4 @@ KERNEL_FEATURES_append = features/netfilter
KERNEL_FEATURES_append = features/taskstats
KERNEL_FEATURES_append_qemux86 = cfg/sound
KERNEL_FEATURES_append_qemux86-64 = cfg/sound
+KERNEL_FEATURES_append_x32 = cfg/x32
Scratch this bit and below, as I think I will use the other mechanism
you talked about to go from a .conf file.
Works for me. The meta change is staged and pushed out, I'll update this
patch to not have the KERNEL_FEATURES portion.
Thanks, see my other email to RP, since x32 is a feature that any x86-64
machine might want to enable based on the DEFAULTTUNE it makes more
sense to be in the machine config includes.
No, it doesn't.
What we need here is:
-KERNEL_FEATURES_append = features/taskstats
+KERNEL_FEATURES_append = features/taskstats
${@bb.utils.contains(TUNE_FEATURES, mx32, cfg/x32, ,d)}
No, this would then only address the qemu machine, what about all the HW
BSP that might want it, they would need to add this same line. If I add
the KERNEL_FEATURES_append to the arch-ia32.inc, conditional on mx32,
then any x86-64 BSP can just enable that TUNE, isn't that the point of
the machine config tuning?
It is the point, however, the key part of this you're ignoring is that
the kernel fragment management only happens for linux-yocto. Only the
linux-yocto recipe supports the KERNEL_FEATURES mechanism.
The arch-ia32.inc file and any machine config *cannot* depend on
linux-yocto.
So this glue belongs in linux-yocto. I agree is suboptimal for people
not using it but such is life, there isn't any generic mechanism we can
place this into.
which is simple, effective and to the point. If we start needing lots of
these, we can look at an x32 override but right now I don't see the
need.
And it does not have to be an x32 override, we just set it in the
arch-ia32.inc file where we define that TUNE.
That seems the best way.
Its not. See above.
Cheers,
Richard
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] gst-plugins-good: fix compile error with recent linux-libc-headers
On Wed, Sep 5, 2012 at 7:50 PM, Andreas Müller schnitzelt...@googlemail.com wrote: With linux-libc-headers-3.5.0 (for tests) the error message was: | gstv4l2bufferpool.c: In function 'gst_v4l2_buffer_new': | gstv4l2bufferpool.c:184:3: error: 'struct v4l2_buffer' has no member named 'input' Signed-off-by: Andreas Müller schnitzelt...@googlemail.com --- ...ild-with-recent-kernels-the-v4l2_buffer-i.patch | 33 .../gstreamer/gst-plugins-good_0.10.31.bb |4 ++- 2 files changed, 36 insertions(+), 1 deletions(-) create mode 100644 meta/recipes-multimedia/gstreamer/gst-plugins-good-0.10.31/0001-v4l2-fix-build-with-recent-kernels-the-v4l2_buffer-i.patch diff --git a/meta/recipes-multimedia/gstreamer/gst-plugins-good-0.10.31/0001-v4l2-fix-build-with-recent-kernels-the-v4l2_buffer-i.patch b/meta/recipes-multimedia/gstreamer/gst-plugins-good-0.10.31/0001-v4l2-fix-build-with-recent-kernels-the-v4l2_buffer-i.patch new file mode 100644 index 000..6456d3c --- /dev/null +++ b/meta/recipes-multimedia/gstreamer/gst-plugins-good-0.10.31/0001-v4l2-fix-build-with-recent-kernels-the-v4l2_buffer-i.patch @@ -0,0 +1,33 @@ +From 12d18fe4e98e7c232d59b56d529a0521f293fe6d Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Andreas=20M=C3=BCller?= schnitzelt...@googlemail.com +Date: Wed, 5 Sep 2012 18:54:42 +0200 +Subject: [PATCH] v4l2: fix build with recent kernels, the v4l2_buffer input + field was removed +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +Upstream-Status: Backport + +[1] http://cgit.freedesktop.org/gstreamer/gst-plugins-good/commit/?id=9f2aa8d47f835ea155aaf635f618c0fc1ca87012 + +Signed-off-by: Andreas Müller schnitzelt...@googlemail.com +--- + sys/v4l2/gstv4l2bufferpool.c |1 - + 1 files changed, 0 insertions(+), 1 deletions(-) + +diff --git a/sys/v4l2/gstv4l2bufferpool.c b/sys/v4l2/gstv4l2bufferpool.c +index b81c6a4..51cc0ce 100644 +--- a/sys/v4l2/gstv4l2bufferpool.c b/sys/v4l2/gstv4l2bufferpool.c +@@ -181,7 +181,6 @@ gst_v4l2_buffer_new (GstV4l2BufferPool * pool, guint index, GstCaps * caps) + GST_LOG_OBJECT (pool-v4l2elem, MMAP offset: %u, + ret-vbuffer.m.offset); + GST_LOG_OBJECT (pool-v4l2elem, length:%u, ret-vbuffer.length); +- GST_LOG_OBJECT (pool-v4l2elem, input: %u, ret-vbuffer.input); + + data = (guint8 *) v4l2_mmap (0, ret-vbuffer.length, + PROT_READ | PROT_WRITE, MAP_SHARED, pool-video_fd, +-- +1.7.6.5 + diff --git a/meta/recipes-multimedia/gstreamer/gst-plugins-good_0.10.31.bb b/meta/recipes-multimedia/gstreamer/gst-plugins-good_0.10.31.bb index ac63f94..abcd836 100644 --- a/meta/recipes-multimedia/gstreamer/gst-plugins-good_0.10.31.bb +++ b/meta/recipes-multimedia/gstreamer/gst-plugins-good_0.10.31.bb @@ -7,10 +7,12 @@ LIC_FILES_CHKSUM = file://COPYING;md5=a6f89e2100d9b6cdffcea4f398e37343 \ DEPENDS += gst-plugins-base gconf cairo jpeg libpng gtk+ zlib libid3tag flac \ speex libsoup-2.4 pulseaudio -PR = r2 +PR = r3 inherit gettext gconf +SRC_URI += file://0001-v4l2-fix-build-with-recent-kernels-the-v4l2_buffer-i.patch + EXTRA_OECONF += --disable-aalib --disable-esd --disable-shout2 --disable-libcaca --disable-hal --without-check \ --disable-orc -- Does it make sense to prepare a rebased version (it is a bugfix for kernel-libc-headers used in the future 3.5) Andreas ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] patch.bbclass: Use one TMPDIR per patching process
We must use one TMPDIR per process (/tmp/${PID}) so that the patching
processes don't generate the same temp file name (the patch program
uses the TMPDIR environment variable for deciding where to create the
temp files).
[YOCTO #3070]
Signed-off-by: Constantin Musca constantinx.mu...@intel.com
---
meta/classes/patch.bbclass | 11 +++
1 file changed, 11 insertions(+)
diff --git a/meta/classes/patch.bbclass b/meta/classes/patch.bbclass
index a724972..d010438 100644
--- a/meta/classes/patch.bbclass
+++ b/meta/classes/patch.bbclass
@@ -139,6 +139,13 @@ python patch_do_patch() {
path = os.getenv('PATH')
os.putenv('PATH', d.getVar('PATH', True))
+import shutil
+process_tmpdir = os.path.join('/tmp', str(os.getpid()))
+if os.path.exists(process_tmpdir):
+shutil.rmtree(process_tmpdir)
+os.makedirs(process_tmpdir)
+os.environ['TMPDIR'] = process_tmpdir
+
for patch in src_patches(d):
_, _, local, _, _, parm = bb.decodeurl(patch)
@@ -161,11 +168,15 @@ python patch_do_patch() {
try:
patchset.Import({file:local, strippath: parm['striplevel']},
True)
except Exception as exc:
+shutil.rmtree(process_tmpdir)
bb.fatal(str(exc))
try:
resolver.Resolve()
except bb.BBHandledException as e:
+shutil.rmtree(process_tmpdir)
bb.fatal(str(e))
+
+shutil.rmtree(process_tmpdir)
}
patch_do_patch[vardepsexclude] = PATCHRESOLVE
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/2] linux-yocto/3.4: add x32 configuration fragment and tuning hook
On Wed, Sep 12, 2012 at 8:25 AM, Richard Purdie
richard.pur...@linuxfoundation.org wrote:
On Tue, 2012-09-11 at 09:07 -0700, Saul Wold wrote:
On 09/11/2012 08:58 AM, Richard Purdie wrote:
On Tue, 2012-09-11 at 08:41 -0700, Saul Wold wrote:
On 09/11/2012 08:39 AM, Bruce Ashfield wrote:
On 12-09-11 11:33 AM, Saul Wold wrote:
On 09/11/2012 08:17 AM, Bruce Ashfield wrote:
When x32 is the tuning for a x86 MACHINE, the kernel should also have
CONFIG_X86_X32=y.
This can be accomplished by adding the x32 configuraion fragment to the
KERNEL_FEATURES when x32 is the tuning for a given machine.
cc: Saul Wold s...@linux.intel.com
Signed-off-by: Bruce Ashfield bruce.ashfi...@windriver.com
---
meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb | 3 ++-
meta/recipes-kernel/linux/linux-yocto_3.4.bb | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb
b/meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb
index 4fd3845..156fb93 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb
@@ -10,7 +10,7 @@ KMETA = meta
SRCREV_machine ?= a35693b1287c0e50cdca33a1b95af0ff48b43cd0
SRCREV_machine_qemuppc ?= 85a1190530cb5749f5f831670976b163438dc301
-SRCREV_meta ?= d9d5fc63d8b38705036e946ea77d971d95de11ad
+SRCREV_meta ?= e0374ce012e7e6fc8e5bb8b957addb0478950898
PR = ${INC_PR}.0
PV = ${LINUX_VERSION}+git${SRCPV}
@@ -27,3 +27,4 @@ KERNEL_FEATURES_append = features/netfilter
KERNEL_FEATURES_append = features/taskstats
KERNEL_FEATURES_append_qemux86 = cfg/sound
KERNEL_FEATURES_append_qemux86-64 = cfg/sound
+KERNEL_FEATURES_append_x32 = cfg/x32
Scratch this bit and below, as I think I will use the other mechanism
you talked about to go from a .conf file.
Works for me. The meta change is staged and pushed out, I'll update this
patch to not have the KERNEL_FEATURES portion.
Thanks, see my other email to RP, since x32 is a feature that any x86-64
machine might want to enable based on the DEFAULTTUNE it makes more
sense to be in the machine config includes.
No, it doesn't.
What we need here is:
-KERNEL_FEATURES_append = features/taskstats
+KERNEL_FEATURES_append = features/taskstats
${@bb.utils.contains(TUNE_FEATURES, mx32, cfg/x32, ,d)}
No, this would then only address the qemu machine, what about all the HW
BSP that might want it, they would need to add this same line. If I add
the KERNEL_FEATURES_append to the arch-ia32.inc, conditional on mx32,
then any x86-64 BSP can just enable that TUNE, isn't that the point of
the machine config tuning?
It is the point, however, the key part of this you're ignoring is that
the kernel fragment management only happens for linux-yocto. Only the
linux-yocto recipe supports the KERNEL_FEATURES mechanism.
The arch-ia32.inc file and any machine config *cannot* depend on
linux-yocto.
So this glue belongs in linux-yocto. I agree is suboptimal for people
not using it but such is life, there isn't any generic mechanism we can
place this into.
:)
linux-yocto it is, I've respun the patches to include the TUNE_FEATURES check
and pushed them to poky-contrib zedd/x32:
7aeb32 linux-yocto/3.4: add x32 configuration fragment
d34a34c linux-yocto*: append to KERNEL_FEATURES instead of assigning
I don't have a x32 build handy, but I assume Saul will take them for a spin.
If you want a full resend of the series, shout and I'll git send-email them out.
Cheers,
Bruce
which is simple, effective and to the point. If we start needing lots of
these, we can look at an x32 override but right now I don't see the
need.
And it does not have to be an x32 override, we just set it in the
arch-ia32.inc file where we define that TUNE.
That seems the best way.
Its not. See above.
Cheers,
Richard
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
--
Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] cml1.bbclass: fix kernel menuconfig
At some host environments the menuconfig displayed wrong characters ang turned
unusable.
Similar suggested in [1]
[1]
http://lists.linuxtogo.org/pipermail/openembedded-core/2012-August/027130.html
Signed-off-by: Andreas Müller schnitzelt...@googlemail.com
---
meta/classes/cml1.bbclass |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/meta/classes/cml1.bbclass b/meta/classes/cml1.bbclass
index 67f17ad..c773684 100644
--- a/meta/classes/cml1.bbclass
+++ b/meta/classes/cml1.bbclass
@@ -9,7 +9,7 @@ addtask configure after do_unpack do_patch before do_compile
inherit terminal
-OE_TERMINAL_EXPORTS += HOST_EXTRACFLAGS HOSTLDFLAGS HOST_LOADLIBES
+OE_TERMINAL_EXPORTS += HOST_EXTRACFLAGS HOST_LOADLIBES
HOST_EXTRACFLAGS = ${BUILD_CFLAGS} ${BUILD_LDFLAGS}
HOSTLDFLAGS = ${BUILD_LDFLAGS}
HOST_LOADLIBES = -lncurses
--
1.7.6.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] cml1.bbclass: fix kernel menuconfig
On Wed, 2012-09-12 at 15:19 +0200, Andreas Müller wrote:
At some host environments the menuconfig displayed wrong characters ang turned
unusable.
Similar suggested in [1]
[1]
http://lists.linuxtogo.org/pipermail/openembedded-core/2012-August/027130.html
Signed-off-by: Andreas Müller schnitzelt...@googlemail.com
---
meta/classes/cml1.bbclass |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/meta/classes/cml1.bbclass b/meta/classes/cml1.bbclass
index 67f17ad..c773684 100644
--- a/meta/classes/cml1.bbclass
+++ b/meta/classes/cml1.bbclass
@@ -9,7 +9,7 @@ addtask configure after do_unpack do_patch before do_compile
inherit terminal
-OE_TERMINAL_EXPORTS += HOST_EXTRACFLAGS HOSTLDFLAGS HOST_LOADLIBES
+OE_TERMINAL_EXPORTS += HOST_EXTRACFLAGS HOST_LOADLIBES
HOST_EXTRACFLAGS = ${BUILD_CFLAGS} ${BUILD_LDFLAGS}
HOSTLDFLAGS = ${BUILD_LDFLAGS}
HOST_LOADLIBES = -lncurses
This effectively just reverts the previous change. The real problem is
that ncurses-native is broken. Could we figure out how/why
ncurses-native is broken and fix the real problem rather than hacking
around it please?
FWIW I've been unable to reproduce this locally :(.
Cheers,
Richard
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Bug: LDFLAGS is not cleared for kernel devshell
On Wed, Sep 12, 2012 at 2:56 AM, Björn Stenberg b...@enea.com wrote: I couldn't figure out where to properly patch this, so I'll just raise the issue: LDFLAGS is configured in bitbake.conf as linker flags to be passed to gcc, not to ld. Hence it uses the -Wl prefix. The linux kernel build system inherits LDFLAGS from the environment and passes it directly to 'ld', in conflict with the bitbake view. This problem is avoided by clearing LDFLAGS and some other enviroment variables in kernel.bbclass:kernel_do_compile(). However this clearing is not done for do_devshell, resulting in errors when trying to compile the kernel in devshell: We could unexport the appropriate variables rather than unsetting them in the task. E.g. LDFLAGS[unexport] = 1 -- Christopher Larson ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] cml1.bbclass: fix kernel menuconfig
On Wed, Sep 12, 2012 at 9:31 AM, Richard Purdie
richard.pur...@linuxfoundation.org wrote:
On Wed, 2012-09-12 at 15:19 +0200, Andreas Müller wrote:
At some host environments the menuconfig displayed wrong characters ang
turned
unusable.
Similar suggested in [1]
[1]
http://lists.linuxtogo.org/pipermail/openembedded-core/2012-August/027130.html
Signed-off-by: Andreas Müller schnitzelt...@googlemail.com
---
meta/classes/cml1.bbclass |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/meta/classes/cml1.bbclass b/meta/classes/cml1.bbclass
index 67f17ad..c773684 100644
--- a/meta/classes/cml1.bbclass
+++ b/meta/classes/cml1.bbclass
@@ -9,7 +9,7 @@ addtask configure after do_unpack do_patch before do_compile
inherit terminal
-OE_TERMINAL_EXPORTS += HOST_EXTRACFLAGS HOSTLDFLAGS HOST_LOADLIBES
+OE_TERMINAL_EXPORTS += HOST_EXTRACFLAGS HOST_LOADLIBES
HOST_EXTRACFLAGS = ${BUILD_CFLAGS} ${BUILD_LDFLAGS}
HOSTLDFLAGS = ${BUILD_LDFLAGS}
HOST_LOADLIBES = -lncurses
This effectively just reverts the previous change. The real problem is
that ncurses-native is broken. Could we figure out how/why
ncurses-native is broken and fix the real problem rather than hacking
around it please?
FWIW I've been unable to reproduce this locally :(.
I've also tried to reproduce this periodically and have never seen it where
I can debug it properly.
I'm also not disputing that this is an issue .. just one I can't get at yet
either.
Cheers,
Bruce
Cheers,
Richard
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
--
Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] kernel: remove unused 'etc' directory
Along with checks to remove empty modprobe.d and modules-load.d
directories we can add a similar check and removal of the etc
directory. This will avoid warnings by the sanity checker.
Signed-off-by: Mark Asselstine mark.asselst...@windriver.com
CC: Bruce Ashfield bruce.ashfi...@windriver.com
---
There is some concern that removing this directory could cause issues
if folks are adding to etc in a bbappend and not checking for and
creating this directory. I don't believe this is an issue as if you
want to add something to etc it should be done as part of a
populate_packages_prepend or earlier since there are sanity checks run
as part of populate_packages, so the removal here is being done at the
latest possible point in the process (populate_packages_prepend in a
bbappend will run before the populate_packages_prepend in
kernel.bbclass).
meta/classes/kernel.bbclass |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 5e04fda..decf6f5 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -468,7 +468,7 @@ python populate_packages_prepend () {
# avoid warnings. removedirs only raises an OSError if an empty
# directory cannot be removed.
dvar = d.getVar('PKGD', True)
-for dir in [%s/etc/modprobe.d % (dvar), %s/etc/modules-load.d %
(dvar)]:
+for dir in [%s/etc/modprobe.d % (dvar), %s/etc/modules-load.d %
(dvar), %s/etc/ % (dvar)]:
if len(os.listdir(dir)) == 0:
os.rmdir(dir)
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/2] linux-yocto/3.4: add x32 configuration fragment and tuning hook
On Wed, 2012-09-12 at 08:58 -0400, Bruce Ashfield wrote:
On Wed, Sep 12, 2012 at 8:25 AM, Richard Purdie
richard.pur...@linuxfoundation.org wrote:
On Tue, 2012-09-11 at 09:07 -0700, Saul Wold wrote:
On 09/11/2012 08:58 AM, Richard Purdie wrote:
On Tue, 2012-09-11 at 08:41 -0700, Saul Wold wrote:
On 09/11/2012 08:39 AM, Bruce Ashfield wrote:
On 12-09-11 11:33 AM, Saul Wold wrote:
On 09/11/2012 08:17 AM, Bruce Ashfield wrote:
When x32 is the tuning for a x86 MACHINE, the kernel should also have
CONFIG_X86_X32=y.
This can be accomplished by adding the x32 configuraion fragment to
the
KERNEL_FEATURES when x32 is the tuning for a given machine.
cc: Saul Wold s...@linux.intel.com
Signed-off-by: Bruce Ashfield bruce.ashfi...@windriver.com
---
meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb | 3 ++-
meta/recipes-kernel/linux/linux-yocto_3.4.bb | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb
b/meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb
index 4fd3845..156fb93 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb
@@ -10,7 +10,7 @@ KMETA = meta
SRCREV_machine ?= a35693b1287c0e50cdca33a1b95af0ff48b43cd0
SRCREV_machine_qemuppc ?= 85a1190530cb5749f5f831670976b163438dc301
-SRCREV_meta ?= d9d5fc63d8b38705036e946ea77d971d95de11ad
+SRCREV_meta ?= e0374ce012e7e6fc8e5bb8b957addb0478950898
PR = ${INC_PR}.0
PV = ${LINUX_VERSION}+git${SRCPV}
@@ -27,3 +27,4 @@ KERNEL_FEATURES_append = features/netfilter
KERNEL_FEATURES_append = features/taskstats
KERNEL_FEATURES_append_qemux86 = cfg/sound
KERNEL_FEATURES_append_qemux86-64 = cfg/sound
+KERNEL_FEATURES_append_x32 = cfg/x32
Scratch this bit and below, as I think I will use the other mechanism
you talked about to go from a .conf file.
Works for me. The meta change is staged and pushed out, I'll update
this
patch to not have the KERNEL_FEATURES portion.
Thanks, see my other email to RP, since x32 is a feature that any x86-64
machine might want to enable based on the DEFAULTTUNE it makes more
sense to be in the machine config includes.
No, it doesn't.
What we need here is:
-KERNEL_FEATURES_append = features/taskstats
+KERNEL_FEATURES_append = features/taskstats
${@bb.utils.contains(TUNE_FEATURES, mx32, cfg/x32, ,d)}
No, this would then only address the qemu machine, what about all the HW
BSP that might want it, they would need to add this same line. If I add
the KERNEL_FEATURES_append to the arch-ia32.inc, conditional on mx32,
then any x86-64 BSP can just enable that TUNE, isn't that the point of
the machine config tuning?
It is the point, however, the key part of this you're ignoring is that
the kernel fragment management only happens for linux-yocto. Only the
linux-yocto recipe supports the KERNEL_FEATURES mechanism.
The arch-ia32.inc file and any machine config *cannot* depend on
linux-yocto.
So this glue belongs in linux-yocto. I agree is suboptimal for people
not using it but such is life, there isn't any generic mechanism we can
place this into.
:)
linux-yocto it is, I've respun the patches to include the TUNE_FEATURES check
and pushed them to poky-contrib zedd/x32:
7aeb32 linux-yocto/3.4: add x32 configuration fragment
d34a34c linux-yocto*: append to KERNEL_FEATURES instead of assigning
I don't have a x32 build handy, but I assume Saul will take them for a spin.
If you want a full resend of the series, shout and I'll git send-email them
out.
I've merged this, thanks. I'm assuming Saul will test the end result.
Cheers,
Richard
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC 13/18] libx11-trim: remove, it's the same as libx11 now
On Wed, 2012-09-12 at 12:46 +0100, Burton, Ross wrote: This is the only patch in the series that isn't ready for merging as far as I'm concerned. Are there sufficient users of libx11-trim on non-debian-renaming systems that use package feeds to add conflicts/replaces for this? I don't think there are many such users so I've merged the series. We've had this mess around for a long time, keep talking about fixing and now someone gives me a patch series so I really just can't resist ;-) Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] gst-plugins-good: fix compile error with recent linux-libc-headers
On Wed, 2012-09-12 at 14:27 +0200, Andreas Müller wrote: On Wed, Sep 5, 2012 at 7:50 PM, Andreas Müller schnitzelt...@googlemail.com wrote: With linux-libc-headers-3.5.0 (for tests) the error message was: | gstv4l2bufferpool.c: In function 'gst_v4l2_buffer_new': | gstv4l2bufferpool.c:184:3: error: 'struct v4l2_buffer' has no member named 'input' Signed-off-by: Andreas Müller schnitzelt...@googlemail.com --- ...ild-with-recent-kernels-the-v4l2_buffer-i.patch | 33 .../gstreamer/gst-plugins-good_0.10.31.bb |4 ++- 2 files changed, 36 insertions(+), 1 deletions(-) create mode 100644 meta/recipes-multimedia/gstreamer/gst-plugins-good-0.10.31/0001-v4l2-fix-build-with-recent-kernels-the-v4l2_buffer-i.patch diff --git a/meta/recipes-multimedia/gstreamer/gst-plugins-good-0.10.31/0001-v4l2-fix-build-with-recent-kernels-the-v4l2_buffer-i.patch b/meta/recipes-multimedia/gstreamer/gst-plugins-good-0.10.31/0001-v4l2-fix-build-with-recent-kernels-the-v4l2_buffer-i.patch new file mode 100644 index 000..6456d3c --- /dev/null +++ b/meta/recipes-multimedia/gstreamer/gst-plugins-good-0.10.31/0001-v4l2-fix-build-with-recent-kernels-the-v4l2_buffer-i.patch @@ -0,0 +1,33 @@ +From 12d18fe4e98e7c232d59b56d529a0521f293fe6d Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Andreas=20M=C3=BCller?= schnitzelt...@googlemail.com +Date: Wed, 5 Sep 2012 18:54:42 +0200 +Subject: [PATCH] v4l2: fix build with recent kernels, the v4l2_buffer input + field was removed +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +Upstream-Status: Backport + +[1] http://cgit.freedesktop.org/gstreamer/gst-plugins-good/commit/?id=9f2aa8d47f835ea155aaf635f618c0fc1ca87012 + +Signed-off-by: Andreas Müller schnitzelt...@googlemail.com +--- + sys/v4l2/gstv4l2bufferpool.c |1 - + 1 files changed, 0 insertions(+), 1 deletions(-) + +diff --git a/sys/v4l2/gstv4l2bufferpool.c b/sys/v4l2/gstv4l2bufferpool.c +index b81c6a4..51cc0ce 100644 +--- a/sys/v4l2/gstv4l2bufferpool.c b/sys/v4l2/gstv4l2bufferpool.c +@@ -181,7 +181,6 @@ gst_v4l2_buffer_new (GstV4l2BufferPool * pool, guint index, GstCaps * caps) + GST_LOG_OBJECT (pool-v4l2elem, MMAP offset: %u, + ret-vbuffer.m.offset); + GST_LOG_OBJECT (pool-v4l2elem, length:%u, ret-vbuffer.length); +- GST_LOG_OBJECT (pool-v4l2elem, input: %u, ret-vbuffer.input); + + data = (guint8 *) v4l2_mmap (0, ret-vbuffer.length, + PROT_READ | PROT_WRITE, MAP_SHARED, pool-video_fd, +-- +1.7.6.5 + diff --git a/meta/recipes-multimedia/gstreamer/gst-plugins-good_0.10.31.bb b/meta/recipes-multimedia/gstreamer/gst-plugins-good_0.10.31.bb index ac63f94..abcd836 100644 --- a/meta/recipes-multimedia/gstreamer/gst-plugins-good_0.10.31.bb +++ b/meta/recipes-multimedia/gstreamer/gst-plugins-good_0.10.31.bb @@ -7,10 +7,12 @@ LIC_FILES_CHKSUM = file://COPYING;md5=a6f89e2100d9b6cdffcea4f398e37343 \ DEPENDS += gst-plugins-base gconf cairo jpeg libpng gtk+ zlib libid3tag flac \ speex libsoup-2.4 pulseaudio -PR = r2 +PR = r3 inherit gettext gconf +SRC_URI += file://0001-v4l2-fix-build-with-recent-kernels-the-v4l2_buffer-i.patch + EXTRA_OECONF += --disable-aalib --disable-esd --disable-shout2 --disable-libcaca --disable-hal --without-check \ --disable-orc -- Does it make sense to prepare a rebased version (it is a bugfix for kernel-libc-headers used in the future 3.5) I've merged it, thanks. Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] quota 4.00: add DEPENDS gettext-native
On Mon, 2012-07-23 at 16:38 +0800, jackie.hu...@windriver.com wrote: From: Jackie Huang jackie.hu...@windriver.com do_install needs command 'msgfmt', it would fail if the command doesn't exist on the host, add DEPENDS gettext-native to fix this. [YOCTO #2811] Signed-off-by: Jackie Huang jackie.hu...@windriver.com --- meta/recipes-extended/quota/quota_4.00.bb |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) Merged to master, thanks. Sorry for the delay on this on, the patch is the correct fix in this case (just a little unusual). Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [CONSOLIDATED REQUEST v2 00/35] Misc Fixes (CV Only)
On Wed, 2012-09-12 at 00:23 -0700, Saul Wold wrote: This contains various fixes from teh community along with a few updates. The Kernel update seems to have trigged a mpc8315 failure, but I am sure Bruce will deal with it quickly. This also include Bruce and my change that now allows us to elimate the x32 layer and by setting the DEFAULTTUNE enable x32 build for any BSP. Phil B. has confirmed his change with BUILD_HISTORY. This is a good change set and should be merged. There are a couple of meta-yocto changes that I need to pull together also, but they are minor. I pulled most of this in. I took an alternative patch for x32 as discussed in other emails. I also dug back and took the older quota patch, not yours since the other DEPENDS one is correct, its an unusual corner case. Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/4] gcc: Switch SRC_URI to use svn
On Tue, 2012-09-11 at 20:44 -0600, Gary Thomas wrote: On 2012-09-05 22:35, Khem Raj wrote: svn tar balls are 96M as compared to 1.3G git tars its unnessary to suck in that much of data. Fixes [YOCTO #2908] Signed-off-by: Khem Raj raj.k...@gmail.com What about this patch? Carrying around a 1.7GB (Sorry, Khem, that's the size of my tar ball!) is a bit much, especially when that's what I send to my customers... I've been hoping to find some time to do something with the fetcher to try and fix this corner we've ended up pinned into. Ideally I'd like to see both gcc and eglibc using git, we have git in ASSUME_PROVIDED and everything is optimal. I'm not going to reach the release point without doing something about this but I would like to stick with git if we can possibly help it. Having to build subversion-native for critical path components is a major pain and performance issue. Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] libx11-diet removal
On 12 September 2012 14:59, Richard Purdie richard.pur...@linuxfoundation.org wrote: I don't think there are many such users so I've merged the series. We've had this mess around for a long time, keep talking about fixing and now someone gives me a patch series so I really just can't resist ;-) Thanks, Richard. The final question is do we keep libx11-diet? It is substantially smaller but the stubbing does knock out some non-deprecated functionality - as far as I'm aware both GTK+ and Qt fail to initialise with libx11-diet. Two options: 1) delete it from oe-core 2) whoever actually uses it can have it, moving it from oe-core I'll do (1) soonish unless someone speaks up in it's defence... Ross ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] autotools.bbclass: Add functionality to force a clean of ${B} when reconfiguring (and ${S} != ${B})
On Tue, 2012-09-11 at 19:01 +, McClintock Matthew-B29882 wrote:
On Tue, Sep 11, 2012 at 9:22 AM, Richard Purdie
richard.pur...@linuxfoundation.org wrote:
Unfortunately whilst rerunning configure and make against a project will
mostly
work there are situations where it does not correctly do the right thing.
In particular, eglibc and gcc will fail out with errors where settings
do not match a previously built configuration. It could be argued they are
broken but the situation is what it is. There is the possibility of more
subtle
errors too.
This patch adds removal of the build directory (${B}) when configure is
rerunning, the sstate checksum for do_configure has changed and ${S} !=
${B}.
We could simply use a stamp but saving out the previous configuration
checksum
adds some data at no real overhead.
If we find there are things where we want to disable this behaviour with
CONFIGURESTAMPFILE = in the recipe, or users could disable it globally.
[YOCTO #2774]
[YOCTO #2848]
This is particularly helpful for eglibc and gcc which use split builds by
default and
are a particular source of reconfigure type problems.
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
Is it feasible to back port this to denzil? I've encountered what I
think are similar issues reconfiguring gcc for example.
One of the bugs above is open against denzil and the issue certainly
exists there. The patch should apply equally well there.
I'd suggest we let this settle in master for a week or two and then add
it to the backport queue if no problems arise.
Cc'ing Scott so he's aware of this.
Cheers,
Richard
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] qemuarm: should it really have TUNE_ARCH armv5te?
On Tue, 2012-09-11 at 15:01 +0200, Martin Jansa wrote:
Hi,
when building spitz and qemuarm (both produces packages in armv5te feed)
resulting packages are tuned with -mtune=xscale (when built for spitz)
or -mtune=arm926ej-s (when built for qemuarm).
From
https://bugzilla.yoctoproject.org/show_bug.cgi?id=1916#c5
Firstly, if you go changing the tune parameters in a given machine,
you are expected to use a different PACKAGE_ARCH. If you do that, you
will get a different package feed for the different binaries,
different WORKDIR and so on. This was always the way the package
architectures was intended to work and nothing has changed there. Yes,
you as the user changing various variables can create inconsistent
package feeds. There are 101 ways you can do that, the simple answer
is just don't. We're therefore unlikely to add MACHINE to DEPLOY_DIR
or remove PACKAGE_ARCH, please just use it as its intended.
Does qemuarm use oe-core as it's intended?
Shouldn't spitz produce something like armv5te-xscale and qemuarm
armv5te-arm926ejs?
It would cause all recipes to build again (cannot share armv5te feed anymore),
but at least it would build it and user will really get it on target, right
now
opkg upgrade can download some packages with xscale some with arm926ej-s.
$ ~/bitbake/bin/bitbake-diffsigs
stamps.1347348910/spitz/armv5te-oe-linux-gnueabi/linux-libc-headers-3.4.3-r0.do_configure.sigdata.04b364a15889fcff7502614f1c116abc
stamps.1347348910/qemuarm/armv5te-oe-linux-gnueabi/linux-libc-headers-3.4.3-r0.do_configure.sigdata.656f0583be969b427f040f2e143bcb14
basehash changed from 7fe9c0a3455dac20ba6a90ed337b097e to
d8dd2ff8613d0aafe60bef1a1e9469a1
Variable TUNE_CCARGS value changed from
${@bb.utils.contains(TUNE_FEATURES, armv5,
-march=armv5${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}, , d)}
${@bb.utils.contains(TUNE_FEATURES, armv4,
-march=armv4${ARMPKGSFX_THUMB}, , d)}
${@bb.utils.contains(TUNE_FEATURES, thumb, ${ARM_THUMB_M_OPT}, , d)}
${@bb.utils.contains(TUNE_FEATURES, no-thumb-interwork,
-mno-thumb-interwork, -mthumb-interwork, d)}
${@bb.utils.contains(TUNE_FEATURES, vfp,
bb.utils.contains(TUNE_FEATURES, callconvention-hard, -mfloat-abi=hard,
-mfloat-abi=softfp, d), ,d)}
${@bb.utils.contains(TUNE_FEATURES, xscale, -mtune=xscale, , d)}
to
${@bb.utils.contains(TUNE_FEATURES, armv5,
-march=armv5${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}, , d)}
${@bb.utils.contains(TUNE_FEATURES, armv4,
-march=armv4${ARMPKGSFX_THUMB}, , d)}
${@bb.utils.contains(TUNE_FEATURES, thumb, ${ARM_THUMB_M_OPT}, , d)}
${@bb.utils.contains(TUNE_FEATURES, no-thumb-interwork,
-mno-thumb-interwork, -mthumb-interwork, d)}
${@bb.utils.contains(TUNE_FEATURES, vfp,
bb.utils.contains(TUNE_FEATURES, callconvention-hard, -mfloat-abi=hard,
-mfloat-abi=softfp, d), ,d)}
${@bb.utils.contains(TUNE_FEATURES, arm926ejs, -mtune=arm926ej-s, ,
d)}
This is a tricky one. As others have mentioned, this is a tune
parameter, not an arch one and as such the binaries are compatible with
each other although they potentially are compiled differently with
different optimisations.
As such, mixing the feeds is permitted and will not cause any real world
usage problem. As you point out, sstate is much more sensitive to this
kind of change and is correctly deciding the output is different though.
I think my preferred approach would be to have the tune files do
something like:
-mtune=${ARMV5TEDEFAULTTUNE}
and then the user can set ARMV5DEFAULTTUNE to whatever the believe is a
appropriate. This would result in the package feed at least having a
consistent state of one tune and sstate would be happy. It then becomes
a distro policy decision which is what it should be. ARMV5TEDEFAULTTUNE
would default to the current values meaning the distro would then just
do:
ARMV5TEDEFAULTTUNE_poky = xscale
and hence make their decision. Of course the distro could also decide to
split the package architectures up which is equally fine.
Does something like that sound like it would work?
Cheers,
Richard
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/2] Enhancement / bug fixes to the complementary install
On 09/07/2012 03:05 PM, Mark Hatle wrote: This is one bug fix and one enhancement to the complementary install. We have a use where we would like to call the complementary install directly with a set of parameters, the enhancement allows us to do this. The bug fix is specific to the implementation within the RPM rootfs generation. Without the fix, a suboptimal installation is generated and performed. The following changes since commit 0de1827a9601143b090f751ea702fdb65a936b77: classes/mirrors: remove bogus gnutls mirror (2012-09-07 14:51:10 +0100) are available in the git repository at: git://git.yoctoproject.org/poky-contrib mhatle/comp_install http://git.yoctoproject.org/cgit.cgi//log/?h=mhatle/comp_install Mark Hatle (2): image.bbclass: Enable the complementary install to be called w/ globbing params package_rpm.bbclass: Avoid unnecessary installs in complementary pass meta/classes/image.bbclass |4 +++- meta/classes/package_rpm.bbclass |9 - 2 files changed, 11 insertions(+), 2 deletions(-) Merged into OE-Core Thanks Sau! ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH V4] base-files: provide a mechanism to skip creation of the hostname file
On 09/08/2012 06:42 AM, Mark Hatle wrote:
From: Mark Asselstine mark.asselst...@windriver.com
The existence of a /etc/hostname file causes any hostname provided on
the kernel command line or via dhcp to be overwritten by the
initscripts 'init.d/hostname.sh'. This change allows you to set a
value of for 'hostname' which will skip the creation of the
/etc/hostname file by the base-files package.
Signed-off-by: Mark Asselstine mark.asselst...@windriver.com
Signed-off-by: Jason Wessel jason.wes...@windriver.com
Signed-off-by: Mark Hatle mark.ha...@windriver.com
---
meta/recipes-core/base-files/base-files_3.0.14.bb | 14 --
1 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/meta/recipes-core/base-files/base-files_3.0.14.bb
b/meta/recipes-core/base-files/base-files_3.0.14.bb
index 6bab040..e80cff1 100644
--- a/meta/recipes-core/base-files/base-files_3.0.14.bb
+++ b/meta/recipes-core/base-files/base-files_3.0.14.bb
@@ -1,7 +1,7 @@
SUMMARY = Miscellaneous files for the base system.
DESCRIPTION = The base-files package creates the basic system directory structure
and provides a small set of key configuration files for the system.
SECTION = base
-PR = r71
+PR = r72
LICENSE = GPLv2
LIC_FILES_CHKSUM =
file://licenses/GPL-2;md5=94d55d512a9ba36caa9b7df079bae19f
# Removed all license related tasks in this recipe as license.bbclass
@@ -107,10 +107,12 @@ do_install () {
}
do_install_basefilesissue () {
- if [ -n ${MACHINE} -a ${hostname} = openembedded ]; then
- echo ${MACHINE} ${D}${sysconfdir}/hostname
- else
- echo ${hostname} ${D}${sysconfdir}/hostname
+ if [ ${hostname} != ]; then
+ if [ -n ${MACHINE} -a ${hostname} = openembedded ]; then
+ echo ${MACHINE} ${D}${sysconfdir}/hostname
+ else
+ echo ${hostname} ${D}${sysconfdir}/hostname
+ fi
fi
install -m 644 ${WORKDIR}/issue* ${D}${sysconfdir}
@@ -144,5 +146,5 @@ FILES_${PN}-doc = ${docdir} ${datadir}/common-licenses
PACKAGE_ARCH = ${MACHINE_ARCH}
-CONFFILES_${PN} = ${sysconfdir}/fstab ${sysconfdir}/hostname
+CONFFILES_${PN} = ${sysconfdir}/fstab ${@['',
'${sysconfdir}/hostname'][(d.getVar('hostname', True) != '')]}
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/1] Minor fix to qt4 -dbg packages
On 09/07/2012 03:07 PM, Mark Hatle wrote: The following changes since commit 0de1827a9601143b090f751ea702fdb65a936b77: classes/mirrors: remove bogus gnutls mirror (2012-09-07 14:51:10 +0100) are available in the git repository at: git://git.yoctoproject.org/poky-contrib mhatle/qt4 http://git.yoctoproject.org/cgit.cgi//log/?h=mhatle/qt4 Mark Hatle (1): qt4: Update qt4.inc to remove staticdev deps in -dbg packages meta/recipes-qt/qt4/qt4-embedded.inc |2 +- meta/recipes-qt/qt4/qt4-x11-free.inc |2 +- meta/recipes-qt/qt4/qt4.inc |2 +- 3 files changed, 3 insertions(+), 3 deletions(-) Merged into OE-Core Thanks Sau! ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] perl-native: PROVIDE libmodule-build-perl-native for consistency with non-native perl
On 09/09/2012 02:13 AM, Phil Blundell wrote:
This module is, apparently, included in the standard perl distribution
since 5.10.1 or so. The regular perl recipe has had this PROVIDES for a
while but it seems to have been overlooked in the native version.
Signed-off-by: Phil Blundell p...@pbcl.net
---
meta/recipes-devtools/perl/perl-native_5.14.2.bb |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/meta/recipes-devtools/perl/perl-native_5.14.2.bb
b/meta/recipes-devtools/perl/perl-native_5.14.2.bb
index df8f058..9f6a077 100644
--- a/meta/recipes-devtools/perl/perl-native_5.14.2.bb
+++ b/meta/recipes-devtools/perl/perl-native_5.14.2.bb
@@ -9,6 +9,9 @@ PR = r1
LIC_FILES_CHKSUM = file://Copying;md5=2b4c6ffbcfcbdee469f02565f253d81a \
file://Artistic;md5=f921793d03cc6d63ec4b15e9be8fd3f8
+# 5.10.1 has Module::Build built-in
+PROVIDES += libmodule-build-perl-native
+
SRC_URI = http://www.cpan.org/src/5.0/perl-${PV}.tar.gz \
file://Configure-multilib.patch \
file://perl-configpm-switch.patch \
This along with the 2 shadow patches were merged into OE-Core
Thanks
Sau!
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] telepathy-idle: fix parallel build
On 09/10/2012 05:49 AM, Ross Burton wrote: Apply a patch from upstream git, and clean up our other patch so that it applies. [ YOCTO #3056 ] Signed-off-by: Ross Burton ross.bur...@intel.com --- .../build-fix-for-make-j-safety.patch | 39 .../fix-svc-gtk-doc.h-target.patch | 24 +--- .../telepathy/telepathy-idle_0.1.12.bb |5 ++- 3 files changed, 43 insertions(+), 25 deletions(-) create mode 100644 meta/recipes-connectivity/telepathy/telepathy-idle-0.1.12/build-fix-for-make-j-safety.patch Merged into OE-Core Thanks Sau! diff --git a/meta/recipes-connectivity/telepathy/telepathy-idle-0.1.12/build-fix-for-make-j-safety.patch b/meta/recipes-connectivity/telepathy/telepathy-idle-0.1.12/build-fix-for-make-j-safety.patch new file mode 100644 index 000..0aeed09 --- /dev/null +++ b/meta/recipes-connectivity/telepathy/telepathy-idle-0.1.12/build-fix-for-make-j-safety.patch @@ -0,0 +1,39 @@ +From b092172e56393fad70e472afa26df4f886dfdbc0 Mon Sep 17 00:00:00 2001 +From: Dan Winship d...@gnome.org +Date: Fri, 24 Aug 2012 12:19:45 -0400 +Subject: [PATCH] build: fix for make -j safety + +A make rule with multiple (non-pattern) targets just says that each of +those files can be built by the rule, not that the rule builds all of +them at once. So under make -j, extensions/Makefile would run three +copies of glib-ginterface-gen.py at once, which could end up deleting +each others' files and causing a make failure. Fix. + +Signed-off-by: Jonny Lamb jonny.l...@collabora.co.uk + +Upstream-Status: Backport [b092172e56393fad70e472afa26df4f886dfdbc0] +Signed-off-by: Ross Burton ross.bur...@intel.com + +--- + extensions/Makefile.am |5 - + 1 file changed, 4 insertions(+), 1 deletion(-) + +diff --git a/extensions/Makefile.am b/extensions/Makefile.am +index 24efb6e..bb837da 100644 +--- a/extensions/Makefile.am b/extensions/Makefile.am +@@ -42,7 +42,10 @@ extensions.html: _gen/all.xml $(tools_dir)/doc-generator.xsl + $(tools_dir)/doc-generator.xsl \ + $ $@ + +-_gen/svc.c _gen/svc.h _gen/svc-gtk-doc.h: _gen/all.xml \ ++_gen/svc.h: _gen/svc.c ++_gen/svc-gtk-doc.h: _gen/svc.c ++ ++_gen/svc.c: _gen/all.xml \ + $(tools_dir)/glib-ginterface-gen.py + $(AM_V_GEN)$(PYTHON) $(tools_dir)/glib-ginterface-gen.py \ + --filename=_gen/svc --signal-marshal-prefix=_idle_ext \ +-- +1.7.10.4 + diff --git a/meta/recipes-connectivity/telepathy/telepathy-idle-0.1.12/fix-svc-gtk-doc.h-target.patch b/meta/recipes-connectivity/telepathy/telepathy-idle-0.1.12/fix-svc-gtk-doc.h-target.patch index a5efed4..2cd2c78 100644 --- a/meta/recipes-connectivity/telepathy/telepathy-idle-0.1.12/fix-svc-gtk-doc.h-target.patch +++ b/meta/recipes-connectivity/telepathy/telepathy-idle-0.1.12/fix-svc-gtk-doc.h-target.patch @@ -3,7 +3,7 @@ Upstream-Status: Pending Signed-off-by: Constantin Musca constantinx.mu...@intel.com --- a/extensions/Makefile.am +++ b/extensions/Makefile.am -@@ -37,12 +37,12 @@ _gen/all.xml: all.xml $(wildcard $(srcdi +@@ -37,8 +37,8 @@ _gen/all.xml: all.xml $(wildcard $(srcdi --xinclude $(tools_dir)/identity.xsl \ $ $@ @@ -13,25 +13,3 @@ Signed-off-by: Constantin Musca constantinx.mu...@intel.com $(tools_dir)/doc-generator.xsl \ $ $@ --_gen/svc.c _gen/svc.h _gen/svc-gtk-doc.h: _gen/all.xml \ -+_gen/svc.c _gen/svc.h: _gen/all.xml \ - $(tools_dir)/glib-ginterface-gen.py - $(AM_V_GEN)$(PYTHON) $(tools_dir)/glib-ginterface-gen.py \ - --filename=_gen/svc --signal-marshal-prefix=_idle_ext \ a/extensions/Makefile.in -+++ b/extensions/Makefile.in -@@ -585,12 +585,12 @@ _gen/all.xml: all.xml $(wildcard $(srcdi - --xinclude $(tools_dir)/identity.xsl \ - $ $@ - --extensions.html: _gen/all.xml $(tools_dir)/doc-generator.xsl -+extensions.html _gen/svc-gtk-doc.h: _gen/all.xml $(tools_dir)/doc-generator.xsl - $(AM_V_GEN)$(XSLTPROC) $(XSLTPROCFLAGS) \ - $(tools_dir)/doc-generator.xsl \ - $ $@ - --_gen/svc.c _gen/svc.h _gen/svc-gtk-doc.h: _gen/all.xml \ -+_gen/svc.c _gen/svc.h: _gen/all.xml \ - $(tools_dir)/glib-ginterface-gen.py - $(AM_V_GEN)$(PYTHON) $(tools_dir)/glib-ginterface-gen.py \ - --filename=_gen/svc --signal-marshal-prefix=_idle_ext \ diff --git a/meta/recipes-connectivity/telepathy/telepathy-idle_0.1.12.bb b/meta/recipes-connectivity/telepathy/telepathy-idle_0.1.12.bb index c8163e2..c9e8b3b 100644 --- a/meta/recipes-connectivity/telepathy/telepathy-idle_0.1.12.bb +++ b/meta/recipes-connectivity/telepathy/telepathy-idle_0.1.12.bb @@ -5,10 +5,11 @@ DEPENDS = glib-2.0 dbus telepathy-glib openssl LICENSE = LGPLv2.1 LIC_FILES_CHKSUM = file://COPYING;md5=2d5025d4aa3495befef8f17206a5b0a1 \
Re: [OE-core] [PATCH 2/2] gettext: Make gettext 0.16.1 extend native and nativesdk.
On 09/11/2012 01:30 AM, Martin Ertsaas wrote:
gettext 0.16.1 is a GPLv2 version of gettext. Making that extend native and
nativesdk makes sure we use the same version of gettext for compiling internally
as well as in our toolchain.
Signed-off-by: Martin Ertsaas mert...@cisco.com
---
meta/recipes-core/gettext/gettext_0.16.1.bb |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/meta/recipes-core/gettext/gettext_0.16.1.bb
b/meta/recipes-core/gettext/gettext_0.16.1.bb
index fa8a213..00045d5 100644
--- a/meta/recipes-core/gettext/gettext_0.16.1.bb
+++ b/meta/recipes-core/gettext/gettext_0.16.1.bb
@@ -93,3 +93,5 @@ FILES_gettext-runtime-doc = ${mandir}/man1/gettext.* \
do_install_append() {
rm -f ${D}${libdir}/preloadable_libintl.so
}
+
+BBCLASSEXTEND = native nativesdk
Merged into OE-Core
Thanks
Sau!
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] webkit-gtk: work around Make bug by re-running make
On 09/10/2012 09:02 AM, Ross Burton wrote:
GNU make 3.82 has a bug where it drops required dependencies.
https://bugs.webkit.org/show_bug.cgi?id=79498 is the WebKitGTK+
bug, and http://savannah.gnu.org/bugs/?30653 is the GNU Make bug.
Work around this by running make again if it fails just in case the failure is
due to the bug.
Based on a patch by Andreas Müller schnitzelt...@googlemail.com.
[ YOCTO #2816 ]
Signed-off-by: Ross Burton ross.bur...@intel.com
---
meta/recipes-sato/webkit/webkit-gtk_1.8.2.bb | 22 ++
1 file changed, 22 insertions(+)
Merged into OE-Core
Thanks
Sau!
diff --git a/meta/recipes-sato/webkit/webkit-gtk_1.8.2.bb
b/meta/recipes-sato/webkit/webkit-gtk_1.8.2.bb
index cf4129d..8beb6eb 100644
--- a/meta/recipes-sato/webkit/webkit-gtk_1.8.2.bb
+++ b/meta/recipes-sato/webkit/webkit-gtk_1.8.2.bb
@@ -7,6 +7,8 @@ LIC_FILES_CHKSUM =
file://Source/WebCore/rendering/RenderApplet.h;endline=22;md
file://Source/WebKit/gtk/webkit/webkit.h;endline=21;md5=b4fbe9f4a944f1d071dba1d2c76b3351
\
file://Source/JavaScriptCore/parser/Parser.h;endline=23;md5=b57c8a2952a8d0e655988fa0ecb2bf7f
+PR = r1
+
# Choice of language backends - icu has issues on Big Endian machines so use
pango
ICU_LIB = icu
ICU_LIB_powerpc = pango
@@ -77,6 +79,26 @@ do_configure_append() {
done
}
+# A dirty hack for GNU make 3.82 bug which means it drops required
+# dependencies. https://bugs.webkit.org/show_bug.cgi?id=79498 is the WebKitGTK+
+# bug, and http://savannah.gnu.org/bugs/?30653 is the GNU Make bug. This is
+# fixed in Make CVS, so 3.83 won't have this problem.
+do_compile() {
+if [ x$MAKE = x ]; then MAKE=make; fi
+bbnote ${MAKE} ${EXTRA_OEMAKE} $@
+for error_count in 1 2 3; do
+bbnote Attempt $error_count of 3
+exit_code=0
+${MAKE} ${EXTRA_OEMAKE} $@ || exit_code=1
+if [ $exit_code = 0 ]; then
+break
+fi
+done
+if [ ! $exit_code = 0 ]; then
+die oe_runmake failed
+fi
+}
+
do_install_append() {
rmdir ${D}${libexecdir}
}
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/2] A couple of fixes for sanity.bbclass
On 09/11/2012 02:40 AM, Paul Eggleton wrote: The following changes since commit 9f0453c29891e32f8038c4bbc22ada28bfbf818a: lib/oe/sstatesig.py: add signature data query function (2012-09-10 13:03:45 +0100) are available in the git repository at: git://git.openembedded.org/openembedded-core-contrib paule/sanityfixes http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=paule/sanityfixes Paul Eggleton (2): classes/sanity: skip tune checks if machine is invalid classes/sanity: remove obsolete code meta/classes/sanity.bbclass | 19 +-- 1 file changed, 9 insertions(+), 10 deletions(-) Merged into OE-Core Thanks Sau! ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2 0/1] Fix nativesdk-qemu relocation issue
On 09/11/2012 06:55 AM, Laurentiu Palcu wrote: Changes in V2: - bump PR Thanks, Laurentiu The following changes since commit 7250638ec895bc89508711831083d43b9e1e9826: upstream_tracking: Fix format issues (2012-09-10 23:21:12 +0100) are available in the git repository at: git://git.yoctoproject.org/poky-contrib lpalcu/qemu_issue http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=lpalcu/qemu_issue Laurentiu Palcu (1): nativesdk-qemu: fix SDK relocation issue .../qemu/qemu-1.2.0/relocatable_sdk.patch | 34 meta/recipes-devtools/qemu/qemu_1.2.0.bb |6 2 files changed, 40 insertions(+) create mode 100644 meta/recipes-devtools/qemu/qemu-1.2.0/relocatable_sdk.patch Merged into OE-Core Thanks Sau! ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/1] libgnome-keyring: add missing DEPENDS on intltool-native
On 09/11/2012 08:13 AM, jackie.hu...@windriver.com wrote: From: Jackie Huang jackie.hu...@windriver.com The following changes since commit 48169c6bc44c546cecaa06207b6c36da558b81f7: classes/packageinfo: use better method to check if package exists (2012-09-10 21:52:37 +0100) are available in the git repository at: git://git.pokylinux.org/poky-contrib jhuang0/bug3081_libgnome-kering_0911 http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=jhuang0/bug3081_libgnome-kering_0911 Jackie Huang (1): libgnome-keyring: add missing DEPENDS on intltool-native .../recipes-gnome/gnome/libgnome-keyring_2.32.0.bb |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) Merged into OE-Core Thanks Sau! ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v3] sysvinit-inittab_2.88dsf.bb: only run serial checks at boot if we have items to check
On 09/11/2012 10:56 AM, Matthew McClintock wrote:
Right now, we delay running the serial console checks to we boot up. This causes
issues for read only file systems. So, if have not configured any serial ports
to
check via SERIAL_CONSOLES_CHECK we can skip the check at boot. This fixes any
issues with read only file systems and ipk packaging.
Signed-off-by: Matthew McClintock m...@freescale.com
---
v2: bump PR
v3: change a == bashism to =
.../sysvinit/sysvinit-inittab_2.88dsf.bb | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/meta/recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bb
b/meta/recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bb
index 1089edb..5b79caf 100644
--- a/meta/recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bb
+++ b/meta/recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bb
@@ -2,7 +2,7 @@ DESCRIPTION = Inittab for sysvinit
LICENSE = GPLv2
LIC_FILES_CHKSUM =
file://${COREBASE}/meta/files/common-licenses/GPL-2.0;md5=801f80980d171dd6425610833a22dbe6
-PR = r7
+PR = r8
SRC_URI = file://inittab
@@ -54,7 +54,7 @@ EOF
pkg_postinst_${PN} () {
# run this on the target
-if [ x$D == x ]; then
+if [ x$D = x ]; then
tmp=${SERIAL_CONSOLES_CHECK}
for i in $tmp
do
@@ -65,7 +65,11 @@ if [ x$D == x ]; then
done
kill -HUP 1
else
- exit 1
+ if [ ${SERIAL_CONSOLES_CHECK} = ]; then
+ exit 0
+ else
+ exit 1
+ fi
fi
}
Merged to OE-Core
Thanks
Sau!
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] eglibc: Restore ${PN} to before ${PN}-dev in PACKAGES
On 09/11/2012 11:14 AM, Phil Blundell wrote:
Commit 13544fbc6217fee1731a6da1e2cf94901a500842 changed the ordering
of PACKAGES so that ${PN}-dev came before ${PN}. However, this caused
the FILES matching to go wrong if ${libdir} == ${base_libdir}. Fix this
by moving ${PN} ahead of ${PN}-dev once again.
Signed-off-by: Phil Blundell p...@pbcl.net
---
V2: now with high-tech PR goodness
meta/recipes-core/eglibc/eglibc-package.inc |2 +-
meta/recipes-core/eglibc/eglibc_2.16.bb |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-core/eglibc/eglibc-package.inc
b/meta/recipes-core/eglibc/eglibc-package.inc
index edf7a75..adf31de 100644
--- a/meta/recipes-core/eglibc/eglibc-package.inc
+++ b/meta/recipes-core/eglibc/eglibc-package.inc
@@ -17,7 +17,7 @@ python __anonymous () {
# Set this to zero if you don't want ldconfig in the output package
USE_LDCONFIG ?= 1
-PACKAGES = ${PN}-dbg catchsegv sln nscd ldd ${PN}-mtrace ${PN}-utils
eglibc-thread-db ${PN}-pic libcidn libmemusage libsegfault ${PN}-pcprofile libsotruss
${PN}-dev ${PN}-staticdev ${PN}-doc ${PN} eglibc-extra-nss
+PACKAGES = ${PN}-dbg catchsegv sln nscd ldd ${PN}-mtrace ${PN}-utils
eglibc-thread-db ${PN}-pic libcidn libmemusage libsegfault ${PN}-pcprofile libsotruss
${PN} eglibc-extra-nss ${PN}-dev ${PN}-staticdev ${PN}-doc
# The ld.so in this eglibc supports the GNU_HASH
RPROVIDES_${PN} = glibc rtld(GNU_HASH)
diff --git a/meta/recipes-core/eglibc/eglibc_2.16.bb
b/meta/recipes-core/eglibc/eglibc_2.16.bb
index c4bc18c..ffa4d5f 100644
--- a/meta/recipes-core/eglibc/eglibc_2.16.bb
+++ b/meta/recipes-core/eglibc/eglibc_2.16.bb
@@ -3,7 +3,7 @@ require eglibc.inc
SRCREV = 20393
DEPENDS += gperf-native
-PR = r7
+PR = r8
PR_append = +svnr${SRCPV}
EGLIBC_BRANCH=eglibc-2_16
Merged into OE-Core
Thanks
Sau!
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-core v2] valgrind: fix debug info reading error when do memcheck on ppc targets
On Wed, Sep 12, 2012 at 3:20 AM, b19...@freescale.com wrote:
From: Zhenhua Luo b19...@freescale.com
following is the error message:
--2263-- WARNING: Serious error when reading debug info
--2263-- When reading debug info from /lib/ld-2.13.so:
--2263-- Can't make sense of .got section mapping
--2263-- WARNING: Serious error when reading debug info
--2263-- When reading debug info from /home/root/lzh:
--2263-- Can't make sense of .data section mapping
--2263-- WARNING: Serious error when reading debug info
--2263-- When reading debug info from
/usr/lib/valgrind/vgpreload_core-ppc32-linux.so:
--2263-- Can't make sense of .data section mapping
--2263-- WARNING: Serious error when reading debug info
--2263-- When reading debug info from
/usr/lib/valgrind/vgpreload_memcheck-ppc32-linux.so:
--2263-- Can't make sense of .data section mapping
--2263-- WARNING: Serious error when reading debug info
--2263-- When reading debug info from /lib/libc-2.13.so:
--2263-- Can't make sense of .data section mapping
Signed-off-by: Zhenhua Luo b19...@freescale.com
Scott,
I've added this to my denzil branch. Please pick it up for denzil-next
when you are working on it again.
http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=mattsm/denzil
Thanks,
Matthew
---
...ind-3.7.0-fix-error-of-reading-debug-info.patch | 33
meta/recipes-devtools/valgrind/valgrind_3.7.0.bb |5 ++-
2 files changed, 37 insertions(+), 1 deletion(-)
create mode 100644
meta/recipes-devtools/valgrind/valgrind-3.7.0/valgrind-3.7.0-fix-error-of-reading-debug-info.patch
diff --git
a/meta/recipes-devtools/valgrind/valgrind-3.7.0/valgrind-3.7.0-fix-error-of-reading-debug-info.patch
b/meta/recipes-devtools/valgrind/valgrind-3.7.0/valgrind-3.7.0-fix-error-of-reading-debug-info.patch
new file mode 100644
index 000..b1626f0
--- /dev/null
+++
b/meta/recipes-devtools/valgrind/valgrind-3.7.0/valgrind-3.7.0-fix-error-of-reading-debug-info.patch
@@ -0,0 +1,33 @@
+Upstream-Status: Pending
+
+fix debug info reading error when do memcheck on ppc targets
+following is the error message:
+--2263-- WARNING: Serious error when reading debug info
+--2263-- When reading debug info from /lib/ld-2.13.so:
+--2263-- Can't make sense of .got section mapping
+--2263-- WARNING: Serious error when reading debug info
+--2263-- When reading debug info from /home/root/lzh:
+--2263-- Can't make sense of .data section mapping
+--2263-- WARNING: Serious error when reading debug info
+--2263-- When reading debug info from
/usr/lib/valgrind/vgpreload_core-ppc32-linux.so:
+--2263-- Can't make sense of .data section mapping
+--2263-- WARNING: Serious error when reading debug info
+--2263-- When reading debug info from
/usr/lib/valgrind/vgpreload_memcheck-ppc32-linux.so:
+--2263-- Can't make sense of .data section mapping
+--2263-- WARNING: Serious error when reading debug info
+--2263-- When reading debug info from /lib/libc-2.13.so:
+--2263-- Can't make sense of .data section mapping
+
+Signed-off-by: Zhenhua Luo b19...@freescale.com
+
+--- a/coregrind/m_debuginfo/readelf.c 2012-09-11 21:45:36.696462313 -0500
b/coregrind/m_debuginfo/readelf.c 2012-09-11 21:45:49.913463615 -0500
+@@ -1539,7 +1539,7 @@
+ phdr-p_offset di-fsm.rw_map_foff +
di-fsm.rw_map_size
+ phdr-p_offset + phdr-p_filesz
+= di-fsm.rw_map_foff + di-fsm.rw_map_size
+- (phdr-p_flags (PF_R | PF_W | PF_X)) == (PF_R | PF_W))
{
++ (phdr-p_flags (PF_R | PF_W | PF_X)) = (PF_R | PF_W))
{
+if (n_rw == N_RX_RW_AREAS) {
+ ML_(symerr)(di, True,
+ N_RX_RW_AREAS is too low;
diff --git a/meta/recipes-devtools/valgrind/valgrind_3.7.0.bb
b/meta/recipes-devtools/valgrind/valgrind_3.7.0.bb
index abda7a6..651ae60 100644
--- a/meta/recipes-devtools/valgrind/valgrind_3.7.0.bb
+++ b/meta/recipes-devtools/valgrind/valgrind_3.7.0.bb
@@ -9,7 +9,7 @@ LIC_FILES_CHKSUM =
file://COPYING;md5=c46082167a314d785d012a244748d803 \
X11DEPENDS = virtual/libx11
DEPENDS = ${@base_contains('DISTRO_FEATURES', 'x11', '${X11DEPENDS}', '',
d)}
-PR = r5
+PR = r6
SRC_URI = http://www.valgrind.org/downloads/valgrind-${PV}.tar.bz2 \
file://fix_issue_caused_by_ccache.patch \
@@ -21,6 +21,9 @@ SRC_URI =
http://www.valgrind.org/downloads/valgrind-${PV}.tar.bz2 \
file://configure-with-glibc-2.16.patch \
+SRC_URI_append_powerpc =
file://valgrind-3.7.0-fix-error-of-reading-debug-info.patch
+SRC_URI_append_powerpc64 =
file://valgrind-3.7.0-fix-error-of-reading-debug-info.patch
+
[OE-core] [for-denzil] eglibc_2.15: make patch only for Freescale machines
It's only Freescale machines that don't imlpement fsqrt, we don't want
this to effect others.
This patch was only added after the last release of denzil, so it's not
present in the release yet. Also, 2.15 is removed from master so it
should only apply to denzil branch
Signed-off-by: Matthew McClintock m...@freescale.com
---
meta/recipes-core/eglibc/eglibc_2.15.bb |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-core/eglibc/eglibc_2.15.bb
b/meta/recipes-core/eglibc/eglibc_2.15.bb
index dc2a546..41f39b2 100644
--- a/meta/recipes-core/eglibc/eglibc_2.15.bb
+++ b/meta/recipes-core/eglibc/eglibc_2.15.bb
@@ -3,7 +3,7 @@ require eglibc.inc
SRCREV = 17386
DEPENDS += gperf-native
-PR = r8
+PR = r9
PR_append = +svnr${SRCPV}
EGLIBC_BRANCH=eglibc-2_15
@@ -23,13 +23,14 @@ SRC_URI =
svn://www.eglibc.org/svn/branches/;module=${EGLIBC_BRANCH};proto=http
file://ppc-sqrt_finite.patch \
file://GLRO_dl_debug_mask.patch \
file://initgroups_keys.patch \
- file://glibc.no_sqrt.patch \
LIC_FILES_CHKSUM = file://LICENSES;md5=98a1128c4b58120182cbea3b1752d8b9 \
file://COPYING;md5=393a5ca445f6965873eca0259a17f833 \
file://posix/rxspencer/COPYRIGHT;md5=dc5485bb394a13b2332ec1c785f5d83a \
file://COPYING.LIB;md5=bbb461211a33b134d42ed5ee802b37ff
+SRC_URI_append_fslmachine = file://glibc.no_sqrt.patch
+
SRC_URI_append_virtclass-nativesdk = file://ld-search-order.patch
S = ${WORKDIR}/${EGLIBC_BRANCH}/libc
B = ${WORKDIR}/build-${TARGET_SYS}
--
1.7.9.7
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] classes/packageinfo: use better method to check if package exists
On 09/10/2012 05:58 AM, Paul Eggleton wrote:
Instead of using a rather error-prone method of looking for output
package files in order to determine if a package got created, use the
.packaged file within pkgdata.
This fixes two separate issues:
* Some packages apparently not being found by this code e.g. all
apm/apmd packages when using ipk packaging.
* Buggy implementation of this checking code which triggered an
exception during the event handler if PKGV was overridden on a
per-package basis (as it is with external-sourcery-toolchain), which
blocked Hob from completing parsing at 99% - fixes [YOCTO #2651].
Signed-off-by: Paul Eggleton paul.eggle...@linux.intel.com
---
meta/classes/packageinfo.bbclass | 34 --
1 file changed, 8 insertions(+), 26 deletions(-)
Merged into OE-Core
Thanks
Sau!
diff --git a/meta/classes/packageinfo.bbclass b/meta/classes/packageinfo.bbclass
index 26cce60..bd7b249 100644
--- a/meta/classes/packageinfo.bbclass
+++ b/meta/classes/packageinfo.bbclass
@@ -14,32 +14,14 @@ python packageinfo_handler () {
for root, dirs, files in os.walk(pkgdata_dir):
for pkgname in files:
if pkgname.endswith('.packaged'):
-continue
-sdata = oe.packagedata.read_pkgdatafile(root + pkgname)
-sdata['PKG'] = pkgname
-pkgrename = sdata['PKG_%s' % pkgname]
-pkgv = sdata['PKGV'].replace('-', '+')
-pkgr = sdata['PKGR']
-# We found there are some renaming issue with certain
architecture.
-# For example, armv7a-vfp-neon, it will use armv7a in
the rpm file. This is the workaround for it.
-arch_tmp = arch.split('-')[0]
-if os.path.exists(deploy_dir + '/' + arch + '/' + \
- pkgname + '-' + pkgv + '-' + pkgr +
'.' + arch + '.' + packaging) or \
- os.path.exists(deploy_dir + '/' + arch + '/' + \
- pkgname + '-' + pkgv + '-' + pkgr +
'.' + arch_tmp + '.' + packaging) or \
- os.path.exists(deploy_dir + '/' + arch + '/' + \
- pkgrename + '-' + pkgv + '-' + pkgr
+ '.' + arch + '.' + packaging) or \
- os.path.exists(deploy_dir + '/' + arch + '/' + \
- pkgrename + '-' + pkgv + '-' + pkgr
+ '.' + arch_tmp + '.' + packaging) or \
- os.path.exists(deploy_dir + '/' + arch + '/' + \
- pkgname + '_' + pkgv + '-' + pkgr +
'_' + arch + '.' + packaging) or \
- os.path.exists(deploy_dir + '/' + arch + '/' + \
- pkgname + '_' + pkgv + '-' + pkgr +
'_' + arch_tmp + '.' + packaging) or \
- os.path.exists(deploy_dir + '/' + arch + '/' + \
- pkgrename + '_' + pkgv + '-' + pkgr
+ '_' + arch + '.' + packaging) or \
- os.path.exists(deploy_dir + '/' + arch + '/' + \
- pkgrename + '_' + pkgv + '-' + pkgr
+ '_' + arch_tmp + '.' + packaging):
-pkginfolist.append(sdata)
+pkgname = pkgname[:-9]
+pkgdatafile = root + pkgname
+try:
+sdata =
oe.packagedata.read_pkgdatafile(pkgdatafile)
+sdata['PKG'] = pkgname
+pkginfolist.append(sdata)
+except Exception as e:
+bb.warn(Failed to read pkgdata file %s: %s:
%s % (pkgdatafile, e.__class__, str(e)))
bb.event.fire(bb.event.PackageInfo(pkginfolist), e.data)
}
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] autotools.bbclass: Add functionality to force a clean of ${B} when reconfiguring (and ${S} != ${B})
On Wed, Sep 12, 2012 at 9:16 AM, Richard Purdie
richard.pur...@linuxfoundation.org wrote:
On Tue, 2012-09-11 at 19:01 +, McClintock Matthew-B29882 wrote:
On Tue, Sep 11, 2012 at 9:22 AM, Richard Purdie
richard.pur...@linuxfoundation.org wrote:
Unfortunately whilst rerunning configure and make against a project will
mostly
work there are situations where it does not correctly do the right thing.
In particular, eglibc and gcc will fail out with errors where settings
do not match a previously built configuration. It could be argued they are
broken but the situation is what it is. There is the possibility of more
subtle
errors too.
This patch adds removal of the build directory (${B}) when configure is
rerunning, the sstate checksum for do_configure has changed and ${S} !=
${B}.
We could simply use a stamp but saving out the previous configuration
checksum
adds some data at no real overhead.
If we find there are things where we want to disable this behaviour with
CONFIGURESTAMPFILE = in the recipe, or users could disable it globally.
[YOCTO #2774]
[YOCTO #2848]
This is particularly helpful for eglibc and gcc which use split builds by
default and
are a particular source of reconfigure type problems.
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
Is it feasible to back port this to denzil? I've encountered what I
think are similar issues reconfiguring gcc for example.
One of the bugs above is open against denzil and the issue certainly
exists there. The patch should apply equally well there.
I'd suggest we let this settle in master for a week or two and then add
it to the backport queue if no problems arise.
Cc'ing Scott so he's aware of this.
I've added this to my denzil branch and will start doing build testing.
http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=mattsm/denzil
-M
Cheers,
Richard
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/6] classes/license: various bugfixes and improvements
On 09/10/2012 06:13 PM, Vladimir Zapolskiy wrote:
This trivial set of changes fixes several bugs including:
* check license.manifest for multiple records about the same
* put precise information about licensing into license.manifest
* specify licensing of packages, where info is in form of LICENSE_${pkg}
Also the change set has some intention to improve performance and
source code readability.
Vladimir Zapolskiy (6):
classes/license: define LICENSE_MANIFEST variable
classes/license: check license manifest for double records
classes/license: remove redundant nested if statements
classes/license: account LICENSE_${pkg} values in manifest
classes/license: correct license info in lisense.manifest
classes/license: place all found licenses on one line
meta/classes/license.bbclass | 55 ++
1 file changed, 34 insertions(+), 21 deletions(-)
Merged into OE-Core
Thanks
Sau!
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/1 V2] package_rpm.bbclass: fix the arch (replace - with _)
On 09/10/2012 12:58 AM, Robert Yang wrote: Changes of V2: * Replace - with _ for sat-solver_git.bb Test info: MACHINE = beagleboard/mpc8315e-rdb/qemux86 PACKAGE_CLASSES = package_rpm $ bitbake core-image-minimal core-image-sato meta-toolchain \ meta-toolchain-sdk adt-installer meta-ide-support $ bitbake package-index $ runqemu qemux86 (when MACHINE=qemux86) All of them are OK. Note: The nativesdk's arch would be x86_64_nativesdk or i686_nativesdk (it was x86_64 or i686 in the past) when use rpm. // Robert The following changes since commit 5343cdb20ee56a8b507733c637dcc2466ae13288: bitbake: fetch2: replace double slashes in paths in encodeurl() (2012-09-07 14:50:04 +0100) are available in the git repository at: git://git.pokylinux.org/poky-contrib robert/rpmarch http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=robert/rpmarch Robert Yang (1): package_rpm.bbclass: fix the arch (replace - with _) meta/classes/package_rpm.bbclass | 10 +- meta/recipes-extended/sat-solver/sat-solver_git.bb | 2 +- 2 files changed, 6 insertions(+), 6 deletions(-) I think this needs rebasing, can you resend please. Sau! ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/5] Package upgrades
On 09/11/2012 08:19 AM, Constantin Musca wrote:
This is another set of package upgrades compiled on all architectures
and tested using core-image-sato.
The following changes since commit 7250638ec895bc89508711831083d43b9e1e9826:
upstream_tracking: Fix format issues (2012-09-10 23:21:12 +0100)
are available in the git repository at:
git://git.yoctoproject.org/poky-contrib cmuscax/upgrades
http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=cmuscax/upgrades
Constantin Musca (5):
boost: upgrade to 1.51.0
glew: upgrade to 1.9.0
libexif: upgrade to 0.6.21
sysstat: upgrade to 10.1.1
Merged the above 4 into OE-Core
openssl: upgrade to 1.0.1c
I had some trouble with this one, there are a number of other recipes
that depend on openssl and need PR bumps and more testing, particularly
git had an issue with this patch. It's probably a good thing to have but
might be just a little to late in the cycle given it's used by other tools.
Thanks
Sau!
.../openssl-1.0.0j/debian/debian-targets.patch | 54 -
.../openssl/openssl-1.0.0j/debian/pic.patch| 242
.../configure-targets.patch|0
.../debian/block_digicert_malaysia.patch | 29 +++
.../openssl-1.0.1c/debian/block_diginotar.patch| 67 ++
.../debian/c_rehash-compat.patch | 15 +-
.../openssl-1.0.1c/debian/c_rehash-multi.patch | 89 +++
.../debian/ca.patch|1 +
.../openssl-1.0.1c/debian/config-hurd.patch| 18 ++
.../openssl-1.0.1c/debian/debian-targets.patch | 67 ++
.../openssl-1.0.1c/debian/default_bits.patch | 14 ++
.../openssl/openssl-1.0.1c/debian/dgst_hmac.patch | 54 +
.../openssl/openssl-1.0.1c/debian/gnu_source.patch | 27 +++
.../debian/libdoc-manpgs-pod-spell.patch | 239 +++
.../openssl-1.0.1c/debian/libssl-misspell.patch| 14 ++
.../debian/make-targets.patch | 13 +-
.../debian/man-dir.patch |1 +
.../debian/man-section.patch |1 +
.../debian/no-rpath.patch |1 +
.../debian/no-symbolic.patch |1 +
.../debian/openssl-pod-misspell.patch | 125 ++
.../openssl/openssl-1.0.1c/debian/pic.patch| 178 ++
.../openssl/openssl-1.0.1c/debian/pkcs12-doc.patch | 39
.../openssl-1.0.1c/debian/pod_ec.misspell.patch| 14 ++
.../debian/pod_pksc12.misspell.patch | 14 ++
.../openssl-1.0.1c/debian/pod_req_misspell2.patch | 15 ++
.../debian/pod_s_server.misspell.patch | 14 ++
.../debian/pod_x509setflags.misspell.patch | 14 ++
.../openssl/openssl-1.0.1c/debian/rehash-crt.patch | 36 +++
.../openssl/openssl-1.0.1c/debian/rehash_pod.patch | 63 +
.../openssl-1.0.1c/debian/renegiotate_tls.patch| 13 ++
.../openssl-1.0.1c/debian/shared-lib-ext.patch | 17 ++
.../openssl/openssl-1.0.1c/debian/stddef.patch | 15 ++
.../openssl/openssl-1.0.1c/debian/valgrind.patch | 23 ++
.../debian/version-script.patch| 203 ++--
.../engines-install-in-libdir-ssl.patch|0
.../{openssl-1.0.0j = openssl-1.0.1c}/find.pl |0
.../oe-ldflags.patch |0
.../openssl-fix-link.patch |0
.../openssl_fix_for_x32.patch | 38 ++-
.../shared-libs.patch | 33 +--
.../{openssl_1.0.0j.bb = openssl_1.0.1c.bb} | 37 ++-
meta/recipes-extended/sysstat/sysstat_10.0.5.bb|8 -
meta/recipes-extended/sysstat/sysstat_10.1.1.bb|8 +
.../glew/{glew_1.7.0.bb = glew_1.9.0.bb} |6 +-
.../boost/{boost_1.50.0.bb = boost_1.51.0.bb} |4 +-
.../{libexif_0.6.20.bb = libexif_0.6.21.bb} |4 +-
47 files changed, 1465 insertions(+), 403 deletions(-)
delete mode 100644
meta/recipes-connectivity/openssl/openssl-1.0.0j/debian/debian-targets.patch
delete mode 100644
meta/recipes-connectivity/openssl/openssl-1.0.0j/debian/pic.patch
rename meta/recipes-connectivity/openssl/{openssl-1.0.0j =
openssl-1.0.1c}/configure-targets.patch (100%)
create mode 100644
meta/recipes-connectivity/openssl/openssl-1.0.1c/debian/block_digicert_malaysia.patch
create mode 100644
meta/recipes-connectivity/openssl/openssl-1.0.1c/debian/block_diginotar.patch
rename meta/recipes-connectivity/openssl/{openssl-1.0.0j =
openssl-1.0.1c}/debian/c_rehash-compat.patch (77%)
create mode 100644
meta/recipes-connectivity/openssl/openssl-1.0.1c/debian/c_rehash-multi.patch
rename meta/recipes-connectivity/openssl/{openssl-1.0.0j =
openssl-1.0.1c}/debian/ca.patch (93%)
create mode 100644
Re: [OE-core] [PATCH 0/3] recipes-rt: Update rt-tests, hwlatdetect, and core-image-rt images
On 09/11/2012 09:17 PM, Darren Hart wrote:
These changes have been tested on the meta-intel sys940x BSP. cyclictest and
hwlatdetect run successfully.
The following changes since commit 48169c6bc44c546cecaa06207b6c36da558b81f7:
classes/packageinfo: use better method to check if package exists
(2012-09-10 21:52:37 +0100)
are available in the git repository at:
git://git.yoctoproject.org/user-contrib/dvhart/oe-core dvhart/rt-tests
http://git.yoctoproject.org/cgit.cgi/user-contrib/dvhart/oe-core/log/?h=dvhart/rt-tests
Darren Hart (3):
rt-tests: Update to 0.84, use the kernel.org git repository
rt-tests: Add hwlatdetect package
rt: Add hwlatdetect to rt images
meta/recipes-rt/images/core-image-rt-sdk.bb| 2 +-
meta/recipes-rt/images/core-image-rt.bb| 2 +-
...1-rt-tests-Allow-for-user-specified-PYLIB.patch | 35 +
...02-rt-tests-Break-out-install_hwlatdetect.patch | 68 +
meta/recipes-rt/rt-tests/hwlatdetect_0.84.bb | 24 ++
.../makefile-support-user-cflags-ldflags.patch | 89 --
meta/recipes-rt/rt-tests/rt-tests.inc | 18 +
.../{rt-tests_0.83.bb = rt-tests_0.84.bb} | 18 +
8 files changed, 151 insertions(+), 105 deletions(-)
create mode 100644
meta/recipes-rt/rt-tests/files/0001-rt-tests-Allow-for-user-specified-PYLIB.patch
create mode 100644
meta/recipes-rt/rt-tests/files/0002-rt-tests-Break-out-install_hwlatdetect.patch
create mode 100644 meta/recipes-rt/rt-tests/hwlatdetect_0.84.bb
delete mode 100644
meta/recipes-rt/rt-tests/rt-tests-0.83/makefile-support-user-cflags-ldflags.patch
create mode 100644 meta/recipes-rt/rt-tests/rt-tests.inc
rename meta/recipes-rt/rt-tests/{rt-tests_0.83.bb = rt-tests_0.84.bb} (61%)
Merged into OE-Core
Thanks
Sau!
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/2] mesa-xlib: remove, it serves no useful purpose
On 09/12/2012 03:23 AM, Ross Burton wrote:
Signed-off-by: Ross Burton ross.bur...@intel.com
---
meta/recipes-graphics/mesa/mesa-xlib.inc |1 -
meta/recipes-graphics/mesa/mesa-xlib_8.0.4.bb |5 -
meta/recipes-graphics/mesa/mesa-xlib_git.bb |8
3 files changed, 14 deletions(-)
delete mode 100644 meta/recipes-graphics/mesa/mesa-xlib.inc
delete mode 100644 meta/recipes-graphics/mesa/mesa-xlib_8.0.4.bb
delete mode 100644 meta/recipes-graphics/mesa/mesa-xlib_git.bb
Merged this and the mesa-dri patch to OE-Core
Thanks
Sau!
diff --git a/meta/recipes-graphics/mesa/mesa-xlib.inc
b/meta/recipes-graphics/mesa/mesa-xlib.inc
deleted file mode 100644
index b720e14..000
--- a/meta/recipes-graphics/mesa/mesa-xlib.inc
+++ /dev/null
@@ -1 +0,0 @@
-EXTRA_OECONF += --with-driver=xlib --without-gallium-drivers
diff --git a/meta/recipes-graphics/mesa/mesa-xlib_8.0.4.bb
b/meta/recipes-graphics/mesa/mesa-xlib_8.0.4.bb
deleted file mode 100644
index a89640e..000
--- a/meta/recipes-graphics/mesa/mesa-xlib_8.0.4.bb
+++ /dev/null
@@ -1,5 +0,0 @@
-require mesa-common.inc
-require mesa-${PV}.inc
-require mesa-xlib.inc
-PR = ${INC_PR}.2
-
diff --git a/meta/recipes-graphics/mesa/mesa-xlib_git.bb
b/meta/recipes-graphics/mesa/mesa-xlib_git.bb
deleted file mode 100644
index 6647120..000
--- a/meta/recipes-graphics/mesa/mesa-xlib_git.bb
+++ /dev/null
@@ -1,8 +0,0 @@
-require mesa-common.inc
-require mesa-git.inc
-require mesa-xlib.inc
-
-# this needs to be lower than -1 because all mesa-dri have -1 and git version
has highest PV, but shouldn't be default
-DEFAULT_PREFERENCE = -2
-
-PR = ${INC_PR}.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] gst-plugins-good: fix compile error with recent linux-libc-headers
On 09/05/2012 10:50 AM, Andreas Müller wrote: With linux-libc-headers-3.5.0 (for tests) the error message was: | gstv4l2bufferpool.c: In function 'gst_v4l2_buffer_new': | gstv4l2bufferpool.c:184:3: error: 'struct v4l2_buffer' has no member named 'input' Signed-off-by: Andreas Müller schnitzelt...@googlemail.com --- ...ild-with-recent-kernels-the-v4l2_buffer-i.patch | 33 .../gstreamer/gst-plugins-good_0.10.31.bb |4 ++- 2 files changed, 36 insertions(+), 1 deletions(-) create mode 100644 meta/recipes-multimedia/gstreamer/gst-plugins-good-0.10.31/0001-v4l2-fix-build-with-recent-kernels-the-v4l2_buffer-i.patch Merged into OE-Core Thanks Sau! diff --git a/meta/recipes-multimedia/gstreamer/gst-plugins-good-0.10.31/0001-v4l2-fix-build-with-recent-kernels-the-v4l2_buffer-i.patch b/meta/recipes-multimedia/gstreamer/gst-plugins-good-0.10.31/0001-v4l2-fix-build-with-recent-kernels-the-v4l2_buffer-i.patch new file mode 100644 index 000..6456d3c --- /dev/null +++ b/meta/recipes-multimedia/gstreamer/gst-plugins-good-0.10.31/0001-v4l2-fix-build-with-recent-kernels-the-v4l2_buffer-i.patch @@ -0,0 +1,33 @@ +From 12d18fe4e98e7c232d59b56d529a0521f293fe6d Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Andreas=20M=C3=BCller?= schnitzelt...@googlemail.com +Date: Wed, 5 Sep 2012 18:54:42 +0200 +Subject: [PATCH] v4l2: fix build with recent kernels, the v4l2_buffer input + field was removed +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +Upstream-Status: Backport + +[1] http://cgit.freedesktop.org/gstreamer/gst-plugins-good/commit/?id=9f2aa8d47f835ea155aaf635f618c0fc1ca87012 + +Signed-off-by: Andreas Müller schnitzelt...@googlemail.com +--- + sys/v4l2/gstv4l2bufferpool.c |1 - + 1 files changed, 0 insertions(+), 1 deletions(-) + +diff --git a/sys/v4l2/gstv4l2bufferpool.c b/sys/v4l2/gstv4l2bufferpool.c +index b81c6a4..51cc0ce 100644 +--- a/sys/v4l2/gstv4l2bufferpool.c b/sys/v4l2/gstv4l2bufferpool.c +@@ -181,7 +181,6 @@ gst_v4l2_buffer_new (GstV4l2BufferPool * pool, guint index, GstCaps * caps) + GST_LOG_OBJECT (pool-v4l2elem, MMAP offset: %u, + ret-vbuffer.m.offset); + GST_LOG_OBJECT (pool-v4l2elem, length:%u, ret-vbuffer.length); +- GST_LOG_OBJECT (pool-v4l2elem, input: %u, ret-vbuffer.input); + + data = (guint8 *) v4l2_mmap (0, ret-vbuffer.length, + PROT_READ | PROT_WRITE, MAP_SHARED, pool-video_fd, +-- +1.7.6.5 + diff --git a/meta/recipes-multimedia/gstreamer/gst-plugins-good_0.10.31.bb b/meta/recipes-multimedia/gstreamer/gst-plugins-good_0.10.31.bb index ac63f94..abcd836 100644 --- a/meta/recipes-multimedia/gstreamer/gst-plugins-good_0.10.31.bb +++ b/meta/recipes-multimedia/gstreamer/gst-plugins-good_0.10.31.bb @@ -7,10 +7,12 @@ LIC_FILES_CHKSUM = file://COPYING;md5=a6f89e2100d9b6cdffcea4f398e37343 \ DEPENDS += gst-plugins-base gconf cairo jpeg libpng gtk+ zlib libid3tag flac \ speex libsoup-2.4 pulseaudio -PR = r2 +PR = r3 inherit gettext gconf +SRC_URI += file://0001-v4l2-fix-build-with-recent-kernels-the-v4l2_buffer-i.patch + EXTRA_OECONF += --disable-aalib --disable-esd --disable-shout2 --disable-libcaca --disable-hal --without-check \ --disable-orc ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-core v2] valgrind: fix debug info reading error when do memcheck on ppc targets
On 09/12/2012 01:20 AM, b19...@freescale.com wrote:
From: Zhenhua Luo b19...@freescale.com
following is the error message:
--2263-- WARNING: Serious error when reading debug info
--2263-- When reading debug info from /lib/ld-2.13.so:
--2263-- Can't make sense of .got section mapping
--2263-- WARNING: Serious error when reading debug info
--2263-- When reading debug info from /home/root/lzh:
--2263-- Can't make sense of .data section mapping
--2263-- WARNING: Serious error when reading debug info
--2263-- When reading debug info from
/usr/lib/valgrind/vgpreload_core-ppc32-linux.so:
--2263-- Can't make sense of .data section mapping
--2263-- WARNING: Serious error when reading debug info
--2263-- When reading debug info from
/usr/lib/valgrind/vgpreload_memcheck-ppc32-linux.so:
--2263-- Can't make sense of .data section mapping
--2263-- WARNING: Serious error when reading debug info
--2263-- When reading debug info from /lib/libc-2.13.so:
--2263-- Can't make sense of .data section mapping
Signed-off-by: Zhenhua Luo b19...@freescale.com
---
...ind-3.7.0-fix-error-of-reading-debug-info.patch | 33
meta/recipes-devtools/valgrind/valgrind_3.7.0.bb |5 ++-
2 files changed, 37 insertions(+), 1 deletion(-)
create mode 100644
meta/recipes-devtools/valgrind/valgrind-3.7.0/valgrind-3.7.0-fix-error-of-reading-debug-info.patch
Merged into OE-Core
Thanks
Sau!
diff --git
a/meta/recipes-devtools/valgrind/valgrind-3.7.0/valgrind-3.7.0-fix-error-of-reading-debug-info.patch
b/meta/recipes-devtools/valgrind/valgrind-3.7.0/valgrind-3.7.0-fix-error-of-reading-debug-info.patch
new file mode 100644
index 000..b1626f0
--- /dev/null
+++
b/meta/recipes-devtools/valgrind/valgrind-3.7.0/valgrind-3.7.0-fix-error-of-reading-debug-info.patch
@@ -0,0 +1,33 @@
+Upstream-Status: Pending
+
+fix debug info reading error when do memcheck on ppc targets
+following is the error message:
+--2263-- WARNING: Serious error when reading debug info
+--2263-- When reading debug info from /lib/ld-2.13.so:
+--2263-- Can't make sense of .got section mapping
+--2263-- WARNING: Serious error when reading debug info
+--2263-- When reading debug info from /home/root/lzh:
+--2263-- Can't make sense of .data section mapping
+--2263-- WARNING: Serious error when reading debug info
+--2263-- When reading debug info from
/usr/lib/valgrind/vgpreload_core-ppc32-linux.so:
+--2263-- Can't make sense of .data section mapping
+--2263-- WARNING: Serious error when reading debug info
+--2263-- When reading debug info from
/usr/lib/valgrind/vgpreload_memcheck-ppc32-linux.so:
+--2263-- Can't make sense of .data section mapping
+--2263-- WARNING: Serious error when reading debug info
+--2263-- When reading debug info from /lib/libc-2.13.so:
+--2263-- Can't make sense of .data section mapping
+
+Signed-off-by: Zhenhua Luo b19...@freescale.com
+
+--- a/coregrind/m_debuginfo/readelf.c 2012-09-11 21:45:36.696462313 -0500
b/coregrind/m_debuginfo/readelf.c 2012-09-11 21:45:49.913463615 -0500
+@@ -1539,7 +1539,7 @@
+ phdr-p_offset di-fsm.rw_map_foff + di-fsm.rw_map_size
+ phdr-p_offset + phdr-p_filesz
+= di-fsm.rw_map_foff + di-fsm.rw_map_size
+- (phdr-p_flags (PF_R | PF_W | PF_X)) == (PF_R | PF_W)) {
++ (phdr-p_flags (PF_R | PF_W | PF_X)) = (PF_R | PF_W)) {
+if (n_rw == N_RX_RW_AREAS) {
+ ML_(symerr)(di, True,
+ N_RX_RW_AREAS is too low;
diff --git a/meta/recipes-devtools/valgrind/valgrind_3.7.0.bb
b/meta/recipes-devtools/valgrind/valgrind_3.7.0.bb
index abda7a6..651ae60 100644
--- a/meta/recipes-devtools/valgrind/valgrind_3.7.0.bb
+++ b/meta/recipes-devtools/valgrind/valgrind_3.7.0.bb
@@ -9,7 +9,7 @@ LIC_FILES_CHKSUM =
file://COPYING;md5=c46082167a314d785d012a244748d803 \
X11DEPENDS = virtual/libx11
DEPENDS = ${@base_contains('DISTRO_FEATURES', 'x11', '${X11DEPENDS}', '',
d)}
-PR = r5
+PR = r6
SRC_URI = http://www.valgrind.org/downloads/valgrind-${PV}.tar.bz2 \
file://fix_issue_caused_by_ccache.patch \
@@ -21,6 +21,9 @@ SRC_URI =
http://www.valgrind.org/downloads/valgrind-${PV}.tar.bz2 \
file://configure-with-glibc-2.16.patch \
+SRC_URI_append_powerpc =
file://valgrind-3.7.0-fix-error-of-reading-debug-info.patch
+SRC_URI_append_powerpc64 =
file://valgrind-3.7.0-fix-error-of-reading-debug-info.patch
+
SRC_URI[md5sum] = a855fda56edf05614f099dca316d1775
SRC_URI[sha256sum] =
5d62c0330f1481fe2c593249192fa68ff454c19c34343978cc9ce91aa324cbf6
___
Openembedded-core mailing list
Re: [OE-core] [PATCH] kernel: remove unused 'etc' directory
I assume this patch is for Denzil? It seems that the current OE-Core
master has etc in that list.
Please confirm
Sau!
On 09/12/2012 06:41 AM, Mark Asselstine wrote:
Along with checks to remove empty modprobe.d and modules-load.d
directories we can add a similar check and removal of the etc
directory. This will avoid warnings by the sanity checker.
Signed-off-by: Mark Asselstine mark.asselst...@windriver.com
CC: Bruce Ashfield bruce.ashfi...@windriver.com
---
There is some concern that removing this directory could cause issues
if folks are adding to etc in a bbappend and not checking for and
creating this directory. I don't believe this is an issue as if you
want to add something to etc it should be done as part of a
populate_packages_prepend or earlier since there are sanity checks run
as part of populate_packages, so the removal here is being done at the
latest possible point in the process (populate_packages_prepend in a
bbappend will run before the populate_packages_prepend in
kernel.bbclass).
meta/classes/kernel.bbclass |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 5e04fda..decf6f5 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -468,7 +468,7 @@ python populate_packages_prepend () {
# avoid warnings. removedirs only raises an OSError if an empty
# directory cannot be removed.
dvar = d.getVar('PKGD', True)
-for dir in [%s/etc/modprobe.d % (dvar), %s/etc/modules-load.d %
(dvar)]:
+for dir in [%s/etc/modprobe.d % (dvar), %s/etc/modules-load.d % (dvar),
%s/etc/ % (dvar)]:
if len(os.listdir(dir)) == 0:
os.rmdir(dir)
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] kernel: remove unused 'etc' directory
On September 12, 2012 11:20:05 Saul Wold wrote:
I assume this patch is for Denzil? It seems that the current OE-Core
master has etc in that list.
Please confirm
Sau!
Saul,
Sorry I got mixed up on my branches there and didn't notice your change,
thanks for straightening me out. Scott any chance we can get Saul's commit
963742f5a9bc [kernel: Fix packaging issue] cherry-picked to Denzil?
Mark
On 09/12/2012 06:41 AM, Mark Asselstine wrote:
Along with checks to remove empty modprobe.d and modules-load.d
directories we can add a similar check and removal of the etc
directory. This will avoid warnings by the sanity checker.
Signed-off-by: Mark Asselstine mark.asselst...@windriver.com
CC: Bruce Ashfield bruce.ashfi...@windriver.com
---
There is some concern that removing this directory could cause issues
if folks are adding to etc in a bbappend and not checking for and
creating this directory. I don't believe this is an issue as if you
want to add something to etc it should be done as part of a
populate_packages_prepend or earlier since there are sanity checks run
as part of populate_packages, so the removal here is being done at the
latest possible point in the process (populate_packages_prepend in a
bbappend will run before the populate_packages_prepend in
kernel.bbclass).
meta/classes/kernel.bbclass |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 5e04fda..decf6f5 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -468,7 +468,7 @@ python populate_packages_prepend () {
# avoid warnings. removedirs only raises an OSError if an empty
# directory cannot be removed.
dvar = d.getVar('PKGD', True)
-for dir in [%s/etc/modprobe.d % (dvar), %s/etc/modules-load.d %
(dvar)]:
+for dir in [%s/etc/modprobe.d % (dvar), %s/etc/modules-load.d %
(dvar), %s/etc/ % (dvar)]:
if len(os.listdir(dir)) == 0:
os.rmdir(dir)
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH V2 0/1] image_types.bbclass: Round up ROOTFS_SIZE after base_size check
V2: Replace expr with awk. In this way an error like expr: non-integer argument is avoided. The following changes since commit 0f55a5868457300a3defc7fa7451ef191d19e018: adt-installer: Allow changing YOCTOADT_REPO (2012-09-05 23:28:10 +0100) are available in the git repository at: git://git.yoctoproject.org/poky-contrib ag/rootfs_size http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=ag/rootfs_size Andrei Gherzan (1): image_types.bbclass: Round up ROOTFS_SIZE after base_size check meta/classes/image_types.bbclass |7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) -- 1.7.9.5 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH V2 1/1] image_types.bbclass: Round up ROOTFS_SIZE after base_size check
If we round up ROOTFS_SIZE to IMAGE_ROOTFS_ALIGNMENT before checking if
base_size is greater then IMAGE_ROOTFS_SIZE, we can end up adding an
unaligned value to IMAGE_ROOTFS_SIZE. Obviously, if
IMAGE_ROOTFS_EXTRA_SPACE was overwritten with an unaligned value. So
let's add the round up code after the base_size calculus and it's
comparison.
Signed-off-by: Andrei Gherzan and...@gherzan.ro
---
meta/classes/image_types.bbclass |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/meta/classes/image_types.bbclass b/meta/classes/image_types.bbclass
index d286eea..6c01b21 100644
--- a/meta/classes/image_types.bbclass
+++ b/meta/classes/image_types.bbclass
@@ -82,9 +82,12 @@ runimagecmd () {
# The base_size gets calculated:
# - initial size determined by `du -ks` of the IMAGE_ROOTFS
# - then multiplied by the IMAGE_OVERHEAD_FACTOR
- # - then rounded up to IMAGE_ROOTFS_ALIGNMENT
# - finally tested against IMAGE_ROOTFS_SIZE
- ROOTFS_SIZE=`du -ks ${IMAGE_ROOTFS}|awk '{base_size = $1 *
${IMAGE_OVERHEAD_FACTOR} + ${IMAGE_ROOTFS_ALIGNMENT} - 1; base_size -=
base_size % ${IMAGE_ROOTFS_ALIGNMENT}; print ((base_size ${IMAGE_ROOTFS_SIZE}
? base_size : ${IMAGE_ROOTFS_SIZE}) + ${IMAGE_ROOTFS_EXTRA_SPACE}) }'`
+ ROOTFS_SIZE=`du -ks ${IMAGE_ROOTFS}|awk '{base_size = $1 *
${IMAGE_OVERHEAD_FACTOR}; print ((base_size ${IMAGE_ROOTFS_SIZE} ? base_size
: ${IMAGE_ROOTFS_SIZE}) + ${IMAGE_ROOTFS_EXTRA_SPACE}) }'`
+
+ # Round up ROOTFS_SIZE to IMAGE_ROOTFS_ALIGNMENT
+ ROOTFS_SIZE=`awk BEGIN { rootfs_size = $ROOTFS_SIZE +
${IMAGE_ROOTFS_ALIGNMENT} - 1; rootfs_size -= rootfs_size %
${IMAGE_ROOTFS_ALIGNMENT}; print rootfs_size }`
+
${cmd}
# Now create the needed compressed versions
cd ${DEPLOY_DIR_IMAGE}/
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH V2 1/1] image_types.bbclass: Round up ROOTFS_SIZE after base_size check
On 09/12/2012 01:10 PM, Andrei Gherzan wrote:
If we round up ROOTFS_SIZE to IMAGE_ROOTFS_ALIGNMENT before checking if
base_size is greater then IMAGE_ROOTFS_SIZE, we can end up adding an
unaligned value to IMAGE_ROOTFS_SIZE. Obviously, if
IMAGE_ROOTFS_EXTRA_SPACE was overwritten with an unaligned value. So
let's add the round up code after the base_size calculus and it's
comparison.
Signed-off-by: Andrei Gherzan and...@gherzan.ro
---
meta/classes/image_types.bbclass |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/meta/classes/image_types.bbclass b/meta/classes/image_types.bbclass
index d286eea..6c01b21 100644
--- a/meta/classes/image_types.bbclass
+++ b/meta/classes/image_types.bbclass
@@ -82,9 +82,12 @@ runimagecmd () {
# The base_size gets calculated:
# - initial size determined by `du -ks` of the IMAGE_ROOTFS
# - then multiplied by the IMAGE_OVERHEAD_FACTOR
- # - then rounded up to IMAGE_ROOTFS_ALIGNMENT
# - finally tested against IMAGE_ROOTFS_SIZE
- ROOTFS_SIZE=`du -ks ${IMAGE_ROOTFS}|awk '{base_size = $1 *
${IMAGE_OVERHEAD_FACTOR} + ${IMAGE_ROOTFS_ALIGNMENT} - 1; base_size -= base_size %
${IMAGE_ROOTFS_ALIGNMENT}; print ((base_size ${IMAGE_ROOTFS_SIZE} ? base_size
: ${IMAGE_ROOTFS_SIZE}) + ${IMAGE_ROOTFS_EXTRA_SPACE}) }'`
+ ROOTFS_SIZE=`du -ks ${IMAGE_ROOTFS}|awk '{base_size = $1 *
${IMAGE_OVERHEAD_FACTOR}; print ((base_size ${IMAGE_ROOTFS_SIZE} ? base_size
: ${IMAGE_ROOTFS_SIZE}) + ${IMAGE_ROOTFS_EXTRA_SPACE}) }'`
+
+ # Round up ROOTFS_SIZE to IMAGE_ROOTFS_ALIGNMENT
+ ROOTFS_SIZE=`awk BEGIN { rootfs_size = $ROOTFS_SIZE +
${IMAGE_ROOTFS_ALIGNMENT} - 1; rootfs_size -= rootfs_size % ${IMAGE_ROOTFS_ALIGNMENT};
print rootfs_size }`
+
AWK seems a little heavy weight here, now we are forking it twice, since
we are already in awk above, can you not just continue the function from
there instead, maybe with a END{} or something else?
Also will this guarantee an Integer result?
${cmd}
# Now create the needed compressed versions
cd ${DEPLOY_DIR_IMAGE}/
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-core v2] valgrind: fix debug info reading error when do memcheck on ppc targets
On Wed, Sep 12, 2012 at 3:20 AM, b19...@freescale.com wrote:
From: Zhenhua Luo b19...@freescale.com
following is the error message:
--2263-- WARNING: Serious error when reading debug info
--2263-- When reading debug info from /lib/ld-2.13.so:
--2263-- Can't make sense of .got section mapping
--2263-- WARNING: Serious error when reading debug info
--2263-- When reading debug info from /home/root/lzh:
--2263-- Can't make sense of .data section mapping
--2263-- WARNING: Serious error when reading debug info
--2263-- When reading debug info from
/usr/lib/valgrind/vgpreload_core-ppc32-linux.so:
--2263-- Can't make sense of .data section mapping
--2263-- WARNING: Serious error when reading debug info
--2263-- When reading debug info from
/usr/lib/valgrind/vgpreload_memcheck-ppc32-linux.so:
--2263-- Can't make sense of .data section mapping
--2263-- WARNING: Serious error when reading debug info
--2263-- When reading debug info from /lib/libc-2.13.so:
--2263-- Can't make sense of .data section mapping
Signed-off-by: Zhenhua Luo b19...@freescale.com
---
...ind-3.7.0-fix-error-of-reading-debug-info.patch | 33
meta/recipes-devtools/valgrind/valgrind_3.7.0.bb |5 ++-
2 files changed, 37 insertions(+), 1 deletion(-)
create mode 100644
meta/recipes-devtools/valgrind/valgrind-3.7.0/valgrind-3.7.0-fix-error-of-reading-debug-info.patch
diff --git
a/meta/recipes-devtools/valgrind/valgrind-3.7.0/valgrind-3.7.0-fix-error-of-reading-debug-info.patch
b/meta/recipes-devtools/valgrind/valgrind-3.7.0/valgrind-3.7.0-fix-error-of-reading-debug-info.patch
new file mode 100644
index 000..b1626f0
--- /dev/null
+++
b/meta/recipes-devtools/valgrind/valgrind-3.7.0/valgrind-3.7.0-fix-error-of-reading-debug-info.patch
@@ -0,0 +1,33 @@
+Upstream-Status: Pending
+
+fix debug info reading error when do memcheck on ppc targets
+following is the error message:
+--2263-- WARNING: Serious error when reading debug info
+--2263-- When reading debug info from /lib/ld-2.13.so:
+--2263-- Can't make sense of .got section mapping
+--2263-- WARNING: Serious error when reading debug info
+--2263-- When reading debug info from /home/root/lzh:
+--2263-- Can't make sense of .data section mapping
+--2263-- WARNING: Serious error when reading debug info
+--2263-- When reading debug info from
/usr/lib/valgrind/vgpreload_core-ppc32-linux.so:
+--2263-- Can't make sense of .data section mapping
+--2263-- WARNING: Serious error when reading debug info
+--2263-- When reading debug info from
/usr/lib/valgrind/vgpreload_memcheck-ppc32-linux.so:
+--2263-- Can't make sense of .data section mapping
+--2263-- WARNING: Serious error when reading debug info
+--2263-- When reading debug info from /lib/libc-2.13.so:
+--2263-- Can't make sense of .data section mapping
+
+Signed-off-by: Zhenhua Luo b19...@freescale.com
+
+--- a/coregrind/m_debuginfo/readelf.c 2012-09-11 21:45:36.696462313 -0500
b/coregrind/m_debuginfo/readelf.c 2012-09-11 21:45:49.913463615 -0500
+@@ -1539,7 +1539,7 @@
+ phdr-p_offset di-fsm.rw_map_foff +
di-fsm.rw_map_size
+ phdr-p_offset + phdr-p_filesz
+= di-fsm.rw_map_foff + di-fsm.rw_map_size
+- (phdr-p_flags (PF_R | PF_W | PF_X)) == (PF_R | PF_W))
{
++ (phdr-p_flags (PF_R | PF_W | PF_X)) = (PF_R | PF_W))
{
+if (n_rw == N_RX_RW_AREAS) {
+ ML_(symerr)(di, True,
+ N_RX_RW_AREAS is too low;
diff --git a/meta/recipes-devtools/valgrind/valgrind_3.7.0.bb
b/meta/recipes-devtools/valgrind/valgrind_3.7.0.bb
index abda7a6..651ae60 100644
--- a/meta/recipes-devtools/valgrind/valgrind_3.7.0.bb
+++ b/meta/recipes-devtools/valgrind/valgrind_3.7.0.bb
@@ -9,7 +9,7 @@ LIC_FILES_CHKSUM =
file://COPYING;md5=c46082167a314d785d012a244748d803 \
X11DEPENDS = virtual/libx11
DEPENDS = ${@base_contains('DISTRO_FEATURES', 'x11', '${X11DEPENDS}', '',
d)}
-PR = r5
+PR = r6
SRC_URI = http://www.valgrind.org/downloads/valgrind-${PV}.tar.bz2 \
file://fix_issue_caused_by_ccache.patch \
@@ -21,6 +21,9 @@ SRC_URI =
http://www.valgrind.org/downloads/valgrind-${PV}.tar.bz2 \
file://configure-with-glibc-2.16.patch \
+SRC_URI_append_powerpc =
file://valgrind-3.7.0-fix-error-of-reading-debug-info.patch
+SRC_URI_append_powerpc64 =
file://valgrind-3.7.0-fix-error-of-reading-debug-info.patch
Did you not build test this? There is a type here. Sent a fix already.
-M
+
SRC_URI[md5sum] = a855fda56edf05614f099dca316d1775
SRC_URI[sha256sum] =
[OE-core] [PATCH] valgrind_3.7.0.bb: fix missing leading space on _append
Signed-off-by: Matthew McClintock m...@freescale.com
---
meta/recipes-devtools/valgrind/valgrind_3.7.0.bb |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-devtools/valgrind/valgrind_3.7.0.bb
b/meta/recipes-devtools/valgrind/valgrind_3.7.0.bb
index 651ae60..3def11d 100644
--- a/meta/recipes-devtools/valgrind/valgrind_3.7.0.bb
+++ b/meta/recipes-devtools/valgrind/valgrind_3.7.0.bb
@@ -9,7 +9,7 @@ LIC_FILES_CHKSUM =
file://COPYING;md5=c46082167a314d785d012a244748d803 \
X11DEPENDS = virtual/libx11
DEPENDS = ${@base_contains('DISTRO_FEATURES', 'x11', '${X11DEPENDS}', '', d)}
-PR = r6
+PR = r7
SRC_URI = http://www.valgrind.org/downloads/valgrind-${PV}.tar.bz2 \
file://fix_issue_caused_by_ccache.patch \
@@ -22,7 +22,7 @@ SRC_URI =
http://www.valgrind.org/downloads/valgrind-${PV}.tar.bz2 \
SRC_URI_append_powerpc =
file://valgrind-3.7.0-fix-error-of-reading-debug-info.patch
-SRC_URI_append_powerpc64 =
file://valgrind-3.7.0-fix-error-of-reading-debug-info.patch
+SRC_URI_append_powerpc64 =
file://valgrind-3.7.0-fix-error-of-reading-debug-info.patch
SRC_URI[md5sum] = a855fda56edf05614f099dca316d1775
SRC_URI[sha256sum] =
5d62c0330f1481fe2c593249192fa68ff454c19c34343978cc9ce91aa324cbf6
--
1.7.9.7
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/3] runqemu: Explicitly specify MACHINE when calling bitbake
On 09/11/2012 10:59 PM, Khem Raj wrote:
When using runqemu with distros outside oe-core then
MACHINE may not be there in local.conf so use the one
thats available in environment of runqemu which is actually
the correct one.
Looks simple enough.
Acked-by: Scott Garman scott.a.gar...@intel.com
Signed-off-by: Khem Raj raj.k...@gmail.com
---
scripts/runqemu |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/runqemu b/scripts/runqemu
index a3c3509..e843946 100755
--- a/scripts/runqemu
+++ b/scripts/runqemu
@@ -281,7 +281,7 @@ setup_tmpdir() {
exit 1; }
# We have bitbake in PATH, get OE_TMPDIR from bitbake
-OE_TMPDIR=`bitbake -e | grep ^TMPDIR=\ | cut -d '=' -f2 | cut -d ''
-f2`
+OE_TMPDIR=`MACHINE=$MACHINE bitbake -e | grep ^TMPDIR=\ | cut -d '=' -f2 |
cut -d '' -f2`
if [ -z $OE_TMPDIR ]; then
echo Error: this script needs to be run from your build
directory,
echo or you need to explicitly set OE_TMPDIR in your environment
--
Scott Garman
Embedded Linux Engineer - Yocto Project
Intel Open Source Technology Center
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH V2 1/1] image_types.bbclass: Round up ROOTFS_SIZE after base_size check
On Wed, Sep 12, 2012 at 11:42 PM, Saul Wold s...@linux.intel.com wrote:
On 09/12/2012 01:10 PM, Andrei Gherzan wrote:
If we round up ROOTFS_SIZE to IMAGE_ROOTFS_ALIGNMENT before checking if
base_size is greater then IMAGE_ROOTFS_SIZE, we can end up adding an
unaligned value to IMAGE_ROOTFS_SIZE. Obviously, if
IMAGE_ROOTFS_EXTRA_SPACE was overwritten with an unaligned value. So
let's add the round up code after the base_size calculus and it's
comparison.
Signed-off-by: Andrei Gherzan and...@gherzan.ro
---
meta/classes/image_types.**bbclass |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/meta/classes/image_types.**bbclass
b/meta/classes/image_types.**bbclass
index d286eea..6c01b21 100644
--- a/meta/classes/image_types.**bbclass
+++ b/meta/classes/image_types.**bbclass
@@ -82,9 +82,12 @@ runimagecmd () {
# The base_size gets calculated:
# - initial size determined by `du -ks` of the IMAGE_ROOTFS
# - then multiplied by the IMAGE_OVERHEAD_FACTOR
- # - then rounded up to IMAGE_ROOTFS_ALIGNMENT
# - finally tested against IMAGE_ROOTFS_SIZE
- ROOTFS_SIZE=`du -ks ${IMAGE_ROOTFS}|awk '{base_size = $1 *
${IMAGE_OVERHEAD_FACTOR} + ${IMAGE_ROOTFS_ALIGNMENT} - 1; base_size -=
base_size % ${IMAGE_ROOTFS_ALIGNMENT}; print ((base_size
${IMAGE_ROOTFS_SIZE} ? base_size : ${IMAGE_ROOTFS_SIZE}) +
${IMAGE_ROOTFS_EXTRA_SPACE}) }'`
+ ROOTFS_SIZE=`du -ks ${IMAGE_ROOTFS}|awk '{base_size = $1 *
${IMAGE_OVERHEAD_FACTOR}; print ((base_size ${IMAGE_ROOTFS_SIZE} ?
base_size : ${IMAGE_ROOTFS_SIZE}) + ${IMAGE_ROOTFS_EXTRA_SPACE}) }'`
+
+ # Round up ROOTFS_SIZE to IMAGE_ROOTFS_ALIGNMENT
+ ROOTFS_SIZE=`awk BEGIN { rootfs_size = $ROOTFS_SIZE +
${IMAGE_ROOTFS_ALIGNMENT} - 1; rootfs_size -= rootfs_size %
${IMAGE_ROOTFS_ALIGNMENT}; print rootfs_size }`
+
AWK seems a little heavy weight here, now we are forking it twice, since
we are already in awk above, can you not just continue the function from
there instead, maybe with a END{} or something else?
So, to be sure i understood. You want to have the whole routine in the
same awk right? I did it this way to make those steps a little clearer. But
indeed, this is a good idea in terms of performance.
Also will this guarantee an Integer result?
Will fix in V3. :)
Branch updated with v3.
ag
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH] insane.conf: add new libexec test
On 09/12/2012 06:01 PM, Saul Wold wrote:
This tests for /usr/libexec as we are moving things to /lib/.
This got clobbered by the shell or something, should be ${prefix}/lib/${BPN}
the test is ignored if the distro defaults to /usr/libexec.
Currently this test will be disabled by default since the current
value of ${libexecdir} is /usr/libexec. Also this tests needs
to be enabled in the WARN_QA list.
[YOCTO #2915]
Signed-off-by: Saul Wold s...@linux.intel.com
---
meta/classes/insane.bbclass | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass
index e74eb3f..8b2d536 100644
--- a/meta/classes/insane.bbclass
+++ b/meta/classes/insane.bbclass
@@ -137,6 +137,20 @@ def package_qa_handle_error(error_class, error_msg, d):
bb.warn(QA Issue: %s % error_msg)
return True
+QAPATHTEST[libexec] = package_qa_check_libexec
+def package_qa_check_libexec(path,name, d, elf, messages):
+
+# Skip the case where the default is explicitly /usr/libexec
+libexec = d.getVar('libexecdir', True)
+if libexec == /usr/libexec:
+return True
+
+if 'libexec' in path.split(os.path.sep):
+messages.append(%s: %s is using libexec please relocate to %s %
(name, package_qa_clean_path(path, d), libexec))
+return False
+
+return True
+
QAPATHTEST[rpaths] = package_qa_check_rpath
def package_qa_check_rpath(file,name, d, elf, messages):
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH] insane.conf: add new libexec test
On 09/12/2012 06:01 PM, Saul Wold wrote:
This tests for /usr/libexec as we are moving things to /lib/.
the test is ignored if the distro defaults to /usr/libexec.
Currently this test will be disabled by default since the current
value of ${libexecdir} is /usr/libexec. Also this tests needs
to be enabled in the WARN_QA list.
An initial run of this against World showed the following packages had
build time issues, I still need to determine runtime issues.
I set libexecdir=${prefix}/lib/${BPN} and enabled the test in WARN_QA
perf seems to hard code libexec someplace
lttng-tools (lttng-consumerd)
qemu (qemu-bridge-helper)
Not bad for the first pass
Sau!
[YOCTO #2915]
Signed-off-by: Saul Wold s...@linux.intel.com
---
meta/classes/insane.bbclass | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass
index e74eb3f..8b2d536 100644
--- a/meta/classes/insane.bbclass
+++ b/meta/classes/insane.bbclass
@@ -137,6 +137,20 @@ def package_qa_handle_error(error_class, error_msg, d):
bb.warn(QA Issue: %s % error_msg)
return True
+QAPATHTEST[libexec] = package_qa_check_libexec
+def package_qa_check_libexec(path,name, d, elf, messages):
+
+# Skip the case where the default is explicitly /usr/libexec
+libexec = d.getVar('libexecdir', True)
+if libexec == /usr/libexec:
+return True
+
+if 'libexec' in path.split(os.path.sep):
+messages.append(%s: %s is using libexec please relocate to %s %
(name, package_qa_clean_path(path, d), libexec))
+return False
+
+return True
+
QAPATHTEST[rpaths] = package_qa_check_rpath
def package_qa_check_rpath(file,name, d, elf, messages):
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [CONSOLIDATED REQUEST 00/10] Misc Fixes (cover only)
Richard,
A few fixes from people.
I have the start of the libexec sanity (insane test) and a couple of
fixes for miss-packaged files.
Sau!
The following changes since commit 835654994574c158d6324218ebe000bd2ef9a792:
rt: Add hwlatdetect to rt images (2012-09-12 15:11:12 +0100)
are available in the git repository at:
git://git.openembedded.org/openembedded-core-contrib sgw/stage
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=sgw/stage
Constantin Musca (1):
patch.bbclass: Use one TMPDIR per patching process
Khem Raj (3):
kernel.bbclass, module-base.bbclass: Use CC to form KERNEL_CC
uclibc: Revert systemd regressing patch from upsteam uclibc and uprev
SRCREV
runqemu: Explicitly specify MACHINE when calling bitbake
Matthew McClintock (1):
valgrind_3.7.0.bb: fix missing leading space on _append
Ross Burton (1):
connman: remove trailing whitespace
Saul Wold (4):
insane.conf: add new libexec test
oprofileui: Add Icons to oprofileui-viewer package
kernelshark: add missing ${D}
lttng-tools: skip new libexec insane test
meta/classes/insane.bbclass| 14 +
meta/classes/kernel-arch.bbclass | 13 +
meta/classes/kernel.bbclass| 16 +-
meta/classes/module-base.bbclass | 16 -
meta/classes/patch.bbclass | 11 +
meta/recipes-connectivity/connman/connman.inc |2 +-
meta/recipes-core/uclibc/uclibc-git.inc|5 +-
...nt.c-wtent.c-move-functions-from-utxent.c.patch | 321
meta/recipes-devtools/valgrind/valgrind_3.7.0.bb |4 +-
meta/recipes-kernel/lttng-2.0/lttng-tools_2.0.4.bb |7 +-
meta/recipes-kernel/oprofile/oprofileui_git.bb |4 +-
meta/recipes-kernel/trace-cmd/kernelshark_1.2.bb |5 +-
scripts/runqemu|2 +-
13 files changed, 378 insertions(+), 42 deletions(-)
create mode 100644
meta/recipes-core/uclibc/uclibc-git/0001-Revert-utent.c-wtent.c-move-functions-from-utxent.c.patch
--
1.7.7.6
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
