From: Jackie Huang
Signed-off-by: Jackie Huang
---
meta/recipes-devtools/dmidecode/dmidecode_2.12.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-devtools/dmidecode/dmidecode_2.12.bb
b/meta/recipes-devtools/dmidecode/dmidecode_2.12.bb
index 3e3a350..b5151b8
From: Denys Dmytriyenko
Signed-off-by: Denys Dmytriyenko
---
v2 - rebase on top of fw-utils combining patch from Otavio
.../0001-tools-env-fix-build-error.patch | 36 ++
...utils_2014.07.bb => u-boot-fw-utils_2015.01.bb} | 21 +++--
...kimage_2014.07.bb =>
Note, I tested this by building a world build for MACHINE qemumips64 with
DEFAULTTUNE set to mips64-n32.
It and the other recent patches I've sent are available at
git://git.yoctoproject.org/poky-contrib mhatle/oe-core
--Mark
On 1/23/15 3:20 PM, Mark Hatle wrote:
> [YOCTO #7230]
>
> In certain
[YOCTO #7230]
In certain system configurations TRANSLATED_TARGET_ARCH will not
expand in the right order for gcc-cross-candian-mips64n32 to be
generated properly.
This will cause SDKs to fail to generate properly.
Changing the global definition of TRANSLATED_TARGET_ARCH always
expands the ABIEXT
On Thu, Jan 22, 2015 at 10:55:07PM -0500, Denys Dmytriyenko wrote:
> On Thu, Jan 22, 2015 at 11:18:27PM -0200, Otavio Salvador wrote:
> > This merges the u-boot-fw-utils-cross into the main u-boot-fw-utils
> > recipe and fixes the build failure seen since 2014.07 update.
>
> So, the actual fix is
On 23 January 2015 at 13:05, Dan McGregor wrote:
> From: Dan McGregor
>
> The sanitizer runtime library is dual-licensed under the NCSA
> and MIT licenses.
>
> Also make nativesdk-gcc-sanitizers use SDKGCCVERSION by default
> instead of GCCVERSION
>
> Signed-off-by: Dan McGregor
> ---
> meta/co
From: Dan McGregor
The sanitizer runtime library is dual-licensed under the NCSA
and MIT licenses.
Also make nativesdk-gcc-sanitizers use SDKGCCVERSION by default
instead of GCCVERSION
Signed-off-by: Dan McGregor
---
meta/conf/distro/include/tcmode-default.inc | 2 +-
meta/recipes-devtools/g
On Friday 23 January 2015 09:04:28 akuster808 wrote:
> On 01/23/2015 04:47 AM, Otavio Salvador wrote:
> > On Fri, Jan 23, 2015 at 12:12 AM, Robert Yang
wrote:
> >> We have several GPLv2 recipes such as m4-native_1.4.9.bb, while we also
> >> have GPLv3's m4-native_1.4.17.bb, I think that we can re
On 01/23/2015 04:47 AM, Otavio Salvador wrote:
On Fri, Jan 23, 2015 at 12:12 AM, Robert Yang wrote:
We have several GPLv2 recipes such as m4-native_1.4.9.bb, while we also
have GPLv3's m4-native_1.4.17.bb, I think that we can remove
m4-native_1.4.9.bb if the target m4_1.4.9.bb builds well ?
On Fri, Jan 23, 2015 at 2:24 PM, Christopher Larson wrote:
>
> On Fri, Jan 23, 2015 at 5:47 AM, Otavio Salvador
> wrote:
>>
>> On Fri, Jan 23, 2015 at 12:12 AM, Robert Yang
>> wrote:
>> > We have several GPLv2 recipes such as m4-native_1.4.9.bb, while we also
>> > have GPLv3's m4-native_1.4.17.b
On Fri, Jan 23, 2015 at 5:47 AM, Otavio Salvador
wrote:
> On Fri, Jan 23, 2015 at 12:12 AM, Robert Yang
> wrote:
> > We have several GPLv2 recipes such as m4-native_1.4.9.bb, while we also
> > have GPLv3's m4-native_1.4.17.bb, I think that we can remove
> > m4-native_1.4.9.bb if the target m4_1.
Hi Fabien,
On Thursday 22 January 2015 15:08:35 Fabien Proriol wrote:
> ---
> meta/recipes-qt/qt4/qt4-x11-free.inc | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/meta/recipes-qt/qt4/qt4-x11-free.inc
> b/meta/recipes-qt/qt4/qt4-x11-free.inc index 3b1e0fe..d1b88ea 10064
On 22 January 2015 at 22:02, Peter Seebach
wrote:
> > ping.
>
> My memory (which is notoriously unreliable) was that we'd merged these
> changes, but it may be we did thim in our local tree.
>
Yeah they're not in master - I think I merged and then backed them out
locally to bisect some breakage.
The reason for the patch series is the observation that swig from
meta-openembedded requires pcre-config to be installed on the host
system, even though it does not actually get used.
While that can be fixed in the swig recipe, investigating the situation
led to the conclusion that the current han
The purpose of binconfig-disabled is to manipulate config scripts such that
using them causes errors. But that only works when the modified config script
really gets installed in the sysroot. That is not the case with the staging
code in binconfig.bbclass.
Only patched config files get staged. For
Returning a non-zero exit code is not enough to cause errors when configure
scripts call the patched config scripts: for example, swig's configure script
uses PCRE_LIBS=`$PCRE_CONFIG --libs` and does not abort on errors. Using empty
output may then succeed, for example when the required library is
On Fri, Jan 23, 2015 at 12:12 AM, Robert Yang wrote:
> We have several GPLv2 recipes such as m4-native_1.4.9.bb, while we also
> have GPLv3's m4-native_1.4.17.bb, I think that we can remove
> m4-native_1.4.9.bb if the target m4_1.4.9.bb builds well ?
>
> I'd like to remove it because we don't buil
On 22 January 2015 at 16:34, Martin Jansa wrote:
> and the .inc file is used in much more recipes (which don't need libx11 to
> build)
>
You can't be arguing that it's alright to build the X11 drivers when the
X11 distro feature is disabled? I thought the end goal was to cover all
X11 recipes,
On 23 January 2015 at 02:23, Peter Seebach
wrote:
> pseudo 1.6.4 fixes a silly configure bug introduced with
> 1.6.3.
>
Thanks for the quick fix Peter :)
Ross
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists
Thanks Ross, I will send this patch to meta-xfce later
2015-01-23 18:48 GMT+08:00 Burton, Ross :
>
> On 23 January 2015 at 07:55, Yong Li wrote:
>
>> meta/recipes-graphics/images/core-image-xfce.bb | 16
>>
>
> This doesn't belong in oe-core, add it to meta-xfce instead.
>
> Ros
On 23 January 2015 at 07:55, Yong Li wrote:
> meta/recipes-graphics/images/core-image-xfce.bb | 16
>
This doesn't belong in oe-core, add it to meta-xfce instead.
Ross
--
___
Openembedded-core mailing list
Openembedded-core@lists.ope
21 matches
Mail list logo
