Re: [yocto] HOB usage

[Sathishkumar Duraisamy]

On Fri, Dec 9, 2011 at 10:37 AM, Sathishkumar Duraisamy
 wrote:
> On Fri, Dec 9, 2011 at 10:28 AM, Joshua Lock  wrote:
>> On 08/12/11 20:52, Sathishkumar Duraisamy wrote:
>>> Hi,
>>>
>>> I migrating from Openembedded to yocto project and using Beagleboard
>>> as playground.
>>>
>>> On Fri, Dec 9, 2011 at 3:27 AM, Joshua Lock  wrote:

 On 05/12/11 10:35, madeeha javed wrote:
> I an using Yocto Edison. My machine configuration is beagleboard. And
> when I launch hob and Bake. I get a message that Output Image Type is
> not set.When I Edit-> Preferences, I see that jffs2 and tar.bz2 are
> set. And even if I select a different type, the message keeps is
> there.

>>> I too faced similar problem for hob.
>>>
 Madeeha,

 I'm not able to replicate this issue. Have you modified any of the
 configuration files by hand? The three key files in build/conf are
 hob-post.conf, hob-pre.conf, local.conf
>>>
>>> Please find these files in the attachment.
>>
>> Did you forget the attachment? Or did the mailing list strip it?
>
> Sorry, I forget to attach.
>>
>>>

 It's possible you've hard-assigned the variable in there.

 If you can provide more information I can try and replicate. A copy of
 the above configuration files would be useful.
>>>
>>> In openembedded, I see the some lines like this
>>>
>>> # Add the required image file system types below. Valid are
>>> # jffs2, tar(.gz|bz2), cpio(.gz), cramfs, ext2(.gz), ext3(.gz), 
>>> ext4(.gz|.bz2),
>>> # squashfs, squashfs-lzma
>>> IMAGE_FSTYPES = "jffs2 tar"
>>>
>>> which is moved to hob-post.conf, which may causing the problems I hope.
>>

I forget to say, in bash terminal, it works fine. In hob only it
causing the issue.

-- 
Regards,
Sathishkumar D
http://flowersopenlab.weebly.com/
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] HOB usage

[Sathishkumar Duraisamy]

On Fri, Dec 9, 2011 at 10:28 AM, Joshua Lock  wrote:
> On 08/12/11 20:52, Sathishkumar Duraisamy wrote:
>> Hi,
>>
>> I migrating from Openembedded to yocto project and using Beagleboard
>> as playground.
>>
>> On Fri, Dec 9, 2011 at 3:27 AM, Joshua Lock  wrote:
>>>
>>> On 05/12/11 10:35, madeeha javed wrote:
 I an using Yocto Edison. My machine configuration is beagleboard. And
 when I launch hob and Bake. I get a message that Output Image Type is
 not set.When I Edit-> Preferences, I see that jffs2 and tar.bz2 are
 set. And even if I select a different type, the message keeps is
 there.
>>>
>> I too faced similar problem for hob.
>>
>>> Madeeha,
>>>
>>> I'm not able to replicate this issue. Have you modified any of the
>>> configuration files by hand? The three key files in build/conf are
>>> hob-post.conf, hob-pre.conf, local.conf
>>
>> Please find these files in the attachment.
>
> Did you forget the attachment? Or did the mailing list strip it?

Sorry, I forget to attach.
>
>>
>>>
>>> It's possible you've hard-assigned the variable in there.
>>>
>>> If you can provide more information I can try and replicate. A copy of
>>> the above configuration files would be useful.
>>
>> In openembedded, I see the some lines like this
>>
>> # Add the required image file system types below. Valid are
>> # jffs2, tar(.gz|bz2), cpio(.gz), cramfs, ext2(.gz), ext3(.gz), 
>> ext4(.gz|.bz2),
>> # squashfs, squashfs-lzma
>> IMAGE_FSTYPES = "jffs2 tar"
>>
>> which is moved to hob-post.conf, which may causing the problems I hope.
>
> Anywhere you set with = is a 'hard' assignment which we cannot override.
>
> Several of hobs settings are in hob-post.conf, if they have already been
> hard assigned in a configuration file which is parsed earlier we cannot
> override it.
>
> If you set the IMAGE_FSTYPES with ?= setting them from the GUI should world.
>
> Please be aware we're working to resolve such issues for hob in Yocto 1.2.
>


-- 
Regards,
Sathishkumar D
http://flowersopenlab.weebly.com/


hob-confs.tar.gz
Description: GNU Zip compressed data
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] HOB usage

[Joshua Lock]

On 08/12/11 20:52, Sathishkumar Duraisamy wrote:
> Hi,
> 
> I migrating from Openembedded to yocto project and using Beagleboard
> as playground.
> 
> On Fri, Dec 9, 2011 at 3:27 AM, Joshua Lock  wrote:
>>
>> On 05/12/11 10:35, madeeha javed wrote:
>>> I an using Yocto Edison. My machine configuration is beagleboard. And
>>> when I launch hob and Bake. I get a message that Output Image Type is
>>> not set.When I Edit-> Preferences, I see that jffs2 and tar.bz2 are
>>> set. And even if I select a different type, the message keeps is
>>> there.
>>
> I too faced similar problem for hob.
> 
>> Madeeha,
>>
>> I'm not able to replicate this issue. Have you modified any of the
>> configuration files by hand? The three key files in build/conf are
>> hob-post.conf, hob-pre.conf, local.conf
> 
> Please find these files in the attachment.

Did you forget the attachment? Or did the mailing list strip it?

> 
>>
>> It's possible you've hard-assigned the variable in there.
>>
>> If you can provide more information I can try and replicate. A copy of
>> the above configuration files would be useful.
> 
> In openembedded, I see the some lines like this
> 
> # Add the required image file system types below. Valid are
> # jffs2, tar(.gz|bz2), cpio(.gz), cramfs, ext2(.gz), ext3(.gz), 
> ext4(.gz|.bz2),
> # squashfs, squashfs-lzma
> IMAGE_FSTYPES = "jffs2 tar"
> 
> which is moved to hob-post.conf, which may causing the problems I hope.

Anywhere you set with = is a 'hard' assignment which we cannot override.

Several of hobs settings are in hob-post.conf, if they have already been
hard assigned in a configuration file which is parsed earlier we cannot
override it.

If you set the IMAGE_FSTYPES with ?= setting them from the GUI should world.

Please be aware we're working to resolve such issues for hob in Yocto 1.2.

Regards,
Joshua
-- 
Joshua Lock
Yocto Project "Johannes factotum"
Intel Open Source Technology Centre
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] HOB usage

[Sathishkumar Duraisamy]

Hi,

I migrating from Openembedded to yocto project and using Beagleboard
as playground.

On Fri, Dec 9, 2011 at 3:27 AM, Joshua Lock  wrote:
>
> On 05/12/11 10:35, madeeha javed wrote:
>> I an using Yocto Edison. My machine configuration is beagleboard. And
>> when I launch hob and Bake. I get a message that Output Image Type is
>> not set.When I Edit-> Preferences, I see that jffs2 and tar.bz2 are
>> set. And even if I select a different type, the message keeps is
>> there.
>
I too faced similar problem for hob.

> Madeeha,
>
> I'm not able to replicate this issue. Have you modified any of the
> configuration files by hand? The three key files in build/conf are
> hob-post.conf, hob-pre.conf, local.conf

Please find these files in the attachment.

>
> It's possible you've hard-assigned the variable in there.
>
> If you can provide more information I can try and replicate. A copy of
> the above configuration files would be useful.

In openembedded, I see the some lines like this

# Add the required image file system types below. Valid are
# jffs2, tar(.gz|bz2), cpio(.gz), cramfs, ext2(.gz), ext3(.gz), ext4(.gz|.bz2),
# squashfs, squashfs-lzma
IMAGE_FSTYPES = "jffs2 tar"

which is moved to hob-post.conf, which may causing the problems I hope.
-- 
Regards,
Sathishkumar D
http://flowersopenlab.weebly.com/
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH] task-core-qt3: Fix package names

[Saul Wold]

Signed-off-by: Saul Wold 
---
 recipes-qt3/tasks/task-core-qt3.bb |3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/recipes-qt3/tasks/task-core-qt3.bb 
b/recipes-qt3/tasks/task-core-qt3.bb
index 81479d9..fa41fb5 100644
--- a/recipes-qt3/tasks/task-core-qt3.bb
+++ b/recipes-qt3/tasks/task-core-qt3.bb
@@ -3,7 +3,7 @@
 #
 
 DESCRIPTION = "Create qt3 Tasks"
-PR = "r0"
+PR = "r1"
 LICENSE = "MIT"
 LIC_FILES_CHKSUM = 
"file://${COREBASE}/LICENSE;md5=3f40d7994397109285ec7b81fdeb3b58 \
 
file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
@@ -17,7 +17,6 @@ ALLOW_EMPTY = "1"
 
 
 RDEPENDS_task-core-qt-mt3 = "\
-qt-x11-free \
 libqt-mt3 \
 "
 
-- 
1.7.3.4

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH] meta-fsl-ppc layer: p1010rdb.conf only has one core, so don't use smp_defconfig

[McClintock Matthew-B29882]

On Thu, Dec 8, 2011 at 4:04 PM, Bob Cochran  wrote:
> P1010 is a single core processor, don't use SMP for defconfig
>
> Should we get a meta-fsl-ppc mail list going?
>
> Signed-off-by: Robert Cochran

Already asked for this to get fixed for all the parts. I've pushed a
fix for this.

-M
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Variable locality too restricted.

[Darren Hart]

On 12/08/2011 03:12 PM, Richard Purdie wrote:
> On Thu, 2011-12-08 at 14:56 -0800, Darren Hart wrote:
>> On 12/08/2011 02:47 PM, Richard Purdie wrote:
>>> On Thu, 2011-12-08 at 10:49 -0800, Darren Hart wrote:
 On 12/08/2011 06:31 AM, Bruce Ashfield wrote:
> If you want to then modify the configuration slightly using either
> in-tree or add on kernel
> configuration fragments you can simply add a .cfg to the SCR_URI or set 
> the
> KERNEL_FEATURES variable, just like Darren did recently.
>
>KERNEL_FEATURES_append_fri2 += " cfg/smp.scc cfg/efi-ext.scc"


 This has the same original variable scope issue as before however. It
 would be nice to be able to do this:

 $ bitbake core-image-minimal
 $ bitbake core-image-minimal-debug

 The latter image would use the same machine, but it would build perf,
 add "debug" and other configurable options to "APPEND", and add a
 configurable set of KERNEL_FEATURES. We should also update the base
 kernel tools (non-Yocto) to use merge_config.sh so fragments can be used
 in those recipes as well.

 The problem I've run into here in the past has been that I cannot
 specify things like PREFERRED_PROVIDER in the image recipe. So, for
 example, to build RT, the current documented approach is to first add a
 PREFERRED_PROVIDER line to either local.conf or bblayers to select
 linux-yocto-rt and then to build core-image-rt which merely adds some
 relevant packages. It would be much preferable to be able to specify
 just an image target and not have to change your configuration because
 the image is the intuitive distinguishing factor for people.
>>>
>>> I'd like to give the bitbake perspective on this problem.
>>>
>>> PREFERRED_PROVIDER in images doesn't really make sense to bitbake.
>>> Imagine you have:
>>>
>>> core-image-minimal setting PREFERRED_PROVIDER = "kernelA" and
>>> core-image-minima-debug setting PREFERRED_PROVIDER = "kernelB". Both
>>> would depend on "virtual/kernel". You then run:
>>>
>>> "bitbake core-image-minimal core-image-minimal-debug"
>>>
>>> What would you expect bitbake to do?
>>
>> What I _think_ most people would expect it to do is to build each kernel
>> and install the right one in each image. I understand this doesn't work
>> with the way bitbake currently handles kernels, as you describe below.
>>
>>> The kernel is special in that doesn't really stage output that is reused
>>> by other parts of the system but we have to consider the general case
>>> where output such as libraries would end up in a shared sysroot. Even
>>> then, the kernel does generate packages which it places in a machine
>>> specific feed and the names don't reflect the different inputs, there is
>>> one kernel-image package for example and in the above case it would be a
>>> race on which one built last.
>>
>> The names not reflecting different inputs seems like it should be
>> something we can address. I appreciate it isn't trivial, and probably
>> stomps on some pretty core assumptions dealing with how we build images,
> 
> Images aren't the problem, those are easy. Its the packages. How do you
> represent that kernel-image A is built with configuration X and
> kernel-image B is built with configuration Y. How do you determine
> whether you can switch between A and B or not? How do you decide which
> one is the higher version?

I'd imagine we change the package name linux-yocto vs. linux-yocto-debug
for example (this is how some of the Linux distributions handle it). I
believe PREFERRED_PROVIDER can then distinguish based on the package
name, and the versioning works the same as it does now.

> 
>> but I believe it would be valuable to be able to build multiple kernel
>> versions for a given machine.
> 
> Version on its own is easier as packages do have pretty clear ideas
> about versions. I suspect you mean different configurations though.

Agreed, that was a generic "version", not PV :-) I believe being able to
select the PN from PREFERRED_PROVIDER in the image recipe is what I'm
saying I'd prefer.


> 
>>  Many Linux distributions do this and I can
>> see users of Yocto wanting to do the same with the distributions they build.
> 
> How do different linux distributions do that exactly? Likely different
> package feeds for each kernel?

They have different names. For example, Red Hat's MRG ships something like:

linux-rt
linux-rt-vanilla
linux-rt-debug
linux-rt-vanilla-debug

It has been a while since I looked, but it was something along those lines.

> 
> As far as I can tell, to do this properly we'd need to:
> 
> a) Adopt per recipe sysroots

Yes. And if the same recipe can be used to generate different PNs based
on the config option, then that is treated as a separate recipe right?

> b) Adopt package feeds constructed per image

Does the term "feed" refer to "all the packages that can be installed"
or "all the packages that will be installed" ? Note 

Re: [yocto] Variable locality too restricted.

[Richard Purdie]

On Thu, 2011-12-08 at 14:56 -0800, Darren Hart wrote:
> On 12/08/2011 02:47 PM, Richard Purdie wrote:
> > On Thu, 2011-12-08 at 10:49 -0800, Darren Hart wrote:
> >> On 12/08/2011 06:31 AM, Bruce Ashfield wrote:
> >>> If you want to then modify the configuration slightly using either
> >>> in-tree or add on kernel
> >>> configuration fragments you can simply add a .cfg to the SCR_URI or set 
> >>> the
> >>> KERNEL_FEATURES variable, just like Darren did recently.
> >>>
> >>>KERNEL_FEATURES_append_fri2 += " cfg/smp.scc cfg/efi-ext.scc"
> >>
> >>
> >> This has the same original variable scope issue as before however. It
> >> would be nice to be able to do this:
> >>
> >> $ bitbake core-image-minimal
> >> $ bitbake core-image-minimal-debug
> >>
> >> The latter image would use the same machine, but it would build perf,
> >> add "debug" and other configurable options to "APPEND", and add a
> >> configurable set of KERNEL_FEATURES. We should also update the base
> >> kernel tools (non-Yocto) to use merge_config.sh so fragments can be used
> >> in those recipes as well.
> >>
> >> The problem I've run into here in the past has been that I cannot
> >> specify things like PREFERRED_PROVIDER in the image recipe. So, for
> >> example, to build RT, the current documented approach is to first add a
> >> PREFERRED_PROVIDER line to either local.conf or bblayers to select
> >> linux-yocto-rt and then to build core-image-rt which merely adds some
> >> relevant packages. It would be much preferable to be able to specify
> >> just an image target and not have to change your configuration because
> >> the image is the intuitive distinguishing factor for people.
> > 
> > I'd like to give the bitbake perspective on this problem.
> > 
> > PREFERRED_PROVIDER in images doesn't really make sense to bitbake.
> > Imagine you have:
> > 
> > core-image-minimal setting PREFERRED_PROVIDER = "kernelA" and
> > core-image-minima-debug setting PREFERRED_PROVIDER = "kernelB". Both
> > would depend on "virtual/kernel". You then run:
> > 
> > "bitbake core-image-minimal core-image-minimal-debug"
> > 
> > What would you expect bitbake to do?
> 
> What I _think_ most people would expect it to do is to build each kernel
> and install the right one in each image. I understand this doesn't work
> with the way bitbake currently handles kernels, as you describe below.
>
> > The kernel is special in that doesn't really stage output that is reused
> > by other parts of the system but we have to consider the general case
> > where output such as libraries would end up in a shared sysroot. Even
> > then, the kernel does generate packages which it places in a machine
> > specific feed and the names don't reflect the different inputs, there is
> > one kernel-image package for example and in the above case it would be a
> > race on which one built last.
> 
> The names not reflecting different inputs seems like it should be
> something we can address. I appreciate it isn't trivial, and probably
> stomps on some pretty core assumptions dealing with how we build images,

Images aren't the problem, those are easy. Its the packages. How do you
represent that kernel-image A is built with configuration X and
kernel-image B is built with configuration Y. How do you determine
whether you can switch between A and B or not? How do you decide which
one is the higher version?

> but I believe it would be valuable to be able to build multiple kernel
> versions for a given machine.

Version on its own is easier as packages do have pretty clear ideas
about versions. I suspect you mean different configurations though.

>  Many Linux distributions do this and I can
> see users of Yocto wanting to do the same with the distributions they build.

How do different linux distributions do that exactly? Likely different
package feeds for each kernel?

As far as I can tell, to do this properly we'd need to:

a) Adopt per recipe sysroots
b) Adopt package feeds constructed per image
c) Drop support for anyone wanting traditional distro type package feeds

These things would not be popular with the community due to a loss of
functionality and would utterly destroy any notion of build speed.

> > Bitbake therefore takes PREFERRED_PROVIDER and VERSION decisions from
> > the core configuration (.conf / .inc / machine / distro / bitbake.conf /
> > base.bbclass). There is no easy solution to this problem, even recipe
> > specific sysroots would only get a part solution.
> 
> Would this be something we should consider as a major feature
> development item for a future release?

