Re: [OE-core] Tell me your build error message annoyances!
On 05/31/2011 03:26 PM, Scott Garman wrote: Hey folks, 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. I'm starting to track some of these situations with the following bugs: http://bugzilla.pokylinux.org/show_bug.cgi?id=542 http://bugzilla.pokylinux.org/show_bug.cgi?id=1127 http://bugzilla.pokylinux.org/show_bug.cgi?id=1128 I can't promise to fix everything you come up with, but I'd like to try to make a dent in some of these issues and improve the usability of our build system. Thanks, Scott 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). o I'm seeing duplicate messages lately - no examples handy, I'll post or open a bug next time. 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). 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. 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. 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. Thanks for collecting these Scott, great idea! -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-core][PATCH 1/1] create-pull-request: allow '+' in git PROTO_RE, ie for 'git+ssh://'
On Thu, Jun 02, 2011 at 10:38:11PM -0700, Darren Hart wrote: Hi Martin, Hi Darren, No objection if this is a valid URL. I didn't include this because 1) I didn't know about it and 2) it isn't listed in the git pull man page, which is what I developed to. Is git+ssh... equivalent to ssh:// ? before this change my pull requests had url like this are available in the git repository at: git+ssh://g...@git.openembedded.org/meta-openembedded-contrib jansa/meta-oe http://cgit.openembedded.org/cgit.cgi/git+ssh://g...@git.openembedded.org/meta-openembedded-contrib/log/?h=jansa/meta-oe because RE wasn't matching my URL at all OE @ ~/shr-core/openembedded-core $ git config remote.contrib.url git+ssh://g...@git.openembedded.org/openembedded-core-contrib IMHO this is equivalent to ssh:// or git@ without protocol but haven't checked documentation to be sure. But I'm sure this is valid and that this works right (as I'm able to push to contrib). As a minor nit, please include a body message for anything more complicated than whitespace or typographical fixes. I use git+ssh:// for many projects so I'm used to it, so I expected that this is widely used and this patch would be clear enough. Regards, -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com pgpQgfjL64w98.pgp Description: PGP signature ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] eglibc: migrate configurability from oe
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
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 features_to_eglibc_settings(d):
+cnf = ([])
+distro_features = (bb.data.getVar('DISTRO_FEATURES_EGLIBC', d, True)
or '').split()
+eglibc_cfg('ipv6', distro_features,
'OPTION_EGLIBC_ADVANCED_INET6', cnf)
+eglibc_cfg('backtrace', distro_features,
'OPTION_EGLIBC_BACKTRACE', cnf)
+eglibc_cfg('big-macros', distro_features,
'OPTION_EGLIBC_BIG_MACROS', cnf)
+eglibc_cfg('bsd', distro_features, 'OPTION_EGLIBC_BSD', cnf)
+eglibc_cfg('cxx-tests', distro_features,
'OPTION_EGLIBC_CXX_TESTS', cnf)
+eglibc_cfg('catgets', distro_features, 'OPTION_EGLIBC_CATGETS',
cnf)
+eglibc_cfg('charsets', distro_features, 'OPTION_EGLIBC_CHARSETS',
cnf)
+eglibc_cfg('crypt', distro_features, 'OPTION_EGLIBC_CRYPT', cnf)
+eglibc_cfg('crypt-ufc', distro_features,
'OPTION_EGLIBC_CRYPT_UFC', cnf)
+eglibc_cfg('db-aliases', distro_features,
'OPTION_EGLIBC_DB_ALIASES',
[OE-core] [PATCH 0/1] eglibc: enable eglibc configurability V2
From: Kang Kai kai.k...@windriver.com Hi Saul, I update the patch that move DISTRO_FEATURES_EGLIBC ??= to eglibc.inc 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 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.git kangkai/distro http://git.pokylinux.org/cgit.cgi//log/?h=kangkai/distro Kang Kai (1): eglibc: migrate configurability from oe 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 -- 1.7.5.1.300.gc565c ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-core][PATCH 1/1] create-pull-request: allow '+' in git PROTO_RE, ie for 'git+ssh://'
On 06/02/2011 11:03 PM, Martin Jansa wrote: On Thu, Jun 02, 2011 at 10:38:11PM -0700, Darren Hart wrote: Hi Martin, Hi Darren, No objection if this is a valid URL. I didn't include this because 1) I didn't know about it and 2) it isn't listed in the git pull man page, which is what I developed to. Is git+ssh... equivalent to ssh:// ? before this change my pull requests had url like this are available in the git repository at: git+ssh://g...@git.openembedded.org/meta-openembedded-contrib jansa/meta-oe http://cgit.openembedded.org/cgit.cgi/git+ssh://g...@git.openembedded.org/meta-openembedded-contrib/log/?h=jansa/meta-oe because RE wasn't matching my URL at all OE @ ~/shr-core/openembedded-core $ git config remote.contrib.url git+ssh://g...@git.openembedded.org/openembedded-core-contrib IMHO this is equivalent to ssh:// or git@ without protocol but haven't checked documentation to be sure. But I'm sure this is valid and that this works right (as I'm able to push to contrib). I'm sure the patch is fine - I was just surprised git pull didn't document the URL. It's already been pulled as well I believe. As a minor nit, please include a body message for anything more complicated than whitespace or typographical fixes. I use git+ssh:// for many projects so I'm used to it, so I expected that this is widely used and this patch would be clear enough. As I said, it's a nit, but it is consistent with guidelines used in many other projects. Cramming too much into the subject line makes the git log hard to read - especially as git doesn't wrap long lines - perhaps due to the prejudices of the authors ;-) Yours doesn't truncate, but it comes close. Anyway, dead horse and all that. Thanks for the fix. -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/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/1] eglibc: migrate configurability from oe
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?
In that case, DISTRO_FEATURES_EGLIBC is not needed, right?
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.
Ok, I will use one flag only.
Cheers,
Richard
Thanks Regards,
Kai
Signed-off-by: Kang Kaikai.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 Kaikai.k...@windriver.com
+
+Upstream-Status: Submitted
+
+Signed-off-by: Kang Kaikai.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 =
Re: [OE-core] [PATCH 1/3] busybox: enable mdev by default
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. regards, Koen ___ 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 09:22 +0100, Richard Purdie wrote: 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 I'm not sure I agree with that. Some, maybe most, of these flags are not really specific to eglibc (in concept, even if eglibc is the only package which respects them at the moment). Some of them (eg ipv6) are already established DISTRO_FEATURES which are used in various other places; others, including perhaps your spawn example, are specifically bound to the contents of the C library but could equally well be respected by uclibc. So, for the latter group, I think just libc-spawn would be better than eglibc-spawn. Maybe libc-has-spawn would be even better, to make it clear that we're talking about a feature within libc and not a specific variant of libc. In an ideal world there would also be a mechanism for packages to declare that they require a particular feature from libc, i.e. a recipe could say DISTRO_REQUIRED_FEATURES = libc-spawn and it would then be a configuration error to try to build that recipe for a distro that doesn't admit the necessary things. 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. Agreed. 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. I didn't fully understand the commentary around PACKAGE_NO_GCONV so I'm not sure that I have a meaningful opinion on that one yet. As far as I know, though, there is no generic packaging code for gconvs (unlike locales, which are handled generically in package.bbclass) but, again, the concept of gconvs is not eglibc specific and there are other libs which might provide them. p. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/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
[OE-core] cross posting
The p...@yoctoproject.org list is set as member posting only, which means that folks who aren't subscribed to that list get an UDN if they hit reply all on a message which was crossposted between poky and the openembedded-core list. As well as the direct annoyance of the bounce message, this means that folks reading the discussion on poky@ will only be seeing a subset of the messages. So, if possible, please avoid crossposting between the two lists. If you do need to write to both for some reason, please set Reply-to: so that replies go to only one place. thanks p. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] problem using SDK built by meta-toolchain-qte: missing native libraries
I'm having problems using the SDK built by meta-toolchain-qte. One or more native libraries seem to be missing from the SDK install. My host is x86_64, building for i586 target. The native libdbus-1.so isn't being installed by the SDK. It is being built though. I can workaround the problem by manually copying libdbus-1.so from the meta-toolchain-qte build into the SDK install tree. Is qt4-tools-nativesdk missing code to install this lib (and possibly others)? Is this a known problem? -james ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] sqlite: remove dependency on tcl-native
Older versions of sqlite required tclsh at compile time but this is no longer the case with recent 3.7.x. See http://lists.linuxtogo.org/pipermail/openembedded-core/2011-June/003653.html Signed-off-by: Phil Blundell ph...@gnu.org --- meta/recipes-support/sqlite/sqlite3.inc |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/meta/recipes-support/sqlite/sqlite3.inc b/meta/recipes-support/sqlite/sqlite3.inc index d8ef8dc..939df14 100644 --- a/meta/recipes-support/sqlite/sqlite3.inc +++ b/meta/recipes-support/sqlite/sqlite3.inc @@ -2,8 +2,8 @@ DESCRIPTION = An Embeddable SQL Database Engine HOMEPAGE = http://www.sqlite.org; SECTION = libs PRIORITY = optional -DEPENDS = readline ncurses tcl-native -DEPENDS_virtclass-native = tcl-native +DEPENDS = readline ncurses +DEPENDS_virtclass-native = LICENSE = PD inherit autotools pkgconfig -- 1.7.2.5 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] HEADS UP: sys_accept4() syscall and recent udevs
Hi, Last night I tried to help Tom R. debug boot failures and it turned out that he was missing the sys_accept4() syscall. This morning I helped a coworker with the same problem. So let's summarize the situation: 1) recent udevs (165) depend on the accept4() syscall 2) kernel 2.6.28 added that syscall, but didn't wire it up for all archs 3) kernel 2.6.36 wired it up for ARM So to get a working recent udev on ARM you need to do the following: a) use = 2.6.36 as linux libc headers or cherry-pick this one: 21d93e2e29722d7832f61cc56d73fb953ee6578e ARM: 6329/1: wire up sys_accept4() on ARM b) cherry-pick the above into your kernel, cherry-pick works cleanly for at least the 2.6.32 and 2.6.35 kernels I tried it on And if you want to use systemd: c) cherry-pick 676db4af043014e852f67ba0349dae0071bd11f3 cgroupfs: create /sys/fs/cgroup to mount cgroupfs If you're using a prebuilt toolchain, contact your toolchain vender to get a headerset and c library with that syscall and optionally things like signalfd(). OE-core users only need to check b) if they are using their own 2.6.36 kernels. regards, Koen ___ 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
Op 3 jun 2011, om 11:50 heeft Richard Purdie het volgende geschreven: 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? I was going to write a lengthy response, but Phil summed it up way too well in http://lists.linuxtogo.org/pipermail/openembedded-core/2011-June/003702.html :) ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/2] allarch.bbclass: Define BASE_PACKAGE_ARCH = all
On Thu, 2011-06-02 at 12:45 -0700, Khem Raj wrote:
+BASE_PACKAGE_ARCH = all
PACKAGE_ARCH = all
Is it necessary to define both of those? bitbake.conf does:
PACKAGE_ARCH = ${BASE_PACKAGE_ARCH}
so it seems like, if setting B_P_A is the right thing to do, there
should be no need to set PACKAGE_ARCH as well.
I don't understand the semantics of those two variables well enough to
say whether setting BASE_PACKAGE_ARCH here is actually the right thing
or not. Is there any documentation anywhere which describes what
exactly the relation is meant to be between B_P_A and P_A, and when it's
appropriate to set each of them?
p.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] gcc-package-cross: also install the symlinks in libexec with target prefix
... since this is where collect2 seems to look for them. This seems like
it is really a bug in collect2, but installing the symlinks is an easy
workaround. Without this you get could not find ld errors when using -flto.
Signed-off-by: Phil Blundell ph...@gnu.org
---
meta/recipes-devtools/gcc/gcc-package-cross.inc |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/meta/recipes-devtools/gcc/gcc-package-cross.inc
b/meta/recipes-devtools/gcc/gcc-package-cross.inc
index 04c8101..b51336b 100644
--- a/meta/recipes-devtools/gcc/gcc-package-cross.inc
+++ b/meta/recipes-devtools/gcc/gcc-package-cross.inc
@@ -20,6 +20,7 @@ do_install () {
install -d $dest
for t in ar as ld nm objcopy objdump ranlib strip g77 gcc cpp gfortran;
do
ln -sf ${BINRELPATH}/${TARGET_PREFIX}$t $dest$t
+ ln -sf ${BINRELPATH}/${TARGET_PREFIX}$t
${dest}${TARGET_PREFIX}$t
done
# Remove things we don't need but keep share/java
--
1.7.2.5
___
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 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. p. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/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
[OE-core] [PATCH] uclibc: remove PACKAGE_ARCH, fix compilation on i586
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
---
.../uclibc/uclibc-git/epoll-asm-fix.patch | 20
meta/recipes-core/uclibc/uclibc.inc| 12 +---
meta/recipes-core/uclibc/uclibc_git.bb |5 ++---
3 files changed, 23 insertions(+), 14 deletions(-)
create mode 100644 meta/recipes-core/uclibc/uclibc-git/epoll-asm-fix.patch
diff --git a/meta/recipes-core/uclibc/uclibc-git/epoll-asm-fix.patch
b/meta/recipes-core/uclibc/uclibc-git/epoll-asm-fix.patch
new file mode 100644
index 000..6129081
--- /dev/null
+++ b/meta/recipes-core/uclibc/uclibc-git/epoll-asm-fix.patch
@@ -0,0 +1,20 @@
+diff --git a/libc/sysdeps/linux/common/epoll.c
b/libc/sysdeps/linux/common/epoll.c
+index 85b0cfd..c034b2c 100644
+--- a/libc/sysdeps/linux/common/epoll.c
b/libc/sysdeps/linux/common/epoll.c
+@@ -67,12 +67,13 @@ extern __typeof(epoll_pwait) __libc_epoll_pwait;
+ int __libc_epoll_pwait(int epfd, struct epoll_event *events, int maxevents,
+ int timeout, const sigset_t
*set)
+ {
++ int nsig = _NSIG / 8;
+ if (SINGLE_THREAD_P)
+- return INLINE_SYSCALL(epoll_pwait, 6, epfd, events, maxevents,
timeout, set, _NSIG / 8);
++ return INLINE_SYSCALL(epoll_pwait, 6, epfd, events, maxevents,
timeout, set, nsig);
+ # ifdef __UCLIBC_HAS_THREADS_NATIVE__
+ else {
+ int oldtype = LIBC_CANCEL_ASYNC ();
+- int result = INLINE_SYSCALL(epoll_pwait, 6, epfd, events,
maxevents, timeout, set, _NSIG / 8);
++ int result = INLINE_SYSCALL(epoll_pwait, 6, epfd, events,
maxevents, timeout, set, nsig);
+ LIBC_CANCEL_RESET (oldtype);
+ return result;
+ }
diff --git a/meta/recipes-core/uclibc/uclibc.inc
b/meta/recipes-core/uclibc/uclibc.inc
index c1bc422..a2c6ee5 100644
--- a/meta/recipes-core/uclibc/uclibc.inc
+++ b/meta/recipes-core/uclibc/uclibc.inc
@@ -36,21 +36,11 @@ cp ${SYSROOT_DESTDIR}${libdir}/libc.so
${WORKDIR}/site_config_libc; \
sed -i -e 's# ${base_libdir}# ${SYSROOT_DESTDIR}${base_libdir}#g' -e 's#
${libdir}# ${SYSROOT_DESTDIR}${libdir}#g' ${WORKDIR}/site_config_libc/libc.so; \
-#
# For now, we will skip building of a gcc package if it is a uclibc one
# and our build is not a uclibc one, and we skip a glibc one if our build
# is a uclibc build.
-#
-# See the note in gcc/gcc_3.4.0.oe
-#
+COMPATIBLE_HOST = .*-uclibc.*
-python __anonymous () {
-import bb, re
-uc_os = (re.match('.*uclibc*', bb.data.getVar('TARGET_OS', d, 1)) != None)
-if not uc_os:
-raise bb.parse.SkipPackage(incompatible with target %s %
- bb.data.getVar('TARGET_OS', d, 1))
-}
PROVIDES += virtual/libc virtual/${TARGET_PREFIX}libc-for-gcc
DEPENDS = virtual/${TARGET_PREFIX}binutils \
virtual/${TARGET_PREFIX}gcc-intermediate \
diff --git a/meta/recipes-core/uclibc/uclibc_git.bb
b/meta/recipes-core/uclibc/uclibc_git.bb
index eded2fb..33c6ec8 100644
--- a/meta/recipes-core/uclibc/uclibc_git.bb
+++ b/meta/recipes-core/uclibc/uclibc_git.bb
@@ -2,11 +2,9 @@ SRCREV=71d63ed75648da9b0b71afabb9c60aaad792c55c
require uclibc.inc
PV = 0.9.31+0.9.32rc3
-PR = ${INC_PR}.2
+PR = ${INC_PR}.3
PROVIDES += virtual/${TARGET_PREFIX}libc-for-gcc
-#recent versions uclibc require real kernel headers
-PACKAGE_ARCH = ${MACHINE_ARCH}
FILESPATH = ${@base_set_filespath([ '${FILE_DIRNAME}/uclibc-git' ], d)}
SRC_URI = git://uclibc.org/uClibc.git;branch=master;protocol=git \
@@ -29,5 +27,6 @@ SRC_URI =
git://uclibc.org/uClibc.git;branch=master;protocol=git \
file://remove_attribute_optimize_Os.patch \
file://append_UCLIBC_EXTRA_CFLAGS.patch \
file://compile-arm-fork-with-O2.patch \
+ file://epoll-asm-fix.patch \
S = ${WORKDIR}/git
--
1.7.2.5
___
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:50 +0100, Richard Purdie wrote: That was my point in the earlier email :) Ah right, yes. Evidently I hadn't had enough of my coffee when I replied to that one. :-} p. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/4] xf86-driver-common.inc: remove .la files to avoid unpackaged warning
On Fri, Jun 3, 2011 at 00:52, Saul Wold s...@linux.intel.com wrote: Would it not be better to package them in the -dev package instead of throwing them away? They are not packaged by I remove them to avoid the unshiped warning. -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/4] xf86-driver-common.inc: remove .la files to avoid unpackaged warning
On Thu, 2011-06-02 at 17:52 -0700, Saul Wold wrote:
On 06/02/2011 12:25 PM, Otavio Salvador wrote:
+do_install_append () {
+# driver's la files are not packaged
+rm -f ${D}${libdir}/xorg/modules/drivers/*.la
+}
Would it not be better to package them in the -dev package instead of
throwing them away?
Not really. The .la files for the drivers aren't good for anything: you
aren't ever going to link against them.
p.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] sqlite: remove dependency on tcl-native
On 06/03/2011 03:40 AM, Phil Blundell wrote: Older versions of sqlite required tclsh at compile time but this is no longer the case with recent 3.7.x. See http://lists.linuxtogo.org/pipermail/openembedded-core/2011-June/003653.html Signed-off-by: Phil Blundell ph...@gnu.org Acked-by: Tom Rini tom_r...@mentor.com --- meta/recipes-support/sqlite/sqlite3.inc |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/meta/recipes-support/sqlite/sqlite3.inc b/meta/recipes-support/sqlite/sqlite3.inc index d8ef8dc..939df14 100644 --- a/meta/recipes-support/sqlite/sqlite3.inc +++ b/meta/recipes-support/sqlite/sqlite3.inc @@ -2,8 +2,8 @@ DESCRIPTION = An Embeddable SQL Database Engine HOMEPAGE = http://www.sqlite.org; SECTION = libs PRIORITY = optional -DEPENDS = readline ncurses tcl-native -DEPENDS_virtclass-native = tcl-native +DEPENDS = readline ncurses +DEPENDS_virtclass-native = LICENSE = PD inherit autotools pkgconfig -- Tom Rini Mentor Graphics Corporation ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Tell me your build error message annoyances!
On 6/3/11 1:10 AM, Darren Hart wrote: On 05/31/2011 03:26 PM, Scott Garman wrote: ... 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 have heard similar comments from others as well. 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. Upon failure we stop updating the UI and print something like: Even if it did scroll, somehow limiting the messages being printed would be beneficial. It's been suggested to me simply one (or two) messages per step MAX. Running linux-yocto do_compile Running matchbox do_fetch ... I believe currently we have around 3-5 messages per step, and it's still too noisy -- unless you need to debug something. 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. Thanks for collecting these Scott, great idea! ___ 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, Jun 01, 2011 at 05:25:58PM +0100, Richard Purdie wrote: 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. Well perhaps it would be easier to build a list of packages that have been skipped? I think the cache knows about them. Perhaps they could be reported to a skipped file or something similar? --mark ___ 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 Friday 03 June 2011 15:35:45 mark gross wrote: Well perhaps it would be easier to build a list of packages that have been skipped? I think the cache knows about them. Perhaps they could be reported to a skipped file or something similar? FYI there is a patch I submitted the other day to bitbake-devel which tracks these in their own internal list. The next step is that when a NoProvider event comes up we can look through this list to see if the requested target is in there, and if so report that it was skipped along with the reason why. I would think that this obviates the need to show the list of skipped packages at the start, although we could easily allow them to be reported via some other mechanism. This is a separate exercise to sorting out the flow of exceptions within bitbake, but still very important for the overall task of improving error output. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Tell me your build error message annoyances!
Op 1 jun 2011, om 00:26 heeft Scott Garman het volgende geschreven: Hey folks, 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. I'm starting to track some of these situations with the following bugs: http://bugzilla.pokylinux.org/show_bug.cgi?id=542 http://bugzilla.pokylinux.org/show_bug.cgi?id=1127 http://bugzilla.pokylinux.org/show_bug.cgi?id=1128 I can't promise to fix everything you come up with, but I'd like to try to make a dent in some of these issues and improve the usability of our build system. This one popped up recently, -b doesn't work anymore: koen@dominion:/OE/tentacle/sources/meta-texasinstruments/recipes-kernel/linux$ ls | grep omap4 linux-omap4/ linux-omap4_2.6.35.3.bb linux-omap4-2.6.35.7/ linux-omap4_2.6.35.7.bb koen@dominion:/OE/tentacle/sources/meta-texasinstruments/recipes-kernel/linux$ MACHINE=omap4430-panda bitbake -b $PWD/linux-omap4_2.6.35.7.bb ERROR: Command execution failed: Traceback (most recent call last): File /OE/tentacle/sources/bitbake/lib/bb/command.py, line 102, in runAsyncCommand commandmethod(self.cmds_async, self, options) File /OE/tentacle/sources/bitbake/lib/bb/command.py, line 190, in buildFile command.cooker.buildFile(bfile, task) File /OE/tentacle/sources/bitbake/lib/bb/cooker.py, line 722, in buildFile fn = self.matchFile(fn) File /OE/tentacle/sources/bitbake/lib/bb/cooker.py, line 700, in matchFile matches = self.matchFiles(buildfile) File /OE/tentacle/sources/bitbake/lib/bb/cooker.py, line 683, in matchFiles filelist, masked = self.collect_bbfiles() File /OE/tentacle/sources/bitbake/lib/bb/cooker.py, line 948, in collect_bbfiles files.sort( key=lambda fileitem: self.calc_bbfile_priority(fileitem) ) File /OE/tentacle/sources/bitbake/lib/bb/cooker.py, line 948, in lambda files.sort( key=lambda fileitem: self.calc_bbfile_priority(fileitem) ) File /OE/tentacle/sources/bitbake/lib/bb/cooker.py, line 411, in calc_bbfile_priority for _, _, regex, pri in self.status.bbfile_config_priorities: AttributeError: 'NoneType' object has no attribute 'bbfile_config_priorities' 'bitbake linux-omap4-2.6.35.7' does work, though ___ 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 Fri, 2011-06-03 at 09:22 -0500, Mark Hatle wrote: I believe currently we have around 3-5 messages per step, and it's still too noisy -- unless you need to debug something. Correct. Right now, the output looks like: NOTE: Running task 613 of 728 (ID: 190, virtual:native:/home/pb/oe/oe-core/meta/recipes-core/util-linux/util-linux_2.19.1.bb, do_install) NOTE: package util-linux-native-2.19.1-r0: task do_install: Started NOTE: package util-linux-native-2.19.1-r0: task do_install: Succeeded NOTE: Running task 614 of 728 (ID: 191, virtual:native:/home/pb/oe/oe-core/meta/recipes-core/util-linux/util-linux_2.19.1.bb, do_populate_sysroot) NOTE: package util-linux-native-2.19.1-r0: task do_populate_sysroot: Started NOTE: package util-linux-native-2.19.1-r0: task do_populate_sysroot: Succeeded It looks as though the Started and Succeeded lines could just be deleted without losing any real information. p. ___ 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 Fri, Jun 3, 2011 at 8:43 AM, Phil Blundell p...@pbcl.net wrote: On Fri, 2011-06-03 at 09:22 -0500, Mark Hatle wrote: I believe currently we have around 3-5 messages per step, and it's still too noisy -- unless you need to debug something. Correct. Right now, the output looks like: NOTE: Running task 613 of 728 (ID: 190, virtual:native:/home/pb/oe/oe-core/meta/recipes-core/util-linux/util-linux_2.19.1.bb, do_install) NOTE: package util-linux-native-2.19.1-r0: task do_install: Started NOTE: package util-linux-native-2.19.1-r0: task do_install: Succeeded NOTE: Running task 614 of 728 (ID: 191, virtual:native:/home/pb/oe/oe-core/meta/recipes-core/util-linux/util-linux_2.19.1.bb, do_populate_sysroot) NOTE: package util-linux-native-2.19.1-r0: task do_populate_sysroot: Started NOTE: package util-linux-native-2.19.1-r0: task do_populate_sysroot: Succeeded It looks as though the Started and Succeeded lines could just be deleted without losing any real information. 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. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] linux-yocto: update target/meta SRCREVs
This SRCREV update picks up the following changes from the
2.6.37 kernel tree:
- fishriver: create and use a dedicated BSP branch
- fishriver: usbnet fixes, but common to all boards
- standard: update omap baseline match the 2.6.34
upstream merge content
Built and boot tested on qemu*
Signed-off-by: Bruce Ashfield bruce.ashfi...@windriver.com
---
meta/recipes-kernel/linux/linux-yocto_git.bb | 14 +++---
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/meta/recipes-kernel/linux/linux-yocto_git.bb
b/meta/recipes-kernel/linux/linux-yocto_git.bb
index 3aedb7a..b625cf2 100644
--- a/meta/recipes-kernel/linux/linux-yocto_git.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_git.bb
@@ -14,13 +14,13 @@ KMETA = meta
LINUX_VERSION ?= 2.6.37
LINUX_VERSION_EXTENSION ?= -yocto-${LINUX_KERNEL_TYPE}
-SRCREV_machine_qemuarm = 8776b242fe2db7b4570e11496e9105b51212a446
-SRCREV_machine_qemumips = 8f8a5e034d7e98ed871fa7ed487fbf72a79229a5
-SRCREV_machine_qemuppc = d9c6b3e576184f0c4223b6251c57b16ac1bac428
-SRCREV_machine_qemux86 = b2afed7ecd54918b73db7f30062aaaf02fdaba54
-SRCREV_machine_qemux86-64 = 86bbbc079652d87392322fbfc14f6bd8792b0f38
-SRCREV_machine = 0974631b821b70aee3613723ed0d4d6ba8da91c6
-SRCREV_meta = 06d3793d459048ee1b4db7170f24670c479e8b29
+SRCREV_machine_qemuarm = 9192bec81b274a6bb71bcddcab9de5475f55ec15
+SRCREV_machine_qemumips = 3e57c1547b07b30900bb29fdedcc38e99c237446
+SRCREV_machine_qemuppc = 492cff27ae13c33fdab68f8d971b15dcb719e7bf
+SRCREV_machine_qemux86 = ae10acfb83ed405127748393d9b4efb9e95cc78b
+SRCREV_machine_qemux86-64 = 28a3080512e19612a2e0b65d3077686f614ae556
+SRCREV_machine = 301ab1710d29a9bb931cb64c747d03da09dfea3f
+SRCREV_meta = f1dc3722d45cdcc92c84ebfecf4ce616d2efed26
PR = r18
PV = ${LINUX_VERSION}+git${SRCPV}
--
1.7.0.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
