* validate_pn() is supposed to protect against invalid characters, fix
  the function so that it actually does (unanchored regex strikes
  again...)
* However, now that the function is enforcing the restrictions, we do
  still want to allow + in recipe names (e.g. "gtk+")

Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

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 <paul.eggleton@linux.intel.com>

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 <richard.purdie@linuxfoundation.org>

If you supplied an empty file to patch_recipe() (or an empty list to
patch_recipe_lines()) then the result was IndexError because the code
checking to see if it needed to add an extra line of padding didn't
check to see if there were in fact any lines before trying to access the
last line.

Fixes [YOCTO #9972].

Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

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 <paul.eggleton@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>

This provides us with the information we need to remove the original
version recipe and associated files when running "devtool finish" after
"devtool upgrade".

Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>

* Allow the function to be called with the base layer path (in which
  case it will just return the same path)
* Ensure that the function doesn't recurse indefinitely if it's called
  on a file that's not inside a layer
* Correct the doc comment for accuracy

Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>

This patch contains all the other misc pieces of the transition to
python3 which didn't make sense to be broken into individual patches.

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

Replaced iteritems -> items, itervalues -> values,
iterkeys -> keys or 'in'

Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>

xrange() no longer exists in python 3, use range()

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>