linux/poky.git/scripts/lib/devtool/upgrade.py, branch 3.5_M1

devtool: print a warning on upgrades if PREFERRED_VERSION is set

2021-08-02T14:44:11+00:00

(From OE-Core rev: 0b0f53eed0aadbf45d9eead96ebf7725cc7447e6) Signed-off-by: Alexander Kanavin Signed-off-by: Richard Purdie

Convert to new override syntax

2021-08-02T14:44:10+00:00

This is the result of automated script conversion: scripts/contrib/convert-overrides.py converting the metadata to use ":" as the override character instead of "_". (From OE-Core rev: 42344347be29f0997cc2f7636d9603b1fe1875ae) Signed-off-by: Richard Purdie

devtool: correctly handle non-standard source tree locations in upgrades

2021-07-16T20:23:43+00:00

When S is set to a sub-directory of upstream source, the license checks and the bbappend writing (specifically, setting EXTERNALSRC) need to operate on that sub-directory. 'devtool modify' already has similar logic, and it was copied from there and adjusted. (From OE-Core rev: fd77e356d4507405fde352c8bba7d3842518bbdd) Signed-off-by: Alexander Kanavin Signed-off-by: Alexandre Belloni Signed-off-by: Richard Purdie

devtool upgrade: rebase override-only patches as well

2021-06-26T10:27:16+00:00

There's a number of recipes (such as nettle or glib) which were upgraded incorrectly due to rebasing only the default set of patches in main SRC_URI. Native-only or musl-only patches were not handled, causing do_patch fails and overall misery. Unfortunately, this also necessitates aborting any incomplete rebases as devtool needs to be able to return to the original branch to complete the upgrade command. Also, do not add devtool-patched-%version tags, as they are not used anywhere, and it's unclear how to extend them to cover multiple override branches. (From OE-Core rev: 00131cbc969f6a73caffe068fcb983287cbe577f) (From OE-Core rev: 588d04748dd89b5371ca9144666e97ec82dd6204) Signed-off-by: Alexander Kanavin Signed-off-by: Alexandre Belloni Signed-off-by: Richard Purdie

classes/lib/scripts: Use bb.utils.rename() instead of os.rename()

2021-05-06T10:16:23+00:00

Incremental build in Docker fails with: OSError: [Errno 18] Invalid cross-device link when source and destination are on different overlay filesystems. Rather than adding fallback code to every call site, use a new wrapper in bitbake which detects this case and falls back to shutil.move which is slower but will handtle the overlay docker filesystems correctly. [YOCTO #14301] (From OE-Core rev: 656a65b2b84e7d529b89cf5de7eb838f902d84a2) Signed-off-by: Richard Purdie

devtool: gitsm:// should be handled same as git:// in upgrades

2020-12-31T11:53:26+00:00

(From OE-Core rev: e7076f1742bb83e76aa4e90aad861546536166cf) Signed-off-by: Alexander Kanavin Signed-off-by: Richard Purdie

devtool: default to empty string, if LIC_FILES_CHKSUM is not available

2020-07-08T09:37:12+00:00

[Bug 13971] https://bugzilla.yoctoproject.org/show_bug.cgi?id=13971 A recipe using LICENSE=CLOSED would normally not have LIC_FILES_CHKSUM set. If LIC_FILES_CHKSUM was not set, it would cause `devtool upgrade` to fail. This fixes the issue by defaulting to an empty string if LIC_FILES_CHKSUM is not found. [YOCTO #13971] (From OE-Core rev: 95e112f0f465868e98285509ea0d1a624a439ac2) Signed-off-by: Bjarne Michelsen Signed-off-by: Richard Purdie

devtool: use -f and don't use --exclude-standard when adding files to workspace

2020-06-04T12:27:29+00:00

* I see a case where a tarball contains .gitignore and bunch of files which are normally ignored in git, but still included in the tarball (e.g. configure script next to configure.ac) * when devtool is creating a git repo in workspace it won't include these files from tarball in the initial devtool-base commit, because git ls-files won't list them * but then the first .patch file (without git headers) when applied with GitApplyTree._applypatch() will add all these still ignored files to a commit which used to only modify some files, because it's using -f: # Add all files shellcmd = ["git", "add", "-f", "-A", "."] output += runcmd(["sh", "-c", " ".join(shellcmd)], self.dir) at least in this case it would be better to add all ignored files in the initial devtool-base commit and then --force-patch-refresh will just include the small modification as before instead of adding unrelated files, just because they were initially ignored - this behavior will also match with the do_patch task in the actual build where the .gitignore is ignored when unpacking some tarball * my use-case is fixed in setup_git_repo, but similar function is in devtool upgrade, I've changed it there as well (From OE-Core rev: 06a24a615549af3550302a56ea08147000a608f3) Signed-off-by: Martin Jansa Signed-off-by: Richard Purdie

devtool: do not write md5sums into upgraded recipes

2020-05-21T09:52:07+00:00

This will drop them md5sums from recipes that still have them, and will not re-add them for recipes where they're already removed. [RP: Added fix for the test recipe] (From OE-Core rev: 1609e77a4db04a4c01cbbff17261cd57e8f816ee) Signed-off-by: Alexander Kanavin Signed-off-by: Richard Purdie

devtool: fix devtool upgrade with reproducible_builds class

2019-11-21T23:08:20+00:00

If the reproducible_build class is inherited then there may be a "source-date-epoch" subdirectory in a fetched source tree; devtool upgrade was not expecting that in the upgraded source. Take a small snippet of code from recipetool create which already handles this, and make it a shared function that can be used in both places. Additionally, fix an assumption that the source is always in a subdirectory in the cleanup code that blocked debugging this. [YOCTO #13635] (From OE-Core rev: 0d642861cd9cf034b8d4951433980addc215d4fd) Signed-off-by: Paul Eggleton Signed-off-by: Richard Purdie