* Re: sdk path problem
From: Tom Rini @ 2011-10-20 16:38 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <CAMKF1spFtH+40uCMJO1nfV2h90n1FnEusooOHq3gBmrA5L+zDw@mail.gmail.com>
On Thu, Oct 20, 2011 at 9:27 AM, Khem Raj <raj.khem@gmail.com> wrote:
> On Thu, Oct 20, 2011 at 1:22 AM, James Limbouris
> <james@digitalmatter.com.au> wrote:
>> Hi,
>>
>> I have been using meta-toolchain-qte in the past to cross compile a Qt app, and the Linux kernel.
>> Recently I replaced my old SDK image with a fresh one, and found that I could not link vmlinux anymore.
>>
>> When building the kernel, I use the following ('rica' is the distribution name):
>> export PATH=$PATH:/usr/local/rica-eglibc-i686-armv5te/sysroots/i686-ricasdk-linux/usr/bin/armv5te-rica-linux-gnueabi/
>> make ARCH=arm CROSS_COMPILE=arm-rica-linux-gnueabi- zImage
>>
>> The new error message is:
>>
>> Kernel: arch/arm/boot/Image is ready
>> AS arch/arm/boot/compressed/head.o
>> GZIP arch/arm/boot/compressed/piggy.gz
>> CC arch/arm/boot/compressed/misc.o
>> AS arch/arm/boot/compressed/piggy.o
>> LD arch/arm/boot/compressed/vmlinux
>> arm-rica-linux-gnueabi-ld: cannot find libgcc.a: No such file or directory
>>
>> Comparing the build with the old sdk to the build with the new one, I find that the command line for linking has changed from:
>>
>> arm-rica-linux-gnueabi-ld -EL --defsym zreladdr=0x80008000 --defsym initrd_phys=0x80800000 --defsym params_phys=0x80000100 -p --no-undefined -X /usr/local/rica-eglibc-i686-armv5te/sysroots/arm-rica-linux-gnueabi/usr/lib/arm-rica-linux-gnueabi/4.5.4/libgcc.a -T arch/arm/boot/compressed/vmlinux.lds arch/arm/boot/compressed/head.o arch/arm/boot/compressed/piggy.o arch/arm/boot/compressed/misc.o -o arch/arm/boot/compressed/vmlinux
>>
>> to:
>>
>> arm-rica-linux-gnueabi-ld -EL --defsym zreladdr=0x80008000 --defsym initrd_phys=0x80800000 --defsym params_phys=0x80000100 -p --no-undefined -X libgcc.a -T arch/arm/boot/compressed/vmlinux.lds arch/arm/boot/compressed/head.o arch/arm/boot/compressed/piggy.o arch/arm/boot/compressed/misc.o -o arch/arm/boot/compressed/vmlinux
>>
>> So libgcc.a has lost its path qualification.
>> I also straced the two linker commands, and found that they differed in one sequence.
>>
>> Old:
>> lstat64("/usr/local/rica-eglibc-i686-armv5te", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
>> lstat64("/usr/local/rica-eglibc-i686-armv5te/sysroots", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
>> lstat64("/usr/local/rica-eglibc-i686-armv5te/sysroots/arm-rica-linux-gnueabi", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
>>
>> New:
>> lstat64("/usr/local/rica-eglibc-i686-armv5te", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
>> lstat64("/usr/local/rica-eglibc-i686-armv5te/sysroots", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
>> lstat64("/usr/local/rica-eglibc-i686-armv5te/sysroots/arm-rica-linux-gnueabi", 0xbffe67cc) = -1 ENOENT (No such file or directory)
>>
>> Both toolchains are looking for a sysroot at 'arm-rica-linux-gnueabi', but the new toolchain should be looking at 'armv5te-rica-linux-gnueabi', as the names have changed.
>> I'm not yet acquainted with the darker arts of toolchain generation. Can anyone help with this?
>>
>
> can you post the build logs and configure logs of
> binutils sdk
I've seen the same problem with just plain old meta-toolchain and
trying to build something simple like u-boot. Hadn't had the time to
dig at it tho.
--
Tom
^ permalink raw reply
* Re: sdk path problem
From: Khem Raj @ 2011-10-20 16:27 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <840A81C1B782724A8EB52725BD519EFF1A8633@MBX20.4emm.local>
On Thu, Oct 20, 2011 at 1:22 AM, James Limbouris
<james@digitalmatter.com.au> wrote:
> Hi,
>
> I have been using meta-toolchain-qte in the past to cross compile a Qt app, and the Linux kernel.
> Recently I replaced my old SDK image with a fresh one, and found that I could not link vmlinux anymore.
>
> When building the kernel, I use the following ('rica' is the distribution name):
> export PATH=$PATH:/usr/local/rica-eglibc-i686-armv5te/sysroots/i686-ricasdk-linux/usr/bin/armv5te-rica-linux-gnueabi/
> make ARCH=arm CROSS_COMPILE=arm-rica-linux-gnueabi- zImage
>
> The new error message is:
>
> Kernel: arch/arm/boot/Image is ready
> AS arch/arm/boot/compressed/head.o
> GZIP arch/arm/boot/compressed/piggy.gz
> CC arch/arm/boot/compressed/misc.o
> AS arch/arm/boot/compressed/piggy.o
> LD arch/arm/boot/compressed/vmlinux
> arm-rica-linux-gnueabi-ld: cannot find libgcc.a: No such file or directory
>
> Comparing the build with the old sdk to the build with the new one, I find that the command line for linking has changed from:
>
> arm-rica-linux-gnueabi-ld -EL --defsym zreladdr=0x80008000 --defsym initrd_phys=0x80800000 --defsym params_phys=0x80000100 -p --no-undefined -X /usr/local/rica-eglibc-i686-armv5te/sysroots/arm-rica-linux-gnueabi/usr/lib/arm-rica-linux-gnueabi/4.5.4/libgcc.a -T arch/arm/boot/compressed/vmlinux.lds arch/arm/boot/compressed/head.o arch/arm/boot/compressed/piggy.o arch/arm/boot/compressed/misc.o -o arch/arm/boot/compressed/vmlinux
>
> to:
>
> arm-rica-linux-gnueabi-ld -EL --defsym zreladdr=0x80008000 --defsym initrd_phys=0x80800000 --defsym params_phys=0x80000100 -p --no-undefined -X libgcc.a -T arch/arm/boot/compressed/vmlinux.lds arch/arm/boot/compressed/head.o arch/arm/boot/compressed/piggy.o arch/arm/boot/compressed/misc.o -o arch/arm/boot/compressed/vmlinux
>
> So libgcc.a has lost its path qualification.
> I also straced the two linker commands, and found that they differed in one sequence.
>
> Old:
> lstat64("/usr/local/rica-eglibc-i686-armv5te", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
> lstat64("/usr/local/rica-eglibc-i686-armv5te/sysroots", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
> lstat64("/usr/local/rica-eglibc-i686-armv5te/sysroots/arm-rica-linux-gnueabi", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
>
> New:
> lstat64("/usr/local/rica-eglibc-i686-armv5te", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
> lstat64("/usr/local/rica-eglibc-i686-armv5te/sysroots", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
> lstat64("/usr/local/rica-eglibc-i686-armv5te/sysroots/arm-rica-linux-gnueabi", 0xbffe67cc) = -1 ENOENT (No such file or directory)
>
> Both toolchains are looking for a sysroot at 'arm-rica-linux-gnueabi', but the new toolchain should be looking at 'armv5te-rica-linux-gnueabi', as the names have changed.
> I'm not yet acquainted with the darker arts of toolchain generation. Can anyone help with this?
>
can you post the build logs and configure logs of
binutils sdk
> Regards,
> James Limbouris
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
^ permalink raw reply
* Re: [CONSOLIDATED PULL 14/16] distro-tracking: update data for some toolchain recipes
From: Koen Kooi @ 2011-10-20 16:24 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <1319126135.2410.51.camel@ted>
Op 20 okt. 2011, om 17:55 heeft Richard Purdie het volgende geschreven:
> On Thu, 2011-10-20 at 16:36 +0200, Martin Jansa wrote:
>> On Thu, Oct 20, 2011 at 03:25:52PM +0100, Richard Purdie wrote:
>>> On Wed, 2011-10-19 at 16:33 -0700, Saul Wold wrote:
>>>> On 10/19/2011 12:00 PM, Otavio Salvador wrote:
>>>>> On Wed, Oct 19, 2011 at 16:30, Khem Raj<raj.khem@gmail.com> wrote:
>>>>> ...
>>>>>>>>> Many upstreams we can't track if updates are required automagically, so
>>>>>>>>> we
>>>>>>>>> need a place to record when the last manual check was, also possible
>>>>>>>>> reasons
>>>>>>>>> why we should not update to newer versions, ...
>>>>>>
>>>>>> hmm manual check means it has to be done manually is there any thing
>>>>>> that needs it ?
>>>>>>
>>>>>> I think unless they are distro specific which seems not since they are
>>>>>> in oe-core
>>>>>> they could exist in recipes thats my opinion.
>>>>>
>>>>> I agree that this should be put into the recipes. Besides this allows
>>>>> for checking if it was updated when the version has been updated.
>>>>>
>>>>> If done right, when updating the version this data will be updated
>>>>> together. I see no change in the amount of changes.
>>>>>
>>>>> A plus of this choice is it will be more difficult to forget to update
>>>>> that info. This happened in last qt update for an example.
>>>>>
>>>>
>>>> This may need to be something that the TSC brings up, possibly we can
>>>> talk about it in Prague next week.
>>>
>>> So just to give some background here, the information in those files was
>>> added by Yocto people to give some idea of the update status of various
>>> recipes. This included when the version was last checked/updated for
>>> recipes which we can't automate that process for, when certain cleanup
>>> checks were made, what the general state of the recipe was and who on
>>> the Yocto team was specifically looking after given recipes.
>>>
>>> When it was discussed, some of it was Yocto specific, some of it wasn't
>>> and popular opinion was against it going into the recipes themselves. I
>>> was ok with that given we have the pn- overrides and can handle the
>>> problem that way just fine.
>>>
>>> OE-Core happened and we kept the data with OE-Core at least for now. We
>>> have several options:
>>>
>>> a) Keep the data where it is
>>> b) Merge the data into the recipes
>>> c) Move the data out of OE-Core
>>>
>>> Since a lot of that data is fairly Yocto process specific, it may make
>>> sense to move it over to meta-yocto...
>>
>> I don't like "global" files where many people should maintain their info
>> and it's so easy to forgot when it's somewhere else then real changes
>> (like it was with checksums.ini and sane-src*.ini).
>
> Some data does make sense to be maintained globally and I don't think we
> should automatically say its bad. It depends what the use case is and
> how its intended to be used.
>
>> So I vote for b) Merge the data into the recipes, only problem with this
>> is that if we have 2 versions of foo (foo_1.0.bb, foo_git.bb) without
>> any foo.inc, will we create foo.inc just for distro-tracking info? Maybe
>> we should and move at least DESCRIPTION and similar variables too.
>>
>> c) moving it to meta-yocto will probably make distro-tracking info even
>> more outdated as sometimes different people then who did upgrade in
>> oe-core will have to update distro-tracking info in this layer (this is
>> also the case now sometimes, but with distro-tracking info in recipe we
>> can try better to update it with upgrades).
>
> I'd actually like Saul's view on this since he generally looks after
> that data. There as been discussion about whether it is "internal" yocto
> tracking stuff or whether its more general OE focused and I don't know
> what the answer is there. I think there is a mixture of uses. I'm also
> wary of "pushing" Yocto policy into OE which I think this might amount
> to.
>
> As a specific example, we've moved away from wanting MAINTAINER info in
> the recipes in the past and this gets us back there again. I don't
> really want to loop over adding data and then removing it again
> repeatedly so this needs thought/discussion. Who gets their name in the
> MAINTAINER field exactly? What is the process for that and what
> responsibilities does that person have?
The problem wasn't with MAINTAINER being in the recipe, the problem was MAINTAINER ending up in the ipk data. The 'abiword crashes' bugs we had years ago illustrated the problem clearly. Abiword only crashed if you used code sourcery binutils, but not with stock binutils. Graeme couldn't get the message thru that he was indeed maintaining abi in OE but wasn't responsible for people using broken toolchains. The specific abiword issue was resolved when the distro in question stopped using CSL stuff (familiar or angstrom, I forget).
I'm in favour of having info in the recipe (or bbappend!) who is looking after it if it doesn't end up in the output package.
Regardless of where to put the info, I would like to propose to orphan every recipe in OE-core and ask for volunteers. There's a ton of stuff I want to look after (bluez, gstreamer, pulse, avahi, X) which already has a maintainer from its yocto/poky/whatever legacy, but I feel is not being looked after with much attention. And adding to the problem is that most yocto people aren't using OE-core, but poky.
regards,
Koen
^ permalink raw reply
* Re: [CONSOLIDATED PULL 14/16] distro-tracking: update data for some toolchain recipes
From: Khem Raj @ 2011-10-20 16:18 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer; +Cc: Phil Blundell
In-Reply-To: <1319120752.2410.34.camel@ted>
On Thu, Oct 20, 2011 at 7:25 AM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> a) Keep the data where it is
> b) Merge the data into the recipes
We once had maintainers and then backed out of it
this would reintroduce that and bitbake might have
to eat more memory to parse this information.
> c) Move the data out of OE-Core
For now this would be a better solution IMO
>
> Since a lot of that data is fairly Yocto process specific, it may make
> sense to move it over to meta-yocto...
>
Yes it seems to be apt.
^ permalink raw reply
* Re: useradd class not working
From: Mark Hatle @ 2011-10-20 16:12 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <CAP9ODKp+c9sXx6A7Bw9VnRXOKgNP_3q2uJmJEpvBwWT=dgXdBQ@mail.gmail.com>
On 10/19/11 11:26 PM, Otavio Salvador wrote:
> Hello,
>
> I am using useradd in a recipe and it needs to add a group in the
> rootfs at build time. This doesn't work.
>
> it seems groupadd does nothing.
>
> Has someone used or tried it?
>
http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta-skeleton/recipes-skeleton/useradd/useradd-example.bb
That is the recipe that was used when testing this feature. If it no longer
works properly then something has recently broken in the groupadd functionality.
--Mark
^ permalink raw reply
* Re: [CONSOLIDATED PULL 14/16] distro-tracking: update data for some toolchain recipes
From: Eric Bénard @ 2011-10-20 16:02 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <CAP9ODKoFRiVnimZ3MDvK9S2v8JLykpR2-pWmmwz_2ua0pr-HfA@mail.gmail.com>
Hi,
Le 19/10/2011 21:00, Otavio Salvador a écrit :
> A plus of this choice is it will be more difficult to forget to update
> that info. This happened in last qt update for an example.
>
in fact that was in the first patch submitted but got lost in the v2 :-(
Eric
^ permalink raw reply
* Re: [CONSOLIDATED PULL 14/16] distro-tracking: update data for some toolchain recipes
From: Richard Purdie @ 2011-10-20 15:55 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <20111020143631.GJ3522@jama.jama.net>
On Thu, 2011-10-20 at 16:36 +0200, Martin Jansa wrote:
> On Thu, Oct 20, 2011 at 03:25:52PM +0100, Richard Purdie wrote:
> > On Wed, 2011-10-19 at 16:33 -0700, Saul Wold wrote:
> > > On 10/19/2011 12:00 PM, Otavio Salvador wrote:
> > > > On Wed, Oct 19, 2011 at 16:30, Khem Raj<raj.khem@gmail.com> wrote:
> > > > ...
> > > >>>>> Many upstreams we can't track if updates are required automagically, so
> > > >>>>> we
> > > >>>>> need a place to record when the last manual check was, also possible
> > > >>>>> reasons
> > > >>>>> why we should not update to newer versions, ...
> > > >>
> > > >> hmm manual check means it has to be done manually is there any thing
> > > >> that needs it ?
> > > >>
> > > >> I think unless they are distro specific which seems not since they are
> > > >> in oe-core
> > > >> they could exist in recipes thats my opinion.
> > > >
> > > > I agree that this should be put into the recipes. Besides this allows
> > > > for checking if it was updated when the version has been updated.
> > > >
> > > > If done right, when updating the version this data will be updated
> > > > together. I see no change in the amount of changes.
> > > >
> > > > A plus of this choice is it will be more difficult to forget to update
> > > > that info. This happened in last qt update for an example.
> > > >
> > >
> > > This may need to be something that the TSC brings up, possibly we can
> > > talk about it in Prague next week.
> >
> > So just to give some background here, the information in those files was
> > added by Yocto people to give some idea of the update status of various
> > recipes. This included when the version was last checked/updated for
> > recipes which we can't automate that process for, when certain cleanup
> > checks were made, what the general state of the recipe was and who on
> > the Yocto team was specifically looking after given recipes.
> >
> > When it was discussed, some of it was Yocto specific, some of it wasn't
> > and popular opinion was against it going into the recipes themselves. I
> > was ok with that given we have the pn- overrides and can handle the
> > problem that way just fine.
> >
> > OE-Core happened and we kept the data with OE-Core at least for now. We
> > have several options:
> >
> > a) Keep the data where it is
> > b) Merge the data into the recipes
> > c) Move the data out of OE-Core
> >
> > Since a lot of that data is fairly Yocto process specific, it may make
> > sense to move it over to meta-yocto...
>
> I don't like "global" files where many people should maintain their info
> and it's so easy to forgot when it's somewhere else then real changes
> (like it was with checksums.ini and sane-src*.ini).
Some data does make sense to be maintained globally and I don't think we
should automatically say its bad. It depends what the use case is and
how its intended to be used.
> So I vote for b) Merge the data into the recipes, only problem with this
> is that if we have 2 versions of foo (foo_1.0.bb, foo_git.bb) without
> any foo.inc, will we create foo.inc just for distro-tracking info? Maybe
> we should and move at least DESCRIPTION and similar variables too.
>
> c) moving it to meta-yocto will probably make distro-tracking info even
> more outdated as sometimes different people then who did upgrade in
> oe-core will have to update distro-tracking info in this layer (this is
> also the case now sometimes, but with distro-tracking info in recipe we
> can try better to update it with upgrades).
I'd actually like Saul's view on this since he generally looks after
that data. There as been discussion about whether it is "internal" yocto
tracking stuff or whether its more general OE focused and I don't know
what the answer is there. I think there is a mixture of uses. I'm also
wary of "pushing" Yocto policy into OE which I think this might amount
to.
As a specific example, we've moved away from wanting MAINTAINER info in
the recipes in the past and this gets us back there again. I don't
really want to loop over adding data and then removing it again
repeatedly so this needs thought/discussion. Who gets their name in the
MAINTAINER field exactly? What is the process for that and what
responsibilities does that person have?
Cheers,
Richard
^ permalink raw reply
* Re: [CONSOLIDATED PULL 14/16] distro-tracking: update data for some toolchain recipes
From: Koen Kooi @ 2011-10-20 14:48 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <20111020143631.GJ3522@jama.jama.net>
Op 20 okt. 2011, om 16:36 heeft Martin Jansa het volgende geschreven:
> On Thu, Oct 20, 2011 at 03:25:52PM +0100, Richard Purdie wrote:
>> On Wed, 2011-10-19 at 16:33 -0700, Saul Wold wrote:
>>> On 10/19/2011 12:00 PM, Otavio Salvador wrote:
>>>> On Wed, Oct 19, 2011 at 16:30, Khem Raj<raj.khem@gmail.com> wrote:
>>>> ...
>>>>>>>> Many upstreams we can't track if updates are required automagically, so
>>>>>>>> we
>>>>>>>> need a place to record when the last manual check was, also possible
>>>>>>>> reasons
>>>>>>>> why we should not update to newer versions, ...
>>>>>
>>>>> hmm manual check means it has to be done manually is there any thing
>>>>> that needs it ?
>>>>>
>>>>> I think unless they are distro specific which seems not since they are
>>>>> in oe-core
>>>>> they could exist in recipes thats my opinion.
>>>>
>>>> I agree that this should be put into the recipes. Besides this allows
>>>> for checking if it was updated when the version has been updated.
>>>>
>>>> If done right, when updating the version this data will be updated
>>>> together. I see no change in the amount of changes.
>>>>
>>>> A plus of this choice is it will be more difficult to forget to update
>>>> that info. This happened in last qt update for an example.
>>>>
>>>
>>> This may need to be something that the TSC brings up, possibly we can
>>> talk about it in Prague next week.
>>
>> So just to give some background here, the information in those files was
>> added by Yocto people to give some idea of the update status of various
>> recipes. This included when the version was last checked/updated for
>> recipes which we can't automate that process for, when certain cleanup
>> checks were made, what the general state of the recipe was and who on
>> the Yocto team was specifically looking after given recipes.
>>
>> When it was discussed, some of it was Yocto specific, some of it wasn't
>> and popular opinion was against it going into the recipes themselves. I
>> was ok with that given we have the pn- overrides and can handle the
>> problem that way just fine.
>>
>> OE-Core happened and we kept the data with OE-Core at least for now. We
>> have several options:
>>
>> a) Keep the data where it is
>> b) Merge the data into the recipes
>> c) Move the data out of OE-Core
>>
>> Since a lot of that data is fairly Yocto process specific, it may make
>> sense to move it over to meta-yocto...
>
> I don't like "global" files where many people should maintain their info
> and it's so easy to forgot when it's somewhere else then real changes
> (like it was with checksums.ini and sane-src*.ini).
>
> So I vote for b) Merge the data into the recipes, only problem with this
> is that if we have 2 versions of foo (foo_1.0.bb, foo_git.bb) without
> any foo.inc, will we create foo.inc just for distro-tracking info? Maybe
> we should and move at least DESCRIPTION and similar variables too.
>
> c) moving it to meta-yocto will probably make distro-tracking info even
> more outdated as sometimes different people then who did upgrade in
> oe-core will have to update distro-tracking info in this layer (this is
> also the case now sometimes, but with distro-tracking info in recipe we
> can try better to update it with upgrades).
I agree completely with Martin.
regards,
Koen
^ permalink raw reply
* Re: [CONSOLIDATED PULL 14/16] distro-tracking: update data for some toolchain recipes
From: Martin Jansa @ 2011-10-20 14:36 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <1319120752.2410.34.camel@ted>
[-- Attachment #1: Type: text/plain, Size: 3286 bytes --]
On Thu, Oct 20, 2011 at 03:25:52PM +0100, Richard Purdie wrote:
> On Wed, 2011-10-19 at 16:33 -0700, Saul Wold wrote:
> > On 10/19/2011 12:00 PM, Otavio Salvador wrote:
> > > On Wed, Oct 19, 2011 at 16:30, Khem Raj<raj.khem@gmail.com> wrote:
> > > ...
> > >>>>> Many upstreams we can't track if updates are required automagically, so
> > >>>>> we
> > >>>>> need a place to record when the last manual check was, also possible
> > >>>>> reasons
> > >>>>> why we should not update to newer versions, ...
> > >>
> > >> hmm manual check means it has to be done manually is there any thing
> > >> that needs it ?
> > >>
> > >> I think unless they are distro specific which seems not since they are
> > >> in oe-core
> > >> they could exist in recipes thats my opinion.
> > >
> > > I agree that this should be put into the recipes. Besides this allows
> > > for checking if it was updated when the version has been updated.
> > >
> > > If done right, when updating the version this data will be updated
> > > together. I see no change in the amount of changes.
> > >
> > > A plus of this choice is it will be more difficult to forget to update
> > > that info. This happened in last qt update for an example.
> > >
> >
> > This may need to be something that the TSC brings up, possibly we can
> > talk about it in Prague next week.
>
> So just to give some background here, the information in those files was
> added by Yocto people to give some idea of the update status of various
> recipes. This included when the version was last checked/updated for
> recipes which we can't automate that process for, when certain cleanup
> checks were made, what the general state of the recipe was and who on
> the Yocto team was specifically looking after given recipes.
>
> When it was discussed, some of it was Yocto specific, some of it wasn't
> and popular opinion was against it going into the recipes themselves. I
> was ok with that given we have the pn- overrides and can handle the
> problem that way just fine.
>
> OE-Core happened and we kept the data with OE-Core at least for now. We
> have several options:
>
> a) Keep the data where it is
> b) Merge the data into the recipes
> c) Move the data out of OE-Core
>
> Since a lot of that data is fairly Yocto process specific, it may make
> sense to move it over to meta-yocto...
I don't like "global" files where many people should maintain their info
and it's so easy to forgot when it's somewhere else then real changes
(like it was with checksums.ini and sane-src*.ini).
So I vote for b) Merge the data into the recipes, only problem with this
is that if we have 2 versions of foo (foo_1.0.bb, foo_git.bb) without
any foo.inc, will we create foo.inc just for distro-tracking info? Maybe
we should and move at least DESCRIPTION and similar variables too.
c) moving it to meta-yocto will probably make distro-tracking info even
more outdated as sometimes different people then who did upgrade in
oe-core will have to update distro-tracking info in this layer (this is
also the case now sometimes, but with distro-tracking info in recipe we
can try better to update it with upgrades).
Regards,
--
Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]
^ permalink raw reply
* Re: [CONSOLIDATED PULL 14/16] distro-tracking: update data for some toolchain recipes
From: Richard Purdie @ 2011-10-20 14:25 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer; +Cc: Phil Blundell
In-Reply-To: <4E9F5E5A.6040002@intel.com>
On Wed, 2011-10-19 at 16:33 -0700, Saul Wold wrote:
> On 10/19/2011 12:00 PM, Otavio Salvador wrote:
> > On Wed, Oct 19, 2011 at 16:30, Khem Raj<raj.khem@gmail.com> wrote:
> > ...
> >>>>> Many upstreams we can't track if updates are required automagically, so
> >>>>> we
> >>>>> need a place to record when the last manual check was, also possible
> >>>>> reasons
> >>>>> why we should not update to newer versions, ...
> >>
> >> hmm manual check means it has to be done manually is there any thing
> >> that needs it ?
> >>
> >> I think unless they are distro specific which seems not since they are
> >> in oe-core
> >> they could exist in recipes thats my opinion.
> >
> > I agree that this should be put into the recipes. Besides this allows
> > for checking if it was updated when the version has been updated.
> >
> > If done right, when updating the version this data will be updated
> > together. I see no change in the amount of changes.
> >
> > A plus of this choice is it will be more difficult to forget to update
> > that info. This happened in last qt update for an example.
> >
>
> This may need to be something that the TSC brings up, possibly we can
> talk about it in Prague next week.
So just to give some background here, the information in those files was
added by Yocto people to give some idea of the update status of various
recipes. This included when the version was last checked/updated for
recipes which we can't automate that process for, when certain cleanup
checks were made, what the general state of the recipe was and who on
the Yocto team was specifically looking after given recipes.
When it was discussed, some of it was Yocto specific, some of it wasn't
and popular opinion was against it going into the recipes themselves. I
was ok with that given we have the pn- overrides and can handle the
problem that way just fine.
OE-Core happened and we kept the data with OE-Core at least for now. We
have several options:
a) Keep the data where it is
b) Merge the data into the recipes
c) Move the data out of OE-Core
Since a lot of that data is fairly Yocto process specific, it may make
sense to move it over to meta-yocto...
Cheers,
Richard
^ permalink raw reply
* Re: [CONSOLIDATED PULL - v2 00/26] More Updates and Fixes
From: Richard Purdie @ 2011-10-20 14:18 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <cover.1319096633.git.sgw@linux.intel.com>
On Thu, 2011-10-20 at 00:50 -0700, Saul Wold wrote:
> Richard,
>
> This adds on to yesterday's Consolidated Pull with more patches for
> both updates and fixes.
>
> a couple of note: Anders' module.bbclass change
> Otavio's distubute_src, this change looks good,
> but needs your eyes.
>
> The rest are mostly straight forward updates, I held off Nitin's gmp change
> on this round do to a failure I was seeing when images failed to work.
>
> Sau!
>
>
> The following changes since commit e31dd9b65f3b03f79cabab25eca157532de3bd9c:
>
> fontconfig: fix fix-pkgconfig.patch (2011-10-18 18:13:47 +0100)
>
> are available in the git repository at:
> git://git.openembedded.org/openembedded-core-contrib sgw/stage2
> http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=sgw/stage2
>
> Anders Darander (1):
> module.bbclass: add lock to prevent error bulding ext modules
>
> Darren Hart (1):
> insane.bbclass: print full path on invalid LICENSE_FILES_CHKSUM
>
> Joshua Lock (5):
> gst-plugins-good: update to 0.10.30
> tzdata: updated SRC_URI and update to 2011k
> tzcode-native: update SRC_URI to new IANA location
> gst-plugins-good: correctly handle gconf schema
> distro-tracking-fields: update fields for tzdata and gst-plugins-good
>
> Kang Kai (5):
> ghostscript: update to 9.04
> libxml-sax-perl: update to 0.99
> liburi-perl: update to 1.59
> libsdl: update to 1.2.14
> distro_tracking_fields: update packages tracking fields
>
> Khem Raj (3):
> bluez4: Add glib-2.0 to DEPENDS
> gcc-4.6: Upgrade SRCREV to latest FSF 4.6 branch
> gcc-4.6: Backport PR46934 fix
>
> Lauri Hintsala (1):
> poky: fix broken ubifs link in deploy folder
>
> Nitin A Kamble (5):
> x86 tune files: set baselib for x32 tune as libx32
> python-scons: upgrade from 2.0.1 to 2.1.0
> python-dbus: upgrade from 0.83.2 to 0.84.0
> libxml-parser-perl: upgrade from 2.40 to 2.41
> distro-tracking: update data for some toolchain recipes
>
> Otavio Salvador (1):
> src_distribute.bbclass, src_distribute_local.bbclass: mostly
> rewritten
>
> Saul Wold (2):
> ghostscript: Disable parallel make due to install issues
> ghostscript: renamed x86_64 to x86-64 for patch to work
>
> Wenzong Fan (2):
> ccache: update to 3.1.6
> chkconfig: Update to 1.3.55
I merged these apart from the second gst-good-plugin patch from Joshua
which Koen had feedback about. I tweaked the message for Nitin's x32
commit.
Cheers,
Richard
^ permalink raw reply
* Re: [PATCH 2/5] kernel.bbclass: respect MACHINE_KERNEL_PR
From: Richard Purdie @ 2011-10-20 13:56 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <7D5D6BF3-6F21-4CE5-8A30-F9154CDB9449@dominion.thruhere.net>
On Thu, 2011-10-20 at 14:54 +0200, Koen Kooi wrote:
> Op 20 okt. 2011, om 14:38 heeft Richard Purdie het volgende geschreven:
>
> > On Thu, 2011-10-20 at 13:29 +0200, Koen Kooi wrote:
> >> Op 20 okt. 2011, om 13:21 heeft Richard Purdie het volgende geschreven:
> >>
> >>> On Thu, 2011-10-20 at 08:23 +0200, Koen Kooi wrote:
> >>>> Op 28 sep. 2011, om 22:04 heeft Otavio Salvador het volgende geschreven:
> >>>>
> >>>>> On Wed, Sep 28, 2011 at 16:50, Richard Purdie
> >>>>> <richard.purdie@linuxfoundation.org> wrote:
> >>>>>>> This patch improves the current situation and I don't foresee the
> >>>>>>> autoPR code working soon
> >>>>>>
> >>>>>> Which is why we need to switch to that model and shake out the issues
> >>>>>> sooner than later. Enough is enough with the PR madness and we need to
> >>>>>> get to grips and fix it.
> >>>>>
> >>>>> I fully agree this is the way to go but this doesn't mean we ought to
> >>>>> hold this patch until all this happens. This patch allows the removal
> >>>>> of the kernel.bbclass from meta-oe so reducing the delta between
> >>>>> oe-core and meta-oe.
> >>>>
> >>>> So a month later and no sign of the mythical working
> >>>> auto-PR-incrementer or work on it.
> >>>
> >>> A month where we were stabilising for a release. Its on the 1.2 feature
> >>> list and as it happens I've been hearing questions about what is needed
> >>> here.
> >>>
> >>>> So can this patch go in? It would mean we can drop kernel.bbclass
> >>>> from meta-oe.
> >>>
> >>> I *HATE* this PR bumping stuff. I've just been told we likely need to
> >>> bump the PR for anything using libGL which once again shows that build
> >>> system basically failing to automate building things.
> >>>
> >>> So I'm drawing a line here and no, we can't take this. If its fine to
> >>> expect people to bump PR values manually for lib* changes, its fine for
> >>> kernels too. I'd suggest you do drop this from meta-oe and we start
> >>> building up pressure for the problem to get fixed properly rather than
> >>> letting people wallpaper over the cracks.
> >>
> >> I have products to ship, so treating meta-oe as a plaything and break
> >> this for the sake of breaking it is unacceptable. I'll let oe-core
> >> have the monopoly on high-qualitily, but broken metadata.
> >
> > Its not as if there isn't another way to handle this, it is a little
> > harder work I agree. This isn't breaking for the sake of breaking
> > either, its applying a bit of pressure to ensure we fix an underlying
> > problem we've had for a long time. I don't think fixing it will be easy,
> > I do think we need to though.
> >
> > Also, the idea never was to have everyone using bleeding edge for
> > shipping products. This is what stable releases are for?
>
> That's what stable releases are for, but I don't see a release for
> OE-core, do you? I see a poky release, but not an OE-core release.
As you are no doubt aware, that got discussed at the last TSC meeting.
Khem did volunteer to help with that, there is a branch there ready to
be tagged too and I was planning to raise progress with this at
tonight's TSC meeting.
Cheers,
Richard
^ permalink raw reply
* Re: [PATCH 2/5] kernel.bbclass: respect MACHINE_KERNEL_PR
From: Otavio Salvador @ 2011-10-20 13:02 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <7D5D6BF3-6F21-4CE5-8A30-F9154CDB9449@dominion.thruhere.net>
On Thu, Oct 20, 2011 at 10:54, Koen Kooi <koen@dominion.thruhere.net> wrote:
...
>> Also, the idea never was to have everyone using bleeding edge for
>> shipping products. This is what stable releases are for?
>
> That's what stable releases are for, but I don't see a release for OE-core, do you? I see a poky release, but not an OE-core release.
People, let's calm down.
I think since Richard disagree about pushing this patch and more then
one person disagree with Richard, TSC is the way to go.
--
Otavio Salvador O.S. Systems
E-mail: otavio@ossystems.com.br http://www.ossystems.com.br
Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
^ permalink raw reply
* Re: [PATCH 2/5] kernel.bbclass: respect MACHINE_KERNEL_PR
From: Koen Kooi @ 2011-10-20 12:54 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <1319114339.2410.5.camel@ted>
Op 20 okt. 2011, om 14:38 heeft Richard Purdie het volgende geschreven:
> On Thu, 2011-10-20 at 13:29 +0200, Koen Kooi wrote:
>> Op 20 okt. 2011, om 13:21 heeft Richard Purdie het volgende geschreven:
>>
>>> On Thu, 2011-10-20 at 08:23 +0200, Koen Kooi wrote:
>>>> Op 28 sep. 2011, om 22:04 heeft Otavio Salvador het volgende geschreven:
>>>>
>>>>> On Wed, Sep 28, 2011 at 16:50, Richard Purdie
>>>>> <richard.purdie@linuxfoundation.org> wrote:
>>>>>>> This patch improves the current situation and I don't foresee the
>>>>>>> autoPR code working soon
>>>>>>
>>>>>> Which is why we need to switch to that model and shake out the issues
>>>>>> sooner than later. Enough is enough with the PR madness and we need to
>>>>>> get to grips and fix it.
>>>>>
>>>>> I fully agree this is the way to go but this doesn't mean we ought to
>>>>> hold this patch until all this happens. This patch allows the removal
>>>>> of the kernel.bbclass from meta-oe so reducing the delta between
>>>>> oe-core and meta-oe.
>>>>
>>>> So a month later and no sign of the mythical working
>>>> auto-PR-incrementer or work on it.
>>>
>>> A month where we were stabilising for a release. Its on the 1.2 feature
>>> list and as it happens I've been hearing questions about what is needed
>>> here.
>>>
>>>> So can this patch go in? It would mean we can drop kernel.bbclass
>>>> from meta-oe.
>>>
>>> I *HATE* this PR bumping stuff. I've just been told we likely need to
>>> bump the PR for anything using libGL which once again shows that build
>>> system basically failing to automate building things.
>>>
>>> So I'm drawing a line here and no, we can't take this. If its fine to
>>> expect people to bump PR values manually for lib* changes, its fine for
>>> kernels too. I'd suggest you do drop this from meta-oe and we start
>>> building up pressure for the problem to get fixed properly rather than
>>> letting people wallpaper over the cracks.
>>
>> I have products to ship, so treating meta-oe as a plaything and break
>> this for the sake of breaking it is unacceptable. I'll let oe-core
>> have the monopoly on high-qualitily, but broken metadata.
>
> Its not as if there isn't another way to handle this, it is a little
> harder work I agree. This isn't breaking for the sake of breaking
> either, its applying a bit of pressure to ensure we fix an underlying
> problem we've had for a long time. I don't think fixing it will be easy,
> I do think we need to though.
>
> Also, the idea never was to have everyone using bleeding edge for
> shipping products. This is what stable releases are for?
That's what stable releases are for, but I don't see a release for OE-core, do you? I see a poky release, but not an OE-core release.
^ permalink raw reply
* Re: [CONSOLIDATED PULL - v2 09/26] x86 tune files: set baselib for x32 tune as libx32
From: Richard Purdie @ 2011-10-20 12:44 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <1319101363.22985.259.camel@phil-desktop>
On Thu, 2011-10-20 at 10:02 +0100, Phil Blundell wrote:
> On Thu, 2011-10-20 at 00:50 -0700, Saul Wold wrote:
> > From: Nitin A Kamble <nitin.a.kamble@intel.com>
> >
> > Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
>
> Why is this a good thing? There is no explanation in the commit
> message.
Agreed, we need to improve the commit messages. I've merged this one
with some additional comments but can people please keep good commit
messages in mind.
Cheers,
Richard
^ permalink raw reply
* Re: [PATCH 2/5] kernel.bbclass: respect MACHINE_KERNEL_PR
From: Richard Purdie @ 2011-10-20 12:38 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <46567209-1B97-42F5-B5DF-E34B823F6BF7@dominion.thruhere.net>
On Thu, 2011-10-20 at 13:29 +0200, Koen Kooi wrote:
> Op 20 okt. 2011, om 13:21 heeft Richard Purdie het volgende geschreven:
>
> > On Thu, 2011-10-20 at 08:23 +0200, Koen Kooi wrote:
> >> Op 28 sep. 2011, om 22:04 heeft Otavio Salvador het volgende geschreven:
> >>
> >>> On Wed, Sep 28, 2011 at 16:50, Richard Purdie
> >>> <richard.purdie@linuxfoundation.org> wrote:
> >>>>> This patch improves the current situation and I don't foresee the
> >>>>> autoPR code working soon
> >>>>
> >>>> Which is why we need to switch to that model and shake out the issues
> >>>> sooner than later. Enough is enough with the PR madness and we need to
> >>>> get to grips and fix it.
> >>>
> >>> I fully agree this is the way to go but this doesn't mean we ought to
> >>> hold this patch until all this happens. This patch allows the removal
> >>> of the kernel.bbclass from meta-oe so reducing the delta between
> >>> oe-core and meta-oe.
> >>
> >> So a month later and no sign of the mythical working
> >> auto-PR-incrementer or work on it.
> >
> > A month where we were stabilising for a release. Its on the 1.2 feature
> > list and as it happens I've been hearing questions about what is needed
> > here.
> >
> >> So can this patch go in? It would mean we can drop kernel.bbclass
> >> from meta-oe.
> >
> > I *HATE* this PR bumping stuff. I've just been told we likely need to
> > bump the PR for anything using libGL which once again shows that build
> > system basically failing to automate building things.
> >
> > So I'm drawing a line here and no, we can't take this. If its fine to
> > expect people to bump PR values manually for lib* changes, its fine for
> > kernels too. I'd suggest you do drop this from meta-oe and we start
> > building up pressure for the problem to get fixed properly rather than
> > letting people wallpaper over the cracks.
>
> I have products to ship, so treating meta-oe as a plaything and break
> this for the sake of breaking it is unacceptable. I'll let oe-core
> have the monopoly on high-qualitily, but broken metadata.
Its not as if there isn't another way to handle this, it is a little
harder work I agree. This isn't breaking for the sake of breaking
either, its applying a bit of pressure to ensure we fix an underlying
problem we've had for a long time. I don't think fixing it will be easy,
I do think we need to though.
Also, the idea never was to have everyone using bleeding edge for
shipping products. This is what stable releases are for?
Cheers,
Richard
^ permalink raw reply
* Re: [PATCH 2/5] kernel.bbclass: respect MACHINE_KERNEL_PR
From: Frans Meulenbroeks @ 2011-10-20 11:53 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <46567209-1B97-42F5-B5DF-E34B823F6BF7@dominion.thruhere.net>
[-- Attachment #1: Type: text/plain, Size: 2219 bytes --]
2011/10/20 Koen Kooi <koen@dominion.thruhere.net>
>
> Op 20 okt. 2011, om 13:21 heeft Richard Purdie het volgende geschreven:
>
> > On Thu, 2011-10-20 at 08:23 +0200, Koen Kooi wrote:
> >> Op 28 sep. 2011, om 22:04 heeft Otavio Salvador het volgende geschreven:
> >>
> >>> On Wed, Sep 28, 2011 at 16:50, Richard Purdie
> >>> <richard.purdie@linuxfoundation.org> wrote:
> >>>>> This patch improves the current situation and I don't foresee the
> >>>>> autoPR code working soon
> >>>>
> >>>> Which is why we need to switch to that model and shake out the issues
> >>>> sooner than later. Enough is enough with the PR madness and we need to
> >>>> get to grips and fix it.
> >>>
> >>> I fully agree this is the way to go but this doesn't mean we ought to
> >>> hold this patch until all this happens. This patch allows the removal
> >>> of the kernel.bbclass from meta-oe so reducing the delta between
> >>> oe-core and meta-oe.
> >>
> >> So a month later and no sign of the mythical working
> >> auto-PR-incrementer or work on it.
> >
> > A month where we were stabilising for a release. Its on the 1.2 feature
> > list and as it happens I've been hearing questions about what is needed
> > here.
> >
> >> So can this patch go in? It would mean we can drop kernel.bbclass
> >> from meta-oe.
> >
> > I *HATE* this PR bumping stuff. I've just been told we likely need to
> > bump the PR for anything using libGL which once again shows that build
> > system basically failing to automate building things.
> >
> > So I'm drawing a line here and no, we can't take this. If its fine to
> > expect people to bump PR values manually for lib* changes, its fine for
> > kernels too. I'd suggest you do drop this from meta-oe and we start
> > building up pressure for the problem to get fixed properly rather than
> > letting people wallpaper over the cracks.
>
> I have products to ship, so treating meta-oe as a plaything and break this
> for the sake of breaking it is unacceptable. I'll let oe-core have the
> monopoly on high-qualitily, but broken metadata.
> .
>
Didn't we have a TSC to escalate discussions and disagreements between
developers to???
Best regards, Frans
[-- Attachment #2: Type: text/html, Size: 2955 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] qmmp: update to 0.5.2
From: Xiaofeng Yan @ 2011-10-20 11:46 UTC (permalink / raw)
To: Saul Wold; +Cc: Patches and discussions about the oe-core layer
In-Reply-To: <4E9F5AC2.9080905@intel.com>
[-- Attachment #1: Type: text/plain, Size: 10144 bytes --]
On 2011年10月20日 07:18, Saul Wold wrote:
> On 10/19/2011 03:31 AM, Xiaofeng Yan wrote:
>> On 2011年10月18日 13:44, Xiaofeng Yan wrote:
>>> On 2011年10月18日 13:35, Saul Wold wrote:
>>>> On 10/17/2011 10:21 PM, Xiaofeng Yan wrote:
>>>>> From: Xiaofeng Yan<xiaofeng.yan@windriver.com>
>>>>>
>>>>> The new version of qmmp can run on core-image-sato by test.
>>>>> $qmmp *.mp3
>>>>>
>>>>> Signed-off-by: Xiaofeng Yan<xiaofeng.yan@windriver.com>
>>>>> ---
>>>>> meta/recipes-qt/qt-apps/qmmp_0.5.2.bb | 49
>>>>> +++++++++++++++++++++++++++++++++
>>>>> 1 files changed, 49 insertions(+), 0 deletions(-)
>>>>> create mode 100644 meta/recipes-qt/qt-apps/qmmp_0.5.2.bb
>>>>>
>>>>> diff --git a/meta/recipes-qt/qt-apps/qmmp_0.5.2.bb
>>>>> b/meta/recipes-qt/qt-apps/qmmp_0.5.2.bb
>>>>> new file mode 100644
>>>>> index 0000000..f31409b
>>>>> --- /dev/null
>>>>> +++ b/meta/recipes-qt/qt-apps/qmmp_0.5.2.bb
>>>>> @@ -0,0 +1,49 @@
>>>>> +dESCRIPTION = "Qmmp (Qt-based Multimedia Player) is an
>>>>> audio-player, written with help of Qt library"
>>>>> +HOMEPAGE = "http://qmmp.ylsoftware.com"
>>>>> +LICENSE = "GPLv2"
>>>>> +LIC_FILES_CHKSUM =
>>>>> "file://COPYING;md5=393a5ca445f6965873eca0259a17f833"
>>>>> +SECTION = "multimedia"
>>>>> +
>>>>> +PR = "r3"
>>>>> +
>>>>> +PROVIDES = "qmmp"
>>>>> +DEPENDS = "qt4-x11-free taglib libmad libvorbis libogg alsa-lib"
>>>>> +RDEPENDS_${PN} += "taglib alsa-lib libmad curl"
>>>>> +
>>>>> +SRC_URI = "http://qmmp.ylsoftware.com/files/${BPN}-${PV}.tar.bz2"
>>>>> +
>>>>> +SRC_URI[md5sum] = "20852f3cce3471bfc5affa9b2e947dc6"
>>>>> +SRC_URI[sha256sum] =
>>>>> "6391dec020d2a381d7f4b7890fae6c49eadf88b3c9aef571fe3c5e96140822ec"
>>>>> +
>>>>> +
>>>>> +PARALLEL_MAKE = ""
>>>>> +
>>>>> +inherit qmake2 cmake
>>>>> +
>>>>> +export EXTRA_OECMAKE = "-DQT_QMAKE_EXECUTABLE=${OE_QMAKE_QMAKE} \
>>>>> + -DQT_LRELEASE_EXECUTABLE=${OE_QMAKE_LRELEASE} \
>>>>> + -DQT_MOC_EXECUTABLE=${OE_QMAKE_MOC} \
>>>>> + -DQT_UIC_EXECUTABLE=${OE_QMAKE_UIC} \
>>>>> + -DQT_RCC_EXECUTABLE=${OE_QMAKE_RCC} \
>>>>> + -DQT_LIBRARY_DIR=${OE_QMAKE_LIBDIR_QT} \
>>>>> + -DQT_HEADERS_DIR=${OE_QMAKE_INCDIR_QT} \
>>>>> + -DQT_QTCORE_INCLUDE_DIR=${OE_QMAKE_INCDIR_QT}/QtCore \
>>>>> + "
>>>>> +
>>>>> +FILES_${PN} =+ "\
>>>>> + ${libdir}/qmmp/*/*.so \
>>>>> + ${datadir}/icons/* \
>>>>> + ${datadir}/qmmp/images/* \
>>>>> + ${datadir}/applications/qmmp.desktop \
>>>>> + "
>>>>> +
>>>> Xiaofeng,
>>>>
>>>> I was looking into this also, I think it would be better to split all
>>>> the various plugins into separate packages using
>>>> do_split_packages(), in
>>>> the packages.bbclass.
>>>>
>>>> I started with this code:
>>>>> PACKAGES_DYNAMIC = "qmmp-plugin-*"
>>>>>
>>>>> python populate_packages_prepend () {
>>>>> qmmp_libdir = bb.data.expand('${libdir}/qmmp', d)
>>>>>
>>>>> do_split_packages(d, qmmp_libdir, '^(.*)/(.*)\.so$',
>>>>> 'qmmp-plugin-%s-%s', 'Qmmp %s Plugin for %s', extra_depends='')
>>>>> }
>>>>
>>>> But have not completed it yet, if you have time to investigate
>>>> further and complete this correctly, there might be a problem with
>>>> using multiple Regular expressions in the do_split_packages code, but
>>>> I have not fully debugged this yet.
>>>>
>>>> Please let me know if you can complete this task.
>>>>
>> Hi saul,
>>
>> The following is my modification to qmmp_0.5.2.bb. Please review it.
>> I want to get a reply about how to ship files in ${datadir} for qmmp. I
>> shipped them to FILES_${PN} because qmmp need these files when starting
>> up. Do you think that they should be packaged like qmmp-plugin-* ?
>>
>> Please give me your suggestion and I will modify this file.
>>
>>
>> PACKAGES_DYNAMIC += "qmmp-plugin-*"
>>
>>
>> python populate_packages_prepend () {
>> qmmp_libdir = bb.data.expand('${libdir}/qmmp', d)
>> do_split_packages(d, qmmp_libdir, '^lib(.*)\.so$',
>> 'qmmp-plugin-%s', 'Qmmp %s Plugin for', recursive=True,extra_depends='')
>> }
>>
> Ah, I see you added the recursive flag, I was trying to capture the
> plugin group (Input, Ouput, Effect, ...) in the package name incase
> there was name conflict, also to match the mad and vorbis naming below.
>
> If using multiple RE expressions in the re match does not work, then
> we should make do_split_package for each grouping and name them correctly
> qmmp-plugin-<group>-<library> with the Description: Qmmp <Group>
> plugin for %s"
>
Hi Saul,
I find .debug can't be packaged to rpm package because it is invisible
directory. In current OE-core .debug was shipped to FILES_${PN}-dbg, for
example , gtk+ ,qt4-x11-free
If we want to split up .debug/* to single package, we can rename .debug
to debug to make this directory visible, then debug directory can be
split up to single package.
Please review the following two mode.
_Mode 1: Ship .debug to FILES_${PN}-dbg_
PACKAGES_DYNAMIC = "qmmp-plugin-* "
python populate_packages_prepend () {
import os
qmmp_libdir = bb.data.expand('${libdir}/qmmp', d)
gd = bb.data.expand('${D}/${libdir}/qmmp', d)
plug_dirs = os.listdir(gd)
/# for makeing do_split_package for each grouping and name them correctly
# qmmp-plugin-<group>-<library> with the Description: Qmmp <Group>
plugin for %s"
# I use the following method./
for plug_dir in plug_dirs:
g_plug_dir = os.path.join(qmmp_libdir,plug_dir)
do_split_packages(d, g_plug_dir, '^lib(.*)\.so$',
'qmmp-plugin-' + plug_dir + '-%s', 'Qmmp' + plug_dir + 'plugin for %s')
}
/# if I don't point files to ship file to ${PN}, then FILE_${PN} will
get files in usr/lib/qmmp and qmmp-plug-* will not get files. /
FILES_${PN} = "\
${bindir}/qmmp \
${libdir}/lib*${SOLIBS} \
${datadir}/icons/* \
${datadir}/qmmp/images/* \
${datadir}/applications/* \
"
FILES_${PN}-dbg += "\
${libdir}/qmmp/*/.debug/* \
"
=================================================================================
_
Mode 2: Split up .debug to sub-packages_
PACKAGES_DYNAMIC = "qmmp-plugin-* qmmp-debug-plugin-*"
python populate_packages_prepend () {
import os
qmmp_libdir = bb.data.expand('${libdir}/qmmp', d)
qmmp_pkgd = bb.data.expand('${WORKDIR}/package/${libdir}/qmmp', d)
gd = bb.data.expand('${D}/${libdir}/qmmp', d)
plug_dirs = os.listdir(gd)
for plug_dir in plug_dirs:
/#rename .debug to debug/
if os.path.exists( qmmp_pkgd + '/' + plug_dir +
'/.debug'):
os.rename(qmmp_pkgd + '/' + plug_dir +
'/.debug',qmmp_pkgd + '/' + plug_dir + '/debug')
g_plug_dir = os.path.join(qmmp_libdir,plug_dir)
do_split_packages(d, g_plug_dir, '^lib(.*)\.so$',
'qmmp-plugin-' + plug_dir + '-%s', 'Qmmp' + plug_dir + 'plugin for %s')
/#split up .debug to sub-packages/
g_plug_debug_dir = os.path.join(g_plug_dir,'debug')
do_split_packages(d, g_plug_debug_dir, '^lib(.*)\.so$',
'qmmp-debug-plugin-' + plug_dir + '-%s', 'Qmmp' + plug_dir + 'plugin
debug for %s')
}
/
# if I don't point files to ship file to ${PN}, then FILE_${PN} will get
files in usr/lib/qmmp and qmmp-plug-* will not get files./ /I check gtk+
and qt4-x11-free and find that they adopt the following method without
using default mode./
FILES_${PN} = "\
${bindir}/qmmp \
${libdir}/lib*${SOLIBS} \
${datadir}/icons/* \
${datadir}/qmmp/images/* \
${datadir}/applications/* \
"
Do you have any comment for above code. If have, I will continue
looking into modification method according to your suggestion. Do you
think we should select which method?
Thanks
Yan
>> FILES_${PN} = "\
> I think this should be a +=
>> ${bindir}/qmmp \
>> ${libdir}/lib*${SOLIBS} \
> These 2 should go away (part of default FILES_${PN}
>> ${datadir}/icons/* \
>> ${datadir}/qmmp/images/* \
>> ${datadir}/applications/* \
>> "
> There are added via the += above.
>
>>
>> FILES_${PN}-dbg += "\
>> ${libdir}/qmmp/*/.debug/* \
>> "
>>
> These should be picked up by the do_split_package above I believe
>
>> PACKAGES += "${PN}-plugin-input-mad ${PN}-plugin-input-vorbis "
>>
>> FILES_${PN}-plugin-input-mad = "${libdir}/qmmp/Input/libmad.so"
>> RDEPENDS_${PN}-plugin-input-mad = "libmad"
>> FILES_${PN}-plugin-input-vorbis = "${libdir}/qmmp/Input/libvorbis.so"
>> RDEPENDS_${PN}-plugin-input-vorbis = "libvorbis libogg"
>>
> Ideally the above PACKAGES and FILES_ go away and the default actions
> take over.
>
> Thanks for looking into this.
>
> Sau!
>
>>
>>
>> Thanks
>> Yan
>>> Thanks for your reply and I will investigate it according to your
>>> suggestion.
>>>
>>> Thanks
>>> Yan
>>>> Thanks
>>>> Sau!
>>>>
>>>>
>>>>> +FILES_${PN}-dbg += "\
>>>>> + ${libdir}/qmmp/*/.debug/* \
>>>>> + "
>>>>> +
>>>>> +PACKAGES += "${PN}-plugin-input-mad ${PN}-plugin-input-vorbis"
>>>>> +
>>>>> +FILES_${PN}-plugin-input-mad = "${libdir}/qmmp/Input/libmad.so"
>>>>> +RDEPENDS_${PN}-plugin-input-mad = "libmad"
>>>>> +FILES_${PN}-plugin-input-vorbis =
>>>>> "${libdir}/qmmp/Input/libvorbis.so"
>>>>> +RDEPENDS_${PN}-plugin-input-vorbis = "libvorbis libogg"
>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> Openembedded-core mailing list
>>> Openembedded-core@lists.openembedded.org
>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>>
>>
>>
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
>
[-- Attachment #2: Type: text/html, Size: 17888 bytes --]
^ permalink raw reply
* Re: [PATCH 2/5] kernel.bbclass: respect MACHINE_KERNEL_PR
From: Otavio Salvador @ 2011-10-20 11:35 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <46567209-1B97-42F5-B5DF-E34B823F6BF7@dominion.thruhere.net>
On Thu, Oct 20, 2011 at 09:29, Koen Kooi <koen@dominion.thruhere.net> wrote:
...
>> So I'm drawing a line here and no, we can't take this. If its fine to
>> expect people to bump PR values manually for lib* changes, its fine for
>> kernels too. I'd suggest you do drop this from meta-oe and we start
>> building up pressure for the problem to get fixed properly rather than
>> letting people wallpaper over the cracks.
>
> I have products to ship, so treating meta-oe as a plaything and break this for the sake of breaking it is unacceptable. I'll let oe-core have the monopoly on high-qualitily, but broken metadata.
Richard,
It makes no sense to don't accept this as it reduces delta between
oe-core and meta-oe and makes easier for other people to move from
oe-classic to oe-core. Once the auto-PR arrives this can be deprecated
but delaying it with no ETA is no sense.
--
Otavio Salvador O.S. Systems
E-mail: otavio@ossystems.com.br http://www.ossystems.com.br
Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
^ permalink raw reply
* Re: [PATCH 2/5] kernel.bbclass: respect MACHINE_KERNEL_PR
From: Koen Kooi @ 2011-10-20 11:29 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <1319109715.16061.4.camel@ted>
Op 20 okt. 2011, om 13:21 heeft Richard Purdie het volgende geschreven:
> On Thu, 2011-10-20 at 08:23 +0200, Koen Kooi wrote:
>> Op 28 sep. 2011, om 22:04 heeft Otavio Salvador het volgende geschreven:
>>
>>> On Wed, Sep 28, 2011 at 16:50, Richard Purdie
>>> <richard.purdie@linuxfoundation.org> wrote:
>>>>> This patch improves the current situation and I don't foresee the
>>>>> autoPR code working soon
>>>>
>>>> Which is why we need to switch to that model and shake out the issues
>>>> sooner than later. Enough is enough with the PR madness and we need to
>>>> get to grips and fix it.
>>>
>>> I fully agree this is the way to go but this doesn't mean we ought to
>>> hold this patch until all this happens. This patch allows the removal
>>> of the kernel.bbclass from meta-oe so reducing the delta between
>>> oe-core and meta-oe.
>>
>> So a month later and no sign of the mythical working
>> auto-PR-incrementer or work on it.
>
> A month where we were stabilising for a release. Its on the 1.2 feature
> list and as it happens I've been hearing questions about what is needed
> here.
>
>> So can this patch go in? It would mean we can drop kernel.bbclass
>> from meta-oe.
>
> I *HATE* this PR bumping stuff. I've just been told we likely need to
> bump the PR for anything using libGL which once again shows that build
> system basically failing to automate building things.
>
> So I'm drawing a line here and no, we can't take this. If its fine to
> expect people to bump PR values manually for lib* changes, its fine for
> kernels too. I'd suggest you do drop this from meta-oe and we start
> building up pressure for the problem to get fixed properly rather than
> letting people wallpaper over the cracks.
I have products to ship, so treating meta-oe as a plaything and break this for the sake of breaking it is unacceptable. I'll let oe-core have the monopoly on high-qualitily, but broken metadata.
^ permalink raw reply
* Re: [PATCH 2/5] kernel.bbclass: respect MACHINE_KERNEL_PR
From: Richard Purdie @ 2011-10-20 11:21 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <67E90C92-F94E-4FF2-ADA5-A5295C4F1279@dominion.thruhere.net>
On Thu, 2011-10-20 at 08:23 +0200, Koen Kooi wrote:
> Op 28 sep. 2011, om 22:04 heeft Otavio Salvador het volgende geschreven:
>
> > On Wed, Sep 28, 2011 at 16:50, Richard Purdie
> > <richard.purdie@linuxfoundation.org> wrote:
> >>> This patch improves the current situation and I don't foresee the
> >>> autoPR code working soon
> >>
> >> Which is why we need to switch to that model and shake out the issues
> >> sooner than later. Enough is enough with the PR madness and we need to
> >> get to grips and fix it.
> >
> > I fully agree this is the way to go but this doesn't mean we ought to
> > hold this patch until all this happens. This patch allows the removal
> > of the kernel.bbclass from meta-oe so reducing the delta between
> > oe-core and meta-oe.
>
> So a month later and no sign of the mythical working
> auto-PR-incrementer or work on it.
A month where we were stabilising for a release. Its on the 1.2 feature
list and as it happens I've been hearing questions about what is needed
here.
> So can this patch go in? It would mean we can drop kernel.bbclass
> from meta-oe.
I *HATE* this PR bumping stuff. I've just been told we likely need to
bump the PR for anything using libGL which once again shows that build
system basically failing to automate building things.
So I'm drawing a line here and no, we can't take this. If its fine to
expect people to bump PR values manually for lib* changes, its fine for
kernels too. I'd suggest you do drop this from meta-oe and we start
building up pressure for the problem to get fixed properly rather than
letting people wallpaper over the cracks.
Cheers,
Richard
^ permalink raw reply
* Re: [CONSOLIDATED PULL - v2 09/26] x86 tune files: set baselib for x32 tune as libx32
From: Phil Blundell @ 2011-10-20 9:02 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <84da55babd48c9de760d3ff271ba97e6a65926c8.1319096633.git.sgw@linux.intel.com>
On Thu, 2011-10-20 at 00:50 -0700, Saul Wold wrote:
> From: Nitin A Kamble <nitin.a.kamble@intel.com>
>
> Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
Why is this a good thing? There is no explanation in the commit
message.
p.
^ permalink raw reply
* Re: [PATCH 2/6] gmp: also generate the libgmpcxx library
From: Phil Blundell @ 2011-10-20 9:01 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <4E9FD2B2.5000508@intel.com>
On Thu, 2011-10-20 at 00:50 -0700, Saul Wold wrote:
> The example case I found was a coreutils package that was built prior to
> this change failed to fulfill it's dependencies after this change when
> creating an image. If I rebuild coreutils with the newer gmp build,
> then all is well, I think we need to understand this better before
> making this change.
>
> Did something else change in the packaging that would cause use to look
> the mapping above?
If you've now got two DSOs in one output package (which it sounds like
you might have, since libgmpcxx was apparently added) then the autonamer
will be defeated. They need to go in separate PACKAGES for that to work
out right.
p.
^ permalink raw reply
* sdk path problem
From: James Limbouris @ 2011-10-20 8:22 UTC (permalink / raw)
To: openembedded-core@lists.openembedded.org
Hi,
I have been using meta-toolchain-qte in the past to cross compile a Qt app, and the Linux kernel.
Recently I replaced my old SDK image with a fresh one, and found that I could not link vmlinux anymore.
When building the kernel, I use the following ('rica' is the distribution name):
export PATH=$PATH:/usr/local/rica-eglibc-i686-armv5te/sysroots/i686-ricasdk-linux/usr/bin/armv5te-rica-linux-gnueabi/
make ARCH=arm CROSS_COMPILE=arm-rica-linux-gnueabi- zImage
The new error message is:
Kernel: arch/arm/boot/Image is ready
AS arch/arm/boot/compressed/head.o
GZIP arch/arm/boot/compressed/piggy.gz
CC arch/arm/boot/compressed/misc.o
AS arch/arm/boot/compressed/piggy.o
LD arch/arm/boot/compressed/vmlinux
arm-rica-linux-gnueabi-ld: cannot find libgcc.a: No such file or directory
Comparing the build with the old sdk to the build with the new one, I find that the command line for linking has changed from:
arm-rica-linux-gnueabi-ld -EL --defsym zreladdr=0x80008000 --defsym initrd_phys=0x80800000 --defsym params_phys=0x80000100 -p --no-undefined -X /usr/local/rica-eglibc-i686-armv5te/sysroots/arm-rica-linux-gnueabi/usr/lib/arm-rica-linux-gnueabi/4.5.4/libgcc.a -T arch/arm/boot/compressed/vmlinux.lds arch/arm/boot/compressed/head.o arch/arm/boot/compressed/piggy.o arch/arm/boot/compressed/misc.o -o arch/arm/boot/compressed/vmlinux
to:
arm-rica-linux-gnueabi-ld -EL --defsym zreladdr=0x80008000 --defsym initrd_phys=0x80800000 --defsym params_phys=0x80000100 -p --no-undefined -X libgcc.a -T arch/arm/boot/compressed/vmlinux.lds arch/arm/boot/compressed/head.o arch/arm/boot/compressed/piggy.o arch/arm/boot/compressed/misc.o -o arch/arm/boot/compressed/vmlinux
So libgcc.a has lost its path qualification.
I also straced the two linker commands, and found that they differed in one sequence.
Old:
lstat64("/usr/local/rica-eglibc-i686-armv5te", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat64("/usr/local/rica-eglibc-i686-armv5te/sysroots", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat64("/usr/local/rica-eglibc-i686-armv5te/sysroots/arm-rica-linux-gnueabi", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
New:
lstat64("/usr/local/rica-eglibc-i686-armv5te", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat64("/usr/local/rica-eglibc-i686-armv5te/sysroots", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat64("/usr/local/rica-eglibc-i686-armv5te/sysroots/arm-rica-linux-gnueabi", 0xbffe67cc) = -1 ENOENT (No such file or directory)
Both toolchains are looking for a sysroot at 'arm-rica-linux-gnueabi', but the new toolchain should be looking at 'armv5te-rica-linux-gnueabi', as the names have changed.
I'm not yet acquainted with the darker arts of toolchain generation. Can anyone help with this?
Regards,
James Limbouris
^ permalink raw reply
* Re: [PATCH 2/6] gmp: also generate the libgmpcxx library
From: Koen Kooi @ 2011-10-20 8:01 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <4E9FD2B2.5000508@intel.com>
Op 20 okt. 2011, om 09:50 heeft Saul Wold het volgende geschreven:
> On 10/18/2011 05:30 PM, nitin.a.kamble@intel.com wrote:
>> From: Nitin A Kamble<nitin.a.kamble@intel.com>
>>
>> configure runs few checks to make sure c++ compiler and runtime are working as expected
>> with the --enable-cxx=detect option.
>>
> Somehow this change has also changed what the gmp package provides, before this change the package provided libgmp10 via PKG_gmp: libgmp10, after this change, the libgmp10 is no longer provided and causes other breakage.
>
> The example case I found was a coreutils package that was built prior to this change failed to fulfill it's dependencies after this change when creating an image. If I rebuild coreutils with the newer gmp build, then all is well, I think we need to understand this better before making this change.
>
> Did something else change in the packaging that would cause use to look the mapping above?
I suspect the shlib renaming doesn't happen when 2 libraries are present without LEAD_SONAME being set in the recipe. I suggest making a new subpackage for libgmpcxx.
regards,
Koen
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox