Re: [OE-core] [PATCH 0/8] Bug Fixes for M2 Rc2
2011/7/8 Saul Wold s...@linux.intel.com Richard, This address the bash, xcb missing from libx11, locale issue and the lack of space due to zypper eating space. I don't think all the dependencies on bash are needed. E.g: eglibc: Add RDEPENDS on bash eglibc itself does not need bash to be present at runtime (or maybe only in some eglibc configurations). I am currently happily running an eglibc system with busybox sh without any problem at all. Footprintwise for embedded systems that is desirable and as such it is quite a common setup. Frans. Sau! The following changes since commit f1fc6d084b079dea21ff1a30b815496452042490: pulseaudio: add 0.9.23 (2011-07-07 13:44:36 +0100) are available in the git repository at: git://git.openembedded.org/openembedded-core-contrib sgw/fix http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=sgw/fix Saul Wold (8): rootfs_rpm: Add 50Meg to image size for zypper image.bbclass: add LINGUAS_INSTALL to depends list gnome-doc-utils: Add RDEPENDS on bash quilt: Add RDEPENDS on bash console-tools: Add RDEPENDS on bash usbutils: Add RDEPENDS on bash eglibc: Add RDEPENDS on bash libx11: enable xcb support meta/classes/image.bbclass |2 +- meta/classes/image_types.bbclass |2 +- meta/classes/rootfs_rpm.bbclass|5 + meta/recipes-bsp/usbutils/usbutils_0.91.bb |5 +++-- .../console-tools/console-tools_0.3.2.bb |3 ++- meta/recipes-core/eglibc/eglibc-package.inc|2 +- meta/recipes-core/eglibc/eglibc.inc|2 +- meta/recipes-core/eglibc/eglibc_2.12.bb|2 +- meta/recipes-core/eglibc/eglibc_2.13.bb|2 +- meta/recipes-devtools/quilt/quilt.inc |2 ++ meta/recipes-devtools/quilt/quilt_0.48.bb |2 +- meta/recipes-gnome/gnome/gnome-doc-utils.inc |2 ++ meta/recipes-gnome/gnome/gnome-doc-utils_0.20.6.bb |2 +- meta/recipes-graphics/xorg-lib/libx11_1.3.4.bb | 11 --- 14 files changed, 30 insertions(+), 14 deletions(-) -- 1.7.3.4 ___ 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 7/8] eglibc: Add RDEPENDS on bash
2011/7/8 Saul Wold s...@linux.intel.com
[YOCTO #1214]
Signed-off-by: Saul Wold s...@linux.intel.com
---
meta/recipes-core/eglibc/eglibc-package.inc |2 +-
meta/recipes-core/eglibc/eglibc.inc |2 +-
meta/recipes-core/eglibc/eglibc_2.12.bb |2 +-
meta/recipes-core/eglibc/eglibc_2.13.bb |2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/meta/recipes-core/eglibc/eglibc-package.inc
b/meta/recipes-core/eglibc/eglibc-package.inc
index 1c6626c..f0fac76 100644
--- a/meta/recipes-core/eglibc/eglibc-package.inc
+++ b/meta/recipes-core/eglibc/eglibc-package.inc
@@ -69,7 +69,7 @@ FILES_eglibc-utils = ${bindir}/* ${sbindir}/*
FILES_${PN}-dbg += ${libexecdir}/*/.debug ${libdir}/audit/.debug
FILES_catchsegv${PKGSUFFIX} = ${bindir}/catchsegv
RDEPENDS_catchsegv${PKGSUFFIX} = libsegfault
-EDEPENDS_eglibc-utils = libsotruss
+RDEPENDS_eglibc-utils += libsotruss bash
FILES_eglibc-pcprofile = ${base_libdir}/libpcprofile.so
FILES_eglibc-thread-db${PKGSUFFIX} = ${base_libdir}/libthread_db*
RPROVIDES_eglibc-dev += libc-dev
diff --git a/meta/recipes-core/eglibc/eglibc.inc
b/meta/recipes-core/eglibc/eglibc.inc
index 74afb9d..058d58e 100644
--- a/meta/recipes-core/eglibc/eglibc.inc
+++ b/meta/recipes-core/eglibc/eglibc.inc
@@ -22,7 +22,7 @@ siteconfig_do_siteconfig_gencache_prepend = \
# nptl needs unwind support in gcc, which can't be built without glibc.
DEPENDS = virtual/${TARGET_PREFIX}gcc-intermediate linux-libc-headers
#this leads to circular deps, so lets not add it yet
-#RDEPENDS_ldd += bash
+RDEPENDS_ldd += bash
Ah ok, now see that this is only for ldd.
In that case the commit message is misleading. (and probably also not
conformant with the commit message policy).
Frans
# nptl needs libgcc but dlopens it, so our shlibs code doesn't detect this
#RDEPENDS_${PN} += ${@['','libgcc']['nptl' in '${GLIBC_ADDONS}']}
PROVIDES = virtual/libc virtual/${TARGET_PREFIX}libc-for-gcc
diff --git
a/meta/recipes-core/eglibc/eglibc_2.12.bbb/meta/recipes-core/eglibc/
eglibc_2.12.bb
index 85d58fa..fd7b485 100644
--- a/meta/recipes-core/eglibc/eglibc_2.12.bb
+++ b/meta/recipes-core/eglibc/eglibc_2.12.bb
@@ -1,7 +1,7 @@
require eglibc.inc
DEPENDS += gperf-native
-PR = r18
+PR = r19
SRCREV = 14158
diff --git
a/meta/recipes-core/eglibc/eglibc_2.13.bbb/meta/recipes-core/eglibc/
eglibc_2.13.bb
index 7986131..be65787 100644
--- a/meta/recipes-core/eglibc/eglibc_2.13.bb
+++ b/meta/recipes-core/eglibc/eglibc_2.13.bb
@@ -4,7 +4,7 @@ SRCREV = 14157
DEPENDS += gperf-native
FILESPATHPKG =. eglibc-svn:
-PR = r5
+PR = r6
PR_append = +svnr${SRCPV}
EGLIBC_BRANCH=eglibc-2_13
--
1.7.3.4
___
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 7/8] eglibc: Add RDEPENDS on bash
Op 8 jul. 2011 om 07:53 heeft Frans Meulenbroeks fransmeulenbro...@gmail.com
het volgende geschreven:
2011/7/8 Saul Wold s...@linux.intel.com
[YOCTO #1214]
Signed-off-by: Saul Wold s...@linux.intel.com
---
meta/recipes-core/eglibc/eglibc-package.inc |2 +-
meta/recipes-core/eglibc/eglibc.inc |2 +-
meta/recipes-core/eglibc/eglibc_2.12.bb |2 +-
meta/recipes-core/eglibc/eglibc_2.13.bb |2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/meta/recipes-core/eglibc/eglibc-package.inc
b/meta/recipes-core/eglibc/eglibc-package.inc
index 1c6626c..f0fac76 100644
--- a/meta/recipes-core/eglibc/eglibc-package.inc
+++ b/meta/recipes-core/eglibc/eglibc-package.inc
@@ -69,7 +69,7 @@ FILES_eglibc-utils =${bindir}/* ${sbindir}/*
FILES_${PN}-dbg +=${libexecdir}/*/.debug ${libdir}/audit/.debug
FILES_catchsegv${PKGSUFFIX} =${bindir}/catchsegv
RDEPENDS_catchsegv${PKGSUFFIX} =libsegfault
-EDEPENDS_eglibc-utils =libsotruss
+RDEPENDS_eglibc-utils +=libsotruss bash
FILES_eglibc-pcprofile =${base_libdir}/libpcprofile.so
FILES_eglibc-thread-db${PKGSUFFIX} =${base_libdir}/libthread_db*
RPROVIDES_eglibc-dev +=libc-dev
diff --git a/meta/recipes-core/eglibc/eglibc.inc
b/meta/recipes-core/eglibc/eglibc.inc
index 74afb9d..058d58e 100644
--- a/meta/recipes-core/eglibc/eglibc.inc
+++ b/meta/recipes-core/eglibc/eglibc.inc
@@ -22,7 +22,7 @@ siteconfig_do_siteconfig_gencache_prepend = \
# nptl needs unwind support in gcc, which can't be built without glibc.
DEPENDS =virtual/${TARGET_PREFIX}gcc-intermediate linux-libc-headers
#this leads to circular deps, so lets not add it yet
-#RDEPENDS_ldd += bash
+RDEPENDS_ldd += bash
Ah ok, now see that this is only for ldd.
In that case the commit message is misleading. (and probably also not
conformant with the commit message policy).
there's an ldd-unbash patch in . dev
Frans
# nptl needs libgcc but dlopens it, so our shlibs code doesn't detect this
#RDEPENDS_${PN} +=${@['','libgcc']['nptl' in '${GLIBC_ADDONS}']}
PROVIDES =virtual/libc virtual/${TARGET_PREFIX}libc-for-gcc
diff --git a/meta/recipes-core/eglibc/eglibc_2.12.bb
b/meta/recipes-core/eglibc/eglibc_2.12.bb
index 85d58fa..fd7b485 100644
--- a/meta/recipes-core/eglibc/eglibc_2.12.bb
+++ b/meta/recipes-core/eglibc/eglibc_2.12.bb
@@ -1,7 +1,7 @@
require eglibc.inc
DEPENDS +=gperf-native
-PR =r18
+PR =r19
SRCREV =14158
diff --git a/meta/recipes-core/eglibc/eglibc_2.13.bb
b/meta/recipes-core/eglibc/eglibc_2.13.bb
index 7986131..be65787 100644
--- a/meta/recipes-core/eglibc/eglibc_2.13.bb
+++ b/meta/recipes-core/eglibc/eglibc_2.13.bb
@@ -4,7 +4,7 @@ SRCREV =14157
DEPENDS +=gperf-native
FILESPATHPKG =. eglibc-svn:
-PR =r5
+PR =r6
PR_append =+svnr${SRCPV}
EGLIBC_BRANCH=eglibc-2_13
--
1.7.3.4
___
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
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 6/8] usbutils: Add RDEPENDS on bash
iirc only the ids package depends on bash, and only to check for wget. Fixing
the update script would be better
Op 8 jul. 2011 om 00:31 heeft Saul Wold s...@linux.intel.com het volgende
geschreven:
[YOCTO #1214]
Signed-off-by: Saul Wold s...@linux.intel.com
---
meta/recipes-bsp/usbutils/usbutils_0.91.bb |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-bsp/usbutils/usbutils_0.91.bb
b/meta/recipes-bsp/usbutils/usbutils_0.91.bb
index 5d605c5..c5420d0 100644
--- a/meta/recipes-bsp/usbutils/usbutils_0.91.bb
+++ b/meta/recipes-bsp/usbutils/usbutils_0.91.bb
@@ -7,8 +7,7 @@ LICENSE = GPLv2+
LIC_FILES_CHKSUM = file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f
DEPENDS = libusb zlib
-RDEPENDS_${PN} = ${PN}-ids
-PR = r1
+PR = r2
SRC_URI = ${KERNELORG_MIRROR}/linux/utils/usb/usbutils/usbutils-${PV}.tar.gz
@@ -26,3 +25,5 @@ do_install_append() {
PACKAGES += ${PN}-ids
FILES_${PN} += ${datadir}/pkgconfig
FILES_${PN}-ids = ${datadir}/usb*
+
+RDEPENDS_${PN} = ${PN}-ids bash
--
1.7.3.4
___
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 7/8] eglibc: Add RDEPENDS on bash
2011/7/8 Koen Kooi k...@dominion.thruhere.net Op 8 jul. 2011 om 07:53 heeft Frans Meulenbroeks fransmeulenbro...@gmail.com het volgende geschreven: -#RDEPENDS_ldd += bash +RDEPENDS_ldd += bash Ah ok, now see that this is only for ldd. In that case the commit message is misleading. (and probably also not conformant with the commit message policy). there's an ldd-unbash patch in . dev Seems to me that that is a better alternative then Frans ___ 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] powertop: inherit update-alternatives and use a higher priority than busybox
Op 8 jul. 2011 om 02:40 heeft Cui, Dexuan dexuan@intel.com het volgende geschreven: Tom Rini wrote: On 07/07/2011 01:39 AM, Dexuan Cui wrote: busybox-1.18.4 installs /bin/powertop and the powertop recipe installs /usr/bin/powertop. So, in PATH, if /bin appears before /usr/bin, we would run the version offered by busybox, which has a very limited function (e.g., no parameter is accepted) and this causes trouble to eclipse plugin. We can use update-alternatives for powertop with higher priority to resolve the issue. Fixes [YOCTO #1208] Signed-off-by: Dexuan Cui dexuan@intel.com This fix seems a bit incomplete. Why is busybox putting powertop into /bin when it almost certainly belongs in /usr/bin like the real recipe was placing it. busybox needs a fix here too. Thanks for the comment! I was hesitant about fixing busybox as I wasn't sure if it's worthy to make a patch to only fix the path for busybox. I don't know why busybox puts it into /bin. I think the best place may be /usr/sbin/. A little unluckily this patch to powertop has been already in poky master... So maybe we could try to fix the recipes in future, e.g., when upgrading them. we should do the right thing in oe-core, the poky people can clean up on their own. Thanks, -- Dexuan ___ 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 1/7] binutils: upgrade from 2.21 to 2.21.1
On Fri, 2011-07-08 at 00:12 +0100, Richard Purdie wrote: On Thu, 2011-07-07 at 14:39 -0700, Khem Raj wrote: How about changing the recipe to fetch from binutils-2_21-branch and call it binutils 2.21 as it is I don't really see the benefits in fetching this from the SCM? Agreed, seems like fetching it from CVS will just make it slower and not really buy us anything. I think sticking with the tarballs is the right answer here. p. ___ 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] bitbake.conf: update OLDEST_KERNEL to 2.6.0
On Friday 08 July 2011 06:21:16 Khem Raj wrote: If oe-core never supported older kernel than 2.6.37 then setting it to 2.6.37 would be better IMO It's not necessarily just about oe-core - it's about what layers get used on top, and some of those will be using kernels older than 2.6.37. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ 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] kernel.bbclass: handle embedding of initramfs images
On Friday 08 July 2011 01:53:38 Khem Raj wrote:
On Fri, Jul 8, 2011 at 1:11 AM, Andrea Adami andrea.ad...@gmail.com
+image = bb.data.getVar('INITRAMFS_IMAGE', d, True)
+if image != '' and image is not None:
^^^
Is this ok ?
Probably if image: would be better.
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
___
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] bitbake.conf: update OLDEST_KERNEL to 2.6.0
On Fri, 2011-07-08 at 09:38 +0100, Paul Eggleton wrote: On Friday 08 July 2011 06:21:16 Khem Raj wrote: If oe-core never supported older kernel than 2.6.37 then setting it to 2.6.37 would be better IMO It's not necessarily just about oe-core - it's about what layers get used on top, and some of those will be using kernels older than 2.6.37. It's very rare that we get a free hand in the choice of kernel version. We get stuck with whichever version the silicon vendor chooses to support, so it would be bad for us if we couldn't use an older kernel in our layers. Cheers, Chris. ___ 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] bitbake.conf: update OLDEST_KERNEL to 2.6.0
On Friday 08 July 2011 09:46:34 Chris Elston wrote: It's very rare that we get a free hand in the choice of kernel version. We get stuck with whichever version the silicon vendor chooses to support, so it would be bad for us if we couldn't use an older kernel in our layers. Just out of interest, what's the oldest kernel you have to deal with in your current/recent projects? Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ 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] bitbake.conf: update OLDEST_KERNEL to 2.6.0
On Fri, 2011-07-08 at 09:38 +0100, Paul Eggleton wrote: On Friday 08 July 2011 06:21:16 Khem Raj wrote: If oe-core never supported older kernel than 2.6.37 then setting it to 2.6.37 would be better IMO It's not necessarily just about oe-core - it's about what layers get used on top, and some of those will be using kernels older than 2.6.37. They can always provide their own OLDEST_KERNEL setting, though. To some extent I think it's a bit academic what the default in oe-core is. p. ___ 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] bitbake.conf: update OLDEST_KERNEL to 2.6.0
On Fri, 2011-07-08 at 11:03 +0100, Paul Eggleton wrote: On Friday 08 July 2011 10:53:49 Phil Blundell wrote: They can always provide their own OLDEST_KERNEL setting, though. To some extent I think it's a bit academic what the default in oe-core is. Yes, but let's have a sensible default value, in particular that will allow the majority not to experience subtle problems that they will have to spend time tracking down. Many people coming to OE fresh will not know this setting even exists - I only discovered it the other day by accident. If OLDEST_KERNEL is set to a value that's too new then the failure you get is anything but subtle: glibc will just print kernel too old and exit. I guess we could enhance that message to refer directly to OLDEST_KERNEL to make it a bit more obvious what you need to do. Also, we could teach kernel.bbclass to issue a diagnostic if you try to build a kernel that's older than OLDEST_KERNEL. p. ___ 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] bitbake.conf: update OLDEST_KERNEL to 2.6.0
On Friday 08 July 2011 11:12:12 Phil Blundell wrote: If OLDEST_KERNEL is set to a value that's too new then the failure you get is anything but subtle: glibc will just print kernel too old and exit. OK, I had just assumed you would just get errors about missing syscalls, good to know that it would be more obvious than that. I guess we could enhance that message to refer directly to OLDEST_KERNEL to make it a bit more obvious what you need to do. Also, we could teach kernel.bbclass to issue a diagnostic if you try to build a kernel that's older than OLDEST_KERNEL. These sound like good ideas. I'll add them to my todo list to have a look at if nobody else gets there first. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ 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] kernel.bbclass: make external module compile
On 6 jul 2011, at 20:32, Darren Hart dvh...@linux.intel.com wrote: On 07/06/2011 10:31 AM, Anders Darander wrote: Hi Darren, On 6 jul 2011, at 18:37, Darren Hart dvh...@linux.intel.com wrote: The scripts are recreated during the build of module.bbclass derived recipes. Are you trying to build modules independently of this method? Richard expressed concerns about not including host specific binaries in the sstate, which was part of the reason this approach was taken. Thanks for pointing out this, especially the first sentence in this paragraph. No matter how many times I've looked at both the recipes in question, as well as the meta/classes directory, I haven't noticed that the old, inherited recipes were not using module.bbclass, but rather inherited module-base.bbclass directly. I'll assume that once I change that, and fix the recipes properly all my issues will go away. Once more, thanks for pointing me to the real problem. Excellent, please keep us posted! Fixing the module recipes as hinted above, solved my problems. Thus, I've back ported the fixes to our current build system, based on oe-dev. Thanks again! Cheers, Anders ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/8] Patches pending for merging from O.S. Systems tree
The following changes since commit f05b7ee7716d1e5cc1ba0bbab57e91c3a0569e9e: x-load: Update to 1.5.0 (2011-07-05 14:16:33 +0100) are available in the git repository at: git://github.com/OSSystems/oe-core master https://github.com/OSSystems/oe-core/tree/master Chris Larson (2): Rework how the devshell functions oe.terminal: improve how we spawn screen Otavio Salvador (6): cmake.bbclass: use CPPFLAGS and CXXFLAGS cmake: refactor recipe libarchive: add 2.8.4 version cmake: add nativesdk and target versions cmake: update to 2.8.5-rc3 fix SDK building due TARGET_ARCH use in installation path meta/classes/cmake.bbclass |8 +- meta/classes/devshell.bbclass | 26 ++--- meta/classes/populate_sdk.bbclass |2 +- meta/classes/terminal.bbclass | 30 ++ meta/conf/bitbake.conf |2 +- meta/lib/oe/classutils.py |2 + meta/lib/oe/terminal.py| 107 meta/recipes-devtools/cmake/cmake-native_2.8.3.bb |7 -- meta/recipes-devtools/cmake/cmake-native_2.8.5.bb | 12 ++ meta/recipes-devtools/cmake/cmake.inc |6 +- .../cmake/cmake/dont-run-cross-binaries.patch | 22 .../cmake/cmake/support-oe-qt4-tools-names.patch | 14 ++-- meta/recipes-devtools/cmake/cmake_2.8.5.bb | 50 + .../0001-Patch-from-upstream-revision-1990.patch | 42 .../0002-Patch-from-upstream-revision-1991.patch | 31 ++ .../0003-Patch-from-upstream-rev-2516.patch| 63 .../0004-Patch-from-upstream-rev-2514.patch| 33 ++ .../0005-Patch-from-upstream-rev-2520.patch| 31 ++ .../0006-Patch-from-upstream-rev-2521.patch| 28 + ...YS-error-when-setting-up-xattrs.-Closes-5.patch | 31 ++ .../libarchive/libarchive_2.8.4.bb | 25 + 21 files changed, 534 insertions(+), 38 deletions(-) create mode 100644 meta/classes/terminal.bbclass create mode 100644 meta/lib/oe/terminal.py delete mode 100644 meta/recipes-devtools/cmake/cmake-native_2.8.3.bb create mode 100644 meta/recipes-devtools/cmake/cmake-native_2.8.5.bb create mode 100644 meta/recipes-devtools/cmake/cmake/dont-run-cross-binaries.patch create mode 100644 meta/recipes-devtools/cmake/cmake_2.8.5.bb create mode 100644 meta/recipes-extended/libarchive/libarchive/0001-Patch-from-upstream-revision-1990.patch create mode 100644 meta/recipes-extended/libarchive/libarchive/0002-Patch-from-upstream-revision-1991.patch create mode 100644 meta/recipes-extended/libarchive/libarchive/0003-Patch-from-upstream-rev-2516.patch create mode 100644 meta/recipes-extended/libarchive/libarchive/0004-Patch-from-upstream-rev-2514.patch create mode 100644 meta/recipes-extended/libarchive/libarchive/0005-Patch-from-upstream-rev-2520.patch create mode 100644 meta/recipes-extended/libarchive/libarchive/0006-Patch-from-upstream-rev-2521.patch create mode 100644 meta/recipes-extended/libarchive/libarchive/0007-Ignore-ENOSYS-error-when-setting-up-xattrs.-Closes-5.patch create mode 100644 meta/recipes-extended/libarchive/libarchive_2.8.4.bb -- 1.7.2.5 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 3/8] cmake.bbclass: use CPPFLAGS and CXXFLAGS
Some classes, as for example nativesdk, defines CPPFLAGS and CXXFLAGS
to be passed to compiler. Using those makes more sense and avoid some
hacks on packages using CMake.
Signed-off-by: Otavio Salvador ota...@ossystems.com.br
---
meta/classes/cmake.bbclass |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/meta/classes/cmake.bbclass b/meta/classes/cmake.bbclass
index 011c232..672325e 100644
--- a/meta/classes/cmake.bbclass
+++ b/meta/classes/cmake.bbclass
@@ -19,10 +19,10 @@ OECMAKE_C_COMPILER ?= `echo ${CC} | sed 's/^\([^
]*\).*/\1/'`
OECMAKE_CXX_COMPILER ?= `echo ${CXX} | sed 's/^\([^ ]*\).*/\1/'`
# Compiler flags
-OECMAKE_C_FLAGS ?= ${HOST_CC_ARCH} ${TOOLCHAIN_OPTIONS} ${TARGET_CPPFLAGS}
-OECMAKE_CXX_FLAGS ?= ${HOST_CC_ARCH} ${TOOLCHAIN_OPTIONS} ${TARGET_CPPFLAGS}
-fpermissive
-OECMAKE_C_FLAGS_RELEASE ?= ${SELECTED_OPTIMIZATION} -DNDEBUG
-OECMAKE_CXX_FLAGS_RELEASE ?= ${SELECTED_OPTIMIZATION} -DNDEBUG
+OECMAKE_C_FLAGS ?= ${HOST_CC_ARCH} ${TOOLCHAIN_OPTIONS} ${CPPFLAGS}
+OECMAKE_CXX_FLAGS ?= ${HOST_CC_ARCH} ${TOOLCHAIN_OPTIONS} ${CXXFLAGS}
-fpermissive
+OECMAKE_C_FLAGS_RELEASE ?= ${SELECTED_OPTIMIZATION} ${CPPFLAGS} -DNDEBUG
+OECMAKE_CXX_FLAGS_RELEASE ?= ${SELECTED_OPTIMIZATION} ${CXXFLAGS} -DNDEBUG
OECMAKE_RPATH ?=
--
1.7.2.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 7/8] cmake: update to 2.8.5-rc3
Signed-off-by: Otavio Salvador ota...@ossystems.com.br
---
meta/recipes-devtools/cmake/cmake-native_2.8.3.bb |7 ---
meta/recipes-devtools/cmake/cmake-native_2.8.5.bb | 12
.../cmake/cmake/support-oe-qt4-tools-names.patch | 14 +++---
.../cmake/{cmake_2.8.3.bb = cmake_2.8.5.bb} |9 +++--
4 files changed, 26 insertions(+), 16 deletions(-)
delete mode 100644 meta/recipes-devtools/cmake/cmake-native_2.8.3.bb
create mode 100644 meta/recipes-devtools/cmake/cmake-native_2.8.5.bb
rename meta/recipes-devtools/cmake/{cmake_2.8.3.bb = cmake_2.8.5.bb} (76%)
diff --git a/meta/recipes-devtools/cmake/cmake-native_2.8.3.bb
b/meta/recipes-devtools/cmake/cmake-native_2.8.3.bb
deleted file mode 100644
index a68a25f..000
--- a/meta/recipes-devtools/cmake/cmake-native_2.8.3.bb
+++ /dev/null
@@ -1,7 +0,0 @@
-require cmake.inc
-inherit native
-
-PR = ${INC_PR}.1
-
-SRC_URI[md5sum] = a76a44b93acf5e3badda9de111385921
-SRC_URI[sha256sum] =
689ed02786b5cefa5515c7716784ee82a82e8ece6be5a3d629ac3cc0c05fc288
diff --git a/meta/recipes-devtools/cmake/cmake-native_2.8.5.bb
b/meta/recipes-devtools/cmake/cmake-native_2.8.5.bb
new file mode 100644
index 000..c8da1cb
--- /dev/null
+++ b/meta/recipes-devtools/cmake/cmake-native_2.8.5.bb
@@ -0,0 +1,12 @@
+require cmake.inc
+inherit native
+
+# This was need to keep version consistent - will be removed once 2.8.5 is
released
+SRC_URI =
http://www.cmake.org/files/v${CMAKE_MAJOR_VERSION}/cmake-2.8.5-rc3.tar.gz \
+ file://support-oe-qt4-tools-names.patch
+S = ${WORKDIR}/cmake-2.8.5-rc3
+
+PR = ${INC_PR}.0
+
+SRC_URI[md5sum] = 2d8018f8fa4c499e2c5b288d71660cba
+SRC_URI[sha256sum] =
2987befc451f6404ea93bb99f00a38b80724fb655f121fed3bb0a08b65a771c8
diff --git a/meta/recipes-devtools/cmake/cmake/support-oe-qt4-tools-names.patch
b/meta/recipes-devtools/cmake/cmake/support-oe-qt4-tools-names.patch
index 9bccd40..339199c 100644
--- a/meta/recipes-devtools/cmake/cmake/support-oe-qt4-tools-names.patch
+++ b/meta/recipes-devtools/cmake/cmake/support-oe-qt4-tools-names.patch
@@ -29,14 +29,14 @@ Signed-off-by: Otavio Salvador ota...@ossystems.com.br
-NAMES moc-qt4 moc
+NAMES moc-qt4 moc4 moc
PATHS ${QT_BINARY_DIR}
- NO_DEFAULT_PATH
+ NO_DEFAULT_PATH NO_CMAKE_FIND_ROOT_PATH
)
FIND_PROGRAM(QT_UIC_EXECUTABLE
-NAMES uic-qt4 uic
+NAMES uic-qt4 uic4 uic
PATHS ${QT_BINARY_DIR}
- NO_DEFAULT_PATH
+ NO_DEFAULT_PATH NO_CMAKE_FIND_ROOT_PATH
)
@@ -1006,49 +1006,49 @@
)
@@ -45,35 +45,35 @@ Signed-off-by: Otavio Salvador ota...@ossystems.com.br
-NAMES rcc
+NAMES rcc4 rcc
PATHS ${QT_BINARY_DIR}
- NO_DEFAULT_PATH
+ NO_DEFAULT_PATH NO_CMAKE_FIND_ROOT_PATH
)
FIND_PROGRAM(QT_DBUSCPP2XML_EXECUTABLE
-NAMES qdbuscpp2xml
+NAMES qdbuscpp2xml4 qdbuscpp2xml
PATHS ${QT_BINARY_DIR}
- NO_DEFAULT_PATH
+ NO_DEFAULT_PATH NO_CMAKE_FIND_ROOT_PATH
)
FIND_PROGRAM(QT_DBUSXML2CPP_EXECUTABLE
-NAMES qdbusxml2cpp
+NAMES qdbusxml2cpp4 qdbusxml2cpp
PATHS ${QT_BINARY_DIR}
- NO_DEFAULT_PATH
+ NO_DEFAULT_PATH NO_CMAKE_FIND_ROOT_PATH
)
FIND_PROGRAM(QT_LUPDATE_EXECUTABLE
-NAMES lupdate-qt4 lupdate
+NAMES lupdate-qt4 lupdate4 lupdate
PATHS ${QT_BINARY_DIR}
- NO_DEFAULT_PATH
+ NO_DEFAULT_PATH NO_CMAKE_FIND_ROOT_PATH
)
FIND_PROGRAM(QT_LRELEASE_EXECUTABLE
-NAMES lrelease-qt4 lrelease
+NAMES lrelease-qt4 lrelease4 lrelease
PATHS ${QT_BINARY_DIR}
- NO_DEFAULT_PATH
+ NO_DEFAULT_PATH NO_CMAKE_FIND_ROOT_PATH
)
FIND_PROGRAM(QT_QCOLLECTIONGENERATOR_EXECUTABLE
diff --git a/meta/recipes-devtools/cmake/cmake_2.8.3.bb
b/meta/recipes-devtools/cmake/cmake_2.8.5.bb
similarity index 76%
rename from meta/recipes-devtools/cmake/cmake_2.8.3.bb
rename to meta/recipes-devtools/cmake/cmake_2.8.5.bb
index d1048ed..2a9a82c 100644
--- a/meta/recipes-devtools/cmake/cmake_2.8.3.bb
+++ b/meta/recipes-devtools/cmake/cmake_2.8.5.bb
@@ -6,10 +6,15 @@ DEPENDS += curl expat zlib libarchive ncurses
PR = ${INC_PR}.0
+# This was need to keep version consistent - will be removed once 2.8.5 is
released
+SRC_URI =
http://www.cmake.org/files/v${CMAKE_MAJOR_VERSION}/cmake-2.8.5-rc3.tar.gz \
+ file://support-oe-qt4-tools-names.patch
+S = ${WORKDIR}/cmake-2.8.5-rc3
+
SRC_URI += file://dont-run-cross-binaries.patch
-SRC_URI[md5sum] = a76a44b93acf5e3badda9de111385921
-SRC_URI[sha256sum] =
689ed02786b5cefa5515c7716784ee82a82e8ece6be5a3d629ac3cc0c05fc288
+SRC_URI[md5sum] = 2d8018f8fa4c499e2c5b288d71660cba
+SRC_URI[sha256sum] =
2987befc451f6404ea93bb99f00a38b80724fb655f121fed3bb0a08b65a771c8
# Strip ${prefix} from ${docdir}, set result into docdir_stripped
python () {
--
1.7.2.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
[OE-core] [PATCH 6/8] cmake: add nativesdk and target versions
Adds a recipe that provides the nativesdk and target versions of
CMake.
This recipe is based on code from OpenEmbeeded (rev
b1f2e1501c19540617a829b37415c0616101c7ad).
Signed-off-by: Otavio Salvador ota...@ossystems.com.br
---
.../cmake/cmake/dont-run-cross-binaries.patch | 22 ++
meta/recipes-devtools/cmake/cmake_2.8.3.bb | 45
2 files changed, 67 insertions(+), 0 deletions(-)
create mode 100644
meta/recipes-devtools/cmake/cmake/dont-run-cross-binaries.patch
create mode 100644 meta/recipes-devtools/cmake/cmake_2.8.3.bb
diff --git a/meta/recipes-devtools/cmake/cmake/dont-run-cross-binaries.patch
b/meta/recipes-devtools/cmake/cmake/dont-run-cross-binaries.patch
new file mode 100644
index 000..4eb1794
--- /dev/null
+++ b/meta/recipes-devtools/cmake/cmake/dont-run-cross-binaries.patch
@@ -0,0 +1,22 @@
+cmake: don't run cross-binaries on host machine
+
+When doing the cross build we obviously cannot run those binaries on
+host since they can be binary incompatible.
+
+Upstream-Status: Inappropriate [embedded specific]
+
+Signed-off-by: Otavio Salvador ota...@ossystems.com.br
+
+diff -ru cmake-2.8.2.orig/CMakeLists.txt cmake-2.8.2/CMakeLists.txt
+--- cmake-2.8.2.orig/CMakeLists.txt2010-07-28 00:48:42.0 +0200
cmake-2.8.2/CMakeLists.txt 2010-07-28 01:05:17.0 +0200
+@@ -518,7 +518,8 @@
+
+ # build the remaining subdirectories
+ ADD_SUBDIRECTORY(Source)
+-ADD_SUBDIRECTORY(Utilities)
++# Come on! Running the cross-binaries on host is not a good idea.
++#ADD_SUBDIRECTORY(Utilities)
+ ADD_SUBDIRECTORY(Tests)
+
+ # add a test
diff --git a/meta/recipes-devtools/cmake/cmake_2.8.3.bb
b/meta/recipes-devtools/cmake/cmake_2.8.3.bb
new file mode 100644
index 000..d1048ed
--- /dev/null
+++ b/meta/recipes-devtools/cmake/cmake_2.8.3.bb
@@ -0,0 +1,45 @@
+require cmake.inc
+
+inherit cmake
+
+DEPENDS += curl expat zlib libarchive ncurses
+
+PR = ${INC_PR}.0
+
+SRC_URI += file://dont-run-cross-binaries.patch
+
+SRC_URI[md5sum] = a76a44b93acf5e3badda9de111385921
+SRC_URI[sha256sum] =
689ed02786b5cefa5515c7716784ee82a82e8ece6be5a3d629ac3cc0c05fc288
+
+# Strip ${prefix} from ${docdir}, set result into docdir_stripped
+python () {
+prefix=bb.data.getVar(prefix, d, 1)
+docdir=bb.data.getVar(docdir, d, 1)
+
+if not docdir.startswith(prefix):
+ raise bb.build.FuncFailed('docdir must contain prefix as its prefix')
+
+docdir_stripped = docdir[len(prefix):]
+if len(docdir_stripped) 0 and docdir_stripped[0] == '/':
+ docdir_stripped = docdir_stripped[1:]
+
+bb.data.setVar(docdir_stripped, docdir_stripped, d)
+}
+
+EXTRA_OECMAKE= \
+-DCMAKE_DOC_DIR=${docdir_stripped}/cmake-${CMAKE_MAJOR_VERSION} \
+-DCMAKE_USE_SYSTEM_LIBRARIES=1 \
+-DKWSYS_CHAR_IS_SIGNED=1 \
+${@base_contains('DISTRO_FEATURES', 'largefile', '-DKWSYS_LFS_WORKS=1',
'-DKWSYS_LFS_DISABLE=1', d)} \
+
+
+# FIXME: Hack due gcc-crosssdk not being able to detect those automatically
+CXXFLAGS_virtclass-nativesdk += \
+ -I${STAGING_DIR_HOST}${SDKPATHNATIVE}/usr/include/c++ \
+ -I${STAGING_DIR_HOST}${SDKPATHNATIVE}/usr/include/c++/${TARGET_SYS} \
+
+
+FILES_${PN} += ${datadir}/cmake-${CMAKE_MAJOR_VERSION}
+FILES_${PN}-doc += ${docdir}/cmake-${CMAKE_MAJOR_VERSION}
+
+BBCLASSEXTEND = nativesdk
--
1.7.2.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 5/8] libarchive: add 2.8.4 version
This recipe has been imported from OpenEmbedded (rev
6db4b9050e0e8b963e2a6b63790e48e3042ea99e).
Signed-off-by: Otavio Salvador ota...@ossystems.com.br
---
.../0001-Patch-from-upstream-revision-1990.patch | 42 +
.../0002-Patch-from-upstream-revision-1991.patch | 31 ++
.../0003-Patch-from-upstream-rev-2516.patch| 63
.../0004-Patch-from-upstream-rev-2514.patch| 33 ++
.../0005-Patch-from-upstream-rev-2520.patch| 31 ++
.../0006-Patch-from-upstream-rev-2521.patch| 28 +
...YS-error-when-setting-up-xattrs.-Closes-5.patch | 31 ++
.../libarchive/libarchive_2.8.4.bb | 25
8 files changed, 284 insertions(+), 0 deletions(-)
create mode 100644
meta/recipes-extended/libarchive/libarchive/0001-Patch-from-upstream-revision-1990.patch
create mode 100644
meta/recipes-extended/libarchive/libarchive/0002-Patch-from-upstream-revision-1991.patch
create mode 100644
meta/recipes-extended/libarchive/libarchive/0003-Patch-from-upstream-rev-2516.patch
create mode 100644
meta/recipes-extended/libarchive/libarchive/0004-Patch-from-upstream-rev-2514.patch
create mode 100644
meta/recipes-extended/libarchive/libarchive/0005-Patch-from-upstream-rev-2520.patch
create mode 100644
meta/recipes-extended/libarchive/libarchive/0006-Patch-from-upstream-rev-2521.patch
create mode 100644
meta/recipes-extended/libarchive/libarchive/0007-Ignore-ENOSYS-error-when-setting-up-xattrs.-Closes-5.patch
create mode 100644 meta/recipes-extended/libarchive/libarchive_2.8.4.bb
diff --git
a/meta/recipes-extended/libarchive/libarchive/0001-Patch-from-upstream-revision-1990.patch
b/meta/recipes-extended/libarchive/libarchive/0001-Patch-from-upstream-revision-1990.patch
new file mode 100644
index 000..f65f89f
--- /dev/null
+++
b/meta/recipes-extended/libarchive/libarchive/0001-Patch-from-upstream-revision-1990.patch
@@ -0,0 +1,42 @@
+libarchive: Backport patch from upstream (revision 1990)
+
+Upstream-Status: Backport
+
+Signed-off-by: Otavio Salvador ota...@ossystems.com.br
+
+diff --git a/libarchive/archive_read_disk_entry_from_file.c
b/libarchive/archive_read_disk_entry_from_file.c
+index 7473c50..27671df 100644
+--- a/libarchive/archive_read_disk_entry_from_file.c
b/libarchive/archive_read_disk_entry_from_file.c
+@@ -163,15 +163,26 @@ archive_read_disk_entry_from_file(struct archive *_a,
+
+ #ifdef HAVE_READLINK
+ if (S_ISLNK(st-st_mode)) {
+- char linkbuffer[PATH_MAX + 1];
+- int lnklen = readlink(path, linkbuffer, PATH_MAX);
++ size_t linkbuffer_len = st-st_size + 1;
++ char *linkbuffer;
++ int lnklen;
++
++ linkbuffer = malloc(linkbuffer_len);
++ if (linkbuffer == NULL) {
++ archive_set_error(a-archive, ENOMEM,
++ Couldn't read link data);
++ return (ARCHIVE_FAILED);
++ }
++ lnklen = readlink(path, linkbuffer, linkbuffer_len);
+ if (lnklen 0) {
+ archive_set_error(a-archive, errno,
+ Couldn't read link data);
++ free(linkbuffer);
+ return (ARCHIVE_FAILED);
+ }
+ linkbuffer[lnklen] = 0;
+ archive_entry_set_symlink(entry, linkbuffer);
++ free(linkbuffer);
+ }
+ #endif
+
+--
+1.7.1
+
diff --git
a/meta/recipes-extended/libarchive/libarchive/0002-Patch-from-upstream-revision-1991.patch
b/meta/recipes-extended/libarchive/libarchive/0002-Patch-from-upstream-revision-1991.patch
new file mode 100644
index 000..6ece7f3
--- /dev/null
+++
b/meta/recipes-extended/libarchive/libarchive/0002-Patch-from-upstream-revision-1991.patch
@@ -0,0 +1,31 @@
+libarchive: Backport patch from upstream (revision 1991)
+
+Upstream-Status: Backport
+
+Signed-off-by: Otavio Salvador ota...@ossystems.com.br
+
+diff --git a/libarchive/archive_write_disk.c b/libarchive/archive_write_disk.c
+index caf958e..60699e0 100644
+--- a/libarchive/archive_write_disk.c
b/libarchive/archive_write_disk.c
+@@ -434,7 +434,7 @@ _archive_write_header(struct archive *_a, struct
archive_entry *entry)
+ if (ret != ARCHIVE_OK)
+ goto done;
+ }
+-#ifdef HAVE_FCHDIR
++#if defined(HAVE_FCHDIR) defined(PATH_MAX)
+ /* If path exceeds PATH_MAX, shorten the path. */
+ edit_deep_directories(a);
+ #endif
+@@ -866,7 +866,7 @@ archive_write_disk_new(void)
+ * object creation is likely to fail, but any error will get handled
+ * at that time.
+ */
+-#ifdef HAVE_FCHDIR
++#if defined(HAVE_FCHDIR) defined(PATH_MAX)
+ static void
+ edit_deep_directories(struct archive_write_disk *a)
+ {
+--
+1.7.1
+
diff --git
a/meta/recipes-extended/libarchive/libarchive/0003-Patch-from-upstream-rev-2516.patch
Re: [OE-core] [PATCH 1/8] rootfs_rpm: Add 50Meg to image size for zypper
On Thu, 2011-07-07 at 22:42 -0700, Saul Wold wrote:
On 07/07/2011 04:38 PM, Richard Purdie wrote:
On Thu, 2011-07-07 at 16:31 -0700, Saul Wold wrote:
[YOCTO #1171]
Add /var space for zypper due to its space usage for db maintence
This hasn't been tested for opkg/deb and is missing something like:
ZYPPER_VAR_DB_SPACE ??= 0
I'd suggest we just change this to append + 51200 to
IMAGE_ROOTFS_EXTRA_SPACE. I'd also like this only to happen when we're
actually installing zypper so the minimal images are unaffected...
I can do the + 51200, but I have not figured out how to do the check for
zypper, maybe it's something straight forward, but I am not finding a
way to do it easily.
How about something like:
IMAGE_ROOTFS_EXTRA_SPACE += ${@base_contains(PACKAGE_INSTALL, zypper, +
51200, ,d)}
?
Not perfect but should basically work for what we need until we find a
bettr fix for zypper itself.
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/1] libc-locale: split locale handling from libc recipe.
On Mon, 2011-06-27 at 16:37 +0800, Dongxiao Xu wrote:
+do_install_locale () {
+ dest=${D}/${includedir}/glibc-locale-internal-${MULTIMACH_TARGET_SYS}
+ install -d ${dest} ${dest}${bindir}
+ cp -fpPR ${D}${base_libdir} ${dest}${base_prefix}
+ cp -fpPR ${D}${libdir} ${dest}${exec_prefix}
+ cp -fpPR ${D}${datadir} ${dest}${exec_prefix}
+ cp -fpPR ${D}${bindir}/localedef ${dest}${bindir}
+ cp -fpPR ${WORKDIR}/SUPPORTED ${dest}
+}
This turns out to lose if you don't have libc-locale-code in
DISTRO_FEATURES, since then localedef isn't installed and it blows up
trying to copy that file.
p.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/7] upgrades misc fixes
On Thu, 2011-07-07 at 13:25 -0700, nitin.a.kam...@intel.com wrote: From: Nitin A Kamble nitin.a.kam...@intel.com The following changes since commit 2c79c9eb7ef8ef0aef8c3096c3c4387e28e56ea2: pulseaudio: add 0.9.23 (2011-07-07 13:45:32 +0100) are available in the git repository at: git://git.pokylinux.org/poky-contrib nitin/misc http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=nitin/misc Nitin A Kamble (7): binutils: upgrade from 2.21 to 2.21.1 gmp: upgrade from 5.0.1 to 5.0.2 distro tracking: update devel.toolchain recipes's fields gcc-runtime: fix installed but unpackaged files elfutils: fix compilations issue with the gcc 4.7 I merged the above, thanks. eglibc: fix installed but not packaged files binutils: package unpackaged files and for these I've followed up with replies against the patches. 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] bluez-dtl1-workaround: remove PRIORITY
On 07/06/2011 04:39 PM, Saul Wold wrote: On 07/06/2011 07:06 AM, Paul Eggleton wrote: On Tuesday 05 July 2011 19:37:24 you wrote: On Tue, 2011-07-05 at 17:31 +0100, Paul Eggleton wrote: Is it possible some people are still using PCMCIA/CF cards with this hardware in it? It's certainly possible, yes. But I don't think that the mere possibility is a very strong argument for keeping the recipe in oe-core. Maybe it would be better suited to meta-oe or some BSP layer, You're right, I guess it doesn't really belong in oe-core. Phil, I will take a patch that deletes from here and adds it into the meta-extra's layer. In some cases this is simple enough to do - move one recipe from here to there. In other cases, not so much. Note that in addition to the removal of these recipes, Phil also kindly cleaned up kernel.bbclass by removing a bunch of special casing that was in place for this specific module. Adding that support to meta-extras is a considerable effort and not particularly sustainable as more old-and-crusty code is purged from OE. It is also not likely to be well tested, which makes meta-extra less and less useful. We need an exit-path for old-and-crusty code - the git repository has the history, so if it's needed we can always pull it into meta-extras and properly test it when we know there is an interest, but if some due diligence has been performed to determine the code is no longer of any use, it seems like a lot of effort for very little gain to move any and all removal of code from oe-core to meta-extras. Thanks, Darren Sau! Cheers, Paul ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 4/7] binutils: package unpackaged files
On Thu, 2011-07-07 at 13:25 -0700, nitin.a.kam...@intel.com wrote:
From: Nitin A Kamble nitin.a.kam...@intel.com
To fix these package qa warnings
WARNING: For recipe binutils, the following files were installed but not
shipped in any package:
WARNING: /usr/bin/ld.bfd
WARNING: /usr/bin/elfedit
Signed-off-by: Nitin A Kamble nitin.a.kam...@intel.com
---
.../binutils/binutils-cross-canadian_2.21.1.bb |2 +-
.../binutils/binutils-crosssdk_2.21.1.bb |2 +-
meta/recipes-devtools/binutils/binutils.inc|2 ++
meta/recipes-devtools/binutils/binutils_2.21.1.bb |2 +-
4 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/meta/recipes-devtools/binutils/binutils-cross-canadian_2.21.1.bb
b/meta/recipes-devtools/binutils/binutils-cross-canadian_2.21.1.bb
index 7dad2a6..e91e7dc 100644
--- a/meta/recipes-devtools/binutils/binutils-cross-canadian_2.21.1.bb
+++ b/meta/recipes-devtools/binutils/binutils-cross-canadian_2.21.1.bb
@@ -1,3 +1,3 @@
require binutils_${PV}.bb
require binutils-cross-canadian.inc
-PR = r0
+PR = r1
diff --git a/meta/recipes-devtools/binutils/binutils-crosssdk_2.21.1.bb
b/meta/recipes-devtools/binutils/binutils-crosssdk_2.21.1.bb
index 0d6efff..21289cd 100644
--- a/meta/recipes-devtools/binutils/binutils-crosssdk_2.21.1.bb
+++ b/meta/recipes-devtools/binutils/binutils-crosssdk_2.21.1.bb
@@ -4,7 +4,7 @@ inherit crosssdk
PROVIDES = virtual/${TARGET_PREFIX}binutils-crosssdk
-PR = r0
+PR = r1
do_configure_prepend () {
sed -i 's#/usr/local/lib /lib /usr/lib#${SDKPATHNATIVE}/lib
${SDKPATHNATIVE}/usr/lib /usr/local/lib /lib /usr/lib#' ${S}/ld/configure.tgt
diff --git a/meta/recipes-devtools/binutils/binutils.inc
b/meta/recipes-devtools/binutils/binutils.inc
index 08c14b2..9a6b9c8 100644
--- a/meta/recipes-devtools/binutils/binutils.inc
+++ b/meta/recipes-devtools/binutils/binutils.inc
@@ -35,11 +35,13 @@ FILES_${PN}-symlinks = \
${bindir}/c++filt \
${bindir}/gprof \
${bindir}/ld \
+ ${bindir}/ld.bfd \
${bindir}/nm \
${bindir}/objcopy \
${bindir}/objdump \
${bindir}/ranlib \
${bindir}/readelf \
+ ${bindir}/elfedit \
${bindir}/size \
${bindir}/strip
Nitin, do you know if the ld.bfd above is a hardlinked copy of ld?
It may be better to turn this into a symlink if so (although our
packaging process should preserve hardlinks these days).
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 5/8] libarchive: add 2.8.4 version
On Fri, 2011-07-08 at 13:47 +, Otavio Salvador wrote: This recipe has been imported from OpenEmbedded (rev 6db4b9050e0e8b963e2a6b63790e48e3042ea99e). The piece of data I don't have here is the reason we need this OE-Core? 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 7/8] cmake: update to 2.8.5-rc3
On Fri, 2011-07-08 at 13:47 +, Otavio Salvador wrote:
Signed-off-by: Otavio Salvador ota...@ossystems.com.br
---
meta/recipes-devtools/cmake/cmake-native_2.8.3.bb |7 ---
meta/recipes-devtools/cmake/cmake-native_2.8.5.bb | 12
.../cmake/cmake/support-oe-qt4-tools-names.patch | 14 +++---
.../cmake/{cmake_2.8.3.bb = cmake_2.8.5.bb} |9 +++--
4 files changed, 26 insertions(+), 16 deletions(-)
delete mode 100644 meta/recipes-devtools/cmake/cmake-native_2.8.3.bb
create mode 100644 meta/recipes-devtools/cmake/cmake-native_2.8.5.bb
rename meta/recipes-devtools/cmake/{cmake_2.8.3.bb = cmake_2.8.5.bb} (76%)
What is the reason for moving to an -rcX release? When is the main
release likely to be made?
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 3/8] cmake.bbclass: use CPPFLAGS and CXXFLAGS
On Fri, 2011-07-08 at 13:47 +, Otavio Salvador wrote: Some classes, as for example nativesdk, defines CPPFLAGS and CXXFLAGS to be passed to compiler. Using those makes more sense and avoid some hacks on packages using CMake. Signed-off-by: Otavio Salvador ota...@ossystems.com.br --- meta/classes/cmake.bbclass |8 1 files changed, 4 insertions(+), 4 deletions(-) Merged to master, 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 8/8] fix SDK building due TARGET_ARCH use in installation path
On Fri, 2011-07-08 at 13:47 +, Otavio Salvador wrote:
TARGET_ARCH makes the building too fragile since it changes during
building of target and nativesdk binaries thus making it difficult to
handle a proper path for installation of binaries. The fix for it is
to move it to toolchain tarball name.
Signed-off-by: Otavio Salvador ota...@ossystems.com.br
---
meta/classes/populate_sdk.bbclass |2 +-
meta/conf/bitbake.conf|2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/classes/populate_sdk.bbclass
b/meta/classes/populate_sdk.bbclass
index 089ed9a..03b6d0f 100644
--- a/meta/classes/populate_sdk.bbclass
+++ b/meta/classes/populate_sdk.bbclass
@@ -9,7 +9,7 @@ SDKTARGETSYSROOT = ${SDKPATH}/sysroots/${TARGET_SYS}
TOOLCHAIN_HOST_TASK ?= task-sdk-host-nativesdk
task-cross-canadian-${TRANSLATED_TARGET_ARCH}
TOOLCHAIN_TARGET_TASK ?= task-core-standalone-sdk-target
task-core-standalone-sdk-target-dbg
-TOOLCHAIN_OUTPUTNAME ?= ${SDK_NAME}-toolchain-${DISTRO_VERSION}
+TOOLCHAIN_OUTPUTNAME ?=
${SDK_NAME}-${SDK_ARCH}-${TARGET_ARCH}-toolchain-${DISTRO_VERSION}
RDEPENDS = ${TOOLCHAIN_TARGET_TASK} ${TOOLCHAIN_HOST_TASK}
DEPENDS = virtual/fakeroot-native sed-native
diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index bdaa35d..cc2b8e2 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -341,7 +341,7 @@ DEPLOY_DIR_TOOLS = ${DEPLOY_DIR}/tools
PKGDATA_DIR = ${TMPDIR}/pkgdata/${MULTIMACH_TARGET_SYS}
-SDK_NAME = oecore-${SDK_ARCH}-${TARGET_ARCH}
+SDK_NAME = oecore-sdk-${DISTRO}
SDKPATH = /usr/local/${SDK_NAME}
SDKPATHNATIVE = ${SDKPATH}/sysroots/${SDK_SYS}
I'd really like Koen to take a look at this with his Angstrom hat on. I
still suspect the better fix for this is likely to end up with:
SDK_NAME = oecore-${SDK_ARCH}-${TARGET_ARCH}
-SDKPATH = /usr/local/${SDK_NAME}
+SDKPATH = /usr/local/oecore-sdk-${DISTRO}
SDKPATHNATIVE = ${SDKPATH}/sysroots/${SDK_SYS}
Certainly having TARGET_ARCH in SDKPATH is a bad idea but I think the
SDK_NAME variable could make sense as it is originally...
Cheers,
Richard
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] eglibc issuettes continued
I'm not sure whether there are pending patches which will address these or not, but with a fresh pull from today I'm still not getting very good packaging for eglibc 2.13. Specifically: WARNING: For recipe eglibc, the following files were installed but not shipped in any package: WARNING: /etc/localtime WARNING: /etc/rpc WARNING: /etc/ld.so.conf WARNING: /lib/gconv/ISO-2022-CN-EXT.so WARNING: /lib/gconv/IBM921.so [... etc ...] WARNING: /lib/gconv/.debug/ISO-2022-CN-EXT.so WARNING: /lib/gconv/.debug/IBM921.so [... etc ...] WARNING: /share/i18n/charmaps/ISO-8859-15.gz WARNING: /share/i18n/charmaps/IBM285.gz [... etc ...] WARNING: /share/i18n/locales/ss_ZA WARNING: /share/i18n/locales/is_IS [... etc ...] WARNING: QA Issue: libc-extra-nss rdepends on eglibc-dev WARNING: QA Issue: libc-thread-db rdepends on eglibc-dev ERROR: QA run found fatal errors. Please consider fixing them. I'm not sure if these are actually new or not, though. It's possible that they've been there for ages and I only just noticed. p. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 7/8] cmake: update to 2.8.5-rc3
On Fri, Jul 8, 2011 at 12:35, Richard Purdie
richard.pur...@linuxfoundation.org wrote:
On Fri, 2011-07-08 at 13:47 +, Otavio Salvador wrote:
Signed-off-by: Otavio Salvador ota...@ossystems.com.br
---
meta/recipes-devtools/cmake/cmake-native_2.8.3.bb | 7 ---
meta/recipes-devtools/cmake/cmake-native_2.8.5.bb | 12
.../cmake/cmake/support-oe-qt4-tools-names.patch | 14 +++---
.../cmake/{cmake_2.8.3.bb = cmake_2.8.5.bb} | 9 +++--
4 files changed, 26 insertions(+), 16 deletions(-)
delete mode 100644 meta/recipes-devtools/cmake/cmake-native_2.8.3.bb
create mode 100644 meta/recipes-devtools/cmake/cmake-native_2.8.5.bb
rename meta/recipes-devtools/cmake/{cmake_2.8.3.bb = cmake_2.8.5.bb} (76%)
What is the reason for moving to an -rcX release? When is the main
release likely to be made?
Saul asked me to update it since the current one has some license
issues that he wants fixed for M2; by the way, this patch has been
fixed in my branch to fix a build failure so take the github one, not
this (I can send an update patch to ml but seems not worth if not
required).
--
Otavio Salvador O.S. Systems
E-mail: ota...@ossystems.com.br http://www.ossystems.com.br
Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 6/8] usbutils: Add RDEPENDS on bash
On Fri, 2011-07-08 at 08:28 +0100, Koen Kooi wrote: iirc only the ids package depends on bash, and only to check for wget. Fixing the update script would be better Agreed and I'll take a follow up patch on this one. The fix in itself is correct as the script is wanting bash currently. 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/1] powertop: inherit update-alternatives and use a higher priority than busybox
Op 8 jul. 2011 om 16:00 heeft Richard Purdie richard.pur...@linuxfoundation.org het volgende geschreven: On Fri, 2011-07-08 at 08:25 +0100, Koen Kooi wrote: Op 8 jul. 2011 om 02:40 heeft Cui, Dexuan dexuan@intel.com het volgende geschreven: Tom Rini wrote: On 07/07/2011 01:39 AM, Dexuan Cui wrote: busybox-1.18.4 installs /bin/powertop and the powertop recipe installs /usr/bin/powertop. So, in PATH, if /bin appears before /usr/bin, we would run the version offered by busybox, which has a very limited function (e.g., no parameter is accepted) and this causes trouble to eclipse plugin. We can use update-alternatives for powertop with higher priority to resolve the issue. Fixes [YOCTO #1208] Signed-off-by: Dexuan Cui dexuan@intel.com This fix seems a bit incomplete. Why is busybox putting powertop into /bin when it almost certainly belongs in /usr/bin like the real recipe was placing it. busybox needs a fix here too. Thanks for the comment! I was hesitant about fixing busybox as I wasn't sure if it's worthy to make a patch to only fix the path for busybox. I don't know why busybox puts it into /bin. I think the best place may be /usr/sbin/. A little unluckily this patch to powertop has been already in poky master... So maybe we could try to fix the recipes in future, e.g., when upgrading them. we should do the right thing in oe-core, the poky people can clean up on their own. I don't think anyone is suggesting we shouldn't do the right thing in OE-Core? :) I merged the original patch on the grounds that its was an improvement to the situation. We've identified a better improvement so can someone please send me the patch and I'll likely merge that too. the email makes it seem that the patch was merged into poky, but not oe-core. When reading it like that the proposal involved merging the 'incomplete' patch for the sake of keeping poky and oe-core in sync FWIW, I agree that powertop should really be under /usr/... 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 1/2] kernel.bbclass: handle embedding of initramfs images
Op 8 jul. 2011 om 16:38 heeft Darren Hart dvh...@linux.intel.com het volgende
geschreven:
On 07/07/2011 04:11 PM, Andrea Adami wrote:
* from org.openembedded.dev (oe-classic)
Hi Andrea,
Please include a descriptive blurb about the patch. When people read
through the commit log they need to know what problem this patch
addresses and how it intends to go about it. If possible, it should also
include the commit id from the source (I suspect that isn't an option here).
+INITRAMFS_IMAGE ?=
+INITRAMFS_TASK ?=
+
inherit kernel-arch deploy
PACKAGES_DYNAMIC += kernel-module-*
@@ -179,8 +191,18 @@ kernel_do_configure() {
cp ${WORKDIR}/defconfig ${S}/.config
fi
yes '' | oe_runmake oldconfig
+
+if [ ! -z ${INITRAMFS_IMAGE} ]; then
+for img in cpio.gz cpio.lzo cpio.lzma; do
+if [ -e ${DEPLOY_DIR_IMAGE}/${INITRAMFS_IMAGE}-${MACHINE}.$img
+cp ${DEPLOY_DIR_IMAGE}/${INITRAMFS_IMAGE}-${MACHINE}.$i
+fi
+done
+fi
Hrm... Why is this part of do_configure? Seems a lot more like a deploy
or install step. Also, the cp line has been truncated here.
the initramfs gets embedded into the kernel, so it needs to happen before
do-compile. maybe a seperate task is better
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
___
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 6/8] cmake: add nativesdk and target versions
On Fri, Jul 8, 2011 at 12:28, Richard Purdie
richard.pur...@linuxfoundation.org wrote:
On Fri, 2011-07-08 at 13:47 +, Otavio Salvador wrote:
Adds a recipe that provides the nativesdk and target versions of
CMake.
This recipe is based on code from OpenEmbeeded (rev
b1f2e1501c19540617a829b37415c0616101c7ad).
Signed-off-by: Otavio Salvador ota...@ossystems.com.br
---
[...]
+# FIXME: Hack due gcc-crosssdk not being able to detect those automatically
+CXXFLAGS_virtclass-nativesdk += \
+ -I${STAGING_DIR_HOST}${SDKPATHNATIVE}/usr/include/c++ \
+ -I${STAGING_DIR_HOST}${SDKPATHNATIVE}/usr/include/c++/${TARGET_SYS} \
+
I get worried when I see things like this :(
Has anyone attempted to work out why gcc-crosssdk can't locate c++
include files?
Not sure why but this is the same things as done on qt4-tools-nativesdk.
--
Otavio Salvador O.S. Systems
E-mail: ota...@ossystems.com.br http://www.ossystems.com.br
Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 6/8] cmake: add nativesdk and target versions
On Friday 08 July 2011 16:49:12 Otavio Salvador wrote:
+# FIXME: Hack due gcc-crosssdk not being able to detect those
automatically +CXXFLAGS_virtclass-nativesdk += \
+ -I${STAGING_DIR_HOST}${SDKPATHNATIVE}/usr/include/c++ \
+ -I${STAGING_DIR_HOST}${SDKPATHNATIVE}/usr/include/c++/${TARGET_SYS}
\ +
I get worried when I see things like this :(
Has anyone attempted to work out why gcc-crosssdk can't locate c++
include files?
Not sure why but this is the same things as done on qt4-tools-nativesdk.
Yes, and I don't like it there either. Suggestions on fixing this would be
welcome - in the time I spent trying to figure out why it wasn't working (some
months ago) I couldn't find the cause.
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/4] uboot: Update to 2011.06
On 07/01/2011 12:16 AM, Koen Kooi wrote:
Op 1 jul 2011, om 08:54 heeft Saul Wold het volgende geschreven:
[YOCTO #1198]
Signed-off-by: Saul Wold s...@linux.intel.com
---
...Drop-config.h-include-in-tools-imximage.h.patch |0
...ove-LDSCRIPT-processing-to-the-top-level-.patch |0
...kimage_2011.03.bb = u-boot-mkimage_2011.06.bb} | 12 +---
.../uboot/{u-boot_2011.03.bb = u-boot_2011.06.bb} | 10 +-
You do realize that people .bbappending 2011.03 are now left out in the cold,
right?
My apologies to Saul as I probably contributed to this by not being
explicit in the bug report. As stated in my earlier mail regarding uboot
policy, we should keep at least two revisions of u-boot around to give
people time to migrate to the newer one (if they can at all).
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
___
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] bitbake.conf: update OLDEST_KERNEL to 2.6.0
On Fri, 2011-07-08 at 07:17 -0700, Khem Raj wrote: On Fri, Jul 8, 2011 at 1:38 AM, Paul Eggleton paul.eggle...@linux.intel.com wrote: On Friday 08 July 2011 06:21:16 Khem Raj wrote: If oe-core never supported older kernel than 2.6.37 then setting it to 2.6.37 would be better IMO It's not necessarily just about oe-core - it's about what layers get used on top, and some of those will be using kernels older than 2.6.37. Its similar to a situation where some of the layers might be using gcc older than 4.6.0 but we still chose 4.6.0 in default distro vars. There always is a possibility to override it if user has to. For now, I've merged the 2.6.16 patch since there seem to be good reasons for making things at least that recent. Its certainly better than 2.4! :) 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/1] [bug 1195] site/mips-common: Cache cvs_cv_func_printf_ptr
On Thu, 2011-07-07 at 16:23 -0700, Jessica Zhang wrote: The following changes since commit c412674cf818e77e35857fb93353e392e7ac9e53: Khem Raj (1): package.bbclass,prserv.bbclass: Compare USE_PR_SERV with 1 or 0 are available in the git repository at: git://git.yoctoproject.org/poky-contrib jzhang/1195 http://git.yoctoproject.org/cgit.cgi//log/?h=jzhang/1195 Khem Raj (1): [bug 1195] site/mips-common: Cache cvs_cv_func_printf_ptr Merged to master, 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 0/3] QA warning fixes
On Thu, 2011-07-07 at 18:32 +0100, Paul Eggleton wrote: I found a couple of issues with the recent insane.bbclass changes. The following patches fix them as well as add a warning fix for something I noticed when building a kernel with LIRC support. The following changes since commit f1fc6d084b079dea21ff1a30b815496452042490: pulseaudio: add 0.9.23 (2011-07-07 13:44:36 +0100) are available in the git repository at: git://git.openembedded.org/openembedded-core-contrib paule/qa-dev-deps http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=paule/qa-dev-deps Paul Eggleton (3): insane.bbclass: allow dev-deps to be skipped via INSANE_SKIP insane.bbclass: fix error/warning status being inverted kernel.bbclass: prevent QA warning about kernel-module-lirc-dev I've taken the first two patches, thanks. In the third case, I think we have bigger problems for both -dbg and -dev packages matching in kernel module space. We should probably disable those two checks for all kernel modules somehow... 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 6/8] cmake: add nativesdk and target versions
On Friday 08 July 2011 17:22:31 Richard Purdie wrote: On Fri, 2011-07-08 at 17:08 +0100, Paul Eggleton wrote: Yes, and I don't like it there either. Suggestions on fixing this would be welcome - in the time I spent trying to figure out why it wasn't working (some months ago) I couldn't find the cause. Ok, I'm not happy but I guess this can go as is for now. Paul: Can you open a bug against that being needed please? Done: http://bugzilla.pokylinux.org/show_bug.cgi?id=1231 Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ 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] combo-layer tool v3
On Tue, 2011-07-05 at 17:28 +0100, Paul Eggleton wrote: This is the third version of Yu Ke's combo-layer tool. Changes since v2: * Fix splitpatch so that it handles commits that only affect some of the components (reports the ones that have been skipped and avoids writing out empty patches) * A few fixes to the help text comments The following changes since commit f05b7ee7716d1e5cc1ba0bbab57e91c3a0569e9e: x-load: Update to 1.5.0 (2011-07-05 14:16:33 +0100) are available in the git repository at: git://git.openembedded.org/openembedded-core-contrib paule/combo-layer-v3 http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=paule/combo-layer-v3 Yu Ke (1): combo-layer-tool: add tool to manipulate combo layers Merged to master, thanks. Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] eglibc issuettes continued
On Fri, 2011-07-08 at 17:49 +0100, Richard Purdie wrote:
I'm guessing something is going wrong with prefixes somewhere. I'm
certainly not seeing the bulk of those locally...
I just realised that the gconv/locale ones are my fault; I had patched
do_install_locale() locally to try to fix a different problem and this
was causing that stuff to get left in ${D} rather than moved out of the
way. Sorry about that false report.
Are you seeing the libc-extra-nss and libc-thread-db warnings?
For things like /etc/rpc, I was wondering this morning whether we should
introduce some sort of FILES_NOT_WANTED kind of variable which could
declare the files that are being left deliberately unshipped. That
would avoid the need for adhoc do_install_append() { rm -rf } kind of
arrangements.
p.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 5/7] eglibc: fix installed but not packaged files
Thanks for clarifications. I will rework the patch to take out the rpc.
Nitin
-Original Message-
From: openembedded-core-boun...@lists.openembedded.org
[mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
Khem Raj
Sent: Thursday, July 07, 2011 2:41 PM
To: Patches and discussions about the oe-core layer
Subject: Re: [OE-core] [PATCH 5/7] eglibc: fix installed but not
packaged files
On Thu, Jul 7, 2011 at 1:42 PM, Phil Blundell p...@pbcl.net wrote:
On Thu, 2011-07-07 at 13:25 -0700, nitin.a.kam...@intel.com wrote:
-FILES_${PN} = ${libc_baselibs} ${libexecdir}/*
${@base_conditional('USE_LDCONFIG', '1', '${base_sbindir}/ldconfig
${sysconfdir}/ld.so.conf', '', d)}
+FILES_${PN} = ${libc_baselibs} ${libexecdir}/* ${sysconfdir}/rpc
${@base_conditional('USE_LDCONFIG', '1', '${base_sbindir}/ldconfig
${sysconfdir}/ld.so.conf', '', d)}
I don't think we want /etc/rpc in libc6, it's just a waste of space
if
you aren't using sunrpc. Nobody has missed it thus far so I would be
inclined to delete it, but it could go in a package of its own if
there
is a feeling that it's valuable.
Moreover sun rpc is now obsolete in glibc 2.14 onwards so probably
removing it from package is right thing to do.
p.
___
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
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/8] libc-package.bbclass: fix for non /usr/lib libdir case
On Thu, 2011-07-07 at 22:10 +0800, Yu Ke wrote:
if libdir is not /usr/lib, e.g. libdir=/usr/lib64, eglibc will
have build failure:
cross-localedef --uint32-align=4 --little-endian --force --old-style
--no-archive
--prefix=/home/kyu3/sdb/lib64/tmp/work/x86_64-poky-linux/eglibc-2.13-r2+svnr14157/locale-tree
--inputfile=/home/kyu3/sdb/lib64/tmp/work/x86_64-poky-linux/eglibc-2.13-r2+svnr14157/locale-tree//usr/share/i18n/locales/es_NI
--charmap=UTF-8
/home/kyu3/sdb/lib64/tmp/work/x86_64-poky-linux/eglibc-2.13-r2+svnr14157/locale-tree/usr/lib/locale/es_NI
NOTE: stdout:
NOTE:
NOTE: stderr:
NOTE: cannot write output files to `(null)': No such file or directory
ERROR: Function 'localedef returned an error' failed
the reason is that libc-package.bbclass has hard code /usr/lib. This patch
fix it by using libdir variable.
Signed-off-by: Yu Ke ke...@intel.com
---
meta/classes/libc-package.bbclass |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/classes/libc-package.bbclass
b/meta/classes/libc-package.bbclass
index 55e3d48..2ece9ae 100644
--- a/meta/classes/libc-package.bbclass
+++ b/meta/classes/libc-package.bbclass
@@ -300,8 +300,8 @@ python package_do_split_gconvs () {
raise bb.build.FuncFailed(unknown arch: +
target_arch + for locale_arch_options)
localedef_opts += --force --old-style --no-archive
--prefix=%s \
- --inputfile=%s/%s/i18n/locales/%s --charmap=%s
%s/usr/lib/locale/%s \
- % (treedir, treedir, datadir, locale, encoding,
treedir, name)
+ --inputfile=%s/%s/i18n/locales/%s --charmap=%s
%s%s/locale/%s \
+ % (treedir, treedir, datadir, locale, encoding,
treedir, libdir, name)
cmd = PATH=\%s\ I18NPATH=\%s\ GCONV_PATH=\%s\
cross-localedef %s % \
(path, i18npath, gconvpath, localedef_opts)
This must be against an older tree since Lianhao sent a patch for this
already?
Cheers,
Richard
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] eglibc issuettes continued
Richard, You can make similar patch for localtime, (which is a broken link), Otherwise I will send a patch for it. Nitin -Original Message- From: openembedded-core-boun...@lists.openembedded.org [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of Richard Purdie Sent: Friday, July 08, 2011 10:19 AM To: Patches and discussions about the oe-core layer Subject: Re: [OE-core] eglibc issuettes continued On Fri, 2011-07-08 at 09:59 -0700, Kamble, Nitin A wrote: I sent a patch to fix /etc/localtime /etc/rpc files. Other than that I am not seeing any issues for the eglibc recipe packaging. I pushed: http://git.openembedded.net/cgit.cgi/openembedded- core/commit/?id=93ce74a299832ca7f24b4ce1b951abffa0232612 to fix one of those. If there is still the localtime issue, we probably need a patch for that one... 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] eglibc issuettes continued
On Fri, 2011-07-08 at 10:22 -0700, Kamble, Nitin A wrote: You can make similar patch for localtime, (which is a broken link), Otherwise I will send a patch for it. Send the patch please. Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] eglibc issuettes continued
On Fri, 2011-07-08 at 09:59 -0700, Kamble, Nitin A wrote: I sent a patch to fix /etc/localtime /etc/rpc files. Other than that I am not seeing any issues for the eglibc recipe packaging. I pushed: http://git.openembedded.net/cgit.cgi/openembedded-core/commit/?id=93ce74a299832ca7f24b4ce1b951abffa0232612 to fix one of those. If there is still the localtime issue, we probably need a patch for that one... Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2 4/4] libx11: enable xcb support
[YOCTO #1196]
XCB support is needed in libx1l, it has been enabled in libx11-trim for
sometime and was not in full version. The usage here is for LSB testing,
which uses full libx11.
Signed-off-by: Saul Wold s...@linux.intel.com
---
meta/recipes-graphics/xorg-lib/libx11_1.3.4.bb | 11 ---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/meta/recipes-graphics/xorg-lib/libx11_1.3.4.bb
b/meta/recipes-graphics/xorg-lib/libx11_1.3.4.bb
index 3e046a1..04d4a97 100644
--- a/meta/recipes-graphics/xorg-lib/libx11_1.3.4.bb
+++ b/meta/recipes-graphics/xorg-lib/libx11_1.3.4.bb
@@ -5,7 +5,7 @@ LICENSE = MIT MIT-style BSD
LIC_FILES_CHKSUM = file://COPYING;md5=bf75bfe4d05068311b5e6862d4b5f2c5
PE = 1
-PR = r1
+PR = r3
SRC_URI += file://x11_disable_makekeys.patch \
file://nodolt.patch \
@@ -16,8 +16,13 @@ SRC_URI[md5sum] = f65c9c7ecbfb64c19dbd7927160d63fd
SRC_URI[sha256sum] =
88d7238ce5f7cd123450567de7a3b56a43556e4ccc45df38b8324147c889a844
DEPENDS += bigreqsproto xproto xextproto xtrans libxau xcmiscproto \
-libxdmcp xf86bigfontproto kbproto inputproto xproto-native
+libxdmcp xf86bigfontproto kbproto inputproto xproto-native libxcb
-EXTRA_OECONF += --without-xcb
+DEPENDS_virtclass-native += bigreqsproto-native xproto-native
xextproto-native xtrans-native libxau-native xcmiscproto-native \
+libxdmcp-native xf86bigfontproto-native kbproto-native
inputproto-native xproto-native
+
+XCB = --with-xcb
+XCB_virtclass-native = --without-xcb
+EXTRA_OECONF += ${XCB}
BBCLASSEXTEND = native nativesdk
--
1.7.3.4
___
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] [bug 1195] site/mips-common: Cache cvs_cv_func_printf_ptr
On 07/08/2011 09:31 AM, Richard Purdie wrote: On Thu, 2011-07-07 at 16:23 -0700, Jessica Zhang wrote: The following changes since commit c412674cf818e77e35857fb93353e392e7ac9e53: Khem Raj (1): package.bbclass,prserv.bbclass: Compare USE_PR_SERV with 1 or 0 are available in the git repository at: git://git.yoctoproject.org/poky-contrib jzhang/1195 http://git.yoctoproject.org/cgit.cgi//log/?h=jzhang/1195 Khem Raj (1): [bug 1195] site/mips-common: Cache cvs_cv_func_printf_ptr Merged to master, thanks. Late again and my fault this time but why is this in site/mips-common and not site/linux-common or glibc-common? -- Tom Rini Mentor Graphics Corporation ___ 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] [bug 1195] site/mips-common: Cache cvs_cv_func_printf_ptr
We only have arm-common, common, ix86-common, mips-common, powerpc-common, sh-common under site, no Linux-common or glibc-common, and it's defined in all the arches-common files except mips-common. Thanks, Jessica -Original Message- From: openembedded-core-boun...@lists.openembedded.org [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of Tom Rini Sent: Friday, July 08, 2011 11:37 AM To: openembedded-core@lists.openembedded.org Subject: Re: [OE-core] [PATCH 0/1] [bug 1195] site/mips-common: Cache cvs_cv_func_printf_ptr On 07/08/2011 09:31 AM, Richard Purdie wrote: On Thu, 2011-07-07 at 16:23 -0700, Jessica Zhang wrote: The following changes since commit c412674cf818e77e35857fb93353e392e7ac9e53: Khem Raj (1): package.bbclass,prserv.bbclass: Compare USE_PR_SERV with 1 or 0 are available in the git repository at: git://git.yoctoproject.org/poky-contrib jzhang/1195 http://git.yoctoproject.org/cgit.cgi//log/?h=jzhang/1195 Khem Raj (1): [bug 1195] site/mips-common: Cache cvs_cv_func_printf_ptr Merged to master, thanks. Late again and my fault this time but why is this in site/mips-common and not site/linux-common or glibc-common? -- Tom Rini Mentor Graphics Corporation ___ 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
[OE-core] [PATCH] eglibc: avoid copying ${libdir} twice if it's the same as ${base_libdir}
Otherwise the following mv ${libdir}/gconv fails because the destination
has already been created.
Signed-off-by: Phil Blundell ph...@gnu.org
---
meta/recipes-core/eglibc/eglibc-package.inc |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-core/eglibc/eglibc-package.inc
b/meta/recipes-core/eglibc/eglibc-package.inc
index 1c6626c..f29417f 100644
--- a/meta/recipes-core/eglibc/eglibc-package.inc
+++ b/meta/recipes-core/eglibc/eglibc-package.inc
@@ -91,9 +91,11 @@ inherit libc-common
do_install_locale () {
dest=${D}/${includedir}/eglibc-locale-internal-${MULTIMACH_TARGET_SYS}
install -d ${dest}${base_libdir} ${dest}${bindir} ${dest}${libdir}
${dest}${datadir}
- cp -fpPR ${D}${base_libdir}/* ${dest}${base_libdir}
+ if [ ${base_libdir} != ${libdir} ]; then
+ cp -fpPR ${D}${base_libdir}/* ${dest}${base_libdir}
+ fi
mv ${D}${bindir}/localedef ${dest}${bindir}
-mv ${D}${libdir}/gconv ${dest}${libdir}
+ mv ${D}${libdir}/gconv ${dest}${libdir}
cp -fpPR ${D}${libdir}/* ${dest}${libdir}
mv ${D}${datadir}/i18n ${dest}${datadir}
cp -fpPR ${D}${datadir}/* ${dest}${datadir}
--
1.7.4.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] eglibc issuettes continued
The reason for the bogus dependencies is that these files are landing in libc6-dev rather than the places where they ought to be: -rwxr-xr-x root/root 42592 2011-07-08 20:16 ./lib/libnss_nis.so.2 -rwxr-xr-x root/root 30408 2011-07-08 20:16 ./lib/libthread_db.so.1 -rwxr-xr-x root/root 50748 2011-07-08 20:16 ./lib/libnss_nisplus.so.2 I'm not quite sure what's going on there. The FILES look okay, so I wonder if perhaps it's an issue with symlink snapping. I'll investigate more over the weekend if I have some time. p. On Fri, 2011-07-08 at 09:59 -0700, Kamble, Nitin A wrote: I sent a patch to fix /etc/localtime /etc/rpc files. Other than that I am not seeing any issues for the eglibc recipe packaging. Nitin -Original Message- From: openembedded-core-boun...@lists.openembedded.org [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of Richard Purdie Sent: Friday, July 08, 2011 9:49 AM To: Patches and discussions about the oe-core layer Subject: Re: [OE-core] eglibc issuettes continued On Fri, 2011-07-08 at 16:41 +0100, Phil Blundell wrote: I'm not sure whether there are pending patches which will address these or not, but with a fresh pull from today I'm still not getting very good packaging for eglibc 2.13. Specifically: WARNING: For recipe eglibc, the following files were installed but not shipped in any package: WARNING: /etc/localtime WARNING: /etc/rpc WARNING: /etc/ld.so.conf WARNING: /lib/gconv/ISO-2022-CN-EXT.so WARNING: /lib/gconv/IBM921.so [... etc ...] WARNING: /lib/gconv/.debug/ISO-2022-CN-EXT.so WARNING: /lib/gconv/.debug/IBM921.so [... etc ...] WARNING: /share/i18n/charmaps/ISO-8859-15.gz WARNING: /share/i18n/charmaps/IBM285.gz [... etc ...] WARNING: /share/i18n/locales/ss_ZA WARNING: /share/i18n/locales/is_IS [... etc ...] WARNING: QA Issue: libc-extra-nss rdepends on eglibc-dev WARNING: QA Issue: libc-thread-db rdepends on eglibc-dev ERROR: QA run found fatal errors. Please consider fixing them. I'm not sure if these are actually new or not, though. It's possible that they've been there for ages and I only just noticed. I'm guessing something is going wrong with prefixes somewhere. I'm certainly not seeing the bulk of those locally... 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 ___ 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] powertop: inherit update-alternatives and use a higher priority than busybox
Op 8 jul. 2011 om 18:43 heeft Richard Purdie richard.pur...@linuxfoundation.org het volgende geschreven: On Fri, 2011-07-08 at 16:57 +0100, Koen Kooi wrote: Op 8 jul. 2011 om 16:00 heeft Richard Purdie richard.pur...@linuxfoundation.org het volgende geschreven: On Fri, 2011-07-08 at 08:25 +0100, Koen Kooi wrote: Op 8 jul. 2011 om 02:40 heeft Cui, Dexuan dexuan@intel.com het volgende geschreven: Tom Rini wrote: On 07/07/2011 01:39 AM, Dexuan Cui wrote: busybox-1.18.4 installs /bin/powertop and the powertop recipe installs /usr/bin/powertop. So, in PATH, if /bin appears before /usr/bin, we would run the version offered by busybox, which has a very limited function (e.g., no parameter is accepted) and this causes trouble to eclipse plugin. We can use update-alternatives for powertop with higher priority to resolve the issue. Fixes [YOCTO #1208] Signed-off-by: Dexuan Cui dexuan@intel.com This fix seems a bit incomplete. Why is busybox putting powertop into /bin when it almost certainly belongs in /usr/bin like the real recipe was placing it. busybox needs a fix here too. Thanks for the comment! I was hesitant about fixing busybox as I wasn't sure if it's worthy to make a patch to only fix the path for busybox. I don't know why busybox puts it into /bin. I think the best place may be /usr/sbin/. A little unluckily this patch to powertop has been already in poky master... So maybe we could try to fix the recipes in future, e.g., when upgrading them. we should do the right thing in oe-core, the poky people can clean up on their own. I don't think anyone is suggesting we shouldn't do the right thing in OE-Core? :) I merged the original patch on the grounds that its was an improvement to the situation. We've identified a better improvement so can someone please send me the patch and I'll likely merge that too. the email makes it seem that the patch was merged into poky, but not oe-core. When reading it like that the proposal involved merging the 'incomplete' patch for the sake of keeping poky and oe-core in sync The OE-Core component of Poky always stays in sync now... I realized that later, I'm way too tired to think properly. sorry about the fuss 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] eglibc issuettes continued
Op 8 jul. 2011 om 19:19 heeft Richard Purdie richard.pur...@linuxfoundation.org het volgende geschreven: On Fri, 2011-07-08 at 09:59 -0700, Kamble, Nitin A wrote: I sent a patch to fix /etc/localtime /etc/rpc files. Other than that I am not seeing any issues for the eglibc recipe packaging. I pushed: http://git.openembedded.net/cgit.cgi/openembedded-core/commit/?id=93ce74a299832ca7f24b4ce1b951abffa0232612 to fix one of those. If there is still the localtime issue, we probably need a patch for that one... iirc we don't use the libc localtime, but another in .dev, but I can't check that right now. fwiw having a image function to change the localtime would be nice to have, but is a different issue 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/1] [bug 1195] site/mips-common: Cache cvs_cv_func_printf_ptr
I have a crude merged version of siteinfo.bbclass in meta-oe, any volunteers to have à look at the differences? Op 8 jul. 2011 om 21:07 heeft Zhang, Jessica jessica.zh...@intel.com het volgende geschreven: We only have arm-common, common, ix86-common, mips-common, powerpc-common, sh-common under site, no Linux-common or glibc-common, and it's defined in all the arches-common files except mips-common. Thanks, Jessica -Original Message- From: openembedded-core-boun...@lists.openembedded.org [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of Tom Rini Sent: Friday, July 08, 2011 11:37 AM To: openembedded-core@lists.openembedded.org Subject: Re: [OE-core] [PATCH 0/1] [bug 1195] site/mips-common: Cache cvs_cv_func_printf_ptr On 07/08/2011 09:31 AM, Richard Purdie wrote: On Thu, 2011-07-07 at 16:23 -0700, Jessica Zhang wrote: The following changes since commit c412674cf818e77e35857fb93353e392e7ac9e53: Khem Raj (1): package.bbclass,prserv.bbclass: Compare USE_PR_SERV with 1 or 0 are available in the git repository at: git://git.yoctoproject.org/poky-contrib jzhang/1195 http://git.yoctoproject.org/cgit.cgi//log/?h=jzhang/1195 Khem Raj (1): [bug 1195] site/mips-common: Cache cvs_cv_func_printf_ptr Merged to master, thanks. Late again and my fault this time but why is this in site/mips-common and not site/linux-common or glibc-common? -- Tom Rini Mentor Graphics Corporation ___ 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 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 4/7] binutils: package unpackaged files
-Original Message-
From: openembedded-core-boun...@lists.openembedded.org
[mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
Phil Blundell
Sent: Friday, July 08, 2011 8:34 AM
To: Patches and discussions about the oe-core layer
Subject: Re: [OE-core] [PATCH 4/7] binutils: package unpackaged files
On Fri, 2011-07-08 at 16:26 +0100, Richard Purdie wrote:
@@ -35,11 +35,13 @@ FILES_${PN}-symlinks = \
${bindir}/c++filt \
${bindir}/gprof \
${bindir}/ld \
+ ${bindir}/ld.bfd \
${bindir}/nm \
${bindir}/objcopy \
${bindir}/objdump \
${bindir}/ranlib \
${bindir}/readelf \
+ ${bindir}/elfedit \
${bindir}/size \
${bindir}/strip
Nitin, do you know if the ld.bfd above is a hardlinked copy of ld?
If you're getting ld.bfd at all (at least with our current recipes)
then
it probably means that ${bindir}/ld is gold. So in that case they
oughtn't to be symlinked.
Just verified that ld.bfd is a soft link to i586-poky-linux-ld.bfd
So what is the right think here, rm -f ld.bfd, or putting it in the symlinks
package is good?
Nitin
p.
___
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 4/7] binutils: package unpackaged files
On Fri, 2011-07-08 at 14:15 -0700, Kamble, Nitin A wrote:
Just verified that ld.bfd is a soft link to i586-poky-linux-ld.bfd
So what is the right think here, rm -f ld.bfd, or putting it in the symlinks
package is good?
Do the same thing that you do with ${bindir}/ld, whatever that is.
Hopefully it isn't rm -f :-)
p.
___
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] kernel.bbclass: handle embedding of initramfs images
On Fri, Jul 8, 2011 at 5:38 PM, Darren Hart dvh...@linux.intel.com wrote: On 07/07/2011 04:11 PM, Andrea Adami wrote: * from org.openembedded.dev (oe-classic) Hi Andrea, Please include a descriptive blurb about the patch. When people read through the commit log they need to know what problem this patch addresses and how it intends to go about it. If possible, it should also include the commit id from the source (I suspect that isn't an option here). Well, there isn't really much to say: whether you know what an initramfs is or not :) Seriously, about the history of the patch, there have been so many commits that I could not choose one. See next comment. Hrm... Why is this part of do_configure? Seems a lot more like a deploy or install step. If you look at the history at http://cgit.openembedded.org/cgit.cgi/openembedded/log/classes/kernel.bbclass?h=org.openembedded.devofs=50 you'll discover that there was a separate task (72761e4) which has been unified by the author as of commit 3e3f297. After some rounds of fixes, the code was moved in do_configure with commit id fc03e2b (kernel.bbclass: move initramfs stuff to configure so we can do postprocessing on it with do_configure_append). Also, the cp line has been truncated here. The original patch sent by git send.email should be sane. -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel Regards Andrea ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/1] bb-matrix performance metrics gathering and visualization scripts
Add bb-matrix.sh and bb-matrix-plot.sh. Example output of these scripts is viewable here: https://wiki.yoctoproject.org/wiki/Build_Performance#bb-matrix The following changes since commit 9f4eaeef33da5595748253d59d95c7ca548e28fa: libx11: enable xcb support (2011-07-08 23:02:08 +0100) are available in the git repository at: git://git.pokylinux.org/poky-contrib dvhart/bb-perf http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=dvhart/bb-perf Darren Hart (1): bb-matrix: initial scripts to record TIME(1) metrics for BB and PM combinations scripts/contrib/bb-perf/bb-matrix-plot.sh | 137 + scripts/contrib/bb-perf/bb-matrix.sh | 78 2 files changed, 215 insertions(+), 0 deletions(-) create mode 100755 scripts/contrib/bb-perf/bb-matrix-plot.sh create mode 100755 scripts/contrib/bb-perf/bb-matrix.sh ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
