On Fri, May 14, 2010 at 8:43 PM, Steve Sakoman wrote:
> Building with oe.dev. Works on 32 bit Ubuntu, but fails on the 64 bit
> version.
>
> Any ideas? Below is log.do_compile:
hmmm I have 10.04 running on 64bit I dont see this error. Can you also
post your local.conf
and anything you have in
Building with oe.dev. Works on 32 bit Ubuntu, but fails on the 64 bit version.
Any ideas? Below is log.do_compile:
NOTE: make -j 4
Making all in libbb
CCgz_open.o
CCunarchive.o
CCunzip.o
CCwfopen.o
unarchive.c: In function 'extract_archive':
unarchive.c:139: warning: ign
On Fri, 2010-05-14 at 23:21 +0200, Andrea Adami wrote:
> > With DISTRO= ? I do most of my builds with 4 and haven't seen this.
> > But with a failure log on gtk+-native, figuring out the missing dep
> > shouldn't be too bad.
>
> FWIW distro is Angstrom, devel branch.
>
> DEPENDS_virtclass-nativ
- without this bitbake meta-toolchain fails because it doesn't find who
provides gdb-cross-sdk
- found thanks to a hint from Phil Blundell on IRC
- tested with Angstrom/ARMv5te
Signed-off-by: Eric Benard
---
classes/cross.bbclass |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff
Hello,
On Fri, May 14, 2010 at 7:47 PM, Andrea Adami wrote:
> I repeated the build of console-image and gtk+-native always fails
> using 4 threads.
> Anyone can confirm?
>
I can confirm this happens, but not always for me.
Tthus probably racy.
Regards,
--
Leon
+1 form me.
Bye Henning
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Hi,
I discussed with pb on irc, how it would be the best way to unpack two tar
archivs into the same directory. He pointed me to the tar strip-components
options and attached is the outcome. Because base.bbclass is touched it is
open for discussion here.
Bye Henning
>From 0688f07fe2e8b1926ae1dc34
> With DISTRO= ? I do most of my builds with 4 and haven't seen this.
> But with a failure log on gtk+-native, figuring out the missing dep
> shouldn't be too bad.
FWIW distro is Angstrom, devel branch.
DEPENDS_virtclass-native = "libpng-native atk-native pango-native
cairo-native libxrender-nat
On Fri, 2010-05-14 at 22:15 +0200, Eric Bénard wrote:
> So actually the fix I propose is needed as while MACHINE_KERNEL_PR is
> not required by policy, module-base.bbclass is broken for machines
> without MACHINE_KERNEL_PR.
Yes, agreed. I think your fix is the right thing.
p.
__
Hey all,
Eric has been posting a number of useful fixes, and has responded
promptly to feedback on patches (and requests to get feedback from
specific people as needed). I'd like to recommend him for write access.
Thanks!
--
Tom Rini
Mentor Graphics Corporation
__
bitbake nano fails without this if gettext is not built
Signed-off-by: Eric Benard
---
recipes/nano/nano.inc |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/recipes/nano/nano.inc b/recipes/nano/nano.inc
index 2aaaedc..5b59b68 100644
--- a/recipes/nano/nano.inc
+++ b/rec
Le 14/05/2010 21:55, Phil Blundell a écrit :
On Fri, 2010-05-14 at 19:45 +0200, Eric Bénard wrote:
so why not setting r0 as a default in bitbake.conf as a compromise ?
A default MACHINE_KERNEL_PR, you mean? That would cause PR to suddenly
go backwards for a whole bunch of machines, which woul
On Fri, 2010-05-14 at 19:45 +0200, Eric Bénard wrote:
> so why not setting r0 as a default in bitbake.conf as a compromise ?
A default MACHINE_KERNEL_PR, you mean? That would cause PR to suddenly
go backwards for a whole bunch of machines, which would definitely not
be a good thing. See the mail
В сообщении от Пятница 14 мая 2010 19:28:32 автор Antonio Ospite написал:
> Update checksums; tzdata version bumps to 2010j as well.
>
> Signed-off-by: Antonio Ospite
> ---
> Changes since v1:
> Set PR to "${INC_PR}.0" as confirmed by Roman.
Thanks, pushed both.
--
http://roman.khimov.ru
mai
On Fri, 2010-05-14 at 19:47 +0200, Andrea Adami wrote:
> On Sat, May 8, 2010 at 1:12 PM, Andrea Adami wrote:
> > PARALLEL_MAKE = "-j5"
> > #BB_NUMBER_THREADS = "4"
> > BB_NUMBER_THREADS = "2"
> >
> > fixed the things. This time the dependencies were (correctly) built
> > before...
> >
> > Andrea
On Sat, May 8, 2010 at 1:12 PM, Andrea Adami wrote:
> PARALLEL_MAKE = "-j5"
> #BB_NUMBER_THREADS = "4"
> BB_NUMBER_THREADS = "2"
>
> fixed the things. This time the dependencies were (correctly) built before...
>
> Andrea
>
I repeated the build of console-image and gtk+-native always fails
using
Le 14/05/2010 19:34, Koen Kooi a écrit :
On 14-05-10 19:17, Eric Bénard wrote:
Le 14/05/2010 17:52, Koen Kooi a écrit :
Op 14 mei 2010, om 17:10 heeft Eric Bénard het volgende geschreven:
I was told you are the person to contact about MACHINE_KERNEL_PR so
may you please have a look to the patc
On Sat, May 8, 2010 at 2:07 PM, Andrea Adami wrote:
> I'm using bitbake 1.10.0 I've noticed some tasks appears twice in /tmp
> of each package:
>
> run.base_do_fetch
> run.do_fetch
>
> run.read_subpackage_metadata
> run.staging_helper
>
>
> I don't think this is normal...
>
> Regards
>
> Andrea
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 14-05-10 19:17, Eric Bénard wrote:
> Le 14/05/2010 17:52, Koen Kooi a écrit :
>> Op 14 mei 2010, om 17:10 heeft Eric Bénard het volgende geschreven:
>>> I was told you are the person to contact about MACHINE_KERNEL_PR so
>>> may you please have a lo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Almost a week later, any fixes people can try[1]?
[1] apart from sed -i -e
's:-L/OE/angstrom-dev/sysroots/x86_64-linux/usr/lib::g'
sysroots/*/usr/lib/*.la
On 08-05-10 09:53, Koen Kooi wrote:
> Hi,
>
> I've been getting failures when ARM apps try to
Le 14/05/2010 17:52, Koen Kooi a écrit :
Op 14 mei 2010, om 17:10 heeft Eric Bénard het volgende geschreven:
I was told you are the person to contact about MACHINE_KERNEL_PR so may you
please have a look to the patch below - also available here :
http://patchwork.openembedded.org/patch/2012/
Quoting Koen Kooi :
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 14-05-10 17:56, Robert P. J. Day wrote:
long story short:
... snip ...
ERROR: Task 3295
(/home/rpjday/oe/openembedded/recipes/mozilla/firefox_3.6.3.bb,
do_install) failed
ERROR: Task 3457
(/home/rpjday/oe/openemb
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 14-05-10 17:56, Robert P. J. Day wrote:
>
> long story short:
>
> ... snip ...
> ERROR: Task 3295
> (/home/rpjday/oe/openembedded/recipes/mozilla/firefox_3.6.3.bb, do_install)
> failed
> ERROR: Task 3457
> (/home/rpjday/oe/openembedded/recipe
On Fri, 2010-05-14 at 17:10 +0200, Eric Bénard wrote:
> -PR = "${MACHINE_KERNEL_PR}"
> +python __anonymous () {
> +machine_kernel_pr = bb.data.getVar('MACHINE_KERNEL_PR', d, True)
> +
> +if machine_kernel_pr:
> + bb.data.setVar('PR', machine_kernel_pr, d)
> +}
Looks reasonable to me.
long story short:
... snip ...
ERROR: Task 3295
(/home/rpjday/oe/openembedded/recipes/mozilla/firefox_3.6.3.bb, do_install)
failed
ERROR: Task 3457
(/home/rpjday/oe/openembedded/recipes/abiword/abiword_2.8.3.bb, do_install)
failed
NOTE: Tasks Summary: Attempted 11085 tasks of which 11085 di
Op 14 mei 2010, om 17:10 heeft Eric Bénard het volgende geschreven:
> Hi Koen,
>
> I was told you are the person to contact about MACHINE_KERNEL_PR so may you
> please have a look to the patch below - also available here :
> http://patchwork.openembedded.org/patch/2012/
>
> Actually, when com
On 05/14/2010 03:00 AM, Robert P. J. Day wrote:
obviously not fatal since the build kept chugging along, but there
were a number of "ERROR"s of the following form:
NOTE: Running task 3873 of 11130 (ID: 4231,
/home/rpjday/oe/openembedded/recipes/xcb/libpthread-stubs_0.2.bb,
do_patch)
ERROR:
Update checksums; tzdata version bumps to 2010j as well.
Signed-off-by: Antonio Ospite
---
Changes since v1:
Set PR to "${INC_PR}.0" as confirmed by Roman.
Thanks,
Antonio
recipes/tzcode/tzcode-native_2010f.bb | 16
recipes/tzcode/tzcode-native_2010j.bb | 16 ++
Hi Koen,
I was told you are the person to contact about MACHINE_KERNEL_PR so may
you please have a look to the patch below - also available here :
http://patchwork.openembedded.org/patch/2012/
Actually, when compiling modules (out of tree), we loose PR if
MACHINE_KERNEL_PR is not set.
Is t
KERNEL_MAJOR_VERSION may not be set (for example when building a module)
, this was preventing modules from being stripped.
Signed-off-by: Eric Benard
---
v2: moved to module_strip.bbclass following an advice from Tom Rini
classes/module_strip.bbclass |3 +++
1 files changed, 3 insertions(+
Thanks,
I will rework patchs and resend them asap.
Regards
On Fri, May 14, 2010 at 7:21 AM, Stefan Schmidt
wrote:
> Hello.
>
> On Thu, 2010-05-13 at 08:46, Adrian Alonso wrote:
> > * Update kernel version 2.6.33
> > * Include xilinx framebuffer patch
>
> You need to reorder your patchset to hav
OE weekly changelog for org.openembedded.dev, 2010-05-03 to 2010-05-10
Andrea Adami (2):
opie-init: uncomment c7x0 specific stuff
linux-kexecboot: further editings for Zaurus defconfigs.
Cliff Brake (2):
acl: clear TOPDIR env variable in recipe
attr: clear TOPDIR env variable in recipe
D
On Fri, 2010-05-14 at 11:25 +0200, Thilo Fromm wrote:
> No it isn't. --enable-kernel=VERSION provides kernel ABI backwards
> compatibility to applications. *At least* the kernel ABI described in
> the headers provided to glibc during compile time must be present at
> runtime.
This is incorrect.
On Fri, 2010-05-14 at 13:40 +0200, Thilo Fromm wrote:
> This would mean that checking for kernel features (e.g. inotify_init1())
> at compile time via an application's configure.ac is pointless, right?
Not entirely pointless: the feature set that you determine at configure
time is the maximum set
Hello.
On Thu, 2010-05-13 at 08:46, Adrian Alonso wrote:
> * Update kernel version 2.6.33
> * Include xilinx framebuffer patch
You need to reorder your patchset to have the fb patch prior to this change.
Without this git bisect will break.
Looking over the patch I think it would be fine to have
Hello.
On Thu, 2010-05-13 at 08:46, Adrian Alonso wrote:
> Signed-off-by: Adrian Alonso
> ---
> conf/machine/xilinx-ml507.conf |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/conf/machine/xilinx-ml507.conf b/conf/machine/xilinx-ml507.conf
> index 693f904..8c888b
I dud some checking around and found this email from the last time
patchwork broke:
http://lists.linuxtogo.org/pipermail/openembedded-devel/2009-August/012982.html
It look like patchwork is still running on amethyst, so we should look
at moving it to the OSUOSL server.
Philip
__
Hello *.*,
I have no means of detecting a level of compatibility at runtime. How
could that work, anyway? I get ENOSYS when calling inotify_init1(), so,
well I *think* this interface is missing (although configure reported it
being available). Then I would have to dynamically fall back to
ino
В сообщении от Пятница 14 мая 2010 15:20:15 автор Antonio Ospite написал:
> And a question for future updates: when renaming recipes it is not needed
> to change PR, is it?
>
> Would it be even better to reset it to some zero value? I mean, like in
> tzcode-native_2010j.bb, should one set PR to "
Signed-off-by: Antonio Ospite
---
recipes/tzdata/tzdata_2010i.bb | 10 --
recipes/tzdata/tzdata_2010j.bb | 10 ++
2 files changed, 10 insertions(+), 10 deletions(-)
delete mode 100644 recipes/tzdata/tzdata_2010i.bb
create mode 100644 recipes/tzdata/tzdata_2010j.bb
diff --gi
Update checksums; tzdata version bumps to 2010j as well.
Signed-off-by: Antonio Ospite
---
recipes/tzcode/tzcode-native_2010f.bb | 16
recipes/tzcode/tzcode-native_2010j.bb | 16
2 files changed, 16 insertions(+), 16 deletions(-)
delete mode 100644 recipes/
And a question for future updates: when renaming recipes it is not needed to
change PR, is it?
Would it be even better to reset it to some zero value? I mean, like in
tzcode-native_2010j.bb, should one set PR to "${INC_PR}.0" after a rename?
Thanks,
Antonio
Antonio Ospite (2):
tzcode-native
On Fri, 2010-05-14 at 11:59 +0200, Thilo Fromm wrote:
> I have no means of detecting a level of compatibility at runtime. How
> could that work, anyway? I get ENOSYS when calling inotify_init1(), so,
> well I *think* this interface is missing (although configure reported it
> being available). T
On Thu, 13 May 2010, Khem Raj wrote:
> On Thu, May 13, 2010 at 11:18 AM, Robert P. J. Day
> wrote:
> >
> > based on a quick google, i realize i'm not the only person who's
> > once been burned by not knowing about the bitbake "fetchall" command
> > versus the "fetch" command. and i'm aware tha
obviously not fatal since the build kept chugging along, but there
were a number of "ERROR"s of the following form:
NOTE: Running task 3873 of 11130 (ID: 4231,
/home/rpjday/oe/openembedded/recipes/xcb/libpthread-stubs_0.2.bb,
do_patch)
ERROR: runstrip: ''arm-angstrom-linux-gnueabi-strip'
--rem
Hello *.*,
It sounds like we have, perhaps, been talking at slight cross purposes.
It is true that you can build glibc against a different version of
linux-libc-headers than the version of the kernel that will be used at
runtime. So long as the runtime kernel version is newer than the
minimum
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Another ping :)
On 13-05-10 10:31, Antonio Ospite wrote:
> On Tue, 11 May 2010 23:39:29 +1000
> Angus Lees wrote:
>
>> It looks like the do_stage() removal was good, but the "inherit cross"
>> refactor broke task-sdk-host and all the SDKs that depen
Hello *.*,
Graeme Gregory in <20100505094242.gf2...@xora-desktop.xora.org.uk>:
[Steffen Sledz]
> > It seem's not to be possible to use DEFAULT_PREFERENCE_hipox in the
> > linux-libc-headers recipes. So what's the right way to handle this?
> > Something like PREFERRED_VERSION_linux-libc-heade
---
recipes/eglibc/eglibc_2.10.bb |5 +++--
recipes/eglibc/eglibc_2.11.bb |5 +++--
recipes/eglibc/eglibc_2.9.bb |5 +++--
3 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/recipes/eglibc/eglibc_2.10.bb b/recipes/eglibc/eglibc_2.10.bb
index 150d775..fb2877d 100644
--- a/r
On Thu, May 13, 2010 at 11:27:49PM +, git version control wrote:
> Module: openembedded.git
> Branch: org.openembedded.dev
> Commit: 3b41668fc1e3db2713cfa61067146cfdaf2be37a
> URL:
> http://gitweb.openembedded.net/?p=openembedded.git&a=commit;h=3b41668fc1e3db2713cfa61067146cfdaf2be37a
>
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 13-05-10 22:03, GNUtoo wrote:
> Should I attach a patch for switching only the machines that overrides
> some file to MACHINE_ARCH
Like I said, if an override in SRC_URI is used, OE will already mark it
as MACHINE_ARCH :)
regards,
Koen
-BEGI
51 matches
Mail list logo