Not without some idea of how it could be made to work. I can't visualise
a way of making this work as you describe as long as we have packages
around to deal with in the conventional way.

We've talked about special cases for the kernel above but any proposal
needs to work generically too which makes this trickier again :(.

Cheers,

Richard

___
yocto mailing list
yocto@yo

Re: [yocto] Variable locality too restricted.

[Darren Hart]

On 12/08/2011 02:47 PM, Richard Purdie wrote:
> On Thu, 2011-12-08 at 10:49 -0800, Darren Hart wrote:
>> On 12/08/2011 06:31 AM, Bruce Ashfield wrote:
>>> If you want to then modify the configuration slightly using either
>>> in-tree or add on kernel
>>> configuration fragments you can simply add a .cfg to the SCR_URI or set the
>>> KERNEL_FEATURES variable, just like Darren did recently.
>>>
>>>KERNEL_FEATURES_append_fri2 += " cfg/smp.scc cfg/efi-ext.scc"
>>
>>
>> This has the same original variable scope issue as before however. It
>> would be nice to be able to do this:
>>
>> $ bitbake core-image-minimal
>> $ bitbake core-image-minimal-debug
>>
>> The latter image would use the same machine, but it would build perf,
>> add "debug" and other configurable options to "APPEND", and add a
>> configurable set of KERNEL_FEATURES. We should also update the base
>> kernel tools (non-Yocto) to use merge_config.sh so fragments can be used
>> in those recipes as well.
>>
>> The problem I've run into here in the past has been that I cannot
>> specify things like PREFERRED_PROVIDER in the image recipe. So, for
>> example, to build RT, the current documented approach is to first add a
>> PREFERRED_PROVIDER line to either local.conf or bblayers to select
>> linux-yocto-rt and then to build core-image-rt which merely adds some
>> relevant packages. It would be much preferable to be able to specify
>> just an image target and not have to change your configuration because
>> the image is the intuitive distinguishing factor for people.
> 
> I'd like to give the bitbake perspective on this problem.
> 
> PREFERRED_PROVIDER in images doesn't really make sense to bitbake.
> Imagine you have:
> 
> core-image-minimal setting PREFERRED_PROVIDER = "kernelA" and
> core-image-minima-debug setting PREFERRED_PROVIDER = "kernelB". Both
> would depend on "virtual/kernel". You then run:
> 
> "bitbake core-image-minimal core-image-minimal-debug"
> 
> What would you expect bitbake to do?

What I _think_ most people would expect it to do is to build each kernel
and install the right one in each image. I understand this doesn't work
with the way bitbake currently handles kernels, as you describe below.

> The kernel is special in that doesn't really stage output that is reused
> by other parts of the system but we have to consider the general case
> where output such as libraries would end up in a shared sysroot. Even
> then, the kernel does generate packages which it places in a machine
> specific feed and the names don't reflect the different inputs, there is
> one kernel-image package for example and in the above case it would be a
> race on which one built last.

The names not reflecting different inputs seems like it should be
something we can address. I appreciate it isn't trivial, and probably
stomps on some pretty core assumptions dealing with how we build images,
but I believe it would be valuable to be able to build multiple kernel
versions for a given machine. Many Linux distributions do this and I can
see users of Yocto wanting to do the same with the distributions they build.

> 
> Bitbake therefore takes PREFERRED_PROVIDER and VERSION decisions from
> the core configuration (.conf / .inc / machine / distro / bitbake.conf /
> base.bbclass). There is no easy solution to this problem, even recipe
> specific sysroots would only get a part solution.

Would this be something we should consider as a major feature
development item for a future release?

> Having said that, if you enable sstate checksums on the stamp files, you
> will get a system that is *much* more responsive to change. With that
> enabled you could:
> 
> bitbake core-image-minimal
> 
> 
> bitbake core-image-minimal
> 
> 
> The reason is that with the checksums on, bitbake can tell exactly what
> changed, what it needs to rebuild and it will then do so.
> 
> Cheers,
> 
> Richard
-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Variable locality too restricted.

[Richard Purdie]

On Thu, 2011-12-08 at 10:49 -0800, Darren Hart wrote:
> On 12/08/2011 06:31 AM, Bruce Ashfield wrote:
> > If you want to then modify the configuration slightly using either
> > in-tree or add on kernel
> > configuration fragments you can simply add a .cfg to the SCR_URI or set the
> > KERNEL_FEATURES variable, just like Darren did recently.
> > 
> >KERNEL_FEATURES_append_fri2 += " cfg/smp.scc cfg/efi-ext.scc"
> 
> 
> This has the same original variable scope issue as before however. It
> would be nice to be able to do this:
> 
> $ bitbake core-image-minimal
> $ bitbake core-image-minimal-debug
> 
> The latter image would use the same machine, but it would build perf,
> add "debug" and other configurable options to "APPEND", and add a
> configurable set of KERNEL_FEATURES. We should also update the base
> kernel tools (non-Yocto) to use merge_config.sh so fragments can be used
> in those recipes as well.
> 
> The problem I've run into here in the past has been that I cannot
> specify things like PREFERRED_PROVIDER in the image recipe. So, for
> example, to build RT, the current documented approach is to first add a
> PREFERRED_PROVIDER line to either local.conf or bblayers to select
> linux-yocto-rt and then to build core-image-rt which merely adds some
> relevant packages. It would be much preferable to be able to specify
> just an image target and not have to change your configuration because
> the image is the intuitive distinguishing factor for people.

I'd like to give the bitbake perspective on this problem.

PREFERRED_PROVIDER in images doesn't really make sense to bitbake.
Imagine you have:

core-image-minimal setting PREFERRED_PROVIDER = "kernelA" and
core-image-minima-debug setting PREFERRED_PROVIDER = "kernelB". Both
would depend on "virtual/kernel". You then run:

"bitbake core-image-minimal core-image-minimal-debug"

What would you expect bitbake to do?

The kernel is special in that doesn't really stage output that is reused
by other parts of the system but we have to consider the general case
where output such as libraries would end up in a shared sysroot. Even
then, the kernel does generate packages which it places in a machine
specific feed and the names don't reflect the different inputs, there is
one kernel-image package for example and in the above case it would be a
race on which one built last.

Bitbake therefore takes PREFERRED_PROVIDER and VERSION decisions from
the core configuration (.conf / .inc / machine / distro / bitbake.conf /
base.bbclass). There is no easy solution to this problem, even recipe
specific sysroots would only get a part solution.

Having said that, if you enable sstate checksums on the stamp files, you
will get a system that is *much* more responsive to change. With that
enabled you could:

bitbake core-image-minimal


bitbake core-image-minimal


The reason is that with the checksums on, bitbake can tell exactly what
changed, what it needs to rebuild and it will then do so.

Cheers,

Richard










___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH] meta-fsl-ppc layer: p1010rdb.conf only has one core, so don't use smp_defconfig

[Bob Cochran]

P1010 is a single core processor, don't use SMP for defconfig

Should we get a meta-fsl-ppc mail list going?

Signed-off-by: Robert Cochran
---
 conf/machine/p1010rdb.conf |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/conf/machine/p1010rdb.conf b/conf/machine/p1010rdb.conf
index 726d212..693eed1 100644
--- a/conf/machine/p1010rdb.conf
+++ b/conf/machine/p1010rdb.conf
@@ -6,4 +6,4 @@ require e500v2.inc

 UBOOT_MACHINES = "P1010RDB_NAND"
 KERNEL_DEVICETREE = "${S}/arch/powerpc/boot/dts/p1010rdb.dts"
-KERNEL_DEFCONFIG = "${S}/arch/powerpc/configs/mpc85xx_smp_defconfig"
+KERNEL_DEFCONFIG = "${S}/arch/powerpc/configs/mpc85xx_defconfig"
--
1.7.1
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] HOB usage

[Joshua Lock]

On 05/12/11 10:35, madeeha javed wrote:
> I an using Yocto Edison. My machine configuration is beagleboard. And
> when I launch hob and Bake. I get a message that Output Image Type is
> not set.When I Edit-> Preferences, I see that jffs2 and tar.bz2 are
> set. And even if I select a different type, the message keeps is
> there.

Madeeha,

I'm not able to replicate this issue. Have you modified any of the
configuration files by hand? The three key files in build/conf are
hob-post.conf, hob-pre.conf, local.conf

It's possible you've hard-assigned the variable in there.

If you can provide more information I can try and replicate. A copy of
the above configuration files would be useful.

Regards,
Joshua
-- 
Joshua Lock
Yocto Project "Johannes factotum"
Intel Open Source Technology Centre
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Adding features to a machine

[Darren Hart]

On 12/08/2011 12:36 PM, Marc Ferland wrote:
> On Thu, Dec 8, 2011 at 2:50 PM, Darren Hart  > wrote:
> 
> On 12/08/2011 11:13 AM, Marc Ferland wrote:
> > Hi,
> >
> > I have a crownbay based machine here and I would like to add the
> > bluetooth machine feature to it. Do I have to create a whole new
> BSP for
> > this? I haven't seen any examples showing how to _modify_ a machine
> > description.
> 
> 
> Have you tried modifying either MACHINE_FEATURES_crownbay or
> KERNEL_FEATURES_crownbay from local.conf? I haven't attempted this
> myself, but I believe it should work.
> 
> 
> Tried both.
> 
> With MACHINE_FEATURES_crownbay += "bluetooth" I get:
> NOTE: Resolving any missing task queue dependencies
> ERROR: Nothing RPROVIDES 'modutils-depmod' (but
> /home/marc/dev/poky/poky-src/meta/recipes-kernel/update-modules/update-modules_1.0.bb
>  RDEPENDS on or otherwise requires it)
> NOTE: Runtime target 'modutils-depmod' is unbuildable, removing...

Hrm, yes, I don't see what provides modutils-depmod. I believe you may
have found a bug. Mind filing one?

> Missing or unbuildable dependency chain was: ['modutils-depmod']
> NOTE: Runtime target 'perf' is unbuildable, removing...
> Missing or unbuildable dependency chain was: ['perf', 'update-modules',
> 'modutils-depmod']
> NOTE: Runtime target 'task-core-tools-profile' is unbuildable, removing...
> Missing or unbuildable dependency chain was: ['task-core-tools-profile',
> 'perf', 'update-modules', 'modutils-depmod']
> ERROR: Required build target 'sonatest-test-image' has no buildable
> providers.
> Missing or unbuildable dependency chain was: ['sonatest-test-image',
> 'task-core-tools-profile', 'perf', 'update-modules', 'modutils-depmod']
> 
> With KERNEL_FEATURES_crownbay += "bluetooth", I get the following when
> recompiling the kernel:
> Log data follows:
> | Deleted branch meta-temp (was 620917d).
> | WARNING: addon feature "bluetooth" was not found
> | ERROR: required features were not found. aborting
> 
> BTW, I did not find any precise kernel feature for bluetooth when
> looking in
> builddir/tmp/work/crownbay-poky-linux/linux-yocto/linux/meta/cfg/kernel-cache/

Right, you would need to add something if you need a driver that isn't
listed there or in the crownbay BSP.


-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Adding features to a machine

[Marc Ferland]

On Thu, Dec 8, 2011 at 2:50 PM, Darren Hart  wrote:

> On 12/08/2011 11:13 AM, Marc Ferland wrote:
> > Hi,
> >
> > I have a crownbay based machine here and I would like to add the
> > bluetooth machine feature to it. Do I have to create a whole new BSP for
> > this? I haven't seen any examples showing how to _modify_ a machine
> > description.
>
>
> Have you tried modifying either MACHINE_FEATURES_crownbay or
> KERNEL_FEATURES_crownbay from local.conf? I haven't attempted this
> myself, but I believe it should work.
>

Tried both.

With MACHINE_FEATURES_crownbay += "bluetooth" I get:
NOTE: Resolving any missing task queue dependencies
ERROR: Nothing RPROVIDES 'modutils-depmod' (but
/home/marc/dev/poky/poky-src/meta/recipes-kernel/update-modules/
update-modules_1.0.bb RDEPENDS on or otherwise requires it)
NOTE: Runtime target 'modutils-depmod' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['modutils-depmod']
NOTE: Runtime target 'perf' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['perf', 'update-modules',
'modutils-depmod']
NOTE: Runtime target 'task-core-tools-profile' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['task-core-tools-profile',
'perf', 'update-modules', 'modutils-depmod']
ERROR: Required build target 'sonatest-test-image' has no buildable
providers.
Missing or unbuildable dependency chain was: ['sonatest-test-image',
'task-core-tools-profile', 'perf', 'update-modules', 'modutils-depmod']

With KERNEL_FEATURES_crownbay += "bluetooth", I get the following when
recompiling the kernel:
Log data follows:
| Deleted branch meta-temp (was 620917d).
| WARNING: addon feature "bluetooth" was not found
| ERROR: required features were not found. aborting

BTW, I did not find any precise kernel feature for bluetooth when looking
in
builddir/tmp/work/crownbay-poky-linux/linux-yocto/linux/meta/cfg/kernel-cache/

Marc
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] meta-oe branch for edison?

[McClintock Matthew-B29882]

Hi all,

Can we create a meta-oe repo in git.yoctoproject.org? I'd like to also
create a branh within the repo that tracks a valid version of the repo
for specific Yocto releases.

(I can add that in my investigation so far -
f78f3f31c06c669006fcb567c8f503d4dbec68da looks like a good starting
commit for edison)

-M
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-qt3] [PATCH 2/3] qt-x11-free(-native): remove PRIORITY

[Paul Eggleton]

PRIORITY is no longer used.

Signed-off-by: Paul Eggleton 
---
 recipes-qt3/qt3/qt-x11-free-common.inc  |1 -
 recipes-qt3/qt3/qt-x11-free-native_3.3.5.bb |1 -
 2 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/recipes-qt3/qt3/qt-x11-free-common.inc 
b/recipes-qt3/qt3/qt-x11-free-common.inc
index 1e00138..3bd4e4a 100644
--- a/recipes-qt3/qt3/qt-x11-free-common.inc
+++ b/recipes-qt3/qt3/qt-x11-free-common.inc
@@ -1,6 +1,5 @@
 DESCRIPTION = "Qt/X11 Version ${PV} is a full fledged cross-platform 
application framework"
 SECTION = "x11/libs"
-PRIORITY = "optional"
 LICENSE = "GPL | QPL"
 HOMEPAGE = "http://www.trolltech.com";
 INC_PR = "r4"
diff --git a/recipes-qt3/qt3/qt-x11-free-native_3.3.5.bb 
b/recipes-qt3/qt3/qt-x11-free-native_3.3.5.bb
index 7dd9a34..48fc3a0 100644
--- a/recipes-qt3/qt3/qt-x11-free-native_3.3.5.bb
+++ b/recipes-qt3/qt3/qt-x11-free-native_3.3.5.bb
@@ -1,6 +1,5 @@
 DESCRIPTION = "Qt/X11 Version ${PV}"
 SECTION = "libs"
-PRIORITY = "optional"
 LICENSE = "GPL | QPL"
 DEPENDS = "xmu-native"
 HOMEPAGE = "http://www.trolltech.com";
-- 
1.7.5.4

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-qt3] [PATCH 1/3] qt-x11-free: fix installation and packaging

[Paul Eggleton]

* You cannot install files into the sysroot, this will cause interaction
  problems with shared state.
* Fixed packaging to install to sensible paths and remove most of the
  warnings.
* Merged prepends/appends and their associated functions within the same
  recipe

Signed-off-by: Paul Eggleton 
---
 recipes-qt3/qt3/qt-x11-free-common.inc |   55 +--
 recipes-qt3/qt3/qt-x11-free_3.3.7.bb   |2 +-
 2 files changed, 24 insertions(+), 33 deletions(-)

diff --git a/recipes-qt3/qt3/qt-x11-free-common.inc 
b/recipes-qt3/qt3/qt-x11-free-common.inc
index c92d883..1e00138 100644
--- a/recipes-qt3/qt3/qt-x11-free-common.inc
+++ b/recipes-qt3/qt3/qt-x11-free-common.inc
@@ -3,7 +3,7 @@ SECTION = "x11/libs"
 PRIORITY = "optional"
 LICENSE = "GPL | QPL"
 HOMEPAGE = "http://www.trolltech.com";
-INC_PR = "r3"
+INC_PR = "r4"
 
 S = "${WORKDIR}/qt-x11-free-${PV}"
 
@@ -11,7 +11,6 @@ S = "${WORKDIR}/qt-x11-free-${PV}"
 inherit qmake_base qt3x11
 
 export QTDIR = "${S}"
-STAGING_QT_DIR = "${STAGING_DIR_HOST}/qt3"
 ARCH_i686 = "x86"
 EXTRA_OEMAKE = "-e"
 
@@ -24,13 +23,11 @@ EXTRA_ENV = 'QMAKE="${STAGING_BINDIR_NATIVE}/qmake -after 
INCPATH+=${STAGING_INC
  AR="${TARGET_PREFIX}ar cqs" \
  MOC="${STAGING_BINDIR_NATIVE}/moc3" 
UIC="${STAGING_BINDIR_NATIVE}/uic3" MAKE="make -e"'
 
-do_configure_prepend() {
-if [ ! -L ${QMAKE_MKSPEC_PATH}/${TARGET_OS}-oe-g++ ]; then
-ln -sf ${QMAKE_MKSPEC_PATH}/linux-g++ 
${QMAKE_MKSPEC_PATH}/${TARGET_OS}-oe-g++
-fi
-}
-
 do_configure() {
+   if [ ! -L ${QMAKE_MKSPEC_PATH}/${TARGET_OS}-oe-g++ ]; then
+   ln -sf ${QMAKE_MKSPEC_PATH}/linux-g++ 
${QMAKE_MKSPEC_PATH}/${TARGET_OS}-oe-g++
+   fi
+
echo "yes" | ./configure -prefix ${prefix} ${QT_CONFIG_FLAGS} -no-fast \
-L${STAGING_LIBDIR} -I${STAGING_INCDIR} 
-I${STAGING_INCDIR}/freetype2 -I${STAGING_INCDIR}/mysql
 
@@ -56,43 +53,37 @@ do_compile() {
oe_runmake -C tools ${EXTRA_ENV}
 }
 
-do_install_prepend() {
-   install -d ${STAGING_QT_DIR}/bin
-   ln -sf ${STAGING_BINDIR_NATIVE}/moc3 ${STAGING_QT_DIR}/bin/moc
-   ln -sf ${STAGING_BINDIR_NATIVE}/uic3 ${STAGING_QT_DIR}/bin/uic
-   ln -sf ${STAGING_BINDIR_NATIVE}/qmake ${STAGING_QT_DIR}/bin/qmake
-   install -d ${STAGING_QT_DIR}/lib
-   oe_soinstall lib/libqt-mt.so.${PV} ${STAGING_QT_DIR}/lib
-   install -d ${STAGING_QT_DIR}/include/private
+do_install() {
+   install -d ${D}${includedir}
+   install -d ${D}${includedir}/qt3
+   install -d ${D}${includedir}/qt3/private
for f in include/*.h
do
-   install -m 0644 $f ${STAGING_QT_DIR}/include/
+   install -m 0644 $f ${D}${includedir}/qt3
done
for f in include/private/*.h
do
-   install -m 0644 $f ${STAGING_QT_DIR}/include/private
+   install -m 0644 $f ${D}${includedir}/qt3/private
done
+   install -d ${D}${libdir}
+   install -d ${D}${libdir}/qt3
for f in lib/*.prl
do
-   install -m 0644 $f ${STAGING_QT_DIR}/lib
+   install -m 0644 $f ${D}${libdir}/qt3
done
-}
-
-do_install() {
-   install -d ${D}${libdir}/
-   oe_soinstall lib/libqt-mt.so.${PV} ${D}${libdir}/
-   install -d ${D}${bindir}/
-   install -d ${D}${prefix}/plugins/
-   cp -pPR plugins/imageformats plugins/sqldrivers plugins/designer 
${D}${prefix}/plugins/
+   oe_libinstall -so -C lib libqt-mt ${D}${libdir}
+   install -d ${D}${libdir}/qt3/plugins/
+   cp -pPR plugins/imageformats plugins/sqldrivers plugins/designer 
${D}${libdir}/qt3/plugins/
 }
 
 PACKAGES =+ " libqt-mt3 qt-x11-plugins-imageformats qt-x11-plugins-sqldrivers 
qt-x11-plugins-designer \
  qt-x11-designer qt-x11-assistant qt-x11-qvfb qt-x11-qtconfig"
-FILES_libqt-mt3 = "${D}/{libdir}/libqt-mt*"
-FILES_qt-x11-plugins-imageformats = "${prefix}/plugins/imageformats/*.so"
-FILES_qt-x11-plugins-sqldrivers = "${prefix}/plugins/sqldrivers/*.so"
-FILES_qt-x11-plugins-designer = "${prefix}/plugins/designer/*.so"
+FILES_libqt-mt3 = "${libdir}/libqt-mt.so.*"
+FILES_${PN}-dev += "${libdir}/qt3/*.prl"
+FILES_qt-x11-plugins-imageformats = "${libdir}/qt3/plugins/imageformats/*.so"
+FILES_qt-x11-plugins-sqldrivers = "${libdir}/qt3/plugins/sqldrivers/*.so"
+FILES_qt-x11-plugins-designer = "${libdir}/qt3/plugins/designer/*.so"
 FILES_qt-x11-designer = "${bindir}/designer"
 FILES_qt-x11-assistant = "${bindir}/assistant"
 FILES_qt-x11-qtconfig = "${bindir}/qtconfig"
-FILES_qt-x11-dbg += "${prefix}/plugins/*/.debug ${D}/qt-x11-plugins-debug"
+FILES_${PN}-dbg += "${libdir}/qt3/plugins/*/.debug"
diff --git a/recipes-qt3/qt3/qt-x11-free_3.3.7.bb 
b/recipes-qt3/qt3/qt-x11-free_3.3.7.bb
index a67dd63..cf3b878 100644
--- a/recipes-qt3/qt3/qt-x11-free_3.3.7.bb
+++ b/recipes-qt3/qt3/qt-x11-free_3.3.7.bb
@@ -1,6 +1,6 @@
 DEPENDS = "qt-x11-free-native freetype virtual/libx11 libxmu libxft libxext 
libxren

[yocto] [meta-qt3] [PATCH 3/3] qt3: fix interaction between qt3 and qt4 in the sysroot

[Paul Eggleton]

* Add a -qt3 suffix to all installed utilities so that they do not clash
  with their qt4 counterparts. This fixes errors mentioning
  QtCore/QVariant, Q3Support etc. which occur due to the Qt4 version of
  uic/moc being used that output source files containing references to
  Qt4 headers. qt3x11.bbclass has been updated to point to these renamed
  executables so any recipes using this class should be unaffected by
  this renaming.
* Install libraries using the standard oe_libinstall method

Fixes [YOCTO #1810].

Signed-off-by: Paul Eggleton 
---
 classes/qt3x11.bbclass  |5 +++--
 recipes-qt3/qt3/qt-x11-free-common.inc  |   18 +-
 recipes-qt3/qt3/qt-x11-free-native_3.3.5.bb |   12 
 3 files changed, 16 insertions(+), 19 deletions(-)

diff --git a/classes/qt3x11.bbclass b/classes/qt3x11.bbclass
index 5408b7f..79664f2 100644
--- a/classes/qt3x11.bbclass
+++ b/classes/qt3x11.bbclass
@@ -4,8 +4,9 @@ EXTRA_QMAKEVARS_POST += "CONFIG+=thread"
 # override variables set by qmake_base to compile Qt/X11 apps
 #
 export QTDIR = "${STAGING_DIR_HOST}/qt3"
-export OE_QMAKE_UIC = "${STAGING_BINDIR_NATIVE}/uic3"
-export OE_QMAKE_MOC = "${STAGING_BINDIR_NATIVE}/moc3"
+export OE_QMAKE_QMAKE = "${STAGING_BINDIR_NATIVE}/qmake-qt3"
+export OE_QMAKE_UIC = "${STAGING_BINDIR_NATIVE}/uic-qt3"
+export OE_QMAKE_MOC = "${STAGING_BINDIR_NATIVE}/moc-qt3"
 export OE_QMAKE_CXXFLAGS = "${CXXFLAGS} -DQT_NO_XIM"
 export OE_QMAKE_INCDIR_QT = "${QTDIR}/include"
 export OE_QMAKE_LIBDIR_QT = "${QTDIR}/lib"
diff --git a/recipes-qt3/qt3/qt-x11-free-common.inc 
b/recipes-qt3/qt3/qt-x11-free-common.inc
index 3bd4e4a..4c16b73 100644
--- a/recipes-qt3/qt3/qt-x11-free-common.inc
+++ b/recipes-qt3/qt3/qt-x11-free-common.inc
@@ -2,7 +2,7 @@ DESCRIPTION = "Qt/X11 Version ${PV} is a full fledged 
cross-platform application
 SECTION = "x11/libs"
 LICENSE = "GPL | QPL"
 HOMEPAGE = "http://www.trolltech.com";
-INC_PR = "r4"
+INC_PR = "r5"
 
 S = "${WORKDIR}/qt-x11-free-${PV}"
 
@@ -16,11 +16,11 @@ EXTRA_OEMAKE = "-e"
 QT_CONFIG_FLAGS = "-release -shared -qt-zlib -no-nas-sound -no-sm -qt-libpng 
-no-gif -no-xinerama \
-no-tablet -no-xkb -no-dlopen-opengl -no-nis -no-cups 
-thread  -verbose"
 
-EXTRA_ENV = 'QMAKE="${STAGING_BINDIR_NATIVE}/qmake -after 
INCPATH+=${STAGING_INCDIR} \
+EXTRA_ENV = 'QMAKE="${OE_QMAKE_QMAKE} -after INCPATH+=${STAGING_INCDIR} \
  INCPATH+=${STAGING_INCDIR}/freetype2 LIBS+=-L${STAGING_LIBDIR}" \
  QMAKESPEC="${QMAKESPEC}" LINK="${CXX} 
-Wl,-rpath-link,${STAGING_LIBDIR}" \
  AR="${TARGET_PREFIX}ar cqs" \
- MOC="${STAGING_BINDIR_NATIVE}/moc3" 
UIC="${STAGING_BINDIR_NATIVE}/uic3" MAKE="make -e"'
+ MOC="${OE_QMAKE_MOC}" UIC="${OE_QMAKE_UIC}" MAKE="make -e"'
 
 do_configure() {
if [ ! -L ${QMAKE_MKSPEC_PATH}/${TARGET_OS}-oe-g++ ]; then
@@ -34,18 +34,18 @@ do_configure() {
rm -f src/qtmain.pro
cat Makefile >makefile
find . -name "Makefile"|xargs rm -f
-   (cd src && qmake -spec ${QMAKESPEC} )
-   (cd plugins/src && qmake -spec ${QMAKESPEC} )
-   (cd tools && qmake -spec ${QMAKESPEC} )
-   (cd tools/qvfb && qmake -spec ${QMAKESPEC} )
+   (cd src && ${OE_QMAKE_QMAKE} -spec ${QMAKESPEC} )
+   (cd plugins/src && ${OE_QMAKE_QMAKE} -spec ${QMAKESPEC} )
+   (cd tools && ${OE_QMAKE_QMAKE} -spec ${QMAKESPEC} )
+   (cd tools/qvfb && ${OE_QMAKE_QMAKE} -spec ${QMAKESPEC} )
 }
 
 do_compile() {
unset CFLAGS
unset CXXFLAGS
 
-   install -m 0755 ${STAGING_BINDIR_NATIVE}/moc3 ${S}/bin/moc
-   install -m 0755 ${STAGING_BINDIR_NATIVE}/uic3 ${S}/bin/uic
+   install -m 0755 ${OE_QMAKE_MOC} ${S}/bin/moc
+   install -m 0755 ${OE_QMAKE_UIC} ${S}/bin/uic
 
oe_runmake -C src ${EXTRA_ENV}
oe_runmake -C plugins/src ${EXTRA_ENV}
diff --git a/recipes-qt3/qt3/qt-x11-free-native_3.3.5.bb 
b/recipes-qt3/qt3/qt-x11-free-native_3.3.5.bb
index 48fc3a0..d70c373 100644
--- a/recipes-qt3/qt3/qt-x11-free-native_3.3.5.bb
+++ b/recipes-qt3/qt3/qt-x11-free-native_3.3.5.bb
@@ -3,7 +3,7 @@ SECTION = "libs"
 LICENSE = "GPL | QPL"
 DEPENDS = "xmu-native"
 HOMEPAGE = "http://www.trolltech.com";
-PR = "r2"
+PR = "r3"
 
 FILESDIR = "${@os.path.dirname(bb.data.getVar('FILE',d,1))}/qt-x11-free"
 
@@ -48,9 +48,9 @@ do_compile() {
 
 do_install() {
 install -d ${D}${bindir}/
-install -m 0755 bin/qmake ${D}${bindir}/qmake3
+install -m 0755 bin/qmake ${D}${bindir}/qmake-qt3
 for i in moc uic  lrelease lupdate; do
-install -m 0755 bin/${i} ${D}${bindir}/${i}3
+install -m 0755 bin/${i} ${D}${bindir}/${i}-qt3
 done
  
 install -d ${D}${datadir}/qt3/
@@ -58,11 +58,7 @@ do_install() {
 ln -sf linux-g++ ${D}${datadir}/qt3/mkspecs/${TARGET_OS}-oe-g++
 ln -sf qt3/mkspecs ${D}${datadir}/qmake
 install -d ${D}${libdir}/
-oe_soinstall lib/libqt-mt.so.${PV} ${D}${libdir}/
-cd ${D}${bindir}
-for i in q

[yocto] [meta-qt3] [PATCH 0/3] More Qt3 fixes

[Paul Eggleton]

These should address the failures we have been seeing on the autobuilder
and clean up a few other things.

The following changes since commit 9d58aef10d75fe5168cc0c561c480c751266d54b:

  classes: remove qt3e.bbclass (2011-12-08 15:09:06 +)

are available in the git repository at:
  git://git.yoctoproject.org/poky-contrib paule/qt3-fixes2
  http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=paule/qt3-fixes2

Paul Eggleton (3):
  qt-x11-free: fix installation and packaging
  qt-x11-free(-native): remove PRIORITY
  qt3: fix interaction between qt3 and qt4 in the sysroot

 classes/qt3x11.bbclass  |5 +-
 recipes-qt3/qt3/qt-x11-free-common.inc  |   72 +++---
 recipes-qt3/qt3/qt-x11-free-native_3.3.5.bb |   13 ++---
 recipes-qt3/qt3/qt-x11-free_3.3.7.bb|2 +-
 4 files changed, 39 insertions(+), 53 deletions(-)

-- 
1.7.5.4

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Adding features to a machine

[Darren Hart]

On 12/08/2011 11:13 AM, Marc Ferland wrote:
> Hi,
> 
> I have a crownbay based machine here and I would like to add the
> bluetooth machine feature to it. Do I have to create a whole new BSP for
> this? I haven't seen any examples showing how to _modify_ a machine
> description.


Have you tried modifying either MACHINE_FEATURES_crownbay or
KERNEL_FEATURES_crownbay from local.conf? I haven't attempted this
myself, but I believe it should work.

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Adding features to a machine

[Marc Ferland]

Hi,

I have a crownbay based machine here and I would like to add the bluetooth
machine feature to it. Do I have to create a whole new BSP for this? I
haven't seen any examples showing how to _modify_ a machine description.

Regards,

Marc
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Variable locality too restricted.

[Darren Hart]

On 12/08/2011 06:31 AM, Bruce Ashfield wrote:
> On Thu, Dec 8, 2011 at 2:24 AM, David Nyström  wrote:
>>
>> 
>> From: Koen Kooi [k...@dominion.thruhere.net]
>> Sent: Wednesday, December 07, 2011 15:07
>> To: Paul Eggleton
>> Cc: Chris Larson; David Nyström; yocto@yoctoproject.org
>> Subject: Re: [yocto] Variable locality too restricted.
>>
>> Op 7 dec. 2011, om 15:05 heeft Paul Eggleton het volgende geschreven:
>>
>>> On Wednesday 07 December 2011 06:52:25 Chris Larson wrote:
 On Wed, Dec 7, 2011 at 6:44 AM, David Nyström 
>>> wrote:
> I'm trying to create a setup for qemuppc.
>
> Goals:
> core-image-minimal + virtual/kernel.
> core-image-minimal + virtual/kernel with modified .config for debug
> flavoured kernel.
>
> Problems:
> PREFERRED_PROVIDER seems to be restricted to local.conf, distro and
> machine.
 This is incorrect. It can be anywhere in the configuration metadata.
 bitbake.conf includes a variety of config files, not just
 distro/machine. Read that to see other existing files which get
 included. Further, you could create a .conf/.inc which you include
 from your machine .conf, if your goal is just to avoid duplication.
>>>
>>> Changing MACHINE has other implications though; do we not have any other way
>>> to switch out the kernel on a per-image basis?
>>
>> And how would that work from a packaging perspective? AIUI changing 
>> DISTRO/MACHINE flags in an image is a recipe for failure.
>>
>> regards,
>>
>> Koen
>> Op 7 dec. 2011, om 15:10 heeft Paul Eggleton het volgende geschreven:
>>
>> --
>>> On Wednesday 07 December 2011 15:07:54 Koen Kooi wrote:
> Changing MACHINE has other implications though; do we not have any other
> way to switch out the kernel on a per-image basis?

 And how would that work from a packaging perspective? AIUI changing
 DISTRO/MACHINE flags in an image is a recipe for failure.
>>>
>>> I'm not suggesting changing the kernel configuration for the existing 
>>> kernel;
>>> naturally you would need a different kernel recipe. Surely you should just 
>>> be
>>> able to have a different kernel that is built and installed for a different
>>> image file? No invalidated packages necessary.
>>
>> A kernel buld will generate packages and thanks to kernel.bbclass they will 
>> have similar names. So what will happen when I do:
>>
>> bitbake foo-image bar-image
>>
>> ? Will it build 2 kernels? Which kernel will end up being packaged or will 
>> there be a mix of both in deploy?
>>
>> regards,
>>
>> Koen
>>
>> --
>>
>> Different virtual/kernel recipies depending on kernel configuration might 
>> not be the best resolution path for this issue.
>>
>> How would it be problematic to have multiple binary flavour packages(Still a 
>> single source package)
>> of the same kernel with the same linux-headers in the distro packages ?
>> In deploy/images a similiar notation as for rootfs could be used.
>> Perhaps there are no mechanisms today to do this, but perhaps there 
>> could/should be ?
>> What about a pkgconfig style approach ?
>>
>> poky configuration contains a logical separation of IMAGE, MACHINE and 
>> DISTRO. (Probably more, but this is unrelated to my point below).
>> What is the roadmap and future of this separation ?
>>
>> image:
>> The IMAGE may contain user applications that will not function without the 
>> proper kernel modules.(Or possibly non-module available .config items).
>> i.e. RDEPENDS = kernel-module- will is impossible to automate since it 
>> only scans kernel build for its existence.(if it was configured by kernel 
>> .config monolith selected by MACHINE)
>> This is solved in most recipies as RRECOMMENDS = kernel-module-xxx to avoid 
>> build breakage.
>>
>> So you need to configure your kernel to support all your IMAGEs, from 
>> core-image-smaller-than-minimal to core-image-huge-system(or in my case 
>> debug, profiling)
>> This is especially problematic for small embedded systems when it comes to 
>> debug and profiling, where included kernel configuration(depending on 
>> exactly what)
>> will have varying degrees of performance impact.(some huge, others we can 
>> probably live with).
>>
>> machine:
>> In my head, this would contain machine specific configuration and not deal 
>> with other kernel configuration.
>> In edison, the kernel configuration is treated as a monolith, perhaps we can 
>> improve this by allowing for a more dynamic configuration model of the 
>> kernel, where the
>> machine logical layer would depend on _only_ the machine specific parts of 
>> the kernel configuration. In the current(edison) case, it usually uses a 
>> defconfig.
>> Great, but let the build modify it.
>>
>> pipedream:
>> 1. MACHINE selects a defconfig.
>> 2. IMAGE selects packets on rootfs, some depend on kernel-module-xx, or 
>> kernel-config-xx.
>> 3. When building image, fist stage scans included recipes for 
>> kernel-module-* and kern

Re: [yocto] [meta-qt3] [PATCH 0/5] Qt3 fixes

[Saul Wold]

On 12/08/2011 07:18 AM, Paul Eggleton wrote:

A fix for a compile error plus a bunch of minor tidy-ups for meta-qt3.

The following changes since commit 0e9784d26df51bd564b8f23bd40a6c36969abd5c:

   qt-x11-free-native: fix where qmake gets linked (2011-09-14 13:41:06 -0700)

are available in the git repository at:
   git://git.yoctoproject.org/poky-contrib paule/qt3-fixes
   http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=paule/qt3-fixes

Paul Eggleton (5):
   qt-x11-free-native: add qt3-cstddef.patch
   qt-x11-free: remove version 3.3.6
   qt-x11-free: use INC_PR
   qt-x11-free(-native): remove erroneous PROVIDES
   classes: remove qt3e.bbclass

  classes/qt3e.bbclass|   11 ---
  recipes-qt3/qt3/qt-x11-free-common.inc  |2 +-
  recipes-qt3/qt3/qt-x11-free-native_3.3.5.bb |7 +++
  recipes-qt3/qt3/qt-x11-free_3.3.6.bb|   13 -
  recipes-qt3/qt3/qt-x11-free_3.3.7.bb|3 +--
  5 files changed, 5 insertions(+), 31 deletions(-)
  delete mode 100644 classes/qt3e.bbclass
  delete mode 100644 recipes-qt3/qt3/qt-x11-free_3.3.6.bb


Merged into the meta-qt3 layer

Thanks for the fixes

Sau!
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] meta-qt3: qt3-x11-native compile fix on Fedora 15 x86-64

[Paul Eggleton]

Hi Andre,

On Wednesday 17 August 2011 11:17:30 Andre Haupt wrote:
> This patch fixes compilation of qt-x11-native_3.3.5 on Fedora 15 x86-64.
> The compiler was complainig about unknown type ptrdiff_t. Including the
> appropriate header in qvaluelist.h helps.

Unfortunately this patch seems to have fallen through the cracks. However the 
same fix has now been merged into meta-qt3. Sorry about the delay!

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-qt3] [PATCH 5/5] classes: remove qt3e.bbclass

[Paul Eggleton]

We can't make use of this class since we don't have qt3-embedded, so
remove it.

Signed-off-by: Paul Eggleton 
---
 classes/qt3e.bbclass |   11 ---
 1 files changed, 0 insertions(+), 11 deletions(-)
 delete mode 100644 classes/qt3e.bbclass

diff --git a/classes/qt3e.bbclass b/classes/qt3e.bbclass
deleted file mode 100644
index d3d4a14..000
--- a/classes/qt3e.bbclass
+++ /dev/null
@@ -1,11 +0,0 @@
-#
-# override variables set by qmake_base to compile Qt/X11 apps
-#
-export QTDIR="${STAGING_DIR_HOST}/qte3"
-export QTEDIR="${STAGING_DIR_HOST}/qte3"
-export OE_QMAKE_UIC="${STAGING_BINDIR_NATIVE}/uic3"
-export OE_QMAKE_MOC="${STAGING_BINDIR_NATIVE}/moc3"
-export OE_QMAKE_CXXFLAGS="${CXXFLAGS} "
-export OE_QMAKE_INCDIR_QT="${STAGING_INCDIR}/qte3/include"
-export OE_QMAKE_LIBDIR_QT="${STAGING_LIBDIR}/qte3/lib"
-export OE_QMAKE_LIBS_QT="qte"
-- 
1.7.5.4

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-qt3] [PATCH 4/5] qt-x11-free(-native): remove erroneous PROVIDES

[Paul Eggleton]

None of these statements do anything, because a recipe always PROVIDES
${PN} by default.

Signed-off-by: Paul Eggleton 
---
 recipes-qt3/qt3/qt-x11-free-native_3.3.5.bb |2 --
 recipes-qt3/qt3/qt-x11-free_3.3.7.bb|1 -
 2 files changed, 0 insertions(+), 3 deletions(-)

diff --git a/recipes-qt3/qt3/qt-x11-free-native_3.3.5.bb 
b/recipes-qt3/qt3/qt-x11-free-native_3.3.5.bb
index 15f71d4..7dd9a34 100644
--- a/recipes-qt3/qt3/qt-x11-free-native_3.3.5.bb
+++ b/recipes-qt3/qt3/qt-x11-free-native_3.3.5.bb
@@ -6,7 +6,6 @@ DEPENDS = "xmu-native"
 HOMEPAGE = "http://www.trolltech.com";
 PR = "r2"
 
-PROVIDES += "qt-x11-free-native"
 FILESDIR = "${@os.path.dirname(bb.data.getVar('FILE',d,1))}/qt-x11-free"
 
 LIC_FILES_CHKSUM = "file://LICENSE.GPL;md5=629178675a7d49c9fa19dfe9f43ea256 \
@@ -22,7 +21,6 @@ S = "${WORKDIR}/qt-x11-free-${PV}"
 # or the full qmake.oeclass.
 #
 
-PROVIDES = "qt-x11-free-native"
 export QTDIR = "${S}"
 export SYSCONF_CXX = "${CCACHE} g++"
 export SYSCONF_CC  = "${CCACHE} gcc"
diff --git a/recipes-qt3/qt3/qt-x11-free_3.3.7.bb 
b/recipes-qt3/qt3/qt-x11-free_3.3.7.bb
index f2e8591..a67dd63 100644
--- a/recipes-qt3/qt3/qt-x11-free_3.3.7.bb
+++ b/recipes-qt3/qt3/qt-x11-free_3.3.7.bb
@@ -2,7 +2,6 @@ DEPENDS = "qt-x11-free-native freetype virtual/libx11 libxmu 
libxft libxext libx
 PROVIDES = "qt3x11"
 PR = "${INC_PR}.1"
 
-PREFERRED_VERSION_qt-x11-free = 3.3.7
 LIC_FILES_CHKSUM = "file://LICENSE.GPL;md5=b07b0d5ac6b1822effe47173a1744433 \
 file://LICENSE.QPL;md5=b81b6b6fc04ed873adde5aa901c0613b"
 
-- 
1.7.5.4

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-qt3] [PATCH 3/5] qt-x11-free: use INC_PR

[Paul Eggleton]

PR was being set in both the inc and the recipes, this is not correct.
Move them to use INC_PR so the recipe and inc can be updated and retain
sanity.

Signed-off-by: Paul Eggleton 
---
 recipes-qt3/qt3/qt-x11-free-common.inc |2 +-
 recipes-qt3/qt3/qt-x11-free_3.3.7.bb   |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/recipes-qt3/qt3/qt-x11-free-common.inc 
b/recipes-qt3/qt3/qt-x11-free-common.inc
index 6aa6306..c92d883 100644
--- a/recipes-qt3/qt3/qt-x11-free-common.inc
+++ b/recipes-qt3/qt3/qt-x11-free-common.inc
@@ -3,7 +3,7 @@ SECTION = "x11/libs"
 PRIORITY = "optional"
 LICENSE = "GPL | QPL"
 HOMEPAGE = "http://www.trolltech.com";
-PR = "r1"
+INC_PR = "r3"
 
 S = "${WORKDIR}/qt-x11-free-${PV}"
 
diff --git a/recipes-qt3/qt3/qt-x11-free_3.3.7.bb 
b/recipes-qt3/qt3/qt-x11-free_3.3.7.bb
index 94486ed..f2e8591 100644
--- a/recipes-qt3/qt3/qt-x11-free_3.3.7.bb
+++ b/recipes-qt3/qt3/qt-x11-free_3.3.7.bb
@@ -1,6 +1,6 @@
 DEPENDS = "qt-x11-free-native freetype virtual/libx11 libxmu libxft libxext 
libxrender libxrandr libxcursor  virtual/libgl"
 PROVIDES = "qt3x11"
-PR = "r0"
+PR = "${INC_PR}.1"
 
 PREFERRED_VERSION_qt-x11-free = 3.3.7
 LIC_FILES_CHKSUM = "file://LICENSE.GPL;md5=b07b0d5ac6b1822effe47173a1744433 \
-- 
1.7.5.4

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-qt3] [PATCH 2/5] qt-x11-free: remove version 3.3.6

[Paul Eggleton]

We only need one version, 3.3.7 was the default preference (in the
absence of DEFAULT_PREFERENCE) and the 3.3.6 recipe depends on
uicmoc3-native which we do not have, so remove it.

Signed-off-by: Paul Eggleton 
---
 recipes-qt3/qt3/qt-x11-free_3.3.6.bb |   13 -
 1 files changed, 0 insertions(+), 13 deletions(-)
 delete mode 100644 recipes-qt3/qt3/qt-x11-free_3.3.6.bb

diff --git a/recipes-qt3/qt3/qt-x11-free_3.3.6.bb 
b/recipes-qt3/qt3/qt-x11-free_3.3.6.bb
deleted file mode 100644
index 789e6fb..000
--- a/recipes-qt3/qt3/qt-x11-free_3.3.6.bb
+++ /dev/null
@@ -1,13 +0,0 @@
-DEPENDS = "uicmoc3-native freetype virtual/libx11 libxft libxext libxrender 
libxrandr libxcursor mysql virtual/libgl"
-PROVIDES = "qt3x11"
-PR = "r3"
-
-SRC_URI = "ftp://ftp.trolltech.com/qt/source/qt-x11-free-${PV}.tar.bz2 \
-  file://configure.patch \
-  file://no-examples.patch \
-   file://gcc4_1-HACK.patch"
-
-require qt-x11-free-common.inc
-
-SRC_URI[md5sum] = "dc1384c03ac08af21f6fefab32d982cf"
-SRC_URI[sha256sum] = 
"04f12083f6a6f7a8fd4d34a6c1efd37db76a67580c424f4fb7b7c43c0565e6ae"
-- 
1.7.5.4

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-qt3] [PATCH 1/5] qt-x11-free-native: add qt3-cstddef.patch

[Paul Eggleton]

When building on Fedora 15 the build failed with the error mentioned in
this patch ("qvaluelist.h: error: 'ptrdiff_t' does not name a type"), so
it is needed by the native recipe as well.

Signed-off-by: Paul Eggleton 
---
 recipes-qt3/qt3/qt-x11-free-native_3.3.5.bb |5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/recipes-qt3/qt3/qt-x11-free-native_3.3.5.bb 
b/recipes-qt3/qt3/qt-x11-free-native_3.3.5.bb
index 779513e..15f71d4 100644
--- a/recipes-qt3/qt3/qt-x11-free-native_3.3.5.bb
+++ b/recipes-qt3/qt3/qt-x11-free-native_3.3.5.bb
@@ -4,7 +4,7 @@ PRIORITY = "optional"
 LICENSE = "GPL | QPL"
 DEPENDS = "xmu-native"
 HOMEPAGE = "http://www.trolltech.com";
-PR = "r1"
+PR = "r2"
 
 PROVIDES += "qt-x11-free-native"
 FILESDIR = "${@os.path.dirname(bb.data.getVar('FILE',d,1))}/qt-x11-free"
@@ -13,7 +13,8 @@ LIC_FILES_CHKSUM = 
"file://LICENSE.GPL;md5=629178675a7d49c9fa19dfe9f43ea256 \
 file://LICENSE.QPL;md5=fff372435cb41647bc0b3cb940ea5c51"
 
 SRC_URI = "ftp://ftp.trolltech.com/qt/source/qt-x11-free-${PV}.tar.bz2 \
-  file://no-examples.patch"
+   file://no-examples.patch \
+   file://qt3-cstddef.patch"
 S = "${WORKDIR}/qt-x11-free-${PV}"
 
 #
-- 
1.7.5.4

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-qt3] [PATCH 0/5] Qt3 fixes

[Paul Eggleton]

A fix for a compile error plus a bunch of minor tidy-ups for meta-qt3.

The following changes since commit 0e9784d26df51bd564b8f23bd40a6c36969abd5c:

  qt-x11-free-native: fix where qmake gets linked (2011-09-14 13:41:06 -0700)

are available in the git repository at:
  git://git.yoctoproject.org/poky-contrib paule/qt3-fixes
  http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=paule/qt3-fixes

Paul Eggleton (5):
  qt-x11-free-native: add qt3-cstddef.patch
  qt-x11-free: remove version 3.3.6
  qt-x11-free: use INC_PR
  qt-x11-free(-native): remove erroneous PROVIDES
  classes: remove qt3e.bbclass

 classes/qt3e.bbclass|   11 ---
 recipes-qt3/qt3/qt-x11-free-common.inc  |2 +-
 recipes-qt3/qt3/qt-x11-free-native_3.3.5.bb |7 +++
 recipes-qt3/qt3/qt-x11-free_3.3.6.bb|   13 -
 recipes-qt3/qt3/qt-x11-free_3.3.7.bb|3 +--
 5 files changed, 5 insertions(+), 31 deletions(-)
 delete mode 100644 classes/qt3e.bbclass
 delete mode 100644 recipes-qt3/qt3/qt-x11-free_3.3.6.bb

-- 
1.7.5.4

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Variable locality too restricted.

[Bruce Ashfield]

On Thu, Dec 8, 2011 at 2:24 AM, David Nyström  wrote:
>
> 
> From: Koen Kooi [k...@dominion.thruhere.net]
> Sent: Wednesday, December 07, 2011 15:07
> To: Paul Eggleton
> Cc: Chris Larson; David Nyström; yocto@yoctoproject.org
> Subject: Re: [yocto] Variable locality too restricted.
>
> Op 7 dec. 2011, om 15:05 heeft Paul Eggleton het volgende geschreven:
>
>> On Wednesday 07 December 2011 06:52:25 Chris Larson wrote:
>>> On Wed, Dec 7, 2011 at 6:44 AM, David Nyström 
>> wrote:
 I'm trying to create a setup for qemuppc.

 Goals:
 core-image-minimal + virtual/kernel.
 core-image-minimal + virtual/kernel with modified .config for debug
 flavoured kernel.

 Problems:
 PREFERRED_PROVIDER seems to be restricted to local.conf, distro and
 machine.
>>> This is incorrect. It can be anywhere in the configuration metadata.
>>> bitbake.conf includes a variety of config files, not just
>>> distro/machine. Read that to see other existing files which get
>>> included. Further, you could create a .conf/.inc which you include
>>> from your machine .conf, if your goal is just to avoid duplication.
>>
>> Changing MACHINE has other implications though; do we not have any other way
>> to switch out the kernel on a per-image basis?
>
> And how would that work from a packaging perspective? AIUI changing 
> DISTRO/MACHINE flags in an image is a recipe for failure.
>
> regards,
>
> Koen
> Op 7 dec. 2011, om 15:10 heeft Paul Eggleton het volgende geschreven:
>
> --
>> On Wednesday 07 December 2011 15:07:54 Koen Kooi wrote:
 Changing MACHINE has other implications though; do we not have any other
 way to switch out the kernel on a per-image basis?
>>>
>>> And how would that work from a packaging perspective? AIUI changing
>>> DISTRO/MACHINE flags in an image is a recipe for failure.
>>
>> I'm not suggesting changing the kernel configuration for the existing kernel;
>> naturally you would need a different kernel recipe. Surely you should just be
>> able to have a different kernel that is built and installed for a different
>> image file? No invalidated packages necessary.
>
> A kernel buld will generate packages and thanks to kernel.bbclass they will 
> have similar names. So what will happen when I do:
>
> bitbake foo-image bar-image
>
> ? Will it build 2 kernels? Which kernel will end up being packaged or will 
> there be a mix of both in deploy?
>
> regards,
>
> Koen
>
> --
>
> Different virtual/kernel recipies depending on kernel configuration might not 
> be the best resolution path for this issue.
>
> How would it be problematic to have multiple binary flavour packages(Still a 
> single source package)
> of the same kernel with the same linux-headers in the distro packages ?
> In deploy/images a similiar notation as for rootfs could be used.
> Perhaps there are no mechanisms today to do this, but perhaps there 
> could/should be ?
> What about a pkgconfig style approach ?
>
> poky configuration contains a logical separation of IMAGE, MACHINE and 
> DISTRO. (Probably more, but this is unrelated to my point below).
> What is the roadmap and future of this separation ?
>
> image:
> The IMAGE may contain user applications that will not function without the 
> proper kernel modules.(Or possibly non-module available .config items).
> i.e. RDEPENDS = kernel-module- will is impossible to automate since it 
> only scans kernel build for its existence.(if it was configured by kernel 
> .config monolith selected by MACHINE)
> This is solved in most recipies as RRECOMMENDS = kernel-module-xxx to avoid 
> build breakage.
>
> So you need to configure your kernel to support all your IMAGEs, from 
> core-image-smaller-than-minimal to core-image-huge-system(or in my case 
> debug, profiling)
> This is especially problematic for small embedded systems when it comes to 
> debug and profiling, where included kernel configuration(depending on exactly 
> what)
> will have varying degrees of performance impact.(some huge, others we can 
> probably live with).
>
> machine:
> In my head, this would contain machine specific configuration and not deal 
> with other kernel configuration.
> In edison, the kernel configuration is treated as a monolith, perhaps we can 
> improve this by allowing for a more dynamic configuration model of the 
> kernel, where the
> machine logical layer would depend on _only_ the machine specific parts of 
> the kernel configuration. In the current(edison) case, it usually uses a 
> defconfig.
> Great, but let the build modify it.
>
> pipedream:
> 1. MACHINE selects a defconfig.
> 2. IMAGE selects packets on rootfs, some depend on kernel-module-xx, or 
> kernel-config-xx.
> 3. When building image, fist stage scans included recipes for kernel-module-* 
> and kernel-config-* and adds this to the MACHINE selected defconfig before 
> building kernel.

Hi David,

For what it's worth, if you use the linux-yocto tooling/base kernel,
there are