Layer Tooling - Revision history

PaulEggleton: I have implemented the layer flattening stuff now

2011-06-30T15:46:34Z

I have implemented the layer flattening stuff now

← Older revision		Revision as of 15:46, 30 June 2011
Line 17:		Line 17:
	* Consider integrating Jeremy Puhlman's remote layers patch (see comments below) [Paul]		* Consider integrating Jeremy Puhlman's remote layers patch (see comments below) [Paul]
	* Tool to manage combination repos (e.g. the poky repo) - see below [Paul/Ke]		* Tool to manage combination repos (e.g. the poky repo) - see below [Paul/Ke]
	* Tool to merge (flatten) several layers into one [Paul~~/Dexuan~~]		* Tool to merge (flatten) several layers into one [Paul]
	** Take current layer config and apply all .bbappend / remove overridden .bb files and output to a separate directory		** Take current layer config and apply all .bbappend / remove overridden .bb files and output to a separate directory

PaulEggleton at 09:34, 13 June 2011

2011-06-13T09:34:56Z

← Older revision		Revision as of 09:34, 13 June 2011
Line 7:		Line 7:
	* Show a parse error if a bbappend matches no existing bb [Dexuan]		* Show a parse error if a bbappend matches no existing bb [Dexuan]
	* bitbake-layers: stop it displaying the warning message about not being run from the wrapper [Dexuan]		* bitbake-layers: stop it displaying the warning message about not being run from the wrapper [Dexuan]
	* bitbake-layers: extend it to show ~~overridden ("cloaked")~~ recipes [~~Dexuan?~~]		* bitbake-layers: extend it to show overlayed recipes [Paul]
	* Update banner info to show layers being used and revisions/branches for each one if available [Dexuan]		* Update banner info to show layers being used and revisions/branches for each one if available [Dexuan]
	* Dependency handling [Paul]		* Dependency handling [Paul]
Line 15:		Line 15:
	*** Layer dependencies (as a list of layer names + versions)		*** Layer dependencies (as a list of layer names + versions)
	** Add dependency/version check		** Add dependency/version check
	* Consider integrating Jeremy Puhlman's remote layers patch (see comments below) [Ke]		* Consider integrating Jeremy Puhlman's remote layers patch (see comments below) [Paul]
	* Tool to manage combination repos (e.g. the poky repo) - see below [Paul/Ke]		* Tool to manage combination repos (e.g. the poky repo) - see below [Paul/Ke]
	* Tool to merge (flatten) several layers into one [Paul/Dexuan]		* Tool to merge (flatten) several layers into one [Paul/Dexuan]

PaulEggleton: Break out combination repo task out to separate section with detail

2011-05-20T16:53:35Z

Break out combination repo task out to separate section with detail

@@ Line 13: / Line 13: @@
 *** Layer name
 *** Layer version
-*** Layer dependencies (as a list of layer names + minimum versions only)
+*** Layer dependencies (as a list of layer names + versions)
-** Add dependency/version check to sanity.bbclass
+** Add dependency/version check
 * Consider integrating Jeremy Puhlman's remote layers patch (see comments below) [Ke]
-* Tool which merges multiple layer components in one repo (e.g. the poky repo situation) [Paul/Ke]
+* Tool to manage combination repos (e.g. the poky repo) - see below [Paul/Ke]
 * Tool to merge (flatten) several layers into one [Paul/Dexuan]
 ** Take current layer config and apply all .bbappend / remove overridden .bb files and output to a separate directory
 === Future tasks ===
@@ Line 88: / Line 110: @@
 Richard says:
 http://lists.linuxtogo.org/pipermail/openembedded-core/2011-May/001940.html

Jpuhlman: /* Jeremy Puhlman */

2011-05-17T16:57:37Z

Jeremy Puhlman

