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.gita=commit;h=97a3ea712003e8d48dc68c282e656591f39d2d1a
Author:
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
|
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:
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:
removed also entry from
meta/recipes-gnome/packagegroups/packagegroup-sdk-gmae.inc
Signed-off-by: Andrei Dinu andrei.adrianx.d...@intel.com
---
meta/recipes-connectivity/gypsy/files/fixups.patch | 21 -
meta/recipes-connectivity/gypsy/gypsy.inc | 15
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
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 ross.bur...@intel.com
---
meta/recipes-sato/shutdown-desktop/shutdown-desktop.bb |5 -
1 file changed, 4 insertions(+), 1
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
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 often
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:
-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 have
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 see if the
-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,
* 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
* 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
* probably copypaste error from tune-cortexm3.conf
commit 789dcb8e68a2ab9784ac10ab36815010c61af2fc
Author: Richard Purdie richard.pur...@linuxfoundation.org
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
* 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:
* 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
* 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
* 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
-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 the
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
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 toolchain
On Thu, Oct 4, 2012 at 1:02 PM, Mark Hatle mark.ha...@windriver.com 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
On Thu, Oct 4, 2012 at 1:37 AM, Andreas Müller
schnitzelt...@googlemail.com wrote:
On Wed, Sep 26, 2012 at 9:41 AM, Andreas Müller
schnitzelt...@googlemail.com wrote:
On Wed, Sep 26, 2012 at 9:09 AM, Laurentiu Palcu
laurentiu.pa...@intel.com wrote:
On 09/20/2012 07:12 PM, Andreas Müller
On 10/4/12 2:03 PM, McClintock Matthew-B29882 wrote:
On Thu, Oct 4, 2012 at 1:02 PM, Mark Hatle mark.ha...@windriver.com 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
On Thu, Oct 4, 2012 at 11:02 AM, Mark Hatle mark.ha...@windriver.com 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
On 10/4/12 3:36 PM, Khem Raj wrote:
On Thu, Oct 4, 2012 at 11:02 AM, Mark Hatle mark.ha...@windriver.com 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
On Thu, Oct 4, 2012 at 2:00 PM, Mark Hatle mark.ha...@windriver.com wrote:
On 10/4/12 3:36 PM, Khem Raj wrote:
On Thu, Oct 4, 2012 at 11:02 AM, Mark Hatle mark.ha...@windriver.com
wrote:
We have an issue where we'd like to have an alternative toolchain
(assembler, linker, compiler)
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
On Thursday 04 October 2012 09:52:45 Khem Raj wrote:
On Thu, Oct 4, 2012 at 5:27 AM, Martin Jansa martin.ja...@gmail.com wrote:
The same does apply to bitbake-diffsigs now after IIRC this patch
http://git.openembedded.org/bitbake/commit/?id=cc70181659c07e04c205e178328
46acf1ff31d28 before
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 raj.k...@gmail.com
---
meta/classes/toolchain-scripts.bbclass |1 +
1 file changed, 1 insertion(+)
36 matches
Mail list logo
