linux/poky.git/meta/lib/oe/patch.py, branch uninative-2.1

patch.py: Use git format-patch with --no-signature --no-numbered params

2018-03-20T09:59:32+00:00

* --no-signature saves unnecessary .patch modifications when executed on host with different git version * --no-numbered saves unnecessary .patch modifications when number of the applied patches is changed (the number is still in the filename so the order how they should be applied is still preserved) * both options exist for very long time, I've tested them with git 1.9.1 from Ubuntu 14.04 and I'm quite sure they were available even in much older releases, so there shouldn't be any issue on relatively new sanity tested distros (From OE-Core rev: ad76fa92c3a5be38962aff09df070ffd9756f777) Signed-off-by: Martin Jansa Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

lib/oe/patch.py: add a warning if patch context was ignored

2018-03-15T13:27:18+00:00

Ignoring patch context increases the chances of patches being applied incorrectly. Depending on what code is being patched, this can go completely unnoticed and create subtle bugs, sometimes with security implications. Please see here for a specific example: https://bugzilla.yoctoproject.org/show_bug.cgi?id=10450 On the other hand, we cannot simply force all patch context to match exactly: doing this would break a lot of recipes suddenly, across all layers. So let's try a softer approach: issue a warning, and gently update patches over a longer span of time. When most of the warnings are eliminated, we can start enforcing a strict patch application policy. I do understand that this patch creates a lot of warnings all of a sudden, however I believe the problem does need to be addressed. All of oe-core recipes have their context already fixed. Sample warning: WARNING: vulkan-1.0.61.1-r0 do_patch: Some of the context lines in patches were ignored. This can lead to incorrectly applied patches. The context lines in the patches can be updated with devtool: devtool modify devtool finish --force-patch-refresh Then the updated patches and the source tree (in devtool's workspace) should be reviewed to make sure the patches apply in the correct place and don't introduce duplicate lines (which can, and does happen when some of the context is ignored). Details: Applying patch demos-Don-t-build-tri-or-cube.patch patching file demos/CMakeLists.txt Hunk #1 succeeded at 63 (offset 2 lines). Hunk #2 succeeded at 76 with fuzz 1 (offset 2 lines). [YOCTO #10450] (From OE-Core rev: 5133fd46bccf14e21680f8d94e952914edccb113) Signed-off-by: Alexander Kanavin Signed-off-by: Richard Purdie

meta/lib/oe/patch.py: do not leave .orig files if a patch isn't perfectly matching

2018-03-11T13:26:59+00:00

Particularly, this was causing 'devtool modify' to erroneously add those .orig files into commits. This was getting in the way, if the goal was to amend/update those existing patches. (From OE-Core rev: f4f3406c3bd9599d7a19275475d52bda4c42f2ab) Signed-off-by: Alexander Kanavin Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

lib/oe/patch: add missing import

2018-01-02T17:24:39+00:00

This module refers to oe.types, so it needs to actually import oe.types. Fixes errors when parsing certain OE-Core recipes within the layer index update script. (From OE-Core rev: 26ff9d2835a24a84c7f2bf9c829a13ed568c9ea0) Signed-off-by: Paul Eggleton Signed-off-by: Richard Purdie

meta: replace uses of bb.data.expand(VARNAME, d) with d.expand(VARNAME)

2017-03-22T11:35:19+00:00

bb.data.expand(x, d) is deprecated API. [YOCTO #10678] (From OE-Core rev: a361babe443da635aed83be46679067457fd6a58) Signed-off-by: Joshua Lock Signed-off-by: Richard Purdie

lib/oe/patch: Support xz-compressed patches

2017-02-23T20:49:48+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) (From OE-Core rev: f50fd7f247d5bb05bc7d1109c574a682067688da) Signed-off-by: Dominic Sacré Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

meta: remove True option to getVar calls

2016-12-16T10:23:23+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\) (From OE-Core rev: 7c552996597faaee2fbee185b250c0ee30ea3b5f) Signed-off-by: Joshua Lock Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

classes/patch: move several functions to oe.patch

2016-12-14T12:30:50+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). (From OE-Core rev: 2724511e18810cc8082c1b028e3b7c8a8b5def56) Signed-off-by: Paul Eggleton Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

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

2016-11-23T11:10:12+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. (From OE-Core rev: d9971f5dc8eb7de551fd6f5e058fd24770ef5d78) Signed-off-by: Paul Eggleton Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

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

2016-09-24T06:30:09+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). (From OE-Core rev: 896cfb10ec166a677cbb3b4f8643719cabeb7663) Signed-off-by: Paul Eggleton Signed-off-by: Richard Purdie