← Older revision		Revision as of 16:57, 17 May 2011
Line 77:		Line 77:

	Paul says: a good start but naturally we want to avoid the bits that hard-code variable values. I wonder about situations where people want their own versions of layers or to share remote layers (e.g. between an oe-core setup and a poky setup); however people can just use local layers for this.		Paul says: a good start but naturally we want to avoid the bits that hard-code variable values. I wonder about situations where people want their own versions of layers or to share remote layers (e.g. between an oe-core setup and a poky setup); however people can just use local layers for this.

			Jeremy says: In reality they are setting "reasonable" defaults. Hardcoding implies something that is unchangeable. All the values are "set if unset", so they can be changed in the bblayers.conf
			file. Prior to the introduction of layers, all the values were hardcoded, just in a bitbake.conf file, so you always had working fetchers. With out that the fetchers are basically broken until
			after you have loaded up the layers. Given the fact that nearly every bitbake.conf file contains the same settings for defining fetchcmd and a like, simply having a reasonable default setting for
			the things the fetchers need is not really that terrible an idea irrespective of the remote layering.

			As for the second question. I have some content tools that I am cleaning up that basically provide methods for defining layers and groups of layers together for mirroring and sharing. That might
			address what your talking about there. They work along with the patch posted here, but could be modified to output things a bit differently if needed.

	Richard says:		Richard says:
	http://lists.linuxtogo.org/pipermail/openembedded-core/2011-May/001940.html		http://lists.linuxtogo.org/pipermail/openembedded-core/2011-May/001940.html

PaulEggleton: Assign remaining unassigned 1.1 tasks as discussed at meeting

2011-05-12T09:43:16Z

Assign remaining unassigned 1.1 tasks as discussed at meeting

← Older revision		Revision as of 09:43, 12 May 2011
Line 16:		Line 16:
	** Add dependency/version check to sanity.bbclass		** Add dependency/version check to sanity.bbclass
	* Consider integrating Jeremy Puhlman's remote layers patch (see comments below) [Ke]		* Consider integrating Jeremy Puhlman's remote layers patch (see comments below) [Ke]
	* Tool which merges multiple layer components in one repo (e.g. the poky repo situation) [~~unassigned~~]		* Tool which merges multiple layer components in one repo (e.g. the poky repo situation) [Paul/Ke]
	** Definition file that indicates what components come from where (git remote URI as well as subdirectory of that repo, and perhaps an optional pegged branch/rev?)		** Definition file that indicates what components come from where (git remote URI as well as subdirectory of that repo, and perhaps an optional pegged branch/rev?)
	** For non-pegged components, may need to actually record latest revision integrated from the component?		** For non-pegged components, may need to actually record latest revision integrated from the component?
Line 22:		Line 22:
	** Enable splitting of a patch into separate parts for different components (use splitdiff for this?)		** Enable splitting of a patch into separate parts for different components (use splitdiff for this?)
	** Could be initially created with git-stitch-repo? (Depends on whether you want the history)		** Could be initially created with git-stitch-repo? (Depends on whether you want the history)
	* Tool to merge (flatten) several layers into one [~~unassigned~~]		* Tool to merge (flatten) several layers into one [Paul/Dexuan]
	** Take current layer config and apply all .bbappend / remove overridden .bb files and output to a separate directory		** Take current layer config and apply all .bbappend / remove overridden .bb files and output to a separate directory

PaulEggleton: /* 1.1 tasks */ Minor correction above->below

2011-05-11T09:49:55Z

1.1 tasks: Minor correction above->below

← Older revision		Revision as of 09:49, 11 May 2011
Line 15:		Line 15:
	*** Layer dependencies (as a list of layer names + minimum versions only)		*** Layer dependencies (as a list of layer names + minimum versions only)
	** Add dependency/version check to sanity.bbclass		** Add dependency/version check to sanity.bbclass
	* Consider integrating Jeremy Puhlman's remote layers patch (see comments ~~above~~) [Ke]		* Consider integrating Jeremy Puhlman's remote layers patch (see comments below) [Ke]
	* Tool which merges multiple layer components in one repo (e.g. the poky repo situation) [unassigned]		* Tool which merges multiple layer components in one repo (e.g. the poky repo situation) [unassigned]
	** Definition file that indicates what components come from where (git remote URI as well as subdirectory of that repo, and perhaps an optional pegged branch/rev?)		** Definition file that indicates what components come from where (git remote URI as well as subdirectory of that repo, and perhaps an optional pegged branch/rev?)

PaulEggleton: Fix headings in task sections

2011-05-10T17:42:58Z

Fix headings in task sections

← Older revision		Revision as of 17:42, 10 May 2011
Line 3:		Line 3:
	Extracted from the brainstorming info below.		Extracted from the brainstorming info below.

	== 1.1 tasks ==		=== 1.1 tasks ===

	* Show a parse error if a bbappend matches no existing bb [Dexuan]		* Show a parse error if a bbappend matches no existing bb [Dexuan]
