openembedded-core.git/scripts/lib/devtool/standard.py, branch uninative-1.4

devtool: add: drop superfluous validation for recipe name

2016-09-19T08:06:52+00:00

Now that recipeutils.validate_pn() properly validates characters used in
the name, we can drop this bit checking for '/' since that's not
permitted by validate_pn(). (The FIXME comment here - that I myself
apparently wrote - is questionable since that function was clearly never
intended to allow '/', perhaps I was misled because it was broken and
did so).

Signed-off-by: Paul Eggleton 
Signed-off-by: Richard Purdie

recipetool: create: support git short form URLs

2016-09-19T08:06:52+00:00

In keeping with making recipetool create / devtool add as easy to use as
possible, users shouldn't have to know how to reformat git short form ssh
URLs for consumption by BitBake's fetcher (for example
user@git.example.com:repo.git should be expressed as
git://user@git.example.com/repo.git;protocol=ssh ) - instead we should
just take care of that automatically. Add some logic in the appropriate
places to do that.

Signed-off-by: Paul Eggleton 
Signed-off-by: Richard Purdie

devtool: update-recipe: support files with subdir=

2016-09-07T23:36:43+00:00

It's rare but there are recipes that have individual files (as opposed
to archives) in SRC_URI using subdir= to put them under the source tree,
the examples in OE-Core being bzip2 and openssl. This broke devtool
update-recipe (and devtool finish) because the file wasn't unpacked into
the oe-local-files directory and thus when it came time to update the
recipe, the file was assumed to have been deleted by the user and thus
the file was erroneously removed. Add logic to handle these properly so
that this doesn't happen.

(We still have another potential problem in that these files become part
of the initial commit from upstream, which could be confusing because
they didn't come from there - but that's a separate issue and not one
that is trivially solved.)

Signed-off-by: Paul Eggleton

scripts: ensure tinfoil is shut down correctly

2016-09-03T22:45:46+00:00

We should always shut down tinfoil when we're finished with it, either
by explicitly calling the shutdown() method or by using it as a
context manager ("with ...").

Signed-off-by: Paul Eggleton 
Signed-off-by: Richard Purdie

lib/oe/patch: commit with a dummy user/email when PATCHTOOL=git

2016-09-03T08:58:45+00:00

When using PATCHTOOL = "git", the user of the system is not really the
committer - it's the build system itself. Thus, specify "dummy" values
for username and email instead of using the user's configured values.
Various parts of the devtool code that need to make commits have also
been updated to use the same logic.

This allows PATCHTOOL = "git" and devtool to be used on systems where
git user.name / user.email has not been set (on versions of git where
it doesn't default a value under this circumstance).

If you want to return to the old behaviour where the externally
configured user name / email are used, set the following in your
local.conf:

PATCH_GIT_USER_NAME = ""
PATCH_GIT_USER_EMAIL = ""

Fixes [YOCTO #8703].

Signed-off-by: Paul Eggleton 
Signed-off-by: Richard Purdie

devtool: Use the wildcard flag in update_recipe_patch

2016-08-25T21:59:29+00:00

The --wilcard-version flag was only used in the srcrev variant of the
update-recipe command.

Signed-off-by: Ola x Nilsson 
Signed-off-by: Ross Burton

devtool/recipetool/meta: Adapt to bitbake API changes for multi-configuration builds

2016-08-18T08:27:56+00:00

Unfortunately to implenent multiconfig support in bitbake some APIs
had to change. This updates code in OE to match the changes in bitbake.
Its mostly periperhal changes around devtool/recipetool

[Will need a bitbake version requirement bump which I'll make when merging]

Signed-off-by: Richard Purdie

devtool: add finish subcommand

2016-07-20T09:24:53+00:00

Add a subcommand which will "finish" the work on a recipe. This is
effectively the same as update-recipe followed by reset, except that the
destination layer is required and it will do the right thing depending
on the situation - if the recipe file itself is in the workspace (e.g.
as a result of devtool add), the recipe file and any associated files
will be moved to the destination layer; or if the destination layer is
the one containing the original recipe, the recipe will be overwritten;
otherwise a bbappend will be created to apply the changes. In all cases
the layer path can be loosely specified - it could be a layer name, or
a partial path into a recipe. In the case of upgrades, devtool finish
will also take care of deleting the old recipe.

This avoids the user having to figure out the correct actions when
they're done - they just do "devtool finish recipename layername" and
it saves their work and then removes the recipe from the workspace.

Addresses [YOCTO #8594].

Signed-off-by: Paul Eggleton 
Signed-off-by: Ross Burton

devtool: update-recipe: refactor to allow calling separately

2016-07-20T09:24:53+00:00

This will be called by "devtool finish" to allow it to update the recipe
or create the bbappend depending on the destination.

Signed-off-by: Paul Eggleton 
Signed-off-by: Ross Burton

devtool: reset: refactor to allow calling separately

2016-07-20T09:24:53+00:00

This will be called by "devtool finish" to allow it to reset the recipe
at the end.

Signed-off-by: Paul Eggleton 
Signed-off-by: Ross Burton