linux/meta-openembedded.git/meta-oe/classes/gitpkgv.bbclass, branch hardknott

gitpkgv.bbclass: Add support for extending the supported tag formats

2020-01-17T23:44:06+00:00

Introduce GITPKGV_TAG_REGEXP (which defaults to "v(\d.*)") to support dropping other unwanted parts of the found tags than just a leading "v". Any matching groups in the regexp will be concatenated to yield the final version. Signed-off-by: Peter Kjellerstedt Signed-off-by: Khem Raj

gitpkgv.bbclass: Support also lightweight tags

2019-11-20T07:33:03+00:00

When checking for commit specific tags during GITPKGVTAG resolution, use additional '--tags' and '--exact-match' options for 'git describe' command. This changes the behaviour so that in case an annotated tag does not exist for the particular commit, then the latest lightweight (non-annotated) tag is used instead, in case that commit has at least one such tag. Signed-off-by: Niko Mauno Signed-off-by: Khem Raj

gitpkgv.bbclass: Use --git-dir option

2019-11-20T07:33:03+00:00

Avoid redundant shell working directory change by resorting to '--git-dir' option for git command instead. Signed-off-by: Niko Mauno Signed-off-by: Khem Raj

gitpkgv.bbclass: fix versioning with multiple repos

2017-02-22T12:16:48+00:00

gitpkgv class is supposed to use SRCREV_FORMAT variable to define how to smoosh together revision info from multiple repos that are used in a single recipe. It is incorrectly repeating the rev hash for the first repo instead of including the rev from each listed repo. Example: SRC_URI = "git://some-server/purple.git;destsuffix=git/purple;name=purple" SRC_URI += "git://other-server/blue.git;destsuffix=git/blue;name=blue" SRCREV_purple = "${AUTOREV}" SRCREV_blue = "${AUTOREV}" SRCREV_FORMAT = "purple_blue" Suppose gitpkgv calculates "67+ea121ea" for purple repo, and "123+feef001" for blue repo. This should result in a package version with them joined together like so: "67+ea121ea_123+feef001" It didn't. Instead the git hash part for the first repo got repeated: "67+ea121ea_123+ea121ea" Fix this by looking in the right place for the git revisions of 2nd (and following) repos when assembling the full version string. Signed-off-by: S. Lockwood-Childs Signed-off-by: Martin Jansa

remove True option to getVar calls

2016-12-02T08:16:17+00:00

getVar() now defaults to expanding by default, thus remove the True option from getVar() calls with a regex search and replace. Search made with the following regex: getVar ?$( ?[^,()]*), True$ Signed-off-by: Joshua Lock

gitpkgv: Fix $GITPKV for a single named git source

2016-09-05T11:30:50+00:00

Recipes that fetch from a single git source, assign a name to this source and do not set SRCREV_FORMAT to this name will always get a GITPKGV value of "default", which causes version-going-backwards QA errors. Fix this by automatically determining a suitable SRCREV_FORMAT from the SRC_URI if none is set explicitly. This code does not run for multiple git sources, because bitbake's fetcher enforces setting SRCREV_FORMAT when multiple version-controlled sources are used. Signed-off-by: Clemens Lang Signed-off-by: Martin Jansa

gitkpkgv: Ensure files are closed

2016-06-08T12:55:26+00:00

This avoids warnings with python 3. Signed-off-by: Richard Purdie Signed-off-by: Martin Jansa

gitpkgv.bbclass: Add support for gitsm:// url type

2015-12-18T11:39:50+00:00

When using "gitsm://", for projects using submodules, instead of "git://", gitpkgv does not work. The limitation is synthetic, this patch simply adds gitsm as an allowed url type. Signed-off-by: Daniel Adolfsson Signed-off-by: Martin Jansa

gitpkgv.bbclass: cache GITPKGV result

2013-01-18T09:49:44+00:00

gitpkgv runs the 'git rev-list | wc -l' several times when processing a package using GITPKGV. This takes ages for packages like the linux kernel which has a) a large repository and b) lots of subpackages. This patch caches the result of 'git rev-list' and uses it on the next run. Signed-off-by: Enrico Scholz Signed-off-by: Martin Jansa

Replace bb.data.* with d.*

2012-10-28T14:32:06+00:00

Used sed expression given here: http://lists.linuxtogo.org/pipermail/openembedded-core/2011-November/012373.html Plus an additional expression for .expand. Full expression is: sed \ -e 's:bb.data.$setVar([^,]*,[^,]*$, $[^ )]*$ *):\2.\1):g' \ -e 's:bb.data.$setVarFlag([^,]*,[^,]*,[^,]*$, $[^) ]*$ *):\2.\1):g' \ -e 's:bb.data.$getVar([^,]*$, $[^, ]*$ *,$[^)]*$):\2.\1,\3):g' \ -e 's:bb.data.$getVarFlag([^,]*,[^,]*$, $[^, ]*$ *,$[^)]*$):\2.\1,\3):g' \ -e 's:bb.data.$getVarFlag([^,]*,[^,]*$, $[^) ]*$ *):\2.\1):g' \ -e 's:bb.data.$getVar([^,]*$, $[^) ]*$ *):\2.\1):g' \ -e 's:bb.data.$expand([^,]*$, $[^ )]*$ *):\2.\1):g' \ -i `grep -ril bb.data *` Some minor correction in systemd.bbclass was needed for some expressions that didn't quite match the regex in the desired way; additionally a few instances were manually changed. Signed-off-by: Paul Eggleton