Hi,
I've just switched to oe-core from -dev, and I'm finding that my root images
are showing incorrect permissions on files, randomly. From one build to the
next, different subsets of files and folders end up owned by 1000:1000, instead
of root:root. They aren't strictly grouped by package - ju
Khem Raj wrote:
On Thursday, July 28, 2011 09:03:06 PM edwin.z...@intel.com wrote:
>
>
> +FILES_${PN}-dev += "${libdir}/aprutil.exp"
> +FILES_${PN} += "${libdir}/apr-util-1/apr_dbm_gdbm-1.so"
> +FILES_${PN}-dbg += "${libdir}/apr-util-1/*
${libdir}/apr-util-1/.debug/*"
do you really want
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} | 13 +
2 files changed, 7 insertions(+), 33 deletions(
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
Signed-off-by: Zhai Edwin
---
.../apr/{apr-util_1.3.10.bb => apr-util_1.3.12.bb} | 12
1 files changed, 8 insertions(+), 4 deletions(-)
rename meta/recipes-support/apr/{apr-util_1.3.10.bb => apr-util_1.3.12.bb}
(67%)
diff --git a/meta/recipes-support/apr/apr-u
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
From: Zhai Edwin
All,
This is new version for some package upgrade according to Raj's comments:
* remove "patch=1" in recipe
* reasonble split files for apr-util
BTW, one bug fix[YOCTO #1211] is also sent.
Thanks,
Edwin
The following changes since commit 860a41bae6b863a289b06a9684d
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
sudo is used to run rootless X in xserver-nodm, and start to fail with
"xf86OpenConsole: Cannot open /dev/tty0" error after upgrade to 1.8.1. sudo
seems wait for some resource that is unavailable in early phase of booting.
This patch swith to "su" for rootless X starting as a fix
From: Zhai Edwin
Signed-off-by: Zhai Edwin
---
.../disable_gpgconf_check.patch|0
.../gpgme/{gpgme_1.3.0.bb => gpgme_1.3.1.bb} | 10 +-
2 files changed, 5 insertions(+), 5 deletions(-)
rename meta/recipes-support/gpgme/{gpgme-1.3.0 =>
gpgme-1.3.1}/disab
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
On Mon, 2011-08-01 at 15:51 -0700, Tom Rini wrote:
> On 08/01/2011 03:28 PM, Saul Wold wrote:
> > On 07/30/2011 11:20 AM, Khem Raj wrote:
> >> On Wednesday, July 27, 2011 05:34:45 PM Kang Kai wrote:
> >>> From: Kang Kai
> >>>
> >>> ghostscript fails some time on autobuilder, it seems a parallel bui
Add a fixup for trying to create ustar archives when the users
UID or GID is larger than the format allows.
Based on a patch from Tom Rini
Signed-off-by: Kumar Gala
---
meta/recipes-devtools/automake/automake.inc|2 +-
.../prefer-cpio-over-pax-for-ustar-archives.patch | 26 ++
On Tue, 2011-08-02 at 03:14 -0500, Kumar Gala wrote:
> Add a fixup for trying to create ustar archives when the users
> UID or GID is larger than the format allows.
>
> Based on a patch from Tom Rini
>
> Signed-off-by: Kumar Gala
> ---
> meta/recipes-devtools/automake/automake.inc|2
On Tue, 2011-08-02 at 07:28 +, James Limbouris wrote:
> Hi,
>
> I've just switched to oe-core from -dev, and I'm finding that my root
> images are showing incorrect permissions on files, randomly. From one
> build to the next, different subsets of files and folders end up owned
> by 1000:1000,
On Mon, 2011-08-01 at 14:16 -0700, Saul Wold wrote:
> On 07/28/2011 03:01 AM, Phil Blundell wrote:
> > Glibc 2.10.1 is outdated now and eglibc seems to provide a superset of
> > its functionality.
> >
> > Signed-off-by: Phil Blundell
> >
>
> Merged into OE-Core
>
> But this seems to have triggere
Hi all,
Andrea pointed out a situation where he has seen the layer priority overriding
version selection, and I've been able to confirm it.
Basically, if you have a recipe with a lower version in a layer with a higher
priority it selects the lower version. What's more after digging further I
f
Hi,
I've been experimenting with a combined repo
(https://github.com/koenkooi/Angstrom-integration-layer/) the past few days and
I have some mixed feelings about it. I tried to mimic the yocto setup and the
questions I get from people are "how do I know where all the stuff is
originally from",
On Mon, 2011-08-01 at 18:47 -0700, Khem Raj wrote:
> Currently the grep regexp matches any occurance of
> 'TMPDIR=' but if you have another variable defined
> e.g. OE_BUILD_TMPDIR=xxx then that gets picked up
> too.
>
> $ bitbake -e | grep TMPDIR=\"
> TMPDIR="/home/kraj/work/angstrom/build/tmp-ang
On Tue, 2011-08-02 at 14:08 +0800, Dexuan Cui wrote:
> [YOCTO #671]
>
> "readlink -f" in Ubuntu 10.04 is buggy: it doesn't ignore a trailing / (e.g.,
> "readlink -f /tmp/non-existent-dir/" returns nothing, but according to
> http://www.gnu.org/s/coreutils/manual/coreutils.pdf it should do that --
* Added do_savedefconfig task to kernel.bbclass.
Signed-off-by: Noor, Ahsan
---
meta/classes/kernel.bbclass |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 25d2629..f2f05b1 100644
--- a/meta/classes/ker
We need to ensure only one value ends up in TUNE_PKGARCH rather than several.
This change ensures consistency accross all the PPC tune files and that they
correctly inherit the core value but also allow it to be overwritten.
Signed-off-by: Richard Purdie
---
diff --git a/meta/conf/machine/include
On Mon, 2011-08-01 at 09:44 -0700, Tom Rini wrote:
> On 08/01/2011 09:07 AM, Phil Blundell wrote:
> > On Mon, 2011-08-01 at 09:37 -0500, Kumar Gala wrote:
> >> Not sure I understand the statement about disambiguate the resulting
> >> compilers, on PPC where I intend to utilize this we'd have the t
On Aug 1, 2011, at 11:57 AM, Richard Purdie wrote:
> On Mon, 2011-08-01 at 09:44 -0700, Tom Rini wrote:
>> On 08/01/2011 09:07 AM, Phil Blundell wrote:
>>> On Mon, 2011-08-01 at 09:37 -0500, Kumar Gala wrote:
Not sure I understand the statement about disambiguate the resulting
compiler
Hi,
when running QEMU, build as console-image, some strange errors occur.
QEMU was started with the following command:
qemu-system-arm -M versatilepb -m 128 -kernel
/var/oe-core/tmp-eglibc/deploy/images/qemuarm/zImage-qemuarm.bin -hda
/var/oe-core/tmp-eglibc/deploy/images/qemuarm/console-image-qem
Op 2 aug. 2011, om 14:30 heeft Noor, Ahsan het volgende geschreven:
> * Added do_savedefconfig task to kernel.bbclass.
>
> Signed-off-by: Noor, Ahsan
> ---
> meta/classes/kernel.bbclass |6 ++
> 1 files changed, 6 insertions(+), 0 deletions(-)
>
> diff --git a/meta/classes/kernel.bbclas
On Mon, 2011-08-01 at 19:17 -0500, Mark Hatle wrote:
> This is an attempt to fix a number of issues with the SDK generation. It has
> been
> tested using bitbake meta-toolchain-sdk.
>
> Note, patches:
>
> 4/5: package_ipk: SDK generation workaround
> 5/5: update-alternatives: Add alternatives
On Mon, 2011-08-01 at 11:59 -0700, Khem Raj wrote:
> On Mon, Aug 1, 2011 at 11:51 AM, Kumar Gala wrote:
> >
> > On Aug 1, 2011, at 12:34 PM, Khem Raj wrote:
> >
> >> On (01/08/11 09:11), Kumar Gala wrote:
> >>>
> >>> On Aug 1, 2011, at 8:03 AM, Richard Purdie wrote:
> >>>
> On Mon, 2011-08-01
On Tue, 2011-08-02 at 08:11 -0500, Kumar Gala wrote:
> On Aug 1, 2011, at 11:57 AM, Richard Purdie wrote:
>
> > On Mon, 2011-08-01 at 09:44 -0700, Tom Rini wrote:
> >> On 08/01/2011 09:07 AM, Phil Blundell wrote:
> >>> On Mon, 2011-08-01 at 09:37 -0500, Kumar Gala wrote:
> Not sure I understa
On Tue, 2011-08-02 at 12:26 +0100, Paul Eggleton wrote:
> Hi all,
>
> Andrea pointed out a situation where he has seen the layer priority
> overriding
> version selection, and I've been able to confirm it.
>
> Basically, if you have a recipe with a lower version in a layer with a higher
> prio
On Mon, 2011-08-01 at 19:17 -0500, Mark Hatle wrote:
> The following allows RPM to generate the SDK image, however without it
> we get a failure because the system has nothing that provides /bin/sh.
>
> Unfortunately the patch causes failures with ipk and deb packages because
> they can not have f
On Tue, 2011-08-02 at 14:45 +0100, Richard Purdie wrote:
> We could do with clearly documenting this in the bitbake manual. I
> suspect users would expect the highest version to win and we probably
> should change the behaviour but I'm open to other opinions.
The original intent with BBFILE_COLLEC
On Tue, Aug 2, 2011 at 6:52 AM, Phil Blundell wrote:
> Actually, to some extent I consider it a bit of a misfeature that the
> layer priority is specified by the layer rather than by the user in
> bblayers.conf, since this makes it harder to vary the stack-up order
> without local hackery to the l
On Tuesday 02 August 2011 15:14:41 Chris Larson wrote:
> as config/class priority is
> determined by order of entries in BBLAYERS, whereas recipe priority is
> determined by layer.conf.
Is that a good thing though? At the moment I'm not convinced that it is.
Cheers,
Paul
--
Paul Eggleton
Intel
On Tue, Aug 2, 2011 at 7:21 AM, Paul Eggleton
wrote:
> On Tuesday 02 August 2011 15:14:41 Chris Larson wrote:
>> as config/class priority is
>> determined by order of entries in BBLAYERS, whereas recipe priority is
>> determined by layer.conf.
>
> Is that a good thing though? At the moment I'm not
On 8/2/11 5:11 AM, Richard Purdie wrote:
> On Tue, 2011-08-02 at 07:28 +, James Limbouris wrote:
>> Hi,
>>
>> I've just switched to oe-core from -dev, and I'm finding that my root
>> images are showing incorrect permissions on files, randomly. From one
>> build to the next, different subsets of
When using binary locales rootfs generation fails with:
| Unknown package 'locale-base-en-us'.
| Collected errors:
| * opkg_install_cmd: Cannot install package locale-base-en-us.
This is due to:
$ dpkg-deb -I ipk/armv7a/locale-base-en-us_2.12-r16_armv7a.ipk | grep Depends
Depends: eglibc-binar
On 8/2/11 8:46 AM, Phil Blundell wrote:
> On Mon, 2011-08-01 at 19:17 -0500, Mark Hatle wrote:
>> The following allows RPM to generate the SDK image, however without it
>> we get a failure because the system has nothing that provides /bin/sh.
>>
>> Unfortunately the patch causes failures with ipk a
On Tuesday 02 August 2011 15:27:58 Chris Larson wrote:
> On Tue, Aug 2, 2011 at 7:21 AM, Paul Eggleton
>
> wrote:
> > On Tuesday 02 August 2011 15:14:41 Chris Larson wrote:
> >> as config/class priority is
> >> determined by order of entries in BBLAYERS, whereas recipe priority is
> >> determined
The bug I was seeing was caused by something else, but I'd still like feedback
on this patch to find out why the dot vs dash difference exists
Op 2 aug. 2011, om 16:47 heeft Koen Kooi het volgende geschreven:
> When using binary locales rootfs generation fails with:
>
> | Unknown package 'local
It does look a bit weird. That code was introduced in 561d8754,
ostensibly as a merger of the eglibc and glibc equivalents. But, the
original code from glibc-package.bbclass did:
def output_locale_binary_rdepends(name, pkgname, locale, encoding):
m = re.match("(.*)\.(.*)",
On Aug 2, 2011, at 1:14 AM, Kumar Gala wrote:
> Add a fixup for trying to create ustar archives when the users
> UID or GID is larger than the format allows.
>
> Based on a patch from Tom Rini
>
> Signed-off-by: Kumar Gala
> ---
> meta/recipes-devtools/automake/automake.inc|2 +-
On Tue, 2011-08-02 at 03:14 -0500, Kumar Gala wrote:
> +-_am_tools='gnutar m4_if([$1], [ustar], [plaintar]) pax cpio none'
> ++_am_tools='gnutar m4_if([$1], [ustar], [plaintar]) cpio pax none'
Have you discussed that with upstream? If not, are you confident that
preferring cpio will not simply me
On Aug 2, 2011, at 7:14 AM, Chris Larson wrote:
> On Tue, Aug 2, 2011 at 6:52 AM, Phil Blundell wrote:
>> Actually, to some extent I consider it a bit of a misfeature that the
>> layer priority is specified by the layer rather than by the user in
>> bblayers.conf, since this makes it harder to
On 08/02/2011 08:19 AM, Phil Blundell wrote:
> On Tue, 2011-08-02 at 03:14 -0500, Kumar Gala wrote:
>> +-_am_tools='gnutar m4_if([$1], [ustar], [plaintar]) pax cpio none'
>> ++_am_tools='gnutar m4_if([$1], [ustar], [plaintar]) cpio pax none'
>
> Have you discussed that with upstream? If not, are
On 08/02/2011 08:34 AM, Tom Rini wrote:
> On 08/02/2011 08:19 AM, Phil Blundell wrote:
>> On Tue, 2011-08-02 at 03:14 -0500, Kumar Gala wrote:
>>> +-_am_tools='gnutar m4_if([$1], [ustar], [plaintar]) pax cpio none'
>>> ++_am_tools='gnutar m4_if([$1], [ustar], [plaintar]) cpio pax none'
>>
>> Have y
On Aug 1, 2011, at 1:58 PM, Kumar Gala wrote:
> I'm trying to track down a bug related the following in
> gcc-configure-common.inc. I know there is one bug in the sed line, but when
> I fix that I run into a second issue. I'm trying to understand what we think
> the following two lines are t
On Tue, 2011-08-02 at 10:36 -0500, Kumar Gala wrote:
> Would really love if anyone knows what is suppose to be going on with
> SYSTEMLIBS_DIR to chime in here.
That stuff was all added in 934d3853 as part of the source tree sharing
work. So I guess you should take it up with Robert Yang.
p.
On Aug 1, 2011, at 1:58 PM, Kumar Gala wrote:
> I'm trying to track down a bug related the following in
> gcc-configure-common.inc. I know there is one bug in the sed line, but when
> I fix that I run into a second issue. I'm trying to understand what we think
> the following two lines are t
On Aug 2, 2011, at 10:41 AM, Phil Blundell wrote:
> On Tue, 2011-08-02 at 10:36 -0500, Kumar Gala wrote:
>> Would really love if anyone knows what is suppose to be going on with
>> SYSTEMLIBS_DIR to chime in here.
>
> That stuff was all added in 934d3853 as part of the source tree sharing
> wor
On Aug 2, 2011, at 10:34 AM, Tom Rini wrote:
> On 08/02/2011 08:19 AM, Phil Blundell wrote:
>> On Tue, 2011-08-02 at 03:14 -0500, Kumar Gala wrote:
>>> +-_am_tools='gnutar m4_if([$1], [ustar], [plaintar]) pax cpio none'
>>> ++_am_tools='gnutar m4_if([$1], [ustar], [plaintar]) cpio pax none'
>>
>
On 08/02/2011 09:01 AM, Kumar Gala wrote:
>
> On Aug 2, 2011, at 10:34 AM, Tom Rini wrote:
>
>> On 08/02/2011 08:19 AM, Phil Blundell wrote:
>>> On Tue, 2011-08-02 at 03:14 -0500, Kumar Gala wrote:
+-_am_tools='gnutar m4_if([$1], [ustar], [plaintar]) pax cpio none'
++_am_tools='gnutar m
On Aug 2, 2011, at 11:04 AM, Tom Rini wrote:
> On 08/02/2011 09:01 AM, Kumar Gala wrote:
>>
>> On Aug 2, 2011, at 10:34 AM, Tom Rini wrote:
>>
>>> On 08/02/2011 08:19 AM, Phil Blundell wrote:
On Tue, 2011-08-02 at 03:14 -0500, Kumar Gala wrote:
> +-_am_tools='gnutar m4_if([$1], [ustar]
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/
Folks,
Thanks for your patience, I am working with Richard to gather up the
requests that have been made over the last week. Now that we are
getting Milestone 3 moving again, OE-Core will get the attention it needs.
I am working to get patches in on a 24-48 hour cycle, so please have
some
On 07/28/2011 11:09 AM, Kumar Gala wrote:
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:
On 07/28/2011 01:59 PM, Kumar Gala wrote:
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/me
On 07/28/2011 01:59 PM, Kumar Gala wrote:
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/mac
On 07/28/2011 01:59 PM, Kumar Gala wrote:
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/m
On 07/28/2011 05:08 PM, Kumar Gala wrote:
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/
On 07/28/2011 08:33 PM, Kang Kai wrote:
From: Kang Kai
Update distro tracking fields of libnewt mailx slang and alsa-tools.
Update mailx licence, slang homepage and alsa-tools.
This should be 4 separate commits, not 1, please resubmit this
Sau!
Signed-off-by: Kang Kai
---
.../conf/distro/
On Tue, Aug 2, 2011 at 9:31 AM, Kumar Gala wrote:
> 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.
there are 2 more patches more or less add
On 07/29/2011 12:34 AM, Martin Jansa wrote:
On Fri, Jul 29, 2011 at 09:17:31AM +0200, Martin Jansa wrote:
* PACKAGES were defined in eglibc.inc as well as eglibc-package.inc, definition
from eglibc.inc was overriden from recipes including eglibc.inc only
* 37ff0fea8f7180b1a9d91d24dfe173573042
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
On 07/29/2011 08:34 AM, Dmitry Eremin-Solenikov wrote:
Currently tune-xscale.inc has options wrt. setting of xscale/xscale-be tunes.
Fix that.
Signed-off-by: Dmitry Eremin-Solenikov
---
meta/conf/machine/include/tune-xscale.inc |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff
On 07/30/2011 05:46 AM, Koen Kooi wrote:
Signed-off-by: Koen Kooi
---
meta/classes/package_deb.bbclass |6 +++---
meta/classes/package_ipk.bbclass |6 +++---
meta/classes/package_rpm.bbclass |6 +++---
3 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/meta/classes/pa
On 07/31/2011 03:31 AM, Dmitry Eremin-Solenikov wrote:
eglibc builds for arm-eabi unconditionally enables the libc-do-syscall.S
file, which contains thumb assembly. It's unused in arm-eabi-nothumb case,
so just ifdef the actual code.
Signed-off-by: Dmitry Eremin-Solenikov
---
.../eglibc-fixup-
On 07/28/2011 01: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:
power
On (27/07/11 15:29), Richard Purdie wrote:
> Since we now handle GLIBC_DYNAMIC_LINKER in gcc-configure-common.inc:
>
> 's#\(GLIBC_DYNAMIC_LINKER[^ ]*\)\( *"/lib.*\)#\1 SYSTEMLIBS_DIR\2#'
>
> we can drop the patch which changes a hardcoded value for this.
>
> No PR bump since there is no code cha
On 07/29/2011 05:24 AM, Noor, Ahsan wrote:
* The menuconfig target exists in places other than the kernel that use kernel
style config.
Signed-off-by: Noor, Ahsan
---
meta/classes/cml1.bbclass | 12
meta/classes/kernel.bbclass | 15 ---
2 files changed, 12 ins
Op 2 aug. 2011, om 20:36 heeft Saul Wold het volgende geschreven:
> On 07/29/2011 05:24 AM, Noor, Ahsan wrote:
>> * The menuconfig target exists in places other than the kernel that use
>> kernel style config.
>>
>> Signed-off-by: Noor, Ahsan
>> ---
>> meta/classes/cml1.bbclass | 12 ++
On Aug 1, 2011, at 8:03 AM, Richard Purdie wrote:
> On Mon, 2011-08-01 at 00:36 -0700, Saul Wold wrote:
>> From: Kumar Gala
>>
>> 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
On Tue, 2011-08-02 at 11:36 -0700, Saul Wold wrote:
> I think this patch will break the linux-* recipes if someone tries to
> use the menuconfig task.
>
> I think you need to also modify the linux-* recipes that currently
> inherit kernel to also include cmd1
kernel.bbclass already does "inheri
On 08/02/2011 11:45 AM, Phil Blundell wrote:
On Tue, 2011-08-02 at 11:36 -0700, Saul Wold wrote:
I think this patch will break the linux-* recipes if someone tries to
use the menuconfig task.
I think you need to also modify the linux-* recipes that currently
inherit kernel to also include cmd1
* Add DEFAULTTUNE setting
* Sync TUNE_PKGARCH with:
commit 20f285728219c1efcc23d8e861902c212893c68d
Author: Richard Purdie
Date: Tue Aug 2 12:40:06 2011 +0100
tune/ppc: Fix various TUNE_PKGARCH issues
Signed-off-by: Kumar Gala
---
.../machine/include/power
On 08/02/2011 09:31 AM, Kumar Gala wrote:
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/
On Aug 2, 2011, at 2:35 PM, Saul Wold wrote:
> On 08/02/2011 09:31 AM, Kumar Gala wrote:
>> 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 ppc64e
On Tue, 2011-08-02 at 14:18 -0500, Kumar Gala wrote:
> * Add DEFAULTTUNE setting
> * Sync TUNE_PKGARCH with:
> commit 20f285728219c1efcc23d8e861902c212893c68d
> Author: Richard Purdie
> Date: Tue Aug 2 12:40:06 2011 +0100
>
> tune/ppc: Fix various TUNE_PKGARCH issues
Add a fixup for trying to create ustar archives when the users
UID or GID is larger than the format allows.
Signed-off-by: Tom Rini
Signed-off-by: Kumar Gala
---
meta/recipes-devtools/automake/automake.inc|2 +-
.../prefer-cpio-over-pax-for-ustar-archives.patch | 41 +
On Aug 2, 2011, at 3:39 PM, Richard Purdie wrote:
> On Tue, 2011-08-02 at 14:18 -0500, Kumar Gala wrote:
>> * Add DEFAULTTUNE setting
>> * Sync TUNE_PKGARCH with:
>> commit 20f285728219c1efcc23d8e861902c212893c68d
>> Author: Richard Purdie
>> Date: Tue Aug 2 12:40:06 2011 +0100
The sed regex in do_configure_prepend was producing the following result:
#define GLIBC_DYNAMIC_LINKER64 SYSTEMLIBS_DIR "/lib64//ld-linux-x86-64.so.2"
instead of
#define GLIBC_DYNAMIC_LINKER64 SYSTEMLIBS_DIR"/ld-linux-x86-64.so.2"
Additionally, with the regex fixed the manipulation of SYSTEML
Add a fixup for trying to create ustar archives when the users
UID or GID is larger than the format allows.
Signed-off-by: Tom Rini
Signed-off-by: Kumar Gala
---
* Removed patch=1
* Fixed a few whitespace issues
meta/recipes-devtools/automake/automake.inc|2 +-
.../prefer-cpio-over
On Tue, Aug 2, 2011 at 2:16 PM, Kumar Gala wrote:
> The sed regex in do_configure_prepend was producing the following result:
>
> #define GLIBC_DYNAMIC_LINKER64 SYSTEMLIBS_DIR "/lib64//ld-linux-x86-64.so.2"
>
> instead of
>
> #define GLIBC_DYNAMIC_LINKER64 SYSTEMLIBS_DIR"/ld-linux-x86-64.so.2"
>
I'd like to report a possible problem with oe-core that I'm not sure how to fix:
On running a "bitbake systemd-gnome-image", the do_rootfs stage fails
saying certain packages are missing.
On digging further, I find that the opkg.conf that opkg-cl uses (in
image.bbclass do_rootfs function) has the
Op 2 aug. 2011 om 23:57 heeft Joel A Fernandes het
volgende geschreven:
> I'd like to report a possible problem with oe-core that I'm not sure how to
> fix:
./oebb.sh update
>
> On running a "bitbake systemd-gnome-image", the do_rootfs stage fails
> saying certain packages are missin
The sed regex in do_configure_prepend was producing the following result:
#define GLIBC_DYNAMIC_LINKER64 SYSTEMLIBS_DIR "/lib64/ld-linux-x86-64.so.2"
instead of removing the leading "/lib" or "/lib64".
Now we have it do:
#define GLIBC_DYNAMIC_LINKER64 SYSTEMLIBS_DIR "ld-linux-x86-64.so.2"
Ad
On Tue, 2011-08-02 at 13:31 -0500, Kumar Gala wrote:
> On Aug 1, 2011, at 8:03 AM, Richard Purdie wrote:
>
> > On Mon, 2011-08-01 at 00:36 -0700, Saul Wold wrote:
> >> From: Kumar Gala
> >>
> >> Its more likely that we explicitly set soft-floating point support for a
> >> given target than hard.
On Tue, Aug 2, 2011 at 5:09 PM, Koen Kooi wrote:
>
>
> Op 2 aug. 2011 om 23:57 heeft Joel A Fernandes het
> volgende geschreven:
>
>> I'd like to report a possible problem with oe-core that I'm not sure how to
>> fix:
>
> ./oebb.sh update
I see you fixed it in [1] , nice, thanks :)
Regards,
J
On Tue, Aug 2, 2011 at 3:33 PM, Kumar Gala wrote:
> The sed regex in do_configure_prepend was producing the following result:
>
> #define GLIBC_DYNAMIC_LINKER64 SYSTEMLIBS_DIR "/lib64/ld-linux-x86-64.so.2"
>
> instead of removing the leading "/lib" or "/lib64".
>
> Now we have it do:
>
> #define
On Aug 1, 2011, at 9:26 AM, Kumar Gala wrote:
> Some of powerpc's dont support the fsqrt[s] instructions so we need an
> implementation of the library functions for those processors.
>
> Signed-off-by: Kumar Gala
> ---
> .../recipes-core/eglibc/eglibc-2.13/ppc-sqrt.patch | 538
On 08/02/2011 04:15 PM, Kumar Gala wrote:
On Aug 1, 2011, at 9:26 AM, Kumar Gala wrote:
Some of powerpc's dont support the fsqrt[s] instructions so we need an
implementation of the library functions for those processors.
Signed-off-by: Kumar Gala
---
.../recipes-core/eglibc/eglibc-2.13/ppc-sq
On 08/01/2011 07:26 AM, Kumar Gala wrote:
Some of powerpc's dont support the fsqrt[s] instructions so we need an
implementation of the library functions for those processors.
Signed-off-by: Kumar Gala
This patch is ok.
Acked-by: Khem Raj
---
.../recipes-core/eglibc/eglibc-2.13/ppc-sqrt.
Hi,
I now get a build error as below with systemd-gnome-image in
do_rootfs, could you take a look?
Also I had to remove 'fontconfig' from RDEPENDS_task-gnome-fonts in
recipes-angstrom/tasks/angstrom-task-gnome.bb as the package didn't
exist and it was causing more opkg install problems in do_root
On Aug 2, 2011, at 6:33 PM, Saul Wold wrote:
> On 08/02/2011 04:15 PM, Kumar Gala wrote:
>>
>> On Aug 1, 2011, at 9:26 AM, Kumar Gala wrote:
>>
>>> Some of powerpc's dont support the fsqrt[s] instructions so we need an
>>> implementation of the library functions for those processors.
>>>
>>> S
On Tue Aug 2 16:40:09, Mark Hatle wrote:
>On 8/2/11 5:11 AM, Richard Purdie wrote:
>> On Tue, 2011-08-02 at 07:28 +, James Limbouris wrote:
>>> Hi,
>>>
>>> I've just switched to oe-core from -dev, and I'm finding that my root
>>> images are showing incorrect permissions on files, randomly. From
On 08/02/2011 04:43 AM, Richard Purdie wrote:
> On Tue, 2011-08-02 at 14:08 +0800, Dexuan Cui wrote:
>> [YOCTO #671]
>>
>> "readlink -f" in Ubuntu 10.04 is buggy: it doesn't ignore a trailing / (e.g.,
>> "readlink -f /tmp/non-existent-dir/" returns nothing, but according to
>> http://www.gnu.org/
On Jul 20, 2011, at 3:27 AM, Saul Wold wrote:
> From: Dongxiao Xu
>
> There is hardcode of /usr/lib dir for some python files.
> Fix it to support multilib.
>
> Signed-off-by: Dongxiao Xu
> ---
> .../xcb/xcb-proto-1.6/aclocal.patch| 22
> meta/recipes-gra
powerp64 dynamic loader is 'ld64.so.1'.
Signed-off-by: Kumar Gala
---
* Use correct name of ppc64 dynamic loader
* user ${baselib} so if we are /lib or /lib64 things work
meta/classes/image-mklibs.bbclass |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/meta/classes/im
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
---
* Removed setting of 'fpu-hard' from the tune files that
If prelink gets a chance to properly run I get a rootfs that does:
/sbin/init: relocation error: /lib64/libc.so.6: symbol _rtld_global_ro, version
GLIBC_PRIVATE not defined in file ld64.so.1 with link time reference
if 'baselib' is set to /lib we get:
/local/home/galak/git/poky/build-p5020/tmp/
1 - 100 of 107 matches
Mail list logo
