oe-core cleanup...
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
Thanks for starting this thread Mark, I've also just been looking at this question so its timely.
Quoted 18 lines · 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.txtneeds 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?
Quoted 8 lines
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:
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
Op 2 mrt 2011, om 19:00 heeft Richard Purdie het volgende geschreven:
Quoted 31 lines
Thanks for starting this thread Mark, I've also just been looking at this question so its timely.
Quoted 18 lines · 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.txtneeds 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?
Quoted 8 lines
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.
Quoted 6 lines
I'm proposing this change so far:
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
Quoted 34 lines · Koen Kooi
Op 2 mrt 2011, om 19:00 heeft Richard Purdie het volgende geschreven:
Quoted 31 lines
Thanks for starting this thread Mark, I've also just been looking at this question so its timely.
Quoted 26 lines · 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.txtneeds 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.
Quoted 8 lines
Quoted 6 lines
I'm proposing this change so far:
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
Quoted 7 lines
regards,
Koen
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Quoted 33 lines · Koen Kooi
Op 2 mrt 2011, om 19:00 heeft Richard Purdie het volgende geschreven:
Quoted 31 lines
Thanks for starting this thread Mark, I've also just been looking at this question so its timely.
Quoted 26 lines · 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.txtneeds 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.
Quoted 8 lines
Quoted 6 lines
I'm proposing this change so far:
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
Quoted 47 lines · Richard Purdie
Quoted 33 lines · Koen Kooi
Op 2 mrt 2011, om 19:00 heeft Richard Purdie het volgende geschreven:
Quoted 31 lines
Thanks for starting this thread Mark, I've also just been looking at this question so its timely.
Quoted 26 lines · 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.txtneeds 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.
Quoted 8 lines
Quoted 6 lines
I'm proposing this change so far:
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?
Quoted 5 lines
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.
Signature · 2 lines
Tom Rini Mentor Graphics Corporation
Op 3 mrt 2011, om 01:58 heeft Tom Rini het volgende geschreven:
Quoted 48 lines · Richard Purdie
Quoted 47 lines · Koen Kooi
Quoted 33 lines
Op 2 mrt 2011, om 19:00 heeft Richard Purdie het volgende geschreven:
Quoted 31 lines
Thanks for starting this thread Mark, I've also just been looking at this question so its timely.
Quoted 26 lines · 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.txtneeds 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.
Quoted 8 lines
Quoted 6 lines
I'm proposing this change so far:
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?
Quoted 7 lines
Quoted 5 lines
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
Quoted 56 lines · Koen Kooi
Op 3 mrt 2011, om 01:58 heeft Tom Rini het volgende geschreven:
Quoted 54 lines · Richard Purdie
Quoted 52 lines · Koen Kooi
Quoted 33 lines
Op 2 mrt 2011, om 19:00 heeft Richard Purdie het volgende geschreven:
Quoted 31 lines
Thanks for starting this thread Mark, I've also just been looking at this question so its timely.
Quoted 26 lines · 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.txtneeds 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.
Quoted 8 lines
Quoted 6 lines
I'm proposing this change so far:
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?
Quoted 8 lines
Quoted 5 lines
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
Quoted 4 lines · Richard Purdie
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
Quoted 9 lines
Cheers,
Richard
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Quoted 6 lines · Mark Hatle
Quoted 4 lines · Richard Purdie
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?
Quoted 8 lines
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.
Signature · 2 lines
Tom Rini Mentor Graphics Corporation
Op 2 mrt 2011, om 18:30 heeft Mark Hatle het volgende geschreven:
Quoted 10 lines
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
Quoted 1 line
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.
Quoted 1 line
and meta-rt components, will those be staying or going?
I don't have a real opinion on that.
Quoted 2 lines
The
meta/recipes.txtneeds to be verified as still what we want -- I assume it is at this point..
It looks OK to me
Quoted 1 line
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.
Quoted 2 lines
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.
Quoted 2 lines
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
Quoted 13 lines · Koen Kooi
Op 2 mrt 2011, om 18:30 heeft Mark Hatle het volgende geschreven:
Quoted 10 lines
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.
Quoted 6 lines
Agreed on the above
Quoted 1 line
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.
Quoted 5 lines
Quoted 2 lines
and meta-rt components, will those be staying or going?
I don't have a real opinion on that.
Quoted 8 lines
Quoted 2 lines
The
meta/recipes.txtneeds to be verified as still what we want -- I assume it is at this point..It looks OK to me
Quoted 1 line
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
Signature · 2 lines
Joshua Lock
Intel Open Source Technology CentreOp 3 mrt 2011, om 14:09 heeft Joshua Lock het volgende geschreven:
Quoted 34 lines · Koen Kooi
Quoted 13 lines
Op 2 mrt 2011, om 18:30 heeft Mark Hatle het volgende geschreven:
Quoted 10 lines
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.
Quoted 6 lines
Agreed on the above
Quoted 1 line
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.
Quoted 10 lines
Quoted 2 lines
and meta-rt components, will those be staying or going?
I don't have a real opinion on that.
Quoted 2 lines
The
meta/recipes.txtneeds to be verified as still what we want -- I assume it is at this point..It looks OK to me
Quoted 7 lines
Quoted 3 lines
Quoted 1 line
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!
Quoted 6 lines
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
Quoted 46 lines · Koen Kooi
Op 3 mrt 2011, om 14:09 heeft Joshua Lock het volgende geschreven:
Quoted 34 lines · Koen Kooi
Quoted 13 lines
Op 2 mrt 2011, om 18:30 heeft Mark Hatle het volgende geschreven:
Quoted 10 lines
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.
Quoted 6 lines
Agreed on the above
Quoted 1 line
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.
Quoted 10 lines
Quoted 2 lines
and meta-rt components, will those be staying or going?
I don't have a real opinion on that.
Quoted 2 lines
The
meta/recipes.txtneeds to be verified as still what we want -- I assume it is at this point..It looks OK to me
Quoted 7 lines
Quoted 3 lines
Quoted 1 line
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!
Quoted 8 lines
Quoted 6 lines
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.
Quoted 7 lines
1) put the overlap in oe-core
2) put the overlap in meta-oe
3) put the overlap in yet another layer
4) duplicateAll 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
Signature · 2 lines
Joshua Lock
Intel Open Source Technology CentreFrom eca003ed03f4fab28d8526d916586534636696a5 Mon Sep 17 00:00:00 2001
From: Joshua Lock <[email protected]>
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.
--- bitbake/bin/bitbake-layers | 11 +++++++++-- 1 files changed, 9 insertions(+), 2 deletions(-) mode change 100644 => 100755 bitbake/bin/bitbake-layers
bitbake/bin/bitbake-layers +9 -2
@@ -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()
Signature · 1 line
1.7.4
Quoted 7 lines · Joshua Lock
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.
Signature · 5 lines
Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics
Quoted 5 lines · Chris Larson
Quoted 4 lines · Joshua Lock
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.
Signature · 5 lines
Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics
On Thu, 2011-03-03 at 07:21 -0700, Chris Larson wrote:
Quoted 1 line · Chris Larson
Quoted 1 line
On Thu, Mar 3, 2011 at 7:05 AM, Joshua Lock <[email protected]>
Quoted 1 line · wrote:
Quoted 1 line
Quoted 1 line
I agree, in fact yesterday I discovered we have the beginnings of
such a
Quoted 1 line
Quoted 1 line
Quoted 1 line
tool (bitbake-layers) written by Chris. Currently it prints out
which
Quoted 1 line
Quoted 1 line
Quoted 1 line
recipes are being modified by a .bbappend and .bbappend files for
which
Quoted 7 lines
Quoted 1 line
Quoted 1 line
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).
Quoted 8 lines
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
Signature · 3 lines
Joshua Lock
Yocto Build System Monkey
Intel Open Source Technology CentreMy 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?
Quoted 1 line · Chris Larson
On Thu, Mar 3, 2011 at 7:05 AM, Joshua Lock <[email protected]>
Quoted 1 line · wrote:
Quoted 1 line
I agree, in fact yesterday I discovered we have the beginnings of
such a
Quoted 1 line
Quoted 1 line
tool (bitbake-layers) written by Chris. Currently it prints out
which
Quoted 1 line
Quoted 1 line
recipes are being modified by a .bbappend and .bbappend files for
which
Quoted 10 lines
Quoted 4 lines
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.
Quoted 11 lines
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.
Quoted 5 lines
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
Signature · 3 lines
Joshua Lock
Yocto Build System Monkey
Intel Open Source Technology CentreQuoted 2 lines · Koen Kooi
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.
Signature · 5 lines
Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics