On Thu, 2011-07-28 at 23:08 -0700, Khem Raj wrote:
> I know SHR uses armv4t but I dont know of armv4 usecases. May be we
> could may armv4t as oldest supported arm arch and leave armv4 out.
There are definitely still folks using OE with SA1100 machines. I think
armv4 support should be kept unles
On 07/28/2011 11:08 PM, Khem Raj wrote:
On 07/27/2011 06:33 AM, Richard Purdie wrote:
On Wed, 2011-07-27 at 13:17 +0100, Phil Blundell wrote:
On Tue, 2011-07-26 at 13:44 +0100, Richard Purdie wrote:
+TARGET_FPU = "${@d.getVar('ARMPKGSFX_FPU', True).strip('-') or
'soft'}"
This seems a bit bac
Signed-off-by: Martin Jansa
---
meta/recipes-support/libfm/libfm_0.1.14.bb |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/meta/recipes-support/libfm/libfm_0.1.14.bb
b/meta/recipes-support/libfm/libfm_0.1.14.bb
index 5c7e95c..38f1d73 100644
--- a/meta/recipes-support/li
Signed-off-by: Martin Jansa
---
meta/recipes-extended/polkit/polkit_0.101.bb |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/meta/recipes-extended/polkit/polkit_0.101.bb
b/meta/recipes-extended/polkit/polkit_0.101.bb
index 64cca10..f3a6f1c 100644
--- a/meta/recipes-exte
On 07/27/2011 10:19 AM, Mark Hatle wrote:
On 7/27/11 10:25 AM, Phil Blundell wrote:
On Wed, 2011-07-27 at 09:58 -0500, Mark Hatle wrote:
For the tune names.. armv5 means I want classic ARM instructions, while armv5t
means I was thumb instructions.
So armv5 and armv5t are distinct in the conte
On 07/27/2011 08:25 AM, Phil Blundell wrote:
On Wed, 2011-07-27 at 09:58 -0500, Mark Hatle wrote:
For the tune names.. armv5 means I want classic ARM instructions, while armv5t
means I was thumb instructions.
So armv5 and armv5t are distinct in the contents of the tunings.
Ah, I see. Does t
On 07/27/2011 08:08 AM, Phil Blundell wrote:
On Wed, 2011-07-27 at 17:01 +0200, Koen Kooi wrote:
the s3c6410 is arm1176 which should support T2. Having said that, I'm not sure
if that actually works since T2 was broken in silicon for early cortex a8
revisions.
What makes you think that ARM1
On 07/27/2011 07:58 AM, Mark Hatle wrote:
For the tune names.. armv5 means I want classic ARM instructions, while armv5t
means I was thumb instructions.
So armv5 and armv5t are distinct in the contents of the tunings.
fwiw its confusing since armv5t will be confused with arm architecture
con
On 07/27/2011 07:49 AM, Mark Hatle wrote:
On 7/27/11 9:33 AM, Koen Kooi wrote:
Op 27 jul. 2011, om 16:27 heeft Mark Hatle het volgende geschreven:
On 7/27/11 8:33 AM, Richard Purdie wrote:
On Wed, 2011-07-27 at 13:17 +0100, Phil Blundell wrote:
On Tue, 2011-07-26 at 13:44 +0100, Richard Pur
On 07/27/2011 07:44 AM, Phil Blundell wrote:
On Wed, 2011-07-27 at 09:27 -0500, Mark Hatle wrote:
On 7/27/11 8:33 AM, Richard Purdie wrote:
On Wed, 2011-07-27 at 13:17 +0100, Phil Blundell wrote:
On Tue, 2011-07-26 at 13:44 +0100, Richard Purdie wrote:
+TARGET_FPU = "${@d.getVar('ARMPKGSFX_FP
On 07/27/2011 06:33 AM, Richard Purdie wrote:
On Wed, 2011-07-27 at 13:17 +0100, Phil Blundell wrote:
On Tue, 2011-07-26 at 13:44 +0100, Richard Purdie wrote:
+TARGET_FPU = "${@d.getVar('ARMPKGSFX_FPU', True).strip('-') or 'soft'}"
This seems a bit backwards. Shouldn't TARGET_FPU be the prim
Hi Mark,Richard
currently qemuarm does not build due to this patch forcing thumb mode
as default for all 't' architectures which could have worked if recipes
using ARM_INSTRUCTION_SET="arm" in them were somehow excluded from
building in thumb mode. Further comments are inline.
On 07/26/2011 0
From: Kang Kai
Update distro tracking fields of libnewt mailx slang and alsa-tools.
Update mailx licence, slang homepage and alsa-tools.
Signed-off-by: Kang Kai
---
.../conf/distro/include/distro_tracking_fields.inc | 28 ---
meta/recipes-extended/mailx/mailx_12.5.bb
From: Kang Kai
Hi Saul,
v3 update the mailx license.
I update the libnewt SRC_URI and checksum. Because the bb file is libnewt and
the source
file is newt, so I write the SRC_URI with newt-${PV}.
Update the distro tracking fields of mailx slang libnewt and alsa-tools.
Thank you!
The follo
From: Kang Kai
Update libnewt to 0.52.13, and remove include-without-python.patch
because it has been merged.
Update SRC_URI and add SRC_URI checksum.
Signed-off-by: Kang Kai
---
.../newt/files/include-without-python.patch| 73
.../{libnewt_0.52.12.bb => libnewt_
On 07/28/2011 06:57 PM, Kumar Gala wrote:
On Jul 28, 2011, at 7:41 PM, Saul Wold wrote:
On 07/28/2011 05:07 PM, Kumar Gala wrote:
Its possible we get duplications if we explicity add TUNE_PKGARCH to
PACKAGE_ARCHS so instead just add a sanity check to verify it.
Signed-off-by: Kumar Gala
---
From: Kang Kai
update distro tracking fields of libnewt mailx slang and alsa-tools.
Signed-off-by: Kang Kai
---
.../conf/distro/include/distro_tracking_fields.inc | 28 ---
meta/recipes-extended/slang/slang_2.2.4.bb |1 +
.../recipes-multimedia/alsa/alsa-tools_1.0
From: Kang Kai
Update libnewt to 0.52.13, and remove include-without-python.patch
because it has been merged.
Update SRC_URI and add SRC_URI checksum.
Signed-off-by: Kang Kai
---
.../newt/files/include-without-python.patch| 73
.../{libnewt_0.52.12.bb => libnewt_
From: Kang Kai
Hi Saul,
I update the libnewt SRC_URI and checksum. Because the bb file is libnewt and
the source
file is newt, so I write the SRC_URI with newt-${PV}.
Update the distro tracking fields of mailx slang libnewt and alsa-tools.
Because the mailx license file COPYING has lots of
On Jul 28, 2011, at 7:41 PM, Saul Wold wrote:
> On 07/28/2011 05:07 PM, Kumar Gala wrote:
>> Its possible we get duplications if we explicity add TUNE_PKGARCH to
>> PACKAGE_ARCHS so instead just add a sanity check to verify it.
>>
>> Signed-off-by: Kumar Gala
>> ---
>> meta/classes/sanity.bbcla
On 07/28/2011 06:15 PM, Mei, Lei wrote:
>
>
>> -Original Message-
>> From: openembedded-core-boun...@lists.openembedded.org
>> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
>> Tom Rini
>> Sent: Thursday, July 28, 2011 11:09 PM
>> To: openembedded-core@lists.openem
>-Original Message-
>From: openembedded-core-boun...@lists.openembedded.org
>[mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
>Tom Rini
>Sent: Thursday, July 28, 2011 11:09 PM
>To: openembedded-core@lists.openembedded.org
>Subject: Re: [OE-core] [PATCH 1/1] python-na
On 07/28/2011 05:07 PM, Kumar Gala wrote:
Its possible we get duplications if we explicity add TUNE_PKGARCH to
PACKAGE_ARCHS so instead just add a sanity check to verify it.
Signed-off-by: Kumar Gala
---
meta/classes/sanity.bbclass | 10 +-
1 files changed, 9 insertions(+), 1 deleti
Add some uniformity to the naming scheme and reduce a bit of redudancy.
Names are now back to: ppc603e, ppce300c2, ppce500, ppce500mc,
ppce500v2.
On 64-bit we'll have something like ppc64e5500.
Signed-off-by: Kumar Gala
---
meta/conf/machine/include/powerpc/arch-powerpc.inc |5 +++--
meta/
Its possible we get duplications if we explicity add TUNE_PKGARCH to
PACKAGE_ARCHS so instead just add a sanity check to verify it.
Signed-off-by: Kumar Gala
---
meta/classes/sanity.bbclass | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/meta/classes/sanity.bbcl
On Jul 28, 2011, at 3:46 PM, Kumar Gala wrote:
> Recent changes to how TUNE_PKGARCH is composed means it might not be in
> the PACKAGE_EXTRA_ARCHS_tune list. Rather than having to update all
> such lists we just add TUNE_PKGARCH to PACKAGE_ARCHS.
>
> An example, for ppc603e TUNE_PKGARCH is now:
From: Malcolm Crossley
Signed-off-by: Malcolm Crossley
Signed-off-by: Kumar Gala
---
meta/conf/machine/include/tune-ppce500mc.inc |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/meta/conf/machine/include/tune-ppce500mc.inc
b/meta/conf/machine/include/tune-ppce500mc.i
We should be able to get away with just one include to handle all
arch-powerpc needs. Also update comments about the various choices
between 32-bit/64-bit and hard/soft floating point.
Signed-off-by: Kumar Gala
---
meta/conf/machine/include/powerpc/arch-powerpc.inc | 14 ++
.../ma
Its more likely that we explicitly set soft-floating point support for a
given target than hard. So use 'fpu-soft' in TUNE_FEATURES rather than
'fpu-hard' to determine setting 'nf' (no-float) in PPCPKGSFX_FPU.
Signed-off-by: Kumar Gala
---
meta/conf/machine/include/powerpc/arch-powerpc.inc |
When figuring out how to set TUNE_CCARGS we should look for 'm64' not
'n64' in TUNE_FEATURES.
Signed-off-by: Kumar Gala
---
.../machine/include/powerpc/arch-powerpc64.inc |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/meta/conf/machine/include/powerpc/arch-powerpc6
All 64-bit PPC processors support hard-float so no need to support
soft-float.
Signed-off-by: Kumar Gala
---
.../machine/include/powerpc/arch-powerpc64.inc |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/meta/conf/machine/include/powerpc/arch-powerpc64.inc
b/me
Just mimic what we do on powerpc (32-bit).
Signed-off-by: Kumar Gala
---
meta/classes/image-mklibs.bbclass |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/meta/classes/image-mklibs.bbclass
b/meta/classes/image-mklibs.bbclass
index 9f5a4ea..d5e8ab7 100644
--- a/meta/cla
Recent changes to how TUNE_PKGARCH is composed means it might not be in
the PACKAGE_EXTRA_ARCHS_tune list. Rather than having to update all
such lists we just add TUNE_PKGARCH to PACKAGE_ARCHS.
An example, for ppc603e TUNE_PKGARCH is now:
powerpcppc603e
However, PACKAGE_EXTRA_ARCHS_tune
On Jul 28, 2011, at 2:04 PM, Phil Blundell wrote:
> On Thu, 2011-07-28 at 20:54 +0200, Martin Jansa wrote:
>> this change causes ERROR here with nokia900:
>> Error, the PACKAGE_ARCHS variable contains duplicates. The following archs
>> are listed more than once: armv7a-vfp-neon
>
> It isn't tot
Hi Kumar,
I'm just debugging the same issue.
It's caused by folder for the target specific packages being mis-named
"powerpcppc603e" instead of "ppc603e" which the rpm package bbclass is
expecting.
I haven't figured out why this is happening yet but I have a workaround
which is to move ${BUILD_
On Thu, 2011-07-28 at 20:54 +0200, Martin Jansa wrote:
> this change causes ERROR here with nokia900:
> Error, the PACKAGE_ARCHS variable contains duplicates. The following archs
> are listed more than once: armv7a-vfp-neon
It isn't totally obvious to me that it needs to be an error for
PACKAGE_A
On Thu, Jul 28, 2011 at 01:43:45PM -0500, Kumar Gala wrote:
>
> On Jul 28, 2011, at 11:05 AM, Saul Wold wrote:
>
> > On 07/28/2011 08:45 AM, Kumar Gala wrote:
> >> I think I know the cause, let me dig up the change that is related. What
> >> bit is looking for just ppc603e?
> >>
> > This might
The do_archgen step creates a script that utilizes the variable name
${ARCH}. However, we also utilize and define ${ARCH} so instead of
having the following in the script:
COMPAT_WITH="${ARCH},${COMPAT} $COMPAT_WITH"
We get something like:
COMPAT_WITH="powerpc,${COMPAT} $COMPAT_
On Jul 28, 2011, at 11:05 AM, Saul Wold wrote:
> On 07/28/2011 08:45 AM, Kumar Gala wrote:
>> I think I know the cause, let me dig up the change that is related. What
>> bit is looking for just ppc603e?
>>
> This might also be related to the PACKAGE_EXTRA_ARCHS issue, please try the
> patch t
On Thu, Jul 28, 2011 at 09:54:06AM +0100, Phil Blundell wrote:
> On Thu, 2011-07-28 at 09:24 +0200, Martin Jansa wrote:
> > Mark is right that if we have PACKAGE_ARCH = "armv4t" and we force
> > no-thumb with ARM_INSTRUCTION_SET = "arm" then PACKAGE_ARCH should be
> > switched to "armv4" only to in
PACKAGE_EXTRA_ARCHS_tune-armv5eb needs to be defined in terms of
the non-e with the same endianness, i.e. PACKAGE_EXTRA_ARCHS_tune-armv5b
not PACKAGE_EXTRA_ARCHS_tune-armv5, otherwise PACKAGE_EXTRA_ARCHS will
end up containing a semi-random mixture of endiannesses and disaster
will ensue. Likewi
On Thu, Jul 28, 2011 at 10:46 AM, Koen Kooi wrote:
>
> Op 28 jul. 2011, om 16:43 heeft Ben Gardiner het volgende geschreven:
>
>> Hi Koen,
>>
>> On Thu, Jul 28, 2011 at 10:36 AM, Koen Kooi
>> wrote:
>>>
>>> Op 28 jul. 2011, om 16:29 heeft Ben Gardiner het volgende geschreven:
>>>
On Thu, Ju
-Original Message-
From: openembedded-core-boun...@lists.openembedded.org
[mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of Lianhao
Lu
Sent: Thursday, July 28, 2011 4:24 AM
To: openembedded-core@lists.openembedded.org
Subject: [OE-core] [PATCH 0/1] Fix bug #1299 for
-Original Message-
From: openembedded-core-boun...@lists.openembedded.org
[mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of Lianhao
Lu
Sent: Thursday, July 28, 2011 4:24 AM
To: openembedded-core@lists.openembedded.org
Subject: [OE-core] [PATCH 1/1] meta-environment:
Hi Koen,
On Thu, Jul 28, 2011 at 10:36 AM, Koen Kooi wrote:
>
> Op 28 jul. 2011, om 16:29 heeft Ben Gardiner het volgende geschreven:
>
>> On Thu, Jul 28, 2011 at 10:24 AM, Frans Meulenbroeks
>> wrote:
>>>
>>>
>>> 2011/7/28 Ben Gardiner
Well, I would not submit _this_ patch for p
I have, it doesn't help. I believe its partly due to how we are appending to
TUNE_PKGARCH, but what's not clear to me is what case is failing and looking
for just ppc603e instead of powerpcppc603e
- k
On Jul 28, 2011, at 11:05 AM, Saul Wold wrote:
> On 07/28/2011 08:45 AM, Kumar Gala wrote:
>
On 07/28/2011 08:45 AM, Kumar Gala wrote:
I think I know the cause, let me dig up the change that is related. What bit
is looking for just ppc603e?
This might also be related to the PACKAGE_EXTRA_ARCHS issue, please try
the patch that Koen posted.
Thanks
Sau!
- k
On Jul 28, 2011,
On Thursday 28 July 2011 16:40:34 Kumar Gala wrote:
> On Jul 28, 2011, at 10:09 AM, Tom Rini wrote:
> > On 07/28/2011 06:10 AM, Kumar Gala wrote:
> >> If a SOCKS5 gateway is needed for a proxy access like git it might also
> >> require authentication to the proxy via a password and username. Addin
On Jul 28, 2011, at 10:15 AM, Tom Rini wrote:
> On 07/28/2011 07:17 AM, Phil Blundell wrote:
>> On Thu, 2011-07-28 at 09:15 -0500, Kumar Gala wrote:
>>> With recent multilib changes for a pure 64-bit target (no multilib) should
>>> things be in /lib or /lib64?
>>
>> They should be in ${base_lib
I think I know the cause, let me dig up the change that is related. What bit
is looking for just ppc603e?
- k
On Jul 28, 2011, at 10:42 AM, Crossley, Malcolm (GE Intelligent Platforms)
wrote:
> Hi Kumar,
>
> I'm just debugging the same issue.
>
> It's caused by folder for the target specifi
On Jul 28, 2011, at 10:09 AM, Tom Rini wrote:
> On 07/28/2011 06:10 AM, Kumar Gala wrote:
>> If a SOCKS5 gateway is needed for a proxy access like git it might also
>> require authentication to the proxy via a password and username. Adding
>> SOCKS5_USER & SOCKS5_PASSWD to BB_ENV_EXTRAWHITE allo
On 07/28/2011 02:41 AM, Kang Kai wrote:
From: Kang Kai
update libnewt to 0.52.13, and remove include-without-python.patch
because it has been merged.
Signed-off-by: Kang Kai
---
.../newt/files/include-without-python.patch| 73
.../{libnewt_0.52.12.bb => libnew
Otherwise the test in TUNE_CCARGS will never match.
Signed-off-by: Phil Blundell
---
meta/conf/machine/include/tune-cortexm1.inc |2 +-
meta/conf/machine/include/tune-cortexm3.inc |2 +-
meta/conf/machine/include/tune-cortexr4.inc |3 +--
3 files changed, 3 insertions(+), 4 deletions
On 07/28/2011 07:17 AM, Phil Blundell wrote:
> On Thu, 2011-07-28 at 09:15 -0500, Kumar Gala wrote:
>> With recent multilib changes for a pure 64-bit target (no multilib) should
>> things be in /lib or /lib64?
>
> They should be in ${base_libdir}. Whether that's /lib or /lib64 is a
> DISTRO choi
On 07/28/2011 06:10 AM, Kumar Gala wrote:
> If a SOCKS5 gateway is needed for a proxy access like git it might also
> require authentication to the proxy via a password and username. Adding
> SOCKS5_USER & SOCKS5_PASSWD to BB_ENV_EXTRAWHITE allow for automation
> of the authentication request to o
On 07/28/2011 12:20 AM, Mei Lei wrote:
> The CC variable sometimes add option information after compiler name, but
> python can't get the real compiler name if those information added.
> Fix this issue by dropping the option information when finding compiler name.
>
> Signed-off-by: Mei Lei
I t
On Jul 28, 2011, at 9:35 AM, Lu, Lianhao wrote:
> Richard Purdie wrote on 2011-07-27:
>> Since we now handle GLIBC_DYNAMIC_LINKER in gcc-configure-common.inc:
>>
>> 's#\(GLIBC_DYNAMIC_LINKER[^ ]*\)\( *"/lib.*\)#\1 SYSTEMLIBS_DIR\2#'
>>
>
> It seems to me that this patch may not be removed. The
On Thu, Jul 28, 2011 at 10:24 AM, Frans Meulenbroeks
wrote:
>
>
> 2011/7/28 Ben Gardiner
>>
>>
>> Well, I would not submit _this_ patch for pull-request. I was hoping
>> to get this version of raptor included and then submit a pull-request
>> for a cherry-pick of the patch to add libxml2 to DEPEN
Op 28 jul. 2011, om 16:43 heeft Ben Gardiner het volgende geschreven:
> Hi Koen,
>
> On Thu, Jul 28, 2011 at 10:36 AM, Koen Kooi
> wrote:
>>
>> Op 28 jul. 2011, om 16:29 heeft Ben Gardiner het volgende geschreven:
>>
>>> On Thu, Jul 28, 2011 at 10:24 AM, Frans Meulenbroeks
>>> wrote:
Op 28 jul. 2011, om 16:29 heeft Ben Gardiner het volgende geschreven:
> On Thu, Jul 28, 2011 at 10:24 AM, Frans Meulenbroeks
> wrote:
>>
>>
>> 2011/7/28 Ben Gardiner
>>>
>>>
>>> Well, I would not submit _this_ patch for pull-request. I was hoping
>>> to get this version of raptor included a
Richard Purdie wrote on 2011-07-27:
> Since we now handle GLIBC_DYNAMIC_LINKER in gcc-configure-common.inc:
>
> 's#\(GLIBC_DYNAMIC_LINKER[^ ]*\)\( *"/lib.*\)#\1 SYSTEMLIBS_DIR\2#'
>
It seems to me that this patch may not be removed. The above code in
gcc-configure-common.inc said it only useful
Hi Koen, Frans,
On Thu, Jul 28, 2011 at 6:48 AM, Koen Kooi wrote:
>
> Op 28 jul. 2011, om 05:38 heeft Ben Gardiner het volgende geschreven:
>
>> Signed-off-by: Frans Meulenbroeks
>> Signed-off-by: Ben Gardiner
>> Signed-off-by: Tom Rini
>>
>> This recipe is a port of recipes/raptor/raptor_1.4.
On Jul 28, 2011, at 9:18 AM, Paul Eggleton wrote:
> Because of the way BitBake handles ??= under certain circumstances, this
> default setting ends up stepping all over the real setting from the arch
> include file. Since virtually all arch include files or tune files define
> a real value for th
Anyone got any ideas about the following:
| ERROR: Function 'do_rootfs' failed (see
/local/home/galak/git/poky/build/tmp/work/mpc8315e_rdb-poky-linux/core-image-minimal-1.0-r0/temp/log.do_rootfs.19834
for fu
rther information)
| Generating solve db for
/local/home/galak/git/poky/build/tmp/deplo
2011/7/28 Ben Gardiner
>
>
> Well, I would not submit _this_ patch for pull-request. I was hoping
> to get this version of raptor included and then submit a pull-request
> for a cherry-pick of the patch to add libxml2 to DEPENDS.
>
Ah, missed that you also added libxml2.
Not sure about the polic
On Thu, 2011-07-28 at 09:15 -0500, Kumar Gala wrote:
> With recent multilib changes for a pure 64-bit target (no multilib) should
> things be in /lib or /lib64?
They should be in ${base_libdir}. Whether that's /lib or /lib64 is a
DISTRO choice I suppose.
p.
__
Because of the way BitBake handles ??= under certain circumstances, this
default setting ends up stepping all over the real setting from the arch
include file. Since virtually all arch include files or tune files define
a real value for this we shouldn't need to have a default (or it needs to
be do
Here's a fix as discussed for the PACKAGE_EXTRA_ARCHS issue since the
tune file changes. It may not be the proper fix but it does at least it
makes the value of this variable correct again.
The following changes since commit 1fe892ab6876c405599c79657221a8b4675b6ecf:
Update TERMCMD message to al
With recent multilib changes for a pure 64-bit target (no multilib) should
things be in /lib or /lib64?
- k
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Hi Frans,
On Thu, Jul 28, 2011 at 9:52 AM, Frans Meulenbroeks
wrote:
>
>
> 2011/7/28 Ben Gardiner
>>
>> Hi Koen, Frans,
>>
>> On Thu, Jul 28, 2011 at 6:48 AM, Koen Kooi
>> wrote:
>> >
>> > Op 28 jul. 2011, om 05:38 heeft Ben Gardiner het volgende geschreven:
>> >
>> >> Signed-off-by: Frans Meul
2011/7/28 Ben Gardiner
> Hi Koen, Frans,
>
> On Thu, Jul 28, 2011 at 6:48 AM, Koen Kooi
> wrote:
> >
> > Op 28 jul. 2011, om 05:38 heeft Ben Gardiner het volgende geschreven:
> >
> >> Signed-off-by: Frans Meulenbroeks
> >> Signed-off-by: Ben Gardiner
> >> Signed-off-by: Tom Rini
> >>
> >> Thi
On Thursday 28 July 2011 14:15:55 Koen Kooi wrote:
> Is that a hook in git or the combo script?
The combo script. The sample config file has an example of how to configure one
(as well as an example hook script that adds origin commit IDs).
> With my distro maintainer hat on, I wouldn't use a c
Op 28 jul. 2011, om 15:00 heeft Paul Eggleton het volgende geschreven:
> On Thursday 28 July 2011 13:11:00 Koen Kooi wrote:
>> I've been playing with this script and I have a few remarks about it. First
>> the ones that aren't the fault of the script:
>>
>> 1) overlapping files like .gitignore b
From: Zhai Edwin
Signed-off-by: Zhai Edwin
---
.../{libassuan_2.0.1.bb => libassuan_2.0.2.bb} |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
rename meta/recipes-support/libassuan/{libassuan_2.0.1.bb =>
libassuan_2.0.2.bb} (82%)
diff --git a/meta/recipes-support/libassuan/l
On Thursday 28 July 2011 13:11:00 Koen Kooi wrote:
> I've been playing with this script and I have a few remarks about it. First
> the ones that aren't the fault of the script:
>
> 1) overlapping files like .gitignore breaks the script
This can be a problem, yes. However if you know about these s
If a SOCKS5 gateway is needed for a proxy access like git it might also
require authentication to the proxy via a password and username. Adding
SOCKS5_USER & SOCKS5_PASSWD to BB_ENV_EXTRAWHITE allow for automation
of the authentication request to occur when something like a git fetch
is going thro
From: Zhai Edwin
Signed-off-by: Zhai Edwin
---
.../{parted-2.3 => parted-3.0}/no_check.patch |0
.../{parted-2.3 => parted-3.0}/syscalls.patch |0
.../parted/{parted_2.3.bb => parted_3.0.bb}|4 ++--
3 files changed, 2 insertions(+), 2 deletions(-)
rename meta/reci
From: Zhai Edwin
Signed-off-by: Zhai Edwin
---
.../disable_gpgconf_check.patch|0
.../gpgme/{gpgme_1.3.0.bb => gpgme_1.3.1.bb} |8
2 files changed, 4 insertions(+), 4 deletions(-)
rename meta/recipes-support/gpgme/{gpgme-1.3.0 =>
gpgme-1.3.1}/disable
From: Zhai Edwin
Signed-off-by: Zhai Edwin
---
...libsoup-2.4_2.34.1.bb => libsoup-2.4_2.34.2.bb} |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
rename meta/recipes-support/libsoup/{libsoup-2.4_2.34.1.bb =>
libsoup-2.4_2.34.2.bb} (76%)
diff --git a/meta/recipes-support/libsoup
From: Zhai Edwin
Remove buildconf_fix.patch as already in upstream.
Signed-off-by: Zhai Edwin
---
meta/recipes-support/apr/apr/buildconf_fix.patch | 27
.../apr/{apr_1.4.2.bb => apr_1.4.5.bb} |9 +++---
2 files changed, 5 insertions(+), 31 deletions(-)
From: Zhai Edwin
Signed-off-by: Zhai Edwin
---
.../apr/{apr-util_1.3.10.bb => apr-util_1.3.12.bb} |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
rename meta/recipes-support/apr/{apr-util_1.3.10.bb => apr-util_1.3.12.bb}
(74%)
diff --git a/meta/recipes-support/apr/apr-util_
From: Zhai Edwin
Signed-off-by: Zhai Edwin
---
.../{lighttpd_1.4.28.bb => lighttpd_1.4.29.bb} |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
rename meta/recipes-extended/lighttpd/{lighttpd_1.4.28.bb =>
lighttpd_1.4.29.bb} (90%)
diff --git a/meta/recipes-extended/lighttpd
From: Zhai Edwin
Saul,
These are some package upgrade. Pls. help to review and pull.
Thanks,
Edwin
The following changes since commit 860a41bae6b863a289b06a9684d9cf6c58a307bd:
arch-ia32.inc: Fix up TUNE_ARCH variable conflicts (2011-07-26 22:39:59 +0100)
are available in the git repository a
Op 28 jul. 2011, om 14:50 heeft Phil Blundell het volgende geschreven:
> On Thu, 2011-07-28 at 14:11 +0200, Koen Kooi wrote:
>> 1) overlapping files like .gitignore breaks the script
>> 2) git format-patch | git am is a lossy process, so you can't import oe-core
>> and bitbake from scratch:
>
On Thu, 2011-07-28 at 14:11 +0200, Koen Kooi wrote:
> 1) overlapping files like .gitignore breaks the script
> 2) git format-patch | git am is a lossy process, so you can't import oe-core
> and bitbake from scratch:
Assuming I understand the intent correctly (which is by no means
certain), it so
Op 5 jul. 2011, om 18:28 heeft Paul Eggleton het volgende geschreven:
> From: Yu Ke
>
> This patch adds the script "combo-layer" to manipulate combo layer
> repos. A combo layer repo is a repo containing multiple component
> repos, e.g. oe-core, bitbake, BSP repos. The combo layer repo needs to
On Wed, 2011-07-27 at 15:34 +0100, Phil Blundell wrote:
> On Tue, 2011-07-26 at 13:44 +0100, Richard Purdie wrote:
> > +PACKAGE_EXTRA_ARCHS_tune-armv4tb = "${PACKAGE_EXTRA_ARCHS_tune-armv4}
> > armv4tb"
>
> That should be "${PACKAGE_EXTRA_ARCHS_tune-armv4b} armv4tb", I think.
> Otherwise you will
2011/7/28 Ben Gardiner
> Signed-off-by: Frans Meulenbroeks
>
Eh, yes and no.
I did write the original recipe and commited it on 14 aug 2010 with a
sign-off message.
As such this got my signoff, but I am not sure the signoff should be
repeated if this moved to oe-core.
My sign-off at that time
Using recipe-scope variable REAL_MULTIMACH_TARGET_SYS instead of the unavailable
OLD_MULTIMACH_TARGET_SYS to generate meta-environment files for ADT installer.
The following changes since commit f94b781695cd8fa387daff16ecbf3987a0883018:
Bruce Ashfield (1):
poky.conf: explicitly reference
The oebb.sh script can be used to update all openembedded-core layers
and custom added sources from the layers.txt file in
"oe-core-dir/setup-scripts/sources/layers.txt".
After checking my local repositories with git-log again, I found out
that your patch is not responsible for this.
It seems like
Fixed [BUGID #1299]. OLD_MULTIMACH_TARGET_SYS is no longer available.
Use new recipe-scope variable REAL_MULTIMACH_TARGET_SYS instead.
Signed-off-by: Lianhao Lu
---
meta/classes/toolchain-scripts.bbclass |7 ---
meta/recipes-core/meta/meta-environment.bb |9 +
2 files cha
Op 28 jul. 2011, om 05:38 heeft Ben Gardiner het volgende geschreven:
> Signed-off-by: Frans Meulenbroeks
> Signed-off-by: Ben Gardiner
> Signed-off-by: Tom Rini
>
> This recipe is a port of recipes/raptor/raptor_1.4.21.bb from
> git://git.openembedded.org/openembedded, commits
> 01e8e9f325d8
Signed-off-by: Frans Meulenbroeks
Signed-off-by: Ben Gardiner
Signed-off-by: Tom Rini
This recipe is a port of recipes/raptor/raptor_1.4.21.bb from
git://git.openembedded.org/openembedded, commits
01e8e9f325d8d251e852e7a5704b5fe50880e1ad 'raptor: added recipe' and
f1d24b5a986233f869364eb109476f
Op 28 jul. 2011, om 11:49 heeft Phil Blundell het volgende geschreven:
> On Thu, 2011-07-28 at 11:44 +0200, Koen Kooi wrote:
>> +ALLOW_EMPTY = "1"
>
> Is that necessary? You seem to be setting ALLOW_EMPTY_${PN}-meta=1 in
> your python code anyway.
In OE classic that was to keep ${PN} alive aft
See
http://lists.linuxtogo.org/pipermail/openembedded-core/2011-July/007075.html
for more background
Signed-off-by: Koen Kooi
---
meta/conf/bitbake.conf |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 6e109ec..1a6
I'm not familiar with oebb.sh or its functionality. But, from what
you're saying below it sounds as though it works something like
"git-am". If I'm understanding correctly you used it to apply the glibc
deletion patch, and now you get this sanity failure (whereas you didn't
get it immediately bef
On Thu, 2011-07-28 at 12:00 +0200, Koen Kooi wrote:
> Removing the PACKAGE_EXTRA_ARCHS line from bitbake.conf makes it work for me
> again, is that an acceptable solution?
Sounds about right to me. If ${TARGET_ARCH} really does need to go into
PACKAGE_EXTRA_ARCHS by default (which sounds implaus
Op 28 jul. 2011, om 11:20 heeft Phil Blundell het volgende geschreven:
> On Thu, 2011-07-28 at 10:57 +0200, Koen Kooi wrote:
>> Op 28 jul. 2011, om 10:47 heeft Paul Eggleton het volgende geschreven:
>>
>>> On Thursday 28 July 2011 08:48:43 Cui, Dexuan wrote:
Saul Wold wrote on 2011-07-28:
>
On Thu, 2011-07-28 at 11:44 +0200, Koen Kooi wrote:
> +ALLOW_EMPTY = "1"
Is that necessary? You seem to be setting ALLOW_EMPTY_${PN}-meta=1 in
your python code anyway.
p.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
ht
Gst-plugins get 2 extra packages:
${PN}-apps: helper apps in ${bindir}
${PN}-meta: meta package that will drag in all plugins, libs and apps ${PN}
generates
And all libs are split out and run through debian style renaming if enabled.
The packaging include was split out to be reused by external
1 - 100 of 113 matches
Mail list logo