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 <sjl@vctlabs.com>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
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 <joshua.g.lock@intel.com>
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 <clemens.lang@bmw-carit.de>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
This avoids warnings with python 3.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
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 <daniel.adolfsson@bluetest.se>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
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 <enrico.scholz@sigma-chemnitz.de>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
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 <paul.eggleton@linux.intel.com>
In case of multiple GIT repositories are used, SRCREV_FORMAT will be
respected while filling it with the proper GIT information to each
revision.
This new feature needed heavy changes in the code so basically it was
a rewrote version that keeps compatibility with previous usage.
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
