openembedded-core.git/meta/lib/oe/patch.py, branch uninative-1.5

lib/oe/patch: Support xz-compressed patches

2017-02-23T20:29:10+00:00

Add .xz to the list of extensions recognized by patch_path(), so that
compressed patches ending in .patch.xz or .diff.xz are automatically
applied.

(From OE-Core rev: f1a2c45765d14d3ca09657ad1f6b526554af2bb6)

Signed-off-by: Dominic Sacré 
Signed-off-by: Ross Burton 
Signed-off-by: Richard Purdie

meta: remove True option to getVar calls

2016-12-16T08:30:03+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 
Signed-off-by: Ross Burton

classes/patch: move several functions to oe.patch

2016-12-14T09:56:35+00:00

Move patch_path(), src_patches() and should_apply() to oe.patch, making
them easier to call from elsewhere (particularly across the
UI/server boundary).

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

lib/oe/patch: fix handling of patches with no header

2016-11-23T11:02:27+00:00

If a patch applied by a recipe has no header and we turn the recipe's
source into a git tree (when PATCHTOOL = "git" or when using devtool
extract / modify / upgrade), the commit message ends up consisting only
of the original filename marker ("%% original patch: filename.patch").
When we come to do turn the commits back into a set of patches in
extractPatches(), this first line ends up in the "Subject: " part of
the file, but we were ignoring it because the line didn't start with the
marker text. The end result was we weren't able to get the original
patch name. Strip off any "Subject [PATCH x/y]" part before looking for
the marker text to fix.

This caused "devtool modify openssl" followed by "devtool update-recipe
openssl" (without any changes in-between) to remove version-script.patch
because that patch has no header and we weren't able to determine the
original filename.

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

lib/oe/patch: improve accuracy of patch header extraction

2016-09-23T17:06:10+00:00

When PATCHTOOL = "git", if we need to manually apply a patch and then
commit it (i.e. when git am doesn't work) we try to extract the author /
date / shortlog from the patch header. Make the following improvements
to that extraction process:

* If there's no explicit Subject: but the first line is followed by a
  blank line, isn't an Upstream-Status: or Index: marker and isn't too
  long, then assume it's good enough to be the shortlog. This avoids
  having too many patches with "Upgrade to version x.y" as the shortlog
  (since that is often when patches get added).
* Add --follow to the command we use to find the commit that added the
  patch, so we mostly get the commit that added the patch rather than
  getting stuck on upgrade commits that last moved/renamed the patch
* Populate the date from the commit that added the patch if we were able
  to get the author but not the date from the patch (otherwise you get
  today's date which is less useful).

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

lib/oe/patch: exclude "From " from commit message when PATCHTOOL is "git"

2016-09-23T17:06:10+00:00

If you leave "From " lines in the commit message it can actually
break git rebase because it tries to interpret the line in the context
of the current repository, and if the hash is invalid then a rebase
will blow up with:

  fatal: git cat-file: could not get object info

or in newer git versions:

  error: unable to find 
  fatal: git cat-file : bad file

(I hit this when I tried to do a devtool upgrade on openssl to 1.0.2i
the first time I did "git rebase --skip")

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

lib/oe/patch: handle non-UTF8 encoding when reading patches

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

When extracting patches from a git repository with PATCHTOOL = "git" we
cannot assume that all patches will be UTF-8 formatted, so as with other
places in this module, try latin-1 if utf-8 fails.

This fixes UnicodeDecodeError running devtool update-recipe or devtool
finish on the openssl recipe.

Signed-off-by: Paul Eggleton

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

lib/oe/patch: handle encoding differences in patch files

2016-07-12T22:10:05+00:00

With Python 3, the encoding of a file is significant; several recipes in
OE-Core have patches which are not fully utf-8 decodable e.g. man,
lrzsz, and gstreamer1.0-libav, leading to errors when using devtool's
modify, upgrade or extract subcommands on these recipes. To work around
this, try reading the patch file as utf-8 first and if that fails try
latin-1 before giving up.

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

scripts: Fix encoding errors for python3

2016-06-02T07:10:03+00:00

Moved call of decode('utf-8') as close as possible to
call of subprocess API to avoid calling it in a lot of
other places.

Decoded binary data to utf-8 where appropriate to fix devtool
and recipetool tests in python 3 environment.

Signed-off-by: Ed Bartosh