Re: [OE-core] [RFC][PATCH] sysvinit: make pidof usuable in a standalone setting
On Tue, 2011-05-31 at 10:27 +0200, Koen Kooi wrote:
No comments at all?
Patience ;-). It was a US/UK holiday yesterday and lots of people have
been taking a long weekend. Personally, whilst I did merge a few things
yesterday, this one didn't look that urgent so its on today's to look at
and reply to list.
Op 28 mei 2011, om 13:21 heeft Koen Kooi het volgende geschreven:
Currently it's a symlink to killall5:
$ dpkg-deb -c sysvinit-pidof_2.88dsf-r1_armv7a.ipk | grep pidof
lrwxrwxrwx root/root 0 2011-05-27 11:05 ./bin/pidof.sysvinit -
/sbin/killall5
The point of the pidof subpackage was to have a pidof without
needing sysvinit, this restores that behaviour. The trade-off is a
14KiB (armv7a, uncompressed) increase in size.
Signed-off-by: Koen Kooi k...@dominion.thruhere.net
---
The alternative is to just move 'killall5' into the pidof subpackage and to
RDPEPENDS_${PN} += ${PN}-pidof
I think I prefer the alternative to duplicating binaries...
Cheers,
Richard
The change in this patch was the least amounts of edits to the recipe, let
me know which way you prefer.
meta/recipes-core/sysvinit/sysvinit_2.88dsf.bb |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-core/sysvinit/sysvinit_2.88dsf.bb
b/meta/recipes-core/sysvinit/sysvinit_2.88dsf.bb
index 7d5e936..f0e73bb 100644
--- a/meta/recipes-core/sysvinit/sysvinit_2.88dsf.bb
+++ b/meta/recipes-core/sysvinit/sysvinit_2.88dsf.bb
@@ -5,7 +5,7 @@ SECTION = base
LICENSE = GPLv2+
LIC_FILES_CHKSUM = file://COPYING;md5=751419260aa954499f7abaabaa882bbe \
file://COPYRIGHT;endline=15;md5=349c872e0066155e1818b786938876a4
-PR = r1
+PR = r2
# USE_VT and SERIAL_CONSOLE are generally defined by the MACHINE .conf.
# Set PACKAGE_ARCH appropriately.
@@ -100,7 +100,7 @@ EOF
ln -s ../init.d/stop-bootlogd
${D}${sysconfdir}/rc$level.d/S99stop-bootlogd
done
mv ${D}${base_sbindir}/init
${D}${base_sbindir}/init.${PN}
- mv ${D}${base_bindir}/pidof ${D}${base_bindir}/pidof.${PN}
+ cp ${D}${base_sbindir}/killall5 ${D}${base_bindir}/pidof.${PN}
mv ${D}${base_sbindir}/halt ${D}${base_sbindir}/halt.${PN}
mv ${D}${base_sbindir}/reboot ${D}${base_sbindir}/reboot.${PN}
mv ${D}${base_sbindir}/shutdown ${D}${base_sbindir}/shutdown.${PN}
--
1.6.6.1
___
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] all architecture packages
Hi, There have been various comments on the list and in the bugzilla about issues with all architecture recipes. To start cleaning this up I've merged: http://git.openembedded.net/cgit.cgi/openembedded-core/commit/?id=26e5e5feb695864b11e47e24017e254c28f14494 which creates an allarch class and starts to convert some recipes over to using it. There is further information in the commit message. Use of the class ensures the packages really are suitable for all architectures and that the sstate packages are reusable. The list of packages which still need attention are: meta/recipes-connectivity/resolvconf/resolvconf_1.48.bb meta/recipes-devtools/update-alternatives/update-alternatives-dpkg.inc meta/recipes-gnome/gnome/gnome-common_2.28.0.bb meta/recipes-gnome/gnome/gnome-icon-theme_2.31.0.bb meta/recipes-gnome/hicolor-icon-theme/hicolor-icon-theme_0.12.bb meta/recipes-graphics/ttf-fonts/liberation-fonts_1.04.bb meta/recipes-graphics/ttf-fonts/liberation-fonts_1.06.bb meta/recipes-graphics/ttf-fonts/ttf-bitstream-vera_1.10.bb meta/recipes-graphics/xcursor-transparent-theme/xcursor-transparent-theme_0.1.1.bb meta/recipes-graphics/xorg-font/encodings_1.0.4.bb meta/recipes-graphics/xorg-font/font-alias_1.0.3.bb meta/recipes-graphics/xorg-font/font-util_1.2.0.bb meta/recipes-graphics/xorg-font/xorg-font-common.inc meta/recipes-graphics/xorg-font/xorg-minimal-fonts.bb meta/recipes-kernel/linux-firmware/linux-firmware_git.bb meta/recipes-sato/sato-icon-theme/sato-icon-theme.inc meta/recipes-sato/sato-icon-theme/sato-icon-theme_0.4.1.bb meta/recipes-support/hal/hal-info.inc Some of these are easy, some trigger configure tests for the cross compiler and are harder to fix. If a package can't use allarch.bbclass, its a strong indicator it shouldn't be PACKAGE_ARCH = all... Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [poky] [PATCH 0/7] User/group creation at preinstall
On Tue, 2011-05-31 at 12:51 -0700, Scott Garman wrote: On 05/31/2011 12:06 PM, Saul Wold wrote: On 05/31/2011 11:45 AM, Koen Kooi wrote: Shouldn't patches like this be sent to the oe-core list? It wouldn't have saved me from the selinux bug in shadow, though :) Scott, I would agree with Koen, this is a oe-core change, not a Poky only change, please resend this request to the oe-core list. Sure, I'll resend it to oe-core. That said, I have no idea what criteria should be used to determine which list to send things to, and I'm sure I'm not the only one. Is this documented anywhere? We're trying to make this simpler over time: bitbake changes - bitbake-devel Any code in oe-core - oe-core list Anything in poky not in oe-core/bitbake - poky list Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [FIX] update mtd-utils to 1.4.4
On Wed, 2011-06-01 at 13:30 +0200, Andrea Adami wrote:
On Fri, Apr 22, 2011 at 10:44 AM, Andrea Adami andrea.ad...@gmail.com wrote:
Hello,
mtd-utils_1.4.1 is broken, in fact whole 1.4.X serie was plagued by
mtd alignment bug until 1.4.4.
See: http://lists.infradead.org/pipermail/linux-mtd/2011-April/034599.html
Updated in oe-dev with commit f8e1b7793ff5b02fd27ce886b34a57c6c2358239.
Regards
Andrea
BUMP
I'll add that the recipe in oe-classic has a different, more grained,
packaging
PACKAGES =+ mkfs-jffs2 mkfs-ubifs
FILES_mkfs-jffs2 = ${sbindir}/mkfs.jffs2
FILES_mkfs-ubifs = ${sbindir}/mkfs.ubifs
Please pick it in oe-core, thx
How about sending some 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] [RFC v1 PATCH 00/16] populate perl-native into its own directory
Hi Dexuan,
On Wed, 2011-06-01 at 21:18 +0800, Dexuan Cui wrote:
Currently both perl-native (a.k.a. ${STAGING_BINDIR_NATIVE}/perl )and
perl-native-runtime(a.k.a. the system perl, or /usr/bin/perl) appear in
the PATH when bitbake is running.
This can cause some race conditions: many places detecting perl from PATH
can't make sure which path will be used as this depends on when perl-native's
populate_sysroot is finished, e.g., automake-native and autoconf-native could
use perl-native-runtime while gnu-config-native could use perl-native and
this inconsistent usages can cause trouble, e.g., bug 941.
And, as RP suggested, the time to use perl-native instead of
perl-native-runtime is where any perl module is being built, perl itself is
being built or anything that has an explicit dependency on the perl version
present.
So I made the following changes to try to address the aboves issues:
1) populate perl-native into its own directory so it won't appear in PATH
by default, and add perlnative.bbclass for these recipes that really depend
on perl-native;
2) check all perl-native references and correct the ones that should be
perl-native-runtime;
3) fix any building issues due to the new location of perl-native,
especially cpan and cpan-base .bbclass.
With the changes, bug 941 doesn't appear.
Tests I did are:
I tried bitbale core-image-sato-sdk and meta-toolchain-gmae in x86_32 and
x86_64 Ubuntu hosts and everything seems building fine.
Please review the changes and comment on them. Thanks!
I had a look through the series and it looks good to me. Hopefully this
addresses the perl issues people have been seeing once and for all (and
unclogs the dependencies a little) :)
I'm going to leave this on the mailing list for a while to give others a
chance to review it though.
Cheers,
Richard
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Tell me your build error message annoyances!
On Wed, 2011-06-01 at 16:06 +0100, Phil Blundell wrote: On Tue, 2011-05-31 at 15:26 -0700, Scott Garman wrote: I'd like to collect some feedback on error messages while building that you find confusing/annoying/unhelpful. I'm going to be working on trying to improve the situation and would like to hear from you about what could be more helpful. Funnily enough we were just having a discussion about this on irc. My personal top two least favourite diagnostics are: a) bitbake -b nonexistent-file gives ten lines of so of python exception traceback and then prints MultipleMatches. b) bitbake -b recipe.bb, with a recipe that skips (due to an inCOMPATIBLE_MACHINE or whatever) gives the traditional ten lines of traceback spew and then prints TypeError: 'NoneType' object is not iterable. This is with bitbake 1.13.0. Agreed, these are issues. I'd like to highlight that there is an underlying design issue in bitbake which make these hard issues to fix. Its very hard for bitbake to work out when it needs to show the traceback and when it doesn't. If the user has been given an explanation of the problem we shouldn't show the traceback but its hard to know that is the case. Somehow we therefore need to improve the error infrastructure in bitbake to be able to tell the difference between an unexpected error where a traceback is useful and a known error which has been explained to the user and no traceback is required. 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 PULL 00/32] 1-June-2011 Request
On Tue, 2011-05-31 at 23:21 -0700, Saul Wold wrote: This contains a few patches from the community, along with a batch of updates and bug fixes from me. This includes the patch I submitted for the beagleboard qt4-x11-free failure. This has been built via world. The following changes since commit 26e5e5feb695864b11e47e24017e254c28f14494: Improve handling of 'all' architecture recipes and their interaction with sstate (2011-05-31 12:56:38 +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 I merged this apart from: Saul Wold (27): libiconv: update to 1.13.1 Due to feedback from Khem. update-alternatives-dpkg update to 1.16.0.3 chkconfig: update to 1.3.52 mailx: update to 12.5 mc: update to 4.7.5.2 msmtp: update tof 1.4.24 gthumb: update to 2.12.3 alsa-tools: update to 1.0.24.1 qmmp: update to 0.5.1 rxvt-unicode: update to 9.11 gnutls: update to 2.12.5 distro tracking: updates bitbake.conf: Create static-dev pacakge for static libraries Due to feedback from me. tcmode-default: disable ARMv7 Optimization for qt4-x11-free Again, I'm not sure this is the right approach and it sounds like there is a patch around for this issue for gcc. 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 v1 PATCH 00/16] populate perl-native into its own directory
On Wed, 2011-06-01 at 10:17 -0700, Tom Rini wrote:
On 06/01/2011 06:18 AM, Dexuan Cui wrote:
Currently both perl-native (a.k.a. ${STAGING_BINDIR_NATIVE}/perl )and
perl-native-runtime(a.k.a. the system perl, or /usr/bin/perl) appear in
the PATH when bitbake is running.
This can cause some race conditions: many places detecting perl from PATH
can't make sure which path will be used as this depends on when
perl-native's
populate_sysroot is finished, e.g., automake-native and autoconf-native
could
use perl-native-runtime while gnu-config-native could use perl-native and
this inconsistent usages can cause trouble, e.g., bug 941.
And, as RP suggested, the time to use perl-native instead of
perl-native-runtime is where any perl module is being built, perl itself is
being built or anything that has an explicit dependency on the perl version
present.
So I made the following changes to try to address the aboves issues:
1) populate perl-native into its own directory so it won't appear in PATH
by default, and add perlnative.bbclass for these recipes that really depend
on perl-native;
2) check all perl-native references and correct the ones that should be
perl-native-runtime;
3) fix any building issues due to the new location of perl-native,
especially cpan and cpan-base .bbclass.
With the changes, bug 941 doesn't appear.
Tests I did are:
I tried bitbale core-image-sato-sdk and meta-toolchain-gmae in x86_32 and
x86_64 Ubuntu hosts and everything seems building fine.
How does this work (by which I mean, test some please :)) with meta-oe
where we have (or will have soon) a lot of perl module recipes? My
concern is that we've just moved the race around a bit and we'll hit
this somewhere else where we both really need perl-native (since we
need some cpan stuff we've built) and also mangle in the perl we found
in PATH into some scripts...
Anything building or using perl modules should be inheriting the
perlnative class. This adds the dependency on perl-native and the
appropriate PATH entry. Where is the race?
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/3] gnutls: link against 'dl' library
On Thu, 2011-06-02 at 08:31 +0200, Martin Jansa wrote:
what do you have in configlog for LIBDL?
here it's all empty
LIBDL=''
LIBDL_PREFIX=''
LTLIBDL=''
if I add
+ --with-libdl-prefix=${STAGING_DIR_HOST}${prefix} \
+ --with-libpthread-prefix=${STAGING_DIR_HOST}${prefix} \
to EXTRA_OE_CONF (we already have couple of --with-*-prefix there) it's
found correctly (and this is at least better workarround then forcing
-ldl directly to LDFLAGS):
LIBDL='/OE/shr-core/tmp/sysroots/om-gta02/usr/lib/libdl.so'
LIBDL_PREFIX='/OE/shr-core/tmp/sysroots/om-gta02/usr'
LTLIBDL='-L/OE/shr-core/tmp/sysroots/om-gta02/usr/lib -ldl'
same problem is with libpthread..
maybe their m4/lib-link.m4 does something wrong in
AC_DEFUN([AC_LIB_HAVE_LINKFLAGS],
[
AC_REQUIRE([AC_LIB_PREPARE_PREFIX])
AC_REQUIRE([AC_LIB_RPATH])
I just looked at the code in lib/configure and concluded that its just
luck whether it figures out the correct values or does something really
nasty. Its poking about ${libdir} for this stuff so you end up with
something like the following combinations:
a) 64 bit system with 64 bit libs in /usr/lib64 and no 32 bit libs:
Finds no -ldl
Something else may or may not link it indirectly so the build may or
may not work.
b) 64 bit system with 64 bit libs in /usr/lib64 and 32 bit libs in /usr/lib,
building for 32 bit:
Finds a -ldl which works.
Things appear to work.
c) Other variations
The correct fix would appear to be to set the paths specifically using
the options Martin mentions 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] [CONSOLIDATED PULL 00/12] 2-June-2011
On Thu, 2011-06-02 at 01:04 -0700, Saul Wold wrote: Pulling a number of patches and updates from the list, they have been built on the autobuild. This has the gcc fix for qt4-x11-free in the form of a gcc patch The following changes since commit 0a496df0209c93fd00ea929b5f27faa1a6e600c0: clutter-1.6: Add patch to update gettext macro version (2011-06-01 18:32:30 +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 Jingdong Lu (1): libx11: fix libX11 keysyms to pass xts5 of lsb Kang Kai (1): task-core-lsb: add cups and ghostscript into image Koen Kooi (3): u-boot: package up u-boot.bin for field upgrades shadow: remove selinux entry from pam.d/login avahi: enable service when using systemd Nitin A Kamble (4): gettext-0.16.1: mark upstream status for gplv2 recipe's patches Phil Blundell (1): rootfs_ipk: delete opkg metadata if package management not required and all packages are configured I merged the above. m4: upgrade from 1.4.15 to 1.4.16 Khem asked what the license change was here and it should have been mentioned in the commit message. autoconf: upgrade from 2.65 to 2.68 Not pulled as likely dependent on the above. bison: upgrade from 2.4.3 to 2.5 Likewise. Saul Wold (2): ghostscript: Fix up file locations and add i686 Why did this need the location fixups? Something sounds wrong here and needs digging into. gcc: Fix volatile access issue for ARM I merged 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] [PATCH 0/2] Upstream-status -- Upstream-Status and a fix to send-pull-request
On Thu, 2011-06-02 at 16:17 +0800, Dexuan Cui wrote: Upstream-status -- Upstream-Status: As a keyword, it's case sensitive, so let's fix the lowercase s here. The fix to send-pull-request: I don't know why othes doesn't complain about this, but without this patch, the script can't run properly in my side. Thanks, -- Dexuan The following changes since commit 484c4e73245c93a08413cd204513bf5c5698b994: clutter-1.6: Add patch to update gettext macro version (2011-06-01 18:34:37 +0100) are available in the git repository at: git://git.pokylinux.org/poky-contrib dcui/master http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=dcui/master Dexuan Cui (2): recipes: Upstream-status -- Upstream-Status: for multiple patches send-pull-request: fix a small typo that fails the script 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] rpm: avoid dependency on perl and python for -native build
On Thu, 2011-06-02 at 10:48 +0100, Phil Blundell wrote: Update override naming (_native - _virtclass-native) to disable perl and python bindings when building native rpm, and adjust the DEPENDS to match. Perl bindings were, in fact, already disabled for both native and target builds so it's only the python ones that have really changed. Signed-off-by: Phil Blundell ph...@gnu.org --- 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] gnutls: add --with-libdl-prefix and --with-libpthread-prefix
On Thu, 2011-06-02 at 13:00 +0200, Martin Jansa wrote:
Signed-off-by: Martin Jansa martin.ja...@gmail.com
---
meta/recipes-support/gnutls/gnutls.inc |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/meta/recipes-support/gnutls/gnutls.inc
b/meta/recipes-support/gnutls/gnutls.inc
index 9f8d81b..03aed6a 100644
--- a/meta/recipes-support/gnutls/gnutls.inc
+++ b/meta/recipes-support/gnutls/gnutls.inc
@@ -22,6 +22,8 @@ inherit autotools binconfig pkgconfig gettext
EXTRA_OECONF=--with-included-opencdk --with-included-libcfg --disable-rpath
\
--with-libtasn1-prefix=${STAGING_DIR_HOST}${prefix} \
--with-libgcrypt
--with-libgcrypt-prefix=${STAGING_DIR_HOST}${prefix} \
+ --with-libdl-prefix=${STAGING_DIR_HOST}${prefix} \
+ --with-libpthread-prefix=${STAGING_DIR_HOST}${prefix} \
--with-lzo --disable-guile \
do_configure_prepend() {
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] dbus: avoid dependency on x11 for -native build
On Thu, 2011-06-02 at 10:15 +0100, Phil Blundell wrote:
The native variant already configures --without-x so the X11 libs are
redundant. Adjust the DEPENDS to match.
Signed-off-by: Phil Blundell ph...@gnu.org
---
meta/recipes-core/dbus/dbus.inc |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-core/dbus/dbus.inc b/meta/recipes-core/dbus/dbus.inc
index fb2f6d4..5f9a8a3 100644
--- a/meta/recipes-core/dbus/dbus.inc
+++ b/meta/recipes-core/dbus/dbus.inc
@@ -5,8 +5,11 @@ SECTION = base
LICENSE = AFL-2 | GPLv2+
LIC_FILES_CHKSUM = file://COPYING;md5=10dded3b58148f3f1fd804b26354af3e \
file://dbus/dbus.h;firstline=6;endline=20;md5=6eea2e0c7750dd8e620dcb1437312fa5
-DEPENDS = expat virtual/libintl virtual/libx11 libsm
-DEPENDS_virtclass-nativesdk = expat virtual/libintl virtual/libx11
+x11deps = virtual/libx11 libsm
+basedeps = expat virtual/libintl
+DEPENDS = ${basedeps} ${x11deps}
+DEPENDS_virtclass-native = ${basedeps}
+DEPENDS_virtclass-nativesdk = ${basedeps} virtual/libx11
SRC_URI = http://dbus.freedesktop.org/releases/dbus/dbus-${PV}.tar.gz \
file://tmpdir.patch; \
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] [RFC v1 PATCH 00/16] populate perl-native into its own directory
On Wed, 2011-06-01 at 13:59 -0700, Tom Rini wrote: On 06/01/2011 01:45 PM, Phil Blundell wrote: On Wed, 2011-06-01 at 13:42 -0700, Tom Rini wrote: What falls down in this case is that once perl-native is built (and in our PATH), if it's a different version than system-wide perl, stuff starts failing on version mis-match. I think that's the bit that I'm not properly understanding. Which versions are mismatching, exactly? Surely the local perl from the sysroot ought to be completely self-contained and shouldn't be using any bits from the host perl install at that point. So this jogs my memory a bit! It's not so much perl itself but stuff that uses perl that can get dirty and then no, you have stuff thats built for system perl and stuff that's built with perl-native clashing. Relying even more on memory, I think help2man was one of the easy culprits and since we also modify the env, we do things like have help2man run with PERL5LIB and so on pointing system-wide perl at perl-native's lib directory and so forth. But with the proposed patch series either: a) help2man depends perlnative.bbclass In this case it can depend on perl-native being there, its in path and things work as per OE.dev. b) help2man doesn't depend in perlnative.bbclass It only sees the system perl. So I'm still not clear where the problem is? 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 PULL 00/12] 2-June-2011
On Thu, 2011-06-02 at 07:57 -0700, Saul Wold wrote: Not pulled as likely dependent on the above. bison: upgrade from 2.4.3 to 2.5 Likewise. Saul Wold (2): ghostscript: Fix up file locations and add i686 Why did this need the location fixups? Something sounds wrong here and needs digging into. So what I changed was to move the architecture header files (in architecture directories) into the ghostscript directory instead of being in the top level of the recipe directory. I also need to add an i686 directory in addition to the i586 directory, if there is a way to map this for the native then more digging is needed. This is required to build ghostscript-native. Sorry, I misread this diff. What you've done is what I'd have expected was needed and I'm find with that. I've merged it. 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] eglibc: fix mispackaging of libcidn
On Thu, 2011-06-02 at 13:15 +0100, Phil Blundell wrote:
The glob for libc_baselibs was too permissive, causing some of the libcidn
symlinks to be placed in ${PN} rather than the intended subpackage. Worse,
the .so itself was actually landing in ${PN}-dev, so the net effect was to
make libc6-dev a dependency of libc6.
Bump PRs for both 2.12 and 2.13 as a result.
Signed-off-by: Phil Blundell ph...@gnu.org
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] [RFC v1 PATCH 00/16] populate perl-native into its own directory
On Thu, 2011-06-02 at 09:28 -0700, Tom Rini wrote:
On 06/02/2011 07:37 AM, Phil Blundell wrote:
On Thu, 2011-06-02 at 07:25 -0700, Tom Rini wrote:
But help2man is just the easy/common case. Heck, it _may_ blow up even
with the host help2man instead of help2man-native, if a recipe uses
system-wide help2man and perlnative.bbclass. The root problem (again,
from memory) is that since we modify PERL5LIB and so on, when we do
that, we've opened ourselves up for system-wide perl trying to use
perl-native's stuff.
Ah right, I think I see what you're getting at now.
If we've got a clean separation between perl-native and host perl,
though, can't we now just eliminate all of that futzing with PERL5LIB in
cpan.bbclass and such like places? perl-native already knows how to
look in the right places within the sysroot for its modules so there
should be no need for anything else to be overriding it.
Well, my question is, does it, really?
If it doesn't it really does need to get fixed. I've not seen any
evidence this has been the problem but it still could be.
Even if we're using the sstate
cache from /foo/oecore/tmp over in /bar/oecore/tmp (and /foo/oecore/tmp
is rm -rf'd) ? Since we've got a create_wrapper around perl and
perl${PV} it should be I suppose (or is easily added there), but I'd
feel a lot better with some testing of the above case (and the updates
to cpan*bbclass).
I only took the perl-native DEPENDS patch on the condition this gets
fixed properly. The patches that are there look to do that, at least for
OE-Core. If there are further issues we're going to have to take them as
they arise as I have an objection to crippling the build dependencies
because perl is broken. Really this could use some TLC from someone with
experience in the area...
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/3] busybox: enable mdev by default
On Wed, 2011-06-01 at 20:40 +, Otavio Salvador wrote: On Wed, Jun 1, 2011 at 20:37, Phil Blundell p...@pbcl.net wrote: On Wed, 2011-06-01 at 20:09 +, Otavio Salvador wrote: -# CONFIG_MDEV is not set +CONFIG_MDEV=y Per previous discussion, I am still uneasy about this change. I think we really need some sort of coherent policy for what exactly the default busybox configuration in oe-core is meant to be doing, and then (if necessary) a set of patches to make it match the policy. Just flipping random features on and off does not seem like a good way to proceed. OE-core has support to mdev as device handling mechanism as such this ought to be enabled by default IMO. Personally it doesn't matter since I have already overriden it in my internal layer. I'm afraid I'm with Phil on this. I don't like the idea of enabling something we don't actually use. This really needs to become some kind of configure option which would at the same time disable/replace udev so the patch in its currently form isn't acceptable. 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/3] qmake_base.bbclass: fix lrelease/lupdate binary names
On Thu, 2011-06-02 at 17:51 +0100, Paul Eggleton wrote:
On Wednesday 01 June 2011 21:09:54 Otavio Salvador wrote:
To support translation, qmake based projects usually call lrelease and
lupdate however OE changes the binary names so this needs some mangle
to work out of box.
Signed-off-by: Otavio Salvador ota...@ossystems.com.br
---
meta/classes/qmake_base.bbclass |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/meta/classes/qmake_base.bbclass
b/meta/classes/qmake_base.bbclass index a054efd..165d689 100644
--- a/meta/classes/qmake_base.bbclass
+++ b/meta/classes/qmake_base.bbclass
@@ -92,6 +92,11 @@ qmake_base_do_configure() {
bbnote qmake prevar substitution: ${EXTRA_QMAKEVARS_PRE}
fi
+ # Hack .pro files to use OE utilities
+ find -name '*.pro' \
+-exec sed -i -e 's,=\s*.*/lrelease,= ${OE_QMAKE_LRELEASE},g' \
+ -e 's,=\s*.*/lupdate,= ${OE_QMAKE_LUPDATE},g' '{}' ';'
+
#bbnote Calling '${OE_QMAKE_QMAKE} -makefile -spec ${QMAKESPEC} -o
Makefile $QMAKE_VARSUBST_PRE $AFTER $PROFILES $QMAKE_VARSUBST_POST' unset
QMAKESPEC || true
${OE_QMAKE_QMAKE} -makefile -spec ${QMAKESPEC} -o Makefile
$QMAKE_VARSUBST_PRE $AFTER $PROFILES $QMAKE_VARSUBST_POST || die Error
calling ${OE_QMAKE_QMAKE} on $PROFILES
Acked-by: Paul Eggleton paul.eggle...@linux.intel.com
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 1/1] eglibc: migrate configurability from oe
On Fri, 2011-06-03 at 14:47 +0800, Kang Kai wrote:
From: Kang Kai kai.k...@windriver.com
Migrate configurability from oe, try to shrink minimal image size
The switch is in local.conf.sample, uncomment the line
DISTRO_FEATURES_EGLIBC =
and write what options you want to enable.
If want to disable locale-code charsets or locales, you have to uncomment
PACKAGE_NO_GCONV = 1
Because without this, it fails on package_do_split_gconvs in
libc-package.bbclass
I have some comments:
a) I think these should become flags in DISTRO_FEATURES with an
eglibc- prefix so something like spawn would become eglibc-spawn
b) I think we need to create a local.conf.sample.extended which has
information about more advanced settings a user can configure. I don't
want every setting in local.conf as standard as it gives the user the
impression they have to change them which they don't. Some existing data
in local.conf.sample can be moved over.
c) The code triggered by PACKAGE_NO_GCONV should also trigger if you set
the appropriate eglibc- feature flags automatically. Having two
variables you have to keep track of the combinations of is just plain
wrong. They should be controlled by one flag only. If there is generic
packaging code that handles these we might not need the eglibc- prefix
for those options.
Cheers,
Richard
Signed-off-by: Kang Kai kai.k...@windriver.com
---
meta-yocto/conf/local.conf.sample |9 +++
.../eglibc-2.13-fix-macro-RTLD_DEBUG.patch | 20 +++
meta/recipes-core/eglibc/eglibc-options.inc| 55
meta/recipes-core/eglibc/eglibc.inc| 13 +
meta/recipes-core/eglibc/eglibc_2.13.bb|4 +-
5 files changed, 100 insertions(+), 1 deletions(-)
create mode 100644
meta/recipes-core/eglibc/eglibc-2.13/eglibc-2.13-fix-macro-RTLD_DEBUG.patch
create mode 100644 meta/recipes-core/eglibc/eglibc-options.inc
diff --git a/meta-yocto/conf/local.conf.sample
b/meta-yocto/conf/local.conf.sample
index 359e510..f68e80a 100644
--- a/meta-yocto/conf/local.conf.sample
+++ b/meta-yocto/conf/local.conf.sample
@@ -87,6 +87,15 @@ PACKAGE_CLASSES ?= package_rpm package_ipk
# NOTE: if listing mklibs prelink both, then make sure mklibs is before
prelink
USER_CLASSES ?= image-mklibs image-prelink
+# eglibc configurability is used to reduce minimal images's size.
+# PACKAGE_NO_GCONV should be set to 1, or locale-code posix-clang-wchar
+# charsets locales need to be include in DISTRO_FEATURES_EGLIBC, please check
+# package_do_split_gconvs in libc-package.bbclass for detail
+#PACKAGE_NO_GCONV = 1
+
+# if you want to enable any option listed below, please uncomment next line
and copy it here
+#DISTRO_FEATURES_EGLIBC =
+
# POKYMODE controls the characteristics of the generated packages/images by
# telling poky which type of toolchain to use.
#
diff --git
a/meta/recipes-core/eglibc/eglibc-2.13/eglibc-2.13-fix-macro-RTLD_DEBUG.patch
b/meta/recipes-core/eglibc/eglibc-2.13/eglibc-2.13-fix-macro-RTLD_DEBUG.patch
new file mode 100644
index 000..dffc648
--- /dev/null
+++
b/meta/recipes-core/eglibc/eglibc-2.13/eglibc-2.13-fix-macro-RTLD_DEBUG.patch
@@ -0,0 +1,20 @@
+When disable OPTION_EGLIBC_RTLD_DEBUG, compilation fails.
+Created on Jun 1, 2011 by Kang Kai kai.k...@windriver.com
+
+Upstream-Status: Submitted
+
+Signed-off-by: Kang Kai kai.k...@windriver.com
+Index: libc/elf/dl-lookup.c
+===
+--- libc/elf/dl-lookup.c (revision 13356)
libc/elf/dl-lookup.c (working copy)
+@@ -423,7 +423,9 @@
+ hash table. */
+ if (__builtin_expect (tab-size, 0))
+ {
++ #if __OPTION_EGLIBC_RTLD_DEBUG
+ assert (GLRO(dl_debug_mask) DL_DEBUG_PRELINK);
++ #endif
+ __rtld_lock_unlock_recursive (tab-lock);
+ goto success;
+ }
diff --git a/meta/recipes-core/eglibc/eglibc-options.inc
b/meta/recipes-core/eglibc/eglibc-options.inc
new file mode 100644
index 000..7cd0287
--- /dev/null
+++ b/meta/recipes-core/eglibc/eglibc-options.inc
@@ -0,0 +1,55 @@
+def eglibc_cfg(feature, features, tokens, cnf):
+ if type(tokens) == type():
+ tokens = [tokens]
+ if type(features) == type([]) and feature in features:
+ cnf.extend([token + ' = y' for token in tokens])
+ else:
+ for token in tokens:
+ cnf.extend([token + ' = n'])
+ if token == 'OPTION_EGLIBC_NSSWITCH':
+
cnf.extend([OPTION_EGLIBC_NSSWITCH_FIXED_CONFIG = ${S}/nss/nsswitch.conf])
+
cnf.extend([OPTION_EGLIBC_NSSWITCH_FIXED_FUNCTIONS =
${S}/nss/fixed-nsswitch.functions])
+
+# Map distro features to eglibc options settings
+def
Re: [OE-core] [PATCH 1/3] busybox: enable mdev by default
On Fri, 2011-06-03 at 08:37 +0200, Koen Kooi wrote: Op 3 jun 2011, om 03:06 heeft Khem Raj het volgende geschreven: On Thursday, June 02, 2011 09:37:41 AM Richard Purdie wrote: On Wed, 2011-06-01 at 20:40 +, Otavio Salvador wrote: On Wed, Jun 1, 2011 at 20:37, Phil Blundell p...@pbcl.net wrote: On Wed, 2011-06-01 at 20:09 +, Otavio Salvador wrote: -# CONFIG_MDEV is not set +CONFIG_MDEV=y Per previous discussion, I am still uneasy about this change. I think we really need some sort of coherent policy for what exactly the default busybox configuration in oe-core is meant to be doing, and then (if necessary) a set of patches to make it match the policy. Just flipping random features on and off does not seem like a good way to proceed. OE-core has support to mdev as device handling mechanism as such this ought to be enabled by default IMO. Personally it doesn't matter since I have already overriden it in my internal layer. I'm afraid I'm with Phil on this. I don't like the idea of enabling something we don't actually use. This really needs to become some kind of configure option which would at the same time disable/replace udev so the patch in its currently form isn't acceptable. mdev or udev are image features so probably should be controlled by IMAGE_FEATURES or some such You can't put IMAGE_FEATURES in the equivalent of EXTRA_OECONF since the packages in the feeds don't magically change when being installed in a different image. Right, it would have to be a DISTRO_FEATURE for that reason... Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Tell me your build error message annoyances!
On Thu, 2011-06-02 at 23:10 -0700, Darren Hart wrote: These are maybe a bit off topic, but I'll leave it to you to decide if they meet the criteria for this effort. o bb.debug messages are not logged anywhere nor do they appear on the console with -DDD during recipe parsing (while bb.note messages do make it to the console). This isn't a priority for Scott's work at this point IMO. o I'm seeing duplicate messages lately - no examples handy, I'll post or open a bug next time. This is a genuine bug that seems to have crept in recently which need to fix, not sure its Scott who needs to do it though. o The bash logging facility (logging.bbclass) is still a second class citizen and probably needs a bitbake server hook so bbnote, bbplain, bbdebug, etc. can call into bitbake proper and use the python equivalents and therefor also make it to the proper destination (console or log). This also isn't a priority for Scott's work at this point IMO. o It's been mentioned, but I'd like to second that most of the time, getting a traceback is really not very helpful. Chris Larson mentioned moving the exception handling higher up the stack - I think that makes a lot of sense. I'd also suggest not printing a traceback unless running with at least -D. A catchall try block that only does: print Unhandled exception:, e under normal conditions and prints a trace with -D enabled would clean things up a lot I think. I'm going to disagree here a little here. If something unexpected happens we always need the traceback so the pastebin'd error message means something to the developers. Currently it shows up even when the failure is a known error case and a message has been printed to the user and this is a bug though. If we get exception handling right I think we solve this problem too. o In general I find the default UI to be exceedingly noisy. It feels very much like what I would write for something I was actively developing - ie, something I expect to break a lot! I don't think that's the sort of impression we want users to have while building a release (for example). I'd prefer if what we currently get today was the output of -D. The current output could instead be something a lot more in the vein of what we see with recipe parsing. Perhaps one line per BB_NUMBER_TREADS (N), maybe something like: Task 2300/4600 [] 0: linux-yocto: do_compile 1: matchbox: do_fetch ... N: dbus: do_configure It would of course update the current lines and not scroll. Most of the time, this would be plenty information. You're describing the code in the ncurses UI. It is there and you can run it but its unfinished :(. Upon failure we stop updating the UI and print something like: ERROR: An unhandled exception occured while processing linux-yocto: do_fetch Exception: No such file or directory. Run with -D for a more detailed error report or consult the appropriate log file: $(pwd)/tmp/work/$machine/linux-yocto-$HASH-$HASH \ /temp/log.do_fetch.$PID Or something along those lines. You should never be asked to rerun something, it should know when to print the right information. 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/3] busybox: enable mdev by default
On Fri, 2011-06-03 at 10:59 +0200, Koen Kooi wrote: Op 3 jun 2011, om 10:24 heeft Richard Purdie het volgende geschreven: On Fri, 2011-06-03 at 08:37 +0200, Koen Kooi wrote: Op 3 jun 2011, om 03:06 heeft Khem Raj het volgende geschreven: On Thursday, June 02, 2011 09:37:41 AM Richard Purdie wrote: On Wed, 2011-06-01 at 20:40 +, Otavio Salvador wrote: On Wed, Jun 1, 2011 at 20:37, Phil Blundell p...@pbcl.net wrote: On Wed, 2011-06-01 at 20:09 +, Otavio Salvador wrote: -# CONFIG_MDEV is not set +CONFIG_MDEV=y Per previous discussion, I am still uneasy about this change. I think we really need some sort of coherent policy for what exactly the default busybox configuration in oe-core is meant to be doing, and then (if necessary) a set of patches to make it match the policy. Just flipping random features on and off does not seem like a good way to proceed. OE-core has support to mdev as device handling mechanism as such this ought to be enabled by default IMO. Personally it doesn't matter since I have already overriden it in my internal layer. I'm afraid I'm with Phil on this. I don't like the idea of enabling something we don't actually use. This really needs to become some kind of configure option which would at the same time disable/replace udev so the patch in its currently form isn't acceptable. mdev or udev are image features so probably should be controlled by IMAGE_FEATURES or some such You can't put IMAGE_FEATURES in the equivalent of EXTRA_OECONF since the packages in the feeds don't magically change when being installed in a different image. Right, it would have to be a DISTRO_FEATURE for that reason... Right, but you can build mdev and choose not to use it, which is what .dev currently does. So while the distro could in theory set a DISTRO_FEATURE, we shouldn't make other decisions based on that, like deciding that if mdev is in DISTRO_FEATURES every image will use it. Why we wouldn't enable that functionality based on the option? 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] eglibc: migrate configurability from oe
On Fri, 2011-06-03 at 16:54 +0800, Kang Kai wrote: Hi Richard, Thanks for your comments. And I have one question: On Fri, 2011-06-03 at 14:47 +0800, Kang Kai wrote: From: Kang Kaikai.k...@windriver.com Migrate configurability from oe, try to shrink minimal image size The switch is in local.conf.sample, uncomment the line DISTRO_FEATURES_EGLIBC = and write what options you want to enable. If want to disable locale-code charsets or locales, you have to uncomment PACKAGE_NO_GCONV = 1 Because without this, it fails on package_do_split_gconvs in libc-package.bbclass I have some comments: a) I think these should become flags in DISTRO_FEATURES with an eglibc- prefix so something like spawn would become eglibc-spawn Do you mean every option in DISTRO_FEATURES_EGLIBC should be a single flag in DISTRO_FEATURES? No, you'd still have all the options you currently have but instead of being called X they would be eglibc-X. 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] eglibc: enable eglibc configurability V2
On Fri, 2011-06-03 at 12:32 +0100, Phil Blundell wrote: On Fri, 2011-06-03 at 14:47 +0800, Kang Kai wrote: If want to disable locale-code charsets or locales, you have to uncomment PACKAGE_NO_GCONV = 1 Because without this, it fails on package_do_split_gconvs in libc-package.bbclass Can we not just fix libc-package.bbclass to stop it failing in that situation? It seems a bit sad to require an extra flip this switch to make it work kind of variable. That was my point in the earlier email :) 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 PULL 01/20] bitbake.conf: Create staticlibs pacakge for static libraries
On Mon, 2011-06-06 at 07:55 +0100, Phil Blundell wrote:
On Sun, 2011-06-05 at 23:44 -0700, Saul Wold wrote:
SECTION_${PN}-dev = devel
ALLOW_EMPTY_${PN}-dev = 1
RDEPENDS_${PN}-dev = ${PN} (= ${EXTENDPKGV})
+FILES_${PN}-staticlibs = ${libdir}/*.a ${base_libdir}/*.a
+SECTION_${PN}-staticlibs = devel
+RDEPENDS_${PN}-staticlibs = ${PN}-dev (= ${EXTENDPV})
This should be ${EXTENDPKGV}, right?
It should.
I'm also not 100% convinced I like -staticlibs vs -staticdev as it
doesn't feel consistent.
The user gets exposed to these at the package manager level and will
xxx install xxx-staticX. The end result they'll get will be the
installation of everything they need for static development (i.e. the
-dev packages will get pulled in for the headers). This means they don't
just result in the static libs as there are dependencies there. From the
user perspective they are therefore packages for static development, not
just the static libraries...
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/4] tar: upgrade to v1.26
On Mon, 2011-06-06 at 09:00 +0100, Phil Blundell wrote: On Sun, 2011-06-05 at 21:49 -0700, Scott Garman wrote: SECTION = base +PRIORITY = optional Seeing this sort of thing makes me wonder whether SECTION and PRIORITY actually belong in the core metadata at all. It seems as though the determination of what exactly is standard vs optional is a matter of distro policy and this would be better done in the distro config files. Also, just on a pragmatic issue, the two values above are actually what bitbake.conf sets as default anyway so there isn't much to be gained by specifying them in the recipe as well. I have to admit I keep wondering about these. PRIORITY does seem a bit of a pointless variable in the default metadata and I'm borderline in favour of dropping it and leaving it to any distros who want to use it, maybe sharing an include file. SECTION does at least start to become useful in an image generation UI as a way to group packages roughly by type which makes me think it has a good default usecase (and OE-Core did clean up the values of it to at least be consistent). 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 PULL 01/20] bitbake.conf: Create staticlibs pacakge for static libraries
On Mon, 2011-06-06 at 17:31 +, Otavio Salvador wrote: On Mon, Jun 6, 2011 at 16:50, Saul Wold s...@linux.intel.com wrote: ... As was pointed out earlier Fedora packages static libraries in a -static package, but this had other implications for OE due to -static already being in use (for busybox and mplayer), I am not sure that this is not a problem for OE-Core, I would need to investigate. Meego also seems to use the Fedora standard with -static. ... I personally prefer -static. -staticlib seems redundant for me since we can end with libfoo-staticlib -static doesn't really work well given we already have -static packages meaning something else (e.g. the busybox 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] [CONSOLIDATED PULL 01/20] bitbake.conf: Create staticlibs pacakge for static libraries
On Mon, 2011-06-06 at 10:03 -0700, Khem Raj wrote:
On Sun, Jun 5, 2011 at 11:44 PM, Saul Wold s...@linux.intel.com wrote:
Signed-off-by: Saul Wold s...@linux.intel.com
---
meta/conf/bitbake.conf | 12 ++--
1 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index de94316..520b808 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -194,9 +194,13 @@ This package contains ELF symbols and related sources
for debugging purposes.
SUMMARY_${PN}-dev ?= ${SUMMARY} - Development files
DESCRIPTION_${PN}-dev ?= ${DESCRIPTION} \
-This package contains symbolic links, static binaries, header files, and \
+This package contains symbolic links, header files, and \
related items necessary for software development.
+SUMMARY_${PN}-staticlibs ?= ${SUMMARY} - Development files (Static
Libraries)
+DESCRIPTION_${PN}-staticlibs?= ${DESCRIPTION} \
+This package contains static libraries for software development.
+
SUMMARY_${PN}-doc ?= ${SUMMARY} - Documentation files
DESCRIPTION_${PN}-doc ?= ${DESCRIPTION} \
This package contains documentation.
@@ -248,13 +252,17 @@ FILES_${PN}-doc = ${docdir} ${mandir} ${infodir}
${datadir}/gtk-doc \
SECTION_${PN}-doc = doc
FILES_${PN}-dev = ${includedir} ${libdir}/lib*${SOLIBSDEV} ${libdir}/*.la
\
-${libdir}/*.a ${libdir}/*.o ${libdir}/pkgconfig \
+${libdir}/*.o ${libdir}/pkgconfig \
${datadir}/pkgconfig ${datadir}/aclocal \
${base_libdir}/*.a ${base_libdir}/*.o
SECTION_${PN}-dev = devel
ALLOW_EMPTY_${PN}-dev = 1
RDEPENDS_${PN}-dev = ${PN} (= ${EXTENDPKGV})
+FILES_${PN}-staticlibs = ${libdir}/*.a ${base_libdir}/*.a
+SECTION_${PN}-staticlibs = devel
+RDEPENDS_${PN}-staticlibs = ${PN}-dev (= ${EXTENDPV})
+
I think if you need to divide it then -dev should be divided into
static, dynamic and headers otherwise this may not be so useful.
The dynamic package would only consist of some symlinks and .la files
though so wouldn't be that much extra compared to the -dev package?
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 PULL 01/20] bitbake.conf: Create staticlibs pacakge for static libraries
On Mon, 2011-06-06 at 19:07 +, Otavio Salvador wrote: On Mon, Jun 6, 2011 at 19:00, Richard Purdie richard.pur...@linuxfoundation.org wrote: On Mon, 2011-06-06 at 17:31 +, Otavio Salvador wrote: I personally prefer -static. -staticlib seems redundant for me since we can end with libfoo-staticlib -static doesn't really work well given we already have -static packages meaning something else (e.g. the busybox case). Aren't we changing the wrong name? In my opinion then busybox ought to be renamed. Like busybox-staticlinked or busybox-nolibs. I think it goes to show that -static is a bad choice of name as it can take so many different meanings. Its also why I feel strong it should reflect what people would use it for, not what it physically contains. Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Tell me your build error message annoyances!
On Mon, 2011-06-06 at 21:53 -0700, Darren Hart wrote: On 06/03/2011 08:47 AM, Chris Larson wrote: Heh, I used to have a personal branch where I dropped those, and also removed the unnecessary NOTE: prefix. I think its a given that something that doesn't indicate a warning or an error is simply informative :) The problem with dropping those messages is for postprocessing scripts, which may well want/need to know when a task completes, not just when it starts. Still, yet another case of something we could drop as long as we log it. We need to add a main bitbake execution log that captures everything, including debug messages, whether the user specifies -D or not. In most systems, running with -D implies not only greater verbosity, but also reduced performance. I haven't checked, but I expect that is the case with bitbake as well. I don't think we want to enable all of -D and log it by default. I'm not sure the performance hit of this would be that great to be honest, particularly if we localised the output to the tasks and didn't hit the IPC mechanism for all the messages. It certainly could be valuable to have more robust logfiles on disk so that when things do break we can dive into them and get full debug info rather than the current partial info. The main cost would be increased disk space but disks are cheap comparatively and the IO is minor compared to other things we do... Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Layer index wiki page
On Tue, 2011-06-07 at 14:58 -0400, Cliff Brake wrote: On Tue, Jun 7, 2011 at 12:12 PM, Paul Eggleton paul.eggle...@linux.intel.com wrote: Hi all, I've created a wiki page to provide a central index of all layers that can be used with oe-core: http://www.openembedded.org/index.php/LayerIndex This is by no means complete - I started with the list from Cliff's changelog and added a few on from there. I was also looking around for a page with the Ångström setup instructions that specifically mentions being oe-core based but I couldn't find it (Koen?) I'm still thinking about how to best represent layer repos that contain multiple layers too (e.g. meta-oe, meta-smartphone, etc.). Comments / updates / additions welcome. Looks good. I've added meta-yocto to the weekly changelog report: http://cgit.openembedded.org/cgit.cgi/openembedded-admin/commit/?id=d017dc35791f100799213cf20de58cd0423b348f Please be careful with this one as poky is currently a fusion of bitbake, oe-core and the meta-yocto pieces and those meta-yocto pieces don't yet have their own repository. There will therefore be duplicate commit information until meta-yocto splits into its own repository. Yocto is working on layer tools and I've been holding doing anything with meta-yocto until they're ready. If there is pressure to split this out now though, we can speed up that process at some extra admin cost for me to maintain them... 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 PULL 00/13] 06-June-2011
On Tue, 2011-06-07 at 00:01 -0700, Saul Wold wrote: Updates for the kernel and lots of distro tracking updates for manual based updates checking. Sau! The following changes since commit 925de3b3e74d15547840a2edaceff437e135bddd: tzcode: Update to 2011g (2011-06-06 15:52:18 +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 (2): linux-yocto: update target/meta SRCREVs linux-yocto: make e1000e structure common [commit: bec3f1e8c] Koen Kooi (1): util-linux: package agetty seperately Phil Blundell (1): sqlite: remove dependency on tcl-native Saul Wold (4): json-glib: Update to 0.12.4 distro tracking: update Qing - Saul distro tracking: fixup some bad entries distro tracking: Manual Updates Scott Garman (5): distro-tracking: updates openssh: upgrade to v5.8p2 grep: upgrade to v2.8 tar: upgrade to v1.26 distro-tracking: update openssh, tar, and grep 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] uclibc: remove PACKAGE_ARCH, fix compilation on i586
On Tue, 2011-06-07 at 10:36 +0100, Phil Blundell wrote: Ping? I'm not against this move at all but before this patch merges we should really have a cleanup which removes the *.machine configuration files from the uclibc recipe directory along with all the machine specific overrides that are in use instead making them arch specific. Any volunteers? Cheers, Richard p. On Fri, 2011-06-03 at 12:55 +0100, Phil Blundell wrote: There is no good reason for uclibc to be machine specific. Remove local assignment to PACKAGE_ARCH so that it gets the default target architecture and bump PR for that change. See http://lists.linuxtogo.org/pipermail/openembedded-core/2011-May/003064.html Also replace a chunk of anonymous python with a COMPATIBLE_HOST declaration. Signed-off-by: Phil Blundell ph...@gnu.org ___ 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] [CONSOLIDATED PULL 00/20] 05-June-2011
On Sun, 2011-06-05 at 23:44 -0700, Saul Wold wrote: This pulls together a set of changes from the later part of last week, these have been built. I have updated Nitin's comment about the License change (which was adding years). This also includes Scott's User Addition code. I did not pull Bruce's change due to a known build issue with x86-64, I am expecting an update from him. Thanks Sau! The following changes since commit 2a52f806f3789f717219651b97dc64fec3881f7f: qmake_base.bbclass: fix lrelease/lupdate binary names (2011-06-02 18:26:19 +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 Khem Raj (2): allarch.bbclass: Define BASE_PACKAGE_ARCH = all util-linux_2.19.1.bb: Fix compliation on uclibc Martin Jansa (1): base.bbclass: add cleansstate task between clean and cleanall Nitin A Kamble (3): m4: upgrade from 1.4.15 to 1.4.16 autoconf: upgrade from 2.65 to 2.68 bison: upgrade from 2.4.3 to 2.5 Otavio Salvador (4): gnutls: use INC_PR on 2.12.5 version recipe gnutls: add p11tool into gnutls-bin package.bbclass: add support to split Qt translation files xf86-driver-common.inc: remove .la files to avoid unpackaged warning Phil Blundell (1): gcc-package-cross: also install the symlinks in libexec with target prefix Saul Wold (2): bitbake.conf: Create staticlibs pacakge for static libraries tzcode: Update to 2011g Scott Garman (7): shadow: recipe and patch cleanup shadow: add a -native recipe with customized utilities base-passwd: populate the target sysroot with passwd/group/login.defs useradd.bbclass: new class for managing user/group permissions useradd-example: example recipe for using inherit useradd bitbake.conf: set PSEUDO_PASSWD within FAKEROOTENV package_rpm.bbclass: make RPM use on-disk permissions I merged these except in the two cases where feedback was given or in the case of the useradd* commits from Scott as I need more time to review those. 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 Wed, 2011-06-08 at 10:36 +0100, Phil Blundell wrote: On Wed, 2011-06-08 at 17:08 +0800, Dongxiao Xu wrote: *libc's do_package will cost a lot of time due to the locale handing, which may delay the other recipe's do_package task and affect the build performance. This commit moves locale handling into a separate recipe *libc-locale. Can you quantify the effect on build performance a bit? If I understand correctly, you're basically saying that the goal is to increase parallelism. Does that cause reduced performance for people running with few threads? One of the side effects of debian.bbclass is that it requires all dependencies to do_package before any package itself can do_package so any renaming of dependencies can be accounted for. There is an issue if do_package for libc takes an age as it holds up any other tasks from writing out packages. Pretty much most things depend on libc. This patch therefore splits it into two stages and means that packaging of things depending on libc can happen sooner thereby increasing the potential parallelism of the packaging stages of builds. There is a very clear step on the bootchart graphs of builds I made showing this. I'm not sure how this would reduce performance of builds of a few threads, it should just make better use of any available spare processing capacity throughout the build. 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 v1 PATCH 00/16] populate perl-native into its own directory
On Thu, 2011-06-02 at 09:55 -0700, Tom Rini wrote:
On 06/02/2011 09:35 AM, Richard Purdie wrote:
On Thu, 2011-06-02 at 09:28 -0700, Tom Rini wrote:
Even if we're using the sstate
cache from /foo/oecore/tmp over in /bar/oecore/tmp (and /foo/oecore/tmp
is rm -rf'd) ? Since we've got a create_wrapper around perl and
perl${PV} it should be I suppose (or is easily added there), but I'd
feel a lot better with some testing of the above case (and the updates
to cpan*bbclass).
I only took the perl-native DEPENDS patch on the condition this gets
fixed properly. The patches that are there look to do that, at least for
OE-Core. If there are further issues we're going to have to take them as
they arise as I have an objection to crippling the build dependencies
because perl is broken. Really this could use some TLC from someone with
experience in the area...
Well, I guess I'd boil down what I said above into a request like this
for v3:
- Modify cpan.bbclass to NOT set PERL_INC / PERL_LIB / PERL_ARCHLIB /
PERLHOSTLIB.
The first three of these are all about the *target* perl location and I
think we still need them due the mess that perl's build system is. With
the patch series in question they won't actually point at perl-native in
the target case and they are only really used for cross compiling
purposes.
PERLHOSTLIB is used by the target perl when cross compiling to find
native .so files. perl-native will always be present at this point and
again, it seems like a valid use case.
Summary is that I don't think perl-native is broken in any way but we do
need those variables.
- In /scratch/oecore/tmp0 build the images that were built for v1
- In /scratch/oecore/tmp1 build perl-native's full sstate cache.
- Keep the sstate cache from tmp1 and otherwise rm -rf tmp1.
- In /scratch/oecore/tmp2 using the sstate from tmp1, build the same
images that were built for tmp0.
I'm confused by this test cycle. What do you mean by build
perl-native's full sstate cache?
I suspect you've asking for some partial sstate cache to be shared
between two builds?
Put simpler, you probably want:
in tmp0 bitbake perl-native
in tmp1, different location to tmp0, bitbake core-image-sato but
sharing the same sstate cache
Is that what you're thinking?
FWIW, I've been running locally with the patch series and I think I'd
like to merge it. If there are issues we can address them as and when
they're identified...
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 v1 PATCH 00/16] populate perl-native into its own directory
On Thu, 2011-06-09 at 09:04 +0100, Richard Purdie wrote:
On Thu, 2011-06-02 at 09:55 -0700, Tom Rini wrote:
On 06/02/2011 09:35 AM, Richard Purdie wrote:
On Thu, 2011-06-02 at 09:28 -0700, Tom Rini wrote:
Even if we're using the sstate
cache from /foo/oecore/tmp over in /bar/oecore/tmp (and /foo/oecore/tmp
is rm -rf'd) ? Since we've got a create_wrapper around perl and
perl${PV} it should be I suppose (or is easily added there), but I'd
feel a lot better with some testing of the above case (and the updates
to cpan*bbclass).
I only took the perl-native DEPENDS patch on the condition this gets
fixed properly. The patches that are there look to do that, at least for
OE-Core. If there are further issues we're going to have to take them as
they arise as I have an objection to crippling the build dependencies
because perl is broken. Really this could use some TLC from someone with
experience in the area...
Well, I guess I'd boil down what I said above into a request like this
for v3:
- Modify cpan.bbclass to NOT set PERL_INC / PERL_LIB / PERL_ARCHLIB /
PERLHOSTLIB.
The first three of these are all about the *target* perl location and I
think we still need them due the mess that perl's build system is. With
the patch series in question they won't actually point at perl-native in
the target case and they are only really used for cross compiling
purposes.
PERLHOSTLIB is used by the target perl when cross compiling to find
native .so files. perl-native will always be present at this point and
again, it seems like a valid use case.
Summary is that I don't think perl-native is broken in any way but we do
need those variables.
- In /scratch/oecore/tmp0 build the images that were built for v1
- In /scratch/oecore/tmp1 build perl-native's full sstate cache.
- Keep the sstate cache from tmp1 and otherwise rm -rf tmp1.
- In /scratch/oecore/tmp2 using the sstate from tmp1, build the same
images that were built for tmp0.
I'm confused by this test cycle. What do you mean by build
perl-native's full sstate cache?
I suspect you've asking for some partial sstate cache to be shared
between two builds?
Put simpler, you probably want:
in tmp0 bitbake perl-native
in tmp1, different location to tmp0, bitbake core-image-sato but
sharing the same sstate cache
I meant to add that tmp0 should be renamed before this second step so if
there are hardcoded references in any of the sstate packages they
couldn't find anything in tmp0 as it would no longer exist.
Is that what you're thinking?
FWIW, I've been running locally with the patch series and I think I'd
like to merge it. If there are issues we can address them as and when
they're identified...
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] LOCALCOUNT increased twice when there are 2 layers with same git recipe
On Thu, 2011-06-09 at 10:38 +0200, Martin Jansa wrote:
Hi,
I was wondering why I see gobject-introspection built on every image
build and it's because LOCALCOUNT is changing all the time.
OE om-gta02@shr ~/shr-core $ find openembedded-core/ -name
gobject-introspection\*
openembedded-core/meta/recipes-gnome/gnome/gobject-introspection_git.bb
SRCREV = efa7266bcf78478ce62e8dd778a4f0417bfd4d15
PV = 0.10.8+git${SRCPV}
OE om-gta02@shr ~/shr-core $ find meta-openembedded/ -name
gobject-introspection\*
meta-openembedded/meta-oe/recipes-gnome/gnome/gobject-introspection_0.9.10.bb
meta-openembedded/meta-oe/recipes-gnome/gnome/gobject-introspection_git.bb
SRCREV = 8d64bc23d2b837421ecf9c7b0e4b8d5d95ca0d21
PV = 1.29.0+gitr${SRCPV}
I had to add gobject-introspection_git.bb to meta-oe, because we're
using newer glib with gdbus-codegen included (instead separate
gdbus-binding-tool we were using before)
meta-openembedded/meta-oe/recipes-core/glib-2.0/glib-2.0_git.bb with
SRCREV = d97cbc6731deab137770bc0fe9c69b06f689f5b4
PV = 2.29.3+gitr${SRCPV}
and default gobject-introspection version is not compatible with it.
Problem is that with 2 _git recipes LOCALCOUNT is incremented twice
because there are 2 different SRCREVs found during parsing.
I wanted to use gobject-introspection_git.bbappend, but it looks like
changing PV/SRCREV from .bbappend is not supported (bitbake-layers also
reported that it cannot find right gobject-introspection version to my
bbappend. And I also cannot blacklist gobject-introspection_git.bb from
oe-core, because Angstrom blacklister uses only PN. So in the end I've
removed that recipe from my oe-core-contrib/shr branch which is used for
SHR builds..
Is there better way to resolve this? With more layers enabled this could
happen more often imho.. Maybe we could add unexpanded -PV to LOCALCOUNT
persistent db key with sideeffect of reseting LOCALCOUNT on every PV
change (upgrade to newer version).
I like this idea at least in principle. If you're changing PV, you don't
mind if the counter resets so I don't see that as a problem...
Cheers,
Richard
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Tell me your build error message annoyances!
On Thu, 2011-06-09 at 12:02 +0100, Phil Blundell wrote: After I made a typo (mismatched quotes) in one of my recipes, my next bitbake run printed: Loading cache: 100% |#| ETA: 00:00:00 Loaded 1323 entries from dependency cache. NOTE: Error expanding variable do_configure | ETA: --:--:-- ERROR: Command execution failed: Traceback (most recent call last):# | ETA: 00:00:00 File /home/pb/oe/bitbake/lib/bb/command.py, line 99, in runAsyncCommand self.cooker.updateCache() File /home/pb/oe/bitbake/lib/bb/cooker.py, line 871, in updateCache if not self.parser.parse_next(): File /home/pb/oe/bitbake/lib/bb/cooker.py, line 1120, in parse_next self.shutdown(clean=False) File /home/pb/oe/bitbake/lib/bb/cooker.py, line 1102, in shutdown bb.codeparser.parser_cache_save(self.cfgdata) File /home/pb/oe/bitbake/lib/bb/codeparser.py, line 77, in parser_cache_save data, version = p.load() EOFError So, this is (a) confusing, because EOFError doesn't yield much information about the actual cause of the problem; (b) unhelpful, since it doesn't mention which line of the file (or even which recipe) was to blame; and (c) annoying, for the usual reasons to do with python traceback. Somewhat worse, even after I fixed the typo, any subsequent attempt to run bitbake would just result in: Loading cache: 100% |#| ETA: 00:00:00 Loaded 1323 entries from dependency cache. Traceback (most recent call last): | ETA: --:--:-- File /usr/lib/python2.6/multiprocessing/util.py, line 235, in _run_finalizers finalizer() File /usr/lib/python2.6/multiprocessing/util.py, line 174, in __call__ res = self._callback(*self._args, **self._kwargs) File /home/pb/oe/bitbake/lib/bb/codeparser.py, line 77, in parser_cache_save data, version = p.load() EOFError (repeated about 10 times) I deleted tmp/cache/* and that seemed to fix the problem. FWIW, bitbake master has fixes for this specific issue and a number of other codeparser performance related issues. If it meets EOF while loading it will now just assume the cache file is corrupt and ignore/rebuild it. 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 Thu, 2011-06-09 at 12:14 +0100, Phil Blundell wrote: On Wed, 2011-06-08 at 16:35 +0100, Richard Purdie wrote: I'm not sure how this would reduce performance of builds of a few threads, it should just make better use of any available spare processing capacity throughout the build. If I'm reading the patch right, it does involve a certain amount of extra copying around of the locale-related files since they need to be stashed away in some place where libc-locale.bb can find them later. I don't think these files are especially big, but there are quite a few of them (which is the whole reason that libc's do_package was slow in the first place). I must admit that I'm slightly surprised that libc's packaging stage is becoming a bottleneck for anything other than the very smallest builds. If there's any substantial amount of other material being compiled then I would expect that there would be enough do_compile() work to keep the other threads busy until libc was done packaging. That's not to say that I think this change is a bad idea, but I would be interested to know what the actual impact is for real-world workloads. And, just on a point of principle, any time we're making a chance for performance-related reasons I think we should always have measurements to back it up. Totally agreed and this decision is being made on real world data even if its perhaps not clearly being presented here. $ cat buildstats/core-image-sato-qemux86/201106030912/eglibc-2.13-r1+svnr13356/do_package | grep time eglibc-2.13-r1+svnr13356: do_package: Elapsed time: 828.01 seconds As you can see, eglibc do_package takes about 14 minutes which is about 14% of our build time. That is a long time to block pretty much all packaging activity, particularly if you have access to something with several cores. When it does complete, even on my 4 core system you see a stampeding herd of packaging happening on the build charts suggesting a backlog does build up. For those reasons I do think its a reasonable change. 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 Thu, 2011-06-09 at 12:43 +0100, Phil Blundell wrote: On Thu, 2011-06-09 at 12:29 +0100, Richard Purdie wrote: As you can see, eglibc do_package takes about 14 minutes which is about 14% of our build time. That is a long time to block pretty much all packaging activity, particularly if you have access to something with several cores. When it does complete, even on my 4 core system you see a stampeding herd of packaging happening on the build charts suggesting a backlog does build up. Yeah, I can imagine that a backlog of packaging activity does build up. The thing I'm not entirely clear on is whether this is actually causing some threads to get starved of work (and hence the total build time to be longer than it needs to be) or whether we're really just shifting things around in the timeline without making much/any difference to the overall build duration. It will certainly be a net win on large core systems which I know of people running builds on as task starvation happens there. Last time I tested this on a 4 core I think we saw a couple of minutes improvement in build time so it appears beneficial there too. (I'm not familiar enough with bitbake's scheduler to know whether it will schedule tasks as early as possible, or as late as possible, or something else.) Roughly speaking, the default scheduler runs tasks with the most things depending upon them first. This means it will fill any spare threads with lower priority tasks such as packaging. Just as a matter of interest, are you using qemu-based locale generation or the cross localedef for your measurement? 14 minutes does sound like an awfully long time and I wonder whether there is anything we could do in absolute terms to just speed that process up. I'm using cross localedef. Its faster than with qemu but still slow. I'm very open to suggestions on how to speed it up as it does take an age. 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 Thu, 2011-06-09 at 14:15 +0100, Richard Purdie wrote: On Thu, 2011-06-09 at 12:43 +0100, Phil Blundell wrote: On Thu, 2011-06-09 at 12:29 +0100, Richard Purdie wrote: As you can see, eglibc do_package takes about 14 minutes which is about 14% of our build time. That is a long time to block pretty much all packaging activity, particularly if you have access to something with several cores. When it does complete, even on my 4 core system you see a stampeding herd of packaging happening on the build charts suggesting a backlog does build up. Yeah, I can imagine that a backlog of packaging activity does build up. The thing I'm not entirely clear on is whether this is actually causing some threads to get starved of work (and hence the total build time to be longer than it needs to be) or whether we're really just shifting things around in the timeline without making much/any difference to the overall build duration. It will certainly be a net win on large core systems which I know of people running builds on as task starvation happens there. Last time I tested this on a 4 core I think we saw a couple of minutes improvement in build time so it appears beneficial there too. Just as another data point, I'm running builds on my 4 core machine here and it is scheduling many do_package tasks including long running ones such as perl's in parallel with eglibc-locale's do_package task. It would appear the bitbake scheduler believes there is benefit in splitting these out at least. 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] kexec-tools: don't depend on virtual/kernel
On Thu, 2011-06-09 at 12:58 +0100, Phil Blundell wrote: There doesn't appear to be any terribly good reason for kexec-tools to depend on the kernel. (I verified that kexec-tools is buildable in a clean TMPDIR without having previously built virtual/kernel.) Having this dependency in place is a nuisance because it makes it awkward to put kexec into an initramfs. So, it seems like we would be better off without. Signed-off-by: Phil Blundell ph...@gnu.org --- meta/recipes-kernel/kexec/kexec-tools.inc |2 +- 1 files changed, 1 insertions(+), 1 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] consolekit: update to 0.4.5
On Thu, 2011-06-09 at 12:53 +0200, Koen Kooi wrote: Signed-off-by: Koen Kooi k...@dominion.thruhere.net --- .../recipes-support/consolekit/consolekit_0.4.4.bb | 26 .../recipes-support/consolekit/consolekit_0.4.5.bb | 25 +++ 2 files changed, 25 insertions(+), 26 deletions(-) delete mode 100644 meta/recipes-support/consolekit/consolekit_0.4.4.bb create mode 100644 meta/recipes-support/consolekit/consolekit_0.4.5.bb 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] metacity 2.30.3: fix build on GNOME-less hosts and fix packaging
On Thu, 2011-06-09 at 12:54 +0200, Koen Kooi wrote: Signed-off-by: Koen Kooi k...@dominion.thruhere.net --- meta/recipes-gnome/gnome/metacity_2.30.3.bb | 13 - 1 files changed, 8 insertions(+), 5 deletions(-) diff --git a/meta/recipes-gnome/gnome/metacity_2.30.3.bb b/meta/recipes-gnome/gnome/metacity_2.30.3.bb index 18105f2..44e21c9 100644 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/1] Fix realpath issue in pseudo
On Thu, 2011-06-09 at 12:15 -0500, Mark Hatle wrote: When pseudo is running in disabled mode (most of the time in oe-core), the realpath function can fail on system systems. This was discovered by some problems found in Qt MOC and qmake. The change is from upstream, and has been verified by the person who originally found the issue. The following changes since commit d3e105451413617cf6415ae1600dc063f3d8d452: scripts/bitbake: Only build tar-replacement-native when the build system tar version 1.24 (2011-06-09 16:32:03 +0100) are available in the git repository at: git://git.pokylinux.org/poky-contrib mhatle/pseudo http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=mhatle/pseudo Mark Hatle (1): pseudo: Fix problem related to realpath 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] [CONSOLIDATED PULL 0/4] 10-June
On Thu, 2011-06-09 at 23:26 -0700, Saul Wold wrote: Kang Kai (1): ghostscript: update SRC_URI Nitin A Kamble (1): gcc: rebase the patch to avoid patch rejection This was a disaster. It breaks the build and is huge, thereby clogging up the source control system web interface etc. I applied it, then had to revert it. Please test things like this more carefully in future. I also think we need to put these kind of patches on the website or in a repo, we shouldn't be carrying them around in the main repo. Phil Blundell (1): busybox: backport distro-features handling from oe master Saul Wold (1): multiple recipes converted to -staticdev packages I'm with Phil on this one, needs more work. I haven't got to the other two since the gcc issue distracted me :/. 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] Share gcc work directories
On Sat, 2011-06-11 at 15:19 +0800, Robert Yang wrote:
This patched is derived from Richard, make gcc use the shared source
directory during the different building:
1) Make gcc-cross, gcc-cross-initial, gcc-cross-intermediate and
gcc-runtime share the same source directory.
2) The source directory is ${TMPDIR}/work-shared/gcc-${PV}, for example:
tmp/work-shared/gcc-4.6.0
3) gcc uses sed and creates config files against ${S} which means the
directory should not be shared. Change the way to make it work.
4) Fix do_clean to clean the shared source directory and stamps
Signed-off-by: Robert Yang liezhi.y...@windriver.com
---
meta/recipes-devtools/gcc/gcc-common.inc | 32 ++-
meta/recipes-devtools/gcc/gcc-configure-common.inc | 10 +-
2 files changed, 39 insertions(+), 3 deletions(-)
diff --git a/meta/recipes-devtools/gcc/gcc-common.inc
b/meta/recipes-devtools/gcc/gcc-common.inc
index a3fa234..7bf036c 100644
--- a/meta/recipes-devtools/gcc/gcc-common.inc
+++ b/meta/recipes-devtools/gcc/gcc-common.inc
@@ -37,10 +37,38 @@ ${GNU_MIRROR}/gcc/
http://gcc.get-software.com/releases/ \n \
#
gcclibdir = ${libdir}/gcc
BINV = ${PV}
-S = ${WORKDIR}/gcc-${PV}
-B = ${S}/build.${HOST_SYS}.${TARGET_SYS}
+#S = ${WORKDIR}/gcc-${PV}
+S = ${TMPDIR}/work-shared/gcc-${PV}/gcc-${PV}
+B = ${WORKDIR}/gcc-${PV}/build.${HOST_SYS}.${TARGET_SYS}
+
+# SS means Shared Stamps directory
+SS = ${TMPDIR}/stamps/work-shared/gcc-${PV}
+do_fetch[stamp-base] = ${SS}
+do_unpack[stamp-base] = ${SS}
+do_patch[stamp-base] = ${SS}
+
+# SW means Shared Work directory
+SW = ${TMPDIR}/work-shared/gcc-${PV}
+WORKDIR_task-unpack = ${SW}
+WORKDIR_task-patch = ${SW}
target_includedir ?= ${includedir}
target_libdir ?= ${libdir}
target_base_libdir ?= ${base_libdir}
target_prefix ?= ${prefix}
+
+CLEANFUNCS += workshared_clean
+# The do_clean should be exclusive since share ${S}
+do_clean[lockfiles] = ${TMPDIR}/stamps/work-shared/gcc-${PV}.clean.lock
+
+python workshared_clean () {
+ clear the source directory
+ dir = bb.data.expand(${SW}, d)
+ bb.note(Removing + dir)
+ oe.path.remove(dir)
+
+ clear the the stamps in work-shared
+ dir = %s.* % bb.data.expand(d.getVarFlag('do_fetch', 'stamp-base',
True), d)
+ bb.note(Removing + dir)
+ oe.path.remove(dir)
+}
diff --git a/meta/recipes-devtools/gcc/gcc-configure-common.inc
b/meta/recipes-devtools/gcc/gcc-configure-common.inc
index f7b5836..c32242d 100644
--- a/meta/recipes-devtools/gcc/gcc-configure-common.inc
+++ b/meta/recipes-devtools/gcc/gcc-configure-common.inc
@@ -87,7 +87,15 @@ do_configure () {
export ARCH_FLAGS_FOR_TARGET=${ARCH_FLAGS_FOR_TARGET}
(cd ${S} gnu-configize) || die failure running gnu-configize
- # teach gcc to find correct target includedir when checking libc ssp
support
+ # teach gcc to find correct target includedir when checking libc ssp
support,
+ # save the files before hack them, so that we can always hack the fresh
one.
+ for i in configure.ac Makefile.in defaults.h configure; do
+ [ ! -f ${S}/gcc/$i.orig ] cp ${S}/gcc/$i ${S}/gcc/$i.orig
+ cp ${S}/gcc/$i.orig ${S}/gcc/$i
+ done
+ # Make sure that ${S}/configure is newer than ${S}/gcc/configure to
prevent
+ # auto run autoconf.
+ touch ${S}/configure
sed -i 's:^\([
]*\)glibc_header_dir=\${with_build_sysroot}/usr/include\:\1glibc_header_dir=\${with_build_sysroot}${SYSTEMHEADERS}\:g'
${S}/gcc/configure.ac
sed -i 's:^\([
]*\)glibc_header_dir=\${with_build_sysroot}/usr/include\:\1glibc_header_dir=\${with_build_sysroot}${SYSTEMHEADERS}\:g'
${S}/gcc/configure
If I run something like a meta-toolchain build at the same time as a
target toolchain build, this isn't going to work. It will also break
when we start doing multilib builds with multiple toolchains as multiple
builds will use ${S} at once.
I think we're going to need to be able to influence these things we
currently set directly either from the configure commandline, or from
config files in ${B} instead of ${S}.
Cheers,
Richard
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 00/11] Various dependency tweaks + nastivesdk fixes
This patch series contains various dependency tweaks simplifying the
dependencies of some of the configuration file/script packages.
It also fixes some bugs in nativesdk handling which were recently
introduced and improves some misleading package names.
The following changes since commit 6a3e57fcd3a172c9b2707510d65741734c98a143:
Revert gcc: rebase the patch to avoid patch rejection (2011-06-10 12:56:29
+0100)
are available in the git repository at:
git://git.openembedded.org/openembedded-core-contrib rpurdie/for-master
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=rpurdie/for-master
Richard Purdie (11):
pointercal: Inhibit toolchain dependencies as its just config files
formfactor: Inhibit toolchain dependencies as its just config files
keymaps: Inhibit toolchain dependencies as its just configuration
files
usbinit: Inherit allarch as its a generic script
base-files: Inherit toolchain dependencies as a compiler isn't used
poky-feed-opkg: Disable default toolchain dependencies as these are
just configuration files
initscripts: makedevs is no longer used anywhere so drop dependency.
Also inhibit compiler/libc dependencies as they're unused
sysvinit-inittab: Inhibit compiler/libc dependencies as this is just
a configuration file
initrdscripts: Inhibit compiler/libc dependencies as this is just a
configuration file
task-sdk-host: Add nativesdk to the task name so its clearer what the
contents of the task represent
nativesdk.bbclass: Correct ordering of manipulations
meta/classes/nativesdk.bbclass | 53 ++--
meta/classes/populate_sdk.bbclass |2 +-
meta/recipes-bsp/formfactor/formfactor_0.0.bb |1 +
meta/recipes-bsp/keymaps/keymaps_1.0.bb|2 +
meta/recipes-bsp/pointercal/pointercal_0.0.bb |1 +
meta/recipes-bsp/usbinit/usbinit.bb|4 +-
meta/recipes-core/base-files/base-files_3.0.14.bb |2 +
.../feed-config/poky-feed-config-opkg_1.0.bb |1 +
.../initrdscripts/initramfs-live-install_1.0.bb|1 +
meta/recipes-core/initscripts/initscripts_1.0.bb |6 +-
.../sysvinit/sysvinit-inittab_2.88dsf.bb |2 +
...task-sdk-host.bb = task-sdk-host-nativesdk.bb} |0
meta/recipes-qt/meta/meta-toolchain-qte.bb |2 +-
...ost.bb = task-qte-toolchain-host-nativesdk.bb} |2 +-
14 files changed, 55 insertions(+), 24 deletions(-)
rename meta/recipes-core/tasks/{task-sdk-host.bb =
task-sdk-host-nativesdk.bb} (100%)
rename meta/recipes-qt/tasks/{task-qte-toolchain-host.bb =
task-qte-toolchain-host-nativesdk.bb} (70%)
--
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] Where is atom-pc.conf hiding?
On Mon, 2011-06-13 at 15:10 -0700, Tom Rini wrote: On 06/13/2011 02:30 PM, Richard Purdie wrote: On Mon, 2011-06-13 at 22:36 +0200, Koen Kooi wrote: Op 13 jun 2011, om 22:28 heeft Saul Wold het volgende geschreven: On 06/13/2011 11:31 AM, Koen Kooi wrote: Hi, Khem was asking if I could reproduce the recent x86 breakage he was seeing[1] and I ran into another bug: koen@dominion:/OE/tentacle/sources/meta-intel$ git blame meta-n450/conf/machine/n450.conf | grep atom 158f88d7 (Saul Wold 2011-01-03 15:33:52 -0800 6) require conf/machine/atom-pc.conf meta-yocto seems to be the place you need to look! I hope that the layering tools can help to detect and inform folks of this like of dependency. Isn't meta-yocto supposed to a the integration layer with no new parts? I can't use meta-yocto since it has conflicting beagleboard stuff in it, which means that meta-intel is now broken for me as well. That surely isn't the intended plan?!?! The plan on public record is that atom-pc moves to meta-intel as soon as the layer tooling comes online and meta-yocto becomes its own repo (which at present its not but its certainly the intent). Until then, and even afterwards can we please get some testing of non-poky builds done? I know the autobuilder is full but can't we toss a few things onto a personal box and try that a few times a week? Sure, the more people testing the various combinations the better! Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Where is atom-pc.conf hiding?
On Mon, 2011-06-13 at 15:44 -0700, Tom Rini wrote: On 06/13/2011 03:35 PM, Richard Purdie wrote: On Mon, 2011-06-13 at 15:10 -0700, Tom Rini wrote: On 06/13/2011 02:30 PM, Richard Purdie wrote: On Mon, 2011-06-13 at 22:36 +0200, Koen Kooi wrote: Op 13 jun 2011, om 22:28 heeft Saul Wold het volgende geschreven: On 06/13/2011 11:31 AM, Koen Kooi wrote: Hi, Khem was asking if I could reproduce the recent x86 breakage he was seeing[1] and I ran into another bug: koen@dominion:/OE/tentacle/sources/meta-intel$ git blame meta-n450/conf/machine/n450.conf | grep atom 158f88d7 (Saul Wold 2011-01-03 15:33:52 -0800 6) require conf/machine/atom-pc.conf meta-yocto seems to be the place you need to look! I hope that the layering tools can help to detect and inform folks of this like of dependency. Isn't meta-yocto supposed to a the integration layer with no new parts? I can't use meta-yocto since it has conflicting beagleboard stuff in it, which means that meta-intel is now broken for me as well. That surely isn't the intended plan?!?! The plan on public record is that atom-pc moves to meta-intel as soon as the layer tooling comes online and meta-yocto becomes its own repo (which at present its not but its certainly the intent). Until then, and even afterwards can we please get some testing of non-poky builds done? I know the autobuilder is full but can't we toss a few things onto a personal box and try that a few times a week? Sure, the more people testing the various combinations the better! I fear I'm not being clear. Can You, Saul and maybe other folks making frequent submissions and are at times more poky-oriented than not, do this as well? While I'd love the world I'd settle for a bunch of -g's to catch obvious problems and a console-image or something.. Since you're highlighting me personally here, I do test a variety of things periodically. I only have access to one desktop machine and one Linux laptop so just like everyone else the testing I can physically do is limited. I also merge a ton of changes from various people and rely at some level on trust of those people to have tested changes. I know Saul also does a lot of testing of various combinations. It might not always be the combination you personally want but its certainly better than no testing at all. OE is getting a number of new computer resources soon thanks to the Linux Foundation and testing OE-Core is on Tom King's todo list. Yocto is also stepping up and doing a lot of testing. It is hardware limited and also looking to increase its resources which is planned and happening, albeit slower than we'd like in an ideal world. So on the one hand I do understand your concern. I'm personally and Yocto are doing the best we can. On the other I'd suggest if testing certain combinations is this important to you (or Mentor?), stepping up and helping with the testing would be *much* appreciated and it isn't the sole responsibility of myself or Saul. Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Where is atom-pc.conf hiding?
On Mon, 2011-06-13 at 23:17 +, Otavio Salvador wrote: On Mon, Jun 13, 2011 at 23:04, Richard Purdie richard.pur...@linuxfoundation.org wrote: ... So on the one hand I do understand your concern. I'm personally and Yocto are doing the best we can. On the other I'd suggest if testing certain combinations is this important to you (or Mentor?), stepping up and helping with the testing would be *much* appreciated and it isn't the sole responsibility of myself or Saul. ... It would be easier and better if people at Yocto could start basing their work on oe-core so stuff get tested there instead of Poky. Poky would then be an integration point not a base. Have you looked at the delta recently? Yocto uses OE-Core with the single addition of the meta-yocto layer which is tiny. Just like angstrom use the meta-angstrom layer and the meta-oe layer. More then once I got broken trees for stuff that were pushed to oe-core and were not working due missing fixes or features that were pushed to Poky's bitbake but not to the upstream one. Again, please look at the delta between upstream bitbake and the one in poky. All bitbake patches are now landing upstream first. There were issues, we came up with a plan to address them and we're doing what we said we would do... Doing this would help to improve it a lot. For example meta-intel would be already fixed since people would be using it against oe-core and would have already noticed the missing machine definition and like. We *know* the machine definition isn't there, its deliberate. We came up with a plan to create OE-Core and to get Poky and OE both migrated to using it. This process is not 100% complete yet although it gets closer every day. Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Where is atom-pc.conf hiding?
On Tue, 2011-06-14 at 08:44 +0100, Phil Blundell wrote: On Mon, 2011-06-13 at 15:10 -0700, Tom Rini wrote: Until then, and even afterwards can we please get some testing of non-poky builds done? I know the autobuilder is full but can't we toss a few things onto a personal box and try that a few times a week? I can probably find some spare cpu cycles to do testing. Is there an existing autobuild/autotest infrastructure that we can conveniently use to drive the tests and report the status? Buildbot is what Yocto is using and the documentation/sample config for what we do is available at: http://git.yoctoproject.org/cgit.cgi/poky-autobuilder/ 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 PULL 00/51] 14-June-2011
Hi Saul, I did a merge of the easy ones in this series. There are some I've left pending a little further review or feedback. On Tue, 2011-06-14 at 01:01 -0700, Saul Wold wrote: This has number fixes for various issues along with recipe updates. While the autobuidler does not look so great, these have built on local machines in a cleaner environment. I removed the large patchset for GCC, it can be reviewed at the browse URL below I merged these with the exception of: Kang Kai (2): eglibc: migrate configurability from oe I wanted to read through this one again... Khem Raj (6): uclibc.inc: libsegfault is only RPROVIDED by uclibc I'm not 100% sure this is a good idea for various reasons, I need to reply about ti. gcc-4.6.0: Bring in patches from FSF 4.6 branch I suspect using gcc svn might be better at this point so we might as well skip merging this and switch straight over. Koen Kooi (2): qemu.inc: append to IMAGE_FSTYPES instead of weakly assigning them This needs more discussion as it forces users to build two image types and I'm not sure that every user will appreciate this. Phil Blundell (5): busybox: backport distro-features handling from oe master I also wanted to read through this one again... Saul Wold (8): json-glib: Fix up SRC_URI Checksums This patch looks like a whitespace change only? alsa-tools: fix Checksums This patch has something which looks unintended. 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] Upgrade gcc 4.6.0 to latest on FSF 4.6 branch
On Tue, 2011-06-14 at 10:28 +0100, Phil Blundell wrote: On Mon, 2011-06-13 at 10:12 -0700, Khem Raj wrote: On Mon, Jun 13, 2011 at 1:51 AM, Phil Blundell p...@pbcl.net wrote: On Sun, 2011-06-12 at 21:03 -0700, Khem Raj wrote: This patch brings in new patches from gcc 4.6 FSF branch And refreshes the headers of existing backported patches to not have git patch numbers in comments I am not sending the patch itself to mailing list due to its large size so please review it on the contrib tree itself Would we not be better off just pulling the tip of the 4.6 branch from FSF SVN, rather than having to keep all these patches in git? there is dislike for this approach in oe-core. As the release point is preferred I suggested to drop the minor release number and call the recipes 4.6 and use SVN REVs to track the recipe updates but it did not fly :) Where does that dislike come from? Koen did make a comment about having liked svn checkouts for 4.5 very, very much but I couldn't quite figure out whether he was being sarcastic or not and, if so, what exactly his objection was. I could understand there being a preference for individual patchsets if we were just going to cherry-pick carefully selected bugfixes from the branch and patch them in. But, if we're going to take the approach of just importing everything from the branch en masse, it seems like keeping them as patches is just making more work for ourselves. We're using svn checkouts for eglibc, which seems to be working well enough and hasn't provoked any particular outrage that I noticed. I think it was my dislike that Khem is referring to. I was under the impression that we were going to be more selective that just taking everything (e.g. the translation updates probably aren't essential to us). I realise its easier to just take everything though and if we are going to do that it probably does make sense to use svn directly. I'll take a patch to do that. 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 V2] allarch.bbclass: Set FEED_ARCH to original value of BASE_PACKAGE_ARCH and then set BASE_PACKAGE_ARCH to 'all'
On Tue, 2011-06-14 at 14:13 -0700, Khem Raj wrote:
Signed-off-by: Khem Raj raj.k...@gmail.com
---
meta/classes/allarch.bbclass |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/meta/classes/allarch.bbclass b/meta/classes/allarch.bbclass
index e3ac392..b9ba28b 100644
--- a/meta/classes/allarch.bbclass
+++ b/meta/classes/allarch.bbclass
@@ -2,9 +2,10 @@
# This class is used for architecture independent recipes/data files (usally
scripts)
#
+# We need to pour the value of BASE_PACKAGE_ARCH into FEED_ARCH
+# before we reset it
+FEED_ARCH := ${BASE_PACKAGE_ARCH}
BASE_PACKAGE_ARCH = all
-PACKAGE_ARCH = all
-
# No need for virtual/libc or a cross compiler
INHIBIT_DEFAULT_DEPS = 1
This is a *really* bad idea. An all package should have no need to set
architecture specific values into FEED_ARCH.
Just for those not following IRC, the problem is Angstrom adds FEED_ARCH
to OVERRIDES. Adding all to overrides turns out to do nasty things to
classes like rm_work with _all in the function names.
I'd suggest that various machines should start adding things like armv7a
to ${MACHINEOVERRIDES} which has a much more clearly defined scope and
that FEED_ARCH should quietly die ;-).
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 V2] allarch.bbclass: Set FEED_ARCH to original value of BASE_PACKAGE_ARCH and then set BASE_PACKAGE_ARCH to 'all'
On Wed, 2011-06-15 at 10:56 +0200, Koen Kooi wrote:
Op 14 jun 2011, om 23:24 heeft Richard Purdie het volgende geschreven:
On Tue, 2011-06-14 at 14:13 -0700, Khem Raj wrote:
Signed-off-by: Khem Raj raj.k...@gmail.com
---
meta/classes/allarch.bbclass |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/meta/classes/allarch.bbclass b/meta/classes/allarch.bbclass
index e3ac392..b9ba28b 100644
--- a/meta/classes/allarch.bbclass
+++ b/meta/classes/allarch.bbclass
@@ -2,9 +2,10 @@
# This class is used for architecture independent recipes/data files
(usally scripts)
#
+# We need to pour the value of BASE_PACKAGE_ARCH into FEED_ARCH
+# before we reset it
+FEED_ARCH := ${BASE_PACKAGE_ARCH}
BASE_PACKAGE_ARCH = all
-PACKAGE_ARCH = all
-
# No need for virtual/libc or a cross compiler
INHIBIT_DEFAULT_DEPS = 1
This is a *really* bad idea. An all package should have no need to set
architecture specific values into FEED_ARCH.
Just for those not following IRC, the problem is Angstrom adds FEED_ARCH
to OVERRIDES. Adding all to overrides turns out to do nasty things to
classes like rm_work with _all in the function names.
So I did the following in angstrom.inc:
# Add FEED_ARCH and SOC_FAMILY to machine overrides so we get access to e.g.
'armv7a' and 'omap3'
# Hopefully we'll never see a machine or arch with 'all' as substring
MACHINEOVERRIDES .= :${@bb.data.getVar('FEED_ARCH',
d,1).replace('all','noarch')}:${SOC_FAMILY}
That makes parsing work for MACHINE=crownbay again, but:
koen@dominion:/OE/tentacle/sources/meta-openembedded$ MACHINE=crownbay
bitbake foo
NOTE: Out of date cache found, rebuilding...
NOTE: angstrom DOES NOT support gconf-dbus because gconf-dbus has been merged
back into main GConf
| ETA: 00:03:09
NOTE: angstrom DOES NOT support gconf-dbus-native because gconf-dbus has been
merged back into main GConf
NOTE: angstrom DOES NOT support libiconv because the eglibc provided iconv
library is used##
| ETA: 00:00:44
NOTE: angstrom DOES NOT support libiconv because the eglibc provided iconv
library is used#
| ETA: 00:00:24
Parsing recipes: 100%
||
Time: 00:01:52
Parsing of 1287 .bb files complete (0 cached, 1287 parsed). 1655 targets, 60
skipped, 0 masked, 0 errors.
Traceback (most recent call last):
File /usr/lib/python2.6/multiprocessing/util.py, line 235, in
_run_finalizers
Traceback (most recent call last):
File /usr/lib/python2.6/multiprocessing/util.py, line 235, in
_run_finalizers
Traceback (most recent call last):
File /usr/lib/python2.6/multiprocessing/util.py, line 235, in
_run_finalizers
Traceback (most recent call last):
File /usr/lib/python2.6/multiprocessing/util.py, line 235, in
_run_finalizers
finalizer()
File /usr/lib/python2.6/multiprocessing/util.py, line 174, in __call__
res = self._callback(*self._args, **self._kwargs)
File /OE/tentacle/sources/bitbake/lib/bb/codeparser.py, line 91, in
parser_cache_save
finalizer()
File /usr/lib/python2.6/multiprocessing/util.py, line 174, in __call__
res = self._callback(*self._args, **self._kwargs)
File /OE/tentacle/sources/bitbake/lib/bb/codeparser.py, line 91, in
parser_cache_save
finalizer()
File /usr/lib/python2.6/multiprocessing/util.py, line 174, in __call__
res = self._callback(*self._args, **self._kwargs)
File /OE/tentacle/sources/bitbake/lib/bb/codeparser.py, line 91, in
parser_cache_save
finalizer()
File /usr/lib/python2.6/multiprocessing/util.py, line 174, in __call__
res = self._callback(*self._args, **self._kwargs)
File /OE/tentacle/sources/bitbake/lib/bb/codeparser.py, line 91, in
parser_cache_save
data, version = p.load()
ValueError: could not convert string to int
data, version = p.load()
ValueError: could not convert string to int
data, version = p.load()
data, version = p.load()
ValueError: could not convert string to int
ValueError: could not convert string to int
ERROR: Command execution failed: Traceback (most recent call last):
File /OE/tentacle/sources/bitbake/lib/bb/command.py, line 99, in
runAsyncCommand
self.cooker.updateCache()
File /OE/tentacle/sources/bitbake/lib/bb/cooker.py, line 937, in
updateCache
if not self.parser.parse_next():
File /OE/tentacle/sources/bitbake/lib/bb/cooker.py, line 1247, in
parse_next
self.shutdown()
File /OE/tentacle/sources/bitbake/lib/bb/cooker.py, line 1236, in shutdown
Re: [OE-core] [PATCH 0/1] linux-yocto: update meta branch SRCREV
On Wed, 2011-06-15 at 00:05 -0400, Bruce Ashfield wrote: Richard/Saul, The patch really says it all, so I'm repeating it here: [ Updating the meta SRCREV to fix a bad commit which resulted in the tree being dirty after checkpoint, and hence a failure during the patch phase. The meta commits never modify code outside the 'meta' directory tree, a rule that was broken with this bad commit. Without this fix, you may see an error like: | [INFO] doing kernel configme | [INFO] Finding user(s) of branch yocto/standard/fsl-mpc8315e-rdb | [INFO] Branch meta-temp used by fsl-mpc8315e-rdb-standard.scc | [INFO] collecting configs in ./meta/meta-series | [INFO] checking out yocto/standard/fsl-mpc8315e-rdb | error: Your local changes to the following files would be overwritten by checkout: | arch/powerpc/boot/dts/mpc8315erdb.dts | Please, commit your changes or stash them before you can switch branches. | Aborting | [ERROR] Checkout of yocto/standard/fsl-mpc8315e-rdb failed | Error running the meta series for collecting config data | config of meta-temp (fsl-mpc8315e-rdb-standard.scc) failed ] The linux-yocto tree was fixed a few days ago, and the dust has settled enough (I hope) on the recipe renames that this can now go out. The following changes since commit 7aa7673459376aff911cef820c9417c998d1aa96: Bruce Ashfield (1): meta-yocto/linux-yocto: update to match the renamed linux-yocto recipes are available in the git repository at: git://git.pokylinux.org/poky-contrib zedd/kernel http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=zedd/kernel Bruce Ashfield (1): linux-yocto: update meta branch SRCREV 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 V2] allarch.bbclass: Set FEED_ARCH to original value of BASE_PACKAGE_ARCH and then set BASE_PACKAGE_ARCH to 'all'
On Wed, 2011-06-15 at 09:00 +0200, Koen Kooi wrote:
Op 15 jun 2011, om 01:12 heeft Khem Raj het volgende geschreven:
On Tue, Jun 14, 2011 at 2:44 PM, Koen Kooi k...@dominion.thruhere.net
wrote:
Op 14 jun 2011, om 23:40 heeft Khem Raj het volgende geschreven:
On Tue, Jun 14, 2011 at 2:32 PM, Koen Kooi k...@dominion.thruhere.net
wrote:
Op 14 jun 2011, om 23:24 heeft Richard Purdie het volgende geschreven:
On Tue, 2011-06-14 at 14:13 -0700, Khem Raj wrote:
Signed-off-by: Khem Raj raj.k...@gmail.com
---
meta/classes/allarch.bbclass |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/meta/classes/allarch.bbclass
b/meta/classes/allarch.bbclass
index e3ac392..b9ba28b 100644
--- a/meta/classes/allarch.bbclass
+++ b/meta/classes/allarch.bbclass
@@ -2,9 +2,10 @@
# This class is used for architecture independent recipes/data files
(usally scripts)
#
+# We need to pour the value of BASE_PACKAGE_ARCH into FEED_ARCH
+# before we reset it
+FEED_ARCH := ${BASE_PACKAGE_ARCH}
BASE_PACKAGE_ARCH = all
-PACKAGE_ARCH = all
-
# No need for virtual/libc or a cross compiler
INHIBIT_DEFAULT_DEPS = 1
This is a *really* bad idea. An all package should have no need to set
architecture specific values into FEED_ARCH.
Just for those not following IRC, the problem is Angstrom adds FEED_ARCH
to OVERRIDES. Adding all to overrides turns out to do nasty things to
classes like rm_work with _all in the function names.
So why don't we just set PACKAGE_ARCH = all in allarch.bbclass and not
touch BASE_PACKAGE_ARCH and FEED_ARCH?
because there are some machines conf files which use BASE_PACKAGE_ARCH
e.g.
tune-xscale.inc
BASE_PACKAGE_ARCH = ${@['armv5teb',
'armv5te'][bb.data.getVar('SITEINFO_ENDIANESS', d, 1) == 'le']}
PACKAGE_EXTRA_ARCHS = ${@['armeb armv4b armv4tb armv5teb', 'arm armv4
armv4t armv5te'][bb.data.getVar('SITEINFO_ENDIANESS', d, 1) == 'le']}
and this does not get evaluated properly then
But that wouldn't matter in the scope of allarch, though?
SITEINFO_ENDIANESS = ${@siteinfo_get_endianess(d)}
def siteinfo_get_endianess(d):
info = get_siteinfo_list(d)
if 'endian-little' in info:
return le
elif 'endian-big' in info:
return be
bb.error(Site info could not determine endianess for target)
and
get_siteinfo_list has this
targetinfo = {\
allarch-linux: ,\
hence siteinfo_get_endianess ends up with
bb.error(Site info could not determine endianess for target)
may be we need to differentiate with None return and empty string
return along with 'endian-little' and 'endian-big'
or may be add another option called 'endian-neutral'
Or just add a bogus endianness:
http://cgit.openembedded.org/cgit.cgi/meta-openembedded/commit/?id=f95ffd6cedb2a0fcad9db1b2d612663a327be87b
This is just papering over cracks. allarch packages shouldn't be
querying endianness, it really is that simple.
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 V2] allarch.bbclass: Set FEED_ARCH to original value of BASE_PACKAGE_ARCH and then set BASE_PACKAGE_ARCH to 'all'
On Wed, 2011-06-15 at 12:37 +0200, Koen Kooi wrote: Op 15 jun 2011, om 12:22 heeft Richard Purdie het volgende geschreven: On Wed, 2011-06-15 at 12:15 +0200, Koen Kooi wrote: Op 15 jun 2011, om 12:07 heeft Richard Purdie het volgende geschreven: I know, but we have two choices: a) Continue this spiral of confusing variable names, conflict and wacky bugs b) Come up with a plan to address it and roll it out I'm favouring b), particularly since this would help several different architectures with a variety of issues. If we need to better document that and have a process fine, but that is not a good argument for not doing it at all. I agree on that, put previous efforts in the yocto universe were rushed through (like the machine-name - machine_name change I keep going on about), so I have a knee jerk reaction to such things nowadays. For various reasons yocto and later oe-core have not been friendly to distros having package feeds out there. Sometimes the changes made things better, but they were still painfull. It seems to be getting better nowadays, which is good, but everyone still needs to be carefull. Pet peeve: missing PR bumps. Well, I think everyone is trying to improve, trying to do better and hopefully we are learning from any mistakes made. What I need for angstrom is a variable that:For 1) *never* changes its value As I've mentioned several times, I think it is reasonable to allarch to clear or otherwise invalidate such a variable. That is a very special case though and setting it to all was perhaps a poor choice of value. 2) holds the base arch (armv7a, ppc603e, etc) Sounds like BASE_PACKAGE_ARCH 3) Is set in *all* the tune include files Again sounds like BASE_PACKAGE_ARCH. Can it not default to TARGET_ARCH? Grepping the tune files in OE-Core we seem to be pretty good about this right now. 4) must be set to complete parsing when MACHINE is set I suspect this doesn't give as much value as you'd think but I'm indifferent. I don't care if it's in overrides by default or not since that's easy enough to do in distro configs. Is this a decision the machine/tune files should make or the distro though? 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] eglibc_2.12.bb: Remove already upstreamed fix-for-make-3.82.diff
On Tue, 2011-06-14 at 11:53 -0700, Khem Raj wrote: This patch is already applied to eglibc 2.12 branch as seen here http://www.eglibc.org/cgi-bin/viewcvs.cgi/branches/eglibc-2_12/libc/manual/Makefile?rev=12230sortby=dater2=12230r1=10495 Signed-off-by: Khem Raj raj.k...@gmail.com --- .../eglibc/eglibc-2.12/fix-for-make-3.82.diff | 27 meta/recipes-core/eglibc/eglibc_2.12.bb|3 +- 2 files changed, 1 insertions(+), 29 deletions(-) delete mode 100644 meta/recipes-core/eglibc/eglibc-2.12/fix-for-make-3.82.diff 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] eglibc: bump PR for SRCREV changes
On Tue, 2011-06-14 at 21:23 +0200, Koen Kooi wrote: Signed-off-by: Koen Kooi k...@dominion.thruhere.net --- meta/recipes-core/eglibc/eglibc_2.12.bb |2 +- meta/recipes-core/eglibc/eglibc_2.13.bb |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) Applied 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] bind: adjust hardcoded install path references
On Wed, 2011-06-15 at 15:26 +0100, Phil Blundell wrote: Fixes do_install() on micro, which otherwise fails for obvious reasons. Signed-off-by: Phil Blundell ph...@gnu.org --- meta/recipes-connectivity/bind/bind_9.7.2-P3.bb | 10 +- 1 files changed, 5 insertions(+), 5 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] 'elfutils' needed to build kernel (perf), but not listed in DEPENDS
On Mon, 2011-06-20 at 13:09 +0200, Koen Kooi wrote: Hi, I finally tracked down the heisenbug that was causing kernel builds to fail: kernel*bbclass has no DEPENDS on elfutils, but it still tries to build perf. While grepping I also stumbled accross this gem: image-swab.bbclass:PARALLEL_MAKE_pn-elfutils = Parallel make fails only when using swabber? Correct, we're still trying to work out why this only happens with swabber and whether its a real PARALLEL_MAKE issue or some kind of bad interaction with make :( Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] Multilib Development Update
We've been experimenting with multilib and I now feel it right to discuss the changes a bit further now there is something to discuss :). The work so far on this is available on the branch: http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=rpurdie/ml There have been a few issues and some lessons to learn. I've also have to make some implementation decisions based on the issues we were running into. To summarise them: a) bitbake has issues if you try and delete variables from the data store. Patches two and three on the branch fix the issues I was seeing. More details are in the commits. b) I found the recent additional event in bitbake wasn't in the right place to optimally support multilib so I had to move the expandKeys() call. Since the only known user is the native/nativesdk classes in OE-Core, this should be ok to do at this point. Again, the commit has the specific details. c) When adding parameter support to BBCLASSEXTEND I added some variables so the class can figure out which class is being processed and what the parameter is. Related to this is the issue that bbclass event handlers once added always get called, even if the class isn't inherited in a subsequent recipe file! d) I switched to using multilib- as the prefix for multilib recipes. This was because using the : character didn't work out as it gets placed into paths in too many places if you add it to PN. e) I've made the assumption that if a name in PACKAGES uses PN, its at the start. f) The use of := in cross.bbclass makes life hard for multilib. There is a special section of multilib.bbclass devoted to handling those variables. Initially I approached this as two separate multilib classes but these are merged together now. g) I set the TARGET_VENDOR to the horrendously ugly string -pokymllib32. The reason is that any - characters in there breaks config.sub at present and other separators cause other issues. I suspect we can fix that going forward but for now it works albeit looking horrible. h) I had to introduce MLPREFIX for use in certain places, thankfully all in places normal recipes shouldn't need to use it. Summary is that you can now add: require conf/multilib.conf MULTILIBS = multilib:lib32 multilib:lib64 to your local.conf and then bitbake zlib lib64-zlib lib32-zlib and it will build all three configurations. Packaging of the components I've looked at is ok so far with the files in the correct directories and whilst I've not tried building an image from these, I'm optimistic :). Since various Yocto people are scheduled to work on pieces of this, I've split the subsequent work into the following tasks for development purposes: 1) Change libdir to lib64 for qemux86-64 and see what breaks. 2) Extend MULTILIB class extension to recipes required to build: a) minimal image b) LSB image? c) Sato image? d) world [stretch goal for 1.1] This task also could include a better way of specifying which recipes to extend. 3) Add support to RPM packaging backend to turn modified package names into true rpm multilib packages. 4) Add support to standard opkg backend to allow parallel install of multilib variant packages (likely to be hacky at first but also include a proposal for better native opkg support of this) 5) Add support to bitbake to pass BBEXTEND parameters from options like bitbake -b where filenames are specified on the commandline 6) Create some standard multilib configurations (x86 32+64 bit) 7) Overhaul architecture, ABI, optimisation configuration files with a view to better structure (and ease specifying multilib configurations). 8) Reconsolidate multilib + multilibcross class differences [already done by RP now] 9) Directly support multlibs within the toolchain itself [post 1.1] 10) Investigate better TARGET_VENDOR handling for config.sub. Currently we can only have ARCH-VENDOR-linux where VENDOR cannot contain - but it might be possible to relax that constraint. I'm quite pleased with the way this code feels now and it isn't working out too invasive into the rest of the system. I therefore think we have a solid base to start building the above tasks upon. There are other cleanup issues it does highlight such as the convoluted mess of MULIMACH_ARCH variables, BASE_PACKAGE_ARCH, PACKAGE_ARCH and so forth but I'll save that for a separate discussion. Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Multilib Development Update
On Tue, 2011-06-21 at 14:28 +0200, Koen Kooi wrote:
Op 21 jun 2011, om 14:14 heeft Richard Purdie het volgende geschreven:
We've been experimenting with multilib and I now feel it right to
discuss the changes a bit further now there is something to discuss :).
The work so far on this is available on the branch:
http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=rpurdie/ml
There have been a few issues and some lessons to learn. I've also have
to make some implementation decisions based on the issues we were
running into. To summarise them:
[..]
g) I set the TARGET_VENDOR to the horrendously ugly string
-pokymllib32. The reason is that any - characters in there breaks
config.sub at present and other separators cause other issues. I suspect
we can fix that going forward but for now it works albeit looking
horrible.
Angstrom has had some problems with that as well and I think DISTROs
shouldn't poke TARGET_VENDOR directly, but do something like:
bitbake.conf:
# No hyphens!
DISTROVENDOR ??= oecore
TARGET_VENDOR = -${DISTROVENDOR}
DISTRO.conf:
# No hyphens!
DISTROVENDOR = foo
Agreed, I think we're going to need to do something like 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] Using TCLIBC = uclibc in oe-core
On Tue, 2011-06-21 at 15:54 +0100, Phil Blundell wrote:
On Tue, 2011-06-21 at 15:04 +0100, Tom Parkin wrote:
The attached patch allows me to (at least) assemble the bitbake task
list when TCLIBC = uclibc. I'm not sure whether this is the correct
approach, though.
Do you know why glib-2.0.inc is doing this crazy thing in the first
place? If we're going to have code in the config files to effectively
make it think that USE_NLS is always on, maybe that check should just be
removed.
You're right though that the current line in tclibc-uclibc.inc is
clearly just wrong and should be either fixed or deleted.
It does appear to work due to code in base.bbclass which does:
use_nls = bb.data.getVar('USE_NLS_%s' % pn, d, 1)
if use_nls != None:
bb.data.setVar('USE_NLS', use_nls, d)
where this code predates the use of pn-${PN} in overrides.
Nowadays it makes sense just to use the pn- override and we should drop
this legacy stuff IMO.
Cheers,
Richard
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Multilib Development Update
On Tue, 2011-06-21 at 15:33 +0200, Eric Bénard wrote: Hi, On 21/06/2011 15:30, Richard Purdie wrote: On Tue, 2011-06-21 at 15:02 +0200, Frans Meulenbroeks wrote: As I already asked before: what is the benefit having this in embedded systems? If I am doing an embedded system I know the target hardware, and there is no need to have e.g. both 32 and 64 bit libs. This has been mentioned before but there are embedded use cases where the requirement is to have a low overhead OS using 32 bit libs and binaries to save memory but the main application (like a database server) runs in 64 bit mode with 64 bit libraries so it can take advantage of system memory, extra instructions or so forth. This applies to mips and powerpc as well as x86. The implementation is fairly self contained so if you don't want multilib, you shouldn't even be aware its there... will that feature allow to build a sdk running on both x86 and amd64 hosts whatever is the build host ? With OE-Core, you could already do this by setting SDKMACHINE and building one, then setting SDKMACHINE to the other and building it again. Looking at the code, I am strongly tempted to replace nativesdk and crosssdk with the multilib code though as I think it can reuse the same functionality. That is a step beyond where we're currently at though :) Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Directory permissions and ownership -- RFC
On Tue, 2011-06-21 at 14:12 -0500, Mark Hatle wrote: On 6/21/11 1:57 PM, Phil Blundell wrote: On Tue, 2011-06-21 at 11:43 -0500, Mark Hatle wrote: Adjust the umask to 022. This resolves the problem of dynamically generated directories (mkdir -p) and specific files (touch foo) having odd permissions. http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=mhatle/permsid=d8470b6a8efdbba04cef5d4dc1ce12720fe83621 Are you confident that this isn't going to break anything like group-shared DL_DIRs? I'm not entirely thrilled about forcing the umask to 022 for everything that bitbake does, although I can see that making it be so for particular tasks like do_install() might have some merit. Even in the latter case, though, I wonder whether we should just be paying more attention to recipe hygiene and using install -m ... with the permissions that we actually want. This is why I bring this up.. I'm a bit concerned that doing it generally will have unintended consequences. So far I am not aware of any. Moving it to a different place in the process may be better. The only issue I've found so far is that just coding int into do_install really isn't an option. Between the custom do_install components, various classes, etc.. it's difficult in the current infrastructure to find a centralized location to set the value. (I'd love to be corrected if someone things of another way of doing it.) The setting of the umask is a very low cost operation, so doing it for certain steps shouldn't cause a performance penalty... but until we figure that out this is the best and easiest solution I've come up with. How about a umask flag for tasks? If bitbake sees it for a given task it would set the umask as indicated for the task. Cheap and easy and would only impact do_install tasks... Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] Patterns in the hackery various classes need - Need API change?
I've spent quite a bit of time recently staring at the insanity that
some of our core classes have. That code generally works so people like
to leave it well alone but when you look at some of it, there is some
nasty stuff going on.
Taking cross.bbclass as an example:
# Save PACKAGE_ARCH before changing HOST_ARCH
OLD_PACKAGE_ARCH := ${PACKAGE_ARCH}
PACKAGE_ARCH = ${OLD_PACKAGE_ARCH}
# Also save BASE_PACKAGE_ARCH since HOST_ARCH can influence it
OLD_BASE_PACKAGE_ARCH := ${BASE_PACKAGE_ARCH}
BASE_PACKAGE_ARCH = ${OLD_BASE_PACKAGE_ARCH}
BASEPKG_HOST_SYS = ${HOST_ARCH}${HOST_VENDOR}-${HOST_OS}
nativesdk.bbclass:
# Update BASE_PACKAGE_ARCH and PACKAGE_ARCHS
#
OLD_PACKAGE_ARCH := ${BASE_PACKAGE_ARCH}
BASE_PACKAGE_ARCH = ${SDK_ARCH}-nativesdk
Then we have the code in base.bbclass and bitbake.conf which plays with
MULTIMACH_ARCH which as far as I can figure out is totally broken. I
have a patch I'm experimenting with to just remove that variable out.
Bottom line, we really need the machine/tune/architecture files to set
variables which we don't mess with and derive all our others from these.
The machine/tune/architecture files really need to specify two things
which in today's variable terms are:
a) The TARGET_ARCH value which is really the broad architecture
b) The BASE_PACKAGE_ARCH which is what things compiled with the tune
flags should get packaged as.
The problem is we need to change TARGET_ARCH under a number of
circumstances and BASE_PACKAGE_ARCH defaults to being derived from
TARGET_ARCH so that is also easily broken.
I'm seriously considering coming up with two new variable names and then
having bitbake exit if the machine/tune/architecture files don't define
these. We could then likely simplify some of the core code and make it
much more plain what was going on. Something like:
TARGET_BASEARCH = arm
TARGET_PKGARCH = armv7a
Would this be too painful for people or something we could do? Most
people are likely using the core tune-* files which should make this
transition a bit less painful...
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] gnome-keyring 2.32.1: fix packaging
On Sun, 2011-06-19 at 14:26 +0200, Koen Kooi wrote: NOTE: package gnome-keyring-2.32.1-r1: task do_package: Started WARNING: the following files were installed but not shipped in any package: WARNING: /usr/share/gcr/ui/gcr-import-dialog.ui WARNING: /usr/share/gcr/ui/gcr-certificate-basics-widget.ui WARNING: /usr/share/gcr/ui/gcr-unlock-options-widget.ui WARNING: /usr/lib/security/pam_gnome_keyring.so Signed-off-by: Koen Kooi k...@dominion.thruhere.net --- meta/recipes-gnome/gnome/gnome-keyring_2.32.1.bb |4 ++-- 1 files changed, 2 insertions(+), 2 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] glib-2.0 2.28.x: update to 2.28.8
On Mon, 2011-06-20 at 10:24 +0200, Koen Kooi wrote: Signed-off-by: Koen Kooi k...@dominion.thruhere.net --- ...003-gatomic-proper-pointer-get-cast.patch.patch | 28 .../0005-glib-mkenums-interpreter.patch.patch | 25 + meta/recipes-core/glib-2.0/glib-2.0_2.28.6.bb | 18 meta/recipes-core/glib-2.0/glib-2.0_2.28.8.bb | 22 +++ meta/recipes-core/glib-2.0/glib.inc|3 +- 5 files changed, 77 insertions(+), 19 deletions(-) create mode 100644 meta/recipes-core/glib-2.0/glib-2.0/0003-gatomic-proper-pointer-get-cast.patch.patch create mode 100644 meta/recipes-core/glib-2.0/glib-2.0/0005-glib-mkenums-interpreter.patch.patch delete mode 100644 meta/recipes-core/glib-2.0/glib-2.0_2.28.6.bb create mode 100644 meta/recipes-core/glib-2.0/glib-2.0_2.28.8.bb Merged to master but please be a little more verbose in future commit messages :) 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] alsa-utils 1.0.24.2: fix packaging
On Wed, 2011-06-22 at 10:42 +0200, Koen Kooi wrote: Put the rules and scripts associated with alsactl in the alsactl subpackage Signed-off-by: Koen Kooi k...@dominion.thruhere.net --- 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/1] Remove obsolete gnome-vfs
On Tue, 2011-06-21 at 15:12 +0800, edwin.z...@intel.com wrote: From: Zhai Edwin edwin.z...@intel.com This patch removed obsolete gnome-vfs in favor of GIO/GVFS. Pls. help to review. Thanks, edwin The following changes since commit 4ff7af11ef69849ef9c16f585eae58ac920b222b: machine confs: Add xserver-kdrive as PREFERRED_PROVIDER (2011-05-27 15:30:19 -0700) are available in the git repository at: g...@git.pokylinux.org:poky-contrib.git gzhai/master http://git.pokylinux.org/cgit.cgi//log/?h=gzhai/master Zhai Edwin (1): gnome-vfs: remove gnome-vfs as it is deprecated in favour of GVFS and GIO .../oprofileui/migrate-from-gnomevfs-to-gio.patch | 219 meta/recipes-kernel/oprofile/oprofileui_git.bb |1 + .../gstreamer/gst-meta-base_0.10.bb|2 +- .../gstreamer/gst-plugins-base_0.10.32.bb |6 +- meta/recipes-sato/webkit/webkit-gtk_svn.bb |2 +- 5 files changed, 224 insertions(+), 6 deletions(-) create mode 100644 meta/recipes-kernel/oprofile/oprofileui/migrate-from-gnomevfs-to-gio.patch This is nice to see, thanks! I've merged it but please try and send pull requests from a slightly more up to date branch please as this one threw conflicts that I needed to resolve in the webkit recipe. 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/4] uclibc and related fixes
On Tue, 2011-06-21 at 18:44 -0700, Khem Raj wrote: Fix uclibc build for x86_64 gettext compile failed on uclibc so fix it and additionally remove unused patches Add required support for systemd to function with uclibc Quash a parse warning where uclibc-initial and uclibc both provided libsegfault The following changes since commit 78de64f58b98101f5be5778e9ecbdaae5ba32997: binutils_2.21.bb: Fix ld segfault exposed by eglibc 2.14 on x86_64 (2011-06-21 17:58:06 -0700) are available in the git repository at: git://git.openembedded.org/openembedded-core-contrib kraj/uclibc http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=kraj/uclibc Khem Raj (4): uclibc.inc: libsegfault is only RPROVIDED by uclibc gettext-0.18.1.1: Remove unused patches uclibc/x86_64/uClibc.machine: Enable ARCH_USE_MMU uclibc: Add support for $ORIGIN Merged to master, thanks. I had reservations about the first one as hardcoding PN can have issues with BBCLASSEXTEND but looking at the recipe, there are bigger issues if we were ever to do that :/ 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] ccache: Integrate ccache-native
On Fri, 2011-06-17 at 17:19 +0800, wenzong@windriver.com wrote:
From: Wenzong Fan wenzong@windriver.com
1) Add ccache as a native tool, for getting it built automatically make
it as the dependency of bzip2; Also, the ccache will be included by SDK
images;
2) Set CCACHE on a per recipe basis and add task 'mkccachedir' to create
the CCACHE_DIR while start a package building;
3) Remove the duplicate 'ccache.inc' from 'meta/class/'.
Signed-off-by: Wenzong Fan wenzong@windriver.com
---
meta/classes/base.bbclass|1 +
meta/classes/ccache.bbclass | 21 +
meta/classes/ccache.inc | 11 ---
meta/conf/bitbake.conf |1 +
meta/recipes-core/tasks/task-core-sdk.bb |1 +
meta/recipes-devtools/ccache/ccache.inc | 16
meta/recipes-devtools/ccache/ccache_3.1.5.bb |8
meta/recipes-extended/bzip2/bzip2_1.0.6.bb |2 ++
8 files changed, 50 insertions(+), 11 deletions(-)
create mode 100644 meta/classes/ccache.bbclass
delete mode 100644 meta/classes/ccache.inc
create mode 100644 meta/recipes-devtools/ccache/ccache.inc
create mode 100644 meta/recipes-devtools/ccache/ccache_3.1.5.bb
diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index 119b052..a329b4e 100644
--- a/meta/classes/base.bbclass
+++ b/meta/classes/base.bbclass
@@ -2,6 +2,7 @@ BB_DEFAULT_TASK ?= build
inherit patch
inherit staging
+inherit ccache
inherit mirrors
inherit utils
diff --git a/meta/classes/ccache.bbclass b/meta/classes/ccache.bbclass
new file mode 100644
index 000..be37c18
--- /dev/null
+++ b/meta/classes/ccache.bbclass
@@ -0,0 +1,21 @@
+# Make ${CCACHE_DIR} if it is not existing
+
+python ccache_do_mkccachedir(){
+ import os
+
+ ccache = bb.data.getVar('CCACHE', d, True)
+ ccache_dir = bb.data.getVar('CCACHE_DIR', d, True)
+ if len(ccache) == 0 or len(ccache_dir) == 0:
+ return
+
+ try:
+ if not os.path.isdir(ccache_dir):
+ bb.note(Creating + ccache_dir)
+ os.makedirs(ccache_dir)
+ except bb.fetch2.BBFetchException, e:
+ raise bb.build.FuncFailed(e)
+}
+
+addtask mkccachedir before do_configure
+
+EXPORT_FUNCTIONS do_mkccachedir
You can do this in a much simpler way by just adding:
do_configure[dirs] += ${CCACHE_DIR}
diff --git a/meta/classes/ccache.inc b/meta/classes/ccache.inc
deleted file mode 100644
index d830a1b..000
--- a/meta/classes/ccache.inc
+++ /dev/null
@@ -1,11 +0,0 @@
-# Make ccache use a TMPDIR specific ccache directory if using the
crosscompiler,
-# since it isn't likely to be useful with any other toolchain than the one
we just
-# built, and would otherwise push more useful things out of the default
cache.
-
-CCACHE_DIR_TARGET = ${TMPDIR}/ccache
-
-python () {
-if not bb.data.inherits_class('native', d) and not
bb.data.inherits_class('cross', d):
-bb.data.setVar('CCACHE_DIR', '${CCACHE_DIR_TARGET}', d)
-bb.data.setVarFlag('CCACHE_DIR', 'export', '1', d)
-}
diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 6d8a674..64b3651 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -391,6 +391,7 @@ export PATH
CCACHE = ${@bb.which(bb.data.getVar('PATH', d, 1), 'ccache') and 'ccache '}
TOOLCHAIN_OPTIONS = --sysroot=${STAGING_DIR_TARGET}
+export CCACHE_DIR = ${TMPDIR}/ccache/${TARGET_SYS}/${PN}
Should this be HOST_SYS instead of TARGET_SYS?
export CC = ${CCACHE}${HOST_PREFIX}gcc ${HOST_CC_ARCH}${TOOLCHAIN_OPTIONS}
export CXX = ${CCACHE}${HOST_PREFIX}g++ ${HOST_CC_ARCH}${TOOLCHAIN_OPTIONS}
export F77 = ${CCACHE}${HOST_PREFIX}g77 ${HOST_CC_ARCH}${TOOLCHAIN_OPTIONS}
diff --git a/meta/recipes-core/tasks/task-core-sdk.bb
b/meta/recipes-core/tasks/task-core-sdk.bb
index 4aee0c2..52fdd75 100644
--- a/meta/recipes-core/tasks/task-core-sdk.bb
+++ b/meta/recipes-core/tasks/task-core-sdk.bb
@@ -25,6 +25,7 @@ RDEPENDS_task-core-sdk = \
coreutils \
cpp \
cpp-symlinks \
+ccache \
diffutils \
gcc \
gcc-symlinks \
diff --git a/meta/recipes-devtools/ccache/ccache.inc
b/meta/recipes-devtools/ccache/ccache.inc
new file mode 100644
index 000..e9f7344
--- /dev/null
+++ b/meta/recipes-devtools/ccache/ccache.inc
@@ -0,0 +1,16 @@
+SUMMARY = a fast C/C++ compiler cache
+DESCRIPTION = ccache is a compiler cache. It speeds up recompilation \
+by caching the result of previous compilations and detecting when the \
+same compilation is being done again. Supported languages are C, C\+\+, \
+Objective-C and Objective-C++.
+HOMEPAGE = http://ccache.samba.org;
+SECTION = devel
+LICENSE = GPLv3+
+
+SRC_URI = http://samba.org/ftp/ccache/ccache-${PV}.tar.gz;
+
+inherit autotools
+
+BBCLASSEXTEND = native
+
+TARGET_CC_ARCH +=
Re: [OE-core] [PATCH 0/1] task-core-lsb: Add absent libraries and commands to task-core-lsb.bb
On Wed, 2011-06-22 at 14:43 +0800, Xiaofeng Yan wrote: From: Xiaofeng Yan xiaofeng@windriver.com tools-profile and tools-testapps which include three packages owl-video , sysprof and alsa-utils-amixer beside other packages were removed from variable EXTRA_IMAGE_FEATURES in meta-yocto/conf/local.conf.sample. The absent libraries in an lsb image depended by the above three packages will be installed into lsb image by dependence relationship. Absent command: |--strip Absent Libraries: |--libatk-1.0.so.0 |--libgdk-x11-2.0.so |--libcairo.so.2 |--libpango-1.0.so |--libpangoft2-1.0.so.0 |--libpangoxft-1.0.so.0 |--libpangocairo-1.0.so Pull URL: git://git.pokylinux.org/poky-contrib.git Branch: xiaofeng/task-core-lsb Browse: http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=xiaofeng/task-core-lsb Thanks, Xiaofeng Yan xiaofeng@windriver.com --- Xiaofeng Yan (1): task-core-lsb: Add absent libraries and commands to task-core-lsb.bb 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/4] eglibc 2.14 upgrade
On Tue, 2011-06-21 at 18:43 -0700, Khem Raj wrote: This patchset upgrades eglibc 2.13 - 2.14 Needed a binutils fix for x86_64 Package sotruss which is new in eglibc 2.14 The following changes since commit 78de64f58b98101f5be5778e9ecbdaae5ba32997: binutils_2.21.bb: Fix ld segfault exposed by eglibc 2.14 on x86_64 (2011-06-21 17:58:06 -0700) are available in the git repository at: git://git.openembedded.org/openembedded-core-contrib kraj/eglibc-2.14 http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=kraj/eglibc-2.14 Khem Raj (4): eglibc: Upgrade recipes from 2.13 - 2.14 eglibc-package.inc: Package newly added sotruss and supporting libraries binutils_2.21.bb: Fix ld segfault exposed by eglibc 2.14 on x86_64 tcmode-default.inc: Bump EGLIBCVERSION to 2.14 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 V2 0/2] Change gcc 4.6 recipes to use svn in SRC_URI
On Tue, 2011-06-21 at 18:43 -0700, Khem Raj wrote: changes since V1 Separate out non gcc changes to a different pull request Patches are not attached inline due to sheer size of them as they might choke patchwork. The are only on the branch The following changes since commit 78de64f58b98101f5be5778e9ecbdaae5ba32997: binutils_2.21.bb: Fix ld segfault exposed by eglibc 2.14 on x86_64 (2011-06-21 17:58:06 -0700) are available in the git repository at: git://git.openembedded.org/openembedded-core-contrib kraj/gcc-4.6 http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=kraj/gcc-4.6 Khem Raj (2): gcc-4.6: Switch to using svn SRC_URI for recipe tcmode-default.inc: use 4.6 for GCCVERSION and SDKGCCVERSION I'm afraid I don't like having gcc 4.6 being so publicly visible. Its fine for the recipe names but the PV itself really needs to be something like 4.6.2+svn. I say this as a person who'd have to deal with people claiming we're behind on gcc since we were on 4.6[.0] :/ 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/4] uclibc and related fixes
On Wed, 2011-06-22 at 08:57 -0700, Khem Raj wrote: On 06/22/2011 08:42 AM, Richard Purdie wrote: On Tue, 2011-06-21 at 18:44 -0700, Khem Raj wrote: Fix uclibc build for x86_64 gettext compile failed on uclibc so fix it and additionally remove unused patches Add required support for systemd to function with uclibc Quash a parse warning where uclibc-initial and uclibc both provided libsegfault The following changes since commit 78de64f58b98101f5be5778e9ecbdaae5ba32997: binutils_2.21.bb: Fix ld segfault exposed by eglibc 2.14 on x86_64 (2011-06-21 17:58:06 -0700) are available in the git repository at: git://git.openembedded.org/openembedded-core-contrib kraj/uclibc http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=kraj/uclibc Khem Raj (4): uclibc.inc: libsegfault is only RPROVIDED by uclibc gettext-0.18.1.1: Remove unused patches uclibc/x86_64/uClibc.machine: Enable ARCH_USE_MMU uclibc: Add support for $ORIGIN Merged to master, thanks. I had reservations about the first one as hardcoding PN can have issues with BBCLASSEXTEND but looking at the recipe, there are bigger issues if we were ever to do that :/ in attached patch I moved it to uclibc recipe is that better ? Its better, yes and its what I was going to suggest until I realised there were other issues that BBCLASSEXTEND would have with the recipe. Its certainly something to keep in mind in the future... 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] Fix for bitbake freeze due to git fetch during parse
On Tue, 2011-06-21 at 18:29 +0100, Paul Eggleton wrote: Addresses [YOCTO #1186]. See patch for further details. (Sending against poky-contrib since OE git is currently experiencing issues.) The following changes since commit 2163461ec94528ecf046a04edc5db3d2dd3a6b8b: systemtap: remove non-core COMPATIBLE_MACHINES (2011-06-16 22:14:06 +0100) are available in the git repository at: git://git.pokylinux.org/poky-contrib paule/fix-uboot-srcrev http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=paule/fix-uboot-srcrev Paul Eggleton (1): u-boot: set SRCREV to a git revision instead of a tag reference meta/recipes-bsp/uboot/u-boot_2011.03.bb |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) I've merged Paul's updated version of this. Its a hard problem given git's way of handling tags/branches etc. so its probably the best we can do in the circumstances... 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] clutter: Use new git repo
On Tue, 2011-06-21 at 20:22 +0800, edwin.z...@intel.com wrote:
From: Zhai Edwin edwin.z...@intel.com
clutter move its git server from clutter-project.org to gnome.org
[YOCTO #1040] got fixed
Signed-off-by: Zhai Edwin edwin.z...@intel.com
---
meta/recipes-graphics/clutter/clutter-box2d_git.bb |2 +-
meta/recipes-graphics/clutter/clutter_git.bb |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-graphics/clutter/clutter-box2d_git.bb
b/meta/recipes-graphics/clutter/clutter-box2d_git.bb
index 4c1c003..2d10d81 100644
--- a/meta/recipes-graphics/clutter/clutter-box2d_git.bb
+++ b/meta/recipes-graphics/clutter/clutter-box2d_git.bb
@@ -6,7 +6,7 @@ SRCREV = 4799ac10ae8cb7da936a2b999aba58fe62eb1ee3
PV = 0.10.1+git${SRCPV}
PR = r0
-SRC_URI = git://git.clutter-project.org/clutter-box2d.git;protocol=git
+SRC_URI = git://git.gnome.org/clutter-box2d;protocol=git
S = ${WORKDIR}/git
diff --git a/meta/recipes-graphics/clutter/clutter_git.bb
b/meta/recipes-graphics/clutter/clutter_git.bb
index cb5f476..76a26a6 100644
--- a/meta/recipes-graphics/clutter/clutter_git.bb
+++ b/meta/recipes-graphics/clutter/clutter_git.bb
@@ -7,7 +7,7 @@ SRCREV = e957e277b8a4893ce8c99e94402036d42a8b3748
PV = 1.0.0+git${SRCPV}
PR = r9
-SRC_URI =
git://git.clutter-project.org/clutter.git;protocol=git;branch=master \
+SRC_URI = git://git.gnome.org/clutter;protocol=git;branch=master \
file://enable_tests-654c26a1301c9bc5f8e3e5e3b68af5eb1b2e0673.patch;patch=1;rev=654c26a1301c9bc5f8e3e5e3b68af5eb1b2e0673
\
file://enable_tests.patch;patch=1;notrev=654c26a1301c9bc5f8e3e5e3b68af5eb1b2e0673
S = ${WORKDIR}/git
Master already has:
http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=e4293c5be719663d75d7bc464a04a841d8b35115
Could you please rebase on top of that?
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/3] qt4-tools-nativesdk fixes
On Sat, 2011-06-18 at 19:56 +0100, Paul Eggleton wrote: Several fixes for qt4-tools-nativesdk. The following changes since commit 835d817f1ba7b99167743fdb86ba80f3a07bd82d: systemtap: remove non-core COMPATIBLE_MACHINES (2011-06-16 22:12:40 +0100) are available in the git repository at: git://git.openembedded.org/openembedded-core-contrib paule/qt4-nativesdk-fix http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=paule/qt4-nativesdk-fix Paul Eggleton (3): qt4-tools-nativesdk: fix unpack failure due to missing g++.conf qt4-tools-nativesdk: drop freetype include as we build with -no-freetype qt4-tools-nativesdk: fix compile failure in src/dbus 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 V2 0/2] Change gcc 4.6 recipes to use svn in SRC_URI
On Wed, 2011-06-22 at 17:05 +0100, Phil Blundell wrote: On Wed, 2011-06-22 at 17:00 +0100, Richard Purdie wrote: I'm afraid I don't like having gcc 4.6 being so publicly visible. Its fine for the recipe names but the PV itself really needs to be something like 4.6.2+svn. Well, er, gcc 4.6.1 hasn't even been released yet. I think 4.6.0 +svn (or just 4.6+svn) is the only reasonable thing to put there. Calling it 4.6.2 would definitely be misleading. I'm just thinking ahead ;-) 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] linux-yocto: bump SRCREVs for utrace
On Fri, 2011-06-17 at 00:38 -0400, Bruce Ashfield wrote: Richard/Saul, Updating the SRCREVs to take into acccount the utrace update from Tom. With this, the stage is set for systemtap support. Note: the pull branch also contains a change for meta-yocto, so grab the right one! The following changes since commit 2163461ec94528ecf046a04edc5db3d2dd3a6b8b: Tom Zanussi (1): systemtap: remove non-core COMPATIBLE_MACHINES are available in the git repository at: git://git.pokylinux.org/poky-contrib zedd/kernel http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=zedd/kernel Bruce Ashfield (1): linux-yocto: update SRCREVs for utrace merge 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/2] linux-yocto: consolidated merge request
On Wed, 2011-06-22 at 17:29 -0400, Bruce Ashfield wrote: Hi, This pull request contains the first iteration of the base configuration changes discussed on the list about two weeks ago, and a common USB fix that was identified during the beagleboard refresh. 94fa015 meta: add taskstats experimental feature group 4fb2ed5 meta: enable freezer support 88d619e meta: enable fuse and cuse as modules f465827 meta: add namespaces + experimental configs fbdd376 meta: add devtmpfs config group b04f6d9 meta: re-enable cgroups options in the standard kernel I've built the relevant qemu targets with the changes, and my sanity tests have all passed here. cc: Koen Kooi k...@dominion.thruhere.net cc: Daren Hart dvh...@linux.intel.com Cheers, Bruce The following changes since commit 46378aec555f08f133bf601be01dacf4bd0b7f05: Bruce Ashfield (1): linux-yocto/meta-yocto: update SRCREVs for utrace merge Merged to master (as soon as my push to the repo works), 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/4] eglibc 2.14 upgrade
On Wed, 2011-06-22 at 15:31 -0700, Khem Raj wrote: On Wed, Jun 22, 2011 at 1:28 PM, Mark Hatle mark.ha...@windriver.com wrote: On 6/22/11 1:35 PM, Mark Hatle wrote: Since applying this update, I'm not longer getting an rpc/rpc.h file, which breaks various things like busybox mount. Is anyone else seeing this behavior? Reverting: 2a68cf4d315cdd18766de0c75928ff17846a6cd7 and 190a946e9a4213944e3ee675c4b3e18701698e87 fixed the problem for me. So there is definitely a problems in the upgrade. onward looking rpc is now maintained with libtirpc starting glibc 2.14 rpc is not to be used from bundled code in glibc. If we dont have recipes for libtirpc then I will add that. There looks to be more than this wrong with this update. A quick comparison shows the following changes in the list of files being installed from do_install: -./lib/libmemusage.so -./lib/libnss_hesiod-2.13.so -./lib/libnss_nisplus-2.13.so -./lib/libutil-2.13.so -./lib/libresolv-2.13.so -./lib/libm-2.13.so -./lib/libnsl-2.13.so -./lib/libnss_compat-2.13.so -./lib/libnss_nis-2.13.so -./lib/libnss_dns-2.13.so -./lib/libanl-2.13.so -./lib/libBrokenLocale-2.13.so -./lib/libcrypt-2.13.so -./etc/rpc -./usr/lib/libnss_compat_pic.a -./usr/lib/libnss_dns_pic.a -./usr/lib/libnss_nisplus_pic.a +./usr/lib/audit/sotruss-lib.so -./usr/lib/libutil_pic.map -./usr/lib/libBrokenLocale_pic.a -./usr/lib/libBrokenLocale.a -./usr/lib/libBrokenLocale_pic.map -./usr/lib/libm.a -./usr/lib/libnss_dns_pic.map -./usr/lib/libm_pic.map -./usr/lib/libnss_hesiod_pic.map -./usr/lib/librpcsvc.a -./usr/lib/libutil.a -./usr/lib/libnss_compat_pic.map -./usr/lib/libcrypt.a -./usr/lib/libutil_pic.a -./usr/lib/libanl.a -./usr/lib/libnsl_pic.a -./usr/lib/libresolv.a -./usr/lib/libnss_hesiod_pic.a -./usr/lib/libm_pic.a -./usr/lib/libnsl_pic.map -./usr/lib/libnss_nis_pic.map -./usr/lib/libanl_pic.a -./usr/lib/libcrypt_pic.map -./usr/lib/libcrypt_pic.a -./usr/lib/libnss_nis_pic.a -./usr/lib/libresolv_pic.map -./usr/lib/libresolv_pic.a -./usr/lib/libanl_pic.map -./usr/lib/libnss_nisplus_pic.map -./usr/lib/libnsl.a -./usr/bin/rpcgen -./usr/bin/gencat +./usr/bin/sotruss -./usr/bin/localedef -./usr/bin/locale -./usr/sbin/rpcinfo -./usr/sbin/nscd Some of these are rpc related but there are other issues too. I've reverted the upgrade itself for now until we have something in place to address the issues and its actually had some testing... 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 V2 0/2] Change gcc 4.6 recipes to use svn in SRC_URI
On Thu, 2011-06-23 at 01:40 -0700, Khem Raj wrote:
On Wed, Jun 22, 2011 at 9:08 AM, Koen Kooi k...@dominion.thruhere.net wrote:
Op 22 jun 2011, om 18:00 heeft Richard Purdie het volgende geschreven:
On Tue, 2011-06-21 at 18:43 -0700, Khem Raj wrote:
changes since V1
Separate out non gcc changes to a different pull request
Patches are not attached inline due to sheer size of them
as they might choke patchwork. The are only on the branch
The following changes since commit
78de64f58b98101f5be5778e9ecbdaae5ba32997:
binutils_2.21.bb: Fix ld segfault exposed by eglibc 2.14 on x86_64
(2011-06-21 17:58:06 -0700)
are available in the git repository at:
git://git.openembedded.org/openembedded-core-contrib kraj/gcc-4.6
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=kraj/gcc-4.6
Khem Raj (2):
gcc-4.6: Switch to using svn SRC_URI for recipe
tcmode-default.inc: use 4.6 for GCCVERSION and SDKGCCVERSION
I'm afraid I don't like having gcc 4.6 being so publicly visible. Its
fine for the recipe names but the PV itself really needs to be something
like 4.6.2+svn.
I say this as a person who'd have to deal with people claiming we're
behind on gcc since we were on 4.6[.0] :/
There will always be people claiming nonsense about numbers :)
Hi Richard
I have pushed updated patches to the branch now. PV is set to
4.6.0+svnr${SRCPV}
and we use wild card in choosing gcc version
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 00/40] Various Recipe Fixes (v3)
On Wed, 2011-06-22 at 14:53 -0500, Mark Hatle wrote: V3 includes fixes to issues noticed by Phil Blundell --- version 2 below --- V2 only includes a change to patch 13, to resolve the issues mentioned by Koen. --- original comments below --- While working on the permissions and umask code, I found a number of random issues with various packages in the system. Most of these problems revolve around: * directory and file permissions, and ownership * -dbg package not being produced correctly * stripped binaries * packages that couldn't rebuild due to dependency or other issues Note, this doesn't solve the permissions and ownership issues that will come in a future patch set devoted to umask and fixing up of the permissions. The following changes since commit 17d5422460bf9074223475b15d128171d12b170a: qt4-tools-nativesdk: fix compile failure in src/dbus (2011-06-22 17:41:39 +0100) are available in the git repository at: git://git.pokylinux.org/poky-contrib mhatle/recipe-fixup http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=mhatle/recipe-fixup Mark Hatle (40): resolveconf: Fix file owners base-passwd: Fix owners/groups gcc: Fix owners/groups ghostscript: Fix owner/group of /etc/cups libtirpc: Fix owner/group of /etc/netconfig tzdata: Ensure all files are owned by root:root gnome-doc-utils: Fix the owner/group on select files perf: Fix linux-tools to ensure perf is installed under fakeroot kernel.bbclass: Add support for perf-dbg package sysfsutils: Fall back to default -dbg package classes/package_rpm.bbclass: Enhance diagnostic messages classes/package_rpm.bbclass: Change the way the PV is transformed python: Switch to using the default -dbg package python-pyobject: Remove unnecessary -dbg setting libxml-parser-perl: Fix debug package texinfo: Change to use the standard -dbg file psmisc: Remove custom -dbg packages, use default modutils: Add in missing -dbg package liba52: Remove custom -dbg, fall back to default python-gst: Add missing files to the -dbg package mc: Add missing debug files to -dbg gamin: Add missing debug files to -dbg gthumb: Add missing debug files systemtamp: Add missing debug files trace-cmd: Add missing debug files gstreamer: Add missing debug files. gtk-sato-engine: Add missing debug files libproxy: Add missing debug files wireless-tools: Avoid stripping binaries busybox: Avoid stripping binaries tinylogin: Avoid stripped binaries quote: Avoid stripping binaries sysstat: Avoid stripping binaries db: Avoid stripping binaries db: Fix file ownership unzip: Avoid stripping binaries dropbear: Don't patch in configure nasm: Fix aclocal python: Add python to the dependencies of python modules boost: Move the do_configure_prepend to a seperate task I did a first pass over this series and merged the ones I was happy with. This leaves: git cherry-pick 5c4ce64fb0bf1c4e8a5899e292917836953412d3 git cherry-pick 7e9ca99962148df2cee0f69ba2f7408788789af5 git cherry-pick 4357212d04ad3bc4e286b72d74136f8d59e4b15c git cherry-pick 27ede7006d75bd6cae3677da9a54b5092b2d4079 git cherry-pick 5f3bcbaf87ce947d48c5683917d9fc99a13e7a33 git cherry-pick b39384a74aa03db222a39a023b4cb1a6a07dd5a5 git cherry-pick a579d68ffe5c162a182d7f4157564f17294a8ff5 git cherry-pick d215f1d253f3ef2ef4f74de36d39334a6939ee5e and also this one which doesn't apply any more due to other gcc changes I merged: git cherry-pick 60f955a2ba068db9e5d072c443a6ef7a894f114e Why didn't I take these? My reasons included: a) I didn't think the python dependency changes looked right b) The whole test -n eval thing looks wrong. I don't see why its needed and would like to debug that. c) I wanted to think a little further about how to handle chown in do_install since we really need an easy way to make that a null op for native cases easily. Options: * Don't call chown but wrap it in our own script oe-chown * Add an intercept script in PATH which would avoid root ops in the native case * Prefix the calls with some kind of magic It might be the answer is not to worry about it right now but it seems a good time to consider it. Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 3/4] classes/conf: Drop MULTIMACH_ARCH variable, it adds unused complexity and serves no useful purpose
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
---
meta/classes/base.bbclass |8 +---
meta/classes/cross-canadian.bbclass | 14 +++---
meta/classes/sstate.bbclass |4 ++--
meta/conf/bitbake.conf |9 ++---
4 files changed, 12 insertions(+), 23 deletions(-)
diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index f390f08..0bea639 100644
--- a/meta/classes/base.bbclass
+++ b/meta/classes/base.bbclass
@@ -362,11 +362,8 @@ python () {
if local.startswith(mp):
#bb.note(overriding PACKAGE_ARCH from %s to %s %
(pkg_arch, mach_arch))
bb.data.setVar('PACKAGE_ARCH', ${MACHINE_ARCH}, d)
-bb.data.setVar('MULTIMACH_ARCH', mach_arch, d)
return
-multiarch = pkg_arch
-
packages = bb.data.getVar('PACKAGES', d, 1).split()
for pkg in packages:
pkgarch = bb.data.getVar(PACKAGE_ARCH_%s % pkg, d, 1)
@@ -375,10 +372,7 @@ python () {
# if multiple differences are present?
# Look through PACKAGE_ARCHS for the priority order?
if pkgarch and pkgarch == mach_arch:
-multiarch = mach_arch
-break
-
-bb.data.setVar('MULTIMACH_ARCH', multiarch, d)
+bb.fatal(Recipe %s is marked as only being architecture specific
but seems to have machine specific packages? % d.getVar(PN, True))
}
def check_gcc3(data):
diff --git a/meta/classes/cross-canadian.bbclass
b/meta/classes/cross-canadian.bbclass
index 1a045ba..edd51da 100644
--- a/meta/classes/cross-canadian.bbclass
+++ b/meta/classes/cross-canadian.bbclass
@@ -9,14 +9,14 @@
# or indirectly via dependency. No need to be in 'world'.
EXCLUDE_FROM_WORLD = 1
-STAGING_BINDIR_TOOLCHAIN =
${STAGING_DIR_NATIVE}${bindir_native}/${SDK_ARCH}${SDK_VENDOR}-${SDK_OS}:${STAGING_DIR_NATIVE}${bindir_native}/${OLD_PACKAGE_ARCH}${TARGET_VENDOR}-${TARGET_OS}
+STAGING_BINDIR_TOOLCHAIN =
${STAGING_DIR_NATIVE}${bindir_native}/${SDK_ARCH}${SDK_VENDOR}-${SDK_OS}:${STAGING_DIR_NATIVE}${bindir_native}/${OLD_BASE_PACKAGE_ARCH}${TARGET_VENDOR}-${TARGET_OS}
#
# Update BASE_PACKAGE_ARCH and PACKAGE_ARCHS
#
-OLD_MULTIMACH_ARCH := ${MULTIMACH_ARCH}
+OLD_PACKAGE_ARCH := ${PACKAGE_ARCH}
OLD_MULTIMACH_TARGET_SYS := ${MULTIMACH_TARGET_SYS}
-OLD_PACKAGE_ARCH := ${BASE_PACKAGE_ARCH}
+OLD_BASE_PACKAGE_ARCH := ${BASE_PACKAGE_ARCH}
BASE_PACKAGE_ARCH = ${SDK_ARCH}-nativesdk
python () {
archs = bb.data.getVar('PACKAGE_ARCHS', d, True).split()
@@ -25,7 +25,7 @@ python () {
sdkarchs.append(arch + '-nativesdk')
bb.data.setVar('PACKAGE_ARCHS', .join(sdkarchs), d)
}
-MULTIMACH_TARGET_SYS = ${MULTIMACH_ARCH}${HOST_VENDOR}-${HOST_OS}
+MULTIMACH_TARGET_SYS = ${PACKAGE_ARCH}${HOST_VENDOR}-${HOST_OS}
INHIBIT_DEFAULT_DEPS = 1
@@ -66,12 +66,12 @@ target_exec_prefix := ${exec_prefix}
base_prefix = ${SDKPATHNATIVE}
prefix = ${SDKPATHNATIVE}${prefix_nativesdk}
exec_prefix = ${SDKPATHNATIVE}${prefix_nativesdk}
-bindir =
${exec_prefix}/bin/${OLD_MULTIMACH_ARCH}${TARGET_VENDOR}-${TARGET_OS}
+bindir = ${exec_prefix}/bin/${OLD_PACKAGE_ARCH}${TARGET_VENDOR}-${TARGET_OS}
sbindir = ${bindir}
base_bindir = ${bindir}
base_sbindir = ${bindir}
-libdir =
${exec_prefix}/lib/${OLD_MULTIMACH_ARCH}${TARGET_VENDOR}-${TARGET_OS}
-libexecdir =
${exec_prefix}/libexec/${OLD_MULTIMACH_ARCH}${TARGET_VENDOR}-${TARGET_OS}
+libdir = ${exec_prefix}/lib/${OLD_PACKAGE_ARCH}${TARGET_VENDOR}-${TARGET_OS}
+libexecdir =
${exec_prefix}/libexec/${OLD_PACKAGE_ARCH}${TARGET_VENDOR}-${TARGET_OS}
FILES_${PN} = ${prefix}
FILES_${PN}-dbg += ${prefix}/.debug \
diff --git a/meta/classes/sstate.bbclass b/meta/classes/sstate.bbclass
index 6358d39..14c90ec 100644
--- a/meta/classes/sstate.bbclass
+++ b/meta/classes/sstate.bbclass
@@ -5,8 +5,8 @@ SSTATE_MANFILEBASE =
${SSTATE_MANIFESTS}/manifest-${SSTATE_MANMACH}-
SSTATE_MANFILEPREFIX = ${SSTATE_MANFILEBASE}${PN}
-SSTATE_PKGARCH= ${MULTIMACH_ARCH}
-SSTATE_PKGSPEC=
sstate-${PN}-${MULTIMACH_ARCH}${TARGET_VENDOR}-${TARGET_OS}-${PV}-${PR}-${SSTATE_PKGARCH}-${SSTATE_VERSION}-
+SSTATE_PKGARCH= ${PACKAGE_ARCH}
+SSTATE_PKGSPEC=
sstate-${PN}-${PACKAGE_ARCH}${TARGET_VENDOR}-${TARGET_OS}-${PV}-${PR}-${SSTATE_PKGARCH}-${SSTATE_VERSION}-
SSTATE_PKGNAME= ${SSTATE_PKGSPEC}${BB_TASKHASH}
SSTATE_PKG= ${SSTATE_DIR}/${SSTATE_PKGNAME}
diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index c05d736..4e89500 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -99,9 +99,8 @@ PACKAGE_ARCHS = all any noarch ${PACKAGE_EXTRA_ARCHS}
${MACHINE_ARCH}
# since machine specific packages are handled using multimachine
PACKAGE_ARCHS[vardepsexclude] = MACHINE_ARCH
-MULTIMACH_ARCH = ${PACKAGE_ARCH}
-MULTIMACH_TARGET_SYS = ${MULTIMACH_ARCH}${TARGET_VENDOR}-${TARGET_OS}
-MULTIMACH_HOST_SYS = ${MULTIMACH_ARCH}${HOST_VENDOR}-${HOST_OS}
+MULTIMACH_TARGET_SYS
[OE-core] [PATCH 4/4] base/glib-2.0: Simplify USE_NLS handling for glib-2.0
Currently the only way to get anything to build is to set USE_NLS=yes
for glib-2.0. We might as well do this in the recipe by default for
now and simpllify the code.
The magic handling of USE_NLS_recipename is also removed since this
can be done in the form USE_NLS_pn-recipename using overrides these
days.
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
---
meta/classes/base.bbclass |4
meta/conf/distro/include/tclibc-uclibc.inc |1 -
meta/recipes-core/glib-2.0/glib-2.0.inc|6 --
meta/recipes-core/glib-2.0/glib.inc|3 +--
4 files changed, 1 insertions(+), 13 deletions(-)
delete mode 100644 meta/recipes-core/glib-2.0/glib-2.0.inc
diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index 0bea639..575352d 100644
--- a/meta/classes/base.bbclass
+++ b/meta/classes/base.bbclass
@@ -303,10 +303,6 @@ python () {
bb.note(SKIPPING %s because it's %s % (pn, this_license))
raise bb.parse.SkipPackage(incompatible with license %s
% this_license)
-use_nls = bb.data.getVar('USE_NLS_%s' % pn, d, 1)
-if use_nls != None:
-bb.data.setVar('USE_NLS', use_nls, d)
-
# Git packages should DEPEND on git-native
srcuri = bb.data.getVar('SRC_URI', d, 1)
if git:// in srcuri:
diff --git a/meta/conf/distro/include/tclibc-uclibc.inc
b/meta/conf/distro/include/tclibc-uclibc.inc
index 83418d6..65693a9 100644
--- a/meta/conf/distro/include/tclibc-uclibc.inc
+++ b/meta/conf/distro/include/tclibc-uclibc.inc
@@ -14,7 +14,6 @@ PREFERRED_PROVIDER_virtual/libiconv ?= libiconv
PREFERRED_PROVIDER_virtual/libintl ?= gettext
USE_NLS ?= no
-USE_NLS_glib-2.0 = yes
CXXFLAGS += -fvisibility-inlines-hidden
diff --git a/meta/recipes-core/glib-2.0/glib-2.0.inc
b/meta/recipes-core/glib-2.0/glib-2.0.inc
deleted file mode 100644
index ccbbd2b..000
--- a/meta/recipes-core/glib-2.0/glib-2.0.inc
+++ /dev/null
@@ -1,6 +0,0 @@
-
-python () {
-import bb
-if bb.data.getVar(USE_NLS, d, 1) == no:
-raise bb.parse.SkipPackage(${PN} requires native language support.)
-}
diff --git a/meta/recipes-core/glib-2.0/glib.inc
b/meta/recipes-core/glib-2.0/glib.inc
index 0800c85..e25db3d 100644
--- a/meta/recipes-core/glib-2.0/glib.inc
+++ b/meta/recipes-core/glib-2.0/glib.inc
@@ -13,8 +13,6 @@ LIC_FILES_CHKSUM =
file://COPYING;md5=3bf50002aefd002f49e7bb854063f7e7 \
BUGTRACKER = http://bugzilla.gnome.org;
SECTION = libs
-require glib-2.0.inc
-
DEPENDS = glib-2.0-native gtk-doc-native zip dbus
DEPENDS_virtclass-native = gtk-doc-native pkgconfig-native gettext-native
dbus-native
DEPENDS_virtclass-nativesdk = libtool-nativesdk
@@ -36,3 +34,4 @@ FILES_${PN}-dev += ${libdir}/glib-2.0/include
FILES_${PN}-dbg += ${datadir}/glib-2.0/gdb ${datadir}/gdb
ARM_INSTRUCTION_SET = arm
+USE_NLS = yes
--
1.7.4.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/4] base.bbclass: Drop old style SRCDATE handling, we have pn- overrides now
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
---
meta/classes/base.bbclass |5 -
1 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index 119b052..4681489 100644
--- a/meta/classes/base.bbclass
+++ b/meta/classes/base.bbclass
@@ -303,11 +303,6 @@ python () {
bb.note(SKIPPING %s because it's %s % (pn, this_license))
raise bb.parse.SkipPackage(incompatible with license %s
% this_license)
-# OBSOLETE in bitbake 1.7.4
-srcdate = bb.data.getVar('SRCDATE_%s' % pn, d, 1)
-if srcdate != None:
-bb.data.setVar('SRCDATE', srcdate, d)
-
use_nls = bb.data.getVar('USE_NLS_%s' % pn, d, 1)
if use_nls != None:
bb.data.setVar('USE_NLS', use_nls, d)
--
1.7.4.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/4] base.bbclass: Since we require python 2.6 which always contains hashlib we can drop this fallback code
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
---
meta/classes/base.bbclass | 10 --
1 files changed, 0 insertions(+), 10 deletions(-)
diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index 4681489..f390f08 100644
--- a/meta/classes/base.bbclass
+++ b/meta/classes/base.bbclass
@@ -326,16 +326,6 @@ python () {
depends = depends + osc-native:do_populate_sysroot
bb.data.setVarFlag('do_fetch', 'depends', depends, d)
-# bb.utils.sha256_file() will fail if hashlib isn't present, so we fallback
-# on shasum-native. We need to ensure that it is staged before we fetch.
-if bb.data.getVar('PN', d, True) != shasum-native:
-try:
-import hashlib
-except ImportError:
-depends = bb.data.getVarFlag('do_fetch', 'depends', d) or
-depends = depends + shasum-native:do_populate_sysroot
-bb.data.setVarFlag('do_fetch', 'depends', depends, d)
-
# *.xz should depends on xz-native for unpacking
# Not endswith because of *.patch.xz;patch=1. Need bb.decodeurl in future
if '.xz' in srcuri:
--
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] [PATCH 1/1] libc-package.bbclass: Replace hard coded libdir.
On Thu, 2011-06-23 at 19:33 +0800, Lianhao Lu wrote:
Replace the hard coded libdir for locale generating to meet the multilib
requirement.
Signed-off-by: Lianhao Lu lianhao...@intel.com
---
meta/classes/libc-package.bbclass |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/meta/classes/libc-package.bbclass
b/meta/classes/libc-package.bbclass
index 55e3d48..84bac5d 100644
--- a/meta/classes/libc-package.bbclass
+++ b/meta/classes/libc-package.bbclass
@@ -277,10 +277,11 @@ python package_do_split_gconvs () {
def output_locale_binary(name, pkgname, locale, encoding):
treedir = base_path_join(bb.data.getVar(WORKDIR, d, 1),
locale-tree)
- ldlibdir = %s/lib % treedir
+ ldlibdir = base_path_join(treedir,libdir)
I think this should be base_libdir, not libdir.
path = bb.data.getVar(PATH, d, 1)
i18npath = base_path_join(treedir, datadir, i18n)
gconvpath = base_path_join(treedir, iconvdata)
+ outputpath = base_path_join(treedir, libdir, locale)
use_cross_localedef =
bb.data.getVar(LOCALE_GENERATION_WITH_CROSS-LOCALEDEF, d, 1) or 0
if use_cross_localedef == 1:
@@ -300,8 +301,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 \
+ % (treedir, treedir, datadir, locale, encoding,
outputpath, name)
cmd = PATH=\%s\ I18NPATH=\%s\ GCONV_PATH=\%s\
cross-localedef %s % \
(path, i18npath, gconvpath, localedef_opts)
But otherwise this looks like a sensible change to me!
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] Use new git server for clutter, V2
On Thu, 2011-06-23 at 20:33 +0800, edwin.z...@intel.com wrote: From: Zhai Edwin edwin.z...@intel.com This patch use new git server for clutter. Pls. pull. The following changes since commit b914de55a45029658116f729ffda3abead654c90: Revert eglibc: Upgrade recipes from 2.13 - 2.14 (2011-06-22 23:49:42 +0100) are available in the git repository at: git://git.pokylinux.org/poky-contrib gzhai/master http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=gzhai/master Zhai Edwin (1): clutter: Use new git repo 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] kernel.bbclass: Stage System.map with KERNEL_VERSION suffix
On Wed, 2011-06-22 at 16:48 -0700, Tom Rini wrote: Without this, images will fail now that kernel-abiversion is back. Signed-off-by: Tom Rini tom_r...@mentor.com --- meta/classes/kernel.bbclass |1 + 1 files changed, 1 insertions(+), 0 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 0/4] eglibc 2.14 upgrade
On Wed, 2011-06-22 at 16:22 -0700, Khem Raj wrote: On Wed, Jun 22, 2011 at 3:59 PM, Richard Purdie richard.pur...@linuxfoundation.org wrote: On Wed, 2011-06-22 at 15:31 -0700, Khem Raj wrote: On Wed, Jun 22, 2011 at 1:28 PM, Mark Hatle mark.ha...@windriver.com wrote: On 6/22/11 1:35 PM, Mark Hatle wrote: Since applying this update, I'm not longer getting an rpc/rpc.h file, which breaks various things like busybox mount. Is anyone else seeing this behavior? Reverting: 2a68cf4d315cdd18766de0c75928ff17846a6cd7 and 190a946e9a4213944e3ee675c4b3e18701698e87 fixed the problem for me. So there is definitely a problems in the upgrade. onward looking rpc is now maintained with libtirpc starting glibc 2.14 rpc is not to be used from bundled code in glibc. If we dont have recipes for libtirpc then I will add that. There looks to be more than this wrong with this update. A quick comparison shows the following changes in the list of files being installed from do_install: -./lib/libmemusage.so -./lib/libnss_hesiod-2.13.so -./lib/libnss_nisplus-2.13.so -./lib/libutil-2.13.so -./lib/libresolv-2.13.so -./lib/libm-2.13.so -./lib/libnsl-2.13.so -./lib/libnss_compat-2.13.so -./lib/libnss_nis-2.13.so -./lib/libnss_dns-2.13.so -./lib/libanl-2.13.so -./lib/libBrokenLocale-2.13.so -./lib/libcrypt-2.13.so -./etc/rpc -./usr/lib/libnss_compat_pic.a -./usr/lib/libnss_dns_pic.a -./usr/lib/libnss_nisplus_pic.a +./usr/lib/audit/sotruss-lib.so -./usr/lib/libutil_pic.map -./usr/lib/libBrokenLocale_pic.a -./usr/lib/libBrokenLocale.a -./usr/lib/libBrokenLocale_pic.map -./usr/lib/libm.a -./usr/lib/libnss_dns_pic.map -./usr/lib/libm_pic.map -./usr/lib/libnss_hesiod_pic.map -./usr/lib/librpcsvc.a -./usr/lib/libutil.a -./usr/lib/libnss_compat_pic.map -./usr/lib/libcrypt.a -./usr/lib/libutil_pic.a -./usr/lib/libanl.a -./usr/lib/libnsl_pic.a -./usr/lib/libresolv.a -./usr/lib/libnss_hesiod_pic.a -./usr/lib/libm_pic.a -./usr/lib/libnsl_pic.map -./usr/lib/libnss_nis_pic.map -./usr/lib/libanl_pic.a -./usr/lib/libcrypt_pic.map -./usr/lib/libcrypt_pic.a -./usr/lib/libnss_nis_pic.a -./usr/lib/libresolv_pic.map -./usr/lib/libresolv_pic.a -./usr/lib/libanl_pic.map -./usr/lib/libnss_nisplus_pic.map -./usr/lib/libnsl.a -./usr/bin/rpcgen -./usr/bin/gencat +./usr/bin/sotruss -./usr/bin/localedef -./usr/bin/locale -./usr/sbin/rpcinfo -./usr/sbin/nscd Some of these are rpc related but there are other issues too. I've reverted the upgrade itself for now until we have something in place to address the issues and its actually had some testing... some of these are due to rpc and others are due to nss being removed I need to backport the nss db re-implementation then most of it should be resolved I guess I will post 2.14 as additional recipes rather than replacement for 2.13 that way we will get some soak time. FWIW, some of the above list was due to local build corruption as I had some weirdness going on with DISTRO_FEATURES locally. That variable now influences the libc quite a lot and might also be catching others out which is why I mention it. Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] sstate skips STAGING_DIR_KERNEL?
On Wed, 2011-06-22 at 17:20 -0700, Tom Rini wrote:
As part of looking into the problem I had that I just posted a patch for
I was going why isn't -c clean (or cleanall or cleansstate) knocking
out STAGING_DIR_KERNEL contents? Answer, sstate is totally skipping
that out. Is there some variable we need to be setting somewhere to add
this in? Or are we going to have to take in the various bits of OE.dev
kernel.bbclass instead here?
I think there is a bug in kernel.bbclass. This should fix it:
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index aaf341b..9f09107 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -119,7 +119,7 @@ kernel_do_install() {
# Support for external module building - create a minimal copy of the
# kernel source tree.
#
- kerneldir=${STAGING_KERNEL_DIR}
+ kerneldir=${D}/kernel
install -d $kerneldir
#
I'll merge something like this is nobody objects.
Cheers,
Richard
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
