linux/poky.git/scripts/lib/devtool/upgrade.py, branch yocto-3.3.5

devtool: print a warning on upgrades if PREFERRED_VERSION is set

2021-08-14T11:01:43+00:00

(From OE-Core rev: 5fb2fb70d14b0e9f6235e5b940e9a3e1145750bb) Signed-off-by: Alexander Kanavin Signed-off-by: Richard Purdie (cherry picked from commit 0b0f53eed0aadbf45d9eead96ebf7725cc7447e6) Signed-off-by: Anuj Mittal Signed-off-by: Richard Purdie

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

2021-08-06T08:59:14+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: ddf5a7f3b644915d360f725eca8322187226f171) Signed-off-by: Alexander Kanavin Signed-off-by: Alexandre Belloni Signed-off-by: Richard Purdie (cherry picked from commit fd77e356d4507405fde352c8bba7d3842518bbdd) Signed-off-by: Anuj Mittal Signed-off-by: Richard Purdie

devtool upgrade: rebase override-only patches as well

2021-07-06T12:02:30+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: a4a5bebcc06637e097f074be9e401aafa8685c38) Signed-off-by: Alexander Kanavin Signed-off-by: Alexandre Belloni (cherry picked from commit 588d04748dd89b5371ca9144666e97ec82dd6204) Signed-off-by: Anuj Mittal 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

devtool: remove temp dir in upgrade

2019-07-22T16:31:03+00:00

For now, the temp dir is left in system, although the temporary source directory has been cleaned up. So we clean it up too. (From OE-Core rev: 8a0602327d5afcf4f36850d3f05c9721305852af) Signed-off-by: Chen Qi Signed-off-by: Richard Purdie

devtool: upgrade: fix handling of errors parsing upgraded recipe

2019-07-03T16:00:57+00:00

As part of upgrading a recipe we create the upgraded recipe file in the workspace and then try to parse it so we can then make further modifications. If for some reason that parsing fails then the failure was not being handled very well - the broken recipe was being left in place, breaking parsing until it was removed by hand. Fix that by adding a call to the cleanup function, and fix the following issues: * Fix the cleanup function which doesn't look like it has ever worked due to a typo in the function call * Fix double-printing the error message * Remove usage of DevtoolError in this case (DevtoolError is for simple usage errors, not this kind of issue which may be the result of a bug). We're still printing a traceback in this scenario but at least it doesn't break the build system requiring manual cleanup. I also introduced a command-line option to preserve the broken upgraded recipe file(s) for debugging purposes. (The reproducer for this is "devtool upgrade libnewt-python", however you need to check out revision b82ea144e144671d3f64c0785ba4beafe905cd4f or earlier since that recipe has now been absorbed into the libnewt recipe. The libnewt-python recipe was causing an issue with the upgrade because it actually included the libnewt recipe using ${PV} in the include statement, and of course PV was changing in the upgrade.) Fixes [YOCTO #13404]. (From OE-Core rev: c519ac360796675d7fc09a5250d21f0f5b6236fc) Signed-off-by: Paul Eggleton Signed-off-by: Richard Purdie