On Tue, Oct 02, 2012 at 04:18:50PM +, g...@git.openembedded.org wrote:
> Module: openembedded-core.git
> Branch: master
> Commit: 97a3ea712003e8d48dc68c282e656591f39d2d1a
> URL:
> http://git.openembedded.org/?p=openembedded-core.git&a=commit;h=97a3ea712003e8d48dc68c282e656591f39d2d1a
>
> A
On Tue, 2012-10-02 at 16:30 -0500, Chase Maupin wrote:
> * When building with 24 bitbake threads on my system I observed
> errors like the following:
> | configure.ac:199: error: LT_LANG: unsupported language: "Go"
> |
> /work/armv7a-vfp-neon-oe-linux-gnueabi/libtool-2.4.2-r3.0/libtool-2
On Thu, 2012-10-04 at 11:12 +0200, Martin Jansa wrote:
> On Tue, Oct 02, 2012 at 04:18:50PM +, g...@git.openembedded.org wrote:
> > Module: openembedded-core.git
> > Branch: master
> > Commit: 97a3ea712003e8d48dc68c282e656591f39d2d1a
> > URL:
> > http://git.openembedded.org/?p=openembedded-
On Thu, Oct 04, 2012 at 10:28:35AM +0100, Richard Purdie wrote:
> On Thu, 2012-10-04 at 11:12 +0200, Martin Jansa wrote:
> > On Tue, Oct 02, 2012 at 04:18:50PM +, g...@git.openembedded.org wrote:
> > > Module: openembedded-core.git
> > > Branch: master
> > > Commit: 97a3ea712003e8d48dc68c282e65
removed also entry from
meta/recipes-gnome/packagegroups/packagegroup-sdk-gmae.inc
Signed-off-by: Andrei Dinu
---
meta/recipes-connectivity/gypsy/files/fixups.patch | 21 -
meta/recipes-connectivity/gypsy/gypsy.inc | 15
meta/recipes-connectivity/gypsy/
On Thu, 2012-10-04 at 11:33 +0200, Martin Jansa wrote:
> On Thu, Oct 04, 2012 at 10:28:35AM +0100, Richard Purdie wrote:
> > On Thu, 2012-10-04 at 11:12 +0200, Martin Jansa wrote:
> > > On Tue, Oct 02, 2012 at 04:18:50PM +, g...@git.openembedded.org wrote:
> > > > Module: openembedded-core.git
Instead of explicitly updating the icon cache use the helper class that also
forces a loader update at the same time. This eliminates the possibility of
updating the icon cache without any gdk-pixbuf loaders.
Also check that the Sato icon theme isn't already set to avoid appending to the
file eve
When the hostname isn't qemuarm the grep fails so the postinst fails. Stop this
happening by explicitly evaluating true.
[YOCTO #3224]
Signed-off-by: Ross Burton
---
meta/recipes-sato/shutdown-desktop/shutdown-desktop.bb |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a
Since updating my copy of bitbake to one which does this extra locking,
I've come to realise that the constraint of having only one copy of
bitbake running is a bit of a nuisance when making use of devshells. I
used to quite often have one or two long-running devshells for packages
that I was acti
On Thu, Oct 04, 2012 at 01:07:46PM +0100, Phil Blundell wrote:
> Since updating my copy of bitbake to one which does this extra locking,
> I've come to realise that the constraint of having only one copy of
> bitbake running is a bit of a nuisance when making use of devshells. I
> used to quite of
At 13:07, Thu 2012-10-04, Phil Blundell wrote:
> Since updating my copy of bitbake to one which does this extra locking,
> I've come to realise that the constraint of having only one copy of
> bitbake running is a bit of a nuisance when making use of devshells.
In Message-ID: <20120924074452.gh2..
> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On
> Behalf Of Richard Purdie
> Sent: Thursday, October 04, 2012 4:21 AM
> To: Maupin, Chase
> Cc: openembedded-core@lists.openembedded.org
> Subject: Re
On Thu, 2012-10-04 at 13:07 +0100, Phil Blundell wrote:
> Since updating my copy of bitbake to one which does this extra locking,
> I've come to realise that the constraint of having only one copy of
> bitbake running is a bit of a nuisance when making use of devshells. I
> used to quite often hav
On Thu, 2012-10-04 at 12:39 +, Maupin, Chase wrote:
> I was able to reproduce this consistently on my build server which has
> 24 cores running at 3.5 GHz. I was using:
>
> BB_NUMBER_THREADS = "24"
>
> And
>
> PARALLEL_MAKE = "-j 24"
>
> I can try a build reducing the number of threads and
> -Original Message-
> From: Richard Purdie [mailto:richard.pur...@linuxfoundation.org]
> Sent: Thursday, October 04, 2012 7:58 AM
> To: Maupin, Chase
> Cc: openembedded-core@lists.openembedded.org
> Subject: RE: [OE-core] [PATCH] libtool: Add missing DEPENDS on
> libtool-cross
>
> On Thu,
Tested with sstate-diff.sh script and fake machine configs added in this branch:
http://git.openembedded.org/openembedded-core-contrib/log/?h=jansa/tune2-test
Fixes [YOCTO #3219]
The following changes since commit df2b756436b90f8f9ff229ba64d0af30d9d4f923:
common-licenses: Adding bzip (2012-10-
* without this you'll get different sstate checksum for webkit-gtk and
cairo even when you build them with DEFAULTTUNE == armv5te
* maybe this isn't needed at all anymore or if it is then it should be
applied in arm-armv5.inc for all armv5te devices, not only xscale?
Signed-off-by: Martin Jans
* we don't care about expression but value
* e.g. tune-xscale and tune-arm926ejs have different expression
in TUNE_CCARGS but with the same DEFAULTTUNE the result is the same
http://lists.linuxtogo.org/pipermail/openembedded-core/2012-September/030032.html
Signed-off-by: Martin Jansa
---
me
* probably copy&paste error from tune-cortexm3.conf
commit 789dcb8e68a2ab9784ac10ab36815010c61af2fc
Author: Richard Purdie
Date: Mon Jul 25 19:03:24 2011 +0100
Add ARM tune file overhaul based largely on work from Mark Hatle
Signed-off-by: Martin Jansa
---
meta/conf/machine/include
* tune-foo is not valid override, for it to work I had to add
ARMPKGARCH = "${ARMPKGARCH_tune-${DEFAULTTUNE}}"
but that doesn't work without value defined for every supported
DEFAULTTUNE value, otherwise it's expanded like this
TUNE_PKGARCH (${ARMPKGARCH_tune-armv5te}te).
Signed-off-by: Ma
* this is mostly for backwards compatibility and to share binary feed
like it was before, but now without missing different -mtune in it
* if you want to build some package with -mtune add something like this
to your distro config
DEFAULTTUNE_qemuarm_pn-openssl = "arm926ejs"
DEFAULTTUNE_qem
* without this tune-xscale and tune-arm926ejs were both creating
packages in armv5te feed, but each with different -mtune, with
OEBasicHash enabled it was causing each package to rebuild with new
-mtune after MACHINE switch, but that doesn't make sense with output
stored in the same armv5te
* it's not very universal, but works with default oe-core setup and
shows basic HOW-TO, because many people still don't know how to detect
machine specific sstate checksums
* someone can improve this with bitbake -e calls to detect BASE and to
specify MACHINEs and TARGETs in parameter instead
> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On
> Behalf Of Maupin, Chase
> Sent: Thursday, October 04, 2012 8:02 AM
> To: Richard Purdie
> Cc: openembedded-core@lists.openembedded.org
> Subject: Re
On Thu, 2012-10-04 at 14:06 +, Maupin, Chase wrote:
> I tried the following to help narrow this down. Please let me know if there
> is something else I could try to help narrow the issue. I ran:
>
> bitbake -c cleanall libtool
> bitbake libtool
>
> Each time it failed I would get a list of
> -Original Message-
> From: Richard Purdie [mailto:richard.pur...@linuxfoundation.org]
> Sent: Thursday, October 04, 2012 9:30 AM
> To: Maupin, Chase
> Cc: openembedded-core@lists.openembedded.org
> Subject: RE: [OE-core] [PATCH] libtool: Add missing DEPENDS on
> libtool-cross
>
> On Thu,
On 10/04/2012 08:50 AM, Maupin, Chase wrote:
-Original Message- From: Richard Purdie
[mailto:richard.pur...@linuxfoundation.org] Sent: Thursday, October
04, 2012 9:30 AM To: Maupin, Chase Cc:
openembedded-core@lists.openembedded.org Subject: RE: [OE-core]
[PATCH] libtool: Add missing DEPE
On Thu, Oct 4, 2012 at 5:27 AM, Martin Jansa wrote:
> On Thu, Oct 04, 2012 at 01:07:46PM +0100, Phil Blundell wrote:
>> Since updating my copy of bitbake to one which does this extra locking,
>> I've come to realise that the constraint of having only one copy of
>> bitbake running is a bit of a nu
On Thu, Oct 4, 2012 at 6:23 AM, Martin Jansa wrote:
>
> -TUNE_CCARGS_pn-webkit-gtk = "-march=armv4t"
> -TUNE_CCARGS_pn-cairo = "-march=armv4t"
> +TUNE_CCARGS_pn-webkit-gtk = "${@bb.utils.contains("TUNE_FEATURES", "xscale",
> "-march=armv4t", "", d)}"
> +TUNE_CCARGS_pn-cairo = "${@bb.utils.contain
On Thu, Oct 4, 2012 at 6:23 AM, Martin Jansa wrote:
>
> -TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "armv7r",
> "-march=armv7-m", "", d)}"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "armv7r",
> "-march=armv7-r", "", d)}"
yeah this is ok
On Thu, Oct 04, 2012 at 09:55:01AM -0700, Khem Raj wrote:
> On Thu, Oct 4, 2012 at 6:23 AM, Martin Jansa wrote:
> >
> > -TUNE_CCARGS_pn-webkit-gtk = "-march=armv4t"
> > -TUNE_CCARGS_pn-cairo = "-march=armv4t"
> > +TUNE_CCARGS_pn-webkit-gtk = "${@bb.utils.contains("TUNE_FEATURES",
> > "xscale", "-
We have an issue where we'd like to have an alternative toolchain (assembler,
linker, compiler) available for our customers to selectively use. However,
before we just go off and implement something, I'd like at least some basic
consensus on what the best practice is for doing this work. Below
I'm curious to know if anyone (I certainly wouldn't be able to!) can
take a guess whether this would "play nicely" with external
toolchains?
In other words, if some recipe is already PROVIDES'ing
virtual/${TARGET_PREFIX}gcc etc would the correct toolchain be used
for the special packages needing t
On 10/4/12 1:15 PM, Trevor Woerner wrote:
I'm curious to know if anyone (I certainly wouldn't be able to!) can
take a guess whether this would "play nicely" with external
toolchains?
In other words, if some recipe is already PROVIDES'ing
virtual/${TARGET_PREFIX}gcc etc would the correct toolchai
On Thu, Oct 4, 2012 at 1:02 PM, Mark Hatle wrote:
> We have an issue where we'd like to have an alternative toolchain
> (assembler, linker, compiler) available for our customers to selectively
> use. However, before we just go off and implement something, I'd like at
> least some basic consensus
On Thu, Oct 4, 2012 at 1:37 AM, Andreas Müller
wrote:
> On Wed, Sep 26, 2012 at 9:41 AM, Andreas Müller
> wrote:
>> On Wed, Sep 26, 2012 at 9:09 AM, Laurentiu Palcu
>> wrote:
>>>
>>>
>>> On 09/20/2012 07:12 PM, Andreas Müller wrote:
On Thu, Sep 20, 2012 at 5:38 PM, Andreas Müller
wrot
On 10/4/12 2:03 PM, McClintock Matthew-B29882 wrote:
On Thu, Oct 4, 2012 at 1:02 PM, Mark Hatle wrote:
We have an issue where we'd like to have an alternative toolchain
(assembler, linker, compiler) available for our customers to selectively
use. However, before we just go off and implement so
On Thu, Oct 4, 2012 at 11:02 AM, Mark Hatle wrote:
> We have an issue where we'd like to have an alternative toolchain
> (assembler, linker, compiler) available for our customers to selectively
> use. However, before we just go off and implement something, I'd like at
> least some basic consensus
On 10/4/12 3:36 PM, Khem Raj wrote:
On Thu, Oct 4, 2012 at 11:02 AM, Mark Hatle wrote:
We have an issue where we'd like to have an alternative toolchain
(assembler, linker, compiler) available for our customers to selectively
use. However, before we just go off and implement something, I'd lik
On Thu, Oct 4, 2012 at 2:00 PM, Mark Hatle wrote:
> On 10/4/12 3:36 PM, Khem Raj wrote:
>>
>> On Thu, Oct 4, 2012 at 11:02 AM, Mark Hatle
>> wrote:
>>>
>>> We have an issue where we'd like to have an alternative toolchain
>>> (assembler, linker, compiler) available for our customers to selectivel
On Thu, 2012-10-04 at 16:00 -0500, Mark Hatle wrote:
> This is only one runtime. You have multiple compilers all capable of
> producing
> software compatible with the same ABI. The default (oe) compiler is used,
> unless otherwise configured. The alternative(s) are used for optimization of
>
On 10/4/12 4:16 PM, Phil Blundell wrote:
On Thu, 2012-10-04 at 16:00 -0500, Mark Hatle wrote:
This is only one runtime. You have multiple compilers all capable of producing
software compatible with the same ABI. The default (oe) compiler is used,
unless otherwise configured. The alternative(s
On Thursday 04 October 2012 09:52:45 Khem Raj wrote:
> On Thu, Oct 4, 2012 at 5:27 AM, Martin Jansa wrote:
> > The same does apply to bitbake-diffsigs now after IIRC this patch
> > http://git.openembedded.org/bitbake/commit/?id=cc70181659c07e04c205e178328
> > 46acf1ff31d28 before that I could use
some packages use M4 variable from environment and sometimes
its hardcoded to /usr/bin/m4 if not found in environment. Lets
define it such that it is picked from path
Signed-off-by: Khem Raj
---
meta/classes/toolchain-scripts.bbclass |1 +
1 file changed, 1 insertion(+)
diff --git a/meta/cl
Op 4 okt. 2012, om 04:46 heeft Franklin S. Cooper Jr
het volgende geschreven:
> From: Richard Purdie
>
> There are only a couple of helper utilities within gconf that need gtk+ as a
> dependency and those are unused and pretty useless. We might as well drop
> the dependency on gtk and allow m
On 10/04/2012 10:16 PM, Andreas Müller wrote:
> On Thu, Oct 4, 2012 at 1:37 AM, Andreas Müller
> wrote:
>> On Wed, Sep 26, 2012 at 9:41 AM, Andreas Müller
>> wrote:
>>> On Wed, Sep 26, 2012 at 9:09 AM, Laurentiu Palcu
>>> wrote:
On 09/20/2012 07:12 PM, Andreas Müller wrote:
46 matches
Mail list logo
