[OE-core] [PATCH 0/5] Misc fixings of nativesdk

This patch serie fixed bunch of things for nativesdk recipes, including: 1. Fixed the issue of reading in incorrect pkgdata files of do_package_write_xxx. 2. Avoided crosssdk tasks generating different task hashs for different MACHINE. 3. Dropped unnecessary target tasks for nativesdk. The follo

[OE-core] [PATCH 1/5] nativesdk.bbclass: Set PACKAGE_ARCHS to SDK_PACKAGE_ARCHS.

This patch fixed the issue of reading incorrect pkgdata files. Previous appending '-nativesdk' suffix to PACKAGE_ARCHS would result the i686-nativesdk recipes reading in x86_64-nativesdk pkgdata files if the MACHINE is set to qemux86-64. Fixed bug [YOCTO #2203]. Signed-off-by: Lianhao Lu --- me

[OE-core] [PATCH 5/5] pkgconfig.bbclass: corrected dependency for -nativesdk.

For -nativesdk, the dependency should be pkgconfig-nativesdk instead of pkgconfig. Signed-off-by: Lianhao Lu --- meta/classes/pkgconfig.bbclass |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/meta/classes/pkgconfig.bbclass b/meta/classes/pkgconfig.bbclass index 53e793a..

[OE-core] [PATCH 2/5] crosssdk.bbclass: Set TUNE_PKGARCH to SDK_PKGARCH.

The TUNE_PKGARCH of crosssdk should be set to SDK_ARCH, not the one from target machine's configuration. Fixed bug [YOCTO #2206] Signed-off-by: Lianhao Lu --- meta/classes/crosssdk.bbclass |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/meta/classes/crosssdk.bbclass

[OE-core] [PATCH 4/5] eglibc-nativesdk: Set GCC_ADDONS.

Set only necessary GCC_ADDONS for eglibc-nativesdk so that it is not dependant on the target eglibc's GCC_ADDONS settings. Signed-off-by: Lianhao Lu --- meta/recipes-core/eglibc/eglibc_2.13.bb |3 ++- meta/recipes-core/eglibc/eglibc_2.15.bb |3 ++- 2 files changed, 4 insertions(+), 2 del

[OE-core] [PATCH 3/5] autotools.bbclass: Drop -nativesdk dependency to lib-cross.

-nativesdk recipes should not have dependency to lib-cross, which is never used. This unnecessary dependency would result different task hash values in sstate for different MACHINE settings. Signed-off-by: Lianhao Lu --- meta/classes/autotools.bbclass |1 + 1 files changed, 1 insertions(+),

Re: [OE-core] [PATCH 0/6] Setup for VMDK to use Direct Disk

Cui, Dexuan wrote on 2012-03-31: > Paul Eggleton wrote on 2012-03-30: >> On Monday 26 March 2012 22:42:54 Saul Wold wrote: >>> Updated comments per Darren's request, added cleanup to image-types >>> to only use one -i (inode-count) parameter. >>> >>> Sau! The following changes since commit >>> 644

Re: [OE-core] why does "bitbake -e" check the license of a *non*-included recipe file?

On Fri, 30 Mar 2012, Chris Larson wrote: > On Fri, Mar 30, 2012 at 5:17 PM, Robert P. J. Day > wrote: > > $ bitbake -e core-image-core > > Loading cache: 100% > > |##| > > ETA:  00:00:00 > > Loaded 1106 entries from dependency

[OE-core] xf86-input-synaptics: failed to build on arm and mips

Hi folks, I met this error when "bitbake world" (MACHINE=qemuarm) | configure.ac:1: run info '(automake)Extending aclocal' | configure.ac:1: or see http://www.gnu.org/software/automake/manual/automake.html#Extending-aclocal | configure.ac:53: error: must install xorg-server development fil

Re: [OE-core] [PATCH 1/1] gstreamer 0.10.x: remove do_configure_prepend

On 03/30/2012 09:24 PM, Richard Purdie wrote: On Wed, 2012-03-21 at 22:45 +0800, Robert Yang wrote: Hi Richard, Please see my comments inline ... On 03/21/2012 08:36 PM, Richard Purdie wrote: On Wed, 2012-03-21 at 16:38 +0800, Robert Yang wrote: Remove the do_configure_prepend which is use

[OE-core] [PATCH] qt-4.7.4: Fix build with gcc 4.7

g++ 4.7 is detecting inheritence problems which we solve by explictly specifying elements in constructors Signed-off-by: Khem Raj --- meta/recipes-qt/qt4/qt-4.7.4.inc |1 + meta/recipes-qt/qt4/qt-4.7.4/gcc47-fix.patch | 67 ++ meta/recipes-qt/qt4/qt4-emb

Re: [OE-core] why does "bitbake -e" check the license of a *non*-included recipe file?

On Fri, Mar 30, 2012 at 5:17 PM, Robert P. J. Day wrote: > $ bitbake -e core-image-core > Loading cache: 100% > |##| ETA: >  00:00:00 > Loaded 1106 entries from dependency cache. > ERROR: This recipe does not have the LICENSE fi

[OE-core] why does "bitbake -e" check the license of a *non*-included recipe file?

goofing around with "bitbake -e" and, with a clean oe-core checkout, both of the following work: $ bitbake -e $ bitbake -e core-image-core now, just for fun, i added a trivial recipe file to that images/ directory to see what kind of error message i would get if i neglected to include a lice

Re: [OE-core] [RFC] One shared state reuse solution

Op 30 mrt. 2012, om 16:23 heeft Chris Larson het volgende geschreven: > On Fri, Mar 30, 2012 at 3:02 PM, Koen Kooi wrote: >> Op 30 mrt. 2012, om 14:54 heeft Chris Larson het volgende geschreven: >> >>> Greetings, >>> >>> Over the past day, I've implemented a solution for the shared state >>> r

[OE-core] [PATCH] tune-cortexa8/9: fix PACKAGE tunes being all armv7at even for non-Thumb ones

From: Denys Dmytriyenko All PACKAGE_EXTRA_ARCHS for cortexa8, cortexa8t and cortexa8-neon have typo in referencing tune-armv7at even for non-Thumb modes. Probably a copy/paste error. That's not the case for recently-added hard-fp tunes. Same for cortexa9. Signed-off-by: Denys Dmytriyenko ---

Re: [OE-core] [RFC] One shared state reuse solution

On Fri, Mar 30, 2012 at 3:02 PM, Koen Kooi wrote: > Op 30 mrt. 2012, om 14:54 heeft Chris Larson het volgende geschreven: > >> Greetings, >> >> Over the past day, I've implemented a solution for the shared state >> reuse issues Mentor has seen with our poky-based product. This >> solution is simil

Re: [OE-core] [PATCH] tune-ppce500: correct the -mfloat-gprs compiler option

I noticed the same problem in the tuning rework that I've gone pending. I'm currently working on validating it and hope to have something for merging once I get done validating all 120 tunes. --Mark On 3/30/12 5:50 PM, Christopher Larson wrote: From: Christopher Larson Per Edmar at Freescal

Re: [OE-core] wanting to clarify bitbake parsing of all .conf files

On Fri, Mar 30, 2012 at 12:47 PM, Robert P. J. Day wrote: >  first, i'm assuming those conf files are processed in exactly that > order, right?  and second, all of that parsing and including is done > and completed before reading the first line of the task or recipe file > that's the bitbake targe

[OE-core] [PATCH] tune-ppce500: correct the -mfloat-gprs compiler option

From: Christopher Larson Per Edmar at Freescale, e500v2 needs -mfloat-gprs=double, but e500v1 needs -mfloat-gprs=single. Signed-off-by: Christopher Larson --- meta/conf/machine/include/tune-ppce500.inc |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/meta/conf/machine/

Re: [OE-core] [PATCH] license.bbclass: remove existing license.manifest before appending new data

On Thu, Mar 29, 2012 at 11:20 PM, Eric Bénard wrote: > Le Thu, 29 Mar 2012 16:22:06 -0700, > Chris Larson a écrit : > >> On Thu, Mar 29, 2012 at 5:22 AM, Eric Bénard wrote: >> > without this fix, we append license each time we build again the same >> > image, >> > ending with a large not up to

[OE-core] [PATCH 3/3] poky-tiny: avoid eglibc locale packaging

From: Nitin A Kamble This fixes bug: [YOCTO #2089] This avoids these errors NOTE: package eglibc-locale-2.13-r19: task do_populate_sysroot: Started ERROR: Error executing a python function in /opt/poky.git/meta/recipes-core/eglibc/eglibc-locale_2.13.bb: OSError: [Errno 2] No such file or directo

[OE-core] [PATCH 2/3] cross-canadian.bbclass: fix rpath for sdk executables

From: Nitin A Kamble This makes the libraries located in places like this findable: /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib Which avoids linking cross canadian sdk executables with host libraries like this: $ ldd /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/bi

[OE-core] [PATCH 1/3] nasm: fix issue with repeat configure

From: Nitin A Kamble This Fixes bug: [YOCTO #2176] This fixes the following issue as mentioned in the bug: If nasm-native has to be rebuilt (due to a signature change) it will fail: | checking for a BSD-compatible install... /usr/bin/install -c | /media/large/tmp/work/x86_64-linux/nasm-native-2

[OE-core] [PATCH 0/3] Misc Fixes

From: Nitin A Kamble The following changes since commit 06fc2d2ec8e72f063f2c67601b2f027f76971e05: documentation/dev-manual/dev-manual-common-tasks.xml: Title change (2012-03-30 17:20:51 +0100) are available in the git repository at: git://git.pokylinux.org/poky-contrib nitin/misc http://

Re: [OE-core] [RFC] One shared state reuse solution

On Fri, Mar 30, 2012 at 3:17 PM, Mark Hatle wrote: > On 3/30/12 5:09 PM, Chris Larson wrote: >> >> On Fri, Mar 30, 2012 at 3:04 PM, Mark Hatle >>  wrote: >>> >>> >>> We've worked on a similar problem in the past.  In specific cases we've >>> added a checksum of the host's glibc to the mix.  The pr

Re: [OE-core] [RFC] One shared state reuse solution

On 3/30/12 5:09 PM, Chris Larson wrote: On Fri, Mar 30, 2012 at 3:04 PM, Mark Hatle wrote: We've worked on a similar problem in the past. In specific cases we've added a checksum of the host's glibc to the mix. The problem we were solving was in glibc uprevs during the RHEL 4 world.. new API

Re: [OE-core] [RFC] One shared state reuse solution

On Fri, Mar 30, 2012 at 3:04 PM, Mark Hatle wrote: > > We've worked on a similar problem in the past.  In specific cases we've > added a checksum of the host's glibc to the mix.  The problem we were > solving was in glibc uprevs during the RHEL 4 world.. new APIs would arrive > and things would br

Re: [OE-core] [RFC] One shared state reuse solution

On Fri, Mar 30, 2012 at 3:02 PM, Koen Kooi wrote: > Op 30 mrt. 2012, om 14:54 heeft Chris Larson het volgende geschreven: >> I'm looking for questions, comments, testers, and in particular, >> thoughts on whether this will meet the needs of others with similar >> requirements (e.g. others shippin

Re: [OE-core] [RFC] One shared state reuse solution

(top posting, ya I know...) We've worked on a similar problem in the past. In specific cases we've added a checksum of the host's glibc to the mix. The problem we were solving was in glibc uprevs during the RHEL 4 world.. new APIs would arrive and things would break -- or workaround would br

Re: [OE-core] [RFC] One shared state reuse solution

Op 30 mrt. 2012, om 14:54 heeft Chris Larson het volgende geschreven: > Greetings, > > Over the past day, I've implemented a solution for the shared state > reuse issues Mentor has seen with our poky-based product. This > solution is similar in concept to what we had in our Mentor Embedded > Lin

Re: [OE-core] [RFC] One shared state reuse solution

On Fri, Mar 30, 2012 at 2:54 PM, Chris Larson wrote: > Over the past day, I've implemented a solution for the shared state > reuse issues Mentor has seen with our poky-based product. This > solution is similar in concept to what we had in our Mentor Embedded > Linux 4 (non-yocto-based) product. >

[OE-core] [RFC] One shared state reuse solution

Greetings, Over the past day, I've implemented a solution for the shared state reuse issues Mentor has seen with our poky-based product. This solution is similar in concept to what we had in our Mentor Embedded Linux 4 (non-yocto-based) product. This implementation restructures SSTATE_DIR such th

Re: [OE-core] [PATCH 0/1] genext2fs: support large files and filesystems without using large amounts of memor

Op 30 mrt. 2012, om 14:49 heeft Richard Purdie het volgende geschreven: > On Fri, 2012-03-30 at 13:43 -0700, Koen Kooi wrote: >> Op 29 mrt. 2012, om 15:07 heeft Richard Purdie het volgende geschreven: >> >>> On Thu, 2012-03-29 at 00:51 +0800, Dexuan Cui wrote: Hi RP, Saul, Paul, Darren, Mar

Re: [OE-core] [PATCH 0/1] genext2fs: support large files and filesystems without using large amounts of memor

On Fri, 2012-03-30 at 13:43 -0700, Koen Kooi wrote: > Op 29 mrt. 2012, om 15:07 heeft Richard Purdie het volgende geschreven: > > > On Thu, 2012-03-29 at 00:51 +0800, Dexuan Cui wrote: > >> Hi RP, Saul, Paul, Darren, Mark, Josh and joaohf and all, please comment. > >> > >> Let's figure out if thi

Re: [OE-core] [RFC][PATCH] arch-armv7a.inc: fix PACKAGE_EXTRA_ARCHS after armv7.inc was removed

I think opkg-config-base needs a PR bump for this, since arch.conf was broken: https://github.com/Angstrom-distribution/buildhistory/commit/7ca5de97ae09aa77c89761a7909cb3c3b0ecdb7b Op 30 mrt. 2012, om 06:26 heeft Martin Jansa het volgende geschreven: > Signed-off-by: Martin Jansa > --- > meta/c

Re: [OE-core] [PATCH 0/6] Setup for VMDK to use Direct Disk

Paul Eggleton wrote on 2012-03-30: > On Monday 26 March 2012 22:42:54 Saul Wold wrote: >> Updated comments per Darren's request, added cleanup to image-types >> to only use one -i (inode-count) parameter. >> >> Sau! The following changes since commit >> 644b7503c37fd73730dd3d7841463b158b8934ed: >>

Re: [OE-core] [PATCH 0/1] genext2fs: support large files and filesystems without using large amounts of memor

Op 29 mrt. 2012, om 15:07 heeft Richard Purdie het volgende geschreven: > On Thu, 2012-03-29 at 00:51 +0800, Dexuan Cui wrote: >> Hi RP, Saul, Paul, Darren, Mark, Josh and joaohf and all, please comment. >> >> Let's figure out if this big patch is accepatable or not... >> >> With this patch, I

Re: [OE-core] require/include a .bb file in the same directory?

On Fri, 30 Mar 2012, Chris Larson wrote: ... snip ... > The directory the recipe lives in gets temporarily injected into > BBPATH as the first element. ah, that wasn't at all obvious, until i dumped the bitbake environment with "bitbake -e" and noticed: BBPATH=":/home/rpjday/oe/oe-core/meta

Re: [OE-core] require/include a .bb file in the same directory?

On Fri, Mar 30, 2012 at 12:50 PM, Denys Dmytriyenko wrote: > On Fri, Mar 30, 2012 at 05:59:22AM -0400, Robert P. J. Day wrote: >> >>   couple questions about the require/include directives.  first, can >> you include *any* valid text file?  not just your standard .inc file >> (even though that is

Re: [OE-core] require/include a .bb file in the same directory?

On Fri, Mar 30, 2012 at 05:59:22AM -0400, Robert P. J. Day wrote: > > couple questions about the require/include directives. first, can > you include *any* valid text file? not just your standard .inc file > (even though that is of course the most common thing to do). > > and second, i'm lo

[OE-core] wanting to clarify bitbake parsing of all .conf files

i'm reading this out of the current bitbake manual and it *seems* pretty straightforward but i'm always paranoid. here's the passage: "BitBake will first search the current working directory for an optional "conf/bblayers.conf" configuration file. This file is expected to contain a BBLAYERS va

[OE-core] LCONF_VERSION versus LAYER_CONF_VERSION?

bblayers.conf.sample opens thusly: # LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf # changes incompatibly LCONF_VERSION = "4" that's confusing since the variable in the comment doesn't match the variable being assigned. clarification? rday --

[OE-core] [PATCH] webkit: Fix build with gcc-4.7

Include unistd.h for all linux and not just for android. Signed-off-by: Khem Raj --- .../recipes-sato/webkit/files/function-scope.patch | 21 meta/recipes-sato/webkit/webkit-gtk_svn.bb |3 +- 2 files changed, 23 insertions(+), 1 deletions(-) create mode 100644

[OE-core] [PATCH 1/2] apt: Fix a latent bug exposed by gcc 4.7

Further Details are in patch itself Signed-off-by: Khem Raj --- .../apt/apt-0.7.14/remove-redeclaration.patch | 57 meta/recipes-devtools/apt/apt_0.7.14.bb|6 ++- 2 files changed, 61 insertions(+), 2 deletions(-) create mode 100644 meta/recipes-devto

[OE-core] [PATCH 2/2] gst-ffmpeg: Fix build with gcc 4.7

A cmp instruction with two constants is invalid, therefore 'g' constraint is not correct but must be "rm" instead. Signed-off-by: Khem Raj --- .../gst-ffmpeg-0.10.13/h264_qpel_mmx.patch | 57 .../gstreamer/gst-ffmpeg_0.10.13.bb|3 +- 2 files cha

Re: [OE-core] Fetch time optimization (svn : gcc/eglibc - git : linux-yocto)

Le Fri, 30 Mar 2012 13:33:05 -0400, Bruce Ashfield a écrit : > There are alternatives that I'm going to be exploring going forward, > just nothing > that we can bring in during the stabilization cycle. The recipes manipulate > git > and use it to construct what you build, they don't absolutely re

Re: [OE-core] [PATCHv2] rootfs_ipk: don't echo opkg-cl output to log.do_rootfs

Op 30 mrt. 2012, om 11:10 heeft Denys Dmytriyenko het volgende geschreven: > On Fri, Mar 30, 2012 at 12:55:39PM +0200, Martin Jansa wrote: >> * log_check can find some files with ERR or Fail substring e.g. in "Source: >> " field >> >> Signed-off-by: Martin Jansa > > This one looks better and

Re: [OE-core] [PATCHv2] rootfs_ipk: don't echo opkg-cl output to log.do_rootfs

On Fri, Mar 30, 2012 at 12:55:39PM +0200, Martin Jansa wrote: > * log_check can find some files with ERR or Fail substring e.g. in "Source: " > field > > Signed-off-by: Martin Jansa This one looks better and it does not change the regex string, like the patch sent to bitbake-devel... Acked-by

Re: [OE-core] Fetch time optimization (svn : gcc/eglibc - git : linux-yocto)

On Fri, Mar 30, 2012 at 12:17 PM, Eric Bénard wrote: > Le Fri, 30 Mar 2012 17:02:24 +0100, > Richard Purdie a écrit : >> The linux-yocto kernel recipe heavily uses the SCM to do things so >> whilst it does have a higher download cost, it as adds value and is >> ultimately a maintainers choice too

[OE-core] [PATCH] license.py: fix behaviour of copyleft_compliance

actually if a package has a license in its LICENSE variable which is not in the whitelist nor in the blacklist and even if an other license in this variable is in the whitelist, the package gets excluded and is not taken in account in the copyleft_compliance. This patch solves this by excluding a r

Re: [OE-core] why i'm being so annoyingly pedantic about nitpicky details

On Fri, 30 Mar 2012, Eric Bénard wrote: > Le Fri, 30 Mar 2012 06:31:39 -0400 (EDT), > "Robert P. J. Day" a écrit : > > in other words, there will be more pedantry, but the end result will > > be released as cc-by-sa, so consider it an investment. :-) > > > I hope that openembedded-core@lists.op

Re: [OE-core] Fetch time optimization (svn : gcc/eglibc - git : linux-yocto)

Le Fri, 30 Mar 2012 17:02:24 +0100, Richard Purdie a écrit : > The linux-yocto kernel recipe heavily uses the SCM to do things so > whilst it does have a higher download cost, it as adds value and is > ultimately a maintainers choice too. > OK now that I've given a closer look at the linux-yocto

Re: [OE-core] Fetch time optimization (svn : gcc/eglibc - git : linux-yocto)

On Fri, 2012-03-30 at 17:24 +0200, Eric Bénard wrote: > Le Fri, 30 Mar 2012 16:12:44 +0100, > Richard Purdie a écrit : > > On Fri, 2012-03-30 at 10:50 +0200, Eric Bénard wrote: > > > the default configuration seems to fetch from source control systems > > > as I always see very long time to fetch

Re: [OE-core] Fetch time optimization (svn : gcc/eglibc - git : linux-yocto)

Le Fri, 30 Mar 2012 11:49:33 -0400, Bruce Ashfield a écrit : > On Fri, Mar 30, 2012 at 11:24 AM, Eric Bénard wrote: > > I think fetching from git or svn should not be the first thing to do in > > recipes like gcc, eglibc, linux & co where we are based on a > > stable released version : this doesn

Re: [OE-core] Fetch time optimization (svn : gcc/eglibc - git : linux-yocto)

On Fri, Mar 30, 2012 at 11:24 AM, Eric Bénard wrote: > Le Fri, 30 Mar 2012 16:12:44 +0100, > Richard Purdie a écrit : >> On Fri, 2012-03-30 at 10:50 +0200, Eric Bénard wrote: >> > the default configuration seems to fetch from source control systems >> > as I always see very long time to fetch gcc

Re: [OE-core] [PATCH 0/1] genext2fs: support large files and filesystems without using large amounts of memor

Darren Hart wrote on 2012-03-30: > On 03/29/2012 03:07 PM, Richard Purdie wrote: >> On Thu, 2012-03-29 at 00:51 +0800, Dexuan Cui wrote: >>> Hi RP, Saul, Paul, Darren, Mark, Josh and joaohf and all, please comment. >>> >>> Let's figure out if this big patch is acceptable or not... >>> >>> With th

Re: [OE-core] Fetch time optimization (svn : gcc/eglibc - git : linux-yocto)

Le Fri, 30 Mar 2012 16:12:44 +0100, Richard Purdie a écrit : > On Fri, 2012-03-30 at 10:50 +0200, Eric Bénard wrote: > > the default configuration seems to fetch from source control systems > > as I always see very long time to fetch gcc/eglibc/linux-yocto > > (despite having a 2.2 MBytes/s downli

Re: [OE-core] Fetch time optimization (svn : gcc/eglibc - git : linux-yocto)

On Fri, 2012-03-30 at 10:50 +0200, Eric Bénard wrote: > Le Thu, 29 Mar 2012 23:03:13 +0100, > Richard Purdie a écrit : > > > On Thu, 2012-03-29 at 22:53 +0200, Eric Bénard wrote: > > > I noticed in from scratch builds for qemuarm that the longest time is > > > taken in fetching sources, especiall

Re: [OE-core] [oe-core][PATCHv 05/10] pixman: add native support and perl-native to DEPENDS from meta-oe

On Fri, 2012-03-30 at 16:22 +0200, Martin Jansa wrote: > On Fri, Mar 30, 2012 at 03:10:32PM +0100, Richard Purdie wrote: > > On Fri, 2012-03-23 at 23:30 +0100, Martin Jansa wrote: > > > Signed-off-by: Martin Jansa > > > --- > > > meta/recipes-graphics/xorg-lib/pixman_0.25.2.bb |3 ++- > > > 1

Re: [OE-core] [oe-core][PATCHv 05/10] pixman: add native support and perl-native to DEPENDS from meta-oe

On Fri, Mar 30, 2012 at 03:10:32PM +0100, Richard Purdie wrote: > On Fri, 2012-03-23 at 23:30 +0100, Martin Jansa wrote: > > Signed-off-by: Martin Jansa > > --- > > meta/recipes-graphics/xorg-lib/pixman_0.25.2.bb |3 ++- > > 1 files changed, 2 insertions(+), 1 deletions(-) > > > > diff --git

Re: [OE-core] [PATCH 0/6] Setup for VMDK to use Direct Disk

On Monday 26 March 2012 22:42:54 Saul Wold wrote: > Updated comments per Darren's request, added cleanup to > image-types to only use one -i (inode-count) parameter. > > Sau! > The following changes since commit 644b7503c37fd73730dd3d7841463b158b8934ed: > > guile: Deal with hardcoded path issue

Re: [OE-core] [oe-core][PATCHv 05/10] pixman: add native support and perl-native to DEPENDS from meta-oe

On Fri, 2012-03-23 at 23:30 +0100, Martin Jansa wrote: > Signed-off-by: Martin Jansa > --- > meta/recipes-graphics/xorg-lib/pixman_0.25.2.bb |3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-) > > diff --git a/meta/recipes-graphics/xorg-lib/pixman_0.25.2.bb > b/meta/recipes-graphics/

Re: [OE-core] pseudo failing with cc1: error: unrecognized command line option '-m32'

On Thu, Mar 29, 2012 at 11:57 AM, Peter Seebach wrote: > On Thu, 29 Mar 2012 11:53:23 -0700 > Steve Sakoman wrote: > >> Clearly not something a sane person would do . . . > > Now that is a persuasive argument in favor of making it work if I've > ever heard one! > > I'm doing too many things right

[OE-core] [RFC][PATCH] arch-armv7a.inc: fix PACKAGE_EXTRA_ARCHS after armv7.inc was removed

Signed-off-by: Martin Jansa --- meta/conf/machine/include/arm/arch-armv7a.inc | 16 1 files changed, 8 insertions(+), 8 deletions(-) diff --git a/meta/conf/machine/include/arm/arch-armv7a.inc b/meta/conf/machine/include/arm/arch-armv7a.inc index 92640e2..2542f45 100644 --- a/

Re: [OE-core] [PATCH 1/1] gstreamer 0.10.x: remove do_configure_prepend

On Wed, 2012-03-21 at 22:45 +0800, Robert Yang wrote: > Hi Richard, > > Please see my comments inline ... > > On 03/21/2012 08:36 PM, Richard Purdie wrote: > > On Wed, 2012-03-21 at 16:38 +0800, Robert Yang wrote: > >> Remove the do_configure_prepend which is used for removing > >> ${S}/m4/lib-li

Re: [OE-core] [oe-commits] Khem Raj : tune/armv7: Delete

On Wed, Mar 28, 2012 at 09:13:35AM +, g...@git.openembedded.org wrote: > Module: openembedded-core.git > Branch: master > Commit: 75b8adbc042e0f65fb1286bc550d02becd3b6aea > URL: > http://git.openembedded.org/?p=openembedded-core.git&a=commit;h=75b8adbc042e0f65fb1286bc550d02becd3b6aea > > A

Re: [OE-core] why i'm being so annoyingly pedantic about nitpicky details

Le Fri, 30 Mar 2012 06:31:39 -0400 (EDT), "Robert P. J. Day" a écrit : > in other words, there will be more pedantry, but the end result will > be released as cc-by-sa, so consider it an investment. :-) > I hope that openembedded-core@lists.openembedded.org will be mentioned as one of the preci

Re: [OE-core] why i'm being so annoyingly pedantic about nitpicky details

On Fri, 30 Mar 2012, Paul Eggleton wrote: > On Friday 30 March 2012 06:31:39 Robert P. J. Day wrote: > > i realize many of my questions are and will be spectacularly > > nitpicky but the motivation here is that i and a buddy of mine > > from wind river are going to be submitting a proposal to th

Re: [OE-core] why i'm being so annoyingly pedantic about nitpicky details

On Friday 30 March 2012 06:31:39 Robert P. J. Day wrote: > i realize many of my questions are and will be spectacularly > nitpicky but the motivation here is that i and a buddy of mine from > wind river are going to be submitting a proposal to this year's ottawa > linux symposium for a 1/2-day tu

[OE-core] [PATCHv2] rootfs_ipk: don't echo opkg-cl output to log.do_rootfs

* log_check can find some files with ERR or Fail substring e.g. in "Source: " field Signed-off-by: Martin Jansa --- meta/classes/rootfs_ipk.bbclass |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/meta/classes/rootfs_ipk.bbclass b/meta/classes/rootfs_ipk.bbclass index 1

Re: [OE-core] argh ... "_append" versus "+=" and IMAGE_INSTALL confusion

On Friday 30 March 2012 06:23:39 Robert P. J. Day wrote: > that is, stop messing with IMAGE_INSTALL and do your customization > with CORE_IMAGE_EXTRA_INSTALL. isn't that what it was expressly > designed for? Possibly, but I had assumed though that CORE_IMAGE_EXTRA_INSTALL (and EXTRA_IMAGE_FEAT

Re: [OE-core] Fetch time optimization (svn : gcc/eglibc - git : linux-yocto)

On Fri, 2012-03-30 at 12:07 +0200, Samuel Stirtzel wrote: > Of course this will only reduce the time of recipes if they are build > for the first time, > or when the version/URL changes. > It is not that important, I agree, > but it would improve the situation for first time users, or new installat

Re: [OE-core] [PATCH] rootfs_ipk: don't echo opkg-cl output to log.do_rootfs

On Fri, Mar 30, 2012 at 11:50:01AM +0200, Martin Jansa wrote: > * log_check can find some files with ERR or Fail substring e.g. in "Source: " > field > > Signed-off-by: Martin Jansa > --- > meta/classes/rootfs_ipk.bbclass |2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff -

[OE-core] why i'm being so annoyingly pedantic about nitpicky details

i realize many of my questions are and will be spectacularly nitpicky but the motivation here is that i and a buddy of mine from wind river are going to be submitting a proposal to this year's ottawa linux symposium for a 1/2-day tutorial on OE/bitbake/yocto, so i want to make absolutely sure i'

Re: [OE-core] argh ... "_append" versus "+=" and IMAGE_INSTALL confusion

On Thu, 29 Mar 2012, Paul Eggleton wrote: > I think what the manual is attempting to mitigate is a situation > where you do the following in your image recipe: > > snip --- > IMAGE_INSTALL += "somepackage1 somepackage2" > > inherit core-image > snip --- > > In this instan

Re: [OE-core] Fetch time optimization (svn : gcc/eglibc - git : linux-yocto)

2012/3/30 Richard Purdie : > On Fri, 2012-03-30 at 08:44 +0200, Samuel Stirtzel wrote: >> this might be a bit off-topic, but another idea would be to add a >> separate threading mechanism for fetching. >> >> Current threading can help to use the CPU and memory load to it's optimum, >> but sometimes

Re: [OE-core] Fetch time optimization (svn : gcc/eglibc - git : linux-yocto)

On Fri, 2012-03-30 at 09:00 +0200, Martin Jansa wrote: > On Thu, Mar 29, 2012 at 09:03:15PM -0400, Bruce Ashfield wrote: > > On Thu, Mar 29, 2012 at 6:03 PM, Richard Purdie > > wrote: > > >> - do the same thing for the linux-yocto kernel or add a --reference > > >> option to the git fetcher so t

[OE-core] require/include a .bb file in the same directory?

couple questions about the require/include directives. first, can you include *any* valid text file? not just your standard .inc file (even though that is of course the most common thing to do). and second, i'm looking at this example in meta/recipes-core/images, where the recipe file core-

[OE-core] [PATCH] rootfs_ipk: don't echo opkg-cl output to log.do_rootfs

* log_check can find some files with ERR or Fail substring e.g. in "Source: " field Signed-off-by: Martin Jansa --- meta/classes/rootfs_ipk.bbclass |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/meta/classes/rootfs_ipk.bbclass b/meta/classes/rootfs_ipk.bbclass index 1

[OE-core] [PATCH v2] docbook-utils-native: fix syntax problem in jw.in

Fix runtime error occurred e.g. with docbook-to-man calls: grep: character class syntax is [[:space:]], not [:space:] grep: character class syntax is [[:space:]], not [:space:] jw: There is no frontend called "/docbook/utils-0.6.14/frontends/docbook". See also:

Re: [OE-core] Fetch time optimization (svn : gcc/eglibc - git : linux-yocto)

On Fri, 2012-03-30 at 08:44 +0200, Samuel Stirtzel wrote: > this might be a bit off-topic, but another idea would be to add a > separate threading mechanism for fetching. > > Current threading can help to use the CPU and memory load to it's optimum, > but sometimes you have to wait for a download

Re: [OE-core] [PATCH 1/2] eglibc-2.15: Update SRCREV

On Sat, Mar 24, 2012 at 03:26:39AM +0100, Martin Jansa wrote: > On Fri, Mar 23, 2012 at 02:17:02PM +0100, Martin Jansa wrote: > > On Fri, Mar 23, 2012 at 12:05:25PM +, Richard Purdie wrote: > > > On Thu, 2012-03-22 at 19:56 -0700, Khem Raj wrote: > > > > Get new patches and remove the one that

Re: [OE-core] Fetch time optimization (svn : gcc/eglibc - git : linux-yocto)

On Friday 30 March 2012 08:44:56 Samuel Stirtzel wrote: > this might be a bit off-topic, but another idea would be to add a > separate threading mechanism for fetching. > > Current threading can help to use the CPU and memory load to it's optimum, > but sometimes you have to wait for a download to

Re: [OE-core] Fetch time optimization (svn : gcc/eglibc - git : linux-yocto)

Le Thu, 29 Mar 2012 23:03:13 +0100, Richard Purdie a écrit : > On Thu, 2012-03-29 at 22:53 +0200, Eric Bénard wrote: > > I noticed in from scratch builds for qemuarm that the longest time is > > taken in fetching sources, especially those fetched using git > > (linux-yocto for example) & svn (gcc

Re: [OE-core] [bitbake-devel] do_rootfs failed ... bug in log_check?

On Fri, Mar 30, 2012 at 02:27:13AM -0400, Oren Leaffer wrote: > Hi, > > I'm getting the following failure on "bitbake -v -D -D -D systemd-image": > ERROR: Task 8 > (/home/ol/setup-scripts/sources/meta-angstrom/recipes-images/angstrom/systemd-image.bb, > do_rootfs) failed with exit code '1' > NOTE

Re: [OE-core] Fetch time optimization (svn : gcc/eglibc - git : linux-yocto)

On Thu, Mar 29, 2012 at 09:03:15PM -0400, Bruce Ashfield wrote: > On Thu, Mar 29, 2012 at 6:03 PM, Richard Purdie > wrote: > > On Thu, 2012-03-29 at 22:53 +0200, Eric Bénard wrote: > >> I noticed in from scratch builds for qemuarm that the longest time is > >> taken in fetching sources, especially