From repvik at kynisk.com  Tue May  1 01:49:14 2007
From: repvik at kynisk.com (=?utf-8?q?=C3=98yvind_Repvik?=)
Date: Tue, 1 May 2007 03:49:14 +0200
Subject: [oe] [oe-commits] MedHelp 28949335
In-Reply-To: <20070430-35259.9357.qmail@bridges>
References: <20070430-35259.9357.qmail@bridges>
Message-ID: <200705010349.14949.repvik@kynisk.com>

On Tuesday 01 May 2007 01:02:18 Canadian Doctor Addie wrote:
> <STYLE>
> /back/CMA/Tournament/Sherrill/Laura/supporting/xxx/1520/blackberry/live/12/
>treatment/Tam/receipt/Unfortunately/wa
>
[lots of crap]

Why isn't there any filtering on oe-commits? Isn't that list commits-only? 
I see my spamfilter kills most of them, but a few still comes through.
Why not just block all non-commit mails?

Regards,
?yvind Repvik



From papercrane at gmail.com  Tue May  1 02:51:24 2007
From: papercrane at gmail.com (Justin Patrin)
Date: Mon, 30 Apr 2007 19:51:24 -0700
Subject: [oe] [oe-commits] MedHelp 28949335
In-Reply-To: <200705010349.14949.repvik@kynisk.com>
References: <20070430-35259.9357.qmail@bridges>
	<200705010349.14949.repvik@kynisk.com>
Message-ID: <432beae0704301951v2cd237f7w8e0300f5681a65b9@mail.gmail.com>

On 4/30/07, ?yvind Repvik <repvik at kynisk.com> wrote:
> On Tuesday 01 May 2007 01:02:18 Canadian Doctor Addie wrote:
> > <STYLE>
> > /back/CMA/Tournament/Sherrill/Laura/supporting/xxx/1520/blackberry/live/12/
> >treatment/Tam/receipt/Unfortunately/wa
> >
> [lots of crap]
>
> Why isn't there any filtering on oe-commits? Isn't that list commits-only?
> I see my spamfilter kills most of them, but a few still comes through.
> Why not just block all non-commit mails?
>

Sounds good to me.

-- 
Justin Patrin



From xjqian at gmail.com  Tue May  1 05:14:40 2007
From: xjqian at gmail.com (Junqian Gordon Xu)
Date: Tue, 01 May 2007 00:14:40 -0500
Subject: [oe] perl 5.8.8 is ready
In-Reply-To: <20070430080044.GA15877@twibble.org>
References: <20070427105722.GA4340@twibble.org> <46359408.9060800@gmail.com>
	<20070430080044.GA15877@twibble.org>
Message-ID: <4636CCC0.1010109@gmail.com>

Thanks. I fixed the hostperl problem.

Don't know why. Even I commented out the DEFAULT_PREFERENCE = "-1", 
bitbake still try to get perl-5.8.7 compiled first

NOTE: package perl-5.8.8-r8: task do_unpack: completed
NOTE: package perl-5.8.8: completed
NOTE: Running task 285 of 302 (ID: 130, 
/home/OE/org.openembedded.dev/packages/perl/perl_5.8.7.bb, do_fetch)
NOTE: package perl-5.8.7: started
NOTE: package perl-5.8.7-r22: task do_fetch: started

Besides, I noticed another issue:
I had linux-libc-headers-2.6.15.99 compiled (I think it's determined 
Machine and Distro) . But perl-5.8.8 wants linux-libc-headers-2.6.20. 
Will that cause problem?

Thanks
Gordon


Jamie Lenehan wrote:
> On Mon, Apr 30, 2007 at 02:00:24AM -0500, Junqian Gordon Xu wrote:
>   
>> Jamie Lenehan wrote:
>>     
> [...]
>   
>> perl-native-5.8.8 builds fine but with the following error
>>
>> ERROR: QA issue: libgettextsrc.la failed sanity test (reference to 
>> workdir or installed)
>>     
> [...]
>
> These ones aren't related to perl-native at all, so no problems there.
>
> [...]
>   
>> perl-5.8.8 build failed. Detail in the attached log file.
>>     
> [...]
>   
>> | hostperl -I/home/OE/build/tosa_angstrom/tmp/work/armv5te-angstrom-linux-gnueabi/perl-5.8.8-r7/perl-5.8.8/Cross/../fake_config_library -MConfig ../../lib/ExtUtils/xsubpp -noprototypes -typemap ../../lib/ExtUtils/typemap  attrs.xs > attrs.xsc && mv attrs.xsc attrs.c
>> | Perl lib version (v5.8.8) doesn't match executable version (v5.8.7) at /home/OE/build/tosa_angstrom/tmp/work/armv5te-angstrom-linux-gnueabi/perl-5.8.8-r7/perl-5.8.8/Cross/../fake_config_library/Config.pm line 46.
>>     
>
> This error is saying that "hostperl" is perl 5.8.7 but that it needs
> to be perl 5.8.8. Can you check what your hostperl, which would be:
>
>   /home/OE/build/tosa_angstrom/tmp/staging/i686-linux/bin/hostperl
>
> is pointing at? It should be 5.8.8 but this error makes it sound like
> it's pointing at 5.8.7:
>
>   %~> ls -l tmp/staging/x86_64-linux/bin/hostperl 
>   lrwxrwxrwx 1 lenehan lenehan 82 2007-04-30 13:28 tmp/staging/x86_64-linux/bin/hostperl -> /home/lenehan/devel/oe/build/titan-glibc-25/tmp/staging/x86_64-linux/bin/perl5.8.8*
>
> Thanks.
>
>   




From rod at whitby.id.au  Tue May  1 08:17:11 2007
From: rod at whitby.id.au (Rod Whitby)
Date: Tue, 01 May 2007 17:47:11 +0930
Subject: [oe] RFC: Rename MACHINE_TASK_PROVIDER to DEFAULT_TASK_PROVIDER
Message-ID: <4636F787.8030902@whitby.id.au>

> <rwhitby> so in my mokoslug distro, I set MACHINE_TASK_PROVIDER to task-boot or task-base, depending on flash size.
> <rwhitby> what is MACHINE_TASK_PROVIDER really meant to be used for?
> <koen> to distinguish between task-bootstrap and task-base
> <rwhitby> does task-bootstrap still exist?
> <koen> rwhitby: I hope not
> <rwhitby> koen: so MACHINE_TASK_PROVIDER has no current reason for existence then?
> <rwhitby> (and no definition of what it should be used for if it did have a current reason for existence)
> <koen> rwhitby: not that I know off, but your task-boot suggestion would make sense
> <rwhitby> koen: So it really should now be called something like BOOTSTRAP_IMAGE_FOUNDATION_TASK or something?
> <rwhitby> (since it doesn't have anything to do with MACHINEs)
> <koen> nor with BOOTSTRAP
> <koen> something like DEFAULT_TASK_PROVIDER?
> <rwhitby> yep, DEFAULT_TASK_PROVIDER floats my boat.
> <koen> do you want to write an RFC for that?

The proposal is to replace MACHINE_TASK_PROVIDER with
DEFAULT_TASK_PROVIDER throughout OE, and encourage all image-foo.bb
maintainers to base their image on DEFAULT_TASK_PROVIDER (which can be
set to task-boot, or task-base, or perhaps some other distro-specific
single task-foo value), plus other image-specific stuff.

Comments?  Objections?

BTW, task-bootstrap existence is as follows:

> ./conf/distro/generic.conf:PREFERRED_PROVIDER_task-bootstrap = "task-bootstrap"
> ./conf/distro/include/oplinux.inc:PREFERRED_PROVIDER_task-bootstrap = "task-base"
> ./conf/distro/angstrom-2007.1.conf:PREFERRED_PROVIDER_task-bootstrap = "task-bootstrap"
> ./conf/distro/jlime-donkey.conf:PREFERRED_PROVIDER_task-bootstrap = "task-bootstrap"
> ./conf/distro/openprotium.conf:#PREFERRED_PROVIDER_task-bootstrap = "task-bootstrap"
> ./conf/machine/gumstix.conf:PREFERRED_VERSION_task-bootstrap = "1.0unionroot"
> ./packages/obsolete/tasks/task-bootstrap-unionroot.bb:PROVIDES = "task-bootstrap"
> ./packages/obsolete/tasks/task-bootstrap-unionroot.bb:RPROVIDES = "task-bootstrap"
> ./packages/obsolete/tasks/task-bootstrap-unionroot.bb:require task-bootstrap.inc
> ./packages/obsolete/tasks/task-bootstrap.bb:require task-bootstrap.inc
> ./packages/images/jlime-opie.bb:DEPENDS = "task-bootstrap task-opie"
> ./packages/images/jlime-opie.bb:INSTALL_PACKAGES = "task-bootstrap task-opie-base task-opie-base-applets \
> ./removal.txt:Package Name:   task-bootstrap*

-- Rod



From no2spam at nospam.arcornews.de  Tue May  1 18:04:10 2007
From: no2spam at nospam.arcornews.de (Rolf Leggewie)
Date: Tue, 01 May 2007 20:04:10 +0200
Subject: [oe] RFC: RW access for polyonymous
Message-ID: <f17ves$luc$1@sea.gmane.org>

Hi,

with the amount (and speed!) of patches being provided by Michael 
'polyonymous' Krelin I think it makes sense to give him RW access to OE. 
  His bugs are at http://tinyurl.com/2llfhw

Take a look, comment and decide.

Regards

Rolf




From papercrane at gmail.com  Tue May  1 18:13:20 2007
From: papercrane at gmail.com (Justin Patrin)
Date: Tue, 1 May 2007 11:13:20 -0700
Subject: [oe] [oe-commits] org.oe.dev xtscal: attempt to fix
	miscalibrations
In-Reply-To: <46362F71.7080604@dominion.kabel.utwente.nl>
References: <E1HgoSJ-0008AG-St@linuxtogo.org>
	<462FBE16.9070805@dominion.kabel.utwente.nl>
	<46362F71.7080604@dominion.kabel.utwente.nl>
Message-ID: <432beae0705011113v61831859x7978062963a48b8@mail.gmail.com>

On 4/30/07, Koen Kooi <koen at dominion.kabel.utwente.nl> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Koen Kooi schreef:
> > koen commit schreef:
> >> xtscal: attempt to fix miscalibrations
> >
> > Could people with one of:
> > "HP IPAQ H3600" | "HP IPAQ H3700" | "HP IPAQ H3900" | "HTC Universal" | *COLLIE | *POODLE
> > | *SPITZ | *AKITA | *BORZOI
> >
> > check if calibration isn't 90 degrees of anymore?
> >
> > If not, we most likely need to revert revision d18552e5056a026d8ed8959e135b2fa05c3e1b6b
>
> Hello?

I was just about to test this when my boot into a new image failed
with a missing libgcc. This RPATH issue needs to be fixed ASAP.

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (Darwin)
>
> iD8DBQFGNi9xMkyGM64RGpERAnbdAJ0WirRd/ONKWpIDHDQcO+6EddMx6gCgmoiw
> bF5efxVbVYf2tUEhwMiCMHc=
> =j3Su
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>


-- 
Justin Patrin



From papercrane at gmail.com  Tue May  1 18:13:20 2007
From: papercrane at gmail.com (Justin Patrin)
Date: Tue, 1 May 2007 11:13:20 -0700
Subject: [oe] [oe-commits] org.oe.dev xtscal: attempt to fix
	miscalibrations
In-Reply-To: <46362F71.7080604@dominion.kabel.utwente.nl>
References: <E1HgoSJ-0008AG-St@linuxtogo.org>
	<462FBE16.9070805@dominion.kabel.utwente.nl>
	<46362F71.7080604@dominion.kabel.utwente.nl>
Message-ID: <432beae0705011113v61831859x7978062963a48b8@mail.gmail.com>

On 4/30/07, Koen Kooi <koen at dominion.kabel.utwente.nl> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Koen Kooi schreef:
> > koen commit schreef:
> >> xtscal: attempt to fix miscalibrations
> >
> > Could people with one of:
> > "HP IPAQ H3600" | "HP IPAQ H3700" | "HP IPAQ H3900" | "HTC Universal" | *COLLIE | *POODLE
> > | *SPITZ | *AKITA | *BORZOI
> >
> > check if calibration isn't 90 degrees of anymore?
> >
> > If not, we most likely need to revert revision d18552e5056a026d8ed8959e135b2fa05c3e1b6b
>
> Hello?

I was just about to test this when my boot into a new image failed
with a missing libgcc. This RPATH issue needs to be fixed ASAP.

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (Darwin)
>
> iD8DBQFGNi9xMkyGM64RGpERAnbdAJ0WirRd/ONKWpIDHDQcO+6EddMx6gCgmoiw
> bF5efxVbVYf2tUEhwMiCMHc=
> =j3Su
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>


-- 
Justin Patrin



From oe at hentges.net  Tue May  1 18:20:26 2007
From: oe at hentges.net (Matthias Hentges)
Date: Tue, 01 May 2007 20:20:26 +0200
Subject: [oe] RFC: RW access for polyonymous
In-Reply-To: <f17ves$luc$1@sea.gmane.org>
References: <f17ves$luc$1@sea.gmane.org>
Message-ID: <1178043626.23506.8.camel@localhost.localdomain>

Am Dienstag, den 01.05.2007, 20:04 +0200 schrieb Rolf Leggewie:
> Hi,
> 
> with the amount (and speed!) of patches being provided by Michael 
> 'polyonymous' Krelin I think it makes sense to give him RW access to OE. 
>   His bugs are at http://tinyurl.com/2llfhw

I agree, it's about time ;)
-- 
Matthias 'CoreDump' Hentges 
Cologne / Germany

Webmaster of Hentges.net & Embedded Linux Developer
GPG ->  gpg --keyserver gpg-keyserver.de --recv-keys 0xAF3030D9

My OS: Debian SID: Geek by Nature, Linux by Choice


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
URL: <http://layers.openembedded.org/pipermail/openembedded-devel/attachments/20070501/be3360eb/attachment.sig>

From skoroneos at digital-opsis.com  Tue May  1 18:32:01 2007
From: skoroneos at digital-opsis.com (Stelios Koroneos)
Date: Tue, 1 May 2007 21:32:01 +0300
Subject: [oe] squasfs jffs2 default image settings
In-Reply-To: <4636F787.8030902@whitby.id.au>
Message-ID: <HOECLKEKOHLAMMGDLLBHKEFLKOAA.skoroneos@digital-opsis.com>

After a day of "head scratching" i realized the the reason an image i was
building, failed to load on a powerpc target was that the default settings
for squashfs squashfs-lzma and jffs2 were set to little endian architecture

//snip from  bitbake.conf

EXTRA_IMAGECMD_jffs2 = "--pad --little-endian --eraseblock=0x40000"
EXTRA_IMAGECMD_squashfs = "-le -b 16384"
EXTRA_IMAGECMD_squashfs-lzma = "-le -b 16384"

These look like they were set for a specific machine (maybe i am wrong), but
shouldn't the default settings be at least architecture neutral ?
(Even the block sizes shouldn't be defined there as a machine might be
better suited by another size)

Any objections to have EXTRA_IMAGECMD for these types of images default to
no specific settings  ?

Stelios S. Koroneos

Digital OPSiS - Embedded Inteligence
http://www.digital-opsis.com


> -----Original Message-----
> From: openembedded-devel-bounces at openembedded.org
> [mailto:openembedded-devel-bounces at openembedded.org]On Behalf Of
> Rod Whitby
> Sent: Tuesday, May 01, 2007 11:17 AM
> To: openembedded-devel at openembedded.org
> Subject: [oe] RFC: Rename MACHINE_TASK_PROVIDER to DEFAULT_TASK_PROVIDER
>
>
> > <rwhitby> so in my mokoslug distro, I set MACHINE_TASK_PROVIDER
> to task-boot or task-base, depending on flash size.
> > <rwhitby> what is MACHINE_TASK_PROVIDER really meant to be used for?
> > <koen> to distinguish between task-bootstrap and task-base
> > <rwhitby> does task-bootstrap still exist?
> > <koen> rwhitby: I hope not
> > <rwhitby> koen: so MACHINE_TASK_PROVIDER has no current reason
> for existence then?
> > <rwhitby> (and no definition of what it should be used for if
> it did have a current reason for existence)
> > <koen> rwhitby: not that I know off, but your task-boot
> suggestion would make sense
> > <rwhitby> koen: So it really should now be called something
> like BOOTSTRAP_IMAGE_FOUNDATION_TASK or something?
> > <rwhitby> (since it doesn't have anything to do with MACHINEs)
> > <koen> nor with BOOTSTRAP
> > <koen> something like DEFAULT_TASK_PROVIDER?
> > <rwhitby> yep, DEFAULT_TASK_PROVIDER floats my boat.
> > <koen> do you want to write an RFC for that?
>
> The proposal is to replace MACHINE_TASK_PROVIDER with
> DEFAULT_TASK_PROVIDER throughout OE, and encourage all image-foo.bb
> maintainers to base their image on DEFAULT_TASK_PROVIDER (which can be
> set to task-boot, or task-base, or perhaps some other distro-specific
> single task-foo value), plus other image-specific stuff.
>
> Comments?  Objections?
>
> BTW, task-bootstrap existence is as follows:
>
> > ./conf/distro/generic.conf:PREFERRED_PROVIDER_task-bootstrap =
> "task-bootstrap"
> >
> ./conf/distro/include/oplinux.inc:PREFERRED_PROVIDER_task-bootstra
> p = "task-base"
> >
> ./conf/distro/angstrom-2007.1.conf:PREFERRED_PROVIDER_task-bootstr
> ap = "task-bootstrap"
> >
> ./conf/distro/jlime-donkey.conf:PREFERRED_PROVIDER_task-bootstrap
> = "task-bootstrap"
> >
> ./conf/distro/openprotium.conf:#PREFERRED_PROVIDER_task-bootstrap
> = "task-bootstrap"
> > ./conf/machine/gumstix.conf:PREFERRED_VERSION_task-bootstrap =
> "1.0unionroot"
> > ./packages/obsolete/tasks/task-bootstrap-unionroot.bb:PROVIDES
> = "task-bootstrap"
> > ./packages/obsolete/tasks/task-bootstrap-unionroot.bb:RPROVIDES
> = "task-bootstrap"
> > ./packages/obsolete/tasks/task-bootstrap-unionroot.bb:require
> task-bootstrap.inc
> > ./packages/obsolete/tasks/task-bootstrap.bb:require task-bootstrap.inc
> > ./packages/images/jlime-opie.bb:DEPENDS = "task-bootstrap task-opie"
> > ./packages/images/jlime-opie.bb:INSTALL_PACKAGES =
> "task-bootstrap task-opie-base task-opie-base-applets \
> > ./removal.txt:Package Name:   task-bootstrap*
>
> -- Rod
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>





From no2spam at nospam.arcornews.de  Tue May  1 19:23:42 2007
From: no2spam at nospam.arcornews.de (Rolf Leggewie)
Date: Tue, 01 May 2007 21:23:42 +0200
Subject: [oe] [oe-commits] org.oe.dev xtscal: attempt to fix
	miscalibrations
In-Reply-To: <432beae0705011113v61831859x7978062963a48b8@mail.gmail.com>
References: <E1HgoSJ-0008AG-St@linuxtogo.org>	<462FBE16.9070805@dominion.kabel.utwente.nl>	<46362F71.7080604@dominion.kabel.utwente.nl>
	<432beae0705011113v61831859x7978062963a48b8@mail.gmail.com>
Message-ID: <f1843v$doc$1@sea.gmane.org>

Justin Patrin wrote:
> I was just about to test this when my boot into a new image failed
> with a missing libgcc. This RPATH issue needs to be fixed ASAP.

OK, you got the job ;-)

Serious now, from what I read in bug 2093 I doubt the miscalibration 
issue is fixed yet.




From koen at dominion.kabel.utwente.nl  Tue May  1 19:34:33 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Tue, 01 May 2007 21:34:33 +0200
Subject: [oe] [oe-commits] org.oe.dev xtscal: attempt to
	fix	miscalibrations
In-Reply-To: <f1843v$doc$1@sea.gmane.org>
References: <E1HgoSJ-0008AG-St@linuxtogo.org>	<462FBE16.9070805@dominion.kabel.utwente.nl>	<46362F71.7080604@dominion.kabel.utwente.nl>	<432beae0705011113v61831859x7978062963a48b8@mail.gmail.com>
	<f1843v$doc$1@sea.gmane.org>
Message-ID: <46379649.7040404@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Rolf Leggewie schreef:
> Justin Patrin wrote:
>> I was just about to test this when my boot into a new image failed
>> with a missing libgcc. This RPATH issue needs to be fixed ASAP.
> 
> OK, you got the job ;-)
> 
> Serious now, from what I read in bug 2093 I doubt the miscalibration 
> issue is fixed yet.

The tr was reinstated and the names uppercased, so what else is missing?

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGN5ZJMkyGM64RGpERApJsAJ9c26K2uBv6n8AwMWtgpVZpMJKeswCZAdLG
p7lqRvR2Nj6GBmPu11/q/ik=
=YVAl
-----END PGP SIGNATURE-----



From pmiscml at gmail.com  Tue May  1 20:42:53 2007
From: pmiscml at gmail.com (Paul Sokolovsky)
Date: Tue, 1 May 2007 23:42:53 +0300
Subject: [oe] RFC: RW access for polyonymous
In-Reply-To: <f17ves$luc$1@sea.gmane.org>
References: <f17ves$luc$1@sea.gmane.org>
Message-ID: <361637820.20070501234253@gmail.com>

Hello Rolf,

Tuesday, May 1, 2007, 9:04:10 PM, you wrote:

> Hi,

> with the amount (and speed!) of patches being provided by Michael 
> 'polyonymous' Krelin I think it makes sense to give him RW access to OE.
>   His bugs are at http://tinyurl.com/2llfhw

> Take a look, comment and decide.

        I support this, and would be happy to peer-review Michael's
commits.

> Regards

> Rolf


-- 
Best regards,
 Paul                            mailto:pmiscml at gmail.com




From no2spam at nospam.arcornews.de  Tue May  1 22:15:11 2007
From: no2spam at nospam.arcornews.de (Rolf Leggewie)
Date: Wed, 02 May 2007 00:15:11 +0200
Subject: [oe] [oe-commits] org.oe.dev xtscal: attempt to fix
	miscalibrations
In-Reply-To: <46379649.7040404@dominion.kabel.utwente.nl>
References: <E1HgoSJ-0008AG-St@linuxtogo.org>	<462FBE16.9070805@dominion.kabel.utwente.nl>	<46362F71.7080604@dominion.kabel.utwente.nl>	<432beae0705011113v61831859x7978062963a48b8@mail.gmail.com>	<f1843v$doc$1@sea.gmane.org>
	<46379649.7040404@dominion.kabel.utwente.nl>
Message-ID: <f18e5h$53j$1@sea.gmane.org>

Koen Kooi wrote:
>> Serious now, from what I read in bug 2093 I doubt the miscalibration 
>> issue is fixed yet.
> 
> The tr was reinstated and the names uppercased, so what else is missing?

polynonymous wrote that he needed mixed case.  But I have no first hand 
knowledge of how to fix this, yet.




From rod at whitby.id.au  Wed May  2 00:05:10 2007
From: rod at whitby.id.au (Rod Whitby)
Date: Wed, 02 May 2007 09:35:10 +0930
Subject: [oe] squasfs jffs2 default image settings
In-Reply-To: <HOECLKEKOHLAMMGDLLBHKEFLKOAA.skoroneos@digital-opsis.com>
References: <HOECLKEKOHLAMMGDLLBHKEFLKOAA.skoroneos@digital-opsis.com>
Message-ID: <4637D5B6.4060305@whitby.id.au>

Stelios Koroneos wrote:
> After a day of "head scratching" i realized the the reason an image i was
> building, failed to load on a powerpc target was that the default settings
> for squashfs squashfs-lzma and jffs2 were set to little endian architecture
> 
> //snip from  bitbake.conf
> 
> EXTRA_IMAGECMD_jffs2 = "--pad --little-endian --eraseblock=0x40000"
> EXTRA_IMAGECMD_squashfs = "-le -b 16384"
> EXTRA_IMAGECMD_squashfs-lzma = "-le -b 16384"
> 
> These look like they were set for a specific machine (maybe i am wrong), but
> shouldn't the default settings be at least architecture neutral ?
> (Even the block sizes shouldn't be defined there as a machine might be
> better suited by another size)
> 
> Any objections to have EXTRA_IMAGECMD for these types of images default to
> no specific settings  ?

Fine with me.  I think the nslu2 and ixp4xx are the few dual-endian
machines in OE, and both of them are already set up to set the
endianness, padding and block size on those commands explicitly.

-- Rod



From lenehan at twibble.org  Wed May  2 00:36:41 2007
From: lenehan at twibble.org (Jamie Lenehan)
Date: Wed, 2 May 2007 10:36:41 +1000
Subject: [oe] perl 5.8.8 is ready
In-Reply-To: <4636CCC0.1010109@gmail.com>
References: <20070427105722.GA4340@twibble.org> <46359408.9060800@gmail.com>
	<20070430080044.GA15877@twibble.org> <4636CCC0.1010109@gmail.com>
Message-ID: <20070502003641.GA5189@twibble.org>

On Tue, May 01, 2007 at 12:14:40AM -0500, Junqian Gordon Xu wrote:
> Thanks. I fixed the hostperl problem.
> 
> Don't know why. Even I commented out the DEFAULT_PREFERENCE = "-1", 
> bitbake still try to get perl-5.8.7 compiled first
> 
> NOTE: package perl-5.8.8-r8: task do_unpack: completed
> NOTE: package perl-5.8.8: completed
> NOTE: Running task 285 of 302 (ID: 130, 
> /home/OE/org.openembedded.dev/packages/perl/perl_5.8.7.bb, do_fetch)
> NOTE: package perl-5.8.7: started
> NOTE: package perl-5.8.7-r22: task do_fetch: started

This turns out to be an error on my part in perl 5.8.8 - I didn't
tell bitbake that perl 5.8.8 was providing all the perl modules. So
when something needed perl-modules (because of a DEPEND or RDEPEND)
it found that perl 5.8.8 provided them while 5.8.8 didn't.

If you had perl 5.8.7 already compiled and lying around you didn't
notice this issue. Since I've been building and testing changes for
both version I had 5.8.7 and 5.8.8 always compiled.

Anyway, I just checked in a fix for this so it should be ok now.

> Besides, I noticed another issue:
> I had linux-libc-headers-2.6.15.99 compiled (I think it's determined 
> Machine and Distro) . But perl-5.8.8 wants linux-libc-headers-2.6.20. 
> Will that cause problem?

Perl shouldn't care about linux-libc-headers, I use 2.6.15.99 here at
the moment.

Thanks.

-- 
 Jamie Lenehan <lenehan at twibble.org>



From xjqian at gmail.com  Wed May  2 04:05:58 2007
From: xjqian at gmail.com (Junqian Gordon Xu)
Date: Tue, 01 May 2007 23:05:58 -0500
Subject: [oe] perl 5.8.8 is ready
In-Reply-To: <20070502003641.GA5189@twibble.org>
References: <20070427105722.GA4340@twibble.org> <46359408.9060800@gmail.com>
	<20070430080044.GA15877@twibble.org> <4636CCC0.1010109@gmail.com>
	<20070502003641.GA5189@twibble.org>
Message-ID: <46380E26.6070303@gmail.com>

Jamie Lenehan wrote:
> On Tue, May 01, 2007 at 12:14:40AM -0500, Junqian Gordon Xu wrote:
>   
> This turns out to be an error on my part in perl 5.8.8 - I didn't
> tell bitbake that perl 5.8.8 was providing all the perl modules. So
> when something needed perl-modules (because of a DEPEND or RDEPEND)
> it found that perl 5.8.8 provided them while 5.8.8 didn't.
>
> If you had perl 5.8.7 already compiled and lying around you didn't
> notice this issue. Since I've been building and testing changes for
> both version I had 5.8.7 and 5.8.8 always compiled.
>
> Anyway, I just checked in a fix for this so it should be ok now.
>
>   
I can confirm with the latest mtn pull, perl-5.8.8 builds fine for me 
here except for some warning signs:

NOTE: package perl-5.8.8: started
NOTE: package perl-5.8.8-r10: task do_package: started
NOTE: perl-lib contains dangling symlink to /usr/lib/perl/5.8.8
NOTE: perl-lib contains dangling symlink to /usr/share/perl/5.8.8
NOTE: Couldn't find shared library provider for libgcc_s.so.1
NOTE: Couldn't find shared library provider for libgcc_s.so.1

>> Besides, I noticed another issue:
>> I had linux-libc-headers-2.6.15.99 compiled (I think it's determined 
>> Machine and Distro) . But perl-5.8.8 wants linux-libc-headers-2.6.20. 
>> Will that cause problem?
>>     
>
> Perl shouldn't care about linux-libc-headers, I use 2.6.15.99 here at
> the moment.
However, this issue is still outstanding. I'm trying to understand where 
the 2.6.20 dependency is coming from. Is this a bitbake issue?

bitbake perl:

OE Build Configuration:
BB_VERSION     = "1.8.3"
OE_REVISION    = "3ea77972dcf422ed70f1a083c412f43ab519f474"
TARGET_ARCH    = "arm"
TARGET_OS      = "linux-gnueabi"
MACHINE        = "tosa"
DISTRO         = "angstrom"
DISTRO_VERSION = "test-20070502"
TARGET_FPU     = "soft"

NOTE: Resolving missing task queue dependencies
NOTE: preferred version 2.5 of glibc not available (for item 
virtual/arm-angstrom-linux-gnueabi-libc-for-gcc)
NOTE: Preparing Runqueue
NOTE: Executing runqueue
NOTE: Running task 115 of 294 (ID: 131, 
/home/OE/org.openembedded.dev/packages/linux-libc-headers/linux-libc-headers_2.6.20.bb, 
do_fetch)
NOTE: package linux-libc-headers-2.6.20: started



From no2spam at nospam.arcornews.de  Wed May  2 15:48:45 2007
From: no2spam at nospam.arcornews.de (Rolf Leggewie)
Date: Wed, 02 May 2007 17:48:45 +0200
Subject: [oe] upgrade "policy"
Message-ID: <f1absu$4no$1@sea.gmane.org>

Hi,

I would like to bring to your attention the powers of "mtn mv" when 
upgrading packages.  I have written up a little HOWTO at 
http://www.openembedded.org/upgradingpackages which I would consider 
"best practice" rather than policy.  I hope you all approve of this.

Regards

Rolf




From rodrigo.vivi at gmail.com  Wed May  2 18:04:39 2007
From: rodrigo.vivi at gmail.com (Rodrigo Vivi)
Date: Wed, 2 May 2007 15:04:39 -0300
Subject: [oe] generating debian source packages (dsc)
Message-ID: <bdb0025f0705021104x23d2c407rb4da0e48e24eb911@mail.gmail.com>

Hi all,

I'm trying to code a bbclass to build debian source packages, because
I need these files under mamona repository:

 * .dsc - debian source package control file
 * .orig.tar.gz - Original source package
 * .diff.gz - patches that we apply

Since this is my first bbclass I need some help to figure some doubts out.

first of all I've created a package_dsc task and added it before do_configure.

This task creates the debian/control and debian/changelog file that
dpkg-source ask for dsc generation. I know that I need to generate the
debian/rules file too because without it the dsc will not be usefull.
But this is not my real problem yet.

The current problem that I'm trying to solve and need help is the following:

before the do_configure all packages have a .pc dir that is not under
orig.tar.gz file neither inside some patch breaking the dpkg-source
but that is pretty easy to ignore doing
$dpkg-source -i"\.pc" ...
But glibc has a ports directory that is not under orig.tar.gz neither
under patches so I need to ignore this file too. And I know that is
NOT a good idea to ignore it doing
dpkg-source  -i"\.pc|ports"
And I've noticed that there are another files that breaks dpkg-source...
like util-linux_2.12r-12.diff.gz under patches dir of util-linux

I'm thinking to create a exclude-list or a dictionary to have an
exclude-list for each package. What do you thing about it? Do you know
a better and simplest way to do this?

I'm anexing my bbclass file in case you want to have a look and help me! ;)

Thanks,
Best Regards,
Vivi.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gen_dsc.bbclass
Type: application/octet-stream
Size: 6393 bytes
Desc: not available
URL: <http://layers.openembedded.org/pipermail/openembedded-devel/attachments/20070502/1191fe55/attachment.obj>

From openembedded at hrw.one.pl  Wed May  2 18:51:02 2007
From: openembedded at hrw.one.pl (Marcin Juszkiewicz)
Date: Wed, 2 May 2007 20:51:02 +0200
Subject: [oe] generating debian source packages (dsc)
In-Reply-To: <bdb0025f0705021104x23d2c407rb4da0e48e24eb911@mail.gmail.com>
References: <bdb0025f0705021104x23d2c407rb4da0e48e24eb911@mail.gmail.com>
Message-ID: <200705022051.03720.openembedded@hrw.one.pl>

Dnia ?roda, 2 maja 2007, Rodrigo Vivi napisa?:
> Hi all,
>
> I'm trying to code a bbclass to build debian source packages, because
> I need these files under mamona repository:
>
>  * .dsc - debian source package control file
>  * .orig.tar.gz - Original source package
>  * .diff.gz - patches that we apply
>
> Since this is my first bbclass I need some help to figure some doubts
> out.

classes/sourcepkg.bbclass is something which you want to extend

-- 
JID: hrw-jabber.org
OpenEmbedded developer/consultant

      I'm trying to decide if I should kill you or simply feign death
      until you feel awkward and leave.





From rodrigo.vivi at gmail.com  Wed May  2 19:52:54 2007
From: rodrigo.vivi at gmail.com (Rodrigo Vivi)
Date: Wed, 2 May 2007 16:52:54 -0300
Subject: [oe] generating debian source packages (dsc)
In-Reply-To: <200705022051.03720.openembedded@hrw.one.pl>
References: <bdb0025f0705021104x23d2c407rb4da0e48e24eb911@mail.gmail.com>
	<200705022051.03720.openembedded@hrw.one.pl>
Message-ID: <bdb0025f0705021252w7e32b305ybf9c914c1cb1edc0@mail.gmail.com>

> classes/sourcepkg.bbclass is something which you want to extend

I've thought about it but I'm not sure that it is a good idea because
just few projects (or just mine) needs the dsc file .......... unless
that I code another sourcedsc.bbclass that inherit the
sourcedpkg.bbclass... o you think that it will work???  I'll think
about it...

Another doubt that I forgot to mention on last email is about changelog:
I'm generating a almost empty changelog file. Is there any official
and/or more appropriated way to do that?

Thanks,
Vivi.

>
> --
> JID: hrw-jabber.org
> OpenEmbedded developer/consultant
>
>       I'm trying to decide if I should kill you or simply feign death
>       until you feel awkward and leave.
>
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>



From papercrane at gmail.com  Wed May  2 20:38:54 2007
From: papercrane at gmail.com (Justin Patrin)
Date: Wed, 2 May 2007 13:38:54 -0700
Subject: [oe] generating debian source packages (dsc)
In-Reply-To: <bdb0025f0705021252w7e32b305ybf9c914c1cb1edc0@mail.gmail.com>
References: <bdb0025f0705021104x23d2c407rb4da0e48e24eb911@mail.gmail.com>
	<200705022051.03720.openembedded@hrw.one.pl>
	<bdb0025f0705021252w7e32b305ybf9c914c1cb1edc0@mail.gmail.com>
Message-ID: <432beae0705021338x7ca36c0oc937a6b1b03f6db5@mail.gmail.com>

On 5/2/07, Rodrigo Vivi <rodrigo.vivi at gmail.com> wrote:
> > classes/sourcepkg.bbclass is something which you want to extend
>
> I've thought about it but I'm not sure that it is a good idea because
> just few projects (or just mine) needs the dsc file .......... unless
> that I code another sourcedsc.bbclass that inherit the
> sourcedpkg.bbclass... o you think that it will work???  I'll think
> about it...
>

Yes, this is what Marcin meant. Create your own sourcedsc.bbclass
which inherits sourcepkg.bbclass. This is how, for example,
efl.bbclass and e.bbclass work.

> Another doubt that I forgot to mention on last email is about changelog:
> I'm generating a almost empty changelog file. Is there any official
> and/or more appropriated way to do that?
>
> Thanks,
> Vivi.
>
> >
> > --
> > JID: hrw-jabber.org
> > OpenEmbedded developer/consultant
> >
> >       I'm trying to decide if I should kill you or simply feign death
> >       until you feel awkward and leave.
> >
> >
> >
> > _______________________________________________
> > Openembedded-devel mailing list
> > Openembedded-devel at lists.openembedded.org
> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> >
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>


-- 
Justin Patrin



From pmiscml at gmail.com  Thu May  3 12:47:32 2007
From: pmiscml at gmail.com (Paul Sokolovsky)
Date: Thu, 3 May 2007 15:47:32 +0300
Subject: [oe] [ALERT] Security vulnerability with recent OE bitbake.conf
	changes
Message-ID: <35653307.20070503154732@gmail.com>

Hello openembedded-devel,

A commit made some time ago,

http://lists.linuxtogo.org/pipermail/openembedded-commits/2007-April/004912.html

introduced a hole which may lead to unnoticed security vulnerabilities
slipping into the packages/images produced. Specifically, it defines a
random application of a random suite to be used for resolving patching
conflicts/failures. If you don't happen to have that random tool,
patching failure will be silently swallowed, leading to any adverse
effects imaginable - from compile failure to the mentioned security
vulnerabilities.

Proposed solutions:

1. Bring back some reality and switch back to previous default of
dropping to standard shell for resolution:

-TERMCMD ?= "${GNOME_TERMCMD}"
-TERMCMDRUN ?= "${GNOME_TERMCMDRUN}"
+TERMCMD ?= "${SHELLRCCMD}"
+TERMCMDRUN ?= "${SHELLRCCMD}"


2. Add DEPENDS on that random tool, namely gnome-terminal.

If going with choice 2, I proposed also to do the following: 1) add
depends on xine, mplayer, totem, few other video players; 2) add depends
on mesa and show nice 3d rotating menu to select player of user choice;
3) use selected player to show video during the build - after all,
if user deserves comfort of using superfluous GUI tools for conflict
resolution, why one should be bored during normal build process?


Thanks,

-- 
 Paul                          mailto:pmiscml at gmail.com




From rpurdie at rpsys.net  Thu May  3 13:07:08 2007
From: rpurdie at rpsys.net (Richard Purdie)
Date: Thu, 03 May 2007 14:07:08 +0100
Subject: [oe] [ALERT] Security vulnerability with recent OE
	bitbake.conf	changes
In-Reply-To: <35653307.20070503154732@gmail.com>
References: <35653307.20070503154732@gmail.com>
Message-ID: <1178197628.6312.22.camel@localhost.localdomain>

On Thu, 2007-05-03 at 15:47 +0300, Paul Sokolovsky wrote:
> If going with choice 2, I proposed also to do the following: 1) add
> depends on xine, mplayer, totem, few other video players; 2) add depends
> on mesa and show nice 3d rotating menu to select player of user choice;
> 3) use selected player to show video during the build - after all,
> if user deserves comfort of using superfluous GUI tools for conflict
> resolution, why one should be bored during normal build process?

Paul,

Is there really any need for this?

It doesn't encourage me to give a sensible reply, does it...

Richard




From rpurdie at rpsys.net  Thu May  3 13:16:39 2007
From: rpurdie at rpsys.net (Richard Purdie)
Date: Thu, 03 May 2007 14:16:39 +0100
Subject: [oe] [ALERT] Security vulnerability with recent OE
	bitbake.conf	changes
In-Reply-To: <35653307.20070503154732@gmail.com>
References: <35653307.20070503154732@gmail.com>
Message-ID: <1178198199.6312.30.camel@localhost.localdomain>

On Thu, 2007-05-03 at 15:47 +0300, Paul Sokolovsky wrote:
> Hello openembedded-devel,
> 
> A commit made some time ago,
> 
> http://lists.linuxtogo.org/pipermail/openembedded-commits/2007-April/004912.html
> 
> introduced a hole which may lead to unnoticed security vulnerabilities
> slipping into the packages/images produced. Specifically, it defines a
> random application of a random suite to be used for resolving patching
> conflicts/failures. If you don't happen to have that random tool,
> patching failure will be silently swallowed, leading to any adverse
> effects imaginable - from compile failure to the mentioned security
> vulnerabilities.

Patch failure should not be silently swallowed, the builds should abort.
If they don't, we need to fix that underlying problem.

FWIW, your first solution using SHELLRCCMD won't actually work due to
the way IO redirection is done in recent bitbake. 

Your second solution of adding the DEPENDS is impractical due to the
amount of -native packages it would require.

So we need to find the real problem and fix that, probably somewhere in
patch.bbclass an error code isn't being propagated at a guess.

I will also hint at the use of PATCH_RESOLVER = "noop" which means the
user gets the old behaviour of patch failure aborts the build with no
help from any resolver. It should have always been the default but
wasn't. I'm not sure what the current default is but we can change it to
that if its not.

Cheers,

Richard




From pmiscml at gmail.com  Thu May  3 13:42:06 2007
From: pmiscml at gmail.com (Paul Sokolovsky)
Date: Thu, 3 May 2007 16:42:06 +0300
Subject: [oe] [ALERT] Security vulnerability with recent OE bitbake.conf
	changes
In-Reply-To: <1178198199.6312.30.camel@localhost.localdomain>
References: <35653307.20070503154732@gmail.com>
	<1178198199.6312.30.camel@localhost.localdomain>
Message-ID: <183568912.20070503164206@gmail.com>

Hello Richard,

Thursday, May 3, 2007, 4:16:39 PM, you wrote:

> On Thu, 2007-05-03 at 15:47 +0300, Paul Sokolovsky wrote:
>> Hello openembedded-devel,
>> 
>> A commit made some time ago,
>> 
>> http://lists.linuxtogo.org/pipermail/openembedded-commits/2007-April/004912.html
>> 
>> introduced a hole which may lead to unnoticed security vulnerabilities
>> slipping into the packages/images produced. Specifically, it defines a
>> random application of a random suite to be used for resolving patching
>> conflicts/failures. If you don't happen to have that random tool,
>> patching failure will be silently swallowed, leading to any adverse
>> effects imaginable - from compile failure to the mentioned security
>> vulnerabilities.


[]

> Is there really any need for this?
> It doesn't encourage me to give a sensible reply, does it...

        Apparently no. But for me, it's pretty clear that even
gnome-terminal shouldn't be used by default, and in expectation of
hardnesses regarding arguing this, I tried to draw picturesquely
absurd "extension", overspiced with few buzzwords. It's of course a
mere small bug otherwise, but I truly looking for solution which won't
by default trouble KDE, other WMs, and classy console guys in favor of
GNOME crowd.


> Patch failure should not be silently swallowed, the builds should abort.
> If they don't, we need to fix that underlying problem.

        Yes, I didn't even bother to ruin my pamphlet with such
down-to-earth triviality ;-). I'd be looking into it as time permits
of course.

> FWIW, your first solution using SHELLRCCMD won't actually work due to
> the way IO redirection is done in recent bitbake. 

> Your second solution of adding the DEPENDS is impractical due to the
> amount of -native packages it would require.

> So we need to find the real problem and fix that, probably somewhere in
> patch.bbclass an error code isn't being propagated at a guess.

> I will also hint at the use of PATCH_RESOLVER = "noop" which means the
> user gets the old behaviour of patch failure aborts the build with no
> help from any resolver. It should have always been the default but
> wasn't. I'm not sure what the current default is but we can change it to
> that if its not.

        Ack, and vote for. Let's have defaults not overloaded with
interactivity, and working along the lines of standard unix/posix
build tools. Frontends, likes one(s) you work on, can have own
config/overrides then. (And few people won't used them anyway, no
matter which potential benefits they give - and not out of
bare-commandline orthodoxy, but because they may have other frontends
relying on classical unix behavior of tools).

> Cheers,

> Richard



-- 
Best regards,
 Paul                            mailto:pmiscml at gmail.com




From leon.woestenberg at gmail.com  Fri May  4 16:19:58 2007
From: leon.woestenberg at gmail.com (Leon Woestenberg)
Date: Fri, 4 May 2007 18:19:58 +0200
Subject: [oe] task-base dependencies and missing logging of failed providers
Message-ID: <c384c5ea0705040919u8bdafe9sa6abe0942ffe3fd8@mail.gmail.com>

Hello,

just wanted to get this down for those not having followed the
discussion on IRC (and just for the record, not that the ideas are
still fresh).

My idea about a minimal image that OE should support (Goal: OE must be
scalable) is a linux kernel with a single init application
(helloworld).

Today on IRC we discussed two issues with BB/OE, indirectly blocking
the ability to build a minimal image using task-base, especially for
new users.

(1) task-base always wants *all* targets in task-* to be buildable,
regardless whether they are installed or not.

Example:

Take angstrom, strip {MACHINE,DISTRO}_FEATURES such that
COMBINED_FEATURES="ext2" or something really basic.
Set USE_NLS="no"

When now building angstrom-minimal-image, task-base wants bluetooth to
be buildable, thus bluez-utils, thus dbus, cups, glib-2.0, etc. etc.
Because glib-2.0 requires USE_NLS="yes", the image build fails with "a
no providers for" message.

[10:34]	<v8jlene>	likewise: Yeah, that task-base one's a bit annoying.
I only had about 400 recipes symlinked in, now I have them all just to
make task-base happy. And as you say it's building lots of stuff that
you don't use.

Workarounds:
- USE_NLS_glib-2.0="yes" (yes, at least makes image buildable, IFF the
other deps are met, everything is still built)

Suggested fixes:
- split task-base into seperate *.bb would work (koen, hrw), but this
is not the proper solution (RP, koen)
- do not use debian.bbclass (tried, but does not work for me)
- ...

(2) It's very hard to track down and I'm not alone:

[10:29]	<v8jlene>	likewise: Heh, I had that issue yesterday when
trying my uclibc builds with 1.8.2 ;) The error bitbake showed was
about bootstrap-image was unavailable (due to task-base pulling in
cups which pulled in dbus which pulled in glib-2.0). Took ages to
figure it all out...

New users won't find this, as bitbake -D -D -D -v does not provide this info.

2) bitbake will NOT report the above dependency
logging of failed providers

However, this one is hard to fix:

[10:31]	<RP>	likewise: There is a bitbake bug already open about the
logging of failed providers
[10:31]	<RP>	Its not as simple as it sounds though


Reproduce

taking the ?ngstr?m distro as a base, I would like to strip it down a
bit. I stripped {MACHINE,DISTRO}_FEATURES such that:

COMBINED_FEATURES="ext2"
DISTRO_EXTRA_RDEPENDS="update-modules module-init-tools
modutils-initscripts sysvinit initscripts sysvinit-pidof netbase
dropbear ipkg ipkg-collateral util-linux-mount util-linux-umount"

As none of the selected package need NLS, I have disabled it.

USE_NLS = "no"

bitbake angstrom-minimal image
or
bitbake bootstrap-image


Regards,
-- 
Leon

The persons and animals named in this email are based on true
characters in real life.



From cailotto at sci.univr.it  Fri May  4 10:33:10 2007
From: cailotto at sci.univr.it (Stefano Cailotto)
Date: Fri, 4 May 2007 12:33:10 +0200
Subject: [oe] OE on Kontron eb425
Message-ID: <002a01c78e37$9d165360$38f21b9d@kai>

Hi all, 
I'm trying to build something usable for a kontron eb425 board, based on an
intel ixp425.
I tried to compile using a generic ixp4xxbe, but when loading, the kernel
stops after uncompressing reporting a CRC error.
It seems that Kontron EmbeddedLinux development kit performs something on
the kernel before making zImage in order to load it in a specifed memory
location.
I'd like to use OE, anyway, so my questions are:
1) has anyone faced my same problem (possibly with positive results)?
2) is there away to "port" kontron configuration inside OE?I'm looking to
understand how...

Thanx, 
Stefano


---------------------------------------------------------------------------
  Stefano Cailotto - Research Consultant
---------------------------------------------------------------------------
  EDALab - Networked Embedded Systems
  c/o  Dipartimento di Informatica - Universita` di Verona
  Strada le Grazie, 15 - 37134 Verona (Italy)
---------------------------------------------------------------------------
  email: cailotto at sci.univr.it stefano.cailotto at edalab.it      
  web:  http://www.edalab.it
  tel: +39-045-802-7062 fax: +39-045-802-7068
---------------------------------------------------------------------------




From leon.woestenberg at gmail.com  Sat May  5 12:35:22 2007
From: leon.woestenberg at gmail.com (Leon Woestenberg)
Date: Sat, 5 May 2007 14:35:22 +0200
Subject: [oe] OE on Kontron eb425
In-Reply-To: <002a01c78e37$9d165360$38f21b9d@kai>
References: <002a01c78e37$9d165360$38f21b9d@kai>
Message-ID: <c384c5ea0705050535i1c13cc5ase333da9be4d6cf8e@mail.gmail.com>

Hello Stefano,

On 5/4/07, Stefano Cailotto <cailotto at sci.univr.it> wrote:
> Hi all,
> I'm trying to build something usable for a kontron eb425 board, based on an
> intel ixp425.
> I tried to compile using a generic ixp4xxbe, but when loading, the kernel
> stops after uncompressing reporting a CRC error.
> It seems that Kontron EmbeddedLinux development kit performs something on
> the kernel before making zImage in order to load it in a specifed memory
> location.
>
There are some IXP42x users on OE, mostly for the NSLU device from
Linksys/Cisco, the Intel dev board (IXDP425) and some custom boards,
but I have not see the Kontron board yet.

With the reported problem, it would help if you understand or at least
could tell where to find the details on the boot loader.

Ideally, you would want to boot loader to be buildable from source
instead of relying on some binary on flash.

Regards,

Leon.



From repvik at kynisk.com  Sat May  5 13:46:45 2007
From: repvik at kynisk.com (=?iso-8859-1?q?=D8yvind_Repvik?=)
Date: Sat, 5 May 2007 15:46:45 +0200
Subject: [oe] OE on Kontron eb425
In-Reply-To: <c384c5ea0705050535i1c13cc5ase333da9be4d6cf8e@mail.gmail.com>
References: <002a01c78e37$9d165360$38f21b9d@kai>
	<c384c5ea0705050535i1c13cc5ase333da9be4d6cf8e@mail.gmail.com>
Message-ID: <200705051546.46019.repvik@kynisk.com>

On Saturday 05 May 2007 14:35:22 Leon Woestenberg wrote:
> Hello Stefano,
>
> On 5/4/07, Stefano Cailotto <cailotto at sci.univr.it> wrote:
> > Hi all,
> > I'm trying to build something usable for a kontron eb425 board, based on
> > an intel ixp425.
> > I tried to compile using a generic ixp4xxbe, but when loading, the kernel
> > stops after uncompressing reporting a CRC error.
> > It seems that Kontron EmbeddedLinux development kit performs something on
> > the kernel before making zImage in order to load it in a specifed memory
> > location.
>
> There are some IXP42x users on OE, mostly for the NSLU device from
> Linksys/Cisco, the Intel dev board (IXDP425) and some custom boards,
> but I have not see the Kontron board yet.
>
> With the reported problem, it would help if you understand or at least
> could tell where to find the details on the boot loader.

A very important detail is which MACH ID the bootloader passes via ATAG.

Regards,
?yvind



From koen at dominion.kabel.utwente.nl  Sat May  5 14:54:52 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Sat, 05 May 2007 16:54:52 +0200
Subject: [oe] Questions: Founding of Open Embedded, dev gatherings etc.
In-Reply-To: <200705041909.29494.kyrvin@trolltech.com>
References: <200705041909.29494.kyrvin@trolltech.com>
Message-ID: <463C9ABC.7090503@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Knut Yrvin schreef:
> Hi all :)
> 
> At FOSDEM I talked with Gerwin van der Kruis about Trolltech helping Open 
> Embedded getting started with developer gatherings and a foundation. 
> 
> I got some experiences with developer gatherings after initiationg the 
> Skolelinux project in 2001. Actually we have organised +30 gatherings. 
> Skolelinux is now a part of DebianEdu. The board of "Free Software in School" 
> organises about 6-7 developer gatherings a year. Pictures from opening of one 
> of the gatherings in Forbach - France, gives an idea of the scale: 
> 
> http://www.bawetic.be/PHOTOS/Forbach2006/
> 
> I would like to see similar activeties in OpenEmbedded space. Maybe Mobile 
> Developer Days 2007 at Alborg University in Denmark could be the place to 
> start?: 
> 
> http://mobiledevices.kom.aau.dk/team_and_organization/events/mobile_developer_days_2007/
> 
> To sum it up. Gerwin van der Kruis idea is to make a foundation, and getting  
> dev.gatherings started. Is this interesting for you? If you are interesed, 
> how should we proceed?

We are certainly interested! At the moment a big part of our core developers is on
holiday, moving appartments, doing examns, etc, so we'll get back to you in a few days.

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGPJq8MkyGM64RGpERApcQAJ9DBG3lBC15R7vs86XeN2DE7UZoGACeIs/R
C1jgdp0EigJhbElqYG+U7Og=
=lH/J
-----END PGP SIGNATURE-----



From koen at dominion.kabel.utwente.nl  Sat May  5 15:11:37 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Sat, 05 May 2007 17:11:37 +0200
Subject: [oe] RFC: make do_install and do_deploy a PACKAGE_FUNC
Message-ID: <463C9EA9.2060302@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Lately there have been several problems with files not getting packaged, because users
resumed builds after a failure. Richard has come up with a fix:

http://www.rpsys.net/openzaurus/temp/oe-install-change.patch

The only bug with that patch is that do_deploy fails, which can be solved by making that a
 PACKAGE_FUNC as well.

What do you think about that?

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGPJ6pMkyGM64RGpERAs9xAKC7qGcvY8E9wGMsp/o/2MQO/pIMmACeKknh
HcvgGS6egpiNlqq9Zx5eQO8=
=CUmR
-----END PGP SIGNATURE-----



From manuel.teira at telefonica.net  Sun May  6 20:17:51 2007
From: manuel.teira at telefonica.net (Manuel Teira)
Date: Sun, 06 May 2007 22:17:51 +0200
Subject: [oe] gstreamer obsoleted recipes
Message-ID: <1178482671.6132.10.camel@localhost>

Hello all.

I've recently added some recipes for gstreamer and gst-plugins-[good|
bad|ugly|...] in order to build the last stable releases of this
software. I've seen that there are a lot of "old" stable releases that
if nobody is needing, we could sanely delete from the repository.

My plan is to only left the last stable version for all the related
packages, so, we would keep only the following recipes, in the directory
gstreamer:

gst-ffmpeg_0.10.2.bb
gst-plugins-base_0.10.12.bb
gst-plugins-good_0.10.5.bb
gst-plugins-ugly_0.10.5.bb
gstreamer_0.10.12.bb

The only distro that seems to depend on  a fixed gstreamer version
(0.10.11) is angstrom. But I assume that we can upgrade that requirement
to 0.10.12 without problems.

If nobody disagree, I will proceed with the gstreamer cleanup the next
week.

Best regards.





From koen at dominion.kabel.utwente.nl  Sun May  6 20:38:32 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Sun, 06 May 2007 22:38:32 +0200
Subject: [oe] gstreamer obsoleted recipes
In-Reply-To: <1178482671.6132.10.camel@localhost>
References: <1178482671.6132.10.camel@localhost>
Message-ID: <463E3CC8.10407@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Manuel Teira schreef:
> Hello all.
> 
> I've recently added some recipes for gstreamer and gst-plugins-[good|
> bad|ugly|...] in order to build the last stable releases of this
> software. I've seen that there are a lot of "old" stable releases that
> if nobody is needing, we could sanely delete from the repository.
> 
> My plan is to only left the last stable version for all the related
> packages, so, we would keep only the following recipes, in the directory
> gstreamer:
> 
> gst-ffmpeg_0.10.2.bb
> gst-plugins-base_0.10.12.bb
> gst-plugins-good_0.10.5.bb
> gst-plugins-ugly_0.10.5.bb
> gstreamer_0.10.12.bb
> 
> The only distro that seems to depend on  a fixed gstreamer version
> (0.10.11) is angstrom. But I assume that we can upgrade that requirement
> to 0.10.12 without problems.

Yes, it's safe, angstrom only had those versions locked down to select 0.10 over 0.8, but
0.8 is gone now, so those preferred_versions should be safe to remove.

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGPjzIMkyGM64RGpERAky3AJ4t1RemMlENfVNDI1pdPIpIkBqJNwCfTIoq
DazvNQqprOC1w9bC1hRehq4=
=6F9d
-----END PGP SIGNATURE-----



From papercrane at gmail.com  Mon May  7 04:29:26 2007
From: papercrane at gmail.com (Justin Patrin)
Date: Sun, 6 May 2007 21:29:26 -0700
Subject: [oe] [ALERT] Security vulnerability with recent OE bitbake.conf
	changes
In-Reply-To: <1178198199.6312.30.camel@localhost.localdomain>
References: <35653307.20070503154732@gmail.com>
	<1178198199.6312.30.camel@localhost.localdomain>
Message-ID: <432beae0705062129i11f69731n1d12777f46a83316@mail.gmail.com>

On 5/3/07, Richard Purdie <rpurdie at rpsys.net> wrote:
> On Thu, 2007-05-03 at 15:47 +0300, Paul Sokolovsky wrote:
> > Hello openembedded-devel,
> >
> > A commit made some time ago,
> >
> > http://lists.linuxtogo.org/pipermail/openembedded-commits/2007-April/004912.html
> >
> > introduced a hole which may lead to unnoticed security vulnerabilities
> > slipping into the packages/images produced. Specifically, it defines a
> > random application of a random suite to be used for resolving patching
> > conflicts/failures. If you don't happen to have that random tool,
> > patching failure will be silently swallowed, leading to any adverse
> > effects imaginable - from compile failure to the mentioned security
> > vulnerabilities.
>
> Patch failure should not be silently swallowed, the builds should abort.
> If they don't, we need to fix that underlying problem.
>
> FWIW, your first solution using SHELLRCCMD won't actually work due to
> the way IO redirection is done in recent bitbake.
>
> Your second solution of adding the DEPENDS is impractical due to the
> amount of -native packages it would require.
>
> So we need to find the real problem and fix that, probably somewhere in
> patch.bbclass an error code isn't being propagated at a guess.
>
> I will also hint at the use of PATCH_RESOLVER = "noop" which means the
> user gets the old behaviour of patch failure aborts the build with no
> help from any resolver. It should have always been the default but
> wasn't. I'm not sure what the current default is but we can change it to
> that if its not.
>

Ummm...where? I tried that in my local.conf and it did nothing. I've
also grepped for PATCH_RESOLVER in both bitbake and oe and found
nothing.

Please, let's remove the gnome-terminal default, it makes no sense to
assume that the lowest common denominator is running bitbake from X...

-- 
Justin Patrin



From papercrane at gmail.com  Mon May  7 04:29:26 2007
From: papercrane at gmail.com (Justin Patrin)
Date: Sun, 6 May 2007 21:29:26 -0700
Subject: [oe] [ALERT] Security vulnerability with recent OE bitbake.conf
	changes
In-Reply-To: <1178198199.6312.30.camel@localhost.localdomain>
References: <35653307.20070503154732@gmail.com>
	<1178198199.6312.30.camel@localhost.localdomain>
Message-ID: <432beae0705062129i11f69731n1d12777f46a83316@mail.gmail.com>

On 5/3/07, Richard Purdie <rpurdie at rpsys.net> wrote:
> On Thu, 2007-05-03 at 15:47 +0300, Paul Sokolovsky wrote:
> > Hello openembedded-devel,
> >
> > A commit made some time ago,
> >
> > http://lists.linuxtogo.org/pipermail/openembedded-commits/2007-April/004912.html
> >
> > introduced a hole which may lead to unnoticed security vulnerabilities
> > slipping into the packages/images produced. Specifically, it defines a
> > random application of a random suite to be used for resolving patching
> > conflicts/failures. If you don't happen to have that random tool,
> > patching failure will be silently swallowed, leading to any adverse
> > effects imaginable - from compile failure to the mentioned security
> > vulnerabilities.
>
> Patch failure should not be silently swallowed, the builds should abort.
> If they don't, we need to fix that underlying problem.
>
> FWIW, your first solution using SHELLRCCMD won't actually work due to
> the way IO redirection is done in recent bitbake.
>
> Your second solution of adding the DEPENDS is impractical due to the
> amount of -native packages it would require.
>
> So we need to find the real problem and fix that, probably somewhere in
> patch.bbclass an error code isn't being propagated at a guess.
>
> I will also hint at the use of PATCH_RESOLVER = "noop" which means the
> user gets the old behaviour of patch failure aborts the build with no
> help from any resolver. It should have always been the default but
> wasn't. I'm not sure what the current default is but we can change it to
> that if its not.
>

Ummm...where? I tried that in my local.conf and it did nothing. I've
also grepped for PATCH_RESOLVER in both bitbake and oe and found
nothing.

Please, let's remove the gnome-terminal default, it makes no sense to
assume that the lowest common denominator is running bitbake from X...

-- 
Justin Patrin



From koen at dominion.kabel.utwente.nl  Mon May  7 10:39:11 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Mon, 07 May 2007 12:39:11 +0200
Subject: [oe] Potential Problems in glibc-package.bbclass
In-Reply-To: <45F0200B.9080002@dominion.kabel.utwente.nl>
References: <a7f8874a0702280825j22bdf3bbw94e58cfd4a0fab93@mail.gmail.com>
	<45F0200B.9080002@dominion.kabel.utwente.nl>
Message-ID: <463F01CF.5010601@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Koen Kooi schreef:
> Hans Henry von Tresckow schreef:
>> I think I may have stumbled across some potential bugs in glibc-package.bbclass:
> 
>> it seems like the standard value for datadir is /usr/share which will
>> cause the following problems in output_locale_binary:
> 
>> 1) i18npath will be set to /usr/share/i18n instead of
>> treedir/usr/share/i18n becouse path.join is too braindead to remove
>> leading / on path entries.
>> 2) the --inputfile option in localdef opts uses datadir instead of
>> treedir, so it looks like it would use the locale files installed on
>> the host instead of the ones we are buildig for.
> 
> 
> There now is a base_path_join function in OE, that doesn't have that bug. No idea why
> glibc.bbclass hasn't been updated to use that.

See http://bugs.openembedded.org/show_bug.cgi?id=1821#c9 for the proposed solution for at
least 1).

regards,

Koen

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGPwHPMkyGM64RGpERAjMsAJ9hwzbjdM/QDmpE/gPkB9taIK7wgACePfxv
E306nGzJX80t3kuMxbtqe+Y=
=W3Un
-----END PGP SIGNATURE-----



From pmiscml at gmail.com  Mon May  7 10:43:31 2007
From: pmiscml at gmail.com (Paul Sokolovsky)
Date: Mon, 7 May 2007 13:43:31 +0300
Subject: [oe] Potential Problems in glibc-package.bbclass
In-Reply-To: <463F01CF.5010601@dominion.kabel.utwente.nl>
References: <a7f8874a0702280825j22bdf3bbw94e58cfd4a0fab93@mail.gmail.com>
	<45F0200B.9080002@dominion.kabel.utwente.nl>
	<463F01CF.5010601@dominion.kabel.utwente.nl>
Message-ID: <1019023621.20070507134331@gmail.com>

Hello Koen,

Monday, May 7, 2007, 1:39:11 PM, you wrote:

[]

>>> I think I may have stumbled across some potential bugs in glibc-package.bbclass:
>> 
>>> it seems like the standard value for datadir is /usr/share which will
>>> cause the following problems in output_locale_binary:
>> 
>>> 1) i18npath will be set to /usr/share/i18n instead of
>>> treedir/usr/share/i18n becouse path.join is too braindead to remove
>>> leading / on path entries.
>>> 2) the --inputfile option in localdef opts uses datadir instead of
>>> treedir, so it looks like it would use the locale files installed on
>>> the host instead of the ones we are buildig for.
>> 
>> 
>> There now is a base_path_join function in OE, that doesn't have that bug. No idea why
>> glibc.bbclass hasn't been updated to use that.

> See http://bugs.openembedded.org/show_bug.cgi?id=1821#c9 for the proposed solution for at
> least 1).

        This is indeed few months old. Let's apply it?


> regards,

> Koen

[]

-- 
Best regards,
 Paul                            mailto:pmiscml at gmail.com




From koen at dominion.kabel.utwente.nl  Mon May  7 10:54:34 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Mon, 07 May 2007 12:54:34 +0200
Subject: [oe] Potential Problems in glibc-package.bbclass
In-Reply-To: <1019023621.20070507134331@gmail.com>
References: <a7f8874a0702280825j22bdf3bbw94e58cfd4a0fab93@mail.gmail.com>	<45F0200B.9080002@dominion.kabel.utwente.nl>	<463F01CF.5010601@dominion.kabel.utwente.nl>
	<1019023621.20070507134331@gmail.com>
Message-ID: <463F056A.7020907@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Paul Sokolovsky schreef:

>> See http://bugs.openembedded.org/show_bug.cgi?id=1821#c9 for the proposed solution for at
>> least 1).
> 
>         This is indeed few months old. Let's apply it?

Fine by me.

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGPwVqMkyGM64RGpERArHoAJ9fW1sGGBVZi0l8TpEruHO9eOJV6gCgnGjj
5Gy2vWx5lGYRjcnSlp2TouA=
=Y7wS
-----END PGP SIGNATURE-----



From no2spam at nospam.arcornews.de  Mon May  7 18:38:49 2007
From: no2spam at nospam.arcornews.de (Rolf Leggewie)
Date: Mon, 07 May 2007 20:38:49 +0200
Subject: [oe] perl 5.8.8 is ready
In-Reply-To: <20070427105722.GA4340@twibble.org>
References: <20070427105722.GA4340@twibble.org>
Message-ID: <f1nrnr$pal$1@sea.gmane.org>

Perl has been recently broken for

a) MACHINE="qemuarm" on angstrom
b) MACHINE="collie" on sharprom-compatible (worked two days prior)




From lenehan at twibble.org  Tue May  8 01:22:28 2007
From: lenehan at twibble.org (Jamie Lenehan)
Date: Tue, 8 May 2007 11:22:28 +1000
Subject: [oe] perl 5.8.8 is ready
In-Reply-To: <f1nrnr$pal$1@sea.gmane.org>
References: <20070427105722.GA4340@twibble.org> <f1nrnr$pal$1@sea.gmane.org>
Message-ID: <20070508012228.GA13161@twibble.org>

On Mon, May 07, 2007 at 08:38:49PM +0200, Rolf Leggewie wrote:
> Perl has been recently broken for
> 
> a) MACHINE="qemuarm" on angstrom
> b) MACHINE="collie" on sharprom-compatible (worked two days prior)

A log or something about what was going wrong might have helped ;)

Looking at irc logs it looks like you having problems with the patching
failing which it doesn't seem to do for anyone else.

My first suspect would be that you added the patch in question
(letgcc-find-errno.patch) locally to test it (when I added it to
bugzilla) and left it in there. Then a recent mt update has resulted
in the change I pushed being included resulting in the patch being
applied twice in the perl recipe.

So can you do an mtn diff on perl_5.8.8.bb and make sure this isn't
the problem? If it isn't the problem I might need some more
information (although I can't really thing of what else this could be
and/or what would help figuring it out at the moment.)

-- 
 Jamie Lenehan <lenehan at twibble.org>



From rpurdie at rpsys.net  Tue May  8 12:30:05 2007
From: rpurdie at rpsys.net (Richard Purdie)
Date: Tue, 08 May 2007 13:30:05 +0100
Subject: [oe] [ALERT] Security vulnerability with recent OE	bitbake.conf
	changes
In-Reply-To: <432beae0705062129i11f69731n1d12777f46a83316@mail.gmail.com>
References: <35653307.20070503154732@gmail.com>
	<1178198199.6312.30.camel@localhost.localdomain>
	<432beae0705062129i11f69731n1d12777f46a83316@mail.gmail.com>
Message-ID: <1178627405.6061.17.camel@localhost.localdomain>

On Sun, 2007-05-06 at 21:29 -0700, Justin Patrin wrote:
> Ummm...where? I tried that in my local.conf and it did nothing. I've
> also grepped for PATCH_RESOLVER in both bitbake and oe and found
> nothing.

Sorry, it should be PATCHRESOLVE = "noop", my memory is playing tricks.

> Please, let's remove the gnome-terminal default, it makes no sense to
> assume that the lowest common denominator is running bitbake from X...

"noop" should be the default. There is no good argument for which
terminal UI should/shouldn't be the default. Ideally I guess it would
autoselect unless the user specifies, I'll give that some thought. A
warning from sanity.bbclass about a missing command might be good too...

Cheers,

Richard




From pmiscml at gmail.com  Tue May  8 13:11:03 2007
From: pmiscml at gmail.com (Paul Sokolovsky)
Date: Tue, 8 May 2007 16:11:03 +0300
Subject: [oe] [ALERT] Security vulnerability with recent OE bitbake.conf
	changes
In-Reply-To: <1178198199.6312.30.camel@localhost.localdomain>
References: <35653307.20070503154732@gmail.com>
	<1178198199.6312.30.camel@localhost.localdomain>
Message-ID: <127969848.20070508161103@gmail.com>

Hello Richard,

Thursday, May 3, 2007, 4:16:39 PM, you wrote:

[]

> So we need to find the real problem and fix that, probably somewhere in
> patch.bbclass an error code isn't being propagated at a guess.

        Ok, so here we go: http://bugs.openembedded.org/show_bug.cgi?id=2274

> NOTE: Applying patch 'include-linux-types.patch'
> sh: line 1: gnome-terminal: command not found
> ERROR: Cannot proceed with manual patch resolution - 'gnome-terminal --disable-factory -t "$TERMWINDOWTITLE" -x bash --rcfile $TERMRCFILE' not found. Check TERMCMDRUN variable.
> ERROR: Error in executing: /home/pfalcon/linux-ppc/org.openembedded.dev/packages/dosfstools/dosfstools_2.11.bb
> ERROR: Exception:exceptions.SystemExit Message:1
> ERROR: Printing the environment of the function

Should be clear enough and helpful to whoever may enable manual mode,
but don't have a required terminal app.

> I will also hint at the use of PATCH_RESOLVER = "noop" which means the
> user gets the old behaviour of patch failure aborts the build with no
> help from any resolver. It should have always been the default but
> wasn't. I'm not sure what the current default is but we can change it to
> that if its not.

        Ok, so please review patches above, and let's make these all
changes ;-).

> Cheers,

> Richard



-- 
Best regards,
 Paul                            mailto:pmiscml at gmail.com




From papercrane at gmail.com  Tue May  8 17:35:14 2007
From: papercrane at gmail.com (Justin Patrin)
Date: Tue, 8 May 2007 10:35:14 -0700
Subject: [oe] [ALERT] Security vulnerability with recent OE bitbake.conf
	changes
In-Reply-To: <1178627405.6061.17.camel@localhost.localdomain>
References: <35653307.20070503154732@gmail.com>
	<1178198199.6312.30.camel@localhost.localdomain>
	<432beae0705062129i11f69731n1d12777f46a83316@mail.gmail.com>
	<1178627405.6061.17.camel@localhost.localdomain>
Message-ID: <432beae0705081035i1b017e3eg652644541f257bbf@mail.gmail.com>

On 5/8/07, Richard Purdie <rpurdie at rpsys.net> wrote:
> On Sun, 2007-05-06 at 21:29 -0700, Justin Patrin wrote:
> > Ummm...where? I tried that in my local.conf and it did nothing. I've
> > also grepped for PATCH_RESOLVER in both bitbake and oe and found
> > nothing.
>
> Sorry, it should be PATCHRESOLVE = "noop", my memory is playing tricks.

Ah there we go, thanks a lot. I tried grepping for gnome-terminal and
it hadn't lead me there.

>
> > Please, let's remove the gnome-terminal default, it makes no sense to
> > assume that the lowest common denominator is running bitbake from X...
>
> "noop" should be the default. There is no good argument for which
> terminal UI should/shouldn't be the default. Ideally I guess it would
> autoselect unless the user specifies, I'll give that some thought. A
> warning from sanity.bbclass about a missing command might be good too...
>

It appears not to be, however...:-|

-- 
Justin Patrin



From papercrane at gmail.com  Tue May  8 17:35:14 2007
From: papercrane at gmail.com (Justin Patrin)
Date: Tue, 8 May 2007 10:35:14 -0700
Subject: [oe] [ALERT] Security vulnerability with recent OE bitbake.conf
	changes
In-Reply-To: <1178627405.6061.17.camel@localhost.localdomain>
References: <35653307.20070503154732@gmail.com>
	<1178198199.6312.30.camel@localhost.localdomain>
	<432beae0705062129i11f69731n1d12777f46a83316@mail.gmail.com>
	<1178627405.6061.17.camel@localhost.localdomain>
Message-ID: <432beae0705081035i1b017e3eg652644541f257bbf@mail.gmail.com>

On 5/8/07, Richard Purdie <rpurdie at rpsys.net> wrote:
> On Sun, 2007-05-06 at 21:29 -0700, Justin Patrin wrote:
> > Ummm...where? I tried that in my local.conf and it did nothing. I've
> > also grepped for PATCH_RESOLVER in both bitbake and oe and found
> > nothing.
>
> Sorry, it should be PATCHRESOLVE = "noop", my memory is playing tricks.

Ah there we go, thanks a lot. I tried grepping for gnome-terminal and
it hadn't lead me there.

>
> > Please, let's remove the gnome-terminal default, it makes no sense to
> > assume that the lowest common denominator is running bitbake from X...
>
> "noop" should be the default. There is no good argument for which
> terminal UI should/shouldn't be the default. Ideally I guess it would
> autoselect unless the user specifies, I'll give that some thought. A
> warning from sanity.bbclass about a missing command might be good too...
>

It appears not to be, however...:-|

-- 
Justin Patrin



From xjqian at gmail.com  Wed May  9 02:25:00 2007
From: xjqian at gmail.com (Junqian Gordon Xu)
Date: Tue, 08 May 2007 21:25:00 -0500
Subject: [oe] QA for intentionally unpackaged files
Message-ID: <464130FC.7030008@gmail.com>

Now there is no way to distinguish if the following is intensional by 
the package maintainer or an oversight without taking a closer look at 
the contents

NOTE: the following files were installed but not shipped in any package:
NOTE:   /usr/lib/libpython2.4.so
NOTE:   /usr/lib/.debug/libpython2.4.so.1.0
NOTE:   /usr/share/man/man1/python.1
NOTE:   /usr/bin/python2.4
NOTE:   /usr/bin/smtpd.py
NOTE:   /usr/bin/.debug/python

Maybe we should have something in insane.bb to take care of the 
intentionally unpackaged crusts. So we can do something like the 
following in a bb file to intensionally leave out some garbage unpackaged:

UNSHIPPED = "${libdir}/libpython2.4.so ${bindir}/smtpd.py"  #reason why 
not package/ship it

so during do_package or package_QA, it would show as

NOTE: the following files were installed but not shipped in any package:
NOTE:   /usr/lib/libpython2.4.so   UNSHIPPED #reason why not 
packaged/ship it
NOTE:   /usr/lib/.debug/libpython2.4.so.1.0
NOTE:   /usr/share/man/man1/python.1
NOTE:   /usr/bin/python2.4
NOTE:   /usr/bin/smtpd.py  UNSHIPPED #reason why not packaged/ship it
NOTE:   /usr/bin/.debug/python

Is SUNK a better word than UNSHIPPED?

Gordon



From pmiscml at gmail.com  Wed May  9 09:38:21 2007
From: pmiscml at gmail.com (Paul Sokolovsky)
Date: Wed, 9 May 2007 12:38:21 +0300
Subject: [oe] QA for intentionally unpackaged files
In-Reply-To: <464130FC.7030008@gmail.com>
References: <464130FC.7030008@gmail.com>
Message-ID: <02827798.20070509123821@gmail.com>

Hello Junqian,

Wednesday, May 9, 2007, 5:25:00 AM, you wrote:

> Now there is no way to distinguish if the following is intensional by 
> the package maintainer or an oversight without taking a closer look at
> the contents

        So, maybe "closer look" is indeed a solution here?

> NOTE: the following files were installed but not shipped in any package:
> NOTE:   /usr/lib/libpython2.4.so
> NOTE:   /usr/lib/.debug/libpython2.4.so.1.0
> NOTE:   /usr/share/man/man1/python.1
> NOTE:   /usr/bin/python2.4
> NOTE:   /usr/bin/smtpd.py
> NOTE:   /usr/bin/.debug/python

> Maybe we should have something in insane.bb to take care of the 
> intentionally unpackaged crusts. So we can do something like the 
> following in a bb file to intensionally leave out some garbage unpackaged:

> UNSHIPPED = "${libdir}/libpython2.4.so ${bindir}/smtpd.py"  #reason why
> not package/ship it

        Who exactly will go over all recipes and add such lines?

> so during do_package or package_QA, it would show as

> NOTE: the following files were installed but not shipped in any package:
> NOTE:   /usr/lib/libpython2.4.so   UNSHIPPED #reason why not 
> packaged/ship it

        No, thanks, it likely shouldn't dump them at all then.

> NOTE:   /usr/lib/.debug/libpython2.4.so.1.0
> NOTE:   /usr/share/man/man1/python.1
> NOTE:   /usr/bin/python2.4
> NOTE:   /usr/bin/smtpd.py  UNSHIPPED #reason why not packaged/ship it
> NOTE:   /usr/bin/.debug/python

> Is SUNK a better word than UNSHIPPED?

        No.

> Gordon


-- 
Best regards,
 Paul                            mailto:pmiscml at gmail.com




From hacker at klever.net  Wed May  9 10:31:45 2007
From: hacker at klever.net (Michael Krelin)
Date: Wed, 09 May 2007 12:31:45 +0200
Subject: [oe] QA for intentionally unpackaged files
In-Reply-To: <02827798.20070509123821@gmail.com>
References: <464130FC.7030008@gmail.com> <02827798.20070509123821@gmail.com>
Message-ID: <4641A311.4030907@klever.net>

> 
>> UNSHIPPED = "${libdir}/libpython2.4.so ${bindir}/smtpd.py"  #reason why
>> not package/ship it
> 
>         Who exactly will go over all recipes and add such lines?

I take it the proposal was that package maintainers should take care of
it. Indeed, it would be better if intentionally unpackaged files invoked
no QA notice. But I think the solution is either not install them or rm
them after installation, depending on installation procedure nature.


Love,
H



From koen at dominion.kabel.utwente.nl  Wed May  9 10:42:42 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Wed, 09 May 2007 12:42:42 +0200
Subject: [oe] QA for intentionally unpackaged files
In-Reply-To: <4641A311.4030907@klever.net>
References: <464130FC.7030008@gmail.com> <02827798.20070509123821@gmail.com>
	<4641A311.4030907@klever.net>
Message-ID: <4641A5A2.8050108@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Michael Krelin schreef:
>>> UNSHIPPED = "${libdir}/libpython2.4.so ${bindir}/smtpd.py"  #reason why
>>> not package/ship it
>>         Who exactly will go over all recipes and add such lines?
> 
> I take it the proposal was that package maintainers should take care of
> it. Indeed, it would be better if intentionally unpackaged files invoked
> no QA notice. But I think the solution is either not install them or rm
> them after installation, depending on installation procedure nature.

Or we could patch package.bbclass[1] to do:

PACKAGES += "${PN}-leftovers"
FILES_${PN}-leftovers = "/"

I'm not sure if that works, but if it does, we would be able to spot leftovers more easily
by looking at deploy.

regards,

Koen

[1] this wouldn't work in bitbake.conf
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGQaWiMkyGM64RGpERAuTXAKCD+n1gXwbL7dyqru7UySv82J/CXQCgmTUM
7dYtDM79sAYQSnyDtwKmcfM=
=hEE+
-----END PGP SIGNATURE-----



From xjqian at gmail.com  Wed May  9 10:48:33 2007
From: xjqian at gmail.com (Junqian Gordon Xu)
Date: Wed, 09 May 2007 05:48:33 -0500
Subject: [oe] QA for intentionally unpackaged files
In-Reply-To: <02827798.20070509123821@gmail.com>
References: <464130FC.7030008@gmail.com> <02827798.20070509123821@gmail.com>
Message-ID: <4641A701.5000204@gmail.com>

Paul Sokolovsky wrote:
>
>         So, maybe "closer look" is indeed a solution here?
>
>   
>         Who exactly will go over all recipes and add such lines?
>
>   
>
>         No, thanks, it likely shouldn't dump them at all then.

I take it as to find an easy and uncumbersome way to take care of this. 
I don't think doing nothing at all is a good solution.

Gordon



From xjqian at gmail.com  Wed May  9 10:57:06 2007
From: xjqian at gmail.com (Junqian Gordon Xu)
Date: Wed, 09 May 2007 05:57:06 -0500
Subject: [oe] QA for intentionally unpackaged files
In-Reply-To: <4641A5A2.8050108@dominion.kabel.utwente.nl>
References: <464130FC.7030008@gmail.com>
	<02827798.20070509123821@gmail.com>	<4641A311.4030907@klever.net>
	<4641A5A2.8050108@dominion.kabel.utwente.nl>
Message-ID: <4641A902.6020506@gmail.com>

Koen Kooi wrote:
> Or we could patch package.bbclass[1] to do:
>
> PACKAGES += "${PN}-leftovers"
> FILES_${PN}-leftovers = "/"
>
> I'm not sure if that works, but if it does, we would be able to spot leftovers more easily
> by looking at deploy.

Again, how do you know which one is "intentionally" left-over vs. which 
one is not?

Gordon




From koen at dominion.kabel.utwente.nl  Wed May  9 11:26:03 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Wed, 09 May 2007 13:26:03 +0200
Subject: [oe] QA for intentionally unpackaged files
In-Reply-To: <4641A902.6020506@gmail.com>
References: <464130FC.7030008@gmail.com>	<02827798.20070509123821@gmail.com>	<4641A311.4030907@klever.net>	<4641A5A2.8050108@dominion.kabel.utwente.nl>
	<4641A902.6020506@gmail.com>
Message-ID: <4641AFCB.6080203@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Junqian Gordon Xu schreef:
> Koen Kooi wrote:
>> Or we could patch package.bbclass[1] to do:
>>
>> PACKAGES += "${PN}-leftovers"
>> FILES_${PN}-leftovers = "/"
>>
>> I'm not sure if that works, but if it does, we would be able to spot leftovers more easily
>> by looking at deploy.
> 
> Again, how do you know which one is "intentionally" left-over vs. which 
> one is not?

I can't think of a valid reason for not packaging files.

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGQa/LMkyGM64RGpERAjF7AJkBFh9SE86gjvybHZ7PRwc0+Cl2qwCcDV1h
tStk9ih9NSv558uCHvxA4G8=
=caUf
-----END PGP SIGNATURE-----



From pmiscml at gmail.com  Wed May  9 11:37:09 2007
From: pmiscml at gmail.com (Paul Sokolovsky)
Date: Wed, 9 May 2007 14:37:09 +0300
Subject: [oe] QA for intentionally unpackaged files
In-Reply-To: <4641AFCB.6080203@dominion.kabel.utwente.nl>
References: <464130FC.7030008@gmail.com> <02827798.20070509123821@gmail.com>
	<4641A311.4030907@klever.net>
	<4641A5A2.8050108@dominion.kabel.utwente.nl>
	<4641A902.6020506@gmail.com>
	<4641AFCB.6080203@dominion.kabel.utwente.nl>
Message-ID: <818235002.20070509143709@gmail.com>

Hello Koen,

Wednesday, May 9, 2007, 2:26:03 PM, you wrote:


> Junqian Gordon Xu schreef:
>> Koen Kooi wrote:
>>> Or we could patch package.bbclass[1] to do:
>>>
>>> PACKAGES += "${PN}-leftovers"
>>> FILES_${PN}-leftovers = "/"
>>>
>>> I'm not sure if that works, but if it does, we would be able to spot leftovers more easily
>>> by looking at deploy.
>> 
>> Again, how do you know which one is "intentionally" left-over vs. which 
>> one is not?

> I can't think of a valid reason for not packaging files.

        busybox doesn't package symlinks, as update-alternative
recreates them on install.


        But I agree that catch-all package is better idea than another
adhoc var. Except that we probably should add ${PN}-unshipped and
${PN}-leftovers to distinguish those intentional vs missed cases.

> regards,

> Koen

-- 
Best regards,
 Paul                            mailto:pmiscml at gmail.com




From hacker at klever.net  Wed May  9 11:43:32 2007
From: hacker at klever.net (Michael Krelin)
Date: Wed, 09 May 2007 13:43:32 +0200
Subject: [oe] QA for intentionally unpackaged files
In-Reply-To: <4641A5A2.8050108@dominion.kabel.utwente.nl>
References: <464130FC.7030008@gmail.com>
	<02827798.20070509123821@gmail.com>	<4641A311.4030907@klever.net>
	<4641A5A2.8050108@dominion.kabel.utwente.nl>
Message-ID: <4641B3E4.1020107@klever.net>

> Michael Krelin schreef:
>>>> UNSHIPPED = "${libdir}/libpython2.4.so ${bindir}/smtpd.py"  #reason why
>>>> not package/ship it
>>>         Who exactly will go over all recipes and add such lines?
>> I take it the proposal was that package maintainers should take care of
>> it. Indeed, it would be better if intentionally unpackaged files invoked
>> no QA notice. But I think the solution is either not install them or rm
>> them after installation, depending on installation procedure nature.
> 
> Or we could patch package.bbclass[1] to do:
> 
> PACKAGES += "${PN}-leftovers"
> FILES_${PN}-leftovers = "/"

I'd rather propose, indeed, packaging the intentional leftovers into a
-leftovers package manually on each package that wants leftovers. But as
you pointed out that there are no valid reasons for files to be
unpackaged, I'm sure it's possible to come up with more meaningful name
for -leftovers package in each particular case. And before files are
packaged QA notice stays QA notice, because it *is* QA issue ;-)


Love,
H



From hacker at klever.net  Wed May  9 11:51:51 2007
From: hacker at klever.net (Michael Krelin)
Date: Wed, 09 May 2007 13:51:51 +0200
Subject: [oe] QA for intentionally unpackaged files
In-Reply-To: <818235002.20070509143709@gmail.com>
References: <464130FC.7030008@gmail.com>
	<02827798.20070509123821@gmail.com>	<4641A311.4030907@klever.net>	<4641A5A2.8050108@dominion.kabel.utwente.nl>	<4641A902.6020506@gmail.com>	<4641AFCB.6080203@dominion.kabel.utwente.nl>
	<818235002.20070509143709@gmail.com>
Message-ID: <4641B5D7.2070406@klever.net>

> 
>         But I agree that catch-all package is better idea than another
> adhoc var. Except that we probably should add ${PN}-unshipped and
> ${PN}-leftovers to distinguish those intentional vs missed cases.
> 

How would any catch-all solution actually differ from disabling QA
notice? Except for that you'd be able to install these leftovers.

Love,
H



From cailotto at sci.univr.it  Wed May  9 15:59:38 2007
From: cailotto at sci.univr.it (Stefano Cailotto)
Date: Wed, 9 May 2007 17:59:38 +0200
Subject: [oe]  OE on Kontron eb425
Message-ID: <001f01c79253$0bf2c970$38f21b9d@kai>

Hello Leon, 
I've extracted kontron modifications with a diff between their shipped
kernel and a fresh one.
I don't know if it is possible to flash even the bootloader...
Looking a bit into source code, there are several kontron patches both for
drivers and kernel boot.
I'm trying to KOntron kernel into OE using Kontron toolchain, but without
success..

Hello Stefano,

On 5/4/07, Stefano Cailotto <cailotto at sci.univr.it> wrote:
> Hi all,
> I'm trying to build something usable for a kontron eb425 board, based on
an
> intel ixp425.
> I tried to compile using a generic ixp4xxbe, but when loading, the kernel
> stops after uncompressing reporting a CRC error.
> It seems that Kontron EmbeddedLinux development kit performs something on
> the kernel before making zImage in order to load it in a specifed memory
> location.
>
There are some IXP42x users on OE, mostly for the NSLU device from
Linksys/Cisco, the Intel dev board (IXDP425) and some custom boards,
but I have not see the Kontron board yet.

With the reported problem, it would help if you understand or at least
could tell where to find the details on the boot loader.

Ideally, you would want to boot loader to be buildable from source
instead of relying on some binary on flash.

Regards,

Leon.

---------------------------------------------------------------------------
  Stefano Cailotto - Research Consultant
---------------------------------------------------------------------------
  EDALab - Networked Embedded Systems
  c/o  Dipartimento di Informatica - Universita` di Verona
  Strada le Grazie, 15 - 37134 Verona (Italy)
---------------------------------------------------------------------------
  email: cailotto at sci.univr.it stefano.cailotto at edalab.it      
  web:  http://www.edalab.it
  tel: +39-045-802-7062 fax: +39-045-802-7068
---------------------------------------------------------------------------




From rodrigo.vivi at gmail.com  Wed May  9 19:44:09 2007
From: rodrigo.vivi at gmail.com (Rodrigo Vivi)
Date: Wed, 9 May 2007 16:44:09 -0300
Subject: [oe] generating debian source packages (dsc)
In-Reply-To: <432beae0705021338x7ca36c0oc937a6b1b03f6db5@mail.gmail.com>
References: <bdb0025f0705021104x23d2c407rb4da0e48e24eb911@mail.gmail.com>
	<200705022051.03720.openembedded@hrw.one.pl>
	<bdb0025f0705021252w7e32b305ybf9c914c1cb1edc0@mail.gmail.com>
	<432beae0705021338x7ca36c0oc937a6b1b03f6db5@mail.gmail.com>
Message-ID: <bdb0025f0705091244u19ce0129h957f9c34154454f0@mail.gmail.com>

I'm trying to use inherit sourcepkg without success.
Does anybody has any suggestion about the following error?

NOTE: package shasum-native-1.0: started
NOTE: package shasum-native-1.0-r1: task do_create_orig_tgz: started
NOTE: <type 'exceptions.IndexError'>:list index out of range while evaluating:

        mkdir -p /indt/mamona/openembedded/tmp/deploy/source
        cd /indt/mamona/openembedded/tmp/work/shasum-native-1.0-r1
        for i in .pc autom4te.cache; do
                echo $i >> temp/exclude-from-file
        done

        src_tree=${@get_src_tree(d)}

        echo $src_tree
        oenote "Creating .orig.tar.gz in
/indt/mamona/openembedded/tmp/deploy/source/shasum-native-1.0.orig.tar.gz"
        tar cvzf
/indt/mamona/openembedded/tmp/deploy/source/shasum-native-1.0.orig.tar.gz
--exclude-from temp/exclude-from-file $src_tree
        cp -pPR $src_tree $src_tree.orig

NOTE: <type 'exceptions.IndexError'>:list index out of range while evaluating:

        cd /indt/mamona/openembedded/tmp/work/shasum-native-1.0-r1
        for i in .pc autom4te.cache; do
                echo $i >> temp/exclude-from-file
        done


        src_tree=${@get_src_tree(d)}

        for i in `find . -maxdepth 1 -type f`; do
                mkdir -p $src_tree/mamona/files
                cp $i $src_tree/mamona/files
        done

        oenote "Creating .diff.gz in
/indt/mamona/openembedded/tmp/deploy/source/shasum-native-1.0-r1.diff.gz"
        LC_ALL=C TZ=UTC0 diff --exclude-from=temp/exclude-from-file
-Naur $src_tree.orig $src_tree | gzip -c >
/indt/mamona/openembedded/tmp/deploy/source/shasum-native-1.0-r1.diff.gz
        rm -rf $src_tree.orig

NOTE: <type 'exceptions.IndexError'>:list index out of range while evaluating:

        src_tree=${@get_src_tree(d)}
        dest=/indt/mamona/openembedded/tmp/work/shasum-native-1.0-r1/$src_tree/mamona
        mkdir -p $dest

        cp /indt/mamona/openembedded/org.openembedded.dev/packages/shasum/shasum-native.bb
$dest

ERROR: function do_create_orig_tgz failed
ERROR: log data follows
(/indt/mamona/openembedded/tmp/work/shasum-native-1.0-r1/temp/log.do_create_orig_tgz.6911)
| /indt/mamona/openembedded/tmp/work/shasum-native-1.0-r1/temp/run.do_create_orig_tgz.6911:
line 510: sourcepkg_do_create_orig_tgz: command not found
NOTE: Task failed:
/indt/mamona/openembedded/tmp/work/shasum-native-1.0-r1/temp/log.do_create_orig_tgz.6911
NOTE: package shasum-native-1.0-r1: task do_create_orig_tgz: failed
ERROR: TaskFailed event exception, aborting
NOTE: package shasum-native-1.0: failed


On 5/2/07, Justin Patrin <papercrane at gmail.com> wrote:
> On 5/2/07, Rodrigo Vivi <rodrigo.vivi at gmail.com> wrote:
> > > classes/sourcepkg.bbclass is something which you want to extend
> >
> > I've thought about it but I'm not sure that it is a good idea because
> > just few projects (or just mine) needs the dsc file .......... unless
> > that I code another sourcedsc.bbclass that inherit the
> > sourcedpkg.bbclass... o you think that it will work???  I'll think
> > about it...
> >
>
> Yes, this is what Marcin meant. Create your own sourcedsc.bbclass
> which inherits sourcepkg.bbclass. This is how, for example,
> efl.bbclass and e.bbclass work.
>
> > Another doubt that I forgot to mention on last email is about changelog:
> > I'm generating a almost empty changelog file. Is there any official
> > and/or more appropriated way to do that?
> >
> > Thanks,
> > Vivi.
> >
> > >
> > > --
> > > JID: hrw-jabber.org
> > > OpenEmbedded developer/consultant
> > >
> > >       I'm trying to decide if I should kill you or simply feign death
> > >       until you feel awkward and leave.
> > >
> > >
> > >
> > > _______________________________________________
> > > Openembedded-devel mailing list
> > > Openembedded-devel at lists.openembedded.org
> > > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> > >
> >
> > _______________________________________________
> > Openembedded-devel mailing list
> > Openembedded-devel at lists.openembedded.org
> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> >
>
>
> --
> Justin Patrin
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>



From pmiscml at gmail.com  Thu May 10 15:00:54 2007
From: pmiscml at gmail.com (Paul Sokolovsky)
Date: Thu, 10 May 2007 18:00:54 +0300
Subject: [oe] Making /var/lib persistent
In-Reply-To: <20070419014949.GA6540@twibble.org>
References: <1176760923.4623f25b913f9@dominion.kabel.utwente.nl>
	<20070418090235.GA21841@twibble.org>
	<46262A0F.1050805@dominion.kabel.utwente.nl>
	<20070419014949.GA6540@twibble.org>
Message-ID: <31583224.20070510180054@gmail.com>

Hello Jamie,

Thursday, April 19, 2007, 4:49:50 AM, you wrote:

> On Wed, Apr 18, 2007 at 07:24:15AM -0700, Koen Kooi wrote:
> [...]
>> Sound like a good idea, do you have a patch for this?

> Try this out:

>   http://twibble.org/dist/oe/var-volatiles-1.patch

> I've tested it locally both with and without tmpfs mounted on
> /var/volatile and all seems to work as expected.

        Any news on this? I've been running with this patch soon since
its original post and don't see any issues. One small nuisance is that
ls -l /var/log doesn't show what you want, but hardly something can be
done about that, plus shell completion uses /var/log/ immediately.

        I suggest committing this patch.

[]

-- 
Best regards,
 Paul                            mailto:pmiscml at gmail.com




From koen at dominion.kabel.utwente.nl  Thu May 10 19:23:30 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Thu, 10 May 2007 21:23:30 +0200
Subject: [oe] Making /var/lib persistent
In-Reply-To: <31583224.20070510180054@gmail.com>
References: <1176760923.4623f25b913f9@dominion.kabel.utwente.nl>	<20070418090235.GA21841@twibble.org>	<46262A0F.1050805@dominion.kabel.utwente.nl>	<20070419014949.GA6540@twibble.org>
	<31583224.20070510180054@gmail.com>
Message-ID: <46437132.1060303@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Paul Sokolovsky schreef:
> Hello Jamie,
> 
> Thursday, April 19, 2007, 4:49:50 AM, you wrote:
> 
>> On Wed, Apr 18, 2007 at 07:24:15AM -0700, Koen Kooi wrote:
>> [...]
>>> Sound like a good idea, do you have a patch for this?
> 
>> Try this out:
> 
>>   http://twibble.org/dist/oe/var-volatiles-1.patch
> 
>> I've tested it locally both with and without tmpfs mounted on
>> /var/volatile and all seems to work as expected.
> 
>         Any news on this? I've been running with this patch soon since
> its original post and don't see any issues. One small nuisance is that
> ls -l /var/log doesn't show what you want, but hardly something can be
> done about that, plus shell completion uses /var/log/ immediately.
> 
>         I suggest committing this patch.

same here.

regards,

Koen

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGQ3EyMkyGM64RGpERAoBNAJ4uabEzcebJd5+x/dtQAKTfYMI8oQCgrza3
buax9m6pqJ+/DZfchJcjlvA=
=hzmX
-----END PGP SIGNATURE-----



From rpurdie at rpsys.net  Thu May 10 23:06:11 2007
From: rpurdie at rpsys.net (Richard Purdie)
Date: Fri, 11 May 2007 00:06:11 +0100
Subject: [oe] Making /var/lib persistent
In-Reply-To: <31583224.20070510180054@gmail.com>
References: <1176760923.4623f25b913f9@dominion.kabel.utwente.nl>
	<20070418090235.GA21841@twibble.org>
	<46262A0F.1050805@dominion.kabel.utwente.nl>
	<20070419014949.GA6540@twibble.org> <31583224.20070510180054@gmail.com>
Message-ID: <1178838371.20362.2.camel@localhost.localdomain>

On Thu, 2007-05-10 at 18:00 +0300, Paul Sokolovsky wrote:
> Hello Jamie,
> 
> Thursday, April 19, 2007, 4:49:50 AM, you wrote:
> 
> > On Wed, Apr 18, 2007 at 07:24:15AM -0700, Koen Kooi wrote:
> > [...]
> >> Sound like a good idea, do you have a patch for this?
> 
> > Try this out:
> 
> >   http://twibble.org/dist/oe/var-volatiles-1.patch
> 
> > I've tested it locally both with and without tmpfs mounted on
> > /var/volatile and all seems to work as expected.
> 
>         Any news on this? I've been running with this patch soon since
> its original post and don't see any issues. One small nuisance is that
> ls -l /var/log doesn't show what you want, but hardly something can be
> done about that, plus shell completion uses /var/log/ immediately.
> 
>         I suggest committing this patch.

The idea sounded sane to me when I read about it so if its working, I
say go for it...

Cheers,

Richard




From pmiscml at gmail.com  Fri May 11 17:00:05 2007
From: pmiscml at gmail.com (Paul Sokolovsky)
Date: Fri, 11 May 2007 20:00:05 +0300
Subject: [oe] [ALERT] Security vulnerability with recent OE bitbake.conf
	changes
In-Reply-To: <127969848.20070508161103@gmail.com>
References: <35653307.20070503154732@gmail.com>
	<1178198199.6312.30.camel@localhost.localdomain>
	<127969848.20070508161103@gmail.com>
Message-ID: <1353801661.20070511200005@gmail.com>

Hello,

Tuesday, May 8, 2007, 4:11:03 PM:

> Hello Richard,

> Thursday, May 3, 2007, 4:16:39 PM, you wrote:

> []

>> So we need to find the real problem and fix that, probably somewhere in
>> patch.bbclass an error code isn't being propagated at a guess.

>         Ok, so here we go:
> http://bugs.openembedded.org/show_bug.cgi?id=2274

        This was committed, as well as PATCHRESOLVE set to "noop" by
default.

[]

-- 
Best regards,
 Paul                            mailto:pmiscml at gmail.com




From tom at openhardware.net  Fri May 11 17:45:47 2007
From: tom at openhardware.net (Tom Walsh)
Date: Fri, 11 May 2007 13:45:47 -0400
Subject: [oe] do_rootfs fails
Message-ID: <4644ABCB.6080202@openhardware.net>

Ok, I admit it, I am totally confused by this whole "debian", 
"multimachine", "package_ipk" stuff.  I've been able to avoid 
understanding this and think that this might be why bootstrap.image 
won't build a filesystem image.

Prior to a month ago, I was using my own task + image bb files to build 
my image.  Since a lot of work has been done to make the task-base more 
generic, I have moved my project over to using the stock 
bootstrap-image.bb and task-base.bb files.  However, it fails to build 
properly.

When running a "bitbake bootstrap-image", everything builds but then 
fails with:

========= begin ============
[tom at jtag oezipit]$ bitbake bootstrap-image
NOTE: Using cache in '/home/tom/oezipit/tmp/cache/zipit'
NOTE: Handling BitBake files: \ (4534/4534) [100 %]
NOTE: Parsing finished. 4329 cached, 0 parsed, 205 skipped, 0 masked.

NOTE: build 200705111324: started

OE Build Configuration:
BB_VERSION     = "1.6.7"
OE_REVISION    = "<unknown>"
TARGET_ARCH    = "arm"
TARGET_OS      = "linux"
MACHINE        = "zipit"
DISTRO         = "zipit"
DISTRO_VERSION = "1.0"
TARGET_FPU     = "soft"

NOTE: multiple providers are available (db3, db);
NOTE: consider defining PREFERRED_PROVIDER_virtual/db
NOTE: multiple providers are available (db3-native, db-native);
NOTE: consider defining PREFERRED_PROVIDER_virtual/db-native
NOTE: package bootstrap-image-1.0: started
NOTE: package bootstrap-image-1.0-r0: task do_rootfs: started
ERROR: function do_rootfs failed
ERROR: see log in 
/home/tom/oezipit/tmp/work/zipit-linux/bootstrap-image-1.0-r0/temp/log.do_rootfs.17150
NOTE: Task failed: 
/home/tom/oezipit/tmp/work/zipit-linux/bootstrap-image-1.0-r0/temp/log.do_rootfs.17150
NOTE: package bootstrap-image-1.0-r0: task do_rootfs: failed
ERROR: TaskFailed event exception, aborting
NOTE: package bootstrap-image-1.0: failed
ERROR: Build of bootstrap-image failed
========= snip =============

When I check the logfile, it says that "sh: fakeroot: command not 
found".  This is correct, fakeroot-native has NOT been built.  So, I do 
a "bitbake -c rebuild fakeroot-native", then run "bitbake 
bootstrap-image" again.

It then fails with a logfile message of 
"/home/tom/oezipit/tmp/work/zipit-linux/bootstrap-image-1.0-r0/temp/run.do_rootfs.24175: 
line 312: ipkg-cl: command not found".  Again, this is true, ipkg-native 
is not present.  So, I do a "bitbake -c rebuild ipkg-native", then run 
"bitbake bootstrap-image" again.

Now it builds the filesystem target tarball image.

How can I automate those needs for fakeroot-native and ipkg-native?  I'm 
not sure where to look, this was working a few weeks ago.

Regards,

TomW





-- 
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net http://cyberiansoftware.com http://openzipit.org
"Windows? No thanks, I have work to do..."
----------------------------------------------------





From koen at dominion.kabel.utwente.nl  Fri May 11 18:07:14 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Fri, 11 May 2007 20:07:14 +0200
Subject: [oe] do_rootfs fails
In-Reply-To: <4644ABCB.6080202@openhardware.net>
References: <4644ABCB.6080202@openhardware.net>
Message-ID: <4644B0D2.8020409@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tom Walsh schreef:

<snip problem description>

> OE Build Configuration:
> BB_VERSION     = "1.6.7"

Tom: Upgrade to 1.8.2 or use the bitbake-1.8 branch (1.8.3 atm).
All: Are we still going to wait 1.5 months with requiring 1.8.x? I've seen enough proof
that 1.6.x is broken with current .dev, with no effort to fix it. "Giving people time to
prepare the upgrade" has now turned into "Stabbing user in the eye" :(

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGRLDRMkyGM64RGpERAm1ZAKCBtqmqLrk3MXEPldP9AvEjxxJSsACggk//
FJLY3HdrD/EF2xvBzEOJvts=
=qgbE
-----END PGP SIGNATURE-----



From hacker at klever.net  Fri May 11 18:24:17 2007
From: hacker at klever.net (Michael Krelin)
Date: Fri, 11 May 2007 20:24:17 +0200
Subject: [oe] do_rootfs fails
In-Reply-To: <4644B0D2.8020409@dominion.kabel.utwente.nl>
References: <4644ABCB.6080202@openhardware.net>
	<4644B0D2.8020409@dominion.kabel.utwente.nl>
Message-ID: <4644B4D1.5010803@klever.net>

> All: Are we still going to wait 1.5 months with requiring 1.8.x? I've seen enough proof
> that 1.6.x is broken with current .dev, with no effort to fix it. "Giving people time to
> prepare the upgrade" has now turned into "Stabbing user in the eye" :(

There's also an option of asking Tom to bitbake -DDD and send it to
zecke, because I couldn't find time to try BB 1.6 for him again. And let
him apply the patch that fixes this problem:

Index: lib/bb/parse/parse_py/BBHandler.py
===================================================================
--- lib/bb/parse/parse_py/BBHandler.py  (revision 817)
+++ lib/bb/parse/parse_py/BBHandler.py  (working copy)
@@ -66,7 +66,9 @@
         if not file in __inherit_cache.split():
             debug(2, "BB %s:%d: inheriting %s" % (fn, lineno, file))
             __inherit_cache += " %s" % file
+            data.setVar('__inherit_cache', __inherit_cache, d)
             include(fn, file, d)
+            __inherit_cache = data.getVar('__inherit_cache', d) or ""
     data.setVar('__inherit_cache', __inherit_cache, d)

Love,
H



From oe at hentges.net  Sat May 12 00:07:53 2007
From: oe at hentges.net (Matthias Hentges)
Date: Sat, 12 May 2007 02:07:53 +0200
Subject: [oe] do_rootfs fails
In-Reply-To: <4644B0D2.8020409@dominion.kabel.utwente.nl>
References: <4644ABCB.6080202@openhardware.net>
	<4644B0D2.8020409@dominion.kabel.utwente.nl>
Message-ID: <1178928474.4954.18.camel@localhost.localdomain>

Am Freitag, den 11.05.2007, 20:07 +0200 schrieb Koen Kooi:

> All: Are we still going to wait 1.5 months with requiring 1.8.x? I've seen enough proof
> that 1.6.x is broken with current .dev, with no effort to fix it. "Giving people time to
> prepare the upgrade" has now turned into "Stabbing user in the eye" :(
> 
> regards,
> 
> Koen

1.8.x has a show-stopper freeze-bug for some users ( including myself )
which has not been fixed or even looked into yet.

-- 
Matthias 'CoreDump' Hentges 
Cologne / Germany

Webmaster of Hentges.net & Embedded Linux Developer
GPG ->  gpg --keyserver gpg-keyserver.de --recv-keys 0xAF3030D9

My OS: Debian SID: Geek by Nature, Linux by Choice


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
URL: <http://layers.openembedded.org/pipermail/openembedded-devel/attachments/20070512/d00d0d5a/attachment.sig>

From koen at dominion.kabel.utwente.nl  Sat May 12 10:28:21 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Sat, 12 May 2007 12:28:21 +0200
Subject: [oe] do_rootfs fails
In-Reply-To: <1178928474.4954.18.camel@localhost.localdomain>
References: <4644ABCB.6080202@openhardware.net>	<4644B0D2.8020409@dominion.kabel.utwente.nl>
	<1178928474.4954.18.camel@localhost.localdomain>
Message-ID: <464596C5.8010303@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Matthias Hentges schreef:
> Am Freitag, den 11.05.2007, 20:07 +0200 schrieb Koen Kooi:
> 
>> All: Are we still going to wait 1.5 months with requiring 1.8.x? I've seen enough proof
>> that 1.6.x is broken with current .dev, with no effort to fix it. "Giving people time to
>> prepare the upgrade" has now turned into "Stabbing user in the eye" :(
>>
>> regards,
>>
>> Koen
> 
> 1.8.x has a show-stopper freeze-bug for some users ( including myself )
> which has not been fixed or even looked into yet.

bugnumber?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGRZbFMkyGM64RGpERAlj8AJ9RQ0xtk2nqZAlJloTFFM5j8ml2zACghM87
qvk0yLeJrlqNyZHCtfub4Xo=
=Z1MH
-----END PGP SIGNATURE-----



From koen at dominion.kabel.utwente.nl  Sat May 12 19:21:23 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Sat, 12 May 2007 21:21:23 +0200
Subject: [oe] uclibc 0.9.29 recipe
Message-ID: <464613B3.8090003@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,


I just started working on a uclibc 0.9.29 recipe, are people interested in it already, or
should I finish it before committing it (with DEFAULT_PREF = -1)?

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGRhOzMkyGM64RGpERAlBJAKC4Hekdx6iKB95Nglwt4elr/scvqQCggdgo
b0a0iWs5X06ZAMKRzYUfKlg=
=S7Cp
-----END PGP SIGNATURE-----



From lpotter at trolltech.com  Sat May 12 19:54:27 2007
From: lpotter at trolltech.com (Lorn Potter)
Date: Sun, 13 May 2007 05:54:27 +1000
Subject: [oe] uclibc 0.9.29 recipe
In-Reply-To: <464613B3.8090003@dominion.kabel.utwente.nl>
References: <464613B3.8090003@dominion.kabel.utwente.nl>
Message-ID: <46461B73.8070900@trolltech.com>



Koen Kooi wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi,
> 
> 
> I just started working on a uclibc 0.9.29 recipe, are people interested in it already, or
> should I finish it before committing it (with DEFAULT_PREF = -1)?
> 
> regards,

I would be, especially if it worked in an angstrom build.



-- 
Lorn 'ljp' Potter
Software Engineer, Systems Group, MES, Trolltech



From lpotter at trolltech.com  Sat May 12 19:54:27 2007
From: lpotter at trolltech.com (Lorn Potter)
Date: Sun, 13 May 2007 05:54:27 +1000
Subject: [oe] uclibc 0.9.29 recipe
In-Reply-To: <464613B3.8090003@dominion.kabel.utwente.nl>
References: <464613B3.8090003@dominion.kabel.utwente.nl>
Message-ID: <46461B73.8070900@trolltech.com>



Koen Kooi wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi,
> 
> 
> I just started working on a uclibc 0.9.29 recipe, are people interested in it already, or
> should I finish it before committing it (with DEFAULT_PREF = -1)?
> 
> regards,

I would be, especially if it worked in an angstrom build.



-- 
Lorn 'ljp' Potter
Software Engineer, Systems Group, MES, Trolltech



From koen at dominion.kabel.utwente.nl  Sat May 12 20:02:58 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Sat, 12 May 2007 22:02:58 +0200
Subject: [oe] uclibc 0.9.29 recipe
In-Reply-To: <46461B73.8070900@trolltech.com>
References: <464613B3.8090003@dominion.kabel.utwente.nl>
	<46461B73.8070900@trolltech.com>
Message-ID: <46461D72.4020206@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Lorn Potter schreef:
> 
> Koen Kooi wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Hi,
>>
>>
>> I just started working on a uclibc 0.9.29 recipe, are people interested in it already, or
>> should I finish it before committing it (with DEFAULT_PREF = -1)?
>>
>> regards,
> 
> I would be, especially if it worked in an angstrom build.

I'll add it once I solved the linux-libc-headers problems. Machine and distro maintainers
need to provide their parts of the uclibc configs to make it usefull, though.

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGRh1yMkyGM64RGpERApzPAJ9dHfEynAkjYtpvJC6aKwcSLcF1PQCggceU
2wDlG7EN1RNSwOJ8YjfCItk=
=Un//
-----END PGP SIGNATURE-----



From koen at dominion.kabel.utwente.nl  Sat May 12 21:04:29 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Sat, 12 May 2007 23:04:29 +0200
Subject: [oe] uclibc 0.9.29 recipe
In-Reply-To: <46461D72.4020206@dominion.kabel.utwente.nl>
References: <464613B3.8090003@dominion.kabel.utwente.nl>	<46461B73.8070900@trolltech.com>
	<46461D72.4020206@dominion.kabel.utwente.nl>
Message-ID: <46462BDD.6000302@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Koen Kooi schreef:
> Lorn Potter schreef:
>> Koen Kooi wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> Hi,
>>>
>>>
>>> I just started working on a uclibc 0.9.29 recipe, are people interested in it already, or
>>> should I finish it before committing it (with DEFAULT_PREF = -1)?
>>>
>>> regards,
>> I would be, especially if it worked in an angstrom build.
> 
> I'll add it once I solved the linux-libc-headers problems. 

Which is non-existant on 0.9.29 :)


> Machine and distro maintainers
> need to provide their parts of the uclibc configs to make it usefull, though.

Angstrom has a uClibc.distro and ixp4xxbe has a uClibc.machine.

To add support for your favourite machine: use uClibc.distro as .config, configure uclibc
for the target you want, save the top 2 blocks of .config (cpu and arch) to uClibc.distro
in uclibc-0.9.29/<machine/uClibc.machine

The recipe is by no means perfect, so any help is welcome.

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGRivdMkyGM64RGpERAoVVAKCCVsINF5WmH0XnnbpCF0oMo15sfACePayI
7vnmpum3r/QkizvA4HinAzc=
=R235
-----END PGP SIGNATURE-----



From skoroneos at digital-opsis.com  Sat May 12 21:19:03 2007
From: skoroneos at digital-opsis.com (Stelios Koroneos)
Date: Sun, 13 May 2007 00:19:03 +0300
Subject: [oe] minimal-image.bb
In-Reply-To: <46461D72.4020206@dominion.kabel.utwente.nl>
Message-ID: <HOECLKEKOHLAMMGDLLBHOECKLAAA.skoroneos@digital-opsis.com>

Greetings to all !

Recently it was made apparent that bootstrap-image was generating images
that could not fit in flash restricted devices (<=4MB)
Koen has pushed angstrom-minimal-image which uses task-boot and as a result
generates images significally smaller.(800K in a jffs2 fs)

The only drawback into this (IMHO) is in the naming of the package.
Adding a distro name infront of an image package gives the impression that
this is distro specific and not a "generic" one.
I tried to push to the rep a more "generic" minimal-image.bb which was
almost identical to angstrom-minima-image but Koen had  dis-approved the
commit as duplicate.

In my opinion if angstrom-minimal-image is not distro specific should be
renamed to minimal-image or if it is distro specific a minimal-image.bb
should be created.

I discussed the matter with Koen on irc but we could not come to a
conlusion, so i am asking for the opinions of others on this, as i believe
is a issue which has to be solved to avoid any future problems.



Stelios S. Koroneos

Digital OPSiS - Embedded Intelligence
http://www.digital-opsis.com







From skoroneos at digital-opsis.com  Sat May 12 21:33:31 2007
From: skoroneos at digital-opsis.com (Stelios Koroneos)
Date: Sun, 13 May 2007 00:33:31 +0300
Subject: [oe] do_rootfs fails
In-Reply-To: <4644B4D1.5010803@klever.net>
Message-ID: <HOECLKEKOHLAMMGDLLBHOECLLAAA.skoroneos@digital-opsis.com>

Had the same problem as i am still using 1.6 .
The mentioned patch solved it

Stelios S. Koroneos

Digital OPSiS - Embedded Intelligence
http://www.digital-opsis.com


> -----Original Message-----
> From: openembedded-devel-bounces at openembedded.org 
> [mailto:openembedded-devel-bounces at openembedded.org]On Behalf Of 
> Michael Krelin
> Sent: Friday, May 11, 2007 9:24 PM
> To: openembedded-devel at openembedded.org
> Subject: Re: [oe] do_rootfs fails
> 
> 
> > All: Are we still going to wait 1.5 months with requiring 
> 1.8.x? I've seen enough proof
> > that 1.6.x is broken with current .dev, with no effort to fix 
> it. "Giving people time to
> > prepare the upgrade" has now turned into "Stabbing user in the eye" :(
> 
> There's also an option of asking Tom to bitbake -DDD and send it to
> zecke, because I couldn't find time to try BB 1.6 for him again. And let
> him apply the patch that fixes this problem:
> 
> Index: lib/bb/parse/parse_py/BBHandler.py
> ===================================================================
> --- lib/bb/parse/parse_py/BBHandler.py  (revision 817)
> +++ lib/bb/parse/parse_py/BBHandler.py  (working copy)
> @@ -66,7 +66,9 @@
>          if not file in __inherit_cache.split():
>              debug(2, "BB %s:%d: inheriting %s" % (fn, lineno, file))
>              __inherit_cache += " %s" % file
> +            data.setVar('__inherit_cache', __inherit_cache, d)
>              include(fn, file, d)
> +            __inherit_cache = data.getVar('__inherit_cache', d) or ""
>      data.setVar('__inherit_cache', __inherit_cache, d)
> 
> Love,
> H
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> 




From dp at xora.org.uk  Sun May 13 12:25:49 2007
From: dp at xora.org.uk (Graeme Gregory)
Date: Sun, 13 May 2007 13:25:49 +0100
Subject: [oe] RFC: Bugzilla CC Field
Message-ID: <1179059149.5404.3.camel@cimmeria.hyboria>

RFC

Dont add people to CC field of bugs without talking to them.

Recently I am finding myself added as CC to bugs I have no interest in
as I either don't have the hardware or don't use the software in
question.

Everyone on oe-issues list gets all bug reports anyway and I can use web
search quite effectively myself.

Graeme (XorA)





From koen at dominion.kabel.utwente.nl  Sun May 13 14:29:35 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Sun, 13 May 2007 16:29:35 +0200
Subject: [oe] RFC: Bugzilla CC Field
In-Reply-To: <1179059149.5404.3.camel@cimmeria.hyboria>
References: <1179059149.5404.3.camel@cimmeria.hyboria>
Message-ID: <464720CF.4030801@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Graeme Gregory schreef:
> RFC
> 
> Dont add people to CC field of bugs without talking to them.
> 
> Recently I am finding myself added as CC to bugs I have no interest in
> as I either don't have the hardware or don't use the software in
> question.
> 
> Everyone on oe-issues list gets all bug reports anyway and I can use web
> search quite effectively myself.

Same here, and I was suggested to just turn off all email in the bugzilla userprefs.

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGRyDPMkyGM64RGpERAmzyAJ4lfF/HAeoRx0k/Kn+jXme1ed8xOwCdGr+V
yEXpOXkev8SZFGHcxLqP5pw=
=bROF
-----END PGP SIGNATURE-----



From no2spam at nospam.arcornews.de  Sun May 13 14:33:06 2007
From: no2spam at nospam.arcornews.de (Rolf Leggewie)
Date: Sun, 13 May 2007 16:33:06 +0200
Subject: [oe] RFD: Bugzilla in general & bug triaging
In-Reply-To: <1179059149.5404.3.camel@cimmeria.hyboria>
References: <1179059149.5404.3.camel@cimmeria.hyboria>
Message-ID: <f277j3$i00$1@sea.gmane.org>

Graeme Gregory wrote:
> RFC
> 
> Dont add people to CC field of bugs without talking to them.

Thank you Graeme for raising this issue.  It is something I meant to 
discuss earlier but never found enough time to think it through and 
write up something.  I still have not thought it through, but here it goes.

Let me first say, that I am totally aware that we are all doing this in 
our limited free time.  We also all don't like things being stuffed down 
our throat.  There is a bit of dilemma here.

As a non-dev, I feel one of the better ways for me and others alike is 
to make sure the BTS is in good shape.  It is called bug triaging which 
I also do in other projects.  For me, this is all about efficiency, 
division of labor so to speak (although that capitalistic thinking might 
not go down too well with all of us freeminds ;-))  The idea is that 
there is someone who sifts through the bug reports and makes sure they 
are understandable, complete and real.  The triager also crosslinks bugs 
that share similarities and classifies them.   All this *before they eat 
up valuable time from a real dev*.  That is at least what I am trying to 
do, for the devs to sit down and find well-structured problems to work 
on whenever they feel like it (I know the OE BTS is not there yet, bug 
2194 is a shy start at this).

This is how Ubuntu and Mozilla approach the bugs they receive.  But it 
needs a way to signal "Hey, this bug is OK" and furthermore bugs are 
usually assigned to the most appropriate person.  So that is what I did 
first, assign bugs to the people I thought would be most appropriate in 
dealing with them.  That did not go down so well :-)  So, it was 
suggested to me that instead of assigning, I should cc people.  But that 
is certainly not the best solution, either.

I believe it would be great if OE started some kind of not too rigid 
process of triaging bugs.  All projects are a bit different, so what do 
you think would be the best way for OE to handle this?

 > Everyone on oe-issues list gets all bug reports anyway and I can use
 > web search quite effectively myself.

Graeme, I understand your concern.  I don't mean to say "Hey, here is 
the solution" but maybe there are some options you might consider.

First is that I would think that it might be a waste of valuable dev 
time if all core devs read all bug reports on oe-issues.  Of course, 
that is an individual decision.  But if we got something like bug 
triaging going in a more instituationalized way, it might indeed become 
unnecessary.  Second, bugzilla offers many settings on what mails you 
want to receive and which you don't at 
http://bugs.openembedded.org/userprefs.cgi?tab=email.  If you read 
oe-issues, you might want to consider deactivating all mail from 
bugzilla itself to keep the load down.




From no2spam at nospam.arcornews.de  Sun May 13 14:35:12 2007
From: no2spam at nospam.arcornews.de (Rolf Leggewie)
Date: Sun, 13 May 2007 16:35:12 +0200
Subject: [oe] minimal-image.bb
In-Reply-To: <HOECLKEKOHLAMMGDLLBHOECKLAAA.skoroneos@digital-opsis.com>
References: <46461D72.4020206@dominion.kabel.utwente.nl>
	<HOECLKEKOHLAMMGDLLBHOECKLAAA.skoroneos@digital-opsis.com>
Message-ID: <f277n0$i00$2@sea.gmane.org>

Stelios Koroneos wrote:
> In my opinion if angstrom-minimal-image is not distro specific should be
> renamed to minimal-image

I agree with Stelios that the belief that angstrom-minimal-image is a 
distro-specific image is a reasonable assumption.  If that is not the 
case, I am in favor renaming.




From koen at dominion.kabel.utwente.nl  Sun May 13 15:02:17 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Sun, 13 May 2007 17:02:17 +0200
Subject: [oe] RFD: Bugzilla in general & bug triaging
In-Reply-To: <f277j3$i00$1@sea.gmane.org>
References: <1179059149.5404.3.camel@cimmeria.hyboria>
	<f277j3$i00$1@sea.gmane.org>
Message-ID: <46472879.7070804@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Rolf Leggewie schreef:

> First is that I would think that it might be a waste of valuable dev 
> time if all core devs read all bug reports on oe-issues. 

Personally, I treat oe-issues the same as oe-commits, by just skimming through the
subjects and reading ones that trigger some sort of red flag.

regards,

Koen

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGRyh5MkyGM64RGpERAih1AKCSCjkbNYMQKvz5uGBlSC4kJUFCuwCdH/ZS
dxXPFRHDlbpXplCWROFMuN8=
=rrgr
-----END PGP SIGNATURE-----



From pmiscml at gmail.com  Sun May 13 15:15:30 2007
From: pmiscml at gmail.com (Paul Sokolovsky)
Date: Sun, 13 May 2007 18:15:30 +0300
Subject: [oe] RFD: Bugzilla in general & bug triaging
In-Reply-To: <f277j3$i00$1@sea.gmane.org>
References: <1179059149.5404.3.camel@cimmeria.hyboria>
	<f277j3$i00$1@sea.gmane.org>
Message-ID: <419056356.20070513181530@gmail.com>

Hello Rolf,

Sunday, May 13, 2007, 5:33:06 PM, you wrote:

> Graeme Gregory wrote:
>> RFC
>> 
>> Dont add people to CC field of bugs without talking to them.

> Thank you Graeme for raising this issue.  It is something I meant to 
> discuss earlier but never found enough time to think it through and 
> write up something.  I still have not thought it through, but here it goes.

> Let me first say, that I am totally aware that we are all doing this in
> our limited free time.  We also all don't like things being stuffed down
> our throat.  There is a bit of dilemma here.

> As a non-dev, I feel one of the better ways for me and others alike is
> to make sure the BTS is in good shape.  It is called bug triaging which
> I also do in other projects.  For me, this is all about efficiency, 
> division of labor so to speak (although that capitalistic thinking might
> not go down too well with all of us freeminds ;-))  The idea is that 
> there is someone who sifts through the bug reports and makes sure they
> are understandable, complete and real.  The triager also crosslinks bugs
> that share similarities and classifies them.   All this *before they eat
> up valuable time from a real dev*.  That is at least what I am trying to
> do, for the devs to sit down and find well-structured problems to work
> on whenever they feel like it (I know the OE BTS is not there yet, bug
> 2194 is a shy start at this).

        I'm sure that I can speak from many peoples' side: your work
and effort on bug management is *much* appreciated. Thanks to you, we
now have *live* bugtracker, not a swamp, which it was just few months
ago.

> This is how Ubuntu and Mozilla approach the bugs they receive.  But it
> needs a way to signal "Hey, this bug is OK" and furthermore bugs are 
> usually assigned to the most appropriate person.  So that is what I did
> first, assign bugs to the people I thought would be most appropriate in
> dealing with them.  That did not go down so well :-)  So, it was 
> suggested to me that instead of assigning, I should cc people.  But that
> is certainly not the best solution, either.

> I believe it would be great if OE started some kind of not too rigid 
> process of triaging bugs.  All projects are a bit different, so what do
> you think would be the best way for OE to handle this?

        I guess this can be expressed as:

1. If there's a confirmed bugtracker manager, whatever he does,
already has good weight in it.
2. There're indeed well-known work flow patterns and best practices,
and those should be rather reused, not ignored.
3. There should be room for improvements and adaption to our specific
case and environment.

        In this regard, I think that current scheme, and your use of
it, is good enough to go with. In particular, I appreciate, and
recommend, that everyone who submits something important (or having
other special criteria) for the area I maintain/watch, to add myself
to cc:, to ensure prompt replies and addition guarantee that important
issues are not lost in awful amount of mail I receive, and don't
depend on not 100% reliable things like my watching bug tracker
notifications.

 >> Everyone on oe-issues list gets all bug reports anyway and I can use
 >> web search quite effectively myself.

> Graeme, I understand your concern.  I don't mean to say "Hey, here is 
> the solution" but maybe there are some options you might consider.

> First is that I would think that it might be a waste of valuable dev 
> time if all core devs read all bug reports on oe-issues.  Of course, 
> that is an individual decision.  But if we got something like bug 
> triaging going in a more instituationalized way, it might indeed become
> unnecessary.  Second, bugzilla offers many settings on what mails you 
> want to receive and which you don't at 
> http://bugs.openembedded.org/userprefs.cgi?tab=email.  If you read 
> oe-issues, you might want to consider deactivating all mail from 
> bugzilla itself to keep the load down.

        I guess this solution is straight into bull's eye - why spend
time communicating your preferences to other people (or, fingers
crossed, quarrel with them), if they instead can be communicated to
Bugzilla, which is there to serve all needs. The same goes for
everyone's best friend, an email client, which has cool things like
folders and filters, and opens their wonders to everyone who wants to
*receive* their mail the way they want, instead of arguing with the
whole world (or arbitrary part of it) how it should send mail to them ;-)


-- 
Best regards,
 Paul                            mailto:pmiscml at gmail.com




From leon.woestenberg at gmail.com  Sun May 13 16:45:04 2007
From: leon.woestenberg at gmail.com (Leon Woestenberg)
Date: Sun, 13 May 2007 18:45:04 +0200
Subject: [oe] uclibc 0.9.29 recipe
In-Reply-To: <46462BDD.6000302@dominion.kabel.utwente.nl>
References: <464613B3.8090003@dominion.kabel.utwente.nl>
	<46461B73.8070900@trolltech.com>
	<46461D72.4020206@dominion.kabel.utwente.nl>
	<46462BDD.6000302@dominion.kabel.utwente.nl>
Message-ID: <c384c5ea0705130945k266d8bccw4f890d99d9997e52@mail.gmail.com>

Hello Koen,

On 5/12/07, Koen Kooi <koen at dominion.kabel.utwente.nl> wrote:
> Koen Kooi schreef:
> To add support for your favourite machine: use uClibc.distro as .config,
> configure uclibc for the target you want, save the top 2 blocks of .config (cpu
> and arch) to uClibc.distro  in uclibc-0.9.29/<machine/uClibc.machine
>
> The recipe is by no means perfect, so any help is welcome.
>
As often, you laid the groundworks, which is often more important than
the make-it-perfect stage.

My hands are twitching to create a clean 0.9.29 .bb that more smartly
configures the library matching the OpenEmbedded configuration. But
let's hack the current setup first.

Who is using uClibc now? In other words, can I break stuff?

Regards,
-- 
Leon



From koen at dominion.kabel.utwente.nl  Sun May 13 16:55:49 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Sun, 13 May 2007 18:55:49 +0200
Subject: [oe] uclibc 0.9.29 recipe
In-Reply-To: <c384c5ea0705130945k266d8bccw4f890d99d9997e52@mail.gmail.com>
References: <464613B3.8090003@dominion.kabel.utwente.nl>	<46461B73.8070900@trolltech.com>	<46461D72.4020206@dominion.kabel.utwente.nl>	<46462BDD.6000302@dominion.kabel.utwente.nl>
	<c384c5ea0705130945k266d8bccw4f890d99d9997e52@mail.gmail.com>
Message-ID: <46474315.1070207@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Leon Woestenberg schreef:
> Hello Koen,
> 
> On 5/12/07, Koen Kooi <koen at dominion.kabel.utwente.nl> wrote:
>> Koen Kooi schreef:
>> To add support for your favourite machine: use uClibc.distro as .config,
>> configure uclibc for the target you want, save the top 2 blocks of .config (cpu
>> and arch) to uClibc.distro  in uclibc-0.9.29/<machine/uClibc.machine
>>
>> The recipe is by no means perfect, so any help is welcome.
>>
> As often, you laid the groundworks, which is often more important than
> the make-it-perfect stage.
> 
> My hands are twitching to create a clean 0.9.29 .bb that more smartly
> configures the library matching the OpenEmbedded configuration. But
> let's hack the current setup first.

It would be nice to set archicture using TARGET_ARCH, endiannes with the info from
siteinfo.bbclass and the the FPU with TARGET_FPU. I bet there are some more options that
could be autoconfigured.

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGR0MVMkyGM64RGpERAmpLAJ40KalkcxFc1oOFNSfOrMB7dypN7gCZAeg4
4C42BTmMvEcIiALtDpSx/eY=
=yp3m
-----END PGP SIGNATURE-----



From leon.woestenberg at gmail.com  Sun May 13 21:39:41 2007
From: leon.woestenberg at gmail.com (Leon Woestenberg)
Date: Sun, 13 May 2007 23:39:41 +0200
Subject: [oe] uclibc 0.9.29 recipe
In-Reply-To: <46474315.1070207@dominion.kabel.utwente.nl>
References: <464613B3.8090003@dominion.kabel.utwente.nl>
	<46461B73.8070900@trolltech.com>
	<46461D72.4020206@dominion.kabel.utwente.nl>
	<46462BDD.6000302@dominion.kabel.utwente.nl>
	<c384c5ea0705130945k266d8bccw4f890d99d9997e52@mail.gmail.com>
	<46474315.1070207@dominion.kabel.utwente.nl>
Message-ID: <c384c5ea0705131439o1a2b71b8i26a16123ae1c591e@mail.gmail.com>

perl 5.8.8 needs:

UCLIBC_SUSV3_LEGACY=y
UCLIBC_SUSV3_LEGACY_MACROS=y



From xjqian at gmail.com  Mon May 14 08:08:03 2007
From: xjqian at gmail.com (Junqian Gordon Xu)
Date: Mon, 14 May 2007 03:08:03 -0500
Subject: [oe] RFD: Bugzilla in general & bug triaging
In-Reply-To: <f277j3$i00$1@sea.gmane.org>
References: <1179059149.5404.3.camel@cimmeria.hyboria>
	<f277j3$i00$1@sea.gmane.org>
Message-ID: <464818E3.7090203@gmail.com>

Rolf,

Is it a problem if I replace the openembedded-issues@ with my email 
address in the Reassign to field? Does openembedded-issues still gets 
all the updates?

I don't want only me receiving the emails even I assign the bug to myself.

regards
Gordon

Rolf Leggewie wrote:
> Graeme Gregory wrote:
>   
>> RFC
>>
>> Dont add people to CC field of bugs without talking to them.
>>     
>
> Thank you Graeme for raising this issue.  It is something I meant to 
> discuss earlier but never found enough time to think it through and 
> write up something.  I still have not thought it through, but here it goes.
>
> Let me first say, that I am totally aware that we are all doing this in 
> our limited free time.  We also all don't like things being stuffed down 
> our throat.  There is a bit of dilemma here.
>
> As a non-dev, I feel one of the better ways for me and others alike is 
> to make sure the BTS is in good shape.  It is called bug triaging which 
> I also do in other projects.  For me, this is all about efficiency, 
> division of labor so to speak (although that capitalistic thinking might 
> not go down too well with all of us freeminds ;-))  The idea is that 
> there is someone who sifts through the bug reports and makes sure they 
> are understandable, complete and real.  The triager also crosslinks bugs 
> that share similarities and classifies them.   All this *before they eat 
> up valuable time from a real dev*.  That is at least what I am trying to 
> do, for the devs to sit down and find well-structured problems to work 
> on whenever they feel like it (I know the OE BTS is not there yet, bug 
> 2194 is a shy start at this).
>
> This is how Ubuntu and Mozilla approach the bugs they receive.  But it 
> needs a way to signal "Hey, this bug is OK" and furthermore bugs are 
> usually assigned to the most appropriate person.  So that is what I did 
> first, assign bugs to the people I thought would be most appropriate in 
> dealing with them.  That did not go down so well :-)  So, it was 
> suggested to me that instead of assigning, I should cc people.  But that 
> is certainly not the best solution, either.
>
> I believe it would be great if OE started some kind of not too rigid 
> process of triaging bugs.  All projects are a bit different, so what do 
> you think would be the best way for OE to handle this?
>
>  > Everyone on oe-issues list gets all bug reports anyway and I can use
>  > web search quite effectively myself.
>
> Graeme, I understand your concern.  I don't mean to say "Hey, here is 
> the solution" but maybe there are some options you might consider.
>
> First is that I would think that it might be a waste of valuable dev 
> time if all core devs read all bug reports on oe-issues.  Of course, 
> that is an individual decision.  But if we got something like bug 
> triaging going in a more instituationalized way, it might indeed become 
> unnecessary.  Second, bugzilla offers many settings on what mails you 
> want to receive and which you don't at 
> http://bugs.openembedded.org/userprefs.cgi?tab=email.  If you read 
> oe-issues, you might want to consider deactivating all mail from 
> bugzilla itself to keep the load down.
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>
>   




From pmiscml at gmail.com  Mon May 14 08:25:58 2007
From: pmiscml at gmail.com (Paul Sokolovsky)
Date: Mon, 14 May 2007 11:25:58 +0300
Subject: [oe] RFD: Bugzilla in general & bug triaging
In-Reply-To: <464818E3.7090203@gmail.com>
References: <1179059149.5404.3.camel@cimmeria.hyboria>
	<f277j3$i00$1@sea.gmane.org> <464818E3.7090203@gmail.com>
Message-ID: <24757045.20070514112558@gmail.com>

Hello Junqian,

Monday, May 14, 2007, 11:08:03 AM, you wrote:

> Rolf,

> Is it a problem if I replace the openembedded-issues@ with my email 
> address in the Reassign to field? Does openembedded-issues still gets 
> all the updates?

        As Rolf described in his mail, we do not reassign bugs in our
workflow - they keep being assigned to ML. That's corresponds to
the fact/reassures that we don't have bug owners in OE, and entire
community welcome to/works on any issue (which in turn is based on the
fact that we don't have dedicated engineers to resolve bugs).

> I don't want only me receiving the emails even I assign the bug to myself.

> regards
> Gordon

> Rolf Leggewie wrote:
[]

-- 
Best regards,
 Paul                            mailto:pmiscml at gmail.com




From xjqian at gmail.com  Mon May 14 08:49:12 2007
From: xjqian at gmail.com (Junqian Gordon Xu)
Date: Mon, 14 May 2007 03:49:12 -0500
Subject: [oe] RFD: Bugzilla in general & bug triaging
In-Reply-To: <24757045.20070514112558@gmail.com>
References: <1179059149.5404.3.camel@cimmeria.hyboria>
	<f277j3$i00$1@sea.gmane.org> <464818E3.7090203@gmail.com>
	<24757045.20070514112558@gmail.com>
Message-ID: <46482288.2040904@gmail.com>

Paul Sokolovsky wrote:
> Hello Junqian,
>
> Monday, May 14, 2007, 11:08:03 AM, you wrote:
>
>   
>> Is it a problem if I replace the openembedded-issues@ with my email 
>> address in the Reassign to field? Does openembedded-issues still gets 
>> all the updates?
>>     
>
>         As Rolf described in his mail, we do not reassign bugs in our
> workflow - they keep being assigned to ML. That's corresponds to
> the fact/reassures that we don't have bug owners in OE, and entire
> community welcome to/works on any issue (which in turn is based on the
> fact that we don't have dedicated engineers to resolve bugs).

Paul,

One benefit of reassigning the bug to myself is that I can click the "My 
Bug" button and list all my filed and self-assigned bugs, instead of 
remembering the bug number or relying on search.

I'm undoing the damages right now. But please let me know if there's an 
alternative to easily keep track of interested bugs.  Well, maybe I'm 
too lazy.

Gordon




From pmiscml at gmail.com  Mon May 14 09:06:30 2007
From: pmiscml at gmail.com (Paul Sokolovsky)
Date: Mon, 14 May 2007 12:06:30 +0300
Subject: [oe] RFD: Bugzilla in general & bug triaging
In-Reply-To: <46482288.2040904@gmail.com>
References: <1179059149.5404.3.camel@cimmeria.hyboria>
	<f277j3$i00$1@sea.gmane.org> <464818E3.7090203@gmail.com>
	<24757045.20070514112558@gmail.com> <46482288.2040904@gmail.com>
Message-ID: <1851689443.20070514120630@gmail.com>

Hello Junqian,

Monday, May 14, 2007, 11:49:12 AM, you wrote:

> Paul Sokolovsky wrote:
>> Hello Junqian,
>>
>> Monday, May 14, 2007, 11:08:03 AM, you wrote:
>>
>>   
>>> Is it a problem if I replace the openembedded-issues@ with my email 
>>> address in the Reassign to field? Does openembedded-issues still gets 
>>> all the updates?
>>>     
>>
>>         As Rolf described in his mail, we do not reassign bugs in our
>> workflow - they keep being assigned to ML. That's corresponds to
>> the fact/reassures that we don't have bug owners in OE, and entire
>> community welcome to/works on any issue (which in turn is based on the
>> fact that we don't have dedicated engineers to resolve bugs).

> Paul,

> One benefit of reassigning the bug to myself is that I can click the "My
> Bug" button and list all my filed and self-assigned bugs, instead of 
> remembering the bug number or relying on search.

        I well understand benefits of assigning bugs, it's just the
fact that OE doesn't assign them (as as was mentioned, it's good, as
have psychological effect of welcoming everyone to work on things, not
think "well, that guy will fix it" or "oh, it's that guy's, I can't
touch it").

> I'm undoing the damages right now. But please let me know if there's an
> alternative to easily keep track of interested bugs.  Well, maybe I'm 
> too lazy.

        You still better rely on search. And Bugzilla is a powerful
("enterprise-grade" ;-) ) tool, which allows you to do many things.
For example, that's how I have it set up: I add myself to cc: of the
interesting bugs (in full accordance to Rolf's RFD), then once made
an advanced search setup, which searches for my address in any email
field (reporter, cc, etc.), and saved it as saved search. Now, it's
the same one click as predefined "My Bugs" search. And you can have
number of saved searches, for machines of your interest, for software,
etc. - all one click away.

> Gordon


-- 
Best regards,
 Paul                            mailto:pmiscml at gmail.com




From koen at dominion.kabel.utwente.nl  Mon May 14 09:06:43 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Mon, 14 May 2007 11:06:43 +0200
Subject: [oe] RFD: Bugzilla in general & bug triaging
In-Reply-To: <46482288.2040904@gmail.com>
References: <1179059149.5404.3.camel@cimmeria.hyboria>	<f277j3$i00$1@sea.gmane.org>
	<464818E3.7090203@gmail.com>	<24757045.20070514112558@gmail.com>
	<46482288.2040904@gmail.com>
Message-ID: <464826A3.7010505@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Junqian Gordon Xu schreef:
> Paul Sokolovsky wrote:
>> Hello Junqian,
>>
>> Monday, May 14, 2007, 11:08:03 AM, you wrote:
>>
>>   
>>> Is it a problem if I replace the openembedded-issues@ with my email 
>>> address in the Reassign to field? Does openembedded-issues still gets 
>>> all the updates?
>>>     
>>         As Rolf described in his mail, we do not reassign bugs in our
>> workflow - they keep being assigned to ML. That's corresponds to
>> the fact/reassures that we don't have bug owners in OE, and entire
>> community welcome to/works on any issue (which in turn is based on the
>> fact that we don't have dedicated engineers to resolve bugs).
> 
> Paul,
> 
> One benefit of reassigning the bug to myself is that I can click the "My 
> Bug" button and list all my filed and self-assigned bugs, instead of 
> remembering the bug number or relying on search.
> 
> I'm undoing the damages right now. But please let me know if there's an 
> alternative to easily keep track of interested bugs.  Well, maybe I'm 
> too lazy.

You could assign to yourself and add oe-issues in CC:

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGSCajMkyGM64RGpERAldiAKCqrJcD6ZE0ULRWcz1Ksxxi+LQ2dACdHXvV
cdawEzHNUHLAOXzREdLLIKQ=
=wDhJ
-----END PGP SIGNATURE-----



From xjqian at gmail.com  Mon May 14 09:18:09 2007
From: xjqian at gmail.com (Junqian Gordon Xu)
Date: Mon, 14 May 2007 04:18:09 -0500
Subject: [oe] RFD: Bugzilla in general & bug triaging
In-Reply-To: <1851689443.20070514120630@gmail.com>
References: <1179059149.5404.3.camel@cimmeria.hyboria>
	<f277j3$i00$1@sea.gmane.org> <464818E3.7090203@gmail.com>
	<24757045.20070514112558@gmail.com> <46482288.2040904@gmail.com>
	<1851689443.20070514120630@gmail.com>
Message-ID: <46482951.8060803@gmail.com>

Paul Sokolovsky wrote:
>> I'm undoing the damages right now. But please let me know if there's an
>> alternative to easily keep track of interested bugs.  Well, maybe I'm 
>> too lazy.
>>     
>
>         You still better rely on search. And Bugzilla is a powerful
> ("enterprise-grade" ;-) ) tool, which allows you to do many things.
> For example, that's how I have it set up: I add myself to cc: of the
> interesting bugs (in full accordance to Rolf's RFD), then once made
> an advanced search setup, which searches for my address in any email
> field (reporter, cc, etc.), and saved it as saved search. Now, it's
> the same one click as predefined "My Bugs" search. And you can have
> number of saved searches, for machines of your interest, for software,
> etc. - all one click away

Thanks for the great tip. When I said I was too lazy, that's also 
including that I'm too lazy to study/play with all the features of 
Bugzilla, esp. considering the enterprise-grade motto :)

Gordon



From koen at dominion.kabel.utwente.nl  Mon May 14 09:42:59 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Mon, 14 May 2007 11:42:59 +0200
Subject: [oe] [oe-commits] org.oe.dev ixp4xx-kernel: Dropped support for
 2.6.21, we're sticking to 2.6.20 stable and 2.6.22 development
In-Reply-To: <E1HnWn2-0007PS-SW@linuxtogo.org>
References: <E1HnWn2-0007PS-SW@linuxtogo.org>
Message-ID: <46482F23.9050504@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

rwhitby commit schreef:
> ixp4xx-kernel: Dropped support for 2.6.21, we're sticking to 2.6.20 stable and 2.6.22 development

> # delete "packages/linux/ixp4xx-kernel_2.6.21.bb"

You broke feeds and upgrade paths for users of that recipe, could you next time just add
DEFAULT_PREFERENCE = "-1" or something? Slugos isn't the only user of OE!
 I just got .21 running on my ixp4xx board, and now I have to remove all kernel packages,
packages built against .21 and find a way for angstrom to deal with that in the feeds for
people doing 'ipkg upgrade'.

I will deal with it, but next time a bit of warning on the OE list would be appreciated.

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGSC8jMkyGM64RGpERAl+UAJ42rD9nGX4EcbKJRzD0yXAgAjwWDwCfaFjg
NoUOnnEP5xC3YJodBtkjQCI=
=a0fc
-----END PGP SIGNATURE-----



From rod at whitby.id.au  Mon May 14 10:14:56 2007
From: rod at whitby.id.au (Rod Whitby)
Date: Mon, 14 May 2007 19:44:56 +0930
Subject: [oe] [oe-commits] org.oe.dev ixp4xx-kernel: Dropped support for
 2.6.21, we're sticking to 2.6.20 stable and 2.6.22 development
In-Reply-To: <46482F23.9050504@dominion.kabel.utwente.nl>
References: <E1HnWn2-0007PS-SW@linuxtogo.org>
	<46482F23.9050504@dominion.kabel.utwente.nl>
Message-ID: <464836A0.6050705@whitby.id.au>

Koen Kooi wrote:
> rwhitby commit schreef:
>>> ixp4xx-kernel: Dropped support for 2.6.21, we're sticking to 2.6.20 stable and 2.6.22 development
> 
>>> # delete "packages/linux/ixp4xx-kernel_2.6.21.bb"
> 
> You broke feeds and upgrade paths for users of that recipe, could you next time just add
> DEFAULT_PREFERENCE = "-1" or something? Slugos isn't the only user of OE!

My apologies.  Mea culpa.

>  I just got .21 running on my ixp4xx board, and now I have to remove all kernel packages,
> packages built against .21 and find a way for angstrom to deal with that in the feeds for
> people doing 'ipkg upgrade'.

I'll put it back immediately.

-- Rod



From no2spam at nospam.arcornews.de  Mon May 14 10:16:37 2007
From: no2spam at nospam.arcornews.de (Rolf Leggewie)
Date: Mon, 14 May 2007 12:16:37 +0200
Subject: [oe] RFD: Bugzilla in general & bug triaging
In-Reply-To: <46482288.2040904@gmail.com>
References: <1179059149.5404.3.camel@cimmeria.hyboria>	<f277j3$i00$1@sea.gmane.org>
	<464818E3.7090203@gmail.com>	<24757045.20070514112558@gmail.com>
	<46482288.2040904@gmail.com>
Message-ID: <f29cu8$lol$1@sea.gmane.org>

Junqian Gordon Xu wrote:
>>         As Rolf described in his mail, we do not reassign bugs in our
>> workflow 

Actually that is neither what I wrote nor what I'd propose ;-)  I have 
no issue with you assigning 2309 to yourself.  You seem to take good 
care of it.

> One benefit of reassigning the bug to myself is that I can click the "My 
> Bug" button and list all my filed and self-assigned bugs, instead of 
> remembering the bug number or relying on search.

yes, very valid point.  It innocently illustrates the kind of workflow 
I'd be looking for (and that I use to a certain degree for myself).  You 
have a link with a search function saved in bugzilla and when you click 
on it all the bugs that need your attention or that you are interested 
in are right there.

Gordon, maybe you want to save http://tinyurl.com/385p8b  You could also 
separate that out to only list cc bugs or whatever suits your needs. 
Tweak it to your liking.

Here are three searches that I use and deem useful for others

http://tinyurl.com/2oypog (todays bugs: action: stay current)
http://tinyurl.com/35l78g (bugs where compilation fails, action: verify)
http://tinyurl.com/39gss8 (old with patches, action: inspect, commit)




From no2spam at nospam.arcornews.de  Mon May 14 10:28:30 2007
From: no2spam at nospam.arcornews.de (Rolf Leggewie)
Date: Mon, 14 May 2007 12:28:30 +0200
Subject: [oe] RFD: Bugzilla in general & bug triaging
In-Reply-To: <f277j3$i00$1@sea.gmane.org>
References: <1179059149.5404.3.camel@cimmeria.hyboria>
	<f277j3$i00$1@sea.gmane.org>
Message-ID: <f29dkh$o3v$1@sea.gmane.org>

Rolf Leggewie wrote:
> Thank you Graeme for raising this issue.  It is something I meant to 
> discuss earlier but never found enough time to think it through and 
> write up something.  I still have not thought it through, but here it goes.

I have asked and been granted greater powers on bugzilla.  There are 
features which we don't use yet but which could aid in establishing a 
sane workflow while rendering unnecessary the current clutches and 
ad-hoc fixes.

Bugzilla will be upgraded soon and no structural changes will be made 
until that is completed.  But that leaves us some good time to think 
about how this should be enhanced.

Things I'd like to see
* confirmation flags
* better documentation of workflow status (need to define it first)
* assigning bugs (or if you prefer "Hey, please take a look")
* link to some bug searches like the ones I send about 5 minutes ago
   on the entry page
* entry page clean-up (why two search fields?)
* removal of dead stuff (ZaurusKernel, Familiar)

Please add to the list.  The most important point is the second.  That 
is what we should discuss.




From pmiscml at gmail.com  Mon May 14 11:26:44 2007
From: pmiscml at gmail.com (Paul Sokolovsky)
Date: Mon, 14 May 2007 14:26:44 +0300
Subject: [oe] RFD: Bugzilla in general & bug triaging
In-Reply-To: <f29cu8$lol$1@sea.gmane.org>
References: <1179059149.5404.3.camel@cimmeria.hyboria>
	<f277j3$i00$1@sea.gmane.org> <464818E3.7090203@gmail.com>
	<24757045.20070514112558@gmail.com>
	<46482288.2040904@gmail.com> <f29cu8$lol$1@sea.gmane.org>
Message-ID: <1848419262.20070514142644@gmail.com>

Hello Rolf,

Monday, May 14, 2007, 1:16:37 PM, you wrote:

> Junqian Gordon Xu wrote:
>>>         As Rolf described in his mail, we do not reassign bugs in our
>>> workflow 

> Actually that is neither what I wrote nor what I'd propose ;-)

        Well, ok, what you wrote is that you once tried assign bugs,
but was suggested not to do that. If you want to propose that again,
then the same suggestion: please don't do that. The reasons were
given, and I reiterate over the matter below again.

> I have
> no issue with you assigning 2309 to yourself.  You seem to take good 
> care of it.

>> One benefit of reassigning the bug to myself is that I can click the "My 
>> Bug" button and list all my filed and self-assigned bugs, instead of 
>> remembering the bug number or relying on search.

> yes, very valid point.  It innocently illustrates the kind of workflow
> I'd be looking for (and that I use to a certain degree for myself).

        That's kind of bug workflow most projects use, be them
opensource or commercial, so no wonder. But such workflow works
especially well if as many as possible of the following are true:

1. Scope of project and functional areas are well defined.
2. There're dedicated developer for each area.
3. There's a manager who performs assignment.

        None of these are true for OE - the scope is too wide, areas
either to big (like, a distro), or too diversified (issues with
specific package or machine), there're no dedicated developers for
specific areas, and no manager who tells folks what to do.

        So, there's another workflow, of course not so organized, but
flexible and well fitting OE devel model, the reason why it was there
well before you or me came into active contribution.

> You
> have a link with a search function saved in bugzilla and when you click
> on it all the bugs that need your attention or that you are interested
> in are right there.

        Yes, you have saved searches, you have email preferences, you
have other cool things in Bugzilla, you learn to use them well in
framework on the existing workflow, before trying to revolutionize the
workflow itself.

> Gordon, maybe you want to save http://tinyurl.com/385p8b  You could also
> separate that out to only list cc bugs or whatever suits your needs. 
> Tweak it to your liking.

> Here are three searches that I use and deem useful for others

> http://tinyurl.com/2oypog (todays bugs: action: stay current)
> http://tinyurl.com/35l78g (bugs where compilation fails, action: verify)
> http://tinyurl.com/39gss8 (old with patches, action: inspect, commit)

        These links are nice, but won't help too much. Until people
start to make bug filters which *they* like and need, there always be
idea that something's lacking and that you need to put it upside down
trying to make it "work" for you.

-- 
Best regards,
 Paul                            mailto:pmiscml at gmail.com




From koen at dominion.kabel.utwente.nl  Mon May 14 12:06:27 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Mon, 14 May 2007 14:06:27 +0200
Subject: [oe] Making /var/lib persistent
In-Reply-To: <31583224.20070510180054@gmail.com>
References: <1176760923.4623f25b913f9@dominion.kabel.utwente.nl>	<20070418090235.GA21841@twibble.org>	<46262A0F.1050805@dominion.kabel.utwente.nl>	<20070419014949.GA6540@twibble.org>
	<31583224.20070510180054@gmail.com>
Message-ID: <464850C3.90202@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Paul Sokolovsky schreef:
> Hello Jamie,
> 
> Thursday, April 19, 2007, 4:49:50 AM, you wrote:
> 
>> On Wed, Apr 18, 2007 at 07:24:15AM -0700, Koen Kooi wrote:
>> [...]
>>> Sound like a good idea, do you have a patch for this?
> 
>> Try this out:
> 
>>   http://twibble.org/dist/oe/var-volatiles-1.patch
> 
>> I've tested it locally both with and without tmpfs mounted on
>> /var/volatile and all seems to work as expected.
> 
>         Any news on this? I've been running with this patch soon since
> its original post and don't see any issues. One small nuisance is that
> ls -l /var/log doesn't show what you want, but hardly something can be
> done about that, plus shell completion uses /var/log/ immediately.
> 
>         I suggest committing this patch.

After I have fixed up the rejects I'll commit and push it.

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGSFDDMkyGM64RGpERArsZAJ0aPIXjYQW8TcJ4qd5z01RWFbSAUACfWBU0
zg9Qmq0tPnSryt6WDAOki3o=
=DO2J
-----END PGP SIGNATURE-----



From koen at dominion.kabel.utwente.nl  Mon May 14 12:21:14 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Mon, 14 May 2007 14:21:14 +0200
Subject: [oe] Making /var/lib persistent
In-Reply-To: <464850C3.90202@dominion.kabel.utwente.nl>
References: <1176760923.4623f25b913f9@dominion.kabel.utwente.nl>	<20070418090235.GA21841@twibble.org>	<46262A0F.1050805@dominion.kabel.utwente.nl>	<20070419014949.GA6540@twibble.org>	<31583224.20070510180054@gmail.com>
	<464850C3.90202@dominion.kabel.utwente.nl>
Message-ID: <4648543A.8080202@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Koen Kooi schreef:

>>>   http://twibble.org/dist/oe/var-volatiles-1.patch

> After I have fixed up the rejects I'll commit and push it.

Ok, it's in, please report any errors/bugs/features

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGSFQ6MkyGM64RGpERAnezAKCfPi397VPH5q72q+wxpLKl9wFtMQCfdHQg
kozdbu7EzNnNWf5zgwr4oBw=
=qZ8t
-----END PGP SIGNATURE-----



From koen at dominion.kabel.utwente.nl  Mon May 14 12:30:00 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Mon, 14 May 2007 14:30:00 +0200
Subject: [oe] uclibc 0.9.29 recipe
In-Reply-To: <c384c5ea0705131439o1a2b71b8i26a16123ae1c591e@mail.gmail.com>
References: <464613B3.8090003@dominion.kabel.utwente.nl>	<46461B73.8070900@trolltech.com>	<46461D72.4020206@dominion.kabel.utwente.nl>	<46462BDD.6000302@dominion.kabel.utwente.nl>	<c384c5ea0705130945k266d8bccw4f890d99d9997e52@mail.gmail.com>	<46474315.1070207@dominion.kabel.utwente.nl>
	<c384c5ea0705131439o1a2b71b8i26a16123ae1c591e@mail.gmail.com>
Message-ID: <46485648.8000705@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Leon Woestenberg schreef:
> perl 5.8.8 needs:
> 
> UCLIBC_SUSV3_LEGACY=y
> UCLIBC_SUSV3_LEGACY_MACROS=y

Feel free to add those to (angstrom/)uClibc.distro

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGSFZIMkyGM64RGpERAm6LAJ9zXFxGitsAcWxB9MBPXT8qYQMrvwCcC6ro
XdSuqhAYD0TKlipoSA0pQJ0=
=d9jH
-----END PGP SIGNATURE-----



From rpurdie at rpsys.net  Mon May 14 12:42:32 2007
From: rpurdie at rpsys.net (Richard Purdie)
Date: Mon, 14 May 2007 13:42:32 +0100
Subject: [oe] do_rootfs fails
In-Reply-To: <1178928474.4954.18.camel@localhost.localdomain>
References: <4644ABCB.6080202@openhardware.net>
	<4644B0D2.8020409@dominion.kabel.utwente.nl>
	<1178928474.4954.18.camel@localhost.localdomain>
Message-ID: <1179146552.5877.1.camel@localhost.localdomain>

On Sat, 2007-05-12 at 02:07 +0200, Matthias Hentges wrote:
> Am Freitag, den 11.05.2007, 20:07 +0200 schrieb Koen Kooi:
> 
> > All: Are we still going to wait 1.5 months with requiring 1.8.x? I've seen enough proof
> > that 1.6.x is broken with current .dev, with no effort to fix it. "Giving people time to
> > prepare the upgrade" has now turned into "Stabbing user in the eye" :(
> > 
> > regards,
> > 
> > Koen
> 
> 1.8.x has a show-stopper freeze-bug for some users ( including myself )
> which has not been fixed or even looked into yet.

Nobody has reported this properly although I keep hearing mention of it.

Could you send me the output from stty in your usual development
environment please?

Thanks,

Richard






From openembedded at hrw.one.pl  Mon May 14 13:28:12 2007
From: openembedded at hrw.one.pl (Marcin Juszkiewicz)
Date: Mon, 14 May 2007 15:28:12 +0200
Subject: [oe] RFD: Bugzilla in general & bug triaging
In-Reply-To: <f29dkh$o3v$1@sea.gmane.org>
References: <1179059149.5404.3.camel@cimmeria.hyboria>
	<f277j3$i00$1@sea.gmane.org> <f29dkh$o3v$1@sea.gmane.org>
Message-ID: <200705141528.12352.openembedded@hrw.one.pl>

Dnia poniedzia?ek, 14 maja 2007, Rolf Leggewie napisa?:

> Bugzilla will be upgraded soon and no structural changes will be made
> until that is completed.  But that leaves us some good time to think
> about how this should be enhanced.

> Please add to the list.  The most important point is the second.  That
> is what we should discuss.

MACHINE field would be useful - there are bugs specific to machine (kernel 
bug etc) which now have it in title or comment. 






From ulf at atmel.com  Mon May 14 13:14:03 2007
From: ulf at atmel.com (Ulf Samuelsson)
Date: Mon, 14 May 2007 15:14:03 +0200
Subject: [oe] qemu-native failure on Angstrom
Message-ID: <07a101c7962b$e0db5860$0200a8c0@atmel.com>

Tried building OpenEmbedded for the first time, DISTRO=?ngstr?m, 
with an at91sam9263 target (made my own file) but it seems that
qemu.native is not compilable on my OpenSuSE 10.1 system using gcc-4.1.2.
The error message says that qemu has only been tested on gcc-4.x.x for arm
and that other architectures need gcc-3.x

Tried to update the bb files to allow gcc-4.1.2 but that resulted in
qemu-arm not beeing built, causing the build to terminate later.

Is there any way to have open embedded build a gcc-3.4.4 cross compiler
as part of the normal build.

Best Regards
Ulf Samuelsson




From koen at dominion.kabel.utwente.nl  Mon May 14 13:40:44 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Mon, 14 May 2007 15:40:44 +0200
Subject: [oe] qemu-native failure on Angstrom
In-Reply-To: <07a101c7962b$e0db5860$0200a8c0@atmel.com>
References: <07a101c7962b$e0db5860$0200a8c0@atmel.com>
Message-ID: <464866DC.6060502@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ulf Samuelsson schreef:
> Tried building OpenEmbedded for the first time, DISTRO=?ngstr?m, 
> with an at91sam9263 target (made my own file) but it seems that
> qemu.native is not compilable on my OpenSuSE 10.1 system using gcc-4.1.2.
> The error message says that qemu has only been tested on gcc-4.x.x for arm
> and that other architectures need gcc-3.x
> 
> Tried to update the bb files to allow gcc-4.1.2 but that resulted in
> qemu-arm not beeing built, causing the build to terminate later.
> 
> Is there any way to have open embedded build a gcc-3.4.4 cross compiler
> as part of the normal build.

You want a native gcc3 on your host, since qemu-native will be compiled with that, on
debian that can be done with 'apt-get install gcc-3.4'.

Alternatively you can set ENABLE_BINARY_LOCALE_GENERATION = "0" in your local.conf.

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGSGbcMkyGM64RGpERAlXOAJ9HlfnJ5CbfVrHd3lOIBsDfyqbDqgCgmzv5
4tDq+oZskVRAfnxs7rWNlVA=
=OQ93
-----END PGP SIGNATURE-----



From skyhusker at rm-fr.net  Mon May 14 13:46:02 2007
From: skyhusker at rm-fr.net (Alberto =?iso-8859-1?q?Garc=EDa_Hierro?=)
Date: Mon, 14 May 2007 15:46:02 +0200
Subject: [oe] qemu-native failure on Angstrom
In-Reply-To: <07a101c7962b$e0db5860$0200a8c0@atmel.com>
References: <07a101c7962b$e0db5860$0200a8c0@atmel.com>
Message-ID: <200705141546.02470.skyhusker@rm-fr.net>

El Monday 14 May 2007 15:14:03 Ulf Samuelsson escribi?:
> Tried building OpenEmbedded for the first time, DISTRO=?ngstr?m,
> with an at91sam9263 target (made my own file) but it seems that
> qemu.native is not compilable on my OpenSuSE 10.1 system using gcc-4.1.2.
> The error message says that qemu has only been tested on gcc-4.x.x for arm
> and that other architectures need gcc-3.x
>
> Tried to update the bb files to allow gcc-4.1.2 but that resulted in
> qemu-arm not beeing built, causing the build to terminate later.
>
> Is there any way to have open embedded build a gcc-3.4.4 cross compiler
> as part of the normal build.

	Check the patch at http://bugs.openembedded.org/show_bug.cgi?id=1144. It's 
for amd64, but with little editing you can adapt it to your system.

Regards,
	Alberto


-- 
Alberto Garc?a Hierro
http://zeus.rm-fr.net/~skyhusker/



From pmiscml at gmail.com  Mon May 14 14:13:06 2007
From: pmiscml at gmail.com (Paul Sokolovsky)
Date: Mon, 14 May 2007 17:13:06 +0300
Subject: [oe] qemu-native failure on Angstrom
In-Reply-To: <200705141546.02470.skyhusker@rm-fr.net>
References: <07a101c7962b$e0db5860$0200a8c0@atmel.com>
	<200705141546.02470.skyhusker@rm-fr.net>
Message-ID: <783750430.20070514171306@gmail.com>

Hello Alberto,

Monday, May 14, 2007, 4:46:02 PM, you wrote:

> El Monday 14 May 2007 15:14:03 Ulf Samuelsson escribi?:
>> Tried building OpenEmbedded for the first time, DISTRO=?ngstr?m,
>> with an at91sam9263 target (made my own file) but it seems that
>> qemu.native is not compilable on my OpenSuSE 10.1 system using gcc-4.1.2.
>> The error message says that qemu has only been tested on gcc-4.x.x for arm
>> and that other architectures need gcc-3.x
>>
>> Tried to update the bb files to allow gcc-4.1.2 but that resulted in
>> qemu-arm not beeing built, causing the build to terminate later.
>>
>> Is there any way to have open embedded build a gcc-3.4.4 cross compiler
>> as part of the normal build.

>         Check the patch at
> http://bugs.openembedded.org/show_bug.cgi?id=1144. It's 
> for amd64, but with little editing you can adapt it to your system.

        Not sure this is anyhow good patch to suggest.
http://bugs.openembedded.org/show_bug.cgi?id=2157 is what promises to
solve gcc4 issues, but that still waits for the confirmation that
it actually cooks locales well.

> Regards,
>         Alberto





-- 
Best regards,
 Paul                            mailto:pmiscml at gmail.com




From ccsmart at smartpal.de  Mon May 14 17:15:16 2007
From: ccsmart at smartpal.de ([cc]smart)
Date: Mon, 14 May 2007 19:15:16 +0200
Subject: [oe] Making /var/lib persistent
Message-ID: <1179162916.23344.6.camel@localhost>

Hi list.

i must admit i am a bit late on the discussion but nonetheless... i
noticed the change on the tree and i would like to comment volatiles use
and the patch:

http://www.openembedded.org/viewmtn/revision.psp?id=d8f8ffd537ebb6baa3cabe50d3f8267cdd28f3b7

The discussion on the list was accompanied by:

>        The only concern is all this override files patchery. I wish 
>we had for fstab the same machinery as for autoconf site files - 
>ability to merge standard template with per-machine overrides. But 
>well, lack of such shouldn't be cause of delay with this patch, hope 
>to see it soon in mainline! 
> 
>Best regards, 
> Paul                            mailto:pmiscml at gmail.com


I would like to take you back a few years into history of volatiles,
because originally, it was invented primarily to assist in modular
configuration.

I'd like to start with the explanation given in the main volatiles
config file:


# This configuration file lists filesystem objects that should get
verified 
# during startup and be created if missing. 
# 
# Every line must either be a comment starting with # 
# or a definition of format: 
# <type> <owner> <group> <mode> <path> <linksource> 
# where the items are separated by whitespace ! 
# 
# <type> : d|f|l : (d)irectory|(f)ile|(l)ink 
# 
# A linking example: 
# l root root 0777 /var/test /tmp/testfile 
# f root root 0644 /var/test none 
# 
# Understanding links: 
# When populate-volatile is to verify/create a directory or file, it
will first 
# check it's existence. If a link is found to exist in the place of the
target, 
# the path of the target is replaced with the target the link points
to. 
# Thus, if a link is in the place to be verified, the object will be
created 
# in the place the link points to instead. 
# This explains the order of "link before object" as in the example
above, where 
# a link will be created at /var/test pointing to /tmp/testfile and due
to this 
# link the file defined as /var/test will actually be created
as /tmp/testfile.


FWIW, i think it has never been observed to create links before the
actual object. Why was it done like that despite it seems
counterintuitive.

Because it is part of the modulartity.

This main file should contain only basic, and only "real object"
descriptions. That is what it was at the beginning. All the redirection
into tmpfs space is NOT meant to be done in this file.

Basically it should roughly be kept like this (mind you, specifying
"none" in the end was not needed originally):

d root root 0755 /var/cache none 
d root root 1777 /var/lock none 
d root root 0755 /var/log none 
d root root 0755 /var/run none 
d root root 1777 /var/tmp none 
d root root 0755 /var/lock/subsys none 
f root root 0664 /var/log/wtmp none 
f root root 0664 /var/run/utmp none

In fstab, there should neither be tmpf on /var nor on /var/volatile but
for example under /media/ram only.

Now let your mind go back to the rule "link before object".

The default is a physical world. Volatiles would set up your directories
as described in it's configuration "ohysically".

If you create a distro for a device on flash, you would deliver your
image with links in var pointing to /media/ram. For example there would
be a link "/var/run" pointing to "/media/ram/run".

Automagically, volatiles would use the line

d root root 0755 /var/run none

to create a directory in "/media/ram". No need for changing the
volatiles base configuration (i hope that no change in volatiles as
broken this, otherwise IMHO it should be fixed to behave like that
again).

Subsequently turnup would only have to remove links in "/var" to get
that distro going on HD.

The second idea in the original design of volatiles is to have a tool
that allows adding and removing directory requirements per package. So a
package can drop in a specification in volatiles config directory. these
are numbered like runlevels.

This allows to have separate specification files. One defines the real
objects, like the base files does, and it's seq. number should be n+1 .

Additionally you may have a redirection config (possibly per distro)
with seq. number n which may redirect to volatile space, like
"/media/ram" .

Basically in thinking you always start physical and then deviate to
volatile.

All in all i would recommend to:

- revert volatiles main config to physical objects only 
- remove all /var based tmpfs's from /etc/fstab and make it more or less
a static thing. 
- get distros pre provide main redirection links in "/var" where needed.

Greetings, 
[cc]smart





From gerwin at vanderkruis.net  Mon May 14 18:38:31 2007
From: gerwin at vanderkruis.net (Gerwin)
Date: Mon, 14 May 2007 20:38:31 +0200
Subject: [oe] Questions: Founding of Open Embedded, dev gatherings etc.
In-Reply-To: <463C9ABC.7090503@dominion.kabel.utwente.nl>
References: <200705041909.29494.kyrvin@trolltech.com>
	<463C9ABC.7090503@dominion.kabel.utwente.nl>
Message-ID: <200705142038.32087.gerwin@vanderkruis.net>

Hi Knut, 

I have been quite busy myself as well , lot of embedded work and lot of 
php/java work. 

I am busy with a wimax kind of smartphone for the asian market which will run 
of course linux(currently hardware design fase). And some smaller projects so 
it is quite busy at this moment.  

> >
> > I got some experiences with developer gatherings after initiationg the
> > Skolelinux project in 2001. Actually we have organised +30 gatherings.
> > Skolelinux is now a part of DebianEdu. The board of "Free Software in
> > School" organises about 6-7 developer gatherings a year. Pictures from
> > opening of one of the gatherings in Forbach - France, gives an idea of
> > the scale:
> >
> > http://www.bawetic.be/PHOTOS/Forbach2006/
> >
> > I would like to see similar activeties in OpenEmbedded space. Maybe
> > Mobile Developer Days 2007 at Alborg University in Denmark could be the
> > place to start?:
> >

Yes I think so , the main problem is that our main developers are in the 
Netherlands , Germany , England and Poland. So yes we can send a delegation 
but I don't think that all developers will be there . I think we have a 
bigger chance if we organize something like this in the Netherlands or 
Germany. 

> > To sum it up. Gerwin van der Kruis idea is to make a foundation, and
> > getting dev.gatherings started. Is this interesting for you? If you are
> > interesed, how should we proceed?
>

We discussed about this also during fosdem and later on as well on irc, the 
main problem is time and knowledge . For example where should such a 
foundation be based , who is going to govern it etc. etc. 

OEDEM Frosconn and t-dose are the first opurtunities that we will be present .

I invited you for t-dose as well for a keynote. 


Kind Regards, 

Gerwin


-- 
The Holographic Klop Doctor

               -
               0
             - |
              \|\
               |/
               |
              /|
            _|_|

Underneath the mango tree  :) 



From oe at hentges.net  Mon May 14 22:23:00 2007
From: oe at hentges.net (Matthias Hentges)
Date: Tue, 15 May 2007 00:23:00 +0200
Subject: [oe] do_rootfs fails
In-Reply-To: <1178928474.4954.18.camel@localhost.localdomain>
References: <4644ABCB.6080202@openhardware.net>
	<4644B0D2.8020409@dominion.kabel.utwente.nl>
	<1178928474.4954.18.camel@localhost.localdomain>
Message-ID: <1179181380.4954.45.camel@localhost.localdomain>

Hello all,

Am Samstag, den 12.05.2007, 02:07 +0200 schrieb Matthias Hentges:

> 1.8.x has a show-stopper freeze-bug for some users ( including myself )
> which has not been fixed or even looked into yet.

RP was kind enough to look into the issue. The following command
unbreaks bitbake 1.8 on my build environment: 

stty -tostop

The IRC discussion leading to the fix is archived here:

http://hentges.net/tmp/logs/irc/%
23oe/2007/May/20070515_oe.log#[20070515%2000:08:46]
-- 
Matthias 'CoreDump' Hentges 
Cologne / Germany

Webmaster of Hentges.net & Embedded Linux Developer
GPG ->  gpg --keyserver gpg-keyserver.de --recv-keys 0xAF3030D9

My OS: Debian SID: Geek by Nature, Linux by Choice


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
URL: <http://layers.openembedded.org/pipermail/openembedded-devel/attachments/20070515/94aee16e/attachment.sig>

From koen at dominion.kabel.utwente.nl  Mon May 14 23:05:53 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Tue, 15 May 2007 01:05:53 +0200
Subject: [oe] Fixing up libtool-native and libtool-cross
Message-ID: <4648EB51.4040303@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Richard has fixed up libtool in Poky a bit and I want to merge his work into OE. Since
it's 1 AM now, and libtool is a pretty 'core' part, I'm posting the patch for review
before committing it tomorrow night.

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGSOtRMkyGM64RGpERAuiCAJ0Yqz+t4X/zNCjTbZIBU7yjaDt8twCgkgVq
iM3uwQTciklpQKjurM34Nys=
=W6UX
-----END PGP SIGNATURE-----
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: libtool.diff
URL: <http://layers.openembedded.org/pipermail/openembedded-devel/attachments/20070515/6b5c5c15/attachment.ksh>

From philipp.zabel at gmail.com  Tue May 15 07:53:30 2007
From: philipp.zabel at gmail.com (pHilipp Zabel)
Date: Tue, 15 May 2007 09:53:30 +0200
Subject: [oe] Fixing up libtool-native and libtool-cross
In-Reply-To: <4648EB51.4040303@dominion.kabel.utwente.nl>
References: <4648EB51.4040303@dominion.kabel.utwente.nl>
Message-ID: <74d0deb30705150053p109b57d6of67860d7fbb028ba@mail.gmail.com>

On 5/15/07, Koen Kooi <koen at dominion.kabel.utwente.nl> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
>
> Richard has fixed up libtool in Poky a bit and I want to merge his work into OE. Since
> it's 1 AM now, and libtool is a pretty 'core' part, I'm posting the patch for review
> before committing it tomorrow night.

Looks good to me.

> regards,
>
> Koen
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (Darwin)
>
> iD8DBQFGSOtRMkyGM64RGpERAuiCAJ0Yqz+t4X/zNCjTbZIBU7yjaDt8twCgkgVq
> iM3uwQTciklpQKjurM34Nys=
> =W6UX
> -----END PGP SIGNATURE-----
>
> #
> # old_revision [990392a71744fa8ec062ee769a883473775269ee]
> #
> # patch "classes/autotools.bbclass"
> #  from [dced52fcafd4e224bafcb35c4fb04253857c7c3b]
> #    to [113ae9d1554b6e93d9c7a7fda84d71da4712caf9]
> #
> # patch "packages/libtool/libtool-cross_1.5.10.bb"
> #  from [58b238af5bb9acdeca5b86c34b50c419fb49b55e]
> #    to [5134256c71b2d679838e87a55b084a99b1ac17d4]
> #
> # patch "packages/libtool/libtool-native_1.5.10.bb"
> #  from [e1d2b08387782afbf7c5c6787a92d9af864dfb2d]
> #    to [bc799a0464069f3531cbb0a017c4d8d2a1afd63e]
> #
> ============================================================
> --- classes/autotools.bbclass   dced52fcafd4e224bafcb35c4fb04253857c7c3b
> +++ classes/autotools.bbclass   113ae9d1554b6e93d9c7a7fda84d71da4712caf9
> @@ -15,6 +15,10 @@ def autotools_dep_prepend(d):
>
>         if not pn in ['libtool', 'libtool-native', 'libtool-cross']:
>                 deps += 'libtool-native '
> +               if not bb.data.inherits_class('native', d) \
> +                        and not bb.data.inherits_class('cross', d) \
> +                        and not bb.data.getVar('INHIBIT_DEFAULT_DEPS', d, 1):
> +                    deps += 'libtool-cross '
>
>         return deps + 'gnu-config-native '
>
> ============================================================
> --- packages/libtool/libtool-cross_1.5.10.bb    58b238af5bb9acdeca5b86c34b50c419fb49b55e
> +++ packages/libtool/libtool-cross_1.5.10.bb    5134256c71b2d679838e87a55b084a99b1ac17d4
> @@ -1,7 +1,7 @@ require libtool_${PV}.bb
>  SECTION = "devel"
>  require libtool_${PV}.bb
>
> -PR = "r4"
> +PR = "r5"
>  PACKAGES = ""
>  FILESDIR = "${@os.path.dirname(bb.data.getVar('FILE',d,1))}/libtool-${PV}"
>  SRC_URI_append = " file://libdir-la.patch;patch=1 \
> @@ -21,6 +21,13 @@ do_stage () {
>
>  do_stage () {
>          install -m 0755 ${HOST_SYS}-libtool ${bindir}/${HOST_SYS}-libtool
> +        install -m 0644 libltdl/ltdl.h ${STAGING_INCDIR}/
> +        install -d ${STAGING_DATADIR}/libtool ${STAGING_DATADIR}/aclocal
> +        install -c config.guess ${STAGING_DATADIR}/libtool/
> +        install -c config.sub ${STAGING_DATADIR}/libtool/
> +        install -c -m 0644 ltmain.sh ${STAGING_DATADIR}/libtool/
> +        install -c -m 0644 libtool.m4 ${STAGING_DATADIR}/aclocal/
> +        install -c -m 0644 ltdl.m4 ${STAGING_DATADIR}/aclocal/
>  }
>
>  do_install () {
> ============================================================
> --- packages/libtool/libtool-native_1.5.10.bb   e1d2b08387782afbf7c5c6787a92d9af864dfb2d
> +++ packages/libtool/libtool-native_1.5.10.bb   bc799a0464069f3531cbb0a017c4d8d2a1afd63e
> @@ -1,7 +1,7 @@ require libtool_${PV}.bb
>  SECTION = "devel"
>  require libtool_${PV}.bb
>
> -PR = "r4"
> +PR = "r5"
>  FILESDIR = "${@os.path.dirname(bb.data.getVar('FILE',d,1))}/libtool-${PV}"
>  SRC_URI_append = " file://libdir-la.patch;patch=1 \
>                     file://prefix.patch;patch=1 \
> @@ -10,8 +10,6 @@ S = "${WORKDIR}/libtool-${PV}"
>                     file://install-path-check.patch;patch=1"
>  S = "${WORKDIR}/libtool-${PV}"
>
> -STAGING_DATADIR_safe := "${STAGING_DATADIR}"
> -
>  inherit native
>
>  do_stage () {
> @@ -19,22 +17,12 @@ do_stage () {
>         install -m 0755 libtoolize ${STAGING_BINDIR}/libtoolize
>         oe_libinstall -a -so -C libltdl libltdl ${STAGING_LIBDIR}
>         install -m 0644 libltdl/ltdl.h ${STAGING_INCDIR}/
> -       for dir in ${STAGING_DATADIR} ${STAGING_DATADIR_safe}; do
> -               ltdldir="${dir}/libtool/libltdl"
> -               install -d $dir/libtool \
> -                          $ltdldir \
> -                          $dir/aclocal
> -               install -c config.guess $dir/libtool/config.guess
> -               install -c config.sub $dir/libtool/config.sub
> -               install -c -m 0644 ltmain.sh $dir/libtool/
> -               install -c -m 0644 libtool.m4 $dir/aclocal/
> -               install -c -m 0644 ltdl.m4 $dir/aclocal/
> -
> -               for src in README COPYING.LIB Makefile.am configure.ac \
> -                               config-h.in ltdl.c ltdl.h; do
> -                       install -m 0644 libltdl/${src} ${ltdldir}
> -               done
> -       done
> +       install -d ${STAGING_DATADIR}/libtool ${STAGING_DATADIR}/aclocal
> +       install -c config.guess ${STAGING_DATADIR}/libtool/
> +       install -c config.sub ${STAGING_DATADIR}/libtool/
> +       install -c -m 0644 ltmain.sh ${STAGING_DATADIR}/libtool/
> +       install -c -m 0644 libtool.m4 ${STAGING_DATADIR}/aclocal/
> +       install -c -m 0644 ltdl.m4 ${STAGING_DATADIR}/aclocal/
>  }
>
>  do_install () {
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>
>



From skoroneos at digital-opsis.com  Tue May 15 08:10:29 2007
From: skoroneos at digital-opsis.com (Stelios Koroneos)
Date: Tue, 15 May 2007 11:10:29 +0300
Subject: [oe] minimal-image.bb
In-Reply-To: <f277n0$i00$2@sea.gmane.org>
Message-ID: <HOECLKEKOHLAMMGDLLBHGEIBLAAA.skoroneos@digital-opsis.com>

> -----Original Message-----
> From: openembedded-devel-bounces at openembedded.org
> [mailto:openembedded-devel-bounces at openembedded.org]On Behalf Of
> Rolf Leggewie
> Sent: Sunday, May 13, 2007 5:35 PM
> To: openembedded-devel at openembedded.org
> Subject: Re: [oe] minimal-image.bb
>
>
> Stelios Koroneos wrote:
> > In my opinion if angstrom-minimal-image is not distro specific should be
> > renamed to minimal-image
>
> I agree with Stelios that the belief that angstrom-minimal-image is a
> distro-specific image is a reasonable assumption.  If that is not the
> case, I am in favor renaming.


There is a bigger issue here than the name of package and that the reason i
brought this matter up.
Angstrom without any dough is the biggest distro supported by OE, but its
not the only one.
No one should also dough that Koen has done a lot of work (and is still
doing) and credits should go to him for a lot of the things in OE, including
the angstrom-minimal-image.bb, but i believe the real issue goes beyond the
developer/distro thing.

Actions like that, give the wrong signals to the people who are looking at
OE for incorporation/support of their products(and believe me there are
*alot* that do that as we speak)
If a distro maintainer (or any OE developer in that fact) comes with a way
of handling things better for his distro that could be used as a generic
framework for others it should be done so and not discouraged.

I am firm believer in community work and that things that could benefit the
OE community should be handled as such and not as distro-specific.






From no2spam at nospam.arcornews.de  Tue May 15 09:59:15 2007
From: no2spam at nospam.arcornews.de (Rolf Leggewie)
Date: Tue, 15 May 2007 11:59:15 +0200
Subject: [oe] minimal-image.bb
In-Reply-To: <HOECLKEKOHLAMMGDLLBHGEIBLAAA.skoroneos@digital-opsis.com>
References: <f277n0$i00$2@sea.gmane.org>
	<HOECLKEKOHLAMMGDLLBHGEIBLAAA.skoroneos@digital-opsis.com>
Message-ID: <f2c09j$8rd$1@sea.gmane.org>

Stelios Koroneos wrote:
> I am firm believer in community work and that things that could benefit the
> OE community should be handled as such and not as distro-specific.

I always thought that Angstrom was all about tearing walls down instead 
of building them up.

/me is baffled




From robin.farine at terminus.org  Tue May 15 11:22:39 2007
From: robin.farine at terminus.org (Robin Farine)
Date: Tue, 15 May 2007 13:22:39 +0200
Subject: [oe] RFC: machine customized ixp4xx NPE firmware
Message-ID: <200705151322.39110.robin.farine@terminus.org>

Hello everyone,

The platform I am working on is using NPE-B and NPE-C as Ethernet
interfaces. The ixp4xx-npe package from the OE snapshot I am 
currently
using builds firmware for NPE-B only and the firmware type is 
hard-coded
in "IxNpeMicrocode.h".

The patch below proposes a means of letting the machine 
configuration file
decide which NPE firmware to build.

Another but somewhat related point is the COMPATIBLE_MACHINE 
variable. If
my machine's name does not start with nslug or ixp4xx, I am forced 
to
change many package recipes (I suspect it is a FAQ but I do not seem 
to
able to access the mailing-list archive at the moment), perhaps a
COMPATIBLE_ARCH variable would be help here ?

Thanks,

Robin

diff --git 
a/packages/ixp4xx/ixp4xx-npe-native-2.3.2/IxNpeMicrocode.h 
b/packages/ixp4xx/ixp4xx-npe-native-2.3.2/IxNpeMicrocode.h
--- a/packages/ixp4xx/ixp4xx-npe-native-2.3.2/IxNpeMicrocode.h
+++ b/packages/ixp4xx/ixp4xx-npe-native-2.3.2/IxNpeMicrocode.h
@@ -42,7 +42,7 @@
 // #define IX_NPEDL_NPEIMAGE_NPEB_DMA
 // #define 
IX_NPEDL_NPEIMAGE_NPEB_ETH_SPAN_FIREWALL_VLAN_QOS_HDR_CONV
 // #define 
IX_NPEDL_NPEIMAGE_NPEB_ETH_LEARN_FILTER_SPAN_FIREWALL_VLAN_QOS
-#define IX_NPEDL_NPEIMAGE_NPEB_ETH_LEARN_FILTER_SPAN_FIREWALL
+// #define IX_NPEDL_NPEIMAGE_NPEB_ETH_LEARN_FILTER_SPAN_FIREWALL
 
 
 // #define 
IX_NPEDL_NPEIMAGE_NPEC_ETH_SPAN_MASK_FIREWALL_VLAN_QOS_HDR_CONV_EXTMIB
@@ -51,7 +51,7 @@
 // #define IX_NPEDL_NPEIMAGE_NPEC_DMA
 // #define IX_NPEDL_NPEIMAGE_NPEC_CRYPTO_AES_ETH_LEARN_FILTER_SPAN
 // #define 
IX_NPEDL_NPEIMAGE_NPEC_CRYPTO_AES_ETH_LEARN_FILTER_FIREWALL
-#define IX_NPEDL_NPEIMAGE_NPEC_CRYPTO_AES_CCM_ETH
+// #define IX_NPEDL_NPEIMAGE_NPEC_CRYPTO_AES_CCM_ETH
 // #define 
IX_NPEDL_NPEIMAGE_NPEC_CRYPTO_ETH_LEARN_FILTER_SPAN_FIREWALL
 // #define 
IX_NPEDL_NPEIMAGE_NPEC_ETH_SPAN_FIREWALL_VLAN_QOS_HDR_CONV
 // #define 
IX_NPEDL_NPEIMAGE_NPEC_ETH_LEARN_FILTER_SPAN_FIREWALL_VLAN_QOS
diff --git a/packages/ixp4xx/ixp4xx-npe-native_2.3.2.bb 
b/packages/ixp4xx/ixp4xx-npe-native_2.3.2.bb
--- a/packages/ixp4xx/ixp4xx-npe-native_2.3.2.bb
+++ b/packages/ixp4xx/ixp4xx-npe-native_2.3.2.bb
@@ -7,9 +7,14 @@ inherit native
 inherit native
 S = "${WORKDIR}/ixp400_xscale_sw/src/npeDl"
 
+# A space-separated list of CPP defines that select the firmware 
images
+# to build for the target machine.
+IXP4XX_NPE_FIRWMARE_DEFINES ?= "\
+-DIX_NPEDL_NPEIMAGE_NPEB_ETH_LEARN_FILTER_SPAN_FIREWALL"
+
 do_compile() {
 	mv ${WORKDIR}/IxNpeMicrocode.h ${S}/
-	gcc -Wall IxNpeMicrocode.c -o IxNpeMicrocode
+	gcc -Wall ${IXP4XX_NPE_FIRWMARE_DEFINES} IxNpeMicrocode.c -o 
IxNpeMicrocode
 }
 
 do_stage() {
diff --git a/packages/ixp4xx/ixp4xx-npe_2.3.2.bb 
b/packages/ixp4xx/ixp4xx-npe_2.3.2.bb
--- a/packages/ixp4xx/ixp4xx-npe_2.3.2.bb
+++ b/packages/ixp4xx/ixp4xx-npe_2.3.2.bb
@@ -13,7 +13,7 @@ S = "${WORKDIR}/ixp400_xscale_sw/src/npe
 
 COMPATIBLE_MACHINE = "(nslu2|ixp4xx)"
 
-FILES_${PN} = "${base_libdir}/firmware/NPE-B"
+FILES_${PN} = "${base_libdir}/firmware/NPE-*"
 
 do_compile() {
 	${STAGING_BINDIR_NATIVE}/IxNpeMicrocode-${PV} -be
@@ -21,13 +21,20 @@ do_compile() {
 
 do_install() {
 	install -d ${D}/${base_libdir}/firmware/
-	rm ${S}/NPE-B
-	mv ${S}/NPE-B.* ${S}/NPE-B
-	install ${S}/NPE-B ${D}/${base_libdir}/firmware/
+	for npe in A B C; do
+		rm ${S}/NPE-${npe} 2>/dev/null || true
+		mv ${S}/NPE-${npe}.* ${S}/NPE-${npe} 2>/dev/null || true
+		if test -f ${S}/NPE-${npe}; then
+			install -m 644 ${S}/NPE-${npe} ${D}/${base_libdir}/firmware/
+		fi
+	done
 }
 
 do_populate_staging() {
 	install -d ${STAGING_FIRMWARE_DIR}
-	install ${S}/NPE-B ${STAGING_FIRMWARE_DIR}/
+	for npe in A B C; do
+		if test -f ${S}/NPE-${npe}; then
+			install -m 644 ${S}/NPE-${npe} ${STAGING_FIRMWARE_DIR}/
+		fi
+	done
 }
-




From philip at balister.org  Tue May 15 11:47:07 2007
From: philip at balister.org (Philip Balister)
Date: Tue, 15 May 2007 07:47:07 -0400
Subject: [oe] Fixing up libtool-native and libtool-cross
In-Reply-To: <4648EB51.4040303@dominion.kabel.utwente.nl>
References: <4648EB51.4040303@dominion.kabel.utwente.nl>
Message-ID: <46499DBB.9080001@balister.org>

Can we apply these to the 1.5.22 libtool bb files also? I ahve added 
these with DEFAULT_PREFERENCE = "-1" since they have trouble building 
some packages, apparently due to looking in build system directories for 
libraries

Philip

Koen Kooi wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi,
> 
> Richard has fixed up libtool in Poky a bit and I want to merge his work into OE. Since
> it's 1 AM now, and libtool is a pretty 'core' part, I'm posting the patch for review
> before committing it tomorrow night.
> 
> regards,
> 
> Koen
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (Darwin)
> 
> iD8DBQFGSOtRMkyGM64RGpERAuiCAJ0Yqz+t4X/zNCjTbZIBU7yjaDt8twCgkgVq
> iM3uwQTciklpQKjurM34Nys=
> =W6UX
> -----END PGP SIGNATURE-----
> 
> 
> ------------------------------------------------------------------------
> 
> #
> # old_revision [990392a71744fa8ec062ee769a883473775269ee]
> #
> # patch "classes/autotools.bbclass"
> #  from [dced52fcafd4e224bafcb35c4fb04253857c7c3b]
> #    to [113ae9d1554b6e93d9c7a7fda84d71da4712caf9]
> # 
> # patch "packages/libtool/libtool-cross_1.5.10.bb"
> #  from [58b238af5bb9acdeca5b86c34b50c419fb49b55e]
> #    to [5134256c71b2d679838e87a55b084a99b1ac17d4]
> # 
> # patch "packages/libtool/libtool-native_1.5.10.bb"
> #  from [e1d2b08387782afbf7c5c6787a92d9af864dfb2d]
> #    to [bc799a0464069f3531cbb0a017c4d8d2a1afd63e]
> #
> ============================================================
> --- classes/autotools.bbclass	dced52fcafd4e224bafcb35c4fb04253857c7c3b
> +++ classes/autotools.bbclass	113ae9d1554b6e93d9c7a7fda84d71da4712caf9
> @@ -15,6 +15,10 @@ def autotools_dep_prepend(d):
>  
>  	if not pn in ['libtool', 'libtool-native', 'libtool-cross']:
>  		deps += 'libtool-native '
> +		if not bb.data.inherits_class('native', d) \
> +                        and not bb.data.inherits_class('cross', d) \
> +                        and not bb.data.getVar('INHIBIT_DEFAULT_DEPS', d, 1):
> +                    deps += 'libtool-cross '
>  
>  	return deps + 'gnu-config-native '
>  
> ============================================================
> --- packages/libtool/libtool-cross_1.5.10.bb	58b238af5bb9acdeca5b86c34b50c419fb49b55e
> +++ packages/libtool/libtool-cross_1.5.10.bb	5134256c71b2d679838e87a55b084a99b1ac17d4
> @@ -1,7 +1,7 @@ require libtool_${PV}.bb
>  SECTION = "devel"
>  require libtool_${PV}.bb
>  
> -PR = "r4"
> +PR = "r5"
>  PACKAGES = ""
>  FILESDIR = "${@os.path.dirname(bb.data.getVar('FILE',d,1))}/libtool-${PV}"
>  SRC_URI_append = " file://libdir-la.patch;patch=1 \
> @@ -21,6 +21,13 @@ do_stage () {
>  
>  do_stage () {
>          install -m 0755 ${HOST_SYS}-libtool ${bindir}/${HOST_SYS}-libtool
> +        install -m 0644 libltdl/ltdl.h ${STAGING_INCDIR}/
> +        install -d ${STAGING_DATADIR}/libtool ${STAGING_DATADIR}/aclocal
> +        install -c config.guess ${STAGING_DATADIR}/libtool/
> +        install -c config.sub ${STAGING_DATADIR}/libtool/
> +        install -c -m 0644 ltmain.sh ${STAGING_DATADIR}/libtool/
> +        install -c -m 0644 libtool.m4 ${STAGING_DATADIR}/aclocal/
> +        install -c -m 0644 ltdl.m4 ${STAGING_DATADIR}/aclocal/
>  }
>  
>  do_install () {
> ============================================================
> --- packages/libtool/libtool-native_1.5.10.bb	e1d2b08387782afbf7c5c6787a92d9af864dfb2d
> +++ packages/libtool/libtool-native_1.5.10.bb	bc799a0464069f3531cbb0a017c4d8d2a1afd63e
> @@ -1,7 +1,7 @@ require libtool_${PV}.bb
>  SECTION = "devel"
>  require libtool_${PV}.bb
>  
> -PR = "r4"
> +PR = "r5"
>  FILESDIR = "${@os.path.dirname(bb.data.getVar('FILE',d,1))}/libtool-${PV}"
>  SRC_URI_append = " file://libdir-la.patch;patch=1 \
>                     file://prefix.patch;patch=1 \
> @@ -10,8 +10,6 @@ S = "${WORKDIR}/libtool-${PV}"
>                     file://install-path-check.patch;patch=1"
>  S = "${WORKDIR}/libtool-${PV}"
>  
> -STAGING_DATADIR_safe := "${STAGING_DATADIR}"
> -
>  inherit native
>  
>  do_stage () {
> @@ -19,22 +17,12 @@ do_stage () {
>  	install -m 0755 libtoolize ${STAGING_BINDIR}/libtoolize
>  	oe_libinstall -a -so -C libltdl libltdl ${STAGING_LIBDIR}
>  	install -m 0644 libltdl/ltdl.h ${STAGING_INCDIR}/
> -	for dir in ${STAGING_DATADIR} ${STAGING_DATADIR_safe}; do
> -		ltdldir="${dir}/libtool/libltdl"
> -		install -d $dir/libtool \
> -			   $ltdldir \
> -			   $dir/aclocal
> -		install -c config.guess $dir/libtool/config.guess
> -		install -c config.sub $dir/libtool/config.sub
> -		install -c -m 0644 ltmain.sh $dir/libtool/
> -		install -c -m 0644 libtool.m4 $dir/aclocal/
> -		install -c -m 0644 ltdl.m4 $dir/aclocal/
> -
> -		for src in README COPYING.LIB Makefile.am configure.ac \
> -				config-h.in ltdl.c ltdl.h; do
> -			install -m 0644 libltdl/${src} ${ltdldir}
> -		done
> -	done
> +	install -d ${STAGING_DATADIR}/libtool ${STAGING_DATADIR}/aclocal
> +	install -c config.guess ${STAGING_DATADIR}/libtool/
> +	install -c config.sub ${STAGING_DATADIR}/libtool/
> +	install -c -m 0644 ltmain.sh ${STAGING_DATADIR}/libtool/
> +	install -c -m 0644 libtool.m4 ${STAGING_DATADIR}/aclocal/
> +	install -c -m 0644 ltdl.m4 ${STAGING_DATADIR}/aclocal/
>  }
>  
>  do_install () {
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3303 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://layers.openembedded.org/pipermail/openembedded-devel/attachments/20070515/59453557/attachment.bin>

From koen at dominion.kabel.utwente.nl  Tue May 15 12:53:17 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Tue, 15 May 2007 14:53:17 +0200
Subject: [oe] Fixing up libtool-native and libtool-cross
In-Reply-To: <46499DBB.9080001@balister.org>
References: <4648EB51.4040303@dominion.kabel.utwente.nl>
	<46499DBB.9080001@balister.org>
Message-ID: <4649AD3D.7070905@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Philip Balister schreef:
> Can we apply these to the 1.5.22 libtool bb files also? I ahve added
> these with DEFAULT_PREFERENCE = "-1" since they have trouble building
> some packages, apparently due to looking in build system directories for
> libraries

I pushed the updates to 1.5.10, could you fix 1.5.22?

TIA,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGSa09MkyGM64RGpERAiN+AJ0ZJTsW7GRLJi24EQy7QOpG1j0nGQCcDGq5
MGVDY5euyKwRk0sNTyg1Lag=
=3i/D
-----END PGP SIGNATURE-----



From leon.woestenberg at gmail.com  Tue May 15 18:38:37 2007
From: leon.woestenberg at gmail.com (Leon Woestenberg)
Date: Tue, 15 May 2007 20:38:37 +0200
Subject: [oe] RFC: machine customized ixp4xx NPE firmware
In-Reply-To: <200705151322.39110.robin.farine@terminus.org>
References: <200705151322.39110.robin.farine@terminus.org>
Message-ID: <c384c5ea0705151138n4087e20cx1f2971a69573091d@mail.gmail.com>

Hello Robin,

On 5/15/07, Robin Farine <robin.farine at terminus.org> wrote:
> +IXP4XX_NPE_FIRWMARE_DEFINES ?= "\
> +-DIX_NPEDL_NPEIMAGE_NPEB_ETH_LEARN_FILTER_SPAN_FIREWALL"
> +
>  do_compile() {
>         mv ${WORKDIR}/IxNpeMicrocode.h ${S}/
> -       gcc -Wall IxNpeMicrocode.c -o IxNpeMicrocode
> +       gcc -Wall ${IXP4XX_NPE_FIRWMARE_DEFINES} IxNpeMicrocode.c -o
>
Please change IXP4XX_NPE_FIRWMARE_DEFINES into IXP4X
IX_NPE_FIRMWARE_DEFINES.

The idea looks ok.

Regards,

Leon.



From robin.farine at terminus.org  Tue May 15 20:17:27 2007
From: robin.farine at terminus.org (Robin Farine)
Date: Tue, 15 May 2007 22:17:27 +0200
Subject: [oe] RFC: machine customized ixp4xx NPE firmware
In-Reply-To: <c384c5ea0705151138n4087e20cx1f2971a69573091d@mail.gmail.com>
References: <200705151322.39110.robin.farine@terminus.org>
	<c384c5ea0705151138n4087e20cx1f2971a69573091d@mail.gmail.com>
Message-ID: <200705152217.27815.rfarine@tilia.local>

On Tuesday May 15 2007 20:38, Leon Woestenberg wrote:
> On 5/15/07, Robin Farine <robin.farine at terminus.org> wrote:
> > +IXP4XX_NPE_FIRWMARE_DEFINES ?= "\
> > +-DIX_NPEDL_NPEIMAGE_NPEB_ETH_LEARN_FILTER_SPAN_FIREWALL"
> > +
> >  do_compile() {
> >         mv ${WORKDIR}/IxNpeMicrocode.h ${S}/
> > -       gcc -Wall IxNpeMicrocode.c -o IxNpeMicrocode
> > +       gcc -Wall ${IXP4XX_NPE_FIRWMARE_DEFINES}
> > IxNpeMicrocode.c -o
>
> Please change IXP4XX_NPE_FIRWMARE_DEFINES into IXP4X
> IX_NPE_FIRMWARE_DEFINES.

Ah, you mean s/FIRWMARE/FIRMWARE/, yes, makes sense :-). I'll fix 
this and submit the patch to the bug tracker.

> The idea looks ok.

Thanks for reviewing it.

Regards,

Robin



From rod at whitby.id.au  Wed May 16 01:24:07 2007
From: rod at whitby.id.au (Rod Whitby)
Date: Wed, 16 May 2007 10:54:07 +0930
Subject: [oe] RFC: machine customized ixp4xx NPE firmware
In-Reply-To: <200705151322.39110.robin.farine@terminus.org>
References: <200705151322.39110.robin.farine@terminus.org>
Message-ID: <464A5D37.4030401@whitby.id.au>

Robin Farine wrote:
> The platform I am working on is using NPE-B and NPE-C as Ethernet
> interfaces. The ixp4xx-npe package from the OE snapshot I am 
> currently
> using builds firmware for NPE-B only and the firmware type is 
> hard-coded
> in "IxNpeMicrocode.h".
> 
> The patch below proposes a means of letting the machine 
> configuration file
> decide which NPE firmware to build.

Thanks.  We'll be very happy to apply that patch.  I'll take a close
look at it tonight.

> Another but somewhat related point is the COMPATIBLE_MACHINE 
> variable. If
> my machine's name does not start with nslug or ixp4xx, I am forced 
> to
> change many package recipes (I suspect it is a FAQ but I do not seem 
> to
> able to access the mailing-list archive at the moment), perhaps a
> COMPATIBLE_ARCH variable would be help here ?

Which machine/arch are you using?  We can easily extend that
compatibility to include any other machines/archs that will use it.

-- Rod



From lenehan at twibble.org  Wed May 16 03:13:29 2007
From: lenehan at twibble.org (Jamie Lenehan)
Date: Wed, 16 May 2007 13:13:29 +1000
Subject: [oe] uclibc 0.9.29 recipe
In-Reply-To: <46461D72.4020206@dominion.kabel.utwente.nl>
References: <464613B3.8090003@dominion.kabel.utwente.nl>
	<46461B73.8070900@trolltech.com>
	<46461D72.4020206@dominion.kabel.utwente.nl>
Message-ID: <20070516031329.GA5205@twibble.org>

On Sat, May 12, 2007 at 10:02:58PM +0200, Koen Kooi wrote:
[...]
> I'll add it once I solved the linux-libc-headers problems. Machine and distro maintainers
> need to provide their parts of the uclibc configs to make it usefull, though.

Do we really need different distro based settings? It's always been a
bit annoying that some things will build with uclibc for one build
but not another due to differing uclibc settings - things are a lot
easier if there's only a single configuration.

For now I'd like to see a

  mtn -e mv uclibc-0.9.29/angstrom/uClibc.distro uclibc-0.9.29/uClibc.distro

and then only add distro based configuration if it turns out to be
really needed by some distro. This'll also gives us a default
configuration for people using other distros.

-- 
 Jamie Lenehan <lenehan at twibble.org>



From xjqian at gmail.com  Wed May 16 03:27:58 2007
From: xjqian at gmail.com (Junqian Gordon Xu)
Date: Tue, 15 May 2007 22:27:58 -0500
Subject: [oe] RFD: Bugzilla in general & bug triaging
In-Reply-To: <f29dkh$o3v$1@sea.gmane.org>
References: <1179059149.5404.3.camel@cimmeria.hyboria>	<f277j3$i00$1@sea.gmane.org>
	<f29dkh$o3v$1@sea.gmane.org>
Message-ID: <464A7A3E.9050905@gmail.com>

Rolf Leggewie wrote:
> I have asked and been granted greater powers on bugzilla.  There are 
> features which we don't use yet but which could aid in establishing a 
> sane workflow while rendering unnecessary the current clutches and 
> ad-hoc fixes.
>
> Bugzilla will be upgraded soon and no structural changes will be made 
> until that is completed.  But that leaves us some good time to think 
> about how this should be enhanced.
>   
two quibbles about the recent change in bugtracker
1) aligning left wastes lot of space on the right of the screen. I think 
the old "centered" scheme looks better.
2) "the Words field cannot be empty. You have to enter at lease on word 
in your search criteria". This is inconvenient for me to just browser 
the bugs.

> Things I'd like to see
> * confirmation flags
> * better documentation of workflow status (need to define it first)
> * assigning bugs (or if you prefer "Hey, please take a look")
> * link to some bug searches like the ones I send about 5 minutes ago
>    on the entry page
> * entry page clean-up (why two search fields?)
>   

> * removal of dead stuff (ZaurusKernel, Familiar)
>   
better hide them (sort of a archive in case some people want to dig into 
those) than remove
> Please add to the list.  The most important point is the second.  That 
> is what we should discuss.
>   
I agree on the necessity of the second point. Please have a list of 
best-practice/workflow rules (whatever they are) and hide the additional 
irrelevant features. A clean and uncluttered interface is also desirable.

Gordon



From lenehan at twibble.org  Wed May 16 05:16:01 2007
From: lenehan at twibble.org (Jamie Lenehan)
Date: Wed, 16 May 2007 15:16:01 +1000
Subject: [oe] uclibc 0.9.29 & SYS_SIGLIST
In-Reply-To: <464613B3.8090003@dominion.kabel.utwente.nl>
References: <464613B3.8090003@dominion.kabel.utwente.nl>
Message-ID: <20070516051600.GA5179@twibble.org>

Currently SYS_SIGLIST is disabled in uclibc but the site files all
say it's present. For the old uclibc version some of the
configurations enabled SYS_SIGLIST support and some didn't. We don't
really need it and the uclibc help says it's going to go away one day
so if no one objects I'll add the following site entries:

common-glibc

 bash_cv_under_sys_siglist=${bash_cv_under_sys_siglist=yes}
 bash_cv_sys_siglist=${bash_cv_sys_siglist=yes}
 ac_cv_have_decl_sys_siglist=${ac_cv_have_decl_sys_siglist=yes}

common-uclibc

 bash_cv_under_sys_siglist=${bash_cv_under_sys_siglist=no}
 bash_cv_sys_siglist=${bash_cv_sys_siglist=no}
 ac_cv_have_decl_sys_siglist=${ac_cv_have_decl_sys_siglist=no}

And remove the above entries from all the other site files.

This siglist things needs to be sorted out to build apr at least
(which is needed to build subversion).

-- 
 Jamie Lenehan <lenehan at twibble.org>



From leon.woestenberg at gmail.com  Wed May 16 07:26:22 2007
From: leon.woestenberg at gmail.com (Leon Woestenberg)
Date: Wed, 16 May 2007 09:26:22 +0200
Subject: [oe] uclibc 0.9.29 recipe
In-Reply-To: <20070516031329.GA5205@twibble.org>
References: <464613B3.8090003@dominion.kabel.utwente.nl>
	<46461B73.8070900@trolltech.com>
	<46461D72.4020206@dominion.kabel.utwente.nl>
	<20070516031329.GA5205@twibble.org>
Message-ID: <c384c5ea0705160026x5965bad9w9d2d0587ae574853@mail.gmail.com>

Hello Jamie,

On 5/16/07, Jamie Lenehan <lenehan at twibble.org> wrote:
> On Sat, May 12, 2007 at 10:02:58PM +0200, Koen Kooi wrote:

> For now I'd like to see a
>
>   mtn -e mv uclibc-0.9.29/angstrom/uClibc.distro uclibc-0.9.29/uClibc.distro
>
> and then only add distro based configuration if it turns out to be
> really needed by some distro. This'll also gives us a default
>
And that generic distro configuration would probably be a full
configuration (i.e. most options enabled) so that it would work for
most packages depending on C library functionality (or glibc
compatibility).

Distro's can optionally tune down the .distro by either:
- providing their own .distro
- mangling the resulting .config

Regards,
-- 
Leon



From koen at dominion.kabel.utwente.nl  Wed May 16 07:41:28 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Wed, 16 May 2007 09:41:28 +0200
Subject: [oe] uclibc 0.9.29 recipe
In-Reply-To: <20070516031329.GA5205@twibble.org>
References: <464613B3.8090003@dominion.kabel.utwente.nl>	<46461B73.8070900@trolltech.com>	<46461D72.4020206@dominion.kabel.utwente.nl>
	<20070516031329.GA5205@twibble.org>
Message-ID: <464AB5A8.8070500@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jamie Lenehan schreef:
> On Sat, May 12, 2007 at 10:02:58PM +0200, Koen Kooi wrote:
> [...]
>> I'll add it once I solved the linux-libc-headers problems. Machine and distro maintainers
>> need to provide their parts of the uclibc configs to make it usefull, though.
> 
> Do we really need different distro based settings? 

I tried to adhere to the existing uclibc infrastructure when adding 0.9.29, but maybe it's
time to rethink and overhaul it.

> It's always been a
> bit annoying that some things will build with uclibc for one build
> but not another due to differing uclibc settings - things are a lot
> easier if there's only a single configuration.
> 
> For now I'd like to see a
> 
>   mtn -e mv uclibc-0.9.29/angstrom/uClibc.distro uclibc-0.9.29/uClibc.distro

Fine by me, could you do that?

> and then only add distro based configuration if it turns out to be
> really needed by some distro. This'll also gives us a default
> configuration for people using other distros.

And gives us a better way to keep our site-files in sync.

regards,

Koen

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGSrWoMkyGM64RGpERAnrXAJwJFcLlBdZpiwEsf1Uw8DBL9agFtgCaA0ny
EleWYKtPe+qa1D9PIgGiJps=
=ByLX
-----END PGP SIGNATURE-----



From robin.farine at terminus.org  Wed May 16 08:56:46 2007
From: robin.farine at terminus.org (Robin Farine)
Date: Wed, 16 May 2007 10:56:46 +0200
Subject: [oe] RFC: machine customized ixp4xx NPE firmware
In-Reply-To: <464A5D37.4030401@whitby.id.au>
References: <200705151322.39110.robin.farine@terminus.org>
	<464A5D37.4030401@whitby.id.au>
Message-ID: <200705161056.46551.robin.farine@terminus.org>

On Wed May 16 2007 03:24, Rod Whitby wrote:
> Robin Farine wrote:

> > The patch below proposes a means of letting the machine
> > configuration file
> > decide which NPE firmware to build.
>
> Thanks.  We'll be very happy to apply that patch.  I'll take a
> close look at it tonight.

I forgot to disable line wrapping when I reposted it to the correct 
mailing-list... You may prefer to have a look at the cleaner 
version in bugzilla.

> Which machine/arch are you using?  We can easily extend that
> compatibility to include any other machines/archs that will use
> it.

Its a custom ixp425 big-endian board of which 2 functional exemplars 
currently exist :-). Not a problem, I just wondered whether 
something like COMPATIBLE_ARCH exists.

Robin



From rpurdie at rpsys.net  Wed May 16 10:44:45 2007
From: rpurdie at rpsys.net (Richard Purdie)
Date: Wed, 16 May 2007 11:44:45 +0100
Subject: [oe] RFC: machine customized ixp4xx NPE firmware
In-Reply-To: <464A5D37.4030401@whitby.id.au>
References: <200705151322.39110.robin.farine@terminus.org>
	<464A5D37.4030401@whitby.id.au>
Message-ID: <1179312285.5854.2.camel@localhost.localdomain>

On Wed, 2007-05-16 at 10:54 +0930, Rod Whitby wrote:
> Robin Farine wrote:
> > Another but somewhat related point is the COMPATIBLE_MACHINE 
> > variable. If
> > my machine's name does not start with nslug or ixp4xx, I am forced 
> > to
> > change many package recipes (I suspect it is a FAQ but I do not seem 
> > to
> > able to access the mailing-list archive at the moment), perhaps a
> > COMPATIBLE_ARCH variable would be help here ?
> 
> Which machine/arch are you using?  We can easily extend that
> compatibility to include any other machines/archs that will use it.

A neat way to handle this might be to define:

IXPMACHINES = "nslu2|ixp4xx|whatever"

and then the ixp specific .bb's check IXPMACHINES rather than a specific
list. The list would then be maintained in one place and is easily
updated if anyone adds a new ixp like machine.

I've not looked at the specifics, its just a random idea I had...

Cheers,

Richard







From golly at stellarwerx.com  Wed May 16 14:32:20 2007
From: golly at stellarwerx.com (Mark Gollahon)
Date: Wed, 16 May 2007 10:32:20 -0400 (EDT)
Subject: [oe] RFC: machine customized ixp4xx NPE firmware
Message-ID: <1179325940.4167@gatekeeper.stellarwerx.com>

Richard Purdie wrote ..
> 
> A neat way to handle this might be to define:
> 
> IXPMACHINES = "nslu2|ixp4xx|whatever"
> 
> and then the ixp specific .bb's check IXPMACHINES rather than a specific
> list. The list would then be maintained in one place and is easily
> updated if anyone adds a new ixp like machine.
> 
> I've not looked at the specifics, its just a random idea I had...
> 
> Cheers,
> 
> Richard

I want to second this approach as I tried awhile back to build OE for an IXP4XX-based machine that came into my possession and, during that time, ended up patching several IXP-specific .bb's to add my new machine.  My work would have been much easier had IXPMACHINES existed.

(NOTE: I did get it almost completely working, the only problem ended up being the networking ports didn't work, which, for a firewall machine, meant the device was useless.  There is an IC175 switch chip sitting between the IXP's two network ports and the physical ports and I couldn't figure out how to hack the IXP net driver to get the IC175 to pass eth frames.)

Regards,
-Mark Gollahon

From koen at dominion.kabel.utwente.nl  Thu May 17 08:01:53 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Thu, 17 May 2007 10:01:53 +0200
Subject: [oe] Questions about SDK generation
Message-ID: <464C0BF1.60300@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

During the build build of gcc-cross-sdk I noticed this:

NOTE: Running task 280 of 284 (ID: 5,
/home/koen/OE/monotone/org.openembedded.dev/packages/gcc/gcc-cross-sdk_4.1.2.bb, do_package)
NOTE: package gcc-cross-sdk-4.1.2: started
NOTE: package gcc-cross-sdk-4.1.2-r3: task do_package: started
NOTE: the following files were installed but not shipped in any package:
NOTE:   /usr/local/arm/oe/libexec/gcc/arm-angstrom-linux-gnueabi/4.1.2/install-tools/fixinc.sh
NOTE:   /usr/local/arm/oe/libexec/gcc/arm-angstrom-linux-gnueabi/4.1.2/install-tools/fixincl
NOTE:   /usr/local/arm/oe/libexec/gcc/arm-angstrom-linux-gnueabi/4.1.2/install-tools/mkheaders
NOTE:   /usr/local/arm/oe/lib/libiberty.a
NOTE:   /usr/local/arm/oe/lib/gcc/arm-angstrom-linux-gnueabi/4.1.2/install-tools/gsyslimits.h
NOTE:   /usr/local/arm/oe/lib/gcc/arm-angstrom-linux-gnueabi/4.1.2/install-tools/macro_list
NOTE:
/usr/local/arm/oe/lib/gcc/arm-angstrom-linux-gnueabi/4.1.2/install-tools/mkheaders.conf
NOTE:
/usr/local/arm/oe/lib/gcc/arm-angstrom-linux-gnueabi/4.1.2/install-tools/include/README
NOTE:
/usr/local/arm/oe/lib/gcc/arm-angstrom-linux-gnueabi/4.1.2/install-tools/include/float.h
NOTE:
/usr/local/arm/oe/lib/gcc/arm-angstrom-linux-gnueabi/4.1.2/install-tools/include/iso646.h
NOTE:
/usr/local/arm/oe/lib/gcc/arm-angstrom-linux-gnueabi/4.1.2/install-tools/include/stdarg.h
NOTE:
/usr/local/arm/oe/lib/gcc/arm-angstrom-linux-gnueabi/4.1.2/install-tools/include/stdbool.h
NOTE:
/usr/local/arm/oe/lib/gcc/arm-angstrom-linux-gnueabi/4.1.2/install-tools/include/stddef.h
NOTE:
/usr/local/arm/oe/lib/gcc/arm-angstrom-linux-gnueabi/4.1.2/install-tools/include/varargs.h
NOTE:
/usr/local/arm/oe/lib/gcc/arm-angstrom-linux-gnueabi/4.1.2/install-tools/include/mmintrin.h
NOTE:
/usr/local/arm/oe/lib/gcc/arm-angstrom-linux-gnueabi/4.1.2/install-tools/include/limits.h
NOTE:
/usr/local/arm/oe/lib/gcc/arm-angstrom-linux-gnueabi/4.1.2/install-tools/include/unwind.h
NOTE:   /usr/local/arm/oe/bin/arm-angstrom-linux-gnueabi-c++
NOTE:   /usr/local/arm/oe/bin/arm-angstrom-linux-gnueabi-gcc-4.1.2
NOTE:   /usr/local/arm/oe/include/mf-runtime.h
NOTE:   /usr/local/arm/oe/arm-angstrom-linux-gnueabi/lib/libsupc++.la
NOTE:   /usr/local/arm/oe/arm-angstrom-linux-gnueabi/lib/libsupc++.a
NOTE:   /usr/local/arm/oe/arm-angstrom-linux-gnueabi/lib/libstdc++_pic.a
NOTE:   /usr/local/arm/oe/arm-angstrom-linux-gnueabi/lib/libstdc++.la
NOTE:   /usr/local/arm/oe/arm-angstrom-linux-gnueabi/lib/libstdc++.a
NOTE:   /usr/local/arm/oe/arm-angstrom-linux-gnueabi/lib/libmudflap.so.0.0.0
NOTE:   /usr/local/arm/oe/arm-angstrom-linux-gnueabi/lib/libmudflap.la
NOTE:   /usr/local/arm/oe/arm-angstrom-linux-gnueabi/lib/libmudflap.a
NOTE:   /usr/local/arm/oe/arm-angstrom-linux-gnueabi/lib/libmudflapth.so.0.0.0
NOTE:   /usr/local/arm/oe/arm-angstrom-linux-gnueabi/lib/libmudflapth.la
NOTE:   /usr/local/arm/oe/arm-angstrom-linux-gnueabi/lib/libmudflapth.a
NOTE:   /usr/local/arm/oe/arm-angstrom-linux-gnueabi/lib/libiberty.a
NOTE:   /usr/local/arm/oe/arm-angstrom-linux-gnueabi/lib/libgcc_s.so
NOTE:   /usr/local/arm/oe/arm-angstrom-linux-gnueabi/lib/libstdc++.so
NOTE:   /usr/local/arm/oe/arm-angstrom-linux-gnueabi/lib/libmudflap.so.0
NOTE:   /usr/local/arm/oe/arm-angstrom-linux-gnueabi/lib/libmudflap.so
NOTE:   /usr/local/arm/oe/arm-angstrom-linux-gnueabi/lib/libmudflapth.so.0
NOTE:   /usr/local/arm/oe/arm-angstrom-linux-gnueabi/lib/libmudflapth.so

Is that intended?

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGTAvxMkyGM64RGpERAmi6AJ4vD8WTFN8JxW3K+3F4PGS0xlv9wACgsB9T
zZFHohWjeI8dRPcnGyrWypY=
=+uw+
-----END PGP SIGNATURE-----



From damwid at gmail.com  Fri May 18 12:08:40 2007
From: damwid at gmail.com (DAMWID)
Date: Fri, 18 May 2007 20:08:40 +0800
Subject: [oe] oe build failed
Message-ID: <464D9748.9000908@gmail.com>

Hi all,

I use OE to build rootfs for PXA270 board, but failed when compile
glibc, the following is error log:

[...]
| make[2]: Entering directory
`/work/bulvder/oe/build/tmp/work/armv5te-linux-gnueabi/glibc-2.3.5+cvs20050627-r13/libc/resource'
| ccache arm-linux-gnueabi-gcc -march=armv5te -mtune=xscale
../ports/sysdeps/unix/sysv/linux/arm/getrlimit.c -c -std=gnu99 -O2 -Wall
-Winline -Wstrict-prototypes -Wwrite-strings -fexpensive-optimizations
-frename-registers
-isystem/opt/arm-linux-gnueabi/arm-linux-gnueabi/include
-fomit-frame-pointer -I../include -I.
-I/work/bulvder/oe/build/tmp/work/armv5te-linux-gnueabi/glibc-2.3.5+cvs20050627-r13/build-arm-linux-gnueabi/resource
-I.. -I../libio
-I/work/bulvder/oe/build/tmp/work/armv5te-linux-gnueabi/glibc-2.3.5+cvs20050627-r13/build-arm-linux-gnueabi
-I../ports/sysdeps/arm/elf
-I../ports/sysdeps/unix/sysv/linux/arm/linuxthreads
-I../ports/sysdeps/unix/sysv/linux/arm
-I../ports/sysdeps/unix/sysv/linux -I../ports/sysdeps/unix/sysv
-I../ports/sysdeps/unix/arm -I../ports/sysdeps/unix
-I../ports/sysdeps/arm/linuxthreads -I../ports/sysdeps/arm
-I../sysdeps/wordsize-32 -I../sysdeps/ieee754/flt-32
-I../sysdeps/ieee754/dbl-64 -I../linuxthreads/sysdeps/unix/sysv/linux
-I../linuxthreads/sysdeps/pthread -I../sysdeps/pthread
-I../linuxthreads/sysdeps/unix/sysv -I../linuxthreads/sysdeps/unix
-I../sysdeps/unix/sysv/linux -I../sysdeps/gnu -I../sysdeps/unix/common
-I../sysdeps/unix/mman -I../sysdeps/unix/inet -I../sysdeps/unix/sysv
-I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/ieee754
-I../sysdeps/generic/elf -I../sysdeps/generic -nostdinc -isystem
/opt/arm-linux-gnueabi/lib/gcc/arm-linux-gnueabi/4.1.1/include -isystem
/opt/arm-linux-gnueabi/arm-linux-gnueabi/include -D_LIBC_REENTRANT
-include ../include/libc-symbols.h -o
/work/bulvder/oe/build/tmp/work/armv5te-linux-gnueabi/glibc-2.3.5+cvs20050627-r13/build-arm-linux-gnueabi/resource/getrlimit.o
-MD -MP -MF
/work/bulvder/oe/build/tmp/work/armv5te-linux-gnueabi/glibc-2.3.5+cvs20050627-r13/build-arm-linux-gnueabi/resource/getrlimit.o.dt
-MT
/work/bulvder/oe/build/tmp/work/armv5te-linux-gnueabi/glibc-2.3.5+cvs20050627-r13/build-arm-linux-gnueabi/resource/getrlimit.o
| In file included from ../ports/sysdeps/unix/sysv/linux/arm/getrlimit.c:1:
| ../sysdeps/unix/sysv/linux/i386/getrlimit.c: In function
'__new_getrlimit':
| ../sysdeps/unix/sysv/linux/i386/getrlimit.c:65: error:
'__NR_getrlimit' undeclared (first use in this function)
| ../sysdeps/unix/sysv/linux/i386/getrlimit.c:65: error: (Each
undeclared identifier is reported only once
| ../sysdeps/unix/sysv/linux/i386/getrlimit.c:65: error: for each
function it appears in.)
| make[2]: ***
[/work/bulvder/oe/build/tmp/work/armv5te-linux-gnueabi/glibc-2.3.5+cvs20050627-r13/build-arm-linux-gnueabi/resource/getrlimit.o]
Error 1
| make[2]: Leaving directory
`/work/bulvder/oe/build/tmp/work/armv5te-linux-gnueabi/glibc-2.3.5+cvs20050627-r13/libc/resource'
| make[1]: *** [resource/subdir_lib] Error 2
| make[1]: Leaving directory
`/work/bulvder/oe/build/tmp/work/armv5te-linux-gnueabi/glibc-2.3.5+cvs20050627-r13/libc'
| make: *** [all] Error 2
| FATAL: oe_runmake failed
NOTE: Task failed:
/work/bulvder/oe/build/tmp/work/armv5te-linux-gnueabi/glibc-2.3.5+cvs20050627-r13/temp/log.do_compile.17022
NOTE: package glibc-2.3.5+cvs20050627-r13: task do_compile: failed
ERROR: TaskFailed event exception, aborting
NOTE: package glibc-2.3.5+cvs20050627: failed

Does anyone know what is the problem? Attachment is my local.conf.

Thanks,
Damwid

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: local.conf
URL: <http://layers.openembedded.org/pipermail/openembedded-devel/attachments/20070518/dd30f3c3/attachment.ksh>

From koen at dominion.kabel.utwente.nl  Fri May 18 12:36:49 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Fri, 18 May 2007 14:36:49 +0200
Subject: [oe] oe build failed
In-Reply-To: <464D9748.9000908@gmail.com>
References: <464D9748.9000908@gmail.com>
Message-ID: <464D9DE1.8000700@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

DAMWID schreef:
> Hi all,
> 
> I use OE to build rootfs for PXA270 board, but failed when compile
> glibc, the following is error log:

Use the local.conf from http://www.angstrom-distribution.org/building-angstrom

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGTZ3hMkyGM64RGpERAmXOAJsEMKrOhU5Z90hWZkVpQmk6QP7IlwCgrFnV
dw5F8T02dKoMip7pUr/ys1c=
=0Ux5
-----END PGP SIGNATURE-----



From rpurdie at rpsys.net  Sat May 19 17:50:15 2007
From: rpurdie at rpsys.net (Richard Purdie)
Date: Sat, 19 May 2007 18:50:15 +0100
Subject: [oe] do_rootfs fails
In-Reply-To: <4644B4D1.5010803@klever.net>
References: <4644ABCB.6080202@openhardware.net>
	<4644B0D2.8020409@dominion.kabel.utwente.nl>
	<4644B4D1.5010803@klever.net>
Message-ID: <1179597015.5852.5.camel@localhost.localdomain>

On Fri, 2007-05-11 at 20:24 +0200, Michael Krelin wrote:
> There's also an option of asking Tom to bitbake -DDD and send it to
> zecke, because I couldn't find time to try BB 1.6 for him again. And let
> him apply the patch that fixes this problem:
> 
> Index: lib/bb/parse/parse_py/BBHandler.py
> ===================================================================
> --- lib/bb/parse/parse_py/BBHandler.py  (revision 817)
> +++ lib/bb/parse/parse_py/BBHandler.py  (working copy)
> @@ -66,7 +66,9 @@
>          if not file in __inherit_cache.split():
>              debug(2, "BB %s:%d: inheriting %s" % (fn, lineno, file))
>              __inherit_cache += " %s" % file
> +            data.setVar('__inherit_cache', __inherit_cache, d)
>              include(fn, file, d)
> +            __inherit_cache = data.getVar('__inherit_cache', d) or ""
>      data.setVar('__inherit_cache', __inherit_cache, d)

Thanks for this, I've merged into bitbake 1.9, 1.8 and 1.6 branches as
they all had this issue!

Cheers,

Richard





From koen at dominion.kabel.utwente.nl  Sat May 19 17:58:32 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Sat, 19 May 2007 19:58:32 +0200
Subject: [oe] RFC: make do_install and do_deploy a PACKAGE_FUNC
In-Reply-To: <463C9EA9.2060302@dominion.kabel.utwente.nl>
References: <463C9EA9.2060302@dominion.kabel.utwente.nl>
Message-ID: <464F3AC8.5000804@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Koen Kooi schreef:
> Hi,
> 
> Lately there have been several problems with files not getting packaged, because users
> resumed builds after a failure. Richard has come up with a fix:
> 
> http://www.rpsys.net/openzaurus/temp/oe-install-change.patch
> 
> The only bug with that patch is that do_deploy fails, which can be solved by making that a
>  PACKAGE_FUNC as well.
> 
> What do you think about that?

So this is bugfree and can go in immediately?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGTzrIMkyGM64RGpERAnN8AJ9NQh73txV4w4h4FyCp8+Zj95R7UQCcChwH
ti0bnbez4K1Iqgbt+futJ4A=
=1Jkw
-----END PGP SIGNATURE-----



From rpurdie at rpsys.net  Sat May 19 20:13:01 2007
From: rpurdie at rpsys.net (Richard Purdie)
Date: Sat, 19 May 2007 21:13:01 +0100
Subject: [oe] RFC: make do_install and do_deploy a PACKAGE_FUNC
In-Reply-To: <464F3AC8.5000804@dominion.kabel.utwente.nl>
References: <463C9EA9.2060302@dominion.kabel.utwente.nl>
	<464F3AC8.5000804@dominion.kabel.utwente.nl>
Message-ID: <1179605582.5852.9.camel@localhost.localdomain>

On Sat, 2007-05-19 at 19:58 +0200, Koen Kooi wrote:
> Koen Kooi schreef:
> > Hi,
> > 
> > Lately there have been several problems with files not getting packaged, because users
> > resumed builds after a failure. Richard has come up with a fix:
> > 
> > http://www.rpsys.net/openzaurus/temp/oe-install-change.patch
> > 
> > The only bug with that patch is that do_deploy fails, which can be solved by making that a
> >  PACKAGE_FUNC as well.
> > 
> > What do you think about that?
> 
> So this is bugfree and can go in immediately?

I'm in two minds about this.

An alternative is we stop populate_packages() moving files around,
copying them instead. This means deploy can run after install, install
can be a separate task and builds should continue where they left of if
interrupted during the packaging phase.

Opinions?

Richard




From leon.woestenberg at gmail.com  Sun May 20 15:45:56 2007
From: leon.woestenberg at gmail.com (Leon Woestenberg)
Date: Sun, 20 May 2007 17:45:56 +0200
Subject: [oe] RFC: make do_install and do_deploy a PACKAGE_FUNC
In-Reply-To: <1179605582.5852.9.camel@localhost.localdomain>
References: <463C9EA9.2060302@dominion.kabel.utwente.nl>
	<464F3AC8.5000804@dominion.kabel.utwente.nl>
	<1179605582.5852.9.camel@localhost.localdomain>
Message-ID: <c384c5ea0705200845w36cf4274x6b22f03cdf01506d@mail.gmail.com>

Hello,

On 5/19/07, Richard Purdie <rpurdie at rpsys.net> wrote:
> An alternative is we stop populate_packages() moving files around,
> copying them instead. This means deploy can run after install, install
> can be a separate task and builds should continue where they left of if
> interrupted during the packaging phase.
>
> Opinions?
>
Looks sane to me.

Leon.



From ulf at atmel.com  Sat May 26 21:07:51 2007
From: ulf at atmel.com (Ulf Samuelsson)
Date: Sat, 26 May 2007 23:07:51 +0200
Subject: [oe] OpenEmbedded insist on downloading existing package
Message-ID: <00b801c79fd9$ee494f90$0302a8c0@atmel.com>

I have defined the download location to and
I have linux-2.6.21.1.tar.bz2 in this directory.

OpenEmbedded seems to ignore this and insists on *downloading*
linux-2.6.21.1.tar.bz2 before use.

- This is no fun.

Anything that can be done?


Best Regards
Ulf Samuelsson




From freyther at gmx.net  Sun May 20 21:47:58 2007
From: freyther at gmx.net (Holger Freyther)
Date: Sun, 20 May 2007 23:47:58 +0200
Subject: [oe] OpenEmbedded insist on downloading existing package
In-Reply-To: <00b801c79fd9$ee494f90$0302a8c0@atmel.com>
References: <00b801c79fd9$ee494f90$0302a8c0@atmel.com>
Message-ID: <66584307-3DAA-4B3C-8A5F-32915D6FF1EC@gmx.net>


Am 26.05.2007 um 23:07 schrieb Ulf Samuelsson:

> I have defined the download location to and
> I have linux-2.6.21.1.tar.bz2 in this directory.
>
> OpenEmbedded seems to ignore this and insists on *downloading*
> linux-2.6.21.1.tar.bz2 before use.
>
> - This is no fun.
>
> Anything that can be done?

Well,

you play with the guts and hope it is working. First you need to have  
a filename.md5 in the same directory otherwise the fetcher will  
continue fetching (this is what you see) and then you might need to  
add a fetched stamp. As this stamp gets created  when the md5sum/ 
sha256sum was verified.


I don't know your reasoning but there must be a better answer to your  
problem.

z.





From koen at dominion.kabel.utwente.nl  Sun May 20 21:48:21 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Sun, 20 May 2007 23:48:21 +0200
Subject: [oe] OpenEmbedded insist on downloading existing package
In-Reply-To: <00b801c79fd9$ee494f90$0302a8c0@atmel.com>
References: <00b801c79fd9$ee494f90$0302a8c0@atmel.com>
Message-ID: <4650C225.9010907@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ulf Samuelsson schreef:
> I have defined the download location to and
> I have linux-2.6.21.1.tar.bz2 in this directory.

is linux-2.6.21.1.tar.bz2.md5 present there?

> OpenEmbedded seems to ignore this and insists on *downloading*
> linux-2.6.21.1.tar.bz2 before use.

if the md5 stamp isn't present it will try to download it again till the downloads
completes and linux-2.6.21.1.tar.bz2.md5 has been created.

> - This is no fun.
> 
> Anything that can be done?

See above.

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGUMIlMkyGM64RGpERAus1AKCLYQPDm8IRkOCvT3TqF/UFWiOCogCfdf2T
W/f6t+bzYKRlzcnbqhs2yYA=
=cJI9
-----END PGP SIGNATURE-----



From ulf at atmel.com  Mon May 21 06:14:43 2007
From: ulf at atmel.com (Ulf Samuelsson)
Date: Mon, 21 May 2007 08:14:43 +0200
Subject: [oe] OpenEmbedded insist on downloading existing package
References: <00b801c79fd9$ee494f90$0302a8c0@atmel.com>
	<4650C225.9010907@dominion.kabel.utwente.nl>
Message-ID: <005201c79b6f$56130270$0302a8c0@atmel.com>

> Ulf Samuelsson schreef:
>> I have defined the download location to and
>> I have linux-2.6.21.1.tar.bz2 in this directory.
> 
> is linux-2.6.21.1.tar.bz2.md5 present there?
> 
>> OpenEmbedded seems to ignore this and insists on *downloading*
>> linux-2.6.21.1.tar.bz2 before use.
> 
> if the md5 stamp isn't present it will try to download it again till the downloads
> completes and linux-2.6.21.1.tar.bz2.md5 has been created.
> 


Thanks, I will try this...

Best Regards
Ulf Samuelsson




From koen at dominion.kabel.utwente.nl  Mon May 21 07:56:09 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Mon, 21 May 2007 09:56:09 +0200
Subject: [oe] RFC: make do_install and do_deploy a PACKAGE_FUNC
In-Reply-To: <1179605582.5852.9.camel@localhost.localdomain>
References: <463C9EA9.2060302@dominion.kabel.utwente.nl>	<464F3AC8.5000804@dominion.kabel.utwente.nl>
	<1179605582.5852.9.camel@localhost.localdomain>
Message-ID: <46515099.6070006@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Richard Purdie schreef:
> On Sat, 2007-05-19 at 19:58 +0200, Koen Kooi wrote:
>> Koen Kooi schreef:
>>> Hi,
>>>
>>> Lately there have been several problems with files not getting packaged, because users
>>> resumed builds after a failure. Richard has come up with a fix:
>>>
>>> http://www.rpsys.net/openzaurus/temp/oe-install-change.patch
>>>
>>> The only bug with that patch is that do_deploy fails, which can be solved by making that a
>>>  PACKAGE_FUNC as well.
>>>
>>> What do you think about that?
>> So this is bugfree and can go in immediately?
> 
> I'm in two minds about this.
> 
> An alternative is we stop populate_packages() moving files around,
> copying them instead. This means deploy can run after install, install
> can be a separate task and builds should continue where they left of if
> interrupted during the packaging phase.
> 
> Opinions?

The copy-don't-move approach sounds good.

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGUVCZMkyGM64RGpERAoEMAJ4rFonlztzdou+L5L79M1Rk1hzn8gCePSjP
qXJHJlIfgDOSd+SkD1Bei1c=
=mo1f
-----END PGP SIGNATURE-----



From france at handhelds.org  Sun May 20 22:48:30 2007
From: france at handhelds.org (George France)
Date: Sun, 20 May 2007 18:48:30 -0400
Subject: [oe] baned from #OE IRC channel
Message-ID: <200705201848.30692.france@handhelds.org>

Hello,

This afternoon on Sunday May 20th, 2007 at about 18:30 EST (GMT-5) while on 
the #oe channel, I was banned by Kergoth for no apparent reason.  I had not 
said a single word, I was just listening like I always do.

What is going on?

--George



From ulf at atmel.com  Mon May 21 19:15:58 2007
From: ulf at atmel.com (Ulf Samuelsson)
Date: Mon, 21 May 2007 21:15:58 +0200
Subject: [oe] ERROR: Task 2246 ( ...
 org.openembedded.dev/packages/gnome/gnome-desktop_2.16.1.bb,
 do_compile) failed
Message-ID: <4651EFEE.50907@atmel.com>

Looks like there is an issue with the fdl.xml in this package?
Any workarounds?



NOTE: Running task 2742 of 3946 (ID: 2246, /home/ulf/projects/OpenEmbedded/org.openembedded.dev/packages/gnome/gnome-desktop_2.16.1.bb, do_compile)
NOTE: package gnome-desktop-2.16.1: started
NOTE: package gnome-desktop-2.16.1-r1: task do_compile: started
ERROR: function do_compile failed
ERROR: log data follows (/home/ulf/projects/OpenEmbedded/build/tmp/work/armv5te-angstrom-linux-gnueabi/gnome-desktop-2.16.1-r1/temp/log.do_compile.24525)
| NOTE: make
| make  all-recursive
| make[1]: Entering directory `/home/ulf/projects/OpenEmbedded/build/tmp/work/armv5te-angstrom-linux-gnueabi/gnome-desktop-2.16.1-r1/gnome-desktop-2.16.1'
| Making all in po
| make[2]: Entering directory `/home/ulf/projects/OpenEmbedded/build/tmp/work/armv5te-angstrom-linux-gnueabi/gnome-desktop-2.16.1-r1/gnome-desktop-2.16.1/po'
| make[2]: Nothing to be done for `all'.
| make[2]: Leaving directory `/home/ulf/projects/OpenEmbedded/build/tmp/work/armv5te-angstrom-linux-gnueabi/gnome-desktop-2.16.1-r1/gnome-desktop-2.16.1/po'
| Making all in libgnome-desktop
| make[2]: Entering directory `/home/ulf/projects/OpenEmbedded/build/tmp/work/armv5te-angstrom-linux-gnueabi/gnome-desktop-2.16.1-r1/gnome-desktop-2.16.1/libgnome-desktop'
| Making all in libgnome
| make[3]: Entering directory `/home/ulf/projects/OpenEmbedded/build/tmp/work/armv5te-angstrom-linux-gnueabi/gnome-desktop-2.16.1-r1/gnome-desktop-2.16.1/libgnome-desktop/libgnome'
| make[3]: Nothing to be done for `all'.
| make[3]: Leaving directory `/home/ulf/projects/OpenEmbedded/build/tmp/work/armv5te-angstrom-linux-gnueabi/gnome-desktop-2.16.1-r1/gnome-desktop-2.16.1/libgnome-desktop/libgnome'
| Making all in libgnomeui
| make[3]: Entering directory `/home/ulf/projects/OpenEmbedded/build/tmp/work/armv5te-angstrom-linux-gnueabi/gnome-desktop-2.16.1-r1/gnome-desktop-2.16.1/libgnome-desktop/libgnomeui'
| make[3]: Nothing to be done for `all'.
| make[3]: Leaving directory `/home/ulf/projects/OpenEmbedded/build/tmp/work/armv5te-angstrom-linux-gnueabi/gnome-desktop-2.16.1-r1/gnome-desktop-2.16.1/libgnome-desktop/libgnomeui'
| make[3]: Entering directory `/home/ulf/projects/OpenEmbedded/build/tmp/work/armv5te-angstrom-linux-gnueabi/gnome-desktop-2.16.1-r1/gnome-desktop-2.16.1/libgnome-desktop'
| make[3]: Nothing to be done for `all-am'.
| make[3]: Leaving directory `/home/ulf/projects/OpenEmbedded/build/tmp/work/armv5te-angstrom-linux-gnueabi/gnome-desktop-2.16.1-r1/gnome-desktop-2.16.1/libgnome-desktop'
| make[2]: Leaving directory `/home/ulf/projects/OpenEmbedded/build/tmp/work/armv5te-angstrom-linux-gnueabi/gnome-desktop-2.16.1-r1/gnome-desktop-2.16.1/libgnome-desktop'
| Making all in gnome-about
| make[2]: Entering directory `/home/ulf/projects/OpenEmbedded/build/tmp/work/armv5te-angstrom-linux-gnueabi/gnome-desktop-2.16.1-r1/gnome-desktop-2.16.1/gnome-about'
| Making all in headers
| make[3]: Entering directory `/home/ulf/projects/OpenEmbedded/build/tmp/work/armv5te-angstrom-linux-gnueabi/gnome-desktop-2.16.1-r1/gnome-desktop-2.16.1/gnome-about/headers'
| make[3]: Nothing to be done for `all'.
| make[3]: Leaving directory `/home/ulf/projects/OpenEmbedded/build/tmp/work/armv5te-angstrom-linux-gnueabi/gnome-desktop-2.16.1-r1/gnome-desktop-2.16.1/gnome-about/headers'
| make[3]: Entering directory `/home/ulf/projects/OpenEmbedded/build/tmp/work/armv5te-angstrom-linux-gnueabi/gnome-desktop-2.16.1-r1/gnome-desktop-2.16.1/gnome-about'
| make[3]: Nothing to be done for `all-am'.
| make[3]: Leaving directory `/home/ulf/projects/OpenEmbedded/build/tmp/work/armv5te-angstrom-linux-gnueabi/gnome-desktop-2.16.1-r1/gnome-desktop-2.16.1/gnome-about'
| make[2]: Leaving directory `/home/ulf/projects/OpenEmbedded/build/tmp/work/armv5te-angstrom-linux-gnueabi/gnome-desktop-2.16.1-r1/gnome-desktop-2.16.1/gnome-about'
| Making all in pixmaps
| make[2]: Entering directory `/home/ulf/projects/OpenEmbedded/build/tmp/work/armv5te-angstrom-linux-gnueabi/gnome-desktop-2.16.1-r1/gnome-desktop-2.16.1/pixmaps'
| make[2]: Nothing to be done for `all'.
| make[2]: Leaving directory `/home/ulf/projects/OpenEmbedded/build/tmp/work/armv5te-angstrom-linux-gnueabi/gnome-desktop-2.16.1-r1/gnome-desktop-2.16.1/pixmaps'
| Making all in desktop-docs
| make[2]: Entering directory `/home/ulf/projects/OpenEmbedded/build/tmp/work/armv5te-angstrom-linux-gnueabi/gnome-desktop-2.16.1-r1/gnome-desktop-2.16.1/desktop-docs'
| Making all in fdl
| make[3]: Entering directory `/home/ulf/projects/OpenEmbedded/build/tmp/work/armv5te-angstrom-linux-gnueabi/gnome-desktop-2.16.1-r1/gnome-desktop-2.16.1/desktop-docs/fdl'
| xsltproc -o fdl-es.omf --stringparam db2omf.basename fdl --stringparam db2omf.format 'docbook' --stringparam db2omf.dtd "-//OASIS//DTD DocBook XML V4.1.2//EN" --stringparam db2omf.lang es --stringparam db2omf.omf_dir "/usr/share/omf" --stringparam db2omf.help_dir "/usr/share/gnome/help"
--stringparam db2omf.omf_in "`pwd`//home/ulf/projects/OpenEmbedded/build/tmp/work/armv5te-angstrom-linux-gnueabi/gnome-desktop-2.16.1-r1/gnome-desktop-2.16.1/desktop-docs/fdl/fdl.omf.in" `/home/ulf/projects/OpenEmbedded/build/tmp/staging/i686-linux/bin/pkg-config --variable db2omf gnome-doc-utils`
es/fdl.xml
| warning: failed to load external entity
"/home/ulf/projects/OpenEmbedded/build/tmp/work/armv5te-angstrom-linux-gnueabi/gnome-desktop-2.16.1-r1/gnome-desktop-2.16.1/desktop-docs/fdl//home/ulf/projects/OpenEmbedded/build/tmp/work/armv5te-angstrom-linux-gnueabi/gnome-desktop-2.16.1-r1/gnome-desktop-2.16.1/desktop-docs/fdl/fdl.omf.in"
| db2omf: Could not construct the OMF maintainer element.
|   Add an author, corpauthor, editor, othercredit, or publisher
|   element with the role attribute set to "maintainer" to fdl.xml.
| make[3]: *** [fdl-es.omf] Error 10
| make[3]: Leaving directory `/home/ulf/projects/OpenEmbedded/build/tmp/work/armv5te-angstrom-linux-gnueabi/gnome-desktop-2.16.1-r1/gnome-desktop-2.16.1/desktop-docs/fdl'
| make[2]: *** [all-recursive] Error 1
| make[2]: Leaving directory `/home/ulf/projects/OpenEmbedded/build/tmp/work/armv5te-angstrom-linux-gnueabi/gnome-desktop-2.16.1-r1/gnome-desktop-2.16.1/desktop-docs'
| make[1]: *** [all-recursive] Error 1
| make[1]: Leaving directory `/home/ulf/projects/OpenEmbedded/build/tmp/work/armv5te-angstrom-linux-gnueabi/gnome-desktop-2.16.1-r1/gnome-desktop-2.16.1'
| make: *** [all] Error 2
| FATAL: oe_runmake failed
NOTE: Task failed: /home/ulf/projects/OpenEmbedded/build/tmp/work/armv5te-angstrom-linux-gnueabi/gnome-desktop-2.16.1-r1/temp/log.do_compile.24525
NOTE: package gnome-desktop-2.16.1-r1: task do_compile: failed
ERROR: TaskFailed event exception, aborting
NOTE: package gnome-desktop-2.16.1: failed
ERROR: Build of /home/ulf/projects/OpenEmbedded/org.openembedded.dev/packages/gnome/gnome-desktop_2.16.1.bb do_compile failed
ERROR: Task 2246 (/home/ulf/projects/OpenEmbedded/org.openembedded.dev/packages/gnome/gnome-desktop_2.16.1.bb, do_compile) failed
ERROR: '/home/ulf/projects/OpenEmbedded/org.openembedded.dev/packages/gnome/gnome-desktop_2.16.1.bb' failed
ulf at aeglos:~/projects/OpenEmbedded/build>


-- 
Best Regards,
Ulf Samuelsson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ulf.vcf
Type: text/x-vcard
Size: 301 bytes
Desc: not available
URL: <http://layers.openembedded.org/pipermail/openembedded-devel/attachments/20070521/b04bd7f9/attachment.vcf>

From freyther at gmx.net  Mon May 21 21:53:12 2007
From: freyther at gmx.net (Holger Freyther)
Date: Mon, 21 May 2007 23:53:12 +0200
Subject: [oe] ERROR: Task 2246 ( ...
	org.openembedded.dev/packages/gnome/gnome-desktop_2.16.1.bb,
	do_compile) failed
In-Reply-To: <4651EFEE.50907@atmel.com>
References: <4651EFEE.50907@atmel.com>
Message-ID: <189F751D-9A54-4A17-84FD-82CD2BF62403@gmx.net>


Am 21.05.2007 um 21:15 schrieb Ulf Samuelsson:

> Looks like there is an issue with the fdl.xml in this package?
> Any workarounds?

Did you lack internet connectivity during the build?







From nils.faerber at kernelconcepts.de  Mon May 21 23:05:27 2007
From: nils.faerber at kernelconcepts.de (Nils Faerber)
Date: Tue, 22 May 2007 01:05:27 +0200
Subject: [oe] Problem wt. perl-native building for PXA
Message-ID: <465225B7.50900@kernelconcepts.de>

Hi!
I am encountering a strange problem while trying to build Angstrom for
PXA (for LinuxTag demo purposes). While we have some other machines
building it with the same version of OE and Bitbake just fine it fails
on my notebook (but I would like to be able to rebuild it directly at
LinuxTag, thus the question).
My machine has Ubuntu feisty installed. I am using Bitbake 1.8 from SVN
and an OE checkout from today.

What happens is that the build works quite well until it comes to
perl-native-5.8.8-r7. There it fails with the following error:

...
|       Making x2p stuff
| make[1]: Entering directory
`/media/disk/oe/build_h5xxx/tmp/work/i686-linux/perl-native-5.8.8-r7/perl-5.8.8/x2p'
| You haven't done a "make depend" yet!
| make[1]: *** [hash.o] Error 1
...
[ full log attached ]

I have the feeling that it has something to do with my host setup but I
have no clue what!? If I comment out the dependency check from the
source directory (outch, hack!) it compiles fine and continues. Most
other packages work to compile then until
libxml-parser-perl-native_2.34.bb which again fails because of a
misinstallation of the per utils in the staging directory.

I am really quite clueless what might be the reason.
If anyone encoutered this before I would be glad to share hints to
resolve the situation ;)

Thanks!

Cheers
  nils faerber

-- 
kernel concepts GbR      Tel: +49-271-771091-12
Sieghuetter Hauptweg 48  Fax: +49-271-771091-19
D-57072 Siegen           Mob: +49-176-21024535
--
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: log.do_compile.6371
URL: <http://layers.openembedded.org/pipermail/openembedded-devel/attachments/20070522/dc1f1f01/attachment.ksh>

From rpurdie at rpsys.net  Mon May 21 23:20:19 2007
From: rpurdie at rpsys.net (Richard Purdie)
Date: Tue, 22 May 2007 00:20:19 +0100
Subject: [oe] Problem wt. perl-native building for PXA
In-Reply-To: <465225B7.50900@kernelconcepts.de>
References: <465225B7.50900@kernelconcepts.de>
Message-ID: <1179789619.5849.59.camel@localhost.localdomain>

Hi,

On Tue, 2007-05-22 at 01:05 +0200, Nils Faerber wrote:
> I am encountering a strange problem while trying to build Angstrom for
> PXA (for LinuxTag demo purposes). While we have some other machines
> building it with the same version of OE and Bitbake just fine it fails
> on my notebook (but I would like to be able to rebuild it directly at
> LinuxTag, thus the question).
> My machine has Ubuntu feisty installed. I am using Bitbake 1.8 from SVN
> and an OE checkout from today.
> 
> What happens is that the build works quite well until it comes to
> perl-native-5.8.8-r7. There it fails with the following error:

I'm not familiar with the error but what does /bin/sh point at?

If its dash, try bash as dash causes no end of headaches.

Cheers,

Richard





From nils.faerber at kernelconcepts.de  Mon May 21 23:34:59 2007
From: nils.faerber at kernelconcepts.de (Nils Faerber)
Date: Tue, 22 May 2007 01:34:59 +0200
Subject: [oe] Problem wt. perl-native building for PXA
In-Reply-To: <1179789619.5849.59.camel@localhost.localdomain>
References: <465225B7.50900@kernelconcepts.de>
	<1179789619.5849.59.camel@localhost.localdomain>
Message-ID: <46522CA3.1010000@kernelconcepts.de>

Richard Purdie schrieb:
> Hi,
Hi!

> On Tue, 2007-05-22 at 01:05 +0200, Nils Faerber wrote:
>> I am encountering a strange problem while trying to build Angstrom for
>> PXA (for LinuxTag demo purposes). While we have some other machines
>> building it with the same version of OE and Bitbake just fine it fails
>> on my notebook (but I would like to be able to rebuild it directly at
>> LinuxTag, thus the question).
>> My machine has Ubuntu feisty installed. I am using Bitbake 1.8 from SVN
>> and an OE checkout from today.
>>
>> What happens is that the build works quite well until it comes to
>> perl-native-5.8.8-r7. There it fails with the following error:
> 
> I'm not familiar with the error but what does /bin/sh point at?
> 
> If its dash, try bash as dash causes no end of headaches.

Is tihs Ubuntu?
I did never recognise this, but you are perfectly right with your
assumption, sh -> dash.

Gee, hey look, now it works!!!
This dash thing should be tarred and feathered ;)

Many thanks!

> Cheers,
> Richard
Cheers
  nils faerber

-- 
kernel concepts GbR      Tel: +49-271-771091-12
Sieghuetter Hauptweg 48  Fax: +49-271-771091-19
D-57072 Siegen           Mob: +49-176-21024535
--



From ulf at atmel.com  Tue May 22 04:24:27 2007
From: ulf at atmel.com (Ulf Samuelsson)
Date: Tue, 22 May 2007 06:24:27 +0200
Subject: [oe] ERROR: Task 2246 (
	...org.openembedded.dev/packages/gnome/gnome-desktop_2.16.1.bb,
	do_compile) failed
References: <4651EFEE.50907@atmel.com>
	<189F751D-9A54-4A17-84FD-82CD2BF62403@gmx.net>
Message-ID: <003a01c79c29$1985a690$26031a0a@atmel.com>

> 
> Am 21.05.2007 um 21:15 schrieb Ulf Samuelsson:
> 
>> Looks like there is an issue with the fdl.xml in this package?
>> Any workarounds?
> 
> Did you lack internet connectivity during the build?
> 


I have been trying to build this for a couple of days,
and sometimes the connections has been bad.


Been trying to fetch all packages in advance by 

$ bitbake -c fetch gpe-image

but that does not work.


Best Regards
Ulf Samuelsson




From no2spam at nospam.arcornews.de  Tue May 22 07:53:51 2007
From: no2spam at nospam.arcornews.de (Rolf Leggewie)
Date: Tue, 22 May 2007 09:53:51 +0200
Subject: [oe] ERROR: Task 2246 (
 ...org.openembedded.dev/packages/gnome/gnome-desktop_2.16.1.bb,
 do_compile) failed
In-Reply-To: <003a01c79c29$1985a690$26031a0a@atmel.com>
References: <4651EFEE.50907@atmel.com>	<189F751D-9A54-4A17-84FD-82CD2BF62403@gmx.net>
	<003a01c79c29$1985a690$26031a0a@atmel.com>
Message-ID: <f2u7if$5g3$1@sea.gmane.org>

Ulf Samuelsson wrote:
> Been trying to fetch all packages in advance by 
> 
> $ bitbake -c fetch gpe-image
> 
> but that does not work.

You want bitbake -c fetchall gpe-image




From koen at dominion.kabel.utwente.nl  Tue May 22 08:28:16 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Tue, 22 May 2007 10:28:16 +0200
Subject: [oe] ERROR: Task 2246 (
 ...org.openembedded.dev/packages/gnome/gnome-desktop_2.16.1.bb,
 do_compile) failed
In-Reply-To: <f2u7if$5g3$1@sea.gmane.org>
References: <4651EFEE.50907@atmel.com>	<189F751D-9A54-4A17-84FD-82CD2BF62403@gmx.net>	<003a01c79c29$1985a690$26031a0a@atmel.com>
	<f2u7if$5g3$1@sea.gmane.org>
Message-ID: <4652A9A0.6060109@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Rolf Leggewie schreef:
> Ulf Samuelsson wrote:
>> Been trying to fetch all packages in advance by 
>>
>> $ bitbake -c fetch gpe-image
>>
>> but that does not work.
> 
> You want bitbake -c fetchall gpe-image

Actually, no. With angstrom you want 'bitbake -c fetchall angstrom-x11-image'

regards,

KOen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGUqmgMkyGM64RGpERArd8AJ96Hc/IqpB0nHLyNOSlImfhs6AbcQCdFGJS
ok7J/m0QH6pWYgfm1Qww0y0=
=tovE
-----END PGP SIGNATURE-----



From openembedded at hrw.one.pl  Tue May 22 08:43:46 2007
From: openembedded at hrw.one.pl (Marcin Juszkiewicz)
Date: Tue, 22 May 2007 10:43:46 +0200
Subject: [oe] ERROR: Task 2246 (
	...org.openembedded.dev/packages/gnome/gnome-desktop_2.16.1.bb,
	do_compile) failed
In-Reply-To: <003a01c79c29$1985a690$26031a0a@atmel.com>
References: <4651EFEE.50907@atmel.com>
	<189F751D-9A54-4A17-84FD-82CD2BF62403@gmx.net>
	<003a01c79c29$1985a690$26031a0a@atmel.com>
Message-ID: <200705221043.47508.openembedded@hrw.one.pl>

Dnia wtorek, 22 maja 2007, Ulf Samuelsson napisa?:

> Been trying to fetch all packages in advance by
>
> $ bitbake -c fetch gpe-image
>
> but that does not work.

"bitbake -cfetchall gpe-image" is for that


-- 
JID: hrw-jabber.org
OpenEmbedded developer/consultant

       If you're going down in flames, aim for something expensive.





From freyther at gmx.net  Tue May 22 09:53:37 2007
From: freyther at gmx.net (Holger Freyther)
Date: Tue, 22 May 2007 11:53:37 +0200
Subject: [oe] ERROR: Task 2246 (
	...org.openembedded.dev/packages/gnome/gnome-desktop_2.16.1.bb,
	do_compile) failed
In-Reply-To: <003a01c79c29$1985a690$26031a0a@atmel.com>
References: <4651EFEE.50907@atmel.com>
	<189F751D-9A54-4A17-84FD-82CD2BF62403@gmx.net>
	<003a01c79c29$1985a690$26031a0a@atmel.com>
Message-ID: <75DD721B-B0C4-46EF-A8F2-838E8DB5CF85@gmx.net>

>
>
> Been trying to fetch all packages in advance by
>
> $ bitbake -c fetch gpe-image

Hi,

even with that you will have the issue from before.

Q: What is the issue?
A: I'm not a XML geek but I think xsltproc and xmllint will download  
doctype and schemata during the generation of the documentation. I  
don't know if one can make xstlproc not to do it, this would be  
something for you to find out (xstlproc --help). What you can do/try  
is to add EXTRA_OECONF += " --disable-doc" in the offending recipes.


z.




From lvcargnini at gmail.com  Wed May 23 01:56:18 2007
From: lvcargnini at gmail.com (=?ISO-8859-1?Q?Lu=EDs_Cargnini?=)
Date: Tue, 22 May 2007 22:56:18 -0300
Subject: [oe] problems cross-compilinx xserver-xorg
Message-ID: <ae36f8040705221856p1ec52709y284a370bbc1af3ee@mail.gmail.com>

Hi I'm trying to bitbake xserver-xorg (cvs version) and I received the
following results:

NOTE: xserver-xorg-6.8.1+cvs20070523-cvs://anoncvs.freedesktop.org/cvs/xorghas
no section, not checking URI
NOTE: xserver-xorg-6.8.1+cvs20070523-file://imake-staging.patch has no
section, not checking URI
NOTE: xserver-xorg-6.8.1+cvs20070523-file://dri.patch has no section, not
checking URI
NOTE: package xserver-xorg-6.8.1+cvs20070523-r3: task do_fetch: completed
NOTE: package xserver-xorg-6.8.1+cvs20070523-r3: task do_unpack: started
NOTE: Unpacking
/home/lvcargnini/puc/instramed/openembedded/build/sources/xc_anoncvs.freedesktop.org__20070523.tar.gz
to
/home/lvcargnini/puc/instramed/openembedded/tmp/work/armv5te-linux/xserver-
xorg-6.8.1+cvs20070523-r3/
NOTE: package xserver-xorg-6.8.1+cvs20070523-r3: task do_unpack: completed
NOTE: package xserver-xorg-6.8.1+cvs20070523-r3: task do_patch: started
NOTE: Applying patch 'imake-staging.patch'
NOTE: Task failed: Command Error: exit status: 127  Output:
sh: quilt: command not found
NOTE: package xserver-xorg-6.8.1+cvs20070523-r3: task do_patch: failed
ERROR: TaskFailed event exception, aborting
NOTE: package xserver-xorg-6.8.1+cvs20070523: failed
ERROR: Build of 'xserver-xorg' failed
Build statistics:
  Attempted builds: 1
  Failed builds: 1
someone please could help me ?
my local.conf:

(enterprise:~/puc/instramed/openembedded) lvcargnini% cat
build/conf/local.conf
#
# OpenEmbedded local configuration file (sample)
#
# Please visit the Wiki at http://openembedded.org/ for more info.
#
#
# Be SURE to read this file in its entirety and the GettingStarted page on
the
# wiki before proceeding.
#
# Once you have done that, remove the line at the end of this
# file and build away.
#
# WARNING: lines starting with a space (' ') will result in parse failures.
# Remove '# ' from commented lines to activate them.
#
# NOTE: Do NOT use $HOME in your paths, BitBake does NOT expand ~ for you.
If you
# must have paths relative to your homedir use ${HOME} (note the {}'s there
# you MUST have them for the variable expansion to be done by BitBake).
Your
# paths should all be absolute paths (They should all start with a / after
# expansion.  Stuff like starting with ${HOME} or ${TOPDIR} is ok).

# Use this to specify where BitBake should place the downloaded sources into
DL_DIR = "/home/lvcargnini/puc/instramed/openembedded/build/sources"

# Delete the line below. Then specify which .bb files to consider for
# your build. Typically this will be something like BBFILES =
"/path/to/openembedded/packages/*/*.bb"
BBFILES :=
"/home/lvcargnini/puc/instramed/openembedded/org.openembedded.dev/packages/*/*.bb"

# Use the BBMASK below to instruct BitBake to _NOT_ consider some .bb files
# This is a regulary expression, so be sure to get your parenthesis
balanced.
BBMASK = ""

# Uncomment this if you want to use a prebuilt toolchain. You will need to
# provide packages for toolchain and additional libraries yourself. You also
# have to set PATH in your environment to make sure BitBake finds additional
binaries.
# Note: You will definitely need to say:
#     ASSUME_PROVIDED += "virtual/arm-linux-gcc-2.95"
# to build any of two Linux 2.4 Embedix kernels,
# i.e. openzaurus-sa-2.4.18 and openzaurus-pxa-2.4.18 - and don't forget
# to rename the binaries as instructed in the Wiki.
# ASSUME_PROVIDED += "virtual/${TARGET_PREFIX}gcc virtual/libc"
ASSUME_PROVIDED += "/opt/eldk/usr/bin"
# Select between multiple alternative providers, if more than one is
eligible.
PREFERRED_PROVIDERS = "virtual/qte:qte virtual/libqpe:libqpe-opie"
PREFERRED_PROVIDERS += " virtual/libsdl:libsdl-x11"
PREFERRED_PROVIDERS += "
virtual/${TARGET_PREFIX}gcc-initial:gcc-cross-initial"
PREFERRED_PROVIDERS += " virtual/${TARGET_PREFIX}gcc:gcc-cross"
PREFERRED_PROVIDERS += " virtual/${TARGET_PREFIX}g++:gcc-cross"

# Uncomment this to specify where BitBake should create its temporary files.
# Note that a full build of everything in OpenEmbedded will take GigaBytes
of hard
# disk space, so make sure to free enough space. The default TMPDIR is
# <build directory>/tmp
# Don't use symlinks in in the path to avoid problems
# TMPDIR = /usr/local/projects/oetmp
TMPDIR=/home/lvcargnini/puc/instramed/openembedded/tmp
# Uncomment this to specify a machine to build for. See the conf directory
# for machines currently known to OpenEmbedded. This will automatically take
care
# of TARGET_ARCH
# MACHINE = "c7x0"
MACHINE = "omap5912osk"
# Use this to specify the target architecture. Note that this is only
# needed when building for a machine not known to OpenEmbedded. Better use
# the MACHINE attribute (see above)
# TARGET_ARCH = "arm"
TARGET_ARCH = "arm"
# Use this to specify the target operating system.  The default is "linux",
# for a normal linux system with glibc. Set this to "linux-uclibc" if you
want
# to build a uclibc based system.
# Normally the DISTRO of your choosing will take care of this
# TARGET_OS = "linux"
# TARGET_OS = "linux-uclibc"
TARGET_OS = "linux"
# Uncomment this to select a distribution policy. See the conf directory
# for distributions currently known to OpenEmbedded.
# Although it no longer contain version number in the (file-)name
# openzaurus-unstable is a so called "versioned"  distro, i.e. they
# explicitely select specific versions of various packages.
# Stay away from unversioned distros unless you really know what you are
doing
# DISTRO = "generic"
DISTRO = "generic"
# So far, angstrom.conf sets ENABLE_BINARY_LOCALE_GENERATION
# to generate binary locale packages at build time using qemu-native and
# thereby guarantee i18n support on all devices. If your build breaks on
# qemu-native consider disabling ENABLE_BINARY_LOCALE_GENERATION (note that
# this breaks i18n on devices with less than 128MB RAM) or installing
# a working third-party qemu (e.g. provided by your distribution) and
# adding qemu-native to ASSUME_PROVIDED. Caveat emptor, since third-party
# qemus lack patches needed to work with various OE targets.
# ENABLE_BINARY_LOCALE_GENERATION = "0"
# ASSUME_PROVIDED += "qemu-native"

# If ENABLE_BINARY_LOCALE_GENERATION is set to "1", you can limit locales
# generated to the list provided by GLIBC_GENERATE_LOCALES. This is huge
# time-savior for developmental builds. Format: list of locale.encodingpairs
# with spaces as separators.
# GLIBC_GENERATE_LOCALES = "en_GB.UTF-8 de_DE.UTF-8"
GLIBC_GENERATE_LOCALES = "en en_GB fr it de pt_BR"
# Uncomment this to select a particular major kernel version if the MACHINE
setting
# supports more than one major kernel version. Currently this is suported by
the
# following MACHINE types: poodle, tosa and simpad.
# MACHINE_KERNEL_VERSION = "2.6"

# Uncomment one of these to build packages during the build process.
# This is done automatically if you set DISTRO (see above)
# INHERIT = "package_ipk"
INHERIT = "package_tar"

# Add the required image file system types below. Valid are jffs2, tar,
cramfs and ext2
IMAGE_FSTYPES = "jffs2 tar cramfs"

# Uncomment this to disable the parse cache (not recommended).
# CACHE = ""

# Uncomment this if you want BitBake to emit debugging output
# BBDEBUG = "yes"
BBDEBUG = "yes
# Uncomment these two if you want BitBake to build images useful for
debugging.
# Note that INHIBIT_PACKAGE_STRIP needs a package format to be defined.
# Also note that OE now produces -dbg packages which contain debugging
symbols.
# DEBUG_BUILD = "1"
# INHIBIT_PACKAGE_STRIP = "1"

# Uncomment these to build a package such that you can use gprof to profile
it.
# NOTE: This will only work with 'linux' targets, not
# 'linux-uclibc', as uClibc doesn't provide the necessary
# object files.  Also, don't build glibc itself with these
# flags, or it'll fail to build.
#
# PROFILE_OPTIMIZATION = "-pg"
# SELECTED_OPTIMIZATION = "${PROFILE_OPTIMIZATION}"
# LDFLAGS =+ "-pg"

# Uncomment this to enable parallel make.
# This allows make to spawn mutliple processes to take advantage of multiple

# processors. Useful on SMP machines. This may break some packages - we're
# in the process of marking these so let us know if you find any.
# PARALLEL_MAKE = "-j 4"

# Uncomment this if you want BitBake to emit the log if a build fails.
BBINCLUDELOGS = "yes"

-- 
------------------------------------------------------------------------------
Thanks && Regards
Msc. Bsc. Lu?s Vit?rio Cargnini
IEEE Member
Electrical Engineer Faculty @ PUCRS
Ipiranga Avenue, 6681 ? Building 30
P.O. Box: 90619-900 ? Porto Alegre/RS
Phone: +55 51 3320 3500  extension: 7696
---------------------------------------------------------------------------------


From mc-lists at tesco.net  Wed May 23 04:17:39 2007
From: mc-lists at tesco.net (Matt Callow)
Date: Wed, 23 May 2007 14:17:39 +1000
Subject: [oe] problems cross-compilinx xserver-xorg
In-Reply-To: <ae36f8040705221856p1ec52709y284a370bbc1af3ee@mail.gmail.com>
References: <ae36f8040705221856p1ec52709y284a370bbc1af3ee@mail.gmail.com>
Message-ID: <5937bed10705222117h314bc92cxc26261af9fcb2fb4@mail.gmail.com>

On 5/23/07, Lu?s Cargnini <lvcargnini at gmail.com> wrote:
> Hi I'm trying to bitbake xserver-xorg (cvs version) and I received the
> following results:
>
...
> sh: quilt: command not found

This looks like your problem. Try installing quilt.

Matt



From lenehan at twibble.org  Thu May 24 02:35:51 2007
From: lenehan at twibble.org (Jamie Lenehan)
Date: Thu, 24 May 2007 12:35:51 +1000
Subject: [oe] Problem wt. perl-native building for PXA
In-Reply-To: <46522CA3.1010000@kernelconcepts.de>
References: <465225B7.50900@kernelconcepts.de>
	<1179789619.5849.59.camel@localhost.localdomain>
	<46522CA3.1010000@kernelconcepts.de>
Message-ID: <20070524023551.GA31623@twibble.org>

On Tue, May 22, 2007 at 01:34:59AM +0200, Nils Faerber wrote:
> Richard Purdie schrieb:
> > Hi,
> Hi!
> 
> > On Tue, 2007-05-22 at 01:05 +0200, Nils Faerber wrote:
[...]
> >> My machine has Ubuntu feisty installed. I am using Bitbake 1.8 from SVN
[...]
> >> What happens is that the build works quite well until it comes to
> >> perl-native-5.8.8-r7. There it fails with the following error:
[...]
> Is tihs Ubuntu?
> I did never recognise this, but you are perfectly right with your
> assumption, sh -> dash.
> 
> Gee, hey look, now it works!!!

> This dash thing should be tarred and feathered ;)

I actually tested perl-native with dash, and it builds just fine here
when using dash:

  ~%> ./bb -b packages/perl/perl-native_5.8.8.bb 
  ...
  NOTE: package perl-native-5.8.8: completed
  ~%> ls -l /bin/sh
  lrwxrwxrwx 1 root root 4 2007-05-24 12:05 /bin/sh -> dash*
  ~%> cat /etc/issue.net 
  Ubuntu 6.10

In theory the following patch should fix the dash issues you were
seeing. Is their someone seeing this dash/perl-native issues that
could test this?

# 
# old_revision [d28c26f2757f88207089404b9e74286950165915]
# 
# add_file "packages/perl/perl-5.8.8/native-makedepend-dash.patch"
#  content [a32ff3bf1b75c57f6ff7ac58b232cc44f2648a27]
# 
# patch "packages/perl/perl-native_5.8.8.bb"
#  from [3013e9425fe473cf0988c3ccf6cad2b894e62e58]
#    to [e95283c93197ba0c2c16f42feef3c0b6691a7a53]
# 
============================================================
--- packages/perl/perl-5.8.8/native-makedepend-dash.patch	a32ff3bf1b75c57f6ff7ac58b232cc44f2648a27
+++ packages/perl/perl-5.8.8/native-makedepend-dash.patch	a32ff3bf1b75c57f6ff7ac58b232cc44f2648a27
@@ -0,0 +1,13 @@
+Index: perl-5.8.8/makedepend.SH
+===================================================================
+--- perl-5.8.8.orig/makedepend.SH	2007-05-24 12:06:52.000000000 +1000
++++ perl-5.8.8/makedepend.SH	2007-05-24 12:27:33.000000000 +1000
+@@ -128,7 +128,7 @@
+     *.y) filebase=`basename $file .y` ;;
+     esac
+     case "$file" in
+-    */*) finc="-I`echo $file | sed 's#/[^/]*$##`" ;;
++    */*) finc="-I`echo $file | sed 's#/[^/]*$##'`" ;;
+     *)   finc= ;;
+     esac
+     $echo "Finding dependencies for $filebase$_o."
============================================================
--- packages/perl/perl-native_5.8.8.bb	3013e9425fe473cf0988c3ccf6cad2b894e62e58
+++ packages/perl/perl-native_5.8.8.bb	e95283c93197ba0c2c16f42feef3c0b6691a7a53
@@ -12,7 +12,8 @@ SRC_URI = "http://ftp.funet.fi/pub/CPAN/
            file://Configure-multilib.patch;patch=1 \
            file://perl-configpm-switch.patch;patch=1 \
            file://native-nopacklist.patch;patch=1 \
-           file://native-no-gdbminc.patch;patch=1"
+           file://native-no-gdbminc.patch;patch=1 \
+           file://native-makedepend-dash.patch;patch=1"
 
 S = "${WORKDIR}/perl-${PV}"
 


-- 
 Jamie Lenehan <lenehan at twibble.org>



From Scott.Davis at smiths-aerospace.com  Tue May 22 19:17:43 2007
From: Scott.Davis at smiths-aerospace.com (Davis, Scott (AGRE))
Date: Tue, 22 May 2007 13:17:43 -0600
Subject: [oe]  Building Python extensions
Message-ID: <BDD06CD3363F254993AED78CA36350E20324E06D@cossmgmbx07.EMAIL.CORP.TLD>


I am trying to build a 32-bit shared library for a C library I have on
an x86_64 AMD SuSE linux system.  I am observing the same problem that
apparently someone on your list has had.  I have a commercial C 32-bit
linux library that I want to use SWIG to build a python extension for.
My linux system is 64-bit and when I compile against Python.h for Python
2.4 I get #error LONG BIT below emitted. 

The original post is at the URL below:
http://projects.linuxtogo.org/pipermail/openembedded-devel/2007-March/00
1722.html

What is the fix to build 32-bit shared library python extension on a
64-bit linux system?

#if LONG_BIT != 8 * SIZEOF_LONG 
/* 04-Oct-2000 LONG_BIT is apparently (mis)defined as 64 on some recent 
* 32-bit platforms using gcc. We try to catch that here at compile-time 
* rather than waiting for integer multiplication to trigger bogus *
overflows. */
 #error "LONG_BIT definition appears wrong for platform (bad gcc/glibc
config?)." 
#endif 

Scott Davis
GE
Aviation
Digital Systems
Principal Software Engineer

T 616 224 6659
F 616 241 8707
E scott.davis at smiths-aerospace.com
www.ge.com/aviation 

3290 Patterson Ave, SE 
Grand Rapids, MI 49512, U.S.A.



</table> </Pre>
<HTML>
<br>
<br>
************************************************<br>
The information contained in, or attached to, this e-mail, may contain confidential information and is intended solely for the use of the individual or entity to whom they are addressed and may be subject to legal privilege.  If you have received this e-mail in error you should notify the sender immediately by reply e-mail, delete the message from your system and notify your system manager.  Please do not copy it for any purpose, or disclose its contents to any other person.  The views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of the company.  The recipient should check this e-mail and any attachments for the presence of viruses.  The company accepts no liability for any damage caused, directly or indirectly, by any virus transmitted in this email.<br>
************************************************<br>
</HTML>

From openembedded at hrw.one.pl  Thu May 24 12:03:52 2007
From: openembedded at hrw.one.pl (Marcin Juszkiewicz)
Date: Thu, 24 May 2007 14:03:52 +0200
Subject: [oe] Building Python extensions
In-Reply-To: <BDD06CD3363F254993AED78CA36350E20324E06D@cossmgmbx07.EMAIL.CORP.TLD>
References: <BDD06CD3363F254993AED78CA36350E20324E06D@cossmgmbx07.EMAIL.CORP.TLD>
Message-ID: <200705241403.55472.openembedded@hrw.one.pl>

Dnia wtorek, 22 maja 2007, Davis, Scott (AGRE) napisa?:
> I am trying to build a 32-bit shared library for a C library I have on
> an x86_64 AMD SuSE linux system.  I am observing the same problem that
> apparently someone on your list has had.  I have a commercial C 32-bit
> linux library that I want to use SWIG to build a python extension for.
> My linux system is 64-bit and when I compile against Python.h for
> Python 2.4 I get #error LONG BIT below emitted.

> What is the fix to build 32-bit shared library python extension on a
> 64-bit linux system?

check OE/packages/python/python-gst/python-path.patch and 
python-gst_0.10.7.bb recipe

Both add --with-python-includes param to configure script with location of 
proper 32bit headers.

-- 
JID: hrw-jabber.org
OpenEmbedded developer/consultant

               We're bad people and we do bad things [Pink]





From mwester at dls.net  Sat May 26 07:53:40 2007
From: mwester at dls.net (Mike (mwester))
Date: Sat, 26 May 2007 02:53:40 -0500
Subject: [oe] PREFERRED_PROVIDER syntax is eluding me...
Message-ID: <038201c79f6a$f9859720$6e01a8c0@twilight>

I'm missing something simple, I expect.  But try as I might, I cannot figure
this out.

Bitbake 1.8.3, building unslung-image (worked fine on 1.6): Bitbake says:
[snip]
NOTE: multiple providers are available for runtime libc6-unslung (glibc,
glibc-initial);
NOTE: consider defining a PREFERRED_PROVIDER entry to match runtime
libc6-unslung
[snip]

This is a problem, because with bitbake 1.8, without a preferred provider
specified, it seems to try to build both.  But only glibc builds;
glibc-initial fails (and the build loops forever).   This is easily fixed by
adding the following line to the local.conf file:

PREFERRED_PROVIDER_libc6-unslung = "glibc"

Except that it doesn't do a blasted thing.  Neither does this line:

PREFERRED_PROVIDERS += " libc6-unslung:glibc"

Thinking that perhaps the "-unslung" was implied since the machine is
"unslung", I tried:

PREFERRED_PROVIDERS += " libc6:glibc"

Still no change.  Being persistent, I tried every variant of the above that
I could think of, to no avail.  It seems that bitbake is not understanding
or processing the info provided.  The -D flag offers no further hints,
either.

For background, back in the glibc bitbake recipes, glibc-initial.bb does a
"require" of glibc.bb (hence the multiple providers).  Near the tail-end of
glibc.bb we find:

PACKAGES_unslung = "libc6-unslung"
RDEPENDS_libc6-unslung = "nslu2-linksys-libs"
RPROVIDES_libc6-unslung = "libc6"
FILES_libc6-unslung = "/lib/librt*"

Figuring that perhaps the problem is that nothing actually "PROVIDES" libc6,
and that maybe bitbake needs to see the build-time dependency in order to
handle the run-time dependency PREFERRED_PROVIDER stuff, I even added
PROVIDES_libc6-unslung = "libc6"
to the glibc.bb recipe, and went back through the list of
PREFERRED_PROVIDERS in the local.conf file.  No luck.  No difference.

I finally hacked the glibc bitbake recipes so that glibc-initial doesn't
"RPROVIDE" libc6 anymore.  Success - bitbake is happy.  But I'm not.  That
doesn't seem like the correct way to resolve the multiple providers issue,
and I expect that commiting such a change would (rightfully) anger many
folks.

If some kind soul could point me to the document or another recipe that
provides the correct syntax for handling this, or provide a pointer to
whatever it is that I'm missing, I'd be most grateful.

Thanks!

Mike (mwester)







From eric.nelson at boundarydevices.com  Sun May 27 14:01:16 2007
From: eric.nelson at boundarydevices.com (Eric Nelson)
Date: Sun, 27 May 2007 07:01:16 -0700
Subject: [oe] preferred-xorg-versions-X11R7.1.inc broken?
Message-ID: <46598F2C.5010707@boundarydevices.com>

Trying to build gpe-image using distro/generic.conf, I'm
getting an error configuring xinerama.

 From the log file
    tmp/work/armv5te-linux/libxinerama-1_1.0.2-r0/temp/log.do_configure.9791

I'm seeing an error of:
    configure.ac:32: error: must install xorg-macros 1.1 or later
    configure.ac:32: the top level

It appears that preferred-xorg-versions-X11R7.1.inc doesn't
specify a xinerama version so it uses the newer one but does
specify a version of util-macros (1.0.2).




From openembedded at hrw.one.pl  Sun May 27 14:30:16 2007
From: openembedded at hrw.one.pl (Marcin Juszkiewicz)
Date: Sun, 27 May 2007 16:30:16 +0200
Subject: [oe] RFC: Rename MACHINE_TASK_PROVIDER to DEFAULT_TASK_PROVIDER
In-Reply-To: <4636F787.8030902@whitby.id.au>
References: <4636F787.8030902@whitby.id.au>
Message-ID: <200705271630.18199.openembedded@hrw.one.pl>

Dnia wtorek, 1 maja 2007, Rod Whitby napisa?:

> The proposal is to replace MACHINE_TASK_PROVIDER with
> DEFAULT_TASK_PROVIDER throughout OE, and encourage all image-foo.bb
> maintainers to base their image on DEFAULT_TASK_PROVIDER (which can be
> set to task-boot, or task-base, or perhaps some other distro-specific
> single task-foo value), plus other image-specific stuff.

DEFAULT_TASK_PROVIDER is good idea for me. I would like to merge it with 
my proposal change to task-base (adding wifi/bt for pcmcia/usbhost/pci 
devices) in a way that we will have:

- task-boot
- task-base
- task-base-extended (wifi/bt added for pcmcia/usbhost/pci machines)

This way we will be able to create images with wifi/bt support for PDA 
with pcmcia but no internal wifi/bt by using task-base-extended as 
DEFAULT_TASK_PROVIDER (set in distro config) and devices with smaller 
amount of space for rootfs will get task-base so users will be free to 
install extra stuff.

What do you think?

-- 
JID: hrw-jabber.org
OpenEmbedded developer/consultant

               Life's not fair. But the root password helps.





From openembedded at hrw.one.pl  Sun May 27 14:38:03 2007
From: openembedded at hrw.one.pl (Marcin Juszkiewicz)
Date: Sun, 27 May 2007 16:38:03 +0200
Subject: [oe] RFC: MACHINE_ namespace
Message-ID: <200705271638.03886.openembedded@hrw.one.pl>


During usage of progear device (now packed due to lack of space) I found 
a problems related to how we use machine configs and X11.

1. We have "alsa" as one of machine features but no way to control kernel 
modules for it - all are added into machine config as 
MACHINE_EXTRA_RRECOMMENDS. Same goes to other features.

2. Progear device use X.org instead of KDrive so I had to create own 
images for it because by default we do not have a way to tell which X 
drivers need to be present in images.


Proposed solution is adding MACHINE_ namespaces:

MACHINE_KERNEL_ALSA   = "kernel-module-snd-ali5451"
MACHINE_KERNEL_PCMCIA = "kernel-module-yenta-socket"

And other MACHINE_KERNEL_feature to control stuff used in task-base.

MACHINE_X11_SERVER  = "xserver-xorg"
MACHINE_X11_DRIVERS = "xf86-video-siliconmotion xf86-input-mutouch"

MACHINE_X11_SERVER will replace XSERVER used now, MACHINE_X11_DRIVERS will 
allow to add needed drivers to X11 images for device without creating 
custom ones.

What do you think about this proposal?

-- 
JID: hrw-jabber.org
OpenEmbedded developer/consultant

                 You can logoff, but you can never leave.
                 		-- Nina Liedtke, "CyberJoly Drim"





From koen at dominion.kabel.utwente.nl  Sun May 27 15:39:39 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Sun, 27 May 2007 17:39:39 +0200
Subject: [oe] RFC: MACHINE_ namespace
In-Reply-To: <200705271638.03886.openembedded@hrw.one.pl>
References: <200705271638.03886.openembedded@hrw.one.pl>
Message-ID: <4659A63B.9080901@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Marcin Juszkiewicz schreef:
> During usage of progear device (now packed due to lack of space) I found 
> a problems related to how we use machine configs and X11.
> 
> 1. We have "alsa" as one of machine features but no way to control kernel 
> modules for it - all are added into machine config as 
> MACHINE_EXTRA_RRECOMMENDS. Same goes to other features.
> 
> 2. Progear device use X.org instead of KDrive so I had to create own 
> images for it because by default we do not have a way to tell which X 
> drivers need to be present in images.
> 
> 
> Proposed solution is adding MACHINE_ namespaces:
> 
> MACHINE_KERNEL_ALSA   = "kernel-module-snd-ali5451"
> MACHINE_KERNEL_PCMCIA = "kernel-module-yenta-socket"
> 
> And other MACHINE_KERNEL_feature to control stuff used in task-base.
> 
> MACHINE_X11_SERVER  = "xserver-xorg"
> MACHINE_X11_DRIVERS = "xf86-video-siliconmotion xf86-input-mutouch"
> 
> MACHINE_X11_SERVER will replace XSERVER used now, MACHINE_X11_DRIVERS will 
> allow to add needed drivers to X11 images for device without creating 
> custom ones.
> 
> What do you think about this proposal?

Sounds pretty good, do you have a patch for it?

regards,

Koen


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGWaY7MkyGM64RGpERAo7vAJ9XGOvAsqKq4cLXv1nhCIH0JCts9ACfVAMr
gb542366W8K6bgr2tOxroV8=
=iSVA
-----END PGP SIGNATURE-----



From pmiscml at gmail.com  Sun May 27 19:28:20 2007
From: pmiscml at gmail.com (Paul Sokolovsky)
Date: Sun, 27 May 2007 22:28:20 +0300
Subject: [oe] RFC: MACHINE_ namespace
In-Reply-To: <200705271638.03886.openembedded@hrw.one.pl>
References: <200705271638.03886.openembedded@hrw.one.pl>
Message-ID: <277782266.20070527222820@gmail.com>

Hello Marcin,

Sunday, May 27, 2007, 5:38:03 PM, you wrote:

> During usage of progear device (now packed due to lack of space) I found
> a problems related to how we use machine configs and X11.

> 1. We have "alsa" as one of machine features but no way to control kernel
> modules for it - all are added into machine config as 
> MACHINE_EXTRA_RRECOMMENDS. Same goes to other features.

> 2. Progear device use X.org instead of KDrive so I had to create own 
> images for it because by default we do not have a way to tell which X 
> drivers need to be present in images.


> Proposed solution is adding MACHINE_ namespaces:

> MACHINE_KERNEL_ALSA   = "kernel-module-snd-ali5451"
> MACHINE_KERNEL_PCMCIA = "kernel-module-yenta-socket"

        This sounds good, especially if we anticipate from the start
that there may be several modules there. And generally, we need to add
more modules into task-base subtasks, targetting at aim when machine
configs will truly contain only machine-specific bits (like hardware
drivers), while other modules will be in task-base.

[]

-- 
Best regards,
 Paul                            mailto:pmiscml at gmail.com




From rod at whitby.id.au  Sun May 27 22:46:38 2007
From: rod at whitby.id.au (Rod Whitby)
Date: Mon, 28 May 2007 08:16:38 +0930
Subject: [oe] RFC: Rename MACHINE_TASK_PROVIDER to DEFAULT_TASK_PROVIDER
In-Reply-To: <200705271630.18199.openembedded@hrw.one.pl>
References: <4636F787.8030902@whitby.id.au>
	<200705271630.18199.openembedded@hrw.one.pl>
Message-ID: <465A0A4E.7060807@whitby.id.au>

Marcin Juszkiewicz wrote:
> Dnia wtorek, 1 maja 2007, Rod Whitby napisa?:
> 
>> The proposal is to replace MACHINE_TASK_PROVIDER with
>> DEFAULT_TASK_PROVIDER throughout OE, and encourage all image-foo.bb
>> maintainers to base their image on DEFAULT_TASK_PROVIDER (which can be
>> set to task-boot, or task-base, or perhaps some other distro-specific
>> single task-foo value), plus other image-specific stuff.
> 
> DEFAULT_TASK_PROVIDER is good idea for me. I would like to merge it with 
> my proposal change to task-base (adding wifi/bt for pcmcia/usbhost/pci 
> devices) in a way that we will have:
> 
> - task-boot
> - task-base
> - task-base-extended (wifi/bt added for pcmcia/usbhost/pci machines)
> 
> This way we will be able to create images with wifi/bt support for PDA 
> with pcmcia but no internal wifi/bt by using task-base-extended as 
> DEFAULT_TASK_PROVIDER (set in distro config) and devices with smaller 
> amount of space for rootfs will get task-base so users will be free to 
> install extra stuff.
> 
> What do you think?

+1 from me.

Can you add:

PROVIDES = "${PACKAGES}"

to task-base.bb while you are there?  I know it should not be required
(it should happen automatically), but for some reason the automatic
stuff is not working for this file at the moment.  I cannot build an
image based on task-boot instead of task-base without doing the above.

-- Rod



From zecke at selfish.org  Mon May 28 09:33:10 2007
From: zecke at selfish.org (Holger Freyther)
Date: Mon, 28 May 2007 11:33:10 +0200
Subject: [oe] RPATH hacks
Message-ID: <A16C87CA-5E9D-4B3B-B237-3BD3890A7D28@selfish.org>

Hey,

I have just pushed a change to libtool-cross that will disable -rpath  
for all cross compiled packages. This should fix all issues with  
rpath on libtool based packages.

What can break?
	I can imagine if you have a binary you can not statically link,  
can't write a /etc/ld.so.conf and can't set LD_LIBRARY_PATH you might  
have troubles now. In that case please speak up and we can look at a  
solution.

I have not tested the resulting image, so if you end up with  
unbootable images feel free to tear and feather me (I like it).


z.




From koen at dominion.kabel.utwente.nl  Mon May 28 09:39:27 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Mon, 28 May 2007 11:39:27 +0200
Subject: [oe] RPATH hacks
In-Reply-To: <A16C87CA-5E9D-4B3B-B237-3BD3890A7D28@selfish.org>
References: <A16C87CA-5E9D-4B3B-B237-3BD3890A7D28@selfish.org>
Message-ID: <465AA34F.3090905@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Holger Freyther schreef:
> Hey,
> 
> I have just pushed a change to libtool-cross that will disable -rpath  
> for all cross compiled packages. This should fix all issues with  
> rpath on libtool based packages.

yay!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGWqNPMkyGM64RGpERAqaYAJ9cBjpMndY31KXOag3OZvlxRk1BzwCgsTx8
piu2PynRbFMnvIe1mO1yAdo=
=OhBm
-----END PGP SIGNATURE-----



From zecke at selfish.org  Mon May 28 10:21:32 2007
From: zecke at selfish.org (Holger Freyther)
Date: Mon, 28 May 2007 12:21:32 +0200
Subject: [oe] RPATH hacks
In-Reply-To: <A16C87CA-5E9D-4B3B-B237-3BD3890A7D28@selfish.org>
References: <A16C87CA-5E9D-4B3B-B237-3BD3890A7D28@selfish.org>
Message-ID: <476F8CF7-CE6C-4461-A336-15D6E43AF9B9@selfish.org>


Am 28.05.2007 um 11:33 schrieb Holger Freyther:

> I have not tested the resulting image, so if you end up with
> unbootable images feel free to tear and feather me (I like it).

Some people might find tearing to painful and wonder how the feathers  
will stay attached to my body, in this case feel free to tear, tar  
and feather me (or skip the tearing...)

z.

PS: Thank you native speakers...



From papercrane at gmail.com  Mon May 28 20:17:13 2007
From: papercrane at gmail.com (Justin Patrin)
Date: Mon, 28 May 2007 13:17:13 -0700
Subject: [oe] PREFERRED_PROVIDER syntax is eluding me...
In-Reply-To: <038201c79f6a$f9859720$6e01a8c0@twilight>
References: <038201c79f6a$f9859720$6e01a8c0@twilight>
Message-ID: <432beae0705281317t3464bacfr833d7ed6b28f374@mail.gmail.com>

On 5/26/07, Mike (mwester) <mwester at dls.net> wrote:
> I'm missing something simple, I expect.  But try as I might, I cannot figure
> this out.
>
> Bitbake 1.8.3, building unslung-image (worked fine on 1.6): Bitbake says:
> [snip]
> NOTE: multiple providers are available for runtime libc6-unslung (glibc,
> glibc-initial);
> NOTE: consider defining a PREFERRED_PROVIDER entry to match runtime
> libc6-unslung
> [snip]
>
> This is a problem, because with bitbake 1.8, without a preferred provider
> specified, it seems to try to build both.  But only glibc builds;
> glibc-initial fails (and the build loops forever).   This is easily fixed by
> adding the following line to the local.conf file:
>
> PREFERRED_PROVIDER_libc6-unslung = "glibc"
>
> Except that it doesn't do a blasted thing.  Neither does this line:
>
> PREFERRED_PROVIDERS += " libc6-unslung:glibc"
>
> Thinking that perhaps the "-unslung" was implied since the machine is
> "unslung", I tried:
>
> PREFERRED_PROVIDERS += " libc6:glibc"
>
> Still no change.  Being persistent, I tried every variant of the above that
> I could think of, to no avail.  It seems that bitbake is not understanding
> or processing the info provided.  The -D flag offers no further hints,
> either.
>
> For background, back in the glibc bitbake recipes, glibc-initial.bb does a
> "require" of glibc.bb (hence the multiple providers).  Near the tail-end of
> glibc.bb we find:
>
> PACKAGES_unslung = "libc6-unslung"
> RDEPENDS_libc6-unslung = "nslu2-linksys-libs"
> RPROVIDES_libc6-unslung = "libc6"
> FILES_libc6-unslung = "/lib/librt*"
>
> Figuring that perhaps the problem is that nothing actually "PROVIDES" libc6,
> and that maybe bitbake needs to see the build-time dependency in order to
> handle the run-time dependency PREFERRED_PROVIDER stuff, I even added
> PROVIDES_libc6-unslung = "libc6"
> to the glibc.bb recipe, and went back through the list of
> PREFERRED_PROVIDERS in the local.conf file.  No luck.  No difference.
>
> I finally hacked the glibc bitbake recipes so that glibc-initial doesn't
> "RPROVIDE" libc6 anymore.  Success - bitbake is happy.  But I'm not.  That
> doesn't seem like the correct way to resolve the multiple providers issue,
> and I expect that commiting such a change would (rightfully) anger many
> folks.
>
> If some kind soul could point me to the document or another recipe that
> provides the correct syntax for handling this, or provide a pointer to
> whatever it is that I'm missing, I'd be most grateful.
>

So it's RPROVIDES and not PROVIDES? Sounds like the problem may be
that PREFERRED_PROVIDERS is for non-R.... Is there an
RPREFERRED_PROVIDERS perhaps?

It's been a while since you posted, sid you get this resolved in the
meantime? Richard Purdie should have more insight into this.

-- 
Justin Patrin



From rpurdie at rpsys.net  Tue May 29 20:46:32 2007
From: rpurdie at rpsys.net (Richard Purdie)
Date: Tue, 29 May 2007 21:46:32 +0100
Subject: [oe] PREFERRED_PROVIDER syntax is eluding me...
In-Reply-To: <432beae0705281317t3464bacfr833d7ed6b28f374@mail.gmail.com>
References: <038201c79f6a$f9859720$6e01a8c0@twilight>
	<432beae0705281317t3464bacfr833d7ed6b28f374@mail.gmail.com>
Message-ID: <1180471592.5822.81.camel@localhost.localdomain>

On Mon, 2007-05-28 at 13:17 -0700, Justin Patrin wrote:
> On 5/26/07, Mike (mwester) <mwester at dls.net> wrote:
> > I'm missing something simple, I expect.  But try as I might, I cannot figure
> > this out.
> >
> > Bitbake 1.8.3, building unslung-image (worked fine on 1.6): Bitbake says:
> > [snip]
> > NOTE: multiple providers are available for runtime libc6-unslung (glibc,
> > glibc-initial);
> > NOTE: consider defining a PREFERRED_PROVIDER entry to match runtime
> > libc6-unslung
> > [snip]
> >
> > This is a problem, because with bitbake 1.8, without a preferred provider
> > specified, it seems to try to build both.  But only glibc builds;
> > glibc-initial fails (and the build loops forever).   This is easily fixed by
> > adding the following line to the local.conf file:
> >
> > PREFERRED_PROVIDER_libc6-unslung = "glibc"
> >
> > Except that it doesn't do a blasted thing.  Neither does this line:
> >
> > PREFERRED_PROVIDERS += " libc6-unslung:glibc"
> >
> > Thinking that perhaps the "-unslung" was implied since the machine is
> > "unslung", I tried:
> >
> > PREFERRED_PROVIDERS += " libc6:glibc"
> >
> > Still no change.  Being persistent, I tried every variant of the above that
> > I could think of, to no avail.  It seems that bitbake is not understanding
> > or processing the info provided.  The -D flag offers no further hints,
> > either.
> >
> > For background, back in the glibc bitbake recipes, glibc-initial.bb does a
> > "require" of glibc.bb (hence the multiple providers).  Near the tail-end of
> > glibc.bb we find:
> >
> > PACKAGES_unslung = "libc6-unslung"
> > RDEPENDS_libc6-unslung = "nslu2-linksys-libs"
> > RPROVIDES_libc6-unslung = "libc6"
> > FILES_libc6-unslung = "/lib/librt*"
> >
> > Figuring that perhaps the problem is that nothing actually "PROVIDES" libc6,
> > and that maybe bitbake needs to see the build-time dependency in order to
> > handle the run-time dependency PREFERRED_PROVIDER stuff, I even added
> > PROVIDES_libc6-unslung = "libc6"
> > to the glibc.bb recipe, and went back through the list of
> > PREFERRED_PROVIDERS in the local.conf file.  No luck.  No difference.
> >
> > I finally hacked the glibc bitbake recipes so that glibc-initial doesn't
> > "RPROVIDE" libc6 anymore.  Success - bitbake is happy.  But I'm not.  That
> > doesn't seem like the correct way to resolve the multiple providers issue,
> > and I expect that commiting such a change would (rightfully) anger many
> > folks.
> >
> > If some kind soul could point me to the document or another recipe that
> > provides the correct syntax for handling this, or provide a pointer to
> > whatever it is that I'm missing, I'd be most grateful.
> >
> 
> So it's RPROVIDES and not PROVIDES? Sounds like the problem may be
> that PREFERRED_PROVIDERS is for non-R.... Is there an
> RPREFERRED_PROVIDERS perhaps?
> 
> It's been a while since you posted, sid you get this resolved in the
> meantime? Richard Purdie should have more insight into this.

Er, hmm, right. The providers code is still a bit of a mystery to me
too ;-)

What you didn't say is that you did:

PROVIDES_unslung = "virtual/libc virtual/${TARGET_PREFIX}libc-for-gcc libc6-unslung"

so this file no longer provides glibc and therefore anything involving
glibc won't help. At a guess I'd try something like:

PREFERRED_PROVIDER_libc6-unslung = "libc6-unslung"

Of course I have to ask why you're doing this at all? It looks a bit
hatstand and I wonder why PREFERRED_VERSION_glibc = "2.2.5" wasn't
enough? ;-) (not that it shouldn't work)

Cheers,

Richard





From mwester at dls.net  Wed May 30 03:27:41 2007
From: mwester at dls.net (Mike (mwester))
Date: Tue, 29 May 2007 22:27:41 -0500
Subject: [oe] PREFERRED_PROVIDER syntax is eluding me...
References: <038201c79f6a$f9859720$6e01a8c0@twilight>
	<432beae0705281317t3464bacfr833d7ed6b28f374@mail.gmail.com>
	<1180471592.5822.81.camel@localhost.localdomain>
Message-ID: <054801c7a26a$7aec5450$6e01a8c0@twilight>

First, sorry for the late reply.

Richard Purdie writes:
> What you didn't say is that you did:
>
> PROVIDES_unslung = "virtual/libc virtual/${TARGET_PREFIX}libc-for-gcc
libc6-unslung"

Yes, I committed that change/fix over the weekend (see below).  Previously
it read just:
PROVIDES_unslung = "virtual/libc virtual/${TARGET_PREFIX}libc-for-gcc"
(without the final "libc6-unslung" on it).

> so this file no longer provides glibc and therefore anything involving
> glibc won't help. At a guess I'd try something like:
>
> PREFERRED_PROVIDER_libc6-unslung = "libc6-unslung"

I actually used:
PREFERRED_PROVIDER_libc6-unslung = "glibc"
My logic was that there were multiple providers for libc6-unslung (glibc's
bb file and glibc-initial's bb file), and that the value the variable was
set to referred to the bitbake recipe that should be preferred for building
of the object named "libc6-unslung".

I tested with so many combinations that my eyes crossed.  I don't recall if
that combination (the change to PROVIDES_unslung above was ever tested with
PREFERRED_PROVIDER_libc6-unslung="libc6-unslung", or not.  I can test that
if that's a more correct solution.

> Of course I have to ask why you're doing this at all? It looks a bit
> hatstand and I wonder why PREFERRED_VERSION_glibc = "2.2.5" wasn't
> enough? ;-) (not that it shouldn't work)

Hatstand, huh?  :-)  I haven't heard that expression, but I think I get it
:-).  I committed the fix I discovered, not because it was necesarily The
Right Fix(tm), but because it worked and the changes were guaranteed to be
localized to Unslung (i.e. I wouldn't risk messing up anyone else's distro's
with the fix I selected).

As for why it's this way, I can't say.  Unslung is itself a strange
creation - and its been in OE for a long time.  Together that seems to
result in some strange constructs.  I'm striving to keep it building in OE,
in the hopes that there might be a compelling feature or event that would
make a new Unslung release interesting at some point in the future.
However, the likelihood of such an event currently appears to be slim enough
that I'm not sure it's a good idea to do significant rework and retesting on
it, frankly.  So I'm in favor of a small simple fix, even a kludgy one, if
it'll work.

> Cheers,
>
> Richard

Thanks!  If you or anyone else has strong feelings about this, and how it's
been addressed, let me know (preferably with some guidance on what would be
acceptable).

Regards,
Mike (mwester)





From rodrigo.vivi at gmail.com  Wed May 30 22:42:53 2007
From: rodrigo.vivi at gmail.com (Rodrigo Vivi)
Date: Wed, 30 May 2007 19:42:53 -0300
Subject: [oe] strange error: missing depends...
Message-ID: <bdb0025f0705301542s7e64e43cjb5b737e7f1958806@mail.gmail.com>

Hi there,

Some days ago I was using the bitbake1.6 to build my packages and it
was working fine, but someday without any apparently reason it stopped
to work.

Then, after a big looser fight I've decided to change to bitbake1.8
and the problem was apparently solved... I was seeing the packages
being build...
But in the end, for my surprise, I've noticed that a lot of depends
wasn't build!

Since my task file is not under official repository yet I'm sending in
this email.

Does any body have any idea?

Thanks,
vivijim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: task-mamona.bb
Type: application/octet-stream
Size: 1216 bytes
Desc: not available
URL: <http://layers.openembedded.org/pipermail/openembedded-devel/attachments/20070530/f80ae2f5/attachment.obj>

From freyther at gmx.net  Thu May 31 09:22:10 2007
From: freyther at gmx.net (Holger Freyther)
Date: Thu, 31 May 2007 11:22:10 +0200
Subject: [oe] strange error: missing depends...
In-Reply-To: <bdb0025f0705301542s7e64e43cjb5b737e7f1958806@mail.gmail.com>
References: <bdb0025f0705301542s7e64e43cjb5b737e7f1958806@mail.gmail.com>
Message-ID: <3A8255A2-0573-4DE5-AF68-B87A30062F3F@gmx.net>


Am 31.05.2007 um 00:42 schrieb Rodrigo Vivi:

> Hi there,
>
> Some days ago I was using the bitbake1.6 to build my packages and it
> was working fine, but someday without any apparently reason it stopped
> to work.
>
> Does any body have any idea?


Hi,

koen says that the recipe looks "OK" to him. He finds that  
'RDEPENDS_task-mamona-all := "${PACKAGES}"' a bit suspicious.

What version of BitBake do you have, is the graph generated by task- 
mamona (-g option of BitBake) having the DEPENDS/RDEPENDS? What is  
bitbake -vvv saying what it tries to build, do the depends show up at  
all?


kind regards
	z.



From rodrigo.vivi at gmail.com  Thu May 31 20:49:22 2007
From: rodrigo.vivi at gmail.com (Rodrigo Vivi)
Date: Thu, 31 May 2007 17:49:22 -0300
Subject: [oe] strange error: missing depends...
In-Reply-To: <3A8255A2-0573-4DE5-AF68-B87A30062F3F@gmx.net>
References: <bdb0025f0705301542s7e64e43cjb5b737e7f1958806@mail.gmail.com>
	<3A8255A2-0573-4DE5-AF68-B87A30062F3F@gmx.net>
Message-ID: <bdb0025f0705311349x73f2f285ge65c3aaa06a4fa21@mail.gmail.com>

I've just noticed that everything is fine with depends, rdepends and
with the task-mamona itself.

My log shows that do_compile and do_package was called for every
package, but for some reason a few of them like bash do not call the
do_package_deb function..

In the log I have this:
NOTE: package bash-3.2-r1: task do_package: started
NOTE: package bash-3.2-r1: task do_package: completed

But I've introduced some debug messages and I'm pretty sure that the
do_package_deb function was not called to this package.

but I can not figure it out...
Why it is called for some packages and not called for other ones.

Does any body has an idea about it?

Thanks,
vivijim

On 5/31/07, Holger Freyther <freyther at gmx.net> wrote:
>
> Am 31.05.2007 um 00:42 schrieb Rodrigo Vivi:
>
> > Hi there,
> >
> > Some days ago I was using the bitbake1.6 to build my packages and it
> > was working fine, but someday without any apparently reason it stopped
> > to work.
> >
> > Does any body have any idea?
>
>
> Hi,
>
> koen says that the recipe looks "OK" to him. He finds that
> 'RDEPENDS_task-mamona-all := "${PACKAGES}"' a bit suspicious.
>
> What version of BitBake do you have, is the graph generated by task-
> mamona (-g option of BitBake) having the DEPENDS/RDEPENDS? What is
> bitbake -vvv saying what it tries to build, do the depends show up at
> all?
>
>
> kind regards
>         z.
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>



From koen at dominion.kabel.utwente.nl  Thu May 31 21:22:19 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Thu, 31 May 2007 23:22:19 +0200
Subject: [oe] Glibc 2.6 added, please test
Message-ID: <465F3C8B.80200@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Glibc 2.6 has just been added to OE, please test it and report bugs.

TIA,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGXzyLMkyGM64RGpERAk8EAJ9vszt8ghLdUoVvRLarLWNM40TpUgCfToVG
QCCW9dQifUQvV8H8H+5VVR0=
=9U8f
-----END PGP SIGNATURE-----



From repvik at kynisk.com  Tue May  1 01:49:14 2007
From: repvik at kynisk.com (=?utf-8?q?=C3=98yvind_Repvik?=)
Date: Tue, 1 May 2007 03:49:14 +0200
Subject: [oe] [oe-commits] MedHelp 28949335
In-Reply-To: <20070430-35259.9357.qmail@bridges>
References: <20070430-35259.9357.qmail@bridges>
Message-ID: <200705010349.14949.repvik@kynisk.com>

On Tuesday 01 May 2007 01:02:18 Canadian Doctor Addie wrote:
> <STYLE>
> /back/CMA/Tournament/Sherrill/Laura/supporting/xxx/1520/blackberry/live/12/
>treatment/Tam/receipt/Unfortunately/wa
>
[lots of crap]

Why isn't there any filtering on oe-commits? Isn't that list commits-only? 
I see my spamfilter kills most of them, but a few still comes through.
Why not just block all non-commit mails?

Regards,
?yvind Repvik



From papercrane at gmail.com  Tue May  1 02:51:24 2007
From: papercrane at gmail.com (Justin Patrin)
Date: Mon, 30 Apr 2007 19:51:24 -0700
Subject: [oe] [oe-commits] MedHelp 28949335
In-Reply-To: <200705010349.14949.repvik@kynisk.com>
References: <20070430-35259.9357.qmail@bridges>
	<200705010349.14949.repvik@kynisk.com>
Message-ID: <432beae0704301951v2cd237f7w8e0300f5681a65b9@mail.gmail.com>

On 4/30/07, ?yvind Repvik <repvik at kynisk.com> wrote:
> On Tuesday 01 May 2007 01:02:18 Canadian Doctor Addie wrote:
> > <STYLE>
> > /back/CMA/Tournament/Sherrill/Laura/supporting/xxx/1520/blackberry/live/12/
> >treatment/Tam/receipt/Unfortunately/wa
> >
> [lots of crap]
>
> Why isn't there any filtering on oe-commits? Isn't that list commits-only?
> I see my spamfilter kills most of them, but a few still comes through.
> Why not just block all non-commit mails?
>

Sounds good to me.

-- 
Justin Patrin



From xjqian at gmail.com  Tue May  1 05:14:40 2007
From: xjqian at gmail.com (Junqian Gordon Xu)
Date: Tue, 01 May 2007 00:14:40 -0500
Subject: [oe] perl 5.8.8 is ready
In-Reply-To: <20070430080044.GA15877@twibble.org>
References: <20070427105722.GA4340@twibble.org> <46359408.9060800@gmail.com>
	<20070430080044.GA15877@twibble.org>
Message-ID: <4636CCC0.1010109@gmail.com>

Thanks. I fixed the hostperl problem.

Don't know why. Even I commented out the DEFAULT_PREFERENCE = "-1", 
bitbake still try to get perl-5.8.7 compiled first

NOTE: package perl-5.8.8-r8: task do_unpack: completed
NOTE: package perl-5.8.8: completed
NOTE: Running task 285 of 302 (ID: 130, 
/home/OE/org.openembedded.dev/packages/perl/perl_5.8.7.bb, do_fetch)
NOTE: package perl-5.8.7: started
NOTE: package perl-5.8.7-r22: task do_fetch: started

Besides, I noticed another issue:
I had linux-libc-headers-2.6.15.99 compiled (I think it's determined 
Machine and Distro) . But perl-5.8.8 wants linux-libc-headers-2.6.20. 
Will that cause problem?

Thanks
Gordon


Jamie Lenehan wrote:
> On Mon, Apr 30, 2007 at 02:00:24AM -0500, Junqian Gordon Xu wrote:
>   
>> Jamie Lenehan wrote:
>>     
> [...]
>   
>> perl-native-5.8.8 builds fine but with the following error
>>
>> ERROR: QA issue: libgettextsrc.la failed sanity test (reference to 
>> workdir or installed)
>>     
> [...]
>
> These ones aren't related to perl-native at all, so no problems there.
>
> [...]
>   
>> perl-5.8.8 build failed. Detail in the attached log file.
>>     
> [...]
>   
>> | hostperl -I/home/OE/build/tosa_angstrom/tmp/work/armv5te-angstrom-linux-gnueabi/perl-5.8.8-r7/perl-5.8.8/Cross/../fake_config_library -MConfig ../../lib/ExtUtils/xsubpp -noprototypes -typemap ../../lib/ExtUtils/typemap  attrs.xs > attrs.xsc && mv attrs.xsc attrs.c
>> | Perl lib version (v5.8.8) doesn't match executable version (v5.8.7) at /home/OE/build/tosa_angstrom/tmp/work/armv5te-angstrom-linux-gnueabi/perl-5.8.8-r7/perl-5.8.8/Cross/../fake_config_library/Config.pm line 46.
>>     
>
> This error is saying that "hostperl" is perl 5.8.7 but that it needs
> to be perl 5.8.8. Can you check what your hostperl, which would be:
>
>   /home/OE/build/tosa_angstrom/tmp/staging/i686-linux/bin/hostperl
>
> is pointing at? It should be 5.8.8 but this error makes it sound like
> it's pointing at 5.8.7:
>
>   %~> ls -l tmp/staging/x86_64-linux/bin/hostperl 
>   lrwxrwxrwx 1 lenehan lenehan 82 2007-04-30 13:28 tmp/staging/x86_64-linux/bin/hostperl -> /home/lenehan/devel/oe/build/titan-glibc-25/tmp/staging/x86_64-linux/bin/perl5.8.8*
>
> Thanks.
>
>   




From rod at whitby.id.au  Tue May  1 08:17:11 2007
From: rod at whitby.id.au (Rod Whitby)
Date: Tue, 01 May 2007 17:47:11 +0930
Subject: [oe] RFC: Rename MACHINE_TASK_PROVIDER to DEFAULT_TASK_PROVIDER
Message-ID: <4636F787.8030902@whitby.id.au>

> <rwhitby> so in my mokoslug distro, I set MACHINE_TASK_PROVIDER to task-boot or task-base, depending on flash size.
> <rwhitby> what is MACHINE_TASK_PROVIDER really meant to be used for?
> <koen> to distinguish between task-bootstrap and task-base
> <rwhitby> does task-bootstrap still exist?
> <koen> rwhitby: I hope not
> <rwhitby> koen: so MACHINE_TASK_PROVIDER has no current reason for existence then?
> <rwhitby> (and no definition of what it should be used for if it did have a current reason for existence)
> <koen> rwhitby: not that I know off, but your task-boot suggestion would make sense
> <rwhitby> koen: So it really should now be called something like BOOTSTRAP_IMAGE_FOUNDATION_TASK or something?
> <rwhitby> (since it doesn't have anything to do with MACHINEs)
> <koen> nor with BOOTSTRAP
> <koen> something like DEFAULT_TASK_PROVIDER?
> <rwhitby> yep, DEFAULT_TASK_PROVIDER floats my boat.
> <koen> do you want to write an RFC for that?

The proposal is to replace MACHINE_TASK_PROVIDER with
DEFAULT_TASK_PROVIDER throughout OE, and encourage all image-foo.bb
maintainers to base their image on DEFAULT_TASK_PROVIDER (which can be
set to task-boot, or task-base, or perhaps some other distro-specific
single task-foo value), plus other image-specific stuff.

Comments?  Objections?

BTW, task-bootstrap existence is as follows:

> ./conf/distro/generic.conf:PREFERRED_PROVIDER_task-bootstrap = "task-bootstrap"
> ./conf/distro/include/oplinux.inc:PREFERRED_PROVIDER_task-bootstrap = "task-base"
> ./conf/distro/angstrom-2007.1.conf:PREFERRED_PROVIDER_task-bootstrap = "task-bootstrap"
> ./conf/distro/jlime-donkey.conf:PREFERRED_PROVIDER_task-bootstrap = "task-bootstrap"
> ./conf/distro/openprotium.conf:#PREFERRED_PROVIDER_task-bootstrap = "task-bootstrap"
> ./conf/machine/gumstix.conf:PREFERRED_VERSION_task-bootstrap = "1.0unionroot"
> ./packages/obsolete/tasks/task-bootstrap-unionroot.bb:PROVIDES = "task-bootstrap"
> ./packages/obsolete/tasks/task-bootstrap-unionroot.bb:RPROVIDES = "task-bootstrap"
> ./packages/obsolete/tasks/task-bootstrap-unionroot.bb:require task-bootstrap.inc
> ./packages/obsolete/tasks/task-bootstrap.bb:require task-bootstrap.inc
> ./packages/images/jlime-opie.bb:DEPENDS = "task-bootstrap task-opie"
> ./packages/images/jlime-opie.bb:INSTALL_PACKAGES = "task-bootstrap task-opie-base task-opie-base-applets \
> ./removal.txt:Package Name:   task-bootstrap*

-- Rod



From no2spam at nospam.arcornews.de  Tue May  1 18:04:10 2007
From: no2spam at nospam.arcornews.de (Rolf Leggewie)
Date: Tue, 01 May 2007 20:04:10 +0200
Subject: [oe] RFC: RW access for polyonymous
Message-ID: <f17ves$luc$1@sea.gmane.org>

Hi,

with the amount (and speed!) of patches being provided by Michael 
'polyonymous' Krelin I think it makes sense to give him RW access to OE. 
  His bugs are at http://tinyurl.com/2llfhw

Take a look, comment and decide.

Regards

Rolf




From papercrane at gmail.com  Tue May  1 18:13:20 2007
From: papercrane at gmail.com (Justin Patrin)
Date: Tue, 1 May 2007 11:13:20 -0700
Subject: [oe] [oe-commits] org.oe.dev xtscal: attempt to fix
	miscalibrations
In-Reply-To: <46362F71.7080604@dominion.kabel.utwente.nl>
References: <E1HgoSJ-0008AG-St@linuxtogo.org>
	<462FBE16.9070805@dominion.kabel.utwente.nl>
	<46362F71.7080604@dominion.kabel.utwente.nl>
Message-ID: <432beae0705011113v61831859x7978062963a48b8@mail.gmail.com>

On 4/30/07, Koen Kooi <koen at dominion.kabel.utwente.nl> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Koen Kooi schreef:
> > koen commit schreef:
> >> xtscal: attempt to fix miscalibrations
> >
> > Could people with one of:
> > "HP IPAQ H3600" | "HP IPAQ H3700" | "HP IPAQ H3900" | "HTC Universal" | *COLLIE | *POODLE
> > | *SPITZ | *AKITA | *BORZOI
> >
> > check if calibration isn't 90 degrees of anymore?
> >
> > If not, we most likely need to revert revision d18552e5056a026d8ed8959e135b2fa05c3e1b6b
>
> Hello?

I was just about to test this when my boot into a new image failed
with a missing libgcc. This RPATH issue needs to be fixed ASAP.

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (Darwin)
>
> iD8DBQFGNi9xMkyGM64RGpERAnbdAJ0WirRd/ONKWpIDHDQcO+6EddMx6gCgmoiw
> bF5efxVbVYf2tUEhwMiCMHc=
> =j3Su
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>


-- 
Justin Patrin



From papercrane at gmail.com  Tue May  1 18:13:20 2007
From: papercrane at gmail.com (Justin Patrin)
Date: Tue, 1 May 2007 11:13:20 -0700
Subject: [oe] [oe-commits] org.oe.dev xtscal: attempt to fix
	miscalibrations
In-Reply-To: <46362F71.7080604@dominion.kabel.utwente.nl>
References: <E1HgoSJ-0008AG-St@linuxtogo.org>
	<462FBE16.9070805@dominion.kabel.utwente.nl>
	<46362F71.7080604@dominion.kabel.utwente.nl>
Message-ID: <432beae0705011113v61831859x7978062963a48b8@mail.gmail.com>

On 4/30/07, Koen Kooi <koen at dominion.kabel.utwente.nl> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Koen Kooi schreef:
> > koen commit schreef:
> >> xtscal: attempt to fix miscalibrations
> >
> > Could people with one of:
> > "HP IPAQ H3600" | "HP IPAQ H3700" | "HP IPAQ H3900" | "HTC Universal" | *COLLIE | *POODLE
> > | *SPITZ | *AKITA | *BORZOI
> >
> > check if calibration isn't 90 degrees of anymore?
> >
> > If not, we most likely need to revert revision d18552e5056a026d8ed8959e135b2fa05c3e1b6b
>
> Hello?

I was just about to test this when my boot into a new image failed
with a missing libgcc. This RPATH issue needs to be fixed ASAP.

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (Darwin)
>
> iD8DBQFGNi9xMkyGM64RGpERAnbdAJ0WirRd/ONKWpIDHDQcO+6EddMx6gCgmoiw
> bF5efxVbVYf2tUEhwMiCMHc=
> =j3Su
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>


-- 
Justin Patrin



From oe at hentges.net  Tue May  1 18:20:26 2007
From: oe at hentges.net (Matthias Hentges)
Date: Tue, 01 May 2007 20:20:26 +0200
Subject: [oe] RFC: RW access for polyonymous
In-Reply-To: <f17ves$luc$1@sea.gmane.org>
References: <f17ves$luc$1@sea.gmane.org>
Message-ID: <1178043626.23506.8.camel@localhost.localdomain>

Am Dienstag, den 01.05.2007, 20:04 +0200 schrieb Rolf Leggewie:
> Hi,
> 
> with the amount (and speed!) of patches being provided by Michael 
> 'polyonymous' Krelin I think it makes sense to give him RW access to OE. 
>   His bugs are at http://tinyurl.com/2llfhw

I agree, it's about time ;)
-- 
Matthias 'CoreDump' Hentges 
Cologne / Germany

Webmaster of Hentges.net & Embedded Linux Developer
GPG ->  gpg --keyserver gpg-keyserver.de --recv-keys 0xAF3030D9

My OS: Debian SID: Geek by Nature, Linux by Choice


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
URL: <http://lists.openembedded.org/pipermail/openembedded-devel/attachments/20070501/be3360eb/attachment-0001.sig>

From skoroneos at digital-opsis.com  Tue May  1 18:32:01 2007
From: skoroneos at digital-opsis.com (Stelios Koroneos)
Date: Tue, 1 May 2007 21:32:01 +0300
Subject: [oe] squasfs jffs2 default image settings
In-Reply-To: <4636F787.8030902@whitby.id.au>
Message-ID: <HOECLKEKOHLAMMGDLLBHKEFLKOAA.skoroneos@digital-opsis.com>

After a day of "head scratching" i realized the the reason an image i was
building, failed to load on a powerpc target was that the default settings
for squashfs squashfs-lzma and jffs2 were set to little endian architecture

//snip from  bitbake.conf

EXTRA_IMAGECMD_jffs2 = "--pad --little-endian --eraseblock=0x40000"
EXTRA_IMAGECMD_squashfs = "-le -b 16384"
EXTRA_IMAGECMD_squashfs-lzma = "-le -b 16384"

These look like they were set for a specific machine (maybe i am wrong), but
shouldn't the default settings be at least architecture neutral ?
(Even the block sizes shouldn't be defined there as a machine might be
better suited by another size)

Any objections to have EXTRA_IMAGECMD for these types of images default to
no specific settings  ?

Stelios S. Koroneos

Digital OPSiS - Embedded Inteligence
http://www.digital-opsis.com


> -----Original Message-----
> From: openembedded-devel-bounces at openembedded.org
> [mailto:openembedded-devel-bounces at openembedded.org]On Behalf Of
> Rod Whitby
> Sent: Tuesday, May 01, 2007 11:17 AM
> To: openembedded-devel at openembedded.org
> Subject: [oe] RFC: Rename MACHINE_TASK_PROVIDER to DEFAULT_TASK_PROVIDER
>
>
> > <rwhitby> so in my mokoslug distro, I set MACHINE_TASK_PROVIDER
> to task-boot or task-base, depending on flash size.
> > <rwhitby> what is MACHINE_TASK_PROVIDER really meant to be used for?
> > <koen> to distinguish between task-bootstrap and task-base
> > <rwhitby> does task-bootstrap still exist?
> > <koen> rwhitby: I hope not
> > <rwhitby> koen: so MACHINE_TASK_PROVIDER has no current reason
> for existence then?
> > <rwhitby> (and no definition of what it should be used for if
> it did have a current reason for existence)
> > <koen> rwhitby: not that I know off, but your task-boot
> suggestion would make sense
> > <rwhitby> koen: So it really should now be called something
> like BOOTSTRAP_IMAGE_FOUNDATION_TASK or something?
> > <rwhitby> (since it doesn't have anything to do with MACHINEs)
> > <koen> nor with BOOTSTRAP
> > <koen> something like DEFAULT_TASK_PROVIDER?
> > <rwhitby> yep, DEFAULT_TASK_PROVIDER floats my boat.
> > <koen> do you want to write an RFC for that?
>
> The proposal is to replace MACHINE_TASK_PROVIDER with
> DEFAULT_TASK_PROVIDER throughout OE, and encourage all image-foo.bb
> maintainers to base their image on DEFAULT_TASK_PROVIDER (which can be
> set to task-boot, or task-base, or perhaps some other distro-specific
> single task-foo value), plus other image-specific stuff.
>
> Comments?  Objections?
>
> BTW, task-bootstrap existence is as follows:
>
> > ./conf/distro/generic.conf:PREFERRED_PROVIDER_task-bootstrap =
> "task-bootstrap"
> >
> ./conf/distro/include/oplinux.inc:PREFERRED_PROVIDER_task-bootstra
> p = "task-base"
> >
> ./conf/distro/angstrom-2007.1.conf:PREFERRED_PROVIDER_task-bootstr
> ap = "task-bootstrap"
> >
> ./conf/distro/jlime-donkey.conf:PREFERRED_PROVIDER_task-bootstrap
> = "task-bootstrap"
> >
> ./conf/distro/openprotium.conf:#PREFERRED_PROVIDER_task-bootstrap
> = "task-bootstrap"
> > ./conf/machine/gumstix.conf:PREFERRED_VERSION_task-bootstrap =
> "1.0unionroot"
> > ./packages/obsolete/tasks/task-bootstrap-unionroot.bb:PROVIDES
> = "task-bootstrap"
> > ./packages/obsolete/tasks/task-bootstrap-unionroot.bb:RPROVIDES
> = "task-bootstrap"
> > ./packages/obsolete/tasks/task-bootstrap-unionroot.bb:require
> task-bootstrap.inc
> > ./packages/obsolete/tasks/task-bootstrap.bb:require task-bootstrap.inc
> > ./packages/images/jlime-opie.bb:DEPENDS = "task-bootstrap task-opie"
> > ./packages/images/jlime-opie.bb:INSTALL_PACKAGES =
> "task-bootstrap task-opie-base task-opie-base-applets \
> > ./removal.txt:Package Name:   task-bootstrap*
>
> -- Rod
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>





From no2spam at nospam.arcornews.de  Tue May  1 19:23:42 2007
From: no2spam at nospam.arcornews.de (Rolf Leggewie)
Date: Tue, 01 May 2007 21:23:42 +0200
Subject: [oe] [oe-commits] org.oe.dev xtscal: attempt to fix
	miscalibrations
In-Reply-To: <432beae0705011113v61831859x7978062963a48b8@mail.gmail.com>
References: <E1HgoSJ-0008AG-St@linuxtogo.org>	<462FBE16.9070805@dominion.kabel.utwente.nl>	<46362F71.7080604@dominion.kabel.utwente.nl>
	<432beae0705011113v61831859x7978062963a48b8@mail.gmail.com>
Message-ID: <f1843v$doc$1@sea.gmane.org>

Justin Patrin wrote:
> I was just about to test this when my boot into a new image failed
> with a missing libgcc. This RPATH issue needs to be fixed ASAP.

OK, you got the job ;-)

Serious now, from what I read in bug 2093 I doubt the miscalibration 
issue is fixed yet.




From koen at dominion.kabel.utwente.nl  Tue May  1 19:34:33 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Tue, 01 May 2007 21:34:33 +0200
Subject: [oe] [oe-commits] org.oe.dev xtscal: attempt to
	fix	miscalibrations
In-Reply-To: <f1843v$doc$1@sea.gmane.org>
References: <E1HgoSJ-0008AG-St@linuxtogo.org>	<462FBE16.9070805@dominion.kabel.utwente.nl>	<46362F71.7080604@dominion.kabel.utwente.nl>	<432beae0705011113v61831859x7978062963a48b8@mail.gmail.com>
	<f1843v$doc$1@sea.gmane.org>
Message-ID: <46379649.7040404@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Rolf Leggewie schreef:
> Justin Patrin wrote:
>> I was just about to test this when my boot into a new image failed
>> with a missing libgcc. This RPATH issue needs to be fixed ASAP.
> 
> OK, you got the job ;-)
> 
> Serious now, from what I read in bug 2093 I doubt the miscalibration 
> issue is fixed yet.

The tr was reinstated and the names uppercased, so what else is missing?

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGN5ZJMkyGM64RGpERApJsAJ9c26K2uBv6n8AwMWtgpVZpMJKeswCZAdLG
p7lqRvR2Nj6GBmPu11/q/ik=
=YVAl
-----END PGP SIGNATURE-----



From pmiscml at gmail.com  Tue May  1 20:42:53 2007
From: pmiscml at gmail.com (Paul Sokolovsky)
Date: Tue, 1 May 2007 23:42:53 +0300
Subject: [oe] RFC: RW access for polyonymous
In-Reply-To: <f17ves$luc$1@sea.gmane.org>
References: <f17ves$luc$1@sea.gmane.org>
Message-ID: <361637820.20070501234253@gmail.com>

Hello Rolf,

Tuesday, May 1, 2007, 9:04:10 PM, you wrote:

> Hi,

> with the amount (and speed!) of patches being provided by Michael 
> 'polyonymous' Krelin I think it makes sense to give him RW access to OE.
>   His bugs are at http://tinyurl.com/2llfhw

> Take a look, comment and decide.

        I support this, and would be happy to peer-review Michael's
commits.

> Regards

> Rolf


-- 
Best regards,
 Paul                            mailto:pmiscml at gmail.com




From no2spam at nospam.arcornews.de  Tue May  1 22:15:11 2007
From: no2spam at nospam.arcornews.de (Rolf Leggewie)
Date: Wed, 02 May 2007 00:15:11 +0200
Subject: [oe] [oe-commits] org.oe.dev xtscal: attempt to fix
	miscalibrations
In-Reply-To: <46379649.7040404@dominion.kabel.utwente.nl>
References: <E1HgoSJ-0008AG-St@linuxtogo.org>	<462FBE16.9070805@dominion.kabel.utwente.nl>	<46362F71.7080604@dominion.kabel.utwente.nl>	<432beae0705011113v61831859x7978062963a48b8@mail.gmail.com>	<f1843v$doc$1@sea.gmane.org>
	<46379649.7040404@dominion.kabel.utwente.nl>
Message-ID: <f18e5h$53j$1@sea.gmane.org>

Koen Kooi wrote:
>> Serious now, from what I read in bug 2093 I doubt the miscalibration 
>> issue is fixed yet.
> 
> The tr was reinstated and the names uppercased, so what else is missing?

polynonymous wrote that he needed mixed case.  But I have no first hand 
knowledge of how to fix this, yet.




From rod at whitby.id.au  Wed May  2 00:05:10 2007
From: rod at whitby.id.au (Rod Whitby)
Date: Wed, 02 May 2007 09:35:10 +0930
Subject: [oe] squasfs jffs2 default image settings
In-Reply-To: <HOECLKEKOHLAMMGDLLBHKEFLKOAA.skoroneos@digital-opsis.com>
References: <HOECLKEKOHLAMMGDLLBHKEFLKOAA.skoroneos@digital-opsis.com>
Message-ID: <4637D5B6.4060305@whitby.id.au>

Stelios Koroneos wrote:
> After a day of "head scratching" i realized the the reason an image i was
> building, failed to load on a powerpc target was that the default settings
> for squashfs squashfs-lzma and jffs2 were set to little endian architecture
> 
> //snip from  bitbake.conf
> 
> EXTRA_IMAGECMD_jffs2 = "--pad --little-endian --eraseblock=0x40000"
> EXTRA_IMAGECMD_squashfs = "-le -b 16384"
> EXTRA_IMAGECMD_squashfs-lzma = "-le -b 16384"
> 
> These look like they were set for a specific machine (maybe i am wrong), but
> shouldn't the default settings be at least architecture neutral ?
> (Even the block sizes shouldn't be defined there as a machine might be
> better suited by another size)
> 
> Any objections to have EXTRA_IMAGECMD for these types of images default to
> no specific settings  ?

Fine with me.  I think the nslu2 and ixp4xx are the few dual-endian
machines in OE, and both of them are already set up to set the
endianness, padding and block size on those commands explicitly.

-- Rod



From lenehan at twibble.org  Wed May  2 00:36:41 2007
From: lenehan at twibble.org (Jamie Lenehan)
Date: Wed, 2 May 2007 10:36:41 +1000
Subject: [oe] perl 5.8.8 is ready
In-Reply-To: <4636CCC0.1010109@gmail.com>
References: <20070427105722.GA4340@twibble.org> <46359408.9060800@gmail.com>
	<20070430080044.GA15877@twibble.org> <4636CCC0.1010109@gmail.com>
Message-ID: <20070502003641.GA5189@twibble.org>

On Tue, May 01, 2007 at 12:14:40AM -0500, Junqian Gordon Xu wrote:
> Thanks. I fixed the hostperl problem.
> 
> Don't know why. Even I commented out the DEFAULT_PREFERENCE = "-1", 
> bitbake still try to get perl-5.8.7 compiled first
> 
> NOTE: package perl-5.8.8-r8: task do_unpack: completed
> NOTE: package perl-5.8.8: completed
> NOTE: Running task 285 of 302 (ID: 130, 
> /home/OE/org.openembedded.dev/packages/perl/perl_5.8.7.bb, do_fetch)
> NOTE: package perl-5.8.7: started
> NOTE: package perl-5.8.7-r22: task do_fetch: started

This turns out to be an error on my part in perl 5.8.8 - I didn't
tell bitbake that perl 5.8.8 was providing all the perl modules. So
when something needed perl-modules (because of a DEPEND or RDEPEND)
it found that perl 5.8.8 provided them while 5.8.8 didn't.

If you had perl 5.8.7 already compiled and lying around you didn't
notice this issue. Since I've been building and testing changes for
both version I had 5.8.7 and 5.8.8 always compiled.

Anyway, I just checked in a fix for this so it should be ok now.

> Besides, I noticed another issue:
> I had linux-libc-headers-2.6.15.99 compiled (I think it's determined 
> Machine and Distro) . But perl-5.8.8 wants linux-libc-headers-2.6.20. 
> Will that cause problem?

Perl shouldn't care about linux-libc-headers, I use 2.6.15.99 here at
the moment.

Thanks.

-- 
 Jamie Lenehan <lenehan at twibble.org>



From xjqian at gmail.com  Wed May  2 04:05:58 2007
From: xjqian at gmail.com (Junqian Gordon Xu)
Date: Tue, 01 May 2007 23:05:58 -0500
Subject: [oe] perl 5.8.8 is ready
In-Reply-To: <20070502003641.GA5189@twibble.org>
References: <20070427105722.GA4340@twibble.org> <46359408.9060800@gmail.com>
	<20070430080044.GA15877@twibble.org> <4636CCC0.1010109@gmail.com>
	<20070502003641.GA5189@twibble.org>
Message-ID: <46380E26.6070303@gmail.com>

Jamie Lenehan wrote:
> On Tue, May 01, 2007 at 12:14:40AM -0500, Junqian Gordon Xu wrote:
>   
> This turns out to be an error on my part in perl 5.8.8 - I didn't
> tell bitbake that perl 5.8.8 was providing all the perl modules. So
> when something needed perl-modules (because of a DEPEND or RDEPEND)
> it found that perl 5.8.8 provided them while 5.8.8 didn't.
>
> If you had perl 5.8.7 already compiled and lying around you didn't
> notice this issue. Since I've been building and testing changes for
> both version I had 5.8.7 and 5.8.8 always compiled.
>
> Anyway, I just checked in a fix for this so it should be ok now.
>
>   
I can confirm with the latest mtn pull, perl-5.8.8 builds fine for me 
here except for some warning signs:

NOTE: package perl-5.8.8: started
NOTE: package perl-5.8.8-r10: task do_package: started
NOTE: perl-lib contains dangling symlink to /usr/lib/perl/5.8.8
NOTE: perl-lib contains dangling symlink to /usr/share/perl/5.8.8
NOTE: Couldn't find shared library provider for libgcc_s.so.1
NOTE: Couldn't find shared library provider for libgcc_s.so.1

>> Besides, I noticed another issue:
>> I had linux-libc-headers-2.6.15.99 compiled (I think it's determined 
>> Machine and Distro) . But perl-5.8.8 wants linux-libc-headers-2.6.20. 
>> Will that cause problem?
>>     
>
> Perl shouldn't care about linux-libc-headers, I use 2.6.15.99 here at
> the moment.
However, this issue is still outstanding. I'm trying to understand where 
the 2.6.20 dependency is coming from. Is this a bitbake issue?

bitbake perl:

OE Build Configuration:
BB_VERSION     = "1.8.3"
OE_REVISION    = "3ea77972dcf422ed70f1a083c412f43ab519f474"
TARGET_ARCH    = "arm"
TARGET_OS      = "linux-gnueabi"
MACHINE        = "tosa"
DISTRO         = "angstrom"
DISTRO_VERSION = "test-20070502"
TARGET_FPU     = "soft"

NOTE: Resolving missing task queue dependencies
NOTE: preferred version 2.5 of glibc not available (for item 
virtual/arm-angstrom-linux-gnueabi-libc-for-gcc)
NOTE: Preparing Runqueue
NOTE: Executing runqueue
NOTE: Running task 115 of 294 (ID: 131, 
/home/OE/org.openembedded.dev/packages/linux-libc-headers/linux-libc-headers_2.6.20.bb, 
do_fetch)
NOTE: package linux-libc-headers-2.6.20: started



From no2spam at nospam.arcornews.de  Wed May  2 15:48:45 2007
From: no2spam at nospam.arcornews.de (Rolf Leggewie)
Date: Wed, 02 May 2007 17:48:45 +0200
Subject: [oe] upgrade "policy"
Message-ID: <f1absu$4no$1@sea.gmane.org>

Hi,

I would like to bring to your attention the powers of "mtn mv" when 
upgrading packages.  I have written up a little HOWTO at 
http://www.openembedded.org/upgradingpackages which I would consider 
"best practice" rather than policy.  I hope you all approve of this.

Regards

Rolf




From rodrigo.vivi at gmail.com  Wed May  2 18:04:39 2007
From: rodrigo.vivi at gmail.com (Rodrigo Vivi)
Date: Wed, 2 May 2007 15:04:39 -0300
Subject: [oe] generating debian source packages (dsc)
Message-ID: <bdb0025f0705021104x23d2c407rb4da0e48e24eb911@mail.gmail.com>

Hi all,

I'm trying to code a bbclass to build debian source packages, because
I need these files under mamona repository:

 * .dsc - debian source package control file
 * .orig.tar.gz - Original source package
 * .diff.gz - patches that we apply

Since this is my first bbclass I need some help to figure some doubts out.

first of all I've created a package_dsc task and added it before do_configure.

This task creates the debian/control and debian/changelog file that
dpkg-source ask for dsc generation. I know that I need to generate the
debian/rules file too because without it the dsc will not be usefull.
But this is not my real problem yet.

The current problem that I'm trying to solve and need help is the following:

before the do_configure all packages have a .pc dir that is not under
orig.tar.gz file neither inside some patch breaking the dpkg-source
but that is pretty easy to ignore doing
$dpkg-source -i"\.pc" ...
But glibc has a ports directory that is not under orig.tar.gz neither
under patches so I need to ignore this file too. And I know that is
NOT a good idea to ignore it doing
dpkg-source  -i"\.pc|ports"
And I've noticed that there are another files that breaks dpkg-source...
like util-linux_2.12r-12.diff.gz under patches dir of util-linux

I'm thinking to create a exclude-list or a dictionary to have an
exclude-list for each package. What do you thing about it? Do you know
a better and simplest way to do this?

I'm anexing my bbclass file in case you want to have a look and help me! ;)

Thanks,
Best Regards,
Vivi.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gen_dsc.bbclass
Type: application/octet-stream
Size: 6393 bytes
Desc: not available
URL: <http://lists.openembedded.org/pipermail/openembedded-devel/attachments/20070502/1191fe55/attachment-0001.obj>

From openembedded at hrw.one.pl  Wed May  2 18:51:02 2007
From: openembedded at hrw.one.pl (Marcin Juszkiewicz)
Date: Wed, 2 May 2007 20:51:02 +0200
Subject: [oe] generating debian source packages (dsc)
In-Reply-To: <bdb0025f0705021104x23d2c407rb4da0e48e24eb911@mail.gmail.com>
References: <bdb0025f0705021104x23d2c407rb4da0e48e24eb911@mail.gmail.com>
Message-ID: <200705022051.03720.openembedded@hrw.one.pl>

Dnia ?roda, 2 maja 2007, Rodrigo Vivi napisa?:
> Hi all,
>
> I'm trying to code a bbclass to build debian source packages, because
> I need these files under mamona repository:
>
>  * .dsc - debian source package control file
>  * .orig.tar.gz - Original source package
>  * .diff.gz - patches that we apply
>
> Since this is my first bbclass I need some help to figure some doubts
> out.

classes/sourcepkg.bbclass is something which you want to extend

-- 
JID: hrw-jabber.org
OpenEmbedded developer/consultant

      I'm trying to decide if I should kill you or simply feign death
      until you feel awkward and leave.





From rodrigo.vivi at gmail.com  Wed May  2 19:52:54 2007
From: rodrigo.vivi at gmail.com (Rodrigo Vivi)
Date: Wed, 2 May 2007 16:52:54 -0300
Subject: [oe] generating debian source packages (dsc)
In-Reply-To: <200705022051.03720.openembedded@hrw.one.pl>
References: <bdb0025f0705021104x23d2c407rb4da0e48e24eb911@mail.gmail.com>
	<200705022051.03720.openembedded@hrw.one.pl>
Message-ID: <bdb0025f0705021252w7e32b305ybf9c914c1cb1edc0@mail.gmail.com>

> classes/sourcepkg.bbclass is something which you want to extend

I've thought about it but I'm not sure that it is a good idea because
just few projects (or just mine) needs the dsc file .......... unless
that I code another sourcedsc.bbclass that inherit the
sourcedpkg.bbclass... o you think that it will work???  I'll think
about it...

Another doubt that I forgot to mention on last email is about changelog:
I'm generating a almost empty changelog file. Is there any official
and/or more appropriated way to do that?

Thanks,
Vivi.

>
> --
> JID: hrw-jabber.org
> OpenEmbedded developer/consultant
>
>       I'm trying to decide if I should kill you or simply feign death
>       until you feel awkward and leave.
>
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>



From papercrane at gmail.com  Wed May  2 20:38:54 2007
From: papercrane at gmail.com (Justin Patrin)
Date: Wed, 2 May 2007 13:38:54 -0700
Subject: [oe] generating debian source packages (dsc)
In-Reply-To: <bdb0025f0705021252w7e32b305ybf9c914c1cb1edc0@mail.gmail.com>
References: <bdb0025f0705021104x23d2c407rb4da0e48e24eb911@mail.gmail.com>
	<200705022051.03720.openembedded@hrw.one.pl>
	<bdb0025f0705021252w7e32b305ybf9c914c1cb1edc0@mail.gmail.com>
Message-ID: <432beae0705021338x7ca36c0oc937a6b1b03f6db5@mail.gmail.com>

On 5/2/07, Rodrigo Vivi <rodrigo.vivi at gmail.com> wrote:
> > classes/sourcepkg.bbclass is something which you want to extend
>
> I've thought about it but I'm not sure that it is a good idea because
> just few projects (or just mine) needs the dsc file .......... unless
> that I code another sourcedsc.bbclass that inherit the
> sourcedpkg.bbclass... o you think that it will work???  I'll think
> about it...
>

Yes, this is what Marcin meant. Create your own sourcedsc.bbclass
which inherits sourcepkg.bbclass. This is how, for example,
efl.bbclass and e.bbclass work.

> Another doubt that I forgot to mention on last email is about changelog:
> I'm generating a almost empty changelog file. Is there any official
> and/or more appropriated way to do that?
>
> Thanks,
> Vivi.
>
> >
> > --
> > JID: hrw-jabber.org
> > OpenEmbedded developer/consultant
> >
> >       I'm trying to decide if I should kill you or simply feign death
> >       until you feel awkward and leave.
> >
> >
> >
> > _______________________________________________
> > Openembedded-devel mailing list
> > Openembedded-devel at lists.openembedded.org
> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> >
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>


-- 
Justin Patrin



From pmiscml at gmail.com  Thu May  3 12:47:32 2007
From: pmiscml at gmail.com (Paul Sokolovsky)
Date: Thu, 3 May 2007 15:47:32 +0300
Subject: [oe] [ALERT] Security vulnerability with recent OE bitbake.conf
	changes
Message-ID: <35653307.20070503154732@gmail.com>

Hello openembedded-devel,

A commit made some time ago,

http://lists.linuxtogo.org/pipermail/openembedded-commits/2007-April/004912.html

introduced a hole which may lead to unnoticed security vulnerabilities
slipping into the packages/images produced. Specifically, it defines a
random application of a random suite to be used for resolving patching
conflicts/failures. If you don't happen to have that random tool,
patching failure will be silently swallowed, leading to any adverse
effects imaginable - from compile failure to the mentioned security
vulnerabilities.

Proposed solutions:

1. Bring back some reality and switch back to previous default of
dropping to standard shell for resolution:

-TERMCMD ?= "${GNOME_TERMCMD}"
-TERMCMDRUN ?= "${GNOME_TERMCMDRUN}"
+TERMCMD ?= "${SHELLRCCMD}"
+TERMCMDRUN ?= "${SHELLRCCMD}"


2. Add DEPENDS on that random tool, namely gnome-terminal.

If going with choice 2, I proposed also to do the following: 1) add
depends on xine, mplayer, totem, few other video players; 2) add depends
on mesa and show nice 3d rotating menu to select player of user choice;
3) use selected player to show video during the build - after all,
if user deserves comfort of using superfluous GUI tools for conflict
resolution, why one should be bored during normal build process?


Thanks,

-- 
 Paul                          mailto:pmiscml at gmail.com




From rpurdie at rpsys.net  Thu May  3 13:07:08 2007
From: rpurdie at rpsys.net (Richard Purdie)
Date: Thu, 03 May 2007 14:07:08 +0100
Subject: [oe] [ALERT] Security vulnerability with recent OE
	bitbake.conf	changes
In-Reply-To: <35653307.20070503154732@gmail.com>
References: <35653307.20070503154732@gmail.com>
Message-ID: <1178197628.6312.22.camel@localhost.localdomain>

On Thu, 2007-05-03 at 15:47 +0300, Paul Sokolovsky wrote:
> If going with choice 2, I proposed also to do the following: 1) add
> depends on xine, mplayer, totem, few other video players; 2) add depends
> on mesa and show nice 3d rotating menu to select player of user choice;
> 3) use selected player to show video during the build - after all,
> if user deserves comfort of using superfluous GUI tools for conflict
> resolution, why one should be bored during normal build process?

Paul,

Is there really any need for this?

It doesn't encourage me to give a sensible reply, does it...

Richard




From rpurdie at rpsys.net  Thu May  3 13:16:39 2007
From: rpurdie at rpsys.net (Richard Purdie)
Date: Thu, 03 May 2007 14:16:39 +0100
Subject: [oe] [ALERT] Security vulnerability with recent OE
	bitbake.conf	changes
In-Reply-To: <35653307.20070503154732@gmail.com>
References: <35653307.20070503154732@gmail.com>
Message-ID: <1178198199.6312.30.camel@localhost.localdomain>

On Thu, 2007-05-03 at 15:47 +0300, Paul Sokolovsky wrote:
> Hello openembedded-devel,
> 
> A commit made some time ago,
> 
> http://lists.linuxtogo.org/pipermail/openembedded-commits/2007-April/004912.html
> 
> introduced a hole which may lead to unnoticed security vulnerabilities
> slipping into the packages/images produced. Specifically, it defines a
> random application of a random suite to be used for resolving patching
> conflicts/failures. If you don't happen to have that random tool,
> patching failure will be silently swallowed, leading to any adverse
> effects imaginable - from compile failure to the mentioned security
> vulnerabilities.

Patch failure should not be silently swallowed, the builds should abort.
If they don't, we need to fix that underlying problem.

FWIW, your first solution using SHELLRCCMD won't actually work due to
the way IO redirection is done in recent bitbake. 

Your second solution of adding the DEPENDS is impractical due to the
amount of -native packages it would require.

So we need to find the real problem and fix that, probably somewhere in
patch.bbclass an error code isn't being propagated at a guess.

I will also hint at the use of PATCH_RESOLVER = "noop" which means the
user gets the old behaviour of patch failure aborts the build with no
help from any resolver. It should have always been the default but
wasn't. I'm not sure what the current default is but we can change it to
that if its not.

Cheers,

Richard




From pmiscml at gmail.com  Thu May  3 13:42:06 2007
From: pmiscml at gmail.com (Paul Sokolovsky)
Date: Thu, 3 May 2007 16:42:06 +0300
Subject: [oe] [ALERT] Security vulnerability with recent OE bitbake.conf
	changes
In-Reply-To: <1178198199.6312.30.camel@localhost.localdomain>
References: <35653307.20070503154732@gmail.com>
	<1178198199.6312.30.camel@localhost.localdomain>
Message-ID: <183568912.20070503164206@gmail.com>

Hello Richard,

Thursday, May 3, 2007, 4:16:39 PM, you wrote:

> On Thu, 2007-05-03 at 15:47 +0300, Paul Sokolovsky wrote:
>> Hello openembedded-devel,
>> 
>> A commit made some time ago,
>> 
>> http://lists.linuxtogo.org/pipermail/openembedded-commits/2007-April/004912.html
>> 
>> introduced a hole which may lead to unnoticed security vulnerabilities
>> slipping into the packages/images produced. Specifically, it defines a
>> random application of a random suite to be used for resolving patching
>> conflicts/failures. If you don't happen to have that random tool,
>> patching failure will be silently swallowed, leading to any adverse
>> effects imaginable - from compile failure to the mentioned security
>> vulnerabilities.


[]

> Is there really any need for this?
> It doesn't encourage me to give a sensible reply, does it...

        Apparently no. But for me, it's pretty clear that even
gnome-terminal shouldn't be used by default, and in expectation of
hardnesses regarding arguing this, I tried to draw picturesquely
absurd "extension", overspiced with few buzzwords. It's of course a
mere small bug otherwise, but I truly looking for solution which won't
by default trouble KDE, other WMs, and classy console guys in favor of
GNOME crowd.


> Patch failure should not be silently swallowed, the builds should abort.
> If they don't, we need to fix that underlying problem.

        Yes, I didn't even bother to ruin my pamphlet with such
down-to-earth triviality ;-). I'd be looking into it as time permits
of course.

> FWIW, your first solution using SHELLRCCMD won't actually work due to
> the way IO redirection is done in recent bitbake. 

> Your second solution of adding the DEPENDS is impractical due to the
> amount of -native packages it would require.

> So we need to find the real problem and fix that, probably somewhere in
> patch.bbclass an error code isn't being propagated at a guess.

> I will also hint at the use of PATCH_RESOLVER = "noop" which means the
> user gets the old behaviour of patch failure aborts the build with no
> help from any resolver. It should have always been the default but
> wasn't. I'm not sure what the current default is but we can change it to
> that if its not.

        Ack, and vote for. Let's have defaults not overloaded with
interactivity, and working along the lines of standard unix/posix
build tools. Frontends, likes one(s) you work on, can have own
config/overrides then. (And few people won't used them anyway, no
matter which potential benefits they give - and not out of
bare-commandline orthodoxy, but because they may have other frontends
relying on classical unix behavior of tools).

> Cheers,

> Richard



-- 
Best regards,
 Paul                            mailto:pmiscml at gmail.com




From leon.woestenberg at gmail.com  Fri May  4 16:19:58 2007
From: leon.woestenberg at gmail.com (Leon Woestenberg)
Date: Fri, 4 May 2007 18:19:58 +0200
Subject: [oe] task-base dependencies and missing logging of failed providers
Message-ID: <c384c5ea0705040919u8bdafe9sa6abe0942ffe3fd8@mail.gmail.com>

Hello,

just wanted to get this down for those not having followed the
discussion on IRC (and just for the record, not that the ideas are
still fresh).

My idea about a minimal image that OE should support (Goal: OE must be
scalable) is a linux kernel with a single init application
(helloworld).

Today on IRC we discussed two issues with BB/OE, indirectly blocking
the ability to build a minimal image using task-base, especially for
new users.

(1) task-base always wants *all* targets in task-* to be buildable,
regardless whether they are installed or not.

Example:

Take angstrom, strip {MACHINE,DISTRO}_FEATURES such that
COMBINED_FEATURES="ext2" or something really basic.
Set USE_NLS="no"

When now building angstrom-minimal-image, task-base wants bluetooth to
be buildable, thus bluez-utils, thus dbus, cups, glib-2.0, etc. etc.
Because glib-2.0 requires USE_NLS="yes", the image build fails with "a
no providers for" message.

[10:34]	<v8jlene>	likewise: Yeah, that task-base one's a bit annoying.
I only had about 400 recipes symlinked in, now I have them all just to
make task-base happy. And as you say it's building lots of stuff that
you don't use.

Workarounds:
- USE_NLS_glib-2.0="yes" (yes, at least makes image buildable, IFF the
other deps are met, everything is still built)

Suggested fixes:
- split task-base into seperate *.bb would work (koen, hrw), but this
is not the proper solution (RP, koen)
- do not use debian.bbclass (tried, but does not work for me)
- ...

(2) It's very hard to track down and I'm not alone:

[10:29]	<v8jlene>	likewise: Heh, I had that issue yesterday when
trying my uclibc builds with 1.8.2 ;) The error bitbake showed was
about bootstrap-image was unavailable (due to task-base pulling in
cups which pulled in dbus which pulled in glib-2.0). Took ages to
figure it all out...

New users won't find this, as bitbake -D -D -D -v does not provide this info.

2) bitbake will NOT report the above dependency
logging of failed providers

However, this one is hard to fix:

[10:31]	<RP>	likewise: There is a bitbake bug already open about the
logging of failed providers
[10:31]	<RP>	Its not as simple as it sounds though


Reproduce

taking the ?ngstr?m distro as a base, I would like to strip it down a
bit. I stripped {MACHINE,DISTRO}_FEATURES such that:

COMBINED_FEATURES="ext2"
DISTRO_EXTRA_RDEPENDS="update-modules module-init-tools
modutils-initscripts sysvinit initscripts sysvinit-pidof netbase
dropbear ipkg ipkg-collateral util-linux-mount util-linux-umount"

As none of the selected package need NLS, I have disabled it.

USE_NLS = "no"

bitbake angstrom-minimal image
or
bitbake bootstrap-image


Regards,
-- 
Leon

The persons and animals named in this email are based on true
characters in real life.



From cailotto at sci.univr.it  Fri May  4 10:33:10 2007
From: cailotto at sci.univr.it (Stefano Cailotto)
Date: Fri, 4 May 2007 12:33:10 +0200
Subject: [oe] OE on Kontron eb425
Message-ID: <002a01c78e37$9d165360$38f21b9d@kai>

Hi all, 
I'm trying to build something usable for a kontron eb425 board, based on an
intel ixp425.
I tried to compile using a generic ixp4xxbe, but when loading, the kernel
stops after uncompressing reporting a CRC error.
It seems that Kontron EmbeddedLinux development kit performs something on
the kernel before making zImage in order to load it in a specifed memory
location.
I'd like to use OE, anyway, so my questions are:
1) has anyone faced my same problem (possibly with positive results)?
2) is there away to "port" kontron configuration inside OE?I'm looking to
understand how...

Thanx, 
Stefano


---------------------------------------------------------------------------
  Stefano Cailotto - Research Consultant
---------------------------------------------------------------------------
  EDALab - Networked Embedded Systems
  c/o  Dipartimento di Informatica - Universita` di Verona
  Strada le Grazie, 15 - 37134 Verona (Italy)
---------------------------------------------------------------------------
  email: cailotto at sci.univr.it stefano.cailotto at edalab.it      
  web:  http://www.edalab.it
  tel: +39-045-802-7062 fax: +39-045-802-7068
---------------------------------------------------------------------------




From leon.woestenberg at gmail.com  Sat May  5 12:35:22 2007
From: leon.woestenberg at gmail.com (Leon Woestenberg)
Date: Sat, 5 May 2007 14:35:22 +0200
Subject: [oe] OE on Kontron eb425
In-Reply-To: <002a01c78e37$9d165360$38f21b9d@kai>
References: <002a01c78e37$9d165360$38f21b9d@kai>
Message-ID: <c384c5ea0705050535i1c13cc5ase333da9be4d6cf8e@mail.gmail.com>

Hello Stefano,

On 5/4/07, Stefano Cailotto <cailotto at sci.univr.it> wrote:
> Hi all,
> I'm trying to build something usable for a kontron eb425 board, based on an
> intel ixp425.
> I tried to compile using a generic ixp4xxbe, but when loading, the kernel
> stops after uncompressing reporting a CRC error.
> It seems that Kontron EmbeddedLinux development kit performs something on
> the kernel before making zImage in order to load it in a specifed memory
> location.
>
There are some IXP42x users on OE, mostly for the NSLU device from
Linksys/Cisco, the Intel dev board (IXDP425) and some custom boards,
but I have not see the Kontron board yet.

With the reported problem, it would help if you understand or at least
could tell where to find the details on the boot loader.

Ideally, you would want to boot loader to be buildable from source
instead of relying on some binary on flash.

Regards,

Leon.



From repvik at kynisk.com  Sat May  5 13:46:45 2007
From: repvik at kynisk.com (=?iso-8859-1?q?=D8yvind_Repvik?=)
Date: Sat, 5 May 2007 15:46:45 +0200
Subject: [oe] OE on Kontron eb425
In-Reply-To: <c384c5ea0705050535i1c13cc5ase333da9be4d6cf8e@mail.gmail.com>
References: <002a01c78e37$9d165360$38f21b9d@kai>
	<c384c5ea0705050535i1c13cc5ase333da9be4d6cf8e@mail.gmail.com>
Message-ID: <200705051546.46019.repvik@kynisk.com>

On Saturday 05 May 2007 14:35:22 Leon Woestenberg wrote:
> Hello Stefano,
>
> On 5/4/07, Stefano Cailotto <cailotto at sci.univr.it> wrote:
> > Hi all,
> > I'm trying to build something usable for a kontron eb425 board, based on
> > an intel ixp425.
> > I tried to compile using a generic ixp4xxbe, but when loading, the kernel
> > stops after uncompressing reporting a CRC error.
> > It seems that Kontron EmbeddedLinux development kit performs something on
> > the kernel before making zImage in order to load it in a specifed memory
> > location.
>
> There are some IXP42x users on OE, mostly for the NSLU device from
> Linksys/Cisco, the Intel dev board (IXDP425) and some custom boards,
> but I have not see the Kontron board yet.
>
> With the reported problem, it would help if you understand or at least
> could tell where to find the details on the boot loader.

A very important detail is which MACH ID the bootloader passes via ATAG.

Regards,
?yvind



From koen at dominion.kabel.utwente.nl  Sat May  5 14:54:52 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Sat, 05 May 2007 16:54:52 +0200
Subject: [oe] Questions: Founding of Open Embedded, dev gatherings etc.
In-Reply-To: <200705041909.29494.kyrvin@trolltech.com>
References: <200705041909.29494.kyrvin@trolltech.com>
Message-ID: <463C9ABC.7090503@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Knut Yrvin schreef:
> Hi all :)
> 
> At FOSDEM I talked with Gerwin van der Kruis about Trolltech helping Open 
> Embedded getting started with developer gatherings and a foundation. 
> 
> I got some experiences with developer gatherings after initiationg the 
> Skolelinux project in 2001. Actually we have organised +30 gatherings. 
> Skolelinux is now a part of DebianEdu. The board of "Free Software in School" 
> organises about 6-7 developer gatherings a year. Pictures from opening of one 
> of the gatherings in Forbach - France, gives an idea of the scale: 
> 
> http://www.bawetic.be/PHOTOS/Forbach2006/
> 
> I would like to see similar activeties in OpenEmbedded space. Maybe Mobile 
> Developer Days 2007 at Alborg University in Denmark could be the place to 
> start?: 
> 
> http://mobiledevices.kom.aau.dk/team_and_organization/events/mobile_developer_days_2007/
> 
> To sum it up. Gerwin van der Kruis idea is to make a foundation, and getting  
> dev.gatherings started. Is this interesting for you? If you are interesed, 
> how should we proceed?

We are certainly interested! At the moment a big part of our core developers is on
holiday, moving appartments, doing examns, etc, so we'll get back to you in a few days.

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGPJq8MkyGM64RGpERApcQAJ9DBG3lBC15R7vs86XeN2DE7UZoGACeIs/R
C1jgdp0EigJhbElqYG+U7Og=
=lH/J
-----END PGP SIGNATURE-----



From koen at dominion.kabel.utwente.nl  Sat May  5 15:11:37 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Sat, 05 May 2007 17:11:37 +0200
Subject: [oe] RFC: make do_install and do_deploy a PACKAGE_FUNC
Message-ID: <463C9EA9.2060302@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Lately there have been several problems with files not getting packaged, because users
resumed builds after a failure. Richard has come up with a fix:

http://www.rpsys.net/openzaurus/temp/oe-install-change.patch

The only bug with that patch is that do_deploy fails, which can be solved by making that a
 PACKAGE_FUNC as well.

What do you think about that?

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGPJ6pMkyGM64RGpERAs9xAKC7qGcvY8E9wGMsp/o/2MQO/pIMmACeKknh
HcvgGS6egpiNlqq9Zx5eQO8=
=CUmR
-----END PGP SIGNATURE-----



From manuel.teira at telefonica.net  Sun May  6 20:17:51 2007
From: manuel.teira at telefonica.net (Manuel Teira)
Date: Sun, 06 May 2007 22:17:51 +0200
Subject: [oe] gstreamer obsoleted recipes
Message-ID: <1178482671.6132.10.camel@localhost>

Hello all.

I've recently added some recipes for gstreamer and gst-plugins-[good|
bad|ugly|...] in order to build the last stable releases of this
software. I've seen that there are a lot of "old" stable releases that
if nobody is needing, we could sanely delete from the repository.

My plan is to only left the last stable version for all the related
packages, so, we would keep only the following recipes, in the directory
gstreamer:

gst-ffmpeg_0.10.2.bb
gst-plugins-base_0.10.12.bb
gst-plugins-good_0.10.5.bb
gst-plugins-ugly_0.10.5.bb
gstreamer_0.10.12.bb

The only distro that seems to depend on  a fixed gstreamer version
(0.10.11) is angstrom. But I assume that we can upgrade that requirement
to 0.10.12 without problems.

If nobody disagree, I will proceed with the gstreamer cleanup the next
week.

Best regards.





From koen at dominion.kabel.utwente.nl  Sun May  6 20:38:32 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Sun, 06 May 2007 22:38:32 +0200
Subject: [oe] gstreamer obsoleted recipes
In-Reply-To: <1178482671.6132.10.camel@localhost>
References: <1178482671.6132.10.camel@localhost>
Message-ID: <463E3CC8.10407@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Manuel Teira schreef:
> Hello all.
> 
> I've recently added some recipes for gstreamer and gst-plugins-[good|
> bad|ugly|...] in order to build the last stable releases of this
> software. I've seen that there are a lot of "old" stable releases that
> if nobody is needing, we could sanely delete from the repository.
> 
> My plan is to only left the last stable version for all the related
> packages, so, we would keep only the following recipes, in the directory
> gstreamer:
> 
> gst-ffmpeg_0.10.2.bb
> gst-plugins-base_0.10.12.bb
> gst-plugins-good_0.10.5.bb
> gst-plugins-ugly_0.10.5.bb
> gstreamer_0.10.12.bb
> 
> The only distro that seems to depend on  a fixed gstreamer version
> (0.10.11) is angstrom. But I assume that we can upgrade that requirement
> to 0.10.12 without problems.

Yes, it's safe, angstrom only had those versions locked down to select 0.10 over 0.8, but
0.8 is gone now, so those preferred_versions should be safe to remove.

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGPjzIMkyGM64RGpERAky3AJ4t1RemMlENfVNDI1pdPIpIkBqJNwCfTIoq
DazvNQqprOC1w9bC1hRehq4=
=6F9d
-----END PGP SIGNATURE-----



From papercrane at gmail.com  Mon May  7 04:29:26 2007
From: papercrane at gmail.com (Justin Patrin)
Date: Sun, 6 May 2007 21:29:26 -0700
Subject: [oe] [ALERT] Security vulnerability with recent OE bitbake.conf
	changes
In-Reply-To: <1178198199.6312.30.camel@localhost.localdomain>
References: <35653307.20070503154732@gmail.com>
	<1178198199.6312.30.camel@localhost.localdomain>
Message-ID: <432beae0705062129i11f69731n1d12777f46a83316@mail.gmail.com>

On 5/3/07, Richard Purdie <rpurdie at rpsys.net> wrote:
> On Thu, 2007-05-03 at 15:47 +0300, Paul Sokolovsky wrote:
> > Hello openembedded-devel,
> >
> > A commit made some time ago,
> >
> > http://lists.linuxtogo.org/pipermail/openembedded-commits/2007-April/004912.html
> >
> > introduced a hole which may lead to unnoticed security vulnerabilities
> > slipping into the packages/images produced. Specifically, it defines a
> > random application of a random suite to be used for resolving patching
> > conflicts/failures. If you don't happen to have that random tool,
> > patching failure will be silently swallowed, leading to any adverse
> > effects imaginable - from compile failure to the mentioned security
> > vulnerabilities.
>
> Patch failure should not be silently swallowed, the builds should abort.
> If they don't, we need to fix that underlying problem.
>
> FWIW, your first solution using SHELLRCCMD won't actually work due to
> the way IO redirection is done in recent bitbake.
>
> Your second solution of adding the DEPENDS is impractical due to the
> amount of -native packages it would require.
>
> So we need to find the real problem and fix that, probably somewhere in
> patch.bbclass an error code isn't being propagated at a guess.
>
> I will also hint at the use of PATCH_RESOLVER = "noop" which means the
> user gets the old behaviour of patch failure aborts the build with no
> help from any resolver. It should have always been the default but
> wasn't. I'm not sure what the current default is but we can change it to
> that if its not.
>

Ummm...where? I tried that in my local.conf and it did nothing. I've
also grepped for PATCH_RESOLVER in both bitbake and oe and found
nothing.

Please, let's remove the gnome-terminal default, it makes no sense to
assume that the lowest common denominator is running bitbake from X...

-- 
Justin Patrin



From papercrane at gmail.com  Mon May  7 04:29:26 2007
From: papercrane at gmail.com (Justin Patrin)
Date: Sun, 6 May 2007 21:29:26 -0700
Subject: [oe] [ALERT] Security vulnerability with recent OE bitbake.conf
	changes
In-Reply-To: <1178198199.6312.30.camel@localhost.localdomain>
References: <35653307.20070503154732@gmail.com>
	<1178198199.6312.30.camel@localhost.localdomain>
Message-ID: <432beae0705062129i11f69731n1d12777f46a83316@mail.gmail.com>

On 5/3/07, Richard Purdie <rpurdie at rpsys.net> wrote:
> On Thu, 2007-05-03 at 15:47 +0300, Paul Sokolovsky wrote:
> > Hello openembedded-devel,
> >
> > A commit made some time ago,
> >
> > http://lists.linuxtogo.org/pipermail/openembedded-commits/2007-April/004912.html
> >
> > introduced a hole which may lead to unnoticed security vulnerabilities
> > slipping into the packages/images produced. Specifically, it defines a
> > random application of a random suite to be used for resolving patching
> > conflicts/failures. If you don't happen to have that random tool,
> > patching failure will be silently swallowed, leading to any adverse
> > effects imaginable - from compile failure to the mentioned security
> > vulnerabilities.
>
> Patch failure should not be silently swallowed, the builds should abort.
> If they don't, we need to fix that underlying problem.
>
> FWIW, your first solution using SHELLRCCMD won't actually work due to
> the way IO redirection is done in recent bitbake.
>
> Your second solution of adding the DEPENDS is impractical due to the
> amount of -native packages it would require.
>
> So we need to find the real problem and fix that, probably somewhere in
> patch.bbclass an error code isn't being propagated at a guess.
>
> I will also hint at the use of PATCH_RESOLVER = "noop" which means the
> user gets the old behaviour of patch failure aborts the build with no
> help from any resolver. It should have always been the default but
> wasn't. I'm not sure what the current default is but we can change it to
> that if its not.
>

Ummm...where? I tried that in my local.conf and it did nothing. I've
also grepped for PATCH_RESOLVER in both bitbake and oe and found
nothing.

Please, let's remove the gnome-terminal default, it makes no sense to
assume that the lowest common denominator is running bitbake from X...

-- 
Justin Patrin



From koen at dominion.kabel.utwente.nl  Mon May  7 10:39:11 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Mon, 07 May 2007 12:39:11 +0200
Subject: [oe] Potential Problems in glibc-package.bbclass
In-Reply-To: <45F0200B.9080002@dominion.kabel.utwente.nl>
References: <a7f8874a0702280825j22bdf3bbw94e58cfd4a0fab93@mail.gmail.com>
	<45F0200B.9080002@dominion.kabel.utwente.nl>
Message-ID: <463F01CF.5010601@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Koen Kooi schreef:
> Hans Henry von Tresckow schreef:
>> I think I may have stumbled across some potential bugs in glibc-package.bbclass:
> 
>> it seems like the standard value for datadir is /usr/share which will
>> cause the following problems in output_locale_binary:
> 
>> 1) i18npath will be set to /usr/share/i18n instead of
>> treedir/usr/share/i18n becouse path.join is too braindead to remove
>> leading / on path entries.
>> 2) the --inputfile option in localdef opts uses datadir instead of
>> treedir, so it looks like it would use the locale files installed on
>> the host instead of the ones we are buildig for.
> 
> 
> There now is a base_path_join function in OE, that doesn't have that bug. No idea why
> glibc.bbclass hasn't been updated to use that.

See http://bugs.openembedded.org/show_bug.cgi?id=1821#c9 for the proposed solution for at
least 1).

regards,

Koen

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGPwHPMkyGM64RGpERAjMsAJ9hwzbjdM/QDmpE/gPkB9taIK7wgACePfxv
E306nGzJX80t3kuMxbtqe+Y=
=W3Un
-----END PGP SIGNATURE-----



From pmiscml at gmail.com  Mon May  7 10:43:31 2007
From: pmiscml at gmail.com (Paul Sokolovsky)
Date: Mon, 7 May 2007 13:43:31 +0300
Subject: [oe] Potential Problems in glibc-package.bbclass
In-Reply-To: <463F01CF.5010601@dominion.kabel.utwente.nl>
References: <a7f8874a0702280825j22bdf3bbw94e58cfd4a0fab93@mail.gmail.com>
	<45F0200B.9080002@dominion.kabel.utwente.nl>
	<463F01CF.5010601@dominion.kabel.utwente.nl>
Message-ID: <1019023621.20070507134331@gmail.com>

Hello Koen,

Monday, May 7, 2007, 1:39:11 PM, you wrote:

[]

>>> I think I may have stumbled across some potential bugs in glibc-package.bbclass:
>> 
>>> it seems like the standard value for datadir is /usr/share which will
>>> cause the following problems in output_locale_binary:
>> 
>>> 1) i18npath will be set to /usr/share/i18n instead of
>>> treedir/usr/share/i18n becouse path.join is too braindead to remove
>>> leading / on path entries.
>>> 2) the --inputfile option in localdef opts uses datadir instead of
>>> treedir, so it looks like it would use the locale files installed on
>>> the host instead of the ones we are buildig for.
>> 
>> 
>> There now is a base_path_join function in OE, that doesn't have that bug. No idea why
>> glibc.bbclass hasn't been updated to use that.

> See http://bugs.openembedded.org/show_bug.cgi?id=1821#c9 for the proposed solution for at
> least 1).

        This is indeed few months old. Let's apply it?


> regards,

> Koen

[]

-- 
Best regards,
 Paul                            mailto:pmiscml at gmail.com




From koen at dominion.kabel.utwente.nl  Mon May  7 10:54:34 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Mon, 07 May 2007 12:54:34 +0200
Subject: [oe] Potential Problems in glibc-package.bbclass
In-Reply-To: <1019023621.20070507134331@gmail.com>
References: <a7f8874a0702280825j22bdf3bbw94e58cfd4a0fab93@mail.gmail.com>	<45F0200B.9080002@dominion.kabel.utwente.nl>	<463F01CF.5010601@dominion.kabel.utwente.nl>
	<1019023621.20070507134331@gmail.com>
Message-ID: <463F056A.7020907@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Paul Sokolovsky schreef:

>> See http://bugs.openembedded.org/show_bug.cgi?id=1821#c9 for the proposed solution for at
>> least 1).
> 
>         This is indeed few months old. Let's apply it?

Fine by me.

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGPwVqMkyGM64RGpERArHoAJ9fW1sGGBVZi0l8TpEruHO9eOJV6gCgnGjj
5Gy2vWx5lGYRjcnSlp2TouA=
=Y7wS
-----END PGP SIGNATURE-----



From no2spam at nospam.arcornews.de  Mon May  7 18:38:49 2007
From: no2spam at nospam.arcornews.de (Rolf Leggewie)
Date: Mon, 07 May 2007 20:38:49 +0200
Subject: [oe] perl 5.8.8 is ready
In-Reply-To: <20070427105722.GA4340@twibble.org>
References: <20070427105722.GA4340@twibble.org>
Message-ID: <f1nrnr$pal$1@sea.gmane.org>

Perl has been recently broken for

a) MACHINE="qemuarm" on angstrom
b) MACHINE="collie" on sharprom-compatible (worked two days prior)




From lenehan at twibble.org  Tue May  8 01:22:28 2007
From: lenehan at twibble.org (Jamie Lenehan)
Date: Tue, 8 May 2007 11:22:28 +1000
Subject: [oe] perl 5.8.8 is ready
In-Reply-To: <f1nrnr$pal$1@sea.gmane.org>
References: <20070427105722.GA4340@twibble.org> <f1nrnr$pal$1@sea.gmane.org>
Message-ID: <20070508012228.GA13161@twibble.org>

On Mon, May 07, 2007 at 08:38:49PM +0200, Rolf Leggewie wrote:
> Perl has been recently broken for
> 
> a) MACHINE="qemuarm" on angstrom
> b) MACHINE="collie" on sharprom-compatible (worked two days prior)

A log or something about what was going wrong might have helped ;)

Looking at irc logs it looks like you having problems with the patching
failing which it doesn't seem to do for anyone else.

My first suspect would be that you added the patch in question
(letgcc-find-errno.patch) locally to test it (when I added it to
bugzilla) and left it in there. Then a recent mt update has resulted
in the change I pushed being included resulting in the patch being
applied twice in the perl recipe.

So can you do an mtn diff on perl_5.8.8.bb and make sure this isn't
the problem? If it isn't the problem I might need some more
information (although I can't really thing of what else this could be
and/or what would help figuring it out at the moment.)

-- 
 Jamie Lenehan <lenehan at twibble.org>



From rpurdie at rpsys.net  Tue May  8 12:30:05 2007
From: rpurdie at rpsys.net (Richard Purdie)
Date: Tue, 08 May 2007 13:30:05 +0100
Subject: [oe] [ALERT] Security vulnerability with recent OE	bitbake.conf
	changes
In-Reply-To: <432beae0705062129i11f69731n1d12777f46a83316@mail.gmail.com>
References: <35653307.20070503154732@gmail.com>
	<1178198199.6312.30.camel@localhost.localdomain>
	<432beae0705062129i11f69731n1d12777f46a83316@mail.gmail.com>
Message-ID: <1178627405.6061.17.camel@localhost.localdomain>

On Sun, 2007-05-06 at 21:29 -0700, Justin Patrin wrote:
> Ummm...where? I tried that in my local.conf and it did nothing. I've
> also grepped for PATCH_RESOLVER in both bitbake and oe and found
> nothing.

Sorry, it should be PATCHRESOLVE = "noop", my memory is playing tricks.

> Please, let's remove the gnome-terminal default, it makes no sense to
> assume that the lowest common denominator is running bitbake from X...

"noop" should be the default. There is no good argument for which
terminal UI should/shouldn't be the default. Ideally I guess it would
autoselect unless the user specifies, I'll give that some thought. A
warning from sanity.bbclass about a missing command might be good too...

Cheers,

Richard




From pmiscml at gmail.com  Tue May  8 13:11:03 2007
From: pmiscml at gmail.com (Paul Sokolovsky)
Date: Tue, 8 May 2007 16:11:03 +0300
Subject: [oe] [ALERT] Security vulnerability with recent OE bitbake.conf
	changes
In-Reply-To: <1178198199.6312.30.camel@localhost.localdomain>
References: <35653307.20070503154732@gmail.com>
	<1178198199.6312.30.camel@localhost.localdomain>
Message-ID: <127969848.20070508161103@gmail.com>

Hello Richard,

Thursday, May 3, 2007, 4:16:39 PM, you wrote:

[]

> So we need to find the real problem and fix that, probably somewhere in
> patch.bbclass an error code isn't being propagated at a guess.

        Ok, so here we go: http://bugs.openembedded.org/show_bug.cgi?id=2274

> NOTE: Applying patch 'include-linux-types.patch'
> sh: line 1: gnome-terminal: command not found
> ERROR: Cannot proceed with manual patch resolution - 'gnome-terminal --disable-factory -t "$TERMWINDOWTITLE" -x bash --rcfile $TERMRCFILE' not found. Check TERMCMDRUN variable.
> ERROR: Error in executing: /home/pfalcon/linux-ppc/org.openembedded.dev/packages/dosfstools/dosfstools_2.11.bb
> ERROR: Exception:exceptions.SystemExit Message:1
> ERROR: Printing the environment of the function

Should be clear enough and helpful to whoever may enable manual mode,
but don't have a required terminal app.

> I will also hint at the use of PATCH_RESOLVER = "noop" which means the
> user gets the old behaviour of patch failure aborts the build with no
> help from any resolver. It should have always been the default but
> wasn't. I'm not sure what the current default is but we can change it to
> that if its not.

        Ok, so please review patches above, and let's make these all
changes ;-).

> Cheers,

> Richard



-- 
Best regards,
 Paul                            mailto:pmiscml at gmail.com




From papercrane at gmail.com  Tue May  8 17:35:14 2007
From: papercrane at gmail.com (Justin Patrin)
Date: Tue, 8 May 2007 10:35:14 -0700
Subject: [oe] [ALERT] Security vulnerability with recent OE bitbake.conf
	changes
In-Reply-To: <1178627405.6061.17.camel@localhost.localdomain>
References: <35653307.20070503154732@gmail.com>
	<1178198199.6312.30.camel@localhost.localdomain>
	<432beae0705062129i11f69731n1d12777f46a83316@mail.gmail.com>
	<1178627405.6061.17.camel@localhost.localdomain>
Message-ID: <432beae0705081035i1b017e3eg652644541f257bbf@mail.gmail.com>

On 5/8/07, Richard Purdie <rpurdie at rpsys.net> wrote:
> On Sun, 2007-05-06 at 21:29 -0700, Justin Patrin wrote:
> > Ummm...where? I tried that in my local.conf and it did nothing. I've
> > also grepped for PATCH_RESOLVER in both bitbake and oe and found
> > nothing.
>
> Sorry, it should be PATCHRESOLVE = "noop", my memory is playing tricks.

Ah there we go, thanks a lot. I tried grepping for gnome-terminal and
it hadn't lead me there.

>
> > Please, let's remove the gnome-terminal default, it makes no sense to
> > assume that the lowest common denominator is running bitbake from X...
>
> "noop" should be the default. There is no good argument for which
> terminal UI should/shouldn't be the default. Ideally I guess it would
> autoselect unless the user specifies, I'll give that some thought. A
> warning from sanity.bbclass about a missing command might be good too...
>

It appears not to be, however...:-|

-- 
Justin Patrin



From papercrane at gmail.com  Tue May  8 17:35:14 2007
From: papercrane at gmail.com (Justin Patrin)
Date: Tue, 8 May 2007 10:35:14 -0700
Subject: [oe] [ALERT] Security vulnerability with recent OE bitbake.conf
	changes
In-Reply-To: <1178627405.6061.17.camel@localhost.localdomain>
References: <35653307.20070503154732@gmail.com>
	<1178198199.6312.30.camel@localhost.localdomain>
	<432beae0705062129i11f69731n1d12777f46a83316@mail.gmail.com>
	<1178627405.6061.17.camel@localhost.localdomain>
Message-ID: <432beae0705081035i1b017e3eg652644541f257bbf@mail.gmail.com>

On 5/8/07, Richard Purdie <rpurdie at rpsys.net> wrote:
> On Sun, 2007-05-06 at 21:29 -0700, Justin Patrin wrote:
> > Ummm...where? I tried that in my local.conf and it did nothing. I've
> > also grepped for PATCH_RESOLVER in both bitbake and oe and found
> > nothing.
>
> Sorry, it should be PATCHRESOLVE = "noop", my memory is playing tricks.

Ah there we go, thanks a lot. I tried grepping for gnome-terminal and
it hadn't lead me there.

>
> > Please, let's remove the gnome-terminal default, it makes no sense to
> > assume that the lowest common denominator is running bitbake from X...
>
> "noop" should be the default. There is no good argument for which
> terminal UI should/shouldn't be the default. Ideally I guess it would
> autoselect unless the user specifies, I'll give that some thought. A
> warning from sanity.bbclass about a missing command might be good too...
>

It appears not to be, however...:-|

-- 
Justin Patrin



From xjqian at gmail.com  Wed May  9 02:25:00 2007
From: xjqian at gmail.com (Junqian Gordon Xu)
Date: Tue, 08 May 2007 21:25:00 -0500
Subject: [oe] QA for intentionally unpackaged files
Message-ID: <464130FC.7030008@gmail.com>

Now there is no way to distinguish if the following is intensional by 
the package maintainer or an oversight without taking a closer look at 
the contents

NOTE: the following files were installed but not shipped in any package:
NOTE:   /usr/lib/libpython2.4.so
NOTE:   /usr/lib/.debug/libpython2.4.so.1.0
NOTE:   /usr/share/man/man1/python.1
NOTE:   /usr/bin/python2.4
NOTE:   /usr/bin/smtpd.py
NOTE:   /usr/bin/.debug/python

Maybe we should have something in insane.bb to take care of the 
intentionally unpackaged crusts. So we can do something like the 
following in a bb file to intensionally leave out some garbage unpackaged:

UNSHIPPED = "${libdir}/libpython2.4.so ${bindir}/smtpd.py"  #reason why 
not package/ship it

so during do_package or package_QA, it would show as

NOTE: the following files were installed but not shipped in any package:
NOTE:   /usr/lib/libpython2.4.so   UNSHIPPED #reason why not 
packaged/ship it
NOTE:   /usr/lib/.debug/libpython2.4.so.1.0
NOTE:   /usr/share/man/man1/python.1
NOTE:   /usr/bin/python2.4
NOTE:   /usr/bin/smtpd.py  UNSHIPPED #reason why not packaged/ship it
NOTE:   /usr/bin/.debug/python

Is SUNK a better word than UNSHIPPED?

Gordon



From pmiscml at gmail.com  Wed May  9 09:38:21 2007
From: pmiscml at gmail.com (Paul Sokolovsky)
Date: Wed, 9 May 2007 12:38:21 +0300
Subject: [oe] QA for intentionally unpackaged files
In-Reply-To: <464130FC.7030008@gmail.com>
References: <464130FC.7030008@gmail.com>
Message-ID: <02827798.20070509123821@gmail.com>

Hello Junqian,

Wednesday, May 9, 2007, 5:25:00 AM, you wrote:

> Now there is no way to distinguish if the following is intensional by 
> the package maintainer or an oversight without taking a closer look at
> the contents

        So, maybe "closer look" is indeed a solution here?

> NOTE: the following files were installed but not shipped in any package:
> NOTE:   /usr/lib/libpython2.4.so
> NOTE:   /usr/lib/.debug/libpython2.4.so.1.0
> NOTE:   /usr/share/man/man1/python.1
> NOTE:   /usr/bin/python2.4
> NOTE:   /usr/bin/smtpd.py
> NOTE:   /usr/bin/.debug/python

> Maybe we should have something in insane.bb to take care of the 
> intentionally unpackaged crusts. So we can do something like the 
> following in a bb file to intensionally leave out some garbage unpackaged:

> UNSHIPPED = "${libdir}/libpython2.4.so ${bindir}/smtpd.py"  #reason why
> not package/ship it

        Who exactly will go over all recipes and add such lines?

> so during do_package or package_QA, it would show as

> NOTE: the following files were installed but not shipped in any package:
> NOTE:   /usr/lib/libpython2.4.so   UNSHIPPED #reason why not 
> packaged/ship it

        No, thanks, it likely shouldn't dump them at all then.

> NOTE:   /usr/lib/.debug/libpython2.4.so.1.0
> NOTE:   /usr/share/man/man1/python.1
> NOTE:   /usr/bin/python2.4
> NOTE:   /usr/bin/smtpd.py  UNSHIPPED #reason why not packaged/ship it
> NOTE:   /usr/bin/.debug/python

> Is SUNK a better word than UNSHIPPED?

        No.

> Gordon


-- 
Best regards,
 Paul                            mailto:pmiscml at gmail.com




From hacker at klever.net  Wed May  9 10:31:45 2007
From: hacker at klever.net (Michael Krelin)
Date: Wed, 09 May 2007 12:31:45 +0200
Subject: [oe] QA for intentionally unpackaged files
In-Reply-To: <02827798.20070509123821@gmail.com>
References: <464130FC.7030008@gmail.com> <02827798.20070509123821@gmail.com>
Message-ID: <4641A311.4030907@klever.net>

> 
>> UNSHIPPED = "${libdir}/libpython2.4.so ${bindir}/smtpd.py"  #reason why
>> not package/ship it
> 
>         Who exactly will go over all recipes and add such lines?

I take it the proposal was that package maintainers should take care of
it. Indeed, it would be better if intentionally unpackaged files invoked
no QA notice. But I think the solution is either not install them or rm
them after installation, depending on installation procedure nature.


Love,
H



From koen at dominion.kabel.utwente.nl  Wed May  9 10:42:42 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Wed, 09 May 2007 12:42:42 +0200
Subject: [oe] QA for intentionally unpackaged files
In-Reply-To: <4641A311.4030907@klever.net>
References: <464130FC.7030008@gmail.com> <02827798.20070509123821@gmail.com>
	<4641A311.4030907@klever.net>
Message-ID: <4641A5A2.8050108@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Michael Krelin schreef:
>>> UNSHIPPED = "${libdir}/libpython2.4.so ${bindir}/smtpd.py"  #reason why
>>> not package/ship it
>>         Who exactly will go over all recipes and add such lines?
> 
> I take it the proposal was that package maintainers should take care of
> it. Indeed, it would be better if intentionally unpackaged files invoked
> no QA notice. But I think the solution is either not install them or rm
> them after installation, depending on installation procedure nature.

Or we could patch package.bbclass[1] to do:

PACKAGES += "${PN}-leftovers"
FILES_${PN}-leftovers = "/"

I'm not sure if that works, but if it does, we would be able to spot leftovers more easily
by looking at deploy.

regards,

Koen

[1] this wouldn't work in bitbake.conf
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGQaWiMkyGM64RGpERAuTXAKCD+n1gXwbL7dyqru7UySv82J/CXQCgmTUM
7dYtDM79sAYQSnyDtwKmcfM=
=hEE+
-----END PGP SIGNATURE-----



From xjqian at gmail.com  Wed May  9 10:48:33 2007
From: xjqian at gmail.com (Junqian Gordon Xu)
Date: Wed, 09 May 2007 05:48:33 -0500
Subject: [oe] QA for intentionally unpackaged files
In-Reply-To: <02827798.20070509123821@gmail.com>
References: <464130FC.7030008@gmail.com> <02827798.20070509123821@gmail.com>
Message-ID: <4641A701.5000204@gmail.com>

Paul Sokolovsky wrote:
>
>         So, maybe "closer look" is indeed a solution here?
>
>   
>         Who exactly will go over all recipes and add such lines?
>
>   
>
>         No, thanks, it likely shouldn't dump them at all then.

I take it as to find an easy and uncumbersome way to take care of this. 
I don't think doing nothing at all is a good solution.

Gordon



From xjqian at gmail.com  Wed May  9 10:57:06 2007
From: xjqian at gmail.com (Junqian Gordon Xu)
Date: Wed, 09 May 2007 05:57:06 -0500
Subject: [oe] QA for intentionally unpackaged files
In-Reply-To: <4641A5A2.8050108@dominion.kabel.utwente.nl>
References: <464130FC.7030008@gmail.com>
	<02827798.20070509123821@gmail.com>	<4641A311.4030907@klever.net>
	<4641A5A2.8050108@dominion.kabel.utwente.nl>
Message-ID: <4641A902.6020506@gmail.com>

Koen Kooi wrote:
> Or we could patch package.bbclass[1] to do:
>
> PACKAGES += "${PN}-leftovers"
> FILES_${PN}-leftovers = "/"
>
> I'm not sure if that works, but if it does, we would be able to spot leftovers more easily
> by looking at deploy.

Again, how do you know which one is "intentionally" left-over vs. which 
one is not?

Gordon




From koen at dominion.kabel.utwente.nl  Wed May  9 11:26:03 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Wed, 09 May 2007 13:26:03 +0200
Subject: [oe] QA for intentionally unpackaged files
In-Reply-To: <4641A902.6020506@gmail.com>
References: <464130FC.7030008@gmail.com>	<02827798.20070509123821@gmail.com>	<4641A311.4030907@klever.net>	<4641A5A2.8050108@dominion.kabel.utwente.nl>
	<4641A902.6020506@gmail.com>
Message-ID: <4641AFCB.6080203@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Junqian Gordon Xu schreef:
> Koen Kooi wrote:
>> Or we could patch package.bbclass[1] to do:
>>
>> PACKAGES += "${PN}-leftovers"
>> FILES_${PN}-leftovers = "/"
>>
>> I'm not sure if that works, but if it does, we would be able to spot leftovers more easily
>> by looking at deploy.
> 
> Again, how do you know which one is "intentionally" left-over vs. which 
> one is not?

I can't think of a valid reason for not packaging files.

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGQa/LMkyGM64RGpERAjF7AJkBFh9SE86gjvybHZ7PRwc0+Cl2qwCcDV1h
tStk9ih9NSv558uCHvxA4G8=
=caUf
-----END PGP SIGNATURE-----



From pmiscml at gmail.com  Wed May  9 11:37:09 2007
From: pmiscml at gmail.com (Paul Sokolovsky)
Date: Wed, 9 May 2007 14:37:09 +0300
Subject: [oe] QA for intentionally unpackaged files
In-Reply-To: <4641AFCB.6080203@dominion.kabel.utwente.nl>
References: <464130FC.7030008@gmail.com> <02827798.20070509123821@gmail.com>
	<4641A311.4030907@klever.net>
	<4641A5A2.8050108@dominion.kabel.utwente.nl>
	<4641A902.6020506@gmail.com>
	<4641AFCB.6080203@dominion.kabel.utwente.nl>
Message-ID: <818235002.20070509143709@gmail.com>

Hello Koen,

Wednesday, May 9, 2007, 2:26:03 PM, you wrote:


> Junqian Gordon Xu schreef:
>> Koen Kooi wrote:
>>> Or we could patch package.bbclass[1] to do:
>>>
>>> PACKAGES += "${PN}-leftovers"
>>> FILES_${PN}-leftovers = "/"
>>>
>>> I'm not sure if that works, but if it does, we would be able to spot leftovers more easily
>>> by looking at deploy.
>> 
>> Again, how do you know which one is "intentionally" left-over vs. which 
>> one is not?

> I can't think of a valid reason for not packaging files.

        busybox doesn't package symlinks, as update-alternative
recreates them on install.


        But I agree that catch-all package is better idea than another
adhoc var. Except that we probably should add ${PN}-unshipped and
${PN}-leftovers to distinguish those intentional vs missed cases.

> regards,

> Koen

-- 
Best regards,
 Paul                            mailto:pmiscml at gmail.com




From hacker at klever.net  Wed May  9 11:43:32 2007
From: hacker at klever.net (Michael Krelin)
Date: Wed, 09 May 2007 13:43:32 +0200
Subject: [oe] QA for intentionally unpackaged files
In-Reply-To: <4641A5A2.8050108@dominion.kabel.utwente.nl>
References: <464130FC.7030008@gmail.com>
	<02827798.20070509123821@gmail.com>	<4641A311.4030907@klever.net>
	<4641A5A2.8050108@dominion.kabel.utwente.nl>
Message-ID: <4641B3E4.1020107@klever.net>

> Michael Krelin schreef:
>>>> UNSHIPPED = "${libdir}/libpython2.4.so ${bindir}/smtpd.py"  #reason why
>>>> not package/ship it
>>>         Who exactly will go over all recipes and add such lines?
>> I take it the proposal was that package maintainers should take care of
>> it. Indeed, it would be better if intentionally unpackaged files invoked
>> no QA notice. But I think the solution is either not install them or rm
>> them after installation, depending on installation procedure nature.
> 
> Or we could patch package.bbclass[1] to do:
> 
> PACKAGES += "${PN}-leftovers"
> FILES_${PN}-leftovers = "/"

I'd rather propose, indeed, packaging the intentional leftovers into a
-leftovers package manually on each package that wants leftovers. But as
you pointed out that there are no valid reasons for files to be
unpackaged, I'm sure it's possible to come up with more meaningful name
for -leftovers package in each particular case. And before files are
packaged QA notice stays QA notice, because it *is* QA issue ;-)


Love,
H



From hacker at klever.net  Wed May  9 11:51:51 2007
From: hacker at klever.net (Michael Krelin)
Date: Wed, 09 May 2007 13:51:51 +0200
Subject: [oe] QA for intentionally unpackaged files
In-Reply-To: <818235002.20070509143709@gmail.com>
References: <464130FC.7030008@gmail.com>
	<02827798.20070509123821@gmail.com>	<4641A311.4030907@klever.net>	<4641A5A2.8050108@dominion.kabel.utwente.nl>	<4641A902.6020506@gmail.com>	<4641AFCB.6080203@dominion.kabel.utwente.nl>
	<818235002.20070509143709@gmail.com>
Message-ID: <4641B5D7.2070406@klever.net>

> 
>         But I agree that catch-all package is better idea than another
> adhoc var. Except that we probably should add ${PN}-unshipped and
> ${PN}-leftovers to distinguish those intentional vs missed cases.
> 

How would any catch-all solution actually differ from disabling QA
notice? Except for that you'd be able to install these leftovers.

Love,
H



From cailotto at sci.univr.it  Wed May  9 15:59:38 2007
From: cailotto at sci.univr.it (Stefano Cailotto)
Date: Wed, 9 May 2007 17:59:38 +0200
Subject: [oe]  OE on Kontron eb425
Message-ID: <001f01c79253$0bf2c970$38f21b9d@kai>

Hello Leon, 
I've extracted kontron modifications with a diff between their shipped
kernel and a fresh one.
I don't know if it is possible to flash even the bootloader...
Looking a bit into source code, there are several kontron patches both for
drivers and kernel boot.
I'm trying to KOntron kernel into OE using Kontron toolchain, but without
success..

Hello Stefano,

On 5/4/07, Stefano Cailotto <cailotto at sci.univr.it> wrote:
> Hi all,
> I'm trying to build something usable for a kontron eb425 board, based on
an
> intel ixp425.
> I tried to compile using a generic ixp4xxbe, but when loading, the kernel
> stops after uncompressing reporting a CRC error.
> It seems that Kontron EmbeddedLinux development kit performs something on
> the kernel before making zImage in order to load it in a specifed memory
> location.
>
There are some IXP42x users on OE, mostly for the NSLU device from
Linksys/Cisco, the Intel dev board (IXDP425) and some custom boards,
but I have not see the Kontron board yet.

With the reported problem, it would help if you understand or at least
could tell where to find the details on the boot loader.

Ideally, you would want to boot loader to be buildable from source
instead of relying on some binary on flash.

Regards,

Leon.

---------------------------------------------------------------------------
  Stefano Cailotto - Research Consultant
---------------------------------------------------------------------------
  EDALab - Networked Embedded Systems
  c/o  Dipartimento di Informatica - Universita` di Verona
  Strada le Grazie, 15 - 37134 Verona (Italy)
---------------------------------------------------------------------------
  email: cailotto at sci.univr.it stefano.cailotto at edalab.it      
  web:  http://www.edalab.it
  tel: +39-045-802-7062 fax: +39-045-802-7068
---------------------------------------------------------------------------




From rodrigo.vivi at gmail.com  Wed May  9 19:44:09 2007
From: rodrigo.vivi at gmail.com (Rodrigo Vivi)
Date: Wed, 9 May 2007 16:44:09 -0300
Subject: [oe] generating debian source packages (dsc)
In-Reply-To: <432beae0705021338x7ca36c0oc937a6b1b03f6db5@mail.gmail.com>
References: <bdb0025f0705021104x23d2c407rb4da0e48e24eb911@mail.gmail.com>
	<200705022051.03720.openembedded@hrw.one.pl>
	<bdb0025f0705021252w7e32b305ybf9c914c1cb1edc0@mail.gmail.com>
	<432beae0705021338x7ca36c0oc937a6b1b03f6db5@mail.gmail.com>
Message-ID: <bdb0025f0705091244u19ce0129h957f9c34154454f0@mail.gmail.com>

I'm trying to use inherit sourcepkg without success.
Does anybody has any suggestion about the following error?

NOTE: package shasum-native-1.0: started
NOTE: package shasum-native-1.0-r1: task do_create_orig_tgz: started
NOTE: <type 'exceptions.IndexError'>:list index out of range while evaluating:

        mkdir -p /indt/mamona/openembedded/tmp/deploy/source
        cd /indt/mamona/openembedded/tmp/work/shasum-native-1.0-r1
        for i in .pc autom4te.cache; do
                echo $i >> temp/exclude-from-file
        done

        src_tree=${@get_src_tree(d)}

        echo $src_tree
        oenote "Creating .orig.tar.gz in
/indt/mamona/openembedded/tmp/deploy/source/shasum-native-1.0.orig.tar.gz"
        tar cvzf
/indt/mamona/openembedded/tmp/deploy/source/shasum-native-1.0.orig.tar.gz
--exclude-from temp/exclude-from-file $src_tree
        cp -pPR $src_tree $src_tree.orig

NOTE: <type 'exceptions.IndexError'>:list index out of range while evaluating:

        cd /indt/mamona/openembedded/tmp/work/shasum-native-1.0-r1
        for i in .pc autom4te.cache; do
                echo $i >> temp/exclude-from-file
        done


        src_tree=${@get_src_tree(d)}

        for i in `find . -maxdepth 1 -type f`; do
                mkdir -p $src_tree/mamona/files
                cp $i $src_tree/mamona/files
        done

        oenote "Creating .diff.gz in
/indt/mamona/openembedded/tmp/deploy/source/shasum-native-1.0-r1.diff.gz"
        LC_ALL=C TZ=UTC0 diff --exclude-from=temp/exclude-from-file
-Naur $src_tree.orig $src_tree | gzip -c >
/indt/mamona/openembedded/tmp/deploy/source/shasum-native-1.0-r1.diff.gz
        rm -rf $src_tree.orig

NOTE: <type 'exceptions.IndexError'>:list index out of range while evaluating:

        src_tree=${@get_src_tree(d)}
        dest=/indt/mamona/openembedded/tmp/work/shasum-native-1.0-r1/$src_tree/mamona
        mkdir -p $dest

        cp /indt/mamona/openembedded/org.openembedded.dev/packages/shasum/shasum-native.bb
$dest

ERROR: function do_create_orig_tgz failed
ERROR: log data follows
(/indt/mamona/openembedded/tmp/work/shasum-native-1.0-r1/temp/log.do_create_orig_tgz.6911)
| /indt/mamona/openembedded/tmp/work/shasum-native-1.0-r1/temp/run.do_create_orig_tgz.6911:
line 510: sourcepkg_do_create_orig_tgz: command not found
NOTE: Task failed:
/indt/mamona/openembedded/tmp/work/shasum-native-1.0-r1/temp/log.do_create_orig_tgz.6911
NOTE: package shasum-native-1.0-r1: task do_create_orig_tgz: failed
ERROR: TaskFailed event exception, aborting
NOTE: package shasum-native-1.0: failed


On 5/2/07, Justin Patrin <papercrane at gmail.com> wrote:
> On 5/2/07, Rodrigo Vivi <rodrigo.vivi at gmail.com> wrote:
> > > classes/sourcepkg.bbclass is something which you want to extend
> >
> > I've thought about it but I'm not sure that it is a good idea because
> > just few projects (or just mine) needs the dsc file .......... unless
> > that I code another sourcedsc.bbclass that inherit the
> > sourcedpkg.bbclass... o you think that it will work???  I'll think
> > about it...
> >
>
> Yes, this is what Marcin meant. Create your own sourcedsc.bbclass
> which inherits sourcepkg.bbclass. This is how, for example,
> efl.bbclass and e.bbclass work.
>
> > Another doubt that I forgot to mention on last email is about changelog:
> > I'm generating a almost empty changelog file. Is there any official
> > and/or more appropriated way to do that?
> >
> > Thanks,
> > Vivi.
> >
> > >
> > > --
> > > JID: hrw-jabber.org
> > > OpenEmbedded developer/consultant
> > >
> > >       I'm trying to decide if I should kill you or simply feign death
> > >       until you feel awkward and leave.
> > >
> > >
> > >
> > > _______________________________________________
> > > Openembedded-devel mailing list
> > > Openembedded-devel at lists.openembedded.org
> > > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> > >
> >
> > _______________________________________________
> > Openembedded-devel mailing list
> > Openembedded-devel at lists.openembedded.org
> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> >
>
>
> --
> Justin Patrin
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>



From pmiscml at gmail.com  Thu May 10 15:00:54 2007
From: pmiscml at gmail.com (Paul Sokolovsky)
Date: Thu, 10 May 2007 18:00:54 +0300
Subject: [oe] Making /var/lib persistent
In-Reply-To: <20070419014949.GA6540@twibble.org>
References: <1176760923.4623f25b913f9@dominion.kabel.utwente.nl>
	<20070418090235.GA21841@twibble.org>
	<46262A0F.1050805@dominion.kabel.utwente.nl>
	<20070419014949.GA6540@twibble.org>
Message-ID: <31583224.20070510180054@gmail.com>

Hello Jamie,

Thursday, April 19, 2007, 4:49:50 AM, you wrote:

> On Wed, Apr 18, 2007 at 07:24:15AM -0700, Koen Kooi wrote:
> [...]
>> Sound like a good idea, do you have a patch for this?

> Try this out:

>   http://twibble.org/dist/oe/var-volatiles-1.patch

> I've tested it locally both with and without tmpfs mounted on
> /var/volatile and all seems to work as expected.

        Any news on this? I've been running with this patch soon since
its original post and don't see any issues. One small nuisance is that
ls -l /var/log doesn't show what you want, but hardly something can be
done about that, plus shell completion uses /var/log/ immediately.

        I suggest committing this patch.

[]

-- 
Best regards,
 Paul                            mailto:pmiscml at gmail.com




From koen at dominion.kabel.utwente.nl  Thu May 10 19:23:30 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Thu, 10 May 2007 21:23:30 +0200
Subject: [oe] Making /var/lib persistent
In-Reply-To: <31583224.20070510180054@gmail.com>
References: <1176760923.4623f25b913f9@dominion.kabel.utwente.nl>	<20070418090235.GA21841@twibble.org>	<46262A0F.1050805@dominion.kabel.utwente.nl>	<20070419014949.GA6540@twibble.org>
	<31583224.20070510180054@gmail.com>
Message-ID: <46437132.1060303@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Paul Sokolovsky schreef:
> Hello Jamie,
> 
> Thursday, April 19, 2007, 4:49:50 AM, you wrote:
> 
>> On Wed, Apr 18, 2007 at 07:24:15AM -0700, Koen Kooi wrote:
>> [...]
>>> Sound like a good idea, do you have a patch for this?
> 
>> Try this out:
> 
>>   http://twibble.org/dist/oe/var-volatiles-1.patch
> 
>> I've tested it locally both with and without tmpfs mounted on
>> /var/volatile and all seems to work as expected.
> 
>         Any news on this? I've been running with this patch soon since
> its original post and don't see any issues. One small nuisance is that
> ls -l /var/log doesn't show what you want, but hardly something can be
> done about that, plus shell completion uses /var/log/ immediately.
> 
>         I suggest committing this patch.

same here.

regards,

Koen

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGQ3EyMkyGM64RGpERAoBNAJ4uabEzcebJd5+x/dtQAKTfYMI8oQCgrza3
buax9m6pqJ+/DZfchJcjlvA=
=hzmX
-----END PGP SIGNATURE-----



From rpurdie at rpsys.net  Thu May 10 23:06:11 2007
From: rpurdie at rpsys.net (Richard Purdie)
Date: Fri, 11 May 2007 00:06:11 +0100
Subject: [oe] Making /var/lib persistent
In-Reply-To: <31583224.20070510180054@gmail.com>
References: <1176760923.4623f25b913f9@dominion.kabel.utwente.nl>
	<20070418090235.GA21841@twibble.org>
	<46262A0F.1050805@dominion.kabel.utwente.nl>
	<20070419014949.GA6540@twibble.org> <31583224.20070510180054@gmail.com>
Message-ID: <1178838371.20362.2.camel@localhost.localdomain>

On Thu, 2007-05-10 at 18:00 +0300, Paul Sokolovsky wrote:
> Hello Jamie,
> 
> Thursday, April 19, 2007, 4:49:50 AM, you wrote:
> 
> > On Wed, Apr 18, 2007 at 07:24:15AM -0700, Koen Kooi wrote:
> > [...]
> >> Sound like a good idea, do you have a patch for this?
> 
> > Try this out:
> 
> >   http://twibble.org/dist/oe/var-volatiles-1.patch
> 
> > I've tested it locally both with and without tmpfs mounted on
> > /var/volatile and all seems to work as expected.
> 
>         Any news on this? I've been running with this patch soon since
> its original post and don't see any issues. One small nuisance is that
> ls -l /var/log doesn't show what you want, but hardly something can be
> done about that, plus shell completion uses /var/log/ immediately.
> 
>         I suggest committing this patch.

The idea sounded sane to me when I read about it so if its working, I
say go for it...

Cheers,

Richard




From pmiscml at gmail.com  Fri May 11 17:00:05 2007
From: pmiscml at gmail.com (Paul Sokolovsky)
Date: Fri, 11 May 2007 20:00:05 +0300
Subject: [oe] [ALERT] Security vulnerability with recent OE bitbake.conf
	changes
In-Reply-To: <127969848.20070508161103@gmail.com>
References: <35653307.20070503154732@gmail.com>
	<1178198199.6312.30.camel@localhost.localdomain>
	<127969848.20070508161103@gmail.com>
Message-ID: <1353801661.20070511200005@gmail.com>

Hello,

Tuesday, May 8, 2007, 4:11:03 PM:

> Hello Richard,

> Thursday, May 3, 2007, 4:16:39 PM, you wrote:

> []

>> So we need to find the real problem and fix that, probably somewhere in
>> patch.bbclass an error code isn't being propagated at a guess.

>         Ok, so here we go:
> http://bugs.openembedded.org/show_bug.cgi?id=2274

        This was committed, as well as PATCHRESOLVE set to "noop" by
default.

[]

-- 
Best regards,
 Paul                            mailto:pmiscml at gmail.com




From tom at openhardware.net  Fri May 11 17:45:47 2007
From: tom at openhardware.net (Tom Walsh)
Date: Fri, 11 May 2007 13:45:47 -0400
Subject: [oe] do_rootfs fails
Message-ID: <4644ABCB.6080202@openhardware.net>

Ok, I admit it, I am totally confused by this whole "debian", 
"multimachine", "package_ipk" stuff.  I've been able to avoid 
understanding this and think that this might be why bootstrap.image 
won't build a filesystem image.

Prior to a month ago, I was using my own task + image bb files to build 
my image.  Since a lot of work has been done to make the task-base more 
generic, I have moved my project over to using the stock 
bootstrap-image.bb and task-base.bb files.  However, it fails to build 
properly.

When running a "bitbake bootstrap-image", everything builds but then 
fails with:

========= begin ============
[tom at jtag oezipit]$ bitbake bootstrap-image
NOTE: Using cache in '/home/tom/oezipit/tmp/cache/zipit'
NOTE: Handling BitBake files: \ (4534/4534) [100 %]
NOTE: Parsing finished. 4329 cached, 0 parsed, 205 skipped, 0 masked.

NOTE: build 200705111324: started

OE Build Configuration:
BB_VERSION     = "1.6.7"
OE_REVISION    = "<unknown>"
TARGET_ARCH    = "arm"
TARGET_OS      = "linux"
MACHINE        = "zipit"
DISTRO         = "zipit"
DISTRO_VERSION = "1.0"
TARGET_FPU     = "soft"

NOTE: multiple providers are available (db3, db);
NOTE: consider defining PREFERRED_PROVIDER_virtual/db
NOTE: multiple providers are available (db3-native, db-native);
NOTE: consider defining PREFERRED_PROVIDER_virtual/db-native
NOTE: package bootstrap-image-1.0: started
NOTE: package bootstrap-image-1.0-r0: task do_rootfs: started
ERROR: function do_rootfs failed
ERROR: see log in 
/home/tom/oezipit/tmp/work/zipit-linux/bootstrap-image-1.0-r0/temp/log.do_rootfs.17150
NOTE: Task failed: 
/home/tom/oezipit/tmp/work/zipit-linux/bootstrap-image-1.0-r0/temp/log.do_rootfs.17150
NOTE: package bootstrap-image-1.0-r0: task do_rootfs: failed
ERROR: TaskFailed event exception, aborting
NOTE: package bootstrap-image-1.0: failed
ERROR: Build of bootstrap-image failed
========= snip =============

When I check the logfile, it says that "sh: fakeroot: command not 
found".  This is correct, fakeroot-native has NOT been built.  So, I do 
a "bitbake -c rebuild fakeroot-native", then run "bitbake 
bootstrap-image" again.

It then fails with a logfile message of 
"/home/tom/oezipit/tmp/work/zipit-linux/bootstrap-image-1.0-r0/temp/run.do_rootfs.24175: 
line 312: ipkg-cl: command not found".  Again, this is true, ipkg-native 
is not present.  So, I do a "bitbake -c rebuild ipkg-native", then run 
"bitbake bootstrap-image" again.

Now it builds the filesystem target tarball image.

How can I automate those needs for fakeroot-native and ipkg-native?  I'm 
not sure where to look, this was working a few weeks ago.

Regards,

TomW





-- 
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net http://cyberiansoftware.com http://openzipit.org
"Windows? No thanks, I have work to do..."
----------------------------------------------------





From koen at dominion.kabel.utwente.nl  Fri May 11 18:07:14 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Fri, 11 May 2007 20:07:14 +0200
Subject: [oe] do_rootfs fails
In-Reply-To: <4644ABCB.6080202@openhardware.net>
References: <4644ABCB.6080202@openhardware.net>
Message-ID: <4644B0D2.8020409@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tom Walsh schreef:

<snip problem description>

> OE Build Configuration:
> BB_VERSION     = "1.6.7"

Tom: Upgrade to 1.8.2 or use the bitbake-1.8 branch (1.8.3 atm).
All: Are we still going to wait 1.5 months with requiring 1.8.x? I've seen enough proof
that 1.6.x is broken with current .dev, with no effort to fix it. "Giving people time to
prepare the upgrade" has now turned into "Stabbing user in the eye" :(

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGRLDRMkyGM64RGpERAm1ZAKCBtqmqLrk3MXEPldP9AvEjxxJSsACggk//
FJLY3HdrD/EF2xvBzEOJvts=
=qgbE
-----END PGP SIGNATURE-----



From hacker at klever.net  Fri May 11 18:24:17 2007
From: hacker at klever.net (Michael Krelin)
Date: Fri, 11 May 2007 20:24:17 +0200
Subject: [oe] do_rootfs fails
In-Reply-To: <4644B0D2.8020409@dominion.kabel.utwente.nl>
References: <4644ABCB.6080202@openhardware.net>
	<4644B0D2.8020409@dominion.kabel.utwente.nl>
Message-ID: <4644B4D1.5010803@klever.net>

> All: Are we still going to wait 1.5 months with requiring 1.8.x? I've seen enough proof
> that 1.6.x is broken with current .dev, with no effort to fix it. "Giving people time to
> prepare the upgrade" has now turned into "Stabbing user in the eye" :(

There's also an option of asking Tom to bitbake -DDD and send it to
zecke, because I couldn't find time to try BB 1.6 for him again. And let
him apply the patch that fixes this problem:

Index: lib/bb/parse/parse_py/BBHandler.py
===================================================================
--- lib/bb/parse/parse_py/BBHandler.py  (revision 817)
+++ lib/bb/parse/parse_py/BBHandler.py  (working copy)
@@ -66,7 +66,9 @@
         if not file in __inherit_cache.split():
             debug(2, "BB %s:%d: inheriting %s" % (fn, lineno, file))
             __inherit_cache += " %s" % file
+            data.setVar('__inherit_cache', __inherit_cache, d)
             include(fn, file, d)
+            __inherit_cache = data.getVar('__inherit_cache', d) or ""
     data.setVar('__inherit_cache', __inherit_cache, d)

Love,
H



From oe at hentges.net  Sat May 12 00:07:53 2007
From: oe at hentges.net (Matthias Hentges)
Date: Sat, 12 May 2007 02:07:53 +0200
Subject: [oe] do_rootfs fails
In-Reply-To: <4644B0D2.8020409@dominion.kabel.utwente.nl>
References: <4644ABCB.6080202@openhardware.net>
	<4644B0D2.8020409@dominion.kabel.utwente.nl>
Message-ID: <1178928474.4954.18.camel@localhost.localdomain>

Am Freitag, den 11.05.2007, 20:07 +0200 schrieb Koen Kooi:

> All: Are we still going to wait 1.5 months with requiring 1.8.x? I've seen enough proof
> that 1.6.x is broken with current .dev, with no effort to fix it. "Giving people time to
> prepare the upgrade" has now turned into "Stabbing user in the eye" :(
> 
> regards,
> 
> Koen

1.8.x has a show-stopper freeze-bug for some users ( including myself )
which has not been fixed or even looked into yet.

-- 
Matthias 'CoreDump' Hentges 
Cologne / Germany

Webmaster of Hentges.net & Embedded Linux Developer
GPG ->  gpg --keyserver gpg-keyserver.de --recv-keys 0xAF3030D9

My OS: Debian SID: Geek by Nature, Linux by Choice


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
URL: <http://lists.openembedded.org/pipermail/openembedded-devel/attachments/20070512/d00d0d5a/attachment-0001.sig>

From koen at dominion.kabel.utwente.nl  Sat May 12 10:28:21 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Sat, 12 May 2007 12:28:21 +0200
Subject: [oe] do_rootfs fails
In-Reply-To: <1178928474.4954.18.camel@localhost.localdomain>
References: <4644ABCB.6080202@openhardware.net>	<4644B0D2.8020409@dominion.kabel.utwente.nl>
	<1178928474.4954.18.camel@localhost.localdomain>
Message-ID: <464596C5.8010303@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Matthias Hentges schreef:
> Am Freitag, den 11.05.2007, 20:07 +0200 schrieb Koen Kooi:
> 
>> All: Are we still going to wait 1.5 months with requiring 1.8.x? I've seen enough proof
>> that 1.6.x is broken with current .dev, with no effort to fix it. "Giving people time to
>> prepare the upgrade" has now turned into "Stabbing user in the eye" :(
>>
>> regards,
>>
>> Koen
> 
> 1.8.x has a show-stopper freeze-bug for some users ( including myself )
> which has not been fixed or even looked into yet.

bugnumber?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGRZbFMkyGM64RGpERAlj8AJ9RQ0xtk2nqZAlJloTFFM5j8ml2zACghM87
qvk0yLeJrlqNyZHCtfub4Xo=
=Z1MH
-----END PGP SIGNATURE-----



From koen at dominion.kabel.utwente.nl  Sat May 12 19:21:23 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Sat, 12 May 2007 21:21:23 +0200
Subject: [oe] uclibc 0.9.29 recipe
Message-ID: <464613B3.8090003@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,


I just started working on a uclibc 0.9.29 recipe, are people interested in it already, or
should I finish it before committing it (with DEFAULT_PREF = -1)?

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGRhOzMkyGM64RGpERAlBJAKC4Hekdx6iKB95Nglwt4elr/scvqQCggdgo
b0a0iWs5X06ZAMKRzYUfKlg=
=S7Cp
-----END PGP SIGNATURE-----



From lpotter at trolltech.com  Sat May 12 19:54:27 2007
From: lpotter at trolltech.com (Lorn Potter)
Date: Sun, 13 May 2007 05:54:27 +1000
Subject: [oe] uclibc 0.9.29 recipe
In-Reply-To: <464613B3.8090003@dominion.kabel.utwente.nl>
References: <464613B3.8090003@dominion.kabel.utwente.nl>
Message-ID: <46461B73.8070900@trolltech.com>



Koen Kooi wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi,
> 
> 
> I just started working on a uclibc 0.9.29 recipe, are people interested in it already, or
> should I finish it before committing it (with DEFAULT_PREF = -1)?
> 
> regards,

I would be, especially if it worked in an angstrom build.



-- 
Lorn 'ljp' Potter
Software Engineer, Systems Group, MES, Trolltech



From lpotter at trolltech.com  Sat May 12 19:54:27 2007
From: lpotter at trolltech.com (Lorn Potter)
Date: Sun, 13 May 2007 05:54:27 +1000
Subject: [oe] uclibc 0.9.29 recipe
In-Reply-To: <464613B3.8090003@dominion.kabel.utwente.nl>
References: <464613B3.8090003@dominion.kabel.utwente.nl>
Message-ID: <46461B73.8070900@trolltech.com>



Koen Kooi wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi,
> 
> 
> I just started working on a uclibc 0.9.29 recipe, are people interested in it already, or
> should I finish it before committing it (with DEFAULT_PREF = -1)?
> 
> regards,

I would be, especially if it worked in an angstrom build.



-- 
Lorn 'ljp' Potter
Software Engineer, Systems Group, MES, Trolltech



From koen at dominion.kabel.utwente.nl  Sat May 12 20:02:58 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Sat, 12 May 2007 22:02:58 +0200
Subject: [oe] uclibc 0.9.29 recipe
In-Reply-To: <46461B73.8070900@trolltech.com>
References: <464613B3.8090003@dominion.kabel.utwente.nl>
	<46461B73.8070900@trolltech.com>
Message-ID: <46461D72.4020206@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Lorn Potter schreef:
> 
> Koen Kooi wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Hi,
>>
>>
>> I just started working on a uclibc 0.9.29 recipe, are people interested in it already, or
>> should I finish it before committing it (with DEFAULT_PREF = -1)?
>>
>> regards,
> 
> I would be, especially if it worked in an angstrom build.

I'll add it once I solved the linux-libc-headers problems. Machine and distro maintainers
need to provide their parts of the uclibc configs to make it usefull, though.

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGRh1yMkyGM64RGpERApzPAJ9dHfEynAkjYtpvJC6aKwcSLcF1PQCggceU
2wDlG7EN1RNSwOJ8YjfCItk=
=Un//
-----END PGP SIGNATURE-----



From koen at dominion.kabel.utwente.nl  Sat May 12 21:04:29 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Sat, 12 May 2007 23:04:29 +0200
Subject: [oe] uclibc 0.9.29 recipe
In-Reply-To: <46461D72.4020206@dominion.kabel.utwente.nl>
References: <464613B3.8090003@dominion.kabel.utwente.nl>	<46461B73.8070900@trolltech.com>
	<46461D72.4020206@dominion.kabel.utwente.nl>
Message-ID: <46462BDD.6000302@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Koen Kooi schreef:
> Lorn Potter schreef:
>> Koen Kooi wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> Hi,
>>>
>>>
>>> I just started working on a uclibc 0.9.29 recipe, are people interested in it already, or
>>> should I finish it before committing it (with DEFAULT_PREF = -1)?
>>>
>>> regards,
>> I would be, especially if it worked in an angstrom build.
> 
> I'll add it once I solved the linux-libc-headers problems. 

Which is non-existant on 0.9.29 :)


> Machine and distro maintainers
> need to provide their parts of the uclibc configs to make it usefull, though.

Angstrom has a uClibc.distro and ixp4xxbe has a uClibc.machine.

To add support for your favourite machine: use uClibc.distro as .config, configure uclibc
for the target you want, save the top 2 blocks of .config (cpu and arch) to uClibc.distro
in uclibc-0.9.29/<machine/uClibc.machine

The recipe is by no means perfect, so any help is welcome.

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGRivdMkyGM64RGpERAoVVAKCCVsINF5WmH0XnnbpCF0oMo15sfACePayI
7vnmpum3r/QkizvA4HinAzc=
=R235
-----END PGP SIGNATURE-----



From skoroneos at digital-opsis.com  Sat May 12 21:19:03 2007
From: skoroneos at digital-opsis.com (Stelios Koroneos)
Date: Sun, 13 May 2007 00:19:03 +0300
Subject: [oe] minimal-image.bb
In-Reply-To: <46461D72.4020206@dominion.kabel.utwente.nl>
Message-ID: <HOECLKEKOHLAMMGDLLBHOECKLAAA.skoroneos@digital-opsis.com>

Greetings to all !

Recently it was made apparent that bootstrap-image was generating images
that could not fit in flash restricted devices (<=4MB)
Koen has pushed angstrom-minimal-image which uses task-boot and as a result
generates images significally smaller.(800K in a jffs2 fs)

The only drawback into this (IMHO) is in the naming of the package.
Adding a distro name infront of an image package gives the impression that
this is distro specific and not a "generic" one.
I tried to push to the rep a more "generic" minimal-image.bb which was
almost identical to angstrom-minima-image but Koen had  dis-approved the
commit as duplicate.

In my opinion if angstrom-minimal-image is not distro specific should be
renamed to minimal-image or if it is distro specific a minimal-image.bb
should be created.

I discussed the matter with Koen on irc but we could not come to a
conlusion, so i am asking for the opinions of others on this, as i believe
is a issue which has to be solved to avoid any future problems.



Stelios S. Koroneos

Digital OPSiS - Embedded Intelligence
http://www.digital-opsis.com







From skoroneos at digital-opsis.com  Sat May 12 21:33:31 2007
From: skoroneos at digital-opsis.com (Stelios Koroneos)
Date: Sun, 13 May 2007 00:33:31 +0300
Subject: [oe] do_rootfs fails
In-Reply-To: <4644B4D1.5010803@klever.net>
Message-ID: <HOECLKEKOHLAMMGDLLBHOECLLAAA.skoroneos@digital-opsis.com>

Had the same problem as i am still using 1.6 .
The mentioned patch solved it

Stelios S. Koroneos

Digital OPSiS - Embedded Intelligence
http://www.digital-opsis.com


> -----Original Message-----
> From: openembedded-devel-bounces at openembedded.org 
> [mailto:openembedded-devel-bounces at openembedded.org]On Behalf Of 
> Michael Krelin
> Sent: Friday, May 11, 2007 9:24 PM
> To: openembedded-devel at openembedded.org
> Subject: Re: [oe] do_rootfs fails
> 
> 
> > All: Are we still going to wait 1.5 months with requiring 
> 1.8.x? I've seen enough proof
> > that 1.6.x is broken with current .dev, with no effort to fix 
> it. "Giving people time to
> > prepare the upgrade" has now turned into "Stabbing user in the eye" :(
> 
> There's also an option of asking Tom to bitbake -DDD and send it to
> zecke, because I couldn't find time to try BB 1.6 for him again. And let
> him apply the patch that fixes this problem:
> 
> Index: lib/bb/parse/parse_py/BBHandler.py
> ===================================================================
> --- lib/bb/parse/parse_py/BBHandler.py  (revision 817)
> +++ lib/bb/parse/parse_py/BBHandler.py  (working copy)
> @@ -66,7 +66,9 @@
>          if not file in __inherit_cache.split():
>              debug(2, "BB %s:%d: inheriting %s" % (fn, lineno, file))
>              __inherit_cache += " %s" % file
> +            data.setVar('__inherit_cache', __inherit_cache, d)
>              include(fn, file, d)
> +            __inherit_cache = data.getVar('__inherit_cache', d) or ""
>      data.setVar('__inherit_cache', __inherit_cache, d)
> 
> Love,
> H
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> 




From dp at xora.org.uk  Sun May 13 12:25:49 2007
From: dp at xora.org.uk (Graeme Gregory)
Date: Sun, 13 May 2007 13:25:49 +0100
Subject: [oe] RFC: Bugzilla CC Field
Message-ID: <1179059149.5404.3.camel@cimmeria.hyboria>

RFC

Dont add people to CC field of bugs without talking to them.

Recently I am finding myself added as CC to bugs I have no interest in
as I either don't have the hardware or don't use the software in
question.

Everyone on oe-issues list gets all bug reports anyway and I can use web
search quite effectively myself.

Graeme (XorA)





From koen at dominion.kabel.utwente.nl  Sun May 13 14:29:35 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Sun, 13 May 2007 16:29:35 +0200
Subject: [oe] RFC: Bugzilla CC Field
In-Reply-To: <1179059149.5404.3.camel@cimmeria.hyboria>
References: <1179059149.5404.3.camel@cimmeria.hyboria>
Message-ID: <464720CF.4030801@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Graeme Gregory schreef:
> RFC
> 
> Dont add people to CC field of bugs without talking to them.
> 
> Recently I am finding myself added as CC to bugs I have no interest in
> as I either don't have the hardware or don't use the software in
> question.
> 
> Everyone on oe-issues list gets all bug reports anyway and I can use web
> search quite effectively myself.

Same here, and I was suggested to just turn off all email in the bugzilla userprefs.

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGRyDPMkyGM64RGpERAmzyAJ4lfF/HAeoRx0k/Kn+jXme1ed8xOwCdGr+V
yEXpOXkev8SZFGHcxLqP5pw=
=bROF
-----END PGP SIGNATURE-----



From no2spam at nospam.arcornews.de  Sun May 13 14:33:06 2007
From: no2spam at nospam.arcornews.de (Rolf Leggewie)
Date: Sun, 13 May 2007 16:33:06 +0200
Subject: [oe] RFD: Bugzilla in general & bug triaging
In-Reply-To: <1179059149.5404.3.camel@cimmeria.hyboria>
References: <1179059149.5404.3.camel@cimmeria.hyboria>
Message-ID: <f277j3$i00$1@sea.gmane.org>

Graeme Gregory wrote:
> RFC
> 
> Dont add people to CC field of bugs without talking to them.

Thank you Graeme for raising this issue.  It is something I meant to 
discuss earlier but never found enough time to think it through and 
write up something.  I still have not thought it through, but here it goes.

Let me first say, that I am totally aware that we are all doing this in 
our limited free time.  We also all don't like things being stuffed down 
our throat.  There is a bit of dilemma here.

As a non-dev, I feel one of the better ways for me and others alike is 
to make sure the BTS is in good shape.  It is called bug triaging which 
I also do in other projects.  For me, this is all about efficiency, 
division of labor so to speak (although that capitalistic thinking might 
not go down too well with all of us freeminds ;-))  The idea is that 
there is someone who sifts through the bug reports and makes sure they 
are understandable, complete and real.  The triager also crosslinks bugs 
that share similarities and classifies them.   All this *before they eat 
up valuable time from a real dev*.  That is at least what I am trying to 
do, for the devs to sit down and find well-structured problems to work 
on whenever they feel like it (I know the OE BTS is not there yet, bug 
2194 is a shy start at this).

This is how Ubuntu and Mozilla approach the bugs they receive.  But it 
needs a way to signal "Hey, this bug is OK" and furthermore bugs are 
usually assigned to the most appropriate person.  So that is what I did 
first, assign bugs to the people I thought would be most appropriate in 
dealing with them.  That did not go down so well :-)  So, it was 
suggested to me that instead of assigning, I should cc people.  But that 
is certainly not the best solution, either.

I believe it would be great if OE started some kind of not too rigid 
process of triaging bugs.  All projects are a bit different, so what do 
you think would be the best way for OE to handle this?

 > Everyone on oe-issues list gets all bug reports anyway and I can use
 > web search quite effectively myself.

Graeme, I understand your concern.  I don't mean to say "Hey, here is 
the solution" but maybe there are some options you might consider.

First is that I would think that it might be a waste of valuable dev 
time if all core devs read all bug reports on oe-issues.  Of course, 
that is an individual decision.  But if we got something like bug 
triaging going in a more instituationalized way, it might indeed become 
unnecessary.  Second, bugzilla offers many settings on what mails you 
want to receive and which you don't at 
http://bugs.openembedded.org/userprefs.cgi?tab=email.  If you read 
oe-issues, you might want to consider deactivating all mail from 
bugzilla itself to keep the load down.




From no2spam at nospam.arcornews.de  Sun May 13 14:35:12 2007
From: no2spam at nospam.arcornews.de (Rolf Leggewie)
Date: Sun, 13 May 2007 16:35:12 +0200
Subject: [oe] minimal-image.bb
In-Reply-To: <HOECLKEKOHLAMMGDLLBHOECKLAAA.skoroneos@digital-opsis.com>
References: <46461D72.4020206@dominion.kabel.utwente.nl>
	<HOECLKEKOHLAMMGDLLBHOECKLAAA.skoroneos@digital-opsis.com>
Message-ID: <f277n0$i00$2@sea.gmane.org>

Stelios Koroneos wrote:
> In my opinion if angstrom-minimal-image is not distro specific should be
> renamed to minimal-image

I agree with Stelios that the belief that angstrom-minimal-image is a 
distro-specific image is a reasonable assumption.  If that is not the 
case, I am in favor renaming.




From koen at dominion.kabel.utwente.nl  Sun May 13 15:02:17 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Sun, 13 May 2007 17:02:17 +0200
Subject: [oe] RFD: Bugzilla in general & bug triaging
In-Reply-To: <f277j3$i00$1@sea.gmane.org>
References: <1179059149.5404.3.camel@cimmeria.hyboria>
	<f277j3$i00$1@sea.gmane.org>
Message-ID: <46472879.7070804@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Rolf Leggewie schreef:

> First is that I would think that it might be a waste of valuable dev 
> time if all core devs read all bug reports on oe-issues. 

Personally, I treat oe-issues the same as oe-commits, by just skimming through the
subjects and reading ones that trigger some sort of red flag.

regards,

Koen

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGRyh5MkyGM64RGpERAih1AKCSCjkbNYMQKvz5uGBlSC4kJUFCuwCdH/ZS
dxXPFRHDlbpXplCWROFMuN8=
=rrgr
-----END PGP SIGNATURE-----



From pmiscml at gmail.com  Sun May 13 15:15:30 2007
From: pmiscml at gmail.com (Paul Sokolovsky)
Date: Sun, 13 May 2007 18:15:30 +0300
Subject: [oe] RFD: Bugzilla in general & bug triaging
In-Reply-To: <f277j3$i00$1@sea.gmane.org>
References: <1179059149.5404.3.camel@cimmeria.hyboria>
	<f277j3$i00$1@sea.gmane.org>
Message-ID: <419056356.20070513181530@gmail.com>

Hello Rolf,

Sunday, May 13, 2007, 5:33:06 PM, you wrote:

> Graeme Gregory wrote:
>> RFC
>> 
>> Dont add people to CC field of bugs without talking to them.

> Thank you Graeme for raising this issue.  It is something I meant to 
> discuss earlier but never found enough time to think it through and 
> write up something.  I still have not thought it through, but here it goes.

> Let me first say, that I am totally aware that we are all doing this in
> our limited free time.  We also all don't like things being stuffed down
> our throat.  There is a bit of dilemma here.

> As a non-dev, I feel one of the better ways for me and others alike is
> to make sure the BTS is in good shape.  It is called bug triaging which
> I also do in other projects.  For me, this is all about efficiency, 
> division of labor so to speak (although that capitalistic thinking might
> not go down too well with all of us freeminds ;-))  The idea is that 
> there is someone who sifts through the bug reports and makes sure they
> are understandable, complete and real.  The triager also crosslinks bugs
> that share similarities and classifies them.   All this *before they eat
> up valuable time from a real dev*.  That is at least what I am trying to
> do, for the devs to sit down and find well-structured problems to work
> on whenever they feel like it (I know the OE BTS is not there yet, bug
> 2194 is a shy start at this).

        I'm sure that I can speak from many peoples' side: your work
and effort on bug management is *much* appreciated. Thanks to you, we
now have *live* bugtracker, not a swamp, which it was just few months
ago.

> This is how Ubuntu and Mozilla approach the bugs they receive.  But it
> needs a way to signal "Hey, this bug is OK" and furthermore bugs are 
> usually assigned to the most appropriate person.  So that is what I did
> first, assign bugs to the people I thought would be most appropriate in
> dealing with them.  That did not go down so well :-)  So, it was 
> suggested to me that instead of assigning, I should cc people.  But that
> is certainly not the best solution, either.

> I believe it would be great if OE started some kind of not too rigid 
> process of triaging bugs.  All projects are a bit different, so what do
> you think would be the best way for OE to handle this?

        I guess this can be expressed as:

1. If there's a confirmed bugtracker manager, whatever he does,
already has good weight in it.
2. There're indeed well-known work flow patterns and best practices,
and those should be rather reused, not ignored.
3. There should be room for improvements and adaption to our specific
case and environment.

        In this regard, I think that current scheme, and your use of
it, is good enough to go with. In particular, I appreciate, and
recommend, that everyone who submits something important (or having
other special criteria) for the area I maintain/watch, to add myself
to cc:, to ensure prompt replies and addition guarantee that important
issues are not lost in awful amount of mail I receive, and don't
depend on not 100% reliable things like my watching bug tracker
notifications.

 >> Everyone on oe-issues list gets all bug reports anyway and I can use
 >> web search quite effectively myself.

> Graeme, I understand your concern.  I don't mean to say "Hey, here is 
> the solution" but maybe there are some options you might consider.

> First is that I would think that it might be a waste of valuable dev 
> time if all core devs read all bug reports on oe-issues.  Of course, 
> that is an individual decision.  But if we got something like bug 
> triaging going in a more instituationalized way, it might indeed become
> unnecessary.  Second, bugzilla offers many settings on what mails you 
> want to receive and which you don't at 
> http://bugs.openembedded.org/userprefs.cgi?tab=email.  If you read 
> oe-issues, you might want to consider deactivating all mail from 
> bugzilla itself to keep the load down.

        I guess this solution is straight into bull's eye - why spend
time communicating your preferences to other people (or, fingers
crossed, quarrel with them), if they instead can be communicated to
Bugzilla, which is there to serve all needs. The same goes for
everyone's best friend, an email client, which has cool things like
folders and filters, and opens their wonders to everyone who wants to
*receive* their mail the way they want, instead of arguing with the
whole world (or arbitrary part of it) how it should send mail to them ;-)


-- 
Best regards,
 Paul                            mailto:pmiscml at gmail.com




From leon.woestenberg at gmail.com  Sun May 13 16:45:04 2007
From: leon.woestenberg at gmail.com (Leon Woestenberg)
Date: Sun, 13 May 2007 18:45:04 +0200
Subject: [oe] uclibc 0.9.29 recipe
In-Reply-To: <46462BDD.6000302@dominion.kabel.utwente.nl>
References: <464613B3.8090003@dominion.kabel.utwente.nl>
	<46461B73.8070900@trolltech.com>
	<46461D72.4020206@dominion.kabel.utwente.nl>
	<46462BDD.6000302@dominion.kabel.utwente.nl>
Message-ID: <c384c5ea0705130945k266d8bccw4f890d99d9997e52@mail.gmail.com>

Hello Koen,

On 5/12/07, Koen Kooi <koen at dominion.kabel.utwente.nl> wrote:
> Koen Kooi schreef:
> To add support for your favourite machine: use uClibc.distro as .config,
> configure uclibc for the target you want, save the top 2 blocks of .config (cpu
> and arch) to uClibc.distro  in uclibc-0.9.29/<machine/uClibc.machine
>
> The recipe is by no means perfect, so any help is welcome.
>
As often, you laid the groundworks, which is often more important than
the make-it-perfect stage.

My hands are twitching to create a clean 0.9.29 .bb that more smartly
configures the library matching the OpenEmbedded configuration. But
let's hack the current setup first.

Who is using uClibc now? In other words, can I break stuff?

Regards,
-- 
Leon



From koen at dominion.kabel.utwente.nl  Sun May 13 16:55:49 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Sun, 13 May 2007 18:55:49 +0200
Subject: [oe] uclibc 0.9.29 recipe
In-Reply-To: <c384c5ea0705130945k266d8bccw4f890d99d9997e52@mail.gmail.com>
References: <464613B3.8090003@dominion.kabel.utwente.nl>	<46461B73.8070900@trolltech.com>	<46461D72.4020206@dominion.kabel.utwente.nl>	<46462BDD.6000302@dominion.kabel.utwente.nl>
	<c384c5ea0705130945k266d8bccw4f890d99d9997e52@mail.gmail.com>
Message-ID: <46474315.1070207@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Leon Woestenberg schreef:
> Hello Koen,
> 
> On 5/12/07, Koen Kooi <koen at dominion.kabel.utwente.nl> wrote:
>> Koen Kooi schreef:
>> To add support for your favourite machine: use uClibc.distro as .config,
>> configure uclibc for the target you want, save the top 2 blocks of .config (cpu
>> and arch) to uClibc.distro  in uclibc-0.9.29/<machine/uClibc.machine
>>
>> The recipe is by no means perfect, so any help is welcome.
>>
> As often, you laid the groundworks, which is often more important than
> the make-it-perfect stage.
> 
> My hands are twitching to create a clean 0.9.29 .bb that more smartly
> configures the library matching the OpenEmbedded configuration. But
> let's hack the current setup first.

It would be nice to set archicture using TARGET_ARCH, endiannes with the info from
siteinfo.bbclass and the the FPU with TARGET_FPU. I bet there are some more options that
could be autoconfigured.

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGR0MVMkyGM64RGpERAmpLAJ40KalkcxFc1oOFNSfOrMB7dypN7gCZAeg4
4C42BTmMvEcIiALtDpSx/eY=
=yp3m
-----END PGP SIGNATURE-----



From leon.woestenberg at gmail.com  Sun May 13 21:39:41 2007
From: leon.woestenberg at gmail.com (Leon Woestenberg)
Date: Sun, 13 May 2007 23:39:41 +0200
Subject: [oe] uclibc 0.9.29 recipe
In-Reply-To: <46474315.1070207@dominion.kabel.utwente.nl>
References: <464613B3.8090003@dominion.kabel.utwente.nl>
	<46461B73.8070900@trolltech.com>
	<46461D72.4020206@dominion.kabel.utwente.nl>
	<46462BDD.6000302@dominion.kabel.utwente.nl>
	<c384c5ea0705130945k266d8bccw4f890d99d9997e52@mail.gmail.com>
	<46474315.1070207@dominion.kabel.utwente.nl>
Message-ID: <c384c5ea0705131439o1a2b71b8i26a16123ae1c591e@mail.gmail.com>

perl 5.8.8 needs:

UCLIBC_SUSV3_LEGACY=y
UCLIBC_SUSV3_LEGACY_MACROS=y



From xjqian at gmail.com  Mon May 14 08:08:03 2007
From: xjqian at gmail.com (Junqian Gordon Xu)
Date: Mon, 14 May 2007 03:08:03 -0500
Subject: [oe] RFD: Bugzilla in general & bug triaging
In-Reply-To: <f277j3$i00$1@sea.gmane.org>
References: <1179059149.5404.3.camel@cimmeria.hyboria>
	<f277j3$i00$1@sea.gmane.org>
Message-ID: <464818E3.7090203@gmail.com>

Rolf,

Is it a problem if I replace the openembedded-issues@ with my email 
address in the Reassign to field? Does openembedded-issues still gets 
all the updates?

I don't want only me receiving the emails even I assign the bug to myself.

regards
Gordon

Rolf Leggewie wrote:
> Graeme Gregory wrote:
>   
>> RFC
>>
>> Dont add people to CC field of bugs without talking to them.
>>     
>
> Thank you Graeme for raising this issue.  It is something I meant to 
> discuss earlier but never found enough time to think it through and 
> write up something.  I still have not thought it through, but here it goes.
>
> Let me first say, that I am totally aware that we are all doing this in 
> our limited free time.  We also all don't like things being stuffed down 
> our throat.  There is a bit of dilemma here.
>
> As a non-dev, I feel one of the better ways for me and others alike is 
> to make sure the BTS is in good shape.  It is called bug triaging which 
> I also do in other projects.  For me, this is all about efficiency, 
> division of labor so to speak (although that capitalistic thinking might 
> not go down too well with all of us freeminds ;-))  The idea is that 
> there is someone who sifts through the bug reports and makes sure they 
> are understandable, complete and real.  The triager also crosslinks bugs 
> that share similarities and classifies them.   All this *before they eat 
> up valuable time from a real dev*.  That is at least what I am trying to 
> do, for the devs to sit down and find well-structured problems to work 
> on whenever they feel like it (I know the OE BTS is not there yet, bug 
> 2194 is a shy start at this).
>
> This is how Ubuntu and Mozilla approach the bugs they receive.  But it 
> needs a way to signal "Hey, this bug is OK" and furthermore bugs are 
> usually assigned to the most appropriate person.  So that is what I did 
> first, assign bugs to the people I thought would be most appropriate in 
> dealing with them.  That did not go down so well :-)  So, it was 
> suggested to me that instead of assigning, I should cc people.  But that 
> is certainly not the best solution, either.
>
> I believe it would be great if OE started some kind of not too rigid 
> process of triaging bugs.  All projects are a bit different, so what do 
> you think would be the best way for OE to handle this?
>
>  > Everyone on oe-issues list gets all bug reports anyway and I can use
>  > web search quite effectively myself.
>
> Graeme, I understand your concern.  I don't mean to say "Hey, here is 
> the solution" but maybe there are some options you might consider.
>
> First is that I would think that it might be a waste of valuable dev 
> time if all core devs read all bug reports on oe-issues.  Of course, 
> that is an individual decision.  But if we got something like bug 
> triaging going in a more instituationalized way, it might indeed become 
> unnecessary.  Second, bugzilla offers many settings on what mails you 
> want to receive and which you don't at 
> http://bugs.openembedded.org/userprefs.cgi?tab=email.  If you read 
> oe-issues, you might want to consider deactivating all mail from 
> bugzilla itself to keep the load down.
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>
>   




From pmiscml at gmail.com  Mon May 14 08:25:58 2007
From: pmiscml at gmail.com (Paul Sokolovsky)
Date: Mon, 14 May 2007 11:25:58 +0300
Subject: [oe] RFD: Bugzilla in general & bug triaging
In-Reply-To: <464818E3.7090203@gmail.com>
References: <1179059149.5404.3.camel@cimmeria.hyboria>
	<f277j3$i00$1@sea.gmane.org> <464818E3.7090203@gmail.com>
Message-ID: <24757045.20070514112558@gmail.com>

Hello Junqian,

Monday, May 14, 2007, 11:08:03 AM, you wrote:

> Rolf,

> Is it a problem if I replace the openembedded-issues@ with my email 
> address in the Reassign to field? Does openembedded-issues still gets 
> all the updates?

        As Rolf described in his mail, we do not reassign bugs in our
workflow - they keep being assigned to ML. That's corresponds to
the fact/reassures that we don't have bug owners in OE, and entire
community welcome to/works on any issue (which in turn is based on the
fact that we don't have dedicated engineers to resolve bugs).

> I don't want only me receiving the emails even I assign the bug to myself.

> regards
> Gordon

> Rolf Leggewie wrote:
[]

-- 
Best regards,
 Paul                            mailto:pmiscml at gmail.com




From xjqian at gmail.com  Mon May 14 08:49:12 2007
From: xjqian at gmail.com (Junqian Gordon Xu)
Date: Mon, 14 May 2007 03:49:12 -0500
Subject: [oe] RFD: Bugzilla in general & bug triaging
In-Reply-To: <24757045.20070514112558@gmail.com>
References: <1179059149.5404.3.camel@cimmeria.hyboria>
	<f277j3$i00$1@sea.gmane.org> <464818E3.7090203@gmail.com>
	<24757045.20070514112558@gmail.com>
Message-ID: <46482288.2040904@gmail.com>

Paul Sokolovsky wrote:
> Hello Junqian,
>
> Monday, May 14, 2007, 11:08:03 AM, you wrote:
>
>   
>> Is it a problem if I replace the openembedded-issues@ with my email 
>> address in the Reassign to field? Does openembedded-issues still gets 
>> all the updates?
>>     
>
>         As Rolf described in his mail, we do not reassign bugs in our
> workflow - they keep being assigned to ML. That's corresponds to
> the fact/reassures that we don't have bug owners in OE, and entire
> community welcome to/works on any issue (which in turn is based on the
> fact that we don't have dedicated engineers to resolve bugs).

Paul,

One benefit of reassigning the bug to myself is that I can click the "My 
Bug" button and list all my filed and self-assigned bugs, instead of 
remembering the bug number or relying on search.

I'm undoing the damages right now. But please let me know if there's an 
alternative to easily keep track of interested bugs.  Well, maybe I'm 
too lazy.

Gordon




From pmiscml at gmail.com  Mon May 14 09:06:30 2007
From: pmiscml at gmail.com (Paul Sokolovsky)
Date: Mon, 14 May 2007 12:06:30 +0300
Subject: [oe] RFD: Bugzilla in general & bug triaging
In-Reply-To: <46482288.2040904@gmail.com>
References: <1179059149.5404.3.camel@cimmeria.hyboria>
	<f277j3$i00$1@sea.gmane.org> <464818E3.7090203@gmail.com>
	<24757045.20070514112558@gmail.com> <46482288.2040904@gmail.com>
Message-ID: <1851689443.20070514120630@gmail.com>

Hello Junqian,

Monday, May 14, 2007, 11:49:12 AM, you wrote:

> Paul Sokolovsky wrote:
>> Hello Junqian,
>>
>> Monday, May 14, 2007, 11:08:03 AM, you wrote:
>>
>>   
>>> Is it a problem if I replace the openembedded-issues@ with my email 
>>> address in the Reassign to field? Does openembedded-issues still gets 
>>> all the updates?
>>>     
>>
>>         As Rolf described in his mail, we do not reassign bugs in our
>> workflow - they keep being assigned to ML. That's corresponds to
>> the fact/reassures that we don't have bug owners in OE, and entire
>> community welcome to/works on any issue (which in turn is based on the
>> fact that we don't have dedicated engineers to resolve bugs).

> Paul,

> One benefit of reassigning the bug to myself is that I can click the "My
> Bug" button and list all my filed and self-assigned bugs, instead of 
> remembering the bug number or relying on search.

        I well understand benefits of assigning bugs, it's just the
fact that OE doesn't assign them (as as was mentioned, it's good, as
have psychological effect of welcoming everyone to work on things, not
think "well, that guy will fix it" or "oh, it's that guy's, I can't
touch it").

> I'm undoing the damages right now. But please let me know if there's an
> alternative to easily keep track of interested bugs.  Well, maybe I'm 
> too lazy.

        You still better rely on search. And Bugzilla is a powerful
("enterprise-grade" ;-) ) tool, which allows you to do many things.
For example, that's how I have it set up: I add myself to cc: of the
interesting bugs (in full accordance to Rolf's RFD), then once made
an advanced search setup, which searches for my address in any email
field (reporter, cc, etc.), and saved it as saved search. Now, it's
the same one click as predefined "My Bugs" search. And you can have
number of saved searches, for machines of your interest, for software,
etc. - all one click away.

> Gordon


-- 
Best regards,
 Paul                            mailto:pmiscml at gmail.com




From koen at dominion.kabel.utwente.nl  Mon May 14 09:06:43 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Mon, 14 May 2007 11:06:43 +0200
Subject: [oe] RFD: Bugzilla in general & bug triaging
In-Reply-To: <46482288.2040904@gmail.com>
References: <1179059149.5404.3.camel@cimmeria.hyboria>	<f277j3$i00$1@sea.gmane.org>
	<464818E3.7090203@gmail.com>	<24757045.20070514112558@gmail.com>
	<46482288.2040904@gmail.com>
Message-ID: <464826A3.7010505@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Junqian Gordon Xu schreef:
> Paul Sokolovsky wrote:
>> Hello Junqian,
>>
>> Monday, May 14, 2007, 11:08:03 AM, you wrote:
>>
>>   
>>> Is it a problem if I replace the openembedded-issues@ with my email 
>>> address in the Reassign to field? Does openembedded-issues still gets 
>>> all the updates?
>>>     
>>         As Rolf described in his mail, we do not reassign bugs in our
>> workflow - they keep being assigned to ML. That's corresponds to
>> the fact/reassures that we don't have bug owners in OE, and entire
>> community welcome to/works on any issue (which in turn is based on the
>> fact that we don't have dedicated engineers to resolve bugs).
> 
> Paul,
> 
> One benefit of reassigning the bug to myself is that I can click the "My 
> Bug" button and list all my filed and self-assigned bugs, instead of 
> remembering the bug number or relying on search.
> 
> I'm undoing the damages right now. But please let me know if there's an 
> alternative to easily keep track of interested bugs.  Well, maybe I'm 
> too lazy.

You could assign to yourself and add oe-issues in CC:

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGSCajMkyGM64RGpERAldiAKCqrJcD6ZE0ULRWcz1Ksxxi+LQ2dACdHXvV
cdawEzHNUHLAOXzREdLLIKQ=
=wDhJ
-----END PGP SIGNATURE-----



From xjqian at gmail.com  Mon May 14 09:18:09 2007
From: xjqian at gmail.com (Junqian Gordon Xu)
Date: Mon, 14 May 2007 04:18:09 -0500
Subject: [oe] RFD: Bugzilla in general & bug triaging
In-Reply-To: <1851689443.20070514120630@gmail.com>
References: <1179059149.5404.3.camel@cimmeria.hyboria>
	<f277j3$i00$1@sea.gmane.org> <464818E3.7090203@gmail.com>
	<24757045.20070514112558@gmail.com> <46482288.2040904@gmail.com>
	<1851689443.20070514120630@gmail.com>
Message-ID: <46482951.8060803@gmail.com>

Paul Sokolovsky wrote:
>> I'm undoing the damages right now. But please let me know if there's an
>> alternative to easily keep track of interested bugs.  Well, maybe I'm 
>> too lazy.
>>     
>
>         You still better rely on search. And Bugzilla is a powerful
> ("enterprise-grade" ;-) ) tool, which allows you to do many things.
> For example, that's how I have it set up: I add myself to cc: of the
> interesting bugs (in full accordance to Rolf's RFD), then once made
> an advanced search setup, which searches for my address in any email
> field (reporter, cc, etc.), and saved it as saved search. Now, it's
> the same one click as predefined "My Bugs" search. And you can have
> number of saved searches, for machines of your interest, for software,
> etc. - all one click away

Thanks for the great tip. When I said I was too lazy, that's also 
including that I'm too lazy to study/play with all the features of 
Bugzilla, esp. considering the enterprise-grade motto :)

Gordon



From koen at dominion.kabel.utwente.nl  Mon May 14 09:42:59 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Mon, 14 May 2007 11:42:59 +0200
Subject: [oe] [oe-commits] org.oe.dev ixp4xx-kernel: Dropped support for
 2.6.21, we're sticking to 2.6.20 stable and 2.6.22 development
In-Reply-To: <E1HnWn2-0007PS-SW@linuxtogo.org>
References: <E1HnWn2-0007PS-SW@linuxtogo.org>
Message-ID: <46482F23.9050504@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

rwhitby commit schreef:
> ixp4xx-kernel: Dropped support for 2.6.21, we're sticking to 2.6.20 stable and 2.6.22 development

> # delete "packages/linux/ixp4xx-kernel_2.6.21.bb"

You broke feeds and upgrade paths for users of that recipe, could you next time just add
DEFAULT_PREFERENCE = "-1" or something? Slugos isn't the only user of OE!
 I just got .21 running on my ixp4xx board, and now I have to remove all kernel packages,
packages built against .21 and find a way for angstrom to deal with that in the feeds for
people doing 'ipkg upgrade'.

I will deal with it, but next time a bit of warning on the OE list would be appreciated.

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGSC8jMkyGM64RGpERAl+UAJ42rD9nGX4EcbKJRzD0yXAgAjwWDwCfaFjg
NoUOnnEP5xC3YJodBtkjQCI=
=a0fc
-----END PGP SIGNATURE-----



From rod at whitby.id.au  Mon May 14 10:14:56 2007
From: rod at whitby.id.au (Rod Whitby)
Date: Mon, 14 May 2007 19:44:56 +0930
Subject: [oe] [oe-commits] org.oe.dev ixp4xx-kernel: Dropped support for
 2.6.21, we're sticking to 2.6.20 stable and 2.6.22 development
In-Reply-To: <46482F23.9050504@dominion.kabel.utwente.nl>
References: <E1HnWn2-0007PS-SW@linuxtogo.org>
	<46482F23.9050504@dominion.kabel.utwente.nl>
Message-ID: <464836A0.6050705@whitby.id.au>

Koen Kooi wrote:
> rwhitby commit schreef:
>>> ixp4xx-kernel: Dropped support for 2.6.21, we're sticking to 2.6.20 stable and 2.6.22 development
> 
>>> # delete "packages/linux/ixp4xx-kernel_2.6.21.bb"
> 
> You broke feeds and upgrade paths for users of that recipe, could you next time just add
> DEFAULT_PREFERENCE = "-1" or something? Slugos isn't the only user of OE!

My apologies.  Mea culpa.

>  I just got .21 running on my ixp4xx board, and now I have to remove all kernel packages,
> packages built against .21 and find a way for angstrom to deal with that in the feeds for
> people doing 'ipkg upgrade'.

I'll put it back immediately.

-- Rod



From no2spam at nospam.arcornews.de  Mon May 14 10:16:37 2007
From: no2spam at nospam.arcornews.de (Rolf Leggewie)
Date: Mon, 14 May 2007 12:16:37 +0200
Subject: [oe] RFD: Bugzilla in general & bug triaging
In-Reply-To: <46482288.2040904@gmail.com>
References: <1179059149.5404.3.camel@cimmeria.hyboria>	<f277j3$i00$1@sea.gmane.org>
	<464818E3.7090203@gmail.com>	<24757045.20070514112558@gmail.com>
	<46482288.2040904@gmail.com>
Message-ID: <f29cu8$lol$1@sea.gmane.org>

Junqian Gordon Xu wrote:
>>         As Rolf described in his mail, we do not reassign bugs in our
>> workflow 

Actually that is neither what I wrote nor what I'd propose ;-)  I have 
no issue with you assigning 2309 to yourself.  You seem to take good 
care of it.

> One benefit of reassigning the bug to myself is that I can click the "My 
> Bug" button and list all my filed and self-assigned bugs, instead of 
> remembering the bug number or relying on search.

yes, very valid point.  It innocently illustrates the kind of workflow 
I'd be looking for (and that I use to a certain degree for myself).  You 
have a link with a search function saved in bugzilla and when you click 
on it all the bugs that need your attention or that you are interested 
in are right there.

Gordon, maybe you want to save http://tinyurl.com/385p8b  You could also 
separate that out to only list cc bugs or whatever suits your needs. 
Tweak it to your liking.

Here are three searches that I use and deem useful for others

http://tinyurl.com/2oypog (todays bugs: action: stay current)
http://tinyurl.com/35l78g (bugs where compilation fails, action: verify)
http://tinyurl.com/39gss8 (old with patches, action: inspect, commit)




From no2spam at nospam.arcornews.de  Mon May 14 10:28:30 2007
From: no2spam at nospam.arcornews.de (Rolf Leggewie)
Date: Mon, 14 May 2007 12:28:30 +0200
Subject: [oe] RFD: Bugzilla in general & bug triaging
In-Reply-To: <f277j3$i00$1@sea.gmane.org>
References: <1179059149.5404.3.camel@cimmeria.hyboria>
	<f277j3$i00$1@sea.gmane.org>
Message-ID: <f29dkh$o3v$1@sea.gmane.org>

Rolf Leggewie wrote:
> Thank you Graeme for raising this issue.  It is something I meant to 
> discuss earlier but never found enough time to think it through and 
> write up something.  I still have not thought it through, but here it goes.

I have asked and been granted greater powers on bugzilla.  There are 
features which we don't use yet but which could aid in establishing a 
sane workflow while rendering unnecessary the current clutches and 
ad-hoc fixes.

Bugzilla will be upgraded soon and no structural changes will be made 
until that is completed.  But that leaves us some good time to think 
about how this should be enhanced.

Things I'd like to see
* confirmation flags
* better documentation of workflow status (need to define it first)
* assigning bugs (or if you prefer "Hey, please take a look")
* link to some bug searches like the ones I send about 5 minutes ago
   on the entry page
* entry page clean-up (why two search fields?)
* removal of dead stuff (ZaurusKernel, Familiar)

Please add to the list.  The most important point is the second.  That 
is what we should discuss.




From pmiscml at gmail.com  Mon May 14 11:26:44 2007
From: pmiscml at gmail.com (Paul Sokolovsky)
Date: Mon, 14 May 2007 14:26:44 +0300
Subject: [oe] RFD: Bugzilla in general & bug triaging
In-Reply-To: <f29cu8$lol$1@sea.gmane.org>
References: <1179059149.5404.3.camel@cimmeria.hyboria>
	<f277j3$i00$1@sea.gmane.org> <464818E3.7090203@gmail.com>
	<24757045.20070514112558@gmail.com>
	<46482288.2040904@gmail.com> <f29cu8$lol$1@sea.gmane.org>
Message-ID: <1848419262.20070514142644@gmail.com>

Hello Rolf,

Monday, May 14, 2007, 1:16:37 PM, you wrote:

> Junqian Gordon Xu wrote:
>>>         As Rolf described in his mail, we do not reassign bugs in our
>>> workflow 

> Actually that is neither what I wrote nor what I'd propose ;-)

        Well, ok, what you wrote is that you once tried assign bugs,
but was suggested not to do that. If you want to propose that again,
then the same suggestion: please don't do that. The reasons were
given, and I reiterate over the matter below again.

> I have
> no issue with you assigning 2309 to yourself.  You seem to take good 
> care of it.

>> One benefit of reassigning the bug to myself is that I can click the "My 
>> Bug" button and list all my filed and self-assigned bugs, instead of 
>> remembering the bug number or relying on search.

> yes, very valid point.  It innocently illustrates the kind of workflow
> I'd be looking for (and that I use to a certain degree for myself).

        That's kind of bug workflow most projects use, be them
opensource or commercial, so no wonder. But such workflow works
especially well if as many as possible of the following are true:

1. Scope of project and functional areas are well defined.
2. There're dedicated developer for each area.
3. There's a manager who performs assignment.

        None of these are true for OE - the scope is too wide, areas
either to big (like, a distro), or too diversified (issues with
specific package or machine), there're no dedicated developers for
specific areas, and no manager who tells folks what to do.

        So, there's another workflow, of course not so organized, but
flexible and well fitting OE devel model, the reason why it was there
well before you or me came into active contribution.

> You
> have a link with a search function saved in bugzilla and when you click
> on it all the bugs that need your attention or that you are interested
> in are right there.

        Yes, you have saved searches, you have email preferences, you
have other cool things in Bugzilla, you learn to use them well in
framework on the existing workflow, before trying to revolutionize the
workflow itself.

> Gordon, maybe you want to save http://tinyurl.com/385p8b  You could also
> separate that out to only list cc bugs or whatever suits your needs. 
> Tweak it to your liking.

> Here are three searches that I use and deem useful for others

> http://tinyurl.com/2oypog (todays bugs: action: stay current)
> http://tinyurl.com/35l78g (bugs where compilation fails, action: verify)
> http://tinyurl.com/39gss8 (old with patches, action: inspect, commit)

        These links are nice, but won't help too much. Until people
start to make bug filters which *they* like and need, there always be
idea that something's lacking and that you need to put it upside down
trying to make it "work" for you.

-- 
Best regards,
 Paul                            mailto:pmiscml at gmail.com




From koen at dominion.kabel.utwente.nl  Mon May 14 12:06:27 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Mon, 14 May 2007 14:06:27 +0200
Subject: [oe] Making /var/lib persistent
In-Reply-To: <31583224.20070510180054@gmail.com>
References: <1176760923.4623f25b913f9@dominion.kabel.utwente.nl>	<20070418090235.GA21841@twibble.org>	<46262A0F.1050805@dominion.kabel.utwente.nl>	<20070419014949.GA6540@twibble.org>
	<31583224.20070510180054@gmail.com>
Message-ID: <464850C3.90202@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Paul Sokolovsky schreef:
> Hello Jamie,
> 
> Thursday, April 19, 2007, 4:49:50 AM, you wrote:
> 
>> On Wed, Apr 18, 2007 at 07:24:15AM -0700, Koen Kooi wrote:
>> [...]
>>> Sound like a good idea, do you have a patch for this?
> 
>> Try this out:
> 
>>   http://twibble.org/dist/oe/var-volatiles-1.patch
> 
>> I've tested it locally both with and without tmpfs mounted on
>> /var/volatile and all seems to work as expected.
> 
>         Any news on this? I've been running with this patch soon since
> its original post and don't see any issues. One small nuisance is that
> ls -l /var/log doesn't show what you want, but hardly something can be
> done about that, plus shell completion uses /var/log/ immediately.
> 
>         I suggest committing this patch.

After I have fixed up the rejects I'll commit and push it.

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGSFDDMkyGM64RGpERArsZAJ0aPIXjYQW8TcJ4qd5z01RWFbSAUACfWBU0
zg9Qmq0tPnSryt6WDAOki3o=
=DO2J
-----END PGP SIGNATURE-----



From koen at dominion.kabel.utwente.nl  Mon May 14 12:21:14 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Mon, 14 May 2007 14:21:14 +0200
Subject: [oe] Making /var/lib persistent
In-Reply-To: <464850C3.90202@dominion.kabel.utwente.nl>
References: <1176760923.4623f25b913f9@dominion.kabel.utwente.nl>	<20070418090235.GA21841@twibble.org>	<46262A0F.1050805@dominion.kabel.utwente.nl>	<20070419014949.GA6540@twibble.org>	<31583224.20070510180054@gmail.com>
	<464850C3.90202@dominion.kabel.utwente.nl>
Message-ID: <4648543A.8080202@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Koen Kooi schreef:

>>>   http://twibble.org/dist/oe/var-volatiles-1.patch

> After I have fixed up the rejects I'll commit and push it.

Ok, it's in, please report any errors/bugs/features

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGSFQ6MkyGM64RGpERAnezAKCfPi397VPH5q72q+wxpLKl9wFtMQCfdHQg
kozdbu7EzNnNWf5zgwr4oBw=
=qZ8t
-----END PGP SIGNATURE-----



From koen at dominion.kabel.utwente.nl  Mon May 14 12:30:00 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Mon, 14 May 2007 14:30:00 +0200
Subject: [oe] uclibc 0.9.29 recipe
In-Reply-To: <c384c5ea0705131439o1a2b71b8i26a16123ae1c591e@mail.gmail.com>
References: <464613B3.8090003@dominion.kabel.utwente.nl>	<46461B73.8070900@trolltech.com>	<46461D72.4020206@dominion.kabel.utwente.nl>	<46462BDD.6000302@dominion.kabel.utwente.nl>	<c384c5ea0705130945k266d8bccw4f890d99d9997e52@mail.gmail.com>	<46474315.1070207@dominion.kabel.utwente.nl>
	<c384c5ea0705131439o1a2b71b8i26a16123ae1c591e@mail.gmail.com>
Message-ID: <46485648.8000705@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Leon Woestenberg schreef:
> perl 5.8.8 needs:
> 
> UCLIBC_SUSV3_LEGACY=y
> UCLIBC_SUSV3_LEGACY_MACROS=y

Feel free to add those to (angstrom/)uClibc.distro

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGSFZIMkyGM64RGpERAm6LAJ9zXFxGitsAcWxB9MBPXT8qYQMrvwCcC6ro
XdSuqhAYD0TKlipoSA0pQJ0=
=d9jH
-----END PGP SIGNATURE-----



From rpurdie at rpsys.net  Mon May 14 12:42:32 2007
From: rpurdie at rpsys.net (Richard Purdie)
Date: Mon, 14 May 2007 13:42:32 +0100
Subject: [oe] do_rootfs fails
In-Reply-To: <1178928474.4954.18.camel@localhost.localdomain>
References: <4644ABCB.6080202@openhardware.net>
	<4644B0D2.8020409@dominion.kabel.utwente.nl>
	<1178928474.4954.18.camel@localhost.localdomain>
Message-ID: <1179146552.5877.1.camel@localhost.localdomain>

On Sat, 2007-05-12 at 02:07 +0200, Matthias Hentges wrote:
> Am Freitag, den 11.05.2007, 20:07 +0200 schrieb Koen Kooi:
> 
> > All: Are we still going to wait 1.5 months with requiring 1.8.x? I've seen enough proof
> > that 1.6.x is broken with current .dev, with no effort to fix it. "Giving people time to
> > prepare the upgrade" has now turned into "Stabbing user in the eye" :(
> > 
> > regards,
> > 
> > Koen
> 
> 1.8.x has a show-stopper freeze-bug for some users ( including myself )
> which has not been fixed or even looked into yet.

Nobody has reported this properly although I keep hearing mention of it.

Could you send me the output from stty in your usual development
environment please?

Thanks,

Richard






From openembedded at hrw.one.pl  Mon May 14 13:28:12 2007
From: openembedded at hrw.one.pl (Marcin Juszkiewicz)
Date: Mon, 14 May 2007 15:28:12 +0200
Subject: [oe] RFD: Bugzilla in general & bug triaging
In-Reply-To: <f29dkh$o3v$1@sea.gmane.org>
References: <1179059149.5404.3.camel@cimmeria.hyboria>
	<f277j3$i00$1@sea.gmane.org> <f29dkh$o3v$1@sea.gmane.org>
Message-ID: <200705141528.12352.openembedded@hrw.one.pl>

Dnia poniedzia?ek, 14 maja 2007, Rolf Leggewie napisa?:

> Bugzilla will be upgraded soon and no structural changes will be made
> until that is completed.  But that leaves us some good time to think
> about how this should be enhanced.

> Please add to the list.  The most important point is the second.  That
> is what we should discuss.

MACHINE field would be useful - there are bugs specific to machine (kernel 
bug etc) which now have it in title or comment. 






From ulf at atmel.com  Mon May 14 13:14:03 2007
From: ulf at atmel.com (Ulf Samuelsson)
Date: Mon, 14 May 2007 15:14:03 +0200
Subject: [oe] qemu-native failure on Angstrom
Message-ID: <07a101c7962b$e0db5860$0200a8c0@atmel.com>

Tried building OpenEmbedded for the first time, DISTRO=?ngstr?m, 
with an at91sam9263 target (made my own file) but it seems that
qemu.native is not compilable on my OpenSuSE 10.1 system using gcc-4.1.2.
The error message says that qemu has only been tested on gcc-4.x.x for arm
and that other architectures need gcc-3.x

Tried to update the bb files to allow gcc-4.1.2 but that resulted in
qemu-arm not beeing built, causing the build to terminate later.

Is there any way to have open embedded build a gcc-3.4.4 cross compiler
as part of the normal build.

Best Regards
Ulf Samuelsson




From koen at dominion.kabel.utwente.nl  Mon May 14 13:40:44 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Mon, 14 May 2007 15:40:44 +0200
Subject: [oe] qemu-native failure on Angstrom
In-Reply-To: <07a101c7962b$e0db5860$0200a8c0@atmel.com>
References: <07a101c7962b$e0db5860$0200a8c0@atmel.com>
Message-ID: <464866DC.6060502@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ulf Samuelsson schreef:
> Tried building OpenEmbedded for the first time, DISTRO=?ngstr?m, 
> with an at91sam9263 target (made my own file) but it seems that
> qemu.native is not compilable on my OpenSuSE 10.1 system using gcc-4.1.2.
> The error message says that qemu has only been tested on gcc-4.x.x for arm
> and that other architectures need gcc-3.x
> 
> Tried to update the bb files to allow gcc-4.1.2 but that resulted in
> qemu-arm not beeing built, causing the build to terminate later.
> 
> Is there any way to have open embedded build a gcc-3.4.4 cross compiler
> as part of the normal build.

You want a native gcc3 on your host, since qemu-native will be compiled with that, on
debian that can be done with 'apt-get install gcc-3.4'.

Alternatively you can set ENABLE_BINARY_LOCALE_GENERATION = "0" in your local.conf.

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGSGbcMkyGM64RGpERAlXOAJ9HlfnJ5CbfVrHd3lOIBsDfyqbDqgCgmzv5
4tDq+oZskVRAfnxs7rWNlVA=
=OQ93
-----END PGP SIGNATURE-----



From skyhusker at rm-fr.net  Mon May 14 13:46:02 2007
From: skyhusker at rm-fr.net (Alberto =?iso-8859-1?q?Garc=EDa_Hierro?=)
Date: Mon, 14 May 2007 15:46:02 +0200
Subject: [oe] qemu-native failure on Angstrom
In-Reply-To: <07a101c7962b$e0db5860$0200a8c0@atmel.com>
References: <07a101c7962b$e0db5860$0200a8c0@atmel.com>
Message-ID: <200705141546.02470.skyhusker@rm-fr.net>

El Monday 14 May 2007 15:14:03 Ulf Samuelsson escribi?:
> Tried building OpenEmbedded for the first time, DISTRO=?ngstr?m,
> with an at91sam9263 target (made my own file) but it seems that
> qemu.native is not compilable on my OpenSuSE 10.1 system using gcc-4.1.2.
> The error message says that qemu has only been tested on gcc-4.x.x for arm
> and that other architectures need gcc-3.x
>
> Tried to update the bb files to allow gcc-4.1.2 but that resulted in
> qemu-arm not beeing built, causing the build to terminate later.
>
> Is there any way to have open embedded build a gcc-3.4.4 cross compiler
> as part of the normal build.

	Check the patch at http://bugs.openembedded.org/show_bug.cgi?id=1144. It's 
for amd64, but with little editing you can adapt it to your system.

Regards,
	Alberto


-- 
Alberto Garc?a Hierro
http://zeus.rm-fr.net/~skyhusker/



From pmiscml at gmail.com  Mon May 14 14:13:06 2007
From: pmiscml at gmail.com (Paul Sokolovsky)
Date: Mon, 14 May 2007 17:13:06 +0300
Subject: [oe] qemu-native failure on Angstrom
In-Reply-To: <200705141546.02470.skyhusker@rm-fr.net>
References: <07a101c7962b$e0db5860$0200a8c0@atmel.com>
	<200705141546.02470.skyhusker@rm-fr.net>
Message-ID: <783750430.20070514171306@gmail.com>

Hello Alberto,

Monday, May 14, 2007, 4:46:02 PM, you wrote:

> El Monday 14 May 2007 15:14:03 Ulf Samuelsson escribi?:
>> Tried building OpenEmbedded for the first time, DISTRO=?ngstr?m,
>> with an at91sam9263 target (made my own file) but it seems that
>> qemu.native is not compilable on my OpenSuSE 10.1 system using gcc-4.1.2.
>> The error message says that qemu has only been tested on gcc-4.x.x for arm
>> and that other architectures need gcc-3.x
>>
>> Tried to update the bb files to allow gcc-4.1.2 but that resulted in
>> qemu-arm not beeing built, causing the build to terminate later.
>>
>> Is there any way to have open embedded build a gcc-3.4.4 cross compiler
>> as part of the normal build.

>         Check the patch at
> http://bugs.openembedded.org/show_bug.cgi?id=1144. It's 
> for amd64, but with little editing you can adapt it to your system.

        Not sure this is anyhow good patch to suggest.
http://bugs.openembedded.org/show_bug.cgi?id=2157 is what promises to
solve gcc4 issues, but that still waits for the confirmation that
it actually cooks locales well.

> Regards,
>         Alberto





-- 
Best regards,
 Paul                            mailto:pmiscml at gmail.com




From ccsmart at smartpal.de  Mon May 14 17:15:16 2007
From: ccsmart at smartpal.de ([cc]smart)
Date: Mon, 14 May 2007 19:15:16 +0200
Subject: [oe] Making /var/lib persistent
Message-ID: <1179162916.23344.6.camel@localhost>

Hi list.

i must admit i am a bit late on the discussion but nonetheless... i
noticed the change on the tree and i would like to comment volatiles use
and the patch:

http://www.openembedded.org/viewmtn/revision.psp?id=d8f8ffd537ebb6baa3cabe50d3f8267cdd28f3b7

The discussion on the list was accompanied by:

>        The only concern is all this override files patchery. I wish 
>we had for fstab the same machinery as for autoconf site files - 
>ability to merge standard template with per-machine overrides. But 
>well, lack of such shouldn't be cause of delay with this patch, hope 
>to see it soon in mainline! 
> 
>Best regards, 
> Paul                            mailto:pmiscml at gmail.com


I would like to take you back a few years into history of volatiles,
because originally, it was invented primarily to assist in modular
configuration.

I'd like to start with the explanation given in the main volatiles
config file:


# This configuration file lists filesystem objects that should get
verified 
# during startup and be created if missing. 
# 
# Every line must either be a comment starting with # 
# or a definition of format: 
# <type> <owner> <group> <mode> <path> <linksource> 
# where the items are separated by whitespace ! 
# 
# <type> : d|f|l : (d)irectory|(f)ile|(l)ink 
# 
# A linking example: 
# l root root 0777 /var/test /tmp/testfile 
# f root root 0644 /var/test none 
# 
# Understanding links: 
# When populate-volatile is to verify/create a directory or file, it
will first 
# check it's existence. If a link is found to exist in the place of the
target, 
# the path of the target is replaced with the target the link points
to. 
# Thus, if a link is in the place to be verified, the object will be
created 
# in the place the link points to instead. 
# This explains the order of "link before object" as in the example
above, where 
# a link will be created at /var/test pointing to /tmp/testfile and due
to this 
# link the file defined as /var/test will actually be created
as /tmp/testfile.


FWIW, i think it has never been observed to create links before the
actual object. Why was it done like that despite it seems
counterintuitive.

Because it is part of the modulartity.

This main file should contain only basic, and only "real object"
descriptions. That is what it was at the beginning. All the redirection
into tmpfs space is NOT meant to be done in this file.

Basically it should roughly be kept like this (mind you, specifying
"none" in the end was not needed originally):

d root root 0755 /var/cache none 
d root root 1777 /var/lock none 
d root root 0755 /var/log none 
d root root 0755 /var/run none 
d root root 1777 /var/tmp none 
d root root 0755 /var/lock/subsys none 
f root root 0664 /var/log/wtmp none 
f root root 0664 /var/run/utmp none

In fstab, there should neither be tmpf on /var nor on /var/volatile but
for example under /media/ram only.

Now let your mind go back to the rule "link before object".

The default is a physical world. Volatiles would set up your directories
as described in it's configuration "ohysically".

If you create a distro for a device on flash, you would deliver your
image with links in var pointing to /media/ram. For example there would
be a link "/var/run" pointing to "/media/ram/run".

Automagically, volatiles would use the line

d root root 0755 /var/run none

to create a directory in "/media/ram". No need for changing the
volatiles base configuration (i hope that no change in volatiles as
broken this, otherwise IMHO it should be fixed to behave like that
again).

Subsequently turnup would only have to remove links in "/var" to get
that distro going on HD.

The second idea in the original design of volatiles is to have a tool
that allows adding and removing directory requirements per package. So a
package can drop in a specification in volatiles config directory. these
are numbered like runlevels.

This allows to have separate specification files. One defines the real
objects, like the base files does, and it's seq. number should be n+1 .

Additionally you may have a redirection config (possibly per distro)
with seq. number n which may redirect to volatile space, like
"/media/ram" .

Basically in thinking you always start physical and then deviate to
volatile.

All in all i would recommend to:

- revert volatiles main config to physical objects only 
- remove all /var based tmpfs's from /etc/fstab and make it more or less
a static thing. 
- get distros pre provide main redirection links in "/var" where needed.

Greetings, 
[cc]smart





From gerwin at vanderkruis.net  Mon May 14 18:38:31 2007
From: gerwin at vanderkruis.net (Gerwin)
Date: Mon, 14 May 2007 20:38:31 +0200
Subject: [oe] Questions: Founding of Open Embedded, dev gatherings etc.
In-Reply-To: <463C9ABC.7090503@dominion.kabel.utwente.nl>
References: <200705041909.29494.kyrvin@trolltech.com>
	<463C9ABC.7090503@dominion.kabel.utwente.nl>
Message-ID: <200705142038.32087.gerwin@vanderkruis.net>

Hi Knut, 

I have been quite busy myself as well , lot of embedded work and lot of 
php/java work. 

I am busy with a wimax kind of smartphone for the asian market which will run 
of course linux(currently hardware design fase). And some smaller projects so 
it is quite busy at this moment.  

> >
> > I got some experiences with developer gatherings after initiationg the
> > Skolelinux project in 2001. Actually we have organised +30 gatherings.
> > Skolelinux is now a part of DebianEdu. The board of "Free Software in
> > School" organises about 6-7 developer gatherings a year. Pictures from
> > opening of one of the gatherings in Forbach - France, gives an idea of
> > the scale:
> >
> > http://www.bawetic.be/PHOTOS/Forbach2006/
> >
> > I would like to see similar activeties in OpenEmbedded space. Maybe
> > Mobile Developer Days 2007 at Alborg University in Denmark could be the
> > place to start?:
> >

Yes I think so , the main problem is that our main developers are in the 
Netherlands , Germany , England and Poland. So yes we can send a delegation 
but I don't think that all developers will be there . I think we have a 
bigger chance if we organize something like this in the Netherlands or 
Germany. 

> > To sum it up. Gerwin van der Kruis idea is to make a foundation, and
> > getting dev.gatherings started. Is this interesting for you? If you are
> > interesed, how should we proceed?
>

We discussed about this also during fosdem and later on as well on irc, the 
main problem is time and knowledge . For example where should such a 
foundation be based , who is going to govern it etc. etc. 

OEDEM Frosconn and t-dose are the first opurtunities that we will be present .

I invited you for t-dose as well for a keynote. 


Kind Regards, 

Gerwin


-- 
The Holographic Klop Doctor

               -
               0
             - |
              \|\
               |/
               |
              /|
            _|_|

Underneath the mango tree  :) 



From oe at hentges.net  Mon May 14 22:23:00 2007
From: oe at hentges.net (Matthias Hentges)
Date: Tue, 15 May 2007 00:23:00 +0200
Subject: [oe] do_rootfs fails
In-Reply-To: <1178928474.4954.18.camel@localhost.localdomain>
References: <4644ABCB.6080202@openhardware.net>
	<4644B0D2.8020409@dominion.kabel.utwente.nl>
	<1178928474.4954.18.camel@localhost.localdomain>
Message-ID: <1179181380.4954.45.camel@localhost.localdomain>

Hello all,

Am Samstag, den 12.05.2007, 02:07 +0200 schrieb Matthias Hentges:

> 1.8.x has a show-stopper freeze-bug for some users ( including myself )
> which has not been fixed or even looked into yet.

RP was kind enough to look into the issue. The following command
unbreaks bitbake 1.8 on my build environment: 

stty -tostop

The IRC discussion leading to the fix is archived here:

http://hentges.net/tmp/logs/irc/%
23oe/2007/May/20070515_oe.log#[20070515%2000:08:46]
-- 
Matthias 'CoreDump' Hentges 
Cologne / Germany

Webmaster of Hentges.net & Embedded Linux Developer
GPG ->  gpg --keyserver gpg-keyserver.de --recv-keys 0xAF3030D9

My OS: Debian SID: Geek by Nature, Linux by Choice


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
URL: <http://lists.openembedded.org/pipermail/openembedded-devel/attachments/20070515/94aee16e/attachment-0001.sig>

From koen at dominion.kabel.utwente.nl  Mon May 14 23:05:53 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Tue, 15 May 2007 01:05:53 +0200
Subject: [oe] Fixing up libtool-native and libtool-cross
Message-ID: <4648EB51.4040303@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Richard has fixed up libtool in Poky a bit and I want to merge his work into OE. Since
it's 1 AM now, and libtool is a pretty 'core' part, I'm posting the patch for review
before committing it tomorrow night.

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGSOtRMkyGM64RGpERAuiCAJ0Yqz+t4X/zNCjTbZIBU7yjaDt8twCgkgVq
iM3uwQTciklpQKjurM34Nys=
=W6UX
-----END PGP SIGNATURE-----
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: libtool.diff
URL: <http://lists.openembedded.org/pipermail/openembedded-devel/attachments/20070515/6b5c5c15/attachment-0001.ksh>

From philipp.zabel at gmail.com  Tue May 15 07:53:30 2007
From: philipp.zabel at gmail.com (pHilipp Zabel)
Date: Tue, 15 May 2007 09:53:30 +0200
Subject: [oe] Fixing up libtool-native and libtool-cross
In-Reply-To: <4648EB51.4040303@dominion.kabel.utwente.nl>
References: <4648EB51.4040303@dominion.kabel.utwente.nl>
Message-ID: <74d0deb30705150053p109b57d6of67860d7fbb028ba@mail.gmail.com>

On 5/15/07, Koen Kooi <koen at dominion.kabel.utwente.nl> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
>
> Richard has fixed up libtool in Poky a bit and I want to merge his work into OE. Since
> it's 1 AM now, and libtool is a pretty 'core' part, I'm posting the patch for review
> before committing it tomorrow night.

Looks good to me.

> regards,
>
> Koen
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (Darwin)
>
> iD8DBQFGSOtRMkyGM64RGpERAuiCAJ0Yqz+t4X/zNCjTbZIBU7yjaDt8twCgkgVq
> iM3uwQTciklpQKjurM34Nys=
> =W6UX
> -----END PGP SIGNATURE-----
>
> #
> # old_revision [990392a71744fa8ec062ee769a883473775269ee]
> #
> # patch "classes/autotools.bbclass"
> #  from [dced52fcafd4e224bafcb35c4fb04253857c7c3b]
> #    to [113ae9d1554b6e93d9c7a7fda84d71da4712caf9]
> #
> # patch "packages/libtool/libtool-cross_1.5.10.bb"
> #  from [58b238af5bb9acdeca5b86c34b50c419fb49b55e]
> #    to [5134256c71b2d679838e87a55b084a99b1ac17d4]
> #
> # patch "packages/libtool/libtool-native_1.5.10.bb"
> #  from [e1d2b08387782afbf7c5c6787a92d9af864dfb2d]
> #    to [bc799a0464069f3531cbb0a017c4d8d2a1afd63e]
> #
> ============================================================
> --- classes/autotools.bbclass   dced52fcafd4e224bafcb35c4fb04253857c7c3b
> +++ classes/autotools.bbclass   113ae9d1554b6e93d9c7a7fda84d71da4712caf9
> @@ -15,6 +15,10 @@ def autotools_dep_prepend(d):
>
>         if not pn in ['libtool', 'libtool-native', 'libtool-cross']:
>                 deps += 'libtool-native '
> +               if not bb.data.inherits_class('native', d) \
> +                        and not bb.data.inherits_class('cross', d) \
> +                        and not bb.data.getVar('INHIBIT_DEFAULT_DEPS', d, 1):
> +                    deps += 'libtool-cross '
>
>         return deps + 'gnu-config-native '
>
> ============================================================
> --- packages/libtool/libtool-cross_1.5.10.bb    58b238af5bb9acdeca5b86c34b50c419fb49b55e
> +++ packages/libtool/libtool-cross_1.5.10.bb    5134256c71b2d679838e87a55b084a99b1ac17d4
> @@ -1,7 +1,7 @@ require libtool_${PV}.bb
>  SECTION = "devel"
>  require libtool_${PV}.bb
>
> -PR = "r4"
> +PR = "r5"
>  PACKAGES = ""
>  FILESDIR = "${@os.path.dirname(bb.data.getVar('FILE',d,1))}/libtool-${PV}"
>  SRC_URI_append = " file://libdir-la.patch;patch=1 \
> @@ -21,6 +21,13 @@ do_stage () {
>
>  do_stage () {
>          install -m 0755 ${HOST_SYS}-libtool ${bindir}/${HOST_SYS}-libtool
> +        install -m 0644 libltdl/ltdl.h ${STAGING_INCDIR}/
> +        install -d ${STAGING_DATADIR}/libtool ${STAGING_DATADIR}/aclocal
> +        install -c config.guess ${STAGING_DATADIR}/libtool/
> +        install -c config.sub ${STAGING_DATADIR}/libtool/
> +        install -c -m 0644 ltmain.sh ${STAGING_DATADIR}/libtool/
> +        install -c -m 0644 libtool.m4 ${STAGING_DATADIR}/aclocal/
> +        install -c -m 0644 ltdl.m4 ${STAGING_DATADIR}/aclocal/
>  }
>
>  do_install () {
> ============================================================
> --- packages/libtool/libtool-native_1.5.10.bb   e1d2b08387782afbf7c5c6787a92d9af864dfb2d
> +++ packages/libtool/libtool-native_1.5.10.bb   bc799a0464069f3531cbb0a017c4d8d2a1afd63e
> @@ -1,7 +1,7 @@ require libtool_${PV}.bb
>  SECTION = "devel"
>  require libtool_${PV}.bb
>
> -PR = "r4"
> +PR = "r5"
>  FILESDIR = "${@os.path.dirname(bb.data.getVar('FILE',d,1))}/libtool-${PV}"
>  SRC_URI_append = " file://libdir-la.patch;patch=1 \
>                     file://prefix.patch;patch=1 \
> @@ -10,8 +10,6 @@ S = "${WORKDIR}/libtool-${PV}"
>                     file://install-path-check.patch;patch=1"
>  S = "${WORKDIR}/libtool-${PV}"
>
> -STAGING_DATADIR_safe := "${STAGING_DATADIR}"
> -
>  inherit native
>
>  do_stage () {
> @@ -19,22 +17,12 @@ do_stage () {
>         install -m 0755 libtoolize ${STAGING_BINDIR}/libtoolize
>         oe_libinstall -a -so -C libltdl libltdl ${STAGING_LIBDIR}
>         install -m 0644 libltdl/ltdl.h ${STAGING_INCDIR}/
> -       for dir in ${STAGING_DATADIR} ${STAGING_DATADIR_safe}; do
> -               ltdldir="${dir}/libtool/libltdl"
> -               install -d $dir/libtool \
> -                          $ltdldir \
> -                          $dir/aclocal
> -               install -c config.guess $dir/libtool/config.guess
> -               install -c config.sub $dir/libtool/config.sub
> -               install -c -m 0644 ltmain.sh $dir/libtool/
> -               install -c -m 0644 libtool.m4 $dir/aclocal/
> -               install -c -m 0644 ltdl.m4 $dir/aclocal/
> -
> -               for src in README COPYING.LIB Makefile.am configure.ac \
> -                               config-h.in ltdl.c ltdl.h; do
> -                       install -m 0644 libltdl/${src} ${ltdldir}
> -               done
> -       done
> +       install -d ${STAGING_DATADIR}/libtool ${STAGING_DATADIR}/aclocal
> +       install -c config.guess ${STAGING_DATADIR}/libtool/
> +       install -c config.sub ${STAGING_DATADIR}/libtool/
> +       install -c -m 0644 ltmain.sh ${STAGING_DATADIR}/libtool/
> +       install -c -m 0644 libtool.m4 ${STAGING_DATADIR}/aclocal/
> +       install -c -m 0644 ltdl.m4 ${STAGING_DATADIR}/aclocal/
>  }
>
>  do_install () {
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>
>



From skoroneos at digital-opsis.com  Tue May 15 08:10:29 2007
From: skoroneos at digital-opsis.com (Stelios Koroneos)
Date: Tue, 15 May 2007 11:10:29 +0300
Subject: [oe] minimal-image.bb
In-Reply-To: <f277n0$i00$2@sea.gmane.org>
Message-ID: <HOECLKEKOHLAMMGDLLBHGEIBLAAA.skoroneos@digital-opsis.com>

> -----Original Message-----
> From: openembedded-devel-bounces at openembedded.org
> [mailto:openembedded-devel-bounces at openembedded.org]On Behalf Of
> Rolf Leggewie
> Sent: Sunday, May 13, 2007 5:35 PM
> To: openembedded-devel at openembedded.org
> Subject: Re: [oe] minimal-image.bb
>
>
> Stelios Koroneos wrote:
> > In my opinion if angstrom-minimal-image is not distro specific should be
> > renamed to minimal-image
>
> I agree with Stelios that the belief that angstrom-minimal-image is a
> distro-specific image is a reasonable assumption.  If that is not the
> case, I am in favor renaming.


There is a bigger issue here than the name of package and that the reason i
brought this matter up.
Angstrom without any dough is the biggest distro supported by OE, but its
not the only one.
No one should also dough that Koen has done a lot of work (and is still
doing) and credits should go to him for a lot of the things in OE, including
the angstrom-minimal-image.bb, but i believe the real issue goes beyond the
developer/distro thing.

Actions like that, give the wrong signals to the people who are looking at
OE for incorporation/support of their products(and believe me there are
*alot* that do that as we speak)
If a distro maintainer (or any OE developer in that fact) comes with a way
of handling things better for his distro that could be used as a generic
framework for others it should be done so and not discouraged.

I am firm believer in community work and that things that could benefit the
OE community should be handled as such and not as distro-specific.






From no2spam at nospam.arcornews.de  Tue May 15 09:59:15 2007
From: no2spam at nospam.arcornews.de (Rolf Leggewie)
Date: Tue, 15 May 2007 11:59:15 +0200
Subject: [oe] minimal-image.bb
In-Reply-To: <HOECLKEKOHLAMMGDLLBHGEIBLAAA.skoroneos@digital-opsis.com>
References: <f277n0$i00$2@sea.gmane.org>
	<HOECLKEKOHLAMMGDLLBHGEIBLAAA.skoroneos@digital-opsis.com>
Message-ID: <f2c09j$8rd$1@sea.gmane.org>

Stelios Koroneos wrote:
> I am firm believer in community work and that things that could benefit the
> OE community should be handled as such and not as distro-specific.

I always thought that Angstrom was all about tearing walls down instead 
of building them up.

/me is baffled




From robin.farine at terminus.org  Tue May 15 11:22:39 2007
From: robin.farine at terminus.org (Robin Farine)
Date: Tue, 15 May 2007 13:22:39 +0200
Subject: [oe] RFC: machine customized ixp4xx NPE firmware
Message-ID: <200705151322.39110.robin.farine@terminus.org>

Hello everyone,

The platform I am working on is using NPE-B and NPE-C as Ethernet
interfaces. The ixp4xx-npe package from the OE snapshot I am 
currently
using builds firmware for NPE-B only and the firmware type is 
hard-coded
in "IxNpeMicrocode.h".

The patch below proposes a means of letting the machine 
configuration file
decide which NPE firmware to build.

Another but somewhat related point is the COMPATIBLE_MACHINE 
variable. If
my machine's name does not start with nslug or ixp4xx, I am forced 
to
change many package recipes (I suspect it is a FAQ but I do not seem 
to
able to access the mailing-list archive at the moment), perhaps a
COMPATIBLE_ARCH variable would be help here ?

Thanks,

Robin

diff --git 
a/packages/ixp4xx/ixp4xx-npe-native-2.3.2/IxNpeMicrocode.h 
b/packages/ixp4xx/ixp4xx-npe-native-2.3.2/IxNpeMicrocode.h
--- a/packages/ixp4xx/ixp4xx-npe-native-2.3.2/IxNpeMicrocode.h
+++ b/packages/ixp4xx/ixp4xx-npe-native-2.3.2/IxNpeMicrocode.h
@@ -42,7 +42,7 @@
 // #define IX_NPEDL_NPEIMAGE_NPEB_DMA
 // #define 
IX_NPEDL_NPEIMAGE_NPEB_ETH_SPAN_FIREWALL_VLAN_QOS_HDR_CONV
 // #define 
IX_NPEDL_NPEIMAGE_NPEB_ETH_LEARN_FILTER_SPAN_FIREWALL_VLAN_QOS
-#define IX_NPEDL_NPEIMAGE_NPEB_ETH_LEARN_FILTER_SPAN_FIREWALL
+// #define IX_NPEDL_NPEIMAGE_NPEB_ETH_LEARN_FILTER_SPAN_FIREWALL
 
 
 // #define 
IX_NPEDL_NPEIMAGE_NPEC_ETH_SPAN_MASK_FIREWALL_VLAN_QOS_HDR_CONV_EXTMIB
@@ -51,7 +51,7 @@
 // #define IX_NPEDL_NPEIMAGE_NPEC_DMA
 // #define IX_NPEDL_NPEIMAGE_NPEC_CRYPTO_AES_ETH_LEARN_FILTER_SPAN
 // #define 
IX_NPEDL_NPEIMAGE_NPEC_CRYPTO_AES_ETH_LEARN_FILTER_FIREWALL
-#define IX_NPEDL_NPEIMAGE_NPEC_CRYPTO_AES_CCM_ETH
+// #define IX_NPEDL_NPEIMAGE_NPEC_CRYPTO_AES_CCM_ETH
 // #define 
IX_NPEDL_NPEIMAGE_NPEC_CRYPTO_ETH_LEARN_FILTER_SPAN_FIREWALL
 // #define 
IX_NPEDL_NPEIMAGE_NPEC_ETH_SPAN_FIREWALL_VLAN_QOS_HDR_CONV
 // #define 
IX_NPEDL_NPEIMAGE_NPEC_ETH_LEARN_FILTER_SPAN_FIREWALL_VLAN_QOS
diff --git a/packages/ixp4xx/ixp4xx-npe-native_2.3.2.bb 
b/packages/ixp4xx/ixp4xx-npe-native_2.3.2.bb
--- a/packages/ixp4xx/ixp4xx-npe-native_2.3.2.bb
+++ b/packages/ixp4xx/ixp4xx-npe-native_2.3.2.bb
@@ -7,9 +7,14 @@ inherit native
 inherit native
 S = "${WORKDIR}/ixp400_xscale_sw/src/npeDl"
 
+# A space-separated list of CPP defines that select the firmware 
images
+# to build for the target machine.
+IXP4XX_NPE_FIRWMARE_DEFINES ?= "\
+-DIX_NPEDL_NPEIMAGE_NPEB_ETH_LEARN_FILTER_SPAN_FIREWALL"
+
 do_compile() {
 	mv ${WORKDIR}/IxNpeMicrocode.h ${S}/
-	gcc -Wall IxNpeMicrocode.c -o IxNpeMicrocode
+	gcc -Wall ${IXP4XX_NPE_FIRWMARE_DEFINES} IxNpeMicrocode.c -o 
IxNpeMicrocode
 }
 
 do_stage() {
diff --git a/packages/ixp4xx/ixp4xx-npe_2.3.2.bb 
b/packages/ixp4xx/ixp4xx-npe_2.3.2.bb
--- a/packages/ixp4xx/ixp4xx-npe_2.3.2.bb
+++ b/packages/ixp4xx/ixp4xx-npe_2.3.2.bb
@@ -13,7 +13,7 @@ S = "${WORKDIR}/ixp400_xscale_sw/src/npe
 
 COMPATIBLE_MACHINE = "(nslu2|ixp4xx)"
 
-FILES_${PN} = "${base_libdir}/firmware/NPE-B"
+FILES_${PN} = "${base_libdir}/firmware/NPE-*"
 
 do_compile() {
 	${STAGING_BINDIR_NATIVE}/IxNpeMicrocode-${PV} -be
@@ -21,13 +21,20 @@ do_compile() {
 
 do_install() {
 	install -d ${D}/${base_libdir}/firmware/
-	rm ${S}/NPE-B
-	mv ${S}/NPE-B.* ${S}/NPE-B
-	install ${S}/NPE-B ${D}/${base_libdir}/firmware/
+	for npe in A B C; do
+		rm ${S}/NPE-${npe} 2>/dev/null || true
+		mv ${S}/NPE-${npe}.* ${S}/NPE-${npe} 2>/dev/null || true
+		if test -f ${S}/NPE-${npe}; then
+			install -m 644 ${S}/NPE-${npe} ${D}/${base_libdir}/firmware/
+		fi
+	done
 }
 
 do_populate_staging() {
 	install -d ${STAGING_FIRMWARE_DIR}
-	install ${S}/NPE-B ${STAGING_FIRMWARE_DIR}/
+	for npe in A B C; do
+		if test -f ${S}/NPE-${npe}; then
+			install -m 644 ${S}/NPE-${npe} ${STAGING_FIRMWARE_DIR}/
+		fi
+	done
 }
-




From philip at balister.org  Tue May 15 11:47:07 2007
From: philip at balister.org (Philip Balister)
Date: Tue, 15 May 2007 07:47:07 -0400
Subject: [oe] Fixing up libtool-native and libtool-cross
In-Reply-To: <4648EB51.4040303@dominion.kabel.utwente.nl>
References: <4648EB51.4040303@dominion.kabel.utwente.nl>
Message-ID: <46499DBB.9080001@balister.org>

Can we apply these to the 1.5.22 libtool bb files also? I ahve added 
these with DEFAULT_PREFERENCE = "-1" since they have trouble building 
some packages, apparently due to looking in build system directories for 
libraries

Philip

Koen Kooi wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi,
> 
> Richard has fixed up libtool in Poky a bit and I want to merge his work into OE. Since
> it's 1 AM now, and libtool is a pretty 'core' part, I'm posting the patch for review
> before committing it tomorrow night.
> 
> regards,
> 
> Koen
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (Darwin)
> 
> iD8DBQFGSOtRMkyGM64RGpERAuiCAJ0Yqz+t4X/zNCjTbZIBU7yjaDt8twCgkgVq
> iM3uwQTciklpQKjurM34Nys=
> =W6UX
> -----END PGP SIGNATURE-----
> 
> 
> ------------------------------------------------------------------------
> 
> #
> # old_revision [990392a71744fa8ec062ee769a883473775269ee]
> #
> # patch "classes/autotools.bbclass"
> #  from [dced52fcafd4e224bafcb35c4fb04253857c7c3b]
> #    to [113ae9d1554b6e93d9c7a7fda84d71da4712caf9]
> # 
> # patch "packages/libtool/libtool-cross_1.5.10.bb"
> #  from [58b238af5bb9acdeca5b86c34b50c419fb49b55e]
> #    to [5134256c71b2d679838e87a55b084a99b1ac17d4]
> # 
> # patch "packages/libtool/libtool-native_1.5.10.bb"
> #  from [e1d2b08387782afbf7c5c6787a92d9af864dfb2d]
> #    to [bc799a0464069f3531cbb0a017c4d8d2a1afd63e]
> #
> ============================================================
> --- classes/autotools.bbclass	dced52fcafd4e224bafcb35c4fb04253857c7c3b
> +++ classes/autotools.bbclass	113ae9d1554b6e93d9c7a7fda84d71da4712caf9
> @@ -15,6 +15,10 @@ def autotools_dep_prepend(d):
>  
>  	if not pn in ['libtool', 'libtool-native', 'libtool-cross']:
>  		deps += 'libtool-native '
> +		if not bb.data.inherits_class('native', d) \
> +                        and not bb.data.inherits_class('cross', d) \
> +                        and not bb.data.getVar('INHIBIT_DEFAULT_DEPS', d, 1):
> +                    deps += 'libtool-cross '
>  
>  	return deps + 'gnu-config-native '
>  
> ============================================================
> --- packages/libtool/libtool-cross_1.5.10.bb	58b238af5bb9acdeca5b86c34b50c419fb49b55e
> +++ packages/libtool/libtool-cross_1.5.10.bb	5134256c71b2d679838e87a55b084a99b1ac17d4
> @@ -1,7 +1,7 @@ require libtool_${PV}.bb
>  SECTION = "devel"
>  require libtool_${PV}.bb
>  
> -PR = "r4"
> +PR = "r5"
>  PACKAGES = ""
>  FILESDIR = "${@os.path.dirname(bb.data.getVar('FILE',d,1))}/libtool-${PV}"
>  SRC_URI_append = " file://libdir-la.patch;patch=1 \
> @@ -21,6 +21,13 @@ do_stage () {
>  
>  do_stage () {
>          install -m 0755 ${HOST_SYS}-libtool ${bindir}/${HOST_SYS}-libtool
> +        install -m 0644 libltdl/ltdl.h ${STAGING_INCDIR}/
> +        install -d ${STAGING_DATADIR}/libtool ${STAGING_DATADIR}/aclocal
> +        install -c config.guess ${STAGING_DATADIR}/libtool/
> +        install -c config.sub ${STAGING_DATADIR}/libtool/
> +        install -c -m 0644 ltmain.sh ${STAGING_DATADIR}/libtool/
> +        install -c -m 0644 libtool.m4 ${STAGING_DATADIR}/aclocal/
> +        install -c -m 0644 ltdl.m4 ${STAGING_DATADIR}/aclocal/
>  }
>  
>  do_install () {
> ============================================================
> --- packages/libtool/libtool-native_1.5.10.bb	e1d2b08387782afbf7c5c6787a92d9af864dfb2d
> +++ packages/libtool/libtool-native_1.5.10.bb	bc799a0464069f3531cbb0a017c4d8d2a1afd63e
> @@ -1,7 +1,7 @@ require libtool_${PV}.bb
>  SECTION = "devel"
>  require libtool_${PV}.bb
>  
> -PR = "r4"
> +PR = "r5"
>  FILESDIR = "${@os.path.dirname(bb.data.getVar('FILE',d,1))}/libtool-${PV}"
>  SRC_URI_append = " file://libdir-la.patch;patch=1 \
>                     file://prefix.patch;patch=1 \
> @@ -10,8 +10,6 @@ S = "${WORKDIR}/libtool-${PV}"
>                     file://install-path-check.patch;patch=1"
>  S = "${WORKDIR}/libtool-${PV}"
>  
> -STAGING_DATADIR_safe := "${STAGING_DATADIR}"
> -
>  inherit native
>  
>  do_stage () {
> @@ -19,22 +17,12 @@ do_stage () {
>  	install -m 0755 libtoolize ${STAGING_BINDIR}/libtoolize
>  	oe_libinstall -a -so -C libltdl libltdl ${STAGING_LIBDIR}
>  	install -m 0644 libltdl/ltdl.h ${STAGING_INCDIR}/
> -	for dir in ${STAGING_DATADIR} ${STAGING_DATADIR_safe}; do
> -		ltdldir="${dir}/libtool/libltdl"
> -		install -d $dir/libtool \
> -			   $ltdldir \
> -			   $dir/aclocal
> -		install -c config.guess $dir/libtool/config.guess
> -		install -c config.sub $dir/libtool/config.sub
> -		install -c -m 0644 ltmain.sh $dir/libtool/
> -		install -c -m 0644 libtool.m4 $dir/aclocal/
> -		install -c -m 0644 ltdl.m4 $dir/aclocal/
> -
> -		for src in README COPYING.LIB Makefile.am configure.ac \
> -				config-h.in ltdl.c ltdl.h; do
> -			install -m 0644 libltdl/${src} ${ltdldir}
> -		done
> -	done
> +	install -d ${STAGING_DATADIR}/libtool ${STAGING_DATADIR}/aclocal
> +	install -c config.guess ${STAGING_DATADIR}/libtool/
> +	install -c config.sub ${STAGING_DATADIR}/libtool/
> +	install -c -m 0644 ltmain.sh ${STAGING_DATADIR}/libtool/
> +	install -c -m 0644 libtool.m4 ${STAGING_DATADIR}/aclocal/
> +	install -c -m 0644 ltdl.m4 ${STAGING_DATADIR}/aclocal/
>  }
>  
>  do_install () {
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3303 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.openembedded.org/pipermail/openembedded-devel/attachments/20070515/59453557/attachment-0001.bin>

From koen at dominion.kabel.utwente.nl  Tue May 15 12:53:17 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Tue, 15 May 2007 14:53:17 +0200
Subject: [oe] Fixing up libtool-native and libtool-cross
In-Reply-To: <46499DBB.9080001@balister.org>
References: <4648EB51.4040303@dominion.kabel.utwente.nl>
	<46499DBB.9080001@balister.org>
Message-ID: <4649AD3D.7070905@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Philip Balister schreef:
> Can we apply these to the 1.5.22 libtool bb files also? I ahve added
> these with DEFAULT_PREFERENCE = "-1" since they have trouble building
> some packages, apparently due to looking in build system directories for
> libraries

I pushed the updates to 1.5.10, could you fix 1.5.22?

TIA,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGSa09MkyGM64RGpERAiN+AJ0ZJTsW7GRLJi24EQy7QOpG1j0nGQCcDGq5
MGVDY5euyKwRk0sNTyg1Lag=
=3i/D
-----END PGP SIGNATURE-----



From leon.woestenberg at gmail.com  Tue May 15 18:38:37 2007
From: leon.woestenberg at gmail.com (Leon Woestenberg)
Date: Tue, 15 May 2007 20:38:37 +0200
Subject: [oe] RFC: machine customized ixp4xx NPE firmware
In-Reply-To: <200705151322.39110.robin.farine@terminus.org>
References: <200705151322.39110.robin.farine@terminus.org>
Message-ID: <c384c5ea0705151138n4087e20cx1f2971a69573091d@mail.gmail.com>

Hello Robin,

On 5/15/07, Robin Farine <robin.farine at terminus.org> wrote:
> +IXP4XX_NPE_FIRWMARE_DEFINES ?= "\
> +-DIX_NPEDL_NPEIMAGE_NPEB_ETH_LEARN_FILTER_SPAN_FIREWALL"
> +
>  do_compile() {
>         mv ${WORKDIR}/IxNpeMicrocode.h ${S}/
> -       gcc -Wall IxNpeMicrocode.c -o IxNpeMicrocode
> +       gcc -Wall ${IXP4XX_NPE_FIRWMARE_DEFINES} IxNpeMicrocode.c -o
>
Please change IXP4XX_NPE_FIRWMARE_DEFINES into IXP4X
IX_NPE_FIRMWARE_DEFINES.

The idea looks ok.

Regards,

Leon.



From robin.farine at terminus.org  Tue May 15 20:17:27 2007
From: robin.farine at terminus.org (Robin Farine)
Date: Tue, 15 May 2007 22:17:27 +0200
Subject: [oe] RFC: machine customized ixp4xx NPE firmware
In-Reply-To: <c384c5ea0705151138n4087e20cx1f2971a69573091d@mail.gmail.com>
References: <200705151322.39110.robin.farine@terminus.org>
	<c384c5ea0705151138n4087e20cx1f2971a69573091d@mail.gmail.com>
Message-ID: <200705152217.27815.rfarine@tilia.local>

On Tuesday May 15 2007 20:38, Leon Woestenberg wrote:
> On 5/15/07, Robin Farine <robin.farine at terminus.org> wrote:
> > +IXP4XX_NPE_FIRWMARE_DEFINES ?= "\
> > +-DIX_NPEDL_NPEIMAGE_NPEB_ETH_LEARN_FILTER_SPAN_FIREWALL"
> > +
> >  do_compile() {
> >         mv ${WORKDIR}/IxNpeMicrocode.h ${S}/
> > -       gcc -Wall IxNpeMicrocode.c -o IxNpeMicrocode
> > +       gcc -Wall ${IXP4XX_NPE_FIRWMARE_DEFINES}
> > IxNpeMicrocode.c -o
>
> Please change IXP4XX_NPE_FIRWMARE_DEFINES into IXP4X
> IX_NPE_FIRMWARE_DEFINES.

Ah, you mean s/FIRWMARE/FIRMWARE/, yes, makes sense :-). I'll fix 
this and submit the patch to the bug tracker.

> The idea looks ok.

Thanks for reviewing it.

Regards,

Robin



From rod at whitby.id.au  Wed May 16 01:24:07 2007
From: rod at whitby.id.au (Rod Whitby)
Date: Wed, 16 May 2007 10:54:07 +0930
Subject: [oe] RFC: machine customized ixp4xx NPE firmware
In-Reply-To: <200705151322.39110.robin.farine@terminus.org>
References: <200705151322.39110.robin.farine@terminus.org>
Message-ID: <464A5D37.4030401@whitby.id.au>

Robin Farine wrote:
> The platform I am working on is using NPE-B and NPE-C as Ethernet
> interfaces. The ixp4xx-npe package from the OE snapshot I am 
> currently
> using builds firmware for NPE-B only and the firmware type is 
> hard-coded
> in "IxNpeMicrocode.h".
> 
> The patch below proposes a means of letting the machine 
> configuration file
> decide which NPE firmware to build.

Thanks.  We'll be very happy to apply that patch.  I'll take a close
look at it tonight.

> Another but somewhat related point is the COMPATIBLE_MACHINE 
> variable. If
> my machine's name does not start with nslug or ixp4xx, I am forced 
> to
> change many package recipes (I suspect it is a FAQ but I do not seem 
> to
> able to access the mailing-list archive at the moment), perhaps a
> COMPATIBLE_ARCH variable would be help here ?

Which machine/arch are you using?  We can easily extend that
compatibility to include any other machines/archs that will use it.

-- Rod



From lenehan at twibble.org  Wed May 16 03:13:29 2007
From: lenehan at twibble.org (Jamie Lenehan)
Date: Wed, 16 May 2007 13:13:29 +1000
Subject: [oe] uclibc 0.9.29 recipe
In-Reply-To: <46461D72.4020206@dominion.kabel.utwente.nl>
References: <464613B3.8090003@dominion.kabel.utwente.nl>
	<46461B73.8070900@trolltech.com>
	<46461D72.4020206@dominion.kabel.utwente.nl>
Message-ID: <20070516031329.GA5205@twibble.org>

On Sat, May 12, 2007 at 10:02:58PM +0200, Koen Kooi wrote:
[...]
> I'll add it once I solved the linux-libc-headers problems. Machine and distro maintainers
> need to provide their parts of the uclibc configs to make it usefull, though.

Do we really need different distro based settings? It's always been a
bit annoying that some things will build with uclibc for one build
but not another due to differing uclibc settings - things are a lot
easier if there's only a single configuration.

For now I'd like to see a

  mtn -e mv uclibc-0.9.29/angstrom/uClibc.distro uclibc-0.9.29/uClibc.distro

and then only add distro based configuration if it turns out to be
really needed by some distro. This'll also gives us a default
configuration for people using other distros.

-- 
 Jamie Lenehan <lenehan at twibble.org>



From xjqian at gmail.com  Wed May 16 03:27:58 2007
From: xjqian at gmail.com (Junqian Gordon Xu)
Date: Tue, 15 May 2007 22:27:58 -0500
Subject: [oe] RFD: Bugzilla in general & bug triaging
In-Reply-To: <f29dkh$o3v$1@sea.gmane.org>
References: <1179059149.5404.3.camel@cimmeria.hyboria>	<f277j3$i00$1@sea.gmane.org>
	<f29dkh$o3v$1@sea.gmane.org>
Message-ID: <464A7A3E.9050905@gmail.com>

Rolf Leggewie wrote:
> I have asked and been granted greater powers on bugzilla.  There are 
> features which we don't use yet but which could aid in establishing a 
> sane workflow while rendering unnecessary the current clutches and 
> ad-hoc fixes.
>
> Bugzilla will be upgraded soon and no structural changes will be made 
> until that is completed.  But that leaves us some good time to think 
> about how this should be enhanced.
>   
two quibbles about the recent change in bugtracker
1) aligning left wastes lot of space on the right of the screen. I think 
the old "centered" scheme looks better.
2) "the Words field cannot be empty. You have to enter at lease on word 
in your search criteria". This is inconvenient for me to just browser 
the bugs.

> Things I'd like to see
> * confirmation flags
> * better documentation of workflow status (need to define it first)
> * assigning bugs (or if you prefer "Hey, please take a look")
> * link to some bug searches like the ones I send about 5 minutes ago
>    on the entry page
> * entry page clean-up (why two search fields?)
>   

> * removal of dead stuff (ZaurusKernel, Familiar)
>   
better hide them (sort of a archive in case some people want to dig into 
those) than remove
> Please add to the list.  The most important point is the second.  That 
> is what we should discuss.
>   
I agree on the necessity of the second point. Please have a list of 
best-practice/workflow rules (whatever they are) and hide the additional 
irrelevant features. A clean and uncluttered interface is also desirable.

Gordon



From lenehan at twibble.org  Wed May 16 05:16:01 2007
From: lenehan at twibble.org (Jamie Lenehan)
Date: Wed, 16 May 2007 15:16:01 +1000
Subject: [oe] uclibc 0.9.29 & SYS_SIGLIST
In-Reply-To: <464613B3.8090003@dominion.kabel.utwente.nl>
References: <464613B3.8090003@dominion.kabel.utwente.nl>
Message-ID: <20070516051600.GA5179@twibble.org>

Currently SYS_SIGLIST is disabled in uclibc but the site files all
say it's present. For the old uclibc version some of the
configurations enabled SYS_SIGLIST support and some didn't. We don't
really need it and the uclibc help says it's going to go away one day
so if no one objects I'll add the following site entries:

common-glibc

 bash_cv_under_sys_siglist=${bash_cv_under_sys_siglist=yes}
 bash_cv_sys_siglist=${bash_cv_sys_siglist=yes}
 ac_cv_have_decl_sys_siglist=${ac_cv_have_decl_sys_siglist=yes}

common-uclibc

 bash_cv_under_sys_siglist=${bash_cv_under_sys_siglist=no}
 bash_cv_sys_siglist=${bash_cv_sys_siglist=no}
 ac_cv_have_decl_sys_siglist=${ac_cv_have_decl_sys_siglist=no}

And remove the above entries from all the other site files.

This siglist things needs to be sorted out to build apr at least
(which is needed to build subversion).

-- 
 Jamie Lenehan <lenehan at twibble.org>



From leon.woestenberg at gmail.com  Wed May 16 07:26:22 2007
From: leon.woestenberg at gmail.com (Leon Woestenberg)
Date: Wed, 16 May 2007 09:26:22 +0200
Subject: [oe] uclibc 0.9.29 recipe
In-Reply-To: <20070516031329.GA5205@twibble.org>
References: <464613B3.8090003@dominion.kabel.utwente.nl>
	<46461B73.8070900@trolltech.com>
	<46461D72.4020206@dominion.kabel.utwente.nl>
	<20070516031329.GA5205@twibble.org>
Message-ID: <c384c5ea0705160026x5965bad9w9d2d0587ae574853@mail.gmail.com>

Hello Jamie,

On 5/16/07, Jamie Lenehan <lenehan at twibble.org> wrote:
> On Sat, May 12, 2007 at 10:02:58PM +0200, Koen Kooi wrote:

> For now I'd like to see a
>
>   mtn -e mv uclibc-0.9.29/angstrom/uClibc.distro uclibc-0.9.29/uClibc.distro
>
> and then only add distro based configuration if it turns out to be
> really needed by some distro. This'll also gives us a default
>
And that generic distro configuration would probably be a full
configuration (i.e. most options enabled) so that it would work for
most packages depending on C library functionality (or glibc
compatibility).

Distro's can optionally tune down the .distro by either:
- providing their own .distro
- mangling the resulting .config

Regards,
-- 
Leon



From koen at dominion.kabel.utwente.nl  Wed May 16 07:41:28 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Wed, 16 May 2007 09:41:28 +0200
Subject: [oe] uclibc 0.9.29 recipe
In-Reply-To: <20070516031329.GA5205@twibble.org>
References: <464613B3.8090003@dominion.kabel.utwente.nl>	<46461B73.8070900@trolltech.com>	<46461D72.4020206@dominion.kabel.utwente.nl>
	<20070516031329.GA5205@twibble.org>
Message-ID: <464AB5A8.8070500@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jamie Lenehan schreef:
> On Sat, May 12, 2007 at 10:02:58PM +0200, Koen Kooi wrote:
> [...]
>> I'll add it once I solved the linux-libc-headers problems. Machine and distro maintainers
>> need to provide their parts of the uclibc configs to make it usefull, though.
> 
> Do we really need different distro based settings? 

I tried to adhere to the existing uclibc infrastructure when adding 0.9.29, but maybe it's
time to rethink and overhaul it.

> It's always been a
> bit annoying that some things will build with uclibc for one build
> but not another due to differing uclibc settings - things are a lot
> easier if there's only a single configuration.
> 
> For now I'd like to see a
> 
>   mtn -e mv uclibc-0.9.29/angstrom/uClibc.distro uclibc-0.9.29/uClibc.distro

Fine by me, could you do that?

> and then only add distro based configuration if it turns out to be
> really needed by some distro. This'll also gives us a default
> configuration for people using other distros.

And gives us a better way to keep our site-files in sync.

regards,

Koen

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGSrWoMkyGM64RGpERAnrXAJwJFcLlBdZpiwEsf1Uw8DBL9agFtgCaA0ny
EleWYKtPe+qa1D9PIgGiJps=
=ByLX
-----END PGP SIGNATURE-----



From robin.farine at terminus.org  Wed May 16 08:56:46 2007
From: robin.farine at terminus.org (Robin Farine)
Date: Wed, 16 May 2007 10:56:46 +0200
Subject: [oe] RFC: machine customized ixp4xx NPE firmware
In-Reply-To: <464A5D37.4030401@whitby.id.au>
References: <200705151322.39110.robin.farine@terminus.org>
	<464A5D37.4030401@whitby.id.au>
Message-ID: <200705161056.46551.robin.farine@terminus.org>

On Wed May 16 2007 03:24, Rod Whitby wrote:
> Robin Farine wrote:

> > The patch below proposes a means of letting the machine
> > configuration file
> > decide which NPE firmware to build.
>
> Thanks.  We'll be very happy to apply that patch.  I'll take a
> close look at it tonight.

I forgot to disable line wrapping when I reposted it to the correct 
mailing-list... You may prefer to have a look at the cleaner 
version in bugzilla.

> Which machine/arch are you using?  We can easily extend that
> compatibility to include any other machines/archs that will use
> it.

Its a custom ixp425 big-endian board of which 2 functional exemplars 
currently exist :-). Not a problem, I just wondered whether 
something like COMPATIBLE_ARCH exists.

Robin



From rpurdie at rpsys.net  Wed May 16 10:44:45 2007
From: rpurdie at rpsys.net (Richard Purdie)
Date: Wed, 16 May 2007 11:44:45 +0100
Subject: [oe] RFC: machine customized ixp4xx NPE firmware
In-Reply-To: <464A5D37.4030401@whitby.id.au>
References: <200705151322.39110.robin.farine@terminus.org>
	<464A5D37.4030401@whitby.id.au>
Message-ID: <1179312285.5854.2.camel@localhost.localdomain>

On Wed, 2007-05-16 at 10:54 +0930, Rod Whitby wrote:
> Robin Farine wrote:
> > Another but somewhat related point is the COMPATIBLE_MACHINE 
> > variable. If
> > my machine's name does not start with nslug or ixp4xx, I am forced 
> > to
> > change many package recipes (I suspect it is a FAQ but I do not seem 
> > to
> > able to access the mailing-list archive at the moment), perhaps a
> > COMPATIBLE_ARCH variable would be help here ?
> 
> Which machine/arch are you using?  We can easily extend that
> compatibility to include any other machines/archs that will use it.

A neat way to handle this might be to define:

IXPMACHINES = "nslu2|ixp4xx|whatever"

and then the ixp specific .bb's check IXPMACHINES rather than a specific
list. The list would then be maintained in one place and is easily
updated if anyone adds a new ixp like machine.

I've not looked at the specifics, its just a random idea I had...

Cheers,

Richard







From golly at stellarwerx.com  Wed May 16 14:32:20 2007
From: golly at stellarwerx.com (Mark Gollahon)
Date: Wed, 16 May 2007 10:32:20 -0400 (EDT)
Subject: [oe] RFC: machine customized ixp4xx NPE firmware
Message-ID: <1179325940.4167@gatekeeper.stellarwerx.com>

Richard Purdie wrote ..
> 
> A neat way to handle this might be to define:
> 
> IXPMACHINES = "nslu2|ixp4xx|whatever"
> 
> and then the ixp specific .bb's check IXPMACHINES rather than a specific
> list. The list would then be maintained in one place and is easily
> updated if anyone adds a new ixp like machine.
> 
> I've not looked at the specifics, its just a random idea I had...
> 
> Cheers,
> 
> Richard

I want to second this approach as I tried awhile back to build OE for an IXP4XX-based machine that came into my possession and, during that time, ended up patching several IXP-specific .bb's to add my new machine.  My work would have been much easier had IXPMACHINES existed.

(NOTE: I did get it almost completely working, the only problem ended up being the networking ports didn't work, which, for a firewall machine, meant the device was useless.  There is an IC175 switch chip sitting between the IXP's two network ports and the physical ports and I couldn't figure out how to hack the IXP net driver to get the IC175 to pass eth frames.)

Regards,
-Mark Gollahon

From koen at dominion.kabel.utwente.nl  Thu May 17 08:01:53 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Thu, 17 May 2007 10:01:53 +0200
Subject: [oe] Questions about SDK generation
Message-ID: <464C0BF1.60300@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

During the build build of gcc-cross-sdk I noticed this:

NOTE: Running task 280 of 284 (ID: 5,
/home/koen/OE/monotone/org.openembedded.dev/packages/gcc/gcc-cross-sdk_4.1.2.bb, do_package)
NOTE: package gcc-cross-sdk-4.1.2: started
NOTE: package gcc-cross-sdk-4.1.2-r3: task do_package: started
NOTE: the following files were installed but not shipped in any package:
NOTE:   /usr/local/arm/oe/libexec/gcc/arm-angstrom-linux-gnueabi/4.1.2/install-tools/fixinc.sh
NOTE:   /usr/local/arm/oe/libexec/gcc/arm-angstrom-linux-gnueabi/4.1.2/install-tools/fixincl
NOTE:   /usr/local/arm/oe/libexec/gcc/arm-angstrom-linux-gnueabi/4.1.2/install-tools/mkheaders
NOTE:   /usr/local/arm/oe/lib/libiberty.a
NOTE:   /usr/local/arm/oe/lib/gcc/arm-angstrom-linux-gnueabi/4.1.2/install-tools/gsyslimits.h
NOTE:   /usr/local/arm/oe/lib/gcc/arm-angstrom-linux-gnueabi/4.1.2/install-tools/macro_list
NOTE:
/usr/local/arm/oe/lib/gcc/arm-angstrom-linux-gnueabi/4.1.2/install-tools/mkheaders.conf
NOTE:
/usr/local/arm/oe/lib/gcc/arm-angstrom-linux-gnueabi/4.1.2/install-tools/include/README
NOTE:
/usr/local/arm/oe/lib/gcc/arm-angstrom-linux-gnueabi/4.1.2/install-tools/include/float.h
NOTE:
/usr/local/arm/oe/lib/gcc/arm-angstrom-linux-gnueabi/4.1.2/install-tools/include/iso646.h
NOTE:
/usr/local/arm/oe/lib/gcc/arm-angstrom-linux-gnueabi/4.1.2/install-tools/include/stdarg.h
NOTE:
/usr/local/arm/oe/lib/gcc/arm-angstrom-linux-gnueabi/4.1.2/install-tools/include/stdbool.h
NOTE:
/usr/local/arm/oe/lib/gcc/arm-angstrom-linux-gnueabi/4.1.2/install-tools/include/stddef.h
NOTE:
/usr/local/arm/oe/lib/gcc/arm-angstrom-linux-gnueabi/4.1.2/install-tools/include/varargs.h
NOTE:
/usr/local/arm/oe/lib/gcc/arm-angstrom-linux-gnueabi/4.1.2/install-tools/include/mmintrin.h
NOTE:
/usr/local/arm/oe/lib/gcc/arm-angstrom-linux-gnueabi/4.1.2/install-tools/include/limits.h
NOTE:
/usr/local/arm/oe/lib/gcc/arm-angstrom-linux-gnueabi/4.1.2/install-tools/include/unwind.h
NOTE:   /usr/local/arm/oe/bin/arm-angstrom-linux-gnueabi-c++
NOTE:   /usr/local/arm/oe/bin/arm-angstrom-linux-gnueabi-gcc-4.1.2
NOTE:   /usr/local/arm/oe/include/mf-runtime.h
NOTE:   /usr/local/arm/oe/arm-angstrom-linux-gnueabi/lib/libsupc++.la
NOTE:   /usr/local/arm/oe/arm-angstrom-linux-gnueabi/lib/libsupc++.a
NOTE:   /usr/local/arm/oe/arm-angstrom-linux-gnueabi/lib/libstdc++_pic.a
NOTE:   /usr/local/arm/oe/arm-angstrom-linux-gnueabi/lib/libstdc++.la
NOTE:   /usr/local/arm/oe/arm-angstrom-linux-gnueabi/lib/libstdc++.a
NOTE:   /usr/local/arm/oe/arm-angstrom-linux-gnueabi/lib/libmudflap.so.0.0.0
NOTE:   /usr/local/arm/oe/arm-angstrom-linux-gnueabi/lib/libmudflap.la
NOTE:   /usr/local/arm/oe/arm-angstrom-linux-gnueabi/lib/libmudflap.a
NOTE:   /usr/local/arm/oe/arm-angstrom-linux-gnueabi/lib/libmudflapth.so.0.0.0
NOTE:   /usr/local/arm/oe/arm-angstrom-linux-gnueabi/lib/libmudflapth.la
NOTE:   /usr/local/arm/oe/arm-angstrom-linux-gnueabi/lib/libmudflapth.a
NOTE:   /usr/local/arm/oe/arm-angstrom-linux-gnueabi/lib/libiberty.a
NOTE:   /usr/local/arm/oe/arm-angstrom-linux-gnueabi/lib/libgcc_s.so
NOTE:   /usr/local/arm/oe/arm-angstrom-linux-gnueabi/lib/libstdc++.so
NOTE:   /usr/local/arm/oe/arm-angstrom-linux-gnueabi/lib/libmudflap.so.0
NOTE:   /usr/local/arm/oe/arm-angstrom-linux-gnueabi/lib/libmudflap.so
NOTE:   /usr/local/arm/oe/arm-angstrom-linux-gnueabi/lib/libmudflapth.so.0
NOTE:   /usr/local/arm/oe/arm-angstrom-linux-gnueabi/lib/libmudflapth.so

Is that intended?

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGTAvxMkyGM64RGpERAmi6AJ4vD8WTFN8JxW3K+3F4PGS0xlv9wACgsB9T
zZFHohWjeI8dRPcnGyrWypY=
=+uw+
-----END PGP SIGNATURE-----



From damwid at gmail.com  Fri May 18 12:08:40 2007
From: damwid at gmail.com (DAMWID)
Date: Fri, 18 May 2007 20:08:40 +0800
Subject: [oe] oe build failed
Message-ID: <464D9748.9000908@gmail.com>

Hi all,

I use OE to build rootfs for PXA270 board, but failed when compile
glibc, the following is error log:

[...]
| make[2]: Entering directory
`/work/bulvder/oe/build/tmp/work/armv5te-linux-gnueabi/glibc-2.3.5+cvs20050627-r13/libc/resource'
| ccache arm-linux-gnueabi-gcc -march=armv5te -mtune=xscale
../ports/sysdeps/unix/sysv/linux/arm/getrlimit.c -c -std=gnu99 -O2 -Wall
-Winline -Wstrict-prototypes -Wwrite-strings -fexpensive-optimizations
-frename-registers
-isystem/opt/arm-linux-gnueabi/arm-linux-gnueabi/include
-fomit-frame-pointer -I../include -I.
-I/work/bulvder/oe/build/tmp/work/armv5te-linux-gnueabi/glibc-2.3.5+cvs20050627-r13/build-arm-linux-gnueabi/resource
-I.. -I../libio
-I/work/bulvder/oe/build/tmp/work/armv5te-linux-gnueabi/glibc-2.3.5+cvs20050627-r13/build-arm-linux-gnueabi
-I../ports/sysdeps/arm/elf
-I../ports/sysdeps/unix/sysv/linux/arm/linuxthreads
-I../ports/sysdeps/unix/sysv/linux/arm
-I../ports/sysdeps/unix/sysv/linux -I../ports/sysdeps/unix/sysv
-I../ports/sysdeps/unix/arm -I../ports/sysdeps/unix
-I../ports/sysdeps/arm/linuxthreads -I../ports/sysdeps/arm
-I../sysdeps/wordsize-32 -I../sysdeps/ieee754/flt-32
-I../sysdeps/ieee754/dbl-64 -I../linuxthreads/sysdeps/unix/sysv/linux
-I../linuxthreads/sysdeps/pthread -I../sysdeps/pthread
-I../linuxthreads/sysdeps/unix/sysv -I../linuxthreads/sysdeps/unix
-I../sysdeps/unix/sysv/linux -I../sysdeps/gnu -I../sysdeps/unix/common
-I../sysdeps/unix/mman -I../sysdeps/unix/inet -I../sysdeps/unix/sysv
-I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/ieee754
-I../sysdeps/generic/elf -I../sysdeps/generic -nostdinc -isystem
/opt/arm-linux-gnueabi/lib/gcc/arm-linux-gnueabi/4.1.1/include -isystem
/opt/arm-linux-gnueabi/arm-linux-gnueabi/include -D_LIBC_REENTRANT
-include ../include/libc-symbols.h -o
/work/bulvder/oe/build/tmp/work/armv5te-linux-gnueabi/glibc-2.3.5+cvs20050627-r13/build-arm-linux-gnueabi/resource/getrlimit.o
-MD -MP -MF
/work/bulvder/oe/build/tmp/work/armv5te-linux-gnueabi/glibc-2.3.5+cvs20050627-r13/build-arm-linux-gnueabi/resource/getrlimit.o.dt
-MT
/work/bulvder/oe/build/tmp/work/armv5te-linux-gnueabi/glibc-2.3.5+cvs20050627-r13/build-arm-linux-gnueabi/resource/getrlimit.o
| In file included from ../ports/sysdeps/unix/sysv/linux/arm/getrlimit.c:1:
| ../sysdeps/unix/sysv/linux/i386/getrlimit.c: In function
'__new_getrlimit':
| ../sysdeps/unix/sysv/linux/i386/getrlimit.c:65: error:
'__NR_getrlimit' undeclared (first use in this function)
| ../sysdeps/unix/sysv/linux/i386/getrlimit.c:65: error: (Each
undeclared identifier is reported only once
| ../sysdeps/unix/sysv/linux/i386/getrlimit.c:65: error: for each
function it appears in.)
| make[2]: ***
[/work/bulvder/oe/build/tmp/work/armv5te-linux-gnueabi/glibc-2.3.5+cvs20050627-r13/build-arm-linux-gnueabi/resource/getrlimit.o]
Error 1
| make[2]: Leaving directory
`/work/bulvder/oe/build/tmp/work/armv5te-linux-gnueabi/glibc-2.3.5+cvs20050627-r13/libc/resource'
| make[1]: *** [resource/subdir_lib] Error 2
| make[1]: Leaving directory
`/work/bulvder/oe/build/tmp/work/armv5te-linux-gnueabi/glibc-2.3.5+cvs20050627-r13/libc'
| make: *** [all] Error 2
| FATAL: oe_runmake failed
NOTE: Task failed:
/work/bulvder/oe/build/tmp/work/armv5te-linux-gnueabi/glibc-2.3.5+cvs20050627-r13/temp/log.do_compile.17022
NOTE: package glibc-2.3.5+cvs20050627-r13: task do_compile: failed
ERROR: TaskFailed event exception, aborting
NOTE: package glibc-2.3.5+cvs20050627: failed

Does anyone know what is the problem? Attachment is my local.conf.

Thanks,
Damwid

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: local.conf
URL: <http://lists.openembedded.org/pipermail/openembedded-devel/attachments/20070518/dd30f3c3/attachment-0001.ksh>

From koen at dominion.kabel.utwente.nl  Fri May 18 12:36:49 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Fri, 18 May 2007 14:36:49 +0200
Subject: [oe] oe build failed
In-Reply-To: <464D9748.9000908@gmail.com>
References: <464D9748.9000908@gmail.com>
Message-ID: <464D9DE1.8000700@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

DAMWID schreef:
> Hi all,
> 
> I use OE to build rootfs for PXA270 board, but failed when compile
> glibc, the following is error log:

Use the local.conf from http://www.angstrom-distribution.org/building-angstrom

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGTZ3hMkyGM64RGpERAmXOAJsEMKrOhU5Z90hWZkVpQmk6QP7IlwCgrFnV
dw5F8T02dKoMip7pUr/ys1c=
=0Ux5
-----END PGP SIGNATURE-----



From rpurdie at rpsys.net  Sat May 19 17:50:15 2007
From: rpurdie at rpsys.net (Richard Purdie)
Date: Sat, 19 May 2007 18:50:15 +0100
Subject: [oe] do_rootfs fails
In-Reply-To: <4644B4D1.5010803@klever.net>
References: <4644ABCB.6080202@openhardware.net>
	<4644B0D2.8020409@dominion.kabel.utwente.nl>
	<4644B4D1.5010803@klever.net>
Message-ID: <1179597015.5852.5.camel@localhost.localdomain>

On Fri, 2007-05-11 at 20:24 +0200, Michael Krelin wrote:
> There's also an option of asking Tom to bitbake -DDD and send it to
> zecke, because I couldn't find time to try BB 1.6 for him again. And let
> him apply the patch that fixes this problem:
> 
> Index: lib/bb/parse/parse_py/BBHandler.py
> ===================================================================
> --- lib/bb/parse/parse_py/BBHandler.py  (revision 817)
> +++ lib/bb/parse/parse_py/BBHandler.py  (working copy)
> @@ -66,7 +66,9 @@
>          if not file in __inherit_cache.split():
>              debug(2, "BB %s:%d: inheriting %s" % (fn, lineno, file))
>              __inherit_cache += " %s" % file
> +            data.setVar('__inherit_cache', __inherit_cache, d)
>              include(fn, file, d)
> +            __inherit_cache = data.getVar('__inherit_cache', d) or ""
>      data.setVar('__inherit_cache', __inherit_cache, d)

Thanks for this, I've merged into bitbake 1.9, 1.8 and 1.6 branches as
they all had this issue!

Cheers,

Richard





From koen at dominion.kabel.utwente.nl  Sat May 19 17:58:32 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Sat, 19 May 2007 19:58:32 +0200
Subject: [oe] RFC: make do_install and do_deploy a PACKAGE_FUNC
In-Reply-To: <463C9EA9.2060302@dominion.kabel.utwente.nl>
References: <463C9EA9.2060302@dominion.kabel.utwente.nl>
Message-ID: <464F3AC8.5000804@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Koen Kooi schreef:
> Hi,
> 
> Lately there have been several problems with files not getting packaged, because users
> resumed builds after a failure. Richard has come up with a fix:
> 
> http://www.rpsys.net/openzaurus/temp/oe-install-change.patch
> 
> The only bug with that patch is that do_deploy fails, which can be solved by making that a
>  PACKAGE_FUNC as well.
> 
> What do you think about that?

So this is bugfree and can go in immediately?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGTzrIMkyGM64RGpERAnN8AJ9NQh73txV4w4h4FyCp8+Zj95R7UQCcChwH
ti0bnbez4K1Iqgbt+futJ4A=
=1Jkw
-----END PGP SIGNATURE-----



From rpurdie at rpsys.net  Sat May 19 20:13:01 2007
From: rpurdie at rpsys.net (Richard Purdie)
Date: Sat, 19 May 2007 21:13:01 +0100
Subject: [oe] RFC: make do_install and do_deploy a PACKAGE_FUNC
In-Reply-To: <464F3AC8.5000804@dominion.kabel.utwente.nl>
References: <463C9EA9.2060302@dominion.kabel.utwente.nl>
	<464F3AC8.5000804@dominion.kabel.utwente.nl>
Message-ID: <1179605582.5852.9.camel@localhost.localdomain>

On Sat, 2007-05-19 at 19:58 +0200, Koen Kooi wrote:
> Koen Kooi schreef:
> > Hi,
> > 
> > Lately there have been several problems with files not getting packaged, because users
> > resumed builds after a failure. Richard has come up with a fix:
> > 
> > http://www.rpsys.net/openzaurus/temp/oe-install-change.patch
> > 
> > The only bug with that patch is that do_deploy fails, which can be solved by making that a
> >  PACKAGE_FUNC as well.
> > 
> > What do you think about that?
> 
> So this is bugfree and can go in immediately?

I'm in two minds about this.

An alternative is we stop populate_packages() moving files around,
copying them instead. This means deploy can run after install, install
can be a separate task and builds should continue where they left of if
interrupted during the packaging phase.

Opinions?

Richard




From leon.woestenberg at gmail.com  Sun May 20 15:45:56 2007
From: leon.woestenberg at gmail.com (Leon Woestenberg)
Date: Sun, 20 May 2007 17:45:56 +0200
Subject: [oe] RFC: make do_install and do_deploy a PACKAGE_FUNC
In-Reply-To: <1179605582.5852.9.camel@localhost.localdomain>
References: <463C9EA9.2060302@dominion.kabel.utwente.nl>
	<464F3AC8.5000804@dominion.kabel.utwente.nl>
	<1179605582.5852.9.camel@localhost.localdomain>
Message-ID: <c384c5ea0705200845w36cf4274x6b22f03cdf01506d@mail.gmail.com>

Hello,

On 5/19/07, Richard Purdie <rpurdie at rpsys.net> wrote:
> An alternative is we stop populate_packages() moving files around,
> copying them instead. This means deploy can run after install, install
> can be a separate task and builds should continue where they left of if
> interrupted during the packaging phase.
>
> Opinions?
>
Looks sane to me.

Leon.



From ulf at atmel.com  Sat May 26 21:07:51 2007
From: ulf at atmel.com (Ulf Samuelsson)
Date: Sat, 26 May 2007 23:07:51 +0200
Subject: [oe] OpenEmbedded insist on downloading existing package
Message-ID: <00b801c79fd9$ee494f90$0302a8c0@atmel.com>

I have defined the download location to and
I have linux-2.6.21.1.tar.bz2 in this directory.

OpenEmbedded seems to ignore this and insists on *downloading*
linux-2.6.21.1.tar.bz2 before use.

- This is no fun.

Anything that can be done?


Best Regards
Ulf Samuelsson




From freyther at gmx.net  Sun May 20 21:47:58 2007
From: freyther at gmx.net (Holger Freyther)
Date: Sun, 20 May 2007 23:47:58 +0200
Subject: [oe] OpenEmbedded insist on downloading existing package
In-Reply-To: <00b801c79fd9$ee494f90$0302a8c0@atmel.com>
References: <00b801c79fd9$ee494f90$0302a8c0@atmel.com>
Message-ID: <66584307-3DAA-4B3C-8A5F-32915D6FF1EC@gmx.net>


Am 26.05.2007 um 23:07 schrieb Ulf Samuelsson:

> I have defined the download location to and
> I have linux-2.6.21.1.tar.bz2 in this directory.
>
> OpenEmbedded seems to ignore this and insists on *downloading*
> linux-2.6.21.1.tar.bz2 before use.
>
> - This is no fun.
>
> Anything that can be done?

Well,

you play with the guts and hope it is working. First you need to have  
a filename.md5 in the same directory otherwise the fetcher will  
continue fetching (this is what you see) and then you might need to  
add a fetched stamp. As this stamp gets created  when the md5sum/ 
sha256sum was verified.


I don't know your reasoning but there must be a better answer to your  
problem.

z.





From koen at dominion.kabel.utwente.nl  Sun May 20 21:48:21 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Sun, 20 May 2007 23:48:21 +0200
Subject: [oe] OpenEmbedded insist on downloading existing package
In-Reply-To: <00b801c79fd9$ee494f90$0302a8c0@atmel.com>
References: <00b801c79fd9$ee494f90$0302a8c0@atmel.com>
Message-ID: <4650C225.9010907@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ulf Samuelsson schreef:
> I have defined the download location to and
> I have linux-2.6.21.1.tar.bz2 in this directory.

is linux-2.6.21.1.tar.bz2.md5 present there?

> OpenEmbedded seems to ignore this and insists on *downloading*
> linux-2.6.21.1.tar.bz2 before use.

if the md5 stamp isn't present it will try to download it again till the downloads
completes and linux-2.6.21.1.tar.bz2.md5 has been created.

> - This is no fun.
> 
> Anything that can be done?

See above.

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGUMIlMkyGM64RGpERAus1AKCLYQPDm8IRkOCvT3TqF/UFWiOCogCfdf2T
W/f6t+bzYKRlzcnbqhs2yYA=
=cJI9
-----END PGP SIGNATURE-----



From ulf at atmel.com  Mon May 21 06:14:43 2007
From: ulf at atmel.com (Ulf Samuelsson)
Date: Mon, 21 May 2007 08:14:43 +0200
Subject: [oe] OpenEmbedded insist on downloading existing package
References: <00b801c79fd9$ee494f90$0302a8c0@atmel.com>
	<4650C225.9010907@dominion.kabel.utwente.nl>
Message-ID: <005201c79b6f$56130270$0302a8c0@atmel.com>

> Ulf Samuelsson schreef:
>> I have defined the download location to and
>> I have linux-2.6.21.1.tar.bz2 in this directory.
> 
> is linux-2.6.21.1.tar.bz2.md5 present there?
> 
>> OpenEmbedded seems to ignore this and insists on *downloading*
>> linux-2.6.21.1.tar.bz2 before use.
> 
> if the md5 stamp isn't present it will try to download it again till the downloads
> completes and linux-2.6.21.1.tar.bz2.md5 has been created.
> 


Thanks, I will try this...

Best Regards
Ulf Samuelsson




From koen at dominion.kabel.utwente.nl  Mon May 21 07:56:09 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Mon, 21 May 2007 09:56:09 +0200
Subject: [oe] RFC: make do_install and do_deploy a PACKAGE_FUNC
In-Reply-To: <1179605582.5852.9.camel@localhost.localdomain>
References: <463C9EA9.2060302@dominion.kabel.utwente.nl>	<464F3AC8.5000804@dominion.kabel.utwente.nl>
	<1179605582.5852.9.camel@localhost.localdomain>
Message-ID: <46515099.6070006@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Richard Purdie schreef:
> On Sat, 2007-05-19 at 19:58 +0200, Koen Kooi wrote:
>> Koen Kooi schreef:
>>> Hi,
>>>
>>> Lately there have been several problems with files not getting packaged, because users
>>> resumed builds after a failure. Richard has come up with a fix:
>>>
>>> http://www.rpsys.net/openzaurus/temp/oe-install-change.patch
>>>
>>> The only bug with that patch is that do_deploy fails, which can be solved by making that a
>>>  PACKAGE_FUNC as well.
>>>
>>> What do you think about that?
>> So this is bugfree and can go in immediately?
> 
> I'm in two minds about this.
> 
> An alternative is we stop populate_packages() moving files around,
> copying them instead. This means deploy can run after install, install
> can be a separate task and builds should continue where they left of if
> interrupted during the packaging phase.
> 
> Opinions?

The copy-don't-move approach sounds good.

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGUVCZMkyGM64RGpERAoEMAJ4rFonlztzdou+L5L79M1Rk1hzn8gCePSjP
qXJHJlIfgDOSd+SkD1Bei1c=
=mo1f
-----END PGP SIGNATURE-----



From france at handhelds.org  Sun May 20 22:48:30 2007
From: france at handhelds.org (George France)
Date: Sun, 20 May 2007 18:48:30 -0400
Subject: [oe] baned from #OE IRC channel
Message-ID: <200705201848.30692.france@handhelds.org>

Hello,

This afternoon on Sunday May 20th, 2007 at about 18:30 EST (GMT-5) while on 
the #oe channel, I was banned by Kergoth for no apparent reason.  I had not 
said a single word, I was just listening like I always do.

What is going on?

--George



From ulf at atmel.com  Mon May 21 19:15:58 2007
From: ulf at atmel.com (Ulf Samuelsson)
Date: Mon, 21 May 2007 21:15:58 +0200
Subject: [oe] ERROR: Task 2246 ( ...
 org.openembedded.dev/packages/gnome/gnome-desktop_2.16.1.bb,
 do_compile) failed
Message-ID: <4651EFEE.50907@atmel.com>

Looks like there is an issue with the fdl.xml in this package?
Any workarounds?



NOTE: Running task 2742 of 3946 (ID: 2246, /home/ulf/projects/OpenEmbedded/org.openembedded.dev/packages/gnome/gnome-desktop_2.16.1.bb, do_compile)
NOTE: package gnome-desktop-2.16.1: started
NOTE: package gnome-desktop-2.16.1-r1: task do_compile: started
ERROR: function do_compile failed
ERROR: log data follows (/home/ulf/projects/OpenEmbedded/build/tmp/work/armv5te-angstrom-linux-gnueabi/gnome-desktop-2.16.1-r1/temp/log.do_compile.24525)
| NOTE: make
| make  all-recursive
| make[1]: Entering directory `/home/ulf/projects/OpenEmbedded/build/tmp/work/armv5te-angstrom-linux-gnueabi/gnome-desktop-2.16.1-r1/gnome-desktop-2.16.1'
| Making all in po
| make[2]: Entering directory `/home/ulf/projects/OpenEmbedded/build/tmp/work/armv5te-angstrom-linux-gnueabi/gnome-desktop-2.16.1-r1/gnome-desktop-2.16.1/po'
| make[2]: Nothing to be done for `all'.
| make[2]: Leaving directory `/home/ulf/projects/OpenEmbedded/build/tmp/work/armv5te-angstrom-linux-gnueabi/gnome-desktop-2.16.1-r1/gnome-desktop-2.16.1/po'
| Making all in libgnome-desktop
| make[2]: Entering directory `/home/ulf/projects/OpenEmbedded/build/tmp/work/armv5te-angstrom-linux-gnueabi/gnome-desktop-2.16.1-r1/gnome-desktop-2.16.1/libgnome-desktop'
| Making all in libgnome
| make[3]: Entering directory `/home/ulf/projects/OpenEmbedded/build/tmp/work/armv5te-angstrom-linux-gnueabi/gnome-desktop-2.16.1-r1/gnome-desktop-2.16.1/libgnome-desktop/libgnome'
| make[3]: Nothing to be done for `all'.
| make[3]: Leaving directory `/home/ulf/projects/OpenEmbedded/build/tmp/work/armv5te-angstrom-linux-gnueabi/gnome-desktop-2.16.1-r1/gnome-desktop-2.16.1/libgnome-desktop/libgnome'
| Making all in libgnomeui
| make[3]: Entering directory `/home/ulf/projects/OpenEmbedded/build/tmp/work/armv5te-angstrom-linux-gnueabi/gnome-desktop-2.16.1-r1/gnome-desktop-2.16.1/libgnome-desktop/libgnomeui'
| make[3]: Nothing to be done for `all'.
| make[3]: Leaving directory `/home/ulf/projects/OpenEmbedded/build/tmp/work/armv5te-angstrom-linux-gnueabi/gnome-desktop-2.16.1-r1/gnome-desktop-2.16.1/libgnome-desktop/libgnomeui'
| make[3]: Entering directory `/home/ulf/projects/OpenEmbedded/build/tmp/work/armv5te-angstrom-linux-gnueabi/gnome-desktop-2.16.1-r1/gnome-desktop-2.16.1/libgnome-desktop'
| make[3]: Nothing to be done for `all-am'.
| make[3]: Leaving directory `/home/ulf/projects/OpenEmbedded/build/tmp/work/armv5te-angstrom-linux-gnueabi/gnome-desktop-2.16.1-r1/gnome-desktop-2.16.1/libgnome-desktop'
| make[2]: Leaving directory `/home/ulf/projects/OpenEmbedded/build/tmp/work/armv5te-angstrom-linux-gnueabi/gnome-desktop-2.16.1-r1/gnome-desktop-2.16.1/libgnome-desktop'
| Making all in gnome-about
| make[2]: Entering directory `/home/ulf/projects/OpenEmbedded/build/tmp/work/armv5te-angstrom-linux-gnueabi/gnome-desktop-2.16.1-r1/gnome-desktop-2.16.1/gnome-about'
| Making all in headers
| make[3]: Entering directory `/home/ulf/projects/OpenEmbedded/build/tmp/work/armv5te-angstrom-linux-gnueabi/gnome-desktop-2.16.1-r1/gnome-desktop-2.16.1/gnome-about/headers'
| make[3]: Nothing to be done for `all'.
| make[3]: Leaving directory `/home/ulf/projects/OpenEmbedded/build/tmp/work/armv5te-angstrom-linux-gnueabi/gnome-desktop-2.16.1-r1/gnome-desktop-2.16.1/gnome-about/headers'
| make[3]: Entering directory `/home/ulf/projects/OpenEmbedded/build/tmp/work/armv5te-angstrom-linux-gnueabi/gnome-desktop-2.16.1-r1/gnome-desktop-2.16.1/gnome-about'
| make[3]: Nothing to be done for `all-am'.
| make[3]: Leaving directory `/home/ulf/projects/OpenEmbedded/build/tmp/work/armv5te-angstrom-linux-gnueabi/gnome-desktop-2.16.1-r1/gnome-desktop-2.16.1/gnome-about'
| make[2]: Leaving directory `/home/ulf/projects/OpenEmbedded/build/tmp/work/armv5te-angstrom-linux-gnueabi/gnome-desktop-2.16.1-r1/gnome-desktop-2.16.1/gnome-about'
| Making all in pixmaps
| make[2]: Entering directory `/home/ulf/projects/OpenEmbedded/build/tmp/work/armv5te-angstrom-linux-gnueabi/gnome-desktop-2.16.1-r1/gnome-desktop-2.16.1/pixmaps'
| make[2]: Nothing to be done for `all'.
| make[2]: Leaving directory `/home/ulf/projects/OpenEmbedded/build/tmp/work/armv5te-angstrom-linux-gnueabi/gnome-desktop-2.16.1-r1/gnome-desktop-2.16.1/pixmaps'
| Making all in desktop-docs
| make[2]: Entering directory `/home/ulf/projects/OpenEmbedded/build/tmp/work/armv5te-angstrom-linux-gnueabi/gnome-desktop-2.16.1-r1/gnome-desktop-2.16.1/desktop-docs'
| Making all in fdl
| make[3]: Entering directory `/home/ulf/projects/OpenEmbedded/build/tmp/work/armv5te-angstrom-linux-gnueabi/gnome-desktop-2.16.1-r1/gnome-desktop-2.16.1/desktop-docs/fdl'
| xsltproc -o fdl-es.omf --stringparam db2omf.basename fdl --stringparam db2omf.format 'docbook' --stringparam db2omf.dtd "-//OASIS//DTD DocBook XML V4.1.2//EN" --stringparam db2omf.lang es --stringparam db2omf.omf_dir "/usr/share/omf" --stringparam db2omf.help_dir "/usr/share/gnome/help"
--stringparam db2omf.omf_in "`pwd`//home/ulf/projects/OpenEmbedded/build/tmp/work/armv5te-angstrom-linux-gnueabi/gnome-desktop-2.16.1-r1/gnome-desktop-2.16.1/desktop-docs/fdl/fdl.omf.in" `/home/ulf/projects/OpenEmbedded/build/tmp/staging/i686-linux/bin/pkg-config --variable db2omf gnome-doc-utils`
es/fdl.xml
| warning: failed to load external entity
"/home/ulf/projects/OpenEmbedded/build/tmp/work/armv5te-angstrom-linux-gnueabi/gnome-desktop-2.16.1-r1/gnome-desktop-2.16.1/desktop-docs/fdl//home/ulf/projects/OpenEmbedded/build/tmp/work/armv5te-angstrom-linux-gnueabi/gnome-desktop-2.16.1-r1/gnome-desktop-2.16.1/desktop-docs/fdl/fdl.omf.in"
| db2omf: Could not construct the OMF maintainer element.
|   Add an author, corpauthor, editor, othercredit, or publisher
|   element with the role attribute set to "maintainer" to fdl.xml.
| make[3]: *** [fdl-es.omf] Error 10
| make[3]: Leaving directory `/home/ulf/projects/OpenEmbedded/build/tmp/work/armv5te-angstrom-linux-gnueabi/gnome-desktop-2.16.1-r1/gnome-desktop-2.16.1/desktop-docs/fdl'
| make[2]: *** [all-recursive] Error 1
| make[2]: Leaving directory `/home/ulf/projects/OpenEmbedded/build/tmp/work/armv5te-angstrom-linux-gnueabi/gnome-desktop-2.16.1-r1/gnome-desktop-2.16.1/desktop-docs'
| make[1]: *** [all-recursive] Error 1
| make[1]: Leaving directory `/home/ulf/projects/OpenEmbedded/build/tmp/work/armv5te-angstrom-linux-gnueabi/gnome-desktop-2.16.1-r1/gnome-desktop-2.16.1'
| make: *** [all] Error 2
| FATAL: oe_runmake failed
NOTE: Task failed: /home/ulf/projects/OpenEmbedded/build/tmp/work/armv5te-angstrom-linux-gnueabi/gnome-desktop-2.16.1-r1/temp/log.do_compile.24525
NOTE: package gnome-desktop-2.16.1-r1: task do_compile: failed
ERROR: TaskFailed event exception, aborting
NOTE: package gnome-desktop-2.16.1: failed
ERROR: Build of /home/ulf/projects/OpenEmbedded/org.openembedded.dev/packages/gnome/gnome-desktop_2.16.1.bb do_compile failed
ERROR: Task 2246 (/home/ulf/projects/OpenEmbedded/org.openembedded.dev/packages/gnome/gnome-desktop_2.16.1.bb, do_compile) failed
ERROR: '/home/ulf/projects/OpenEmbedded/org.openembedded.dev/packages/gnome/gnome-desktop_2.16.1.bb' failed
ulf at aeglos:~/projects/OpenEmbedded/build>


-- 
Best Regards,
Ulf Samuelsson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ulf.vcf
Type: text/x-vcard
Size: 301 bytes
Desc: not available
URL: <http://lists.openembedded.org/pipermail/openembedded-devel/attachments/20070521/b04bd7f9/attachment-0001.vcf>

From freyther at gmx.net  Mon May 21 21:53:12 2007
From: freyther at gmx.net (Holger Freyther)
Date: Mon, 21 May 2007 23:53:12 +0200
Subject: [oe] ERROR: Task 2246 ( ...
	org.openembedded.dev/packages/gnome/gnome-desktop_2.16.1.bb,
	do_compile) failed
In-Reply-To: <4651EFEE.50907@atmel.com>
References: <4651EFEE.50907@atmel.com>
Message-ID: <189F751D-9A54-4A17-84FD-82CD2BF62403@gmx.net>


Am 21.05.2007 um 21:15 schrieb Ulf Samuelsson:

> Looks like there is an issue with the fdl.xml in this package?
> Any workarounds?

Did you lack internet connectivity during the build?







From nils.faerber at kernelconcepts.de  Mon May 21 23:05:27 2007
From: nils.faerber at kernelconcepts.de (Nils Faerber)
Date: Tue, 22 May 2007 01:05:27 +0200
Subject: [oe] Problem wt. perl-native building for PXA
Message-ID: <465225B7.50900@kernelconcepts.de>

Hi!
I am encountering a strange problem while trying to build Angstrom for
PXA (for LinuxTag demo purposes). While we have some other machines
building it with the same version of OE and Bitbake just fine it fails
on my notebook (but I would like to be able to rebuild it directly at
LinuxTag, thus the question).
My machine has Ubuntu feisty installed. I am using Bitbake 1.8 from SVN
and an OE checkout from today.

What happens is that the build works quite well until it comes to
perl-native-5.8.8-r7. There it fails with the following error:

...
|       Making x2p stuff
| make[1]: Entering directory
`/media/disk/oe/build_h5xxx/tmp/work/i686-linux/perl-native-5.8.8-r7/perl-5.8.8/x2p'
| You haven't done a "make depend" yet!
| make[1]: *** [hash.o] Error 1
...
[ full log attached ]

I have the feeling that it has something to do with my host setup but I
have no clue what!? If I comment out the dependency check from the
source directory (outch, hack!) it compiles fine and continues. Most
other packages work to compile then until
libxml-parser-perl-native_2.34.bb which again fails because of a
misinstallation of the per utils in the staging directory.

I am really quite clueless what might be the reason.
If anyone encoutered this before I would be glad to share hints to
resolve the situation ;)

Thanks!

Cheers
  nils faerber

-- 
kernel concepts GbR      Tel: +49-271-771091-12
Sieghuetter Hauptweg 48  Fax: +49-271-771091-19
D-57072 Siegen           Mob: +49-176-21024535
--
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: log.do_compile.6371
URL: <http://lists.openembedded.org/pipermail/openembedded-devel/attachments/20070522/dc1f1f01/attachment-0001.ksh>

From rpurdie at rpsys.net  Mon May 21 23:20:19 2007
From: rpurdie at rpsys.net (Richard Purdie)
Date: Tue, 22 May 2007 00:20:19 +0100
Subject: [oe] Problem wt. perl-native building for PXA
In-Reply-To: <465225B7.50900@kernelconcepts.de>
References: <465225B7.50900@kernelconcepts.de>
Message-ID: <1179789619.5849.59.camel@localhost.localdomain>

Hi,

On Tue, 2007-05-22 at 01:05 +0200, Nils Faerber wrote:
> I am encountering a strange problem while trying to build Angstrom for
> PXA (for LinuxTag demo purposes). While we have some other machines
> building it with the same version of OE and Bitbake just fine it fails
> on my notebook (but I would like to be able to rebuild it directly at
> LinuxTag, thus the question).
> My machine has Ubuntu feisty installed. I am using Bitbake 1.8 from SVN
> and an OE checkout from today.
> 
> What happens is that the build works quite well until it comes to
> perl-native-5.8.8-r7. There it fails with the following error:

I'm not familiar with the error but what does /bin/sh point at?

If its dash, try bash as dash causes no end of headaches.

Cheers,

Richard





From nils.faerber at kernelconcepts.de  Mon May 21 23:34:59 2007
From: nils.faerber at kernelconcepts.de (Nils Faerber)
Date: Tue, 22 May 2007 01:34:59 +0200
Subject: [oe] Problem wt. perl-native building for PXA
In-Reply-To: <1179789619.5849.59.camel@localhost.localdomain>
References: <465225B7.50900@kernelconcepts.de>
	<1179789619.5849.59.camel@localhost.localdomain>
Message-ID: <46522CA3.1010000@kernelconcepts.de>

Richard Purdie schrieb:
> Hi,
Hi!

> On Tue, 2007-05-22 at 01:05 +0200, Nils Faerber wrote:
>> I am encountering a strange problem while trying to build Angstrom for
>> PXA (for LinuxTag demo purposes). While we have some other machines
>> building it with the same version of OE and Bitbake just fine it fails
>> on my notebook (but I would like to be able to rebuild it directly at
>> LinuxTag, thus the question).
>> My machine has Ubuntu feisty installed. I am using Bitbake 1.8 from SVN
>> and an OE checkout from today.
>>
>> What happens is that the build works quite well until it comes to
>> perl-native-5.8.8-r7. There it fails with the following error:
> 
> I'm not familiar with the error but what does /bin/sh point at?
> 
> If its dash, try bash as dash causes no end of headaches.

Is tihs Ubuntu?
I did never recognise this, but you are perfectly right with your
assumption, sh -> dash.

Gee, hey look, now it works!!!
This dash thing should be tarred and feathered ;)

Many thanks!

> Cheers,
> Richard
Cheers
  nils faerber

-- 
kernel concepts GbR      Tel: +49-271-771091-12
Sieghuetter Hauptweg 48  Fax: +49-271-771091-19
D-57072 Siegen           Mob: +49-176-21024535
--



From ulf at atmel.com  Tue May 22 04:24:27 2007
From: ulf at atmel.com (Ulf Samuelsson)
Date: Tue, 22 May 2007 06:24:27 +0200
Subject: [oe] ERROR: Task 2246 (
	...org.openembedded.dev/packages/gnome/gnome-desktop_2.16.1.bb,
	do_compile) failed
References: <4651EFEE.50907@atmel.com>
	<189F751D-9A54-4A17-84FD-82CD2BF62403@gmx.net>
Message-ID: <003a01c79c29$1985a690$26031a0a@atmel.com>

> 
> Am 21.05.2007 um 21:15 schrieb Ulf Samuelsson:
> 
>> Looks like there is an issue with the fdl.xml in this package?
>> Any workarounds?
> 
> Did you lack internet connectivity during the build?
> 


I have been trying to build this for a couple of days,
and sometimes the connections has been bad.


Been trying to fetch all packages in advance by 

$ bitbake -c fetch gpe-image

but that does not work.


Best Regards
Ulf Samuelsson




From no2spam at nospam.arcornews.de  Tue May 22 07:53:51 2007
From: no2spam at nospam.arcornews.de (Rolf Leggewie)
Date: Tue, 22 May 2007 09:53:51 +0200
Subject: [oe] ERROR: Task 2246 (
 ...org.openembedded.dev/packages/gnome/gnome-desktop_2.16.1.bb,
 do_compile) failed
In-Reply-To: <003a01c79c29$1985a690$26031a0a@atmel.com>
References: <4651EFEE.50907@atmel.com>	<189F751D-9A54-4A17-84FD-82CD2BF62403@gmx.net>
	<003a01c79c29$1985a690$26031a0a@atmel.com>
Message-ID: <f2u7if$5g3$1@sea.gmane.org>

Ulf Samuelsson wrote:
> Been trying to fetch all packages in advance by 
> 
> $ bitbake -c fetch gpe-image
> 
> but that does not work.

You want bitbake -c fetchall gpe-image




From koen at dominion.kabel.utwente.nl  Tue May 22 08:28:16 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Tue, 22 May 2007 10:28:16 +0200
Subject: [oe] ERROR: Task 2246 (
 ...org.openembedded.dev/packages/gnome/gnome-desktop_2.16.1.bb,
 do_compile) failed
In-Reply-To: <f2u7if$5g3$1@sea.gmane.org>
References: <4651EFEE.50907@atmel.com>	<189F751D-9A54-4A17-84FD-82CD2BF62403@gmx.net>	<003a01c79c29$1985a690$26031a0a@atmel.com>
	<f2u7if$5g3$1@sea.gmane.org>
Message-ID: <4652A9A0.6060109@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Rolf Leggewie schreef:
> Ulf Samuelsson wrote:
>> Been trying to fetch all packages in advance by 
>>
>> $ bitbake -c fetch gpe-image
>>
>> but that does not work.
> 
> You want bitbake -c fetchall gpe-image

Actually, no. With angstrom you want 'bitbake -c fetchall angstrom-x11-image'

regards,

KOen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGUqmgMkyGM64RGpERArd8AJ96Hc/IqpB0nHLyNOSlImfhs6AbcQCdFGJS
ok7J/m0QH6pWYgfm1Qww0y0=
=tovE
-----END PGP SIGNATURE-----



From openembedded at hrw.one.pl  Tue May 22 08:43:46 2007
From: openembedded at hrw.one.pl (Marcin Juszkiewicz)
Date: Tue, 22 May 2007 10:43:46 +0200
Subject: [oe] ERROR: Task 2246 (
	...org.openembedded.dev/packages/gnome/gnome-desktop_2.16.1.bb,
	do_compile) failed
In-Reply-To: <003a01c79c29$1985a690$26031a0a@atmel.com>
References: <4651EFEE.50907@atmel.com>
	<189F751D-9A54-4A17-84FD-82CD2BF62403@gmx.net>
	<003a01c79c29$1985a690$26031a0a@atmel.com>
Message-ID: <200705221043.47508.openembedded@hrw.one.pl>

Dnia wtorek, 22 maja 2007, Ulf Samuelsson napisa?:

> Been trying to fetch all packages in advance by
>
> $ bitbake -c fetch gpe-image
>
> but that does not work.

"bitbake -cfetchall gpe-image" is for that


-- 
JID: hrw-jabber.org
OpenEmbedded developer/consultant

       If you're going down in flames, aim for something expensive.





From freyther at gmx.net  Tue May 22 09:53:37 2007
From: freyther at gmx.net (Holger Freyther)
Date: Tue, 22 May 2007 11:53:37 +0200
Subject: [oe] ERROR: Task 2246 (
	...org.openembedded.dev/packages/gnome/gnome-desktop_2.16.1.bb,
	do_compile) failed
In-Reply-To: <003a01c79c29$1985a690$26031a0a@atmel.com>
References: <4651EFEE.50907@atmel.com>
	<189F751D-9A54-4A17-84FD-82CD2BF62403@gmx.net>
	<003a01c79c29$1985a690$26031a0a@atmel.com>
Message-ID: <75DD721B-B0C4-46EF-A8F2-838E8DB5CF85@gmx.net>

>
>
> Been trying to fetch all packages in advance by
>
> $ bitbake -c fetch gpe-image

Hi,

even with that you will have the issue from before.

Q: What is the issue?
A: I'm not a XML geek but I think xsltproc and xmllint will download  
doctype and schemata during the generation of the documentation. I  
don't know if one can make xstlproc not to do it, this would be  
something for you to find out (xstlproc --help). What you can do/try  
is to add EXTRA_OECONF += " --disable-doc" in the offending recipes.


z.




From lvcargnini at gmail.com  Wed May 23 01:56:18 2007
From: lvcargnini at gmail.com (=?ISO-8859-1?Q?Lu=EDs_Cargnini?=)
Date: Tue, 22 May 2007 22:56:18 -0300
Subject: [oe] problems cross-compilinx xserver-xorg
Message-ID: <ae36f8040705221856p1ec52709y284a370bbc1af3ee@mail.gmail.com>

Hi I'm trying to bitbake xserver-xorg (cvs version) and I received the
following results:

NOTE: xserver-xorg-6.8.1+cvs20070523-cvs://anoncvs.freedesktop.org/cvs/xorghas
no section, not checking URI
NOTE: xserver-xorg-6.8.1+cvs20070523-file://imake-staging.patch has no
section, not checking URI
NOTE: xserver-xorg-6.8.1+cvs20070523-file://dri.patch has no section, not
checking URI
NOTE: package xserver-xorg-6.8.1+cvs20070523-r3: task do_fetch: completed
NOTE: package xserver-xorg-6.8.1+cvs20070523-r3: task do_unpack: started
NOTE: Unpacking
/home/lvcargnini/puc/instramed/openembedded/build/sources/xc_anoncvs.freedesktop.org__20070523.tar.gz
to
/home/lvcargnini/puc/instramed/openembedded/tmp/work/armv5te-linux/xserver-
xorg-6.8.1+cvs20070523-r3/
NOTE: package xserver-xorg-6.8.1+cvs20070523-r3: task do_unpack: completed
NOTE: package xserver-xorg-6.8.1+cvs20070523-r3: task do_patch: started
NOTE: Applying patch 'imake-staging.patch'
NOTE: Task failed: Command Error: exit status: 127  Output:
sh: quilt: command not found
NOTE: package xserver-xorg-6.8.1+cvs20070523-r3: task do_patch: failed
ERROR: TaskFailed event exception, aborting
NOTE: package xserver-xorg-6.8.1+cvs20070523: failed
ERROR: Build of 'xserver-xorg' failed
Build statistics:
  Attempted builds: 1
  Failed builds: 1
someone please could help me ?
my local.conf:

(enterprise:~/puc/instramed/openembedded) lvcargnini% cat
build/conf/local.conf
#
# OpenEmbedded local configuration file (sample)
#
# Please visit the Wiki at http://openembedded.org/ for more info.
#
#
# Be SURE to read this file in its entirety and the GettingStarted page on
the
# wiki before proceeding.
#
# Once you have done that, remove the line at the end of this
# file and build away.
#
# WARNING: lines starting with a space (' ') will result in parse failures.
# Remove '# ' from commented lines to activate them.
#
# NOTE: Do NOT use $HOME in your paths, BitBake does NOT expand ~ for you.
If you
# must have paths relative to your homedir use ${HOME} (note the {}'s there
# you MUST have them for the variable expansion to be done by BitBake).
Your
# paths should all be absolute paths (They should all start with a / after
# expansion.  Stuff like starting with ${HOME} or ${TOPDIR} is ok).

# Use this to specify where BitBake should place the downloaded sources into
DL_DIR = "/home/lvcargnini/puc/instramed/openembedded/build/sources"

# Delete the line below. Then specify which .bb files to consider for
# your build. Typically this will be something like BBFILES =
"/path/to/openembedded/packages/*/*.bb"
BBFILES :=
"/home/lvcargnini/puc/instramed/openembedded/org.openembedded.dev/packages/*/*.bb"

# Use the BBMASK below to instruct BitBake to _NOT_ consider some .bb files
# This is a regulary expression, so be sure to get your parenthesis
balanced.
BBMASK = ""

# Uncomment this if you want to use a prebuilt toolchain. You will need to
# provide packages for toolchain and additional libraries yourself. You also
# have to set PATH in your environment to make sure BitBake finds additional
binaries.
# Note: You will definitely need to say:
#     ASSUME_PROVIDED += "virtual/arm-linux-gcc-2.95"
# to build any of two Linux 2.4 Embedix kernels,
# i.e. openzaurus-sa-2.4.18 and openzaurus-pxa-2.4.18 - and don't forget
# to rename the binaries as instructed in the Wiki.
# ASSUME_PROVIDED += "virtual/${TARGET_PREFIX}gcc virtual/libc"
ASSUME_PROVIDED += "/opt/eldk/usr/bin"
# Select between multiple alternative providers, if more than one is
eligible.
PREFERRED_PROVIDERS = "virtual/qte:qte virtual/libqpe:libqpe-opie"
PREFERRED_PROVIDERS += " virtual/libsdl:libsdl-x11"
PREFERRED_PROVIDERS += "
virtual/${TARGET_PREFIX}gcc-initial:gcc-cross-initial"
PREFERRED_PROVIDERS += " virtual/${TARGET_PREFIX}gcc:gcc-cross"
PREFERRED_PROVIDERS += " virtual/${TARGET_PREFIX}g++:gcc-cross"

# Uncomment this to specify where BitBake should create its temporary files.
# Note that a full build of everything in OpenEmbedded will take GigaBytes
of hard
# disk space, so make sure to free enough space. The default TMPDIR is
# <build directory>/tmp
# Don't use symlinks in in the path to avoid problems
# TMPDIR = /usr/local/projects/oetmp
TMPDIR=/home/lvcargnini/puc/instramed/openembedded/tmp
# Uncomment this to specify a machine to build for. See the conf directory
# for machines currently known to OpenEmbedded. This will automatically take
care
# of TARGET_ARCH
# MACHINE = "c7x0"
MACHINE = "omap5912osk"
# Use this to specify the target architecture. Note that this is only
# needed when building for a machine not known to OpenEmbedded. Better use
# the MACHINE attribute (see above)
# TARGET_ARCH = "arm"
TARGET_ARCH = "arm"
# Use this to specify the target operating system.  The default is "linux",
# for a normal linux system with glibc. Set this to "linux-uclibc" if you
want
# to build a uclibc based system.
# Normally the DISTRO of your choosing will take care of this
# TARGET_OS = "linux"
# TARGET_OS = "linux-uclibc"
TARGET_OS = "linux"
# Uncomment this to select a distribution policy. See the conf directory
# for distributions currently known to OpenEmbedded.
# Although it no longer contain version number in the (file-)name
# openzaurus-unstable is a so called "versioned"  distro, i.e. they
# explicitely select specific versions of various packages.
# Stay away from unversioned distros unless you really know what you are
doing
# DISTRO = "generic"
DISTRO = "generic"
# So far, angstrom.conf sets ENABLE_BINARY_LOCALE_GENERATION
# to generate binary locale packages at build time using qemu-native and
# thereby guarantee i18n support on all devices. If your build breaks on
# qemu-native consider disabling ENABLE_BINARY_LOCALE_GENERATION (note that
# this breaks i18n on devices with less than 128MB RAM) or installing
# a working third-party qemu (e.g. provided by your distribution) and
# adding qemu-native to ASSUME_PROVIDED. Caveat emptor, since third-party
# qemus lack patches needed to work with various OE targets.
# ENABLE_BINARY_LOCALE_GENERATION = "0"
# ASSUME_PROVIDED += "qemu-native"

# If ENABLE_BINARY_LOCALE_GENERATION is set to "1", you can limit locales
# generated to the list provided by GLIBC_GENERATE_LOCALES. This is huge
# time-savior for developmental builds. Format: list of locale.encodingpairs
# with spaces as separators.
# GLIBC_GENERATE_LOCALES = "en_GB.UTF-8 de_DE.UTF-8"
GLIBC_GENERATE_LOCALES = "en en_GB fr it de pt_BR"
# Uncomment this to select a particular major kernel version if the MACHINE
setting
# supports more than one major kernel version. Currently this is suported by
the
# following MACHINE types: poodle, tosa and simpad.
# MACHINE_KERNEL_VERSION = "2.6"

# Uncomment one of these to build packages during the build process.
# This is done automatically if you set DISTRO (see above)
# INHERIT = "package_ipk"
INHERIT = "package_tar"

# Add the required image file system types below. Valid are jffs2, tar,
cramfs and ext2
IMAGE_FSTYPES = "jffs2 tar cramfs"

# Uncomment this to disable the parse cache (not recommended).
# CACHE = ""

# Uncomment this if you want BitBake to emit debugging output
# BBDEBUG = "yes"
BBDEBUG = "yes
# Uncomment these two if you want BitBake to build images useful for
debugging.
# Note that INHIBIT_PACKAGE_STRIP needs a package format to be defined.
# Also note that OE now produces -dbg packages which contain debugging
symbols.
# DEBUG_BUILD = "1"
# INHIBIT_PACKAGE_STRIP = "1"

# Uncomment these to build a package such that you can use gprof to profile
it.
# NOTE: This will only work with 'linux' targets, not
# 'linux-uclibc', as uClibc doesn't provide the necessary
# object files.  Also, don't build glibc itself with these
# flags, or it'll fail to build.
#
# PROFILE_OPTIMIZATION = "-pg"
# SELECTED_OPTIMIZATION = "${PROFILE_OPTIMIZATION}"
# LDFLAGS =+ "-pg"

# Uncomment this to enable parallel make.
# This allows make to spawn mutliple processes to take advantage of multiple

# processors. Useful on SMP machines. This may break some packages - we're
# in the process of marking these so let us know if you find any.
# PARALLEL_MAKE = "-j 4"

# Uncomment this if you want BitBake to emit the log if a build fails.
BBINCLUDELOGS = "yes"

-- 
------------------------------------------------------------------------------
Thanks && Regards
Msc. Bsc. Lu?s Vit?rio Cargnini
IEEE Member
Electrical Engineer Faculty @ PUCRS
Ipiranga Avenue, 6681 ? Building 30
P.O. Box: 90619-900 ? Porto Alegre/RS
Phone: +55 51 3320 3500  extension: 7696
---------------------------------------------------------------------------------


From mc-lists at tesco.net  Wed May 23 04:17:39 2007
From: mc-lists at tesco.net (Matt Callow)
Date: Wed, 23 May 2007 14:17:39 +1000
Subject: [oe] problems cross-compilinx xserver-xorg
In-Reply-To: <ae36f8040705221856p1ec52709y284a370bbc1af3ee@mail.gmail.com>
References: <ae36f8040705221856p1ec52709y284a370bbc1af3ee@mail.gmail.com>
Message-ID: <5937bed10705222117h314bc92cxc26261af9fcb2fb4@mail.gmail.com>

On 5/23/07, Lu?s Cargnini <lvcargnini at gmail.com> wrote:
> Hi I'm trying to bitbake xserver-xorg (cvs version) and I received the
> following results:
>
...
> sh: quilt: command not found

This looks like your problem. Try installing quilt.

Matt



From lenehan at twibble.org  Thu May 24 02:35:51 2007
From: lenehan at twibble.org (Jamie Lenehan)
Date: Thu, 24 May 2007 12:35:51 +1000
Subject: [oe] Problem wt. perl-native building for PXA
In-Reply-To: <46522CA3.1010000@kernelconcepts.de>
References: <465225B7.50900@kernelconcepts.de>
	<1179789619.5849.59.camel@localhost.localdomain>
	<46522CA3.1010000@kernelconcepts.de>
Message-ID: <20070524023551.GA31623@twibble.org>

On Tue, May 22, 2007 at 01:34:59AM +0200, Nils Faerber wrote:
> Richard Purdie schrieb:
> > Hi,
> Hi!
> 
> > On Tue, 2007-05-22 at 01:05 +0200, Nils Faerber wrote:
[...]
> >> My machine has Ubuntu feisty installed. I am using Bitbake 1.8 from SVN
[...]
> >> What happens is that the build works quite well until it comes to
> >> perl-native-5.8.8-r7. There it fails with the following error:
[...]
> Is tihs Ubuntu?
> I did never recognise this, but you are perfectly right with your
> assumption, sh -> dash.
> 
> Gee, hey look, now it works!!!

> This dash thing should be tarred and feathered ;)

I actually tested perl-native with dash, and it builds just fine here
when using dash:

  ~%> ./bb -b packages/perl/perl-native_5.8.8.bb 
  ...
  NOTE: package perl-native-5.8.8: completed
  ~%> ls -l /bin/sh
  lrwxrwxrwx 1 root root 4 2007-05-24 12:05 /bin/sh -> dash*
  ~%> cat /etc/issue.net 
  Ubuntu 6.10

In theory the following patch should fix the dash issues you were
seeing. Is their someone seeing this dash/perl-native issues that
could test this?

# 
# old_revision [d28c26f2757f88207089404b9e74286950165915]
# 
# add_file "packages/perl/perl-5.8.8/native-makedepend-dash.patch"
#  content [a32ff3bf1b75c57f6ff7ac58b232cc44f2648a27]
# 
# patch "packages/perl/perl-native_5.8.8.bb"
#  from [3013e9425fe473cf0988c3ccf6cad2b894e62e58]
#    to [e95283c93197ba0c2c16f42feef3c0b6691a7a53]
# 
============================================================
--- packages/perl/perl-5.8.8/native-makedepend-dash.patch	a32ff3bf1b75c57f6ff7ac58b232cc44f2648a27
+++ packages/perl/perl-5.8.8/native-makedepend-dash.patch	a32ff3bf1b75c57f6ff7ac58b232cc44f2648a27
@@ -0,0 +1,13 @@
+Index: perl-5.8.8/makedepend.SH
+===================================================================
+--- perl-5.8.8.orig/makedepend.SH	2007-05-24 12:06:52.000000000 +1000
++++ perl-5.8.8/makedepend.SH	2007-05-24 12:27:33.000000000 +1000
+@@ -128,7 +128,7 @@
+     *.y) filebase=`basename $file .y` ;;
+     esac
+     case "$file" in
+-    */*) finc="-I`echo $file | sed 's#/[^/]*$##`" ;;
++    */*) finc="-I`echo $file | sed 's#/[^/]*$##'`" ;;
+     *)   finc= ;;
+     esac
+     $echo "Finding dependencies for $filebase$_o."
============================================================
--- packages/perl/perl-native_5.8.8.bb	3013e9425fe473cf0988c3ccf6cad2b894e62e58
+++ packages/perl/perl-native_5.8.8.bb	e95283c93197ba0c2c16f42feef3c0b6691a7a53
@@ -12,7 +12,8 @@ SRC_URI = "http://ftp.funet.fi/pub/CPAN/
            file://Configure-multilib.patch;patch=1 \
            file://perl-configpm-switch.patch;patch=1 \
            file://native-nopacklist.patch;patch=1 \
-           file://native-no-gdbminc.patch;patch=1"
+           file://native-no-gdbminc.patch;patch=1 \
+           file://native-makedepend-dash.patch;patch=1"
 
 S = "${WORKDIR}/perl-${PV}"
 


-- 
 Jamie Lenehan <lenehan at twibble.org>



From Scott.Davis at smiths-aerospace.com  Tue May 22 19:17:43 2007
From: Scott.Davis at smiths-aerospace.com (Davis, Scott (AGRE))
Date: Tue, 22 May 2007 13:17:43 -0600
Subject: [oe]  Building Python extensions
Message-ID: <BDD06CD3363F254993AED78CA36350E20324E06D@cossmgmbx07.EMAIL.CORP.TLD>


I am trying to build a 32-bit shared library for a C library I have on
an x86_64 AMD SuSE linux system.  I am observing the same problem that
apparently someone on your list has had.  I have a commercial C 32-bit
linux library that I want to use SWIG to build a python extension for.
My linux system is 64-bit and when I compile against Python.h for Python
2.4 I get #error LONG BIT below emitted. 

The original post is at the URL below:
http://projects.linuxtogo.org/pipermail/openembedded-devel/2007-March/00
1722.html

What is the fix to build 32-bit shared library python extension on a
64-bit linux system?

#if LONG_BIT != 8 * SIZEOF_LONG 
/* 04-Oct-2000 LONG_BIT is apparently (mis)defined as 64 on some recent 
* 32-bit platforms using gcc. We try to catch that here at compile-time 
* rather than waiting for integer multiplication to trigger bogus *
overflows. */
 #error "LONG_BIT definition appears wrong for platform (bad gcc/glibc
config?)." 
#endif 

Scott Davis
GE
Aviation
Digital Systems
Principal Software Engineer

T 616 224 6659
F 616 241 8707
E scott.davis at smiths-aerospace.com
www.ge.com/aviation 

3290 Patterson Ave, SE 
Grand Rapids, MI 49512, U.S.A.



</table> </Pre>
<HTML>
<br>
<br>
************************************************<br>
The information contained in, or attached to, this e-mail, may contain confidential information and is intended solely for the use of the individual or entity to whom they are addressed and may be subject to legal privilege.  If you have received this e-mail in error you should notify the sender immediately by reply e-mail, delete the message from your system and notify your system manager.  Please do not copy it for any purpose, or disclose its contents to any other person.  The views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of the company.  The recipient should check this e-mail and any attachments for the presence of viruses.  The company accepts no liability for any damage caused, directly or indirectly, by any virus transmitted in this email.<br>
************************************************<br>
</HTML>

From openembedded at hrw.one.pl  Thu May 24 12:03:52 2007
From: openembedded at hrw.one.pl (Marcin Juszkiewicz)
Date: Thu, 24 May 2007 14:03:52 +0200
Subject: [oe] Building Python extensions
In-Reply-To: <BDD06CD3363F254993AED78CA36350E20324E06D@cossmgmbx07.EMAIL.CORP.TLD>
References: <BDD06CD3363F254993AED78CA36350E20324E06D@cossmgmbx07.EMAIL.CORP.TLD>
Message-ID: <200705241403.55472.openembedded@hrw.one.pl>

Dnia wtorek, 22 maja 2007, Davis, Scott (AGRE) napisa?:
> I am trying to build a 32-bit shared library for a C library I have on
> an x86_64 AMD SuSE linux system.  I am observing the same problem that
> apparently someone on your list has had.  I have a commercial C 32-bit
> linux library that I want to use SWIG to build a python extension for.
> My linux system is 64-bit and when I compile against Python.h for
> Python 2.4 I get #error LONG BIT below emitted.

> What is the fix to build 32-bit shared library python extension on a
> 64-bit linux system?

check OE/packages/python/python-gst/python-path.patch and 
python-gst_0.10.7.bb recipe

Both add --with-python-includes param to configure script with location of 
proper 32bit headers.

-- 
JID: hrw-jabber.org
OpenEmbedded developer/consultant

               We're bad people and we do bad things [Pink]





From mwester at dls.net  Sat May 26 07:53:40 2007
From: mwester at dls.net (Mike (mwester))
Date: Sat, 26 May 2007 02:53:40 -0500
Subject: [oe] PREFERRED_PROVIDER syntax is eluding me...
Message-ID: <038201c79f6a$f9859720$6e01a8c0@twilight>

I'm missing something simple, I expect.  But try as I might, I cannot figure
this out.

Bitbake 1.8.3, building unslung-image (worked fine on 1.6): Bitbake says:
[snip]
NOTE: multiple providers are available for runtime libc6-unslung (glibc,
glibc-initial);
NOTE: consider defining a PREFERRED_PROVIDER entry to match runtime
libc6-unslung
[snip]

This is a problem, because with bitbake 1.8, without a preferred provider
specified, it seems to try to build both.  But only glibc builds;
glibc-initial fails (and the build loops forever).   This is easily fixed by
adding the following line to the local.conf file:

PREFERRED_PROVIDER_libc6-unslung = "glibc"

Except that it doesn't do a blasted thing.  Neither does this line:

PREFERRED_PROVIDERS += " libc6-unslung:glibc"

Thinking that perhaps the "-unslung" was implied since the machine is
"unslung", I tried:

PREFERRED_PROVIDERS += " libc6:glibc"

Still no change.  Being persistent, I tried every variant of the above that
I could think of, to no avail.  It seems that bitbake is not understanding
or processing the info provided.  The -D flag offers no further hints,
either.

For background, back in the glibc bitbake recipes, glibc-initial.bb does a
"require" of glibc.bb (hence the multiple providers).  Near the tail-end of
glibc.bb we find:

PACKAGES_unslung = "libc6-unslung"
RDEPENDS_libc6-unslung = "nslu2-linksys-libs"
RPROVIDES_libc6-unslung = "libc6"
FILES_libc6-unslung = "/lib/librt*"

Figuring that perhaps the problem is that nothing actually "PROVIDES" libc6,
and that maybe bitbake needs to see the build-time dependency in order to
handle the run-time dependency PREFERRED_PROVIDER stuff, I even added
PROVIDES_libc6-unslung = "libc6"
to the glibc.bb recipe, and went back through the list of
PREFERRED_PROVIDERS in the local.conf file.  No luck.  No difference.

I finally hacked the glibc bitbake recipes so that glibc-initial doesn't
"RPROVIDE" libc6 anymore.  Success - bitbake is happy.  But I'm not.  That
doesn't seem like the correct way to resolve the multiple providers issue,
and I expect that commiting such a change would (rightfully) anger many
folks.

If some kind soul could point me to the document or another recipe that
provides the correct syntax for handling this, or provide a pointer to
whatever it is that I'm missing, I'd be most grateful.

Thanks!

Mike (mwester)







From eric.nelson at boundarydevices.com  Sun May 27 14:01:16 2007
From: eric.nelson at boundarydevices.com (Eric Nelson)
Date: Sun, 27 May 2007 07:01:16 -0700
Subject: [oe] preferred-xorg-versions-X11R7.1.inc broken?
Message-ID: <46598F2C.5010707@boundarydevices.com>

Trying to build gpe-image using distro/generic.conf, I'm
getting an error configuring xinerama.

 From the log file
    tmp/work/armv5te-linux/libxinerama-1_1.0.2-r0/temp/log.do_configure.9791

I'm seeing an error of:
    configure.ac:32: error: must install xorg-macros 1.1 or later
    configure.ac:32: the top level

It appears that preferred-xorg-versions-X11R7.1.inc doesn't
specify a xinerama version so it uses the newer one but does
specify a version of util-macros (1.0.2).




From openembedded at hrw.one.pl  Sun May 27 14:30:16 2007
From: openembedded at hrw.one.pl (Marcin Juszkiewicz)
Date: Sun, 27 May 2007 16:30:16 +0200
Subject: [oe] RFC: Rename MACHINE_TASK_PROVIDER to DEFAULT_TASK_PROVIDER
In-Reply-To: <4636F787.8030902@whitby.id.au>
References: <4636F787.8030902@whitby.id.au>
Message-ID: <200705271630.18199.openembedded@hrw.one.pl>

Dnia wtorek, 1 maja 2007, Rod Whitby napisa?:

> The proposal is to replace MACHINE_TASK_PROVIDER with
> DEFAULT_TASK_PROVIDER throughout OE, and encourage all image-foo.bb
> maintainers to base their image on DEFAULT_TASK_PROVIDER (which can be
> set to task-boot, or task-base, or perhaps some other distro-specific
> single task-foo value), plus other image-specific stuff.

DEFAULT_TASK_PROVIDER is good idea for me. I would like to merge it with 
my proposal change to task-base (adding wifi/bt for pcmcia/usbhost/pci 
devices) in a way that we will have:

- task-boot
- task-base
- task-base-extended (wifi/bt added for pcmcia/usbhost/pci machines)

This way we will be able to create images with wifi/bt support for PDA 
with pcmcia but no internal wifi/bt by using task-base-extended as 
DEFAULT_TASK_PROVIDER (set in distro config) and devices with smaller 
amount of space for rootfs will get task-base so users will be free to 
install extra stuff.

What do you think?

-- 
JID: hrw-jabber.org
OpenEmbedded developer/consultant

               Life's not fair. But the root password helps.





From openembedded at hrw.one.pl  Sun May 27 14:38:03 2007
From: openembedded at hrw.one.pl (Marcin Juszkiewicz)
Date: Sun, 27 May 2007 16:38:03 +0200
Subject: [oe] RFC: MACHINE_ namespace
Message-ID: <200705271638.03886.openembedded@hrw.one.pl>


During usage of progear device (now packed due to lack of space) I found 
a problems related to how we use machine configs and X11.

1. We have "alsa" as one of machine features but no way to control kernel 
modules for it - all are added into machine config as 
MACHINE_EXTRA_RRECOMMENDS. Same goes to other features.

2. Progear device use X.org instead of KDrive so I had to create own 
images for it because by default we do not have a way to tell which X 
drivers need to be present in images.


Proposed solution is adding MACHINE_ namespaces:

MACHINE_KERNEL_ALSA   = "kernel-module-snd-ali5451"
MACHINE_KERNEL_PCMCIA = "kernel-module-yenta-socket"

And other MACHINE_KERNEL_feature to control stuff used in task-base.

MACHINE_X11_SERVER  = "xserver-xorg"
MACHINE_X11_DRIVERS = "xf86-video-siliconmotion xf86-input-mutouch"

MACHINE_X11_SERVER will replace XSERVER used now, MACHINE_X11_DRIVERS will 
allow to add needed drivers to X11 images for device without creating 
custom ones.

What do you think about this proposal?

-- 
JID: hrw-jabber.org
OpenEmbedded developer/consultant

                 You can logoff, but you can never leave.
                 		-- Nina Liedtke, "CyberJoly Drim"





From koen at dominion.kabel.utwente.nl  Sun May 27 15:39:39 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Sun, 27 May 2007 17:39:39 +0200
Subject: [oe] RFC: MACHINE_ namespace
In-Reply-To: <200705271638.03886.openembedded@hrw.one.pl>
References: <200705271638.03886.openembedded@hrw.one.pl>
Message-ID: <4659A63B.9080901@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Marcin Juszkiewicz schreef:
> During usage of progear device (now packed due to lack of space) I found 
> a problems related to how we use machine configs and X11.
> 
> 1. We have "alsa" as one of machine features but no way to control kernel 
> modules for it - all are added into machine config as 
> MACHINE_EXTRA_RRECOMMENDS. Same goes to other features.
> 
> 2. Progear device use X.org instead of KDrive so I had to create own 
> images for it because by default we do not have a way to tell which X 
> drivers need to be present in images.
> 
> 
> Proposed solution is adding MACHINE_ namespaces:
> 
> MACHINE_KERNEL_ALSA   = "kernel-module-snd-ali5451"
> MACHINE_KERNEL_PCMCIA = "kernel-module-yenta-socket"
> 
> And other MACHINE_KERNEL_feature to control stuff used in task-base.
> 
> MACHINE_X11_SERVER  = "xserver-xorg"
> MACHINE_X11_DRIVERS = "xf86-video-siliconmotion xf86-input-mutouch"
> 
> MACHINE_X11_SERVER will replace XSERVER used now, MACHINE_X11_DRIVERS will 
> allow to add needed drivers to X11 images for device without creating 
> custom ones.
> 
> What do you think about this proposal?

Sounds pretty good, do you have a patch for it?

regards,

Koen


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGWaY7MkyGM64RGpERAo7vAJ9XGOvAsqKq4cLXv1nhCIH0JCts9ACfVAMr
gb542366W8K6bgr2tOxroV8=
=iSVA
-----END PGP SIGNATURE-----



From pmiscml at gmail.com  Sun May 27 19:28:20 2007
From: pmiscml at gmail.com (Paul Sokolovsky)
Date: Sun, 27 May 2007 22:28:20 +0300
Subject: [oe] RFC: MACHINE_ namespace
In-Reply-To: <200705271638.03886.openembedded@hrw.one.pl>
References: <200705271638.03886.openembedded@hrw.one.pl>
Message-ID: <277782266.20070527222820@gmail.com>

Hello Marcin,

Sunday, May 27, 2007, 5:38:03 PM, you wrote:

> During usage of progear device (now packed due to lack of space) I found
> a problems related to how we use machine configs and X11.

> 1. We have "alsa" as one of machine features but no way to control kernel
> modules for it - all are added into machine config as 
> MACHINE_EXTRA_RRECOMMENDS. Same goes to other features.

> 2. Progear device use X.org instead of KDrive so I had to create own 
> images for it because by default we do not have a way to tell which X 
> drivers need to be present in images.


> Proposed solution is adding MACHINE_ namespaces:

> MACHINE_KERNEL_ALSA   = "kernel-module-snd-ali5451"
> MACHINE_KERNEL_PCMCIA = "kernel-module-yenta-socket"

        This sounds good, especially if we anticipate from the start
that there may be several modules there. And generally, we need to add
more modules into task-base subtasks, targetting at aim when machine
configs will truly contain only machine-specific bits (like hardware
drivers), while other modules will be in task-base.

[]

-- 
Best regards,
 Paul                            mailto:pmiscml at gmail.com




From rod at whitby.id.au  Sun May 27 22:46:38 2007
From: rod at whitby.id.au (Rod Whitby)
Date: Mon, 28 May 2007 08:16:38 +0930
Subject: [oe] RFC: Rename MACHINE_TASK_PROVIDER to DEFAULT_TASK_PROVIDER
In-Reply-To: <200705271630.18199.openembedded@hrw.one.pl>
References: <4636F787.8030902@whitby.id.au>
	<200705271630.18199.openembedded@hrw.one.pl>
Message-ID: <465A0A4E.7060807@whitby.id.au>

Marcin Juszkiewicz wrote:
> Dnia wtorek, 1 maja 2007, Rod Whitby napisa?:
> 
>> The proposal is to replace MACHINE_TASK_PROVIDER with
>> DEFAULT_TASK_PROVIDER throughout OE, and encourage all image-foo.bb
>> maintainers to base their image on DEFAULT_TASK_PROVIDER (which can be
>> set to task-boot, or task-base, or perhaps some other distro-specific
>> single task-foo value), plus other image-specific stuff.
> 
> DEFAULT_TASK_PROVIDER is good idea for me. I would like to merge it with 
> my proposal change to task-base (adding wifi/bt for pcmcia/usbhost/pci 
> devices) in a way that we will have:
> 
> - task-boot
> - task-base
> - task-base-extended (wifi/bt added for pcmcia/usbhost/pci machines)
> 
> This way we will be able to create images with wifi/bt support for PDA 
> with pcmcia but no internal wifi/bt by using task-base-extended as 
> DEFAULT_TASK_PROVIDER (set in distro config) and devices with smaller 
> amount of space for rootfs will get task-base so users will be free to 
> install extra stuff.
> 
> What do you think?

+1 from me.

Can you add:

PROVIDES = "${PACKAGES}"

to task-base.bb while you are there?  I know it should not be required
(it should happen automatically), but for some reason the automatic
stuff is not working for this file at the moment.  I cannot build an
image based on task-boot instead of task-base without doing the above.

-- Rod



From zecke at selfish.org  Mon May 28 09:33:10 2007
From: zecke at selfish.org (Holger Freyther)
Date: Mon, 28 May 2007 11:33:10 +0200
Subject: [oe] RPATH hacks
Message-ID: <A16C87CA-5E9D-4B3B-B237-3BD3890A7D28@selfish.org>

Hey,

I have just pushed a change to libtool-cross that will disable -rpath  
for all cross compiled packages. This should fix all issues with  
rpath on libtool based packages.

What can break?
	I can imagine if you have a binary you can not statically link,  
can't write a /etc/ld.so.conf and can't set LD_LIBRARY_PATH you might  
have troubles now. In that case please speak up and we can look at a  
solution.

I have not tested the resulting image, so if you end up with  
unbootable images feel free to tear and feather me (I like it).


z.




From koen at dominion.kabel.utwente.nl  Mon May 28 09:39:27 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Mon, 28 May 2007 11:39:27 +0200
Subject: [oe] RPATH hacks
In-Reply-To: <A16C87CA-5E9D-4B3B-B237-3BD3890A7D28@selfish.org>
References: <A16C87CA-5E9D-4B3B-B237-3BD3890A7D28@selfish.org>
Message-ID: <465AA34F.3090905@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Holger Freyther schreef:
> Hey,
> 
> I have just pushed a change to libtool-cross that will disable -rpath  
> for all cross compiled packages. This should fix all issues with  
> rpath on libtool based packages.

yay!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGWqNPMkyGM64RGpERAqaYAJ9cBjpMndY31KXOag3OZvlxRk1BzwCgsTx8
piu2PynRbFMnvIe1mO1yAdo=
=OhBm
-----END PGP SIGNATURE-----



From zecke at selfish.org  Mon May 28 10:21:32 2007
From: zecke at selfish.org (Holger Freyther)
Date: Mon, 28 May 2007 12:21:32 +0200
Subject: [oe] RPATH hacks
In-Reply-To: <A16C87CA-5E9D-4B3B-B237-3BD3890A7D28@selfish.org>
References: <A16C87CA-5E9D-4B3B-B237-3BD3890A7D28@selfish.org>
Message-ID: <476F8CF7-CE6C-4461-A336-15D6E43AF9B9@selfish.org>


Am 28.05.2007 um 11:33 schrieb Holger Freyther:

> I have not tested the resulting image, so if you end up with
> unbootable images feel free to tear and feather me (I like it).

Some people might find tearing to painful and wonder how the feathers  
will stay attached to my body, in this case feel free to tear, tar  
and feather me (or skip the tearing...)

z.

PS: Thank you native speakers...



From papercrane at gmail.com  Mon May 28 20:17:13 2007
From: papercrane at gmail.com (Justin Patrin)
Date: Mon, 28 May 2007 13:17:13 -0700
Subject: [oe] PREFERRED_PROVIDER syntax is eluding me...
In-Reply-To: <038201c79f6a$f9859720$6e01a8c0@twilight>
References: <038201c79f6a$f9859720$6e01a8c0@twilight>
Message-ID: <432beae0705281317t3464bacfr833d7ed6b28f374@mail.gmail.com>

On 5/26/07, Mike (mwester) <mwester at dls.net> wrote:
> I'm missing something simple, I expect.  But try as I might, I cannot figure
> this out.
>
> Bitbake 1.8.3, building unslung-image (worked fine on 1.6): Bitbake says:
> [snip]
> NOTE: multiple providers are available for runtime libc6-unslung (glibc,
> glibc-initial);
> NOTE: consider defining a PREFERRED_PROVIDER entry to match runtime
> libc6-unslung
> [snip]
>
> This is a problem, because with bitbake 1.8, without a preferred provider
> specified, it seems to try to build both.  But only glibc builds;
> glibc-initial fails (and the build loops forever).   This is easily fixed by
> adding the following line to the local.conf file:
>
> PREFERRED_PROVIDER_libc6-unslung = "glibc"
>
> Except that it doesn't do a blasted thing.  Neither does this line:
>
> PREFERRED_PROVIDERS += " libc6-unslung:glibc"
>
> Thinking that perhaps the "-unslung" was implied since the machine is
> "unslung", I tried:
>
> PREFERRED_PROVIDERS += " libc6:glibc"
>
> Still no change.  Being persistent, I tried every variant of the above that
> I could think of, to no avail.  It seems that bitbake is not understanding
> or processing the info provided.  The -D flag offers no further hints,
> either.
>
> For background, back in the glibc bitbake recipes, glibc-initial.bb does a
> "require" of glibc.bb (hence the multiple providers).  Near the tail-end of
> glibc.bb we find:
>
> PACKAGES_unslung = "libc6-unslung"
> RDEPENDS_libc6-unslung = "nslu2-linksys-libs"
> RPROVIDES_libc6-unslung = "libc6"
> FILES_libc6-unslung = "/lib/librt*"
>
> Figuring that perhaps the problem is that nothing actually "PROVIDES" libc6,
> and that maybe bitbake needs to see the build-time dependency in order to
> handle the run-time dependency PREFERRED_PROVIDER stuff, I even added
> PROVIDES_libc6-unslung = "libc6"
> to the glibc.bb recipe, and went back through the list of
> PREFERRED_PROVIDERS in the local.conf file.  No luck.  No difference.
>
> I finally hacked the glibc bitbake recipes so that glibc-initial doesn't
> "RPROVIDE" libc6 anymore.  Success - bitbake is happy.  But I'm not.  That
> doesn't seem like the correct way to resolve the multiple providers issue,
> and I expect that commiting such a change would (rightfully) anger many
> folks.
>
> If some kind soul could point me to the document or another recipe that
> provides the correct syntax for handling this, or provide a pointer to
> whatever it is that I'm missing, I'd be most grateful.
>

So it's RPROVIDES and not PROVIDES? Sounds like the problem may be
that PREFERRED_PROVIDERS is for non-R.... Is there an
RPREFERRED_PROVIDERS perhaps?

It's been a while since you posted, sid you get this resolved in the
meantime? Richard Purdie should have more insight into this.

-- 
Justin Patrin



From rpurdie at rpsys.net  Tue May 29 20:46:32 2007
From: rpurdie at rpsys.net (Richard Purdie)
Date: Tue, 29 May 2007 21:46:32 +0100
Subject: [oe] PREFERRED_PROVIDER syntax is eluding me...
In-Reply-To: <432beae0705281317t3464bacfr833d7ed6b28f374@mail.gmail.com>
References: <038201c79f6a$f9859720$6e01a8c0@twilight>
	<432beae0705281317t3464bacfr833d7ed6b28f374@mail.gmail.com>
Message-ID: <1180471592.5822.81.camel@localhost.localdomain>

On Mon, 2007-05-28 at 13:17 -0700, Justin Patrin wrote:
> On 5/26/07, Mike (mwester) <mwester at dls.net> wrote:
> > I'm missing something simple, I expect.  But try as I might, I cannot figure
> > this out.
> >
> > Bitbake 1.8.3, building unslung-image (worked fine on 1.6): Bitbake says:
> > [snip]
> > NOTE: multiple providers are available for runtime libc6-unslung (glibc,
> > glibc-initial);
> > NOTE: consider defining a PREFERRED_PROVIDER entry to match runtime
> > libc6-unslung
> > [snip]
> >
> > This is a problem, because with bitbake 1.8, without a preferred provider
> > specified, it seems to try to build both.  But only glibc builds;
> > glibc-initial fails (and the build loops forever).   This is easily fixed by
> > adding the following line to the local.conf file:
> >
> > PREFERRED_PROVIDER_libc6-unslung = "glibc"
> >
> > Except that it doesn't do a blasted thing.  Neither does this line:
> >
> > PREFERRED_PROVIDERS += " libc6-unslung:glibc"
> >
> > Thinking that perhaps the "-unslung" was implied since the machine is
> > "unslung", I tried:
> >
> > PREFERRED_PROVIDERS += " libc6:glibc"
> >
> > Still no change.  Being persistent, I tried every variant of the above that
> > I could think of, to no avail.  It seems that bitbake is not understanding
> > or processing the info provided.  The -D flag offers no further hints,
> > either.
> >
> > For background, back in the glibc bitbake recipes, glibc-initial.bb does a
> > "require" of glibc.bb (hence the multiple providers).  Near the tail-end of
> > glibc.bb we find:
> >
> > PACKAGES_unslung = "libc6-unslung"
> > RDEPENDS_libc6-unslung = "nslu2-linksys-libs"
> > RPROVIDES_libc6-unslung = "libc6"
> > FILES_libc6-unslung = "/lib/librt*"
> >
> > Figuring that perhaps the problem is that nothing actually "PROVIDES" libc6,
> > and that maybe bitbake needs to see the build-time dependency in order to
> > handle the run-time dependency PREFERRED_PROVIDER stuff, I even added
> > PROVIDES_libc6-unslung = "libc6"
> > to the glibc.bb recipe, and went back through the list of
> > PREFERRED_PROVIDERS in the local.conf file.  No luck.  No difference.
> >
> > I finally hacked the glibc bitbake recipes so that glibc-initial doesn't
> > "RPROVIDE" libc6 anymore.  Success - bitbake is happy.  But I'm not.  That
> > doesn't seem like the correct way to resolve the multiple providers issue,
> > and I expect that commiting such a change would (rightfully) anger many
> > folks.
> >
> > If some kind soul could point me to the document or another recipe that
> > provides the correct syntax for handling this, or provide a pointer to
> > whatever it is that I'm missing, I'd be most grateful.
> >
> 
> So it's RPROVIDES and not PROVIDES? Sounds like the problem may be
> that PREFERRED_PROVIDERS is for non-R.... Is there an
> RPREFERRED_PROVIDERS perhaps?
> 
> It's been a while since you posted, sid you get this resolved in the
> meantime? Richard Purdie should have more insight into this.

Er, hmm, right. The providers code is still a bit of a mystery to me
too ;-)

What you didn't say is that you did:

PROVIDES_unslung = "virtual/libc virtual/${TARGET_PREFIX}libc-for-gcc libc6-unslung"

so this file no longer provides glibc and therefore anything involving
glibc won't help. At a guess I'd try something like:

PREFERRED_PROVIDER_libc6-unslung = "libc6-unslung"

Of course I have to ask why you're doing this at all? It looks a bit
hatstand and I wonder why PREFERRED_VERSION_glibc = "2.2.5" wasn't
enough? ;-) (not that it shouldn't work)

Cheers,

Richard





From mwester at dls.net  Wed May 30 03:27:41 2007
From: mwester at dls.net (Mike (mwester))
Date: Tue, 29 May 2007 22:27:41 -0500
Subject: [oe] PREFERRED_PROVIDER syntax is eluding me...
References: <038201c79f6a$f9859720$6e01a8c0@twilight>
	<432beae0705281317t3464bacfr833d7ed6b28f374@mail.gmail.com>
	<1180471592.5822.81.camel@localhost.localdomain>
Message-ID: <054801c7a26a$7aec5450$6e01a8c0@twilight>

First, sorry for the late reply.

Richard Purdie writes:
> What you didn't say is that you did:
>
> PROVIDES_unslung = "virtual/libc virtual/${TARGET_PREFIX}libc-for-gcc
libc6-unslung"

Yes, I committed that change/fix over the weekend (see below).  Previously
it read just:
PROVIDES_unslung = "virtual/libc virtual/${TARGET_PREFIX}libc-for-gcc"
(without the final "libc6-unslung" on it).

> so this file no longer provides glibc and therefore anything involving
> glibc won't help. At a guess I'd try something like:
>
> PREFERRED_PROVIDER_libc6-unslung = "libc6-unslung"

I actually used:
PREFERRED_PROVIDER_libc6-unslung = "glibc"
My logic was that there were multiple providers for libc6-unslung (glibc's
bb file and glibc-initial's bb file), and that the value the variable was
set to referred to the bitbake recipe that should be preferred for building
of the object named "libc6-unslung".

I tested with so many combinations that my eyes crossed.  I don't recall if
that combination (the change to PROVIDES_unslung above was ever tested with
PREFERRED_PROVIDER_libc6-unslung="libc6-unslung", or not.  I can test that
if that's a more correct solution.

> Of course I have to ask why you're doing this at all? It looks a bit
> hatstand and I wonder why PREFERRED_VERSION_glibc = "2.2.5" wasn't
> enough? ;-) (not that it shouldn't work)

Hatstand, huh?  :-)  I haven't heard that expression, but I think I get it
:-).  I committed the fix I discovered, not because it was necesarily The
Right Fix(tm), but because it worked and the changes were guaranteed to be
localized to Unslung (i.e. I wouldn't risk messing up anyone else's distro's
with the fix I selected).

As for why it's this way, I can't say.  Unslung is itself a strange
creation - and its been in OE for a long time.  Together that seems to
result in some strange constructs.  I'm striving to keep it building in OE,
in the hopes that there might be a compelling feature or event that would
make a new Unslung release interesting at some point in the future.
However, the likelihood of such an event currently appears to be slim enough
that I'm not sure it's a good idea to do significant rework and retesting on
it, frankly.  So I'm in favor of a small simple fix, even a kludgy one, if
it'll work.

> Cheers,
>
> Richard

Thanks!  If you or anyone else has strong feelings about this, and how it's
been addressed, let me know (preferably with some guidance on what would be
acceptable).

Regards,
Mike (mwester)





From rodrigo.vivi at gmail.com  Wed May 30 22:42:53 2007
From: rodrigo.vivi at gmail.com (Rodrigo Vivi)
Date: Wed, 30 May 2007 19:42:53 -0300
Subject: [oe] strange error: missing depends...
Message-ID: <bdb0025f0705301542s7e64e43cjb5b737e7f1958806@mail.gmail.com>

Hi there,

Some days ago I was using the bitbake1.6 to build my packages and it
was working fine, but someday without any apparently reason it stopped
to work.

Then, after a big looser fight I've decided to change to bitbake1.8
and the problem was apparently solved... I was seeing the packages
being build...
But in the end, for my surprise, I've noticed that a lot of depends
wasn't build!

Since my task file is not under official repository yet I'm sending in
this email.

Does any body have any idea?

Thanks,
vivijim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: task-mamona.bb
Type: application/octet-stream
Size: 1216 bytes
Desc: not available
URL: <http://lists.openembedded.org/pipermail/openembedded-devel/attachments/20070530/f80ae2f5/attachment-0001.obj>

From freyther at gmx.net  Thu May 31 09:22:10 2007
From: freyther at gmx.net (Holger Freyther)
Date: Thu, 31 May 2007 11:22:10 +0200
Subject: [oe] strange error: missing depends...
In-Reply-To: <bdb0025f0705301542s7e64e43cjb5b737e7f1958806@mail.gmail.com>
References: <bdb0025f0705301542s7e64e43cjb5b737e7f1958806@mail.gmail.com>
Message-ID: <3A8255A2-0573-4DE5-AF68-B87A30062F3F@gmx.net>


Am 31.05.2007 um 00:42 schrieb Rodrigo Vivi:

> Hi there,
>
> Some days ago I was using the bitbake1.6 to build my packages and it
> was working fine, but someday without any apparently reason it stopped
> to work.
>
> Does any body have any idea?


Hi,

koen says that the recipe looks "OK" to him. He finds that  
'RDEPENDS_task-mamona-all := "${PACKAGES}"' a bit suspicious.

What version of BitBake do you have, is the graph generated by task- 
mamona (-g option of BitBake) having the DEPENDS/RDEPENDS? What is  
bitbake -vvv saying what it tries to build, do the depends show up at  
all?


kind regards
	z.



From rodrigo.vivi at gmail.com  Thu May 31 20:49:22 2007
From: rodrigo.vivi at gmail.com (Rodrigo Vivi)
Date: Thu, 31 May 2007 17:49:22 -0300
Subject: [oe] strange error: missing depends...
In-Reply-To: <3A8255A2-0573-4DE5-AF68-B87A30062F3F@gmx.net>
References: <bdb0025f0705301542s7e64e43cjb5b737e7f1958806@mail.gmail.com>
	<3A8255A2-0573-4DE5-AF68-B87A30062F3F@gmx.net>
Message-ID: <bdb0025f0705311349x73f2f285ge65c3aaa06a4fa21@mail.gmail.com>

I've just noticed that everything is fine with depends, rdepends and
with the task-mamona itself.

My log shows that do_compile and do_package was called for every
package, but for some reason a few of them like bash do not call the
do_package_deb function..

In the log I have this:
NOTE: package bash-3.2-r1: task do_package: started
NOTE: package bash-3.2-r1: task do_package: completed

But I've introduced some debug messages and I'm pretty sure that the
do_package_deb function was not called to this package.

but I can not figure it out...
Why it is called for some packages and not called for other ones.

Does any body has an idea about it?

Thanks,
vivijim

On 5/31/07, Holger Freyther <freyther at gmx.net> wrote:
>
> Am 31.05.2007 um 00:42 schrieb Rodrigo Vivi:
>
> > Hi there,
> >
> > Some days ago I was using the bitbake1.6 to build my packages and it
> > was working fine, but someday without any apparently reason it stopped
> > to work.
> >
> > Does any body have any idea?
>
>
> Hi,
>
> koen says that the recipe looks "OK" to him. He finds that
> 'RDEPENDS_task-mamona-all := "${PACKAGES}"' a bit suspicious.
>
> What version of BitBake do you have, is the graph generated by task-
> mamona (-g option of BitBake) having the DEPENDS/RDEPENDS? What is
> bitbake -vvv saying what it tries to build, do the depends show up at
> all?
>
>
> kind regards
>         z.
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>



From koen at dominion.kabel.utwente.nl  Thu May 31 21:22:19 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Thu, 31 May 2007 23:22:19 +0200
Subject: [oe] Glibc 2.6 added, please test
Message-ID: <465F3C8B.80200@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Glibc 2.6 has just been added to OE, please test it and report bugs.

TIA,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGXzyLMkyGM64RGpERAk8EAJ9vszt8ghLdUoVvRLarLWNM40TpUgCfToVG
QCCW9dQifUQvV8H8H+5VVR0=
=9U8f
-----END PGP SIGNATURE-----



From repvik at kynisk.com  Tue May  1 01:49:14 2007
From: repvik at kynisk.com (=?utf-8?q?=C3=98yvind_Repvik?=)
Date: Tue, 1 May 2007 03:49:14 +0200
Subject: [oe] [oe-commits] MedHelp 28949335
In-Reply-To: <20070430-35259.9357.qmail@bridges>
References: <20070430-35259.9357.qmail@bridges>
Message-ID: <200705010349.14949.repvik@kynisk.com>

On Tuesday 01 May 2007 01:02:18 Canadian Doctor Addie wrote:
> <STYLE>
> /back/CMA/Tournament/Sherrill/Laura/supporting/xxx/1520/blackberry/live/12/
>treatment/Tam/receipt/Unfortunately/wa
>
[lots of crap]

Why isn't there any filtering on oe-commits? Isn't that list commits-only? 
I see my spamfilter kills most of them, but a few still comes through.
Why not just block all non-commit mails?

Regards,
?yvind Repvik



From papercrane at gmail.com  Tue May  1 02:51:24 2007
From: papercrane at gmail.com (Justin Patrin)
Date: Mon, 30 Apr 2007 19:51:24 -0700
Subject: [oe] [oe-commits] MedHelp 28949335
In-Reply-To: <200705010349.14949.repvik@kynisk.com>
References: <20070430-35259.9357.qmail@bridges>
	<200705010349.14949.repvik@kynisk.com>
Message-ID: <432beae0704301951v2cd237f7w8e0300f5681a65b9@mail.gmail.com>

On 4/30/07, ?yvind Repvik <repvik at kynisk.com> wrote:
> On Tuesday 01 May 2007 01:02:18 Canadian Doctor Addie wrote:
> > <STYLE>
> > /back/CMA/Tournament/Sherrill/Laura/supporting/xxx/1520/blackberry/live/12/
> >treatment/Tam/receipt/Unfortunately/wa
> >
> [lots of crap]
>
> Why isn't there any filtering on oe-commits? Isn't that list commits-only?
> I see my spamfilter kills most of them, but a few still comes through.
> Why not just block all non-commit mails?
>

Sounds good to me.

-- 
Justin Patrin



From xjqian at gmail.com  Tue May  1 05:14:40 2007
From: xjqian at gmail.com (Junqian Gordon Xu)
Date: Tue, 01 May 2007 00:14:40 -0500
Subject: [oe] perl 5.8.8 is ready
In-Reply-To: <20070430080044.GA15877@twibble.org>
References: <20070427105722.GA4340@twibble.org> <46359408.9060800@gmail.com>
	<20070430080044.GA15877@twibble.org>
Message-ID: <4636CCC0.1010109@gmail.com>

Thanks. I fixed the hostperl problem.

Don't know why. Even I commented out the DEFAULT_PREFERENCE = "-1", 
bitbake still try to get perl-5.8.7 compiled first

NOTE: package perl-5.8.8-r8: task do_unpack: completed
NOTE: package perl-5.8.8: completed
NOTE: Running task 285 of 302 (ID: 130, 
/home/OE/org.openembedded.dev/packages/perl/perl_5.8.7.bb, do_fetch)
NOTE: package perl-5.8.7: started
NOTE: package perl-5.8.7-r22: task do_fetch: started

Besides, I noticed another issue:
I had linux-libc-headers-2.6.15.99 compiled (I think it's determined 
Machine and Distro) . But perl-5.8.8 wants linux-libc-headers-2.6.20. 
Will that cause problem?

Thanks
Gordon


Jamie Lenehan wrote:
> On Mon, Apr 30, 2007 at 02:00:24AM -0500, Junqian Gordon Xu wrote:
>   
>> Jamie Lenehan wrote:
>>     
> [...]
>   
>> perl-native-5.8.8 builds fine but with the following error
>>
>> ERROR: QA issue: libgettextsrc.la failed sanity test (reference to 
>> workdir or installed)
>>     
> [...]
>
> These ones aren't related to perl-native at all, so no problems there.
>
> [...]
>   
>> perl-5.8.8 build failed. Detail in the attached log file.
>>     
> [...]
>   
>> | hostperl -I/home/OE/build/tosa_angstrom/tmp/work/armv5te-angstrom-linux-gnueabi/perl-5.8.8-r7/perl-5.8.8/Cross/../fake_config_library -MConfig ../../lib/ExtUtils/xsubpp -noprototypes -typemap ../../lib/ExtUtils/typemap  attrs.xs > attrs.xsc && mv attrs.xsc attrs.c
>> | Perl lib version (v5.8.8) doesn't match executable version (v5.8.7) at /home/OE/build/tosa_angstrom/tmp/work/armv5te-angstrom-linux-gnueabi/perl-5.8.8-r7/perl-5.8.8/Cross/../fake_config_library/Config.pm line 46.
>>     
>
> This error is saying that "hostperl" is perl 5.8.7 but that it needs
> to be perl 5.8.8. Can you check what your hostperl, which would be:
>
>   /home/OE/build/tosa_angstrom/tmp/staging/i686-linux/bin/hostperl
>
> is pointing at? It should be 5.8.8 but this error makes it sound like
> it's pointing at 5.8.7:
>
>   %~> ls -l tmp/staging/x86_64-linux/bin/hostperl 
>   lrwxrwxrwx 1 lenehan lenehan 82 2007-04-30 13:28 tmp/staging/x86_64-linux/bin/hostperl -> /home/lenehan/devel/oe/build/titan-glibc-25/tmp/staging/x86_64-linux/bin/perl5.8.8*
>
> Thanks.
>
>   




From rod at whitby.id.au  Tue May  1 08:17:11 2007
From: rod at whitby.id.au (Rod Whitby)
Date: Tue, 01 May 2007 17:47:11 +0930
Subject: [oe] RFC: Rename MACHINE_TASK_PROVIDER to DEFAULT_TASK_PROVIDER
Message-ID: <4636F787.8030902@whitby.id.au>

> <rwhitby> so in my mokoslug distro, I set MACHINE_TASK_PROVIDER to task-boot or task-base, depending on flash size.
> <rwhitby> what is MACHINE_TASK_PROVIDER really meant to be used for?
> <koen> to distinguish between task-bootstrap and task-base
> <rwhitby> does task-bootstrap still exist?
> <koen> rwhitby: I hope not
> <rwhitby> koen: so MACHINE_TASK_PROVIDER has no current reason for existence then?
> <rwhitby> (and no definition of what it should be used for if it did have a current reason for existence)
> <koen> rwhitby: not that I know off, but your task-boot suggestion would make sense
> <rwhitby> koen: So it really should now be called something like BOOTSTRAP_IMAGE_FOUNDATION_TASK or something?
> <rwhitby> (since it doesn't have anything to do with MACHINEs)
> <koen> nor with BOOTSTRAP
> <koen> something like DEFAULT_TASK_PROVIDER?
> <rwhitby> yep, DEFAULT_TASK_PROVIDER floats my boat.
> <koen> do you want to write an RFC for that?

The proposal is to replace MACHINE_TASK_PROVIDER with
DEFAULT_TASK_PROVIDER throughout OE, and encourage all image-foo.bb
maintainers to base their image on DEFAULT_TASK_PROVIDER (which can be
set to task-boot, or task-base, or perhaps some other distro-specific
single task-foo value), plus other image-specific stuff.

Comments?  Objections?

BTW, task-bootstrap existence is as follows:

> ./conf/distro/generic.conf:PREFERRED_PROVIDER_task-bootstrap = "task-bootstrap"
> ./conf/distro/include/oplinux.inc:PREFERRED_PROVIDER_task-bootstrap = "task-base"
> ./conf/distro/angstrom-2007.1.conf:PREFERRED_PROVIDER_task-bootstrap = "task-bootstrap"
> ./conf/distro/jlime-donkey.conf:PREFERRED_PROVIDER_task-bootstrap = "task-bootstrap"
> ./conf/distro/openprotium.conf:#PREFERRED_PROVIDER_task-bootstrap = "task-bootstrap"
> ./conf/machine/gumstix.conf:PREFERRED_VERSION_task-bootstrap = "1.0unionroot"
> ./packages/obsolete/tasks/task-bootstrap-unionroot.bb:PROVIDES = "task-bootstrap"
> ./packages/obsolete/tasks/task-bootstrap-unionroot.bb:RPROVIDES = "task-bootstrap"
> ./packages/obsolete/tasks/task-bootstrap-unionroot.bb:require task-bootstrap.inc
> ./packages/obsolete/tasks/task-bootstrap.bb:require task-bootstrap.inc
> ./packages/images/jlime-opie.bb:DEPENDS = "task-bootstrap task-opie"
> ./packages/images/jlime-opie.bb:INSTALL_PACKAGES = "task-bootstrap task-opie-base task-opie-base-applets \
> ./removal.txt:Package Name:   task-bootstrap*

-- Rod



From no2spam at nospam.arcornews.de  Tue May  1 18:04:10 2007
From: no2spam at nospam.arcornews.de (Rolf Leggewie)
Date: Tue, 01 May 2007 20:04:10 +0200
Subject: [oe] RFC: RW access for polyonymous
Message-ID: <f17ves$luc$1@sea.gmane.org>

Hi,

with the amount (and speed!) of patches being provided by Michael 
'polyonymous' Krelin I think it makes sense to give him RW access to OE. 
  His bugs are at http://tinyurl.com/2llfhw

Take a look, comment and decide.

Regards

Rolf




From papercrane at gmail.com  Tue May  1 18:13:20 2007
From: papercrane at gmail.com (Justin Patrin)
Date: Tue, 1 May 2007 11:13:20 -0700
Subject: [oe] [oe-commits] org.oe.dev xtscal: attempt to fix
	miscalibrations
In-Reply-To: <46362F71.7080604@dominion.kabel.utwente.nl>
References: <E1HgoSJ-0008AG-St@linuxtogo.org>
	<462FBE16.9070805@dominion.kabel.utwente.nl>
	<46362F71.7080604@dominion.kabel.utwente.nl>
Message-ID: <432beae0705011113v61831859x7978062963a48b8@mail.gmail.com>

On 4/30/07, Koen Kooi <koen at dominion.kabel.utwente.nl> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Koen Kooi schreef:
> > koen commit schreef:
> >> xtscal: attempt to fix miscalibrations
> >
> > Could people with one of:
> > "HP IPAQ H3600" | "HP IPAQ H3700" | "HP IPAQ H3900" | "HTC Universal" | *COLLIE | *POODLE
> > | *SPITZ | *AKITA | *BORZOI
> >
> > check if calibration isn't 90 degrees of anymore?
> >
> > If not, we most likely need to revert revision d18552e5056a026d8ed8959e135b2fa05c3e1b6b
>
> Hello?

I was just about to test this when my boot into a new image failed
with a missing libgcc. This RPATH issue needs to be fixed ASAP.

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (Darwin)
>
> iD8DBQFGNi9xMkyGM64RGpERAnbdAJ0WirRd/ONKWpIDHDQcO+6EddMx6gCgmoiw
> bF5efxVbVYf2tUEhwMiCMHc=
> =j3Su
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>


-- 
Justin Patrin



From papercrane at gmail.com  Tue May  1 18:13:20 2007
From: papercrane at gmail.com (Justin Patrin)
Date: Tue, 1 May 2007 11:13:20 -0700
Subject: [oe] [oe-commits] org.oe.dev xtscal: attempt to fix
	miscalibrations
In-Reply-To: <46362F71.7080604@dominion.kabel.utwente.nl>
References: <E1HgoSJ-0008AG-St@linuxtogo.org>
	<462FBE16.9070805@dominion.kabel.utwente.nl>
	<46362F71.7080604@dominion.kabel.utwente.nl>
Message-ID: <432beae0705011113v61831859x7978062963a48b8@mail.gmail.com>

On 4/30/07, Koen Kooi <koen at dominion.kabel.utwente.nl> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Koen Kooi schreef:
> > koen commit schreef:
> >> xtscal: attempt to fix miscalibrations
> >
> > Could people with one of:
> > "HP IPAQ H3600" | "HP IPAQ H3700" | "HP IPAQ H3900" | "HTC Universal" | *COLLIE | *POODLE
> > | *SPITZ | *AKITA | *BORZOI
> >
> > check if calibration isn't 90 degrees of anymore?
> >
> > If not, we most likely need to revert revision d18552e5056a026d8ed8959e135b2fa05c3e1b6b
>
> Hello?

I was just about to test this when my boot into a new image failed
with a missing libgcc. This RPATH issue needs to be fixed ASAP.

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (Darwin)
>
> iD8DBQFGNi9xMkyGM64RGpERAnbdAJ0WirRd/ONKWpIDHDQcO+6EddMx6gCgmoiw
> bF5efxVbVYf2tUEhwMiCMHc=
> =j3Su
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>


-- 
Justin Patrin



From oe at hentges.net  Tue May  1 18:20:26 2007
From: oe at hentges.net (Matthias Hentges)
Date: Tue, 01 May 2007 20:20:26 +0200
Subject: [oe] RFC: RW access for polyonymous
In-Reply-To: <f17ves$luc$1@sea.gmane.org>
References: <f17ves$luc$1@sea.gmane.org>
Message-ID: <1178043626.23506.8.camel@localhost.localdomain>

Am Dienstag, den 01.05.2007, 20:04 +0200 schrieb Rolf Leggewie:
> Hi,
> 
> with the amount (and speed!) of patches being provided by Michael 
> 'polyonymous' Krelin I think it makes sense to give him RW access to OE. 
>   His bugs are at http://tinyurl.com/2llfhw

I agree, it's about time ;)
-- 
Matthias 'CoreDump' Hentges 
Cologne / Germany

Webmaster of Hentges.net & Embedded Linux Developer
GPG ->  gpg --keyserver gpg-keyserver.de --recv-keys 0xAF3030D9

My OS: Debian SID: Geek by Nature, Linux by Choice


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
URL: <http://lists.openembedded.org/pipermail/openembedded-devel/attachments/20070501/be3360eb/attachment-0002.sig>

From skoroneos at digital-opsis.com  Tue May  1 18:32:01 2007
From: skoroneos at digital-opsis.com (Stelios Koroneos)
Date: Tue, 1 May 2007 21:32:01 +0300
Subject: [oe] squasfs jffs2 default image settings
In-Reply-To: <4636F787.8030902@whitby.id.au>
Message-ID: <HOECLKEKOHLAMMGDLLBHKEFLKOAA.skoroneos@digital-opsis.com>

After a day of "head scratching" i realized the the reason an image i was
building, failed to load on a powerpc target was that the default settings
for squashfs squashfs-lzma and jffs2 were set to little endian architecture

//snip from  bitbake.conf

EXTRA_IMAGECMD_jffs2 = "--pad --little-endian --eraseblock=0x40000"
EXTRA_IMAGECMD_squashfs = "-le -b 16384"
EXTRA_IMAGECMD_squashfs-lzma = "-le -b 16384"

These look like they were set for a specific machine (maybe i am wrong), but
shouldn't the default settings be at least architecture neutral ?
(Even the block sizes shouldn't be defined there as a machine might be
better suited by another size)

Any objections to have EXTRA_IMAGECMD for these types of images default to
no specific settings  ?

Stelios S. Koroneos

Digital OPSiS - Embedded Inteligence
http://www.digital-opsis.com


> -----Original Message-----
> From: openembedded-devel-bounces at openembedded.org
> [mailto:openembedded-devel-bounces at openembedded.org]On Behalf Of
> Rod Whitby
> Sent: Tuesday, May 01, 2007 11:17 AM
> To: openembedded-devel at openembedded.org
> Subject: [oe] RFC: Rename MACHINE_TASK_PROVIDER to DEFAULT_TASK_PROVIDER
>
>
> > <rwhitby> so in my mokoslug distro, I set MACHINE_TASK_PROVIDER
> to task-boot or task-base, depending on flash size.
> > <rwhitby> what is MACHINE_TASK_PROVIDER really meant to be used for?
> > <koen> to distinguish between task-bootstrap and task-base
> > <rwhitby> does task-bootstrap still exist?
> > <koen> rwhitby: I hope not
> > <rwhitby> koen: so MACHINE_TASK_PROVIDER has no current reason
> for existence then?
> > <rwhitby> (and no definition of what it should be used for if
> it did have a current reason for existence)
> > <koen> rwhitby: not that I know off, but your task-boot
> suggestion would make sense
> > <rwhitby> koen: So it really should now be called something
> like BOOTSTRAP_IMAGE_FOUNDATION_TASK or something?
> > <rwhitby> (since it doesn't have anything to do with MACHINEs)
> > <koen> nor with BOOTSTRAP
> > <koen> something like DEFAULT_TASK_PROVIDER?
> > <rwhitby> yep, DEFAULT_TASK_PROVIDER floats my boat.
> > <koen> do you want to write an RFC for that?
>
> The proposal is to replace MACHINE_TASK_PROVIDER with
> DEFAULT_TASK_PROVIDER throughout OE, and encourage all image-foo.bb
> maintainers to base their image on DEFAULT_TASK_PROVIDER (which can be
> set to task-boot, or task-base, or perhaps some other distro-specific
> single task-foo value), plus other image-specific stuff.
>
> Comments?  Objections?
>
> BTW, task-bootstrap existence is as follows:
>
> > ./conf/distro/generic.conf:PREFERRED_PROVIDER_task-bootstrap =
> "task-bootstrap"
> >
> ./conf/distro/include/oplinux.inc:PREFERRED_PROVIDER_task-bootstra
> p = "task-base"
> >
> ./conf/distro/angstrom-2007.1.conf:PREFERRED_PROVIDER_task-bootstr
> ap = "task-bootstrap"
> >
> ./conf/distro/jlime-donkey.conf:PREFERRED_PROVIDER_task-bootstrap
> = "task-bootstrap"
> >
> ./conf/distro/openprotium.conf:#PREFERRED_PROVIDER_task-bootstrap
> = "task-bootstrap"
> > ./conf/machine/gumstix.conf:PREFERRED_VERSION_task-bootstrap =
> "1.0unionroot"
> > ./packages/obsolete/tasks/task-bootstrap-unionroot.bb:PROVIDES
> = "task-bootstrap"
> > ./packages/obsolete/tasks/task-bootstrap-unionroot.bb:RPROVIDES
> = "task-bootstrap"
> > ./packages/obsolete/tasks/task-bootstrap-unionroot.bb:require
> task-bootstrap.inc
> > ./packages/obsolete/tasks/task-bootstrap.bb:require task-bootstrap.inc
> > ./packages/images/jlime-opie.bb:DEPENDS = "task-bootstrap task-opie"
> > ./packages/images/jlime-opie.bb:INSTALL_PACKAGES =
> "task-bootstrap task-opie-base task-opie-base-applets \
> > ./removal.txt:Package Name:   task-bootstrap*
>
> -- Rod
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>





From no2spam at nospam.arcornews.de  Tue May  1 19:23:42 2007
From: no2spam at nospam.arcornews.de (Rolf Leggewie)
Date: Tue, 01 May 2007 21:23:42 +0200
Subject: [oe] [oe-commits] org.oe.dev xtscal: attempt to fix
	miscalibrations
In-Reply-To: <432beae0705011113v61831859x7978062963a48b8@mail.gmail.com>
References: <E1HgoSJ-0008AG-St@linuxtogo.org>	<462FBE16.9070805@dominion.kabel.utwente.nl>	<46362F71.7080604@dominion.kabel.utwente.nl>
	<432beae0705011113v61831859x7978062963a48b8@mail.gmail.com>
Message-ID: <f1843v$doc$1@sea.gmane.org>

Justin Patrin wrote:
> I was just about to test this when my boot into a new image failed
> with a missing libgcc. This RPATH issue needs to be fixed ASAP.

OK, you got the job ;-)

Serious now, from what I read in bug 2093 I doubt the miscalibration 
issue is fixed yet.




From koen at dominion.kabel.utwente.nl  Tue May  1 19:34:33 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Tue, 01 May 2007 21:34:33 +0200
Subject: [oe] [oe-commits] org.oe.dev xtscal: attempt to
	fix	miscalibrations
In-Reply-To: <f1843v$doc$1@sea.gmane.org>
References: <E1HgoSJ-0008AG-St@linuxtogo.org>	<462FBE16.9070805@dominion.kabel.utwente.nl>	<46362F71.7080604@dominion.kabel.utwente.nl>	<432beae0705011113v61831859x7978062963a48b8@mail.gmail.com>
	<f1843v$doc$1@sea.gmane.org>
Message-ID: <46379649.7040404@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Rolf Leggewie schreef:
> Justin Patrin wrote:
>> I was just about to test this when my boot into a new image failed
>> with a missing libgcc. This RPATH issue needs to be fixed ASAP.
> 
> OK, you got the job ;-)
> 
> Serious now, from what I read in bug 2093 I doubt the miscalibration 
> issue is fixed yet.

The tr was reinstated and the names uppercased, so what else is missing?

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGN5ZJMkyGM64RGpERApJsAJ9c26K2uBv6n8AwMWtgpVZpMJKeswCZAdLG
p7lqRvR2Nj6GBmPu11/q/ik=
=YVAl
-----END PGP SIGNATURE-----



From pmiscml at gmail.com  Tue May  1 20:42:53 2007
From: pmiscml at gmail.com (Paul Sokolovsky)
Date: Tue, 1 May 2007 23:42:53 +0300
Subject: [oe] RFC: RW access for polyonymous
In-Reply-To: <f17ves$luc$1@sea.gmane.org>
References: <f17ves$luc$1@sea.gmane.org>
Message-ID: <361637820.20070501234253@gmail.com>

Hello Rolf,

Tuesday, May 1, 2007, 9:04:10 PM, you wrote:

> Hi,

> with the amount (and speed!) of patches being provided by Michael 
> 'polyonymous' Krelin I think it makes sense to give him RW access to OE.
>   His bugs are at http://tinyurl.com/2llfhw

> Take a look, comment and decide.

        I support this, and would be happy to peer-review Michael's
commits.

> Regards

> Rolf


-- 
Best regards,
 Paul                            mailto:pmiscml at gmail.com




From no2spam at nospam.arcornews.de  Tue May  1 22:15:11 2007
From: no2spam at nospam.arcornews.de (Rolf Leggewie)
Date: Wed, 02 May 2007 00:15:11 +0200
Subject: [oe] [oe-commits] org.oe.dev xtscal: attempt to fix
	miscalibrations
In-Reply-To: <46379649.7040404@dominion.kabel.utwente.nl>
References: <E1HgoSJ-0008AG-St@linuxtogo.org>	<462FBE16.9070805@dominion.kabel.utwente.nl>	<46362F71.7080604@dominion.kabel.utwente.nl>	<432beae0705011113v61831859x7978062963a48b8@mail.gmail.com>	<f1843v$doc$1@sea.gmane.org>
	<46379649.7040404@dominion.kabel.utwente.nl>
Message-ID: <f18e5h$53j$1@sea.gmane.org>

Koen Kooi wrote:
>> Serious now, from what I read in bug 2093 I doubt the miscalibration 
>> issue is fixed yet.
> 
> The tr was reinstated and the names uppercased, so what else is missing?

polynonymous wrote that he needed mixed case.  But I have no first hand 
knowledge of how to fix this, yet.




From rod at whitby.id.au  Wed May  2 00:05:10 2007
From: rod at whitby.id.au (Rod Whitby)
Date: Wed, 02 May 2007 09:35:10 +0930
Subject: [oe] squasfs jffs2 default image settings
In-Reply-To: <HOECLKEKOHLAMMGDLLBHKEFLKOAA.skoroneos@digital-opsis.com>
References: <HOECLKEKOHLAMMGDLLBHKEFLKOAA.skoroneos@digital-opsis.com>
Message-ID: <4637D5B6.4060305@whitby.id.au>

Stelios Koroneos wrote:
> After a day of "head scratching" i realized the the reason an image i was
> building, failed to load on a powerpc target was that the default settings
> for squashfs squashfs-lzma and jffs2 were set to little endian architecture
> 
> //snip from  bitbake.conf
> 
> EXTRA_IMAGECMD_jffs2 = "--pad --little-endian --eraseblock=0x40000"
> EXTRA_IMAGECMD_squashfs = "-le -b 16384"
> EXTRA_IMAGECMD_squashfs-lzma = "-le -b 16384"
> 
> These look like they were set for a specific machine (maybe i am wrong), but
> shouldn't the default settings be at least architecture neutral ?
> (Even the block sizes shouldn't be defined there as a machine might be
> better suited by another size)
> 
> Any objections to have EXTRA_IMAGECMD for these types of images default to
> no specific settings  ?

Fine with me.  I think the nslu2 and ixp4xx are the few dual-endian
machines in OE, and both of them are already set up to set the
endianness, padding and block size on those commands explicitly.

-- Rod



From lenehan at twibble.org  Wed May  2 00:36:41 2007
From: lenehan at twibble.org (Jamie Lenehan)
Date: Wed, 2 May 2007 10:36:41 +1000
Subject: [oe] perl 5.8.8 is ready
In-Reply-To: <4636CCC0.1010109@gmail.com>
References: <20070427105722.GA4340@twibble.org> <46359408.9060800@gmail.com>
	<20070430080044.GA15877@twibble.org> <4636CCC0.1010109@gmail.com>
Message-ID: <20070502003641.GA5189@twibble.org>

On Tue, May 01, 2007 at 12:14:40AM -0500, Junqian Gordon Xu wrote:
> Thanks. I fixed the hostperl problem.
> 
> Don't know why. Even I commented out the DEFAULT_PREFERENCE = "-1", 
> bitbake still try to get perl-5.8.7 compiled first
> 
> NOTE: package perl-5.8.8-r8: task do_unpack: completed
> NOTE: package perl-5.8.8: completed
> NOTE: Running task 285 of 302 (ID: 130, 
> /home/OE/org.openembedded.dev/packages/perl/perl_5.8.7.bb, do_fetch)
> NOTE: package perl-5.8.7: started
> NOTE: package perl-5.8.7-r22: task do_fetch: started

This turns out to be an error on my part in perl 5.8.8 - I didn't
tell bitbake that perl 5.8.8 was providing all the perl modules. So
when something needed perl-modules (because of a DEPEND or RDEPEND)
it found that perl 5.8.8 provided them while 5.8.8 didn't.

If you had perl 5.8.7 already compiled and lying around you didn't
notice this issue. Since I've been building and testing changes for
both version I had 5.8.7 and 5.8.8 always compiled.

Anyway, I just checked in a fix for this so it should be ok now.

> Besides, I noticed another issue:
> I had linux-libc-headers-2.6.15.99 compiled (I think it's determined 
> Machine and Distro) . But perl-5.8.8 wants linux-libc-headers-2.6.20. 
> Will that cause problem?

Perl shouldn't care about linux-libc-headers, I use 2.6.15.99 here at
the moment.

Thanks.

-- 
 Jamie Lenehan <lenehan at twibble.org>



From xjqian at gmail.com  Wed May  2 04:05:58 2007
From: xjqian at gmail.com (Junqian Gordon Xu)
Date: Tue, 01 May 2007 23:05:58 -0500
Subject: [oe] perl 5.8.8 is ready
In-Reply-To: <20070502003641.GA5189@twibble.org>
References: <20070427105722.GA4340@twibble.org> <46359408.9060800@gmail.com>
	<20070430080044.GA15877@twibble.org> <4636CCC0.1010109@gmail.com>
	<20070502003641.GA5189@twibble.org>
Message-ID: <46380E26.6070303@gmail.com>

Jamie Lenehan wrote:
> On Tue, May 01, 2007 at 12:14:40AM -0500, Junqian Gordon Xu wrote:
>   
> This turns out to be an error on my part in perl 5.8.8 - I didn't
> tell bitbake that perl 5.8.8 was providing all the perl modules. So
> when something needed perl-modules (because of a DEPEND or RDEPEND)
> it found that perl 5.8.8 provided them while 5.8.8 didn't.
>
> If you had perl 5.8.7 already compiled and lying around you didn't
> notice this issue. Since I've been building and testing changes for
> both version I had 5.8.7 and 5.8.8 always compiled.
>
> Anyway, I just checked in a fix for this so it should be ok now.
>
>   
I can confirm with the latest mtn pull, perl-5.8.8 builds fine for me 
here except for some warning signs:

NOTE: package perl-5.8.8: started
NOTE: package perl-5.8.8-r10: task do_package: started
NOTE: perl-lib contains dangling symlink to /usr/lib/perl/5.8.8
NOTE: perl-lib contains dangling symlink to /usr/share/perl/5.8.8
NOTE: Couldn't find shared library provider for libgcc_s.so.1
NOTE: Couldn't find shared library provider for libgcc_s.so.1

>> Besides, I noticed another issue:
>> I had linux-libc-headers-2.6.15.99 compiled (I think it's determined 
>> Machine and Distro) . But perl-5.8.8 wants linux-libc-headers-2.6.20. 
>> Will that cause problem?
>>     
>
> Perl shouldn't care about linux-libc-headers, I use 2.6.15.99 here at
> the moment.
However, this issue is still outstanding. I'm trying to understand where 
the 2.6.20 dependency is coming from. Is this a bitbake issue?

bitbake perl:

OE Build Configuration:
BB_VERSION     = "1.8.3"
OE_REVISION    = "3ea77972dcf422ed70f1a083c412f43ab519f474"
TARGET_ARCH    = "arm"
TARGET_OS      = "linux-gnueabi"
MACHINE        = "tosa"
DISTRO         = "angstrom"
DISTRO_VERSION = "test-20070502"
TARGET_FPU     = "soft"

NOTE: Resolving missing task queue dependencies
NOTE: preferred version 2.5 of glibc not available (for item 
virtual/arm-angstrom-linux-gnueabi-libc-for-gcc)
NOTE: Preparing Runqueue
NOTE: Executing runqueue
NOTE: Running task 115 of 294 (ID: 131, 
/home/OE/org.openembedded.dev/packages/linux-libc-headers/linux-libc-headers_2.6.20.bb, 
do_fetch)
NOTE: package linux-libc-headers-2.6.20: started



From no2spam at nospam.arcornews.de  Wed May  2 15:48:45 2007
From: no2spam at nospam.arcornews.de (Rolf Leggewie)
Date: Wed, 02 May 2007 17:48:45 +0200
Subject: [oe] upgrade "policy"
Message-ID: <f1absu$4no$1@sea.gmane.org>

Hi,

I would like to bring to your attention the powers of "mtn mv" when 
upgrading packages.  I have written up a little HOWTO at 
http://www.openembedded.org/upgradingpackages which I would consider 
"best practice" rather than policy.  I hope you all approve of this.

Regards

Rolf




From rodrigo.vivi at gmail.com  Wed May  2 18:04:39 2007
From: rodrigo.vivi at gmail.com (Rodrigo Vivi)
Date: Wed, 2 May 2007 15:04:39 -0300
Subject: [oe] generating debian source packages (dsc)
Message-ID: <bdb0025f0705021104x23d2c407rb4da0e48e24eb911@mail.gmail.com>

Hi all,

I'm trying to code a bbclass to build debian source packages, because
I need these files under mamona repository:

 * .dsc - debian source package control file
 * .orig.tar.gz - Original source package
 * .diff.gz - patches that we apply

Since this is my first bbclass I need some help to figure some doubts out.

first of all I've created a package_dsc task and added it before do_configure.

This task creates the debian/control and debian/changelog file that
dpkg-source ask for dsc generation. I know that I need to generate the
debian/rules file too because without it the dsc will not be usefull.
But this is not my real problem yet.

The current problem that I'm trying to solve and need help is the following:

before the do_configure all packages have a .pc dir that is not under
orig.tar.gz file neither inside some patch breaking the dpkg-source
but that is pretty easy to ignore doing
$dpkg-source -i"\.pc" ...
But glibc has a ports directory that is not under orig.tar.gz neither
under patches so I need to ignore this file too. And I know that is
NOT a good idea to ignore it doing
dpkg-source  -i"\.pc|ports"
And I've noticed that there are another files that breaks dpkg-source...
like util-linux_2.12r-12.diff.gz under patches dir of util-linux

I'm thinking to create a exclude-list or a dictionary to have an
exclude-list for each package. What do you thing about it? Do you know
a better and simplest way to do this?

I'm anexing my bbclass file in case you want to have a look and help me! ;)

Thanks,
Best Regards,
Vivi.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gen_dsc.bbclass
Type: application/octet-stream
Size: 6393 bytes
Desc: not available
URL: <http://lists.openembedded.org/pipermail/openembedded-devel/attachments/20070502/1191fe55/attachment-0002.obj>

From openembedded at hrw.one.pl  Wed May  2 18:51:02 2007
From: openembedded at hrw.one.pl (Marcin Juszkiewicz)
Date: Wed, 2 May 2007 20:51:02 +0200
Subject: [oe] generating debian source packages (dsc)
In-Reply-To: <bdb0025f0705021104x23d2c407rb4da0e48e24eb911@mail.gmail.com>
References: <bdb0025f0705021104x23d2c407rb4da0e48e24eb911@mail.gmail.com>
Message-ID: <200705022051.03720.openembedded@hrw.one.pl>

Dnia ?roda, 2 maja 2007, Rodrigo Vivi napisa?:
> Hi all,
>
> I'm trying to code a bbclass to build debian source packages, because
> I need these files under mamona repository:
>
>  * .dsc - debian source package control file
>  * .orig.tar.gz - Original source package
>  * .diff.gz - patches that we apply
>
> Since this is my first bbclass I need some help to figure some doubts
> out.

classes/sourcepkg.bbclass is something which you want to extend

-- 
JID: hrw-jabber.org
OpenEmbedded developer/consultant

      I'm trying to decide if I should kill you or simply feign death
      until you feel awkward and leave.





From rodrigo.vivi at gmail.com  Wed May  2 19:52:54 2007
From: rodrigo.vivi at gmail.com (Rodrigo Vivi)
Date: Wed, 2 May 2007 16:52:54 -0300
Subject: [oe] generating debian source packages (dsc)
In-Reply-To: <200705022051.03720.openembedded@hrw.one.pl>
References: <bdb0025f0705021104x23d2c407rb4da0e48e24eb911@mail.gmail.com>
	<200705022051.03720.openembedded@hrw.one.pl>
Message-ID: <bdb0025f0705021252w7e32b305ybf9c914c1cb1edc0@mail.gmail.com>

> classes/sourcepkg.bbclass is something which you want to extend

I've thought about it but I'm not sure that it is a good idea because
just few projects (or just mine) needs the dsc file .......... unless
that I code another sourcedsc.bbclass that inherit the
sourcedpkg.bbclass... o you think that it will work???  I'll think
about it...

Another doubt that I forgot to mention on last email is about changelog:
I'm generating a almost empty changelog file. Is there any official
and/or more appropriated way to do that?

Thanks,
Vivi.

>
> --
> JID: hrw-jabber.org
> OpenEmbedded developer/consultant
>
>       I'm trying to decide if I should kill you or simply feign death
>       until you feel awkward and leave.
>
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>



From papercrane at gmail.com  Wed May  2 20:38:54 2007
From: papercrane at gmail.com (Justin Patrin)
Date: Wed, 2 May 2007 13:38:54 -0700
Subject: [oe] generating debian source packages (dsc)
In-Reply-To: <bdb0025f0705021252w7e32b305ybf9c914c1cb1edc0@mail.gmail.com>
References: <bdb0025f0705021104x23d2c407rb4da0e48e24eb911@mail.gmail.com>
	<200705022051.03720.openembedded@hrw.one.pl>
	<bdb0025f0705021252w7e32b305ybf9c914c1cb1edc0@mail.gmail.com>
Message-ID: <432beae0705021338x7ca36c0oc937a6b1b03f6db5@mail.gmail.com>

On 5/2/07, Rodrigo Vivi <rodrigo.vivi at gmail.com> wrote:
> > classes/sourcepkg.bbclass is something which you want to extend
>
> I've thought about it but I'm not sure that it is a good idea because
> just few projects (or just mine) needs the dsc file .......... unless
> that I code another sourcedsc.bbclass that inherit the
> sourcedpkg.bbclass... o you think that it will work???  I'll think
> about it...
>

Yes, this is what Marcin meant. Create your own sourcedsc.bbclass
which inherits sourcepkg.bbclass. This is how, for example,
efl.bbclass and e.bbclass work.

> Another doubt that I forgot to mention on last email is about changelog:
> I'm generating a almost empty changelog file. Is there any official
> and/or more appropriated way to do that?
>
> Thanks,
> Vivi.
>
> >
> > --
> > JID: hrw-jabber.org
> > OpenEmbedded developer/consultant
> >
> >       I'm trying to decide if I should kill you or simply feign death
> >       until you feel awkward and leave.
> >
> >
> >
> > _______________________________________________
> > Openembedded-devel mailing list
> > Openembedded-devel at lists.openembedded.org
> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> >
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>


-- 
Justin Patrin



From pmiscml at gmail.com  Thu May  3 12:47:32 2007
From: pmiscml at gmail.com (Paul Sokolovsky)
Date: Thu, 3 May 2007 15:47:32 +0300
Subject: [oe] [ALERT] Security vulnerability with recent OE bitbake.conf
	changes
Message-ID: <35653307.20070503154732@gmail.com>

Hello openembedded-devel,

A commit made some time ago,

http://lists.linuxtogo.org/pipermail/openembedded-commits/2007-April/004912.html

introduced a hole which may lead to unnoticed security vulnerabilities
slipping into the packages/images produced. Specifically, it defines a
random application of a random suite to be used for resolving patching
conflicts/failures. If you don't happen to have that random tool,
patching failure will be silently swallowed, leading to any adverse
effects imaginable - from compile failure to the mentioned security
vulnerabilities.

Proposed solutions:

1. Bring back some reality and switch back to previous default of
dropping to standard shell for resolution:

-TERMCMD ?= "${GNOME_TERMCMD}"
-TERMCMDRUN ?= "${GNOME_TERMCMDRUN}"
+TERMCMD ?= "${SHELLRCCMD}"
+TERMCMDRUN ?= "${SHELLRCCMD}"


2. Add DEPENDS on that random tool, namely gnome-terminal.

If going with choice 2, I proposed also to do the following: 1) add
depends on xine, mplayer, totem, few other video players; 2) add depends
on mesa and show nice 3d rotating menu to select player of user choice;
3) use selected player to show video during the build - after all,
if user deserves comfort of using superfluous GUI tools for conflict
resolution, why one should be bored during normal build process?


Thanks,

-- 
 Paul                          mailto:pmiscml at gmail.com




From rpurdie at rpsys.net  Thu May  3 13:07:08 2007
From: rpurdie at rpsys.net (Richard Purdie)
Date: Thu, 03 May 2007 14:07:08 +0100
Subject: [oe] [ALERT] Security vulnerability with recent OE
	bitbake.conf	changes
In-Reply-To: <35653307.20070503154732@gmail.com>
References: <35653307.20070503154732@gmail.com>
Message-ID: <1178197628.6312.22.camel@localhost.localdomain>

On Thu, 2007-05-03 at 15:47 +0300, Paul Sokolovsky wrote:
> If going with choice 2, I proposed also to do the following: 1) add
> depends on xine, mplayer, totem, few other video players; 2) add depends
> on mesa and show nice 3d rotating menu to select player of user choice;
> 3) use selected player to show video during the build - after all,
> if user deserves comfort of using superfluous GUI tools for conflict
> resolution, why one should be bored during normal build process?

Paul,

Is there really any need for this?

It doesn't encourage me to give a sensible reply, does it...

Richard




From rpurdie at rpsys.net  Thu May  3 13:16:39 2007
From: rpurdie at rpsys.net (Richard Purdie)
Date: Thu, 03 May 2007 14:16:39 +0100
Subject: [oe] [ALERT] Security vulnerability with recent OE
	bitbake.conf	changes
In-Reply-To: <35653307.20070503154732@gmail.com>
References: <35653307.20070503154732@gmail.com>
Message-ID: <1178198199.6312.30.camel@localhost.localdomain>

On Thu, 2007-05-03 at 15:47 +0300, Paul Sokolovsky wrote:
> Hello openembedded-devel,
> 
> A commit made some time ago,
> 
> http://lists.linuxtogo.org/pipermail/openembedded-commits/2007-April/004912.html
> 
> introduced a hole which may lead to unnoticed security vulnerabilities
> slipping into the packages/images produced. Specifically, it defines a
> random application of a random suite to be used for resolving patching
> conflicts/failures. If you don't happen to have that random tool,
> patching failure will be silently swallowed, leading to any adverse
> effects imaginable - from compile failure to the mentioned security
> vulnerabilities.

Patch failure should not be silently swallowed, the builds should abort.
If they don't, we need to fix that underlying problem.

FWIW, your first solution using SHELLRCCMD won't actually work due to
the way IO redirection is done in recent bitbake. 

Your second solution of adding the DEPENDS is impractical due to the
amount of -native packages it would require.

So we need to find the real problem and fix that, probably somewhere in
patch.bbclass an error code isn't being propagated at a guess.

I will also hint at the use of PATCH_RESOLVER = "noop" which means the
user gets the old behaviour of patch failure aborts the build with no
help from any resolver. It should have always been the default but
wasn't. I'm not sure what the current default is but we can change it to
that if its not.

Cheers,

Richard




From pmiscml at gmail.com  Thu May  3 13:42:06 2007
From: pmiscml at gmail.com (Paul Sokolovsky)
Date: Thu, 3 May 2007 16:42:06 +0300
Subject: [oe] [ALERT] Security vulnerability with recent OE bitbake.conf
	changes
In-Reply-To: <1178198199.6312.30.camel@localhost.localdomain>
References: <35653307.20070503154732@gmail.com>
	<1178198199.6312.30.camel@localhost.localdomain>
Message-ID: <183568912.20070503164206@gmail.com>

Hello Richard,

Thursday, May 3, 2007, 4:16:39 PM, you wrote:

> On Thu, 2007-05-03 at 15:47 +0300, Paul Sokolovsky wrote:
>> Hello openembedded-devel,
>> 
>> A commit made some time ago,
>> 
>> http://lists.linuxtogo.org/pipermail/openembedded-commits/2007-April/004912.html
>> 
>> introduced a hole which may lead to unnoticed security vulnerabilities
>> slipping into the packages/images produced. Specifically, it defines a
>> random application of a random suite to be used for resolving patching
>> conflicts/failures. If you don't happen to have that random tool,
>> patching failure will be silently swallowed, leading to any adverse
>> effects imaginable - from compile failure to the mentioned security
>> vulnerabilities.


[]

> Is there really any need for this?
> It doesn't encourage me to give a sensible reply, does it...

        Apparently no. But for me, it's pretty clear that even
gnome-terminal shouldn't be used by default, and in expectation of
hardnesses regarding arguing this, I tried to draw picturesquely
absurd "extension", overspiced with few buzzwords. It's of course a
mere small bug otherwise, but I truly looking for solution which won't
by default trouble KDE, other WMs, and classy console guys in favor of
GNOME crowd.


> Patch failure should not be silently swallowed, the builds should abort.
> If they don't, we need to fix that underlying problem.

        Yes, I didn't even bother to ruin my pamphlet with such
down-to-earth triviality ;-). I'd be looking into it as time permits
of course.

> FWIW, your first solution using SHELLRCCMD won't actually work due to
> the way IO redirection is done in recent bitbake. 

> Your second solution of adding the DEPENDS is impractical due to the
> amount of -native packages it would require.

> So we need to find the real problem and fix that, probably somewhere in
> patch.bbclass an error code isn't being propagated at a guess.

> I will also hint at the use of PATCH_RESOLVER = "noop" which means the
> user gets the old behaviour of patch failure aborts the build with no
> help from any resolver. It should have always been the default but
> wasn't. I'm not sure what the current default is but we can change it to
> that if its not.

        Ack, and vote for. Let's have defaults not overloaded with
interactivity, and working along the lines of standard unix/posix
build tools. Frontends, likes one(s) you work on, can have own
config/overrides then. (And few people won't used them anyway, no
matter which potential benefits they give - and not out of
bare-commandline orthodoxy, but because they may have other frontends
relying on classical unix behavior of tools).

> Cheers,

> Richard



-- 
Best regards,
 Paul                            mailto:pmiscml at gmail.com




From leon.woestenberg at gmail.com  Fri May  4 16:19:58 2007
From: leon.woestenberg at gmail.com (Leon Woestenberg)
Date: Fri, 4 May 2007 18:19:58 +0200
Subject: [oe] task-base dependencies and missing logging of failed providers
Message-ID: <c384c5ea0705040919u8bdafe9sa6abe0942ffe3fd8@mail.gmail.com>

Hello,

just wanted to get this down for those not having followed the
discussion on IRC (and just for the record, not that the ideas are
still fresh).

My idea about a minimal image that OE should support (Goal: OE must be
scalable) is a linux kernel with a single init application
(helloworld).

Today on IRC we discussed two issues with BB/OE, indirectly blocking
the ability to build a minimal image using task-base, especially for
new users.

(1) task-base always wants *all* targets in task-* to be buildable,
regardless whether they are installed or not.

Example:

Take angstrom, strip {MACHINE,DISTRO}_FEATURES such that
COMBINED_FEATURES="ext2" or something really basic.
Set USE_NLS="no"

When now building angstrom-minimal-image, task-base wants bluetooth to
be buildable, thus bluez-utils, thus dbus, cups, glib-2.0, etc. etc.
Because glib-2.0 requires USE_NLS="yes", the image build fails with "a
no providers for" message.

[10:34]	<v8jlene>	likewise: Yeah, that task-base one's a bit annoying.
I only had about 400 recipes symlinked in, now I have them all just to
make task-base happy. And as you say it's building lots of stuff that
you don't use.

Workarounds:
- USE_NLS_glib-2.0="yes" (yes, at least makes image buildable, IFF the
other deps are met, everything is still built)

Suggested fixes:
- split task-base into seperate *.bb would work (koen, hrw), but this
is not the proper solution (RP, koen)
- do not use debian.bbclass (tried, but does not work for me)
- ...

(2) It's very hard to track down and I'm not alone:

[10:29]	<v8jlene>	likewise: Heh, I had that issue yesterday when
trying my uclibc builds with 1.8.2 ;) The error bitbake showed was
about bootstrap-image was unavailable (due to task-base pulling in
cups which pulled in dbus which pulled in glib-2.0). Took ages to
figure it all out...

New users won't find this, as bitbake -D -D -D -v does not provide this info.

2) bitbake will NOT report the above dependency
logging of failed providers

However, this one is hard to fix:

[10:31]	<RP>	likewise: There is a bitbake bug already open about the
logging of failed providers
[10:31]	<RP>	Its not as simple as it sounds though


Reproduce

taking the ?ngstr?m distro as a base, I would like to strip it down a
bit. I stripped {MACHINE,DISTRO}_FEATURES such that:

COMBINED_FEATURES="ext2"
DISTRO_EXTRA_RDEPENDS="update-modules module-init-tools
modutils-initscripts sysvinit initscripts sysvinit-pidof netbase
dropbear ipkg ipkg-collateral util-linux-mount util-linux-umount"

As none of the selected package need NLS, I have disabled it.

USE_NLS = "no"

bitbake angstrom-minimal image
or
bitbake bootstrap-image


Regards,
-- 
Leon

The persons and animals named in this email are based on true
characters in real life.



From cailotto at sci.univr.it  Fri May  4 10:33:10 2007
From: cailotto at sci.univr.it (Stefano Cailotto)
Date: Fri, 4 May 2007 12:33:10 +0200
Subject: [oe] OE on Kontron eb425
Message-ID: <002a01c78e37$9d165360$38f21b9d@kai>

Hi all, 
I'm trying to build something usable for a kontron eb425 board, based on an
intel ixp425.
I tried to compile using a generic ixp4xxbe, but when loading, the kernel
stops after uncompressing reporting a CRC error.
It seems that Kontron EmbeddedLinux development kit performs something on
the kernel before making zImage in order to load it in a specifed memory
location.
I'd like to use OE, anyway, so my questions are:
1) has anyone faced my same problem (possibly with positive results)?
2) is there away to "port" kontron configuration inside OE?I'm looking to
understand how...

Thanx, 
Stefano


---------------------------------------------------------------------------
  Stefano Cailotto - Research Consultant
---------------------------------------------------------------------------
  EDALab - Networked Embedded Systems
  c/o  Dipartimento di Informatica - Universita` di Verona
  Strada le Grazie, 15 - 37134 Verona (Italy)
---------------------------------------------------------------------------
  email: cailotto at sci.univr.it stefano.cailotto at edalab.it      
  web:  http://www.edalab.it
  tel: +39-045-802-7062 fax: +39-045-802-7068
---------------------------------------------------------------------------




From leon.woestenberg at gmail.com  Sat May  5 12:35:22 2007
From: leon.woestenberg at gmail.com (Leon Woestenberg)
Date: Sat, 5 May 2007 14:35:22 +0200
Subject: [oe] OE on Kontron eb425
In-Reply-To: <002a01c78e37$9d165360$38f21b9d@kai>
References: <002a01c78e37$9d165360$38f21b9d@kai>
Message-ID: <c384c5ea0705050535i1c13cc5ase333da9be4d6cf8e@mail.gmail.com>

Hello Stefano,

On 5/4/07, Stefano Cailotto <cailotto at sci.univr.it> wrote:
> Hi all,
> I'm trying to build something usable for a kontron eb425 board, based on an
> intel ixp425.
> I tried to compile using a generic ixp4xxbe, but when loading, the kernel
> stops after uncompressing reporting a CRC error.
> It seems that Kontron EmbeddedLinux development kit performs something on
> the kernel before making zImage in order to load it in a specifed memory
> location.
>
There are some IXP42x users on OE, mostly for the NSLU device from
Linksys/Cisco, the Intel dev board (IXDP425) and some custom boards,
but I have not see the Kontron board yet.

With the reported problem, it would help if you understand or at least
could tell where to find the details on the boot loader.

Ideally, you would want to boot loader to be buildable from source
instead of relying on some binary on flash.

Regards,

Leon.



From repvik at kynisk.com  Sat May  5 13:46:45 2007
From: repvik at kynisk.com (=?iso-8859-1?q?=D8yvind_Repvik?=)
Date: Sat, 5 May 2007 15:46:45 +0200
Subject: [oe] OE on Kontron eb425
In-Reply-To: <c384c5ea0705050535i1c13cc5ase333da9be4d6cf8e@mail.gmail.com>
References: <002a01c78e37$9d165360$38f21b9d@kai>
	<c384c5ea0705050535i1c13cc5ase333da9be4d6cf8e@mail.gmail.com>
Message-ID: <200705051546.46019.repvik@kynisk.com>

On Saturday 05 May 2007 14:35:22 Leon Woestenberg wrote:
> Hello Stefano,
>
> On 5/4/07, Stefano Cailotto <cailotto at sci.univr.it> wrote:
> > Hi all,
> > I'm trying to build something usable for a kontron eb425 board, based on
> > an intel ixp425.
> > I tried to compile using a generic ixp4xxbe, but when loading, the kernel
> > stops after uncompressing reporting a CRC error.
> > It seems that Kontron EmbeddedLinux development kit performs something on
> > the kernel before making zImage in order to load it in a specifed memory
> > location.
>
> There are some IXP42x users on OE, mostly for the NSLU device from
> Linksys/Cisco, the Intel dev board (IXDP425) and some custom boards,
> but I have not see the Kontron board yet.
>
> With the reported problem, it would help if you understand or at least
> could tell where to find the details on the boot loader.

A very important detail is which MACH ID the bootloader passes via ATAG.

Regards,
?yvind



From koen at dominion.kabel.utwente.nl  Sat May  5 14:54:52 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Sat, 05 May 2007 16:54:52 +0200
Subject: [oe] Questions: Founding of Open Embedded, dev gatherings etc.
In-Reply-To: <200705041909.29494.kyrvin@trolltech.com>
References: <200705041909.29494.kyrvin@trolltech.com>
Message-ID: <463C9ABC.7090503@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Knut Yrvin schreef:
> Hi all :)
> 
> At FOSDEM I talked with Gerwin van der Kruis about Trolltech helping Open 
> Embedded getting started with developer gatherings and a foundation. 
> 
> I got some experiences with developer gatherings after initiationg the 
> Skolelinux project in 2001. Actually we have organised +30 gatherings. 
> Skolelinux is now a part of DebianEdu. The board of "Free Software in School" 
> organises about 6-7 developer gatherings a year. Pictures from opening of one 
> of the gatherings in Forbach - France, gives an idea of the scale: 
> 
> http://www.bawetic.be/PHOTOS/Forbach2006/
> 
> I would like to see similar activeties in OpenEmbedded space. Maybe Mobile 
> Developer Days 2007 at Alborg University in Denmark could be the place to 
> start?: 
> 
> http://mobiledevices.kom.aau.dk/team_and_organization/events/mobile_developer_days_2007/
> 
> To sum it up. Gerwin van der Kruis idea is to make a foundation, and getting  
> dev.gatherings started. Is this interesting for you? If you are interesed, 
> how should we proceed?

We are certainly interested! At the moment a big part of our core developers is on
holiday, moving appartments, doing examns, etc, so we'll get back to you in a few days.

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGPJq8MkyGM64RGpERApcQAJ9DBG3lBC15R7vs86XeN2DE7UZoGACeIs/R
C1jgdp0EigJhbElqYG+U7Og=
=lH/J
-----END PGP SIGNATURE-----



From koen at dominion.kabel.utwente.nl  Sat May  5 15:11:37 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Sat, 05 May 2007 17:11:37 +0200
Subject: [oe] RFC: make do_install and do_deploy a PACKAGE_FUNC
Message-ID: <463C9EA9.2060302@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Lately there have been several problems with files not getting packaged, because users
resumed builds after a failure. Richard has come up with a fix:

http://www.rpsys.net/openzaurus/temp/oe-install-change.patch

The only bug with that patch is that do_deploy fails, which can be solved by making that a
 PACKAGE_FUNC as well.

What do you think about that?

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGPJ6pMkyGM64RGpERAs9xAKC7qGcvY8E9wGMsp/o/2MQO/pIMmACeKknh
HcvgGS6egpiNlqq9Zx5eQO8=
=CUmR
-----END PGP SIGNATURE-----



From manuel.teira at telefonica.net  Sun May  6 20:17:51 2007
From: manuel.teira at telefonica.net (Manuel Teira)
Date: Sun, 06 May 2007 22:17:51 +0200
Subject: [oe] gstreamer obsoleted recipes
Message-ID: <1178482671.6132.10.camel@localhost>

Hello all.

I've recently added some recipes for gstreamer and gst-plugins-[good|
bad|ugly|...] in order to build the last stable releases of this
software. I've seen that there are a lot of "old" stable releases that
if nobody is needing, we could sanely delete from the repository.

My plan is to only left the last stable version for all the related
packages, so, we would keep only the following recipes, in the directory
gstreamer:

gst-ffmpeg_0.10.2.bb
gst-plugins-base_0.10.12.bb
gst-plugins-good_0.10.5.bb
gst-plugins-ugly_0.10.5.bb
gstreamer_0.10.12.bb

The only distro that seems to depend on  a fixed gstreamer version
(0.10.11) is angstrom. But I assume that we can upgrade that requirement
to 0.10.12 without problems.

If nobody disagree, I will proceed with the gstreamer cleanup the next
week.

Best regards.





From koen at dominion.kabel.utwente.nl  Sun May  6 20:38:32 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Sun, 06 May 2007 22:38:32 +0200
Subject: [oe] gstreamer obsoleted recipes
In-Reply-To: <1178482671.6132.10.camel@localhost>
References: <1178482671.6132.10.camel@localhost>
Message-ID: <463E3CC8.10407@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Manuel Teira schreef:
> Hello all.
> 
> I've recently added some recipes for gstreamer and gst-plugins-[good|
> bad|ugly|...] in order to build the last stable releases of this
> software. I've seen that there are a lot of "old" stable releases that
> if nobody is needing, we could sanely delete from the repository.
> 
> My plan is to only left the last stable version for all the related
> packages, so, we would keep only the following recipes, in the directory
> gstreamer:
> 
> gst-ffmpeg_0.10.2.bb
> gst-plugins-base_0.10.12.bb
> gst-plugins-good_0.10.5.bb
> gst-plugins-ugly_0.10.5.bb
> gstreamer_0.10.12.bb
> 
> The only distro that seems to depend on  a fixed gstreamer version
> (0.10.11) is angstrom. But I assume that we can upgrade that requirement
> to 0.10.12 without problems.

Yes, it's safe, angstrom only had those versions locked down to select 0.10 over 0.8, but
0.8 is gone now, so those preferred_versions should be safe to remove.

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGPjzIMkyGM64RGpERAky3AJ4t1RemMlENfVNDI1pdPIpIkBqJNwCfTIoq
DazvNQqprOC1w9bC1hRehq4=
=6F9d
-----END PGP SIGNATURE-----



From papercrane at gmail.com  Mon May  7 04:29:26 2007
From: papercrane at gmail.com (Justin Patrin)
Date: Sun, 6 May 2007 21:29:26 -0700
Subject: [oe] [ALERT] Security vulnerability with recent OE bitbake.conf
	changes
In-Reply-To: <1178198199.6312.30.camel@localhost.localdomain>
References: <35653307.20070503154732@gmail.com>
	<1178198199.6312.30.camel@localhost.localdomain>
Message-ID: <432beae0705062129i11f69731n1d12777f46a83316@mail.gmail.com>

On 5/3/07, Richard Purdie <rpurdie at rpsys.net> wrote:
> On Thu, 2007-05-03 at 15:47 +0300, Paul Sokolovsky wrote:
> > Hello openembedded-devel,
> >
> > A commit made some time ago,
> >
> > http://lists.linuxtogo.org/pipermail/openembedded-commits/2007-April/004912.html
> >
> > introduced a hole which may lead to unnoticed security vulnerabilities
> > slipping into the packages/images produced. Specifically, it defines a
> > random application of a random suite to be used for resolving patching
> > conflicts/failures. If you don't happen to have that random tool,
> > patching failure will be silently swallowed, leading to any adverse
> > effects imaginable - from compile failure to the mentioned security
> > vulnerabilities.
>
> Patch failure should not be silently swallowed, the builds should abort.
> If they don't, we need to fix that underlying problem.
>
> FWIW, your first solution using SHELLRCCMD won't actually work due to
> the way IO redirection is done in recent bitbake.
>
> Your second solution of adding the DEPENDS is impractical due to the
> amount of -native packages it would require.
>
> So we need to find the real problem and fix that, probably somewhere in
> patch.bbclass an error code isn't being propagated at a guess.
>
> I will also hint at the use of PATCH_RESOLVER = "noop" which means the
> user gets the old behaviour of patch failure aborts the build with no
> help from any resolver. It should have always been the default but
> wasn't. I'm not sure what the current default is but we can change it to
> that if its not.
>

Ummm...where? I tried that in my local.conf and it did nothing. I've
also grepped for PATCH_RESOLVER in both bitbake and oe and found
nothing.

Please, let's remove the gnome-terminal default, it makes no sense to
assume that the lowest common denominator is running bitbake from X...

-- 
Justin Patrin



From papercrane at gmail.com  Mon May  7 04:29:26 2007
From: papercrane at gmail.com (Justin Patrin)
Date: Sun, 6 May 2007 21:29:26 -0700
Subject: [oe] [ALERT] Security vulnerability with recent OE bitbake.conf
	changes
In-Reply-To: <1178198199.6312.30.camel@localhost.localdomain>
References: <35653307.20070503154732@gmail.com>
	<1178198199.6312.30.camel@localhost.localdomain>
Message-ID: <432beae0705062129i11f69731n1d12777f46a83316@mail.gmail.com>

On 5/3/07, Richard Purdie <rpurdie at rpsys.net> wrote:
> On Thu, 2007-05-03 at 15:47 +0300, Paul Sokolovsky wrote:
> > Hello openembedded-devel,
> >
> > A commit made some time ago,
> >
> > http://lists.linuxtogo.org/pipermail/openembedded-commits/2007-April/004912.html
> >
> > introduced a hole which may lead to unnoticed security vulnerabilities
> > slipping into the packages/images produced. Specifically, it defines a
> > random application of a random suite to be used for resolving patching
> > conflicts/failures. If you don't happen to have that random tool,
> > patching failure will be silently swallowed, leading to any adverse
> > effects imaginable - from compile failure to the mentioned security
> > vulnerabilities.
>
> Patch failure should not be silently swallowed, the builds should abort.
> If they don't, we need to fix that underlying problem.
>
> FWIW, your first solution using SHELLRCCMD won't actually work due to
> the way IO redirection is done in recent bitbake.
>
> Your second solution of adding the DEPENDS is impractical due to the
> amount of -native packages it would require.
>
> So we need to find the real problem and fix that, probably somewhere in
> patch.bbclass an error code isn't being propagated at a guess.
>
> I will also hint at the use of PATCH_RESOLVER = "noop" which means the
> user gets the old behaviour of patch failure aborts the build with no
> help from any resolver. It should have always been the default but
> wasn't. I'm not sure what the current default is but we can change it to
> that if its not.
>

Ummm...where? I tried that in my local.conf and it did nothing. I've
also grepped for PATCH_RESOLVER in both bitbake and oe and found
nothing.

Please, let's remove the gnome-terminal default, it makes no sense to
assume that the lowest common denominator is running bitbake from X...

-- 
Justin Patrin



From koen at dominion.kabel.utwente.nl  Mon May  7 10:39:11 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Mon, 07 May 2007 12:39:11 +0200
Subject: [oe] Potential Problems in glibc-package.bbclass
In-Reply-To: <45F0200B.9080002@dominion.kabel.utwente.nl>
References: <a7f8874a0702280825j22bdf3bbw94e58cfd4a0fab93@mail.gmail.com>
	<45F0200B.9080002@dominion.kabel.utwente.nl>
Message-ID: <463F01CF.5010601@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Koen Kooi schreef:
> Hans Henry von Tresckow schreef:
>> I think I may have stumbled across some potential bugs in glibc-package.bbclass:
> 
>> it seems like the standard value for datadir is /usr/share which will
>> cause the following problems in output_locale_binary:
> 
>> 1) i18npath will be set to /usr/share/i18n instead of
>> treedir/usr/share/i18n becouse path.join is too braindead to remove
>> leading / on path entries.
>> 2) the --inputfile option in localdef opts uses datadir instead of
>> treedir, so it looks like it would use the locale files installed on
>> the host instead of the ones we are buildig for.
> 
> 
> There now is a base_path_join function in OE, that doesn't have that bug. No idea why
> glibc.bbclass hasn't been updated to use that.

See http://bugs.openembedded.org/show_bug.cgi?id=1821#c9 for the proposed solution for at
least 1).

regards,

Koen

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGPwHPMkyGM64RGpERAjMsAJ9hwzbjdM/QDmpE/gPkB9taIK7wgACePfxv
E306nGzJX80t3kuMxbtqe+Y=
=W3Un
-----END PGP SIGNATURE-----



From pmiscml at gmail.com  Mon May  7 10:43:31 2007
From: pmiscml at gmail.com (Paul Sokolovsky)
Date: Mon, 7 May 2007 13:43:31 +0300
Subject: [oe] Potential Problems in glibc-package.bbclass
In-Reply-To: <463F01CF.5010601@dominion.kabel.utwente.nl>
References: <a7f8874a0702280825j22bdf3bbw94e58cfd4a0fab93@mail.gmail.com>
	<45F0200B.9080002@dominion.kabel.utwente.nl>
	<463F01CF.5010601@dominion.kabel.utwente.nl>
Message-ID: <1019023621.20070507134331@gmail.com>

Hello Koen,

Monday, May 7, 2007, 1:39:11 PM, you wrote:

[]

>>> I think I may have stumbled across some potential bugs in glibc-package.bbclass:
>> 
>>> it seems like the standard value for datadir is /usr/share which will
>>> cause the following problems in output_locale_binary:
>> 
>>> 1) i18npath will be set to /usr/share/i18n instead of
>>> treedir/usr/share/i18n becouse path.join is too braindead to remove
>>> leading / on path entries.
>>> 2) the --inputfile option in localdef opts uses datadir instead of
>>> treedir, so it looks like it would use the locale files installed on
>>> the host instead of the ones we are buildig for.
>> 
>> 
>> There now is a base_path_join function in OE, that doesn't have that bug. No idea why
>> glibc.bbclass hasn't been updated to use that.

> See http://bugs.openembedded.org/show_bug.cgi?id=1821#c9 for the proposed solution for at
> least 1).

        This is indeed few months old. Let's apply it?


> regards,

> Koen

[]

-- 
Best regards,
 Paul                            mailto:pmiscml at gmail.com




From koen at dominion.kabel.utwente.nl  Mon May  7 10:54:34 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Mon, 07 May 2007 12:54:34 +0200
Subject: [oe] Potential Problems in glibc-package.bbclass
In-Reply-To: <1019023621.20070507134331@gmail.com>
References: <a7f8874a0702280825j22bdf3bbw94e58cfd4a0fab93@mail.gmail.com>	<45F0200B.9080002@dominion.kabel.utwente.nl>	<463F01CF.5010601@dominion.kabel.utwente.nl>
	<1019023621.20070507134331@gmail.com>
Message-ID: <463F056A.7020907@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Paul Sokolovsky schreef:

>> See http://bugs.openembedded.org/show_bug.cgi?id=1821#c9 for the proposed solution for at
>> least 1).
> 
>         This is indeed few months old. Let's apply it?

Fine by me.

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGPwVqMkyGM64RGpERArHoAJ9fW1sGGBVZi0l8TpEruHO9eOJV6gCgnGjj
5Gy2vWx5lGYRjcnSlp2TouA=
=Y7wS
-----END PGP SIGNATURE-----



From no2spam at nospam.arcornews.de  Mon May  7 18:38:49 2007
From: no2spam at nospam.arcornews.de (Rolf Leggewie)
Date: Mon, 07 May 2007 20:38:49 +0200
Subject: [oe] perl 5.8.8 is ready
In-Reply-To: <20070427105722.GA4340@twibble.org>
References: <20070427105722.GA4340@twibble.org>
Message-ID: <f1nrnr$pal$1@sea.gmane.org>

Perl has been recently broken for

a) MACHINE="qemuarm" on angstrom
b) MACHINE="collie" on sharprom-compatible (worked two days prior)




From lenehan at twibble.org  Tue May  8 01:22:28 2007
From: lenehan at twibble.org (Jamie Lenehan)
Date: Tue, 8 May 2007 11:22:28 +1000
Subject: [oe] perl 5.8.8 is ready
In-Reply-To: <f1nrnr$pal$1@sea.gmane.org>
References: <20070427105722.GA4340@twibble.org> <f1nrnr$pal$1@sea.gmane.org>
Message-ID: <20070508012228.GA13161@twibble.org>

On Mon, May 07, 2007 at 08:38:49PM +0200, Rolf Leggewie wrote:
> Perl has been recently broken for
> 
> a) MACHINE="qemuarm" on angstrom
> b) MACHINE="collie" on sharprom-compatible (worked two days prior)

A log or something about what was going wrong might have helped ;)

Looking at irc logs it looks like you having problems with the patching
failing which it doesn't seem to do for anyone else.

My first suspect would be that you added the patch in question
(letgcc-find-errno.patch) locally to test it (when I added it to
bugzilla) and left it in there. Then a recent mt update has resulted
in the change I pushed being included resulting in the patch being
applied twice in the perl recipe.

So can you do an mtn diff on perl_5.8.8.bb and make sure this isn't
the problem? If it isn't the problem I might need some more
information (although I can't really thing of what else this could be
and/or what would help figuring it out at the moment.)

-- 
 Jamie Lenehan <lenehan at twibble.org>



From rpurdie at rpsys.net  Tue May  8 12:30:05 2007
From: rpurdie at rpsys.net (Richard Purdie)
Date: Tue, 08 May 2007 13:30:05 +0100
Subject: [oe] [ALERT] Security vulnerability with recent OE	bitbake.conf
	changes
In-Reply-To: <432beae0705062129i11f69731n1d12777f46a83316@mail.gmail.com>
References: <35653307.20070503154732@gmail.com>
	<1178198199.6312.30.camel@localhost.localdomain>
	<432beae0705062129i11f69731n1d12777f46a83316@mail.gmail.com>
Message-ID: <1178627405.6061.17.camel@localhost.localdomain>

On Sun, 2007-05-06 at 21:29 -0700, Justin Patrin wrote:
> Ummm...where? I tried that in my local.conf and it did nothing. I've
> also grepped for PATCH_RESOLVER in both bitbake and oe and found
> nothing.

Sorry, it should be PATCHRESOLVE = "noop", my memory is playing tricks.

> Please, let's remove the gnome-terminal default, it makes no sense to
> assume that the lowest common denominator is running bitbake from X...

"noop" should be the default. There is no good argument for which
terminal UI should/shouldn't be the default. Ideally I guess it would
autoselect unless the user specifies, I'll give that some thought. A
warning from sanity.bbclass about a missing command might be good too...

Cheers,

Richard




From pmiscml at gmail.com  Tue May  8 13:11:03 2007
From: pmiscml at gmail.com (Paul Sokolovsky)
Date: Tue, 8 May 2007 16:11:03 +0300
Subject: [oe] [ALERT] Security vulnerability with recent OE bitbake.conf
	changes
In-Reply-To: <1178198199.6312.30.camel@localhost.localdomain>
References: <35653307.20070503154732@gmail.com>
	<1178198199.6312.30.camel@localhost.localdomain>
Message-ID: <127969848.20070508161103@gmail.com>

Hello Richard,

Thursday, May 3, 2007, 4:16:39 PM, you wrote:

[]

> So we need to find the real problem and fix that, probably somewhere in
> patch.bbclass an error code isn't being propagated at a guess.

        Ok, so here we go: http://bugs.openembedded.org/show_bug.cgi?id=2274

> NOTE: Applying patch 'include-linux-types.patch'
> sh: line 1: gnome-terminal: command not found
> ERROR: Cannot proceed with manual patch resolution - 'gnome-terminal --disable-factory -t "$TERMWINDOWTITLE" -x bash --rcfile $TERMRCFILE' not found. Check TERMCMDRUN variable.
> ERROR: Error in executing: /home/pfalcon/linux-ppc/org.openembedded.dev/packages/dosfstools/dosfstools_2.11.bb
> ERROR: Exception:exceptions.SystemExit Message:1
> ERROR: Printing the environment of the function

Should be clear enough and helpful to whoever may enable manual mode,
but don't have a required terminal app.

> I will also hint at the use of PATCH_RESOLVER = "noop" which means the
> user gets the old behaviour of patch failure aborts the build with no
> help from any resolver. It should have always been the default but
> wasn't. I'm not sure what the current default is but we can change it to
> that if its not.

        Ok, so please review patches above, and let's make these all
changes ;-).

> Cheers,

> Richard



-- 
Best regards,
 Paul                            mailto:pmiscml at gmail.com




From papercrane at gmail.com  Tue May  8 17:35:14 2007
From: papercrane at gmail.com (Justin Patrin)
Date: Tue, 8 May 2007 10:35:14 -0700
Subject: [oe] [ALERT] Security vulnerability with recent OE bitbake.conf
	changes
In-Reply-To: <1178627405.6061.17.camel@localhost.localdomain>
References: <35653307.20070503154732@gmail.com>
	<1178198199.6312.30.camel@localhost.localdomain>
	<432beae0705062129i11f69731n1d12777f46a83316@mail.gmail.com>
	<1178627405.6061.17.camel@localhost.localdomain>
Message-ID: <432beae0705081035i1b017e3eg652644541f257bbf@mail.gmail.com>

On 5/8/07, Richard Purdie <rpurdie at rpsys.net> wrote:
> On Sun, 2007-05-06 at 21:29 -0700, Justin Patrin wrote:
> > Ummm...where? I tried that in my local.conf and it did nothing. I've
> > also grepped for PATCH_RESOLVER in both bitbake and oe and found
> > nothing.
>
> Sorry, it should be PATCHRESOLVE = "noop", my memory is playing tricks.

Ah there we go, thanks a lot. I tried grepping for gnome-terminal and
it hadn't lead me there.

>
> > Please, let's remove the gnome-terminal default, it makes no sense to
> > assume that the lowest common denominator is running bitbake from X...
>
> "noop" should be the default. There is no good argument for which
> terminal UI should/shouldn't be the default. Ideally I guess it would
> autoselect unless the user specifies, I'll give that some thought. A
> warning from sanity.bbclass about a missing command might be good too...
>

It appears not to be, however...:-|

-- 
Justin Patrin



From papercrane at gmail.com  Tue May  8 17:35:14 2007
From: papercrane at gmail.com (Justin Patrin)
Date: Tue, 8 May 2007 10:35:14 -0700
Subject: [oe] [ALERT] Security vulnerability with recent OE bitbake.conf
	changes
In-Reply-To: <1178627405.6061.17.camel@localhost.localdomain>
References: <35653307.20070503154732@gmail.com>
	<1178198199.6312.30.camel@localhost.localdomain>
	<432beae0705062129i11f69731n1d12777f46a83316@mail.gmail.com>
	<1178627405.6061.17.camel@localhost.localdomain>
Message-ID: <432beae0705081035i1b017e3eg652644541f257bbf@mail.gmail.com>

On 5/8/07, Richard Purdie <rpurdie at rpsys.net> wrote:
> On Sun, 2007-05-06 at 21:29 -0700, Justin Patrin wrote:
> > Ummm...where? I tried that in my local.conf and it did nothing. I've
> > also grepped for PATCH_RESOLVER in both bitbake and oe and found
> > nothing.
>
> Sorry, it should be PATCHRESOLVE = "noop", my memory is playing tricks.

Ah there we go, thanks a lot. I tried grepping for gnome-terminal and
it hadn't lead me there.

>
> > Please, let's remove the gnome-terminal default, it makes no sense to
> > assume that the lowest common denominator is running bitbake from X...
>
> "noop" should be the default. There is no good argument for which
> terminal UI should/shouldn't be the default. Ideally I guess it would
> autoselect unless the user specifies, I'll give that some thought. A
> warning from sanity.bbclass about a missing command might be good too...
>

It appears not to be, however...:-|

-- 
Justin Patrin



From xjqian at gmail.com  Wed May  9 02:25:00 2007
From: xjqian at gmail.com (Junqian Gordon Xu)
Date: Tue, 08 May 2007 21:25:00 -0500
Subject: [oe] QA for intentionally unpackaged files
Message-ID: <464130FC.7030008@gmail.com>

Now there is no way to distinguish if the following is intensional by 
the package maintainer or an oversight without taking a closer look at 
the contents

NOTE: the following files were installed but not shipped in any package:
NOTE:   /usr/lib/libpython2.4.so
NOTE:   /usr/lib/.debug/libpython2.4.so.1.0
NOTE:   /usr/share/man/man1/python.1
NOTE:   /usr/bin/python2.4
NOTE:   /usr/bin/smtpd.py
NOTE:   /usr/bin/.debug/python

Maybe we should have something in insane.bb to take care of the 
intentionally unpackaged crusts. So we can do something like the 
following in a bb file to intensionally leave out some garbage unpackaged:

UNSHIPPED = "${libdir}/libpython2.4.so ${bindir}/smtpd.py"  #reason why 
not package/ship it

so during do_package or package_QA, it would show as

NOTE: the following files were installed but not shipped in any package:
NOTE:   /usr/lib/libpython2.4.so   UNSHIPPED #reason why not 
packaged/ship it
NOTE:   /usr/lib/.debug/libpython2.4.so.1.0
NOTE:   /usr/share/man/man1/python.1
NOTE:   /usr/bin/python2.4
NOTE:   /usr/bin/smtpd.py  UNSHIPPED #reason why not packaged/ship it
NOTE:   /usr/bin/.debug/python

Is SUNK a better word than UNSHIPPED?

Gordon



From pmiscml at gmail.com  Wed May  9 09:38:21 2007
From: pmiscml at gmail.com (Paul Sokolovsky)
Date: Wed, 9 May 2007 12:38:21 +0300
Subject: [oe] QA for intentionally unpackaged files
In-Reply-To: <464130FC.7030008@gmail.com>
References: <464130FC.7030008@gmail.com>
Message-ID: <02827798.20070509123821@gmail.com>

Hello Junqian,

Wednesday, May 9, 2007, 5:25:00 AM, you wrote:

> Now there is no way to distinguish if the following is intensional by 
> the package maintainer or an oversight without taking a closer look at
> the contents

        So, maybe "closer look" is indeed a solution here?

> NOTE: the following files were installed but not shipped in any package:
> NOTE:   /usr/lib/libpython2.4.so
> NOTE:   /usr/lib/.debug/libpython2.4.so.1.0
> NOTE:   /usr/share/man/man1/python.1
> NOTE:   /usr/bin/python2.4
> NOTE:   /usr/bin/smtpd.py
> NOTE:   /usr/bin/.debug/python

> Maybe we should have something in insane.bb to take care of the 
> intentionally unpackaged crusts. So we can do something like the 
> following in a bb file to intensionally leave out some garbage unpackaged:

> UNSHIPPED = "${libdir}/libpython2.4.so ${bindir}/smtpd.py"  #reason why
> not package/ship it

        Who exactly will go over all recipes and add such lines?

> so during do_package or package_QA, it would show as

> NOTE: the following files were installed but not shipped in any package:
> NOTE:   /usr/lib/libpython2.4.so   UNSHIPPED #reason why not 
> packaged/ship it

        No, thanks, it likely shouldn't dump them at all then.

> NOTE:   /usr/lib/.debug/libpython2.4.so.1.0
> NOTE:   /usr/share/man/man1/python.1
> NOTE:   /usr/bin/python2.4
> NOTE:   /usr/bin/smtpd.py  UNSHIPPED #reason why not packaged/ship it
> NOTE:   /usr/bin/.debug/python

> Is SUNK a better word than UNSHIPPED?

        No.

> Gordon


-- 
Best regards,
 Paul                            mailto:pmiscml at gmail.com




From hacker at klever.net  Wed May  9 10:31:45 2007
From: hacker at klever.net (Michael Krelin)
Date: Wed, 09 May 2007 12:31:45 +0200
Subject: [oe] QA for intentionally unpackaged files
In-Reply-To: <02827798.20070509123821@gmail.com>
References: <464130FC.7030008@gmail.com> <02827798.20070509123821@gmail.com>
Message-ID: <4641A311.4030907@klever.net>

> 
>> UNSHIPPED = "${libdir}/libpython2.4.so ${bindir}/smtpd.py"  #reason why
>> not package/ship it
> 
>         Who exactly will go over all recipes and add such lines?

I take it the proposal was that package maintainers should take care of
it. Indeed, it would be better if intentionally unpackaged files invoked
no QA notice. But I think the solution is either not install them or rm
them after installation, depending on installation procedure nature.


Love,
H



From koen at dominion.kabel.utwente.nl  Wed May  9 10:42:42 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Wed, 09 May 2007 12:42:42 +0200
Subject: [oe] QA for intentionally unpackaged files
In-Reply-To: <4641A311.4030907@klever.net>
References: <464130FC.7030008@gmail.com> <02827798.20070509123821@gmail.com>
	<4641A311.4030907@klever.net>
Message-ID: <4641A5A2.8050108@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Michael Krelin schreef:
>>> UNSHIPPED = "${libdir}/libpython2.4.so ${bindir}/smtpd.py"  #reason why
>>> not package/ship it
>>         Who exactly will go over all recipes and add such lines?
> 
> I take it the proposal was that package maintainers should take care of
> it. Indeed, it would be better if intentionally unpackaged files invoked
> no QA notice. But I think the solution is either not install them or rm
> them after installation, depending on installation procedure nature.

Or we could patch package.bbclass[1] to do:

PACKAGES += "${PN}-leftovers"
FILES_${PN}-leftovers = "/"

I'm not sure if that works, but if it does, we would be able to spot leftovers more easily
by looking at deploy.

regards,

Koen

[1] this wouldn't work in bitbake.conf
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGQaWiMkyGM64RGpERAuTXAKCD+n1gXwbL7dyqru7UySv82J/CXQCgmTUM
7dYtDM79sAYQSnyDtwKmcfM=
=hEE+
-----END PGP SIGNATURE-----



From xjqian at gmail.com  Wed May  9 10:48:33 2007
From: xjqian at gmail.com (Junqian Gordon Xu)
Date: Wed, 09 May 2007 05:48:33 -0500
Subject: [oe] QA for intentionally unpackaged files
In-Reply-To: <02827798.20070509123821@gmail.com>
References: <464130FC.7030008@gmail.com> <02827798.20070509123821@gmail.com>
Message-ID: <4641A701.5000204@gmail.com>

Paul Sokolovsky wrote:
>
>         So, maybe "closer look" is indeed a solution here?
>
>   
>         Who exactly will go over all recipes and add such lines?
>
>   
>
>         No, thanks, it likely shouldn't dump them at all then.

I take it as to find an easy and uncumbersome way to take care of this. 
I don't think doing nothing at all is a good solution.

Gordon



From xjqian at gmail.com  Wed May  9 10:57:06 2007
From: xjqian at gmail.com (Junqian Gordon Xu)
Date: Wed, 09 May 2007 05:57:06 -0500
Subject: [oe] QA for intentionally unpackaged files
In-Reply-To: <4641A5A2.8050108@dominion.kabel.utwente.nl>
References: <464130FC.7030008@gmail.com>
	<02827798.20070509123821@gmail.com>	<4641A311.4030907@klever.net>
	<4641A5A2.8050108@dominion.kabel.utwente.nl>
Message-ID: <4641A902.6020506@gmail.com>

Koen Kooi wrote:
> Or we could patch package.bbclass[1] to do:
>
> PACKAGES += "${PN}-leftovers"
> FILES_${PN}-leftovers = "/"
>
> I'm not sure if that works, but if it does, we would be able to spot leftovers more easily
> by looking at deploy.

Again, how do you know which one is "intentionally" left-over vs. which 
one is not?

Gordon




From koen at dominion.kabel.utwente.nl  Wed May  9 11:26:03 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Wed, 09 May 2007 13:26:03 +0200
Subject: [oe] QA for intentionally unpackaged files
In-Reply-To: <4641A902.6020506@gmail.com>
References: <464130FC.7030008@gmail.com>	<02827798.20070509123821@gmail.com>	<4641A311.4030907@klever.net>	<4641A5A2.8050108@dominion.kabel.utwente.nl>
	<4641A902.6020506@gmail.com>
Message-ID: <4641AFCB.6080203@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Junqian Gordon Xu schreef:
> Koen Kooi wrote:
>> Or we could patch package.bbclass[1] to do:
>>
>> PACKAGES += "${PN}-leftovers"
>> FILES_${PN}-leftovers = "/"
>>
>> I'm not sure if that works, but if it does, we would be able to spot leftovers more easily
>> by looking at deploy.
> 
> Again, how do you know which one is "intentionally" left-over vs. which 
> one is not?

I can't think of a valid reason for not packaging files.

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGQa/LMkyGM64RGpERAjF7AJkBFh9SE86gjvybHZ7PRwc0+Cl2qwCcDV1h
tStk9ih9NSv558uCHvxA4G8=
=caUf
-----END PGP SIGNATURE-----



From pmiscml at gmail.com  Wed May  9 11:37:09 2007
From: pmiscml at gmail.com (Paul Sokolovsky)
Date: Wed, 9 May 2007 14:37:09 +0300
Subject: [oe] QA for intentionally unpackaged files
In-Reply-To: <4641AFCB.6080203@dominion.kabel.utwente.nl>
References: <464130FC.7030008@gmail.com> <02827798.20070509123821@gmail.com>
	<4641A311.4030907@klever.net>
	<4641A5A2.8050108@dominion.kabel.utwente.nl>
	<4641A902.6020506@gmail.com>
	<4641AFCB.6080203@dominion.kabel.utwente.nl>
Message-ID: <818235002.20070509143709@gmail.com>

Hello Koen,

Wednesday, May 9, 2007, 2:26:03 PM, you wrote:


> Junqian Gordon Xu schreef:
>> Koen Kooi wrote:
>>> Or we could patch package.bbclass[1] to do:
>>>
>>> PACKAGES += "${PN}-leftovers"
>>> FILES_${PN}-leftovers = "/"
>>>
>>> I'm not sure if that works, but if it does, we would be able to spot leftovers more easily
>>> by looking at deploy.
>> 
>> Again, how do you know which one is "intentionally" left-over vs. which 
>> one is not?

> I can't think of a valid reason for not packaging files.

        busybox doesn't package symlinks, as update-alternative
recreates them on install.


        But I agree that catch-all package is better idea than another
adhoc var. Except that we probably should add ${PN}-unshipped and
${PN}-leftovers to distinguish those intentional vs missed cases.

> regards,

> Koen

-- 
Best regards,
 Paul                            mailto:pmiscml at gmail.com




From hacker at klever.net  Wed May  9 11:43:32 2007
From: hacker at klever.net (Michael Krelin)
Date: Wed, 09 May 2007 13:43:32 +0200
Subject: [oe] QA for intentionally unpackaged files
In-Reply-To: <4641A5A2.8050108@dominion.kabel.utwente.nl>
References: <464130FC.7030008@gmail.com>
	<02827798.20070509123821@gmail.com>	<4641A311.4030907@klever.net>
	<4641A5A2.8050108@dominion.kabel.utwente.nl>
Message-ID: <4641B3E4.1020107@klever.net>

> Michael Krelin schreef:
>>>> UNSHIPPED = "${libdir}/libpython2.4.so ${bindir}/smtpd.py"  #reason why
>>>> not package/ship it
>>>         Who exactly will go over all recipes and add such lines?
>> I take it the proposal was that package maintainers should take care of
>> it. Indeed, it would be better if intentionally unpackaged files invoked
>> no QA notice. But I think the solution is either not install them or rm
>> them after installation, depending on installation procedure nature.
> 
> Or we could patch package.bbclass[1] to do:
> 
> PACKAGES += "${PN}-leftovers"
> FILES_${PN}-leftovers = "/"

I'd rather propose, indeed, packaging the intentional leftovers into a
-leftovers package manually on each package that wants leftovers. But as
you pointed out that there are no valid reasons for files to be
unpackaged, I'm sure it's possible to come up with more meaningful name
for -leftovers package in each particular case. And before files are
packaged QA notice stays QA notice, because it *is* QA issue ;-)


Love,
H



From hacker at klever.net  Wed May  9 11:51:51 2007
From: hacker at klever.net (Michael Krelin)
Date: Wed, 09 May 2007 13:51:51 +0200
Subject: [oe] QA for intentionally unpackaged files
In-Reply-To: <818235002.20070509143709@gmail.com>
References: <464130FC.7030008@gmail.com>
	<02827798.20070509123821@gmail.com>	<4641A311.4030907@klever.net>	<4641A5A2.8050108@dominion.kabel.utwente.nl>	<4641A902.6020506@gmail.com>	<4641AFCB.6080203@dominion.kabel.utwente.nl>
	<818235002.20070509143709@gmail.com>
Message-ID: <4641B5D7.2070406@klever.net>

> 
>         But I agree that catch-all package is better idea than another
> adhoc var. Except that we probably should add ${PN}-unshipped and
> ${PN}-leftovers to distinguish those intentional vs missed cases.
> 

How would any catch-all solution actually differ from disabling QA
notice? Except for that you'd be able to install these leftovers.

Love,
H



From cailotto at sci.univr.it  Wed May  9 15:59:38 2007
From: cailotto at sci.univr.it (Stefano Cailotto)
Date: Wed, 9 May 2007 17:59:38 +0200
Subject: [oe]  OE on Kontron eb425
Message-ID: <001f01c79253$0bf2c970$38f21b9d@kai>

Hello Leon, 
I've extracted kontron modifications with a diff between their shipped
kernel and a fresh one.
I don't know if it is possible to flash even the bootloader...
Looking a bit into source code, there are several kontron patches both for
drivers and kernel boot.
I'm trying to KOntron kernel into OE using Kontron toolchain, but without
success..

Hello Stefano,

On 5/4/07, Stefano Cailotto <cailotto at sci.univr.it> wrote:
> Hi all,
> I'm trying to build something usable for a kontron eb425 board, based on
an
> intel ixp425.
> I tried to compile using a generic ixp4xxbe, but when loading, the kernel
> stops after uncompressing reporting a CRC error.
> It seems that Kontron EmbeddedLinux development kit performs something on
> the kernel before making zImage in order to load it in a specifed memory
> location.
>
There are some IXP42x users on OE, mostly for the NSLU device from
Linksys/Cisco, the Intel dev board (IXDP425) and some custom boards,
but I have not see the Kontron board yet.

With the reported problem, it would help if you understand or at least
could tell where to find the details on the boot loader.

Ideally, you would want to boot loader to be buildable from source
instead of relying on some binary on flash.

Regards,

Leon.

---------------------------------------------------------------------------
  Stefano Cailotto - Research Consultant
---------------------------------------------------------------------------
  EDALab - Networked Embedded Systems
  c/o  Dipartimento di Informatica - Universita` di Verona
  Strada le Grazie, 15 - 37134 Verona (Italy)
---------------------------------------------------------------------------
  email: cailotto at sci.univr.it stefano.cailotto at edalab.it      
  web:  http://www.edalab.it
  tel: +39-045-802-7062 fax: +39-045-802-7068
---------------------------------------------------------------------------




From rodrigo.vivi at gmail.com  Wed May  9 19:44:09 2007
From: rodrigo.vivi at gmail.com (Rodrigo Vivi)
Date: Wed, 9 May 2007 16:44:09 -0300
Subject: [oe] generating debian source packages (dsc)
In-Reply-To: <432beae0705021338x7ca36c0oc937a6b1b03f6db5@mail.gmail.com>
References: <bdb0025f0705021104x23d2c407rb4da0e48e24eb911@mail.gmail.com>
	<200705022051.03720.openembedded@hrw.one.pl>
	<bdb0025f0705021252w7e32b305ybf9c914c1cb1edc0@mail.gmail.com>
	<432beae0705021338x7ca36c0oc937a6b1b03f6db5@mail.gmail.com>
Message-ID: <bdb0025f0705091244u19ce0129h957f9c34154454f0@mail.gmail.com>

I'm trying to use inherit sourcepkg without success.
Does anybody has any suggestion about the following error?

NOTE: package shasum-native-1.0: started
NOTE: package shasum-native-1.0-r1: task do_create_orig_tgz: started
NOTE: <type 'exceptions.IndexError'>:list index out of range while evaluating:

        mkdir -p /indt/mamona/openembedded/tmp/deploy/source
        cd /indt/mamona/openembedded/tmp/work/shasum-native-1.0-r1
        for i in .pc autom4te.cache; do
                echo $i >> temp/exclude-from-file
        done

        src_tree=${@get_src_tree(d)}

        echo $src_tree
        oenote "Creating .orig.tar.gz in
/indt/mamona/openembedded/tmp/deploy/source/shasum-native-1.0.orig.tar.gz"
        tar cvzf
/indt/mamona/openembedded/tmp/deploy/source/shasum-native-1.0.orig.tar.gz
--exclude-from temp/exclude-from-file $src_tree
        cp -pPR $src_tree $src_tree.orig

NOTE: <type 'exceptions.IndexError'>:list index out of range while evaluating:

        cd /indt/mamona/openembedded/tmp/work/shasum-native-1.0-r1
        for i in .pc autom4te.cache; do
                echo $i >> temp/exclude-from-file
        done


        src_tree=${@get_src_tree(d)}

        for i in `find . -maxdepth 1 -type f`; do
                mkdir -p $src_tree/mamona/files
                cp $i $src_tree/mamona/files
        done

        oenote "Creating .diff.gz in
/indt/mamona/openembedded/tmp/deploy/source/shasum-native-1.0-r1.diff.gz"
        LC_ALL=C TZ=UTC0 diff --exclude-from=temp/exclude-from-file
-Naur $src_tree.orig $src_tree | gzip -c >
/indt/mamona/openembedded/tmp/deploy/source/shasum-native-1.0-r1.diff.gz
        rm -rf $src_tree.orig

NOTE: <type 'exceptions.IndexError'>:list index out of range while evaluating:

        src_tree=${@get_src_tree(d)}
        dest=/indt/mamona/openembedded/tmp/work/shasum-native-1.0-r1/$src_tree/mamona
        mkdir -p $dest

        cp /indt/mamona/openembedded/org.openembedded.dev/packages/shasum/shasum-native.bb
$dest

ERROR: function do_create_orig_tgz failed
ERROR: log data follows
(/indt/mamona/openembedded/tmp/work/shasum-native-1.0-r1/temp/log.do_create_orig_tgz.6911)
| /indt/mamona/openembedded/tmp/work/shasum-native-1.0-r1/temp/run.do_create_orig_tgz.6911:
line 510: sourcepkg_do_create_orig_tgz: command not found
NOTE: Task failed:
/indt/mamona/openembedded/tmp/work/shasum-native-1.0-r1/temp/log.do_create_orig_tgz.6911
NOTE: package shasum-native-1.0-r1: task do_create_orig_tgz: failed
ERROR: TaskFailed event exception, aborting
NOTE: package shasum-native-1.0: failed


On 5/2/07, Justin Patrin <papercrane at gmail.com> wrote:
> On 5/2/07, Rodrigo Vivi <rodrigo.vivi at gmail.com> wrote:
> > > classes/sourcepkg.bbclass is something which you want to extend
> >
> > I've thought about it but I'm not sure that it is a good idea because
> > just few projects (or just mine) needs the dsc file .......... unless
> > that I code another sourcedsc.bbclass that inherit the
> > sourcedpkg.bbclass... o you think that it will work???  I'll think
> > about it...
> >
>
> Yes, this is what Marcin meant. Create your own sourcedsc.bbclass
> which inherits sourcepkg.bbclass. This is how, for example,
> efl.bbclass and e.bbclass work.
>
> > Another doubt that I forgot to mention on last email is about changelog:
> > I'm generating a almost empty changelog file. Is there any official
> > and/or more appropriated way to do that?
> >
> > Thanks,
> > Vivi.
> >
> > >
> > > --
> > > JID: hrw-jabber.org
> > > OpenEmbedded developer/consultant
> > >
> > >       I'm trying to decide if I should kill you or simply feign death
> > >       until you feel awkward and leave.
> > >
> > >
> > >
> > > _______________________________________________
> > > Openembedded-devel mailing list
> > > Openembedded-devel at lists.openembedded.org
> > > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> > >
> >
> > _______________________________________________
> > Openembedded-devel mailing list
> > Openembedded-devel at lists.openembedded.org
> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> >
>
>
> --
> Justin Patrin
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>



From pmiscml at gmail.com  Thu May 10 15:00:54 2007
From: pmiscml at gmail.com (Paul Sokolovsky)
Date: Thu, 10 May 2007 18:00:54 +0300
Subject: [oe] Making /var/lib persistent
In-Reply-To: <20070419014949.GA6540@twibble.org>
References: <1176760923.4623f25b913f9@dominion.kabel.utwente.nl>
	<20070418090235.GA21841@twibble.org>
	<46262A0F.1050805@dominion.kabel.utwente.nl>
	<20070419014949.GA6540@twibble.org>
Message-ID: <31583224.20070510180054@gmail.com>

Hello Jamie,

Thursday, April 19, 2007, 4:49:50 AM, you wrote:

> On Wed, Apr 18, 2007 at 07:24:15AM -0700, Koen Kooi wrote:
> [...]
>> Sound like a good idea, do you have a patch for this?

> Try this out:

>   http://twibble.org/dist/oe/var-volatiles-1.patch

> I've tested it locally both with and without tmpfs mounted on
> /var/volatile and all seems to work as expected.

        Any news on this? I've been running with this patch soon since
its original post and don't see any issues. One small nuisance is that
ls -l /var/log doesn't show what you want, but hardly something can be
done about that, plus shell completion uses /var/log/ immediately.

        I suggest committing this patch.

[]

-- 
Best regards,
 Paul                            mailto:pmiscml at gmail.com




From koen at dominion.kabel.utwente.nl  Thu May 10 19:23:30 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Thu, 10 May 2007 21:23:30 +0200
Subject: [oe] Making /var/lib persistent
In-Reply-To: <31583224.20070510180054@gmail.com>
References: <1176760923.4623f25b913f9@dominion.kabel.utwente.nl>	<20070418090235.GA21841@twibble.org>	<46262A0F.1050805@dominion.kabel.utwente.nl>	<20070419014949.GA6540@twibble.org>
	<31583224.20070510180054@gmail.com>
Message-ID: <46437132.1060303@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Paul Sokolovsky schreef:
> Hello Jamie,
> 
> Thursday, April 19, 2007, 4:49:50 AM, you wrote:
> 
>> On Wed, Apr 18, 2007 at 07:24:15AM -0700, Koen Kooi wrote:
>> [...]
>>> Sound like a good idea, do you have a patch for this?
> 
>> Try this out:
> 
>>   http://twibble.org/dist/oe/var-volatiles-1.patch
> 
>> I've tested it locally both with and without tmpfs mounted on
>> /var/volatile and all seems to work as expected.
> 
>         Any news on this? I've been running with this patch soon since
> its original post and don't see any issues. One small nuisance is that
> ls -l /var/log doesn't show what you want, but hardly something can be
> done about that, plus shell completion uses /var/log/ immediately.
> 
>         I suggest committing this patch.

same here.

regards,

Koen

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGQ3EyMkyGM64RGpERAoBNAJ4uabEzcebJd5+x/dtQAKTfYMI8oQCgrza3
buax9m6pqJ+/DZfchJcjlvA=
=hzmX
-----END PGP SIGNATURE-----



From rpurdie at rpsys.net  Thu May 10 23:06:11 2007
From: rpurdie at rpsys.net (Richard Purdie)
Date: Fri, 11 May 2007 00:06:11 +0100
Subject: [oe] Making /var/lib persistent
In-Reply-To: <31583224.20070510180054@gmail.com>
References: <1176760923.4623f25b913f9@dominion.kabel.utwente.nl>
	<20070418090235.GA21841@twibble.org>
	<46262A0F.1050805@dominion.kabel.utwente.nl>
	<20070419014949.GA6540@twibble.org> <31583224.20070510180054@gmail.com>
Message-ID: <1178838371.20362.2.camel@localhost.localdomain>

On Thu, 2007-05-10 at 18:00 +0300, Paul Sokolovsky wrote:
> Hello Jamie,
> 
> Thursday, April 19, 2007, 4:49:50 AM, you wrote:
> 
> > On Wed, Apr 18, 2007 at 07:24:15AM -0700, Koen Kooi wrote:
> > [...]
> >> Sound like a good idea, do you have a patch for this?
> 
> > Try this out:
> 
> >   http://twibble.org/dist/oe/var-volatiles-1.patch
> 
> > I've tested it locally both with and without tmpfs mounted on
> > /var/volatile and all seems to work as expected.
> 
>         Any news on this? I've been running with this patch soon since
> its original post and don't see any issues. One small nuisance is that
> ls -l /var/log doesn't show what you want, but hardly something can be
> done about that, plus shell completion uses /var/log/ immediately.
> 
>         I suggest committing this patch.

The idea sounded sane to me when I read about it so if its working, I
say go for it...

Cheers,

Richard




From pmiscml at gmail.com  Fri May 11 17:00:05 2007
From: pmiscml at gmail.com (Paul Sokolovsky)
Date: Fri, 11 May 2007 20:00:05 +0300
Subject: [oe] [ALERT] Security vulnerability with recent OE bitbake.conf
	changes
In-Reply-To: <127969848.20070508161103@gmail.com>
References: <35653307.20070503154732@gmail.com>
	<1178198199.6312.30.camel@localhost.localdomain>
	<127969848.20070508161103@gmail.com>
Message-ID: <1353801661.20070511200005@gmail.com>

Hello,

Tuesday, May 8, 2007, 4:11:03 PM:

> Hello Richard,

> Thursday, May 3, 2007, 4:16:39 PM, you wrote:

> []

>> So we need to find the real problem and fix that, probably somewhere in
>> patch.bbclass an error code isn't being propagated at a guess.

>         Ok, so here we go:
> http://bugs.openembedded.org/show_bug.cgi?id=2274

        This was committed, as well as PATCHRESOLVE set to "noop" by
default.

[]

-- 
Best regards,
 Paul                            mailto:pmiscml at gmail.com




From tom at openhardware.net  Fri May 11 17:45:47 2007
From: tom at openhardware.net (Tom Walsh)
Date: Fri, 11 May 2007 13:45:47 -0400
Subject: [oe] do_rootfs fails
Message-ID: <4644ABCB.6080202@openhardware.net>

Ok, I admit it, I am totally confused by this whole "debian", 
"multimachine", "package_ipk" stuff.  I've been able to avoid 
understanding this and think that this might be why bootstrap.image 
won't build a filesystem image.

Prior to a month ago, I was using my own task + image bb files to build 
my image.  Since a lot of work has been done to make the task-base more 
generic, I have moved my project over to using the stock 
bootstrap-image.bb and task-base.bb files.  However, it fails to build 
properly.

When running a "bitbake bootstrap-image", everything builds but then 
fails with:

========= begin ============
[tom at jtag oezipit]$ bitbake bootstrap-image
NOTE: Using cache in '/home/tom/oezipit/tmp/cache/zipit'
NOTE: Handling BitBake files: \ (4534/4534) [100 %]
NOTE: Parsing finished. 4329 cached, 0 parsed, 205 skipped, 0 masked.

NOTE: build 200705111324: started

OE Build Configuration:
BB_VERSION     = "1.6.7"
OE_REVISION    = "<unknown>"
TARGET_ARCH    = "arm"
TARGET_OS      = "linux"
MACHINE        = "zipit"
DISTRO         = "zipit"
DISTRO_VERSION = "1.0"
TARGET_FPU     = "soft"

NOTE: multiple providers are available (db3, db);
NOTE: consider defining PREFERRED_PROVIDER_virtual/db
NOTE: multiple providers are available (db3-native, db-native);
NOTE: consider defining PREFERRED_PROVIDER_virtual/db-native
NOTE: package bootstrap-image-1.0: started
NOTE: package bootstrap-image-1.0-r0: task do_rootfs: started
ERROR: function do_rootfs failed
ERROR: see log in 
/home/tom/oezipit/tmp/work/zipit-linux/bootstrap-image-1.0-r0/temp/log.do_rootfs.17150
NOTE: Task failed: 
/home/tom/oezipit/tmp/work/zipit-linux/bootstrap-image-1.0-r0/temp/log.do_rootfs.17150
NOTE: package bootstrap-image-1.0-r0: task do_rootfs: failed
ERROR: TaskFailed event exception, aborting
NOTE: package bootstrap-image-1.0: failed
ERROR: Build of bootstrap-image failed
========= snip =============

When I check the logfile, it says that "sh: fakeroot: command not 
found".  This is correct, fakeroot-native has NOT been built.  So, I do 
a "bitbake -c rebuild fakeroot-native", then run "bitbake 
bootstrap-image" again.

It then fails with a logfile message of 
"/home/tom/oezipit/tmp/work/zipit-linux/bootstrap-image-1.0-r0/temp/run.do_rootfs.24175: 
line 312: ipkg-cl: command not found".  Again, this is true, ipkg-native 
is not present.  So, I do a "bitbake -c rebuild ipkg-native", then run 
"bitbake bootstrap-image" again.

Now it builds the filesystem target tarball image.

How can I automate those needs for fakeroot-native and ipkg-native?  I'm 
not sure where to look, this was working a few weeks ago.

Regards,

TomW





-- 
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net http://cyberiansoftware.com http://openzipit.org
"Windows? No thanks, I have work to do..."
----------------------------------------------------





From koen at dominion.kabel.utwente.nl  Fri May 11 18:07:14 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Fri, 11 May 2007 20:07:14 +0200
Subject: [oe] do_rootfs fails
In-Reply-To: <4644ABCB.6080202@openhardware.net>
References: <4644ABCB.6080202@openhardware.net>
Message-ID: <4644B0D2.8020409@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tom Walsh schreef:

<snip problem description>

> OE Build Configuration:
> BB_VERSION     = "1.6.7"

Tom: Upgrade to 1.8.2 or use the bitbake-1.8 branch (1.8.3 atm).
All: Are we still going to wait 1.5 months with requiring 1.8.x? I've seen enough proof
that 1.6.x is broken with current .dev, with no effort to fix it. "Giving people time to
prepare the upgrade" has now turned into "Stabbing user in the eye" :(

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGRLDRMkyGM64RGpERAm1ZAKCBtqmqLrk3MXEPldP9AvEjxxJSsACggk//
FJLY3HdrD/EF2xvBzEOJvts=
=qgbE
-----END PGP SIGNATURE-----



From hacker at klever.net  Fri May 11 18:24:17 2007
From: hacker at klever.net (Michael Krelin)
Date: Fri, 11 May 2007 20:24:17 +0200
Subject: [oe] do_rootfs fails
In-Reply-To: <4644B0D2.8020409@dominion.kabel.utwente.nl>
References: <4644ABCB.6080202@openhardware.net>
	<4644B0D2.8020409@dominion.kabel.utwente.nl>
Message-ID: <4644B4D1.5010803@klever.net>

> All: Are we still going to wait 1.5 months with requiring 1.8.x? I've seen enough proof
> that 1.6.x is broken with current .dev, with no effort to fix it. "Giving people time to
> prepare the upgrade" has now turned into "Stabbing user in the eye" :(

There's also an option of asking Tom to bitbake -DDD and send it to
zecke, because I couldn't find time to try BB 1.6 for him again. And let
him apply the patch that fixes this problem:

Index: lib/bb/parse/parse_py/BBHandler.py
===================================================================
--- lib/bb/parse/parse_py/BBHandler.py  (revision 817)
+++ lib/bb/parse/parse_py/BBHandler.py  (working copy)
@@ -66,7 +66,9 @@
         if not file in __inherit_cache.split():
             debug(2, "BB %s:%d: inheriting %s" % (fn, lineno, file))
             __inherit_cache += " %s" % file
+            data.setVar('__inherit_cache', __inherit_cache, d)
             include(fn, file, d)
+            __inherit_cache = data.getVar('__inherit_cache', d) or ""
     data.setVar('__inherit_cache', __inherit_cache, d)

Love,
H



From oe at hentges.net  Sat May 12 00:07:53 2007
From: oe at hentges.net (Matthias Hentges)
Date: Sat, 12 May 2007 02:07:53 +0200
Subject: [oe] do_rootfs fails
In-Reply-To: <4644B0D2.8020409@dominion.kabel.utwente.nl>
References: <4644ABCB.6080202@openhardware.net>
	<4644B0D2.8020409@dominion.kabel.utwente.nl>
Message-ID: <1178928474.4954.18.camel@localhost.localdomain>

Am Freitag, den 11.05.2007, 20:07 +0200 schrieb Koen Kooi:

> All: Are we still going to wait 1.5 months with requiring 1.8.x? I've seen enough proof
> that 1.6.x is broken with current .dev, with no effort to fix it. "Giving people time to
> prepare the upgrade" has now turned into "Stabbing user in the eye" :(
> 
> regards,
> 
> Koen

1.8.x has a show-stopper freeze-bug for some users ( including myself )
which has not been fixed or even looked into yet.

-- 
Matthias 'CoreDump' Hentges 
Cologne / Germany

Webmaster of Hentges.net & Embedded Linux Developer
GPG ->  gpg --keyserver gpg-keyserver.de --recv-keys 0xAF3030D9

My OS: Debian SID: Geek by Nature, Linux by Choice


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
URL: <http://lists.openembedded.org/pipermail/openembedded-devel/attachments/20070512/d00d0d5a/attachment-0002.sig>

From koen at dominion.kabel.utwente.nl  Sat May 12 10:28:21 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Sat, 12 May 2007 12:28:21 +0200
Subject: [oe] do_rootfs fails
In-Reply-To: <1178928474.4954.18.camel@localhost.localdomain>
References: <4644ABCB.6080202@openhardware.net>	<4644B0D2.8020409@dominion.kabel.utwente.nl>
	<1178928474.4954.18.camel@localhost.localdomain>
Message-ID: <464596C5.8010303@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Matthias Hentges schreef:
> Am Freitag, den 11.05.2007, 20:07 +0200 schrieb Koen Kooi:
> 
>> All: Are we still going to wait 1.5 months with requiring 1.8.x? I've seen enough proof
>> that 1.6.x is broken with current .dev, with no effort to fix it. "Giving people time to
>> prepare the upgrade" has now turned into "Stabbing user in the eye" :(
>>
>> regards,
>>
>> Koen
> 
> 1.8.x has a show-stopper freeze-bug for some users ( including myself )
> which has not been fixed or even looked into yet.

bugnumber?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGRZbFMkyGM64RGpERAlj8AJ9RQ0xtk2nqZAlJloTFFM5j8ml2zACghM87
qvk0yLeJrlqNyZHCtfub4Xo=
=Z1MH
-----END PGP SIGNATURE-----



From koen at dominion.kabel.utwente.nl  Sat May 12 19:21:23 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Sat, 12 May 2007 21:21:23 +0200
Subject: [oe] uclibc 0.9.29 recipe
Message-ID: <464613B3.8090003@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,


I just started working on a uclibc 0.9.29 recipe, are people interested in it already, or
should I finish it before committing it (with DEFAULT_PREF = -1)?

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGRhOzMkyGM64RGpERAlBJAKC4Hekdx6iKB95Nglwt4elr/scvqQCggdgo
b0a0iWs5X06ZAMKRzYUfKlg=
=S7Cp
-----END PGP SIGNATURE-----



From lpotter at trolltech.com  Sat May 12 19:54:27 2007
From: lpotter at trolltech.com (Lorn Potter)
Date: Sun, 13 May 2007 05:54:27 +1000
Subject: [oe] uclibc 0.9.29 recipe
In-Reply-To: <464613B3.8090003@dominion.kabel.utwente.nl>
References: <464613B3.8090003@dominion.kabel.utwente.nl>
Message-ID: <46461B73.8070900@trolltech.com>



Koen Kooi wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi,
> 
> 
> I just started working on a uclibc 0.9.29 recipe, are people interested in it already, or
> should I finish it before committing it (with DEFAULT_PREF = -1)?
> 
> regards,

I would be, especially if it worked in an angstrom build.



-- 
Lorn 'ljp' Potter
Software Engineer, Systems Group, MES, Trolltech



From lpotter at trolltech.com  Sat May 12 19:54:27 2007
From: lpotter at trolltech.com (Lorn Potter)
Date: Sun, 13 May 2007 05:54:27 +1000
Subject: [oe] uclibc 0.9.29 recipe
In-Reply-To: <464613B3.8090003@dominion.kabel.utwente.nl>
References: <464613B3.8090003@dominion.kabel.utwente.nl>
Message-ID: <46461B73.8070900@trolltech.com>



Koen Kooi wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi,
> 
> 
> I just started working on a uclibc 0.9.29 recipe, are people interested in it already, or
> should I finish it before committing it (with DEFAULT_PREF = -1)?
> 
> regards,

I would be, especially if it worked in an angstrom build.



-- 
Lorn 'ljp' Potter
Software Engineer, Systems Group, MES, Trolltech



From koen at dominion.kabel.utwente.nl  Sat May 12 20:02:58 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Sat, 12 May 2007 22:02:58 +0200
Subject: [oe] uclibc 0.9.29 recipe
In-Reply-To: <46461B73.8070900@trolltech.com>
References: <464613B3.8090003@dominion.kabel.utwente.nl>
	<46461B73.8070900@trolltech.com>
Message-ID: <46461D72.4020206@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Lorn Potter schreef:
> 
> Koen Kooi wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Hi,
>>
>>
>> I just started working on a uclibc 0.9.29 recipe, are people interested in it already, or
>> should I finish it before committing it (with DEFAULT_PREF = -1)?
>>
>> regards,
> 
> I would be, especially if it worked in an angstrom build.

I'll add it once I solved the linux-libc-headers problems. Machine and distro maintainers
need to provide their parts of the uclibc configs to make it usefull, though.

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGRh1yMkyGM64RGpERApzPAJ9dHfEynAkjYtpvJC6aKwcSLcF1PQCggceU
2wDlG7EN1RNSwOJ8YjfCItk=
=Un//
-----END PGP SIGNATURE-----



From koen at dominion.kabel.utwente.nl  Sat May 12 21:04:29 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Sat, 12 May 2007 23:04:29 +0200
Subject: [oe] uclibc 0.9.29 recipe
In-Reply-To: <46461D72.4020206@dominion.kabel.utwente.nl>
References: <464613B3.8090003@dominion.kabel.utwente.nl>	<46461B73.8070900@trolltech.com>
	<46461D72.4020206@dominion.kabel.utwente.nl>
Message-ID: <46462BDD.6000302@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Koen Kooi schreef:
> Lorn Potter schreef:
>> Koen Kooi wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> Hi,
>>>
>>>
>>> I just started working on a uclibc 0.9.29 recipe, are people interested in it already, or
>>> should I finish it before committing it (with DEFAULT_PREF = -1)?
>>>
>>> regards,
>> I would be, especially if it worked in an angstrom build.
> 
> I'll add it once I solved the linux-libc-headers problems. 

Which is non-existant on 0.9.29 :)


> Machine and distro maintainers
> need to provide their parts of the uclibc configs to make it usefull, though.

Angstrom has a uClibc.distro and ixp4xxbe has a uClibc.machine.

To add support for your favourite machine: use uClibc.distro as .config, configure uclibc
for the target you want, save the top 2 blocks of .config (cpu and arch) to uClibc.distro
in uclibc-0.9.29/<machine/uClibc.machine

The recipe is by no means perfect, so any help is welcome.

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGRivdMkyGM64RGpERAoVVAKCCVsINF5WmH0XnnbpCF0oMo15sfACePayI
7vnmpum3r/QkizvA4HinAzc=
=R235
-----END PGP SIGNATURE-----



From skoroneos at digital-opsis.com  Sat May 12 21:19:03 2007
From: skoroneos at digital-opsis.com (Stelios Koroneos)
Date: Sun, 13 May 2007 00:19:03 +0300
Subject: [oe] minimal-image.bb
In-Reply-To: <46461D72.4020206@dominion.kabel.utwente.nl>
Message-ID: <HOECLKEKOHLAMMGDLLBHOECKLAAA.skoroneos@digital-opsis.com>

Greetings to all !

Recently it was made apparent that bootstrap-image was generating images
that could not fit in flash restricted devices (<=4MB)
Koen has pushed angstrom-minimal-image which uses task-boot and as a result
generates images significally smaller.(800K in a jffs2 fs)

The only drawback into this (IMHO) is in the naming of the package.
Adding a distro name infront of an image package gives the impression that
this is distro specific and not a "generic" one.
I tried to push to the rep a more "generic" minimal-image.bb which was
almost identical to angstrom-minima-image but Koen had  dis-approved the
commit as duplicate.

In my opinion if angstrom-minimal-image is not distro specific should be
renamed to minimal-image or if it is distro specific a minimal-image.bb
should be created.

I discussed the matter with Koen on irc but we could not come to a
conlusion, so i am asking for the opinions of others on this, as i believe
is a issue which has to be solved to avoid any future problems.



Stelios S. Koroneos

Digital OPSiS - Embedded Intelligence
http://www.digital-opsis.com







From skoroneos at digital-opsis.com  Sat May 12 21:33:31 2007
From: skoroneos at digital-opsis.com (Stelios Koroneos)
Date: Sun, 13 May 2007 00:33:31 +0300
Subject: [oe] do_rootfs fails
In-Reply-To: <4644B4D1.5010803@klever.net>
Message-ID: <HOECLKEKOHLAMMGDLLBHOECLLAAA.skoroneos@digital-opsis.com>

Had the same problem as i am still using 1.6 .
The mentioned patch solved it

Stelios S. Koroneos

Digital OPSiS - Embedded Intelligence
http://www.digital-opsis.com


> -----Original Message-----
> From: openembedded-devel-bounces at openembedded.org 
> [mailto:openembedded-devel-bounces at openembedded.org]On Behalf Of 
> Michael Krelin
> Sent: Friday, May 11, 2007 9:24 PM
> To: openembedded-devel at openembedded.org
> Subject: Re: [oe] do_rootfs fails
> 
> 
> > All: Are we still going to wait 1.5 months with requiring 
> 1.8.x? I've seen enough proof
> > that 1.6.x is broken with current .dev, with no effort to fix 
> it. "Giving people time to
> > prepare the upgrade" has now turned into "Stabbing user in the eye" :(
> 
> There's also an option of asking Tom to bitbake -DDD and send it to
> zecke, because I couldn't find time to try BB 1.6 for him again. And let
> him apply the patch that fixes this problem:
> 
> Index: lib/bb/parse/parse_py/BBHandler.py
> ===================================================================
> --- lib/bb/parse/parse_py/BBHandler.py  (revision 817)
> +++ lib/bb/parse/parse_py/BBHandler.py  (working copy)
> @@ -66,7 +66,9 @@
>          if not file in __inherit_cache.split():
>              debug(2, "BB %s:%d: inheriting %s" % (fn, lineno, file))
>              __inherit_cache += " %s" % file
> +            data.setVar('__inherit_cache', __inherit_cache, d)
>              include(fn, file, d)
> +            __inherit_cache = data.getVar('__inherit_cache', d) or ""
>      data.setVar('__inherit_cache', __inherit_cache, d)
> 
> Love,
> H
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> 




From dp at xora.org.uk  Sun May 13 12:25:49 2007
From: dp at xora.org.uk (Graeme Gregory)
Date: Sun, 13 May 2007 13:25:49 +0100
Subject: [oe] RFC: Bugzilla CC Field
Message-ID: <1179059149.5404.3.camel@cimmeria.hyboria>

RFC

Dont add people to CC field of bugs without talking to them.

Recently I am finding myself added as CC to bugs I have no interest in
as I either don't have the hardware or don't use the software in
question.

Everyone on oe-issues list gets all bug reports anyway and I can use web
search quite effectively myself.

Graeme (XorA)





From koen at dominion.kabel.utwente.nl  Sun May 13 14:29:35 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Sun, 13 May 2007 16:29:35 +0200
Subject: [oe] RFC: Bugzilla CC Field
In-Reply-To: <1179059149.5404.3.camel@cimmeria.hyboria>
References: <1179059149.5404.3.camel@cimmeria.hyboria>
Message-ID: <464720CF.4030801@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Graeme Gregory schreef:
> RFC
> 
> Dont add people to CC field of bugs without talking to them.
> 
> Recently I am finding myself added as CC to bugs I have no interest in
> as I either don't have the hardware or don't use the software in
> question.
> 
> Everyone on oe-issues list gets all bug reports anyway and I can use web
> search quite effectively myself.

Same here, and I was suggested to just turn off all email in the bugzilla userprefs.

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGRyDPMkyGM64RGpERAmzyAJ4lfF/HAeoRx0k/Kn+jXme1ed8xOwCdGr+V
yEXpOXkev8SZFGHcxLqP5pw=
=bROF
-----END PGP SIGNATURE-----



From no2spam at nospam.arcornews.de  Sun May 13 14:33:06 2007
From: no2spam at nospam.arcornews.de (Rolf Leggewie)
Date: Sun, 13 May 2007 16:33:06 +0200
Subject: [oe] RFD: Bugzilla in general & bug triaging
In-Reply-To: <1179059149.5404.3.camel@cimmeria.hyboria>
References: <1179059149.5404.3.camel@cimmeria.hyboria>
Message-ID: <f277j3$i00$1@sea.gmane.org>

Graeme Gregory wrote:
> RFC
> 
> Dont add people to CC field of bugs without talking to them.

Thank you Graeme for raising this issue.  It is something I meant to 
discuss earlier but never found enough time to think it through and 
write up something.  I still have not thought it through, but here it goes.

Let me first say, that I am totally aware that we are all doing this in 
our limited free time.  We also all don't like things being stuffed down 
our throat.  There is a bit of dilemma here.

As a non-dev, I feel one of the better ways for me and others alike is 
to make sure the BTS is in good shape.  It is called bug triaging which 
I also do in other projects.  For me, this is all about efficiency, 
division of labor so to speak (although that capitalistic thinking might 
not go down too well with all of us freeminds ;-))  The idea is that 
there is someone who sifts through the bug reports and makes sure they 
are understandable, complete and real.  The triager also crosslinks bugs 
that share similarities and classifies them.   All this *before they eat 
up valuable time from a real dev*.  That is at least what I am trying to 
do, for the devs to sit down and find well-structured problems to work 
on whenever they feel like it (I know the OE BTS is not there yet, bug 
2194 is a shy start at this).

This is how Ubuntu and Mozilla approach the bugs they receive.  But it 
needs a way to signal "Hey, this bug is OK" and furthermore bugs are 
usually assigned to the most appropriate person.  So that is what I did 
first, assign bugs to the people I thought would be most appropriate in 
dealing with them.  That did not go down so well :-)  So, it was 
suggested to me that instead of assigning, I should cc people.  But that 
is certainly not the best solution, either.

I believe it would be great if OE started some kind of not too rigid 
process of triaging bugs.  All projects are a bit different, so what do 
you think would be the best way for OE to handle this?

 > Everyone on oe-issues list gets all bug reports anyway and I can use
 > web search quite effectively myself.

Graeme, I understand your concern.  I don't mean to say "Hey, here is 
the solution" but maybe there are some options you might consider.

First is that I would think that it might be a waste of valuable dev 
time if all core devs read all bug reports on oe-issues.  Of course, 
that is an individual decision.  But if we got something like bug 
triaging going in a more instituationalized way, it might indeed become 
unnecessary.  Second, bugzilla offers many settings on what mails you 
want to receive and which you don't at 
http://bugs.openembedded.org/userprefs.cgi?tab=email.  If you read 
oe-issues, you might want to consider deactivating all mail from 
bugzilla itself to keep the load down.




From no2spam at nospam.arcornews.de  Sun May 13 14:35:12 2007
From: no2spam at nospam.arcornews.de (Rolf Leggewie)
Date: Sun, 13 May 2007 16:35:12 +0200
Subject: [oe] minimal-image.bb
In-Reply-To: <HOECLKEKOHLAMMGDLLBHOECKLAAA.skoroneos@digital-opsis.com>
References: <46461D72.4020206@dominion.kabel.utwente.nl>
	<HOECLKEKOHLAMMGDLLBHOECKLAAA.skoroneos@digital-opsis.com>
Message-ID: <f277n0$i00$2@sea.gmane.org>

Stelios Koroneos wrote:
> In my opinion if angstrom-minimal-image is not distro specific should be
> renamed to minimal-image

I agree with Stelios that the belief that angstrom-minimal-image is a 
distro-specific image is a reasonable assumption.  If that is not the 
case, I am in favor renaming.




From koen at dominion.kabel.utwente.nl  Sun May 13 15:02:17 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Sun, 13 May 2007 17:02:17 +0200
Subject: [oe] RFD: Bugzilla in general & bug triaging
In-Reply-To: <f277j3$i00$1@sea.gmane.org>
References: <1179059149.5404.3.camel@cimmeria.hyboria>
	<f277j3$i00$1@sea.gmane.org>
Message-ID: <46472879.7070804@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Rolf Leggewie schreef:

> First is that I would think that it might be a waste of valuable dev 
> time if all core devs read all bug reports on oe-issues. 

Personally, I treat oe-issues the same as oe-commits, by just skimming through the
subjects and reading ones that trigger some sort of red flag.

regards,

Koen

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGRyh5MkyGM64RGpERAih1AKCSCjkbNYMQKvz5uGBlSC4kJUFCuwCdH/ZS
dxXPFRHDlbpXplCWROFMuN8=
=rrgr
-----END PGP SIGNATURE-----



From pmiscml at gmail.com  Sun May 13 15:15:30 2007
From: pmiscml at gmail.com (Paul Sokolovsky)
Date: Sun, 13 May 2007 18:15:30 +0300
Subject: [oe] RFD: Bugzilla in general & bug triaging
In-Reply-To: <f277j3$i00$1@sea.gmane.org>
References: <1179059149.5404.3.camel@cimmeria.hyboria>
	<f277j3$i00$1@sea.gmane.org>
Message-ID: <419056356.20070513181530@gmail.com>

Hello Rolf,

Sunday, May 13, 2007, 5:33:06 PM, you wrote:

> Graeme Gregory wrote:
>> RFC
>> 
>> Dont add people to CC field of bugs without talking to them.

> Thank you Graeme for raising this issue.  It is something I meant to 
> discuss earlier but never found enough time to think it through and 
> write up something.  I still have not thought it through, but here it goes.

> Let me first say, that I am totally aware that we are all doing this in
> our limited free time.  We also all don't like things being stuffed down
> our throat.  There is a bit of dilemma here.

> As a non-dev, I feel one of the better ways for me and others alike is
> to make sure the BTS is in good shape.  It is called bug triaging which
> I also do in other projects.  For me, this is all about efficiency, 
> division of labor so to speak (although that capitalistic thinking might
> not go down too well with all of us freeminds ;-))  The idea is that 
> there is someone who sifts through the bug reports and makes sure they
> are understandable, complete and real.  The triager also crosslinks bugs
> that share similarities and classifies them.   All this *before they eat
> up valuable time from a real dev*.  That is at least what I am trying to
> do, for the devs to sit down and find well-structured problems to work
> on whenever they feel like it (I know the OE BTS is not there yet, bug
> 2194 is a shy start at this).

        I'm sure that I can speak from many peoples' side: your work
and effort on bug management is *much* appreciated. Thanks to you, we
now have *live* bugtracker, not a swamp, which it was just few months
ago.

> This is how Ubuntu and Mozilla approach the bugs they receive.  But it
> needs a way to signal "Hey, this bug is OK" and furthermore bugs are 
> usually assigned to the most appropriate person.  So that is what I did
> first, assign bugs to the people I thought would be most appropriate in
> dealing with them.  That did not go down so well :-)  So, it was 
> suggested to me that instead of assigning, I should cc people.  But that
> is certainly not the best solution, either.

> I believe it would be great if OE started some kind of not too rigid 
> process of triaging bugs.  All projects are a bit different, so what do
> you think would be the best way for OE to handle this?

        I guess this can be expressed as:

1. If there's a confirmed bugtracker manager, whatever he does,
already has good weight in it.
2. There're indeed well-known work flow patterns and best practices,
and those should be rather reused, not ignored.
3. There should be room for improvements and adaption to our specific
case and environment.

        In this regard, I think that current scheme, and your use of
it, is good enough to go with. In particular, I appreciate, and
recommend, that everyone who submits something important (or having
other special criteria) for the area I maintain/watch, to add myself
to cc:, to ensure prompt replies and addition guarantee that important
issues are not lost in awful amount of mail I receive, and don't
depend on not 100% reliable things like my watching bug tracker
notifications.

 >> Everyone on oe-issues list gets all bug reports anyway and I can use
 >> web search quite effectively myself.

> Graeme, I understand your concern.  I don't mean to say "Hey, here is 
> the solution" but maybe there are some options you might consider.

> First is that I would think that it might be a waste of valuable dev 
> time if all core devs read all bug reports on oe-issues.  Of course, 
> that is an individual decision.  But if we got something like bug 
> triaging going in a more instituationalized way, it might indeed become
> unnecessary.  Second, bugzilla offers many settings on what mails you 
> want to receive and which you don't at 
> http://bugs.openembedded.org/userprefs.cgi?tab=email.  If you read 
> oe-issues, you might want to consider deactivating all mail from 
> bugzilla itself to keep the load down.

        I guess this solution is straight into bull's eye - why spend
time communicating your preferences to other people (or, fingers
crossed, quarrel with them), if they instead can be communicated to
Bugzilla, which is there to serve all needs. The same goes for
everyone's best friend, an email client, which has cool things like
folders and filters, and opens their wonders to everyone who wants to
*receive* their mail the way they want, instead of arguing with the
whole world (or arbitrary part of it) how it should send mail to them ;-)


-- 
Best regards,
 Paul                            mailto:pmiscml at gmail.com




From leon.woestenberg at gmail.com  Sun May 13 16:45:04 2007
From: leon.woestenberg at gmail.com (Leon Woestenberg)
Date: Sun, 13 May 2007 18:45:04 +0200
Subject: [oe] uclibc 0.9.29 recipe
In-Reply-To: <46462BDD.6000302@dominion.kabel.utwente.nl>
References: <464613B3.8090003@dominion.kabel.utwente.nl>
	<46461B73.8070900@trolltech.com>
	<46461D72.4020206@dominion.kabel.utwente.nl>
	<46462BDD.6000302@dominion.kabel.utwente.nl>
Message-ID: <c384c5ea0705130945k266d8bccw4f890d99d9997e52@mail.gmail.com>

Hello Koen,

On 5/12/07, Koen Kooi <koen at dominion.kabel.utwente.nl> wrote:
> Koen Kooi schreef:
> To add support for your favourite machine: use uClibc.distro as .config,
> configure uclibc for the target you want, save the top 2 blocks of .config (cpu
> and arch) to uClibc.distro  in uclibc-0.9.29/<machine/uClibc.machine
>
> The recipe is by no means perfect, so any help is welcome.
>
As often, you laid the groundworks, which is often more important than
the make-it-perfect stage.

My hands are twitching to create a clean 0.9.29 .bb that more smartly
configures the library matching the OpenEmbedded configuration. But
let's hack the current setup first.

Who is using uClibc now? In other words, can I break stuff?

Regards,
-- 
Leon



From koen at dominion.kabel.utwente.nl  Sun May 13 16:55:49 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Sun, 13 May 2007 18:55:49 +0200
Subject: [oe] uclibc 0.9.29 recipe
In-Reply-To: <c384c5ea0705130945k266d8bccw4f890d99d9997e52@mail.gmail.com>
References: <464613B3.8090003@dominion.kabel.utwente.nl>	<46461B73.8070900@trolltech.com>	<46461D72.4020206@dominion.kabel.utwente.nl>	<46462BDD.6000302@dominion.kabel.utwente.nl>
	<c384c5ea0705130945k266d8bccw4f890d99d9997e52@mail.gmail.com>
Message-ID: <46474315.1070207@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Leon Woestenberg schreef:
> Hello Koen,
> 
> On 5/12/07, Koen Kooi <koen at dominion.kabel.utwente.nl> wrote:
>> Koen Kooi schreef:
>> To add support for your favourite machine: use uClibc.distro as .config,
>> configure uclibc for the target you want, save the top 2 blocks of .config (cpu
>> and arch) to uClibc.distro  in uclibc-0.9.29/<machine/uClibc.machine
>>
>> The recipe is by no means perfect, so any help is welcome.
>>
> As often, you laid the groundworks, which is often more important than
> the make-it-perfect stage.
> 
> My hands are twitching to create a clean 0.9.29 .bb that more smartly
> configures the library matching the OpenEmbedded configuration. But
> let's hack the current setup first.

It would be nice to set archicture using TARGET_ARCH, endiannes with the info from
siteinfo.bbclass and the the FPU with TARGET_FPU. I bet there are some more options that
could be autoconfigured.

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGR0MVMkyGM64RGpERAmpLAJ40KalkcxFc1oOFNSfOrMB7dypN7gCZAeg4
4C42BTmMvEcIiALtDpSx/eY=
=yp3m
-----END PGP SIGNATURE-----



From leon.woestenberg at gmail.com  Sun May 13 21:39:41 2007
From: leon.woestenberg at gmail.com (Leon Woestenberg)
Date: Sun, 13 May 2007 23:39:41 +0200
Subject: [oe] uclibc 0.9.29 recipe
In-Reply-To: <46474315.1070207@dominion.kabel.utwente.nl>
References: <464613B3.8090003@dominion.kabel.utwente.nl>
	<46461B73.8070900@trolltech.com>
	<46461D72.4020206@dominion.kabel.utwente.nl>
	<46462BDD.6000302@dominion.kabel.utwente.nl>
	<c384c5ea0705130945k266d8bccw4f890d99d9997e52@mail.gmail.com>
	<46474315.1070207@dominion.kabel.utwente.nl>
Message-ID: <c384c5ea0705131439o1a2b71b8i26a16123ae1c591e@mail.gmail.com>

perl 5.8.8 needs:

UCLIBC_SUSV3_LEGACY=y
UCLIBC_SUSV3_LEGACY_MACROS=y



From xjqian at gmail.com  Mon May 14 08:08:03 2007
From: xjqian at gmail.com (Junqian Gordon Xu)
Date: Mon, 14 May 2007 03:08:03 -0500
Subject: [oe] RFD: Bugzilla in general & bug triaging
In-Reply-To: <f277j3$i00$1@sea.gmane.org>
References: <1179059149.5404.3.camel@cimmeria.hyboria>
	<f277j3$i00$1@sea.gmane.org>
Message-ID: <464818E3.7090203@gmail.com>

Rolf,

Is it a problem if I replace the openembedded-issues@ with my email 
address in the Reassign to field? Does openembedded-issues still gets 
all the updates?

I don't want only me receiving the emails even I assign the bug to myself.

regards
Gordon

Rolf Leggewie wrote:
> Graeme Gregory wrote:
>   
>> RFC
>>
>> Dont add people to CC field of bugs without talking to them.
>>     
>
> Thank you Graeme for raising this issue.  It is something I meant to 
> discuss earlier but never found enough time to think it through and 
> write up something.  I still have not thought it through, but here it goes.
>
> Let me first say, that I am totally aware that we are all doing this in 
> our limited free time.  We also all don't like things being stuffed down 
> our throat.  There is a bit of dilemma here.
>
> As a non-dev, I feel one of the better ways for me and others alike is 
> to make sure the BTS is in good shape.  It is called bug triaging which 
> I also do in other projects.  For me, this is all about efficiency, 
> division of labor so to speak (although that capitalistic thinking might 
> not go down too well with all of us freeminds ;-))  The idea is that 
> there is someone who sifts through the bug reports and makes sure they 
> are understandable, complete and real.  The triager also crosslinks bugs 
> that share similarities and classifies them.   All this *before they eat 
> up valuable time from a real dev*.  That is at least what I am trying to 
> do, for the devs to sit down and find well-structured problems to work 
> on whenever they feel like it (I know the OE BTS is not there yet, bug 
> 2194 is a shy start at this).
>
> This is how Ubuntu and Mozilla approach the bugs they receive.  But it 
> needs a way to signal "Hey, this bug is OK" and furthermore bugs are 
> usually assigned to the most appropriate person.  So that is what I did 
> first, assign bugs to the people I thought would be most appropriate in 
> dealing with them.  That did not go down so well :-)  So, it was 
> suggested to me that instead of assigning, I should cc people.  But that 
> is certainly not the best solution, either.
>
> I believe it would be great if OE started some kind of not too rigid 
> process of triaging bugs.  All projects are a bit different, so what do 
> you think would be the best way for OE to handle this?
>
>  > Everyone on oe-issues list gets all bug reports anyway and I can use
>  > web search quite effectively myself.
>
> Graeme, I understand your concern.  I don't mean to say "Hey, here is 
> the solution" but maybe there are some options you might consider.
>
> First is that I would think that it might be a waste of valuable dev 
> time if all core devs read all bug reports on oe-issues.  Of course, 
> that is an individual decision.  But if we got something like bug 
> triaging going in a more instituationalized way, it might indeed become 
> unnecessary.  Second, bugzilla offers many settings on what mails you 
> want to receive and which you don't at 
> http://bugs.openembedded.org/userprefs.cgi?tab=email.  If you read 
> oe-issues, you might want to consider deactivating all mail from 
> bugzilla itself to keep the load down.
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>
>   




From pmiscml at gmail.com  Mon May 14 08:25:58 2007
From: pmiscml at gmail.com (Paul Sokolovsky)
Date: Mon, 14 May 2007 11:25:58 +0300
Subject: [oe] RFD: Bugzilla in general & bug triaging
In-Reply-To: <464818E3.7090203@gmail.com>
References: <1179059149.5404.3.camel@cimmeria.hyboria>
	<f277j3$i00$1@sea.gmane.org> <464818E3.7090203@gmail.com>
Message-ID: <24757045.20070514112558@gmail.com>

Hello Junqian,

Monday, May 14, 2007, 11:08:03 AM, you wrote:

> Rolf,

> Is it a problem if I replace the openembedded-issues@ with my email 
> address in the Reassign to field? Does openembedded-issues still gets 
> all the updates?

        As Rolf described in his mail, we do not reassign bugs in our
workflow - they keep being assigned to ML. That's corresponds to
the fact/reassures that we don't have bug owners in OE, and entire
community welcome to/works on any issue (which in turn is based on the
fact that we don't have dedicated engineers to resolve bugs).

> I don't want only me receiving the emails even I assign the bug to myself.

> regards
> Gordon

> Rolf Leggewie wrote:
[]

-- 
Best regards,
 Paul                            mailto:pmiscml at gmail.com




From xjqian at gmail.com  Mon May 14 08:49:12 2007
From: xjqian at gmail.com (Junqian Gordon Xu)
Date: Mon, 14 May 2007 03:49:12 -0500
Subject: [oe] RFD: Bugzilla in general & bug triaging
In-Reply-To: <24757045.20070514112558@gmail.com>
References: <1179059149.5404.3.camel@cimmeria.hyboria>
	<f277j3$i00$1@sea.gmane.org> <464818E3.7090203@gmail.com>
	<24757045.20070514112558@gmail.com>
Message-ID: <46482288.2040904@gmail.com>

Paul Sokolovsky wrote:
> Hello Junqian,
>
> Monday, May 14, 2007, 11:08:03 AM, you wrote:
>
>   
>> Is it a problem if I replace the openembedded-issues@ with my email 
>> address in the Reassign to field? Does openembedded-issues still gets 
>> all the updates?
>>     
>
>         As Rolf described in his mail, we do not reassign bugs in our
> workflow - they keep being assigned to ML. That's corresponds to
> the fact/reassures that we don't have bug owners in OE, and entire
> community welcome to/works on any issue (which in turn is based on the
> fact that we don't have dedicated engineers to resolve bugs).

Paul,

One benefit of reassigning the bug to myself is that I can click the "My 
Bug" button and list all my filed and self-assigned bugs, instead of 
remembering the bug number or relying on search.

I'm undoing the damages right now. But please let me know if there's an 
alternative to easily keep track of interested bugs.  Well, maybe I'm 
too lazy.

Gordon




From pmiscml at gmail.com  Mon May 14 09:06:30 2007
From: pmiscml at gmail.com (Paul Sokolovsky)
Date: Mon, 14 May 2007 12:06:30 +0300
Subject: [oe] RFD: Bugzilla in general & bug triaging
In-Reply-To: <46482288.2040904@gmail.com>
References: <1179059149.5404.3.camel@cimmeria.hyboria>
	<f277j3$i00$1@sea.gmane.org> <464818E3.7090203@gmail.com>
	<24757045.20070514112558@gmail.com> <46482288.2040904@gmail.com>
Message-ID: <1851689443.20070514120630@gmail.com>

Hello Junqian,

Monday, May 14, 2007, 11:49:12 AM, you wrote:

> Paul Sokolovsky wrote:
>> Hello Junqian,
>>
>> Monday, May 14, 2007, 11:08:03 AM, you wrote:
>>
>>   
>>> Is it a problem if I replace the openembedded-issues@ with my email 
>>> address in the Reassign to field? Does openembedded-issues still gets 
>>> all the updates?
>>>     
>>
>>         As Rolf described in his mail, we do not reassign bugs in our
>> workflow - they keep being assigned to ML. That's corresponds to
>> the fact/reassures that we don't have bug owners in OE, and entire
>> community welcome to/works on any issue (which in turn is based on the
>> fact that we don't have dedicated engineers to resolve bugs).

> Paul,

> One benefit of reassigning the bug to myself is that I can click the "My
> Bug" button and list all my filed and self-assigned bugs, instead of 
> remembering the bug number or relying on search.

        I well understand benefits of assigning bugs, it's just the
fact that OE doesn't assign them (as as was mentioned, it's good, as
have psychological effect of welcoming everyone to work on things, not
think "well, that guy will fix it" or "oh, it's that guy's, I can't
touch it").

> I'm undoing the damages right now. But please let me know if there's an
> alternative to easily keep track of interested bugs.  Well, maybe I'm 
> too lazy.

        You still better rely on search. And Bugzilla is a powerful
("enterprise-grade" ;-) ) tool, which allows you to do many things.
For example, that's how I have it set up: I add myself to cc: of the
interesting bugs (in full accordance to Rolf's RFD), then once made
an advanced search setup, which searches for my address in any email
field (reporter, cc, etc.), and saved it as saved search. Now, it's
the same one click as predefined "My Bugs" search. And you can have
number of saved searches, for machines of your interest, for software,
etc. - all one click away.

> Gordon


-- 
Best regards,
 Paul                            mailto:pmiscml at gmail.com




From koen at dominion.kabel.utwente.nl  Mon May 14 09:06:43 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Mon, 14 May 2007 11:06:43 +0200
Subject: [oe] RFD: Bugzilla in general & bug triaging
In-Reply-To: <46482288.2040904@gmail.com>
References: <1179059149.5404.3.camel@cimmeria.hyboria>	<f277j3$i00$1@sea.gmane.org>
	<464818E3.7090203@gmail.com>	<24757045.20070514112558@gmail.com>
	<46482288.2040904@gmail.com>
Message-ID: <464826A3.7010505@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Junqian Gordon Xu schreef:
> Paul Sokolovsky wrote:
>> Hello Junqian,
>>
>> Monday, May 14, 2007, 11:08:03 AM, you wrote:
>>
>>   
>>> Is it a problem if I replace the openembedded-issues@ with my email 
>>> address in the Reassign to field? Does openembedded-issues still gets 
>>> all the updates?
>>>     
>>         As Rolf described in his mail, we do not reassign bugs in our
>> workflow - they keep being assigned to ML. That's corresponds to
>> the fact/reassures that we don't have bug owners in OE, and entire
>> community welcome to/works on any issue (which in turn is based on the
>> fact that we don't have dedicated engineers to resolve bugs).
> 
> Paul,
> 
> One benefit of reassigning the bug to myself is that I can click the "My 
> Bug" button and list all my filed and self-assigned bugs, instead of 
> remembering the bug number or relying on search.
> 
> I'm undoing the damages right now. But please let me know if there's an 
> alternative to easily keep track of interested bugs.  Well, maybe I'm 
> too lazy.

You could assign to yourself and add oe-issues in CC:

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGSCajMkyGM64RGpERAldiAKCqrJcD6ZE0ULRWcz1Ksxxi+LQ2dACdHXvV
cdawEzHNUHLAOXzREdLLIKQ=
=wDhJ
-----END PGP SIGNATURE-----



From xjqian at gmail.com  Mon May 14 09:18:09 2007
From: xjqian at gmail.com (Junqian Gordon Xu)
Date: Mon, 14 May 2007 04:18:09 -0500
Subject: [oe] RFD: Bugzilla in general & bug triaging
In-Reply-To: <1851689443.20070514120630@gmail.com>
References: <1179059149.5404.3.camel@cimmeria.hyboria>
	<f277j3$i00$1@sea.gmane.org> <464818E3.7090203@gmail.com>
	<24757045.20070514112558@gmail.com> <46482288.2040904@gmail.com>
	<1851689443.20070514120630@gmail.com>
Message-ID: <46482951.8060803@gmail.com>

Paul Sokolovsky wrote:
>> I'm undoing the damages right now. But please let me know if there's an
>> alternative to easily keep track of interested bugs.  Well, maybe I'm 
>> too lazy.
>>     
>
>         You still better rely on search. And Bugzilla is a powerful
> ("enterprise-grade" ;-) ) tool, which allows you to do many things.
> For example, that's how I have it set up: I add myself to cc: of the
> interesting bugs (in full accordance to Rolf's RFD), then once made
> an advanced search setup, which searches for my address in any email
> field (reporter, cc, etc.), and saved it as saved search. Now, it's
> the same one click as predefined "My Bugs" search. And you can have
> number of saved searches, for machines of your interest, for software,
> etc. - all one click away

Thanks for the great tip. When I said I was too lazy, that's also 
including that I'm too lazy to study/play with all the features of 
Bugzilla, esp. considering the enterprise-grade motto :)

Gordon



From koen at dominion.kabel.utwente.nl  Mon May 14 09:42:59 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Mon, 14 May 2007 11:42:59 +0200
Subject: [oe] [oe-commits] org.oe.dev ixp4xx-kernel: Dropped support for
 2.6.21, we're sticking to 2.6.20 stable and 2.6.22 development
In-Reply-To: <E1HnWn2-0007PS-SW@linuxtogo.org>
References: <E1HnWn2-0007PS-SW@linuxtogo.org>
Message-ID: <46482F23.9050504@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

rwhitby commit schreef:
> ixp4xx-kernel: Dropped support for 2.6.21, we're sticking to 2.6.20 stable and 2.6.22 development

> # delete "packages/linux/ixp4xx-kernel_2.6.21.bb"

You broke feeds and upgrade paths for users of that recipe, could you next time just add
DEFAULT_PREFERENCE = "-1" or something? Slugos isn't the only user of OE!
 I just got .21 running on my ixp4xx board, and now I have to remove all kernel packages,
packages built against .21 and find a way for angstrom to deal with that in the feeds for
people doing 'ipkg upgrade'.

I will deal with it, but next time a bit of warning on the OE list would be appreciated.

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGSC8jMkyGM64RGpERAl+UAJ42rD9nGX4EcbKJRzD0yXAgAjwWDwCfaFjg
NoUOnnEP5xC3YJodBtkjQCI=
=a0fc
-----END PGP SIGNATURE-----



From rod at whitby.id.au  Mon May 14 10:14:56 2007
From: rod at whitby.id.au (Rod Whitby)
Date: Mon, 14 May 2007 19:44:56 +0930
Subject: [oe] [oe-commits] org.oe.dev ixp4xx-kernel: Dropped support for
 2.6.21, we're sticking to 2.6.20 stable and 2.6.22 development
In-Reply-To: <46482F23.9050504@dominion.kabel.utwente.nl>
References: <E1HnWn2-0007PS-SW@linuxtogo.org>
	<46482F23.9050504@dominion.kabel.utwente.nl>
Message-ID: <464836A0.6050705@whitby.id.au>

Koen Kooi wrote:
> rwhitby commit schreef:
>>> ixp4xx-kernel: Dropped support for 2.6.21, we're sticking to 2.6.20 stable and 2.6.22 development
> 
>>> # delete "packages/linux/ixp4xx-kernel_2.6.21.bb"
> 
> You broke feeds and upgrade paths for users of that recipe, could you next time just add
> DEFAULT_PREFERENCE = "-1" or something? Slugos isn't the only user of OE!

My apologies.  Mea culpa.

>  I just got .21 running on my ixp4xx board, and now I have to remove all kernel packages,
> packages built against .21 and find a way for angstrom to deal with that in the feeds for
> people doing 'ipkg upgrade'.

I'll put it back immediately.

-- Rod



From no2spam at nospam.arcornews.de  Mon May 14 10:16:37 2007
From: no2spam at nospam.arcornews.de (Rolf Leggewie)
Date: Mon, 14 May 2007 12:16:37 +0200
Subject: [oe] RFD: Bugzilla in general & bug triaging
In-Reply-To: <46482288.2040904@gmail.com>
References: <1179059149.5404.3.camel@cimmeria.hyboria>	<f277j3$i00$1@sea.gmane.org>
	<464818E3.7090203@gmail.com>	<24757045.20070514112558@gmail.com>
	<46482288.2040904@gmail.com>
Message-ID: <f29cu8$lol$1@sea.gmane.org>

Junqian Gordon Xu wrote:
>>         As Rolf described in his mail, we do not reassign bugs in our
>> workflow 

Actually that is neither what I wrote nor what I'd propose ;-)  I have 
no issue with you assigning 2309 to yourself.  You seem to take good 
care of it.

> One benefit of reassigning the bug to myself is that I can click the "My 
> Bug" button and list all my filed and self-assigned bugs, instead of 
> remembering the bug number or relying on search.

yes, very valid point.  It innocently illustrates the kind of workflow 
I'd be looking for (and that I use to a certain degree for myself).  You 
have a link with a search function saved in bugzilla and when you click 
on it all the bugs that need your attention or that you are interested 
in are right there.

Gordon, maybe you want to save http://tinyurl.com/385p8b  You could also 
separate that out to only list cc bugs or whatever suits your needs. 
Tweak it to your liking.

Here are three searches that I use and deem useful for others

http://tinyurl.com/2oypog (todays bugs: action: stay current)
http://tinyurl.com/35l78g (bugs where compilation fails, action: verify)
http://tinyurl.com/39gss8 (old with patches, action: inspect, commit)




From no2spam at nospam.arcornews.de  Mon May 14 10:28:30 2007
From: no2spam at nospam.arcornews.de (Rolf Leggewie)
Date: Mon, 14 May 2007 12:28:30 +0200
Subject: [oe] RFD: Bugzilla in general & bug triaging
In-Reply-To: <f277j3$i00$1@sea.gmane.org>
References: <1179059149.5404.3.camel@cimmeria.hyboria>
	<f277j3$i00$1@sea.gmane.org>
Message-ID: <f29dkh$o3v$1@sea.gmane.org>

Rolf Leggewie wrote:
> Thank you Graeme for raising this issue.  It is something I meant to 
> discuss earlier but never found enough time to think it through and 
> write up something.  I still have not thought it through, but here it goes.

I have asked and been granted greater powers on bugzilla.  There are 
features which we don't use yet but which could aid in establishing a 
sane workflow while rendering unnecessary the current clutches and 
ad-hoc fixes.

Bugzilla will be upgraded soon and no structural changes will be made 
until that is completed.  But that leaves us some good time to think 
about how this should be enhanced.

Things I'd like to see
* confirmation flags
* better documentation of workflow status (need to define it first)
* assigning bugs (or if you prefer "Hey, please take a look")
* link to some bug searches like the ones I send about 5 minutes ago
   on the entry page
* entry page clean-up (why two search fields?)
* removal of dead stuff (ZaurusKernel, Familiar)

Please add to the list.  The most important point is the second.  That 
is what we should discuss.




From pmiscml at gmail.com  Mon May 14 11:26:44 2007
From: pmiscml at gmail.com (Paul Sokolovsky)
Date: Mon, 14 May 2007 14:26:44 +0300
Subject: [oe] RFD: Bugzilla in general & bug triaging
In-Reply-To: <f29cu8$lol$1@sea.gmane.org>
References: <1179059149.5404.3.camel@cimmeria.hyboria>
	<f277j3$i00$1@sea.gmane.org> <464818E3.7090203@gmail.com>
	<24757045.20070514112558@gmail.com>
	<46482288.2040904@gmail.com> <f29cu8$lol$1@sea.gmane.org>
Message-ID: <1848419262.20070514142644@gmail.com>

Hello Rolf,

Monday, May 14, 2007, 1:16:37 PM, you wrote:

> Junqian Gordon Xu wrote:
>>>         As Rolf described in his mail, we do not reassign bugs in our
>>> workflow 

> Actually that is neither what I wrote nor what I'd propose ;-)

        Well, ok, what you wrote is that you once tried assign bugs,
but was suggested not to do that. If you want to propose that again,
then the same suggestion: please don't do that. The reasons were
given, and I reiterate over the matter below again.

> I have
> no issue with you assigning 2309 to yourself.  You seem to take good 
> care of it.

>> One benefit of reassigning the bug to myself is that I can click the "My 
>> Bug" button and list all my filed and self-assigned bugs, instead of 
>> remembering the bug number or relying on search.

> yes, very valid point.  It innocently illustrates the kind of workflow
> I'd be looking for (and that I use to a certain degree for myself).

        That's kind of bug workflow most projects use, be them
opensource or commercial, so no wonder. But such workflow works
especially well if as many as possible of the following are true:

1. Scope of project and functional areas are well defined.
2. There're dedicated developer for each area.
3. There's a manager who performs assignment.

        None of these are true for OE - the scope is too wide, areas
either to big (like, a distro), or too diversified (issues with
specific package or machine), there're no dedicated developers for
specific areas, and no manager who tells folks what to do.

        So, there's another workflow, of course not so organized, but
flexible and well fitting OE devel model, the reason why it was there
well before you or me came into active contribution.

> You
> have a link with a search function saved in bugzilla and when you click
> on it all the bugs that need your attention or that you are interested
> in are right there.

        Yes, you have saved searches, you have email preferences, you
have other cool things in Bugzilla, you learn to use them well in
framework on the existing workflow, before trying to revolutionize the
workflow itself.

> Gordon, maybe you want to save http://tinyurl.com/385p8b  You could also
> separate that out to only list cc bugs or whatever suits your needs. 
> Tweak it to your liking.

> Here are three searches that I use and deem useful for others

> http://tinyurl.com/2oypog (todays bugs: action: stay current)
> http://tinyurl.com/35l78g (bugs where compilation fails, action: verify)
> http://tinyurl.com/39gss8 (old with patches, action: inspect, commit)

        These links are nice, but won't help too much. Until people
start to make bug filters which *they* like and need, there always be
idea that something's lacking and that you need to put it upside down
trying to make it "work" for you.

-- 
Best regards,
 Paul                            mailto:pmiscml at gmail.com




From koen at dominion.kabel.utwente.nl  Mon May 14 12:06:27 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Mon, 14 May 2007 14:06:27 +0200
Subject: [oe] Making /var/lib persistent
In-Reply-To: <31583224.20070510180054@gmail.com>
References: <1176760923.4623f25b913f9@dominion.kabel.utwente.nl>	<20070418090235.GA21841@twibble.org>	<46262A0F.1050805@dominion.kabel.utwente.nl>	<20070419014949.GA6540@twibble.org>
	<31583224.20070510180054@gmail.com>
Message-ID: <464850C3.90202@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Paul Sokolovsky schreef:
> Hello Jamie,
> 
> Thursday, April 19, 2007, 4:49:50 AM, you wrote:
> 
>> On Wed, Apr 18, 2007 at 07:24:15AM -0700, Koen Kooi wrote:
>> [...]
>>> Sound like a good idea, do you have a patch for this?
> 
>> Try this out:
> 
>>   http://twibble.org/dist/oe/var-volatiles-1.patch
> 
>> I've tested it locally both with and without tmpfs mounted on
>> /var/volatile and all seems to work as expected.
> 
>         Any news on this? I've been running with this patch soon since
> its original post and don't see any issues. One small nuisance is that
> ls -l /var/log doesn't show what you want, but hardly something can be
> done about that, plus shell completion uses /var/log/ immediately.
> 
>         I suggest committing this patch.

After I have fixed up the rejects I'll commit and push it.

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGSFDDMkyGM64RGpERArsZAJ0aPIXjYQW8TcJ4qd5z01RWFbSAUACfWBU0
zg9Qmq0tPnSryt6WDAOki3o=
=DO2J
-----END PGP SIGNATURE-----



From koen at dominion.kabel.utwente.nl  Mon May 14 12:21:14 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Mon, 14 May 2007 14:21:14 +0200
Subject: [oe] Making /var/lib persistent
In-Reply-To: <464850C3.90202@dominion.kabel.utwente.nl>
References: <1176760923.4623f25b913f9@dominion.kabel.utwente.nl>	<20070418090235.GA21841@twibble.org>	<46262A0F.1050805@dominion.kabel.utwente.nl>	<20070419014949.GA6540@twibble.org>	<31583224.20070510180054@gmail.com>
	<464850C3.90202@dominion.kabel.utwente.nl>
Message-ID: <4648543A.8080202@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Koen Kooi schreef:

>>>   http://twibble.org/dist/oe/var-volatiles-1.patch

> After I have fixed up the rejects I'll commit and push it.

Ok, it's in, please report any errors/bugs/features

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGSFQ6MkyGM64RGpERAnezAKCfPi397VPH5q72q+wxpLKl9wFtMQCfdHQg
kozdbu7EzNnNWf5zgwr4oBw=
=qZ8t
-----END PGP SIGNATURE-----



From koen at dominion.kabel.utwente.nl  Mon May 14 12:30:00 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Mon, 14 May 2007 14:30:00 +0200
Subject: [oe] uclibc 0.9.29 recipe
In-Reply-To: <c384c5ea0705131439o1a2b71b8i26a16123ae1c591e@mail.gmail.com>
References: <464613B3.8090003@dominion.kabel.utwente.nl>	<46461B73.8070900@trolltech.com>	<46461D72.4020206@dominion.kabel.utwente.nl>	<46462BDD.6000302@dominion.kabel.utwente.nl>	<c384c5ea0705130945k266d8bccw4f890d99d9997e52@mail.gmail.com>	<46474315.1070207@dominion.kabel.utwente.nl>
	<c384c5ea0705131439o1a2b71b8i26a16123ae1c591e@mail.gmail.com>
Message-ID: <46485648.8000705@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Leon Woestenberg schreef:
> perl 5.8.8 needs:
> 
> UCLIBC_SUSV3_LEGACY=y
> UCLIBC_SUSV3_LEGACY_MACROS=y

Feel free to add those to (angstrom/)uClibc.distro

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGSFZIMkyGM64RGpERAm6LAJ9zXFxGitsAcWxB9MBPXT8qYQMrvwCcC6ro
XdSuqhAYD0TKlipoSA0pQJ0=
=d9jH
-----END PGP SIGNATURE-----



From rpurdie at rpsys.net  Mon May 14 12:42:32 2007
From: rpurdie at rpsys.net (Richard Purdie)
Date: Mon, 14 May 2007 13:42:32 +0100
Subject: [oe] do_rootfs fails
In-Reply-To: <1178928474.4954.18.camel@localhost.localdomain>
References: <4644ABCB.6080202@openhardware.net>
	<4644B0D2.8020409@dominion.kabel.utwente.nl>
	<1178928474.4954.18.camel@localhost.localdomain>
Message-ID: <1179146552.5877.1.camel@localhost.localdomain>

On Sat, 2007-05-12 at 02:07 +0200, Matthias Hentges wrote:
> Am Freitag, den 11.05.2007, 20:07 +0200 schrieb Koen Kooi:
> 
> > All: Are we still going to wait 1.5 months with requiring 1.8.x? I've seen enough proof
> > that 1.6.x is broken with current .dev, with no effort to fix it. "Giving people time to
> > prepare the upgrade" has now turned into "Stabbing user in the eye" :(
> > 
> > regards,
> > 
> > Koen
> 
> 1.8.x has a show-stopper freeze-bug for some users ( including myself )
> which has not been fixed or even looked into yet.

Nobody has reported this properly although I keep hearing mention of it.

Could you send me the output from stty in your usual development
environment please?

Thanks,

Richard






From openembedded at hrw.one.pl  Mon May 14 13:28:12 2007
From: openembedded at hrw.one.pl (Marcin Juszkiewicz)
Date: Mon, 14 May 2007 15:28:12 +0200
Subject: [oe] RFD: Bugzilla in general & bug triaging
In-Reply-To: <f29dkh$o3v$1@sea.gmane.org>
References: <1179059149.5404.3.camel@cimmeria.hyboria>
	<f277j3$i00$1@sea.gmane.org> <f29dkh$o3v$1@sea.gmane.org>
Message-ID: <200705141528.12352.openembedded@hrw.one.pl>

Dnia poniedzia?ek, 14 maja 2007, Rolf Leggewie napisa?:

> Bugzilla will be upgraded soon and no structural changes will be made
> until that is completed.  But that leaves us some good time to think
> about how this should be enhanced.

> Please add to the list.  The most important point is the second.  That
> is what we should discuss.

MACHINE field would be useful - there are bugs specific to machine (kernel 
bug etc) which now have it in title or comment. 






From ulf at atmel.com  Mon May 14 13:14:03 2007
From: ulf at atmel.com (Ulf Samuelsson)
Date: Mon, 14 May 2007 15:14:03 +0200
Subject: [oe] qemu-native failure on Angstrom
Message-ID: <07a101c7962b$e0db5860$0200a8c0@atmel.com>

Tried building OpenEmbedded for the first time, DISTRO=?ngstr?m, 
with an at91sam9263 target (made my own file) but it seems that
qemu.native is not compilable on my OpenSuSE 10.1 system using gcc-4.1.2.
The error message says that qemu has only been tested on gcc-4.x.x for arm
and that other architectures need gcc-3.x

Tried to update the bb files to allow gcc-4.1.2 but that resulted in
qemu-arm not beeing built, causing the build to terminate later.

Is there any way to have open embedded build a gcc-3.4.4 cross compiler
as part of the normal build.

Best Regards
Ulf Samuelsson




From koen at dominion.kabel.utwente.nl  Mon May 14 13:40:44 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Mon, 14 May 2007 15:40:44 +0200
Subject: [oe] qemu-native failure on Angstrom
In-Reply-To: <07a101c7962b$e0db5860$0200a8c0@atmel.com>
References: <07a101c7962b$e0db5860$0200a8c0@atmel.com>
Message-ID: <464866DC.6060502@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ulf Samuelsson schreef:
> Tried building OpenEmbedded for the first time, DISTRO=?ngstr?m, 
> with an at91sam9263 target (made my own file) but it seems that
> qemu.native is not compilable on my OpenSuSE 10.1 system using gcc-4.1.2.
> The error message says that qemu has only been tested on gcc-4.x.x for arm
> and that other architectures need gcc-3.x
> 
> Tried to update the bb files to allow gcc-4.1.2 but that resulted in
> qemu-arm not beeing built, causing the build to terminate later.
> 
> Is there any way to have open embedded build a gcc-3.4.4 cross compiler
> as part of the normal build.

You want a native gcc3 on your host, since qemu-native will be compiled with that, on
debian that can be done with 'apt-get install gcc-3.4'.

Alternatively you can set ENABLE_BINARY_LOCALE_GENERATION = "0" in your local.conf.

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGSGbcMkyGM64RGpERAlXOAJ9HlfnJ5CbfVrHd3lOIBsDfyqbDqgCgmzv5
4tDq+oZskVRAfnxs7rWNlVA=
=OQ93
-----END PGP SIGNATURE-----



From skyhusker at rm-fr.net  Mon May 14 13:46:02 2007
From: skyhusker at rm-fr.net (Alberto =?iso-8859-1?q?Garc=EDa_Hierro?=)
Date: Mon, 14 May 2007 15:46:02 +0200
Subject: [oe] qemu-native failure on Angstrom
In-Reply-To: <07a101c7962b$e0db5860$0200a8c0@atmel.com>
References: <07a101c7962b$e0db5860$0200a8c0@atmel.com>
Message-ID: <200705141546.02470.skyhusker@rm-fr.net>

El Monday 14 May 2007 15:14:03 Ulf Samuelsson escribi?:
> Tried building OpenEmbedded for the first time, DISTRO=?ngstr?m,
> with an at91sam9263 target (made my own file) but it seems that
> qemu.native is not compilable on my OpenSuSE 10.1 system using gcc-4.1.2.
> The error message says that qemu has only been tested on gcc-4.x.x for arm
> and that other architectures need gcc-3.x
>
> Tried to update the bb files to allow gcc-4.1.2 but that resulted in
> qemu-arm not beeing built, causing the build to terminate later.
>
> Is there any way to have open embedded build a gcc-3.4.4 cross compiler
> as part of the normal build.

	Check the patch at http://bugs.openembedded.org/show_bug.cgi?id=1144. It's 
for amd64, but with little editing you can adapt it to your system.

Regards,
	Alberto


-- 
Alberto Garc?a Hierro
http://zeus.rm-fr.net/~skyhusker/



From pmiscml at gmail.com  Mon May 14 14:13:06 2007
From: pmiscml at gmail.com (Paul Sokolovsky)
Date: Mon, 14 May 2007 17:13:06 +0300
Subject: [oe] qemu-native failure on Angstrom
In-Reply-To: <200705141546.02470.skyhusker@rm-fr.net>
References: <07a101c7962b$e0db5860$0200a8c0@atmel.com>
	<200705141546.02470.skyhusker@rm-fr.net>
Message-ID: <783750430.20070514171306@gmail.com>

Hello Alberto,

Monday, May 14, 2007, 4:46:02 PM, you wrote:

> El Monday 14 May 2007 15:14:03 Ulf Samuelsson escribi?:
>> Tried building OpenEmbedded for the first time, DISTRO=?ngstr?m,
>> with an at91sam9263 target (made my own file) but it seems that
>> qemu.native is not compilable on my OpenSuSE 10.1 system using gcc-4.1.2.
>> The error message says that qemu has only been tested on gcc-4.x.x for arm
>> and that other architectures need gcc-3.x
>>
>> Tried to update the bb files to allow gcc-4.1.2 but that resulted in
>> qemu-arm not beeing built, causing the build to terminate later.
>>
>> Is there any way to have open embedded build a gcc-3.4.4 cross compiler
>> as part of the normal build.

>         Check the patch at
> http://bugs.openembedded.org/show_bug.cgi?id=1144. It's 
> for amd64, but with little editing you can adapt it to your system.

        Not sure this is anyhow good patch to suggest.
http://bugs.openembedded.org/show_bug.cgi?id=2157 is what promises to
solve gcc4 issues, but that still waits for the confirmation that
it actually cooks locales well.

> Regards,
>         Alberto





-- 
Best regards,
 Paul                            mailto:pmiscml at gmail.com




From ccsmart at smartpal.de  Mon May 14 17:15:16 2007
From: ccsmart at smartpal.de ([cc]smart)
Date: Mon, 14 May 2007 19:15:16 +0200
Subject: [oe] Making /var/lib persistent
Message-ID: <1179162916.23344.6.camel@localhost>

Hi list.

i must admit i am a bit late on the discussion but nonetheless... i
noticed the change on the tree and i would like to comment volatiles use
and the patch:

http://www.openembedded.org/viewmtn/revision.psp?id=d8f8ffd537ebb6baa3cabe50d3f8267cdd28f3b7

The discussion on the list was accompanied by:

>        The only concern is all this override files patchery. I wish 
>we had for fstab the same machinery as for autoconf site files - 
>ability to merge standard template with per-machine overrides. But 
>well, lack of such shouldn't be cause of delay with this patch, hope 
>to see it soon in mainline! 
> 
>Best regards, 
> Paul                            mailto:pmiscml at gmail.com


I would like to take you back a few years into history of volatiles,
because originally, it was invented primarily to assist in modular
configuration.

I'd like to start with the explanation given in the main volatiles
config file:


# This configuration file lists filesystem objects that should get
verified 
# during startup and be created if missing. 
# 
# Every line must either be a comment starting with # 
# or a definition of format: 
# <type> <owner> <group> <mode> <path> <linksource> 
# where the items are separated by whitespace ! 
# 
# <type> : d|f|l : (d)irectory|(f)ile|(l)ink 
# 
# A linking example: 
# l root root 0777 /var/test /tmp/testfile 
# f root root 0644 /var/test none 
# 
# Understanding links: 
# When populate-volatile is to verify/create a directory or file, it
will first 
# check it's existence. If a link is found to exist in the place of the
target, 
# the path of the target is replaced with the target the link points
to. 
# Thus, if a link is in the place to be verified, the object will be
created 
# in the place the link points to instead. 
# This explains the order of "link before object" as in the example
above, where 
# a link will be created at /var/test pointing to /tmp/testfile and due
to this 
# link the file defined as /var/test will actually be created
as /tmp/testfile.


FWIW, i think it has never been observed to create links before the
actual object. Why was it done like that despite it seems
counterintuitive.

Because it is part of the modulartity.

This main file should contain only basic, and only "real object"
descriptions. That is what it was at the beginning. All the redirection
into tmpfs space is NOT meant to be done in this file.

Basically it should roughly be kept like this (mind you, specifying
"none" in the end was not needed originally):

d root root 0755 /var/cache none 
d root root 1777 /var/lock none 
d root root 0755 /var/log none 
d root root 0755 /var/run none 
d root root 1777 /var/tmp none 
d root root 0755 /var/lock/subsys none 
f root root 0664 /var/log/wtmp none 
f root root 0664 /var/run/utmp none

In fstab, there should neither be tmpf on /var nor on /var/volatile but
for example under /media/ram only.

Now let your mind go back to the rule "link before object".

The default is a physical world. Volatiles would set up your directories
as described in it's configuration "ohysically".

If you create a distro for a device on flash, you would deliver your
image with links in var pointing to /media/ram. For example there would
be a link "/var/run" pointing to "/media/ram/run".

Automagically, volatiles would use the line

d root root 0755 /var/run none

to create a directory in "/media/ram". No need for changing the
volatiles base configuration (i hope that no change in volatiles as
broken this, otherwise IMHO it should be fixed to behave like that
again).

Subsequently turnup would only have to remove links in "/var" to get
that distro going on HD.

The second idea in the original design of volatiles is to have a tool
that allows adding and removing directory requirements per package. So a
package can drop in a specification in volatiles config directory. these
are numbered like runlevels.

This allows to have separate specification files. One defines the real
objects, like the base files does, and it's seq. number should be n+1 .

Additionally you may have a redirection config (possibly per distro)
with seq. number n which may redirect to volatile space, like
"/media/ram" .

Basically in thinking you always start physical and then deviate to
volatile.

All in all i would recommend to:

- revert volatiles main config to physical objects only 
- remove all /var based tmpfs's from /etc/fstab and make it more or less
a static thing. 
- get distros pre provide main redirection links in "/var" where needed.

Greetings, 
[cc]smart





From gerwin at vanderkruis.net  Mon May 14 18:38:31 2007
From: gerwin at vanderkruis.net (Gerwin)
Date: Mon, 14 May 2007 20:38:31 +0200
Subject: [oe] Questions: Founding of Open Embedded, dev gatherings etc.
In-Reply-To: <463C9ABC.7090503@dominion.kabel.utwente.nl>
References: <200705041909.29494.kyrvin@trolltech.com>
	<463C9ABC.7090503@dominion.kabel.utwente.nl>
Message-ID: <200705142038.32087.gerwin@vanderkruis.net>

Hi Knut, 

I have been quite busy myself as well , lot of embedded work and lot of 
php/java work. 

I am busy with a wimax kind of smartphone for the asian market which will run 
of course linux(currently hardware design fase). And some smaller projects so 
it is quite busy at this moment.  

> >
> > I got some experiences with developer gatherings after initiationg the
> > Skolelinux project in 2001. Actually we have organised +30 gatherings.
> > Skolelinux is now a part of DebianEdu. The board of "Free Software in
> > School" organises about 6-7 developer gatherings a year. Pictures from
> > opening of one of the gatherings in Forbach - France, gives an idea of
> > the scale:
> >
> > http://www.bawetic.be/PHOTOS/Forbach2006/
> >
> > I would like to see similar activeties in OpenEmbedded space. Maybe
> > Mobile Developer Days 2007 at Alborg University in Denmark could be the
> > place to start?:
> >

Yes I think so , the main problem is that our main developers are in the 
Netherlands , Germany , England and Poland. So yes we can send a delegation 
but I don't think that all developers will be there . I think we have a 
bigger chance if we organize something like this in the Netherlands or 
Germany. 

> > To sum it up. Gerwin van der Kruis idea is to make a foundation, and
> > getting dev.gatherings started. Is this interesting for you? If you are
> > interesed, how should we proceed?
>

We discussed about this also during fosdem and later on as well on irc, the 
main problem is time and knowledge . For example where should such a 
foundation be based , who is going to govern it etc. etc. 

OEDEM Frosconn and t-dose are the first opurtunities that we will be present .

I invited you for t-dose as well for a keynote. 


Kind Regards, 

Gerwin


-- 
The Holographic Klop Doctor

               -
               0
             - |
              \|\
               |/
               |
              /|
            _|_|

Underneath the mango tree  :) 



From oe at hentges.net  Mon May 14 22:23:00 2007
From: oe at hentges.net (Matthias Hentges)
Date: Tue, 15 May 2007 00:23:00 +0200
Subject: [oe] do_rootfs fails
In-Reply-To: <1178928474.4954.18.camel@localhost.localdomain>
References: <4644ABCB.6080202@openhardware.net>
	<4644B0D2.8020409@dominion.kabel.utwente.nl>
	<1178928474.4954.18.camel@localhost.localdomain>
Message-ID: <1179181380.4954.45.camel@localhost.localdomain>

Hello all,

Am Samstag, den 12.05.2007, 02:07 +0200 schrieb Matthias Hentges:

> 1.8.x has a show-stopper freeze-bug for some users ( including myself )
> which has not been fixed or even looked into yet.

RP was kind enough to look into the issue. The following command
unbreaks bitbake 1.8 on my build environment: 

stty -tostop

The IRC discussion leading to the fix is archived here:

http://hentges.net/tmp/logs/irc/%
23oe/2007/May/20070515_oe.log#[20070515%2000:08:46]
-- 
Matthias 'CoreDump' Hentges 
Cologne / Germany

Webmaster of Hentges.net & Embedded Linux Developer
GPG ->  gpg --keyserver gpg-keyserver.de --recv-keys 0xAF3030D9

My OS: Debian SID: Geek by Nature, Linux by Choice


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
URL: <http://lists.openembedded.org/pipermail/openembedded-devel/attachments/20070515/94aee16e/attachment-0002.sig>

From koen at dominion.kabel.utwente.nl  Mon May 14 23:05:53 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Tue, 15 May 2007 01:05:53 +0200
Subject: [oe] Fixing up libtool-native and libtool-cross
Message-ID: <4648EB51.4040303@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Richard has fixed up libtool in Poky a bit and I want to merge his work into OE. Since
it's 1 AM now, and libtool is a pretty 'core' part, I'm posting the patch for review
before committing it tomorrow night.

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGSOtRMkyGM64RGpERAuiCAJ0Yqz+t4X/zNCjTbZIBU7yjaDt8twCgkgVq
iM3uwQTciklpQKjurM34Nys=
=W6UX
-----END PGP SIGNATURE-----
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: libtool.diff
URL: <http://lists.openembedded.org/pipermail/openembedded-devel/attachments/20070515/6b5c5c15/attachment-0002.ksh>

From philipp.zabel at gmail.com  Tue May 15 07:53:30 2007
From: philipp.zabel at gmail.com (pHilipp Zabel)
Date: Tue, 15 May 2007 09:53:30 +0200
Subject: [oe] Fixing up libtool-native and libtool-cross
In-Reply-To: <4648EB51.4040303@dominion.kabel.utwente.nl>
References: <4648EB51.4040303@dominion.kabel.utwente.nl>
Message-ID: <74d0deb30705150053p109b57d6of67860d7fbb028ba@mail.gmail.com>

On 5/15/07, Koen Kooi <koen at dominion.kabel.utwente.nl> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
>
> Richard has fixed up libtool in Poky a bit and I want to merge his work into OE. Since
> it's 1 AM now, and libtool is a pretty 'core' part, I'm posting the patch for review
> before committing it tomorrow night.

Looks good to me.

> regards,
>
> Koen
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (Darwin)
>
> iD8DBQFGSOtRMkyGM64RGpERAuiCAJ0Yqz+t4X/zNCjTbZIBU7yjaDt8twCgkgVq
> iM3uwQTciklpQKjurM34Nys=
> =W6UX
> -----END PGP SIGNATURE-----
>
> #
> # old_revision [990392a71744fa8ec062ee769a883473775269ee]
> #
> # patch "classes/autotools.bbclass"
> #  from [dced52fcafd4e224bafcb35c4fb04253857c7c3b]
> #    to [113ae9d1554b6e93d9c7a7fda84d71da4712caf9]
> #
> # patch "packages/libtool/libtool-cross_1.5.10.bb"
> #  from [58b238af5bb9acdeca5b86c34b50c419fb49b55e]
> #    to [5134256c71b2d679838e87a55b084a99b1ac17d4]
> #
> # patch "packages/libtool/libtool-native_1.5.10.bb"
> #  from [e1d2b08387782afbf7c5c6787a92d9af864dfb2d]
> #    to [bc799a0464069f3531cbb0a017c4d8d2a1afd63e]
> #
> ============================================================
> --- classes/autotools.bbclass   dced52fcafd4e224bafcb35c4fb04253857c7c3b
> +++ classes/autotools.bbclass   113ae9d1554b6e93d9c7a7fda84d71da4712caf9
> @@ -15,6 +15,10 @@ def autotools_dep_prepend(d):
>
>         if not pn in ['libtool', 'libtool-native', 'libtool-cross']:
>                 deps += 'libtool-native '
> +               if not bb.data.inherits_class('native', d) \
> +                        and not bb.data.inherits_class('cross', d) \
> +                        and not bb.data.getVar('INHIBIT_DEFAULT_DEPS', d, 1):
> +                    deps += 'libtool-cross '
>
>         return deps + 'gnu-config-native '
>
> ============================================================
> --- packages/libtool/libtool-cross_1.5.10.bb    58b238af5bb9acdeca5b86c34b50c419fb49b55e
> +++ packages/libtool/libtool-cross_1.5.10.bb    5134256c71b2d679838e87a55b084a99b1ac17d4
> @@ -1,7 +1,7 @@ require libtool_${PV}.bb
>  SECTION = "devel"
>  require libtool_${PV}.bb
>
> -PR = "r4"
> +PR = "r5"
>  PACKAGES = ""
>  FILESDIR = "${@os.path.dirname(bb.data.getVar('FILE',d,1))}/libtool-${PV}"
>  SRC_URI_append = " file://libdir-la.patch;patch=1 \
> @@ -21,6 +21,13 @@ do_stage () {
>
>  do_stage () {
>          install -m 0755 ${HOST_SYS}-libtool ${bindir}/${HOST_SYS}-libtool
> +        install -m 0644 libltdl/ltdl.h ${STAGING_INCDIR}/
> +        install -d ${STAGING_DATADIR}/libtool ${STAGING_DATADIR}/aclocal
> +        install -c config.guess ${STAGING_DATADIR}/libtool/
> +        install -c config.sub ${STAGING_DATADIR}/libtool/
> +        install -c -m 0644 ltmain.sh ${STAGING_DATADIR}/libtool/
> +        install -c -m 0644 libtool.m4 ${STAGING_DATADIR}/aclocal/
> +        install -c -m 0644 ltdl.m4 ${STAGING_DATADIR}/aclocal/
>  }
>
>  do_install () {
> ============================================================
> --- packages/libtool/libtool-native_1.5.10.bb   e1d2b08387782afbf7c5c6787a92d9af864dfb2d
> +++ packages/libtool/libtool-native_1.5.10.bb   bc799a0464069f3531cbb0a017c4d8d2a1afd63e
> @@ -1,7 +1,7 @@ require libtool_${PV}.bb
>  SECTION = "devel"
>  require libtool_${PV}.bb
>
> -PR = "r4"
> +PR = "r5"
>  FILESDIR = "${@os.path.dirname(bb.data.getVar('FILE',d,1))}/libtool-${PV}"
>  SRC_URI_append = " file://libdir-la.patch;patch=1 \
>                     file://prefix.patch;patch=1 \
> @@ -10,8 +10,6 @@ S = "${WORKDIR}/libtool-${PV}"
>                     file://install-path-check.patch;patch=1"
>  S = "${WORKDIR}/libtool-${PV}"
>
> -STAGING_DATADIR_safe := "${STAGING_DATADIR}"
> -
>  inherit native
>
>  do_stage () {
> @@ -19,22 +17,12 @@ do_stage () {
>         install -m 0755 libtoolize ${STAGING_BINDIR}/libtoolize
>         oe_libinstall -a -so -C libltdl libltdl ${STAGING_LIBDIR}
>         install -m 0644 libltdl/ltdl.h ${STAGING_INCDIR}/
> -       for dir in ${STAGING_DATADIR} ${STAGING_DATADIR_safe}; do
> -               ltdldir="${dir}/libtool/libltdl"
> -               install -d $dir/libtool \
> -                          $ltdldir \
> -                          $dir/aclocal
> -               install -c config.guess $dir/libtool/config.guess
> -               install -c config.sub $dir/libtool/config.sub
> -               install -c -m 0644 ltmain.sh $dir/libtool/
> -               install -c -m 0644 libtool.m4 $dir/aclocal/
> -               install -c -m 0644 ltdl.m4 $dir/aclocal/
> -
> -               for src in README COPYING.LIB Makefile.am configure.ac \
> -                               config-h.in ltdl.c ltdl.h; do
> -                       install -m 0644 libltdl/${src} ${ltdldir}
> -               done
> -       done
> +       install -d ${STAGING_DATADIR}/libtool ${STAGING_DATADIR}/aclocal
> +       install -c config.guess ${STAGING_DATADIR}/libtool/
> +       install -c config.sub ${STAGING_DATADIR}/libtool/
> +       install -c -m 0644 ltmain.sh ${STAGING_DATADIR}/libtool/
> +       install -c -m 0644 libtool.m4 ${STAGING_DATADIR}/aclocal/
> +       install -c -m 0644 ltdl.m4 ${STAGING_DATADIR}/aclocal/
>  }
>
>  do_install () {
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>
>



From skoroneos at digital-opsis.com  Tue May 15 08:10:29 2007
From: skoroneos at digital-opsis.com (Stelios Koroneos)
Date: Tue, 15 May 2007 11:10:29 +0300
Subject: [oe] minimal-image.bb
In-Reply-To: <f277n0$i00$2@sea.gmane.org>
Message-ID: <HOECLKEKOHLAMMGDLLBHGEIBLAAA.skoroneos@digital-opsis.com>

> -----Original Message-----
> From: openembedded-devel-bounces at openembedded.org
> [mailto:openembedded-devel-bounces at openembedded.org]On Behalf Of
> Rolf Leggewie
> Sent: Sunday, May 13, 2007 5:35 PM
> To: openembedded-devel at openembedded.org
> Subject: Re: [oe] minimal-image.bb
>
>
> Stelios Koroneos wrote:
> > In my opinion if angstrom-minimal-image is not distro specific should be
> > renamed to minimal-image
>
> I agree with Stelios that the belief that angstrom-minimal-image is a
> distro-specific image is a reasonable assumption.  If that is not the
> case, I am in favor renaming.


There is a bigger issue here than the name of package and that the reason i
brought this matter up.
Angstrom without any dough is the biggest distro supported by OE, but its
not the only one.
No one should also dough that Koen has done a lot of work (and is still
doing) and credits should go to him for a lot of the things in OE, including
the angstrom-minimal-image.bb, but i believe the real issue goes beyond the
developer/distro thing.

Actions like that, give the wrong signals to the people who are looking at
OE for incorporation/support of their products(and believe me there are
*alot* that do that as we speak)
If a distro maintainer (or any OE developer in that fact) comes with a way
of handling things better for his distro that could be used as a generic
framework for others it should be done so and not discouraged.

I am firm believer in community work and that things that could benefit the
OE community should be handled as such and not as distro-specific.






From no2spam at nospam.arcornews.de  Tue May 15 09:59:15 2007
From: no2spam at nospam.arcornews.de (Rolf Leggewie)
Date: Tue, 15 May 2007 11:59:15 +0200
Subject: [oe] minimal-image.bb
In-Reply-To: <HOECLKEKOHLAMMGDLLBHGEIBLAAA.skoroneos@digital-opsis.com>
References: <f277n0$i00$2@sea.gmane.org>
	<HOECLKEKOHLAMMGDLLBHGEIBLAAA.skoroneos@digital-opsis.com>
Message-ID: <f2c09j$8rd$1@sea.gmane.org>

Stelios Koroneos wrote:
> I am firm believer in community work and that things that could benefit the
> OE community should be handled as such and not as distro-specific.

I always thought that Angstrom was all about tearing walls down instead 
of building them up.

/me is baffled




From robin.farine at terminus.org  Tue May 15 11:22:39 2007
From: robin.farine at terminus.org (Robin Farine)
Date: Tue, 15 May 2007 13:22:39 +0200
Subject: [oe] RFC: machine customized ixp4xx NPE firmware
Message-ID: <200705151322.39110.robin.farine@terminus.org>

Hello everyone,

The platform I am working on is using NPE-B and NPE-C as Ethernet
interfaces. The ixp4xx-npe package from the OE snapshot I am 
currently
using builds firmware for NPE-B only and the firmware type is 
hard-coded
in "IxNpeMicrocode.h".

The patch below proposes a means of letting the machine 
configuration file
decide which NPE firmware to build.

Another but somewhat related point is the COMPATIBLE_MACHINE 
variable. If
my machine's name does not start with nslug or ixp4xx, I am forced 
to
change many package recipes (I suspect it is a FAQ but I do not seem 
to
able to access the mailing-list archive at the moment), perhaps a
COMPATIBLE_ARCH variable would be help here ?

Thanks,

Robin

diff --git 
a/packages/ixp4xx/ixp4xx-npe-native-2.3.2/IxNpeMicrocode.h 
b/packages/ixp4xx/ixp4xx-npe-native-2.3.2/IxNpeMicrocode.h
--- a/packages/ixp4xx/ixp4xx-npe-native-2.3.2/IxNpeMicrocode.h
+++ b/packages/ixp4xx/ixp4xx-npe-native-2.3.2/IxNpeMicrocode.h
@@ -42,7 +42,7 @@
 // #define IX_NPEDL_NPEIMAGE_NPEB_DMA
 // #define 
IX_NPEDL_NPEIMAGE_NPEB_ETH_SPAN_FIREWALL_VLAN_QOS_HDR_CONV
 // #define 
IX_NPEDL_NPEIMAGE_NPEB_ETH_LEARN_FILTER_SPAN_FIREWALL_VLAN_QOS
-#define IX_NPEDL_NPEIMAGE_NPEB_ETH_LEARN_FILTER_SPAN_FIREWALL
+// #define IX_NPEDL_NPEIMAGE_NPEB_ETH_LEARN_FILTER_SPAN_FIREWALL
 
 
 // #define 
IX_NPEDL_NPEIMAGE_NPEC_ETH_SPAN_MASK_FIREWALL_VLAN_QOS_HDR_CONV_EXTMIB
@@ -51,7 +51,7 @@
 // #define IX_NPEDL_NPEIMAGE_NPEC_DMA
 // #define IX_NPEDL_NPEIMAGE_NPEC_CRYPTO_AES_ETH_LEARN_FILTER_SPAN
 // #define 
IX_NPEDL_NPEIMAGE_NPEC_CRYPTO_AES_ETH_LEARN_FILTER_FIREWALL
-#define IX_NPEDL_NPEIMAGE_NPEC_CRYPTO_AES_CCM_ETH
+// #define IX_NPEDL_NPEIMAGE_NPEC_CRYPTO_AES_CCM_ETH
 // #define 
IX_NPEDL_NPEIMAGE_NPEC_CRYPTO_ETH_LEARN_FILTER_SPAN_FIREWALL
 // #define 
IX_NPEDL_NPEIMAGE_NPEC_ETH_SPAN_FIREWALL_VLAN_QOS_HDR_CONV
 // #define 
IX_NPEDL_NPEIMAGE_NPEC_ETH_LEARN_FILTER_SPAN_FIREWALL_VLAN_QOS
diff --git a/packages/ixp4xx/ixp4xx-npe-native_2.3.2.bb 
b/packages/ixp4xx/ixp4xx-npe-native_2.3.2.bb
--- a/packages/ixp4xx/ixp4xx-npe-native_2.3.2.bb
+++ b/packages/ixp4xx/ixp4xx-npe-native_2.3.2.bb
@@ -7,9 +7,14 @@ inherit native
 inherit native
 S = "${WORKDIR}/ixp400_xscale_sw/src/npeDl"
 
+# A space-separated list of CPP defines that select the firmware 
images
+# to build for the target machine.
+IXP4XX_NPE_FIRWMARE_DEFINES ?= "\
+-DIX_NPEDL_NPEIMAGE_NPEB_ETH_LEARN_FILTER_SPAN_FIREWALL"
+
 do_compile() {
 	mv ${WORKDIR}/IxNpeMicrocode.h ${S}/
-	gcc -Wall IxNpeMicrocode.c -o IxNpeMicrocode
+	gcc -Wall ${IXP4XX_NPE_FIRWMARE_DEFINES} IxNpeMicrocode.c -o 
IxNpeMicrocode
 }
 
 do_stage() {
diff --git a/packages/ixp4xx/ixp4xx-npe_2.3.2.bb 
b/packages/ixp4xx/ixp4xx-npe_2.3.2.bb
--- a/packages/ixp4xx/ixp4xx-npe_2.3.2.bb
+++ b/packages/ixp4xx/ixp4xx-npe_2.3.2.bb
@@ -13,7 +13,7 @@ S = "${WORKDIR}/ixp400_xscale_sw/src/npe
 
 COMPATIBLE_MACHINE = "(nslu2|ixp4xx)"
 
-FILES_${PN} = "${base_libdir}/firmware/NPE-B"
+FILES_${PN} = "${base_libdir}/firmware/NPE-*"
 
 do_compile() {
 	${STAGING_BINDIR_NATIVE}/IxNpeMicrocode-${PV} -be
@@ -21,13 +21,20 @@ do_compile() {
 
 do_install() {
 	install -d ${D}/${base_libdir}/firmware/
-	rm ${S}/NPE-B
-	mv ${S}/NPE-B.* ${S}/NPE-B
-	install ${S}/NPE-B ${D}/${base_libdir}/firmware/
+	for npe in A B C; do
+		rm ${S}/NPE-${npe} 2>/dev/null || true
+		mv ${S}/NPE-${npe}.* ${S}/NPE-${npe} 2>/dev/null || true
+		if test -f ${S}/NPE-${npe}; then
+			install -m 644 ${S}/NPE-${npe} ${D}/${base_libdir}/firmware/
+		fi
+	done
 }
 
 do_populate_staging() {
 	install -d ${STAGING_FIRMWARE_DIR}
-	install ${S}/NPE-B ${STAGING_FIRMWARE_DIR}/
+	for npe in A B C; do
+		if test -f ${S}/NPE-${npe}; then
+			install -m 644 ${S}/NPE-${npe} ${STAGING_FIRMWARE_DIR}/
+		fi
+	done
 }
-




From philip at balister.org  Tue May 15 11:47:07 2007
From: philip at balister.org (Philip Balister)
Date: Tue, 15 May 2007 07:47:07 -0400
Subject: [oe] Fixing up libtool-native and libtool-cross
In-Reply-To: <4648EB51.4040303@dominion.kabel.utwente.nl>
References: <4648EB51.4040303@dominion.kabel.utwente.nl>
Message-ID: <46499DBB.9080001@balister.org>

Can we apply these to the 1.5.22 libtool bb files also? I ahve added 
these with DEFAULT_PREFERENCE = "-1" since they have trouble building 
some packages, apparently due to looking in build system directories for 
libraries

Philip

Koen Kooi wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi,
> 
> Richard has fixed up libtool in Poky a bit and I want to merge his work into OE. Since
> it's 1 AM now, and libtool is a pretty 'core' part, I'm posting the patch for review
> before committing it tomorrow night.
> 
> regards,
> 
> Koen
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (Darwin)
> 
> iD8DBQFGSOtRMkyGM64RGpERAuiCAJ0Yqz+t4X/zNCjTbZIBU7yjaDt8twCgkgVq
> iM3uwQTciklpQKjurM34Nys=
> =W6UX
> -----END PGP SIGNATURE-----
> 
> 
> ------------------------------------------------------------------------
> 
> #
> # old_revision [990392a71744fa8ec062ee769a883473775269ee]
> #
> # patch "classes/autotools.bbclass"
> #  from [dced52fcafd4e224bafcb35c4fb04253857c7c3b]
> #    to [113ae9d1554b6e93d9c7a7fda84d71da4712caf9]
> # 
> # patch "packages/libtool/libtool-cross_1.5.10.bb"
> #  from [58b238af5bb9acdeca5b86c34b50c419fb49b55e]
> #    to [5134256c71b2d679838e87a55b084a99b1ac17d4]
> # 
> # patch "packages/libtool/libtool-native_1.5.10.bb"
> #  from [e1d2b08387782afbf7c5c6787a92d9af864dfb2d]
> #    to [bc799a0464069f3531cbb0a017c4d8d2a1afd63e]
> #
> ============================================================
> --- classes/autotools.bbclass	dced52fcafd4e224bafcb35c4fb04253857c7c3b
> +++ classes/autotools.bbclass	113ae9d1554b6e93d9c7a7fda84d71da4712caf9
> @@ -15,6 +15,10 @@ def autotools_dep_prepend(d):
>  
>  	if not pn in ['libtool', 'libtool-native', 'libtool-cross']:
>  		deps += 'libtool-native '
> +		if not bb.data.inherits_class('native', d) \
> +                        and not bb.data.inherits_class('cross', d) \
> +                        and not bb.data.getVar('INHIBIT_DEFAULT_DEPS', d, 1):
> +                    deps += 'libtool-cross '
>  
>  	return deps + 'gnu-config-native '
>  
> ============================================================
> --- packages/libtool/libtool-cross_1.5.10.bb	58b238af5bb9acdeca5b86c34b50c419fb49b55e
> +++ packages/libtool/libtool-cross_1.5.10.bb	5134256c71b2d679838e87a55b084a99b1ac17d4
> @@ -1,7 +1,7 @@ require libtool_${PV}.bb
>  SECTION = "devel"
>  require libtool_${PV}.bb
>  
> -PR = "r4"
> +PR = "r5"
>  PACKAGES = ""
>  FILESDIR = "${@os.path.dirname(bb.data.getVar('FILE',d,1))}/libtool-${PV}"
>  SRC_URI_append = " file://libdir-la.patch;patch=1 \
> @@ -21,6 +21,13 @@ do_stage () {
>  
>  do_stage () {
>          install -m 0755 ${HOST_SYS}-libtool ${bindir}/${HOST_SYS}-libtool
> +        install -m 0644 libltdl/ltdl.h ${STAGING_INCDIR}/
> +        install -d ${STAGING_DATADIR}/libtool ${STAGING_DATADIR}/aclocal
> +        install -c config.guess ${STAGING_DATADIR}/libtool/
> +        install -c config.sub ${STAGING_DATADIR}/libtool/
> +        install -c -m 0644 ltmain.sh ${STAGING_DATADIR}/libtool/
> +        install -c -m 0644 libtool.m4 ${STAGING_DATADIR}/aclocal/
> +        install -c -m 0644 ltdl.m4 ${STAGING_DATADIR}/aclocal/
>  }
>  
>  do_install () {
> ============================================================
> --- packages/libtool/libtool-native_1.5.10.bb	e1d2b08387782afbf7c5c6787a92d9af864dfb2d
> +++ packages/libtool/libtool-native_1.5.10.bb	bc799a0464069f3531cbb0a017c4d8d2a1afd63e
> @@ -1,7 +1,7 @@ require libtool_${PV}.bb
>  SECTION = "devel"
>  require libtool_${PV}.bb
>  
> -PR = "r4"
> +PR = "r5"
>  FILESDIR = "${@os.path.dirname(bb.data.getVar('FILE',d,1))}/libtool-${PV}"
>  SRC_URI_append = " file://libdir-la.patch;patch=1 \
>                     file://prefix.patch;patch=1 \
> @@ -10,8 +10,6 @@ S = "${WORKDIR}/libtool-${PV}"
>                     file://install-path-check.patch;patch=1"
>  S = "${WORKDIR}/libtool-${PV}"
>  
> -STAGING_DATADIR_safe := "${STAGING_DATADIR}"
> -
>  inherit native
>  
>  do_stage () {
> @@ -19,22 +17,12 @@ do_stage () {
>  	install -m 0755 libtoolize ${STAGING_BINDIR}/libtoolize
>  	oe_libinstall -a -so -C libltdl libltdl ${STAGING_LIBDIR}
>  	install -m 0644 libltdl/ltdl.h ${STAGING_INCDIR}/
> -	for dir in ${STAGING_DATADIR} ${STAGING_DATADIR_safe}; do
> -		ltdldir="${dir}/libtool/libltdl"
> -		install -d $dir/libtool \
> -			   $ltdldir \
> -			   $dir/aclocal
> -		install -c config.guess $dir/libtool/config.guess
> -		install -c config.sub $dir/libtool/config.sub
> -		install -c -m 0644 ltmain.sh $dir/libtool/
> -		install -c -m 0644 libtool.m4 $dir/aclocal/
> -		install -c -m 0644 ltdl.m4 $dir/aclocal/
> -
> -		for src in README COPYING.LIB Makefile.am configure.ac \
> -				config-h.in ltdl.c ltdl.h; do
> -			install -m 0644 libltdl/${src} ${ltdldir}
> -		done
> -	done
> +	install -d ${STAGING_DATADIR}/libtool ${STAGING_DATADIR}/aclocal
> +	install -c config.guess ${STAGING_DATADIR}/libtool/
> +	install -c config.sub ${STAGING_DATADIR}/libtool/
> +	install -c -m 0644 ltmain.sh ${STAGING_DATADIR}/libtool/
> +	install -c -m 0644 libtool.m4 ${STAGING_DATADIR}/aclocal/
> +	install -c -m 0644 ltdl.m4 ${STAGING_DATADIR}/aclocal/
>  }
>  
>  do_install () {
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3303 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.openembedded.org/pipermail/openembedded-devel/attachments/20070515/59453557/attachment-0002.bin>

From koen at dominion.kabel.utwente.nl  Tue May 15 12:53:17 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Tue, 15 May 2007 14:53:17 +0200
Subject: [oe] Fixing up libtool-native and libtool-cross
In-Reply-To: <46499DBB.9080001@balister.org>
References: <4648EB51.4040303@dominion.kabel.utwente.nl>
	<46499DBB.9080001@balister.org>
Message-ID: <4649AD3D.7070905@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Philip Balister schreef:
> Can we apply these to the 1.5.22 libtool bb files also? I ahve added
> these with DEFAULT_PREFERENCE = "-1" since they have trouble building
> some packages, apparently due to looking in build system directories for
> libraries

I pushed the updates to 1.5.10, could you fix 1.5.22?

TIA,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGSa09MkyGM64RGpERAiN+AJ0ZJTsW7GRLJi24EQy7QOpG1j0nGQCcDGq5
MGVDY5euyKwRk0sNTyg1Lag=
=3i/D
-----END PGP SIGNATURE-----



From leon.woestenberg at gmail.com  Tue May 15 18:38:37 2007
From: leon.woestenberg at gmail.com (Leon Woestenberg)
Date: Tue, 15 May 2007 20:38:37 +0200
Subject: [oe] RFC: machine customized ixp4xx NPE firmware
In-Reply-To: <200705151322.39110.robin.farine@terminus.org>
References: <200705151322.39110.robin.farine@terminus.org>
Message-ID: <c384c5ea0705151138n4087e20cx1f2971a69573091d@mail.gmail.com>

Hello Robin,

On 5/15/07, Robin Farine <robin.farine at terminus.org> wrote:
> +IXP4XX_NPE_FIRWMARE_DEFINES ?= "\
> +-DIX_NPEDL_NPEIMAGE_NPEB_ETH_LEARN_FILTER_SPAN_FIREWALL"
> +
>  do_compile() {
>         mv ${WORKDIR}/IxNpeMicrocode.h ${S}/
> -       gcc -Wall IxNpeMicrocode.c -o IxNpeMicrocode
> +       gcc -Wall ${IXP4XX_NPE_FIRWMARE_DEFINES} IxNpeMicrocode.c -o
>
Please change IXP4XX_NPE_FIRWMARE_DEFINES into IXP4X
IX_NPE_FIRMWARE_DEFINES.

The idea looks ok.

Regards,

Leon.



From robin.farine at terminus.org  Tue May 15 20:17:27 2007
From: robin.farine at terminus.org (Robin Farine)
Date: Tue, 15 May 2007 22:17:27 +0200
Subject: [oe] RFC: machine customized ixp4xx NPE firmware
In-Reply-To: <c384c5ea0705151138n4087e20cx1f2971a69573091d@mail.gmail.com>
References: <200705151322.39110.robin.farine@terminus.org>
	<c384c5ea0705151138n4087e20cx1f2971a69573091d@mail.gmail.com>
Message-ID: <200705152217.27815.rfarine@tilia.local>

On Tuesday May 15 2007 20:38, Leon Woestenberg wrote:
> On 5/15/07, Robin Farine <robin.farine at terminus.org> wrote:
> > +IXP4XX_NPE_FIRWMARE_DEFINES ?= "\
> > +-DIX_NPEDL_NPEIMAGE_NPEB_ETH_LEARN_FILTER_SPAN_FIREWALL"
> > +
> >  do_compile() {
> >         mv ${WORKDIR}/IxNpeMicrocode.h ${S}/
> > -       gcc -Wall IxNpeMicrocode.c -o IxNpeMicrocode
> > +       gcc -Wall ${IXP4XX_NPE_FIRWMARE_DEFINES}
> > IxNpeMicrocode.c -o
>
> Please change IXP4XX_NPE_FIRWMARE_DEFINES into IXP4X
> IX_NPE_FIRMWARE_DEFINES.

Ah, you mean s/FIRWMARE/FIRMWARE/, yes, makes sense :-). I'll fix 
this and submit the patch to the bug tracker.

> The idea looks ok.

Thanks for reviewing it.

Regards,

Robin



From rod at whitby.id.au  Wed May 16 01:24:07 2007
From: rod at whitby.id.au (Rod Whitby)
Date: Wed, 16 May 2007 10:54:07 +0930
Subject: [oe] RFC: machine customized ixp4xx NPE firmware
In-Reply-To: <200705151322.39110.robin.farine@terminus.org>
References: <200705151322.39110.robin.farine@terminus.org>
Message-ID: <464A5D37.4030401@whitby.id.au>

Robin Farine wrote:
> The platform I am working on is using NPE-B and NPE-C as Ethernet
> interfaces. The ixp4xx-npe package from the OE snapshot I am 
> currently
> using builds firmware for NPE-B only and the firmware type is 
> hard-coded
> in "IxNpeMicrocode.h".
> 
> The patch below proposes a means of letting the machine 
> configuration file
> decide which NPE firmware to build.

Thanks.  We'll be very happy to apply that patch.  I'll take a close
look at it tonight.

> Another but somewhat related point is the COMPATIBLE_MACHINE 
> variable. If
> my machine's name does not start with nslug or ixp4xx, I am forced 
> to
> change many package recipes (I suspect it is a FAQ but I do not seem 
> to
> able to access the mailing-list archive at the moment), perhaps a
> COMPATIBLE_ARCH variable would be help here ?

Which machine/arch are you using?  We can easily extend that
compatibility to include any other machines/archs that will use it.

-- Rod



From lenehan at twibble.org  Wed May 16 03:13:29 2007
From: lenehan at twibble.org (Jamie Lenehan)
Date: Wed, 16 May 2007 13:13:29 +1000
Subject: [oe] uclibc 0.9.29 recipe
In-Reply-To: <46461D72.4020206@dominion.kabel.utwente.nl>
References: <464613B3.8090003@dominion.kabel.utwente.nl>
	<46461B73.8070900@trolltech.com>
	<46461D72.4020206@dominion.kabel.utwente.nl>
Message-ID: <20070516031329.GA5205@twibble.org>

On Sat, May 12, 2007 at 10:02:58PM +0200, Koen Kooi wrote:
[...]
> I'll add it once I solved the linux-libc-headers problems. Machine and distro maintainers
> need to provide their parts of the uclibc configs to make it usefull, though.

Do we really need different distro based settings? It's always been a
bit annoying that some things will build with uclibc for one build
but not another due to differing uclibc settings - things are a lot
easier if there's only a single configuration.

For now I'd like to see a

  mtn -e mv uclibc-0.9.29/angstrom/uClibc.distro uclibc-0.9.29/uClibc.distro

and then only add distro based configuration if it turns out to be
really needed by some distro. This'll also gives us a default
configuration for people using other distros.

-- 
 Jamie Lenehan <lenehan at twibble.org>



From xjqian at gmail.com  Wed May 16 03:27:58 2007
From: xjqian at gmail.com (Junqian Gordon Xu)
Date: Tue, 15 May 2007 22:27:58 -0500
Subject: [oe] RFD: Bugzilla in general & bug triaging
In-Reply-To: <f29dkh$o3v$1@sea.gmane.org>
References: <1179059149.5404.3.camel@cimmeria.hyboria>	<f277j3$i00$1@sea.gmane.org>
	<f29dkh$o3v$1@sea.gmane.org>
Message-ID: <464A7A3E.9050905@gmail.com>

Rolf Leggewie wrote:
> I have asked and been granted greater powers on bugzilla.  There are 
> features which we don't use yet but which could aid in establishing a 
> sane workflow while rendering unnecessary the current clutches and 
> ad-hoc fixes.
>
> Bugzilla will be upgraded soon and no structural changes will be made 
> until that is completed.  But that leaves us some good time to think 
> about how this should be enhanced.
>   
two quibbles about the recent change in bugtracker
1) aligning left wastes lot of space on the right of the screen. I think 
the old "centered" scheme looks better.
2) "the Words field cannot be empty. You have to enter at lease on word 
in your search criteria". This is inconvenient for me to just browser 
the bugs.

> Things I'd like to see
> * confirmation flags
> * better documentation of workflow status (need to define it first)
> * assigning bugs (or if you prefer "Hey, please take a look")
> * link to some bug searches like the ones I send about 5 minutes ago
>    on the entry page
> * entry page clean-up (why two search fields?)
>   

> * removal of dead stuff (ZaurusKernel, Familiar)
>   
better hide them (sort of a archive in case some people want to dig into 
those) than remove
> Please add to the list.  The most important point is the second.  That 
> is what we should discuss.
>   
I agree on the necessity of the second point. Please have a list of 
best-practice/workflow rules (whatever they are) and hide the additional 
irrelevant features. A clean and uncluttered interface is also desirable.

Gordon



From lenehan at twibble.org  Wed May 16 05:16:01 2007
From: lenehan at twibble.org (Jamie Lenehan)
Date: Wed, 16 May 2007 15:16:01 +1000
Subject: [oe] uclibc 0.9.29 & SYS_SIGLIST
In-Reply-To: <464613B3.8090003@dominion.kabel.utwente.nl>
References: <464613B3.8090003@dominion.kabel.utwente.nl>
Message-ID: <20070516051600.GA5179@twibble.org>

Currently SYS_SIGLIST is disabled in uclibc but the site files all
say it's present. For the old uclibc version some of the
configurations enabled SYS_SIGLIST support and some didn't. We don't
really need it and the uclibc help says it's going to go away one day
so if no one objects I'll add the following site entries:

common-glibc

 bash_cv_under_sys_siglist=${bash_cv_under_sys_siglist=yes}
 bash_cv_sys_siglist=${bash_cv_sys_siglist=yes}
 ac_cv_have_decl_sys_siglist=${ac_cv_have_decl_sys_siglist=yes}

common-uclibc

 bash_cv_under_sys_siglist=${bash_cv_under_sys_siglist=no}
 bash_cv_sys_siglist=${bash_cv_sys_siglist=no}
 ac_cv_have_decl_sys_siglist=${ac_cv_have_decl_sys_siglist=no}

And remove the above entries from all the other site files.

This siglist things needs to be sorted out to build apr at least
(which is needed to build subversion).

-- 
 Jamie Lenehan <lenehan at twibble.org>



From leon.woestenberg at gmail.com  Wed May 16 07:26:22 2007
From: leon.woestenberg at gmail.com (Leon Woestenberg)
Date: Wed, 16 May 2007 09:26:22 +0200
Subject: [oe] uclibc 0.9.29 recipe
In-Reply-To: <20070516031329.GA5205@twibble.org>
References: <464613B3.8090003@dominion.kabel.utwente.nl>
	<46461B73.8070900@trolltech.com>
	<46461D72.4020206@dominion.kabel.utwente.nl>
	<20070516031329.GA5205@twibble.org>
Message-ID: <c384c5ea0705160026x5965bad9w9d2d0587ae574853@mail.gmail.com>

Hello Jamie,

On 5/16/07, Jamie Lenehan <lenehan at twibble.org> wrote:
> On Sat, May 12, 2007 at 10:02:58PM +0200, Koen Kooi wrote:

> For now I'd like to see a
>
>   mtn -e mv uclibc-0.9.29/angstrom/uClibc.distro uclibc-0.9.29/uClibc.distro
>
> and then only add distro based configuration if it turns out to be
> really needed by some distro. This'll also gives us a default
>
And that generic distro configuration would probably be a full
configuration (i.e. most options enabled) so that it would work for
most packages depending on C library functionality (or glibc
compatibility).

Distro's can optionally tune down the .distro by either:
- providing their own .distro
- mangling the resulting .config

Regards,
-- 
Leon



From koen at dominion.kabel.utwente.nl  Wed May 16 07:41:28 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Wed, 16 May 2007 09:41:28 +0200
Subject: [oe] uclibc 0.9.29 recipe
In-Reply-To: <20070516031329.GA5205@twibble.org>
References: <464613B3.8090003@dominion.kabel.utwente.nl>	<46461B73.8070900@trolltech.com>	<46461D72.4020206@dominion.kabel.utwente.nl>
	<20070516031329.GA5205@twibble.org>
Message-ID: <464AB5A8.8070500@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jamie Lenehan schreef:
> On Sat, May 12, 2007 at 10:02:58PM +0200, Koen Kooi wrote:
> [...]
>> I'll add it once I solved the linux-libc-headers problems. Machine and distro maintainers
>> need to provide their parts of the uclibc configs to make it usefull, though.
> 
> Do we really need different distro based settings? 

I tried to adhere to the existing uclibc infrastructure when adding 0.9.29, but maybe it's
time to rethink and overhaul it.

> It's always been a
> bit annoying that some things will build with uclibc for one build
> but not another due to differing uclibc settings - things are a lot
> easier if there's only a single configuration.
> 
> For now I'd like to see a
> 
>   mtn -e mv uclibc-0.9.29/angstrom/uClibc.distro uclibc-0.9.29/uClibc.distro

Fine by me, could you do that?

> and then only add distro based configuration if it turns out to be
> really needed by some distro. This'll also gives us a default
> configuration for people using other distros.

And gives us a better way to keep our site-files in sync.

regards,

Koen

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGSrWoMkyGM64RGpERAnrXAJwJFcLlBdZpiwEsf1Uw8DBL9agFtgCaA0ny
EleWYKtPe+qa1D9PIgGiJps=
=ByLX
-----END PGP SIGNATURE-----



From robin.farine at terminus.org  Wed May 16 08:56:46 2007
From: robin.farine at terminus.org (Robin Farine)
Date: Wed, 16 May 2007 10:56:46 +0200
Subject: [oe] RFC: machine customized ixp4xx NPE firmware
In-Reply-To: <464A5D37.4030401@whitby.id.au>
References: <200705151322.39110.robin.farine@terminus.org>
	<464A5D37.4030401@whitby.id.au>
Message-ID: <200705161056.46551.robin.farine@terminus.org>

On Wed May 16 2007 03:24, Rod Whitby wrote:
> Robin Farine wrote:

> > The patch below proposes a means of letting the machine
> > configuration file
> > decide which NPE firmware to build.
>
> Thanks.  We'll be very happy to apply that patch.  I'll take a
> close look at it tonight.

I forgot to disable line wrapping when I reposted it to the correct 
mailing-list... You may prefer to have a look at the cleaner 
version in bugzilla.

> Which machine/arch are you using?  We can easily extend that
> compatibility to include any other machines/archs that will use
> it.

Its a custom ixp425 big-endian board of which 2 functional exemplars 
currently exist :-). Not a problem, I just wondered whether 
something like COMPATIBLE_ARCH exists.

Robin



From rpurdie at rpsys.net  Wed May 16 10:44:45 2007
From: rpurdie at rpsys.net (Richard Purdie)
Date: Wed, 16 May 2007 11:44:45 +0100
Subject: [oe] RFC: machine customized ixp4xx NPE firmware
In-Reply-To: <464A5D37.4030401@whitby.id.au>
References: <200705151322.39110.robin.farine@terminus.org>
	<464A5D37.4030401@whitby.id.au>
Message-ID: <1179312285.5854.2.camel@localhost.localdomain>

On Wed, 2007-05-16 at 10:54 +0930, Rod Whitby wrote:
> Robin Farine wrote:
> > Another but somewhat related point is the COMPATIBLE_MACHINE 
> > variable. If
> > my machine's name does not start with nslug or ixp4xx, I am forced 
> > to
> > change many package recipes (I suspect it is a FAQ but I do not seem 
> > to
> > able to access the mailing-list archive at the moment), perhaps a
> > COMPATIBLE_ARCH variable would be help here ?
> 
> Which machine/arch are you using?  We can easily extend that
> compatibility to include any other machines/archs that will use it.

A neat way to handle this might be to define:

IXPMACHINES = "nslu2|ixp4xx|whatever"

and then the ixp specific .bb's check IXPMACHINES rather than a specific
list. The list would then be maintained in one place and is easily
updated if anyone adds a new ixp like machine.

I've not looked at the specifics, its just a random idea I had...

Cheers,

Richard







From golly at stellarwerx.com  Wed May 16 14:32:20 2007
From: golly at stellarwerx.com (Mark Gollahon)
Date: Wed, 16 May 2007 10:32:20 -0400 (EDT)
Subject: [oe] RFC: machine customized ixp4xx NPE firmware
Message-ID: <1179325940.4167@gatekeeper.stellarwerx.com>

Richard Purdie wrote ..
> 
> A neat way to handle this might be to define:
> 
> IXPMACHINES = "nslu2|ixp4xx|whatever"
> 
> and then the ixp specific .bb's check IXPMACHINES rather than a specific
> list. The list would then be maintained in one place and is easily
> updated if anyone adds a new ixp like machine.
> 
> I've not looked at the specifics, its just a random idea I had...
> 
> Cheers,
> 
> Richard

I want to second this approach as I tried awhile back to build OE for an IXP4XX-based machine that came into my possession and, during that time, ended up patching several IXP-specific .bb's to add my new machine.  My work would have been much easier had IXPMACHINES existed.

(NOTE: I did get it almost completely working, the only problem ended up being the networking ports didn't work, which, for a firewall machine, meant the device was useless.  There is an IC175 switch chip sitting between the IXP's two network ports and the physical ports and I couldn't figure out how to hack the IXP net driver to get the IC175 to pass eth frames.)

Regards,
-Mark Gollahon

From koen at dominion.kabel.utwente.nl  Thu May 17 08:01:53 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Thu, 17 May 2007 10:01:53 +0200
Subject: [oe] Questions about SDK generation
Message-ID: <464C0BF1.60300@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

During the build build of gcc-cross-sdk I noticed this:

NOTE: Running task 280 of 284 (ID: 5,
/home/koen/OE/monotone/org.openembedded.dev/packages/gcc/gcc-cross-sdk_4.1.2.bb, do_package)
NOTE: package gcc-cross-sdk-4.1.2: started
NOTE: package gcc-cross-sdk-4.1.2-r3: task do_package: started
NOTE: the following files were installed but not shipped in any package:
NOTE:   /usr/local/arm/oe/libexec/gcc/arm-angstrom-linux-gnueabi/4.1.2/install-tools/fixinc.sh
NOTE:   /usr/local/arm/oe/libexec/gcc/arm-angstrom-linux-gnueabi/4.1.2/install-tools/fixincl
NOTE:   /usr/local/arm/oe/libexec/gcc/arm-angstrom-linux-gnueabi/4.1.2/install-tools/mkheaders
NOTE:   /usr/local/arm/oe/lib/libiberty.a
NOTE:   /usr/local/arm/oe/lib/gcc/arm-angstrom-linux-gnueabi/4.1.2/install-tools/gsyslimits.h
NOTE:   /usr/local/arm/oe/lib/gcc/arm-angstrom-linux-gnueabi/4.1.2/install-tools/macro_list
NOTE:
/usr/local/arm/oe/lib/gcc/arm-angstrom-linux-gnueabi/4.1.2/install-tools/mkheaders.conf
NOTE:
/usr/local/arm/oe/lib/gcc/arm-angstrom-linux-gnueabi/4.1.2/install-tools/include/README
NOTE:
/usr/local/arm/oe/lib/gcc/arm-angstrom-linux-gnueabi/4.1.2/install-tools/include/float.h
NOTE:
/usr/local/arm/oe/lib/gcc/arm-angstrom-linux-gnueabi/4.1.2/install-tools/include/iso646.h
NOTE:
/usr/local/arm/oe/lib/gcc/arm-angstrom-linux-gnueabi/4.1.2/install-tools/include/stdarg.h
NOTE:
/usr/local/arm/oe/lib/gcc/arm-angstrom-linux-gnueabi/4.1.2/install-tools/include/stdbool.h
NOTE:
/usr/local/arm/oe/lib/gcc/arm-angstrom-linux-gnueabi/4.1.2/install-tools/include/stddef.h
NOTE:
/usr/local/arm/oe/lib/gcc/arm-angstrom-linux-gnueabi/4.1.2/install-tools/include/varargs.h
NOTE:
/usr/local/arm/oe/lib/gcc/arm-angstrom-linux-gnueabi/4.1.2/install-tools/include/mmintrin.h
NOTE:
/usr/local/arm/oe/lib/gcc/arm-angstrom-linux-gnueabi/4.1.2/install-tools/include/limits.h
NOTE:
/usr/local/arm/oe/lib/gcc/arm-angstrom-linux-gnueabi/4.1.2/install-tools/include/unwind.h
NOTE:   /usr/local/arm/oe/bin/arm-angstrom-linux-gnueabi-c++
NOTE:   /usr/local/arm/oe/bin/arm-angstrom-linux-gnueabi-gcc-4.1.2
NOTE:   /usr/local/arm/oe/include/mf-runtime.h
NOTE:   /usr/local/arm/oe/arm-angstrom-linux-gnueabi/lib/libsupc++.la
NOTE:   /usr/local/arm/oe/arm-angstrom-linux-gnueabi/lib/libsupc++.a
NOTE:   /usr/local/arm/oe/arm-angstrom-linux-gnueabi/lib/libstdc++_pic.a
NOTE:   /usr/local/arm/oe/arm-angstrom-linux-gnueabi/lib/libstdc++.la
NOTE:   /usr/local/arm/oe/arm-angstrom-linux-gnueabi/lib/libstdc++.a
NOTE:   /usr/local/arm/oe/arm-angstrom-linux-gnueabi/lib/libmudflap.so.0.0.0
NOTE:   /usr/local/arm/oe/arm-angstrom-linux-gnueabi/lib/libmudflap.la
NOTE:   /usr/local/arm/oe/arm-angstrom-linux-gnueabi/lib/libmudflap.a
NOTE:   /usr/local/arm/oe/arm-angstrom-linux-gnueabi/lib/libmudflapth.so.0.0.0
NOTE:   /usr/local/arm/oe/arm-angstrom-linux-gnueabi/lib/libmudflapth.la
NOTE:   /usr/local/arm/oe/arm-angstrom-linux-gnueabi/lib/libmudflapth.a
NOTE:   /usr/local/arm/oe/arm-angstrom-linux-gnueabi/lib/libiberty.a
NOTE:   /usr/local/arm/oe/arm-angstrom-linux-gnueabi/lib/libgcc_s.so
NOTE:   /usr/local/arm/oe/arm-angstrom-linux-gnueabi/lib/libstdc++.so
NOTE:   /usr/local/arm/oe/arm-angstrom-linux-gnueabi/lib/libmudflap.so.0
NOTE:   /usr/local/arm/oe/arm-angstrom-linux-gnueabi/lib/libmudflap.so
NOTE:   /usr/local/arm/oe/arm-angstrom-linux-gnueabi/lib/libmudflapth.so.0
NOTE:   /usr/local/arm/oe/arm-angstrom-linux-gnueabi/lib/libmudflapth.so

Is that intended?

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGTAvxMkyGM64RGpERAmi6AJ4vD8WTFN8JxW3K+3F4PGS0xlv9wACgsB9T
zZFHohWjeI8dRPcnGyrWypY=
=+uw+
-----END PGP SIGNATURE-----



From damwid at gmail.com  Fri May 18 12:08:40 2007
From: damwid at gmail.com (DAMWID)
Date: Fri, 18 May 2007 20:08:40 +0800
Subject: [oe] oe build failed
Message-ID: <464D9748.9000908@gmail.com>

Hi all,

I use OE to build rootfs for PXA270 board, but failed when compile
glibc, the following is error log:

[...]
| make[2]: Entering directory
`/work/bulvder/oe/build/tmp/work/armv5te-linux-gnueabi/glibc-2.3.5+cvs20050627-r13/libc/resource'
| ccache arm-linux-gnueabi-gcc -march=armv5te -mtune=xscale
../ports/sysdeps/unix/sysv/linux/arm/getrlimit.c -c -std=gnu99 -O2 -Wall
-Winline -Wstrict-prototypes -Wwrite-strings -fexpensive-optimizations
-frename-registers
-isystem/opt/arm-linux-gnueabi/arm-linux-gnueabi/include
-fomit-frame-pointer -I../include -I.
-I/work/bulvder/oe/build/tmp/work/armv5te-linux-gnueabi/glibc-2.3.5+cvs20050627-r13/build-arm-linux-gnueabi/resource
-I.. -I../libio
-I/work/bulvder/oe/build/tmp/work/armv5te-linux-gnueabi/glibc-2.3.5+cvs20050627-r13/build-arm-linux-gnueabi
-I../ports/sysdeps/arm/elf
-I../ports/sysdeps/unix/sysv/linux/arm/linuxthreads
-I../ports/sysdeps/unix/sysv/linux/arm
-I../ports/sysdeps/unix/sysv/linux -I../ports/sysdeps/unix/sysv
-I../ports/sysdeps/unix/arm -I../ports/sysdeps/unix
-I../ports/sysdeps/arm/linuxthreads -I../ports/sysdeps/arm
-I../sysdeps/wordsize-32 -I../sysdeps/ieee754/flt-32
-I../sysdeps/ieee754/dbl-64 -I../linuxthreads/sysdeps/unix/sysv/linux
-I../linuxthreads/sysdeps/pthread -I../sysdeps/pthread
-I../linuxthreads/sysdeps/unix/sysv -I../linuxthreads/sysdeps/unix
-I../sysdeps/unix/sysv/linux -I../sysdeps/gnu -I../sysdeps/unix/common
-I../sysdeps/unix/mman -I../sysdeps/unix/inet -I../sysdeps/unix/sysv
-I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/ieee754
-I../sysdeps/generic/elf -I../sysdeps/generic -nostdinc -isystem
/opt/arm-linux-gnueabi/lib/gcc/arm-linux-gnueabi/4.1.1/include -isystem
/opt/arm-linux-gnueabi/arm-linux-gnueabi/include -D_LIBC_REENTRANT
-include ../include/libc-symbols.h -o
/work/bulvder/oe/build/tmp/work/armv5te-linux-gnueabi/glibc-2.3.5+cvs20050627-r13/build-arm-linux-gnueabi/resource/getrlimit.o
-MD -MP -MF
/work/bulvder/oe/build/tmp/work/armv5te-linux-gnueabi/glibc-2.3.5+cvs20050627-r13/build-arm-linux-gnueabi/resource/getrlimit.o.dt
-MT
/work/bulvder/oe/build/tmp/work/armv5te-linux-gnueabi/glibc-2.3.5+cvs20050627-r13/build-arm-linux-gnueabi/resource/getrlimit.o
| In file included from ../ports/sysdeps/unix/sysv/linux/arm/getrlimit.c:1:
| ../sysdeps/unix/sysv/linux/i386/getrlimit.c: In function
'__new_getrlimit':
| ../sysdeps/unix/sysv/linux/i386/getrlimit.c:65: error:
'__NR_getrlimit' undeclared (first use in this function)
| ../sysdeps/unix/sysv/linux/i386/getrlimit.c:65: error: (Each
undeclared identifier is reported only once
| ../sysdeps/unix/sysv/linux/i386/getrlimit.c:65: error: for each
function it appears in.)
| make[2]: ***
[/work/bulvder/oe/build/tmp/work/armv5te-linux-gnueabi/glibc-2.3.5+cvs20050627-r13/build-arm-linux-gnueabi/resource/getrlimit.o]
Error 1
| make[2]: Leaving directory
`/work/bulvder/oe/build/tmp/work/armv5te-linux-gnueabi/glibc-2.3.5+cvs20050627-r13/libc/resource'
| make[1]: *** [resource/subdir_lib] Error 2
| make[1]: Leaving directory
`/work/bulvder/oe/build/tmp/work/armv5te-linux-gnueabi/glibc-2.3.5+cvs20050627-r13/libc'
| make: *** [all] Error 2
| FATAL: oe_runmake failed
NOTE: Task failed:
/work/bulvder/oe/build/tmp/work/armv5te-linux-gnueabi/glibc-2.3.5+cvs20050627-r13/temp/log.do_compile.17022
NOTE: package glibc-2.3.5+cvs20050627-r13: task do_compile: failed
ERROR: TaskFailed event exception, aborting
NOTE: package glibc-2.3.5+cvs20050627: failed

Does anyone know what is the problem? Attachment is my local.conf.

Thanks,
Damwid

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: local.conf
URL: <http://lists.openembedded.org/pipermail/openembedded-devel/attachments/20070518/dd30f3c3/attachment-0002.ksh>

From koen at dominion.kabel.utwente.nl  Fri May 18 12:36:49 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Fri, 18 May 2007 14:36:49 +0200
Subject: [oe] oe build failed
In-Reply-To: <464D9748.9000908@gmail.com>
References: <464D9748.9000908@gmail.com>
Message-ID: <464D9DE1.8000700@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

DAMWID schreef:
> Hi all,
> 
> I use OE to build rootfs for PXA270 board, but failed when compile
> glibc, the following is error log:

Use the local.conf from http://www.angstrom-distribution.org/building-angstrom

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGTZ3hMkyGM64RGpERAmXOAJsEMKrOhU5Z90hWZkVpQmk6QP7IlwCgrFnV
dw5F8T02dKoMip7pUr/ys1c=
=0Ux5
-----END PGP SIGNATURE-----



From rpurdie at rpsys.net  Sat May 19 17:50:15 2007
From: rpurdie at rpsys.net (Richard Purdie)
Date: Sat, 19 May 2007 18:50:15 +0100
Subject: [oe] do_rootfs fails
In-Reply-To: <4644B4D1.5010803@klever.net>
References: <4644ABCB.6080202@openhardware.net>
	<4644B0D2.8020409@dominion.kabel.utwente.nl>
	<4644B4D1.5010803@klever.net>
Message-ID: <1179597015.5852.5.camel@localhost.localdomain>

On Fri, 2007-05-11 at 20:24 +0200, Michael Krelin wrote:
> There's also an option of asking Tom to bitbake -DDD and send it to
> zecke, because I couldn't find time to try BB 1.6 for him again. And let
> him apply the patch that fixes this problem:
> 
> Index: lib/bb/parse/parse_py/BBHandler.py
> ===================================================================
> --- lib/bb/parse/parse_py/BBHandler.py  (revision 817)
> +++ lib/bb/parse/parse_py/BBHandler.py  (working copy)
> @@ -66,7 +66,9 @@
>          if not file in __inherit_cache.split():
>              debug(2, "BB %s:%d: inheriting %s" % (fn, lineno, file))
>              __inherit_cache += " %s" % file
> +            data.setVar('__inherit_cache', __inherit_cache, d)
>              include(fn, file, d)
> +            __inherit_cache = data.getVar('__inherit_cache', d) or ""
>      data.setVar('__inherit_cache', __inherit_cache, d)

Thanks for this, I've merged into bitbake 1.9, 1.8 and 1.6 branches as
they all had this issue!

Cheers,

Richard





From koen at dominion.kabel.utwente.nl  Sat May 19 17:58:32 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Sat, 19 May 2007 19:58:32 +0200
Subject: [oe] RFC: make do_install and do_deploy a PACKAGE_FUNC
In-Reply-To: <463C9EA9.2060302@dominion.kabel.utwente.nl>
References: <463C9EA9.2060302@dominion.kabel.utwente.nl>
Message-ID: <464F3AC8.5000804@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Koen Kooi schreef:
> Hi,
> 
> Lately there have been several problems with files not getting packaged, because users
> resumed builds after a failure. Richard has come up with a fix:
> 
> http://www.rpsys.net/openzaurus/temp/oe-install-change.patch
> 
> The only bug with that patch is that do_deploy fails, which can be solved by making that a
>  PACKAGE_FUNC as well.
> 
> What do you think about that?

So this is bugfree and can go in immediately?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGTzrIMkyGM64RGpERAnN8AJ9NQh73txV4w4h4FyCp8+Zj95R7UQCcChwH
ti0bnbez4K1Iqgbt+futJ4A=
=1Jkw
-----END PGP SIGNATURE-----



From rpurdie at rpsys.net  Sat May 19 20:13:01 2007
From: rpurdie at rpsys.net (Richard Purdie)
Date: Sat, 19 May 2007 21:13:01 +0100
Subject: [oe] RFC: make do_install and do_deploy a PACKAGE_FUNC
In-Reply-To: <464F3AC8.5000804@dominion.kabel.utwente.nl>
References: <463C9EA9.2060302@dominion.kabel.utwente.nl>
	<464F3AC8.5000804@dominion.kabel.utwente.nl>
Message-ID: <1179605582.5852.9.camel@localhost.localdomain>

On Sat, 2007-05-19 at 19:58 +0200, Koen Kooi wrote:
> Koen Kooi schreef:
> > Hi,
> > 
> > Lately there have been several problems with files not getting packaged, because users
> > resumed builds after a failure. Richard has come up with a fix:
> > 
> > http://www.rpsys.net/openzaurus/temp/oe-install-change.patch
> > 
> > The only bug with that patch is that do_deploy fails, which can be solved by making that a
> >  PACKAGE_FUNC as well.
> > 
> > What do you think about that?
> 
> So this is bugfree and can go in immediately?

I'm in two minds about this.

An alternative is we stop populate_packages() moving files around,
copying them instead. This means deploy can run after install, install
can be a separate task and builds should continue where they left of if
interrupted during the packaging phase.

Opinions?

Richard




From leon.woestenberg at gmail.com  Sun May 20 15:45:56 2007
From: leon.woestenberg at gmail.com (Leon Woestenberg)
Date: Sun, 20 May 2007 17:45:56 +0200
Subject: [oe] RFC: make do_install and do_deploy a PACKAGE_FUNC
In-Reply-To: <1179605582.5852.9.camel@localhost.localdomain>
References: <463C9EA9.2060302@dominion.kabel.utwente.nl>
	<464F3AC8.5000804@dominion.kabel.utwente.nl>
	<1179605582.5852.9.camel@localhost.localdomain>
Message-ID: <c384c5ea0705200845w36cf4274x6b22f03cdf01506d@mail.gmail.com>

Hello,

On 5/19/07, Richard Purdie <rpurdie at rpsys.net> wrote:
> An alternative is we stop populate_packages() moving files around,
> copying them instead. This means deploy can run after install, install
> can be a separate task and builds should continue where they left of if
> interrupted during the packaging phase.
>
> Opinions?
>
Looks sane to me.

Leon.



From ulf at atmel.com  Sat May 26 21:07:51 2007
From: ulf at atmel.com (Ulf Samuelsson)
Date: Sat, 26 May 2007 23:07:51 +0200
Subject: [oe] OpenEmbedded insist on downloading existing package
Message-ID: <00b801c79fd9$ee494f90$0302a8c0@atmel.com>

I have defined the download location to and
I have linux-2.6.21.1.tar.bz2 in this directory.

OpenEmbedded seems to ignore this and insists on *downloading*
linux-2.6.21.1.tar.bz2 before use.

- This is no fun.

Anything that can be done?


Best Regards
Ulf Samuelsson




From freyther at gmx.net  Sun May 20 21:47:58 2007
From: freyther at gmx.net (Holger Freyther)
Date: Sun, 20 May 2007 23:47:58 +0200
Subject: [oe] OpenEmbedded insist on downloading existing package
In-Reply-To: <00b801c79fd9$ee494f90$0302a8c0@atmel.com>
References: <00b801c79fd9$ee494f90$0302a8c0@atmel.com>
Message-ID: <66584307-3DAA-4B3C-8A5F-32915D6FF1EC@gmx.net>


Am 26.05.2007 um 23:07 schrieb Ulf Samuelsson:

> I have defined the download location to and
> I have linux-2.6.21.1.tar.bz2 in this directory.
>
> OpenEmbedded seems to ignore this and insists on *downloading*
> linux-2.6.21.1.tar.bz2 before use.
>
> - This is no fun.
>
> Anything that can be done?

Well,

you play with the guts and hope it is working. First you need to have  
a filename.md5 in the same directory otherwise the fetcher will  
continue fetching (this is what you see) and then you might need to  
add a fetched stamp. As this stamp gets created  when the md5sum/ 
sha256sum was verified.


I don't know your reasoning but there must be a better answer to your  
problem.

z.





From koen at dominion.kabel.utwente.nl  Sun May 20 21:48:21 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Sun, 20 May 2007 23:48:21 +0200
Subject: [oe] OpenEmbedded insist on downloading existing package
In-Reply-To: <00b801c79fd9$ee494f90$0302a8c0@atmel.com>
References: <00b801c79fd9$ee494f90$0302a8c0@atmel.com>
Message-ID: <4650C225.9010907@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ulf Samuelsson schreef:
> I have defined the download location to and
> I have linux-2.6.21.1.tar.bz2 in this directory.

is linux-2.6.21.1.tar.bz2.md5 present there?

> OpenEmbedded seems to ignore this and insists on *downloading*
> linux-2.6.21.1.tar.bz2 before use.

if the md5 stamp isn't present it will try to download it again till the downloads
completes and linux-2.6.21.1.tar.bz2.md5 has been created.

> - This is no fun.
> 
> Anything that can be done?

See above.

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGUMIlMkyGM64RGpERAus1AKCLYQPDm8IRkOCvT3TqF/UFWiOCogCfdf2T
W/f6t+bzYKRlzcnbqhs2yYA=
=cJI9
-----END PGP SIGNATURE-----



From ulf at atmel.com  Mon May 21 06:14:43 2007
From: ulf at atmel.com (Ulf Samuelsson)
Date: Mon, 21 May 2007 08:14:43 +0200
Subject: [oe] OpenEmbedded insist on downloading existing package
References: <00b801c79fd9$ee494f90$0302a8c0@atmel.com>
	<4650C225.9010907@dominion.kabel.utwente.nl>
Message-ID: <005201c79b6f$56130270$0302a8c0@atmel.com>

> Ulf Samuelsson schreef:
>> I have defined the download location to and
>> I have linux-2.6.21.1.tar.bz2 in this directory.
> 
> is linux-2.6.21.1.tar.bz2.md5 present there?
> 
>> OpenEmbedded seems to ignore this and insists on *downloading*
>> linux-2.6.21.1.tar.bz2 before use.
> 
> if the md5 stamp isn't present it will try to download it again till the downloads
> completes and linux-2.6.21.1.tar.bz2.md5 has been created.
> 


Thanks, I will try this...

Best Regards
Ulf Samuelsson




From koen at dominion.kabel.utwente.nl  Mon May 21 07:56:09 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Mon, 21 May 2007 09:56:09 +0200
Subject: [oe] RFC: make do_install and do_deploy a PACKAGE_FUNC
In-Reply-To: <1179605582.5852.9.camel@localhost.localdomain>
References: <463C9EA9.2060302@dominion.kabel.utwente.nl>	<464F3AC8.5000804@dominion.kabel.utwente.nl>
	<1179605582.5852.9.camel@localhost.localdomain>
Message-ID: <46515099.6070006@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Richard Purdie schreef:
> On Sat, 2007-05-19 at 19:58 +0200, Koen Kooi wrote:
>> Koen Kooi schreef:
>>> Hi,
>>>
>>> Lately there have been several problems with files not getting packaged, because users
>>> resumed builds after a failure. Richard has come up with a fix:
>>>
>>> http://www.rpsys.net/openzaurus/temp/oe-install-change.patch
>>>
>>> The only bug with that patch is that do_deploy fails, which can be solved by making that a
>>>  PACKAGE_FUNC as well.
>>>
>>> What do you think about that?
>> So this is bugfree and can go in immediately?
> 
> I'm in two minds about this.
> 
> An alternative is we stop populate_packages() moving files around,
> copying them instead. This means deploy can run after install, install
> can be a separate task and builds should continue where they left of if
> interrupted during the packaging phase.
> 
> Opinions?

The copy-don't-move approach sounds good.

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGUVCZMkyGM64RGpERAoEMAJ4rFonlztzdou+L5L79M1Rk1hzn8gCePSjP
qXJHJlIfgDOSd+SkD1Bei1c=
=mo1f
-----END PGP SIGNATURE-----



From france at handhelds.org  Sun May 20 22:48:30 2007
From: france at handhelds.org (George France)
Date: Sun, 20 May 2007 18:48:30 -0400
Subject: [oe] baned from #OE IRC channel
Message-ID: <200705201848.30692.france@handhelds.org>

Hello,

This afternoon on Sunday May 20th, 2007 at about 18:30 EST (GMT-5) while on 
the #oe channel, I was banned by Kergoth for no apparent reason.  I had not 
said a single word, I was just listening like I always do.

What is going on?

--George



From ulf at atmel.com  Mon May 21 19:15:58 2007
From: ulf at atmel.com (Ulf Samuelsson)
Date: Mon, 21 May 2007 21:15:58 +0200
Subject: [oe] ERROR: Task 2246 ( ...
 org.openembedded.dev/packages/gnome/gnome-desktop_2.16.1.bb,
 do_compile) failed
Message-ID: <4651EFEE.50907@atmel.com>

Looks like there is an issue with the fdl.xml in this package?
Any workarounds?



NOTE: Running task 2742 of 3946 (ID: 2246, /home/ulf/projects/OpenEmbedded/org.openembedded.dev/packages/gnome/gnome-desktop_2.16.1.bb, do_compile)
NOTE: package gnome-desktop-2.16.1: started
NOTE: package gnome-desktop-2.16.1-r1: task do_compile: started
ERROR: function do_compile failed
ERROR: log data follows (/home/ulf/projects/OpenEmbedded/build/tmp/work/armv5te-angstrom-linux-gnueabi/gnome-desktop-2.16.1-r1/temp/log.do_compile.24525)
| NOTE: make
| make  all-recursive
| make[1]: Entering directory `/home/ulf/projects/OpenEmbedded/build/tmp/work/armv5te-angstrom-linux-gnueabi/gnome-desktop-2.16.1-r1/gnome-desktop-2.16.1'
| Making all in po
| make[2]: Entering directory `/home/ulf/projects/OpenEmbedded/build/tmp/work/armv5te-angstrom-linux-gnueabi/gnome-desktop-2.16.1-r1/gnome-desktop-2.16.1/po'
| make[2]: Nothing to be done for `all'.
| make[2]: Leaving directory `/home/ulf/projects/OpenEmbedded/build/tmp/work/armv5te-angstrom-linux-gnueabi/gnome-desktop-2.16.1-r1/gnome-desktop-2.16.1/po'
| Making all in libgnome-desktop
| make[2]: Entering directory `/home/ulf/projects/OpenEmbedded/build/tmp/work/armv5te-angstrom-linux-gnueabi/gnome-desktop-2.16.1-r1/gnome-desktop-2.16.1/libgnome-desktop'
| Making all in libgnome
| make[3]: Entering directory `/home/ulf/projects/OpenEmbedded/build/tmp/work/armv5te-angstrom-linux-gnueabi/gnome-desktop-2.16.1-r1/gnome-desktop-2.16.1/libgnome-desktop/libgnome'
| make[3]: Nothing to be done for `all'.
| make[3]: Leaving directory `/home/ulf/projects/OpenEmbedded/build/tmp/work/armv5te-angstrom-linux-gnueabi/gnome-desktop-2.16.1-r1/gnome-desktop-2.16.1/libgnome-desktop/libgnome'
| Making all in libgnomeui
| make[3]: Entering directory `/home/ulf/projects/OpenEmbedded/build/tmp/work/armv5te-angstrom-linux-gnueabi/gnome-desktop-2.16.1-r1/gnome-desktop-2.16.1/libgnome-desktop/libgnomeui'
| make[3]: Nothing to be done for `all'.
| make[3]: Leaving directory `/home/ulf/projects/OpenEmbedded/build/tmp/work/armv5te-angstrom-linux-gnueabi/gnome-desktop-2.16.1-r1/gnome-desktop-2.16.1/libgnome-desktop/libgnomeui'
| make[3]: Entering directory `/home/ulf/projects/OpenEmbedded/build/tmp/work/armv5te-angstrom-linux-gnueabi/gnome-desktop-2.16.1-r1/gnome-desktop-2.16.1/libgnome-desktop'
| make[3]: Nothing to be done for `all-am'.
| make[3]: Leaving directory `/home/ulf/projects/OpenEmbedded/build/tmp/work/armv5te-angstrom-linux-gnueabi/gnome-desktop-2.16.1-r1/gnome-desktop-2.16.1/libgnome-desktop'
| make[2]: Leaving directory `/home/ulf/projects/OpenEmbedded/build/tmp/work/armv5te-angstrom-linux-gnueabi/gnome-desktop-2.16.1-r1/gnome-desktop-2.16.1/libgnome-desktop'
| Making all in gnome-about
| make[2]: Entering directory `/home/ulf/projects/OpenEmbedded/build/tmp/work/armv5te-angstrom-linux-gnueabi/gnome-desktop-2.16.1-r1/gnome-desktop-2.16.1/gnome-about'
| Making all in headers
| make[3]: Entering directory `/home/ulf/projects/OpenEmbedded/build/tmp/work/armv5te-angstrom-linux-gnueabi/gnome-desktop-2.16.1-r1/gnome-desktop-2.16.1/gnome-about/headers'
| make[3]: Nothing to be done for `all'.
| make[3]: Leaving directory `/home/ulf/projects/OpenEmbedded/build/tmp/work/armv5te-angstrom-linux-gnueabi/gnome-desktop-2.16.1-r1/gnome-desktop-2.16.1/gnome-about/headers'
| make[3]: Entering directory `/home/ulf/projects/OpenEmbedded/build/tmp/work/armv5te-angstrom-linux-gnueabi/gnome-desktop-2.16.1-r1/gnome-desktop-2.16.1/gnome-about'
| make[3]: Nothing to be done for `all-am'.
| make[3]: Leaving directory `/home/ulf/projects/OpenEmbedded/build/tmp/work/armv5te-angstrom-linux-gnueabi/gnome-desktop-2.16.1-r1/gnome-desktop-2.16.1/gnome-about'
| make[2]: Leaving directory `/home/ulf/projects/OpenEmbedded/build/tmp/work/armv5te-angstrom-linux-gnueabi/gnome-desktop-2.16.1-r1/gnome-desktop-2.16.1/gnome-about'
| Making all in pixmaps
| make[2]: Entering directory `/home/ulf/projects/OpenEmbedded/build/tmp/work/armv5te-angstrom-linux-gnueabi/gnome-desktop-2.16.1-r1/gnome-desktop-2.16.1/pixmaps'
| make[2]: Nothing to be done for `all'.
| make[2]: Leaving directory `/home/ulf/projects/OpenEmbedded/build/tmp/work/armv5te-angstrom-linux-gnueabi/gnome-desktop-2.16.1-r1/gnome-desktop-2.16.1/pixmaps'
| Making all in desktop-docs
| make[2]: Entering directory `/home/ulf/projects/OpenEmbedded/build/tmp/work/armv5te-angstrom-linux-gnueabi/gnome-desktop-2.16.1-r1/gnome-desktop-2.16.1/desktop-docs'
| Making all in fdl
| make[3]: Entering directory `/home/ulf/projects/OpenEmbedded/build/tmp/work/armv5te-angstrom-linux-gnueabi/gnome-desktop-2.16.1-r1/gnome-desktop-2.16.1/desktop-docs/fdl'
| xsltproc -o fdl-es.omf --stringparam db2omf.basename fdl --stringparam db2omf.format 'docbook' --stringparam db2omf.dtd "-//OASIS//DTD DocBook XML V4.1.2//EN" --stringparam db2omf.lang es --stringparam db2omf.omf_dir "/usr/share/omf" --stringparam db2omf.help_dir "/usr/share/gnome/help"
--stringparam db2omf.omf_in "`pwd`//home/ulf/projects/OpenEmbedded/build/tmp/work/armv5te-angstrom-linux-gnueabi/gnome-desktop-2.16.1-r1/gnome-desktop-2.16.1/desktop-docs/fdl/fdl.omf.in" `/home/ulf/projects/OpenEmbedded/build/tmp/staging/i686-linux/bin/pkg-config --variable db2omf gnome-doc-utils`
es/fdl.xml
| warning: failed to load external entity
"/home/ulf/projects/OpenEmbedded/build/tmp/work/armv5te-angstrom-linux-gnueabi/gnome-desktop-2.16.1-r1/gnome-desktop-2.16.1/desktop-docs/fdl//home/ulf/projects/OpenEmbedded/build/tmp/work/armv5te-angstrom-linux-gnueabi/gnome-desktop-2.16.1-r1/gnome-desktop-2.16.1/desktop-docs/fdl/fdl.omf.in"
| db2omf: Could not construct the OMF maintainer element.
|   Add an author, corpauthor, editor, othercredit, or publisher
|   element with the role attribute set to "maintainer" to fdl.xml.
| make[3]: *** [fdl-es.omf] Error 10
| make[3]: Leaving directory `/home/ulf/projects/OpenEmbedded/build/tmp/work/armv5te-angstrom-linux-gnueabi/gnome-desktop-2.16.1-r1/gnome-desktop-2.16.1/desktop-docs/fdl'
| make[2]: *** [all-recursive] Error 1
| make[2]: Leaving directory `/home/ulf/projects/OpenEmbedded/build/tmp/work/armv5te-angstrom-linux-gnueabi/gnome-desktop-2.16.1-r1/gnome-desktop-2.16.1/desktop-docs'
| make[1]: *** [all-recursive] Error 1
| make[1]: Leaving directory `/home/ulf/projects/OpenEmbedded/build/tmp/work/armv5te-angstrom-linux-gnueabi/gnome-desktop-2.16.1-r1/gnome-desktop-2.16.1'
| make: *** [all] Error 2
| FATAL: oe_runmake failed
NOTE: Task failed: /home/ulf/projects/OpenEmbedded/build/tmp/work/armv5te-angstrom-linux-gnueabi/gnome-desktop-2.16.1-r1/temp/log.do_compile.24525
NOTE: package gnome-desktop-2.16.1-r1: task do_compile: failed
ERROR: TaskFailed event exception, aborting
NOTE: package gnome-desktop-2.16.1: failed
ERROR: Build of /home/ulf/projects/OpenEmbedded/org.openembedded.dev/packages/gnome/gnome-desktop_2.16.1.bb do_compile failed
ERROR: Task 2246 (/home/ulf/projects/OpenEmbedded/org.openembedded.dev/packages/gnome/gnome-desktop_2.16.1.bb, do_compile) failed
ERROR: '/home/ulf/projects/OpenEmbedded/org.openembedded.dev/packages/gnome/gnome-desktop_2.16.1.bb' failed
ulf at aeglos:~/projects/OpenEmbedded/build>


-- 
Best Regards,
Ulf Samuelsson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ulf.vcf
Type: text/x-vcard
Size: 301 bytes
Desc: not available
URL: <http://lists.openembedded.org/pipermail/openembedded-devel/attachments/20070521/b04bd7f9/attachment-0002.vcf>

From freyther at gmx.net  Mon May 21 21:53:12 2007
From: freyther at gmx.net (Holger Freyther)
Date: Mon, 21 May 2007 23:53:12 +0200
Subject: [oe] ERROR: Task 2246 ( ...
	org.openembedded.dev/packages/gnome/gnome-desktop_2.16.1.bb,
	do_compile) failed
In-Reply-To: <4651EFEE.50907@atmel.com>
References: <4651EFEE.50907@atmel.com>
Message-ID: <189F751D-9A54-4A17-84FD-82CD2BF62403@gmx.net>


Am 21.05.2007 um 21:15 schrieb Ulf Samuelsson:

> Looks like there is an issue with the fdl.xml in this package?
> Any workarounds?

Did you lack internet connectivity during the build?







From nils.faerber at kernelconcepts.de  Mon May 21 23:05:27 2007
From: nils.faerber at kernelconcepts.de (Nils Faerber)
Date: Tue, 22 May 2007 01:05:27 +0200
Subject: [oe] Problem wt. perl-native building for PXA
Message-ID: <465225B7.50900@kernelconcepts.de>

Hi!
I am encountering a strange problem while trying to build Angstrom for
PXA (for LinuxTag demo purposes). While we have some other machines
building it with the same version of OE and Bitbake just fine it fails
on my notebook (but I would like to be able to rebuild it directly at
LinuxTag, thus the question).
My machine has Ubuntu feisty installed. I am using Bitbake 1.8 from SVN
and an OE checkout from today.

What happens is that the build works quite well until it comes to
perl-native-5.8.8-r7. There it fails with the following error:

...
|       Making x2p stuff
| make[1]: Entering directory
`/media/disk/oe/build_h5xxx/tmp/work/i686-linux/perl-native-5.8.8-r7/perl-5.8.8/x2p'
| You haven't done a "make depend" yet!
| make[1]: *** [hash.o] Error 1
...
[ full log attached ]

I have the feeling that it has something to do with my host setup but I
have no clue what!? If I comment out the dependency check from the
source directory (outch, hack!) it compiles fine and continues. Most
other packages work to compile then until
libxml-parser-perl-native_2.34.bb which again fails because of a
misinstallation of the per utils in the staging directory.

I am really quite clueless what might be the reason.
If anyone encoutered this before I would be glad to share hints to
resolve the situation ;)

Thanks!

Cheers
  nils faerber

-- 
kernel concepts GbR      Tel: +49-271-771091-12
Sieghuetter Hauptweg 48  Fax: +49-271-771091-19
D-57072 Siegen           Mob: +49-176-21024535
--
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: log.do_compile.6371
URL: <http://lists.openembedded.org/pipermail/openembedded-devel/attachments/20070522/dc1f1f01/attachment-0002.ksh>

From rpurdie at rpsys.net  Mon May 21 23:20:19 2007
From: rpurdie at rpsys.net (Richard Purdie)
Date: Tue, 22 May 2007 00:20:19 +0100
Subject: [oe] Problem wt. perl-native building for PXA
In-Reply-To: <465225B7.50900@kernelconcepts.de>
References: <465225B7.50900@kernelconcepts.de>
Message-ID: <1179789619.5849.59.camel@localhost.localdomain>

Hi,

On Tue, 2007-05-22 at 01:05 +0200, Nils Faerber wrote:
> I am encountering a strange problem while trying to build Angstrom for
> PXA (for LinuxTag demo purposes). While we have some other machines
> building it with the same version of OE and Bitbake just fine it fails
> on my notebook (but I would like to be able to rebuild it directly at
> LinuxTag, thus the question).
> My machine has Ubuntu feisty installed. I am using Bitbake 1.8 from SVN
> and an OE checkout from today.
> 
> What happens is that the build works quite well until it comes to
> perl-native-5.8.8-r7. There it fails with the following error:

I'm not familiar with the error but what does /bin/sh point at?

If its dash, try bash as dash causes no end of headaches.

Cheers,

Richard





From nils.faerber at kernelconcepts.de  Mon May 21 23:34:59 2007
From: nils.faerber at kernelconcepts.de (Nils Faerber)
Date: Tue, 22 May 2007 01:34:59 +0200
Subject: [oe] Problem wt. perl-native building for PXA
In-Reply-To: <1179789619.5849.59.camel@localhost.localdomain>
References: <465225B7.50900@kernelconcepts.de>
	<1179789619.5849.59.camel@localhost.localdomain>
Message-ID: <46522CA3.1010000@kernelconcepts.de>

Richard Purdie schrieb:
> Hi,
Hi!

> On Tue, 2007-05-22 at 01:05 +0200, Nils Faerber wrote:
>> I am encountering a strange problem while trying to build Angstrom for
>> PXA (for LinuxTag demo purposes). While we have some other machines
>> building it with the same version of OE and Bitbake just fine it fails
>> on my notebook (but I would like to be able to rebuild it directly at
>> LinuxTag, thus the question).
>> My machine has Ubuntu feisty installed. I am using Bitbake 1.8 from SVN
>> and an OE checkout from today.
>>
>> What happens is that the build works quite well until it comes to
>> perl-native-5.8.8-r7. There it fails with the following error:
> 
> I'm not familiar with the error but what does /bin/sh point at?
> 
> If its dash, try bash as dash causes no end of headaches.

Is tihs Ubuntu?
I did never recognise this, but you are perfectly right with your
assumption, sh -> dash.

Gee, hey look, now it works!!!
This dash thing should be tarred and feathered ;)

Many thanks!

> Cheers,
> Richard
Cheers
  nils faerber

-- 
kernel concepts GbR      Tel: +49-271-771091-12
Sieghuetter Hauptweg 48  Fax: +49-271-771091-19
D-57072 Siegen           Mob: +49-176-21024535
--



From ulf at atmel.com  Tue May 22 04:24:27 2007
From: ulf at atmel.com (Ulf Samuelsson)
Date: Tue, 22 May 2007 06:24:27 +0200
Subject: [oe] ERROR: Task 2246 (
	...org.openembedded.dev/packages/gnome/gnome-desktop_2.16.1.bb,
	do_compile) failed
References: <4651EFEE.50907@atmel.com>
	<189F751D-9A54-4A17-84FD-82CD2BF62403@gmx.net>
Message-ID: <003a01c79c29$1985a690$26031a0a@atmel.com>

> 
> Am 21.05.2007 um 21:15 schrieb Ulf Samuelsson:
> 
>> Looks like there is an issue with the fdl.xml in this package?
>> Any workarounds?
> 
> Did you lack internet connectivity during the build?
> 


I have been trying to build this for a couple of days,
and sometimes the connections has been bad.


Been trying to fetch all packages in advance by 

$ bitbake -c fetch gpe-image

but that does not work.


Best Regards
Ulf Samuelsson




From no2spam at nospam.arcornews.de  Tue May 22 07:53:51 2007
From: no2spam at nospam.arcornews.de (Rolf Leggewie)
Date: Tue, 22 May 2007 09:53:51 +0200
Subject: [oe] ERROR: Task 2246 (
 ...org.openembedded.dev/packages/gnome/gnome-desktop_2.16.1.bb,
 do_compile) failed
In-Reply-To: <003a01c79c29$1985a690$26031a0a@atmel.com>
References: <4651EFEE.50907@atmel.com>	<189F751D-9A54-4A17-84FD-82CD2BF62403@gmx.net>
	<003a01c79c29$1985a690$26031a0a@atmel.com>
Message-ID: <f2u7if$5g3$1@sea.gmane.org>

Ulf Samuelsson wrote:
> Been trying to fetch all packages in advance by 
> 
> $ bitbake -c fetch gpe-image
> 
> but that does not work.

You want bitbake -c fetchall gpe-image




From koen at dominion.kabel.utwente.nl  Tue May 22 08:28:16 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Tue, 22 May 2007 10:28:16 +0200
Subject: [oe] ERROR: Task 2246 (
 ...org.openembedded.dev/packages/gnome/gnome-desktop_2.16.1.bb,
 do_compile) failed
In-Reply-To: <f2u7if$5g3$1@sea.gmane.org>
References: <4651EFEE.50907@atmel.com>	<189F751D-9A54-4A17-84FD-82CD2BF62403@gmx.net>	<003a01c79c29$1985a690$26031a0a@atmel.com>
	<f2u7if$5g3$1@sea.gmane.org>
Message-ID: <4652A9A0.6060109@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Rolf Leggewie schreef:
> Ulf Samuelsson wrote:
>> Been trying to fetch all packages in advance by 
>>
>> $ bitbake -c fetch gpe-image
>>
>> but that does not work.
> 
> You want bitbake -c fetchall gpe-image

Actually, no. With angstrom you want 'bitbake -c fetchall angstrom-x11-image'

regards,

KOen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGUqmgMkyGM64RGpERArd8AJ96Hc/IqpB0nHLyNOSlImfhs6AbcQCdFGJS
ok7J/m0QH6pWYgfm1Qww0y0=
=tovE
-----END PGP SIGNATURE-----



From openembedded at hrw.one.pl  Tue May 22 08:43:46 2007
From: openembedded at hrw.one.pl (Marcin Juszkiewicz)
Date: Tue, 22 May 2007 10:43:46 +0200
Subject: [oe] ERROR: Task 2246 (
	...org.openembedded.dev/packages/gnome/gnome-desktop_2.16.1.bb,
	do_compile) failed
In-Reply-To: <003a01c79c29$1985a690$26031a0a@atmel.com>
References: <4651EFEE.50907@atmel.com>
	<189F751D-9A54-4A17-84FD-82CD2BF62403@gmx.net>
	<003a01c79c29$1985a690$26031a0a@atmel.com>
Message-ID: <200705221043.47508.openembedded@hrw.one.pl>

Dnia wtorek, 22 maja 2007, Ulf Samuelsson napisa?:

> Been trying to fetch all packages in advance by
>
> $ bitbake -c fetch gpe-image
>
> but that does not work.

"bitbake -cfetchall gpe-image" is for that


-- 
JID: hrw-jabber.org
OpenEmbedded developer/consultant

       If you're going down in flames, aim for something expensive.





From freyther at gmx.net  Tue May 22 09:53:37 2007
From: freyther at gmx.net (Holger Freyther)
Date: Tue, 22 May 2007 11:53:37 +0200
Subject: [oe] ERROR: Task 2246 (
	...org.openembedded.dev/packages/gnome/gnome-desktop_2.16.1.bb,
	do_compile) failed
In-Reply-To: <003a01c79c29$1985a690$26031a0a@atmel.com>
References: <4651EFEE.50907@atmel.com>
	<189F751D-9A54-4A17-84FD-82CD2BF62403@gmx.net>
	<003a01c79c29$1985a690$26031a0a@atmel.com>
Message-ID: <75DD721B-B0C4-46EF-A8F2-838E8DB5CF85@gmx.net>

>
>
> Been trying to fetch all packages in advance by
>
> $ bitbake -c fetch gpe-image

Hi,

even with that you will have the issue from before.

Q: What is the issue?
A: I'm not a XML geek but I think xsltproc and xmllint will download  
doctype and schemata during the generation of the documentation. I  
don't know if one can make xstlproc not to do it, this would be  
something for you to find out (xstlproc --help). What you can do/try  
is to add EXTRA_OECONF += " --disable-doc" in the offending recipes.


z.




From lvcargnini at gmail.com  Wed May 23 01:56:18 2007
From: lvcargnini at gmail.com (=?ISO-8859-1?Q?Lu=EDs_Cargnini?=)
Date: Tue, 22 May 2007 22:56:18 -0300
Subject: [oe] problems cross-compilinx xserver-xorg
Message-ID: <ae36f8040705221856p1ec52709y284a370bbc1af3ee@mail.gmail.com>

Hi I'm trying to bitbake xserver-xorg (cvs version) and I received the
following results:

NOTE: xserver-xorg-6.8.1+cvs20070523-cvs://anoncvs.freedesktop.org/cvs/xorghas
no section, not checking URI
NOTE: xserver-xorg-6.8.1+cvs20070523-file://imake-staging.patch has no
section, not checking URI
NOTE: xserver-xorg-6.8.1+cvs20070523-file://dri.patch has no section, not
checking URI
NOTE: package xserver-xorg-6.8.1+cvs20070523-r3: task do_fetch: completed
NOTE: package xserver-xorg-6.8.1+cvs20070523-r3: task do_unpack: started
NOTE: Unpacking
/home/lvcargnini/puc/instramed/openembedded/build/sources/xc_anoncvs.freedesktop.org__20070523.tar.gz
to
/home/lvcargnini/puc/instramed/openembedded/tmp/work/armv5te-linux/xserver-
xorg-6.8.1+cvs20070523-r3/
NOTE: package xserver-xorg-6.8.1+cvs20070523-r3: task do_unpack: completed
NOTE: package xserver-xorg-6.8.1+cvs20070523-r3: task do_patch: started
NOTE: Applying patch 'imake-staging.patch'
NOTE: Task failed: Command Error: exit status: 127  Output:
sh: quilt: command not found
NOTE: package xserver-xorg-6.8.1+cvs20070523-r3: task do_patch: failed
ERROR: TaskFailed event exception, aborting
NOTE: package xserver-xorg-6.8.1+cvs20070523: failed
ERROR: Build of 'xserver-xorg' failed
Build statistics:
  Attempted builds: 1
  Failed builds: 1
someone please could help me ?
my local.conf:

(enterprise:~/puc/instramed/openembedded) lvcargnini% cat
build/conf/local.conf
#
# OpenEmbedded local configuration file (sample)
#
# Please visit the Wiki at http://openembedded.org/ for more info.
#
#
# Be SURE to read this file in its entirety and the GettingStarted page on
the
# wiki before proceeding.
#
# Once you have done that, remove the line at the end of this
# file and build away.
#
# WARNING: lines starting with a space (' ') will result in parse failures.
# Remove '# ' from commented lines to activate them.
#
# NOTE: Do NOT use $HOME in your paths, BitBake does NOT expand ~ for you.
If you
# must have paths relative to your homedir use ${HOME} (note the {}'s there
# you MUST have them for the variable expansion to be done by BitBake).
Your
# paths should all be absolute paths (They should all start with a / after
# expansion.  Stuff like starting with ${HOME} or ${TOPDIR} is ok).

# Use this to specify where BitBake should place the downloaded sources into
DL_DIR = "/home/lvcargnini/puc/instramed/openembedded/build/sources"

# Delete the line below. Then specify which .bb files to consider for
# your build. Typically this will be something like BBFILES =
"/path/to/openembedded/packages/*/*.bb"
BBFILES :=
"/home/lvcargnini/puc/instramed/openembedded/org.openembedded.dev/packages/*/*.bb"

# Use the BBMASK below to instruct BitBake to _NOT_ consider some .bb files
# This is a regulary expression, so be sure to get your parenthesis
balanced.
BBMASK = ""

# Uncomment this if you want to use a prebuilt toolchain. You will need to
# provide packages for toolchain and additional libraries yourself. You also
# have to set PATH in your environment to make sure BitBake finds additional
binaries.
# Note: You will definitely need to say:
#     ASSUME_PROVIDED += "virtual/arm-linux-gcc-2.95"
# to build any of two Linux 2.4 Embedix kernels,
# i.e. openzaurus-sa-2.4.18 and openzaurus-pxa-2.4.18 - and don't forget
# to rename the binaries as instructed in the Wiki.
# ASSUME_PROVIDED += "virtual/${TARGET_PREFIX}gcc virtual/libc"
ASSUME_PROVIDED += "/opt/eldk/usr/bin"
# Select between multiple alternative providers, if more than one is
eligible.
PREFERRED_PROVIDERS = "virtual/qte:qte virtual/libqpe:libqpe-opie"
PREFERRED_PROVIDERS += " virtual/libsdl:libsdl-x11"
PREFERRED_PROVIDERS += "
virtual/${TARGET_PREFIX}gcc-initial:gcc-cross-initial"
PREFERRED_PROVIDERS += " virtual/${TARGET_PREFIX}gcc:gcc-cross"
PREFERRED_PROVIDERS += " virtual/${TARGET_PREFIX}g++:gcc-cross"

# Uncomment this to specify where BitBake should create its temporary files.
# Note that a full build of everything in OpenEmbedded will take GigaBytes
of hard
# disk space, so make sure to free enough space. The default TMPDIR is
# <build directory>/tmp
# Don't use symlinks in in the path to avoid problems
# TMPDIR = /usr/local/projects/oetmp
TMPDIR=/home/lvcargnini/puc/instramed/openembedded/tmp
# Uncomment this to specify a machine to build for. See the conf directory
# for machines currently known to OpenEmbedded. This will automatically take
care
# of TARGET_ARCH
# MACHINE = "c7x0"
MACHINE = "omap5912osk"
# Use this to specify the target architecture. Note that this is only
# needed when building for a machine not known to OpenEmbedded. Better use
# the MACHINE attribute (see above)
# TARGET_ARCH = "arm"
TARGET_ARCH = "arm"
# Use this to specify the target operating system.  The default is "linux",
# for a normal linux system with glibc. Set this to "linux-uclibc" if you
want
# to build a uclibc based system.
# Normally the DISTRO of your choosing will take care of this
# TARGET_OS = "linux"
# TARGET_OS = "linux-uclibc"
TARGET_OS = "linux"
# Uncomment this to select a distribution policy. See the conf directory
# for distributions currently known to OpenEmbedded.
# Although it no longer contain version number in the (file-)name
# openzaurus-unstable is a so called "versioned"  distro, i.e. they
# explicitely select specific versions of various packages.
# Stay away from unversioned distros unless you really know what you are
doing
# DISTRO = "generic"
DISTRO = "generic"
# So far, angstrom.conf sets ENABLE_BINARY_LOCALE_GENERATION
# to generate binary locale packages at build time using qemu-native and
# thereby guarantee i18n support on all devices. If your build breaks on
# qemu-native consider disabling ENABLE_BINARY_LOCALE_GENERATION (note that
# this breaks i18n on devices with less than 128MB RAM) or installing
# a working third-party qemu (e.g. provided by your distribution) and
# adding qemu-native to ASSUME_PROVIDED. Caveat emptor, since third-party
# qemus lack patches needed to work with various OE targets.
# ENABLE_BINARY_LOCALE_GENERATION = "0"
# ASSUME_PROVIDED += "qemu-native"

# If ENABLE_BINARY_LOCALE_GENERATION is set to "1", you can limit locales
# generated to the list provided by GLIBC_GENERATE_LOCALES. This is huge
# time-savior for developmental builds. Format: list of locale.encodingpairs
# with spaces as separators.
# GLIBC_GENERATE_LOCALES = "en_GB.UTF-8 de_DE.UTF-8"
GLIBC_GENERATE_LOCALES = "en en_GB fr it de pt_BR"
# Uncomment this to select a particular major kernel version if the MACHINE
setting
# supports more than one major kernel version. Currently this is suported by
the
# following MACHINE types: poodle, tosa and simpad.
# MACHINE_KERNEL_VERSION = "2.6"

# Uncomment one of these to build packages during the build process.
# This is done automatically if you set DISTRO (see above)
# INHERIT = "package_ipk"
INHERIT = "package_tar"

# Add the required image file system types below. Valid are jffs2, tar,
cramfs and ext2
IMAGE_FSTYPES = "jffs2 tar cramfs"

# Uncomment this to disable the parse cache (not recommended).
# CACHE = ""

# Uncomment this if you want BitBake to emit debugging output
# BBDEBUG = "yes"
BBDEBUG = "yes
# Uncomment these two if you want BitBake to build images useful for
debugging.
# Note that INHIBIT_PACKAGE_STRIP needs a package format to be defined.
# Also note that OE now produces -dbg packages which contain debugging
symbols.
# DEBUG_BUILD = "1"
# INHIBIT_PACKAGE_STRIP = "1"

# Uncomment these to build a package such that you can use gprof to profile
it.
# NOTE: This will only work with 'linux' targets, not
# 'linux-uclibc', as uClibc doesn't provide the necessary
# object files.  Also, don't build glibc itself with these
# flags, or it'll fail to build.
#
# PROFILE_OPTIMIZATION = "-pg"
# SELECTED_OPTIMIZATION = "${PROFILE_OPTIMIZATION}"
# LDFLAGS =+ "-pg"

# Uncomment this to enable parallel make.
# This allows make to spawn mutliple processes to take advantage of multiple

# processors. Useful on SMP machines. This may break some packages - we're
# in the process of marking these so let us know if you find any.
# PARALLEL_MAKE = "-j 4"

# Uncomment this if you want BitBake to emit the log if a build fails.
BBINCLUDELOGS = "yes"

-- 
------------------------------------------------------------------------------
Thanks && Regards
Msc. Bsc. Lu?s Vit?rio Cargnini
IEEE Member
Electrical Engineer Faculty @ PUCRS
Ipiranga Avenue, 6681 ? Building 30
P.O. Box: 90619-900 ? Porto Alegre/RS
Phone: +55 51 3320 3500  extension: 7696
---------------------------------------------------------------------------------


From mc-lists at tesco.net  Wed May 23 04:17:39 2007
From: mc-lists at tesco.net (Matt Callow)
Date: Wed, 23 May 2007 14:17:39 +1000
Subject: [oe] problems cross-compilinx xserver-xorg
In-Reply-To: <ae36f8040705221856p1ec52709y284a370bbc1af3ee@mail.gmail.com>
References: <ae36f8040705221856p1ec52709y284a370bbc1af3ee@mail.gmail.com>
Message-ID: <5937bed10705222117h314bc92cxc26261af9fcb2fb4@mail.gmail.com>

On 5/23/07, Lu?s Cargnini <lvcargnini at gmail.com> wrote:
> Hi I'm trying to bitbake xserver-xorg (cvs version) and I received the
> following results:
>
...
> sh: quilt: command not found

This looks like your problem. Try installing quilt.

Matt



From lenehan at twibble.org  Thu May 24 02:35:51 2007
From: lenehan at twibble.org (Jamie Lenehan)
Date: Thu, 24 May 2007 12:35:51 +1000
Subject: [oe] Problem wt. perl-native building for PXA
In-Reply-To: <46522CA3.1010000@kernelconcepts.de>
References: <465225B7.50900@kernelconcepts.de>
	<1179789619.5849.59.camel@localhost.localdomain>
	<46522CA3.1010000@kernelconcepts.de>
Message-ID: <20070524023551.GA31623@twibble.org>

On Tue, May 22, 2007 at 01:34:59AM +0200, Nils Faerber wrote:
> Richard Purdie schrieb:
> > Hi,
> Hi!
> 
> > On Tue, 2007-05-22 at 01:05 +0200, Nils Faerber wrote:
[...]
> >> My machine has Ubuntu feisty installed. I am using Bitbake 1.8 from SVN
[...]
> >> What happens is that the build works quite well until it comes to
> >> perl-native-5.8.8-r7. There it fails with the following error:
[...]
> Is tihs Ubuntu?
> I did never recognise this, but you are perfectly right with your
> assumption, sh -> dash.
> 
> Gee, hey look, now it works!!!

> This dash thing should be tarred and feathered ;)

I actually tested perl-native with dash, and it builds just fine here
when using dash:

  ~%> ./bb -b packages/perl/perl-native_5.8.8.bb 
  ...
  NOTE: package perl-native-5.8.8: completed
  ~%> ls -l /bin/sh
  lrwxrwxrwx 1 root root 4 2007-05-24 12:05 /bin/sh -> dash*
  ~%> cat /etc/issue.net 
  Ubuntu 6.10

In theory the following patch should fix the dash issues you were
seeing. Is their someone seeing this dash/perl-native issues that
could test this?

# 
# old_revision [d28c26f2757f88207089404b9e74286950165915]
# 
# add_file "packages/perl/perl-5.8.8/native-makedepend-dash.patch"
#  content [a32ff3bf1b75c57f6ff7ac58b232cc44f2648a27]
# 
# patch "packages/perl/perl-native_5.8.8.bb"
#  from [3013e9425fe473cf0988c3ccf6cad2b894e62e58]
#    to [e95283c93197ba0c2c16f42feef3c0b6691a7a53]
# 
============================================================
--- packages/perl/perl-5.8.8/native-makedepend-dash.patch	a32ff3bf1b75c57f6ff7ac58b232cc44f2648a27
+++ packages/perl/perl-5.8.8/native-makedepend-dash.patch	a32ff3bf1b75c57f6ff7ac58b232cc44f2648a27
@@ -0,0 +1,13 @@
+Index: perl-5.8.8/makedepend.SH
+===================================================================
+--- perl-5.8.8.orig/makedepend.SH	2007-05-24 12:06:52.000000000 +1000
++++ perl-5.8.8/makedepend.SH	2007-05-24 12:27:33.000000000 +1000
+@@ -128,7 +128,7 @@
+     *.y) filebase=`basename $file .y` ;;
+     esac
+     case "$file" in
+-    */*) finc="-I`echo $file | sed 's#/[^/]*$##`" ;;
++    */*) finc="-I`echo $file | sed 's#/[^/]*$##'`" ;;
+     *)   finc= ;;
+     esac
+     $echo "Finding dependencies for $filebase$_o."
============================================================
--- packages/perl/perl-native_5.8.8.bb	3013e9425fe473cf0988c3ccf6cad2b894e62e58
+++ packages/perl/perl-native_5.8.8.bb	e95283c93197ba0c2c16f42feef3c0b6691a7a53
@@ -12,7 +12,8 @@ SRC_URI = "http://ftp.funet.fi/pub/CPAN/
            file://Configure-multilib.patch;patch=1 \
            file://perl-configpm-switch.patch;patch=1 \
            file://native-nopacklist.patch;patch=1 \
-           file://native-no-gdbminc.patch;patch=1"
+           file://native-no-gdbminc.patch;patch=1 \
+           file://native-makedepend-dash.patch;patch=1"
 
 S = "${WORKDIR}/perl-${PV}"
 


-- 
 Jamie Lenehan <lenehan at twibble.org>



From Scott.Davis at smiths-aerospace.com  Tue May 22 19:17:43 2007
From: Scott.Davis at smiths-aerospace.com (Davis, Scott (AGRE))
Date: Tue, 22 May 2007 13:17:43 -0600
Subject: [oe]  Building Python extensions
Message-ID: <BDD06CD3363F254993AED78CA36350E20324E06D@cossmgmbx07.EMAIL.CORP.TLD>


I am trying to build a 32-bit shared library for a C library I have on
an x86_64 AMD SuSE linux system.  I am observing the same problem that
apparently someone on your list has had.  I have a commercial C 32-bit
linux library that I want to use SWIG to build a python extension for.
My linux system is 64-bit and when I compile against Python.h for Python
2.4 I get #error LONG BIT below emitted. 

The original post is at the URL below:
http://projects.linuxtogo.org/pipermail/openembedded-devel/2007-March/00
1722.html

What is the fix to build 32-bit shared library python extension on a
64-bit linux system?

#if LONG_BIT != 8 * SIZEOF_LONG 
/* 04-Oct-2000 LONG_BIT is apparently (mis)defined as 64 on some recent 
* 32-bit platforms using gcc. We try to catch that here at compile-time 
* rather than waiting for integer multiplication to trigger bogus *
overflows. */
 #error "LONG_BIT definition appears wrong for platform (bad gcc/glibc
config?)." 
#endif 

Scott Davis
GE
Aviation
Digital Systems
Principal Software Engineer

T 616 224 6659
F 616 241 8707
E scott.davis at smiths-aerospace.com
www.ge.com/aviation 

3290 Patterson Ave, SE 
Grand Rapids, MI 49512, U.S.A.



</table> </Pre>
<HTML>
<br>
<br>
************************************************<br>
The information contained in, or attached to, this e-mail, may contain confidential information and is intended solely for the use of the individual or entity to whom they are addressed and may be subject to legal privilege.  If you have received this e-mail in error you should notify the sender immediately by reply e-mail, delete the message from your system and notify your system manager.  Please do not copy it for any purpose, or disclose its contents to any other person.  The views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of the company.  The recipient should check this e-mail and any attachments for the presence of viruses.  The company accepts no liability for any damage caused, directly or indirectly, by any virus transmitted in this email.<br>
************************************************<br>
</HTML>

From openembedded at hrw.one.pl  Thu May 24 12:03:52 2007
From: openembedded at hrw.one.pl (Marcin Juszkiewicz)
Date: Thu, 24 May 2007 14:03:52 +0200
Subject: [oe] Building Python extensions
In-Reply-To: <BDD06CD3363F254993AED78CA36350E20324E06D@cossmgmbx07.EMAIL.CORP.TLD>
References: <BDD06CD3363F254993AED78CA36350E20324E06D@cossmgmbx07.EMAIL.CORP.TLD>
Message-ID: <200705241403.55472.openembedded@hrw.one.pl>

Dnia wtorek, 22 maja 2007, Davis, Scott (AGRE) napisa?:
> I am trying to build a 32-bit shared library for a C library I have on
> an x86_64 AMD SuSE linux system.  I am observing the same problem that
> apparently someone on your list has had.  I have a commercial C 32-bit
> linux library that I want to use SWIG to build a python extension for.
> My linux system is 64-bit and when I compile against Python.h for
> Python 2.4 I get #error LONG BIT below emitted.

> What is the fix to build 32-bit shared library python extension on a
> 64-bit linux system?

check OE/packages/python/python-gst/python-path.patch and 
python-gst_0.10.7.bb recipe

Both add --with-python-includes param to configure script with location of 
proper 32bit headers.

-- 
JID: hrw-jabber.org
OpenEmbedded developer/consultant

               We're bad people and we do bad things [Pink]





From mwester at dls.net  Sat May 26 07:53:40 2007
From: mwester at dls.net (Mike (mwester))
Date: Sat, 26 May 2007 02:53:40 -0500
Subject: [oe] PREFERRED_PROVIDER syntax is eluding me...
Message-ID: <038201c79f6a$f9859720$6e01a8c0@twilight>

I'm missing something simple, I expect.  But try as I might, I cannot figure
this out.

Bitbake 1.8.3, building unslung-image (worked fine on 1.6): Bitbake says:
[snip]
NOTE: multiple providers are available for runtime libc6-unslung (glibc,
glibc-initial);
NOTE: consider defining a PREFERRED_PROVIDER entry to match runtime
libc6-unslung
[snip]

This is a problem, because with bitbake 1.8, without a preferred provider
specified, it seems to try to build both.  But only glibc builds;
glibc-initial fails (and the build loops forever).   This is easily fixed by
adding the following line to the local.conf file:

PREFERRED_PROVIDER_libc6-unslung = "glibc"

Except that it doesn't do a blasted thing.  Neither does this line:

PREFERRED_PROVIDERS += " libc6-unslung:glibc"

Thinking that perhaps the "-unslung" was implied since the machine is
"unslung", I tried:

PREFERRED_PROVIDERS += " libc6:glibc"

Still no change.  Being persistent, I tried every variant of the above that
I could think of, to no avail.  It seems that bitbake is not understanding
or processing the info provided.  The -D flag offers no further hints,
either.

For background, back in the glibc bitbake recipes, glibc-initial.bb does a
"require" of glibc.bb (hence the multiple providers).  Near the tail-end of
glibc.bb we find:

PACKAGES_unslung = "libc6-unslung"
RDEPENDS_libc6-unslung = "nslu2-linksys-libs"
RPROVIDES_libc6-unslung = "libc6"
FILES_libc6-unslung = "/lib/librt*"

Figuring that perhaps the problem is that nothing actually "PROVIDES" libc6,
and that maybe bitbake needs to see the build-time dependency in order to
handle the run-time dependency PREFERRED_PROVIDER stuff, I even added
PROVIDES_libc6-unslung = "libc6"
to the glibc.bb recipe, and went back through the list of
PREFERRED_PROVIDERS in the local.conf file.  No luck.  No difference.

I finally hacked the glibc bitbake recipes so that glibc-initial doesn't
"RPROVIDE" libc6 anymore.  Success - bitbake is happy.  But I'm not.  That
doesn't seem like the correct way to resolve the multiple providers issue,
and I expect that commiting such a change would (rightfully) anger many
folks.

If some kind soul could point me to the document or another recipe that
provides the correct syntax for handling this, or provide a pointer to
whatever it is that I'm missing, I'd be most grateful.

Thanks!

Mike (mwester)







From eric.nelson at boundarydevices.com  Sun May 27 14:01:16 2007
From: eric.nelson at boundarydevices.com (Eric Nelson)
Date: Sun, 27 May 2007 07:01:16 -0700
Subject: [oe] preferred-xorg-versions-X11R7.1.inc broken?
Message-ID: <46598F2C.5010707@boundarydevices.com>

Trying to build gpe-image using distro/generic.conf, I'm
getting an error configuring xinerama.

 From the log file
    tmp/work/armv5te-linux/libxinerama-1_1.0.2-r0/temp/log.do_configure.9791

I'm seeing an error of:
    configure.ac:32: error: must install xorg-macros 1.1 or later
    configure.ac:32: the top level

It appears that preferred-xorg-versions-X11R7.1.inc doesn't
specify a xinerama version so it uses the newer one but does
specify a version of util-macros (1.0.2).




From openembedded at hrw.one.pl  Sun May 27 14:30:16 2007
From: openembedded at hrw.one.pl (Marcin Juszkiewicz)
Date: Sun, 27 May 2007 16:30:16 +0200
Subject: [oe] RFC: Rename MACHINE_TASK_PROVIDER to DEFAULT_TASK_PROVIDER
In-Reply-To: <4636F787.8030902@whitby.id.au>
References: <4636F787.8030902@whitby.id.au>
Message-ID: <200705271630.18199.openembedded@hrw.one.pl>

Dnia wtorek, 1 maja 2007, Rod Whitby napisa?:

> The proposal is to replace MACHINE_TASK_PROVIDER with
> DEFAULT_TASK_PROVIDER throughout OE, and encourage all image-foo.bb
> maintainers to base their image on DEFAULT_TASK_PROVIDER (which can be
> set to task-boot, or task-base, or perhaps some other distro-specific
> single task-foo value), plus other image-specific stuff.

DEFAULT_TASK_PROVIDER is good idea for me. I would like to merge it with 
my proposal change to task-base (adding wifi/bt for pcmcia/usbhost/pci 
devices) in a way that we will have:

- task-boot
- task-base
- task-base-extended (wifi/bt added for pcmcia/usbhost/pci machines)

This way we will be able to create images with wifi/bt support for PDA 
with pcmcia but no internal wifi/bt by using task-base-extended as 
DEFAULT_TASK_PROVIDER (set in distro config) and devices with smaller 
amount of space for rootfs will get task-base so users will be free to 
install extra stuff.

What do you think?

-- 
JID: hrw-jabber.org
OpenEmbedded developer/consultant

               Life's not fair. But the root password helps.





From openembedded at hrw.one.pl  Sun May 27 14:38:03 2007
From: openembedded at hrw.one.pl (Marcin Juszkiewicz)
Date: Sun, 27 May 2007 16:38:03 +0200
Subject: [oe] RFC: MACHINE_ namespace
Message-ID: <200705271638.03886.openembedded@hrw.one.pl>


During usage of progear device (now packed due to lack of space) I found 
a problems related to how we use machine configs and X11.

1. We have "alsa" as one of machine features but no way to control kernel 
modules for it - all are added into machine config as 
MACHINE_EXTRA_RRECOMMENDS. Same goes to other features.

2. Progear device use X.org instead of KDrive so I had to create own 
images for it because by default we do not have a way to tell which X 
drivers need to be present in images.


Proposed solution is adding MACHINE_ namespaces:

MACHINE_KERNEL_ALSA   = "kernel-module-snd-ali5451"
MACHINE_KERNEL_PCMCIA = "kernel-module-yenta-socket"

And other MACHINE_KERNEL_feature to control stuff used in task-base.

MACHINE_X11_SERVER  = "xserver-xorg"
MACHINE_X11_DRIVERS = "xf86-video-siliconmotion xf86-input-mutouch"

MACHINE_X11_SERVER will replace XSERVER used now, MACHINE_X11_DRIVERS will 
allow to add needed drivers to X11 images for device without creating 
custom ones.

What do you think about this proposal?

-- 
JID: hrw-jabber.org
OpenEmbedded developer/consultant

                 You can logoff, but you can never leave.
                 		-- Nina Liedtke, "CyberJoly Drim"





From koen at dominion.kabel.utwente.nl  Sun May 27 15:39:39 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Sun, 27 May 2007 17:39:39 +0200
Subject: [oe] RFC: MACHINE_ namespace
In-Reply-To: <200705271638.03886.openembedded@hrw.one.pl>
References: <200705271638.03886.openembedded@hrw.one.pl>
Message-ID: <4659A63B.9080901@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Marcin Juszkiewicz schreef:
> During usage of progear device (now packed due to lack of space) I found 
> a problems related to how we use machine configs and X11.
> 
> 1. We have "alsa" as one of machine features but no way to control kernel 
> modules for it - all are added into machine config as 
> MACHINE_EXTRA_RRECOMMENDS. Same goes to other features.
> 
> 2. Progear device use X.org instead of KDrive so I had to create own 
> images for it because by default we do not have a way to tell which X 
> drivers need to be present in images.
> 
> 
> Proposed solution is adding MACHINE_ namespaces:
> 
> MACHINE_KERNEL_ALSA   = "kernel-module-snd-ali5451"
> MACHINE_KERNEL_PCMCIA = "kernel-module-yenta-socket"
> 
> And other MACHINE_KERNEL_feature to control stuff used in task-base.
> 
> MACHINE_X11_SERVER  = "xserver-xorg"
> MACHINE_X11_DRIVERS = "xf86-video-siliconmotion xf86-input-mutouch"
> 
> MACHINE_X11_SERVER will replace XSERVER used now, MACHINE_X11_DRIVERS will 
> allow to add needed drivers to X11 images for device without creating 
> custom ones.
> 
> What do you think about this proposal?

Sounds pretty good, do you have a patch for it?

regards,

Koen


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGWaY7MkyGM64RGpERAo7vAJ9XGOvAsqKq4cLXv1nhCIH0JCts9ACfVAMr
gb542366W8K6bgr2tOxroV8=
=iSVA
-----END PGP SIGNATURE-----



From pmiscml at gmail.com  Sun May 27 19:28:20 2007
From: pmiscml at gmail.com (Paul Sokolovsky)
Date: Sun, 27 May 2007 22:28:20 +0300
Subject: [oe] RFC: MACHINE_ namespace
In-Reply-To: <200705271638.03886.openembedded@hrw.one.pl>
References: <200705271638.03886.openembedded@hrw.one.pl>
Message-ID: <277782266.20070527222820@gmail.com>

Hello Marcin,

Sunday, May 27, 2007, 5:38:03 PM, you wrote:

> During usage of progear device (now packed due to lack of space) I found
> a problems related to how we use machine configs and X11.

> 1. We have "alsa" as one of machine features but no way to control kernel
> modules for it - all are added into machine config as 
> MACHINE_EXTRA_RRECOMMENDS. Same goes to other features.

> 2. Progear device use X.org instead of KDrive so I had to create own 
> images for it because by default we do not have a way to tell which X 
> drivers need to be present in images.


> Proposed solution is adding MACHINE_ namespaces:

> MACHINE_KERNEL_ALSA   = "kernel-module-snd-ali5451"
> MACHINE_KERNEL_PCMCIA = "kernel-module-yenta-socket"

        This sounds good, especially if we anticipate from the start
that there may be several modules there. And generally, we need to add
more modules into task-base subtasks, targetting at aim when machine
configs will truly contain only machine-specific bits (like hardware
drivers), while other modules will be in task-base.

[]

-- 
Best regards,
 Paul                            mailto:pmiscml at gmail.com




From rod at whitby.id.au  Sun May 27 22:46:38 2007
From: rod at whitby.id.au (Rod Whitby)
Date: Mon, 28 May 2007 08:16:38 +0930
Subject: [oe] RFC: Rename MACHINE_TASK_PROVIDER to DEFAULT_TASK_PROVIDER
In-Reply-To: <200705271630.18199.openembedded@hrw.one.pl>
References: <4636F787.8030902@whitby.id.au>
	<200705271630.18199.openembedded@hrw.one.pl>
Message-ID: <465A0A4E.7060807@whitby.id.au>

Marcin Juszkiewicz wrote:
> Dnia wtorek, 1 maja 2007, Rod Whitby napisa?:
> 
>> The proposal is to replace MACHINE_TASK_PROVIDER with
>> DEFAULT_TASK_PROVIDER throughout OE, and encourage all image-foo.bb
>> maintainers to base their image on DEFAULT_TASK_PROVIDER (which can be
>> set to task-boot, or task-base, or perhaps some other distro-specific
>> single task-foo value), plus other image-specific stuff.
> 
> DEFAULT_TASK_PROVIDER is good idea for me. I would like to merge it with 
> my proposal change to task-base (adding wifi/bt for pcmcia/usbhost/pci 
> devices) in a way that we will have:
> 
> - task-boot
> - task-base
> - task-base-extended (wifi/bt added for pcmcia/usbhost/pci machines)
> 
> This way we will be able to create images with wifi/bt support for PDA 
> with pcmcia but no internal wifi/bt by using task-base-extended as 
> DEFAULT_TASK_PROVIDER (set in distro config) and devices with smaller 
> amount of space for rootfs will get task-base so users will be free to 
> install extra stuff.
> 
> What do you think?

+1 from me.

Can you add:

PROVIDES = "${PACKAGES}"

to task-base.bb while you are there?  I know it should not be required
(it should happen automatically), but for some reason the automatic
stuff is not working for this file at the moment.  I cannot build an
image based on task-boot instead of task-base without doing the above.

-- Rod



From zecke at selfish.org  Mon May 28 09:33:10 2007
From: zecke at selfish.org (Holger Freyther)
Date: Mon, 28 May 2007 11:33:10 +0200
Subject: [oe] RPATH hacks
Message-ID: <A16C87CA-5E9D-4B3B-B237-3BD3890A7D28@selfish.org>

Hey,

I have just pushed a change to libtool-cross that will disable -rpath  
for all cross compiled packages. This should fix all issues with  
rpath on libtool based packages.

What can break?
	I can imagine if you have a binary you can not statically link,  
can't write a /etc/ld.so.conf and can't set LD_LIBRARY_PATH you might  
have troubles now. In that case please speak up and we can look at a  
solution.

I have not tested the resulting image, so if you end up with  
unbootable images feel free to tear and feather me (I like it).


z.




From koen at dominion.kabel.utwente.nl  Mon May 28 09:39:27 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Mon, 28 May 2007 11:39:27 +0200
Subject: [oe] RPATH hacks
In-Reply-To: <A16C87CA-5E9D-4B3B-B237-3BD3890A7D28@selfish.org>
References: <A16C87CA-5E9D-4B3B-B237-3BD3890A7D28@selfish.org>
Message-ID: <465AA34F.3090905@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Holger Freyther schreef:
> Hey,
> 
> I have just pushed a change to libtool-cross that will disable -rpath  
> for all cross compiled packages. This should fix all issues with  
> rpath on libtool based packages.

yay!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGWqNPMkyGM64RGpERAqaYAJ9cBjpMndY31KXOag3OZvlxRk1BzwCgsTx8
piu2PynRbFMnvIe1mO1yAdo=
=OhBm
-----END PGP SIGNATURE-----



From zecke at selfish.org  Mon May 28 10:21:32 2007
From: zecke at selfish.org (Holger Freyther)
Date: Mon, 28 May 2007 12:21:32 +0200
Subject: [oe] RPATH hacks
In-Reply-To: <A16C87CA-5E9D-4B3B-B237-3BD3890A7D28@selfish.org>
References: <A16C87CA-5E9D-4B3B-B237-3BD3890A7D28@selfish.org>
Message-ID: <476F8CF7-CE6C-4461-A336-15D6E43AF9B9@selfish.org>


Am 28.05.2007 um 11:33 schrieb Holger Freyther:

> I have not tested the resulting image, so if you end up with
> unbootable images feel free to tear and feather me (I like it).

Some people might find tearing to painful and wonder how the feathers  
will stay attached to my body, in this case feel free to tear, tar  
and feather me (or skip the tearing...)

z.

PS: Thank you native speakers...



From papercrane at gmail.com  Mon May 28 20:17:13 2007
From: papercrane at gmail.com (Justin Patrin)
Date: Mon, 28 May 2007 13:17:13 -0700
Subject: [oe] PREFERRED_PROVIDER syntax is eluding me...
In-Reply-To: <038201c79f6a$f9859720$6e01a8c0@twilight>
References: <038201c79f6a$f9859720$6e01a8c0@twilight>
Message-ID: <432beae0705281317t3464bacfr833d7ed6b28f374@mail.gmail.com>

On 5/26/07, Mike (mwester) <mwester at dls.net> wrote:
> I'm missing something simple, I expect.  But try as I might, I cannot figure
> this out.
>
> Bitbake 1.8.3, building unslung-image (worked fine on 1.6): Bitbake says:
> [snip]
> NOTE: multiple providers are available for runtime libc6-unslung (glibc,
> glibc-initial);
> NOTE: consider defining a PREFERRED_PROVIDER entry to match runtime
> libc6-unslung
> [snip]
>
> This is a problem, because with bitbake 1.8, without a preferred provider
> specified, it seems to try to build both.  But only glibc builds;
> glibc-initial fails (and the build loops forever).   This is easily fixed by
> adding the following line to the local.conf file:
>
> PREFERRED_PROVIDER_libc6-unslung = "glibc"
>
> Except that it doesn't do a blasted thing.  Neither does this line:
>
> PREFERRED_PROVIDERS += " libc6-unslung:glibc"
>
> Thinking that perhaps the "-unslung" was implied since the machine is
> "unslung", I tried:
>
> PREFERRED_PROVIDERS += " libc6:glibc"
>
> Still no change.  Being persistent, I tried every variant of the above that
> I could think of, to no avail.  It seems that bitbake is not understanding
> or processing the info provided.  The -D flag offers no further hints,
> either.
>
> For background, back in the glibc bitbake recipes, glibc-initial.bb does a
> "require" of glibc.bb (hence the multiple providers).  Near the tail-end of
> glibc.bb we find:
>
> PACKAGES_unslung = "libc6-unslung"
> RDEPENDS_libc6-unslung = "nslu2-linksys-libs"
> RPROVIDES_libc6-unslung = "libc6"
> FILES_libc6-unslung = "/lib/librt*"
>
> Figuring that perhaps the problem is that nothing actually "PROVIDES" libc6,
> and that maybe bitbake needs to see the build-time dependency in order to
> handle the run-time dependency PREFERRED_PROVIDER stuff, I even added
> PROVIDES_libc6-unslung = "libc6"
> to the glibc.bb recipe, and went back through the list of
> PREFERRED_PROVIDERS in the local.conf file.  No luck.  No difference.
>
> I finally hacked the glibc bitbake recipes so that glibc-initial doesn't
> "RPROVIDE" libc6 anymore.  Success - bitbake is happy.  But I'm not.  That
> doesn't seem like the correct way to resolve the multiple providers issue,
> and I expect that commiting such a change would (rightfully) anger many
> folks.
>
> If some kind soul could point me to the document or another recipe that
> provides the correct syntax for handling this, or provide a pointer to
> whatever it is that I'm missing, I'd be most grateful.
>

So it's RPROVIDES and not PROVIDES? Sounds like the problem may be
that PREFERRED_PROVIDERS is for non-R.... Is there an
RPREFERRED_PROVIDERS perhaps?

It's been a while since you posted, sid you get this resolved in the
meantime? Richard Purdie should have more insight into this.

-- 
Justin Patrin



From rpurdie at rpsys.net  Tue May 29 20:46:32 2007
From: rpurdie at rpsys.net (Richard Purdie)
Date: Tue, 29 May 2007 21:46:32 +0100
Subject: [oe] PREFERRED_PROVIDER syntax is eluding me...
In-Reply-To: <432beae0705281317t3464bacfr833d7ed6b28f374@mail.gmail.com>
References: <038201c79f6a$f9859720$6e01a8c0@twilight>
	<432beae0705281317t3464bacfr833d7ed6b28f374@mail.gmail.com>
Message-ID: <1180471592.5822.81.camel@localhost.localdomain>

On Mon, 2007-05-28 at 13:17 -0700, Justin Patrin wrote:
> On 5/26/07, Mike (mwester) <mwester at dls.net> wrote:
> > I'm missing something simple, I expect.  But try as I might, I cannot figure
> > this out.
> >
> > Bitbake 1.8.3, building unslung-image (worked fine on 1.6): Bitbake says:
> > [snip]
> > NOTE: multiple providers are available for runtime libc6-unslung (glibc,
> > glibc-initial);
> > NOTE: consider defining a PREFERRED_PROVIDER entry to match runtime
> > libc6-unslung
> > [snip]
> >
> > This is a problem, because with bitbake 1.8, without a preferred provider
> > specified, it seems to try to build both.  But only glibc builds;
> > glibc-initial fails (and the build loops forever).   This is easily fixed by
> > adding the following line to the local.conf file:
> >
> > PREFERRED_PROVIDER_libc6-unslung = "glibc"
> >
> > Except that it doesn't do a blasted thing.  Neither does this line:
> >
> > PREFERRED_PROVIDERS += " libc6-unslung:glibc"
> >
> > Thinking that perhaps the "-unslung" was implied since the machine is
> > "unslung", I tried:
> >
> > PREFERRED_PROVIDERS += " libc6:glibc"
> >
> > Still no change.  Being persistent, I tried every variant of the above that
> > I could think of, to no avail.  It seems that bitbake is not understanding
> > or processing the info provided.  The -D flag offers no further hints,
> > either.
> >
> > For background, back in the glibc bitbake recipes, glibc-initial.bb does a
> > "require" of glibc.bb (hence the multiple providers).  Near the tail-end of
> > glibc.bb we find:
> >
> > PACKAGES_unslung = "libc6-unslung"
> > RDEPENDS_libc6-unslung = "nslu2-linksys-libs"
> > RPROVIDES_libc6-unslung = "libc6"
> > FILES_libc6-unslung = "/lib/librt*"
> >
> > Figuring that perhaps the problem is that nothing actually "PROVIDES" libc6,
> > and that maybe bitbake needs to see the build-time dependency in order to
> > handle the run-time dependency PREFERRED_PROVIDER stuff, I even added
> > PROVIDES_libc6-unslung = "libc6"
> > to the glibc.bb recipe, and went back through the list of
> > PREFERRED_PROVIDERS in the local.conf file.  No luck.  No difference.
> >
> > I finally hacked the glibc bitbake recipes so that glibc-initial doesn't
> > "RPROVIDE" libc6 anymore.  Success - bitbake is happy.  But I'm not.  That
> > doesn't seem like the correct way to resolve the multiple providers issue,
> > and I expect that commiting such a change would (rightfully) anger many
> > folks.
> >
> > If some kind soul could point me to the document or another recipe that
> > provides the correct syntax for handling this, or provide a pointer to
> > whatever it is that I'm missing, I'd be most grateful.
> >
> 
> So it's RPROVIDES and not PROVIDES? Sounds like the problem may be
> that PREFERRED_PROVIDERS is for non-R.... Is there an
> RPREFERRED_PROVIDERS perhaps?
> 
> It's been a while since you posted, sid you get this resolved in the
> meantime? Richard Purdie should have more insight into this.

Er, hmm, right. The providers code is still a bit of a mystery to me
too ;-)

What you didn't say is that you did:

PROVIDES_unslung = "virtual/libc virtual/${TARGET_PREFIX}libc-for-gcc libc6-unslung"

so this file no longer provides glibc and therefore anything involving
glibc won't help. At a guess I'd try something like:

PREFERRED_PROVIDER_libc6-unslung = "libc6-unslung"

Of course I have to ask why you're doing this at all? It looks a bit
hatstand and I wonder why PREFERRED_VERSION_glibc = "2.2.5" wasn't
enough? ;-) (not that it shouldn't work)

Cheers,

Richard





From mwester at dls.net  Wed May 30 03:27:41 2007
From: mwester at dls.net (Mike (mwester))
Date: Tue, 29 May 2007 22:27:41 -0500
Subject: [oe] PREFERRED_PROVIDER syntax is eluding me...
References: <038201c79f6a$f9859720$6e01a8c0@twilight>
	<432beae0705281317t3464bacfr833d7ed6b28f374@mail.gmail.com>
	<1180471592.5822.81.camel@localhost.localdomain>
Message-ID: <054801c7a26a$7aec5450$6e01a8c0@twilight>

First, sorry for the late reply.

Richard Purdie writes:
> What you didn't say is that you did:
>
> PROVIDES_unslung = "virtual/libc virtual/${TARGET_PREFIX}libc-for-gcc
libc6-unslung"

Yes, I committed that change/fix over the weekend (see below).  Previously
it read just:
PROVIDES_unslung = "virtual/libc virtual/${TARGET_PREFIX}libc-for-gcc"
(without the final "libc6-unslung" on it).

> so this file no longer provides glibc and therefore anything involving
> glibc won't help. At a guess I'd try something like:
>
> PREFERRED_PROVIDER_libc6-unslung = "libc6-unslung"

I actually used:
PREFERRED_PROVIDER_libc6-unslung = "glibc"
My logic was that there were multiple providers for libc6-unslung (glibc's
bb file and glibc-initial's bb file), and that the value the variable was
set to referred to the bitbake recipe that should be preferred for building
of the object named "libc6-unslung".

I tested with so many combinations that my eyes crossed.  I don't recall if
that combination (the change to PROVIDES_unslung above was ever tested with
PREFERRED_PROVIDER_libc6-unslung="libc6-unslung", or not.  I can test that
if that's a more correct solution.

> Of course I have to ask why you're doing this at all? It looks a bit
> hatstand and I wonder why PREFERRED_VERSION_glibc = "2.2.5" wasn't
> enough? ;-) (not that it shouldn't work)

Hatstand, huh?  :-)  I haven't heard that expression, but I think I get it
:-).  I committed the fix I discovered, not because it was necesarily The
Right Fix(tm), but because it worked and the changes were guaranteed to be
localized to Unslung (i.e. I wouldn't risk messing up anyone else's distro's
with the fix I selected).

As for why it's this way, I can't say.  Unslung is itself a strange
creation - and its been in OE for a long time.  Together that seems to
result in some strange constructs.  I'm striving to keep it building in OE,
in the hopes that there might be a compelling feature or event that would
make a new Unslung release interesting at some point in the future.
However, the likelihood of such an event currently appears to be slim enough
that I'm not sure it's a good idea to do significant rework and retesting on
it, frankly.  So I'm in favor of a small simple fix, even a kludgy one, if
it'll work.

> Cheers,
>
> Richard

Thanks!  If you or anyone else has strong feelings about this, and how it's
been addressed, let me know (preferably with some guidance on what would be
acceptable).

Regards,
Mike (mwester)





From rodrigo.vivi at gmail.com  Wed May 30 22:42:53 2007
From: rodrigo.vivi at gmail.com (Rodrigo Vivi)
Date: Wed, 30 May 2007 19:42:53 -0300
Subject: [oe] strange error: missing depends...
Message-ID: <bdb0025f0705301542s7e64e43cjb5b737e7f1958806@mail.gmail.com>

Hi there,

Some days ago I was using the bitbake1.6 to build my packages and it
was working fine, but someday without any apparently reason it stopped
to work.

Then, after a big looser fight I've decided to change to bitbake1.8
and the problem was apparently solved... I was seeing the packages
being build...
But in the end, for my surprise, I've noticed that a lot of depends
wasn't build!

Since my task file is not under official repository yet I'm sending in
this email.

Does any body have any idea?

Thanks,
vivijim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: task-mamona.bb
Type: application/octet-stream
Size: 1216 bytes
Desc: not available
URL: <http://lists.openembedded.org/pipermail/openembedded-devel/attachments/20070530/f80ae2f5/attachment-0002.obj>

From freyther at gmx.net  Thu May 31 09:22:10 2007
From: freyther at gmx.net (Holger Freyther)
Date: Thu, 31 May 2007 11:22:10 +0200
Subject: [oe] strange error: missing depends...
In-Reply-To: <bdb0025f0705301542s7e64e43cjb5b737e7f1958806@mail.gmail.com>
References: <bdb0025f0705301542s7e64e43cjb5b737e7f1958806@mail.gmail.com>
Message-ID: <3A8255A2-0573-4DE5-AF68-B87A30062F3F@gmx.net>


Am 31.05.2007 um 00:42 schrieb Rodrigo Vivi:

> Hi there,
>
> Some days ago I was using the bitbake1.6 to build my packages and it
> was working fine, but someday without any apparently reason it stopped
> to work.
>
> Does any body have any idea?


Hi,

koen says that the recipe looks "OK" to him. He finds that  
'RDEPENDS_task-mamona-all := "${PACKAGES}"' a bit suspicious.

What version of BitBake do you have, is the graph generated by task- 
mamona (-g option of BitBake) having the DEPENDS/RDEPENDS? What is  
bitbake -vvv saying what it tries to build, do the depends show up at  
all?


kind regards
	z.



From rodrigo.vivi at gmail.com  Thu May 31 20:49:22 2007
From: rodrigo.vivi at gmail.com (Rodrigo Vivi)
Date: Thu, 31 May 2007 17:49:22 -0300
Subject: [oe] strange error: missing depends...
In-Reply-To: <3A8255A2-0573-4DE5-AF68-B87A30062F3F@gmx.net>
References: <bdb0025f0705301542s7e64e43cjb5b737e7f1958806@mail.gmail.com>
	<3A8255A2-0573-4DE5-AF68-B87A30062F3F@gmx.net>
Message-ID: <bdb0025f0705311349x73f2f285ge65c3aaa06a4fa21@mail.gmail.com>

I've just noticed that everything is fine with depends, rdepends and
with the task-mamona itself.

My log shows that do_compile and do_package was called for every
package, but for some reason a few of them like bash do not call the
do_package_deb function..

In the log I have this:
NOTE: package bash-3.2-r1: task do_package: started
NOTE: package bash-3.2-r1: task do_package: completed

But I've introduced some debug messages and I'm pretty sure that the
do_package_deb function was not called to this package.

but I can not figure it out...
Why it is called for some packages and not called for other ones.

Does any body has an idea about it?

Thanks,
vivijim

On 5/31/07, Holger Freyther <freyther at gmx.net> wrote:
>
> Am 31.05.2007 um 00:42 schrieb Rodrigo Vivi:
>
> > Hi there,
> >
> > Some days ago I was using the bitbake1.6 to build my packages and it
> > was working fine, but someday without any apparently reason it stopped
> > to work.
> >
> > Does any body have any idea?
>
>
> Hi,
>
> koen says that the recipe looks "OK" to him. He finds that
> 'RDEPENDS_task-mamona-all := "${PACKAGES}"' a bit suspicious.
>
> What version of BitBake do you have, is the graph generated by task-
> mamona (-g option of BitBake) having the DEPENDS/RDEPENDS? What is
> bitbake -vvv saying what it tries to build, do the depends show up at
> all?
>
>
> kind regards
>         z.
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>



From koen at dominion.kabel.utwente.nl  Thu May 31 21:22:19 2007
From: koen at dominion.kabel.utwente.nl (Koen Kooi)
Date: Thu, 31 May 2007 23:22:19 +0200
Subject: [oe] Glibc 2.6 added, please test
Message-ID: <465F3C8B.80200@dominion.kabel.utwente.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Glibc 2.6 has just been added to OE, please test it and report bugs.

TIA,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGXzyLMkyGM64RGpERAk8EAJ9vszt8ghLdUoVvRLarLWNM40TpUgCfToVG
QCCW9dQifUQvV8H8H+5VVR0=
=9U8f
-----END PGP SIGNATURE-----