Line 25:		Line 25:
	** Take current layer config and apply all .bbappend / remove overridden .bb files and output to a separate directory		** Take current layer config and apply all .bbappend / remove overridden .bb files and output to a separate directory

	== Future tasks ==		=== Future tasks ===

	Nice to have - may be added in 1.1 time allowing but not mandatory:		Nice to have - may be added in 1.1 time allowing but not mandatory:

PaulEggleton: Clarify bitbake-layers item, add min versions to layer deps list

2011-05-10T17:25:57Z

Clarify bitbake-layers item, add min versions to layer deps list

← Older revision		Revision as of 17:25, 10 May 2011
Line 7:		Line 7:
	* Show a parse error if a bbappend matches no existing bb [Dexuan]		* Show a parse error if a bbappend matches no existing bb [Dexuan]
	* bitbake-layers: stop it displaying the warning message about not being run from the wrapper [Dexuan]		* bitbake-layers: stop it displaying the warning message about not being run from the wrapper [Dexuan]
	* bitbake-layers: extend it to show ~~all overrides~~ (~~needs more detail~~) [Dexuan?]		* bitbake-layers: extend it to show overridden ("cloaked") recipes [Dexuan?]
	* Update banner info to show layers being used and revisions/branches for each one if available [Dexuan]		* Update banner info to show layers being used and revisions/branches for each one if available [Dexuan]
	* Dependency handling [Paul]		* Dependency handling [Paul]
Line 13:		Line 13:
	*** Layer name		*** Layer name
	*** Layer version		*** Layer version
	*** Layer dependencies (as a list of layer names only)		*** Layer dependencies (as a list of layer names + minimum versions only)
	** Add dependency/version check to sanity.bbclass		** Add dependency/version check to sanity.bbclass
	* Consider integrating Jeremy Puhlman's remote layers patch (see comments above) [Ke]		* Consider integrating Jeremy Puhlman's remote layers patch (see comments above) [Ke]
Line 65:		Line 65:
	=== Paul Eggleton / Chris Larson ===		=== Paul Eggleton / Chris Larson ===

	* Show easily which recipes are being used and which are overridden. We have bitbake-layers, but this clearly needs some extension. I think long term we would want to be able to analyse overrides ~~accross~~ a set of layers to figure out where common stuff in non-core layers needs pushing up to oe-core.		* Show easily which recipes are being used and which are overridden. We have bitbake-layers, but this clearly needs some extension. I think long term we would want to be able to analyse overrides across a set of layers to figure out where common stuff in non-core layers needs pushing up to oe-core.

	* Allow layer maintainers to easily pull a version of a recipe into their own layer if it's about to be removed from oe-core - with some complicated recipes that could be painful/annoying to pick out all the necessary files by hand. We have newcollection.bbclass in OE which does this, may be useful to break it out to a separate script somehow.		* Allow layer maintainers to easily pull a version of a recipe into their own layer if it's about to be removed from oe-core - with some complicated recipes that could be painful/annoying to pick out all the necessary files by hand. We have newcollection.bbclass in OE which does this, may be useful to break it out to a separate script somehow.

PaulEggleton: Move brainstorming below tasks

2011-05-10T16:22:47Z

Move brainstorming below tasks

@@ Line 1: / Line 1: @@
-'''Note: this is a work in progress, not yet a concrete plan.'''
+== Tasks ==
 == Brainstorming submissions ==
@@ Line 47: / Line 80: @@
 Richard says:
 http://lists.linuxtogo.org/pipermail/openembedded-core/2011-May/001940.html

PaulEggleton: Update after discussion with Richard

2011-05-10T14:50:43Z

Update after discussion with Richard

← Older revision		Revision as of 14:50, 10 May 2011
Line 71:		Line 71:
	** Enable splitting of a patch into separate parts for different components (use splitdiff for this?)		** Enable splitting of a patch into separate parts for different components (use splitdiff for this?)
	** Could be initially created with git-stitch-repo? (Depends on whether you want the history)		** Could be initially created with git-stitch-repo? (Depends on whether you want the history)
	* Tool to merge (flatten) several layers into one ~~(clarification needed)~~ [unassigned]		* Tool to merge (flatten) several layers into one [unassigned]
	** Take current layer config and apply all .bbappend / ~~copy~~ .bb files ~~into the "main" layer~~		** Take current layer config and apply all .bbappend / remove overridden .bb files and output to a separate directory

	== Future tasks ==		== Future tasks ==