oe-core cleanup...

oe-core cleanup...

[Mark Hatle]

I finally got a chance to look at the oe-core and where it currently is..  Some
suggestions below:

LICENSE file, this may need to be cleaned up to only cover the components
actually in the oe-core.

README likely needs some revision

README.hardware needs a lot of revision.  Anything outside of support for QEMU
should be removed.

The meta-demoapps and meta-rt components, will those be staying or going?

The meta/recipes.txt needs to be verified as still what we want -- I assume it
is at this point..

meta/recipes-...  sato, qt, gnome, I thought were going elsewhere?

Do the items in the "scripts" need to be renamed or is Poky being kept in the
naming?  Same with the poky-init-build-env?

Then I also assume the items in the documentation directory need to be cleaned
up as well...

Let me know what you'd like me to try and tackle -- or if we need to bring these
items up at the TSC for recommendation.

--Mark

Re: oe-core cleanup...

[Richard Purdie]

Thanks for starting this thread Mark, I've also just been looking at
this question so its timely.

On Wed, 2011-03-02 at 11:30 -0600, Mark Hatle wrote:
> I finally got a chance to look at the oe-core and where it currently is..  Some
> suggestions below:
> 
> LICENSE file, this may need to be cleaned up to only cover the components
> actually in the oe-core.
> 
> README likely needs some revision
> 
> README.hardware needs a lot of revision.  Anything outside of support for QEMU
> should be removed.
> 
> The meta-demoapps and meta-rt components, will those be staying or going?
> 
> The meta/recipes.txt needs to be verified as still what we want -- I assume it
> is at this point..
> 
> meta/recipes-...  sato, qt, gnome, I thought were going elsewhere?
> 
> Do the items in the "scripts" need to be renamed or is Poky being kept in the
> naming?  Same with the poky-init-build-env?
> 
> Then I also assume the items in the documentation directory need to be cleaned
> up as well...
> 
> Let me know what you'd like me to try and tackle -- or if we need to bring these
> items up at the TSC for recommendation.

I'm proposing this change so far:

http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/roorg&id=891ad22536b49d4fee066a5865ad730f791d36e9

with those relocated files being removed from oe-core. Any objections to
that to start with? I think meta-demoapps would also be removed and I
think the TSC pretty much agreed on that.

That would leave these files/directories that I'm aware of that also
need attention:

LICENSE
README
README.hardware
poky-init-build-env
meta/conf/distro/include
meta-rt/*
scripts/*

Is there an easy choice to make on these?

I would like to setup some common distro include files but that is a
separate topic. The main quesiton is whether to leave any of
meta/conf/distro/include around for this or remove for now and bring
back as needed?

Cheers,

Richard

Re: oe-core cleanup...

[Koen Kooi]

Op 2 mrt 2011, om 19:00 heeft Richard Purdie het volgende geschreven:

> Thanks for starting this thread Mark, I've also just been looking at
> this question so its timely.
> 
> On Wed, 2011-03-02 at 11:30 -0600, Mark Hatle wrote:
>> I finally got a chance to look at the oe-core and where it currently is..  Some
>> suggestions below:
>> 
>> LICENSE file, this may need to be cleaned up to only cover the components
>> actually in the oe-core.
>> 
>> README likely needs some revision
>> 
>> README.hardware needs a lot of revision.  Anything outside of support for QEMU
>> should be removed.
>> 
>> The meta-demoapps and meta-rt components, will those be staying or going?
>> 
>> The meta/recipes.txt needs to be verified as still what we want -- I assume it
>> is at this point..
>> 
>> meta/recipes-...  sato, qt, gnome, I thought were going elsewhere?
>> 
>> Do the items in the "scripts" need to be renamed or is Poky being kept in the
>> naming?  Same with the poky-init-build-env?
>> 
>> Then I also assume the items in the documentation directory need to be cleaned
>> up as well...
>> 
>> Let me know what you'd like me to try and tackle -- or if we need to bring these
>> items up at the TSC for recommendation.
> 
> I'm proposing this change so far:
> 
> http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/roorg&id=891ad22536b49d4fee066a5865ad730f791d36e9
> 
> with those relocated files being removed from oe-core. Any objections to
> that to start with? 

Why not put the recipes in meta-oe? I have need for e.g eds-dbus and would like to have that in meta-oe.

regards,

Koen

Re: oe-core cleanup...

[Mark Hatle]

On 3/2/11 12:27 PM, Koen Kooi wrote:
> 
> Op 2 mrt 2011, om 19:00 heeft Richard Purdie het volgende geschreven:
> 
>> Thanks for starting this thread Mark, I've also just been looking at
>> this question so its timely.
>>
>> On Wed, 2011-03-02 at 11:30 -0600, Mark Hatle wrote:
>>> I finally got a chance to look at the oe-core and where it currently is..  Some
>>> suggestions below:
>>>
>>> LICENSE file, this may need to be cleaned up to only cover the components
>>> actually in the oe-core.
>>>
>>> README likely needs some revision
>>>
>>> README.hardware needs a lot of revision.  Anything outside of support for QEMU
>>> should be removed.
>>>
>>> The meta-demoapps and meta-rt components, will those be staying or going?
>>>
>>> The meta/recipes.txt needs to be verified as still what we want -- I assume it
>>> is at this point..
>>>
>>> meta/recipes-...  sato, qt, gnome, I thought were going elsewhere?
>>>
>>> Do the items in the "scripts" need to be renamed or is Poky being kept in the
>>> naming?  Same with the poky-init-build-env?
>>>
>>> Then I also assume the items in the documentation directory need to be cleaned
>>> up as well...
>>>
>>> Let me know what you'd like me to try and tackle -- or if we need to bring these
>>> items up at the TSC for recommendation.
>>
>> I'm proposing this change so far:
>>
>> http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/roorg&id=891ad22536b49d4fee066a5865ad730f791d36e9
>>
>> with those relocated files being removed from oe-core. Any objections to
>> that to start with? 
> 
> Why not put the recipes in meta-oe? I have need for e.g eds-dbus and would like to have that in meta-oe.

If it's acceptable within meta-oe (I don't see why this wouldn't be) it
certainly can be added there as well.. however, I was assuming the default was
meta-yocto and it not going into meta-oe until a separate merge step, process,
etc..  meta-oe would be made up of the existing OE components (not in core)
initially...

--Mark

> regards,
> 
> Koen
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: oe-core cleanup...

[Richard Purdie]

On Wed, 2011-03-02 at 19:27 +0100, Koen Kooi wrote:
> Op 2 mrt 2011, om 19:00 heeft Richard Purdie het volgende geschreven:
> 
> > Thanks for starting this thread Mark, I've also just been looking at
> > this question so its timely.
> > 
> > On Wed, 2011-03-02 at 11:30 -0600, Mark Hatle wrote:
> >> I finally got a chance to look at the oe-core and where it currently is..  Some
> >> suggestions below:
> >> 
> >> LICENSE file, this may need to be cleaned up to only cover the components
> >> actually in the oe-core.
> >> 
> >> README likely needs some revision
> >> 
> >> README.hardware needs a lot of revision.  Anything outside of support for QEMU
> >> should be removed.
> >> 
> >> The meta-demoapps and meta-rt components, will those be staying or going?
> >> 
> >> The meta/recipes.txt needs to be verified as still what we want -- I assume it
> >> is at this point..
> >> 
> >> meta/recipes-...  sato, qt, gnome, I thought were going elsewhere?
> >> 
> >> Do the items in the "scripts" need to be renamed or is Poky being kept in the
> >> naming?  Same with the poky-init-build-env?
> >> 
> >> Then I also assume the items in the documentation directory need to be cleaned
> >> up as well...
> >> 
> >> Let me know what you'd like me to try and tackle -- or if we need to bring these
> >> items up at the TSC for recommendation.
> > 
> > I'm proposing this change so far:
> > 
> > http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/roorg&id=891ad22536b49d4fee066a5865ad730f791d36e9
> > 
> > with those relocated files being removed from oe-core. Any objections to
> > that to start with? 
> 
> Why not put the recipes in meta-oe? I have need for e.g eds-dbus and would like to have that in meta-oe.

Which pieces are we talking about? Does oe-core want sato? Should some
of these go to meta-gnome and is that what we want? Or do we want all of
sato there?

I was under the impression sato might not be wanted but I'm open to
influence either way on that. Certainly there are some pieces "we" as in
Yocto put into recipe-sato that could arguably be positioned elsewhere.

Are you also concerned about meta-demoapps or is that fine?

Cheers,

Richard

Re: oe-core cleanup...

[Tom Rini]

On 03/02/2011 12:18 PM, Richard Purdie wrote:
> On Wed, 2011-03-02 at 19:27 +0100, Koen Kooi wrote:
>> Op 2 mrt 2011, om 19:00 heeft Richard Purdie het volgende geschreven:
>>
>>> Thanks for starting this thread Mark, I've also just been looking at
>>> this question so its timely.
>>>
>>> On Wed, 2011-03-02 at 11:30 -0600, Mark Hatle wrote:
>>>> I finally got a chance to look at the oe-core and where it currently is..  Some
>>>> suggestions below:
>>>>
>>>> LICENSE file, this may need to be cleaned up to only cover the components
>>>> actually in the oe-core.
>>>>
>>>> README likely needs some revision
>>>>
>>>> README.hardware needs a lot of revision.  Anything outside of support for QEMU
>>>> should be removed.
>>>>
>>>> The meta-demoapps and meta-rt components, will those be staying or going?
>>>>
>>>> The meta/recipes.txt needs to be verified as still what we want -- I assume it
>>>> is at this point..
>>>>
>>>> meta/recipes-...  sato, qt, gnome, I thought were going elsewhere?
>>>>
>>>> Do the items in the "scripts" need to be renamed or is Poky being kept in the
>>>> naming?  Same with the poky-init-build-env?
>>>>
>>>> Then I also assume the items in the documentation directory need to be cleaned
>>>> up as well...
>>>>
>>>> Let me know what you'd like me to try and tackle -- or if we need to bring these
>>>> items up at the TSC for recommendation.
>>>
>>> I'm proposing this change so far:
>>>
>>> http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/roorg&id=891ad22536b49d4fee066a5865ad730f791d36e9
>>>
>>> with those relocated files being removed from oe-core. Any objections to
>>> that to start with?
>>
>> Why not put the recipes in meta-oe? I have need for e.g eds-dbus and would like to have that in meta-oe.
>
> Which pieces are we talking about? Does oe-core want sato? Should some
> of these go to meta-gnome and is that what we want? Or do we want all of
> sato there?
>
> I was under the impression sato might not be wanted but I'm open to
> influence either way on that. Certainly there are some pieces "we" as in
> Yocto put into recipe-sato that could arguably be positioned elsewhere.
>
> Are you also concerned about meta-demoapps or is that fine?

To me, sato should be however poky wants to deal with it.  But a lot of 
the deps are common gnome things and so forth that others care about too 
and we should try for meta-oe.  Again, to me, this is how we can 
reconcile the bits that poky has better than oe.dev (and vice versa) so 
both parties win.

-- 
Tom Rini
Mentor Graphics Corporation

Re: oe-core cleanup...

[Koen Kooi]

Op 3 mrt 2011, om 01:58 heeft Tom Rini het volgende geschreven:

> On 03/02/2011 12:18 PM, Richard Purdie wrote:
>> On Wed, 2011-03-02 at 19:27 +0100, Koen Kooi wrote:
>>> Op 2 mrt 2011, om 19:00 heeft Richard Purdie het volgende geschreven:
>>> 
>>>> Thanks for starting this thread Mark, I've also just been looking at
>>>> this question so its timely.
>>>> 
>>>> On Wed, 2011-03-02 at 11:30 -0600, Mark Hatle wrote:
>>>>> I finally got a chance to look at the oe-core and where it currently is..  Some
>>>>> suggestions below:
>>>>> 
>>>>> LICENSE file, this may need to be cleaned up to only cover the components
>>>>> actually in the oe-core.
>>>>> 
>>>>> README likely needs some revision
>>>>> 
>>>>> README.hardware needs a lot of revision.  Anything outside of support for QEMU
>>>>> should be removed.
>>>>> 
>>>>> The meta-demoapps and meta-rt components, will those be staying or going?
>>>>> 
>>>>> The meta/recipes.txt needs to be verified as still what we want -- I assume it
>>>>> is at this point..
>>>>> 
>>>>> meta/recipes-...  sato, qt, gnome, I thought were going elsewhere?
>>>>> 
>>>>> Do the items in the "scripts" need to be renamed or is Poky being kept in the
>>>>> naming?  Same with the poky-init-build-env?
>>>>> 
>>>>> Then I also assume the items in the documentation directory need to be cleaned
>>>>> up as well...
>>>>> 
>>>>> Let me know what you'd like me to try and tackle -- or if we need to bring these
>>>>> items up at the TSC for recommendation.
>>>> 
>>>> I'm proposing this change so far:
>>>> 
>>>> http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/roorg&id=891ad22536b49d4fee066a5865ad730f791d36e9
>>>> 
>>>> with those relocated files being removed from oe-core. Any objections to
>>>> that to start with?
>>> 
>>> Why not put the recipes in meta-oe? I have need for e.g eds-dbus and would like to have that in meta-oe.
>> 
>> Which pieces are we talking about? Does oe-core want sato? Should some
>> of these go to meta-gnome and is that what we want? Or do we want all of
>> sato there?
>> 
>> I was under the impression sato might not be wanted but I'm open to
>> influence either way on that. Certainly there are some pieces "we" as in
>> Yocto put into recipe-sato that could arguably be positioned elsewhere.
>> 
>> Are you also concerned about meta-demoapps or is that fine?
> 
> To me, sato should be however poky wants to deal with it.  But a lot of the deps are common gnome things and so forth that others care about too and we should try for meta-oe.  Again, to me, this is how we can reconcile the bits that poky has better than oe.dev (and vice versa) so both parties win.

I added sato to OE years ago, but didn't update it, so I argue since it's already in OE we should put it in meta-oe :)

regards,

Koen

Re: oe-core cleanup...

[Richard Purdie]

On Thu, 2011-03-03 at 09:02 +0100, Koen Kooi wrote:
> Op 3 mrt 2011, om 01:58 heeft Tom Rini het volgende geschreven:
> 
> > On 03/02/2011 12:18 PM, Richard Purdie wrote:
> >> On Wed, 2011-03-02 at 19:27 +0100, Koen Kooi wrote:
> >>> Op 2 mrt 2011, om 19:00 heeft Richard Purdie het volgende geschreven:
> >>> 
> >>>> Thanks for starting this thread Mark, I've also just been looking at
> >>>> this question so its timely.
> >>>> 
> >>>> On Wed, 2011-03-02 at 11:30 -0600, Mark Hatle wrote:
> >>>>> I finally got a chance to look at the oe-core and where it currently is..  Some
> >>>>> suggestions below:
> >>>>> 
> >>>>> LICENSE file, this may need to be cleaned up to only cover the components
> >>>>> actually in the oe-core.
> >>>>> 
> >>>>> README likely needs some revision
> >>>>> 
> >>>>> README.hardware needs a lot of revision.  Anything outside of support for QEMU
> >>>>> should be removed.
> >>>>> 
> >>>>> The meta-demoapps and meta-rt components, will those be staying or going?
> >>>>> 
> >>>>> The meta/recipes.txt needs to be verified as still what we want -- I assume it
> >>>>> is at this point..
> >>>>> 
> >>>>> meta/recipes-...  sato, qt, gnome, I thought were going elsewhere?
> >>>>> 
> >>>>> Do the items in the "scripts" need to be renamed or is Poky being kept in the
> >>>>> naming?  Same with the poky-init-build-env?
> >>>>> 
> >>>>> Then I also assume the items in the documentation directory need to be cleaned
> >>>>> up as well...
> >>>>> 
> >>>>> Let me know what you'd like me to try and tackle -- or if we need to bring these
> >>>>> items up at the TSC for recommendation.
> >>>> 
> >>>> I'm proposing this change so far:
> >>>> 
> >>>> http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/roorg&id=891ad22536b49d4fee066a5865ad730f791d36e9
> >>>> 
> >>>> with those relocated files being removed from oe-core. Any objections to
> >>>> that to start with?
> >>> 
> >>> Why not put the recipes in meta-oe? I have need for e.g eds-dbus and would like to have that in meta-oe.
> >> 
> >> Which pieces are we talking about? Does oe-core want sato? Should some
> >> of these go to meta-gnome and is that what we want? Or do we want all of
> >> sato there?
> >> 
> >> I was under the impression sato might not be wanted but I'm open to
> >> influence either way on that. Certainly there are some pieces "we" as in
> >> Yocto put into recipe-sato that could arguably be positioned elsewhere.
> >> 
> >> Are you also concerned about meta-demoapps or is that fine?
> > 
> > To me, sato should be however poky wants to deal with it.  But a lot
> > of the deps are common gnome things and so forth that others care 
> > about too and we should try for meta-oe.  Again, to me, this is how
> > we can reconcile the bits that poky has better than oe.dev (and vice
> > versa) so both parties win.
> 
> I added sato to OE years ago, but didn't update it, so I argue since
> it's already in OE we should put it in meta-oe :)

There is a very strong commitment to look after Sato from the Yocto
community so based on that, I'm ok with keeping it there.

I'm still not 100% convinced this is the right place for it but there is
no reason to rush to remove it either.

So I think we're agreed on the machine component of that commit above.
The distro component I think needs to go in, what about the other areas
I mentioned.

I'd really at least like the TSC members to comment on those different
pieces. I've already seen Chris comment that "poky-init-build-env"
shouldn't be in the core for example. What about the rest of the scripts
directory?

Cheers,

Richard

Re: oe-core cleanup...

[Mark Hatle]

On 3/3/11 6:10 AM, Richard Purdie wrote:
> I'd really at least like the TSC members to comment on those different
> pieces. I've already seen Chris comment that "poky-init-build-env"
> shouldn't be in the core for example. What about the rest of the scripts
> directory?

I think they should be in oe-core, and specifically labeled as self-contained
examples for oe-core itself.

There must be a simple way for people to setup the environment and run a build
so they can test the oe-core itself.  But there should be nothing in the system
that requires all of the components to exist, if there is, it should be clearly
documented that it's not an example component.  (Even putting the word "example"
in the name would be fine with me.  i.e. replacing "poky" with "example".)

--Mark

> Cheers,
> 
> Richard
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: oe-core cleanup...

[Tom Rini]

On 03/03/2011 07:43 AM, Mark Hatle wrote:
> On 3/3/11 6:10 AM, Richard Purdie wrote:
>> I'd really at least like the TSC members to comment on those different
>> pieces. I've already seen Chris comment that "poky-init-build-env"
>> shouldn't be in the core for example. What about the rest of the scripts
>> directory?
>
> I think they should be in oe-core, and specifically labeled as self-contained
> examples for oe-core itself.
>
> There must be a simple way for people to setup the environment and run a build
> so they can test the oe-core itself.  But there should be nothing in the system
> that requires all of the components to exist, if there is, it should be clearly
> documented that it's not an example component.  (Even putting the word "example"
> in the name would be fine with me.  i.e. replacing "poky" with "example".)

I agree.  I'd like to see us provide example scripts for running qemu, 
setting up the build env and so forth.  And I expect that distros will 
still provide their own version as they see fit.

-- 
Tom Rini
Mentor Graphics Corporation

Re: oe-core cleanup...

[Koen Kooi]

Op 2 mrt 2011, om 18:30 heeft Mark Hatle het volgende geschreven:

> I finally got a chance to look at the oe-core and where it currently is..  Some
> suggestions below:
> 
> LICENSE file, this may need to be cleaned up to only cover the components
> actually in the oe-core.
> 
> README likely needs some revision
> 
> README.hardware needs a lot of revision.  Anything outside of support for QEMU
> should be removed.

Agreed on the above

> The meta-demoapps

That has a lot of GNOME bits I need, so I would suggest meta-oe, a seperate gnome layer or the easiest way, keep it as a seperate layer, but outside of yocto. I think a GNOME (2) layer would make a lot of sense, but I don't know how many people will be looking after it.
With my beagleboard.org hat on, a full GNOME desktop is one of our deliverables to go on the SD card included with the board at the factory, so sorting out the duplication between the layers for GNOME components would be nice.

> and meta-rt components, will those be staying or going?

I don't have a real opinion on that.

> The meta/recipes.txt needs to be verified as still what we want -- I assume it
> is at this point..

It looks OK to me

> meta/recipes-...  sato, qt, gnome, I thought were going elsewhere?

See above for GNOME layer, QT is likely a similar case. Layers would also benefit from having their own git repository, but I can see the combinatorial explosion that could bring.

> Do the items in the "scripts" need to be renamed or is Poky being kept in the
> naming?  Same with the poky-init-build-env?

I would suggest renaming by doing s/poky/oecore/g for the build scripts.

> Then I also assume the items in the documentation directory need to be cleaned
> up as well...

It would be nice to use 'oe-core' or 'oecore' for everything related to building, instead of 'poky', since poky is a distro, not a buildsystem (anymore).

regards,

Koen

Re: oe-core cleanup...

[Joshua Lock]

On Thu, 2011-03-03 at 13:46 +0100, Koen Kooi wrote:
> Op 2 mrt 2011, om 18:30 heeft Mark Hatle het volgende geschreven:
> 
> > I finally got a chance to look at the oe-core and where it currently is..  Some
> > suggestions below:
> > 
> > LICENSE file, this may need to be cleaned up to only cover the components
> > actually in the oe-core.
> > 
> > README likely needs some revision
> > 
> > README.hardware needs a lot of revision.  Anything outside of support for QEMU
> > should be removed.
> 
> Agreed on the above
> 
> > The meta-demoapps
> 
> That has a lot of GNOME bits I need, so I would suggest meta-oe, a seperate gnome layer or the easiest way, keep it as a seperate layer, but outside of yocto. I think a GNOME (2) layer would make a lot of sense, but I don't know how many people will be looking after it.
> With my beagleboard.org hat on, a full GNOME desktop is one of our deliverables to go on the SD card included with the board at the factory, so sorting out the duplication between the layers for GNOME components would be nice.

I'd be inclined to suggest the separate GNOME layer, though see below
for some further thoughts.

> 
> > and meta-rt components, will those be staying or going?
> 
> I don't have a real opinion on that.
> 
> > The meta/recipes.txt needs to be verified as still what we want -- I assume it
> > is at this point..
> 
> It looks OK to me
> 
> > meta/recipes-...  sato, qt, gnome, I thought were going elsewhere?
> 
> See above for GNOME layer, QT is likely a similar case. Layers would also benefit from having their own git repository, but I can see the combinatorial explosion that could bring.

I agree with this in principle, but before we dive into this we need to
decide where we draw the line. GNOME and Qt are not comparable. GNOME
and KDE are, Gtk+ and Qt are.

Where should Gtk+ and Qt live? E.g: if Gtk+ lives in meta-gnome does
that mean someone creating a meta-xfce needs to either a) provide their
own (copy of the) Gtk+ recipe OR b) depend on the meta-gnome's presence.

I'll accept "We'll cross that bridge when we come to it" as an answer
but I at least feel it's worth pointing this out.

Cheers,
Joshua
-- 
Joshua Lock
        Intel Open Source Technology Centre

Re: oe-core cleanup...

[Koen Kooi]

Op 3 mrt 2011, om 14:09 heeft Joshua Lock het volgende geschreven:

> On Thu, 2011-03-03 at 13:46 +0100, Koen Kooi wrote:
>> Op 2 mrt 2011, om 18:30 heeft Mark Hatle het volgende geschreven:
>> 
>>> I finally got a chance to look at the oe-core and where it currently is..  Some
>>> suggestions below:
>>> 
>>> LICENSE file, this may need to be cleaned up to only cover the components
>>> actually in the oe-core.
>>> 
>>> README likely needs some revision
>>> 
>>> README.hardware needs a lot of revision.  Anything outside of support for QEMU
>>> should be removed.
>> 
>> Agreed on the above
>> 
>>> The meta-demoapps
>> 
>> That has a lot of GNOME bits I need, so I would suggest meta-oe, a seperate gnome layer or the easiest way, keep it as a seperate layer, but outside of yocto. I think a GNOME (2) layer would make a lot of sense, but I don't know how many people will be looking after it.
>> With my beagleboard.org hat on, a full GNOME desktop is one of our deliverables to go on the SD card included with the board at the factory, so sorting out the duplication between the layers for GNOME components would be nice.
> 
> I'd be inclined to suggest the separate GNOME layer, though see below
> for some further thoughts.
> 
>> 
>>> and meta-rt components, will those be staying or going?
>> 
>> I don't have a real opinion on that.
>> 
>>> The meta/recipes.txt needs to be verified as still what we want -- I assume it
>>> is at this point..
>> 
>> It looks OK to me
>> 
>>> meta/recipes-...  sato, qt, gnome, I thought were going elsewhere?
>> 
>> See above for GNOME layer, QT is likely a similar case. Layers would also benefit from having their own git repository, but I can see the combinatorial explosion that could bring.
> 
> I agree with this in principle, but before we dive into this we need to
> decide where we draw the line. GNOME and Qt are not comparable. GNOME
> and KDE are, Gtk+ and Qt are.

You completely right on that!

> Where should Gtk+ and Qt live? E.g: if Gtk+ lives in meta-gnome does
> that mean someone creating a meta-xfce needs to either a) provide their
> own (copy of the) Gtk+ recipe OR b) depend on the meta-gnome's presence.
> 
> I'll accept "We'll cross that bridge when we come to it" as an answer
> but I at least feel it's worth pointing this out.

I thought about that as well, but gtk+ is in core, as is glib-2.0 which both gtk+ and QT use. There shouldn't be any other overlay between xfce and gnome. If 2 layers really don't get along we can consider the following:

1) put the overlap in oe-core
2) put the overlap in meta-oe
3) put the overlap in yet another layer
4) duplicate

All these show that we need more and better tools to deal with layers. At the minimum bitbake should print out warnings about layer issues like bbappend a recipe that doesn't exist.

regards,

Koen

Re: oe-core cleanup...

[Joshua Lock]

[-- Attachment #1: Type: text/plain, Size: 3554 bytes --]

On Thu, 2011-03-03 at 14:57 +0100, Koen Kooi wrote:
> Op 3 mrt 2011, om 14:09 heeft Joshua Lock het volgende geschreven:
> 
> > On Thu, 2011-03-03 at 13:46 +0100, Koen Kooi wrote:
> >> Op 2 mrt 2011, om 18:30 heeft Mark Hatle het volgende geschreven:
> >> 
> >>> I finally got a chance to look at the oe-core and where it currently is..  Some
> >>> suggestions below:
> >>> 
> >>> LICENSE file, this may need to be cleaned up to only cover the components
> >>> actually in the oe-core.
> >>> 
> >>> README likely needs some revision
> >>> 
> >>> README.hardware needs a lot of revision.  Anything outside of support for QEMU
> >>> should be removed.
> >> 
> >> Agreed on the above
> >> 
> >>> The meta-demoapps
> >> 
> >> That has a lot of GNOME bits I need, so I would suggest meta-oe, a seperate gnome layer or the easiest way, keep it as a seperate layer, but outside of yocto. I think a GNOME (2) layer would make a lot of sense, but I don't know how many people will be looking after it.
> >> With my beagleboard.org hat on, a full GNOME desktop is one of our deliverables to go on the SD card included with the board at the factory, so sorting out the duplication between the layers for GNOME components would be nice.
> > 
> > I'd be inclined to suggest the separate GNOME layer, though see below
> > for some further thoughts.
> > 
> >> 
> >>> and meta-rt components, will those be staying or going?
> >> 
> >> I don't have a real opinion on that.
> >> 
> >>> The meta/recipes.txt needs to be verified as still what we want -- I assume it
> >>> is at this point..
> >> 
> >> It looks OK to me
> >> 
> >>> meta/recipes-...  sato, qt, gnome, I thought were going elsewhere?
> >> 
> >> See above for GNOME layer, QT is likely a similar case. Layers would also benefit from having their own git repository, but I can see the combinatorial explosion that could bring.
> > 
> > I agree with this in principle, but before we dive into this we need to
> > decide where we draw the line. GNOME and Qt are not comparable. GNOME
> > and KDE are, Gtk+ and Qt are.
> 
> You completely right on that!
> 
> > Where should Gtk+ and Qt live? E.g: if Gtk+ lives in meta-gnome does
> > that mean someone creating a meta-xfce needs to either a) provide their
> > own (copy of the) Gtk+ recipe OR b) depend on the meta-gnome's presence.
> > 
> > I'll accept "We'll cross that bridge when we come to it" as an answer
> > but I at least feel it's worth pointing this out.
> 
> I thought about that as well, but gtk+ is in core, as is glib-2.0 which both gtk+ and QT use. There shouldn't be any other overlay between xfce and gnome. If 2 layers really don't get along we can consider the following:

Whoops, I'd missed that Gtk+ was in core... I guess this is a non-issue
atm then.

> 
> 1) put the overlap in oe-core
> 2) put the overlap in meta-oe
> 3) put the overlap in yet another layer
> 4) duplicate
> 
> All these show that we need more and better tools to deal with layers. At the minimum bitbake should print out warnings about layer issues like bbappend a recipe that doesn't exist.

I agree, in fact yesterday I discovered we have the beginnings of such a
tool (bitbake-layers) written by Chris. Currently it prints out which
recipes are being modified by a .bbappend and .bbappend files for which
no recipe exists.

I had to write a trivial patch (attached) to make it work but it's a
good start. :-)

Cheers,
Joshua
-- 
Joshua Lock
        Intel Open Source Technology Centre

[-- Attachment #2: bitbake-layers.patch --]
[-- Type: text/x-patch, Size: 1998 bytes --]

From eca003ed03f4fab28d8526d916586534636696a5 Mon Sep 17 00:00:00 2001
From: Joshua Lock <josh@linux.intel.com>
Date: Wed, 2 Mar 2011 17:59:38 +0000
Subject: [PATCH 2/2] bitbake/bitbake-layers: fix to run with recent changes

This patch marks the bitbake-layers script as executable and fixes the
instantiation of the BBCooker to match recent changes in the BitBake
libraries.

I've also added a brief header which demonstrates the intent and usage
as taken from Chris Larson's original commit message.

Signed-off-by: Joshua Lock <josh@linux.intel.com>
---
 bitbake/bin/bitbake-layers |   11 +++++++++--
 1 files changed, 9 insertions(+), 2 deletions(-)
 mode change 100644 => 100755 bitbake/bin/bitbake-layers

diff --git a/bitbake/bin/bitbake-layers b/bitbake/bin/bitbake-layers
old mode 100644
new mode 100755
index ed11e5a..03bda13
--- a/bitbake/bin/bitbake-layers
+++ b/bitbake/bin/bitbake-layers
@@ -1,4 +1,10 @@
-#!/usr/bin/env python2.6
+#!/usr/bin/env python2
+
+# This script has subcommands which operate against your bitbake layers, either
+# displaying useful information, or acting against them.
+# Currently, it only provides a show_appends command, which shows you what
+# bbappends are in effect, and warns you if you have appends which are not being
+# utilized.
 
 import cmd
 import logging
@@ -13,6 +19,7 @@ import bb.cache
 import bb.cooker
 import bb.providers
 from bb.cooker import state
+from bb.server import none
 
 
 logger = logging.getLogger('BitBake')
@@ -38,7 +45,7 @@ class Commands(cmd.Cmd):
         self.returncode = 0
         self.config = Config(parse_only=True)
         self.cooker = bb.cooker.BBCooker(self.config,
-                                         self.register_idle_function)
+                                         bb.server.none)
         self.config_data = self.cooker.configuration.data
         bb.providers.logger.setLevel(logging.ERROR)
         self.prepare_cooker()
-- 
1.7.4

Re: oe-core cleanup...

[Chris Larson]

On Thu, Mar 3, 2011 at 7:05 AM, Joshua Lock <josh@linux.intel.com> wrote:
> I agree, in fact yesterday I discovered we have the beginnings of such a
> tool (bitbake-layers) written by Chris. Currently it prints out which
> recipes are being modified by a .bbappend and .bbappend files for which
> no recipe exists.
>
> I had to write a trivial patch (attached) to make it work but it's a
> good start. :-)

Note that "fixes the instantiation of the BBCooker to match recent
changes in the BitBake libraries." is not correct.  It's not a recent
change, it's a poky vs upstream difference at the moment, due to the
switch to the Process based server.  The change in that patch will
make it work with poky, which is good, but not with master.

This is the last somewhat large piece of the bitbake sync, as far as I
know -- we need to decide how best to resurrect the XML/RPC server in
master, but we haven't yet determined how the user should select their
server.  For the average user, they just want to run a UI, the server
is implementation details, so I'd argue that we let the UI instantiate
the server it needs, create a UI that spawns an xml/rpc server and
displays the connection info to stdout, and add an env var to let the
other UIs connect to a nondefault server, but there are other
possibilities that need to be considered.  In poky, you have to
comment/uncomment lines in bin/bitbake, which is .. not ideal :)

Do let me know if you come up with any good ideas for additional
commands for the bitbake-layers tool -- I'm sure there are plenty of
useful things we can add to assist in layer maintenance.  Thanks!
I'll apply the #! change to upstream right away.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics

Re: oe-core cleanup...

[Chris Larson]

On Thu, Mar 3, 2011 at 7:14 AM, Chris Larson <clarson@kergoth.com> wrote:
> On Thu, Mar 3, 2011 at 7:05 AM, Joshua Lock <josh@linux.intel.com> wrote:
>> I agree, in fact yesterday I discovered we have the beginnings of such a
>> tool (bitbake-layers) written by Chris. Currently it prints out which
>> recipes are being modified by a .bbappend and .bbappend files for which
>> no recipe exists.

Note that it also warns about bbappending to a non-preferred version
of a recipe, but not bbappending to the preferred version of the
recipe, to cover the case where a bump of an earlier layer adds a new
version without removing the old.  I was trying to catch all the cases
where your local changes might seem "lost" when updating things.

On another note, I was really surprised at just how painless it was to
create a new standalone tool to do this, considering it bypasses much
of the infrastructure which the main bitbake tool uses.  There are
definitely still some hiccups in bitbake we should fix to make it
easier, but it wasn't bad at all, which was great to see, and we'll
have to think about what other standalone tools might be useful in the
long term.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics

Re: oe-core cleanup...

[Joshua Lock]

On Thu, 2011-03-03 at 07:21 -0700, Chris Larson wrote:
On Thu, Mar 3, 2011 at 7:14 AM, Chris Larson <clarson@kergoth.com>
wrote:
> > On Thu, Mar 3, 2011 at 7:05 AM, Joshua Lock <josh@linux.intel.com>
wrote:
> >> I agree, in fact yesterday I discovered we have the beginnings of
such a
> >> tool (bitbake-layers) written by Chris. Currently it prints out
which
> >> recipes are being modified by a .bbappend and .bbappend files for
which
> >> no recipe exists.
> 
> Note that it also warns about bbappending to a non-preferred version
> of a recipe, but not bbappending to the preferred version of the
> recipe, to cover the case where a bump of an earlier layer adds a new
> version without removing the old.  I was trying to catch all the cases
> where your local changes might seem "lost" when updating things.

Ah, that's a nice feature that I'd missed (I don't have any such recipes
in the layers I'm using).

> On another note, I was really surprised at just how painless it was to
> create a new standalone tool to do this, considering it bypasses much
> of the infrastructure which the main bitbake tool uses.  There are
> definitely still some hiccups in bitbake we should fix to make it
> easier, but it wasn't bad at all, which was great to see, and we'll
> have to think about what other standalone tools might be useful in the
> long term.
>
Yes indeed. I was pleased when I discovered bitbake-layers and even more
pleased when I saw how concise a program it is.

I'd love to see a wiki-page or some such where we can collaborate on
tools ideas. I'm slowly understanding more and more of BitBake and
gaining an increased appreciation of Python so little hack project ideas
would be welcome.

Cheers,
Joshua
-- 
Joshua Lock
        Yocto Build System Monkey
        Intel Open Source Technology Centre

Re: oe-core cleanup...

[Joshua Lock]

My last reply went straight to Chris rather than the list so re-sending,
sorry Chris.

Is it intended that the list doesn't reply to list by default?

On Thu, 2011-03-03 at 07:14 -0700, Chris Larson wrote:
> On Thu, Mar 3, 2011 at 7:05 AM, Joshua Lock <josh@linux.intel.com>
wrote:
> > I agree, in fact yesterday I discovered we have the beginnings of
such a
> > tool (bitbake-layers) written by Chris. Currently it prints out
which
> > recipes are being modified by a .bbappend and .bbappend files for
which
> > no recipe exists.
> >
> > I had to write a trivial patch (attached) to make it work but it's a
> > good start. :-)
> 
> Note that "fixes the instantiation of the BBCooker to match recent
> changes in the BitBake libraries." is not correct.  It's not a recent
> change, it's a poky vs upstream difference at the moment, due to the
> switch to the Process based server.  The change in that patch will
> make it work with poky, which is good, but not with master.

Fair enough, Poky is (currently) the environment in which I do most of
my BitBake hacking but I appreciate you pointing this out.

I was just about to reply pointing out that the patch is against Poky
rather than upstream.

> 
> This is the last somewhat large piece of the bitbake sync, as far as I
> know -- we need to decide how best to resurrect the XML/RPC server in
> master, but we haven't yet determined how the user should select their
> server.  For the average user, they just want to run a UI, the server
> is implementation details, so I'd argue that we let the UI instantiate
> the server it needs, create a UI that spawns an xml/rpc server and
> displays the connection info to stdout, and add an env var to let the
> other UIs connect to a nondefault server, but there are other
> possibilities that need to be considered.  In poky, you have to
> comment/uncomment lines in bin/bitbake, which is .. not ideal :)

I agree with what you're saying here and I'm thinking along similar
lines wrt having the UI be able to select the desired server but was
also thinking of having a command line switch to choose which server you
want to use. I've kept quiet about this so far as I don't yet have any
patches. ;-)

I like the idea of an env var to use a non-default server.

> 
> Do let me know if you come up with any good ideas for additional
> commands for the bitbake-layers tool -- I'm sure there are plenty of
> useful things we can add to assist in layer maintenance.  Thanks!
> I'll apply the #! change to upstream right away.

Great, thanks very much. I've not had any good ideas yet but you can be
sure you'll see patches if/when I do.

Cheers,
Joshua
-- 
Joshua Lock
        Yocto Build System Monkey
        Intel Open Source Technology Centre

Re: oe-core cleanup...

[Chris Larson]

On Thu, Mar 3, 2011 at 6:57 AM, Koen Kooi <koen@dominion.thruhere.net> wrote:
> All these show that we need more and better tools to deal with layers. At the minimum bitbake should print out warnings about layer issues like bbappend a recipe that doesn't exist.
>

Agreed.  This particular case is why bitbake-layers exists.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics