summaryrefslogtreecommitdiffstats
path: root/scripts/lib/devtool/upgrade.py
AgeCommit message (Collapse)Author
2020-07-08devtool: default to empty string, if LIC_FILES_CHKSUM is not availableBjarne Michelsen
[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 <bjarne_michelsen@hotmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2020-06-04devtool: use -f and don't use --exclude-standard when adding files to workspaceMartin Jansa
* 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 <Martin.Jansa@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2020-05-21devtool: do not write md5sums into upgraded recipesAlexander Kanavin
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 <alex.kanavin@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2019-11-21devtool: fix devtool upgrade with reproducible_builds classPaul Eggleton
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 <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2019-07-22devtool: remove temp dir in upgradeChen Qi
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 <Qi.Chen@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2019-07-03devtool: upgrade: fix handling of errors parsing upgraded recipePaul Eggleton
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 <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2019-05-09meta/lib+scripts: Convert to SPDX license headersRichard Purdie
This adds SPDX license headers in place of the wide assortment of things currently in our script headers. We default to GPL-2.0-only except for the oeqa code where it was clearly submitted and marked as MIT on the most part or some scripts which had the "or later" GPL versioning. The patch also drops other obsolete bits of file headers where they were encoountered such as editor modelines, obsolete maintainer information or the phrase "All rights reserved" which is now obsolete and not required in copyright headers (in this case its actually confusing for licensing as all rights were not reserved). More work is needed for OE-Core but this takes care of the bulk of the scripts and meta/lib directories. The top level LICENSE files are tweaked to match the new structure and the SPDX naming. (From OE-Core rev: f8c9c511b5f1b7dbd45b77f345cb6c048ae6763e) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2019-02-02devtool: add --all option to check-upgrade-statusRoss Burton
The default behaviour is to show just recipes needing upgrades, but for automated reports showing all recipes can be useful. (From OE-Core rev: 29e064ac6bd8d1ef74c280bf85bf8428c37ba014) Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2019-01-26devtool: add a command to print an overall list of recipes that can be updatedAlexander Kanavin
A sample portion of the output: $ devtool check-upgrade-status ... NOTE: acpid 2.0.30 2.0.31 Ross Burton <ross.burton@intel.com> NOTE: u-boot-fw-utils 2018.11 2019.01 Marek Vasut <marek.vasut@gmail.com> d3689267f92c5956e09cc7d1baa4700141662bff NOTE: u-boot-tools 2018.11 2019.01 Marek Vasut <marek.vasut@gmail.com> d3689267f92c5956e09cc7d1baa4700141662bff NOTE: u-boot 2018.11 2019.01 Marek Vasut <marek.vasut@gmail.com> d3689267f92c5956e09cc7d1baa4700141662bff NOTE: bind 9.11.5 9.13.5 Armin Kuster <akuster808@gmail.com> cannot be updated due to: 9.11 is LTS 2021 NOTE: iproute2 4.19.0 4.20.0 Changhyeok Bae <changhyeok.bae@lge.com> NOTE: ofono 1.25 1.27 Ross Burton <ross.burton@intel.com> NOTE: wpa-supplicant 2.6 2.7 Changhyeok Bae <changhyeok.bae@lge.com> NOTE: base-passwd 3.5.29 3.5.45 Anuj Mittal <anuj.mittal@intel.com> cannot be updated due to: Version 3.5.38 requires cdebconf for update-passwd utility NOTE: busybox 1.29.2 1.30.0 Andrej Valek <andrej.valek@siemens.com> NOTE: dbus-test 1.12.10 1.12.12 Chen Qi <Qi.Chen@windriver.com> NOTE: dbus 1.12.10 1.12.12 Chen Qi <Qi.Chen@windriver.com> NOTE: glib-2.0 2.58.0 2.58.3 Anuj Mittal <anuj.mittal@intel.com> NOTE: glib-networking 2.54.1 2.58.0 Anuj Mittal <anuj.mittal@intel.com> ... (From OE-Core rev: 02284423b6391c77da19912192fc607fedb05e67) Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2018-07-26logging: use warning instead warnChen Qi
The warn method is deprecated. We should use the documented warning instead. Quoting from the python's official doc: """ Note: There is an obsolete method warn which is functionally identical to warning. As warn is deprecated, please do not use it - use warning instead. """ (From OE-Core rev: f467fd277eb77336097cfc0f5f329bdc8d0f70cb) Signed-off-by: Chen Qi <Qi.Chen@windriver.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2018-05-15devtool/upgrade: fix the order of license checksum representationChen Qi
In most recipes in OE, beginline and endline are before md5 checksum. We should obey this tradition in devtool's upgrade. Otherwise, we might see meaningless change just because of the order change. e.g. -LIC_FILES_CHKSUM = "file://doc/LICENSE;md5=7765a3d787cb4fed3ccc3c9cee030af9 \ - file://plugins/sudoers/redblack.c;beginline=1;endline=41;md5=805782a8466975716f8376b2be9aedde \ - file://lib/util/reallocarray.c;beginline=3;endline=16;md5=85b0905b795d4d58bf2e00635649eec6 \ - file://lib/util/fnmatch.c;beginline=3;endline=27;md5=67f83ee9bd456557397082f8f1be0efd \ - file://lib/util/getcwd.c;beginline=5;endline=27;md5=449af4cc57fc7d46f42090608ba3e681 \ - file://lib/util/glob.c;beginline=6;endline=31;md5=5872733146b9eb0deb79e1f664815b85 \ - file://lib/util/snprintf.c;beginline=6;endline=34;md5=c82c1b3a5c32e08545c9ec5d71e41e50 \ - file://include/sudo_queue.h;beginline=5;endline=27;md5=449af4cc57fc7d46f42090608ba3e681 \ - file://lib/util/inet_pton.c;beginline=3;endline=17;md5=3970ab0518ab79cbd0bafb697f10b33a" +LIC_FILES_CHKSUM = "file://doc/LICENSE;md5=cc4bf2366b059c9598e3947f885931ec \ + file://plugins/sudoers/redblack.c;md5=805782a8466975716f8376b2be9aedde;beginline=1;endline=41 \ + file://lib/util/reallocarray.c;md5=85b0905b795d4d58bf2e00635649eec6;beginline=3;endline=16 \ + file://lib/util/fnmatch.c;md5=67f83ee9bd456557397082f8f1be0efd;beginline=3;endline=27 \ + file://lib/util/getcwd.c;md5=449af4cc57fc7d46f42090608ba3e681;beginline=5;endline=27 \ + file://lib/util/glob.c;md5=5872733146b9eb0deb79e1f664815b85;beginline=6;endline=31 \ + file://lib/util/snprintf.c;md5=c82c1b3a5c32e08545c9ec5d71e41e50;beginline=6;endline=34 \ + file://include/sudo_queue.h;md5=449af4cc57fc7d46f42090608ba3e681;beginline=5;endline=27 \ + file://lib/util/inet_pton.c;md5=3970ab0518ab79cbd0bafb697f10b33a;beginline=3;endline=17 \ + " After this change, it becomes: -LIC_FILES_CHKSUM = "file://doc/LICENSE;md5=7765a3d787cb4fed3ccc3c9cee030af9 \ +LIC_FILES_CHKSUM = "file://doc/LICENSE;md5=cc4bf2366b059c9598e3947f885931ec \ file://plugins/sudoers/redblack.c;beginline=1;endline=41;md5=805782a8466975716f8376b2be9aedde \ file://lib/util/reallocarray.c;beginline=3;endline=16;md5=85b0905b795d4d58bf2e00635649eec6 \ file://lib/util/fnmatch.c;beginline=3;endline=27;md5=67f83ee9bd456557397082f8f1be0efd \ @@ -12,7 +12,8 @@ LIC_FILES_CHKSUM = "file://doc/LICENSE;md5=7765a3d787cb4fed3ccc3c9cee030af9 \ file://lib/util/glob.c;beginline=6;endline=31;md5=5872733146b9eb0deb79e1f664815b85 \ file://lib/util/snprintf.c;beginline=6;endline=34;md5=c82c1b3a5c32e08545c9ec5d71e41e50 \ file://include/sudo_queue.h;beginline=5;endline=27;md5=449af4cc57fc7d46f42090608ba3e681 \ - file://lib/util/inet_pton.c;beginline=3;endline=17;md5=3970ab0518ab79cbd0bafb697f10b33a" + file://lib/util/inet_pton.c;beginline=3;endline=17;md5=3970ab0518ab79cbd0bafb697f10b33a \ + " (From OE-Core rev: 6c5cc1b298be6aa1e9d378bc8349e11cbf17d300) Signed-off-by: Chen Qi <Qi.Chen@windriver.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2018-01-18devtool: rename the suggested license change tag to 'License-Update:'Alexander Kanavin
(From OE-Core rev: 3905ae20330f204f3c8997e2d5aaf15dcf5a860c) Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-12-18devtool: add license checksum change handling to 'devtool upgrade'Alexander Kanavin
Specifically, 'devtool upgrade' will now do these things: 1) determine if any of the license checksums need updating; if so, write the new checksums into the LIC_FILES_CHKSUM value in the recipe that is written to the workspace; 2) print a notice to the standard output: NOTE: New recipe is /home/ak/development/poky/build/workspace/recipes/puzzles/puzzles_git.bb NOTE: License checksums have been updated in the new recipe; please refer to it for the difference between the old and the new license texts. 3) and the cool part: devtool will create a diff of the old and new licenses, and write the diff into the workspace recipe as a comment, like this: ====== FIXME: the LIC_FILES_CHKSUM values have been updated by 'devtool upgrade'. The following is the difference between the old and the new license text. Please update the LICENSE value if needed, and summarize the changes in the commit message via 'License-checksum-change:' tag. (example: 'License-checksum-change: copyright years updated.') The changes: --- LICENCE +++ LICENCE @@ -1,8 +1,9 @@ This software is copyright (c) 2004-2014 Simon Tatham. Portions copyright Richard Boulton, James Harvey, Mike Pinna, Jonas -Klker, Dariusz Olszewski, Michael Schierl, Lambros Lambrou, Bernd -Schmidt, Steffen Bauer, Lennard Sprong and Rogier Goossens. +Kölker, Dariusz Olszewski, Michael Schierl, Lambros Lambrou, Bernd +Schmidt, Steffen Bauer, Lennard Sprong, Rogier Goossens and Michael +Quevillon. Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files ====== (From OE-Core rev: ccb37f9e81eb78ed0eb2a238d7c3e196db9b2f72) Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-12-18devtool: provide useful defaults for version/commit when upgrading recipesAlexander Kanavin
Specifically, 'devtool upgrade' will use the latest upstream release if available or latest commit if upstream never makes releases. (From OE-Core rev: 45b4242b105ad36e94ae15a96d588a58b917b8e8) Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-12-18devtool: add a 'latest-version' commandAlexander Kanavin
This command queries the upstream server for what the latest release is and prints the output; it is a much neater way to find out these things than fumbling with distrodata, 'bitbake -c checkpkg' and awkward to read csv output in a file. Examples: python3 (tarballs): NOTE: Current version: 3.5.3 NOTE: Latest version: 3.6.3 rpm (git): NOTE: Current version: 4.13.90 NOTE: Latest version: 4.14.0 NOTE: Latest version's commit: da3720f62e57648fb1dc2a632744d38866139971 puzzles (git without version tags): NOTE: Latest commit: ee8ea9b9785964694cb2b3ad77c3fb2460f49510 (From OE-Core rev: e8f5b5cc25ce7a9882f21473cefc47edcebf77d4) Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-11-11devtool: implement conditional patch handlingPaul Eggleton
If you have a recipe that uses overrides to conditionally extend SRC_URI to add additional patches, then you will often need to update those patches if you're making other changes to the source tree (for example if you're upgrading the underlying source). Make this possible with devtool by creating devtool-override-* branches for each override that conditionally appends/prepends SRC_URI, and have devtool update-recipe / finish check each branch out in turn and update the corresponding patches. A current example of a recipe that does this is the quota recipe - it applies an additional patch if musl is the selected C library (i.e. libc-musl is in OVERRIDES). Note that use of this functionality does require some care - in particular, updates to patches that appear on the main branch (named "devtool" by default) should be made there and not only on one of the specific devtool-override-* branches that are created for each override. The recommended procedure is to make the changes you want to make to the main branch first, then check out and rebase each devtool-override-* branch, testing each one by activating the corresponding configuration, and then finally run devtool finish. Fixes [YOCTO #11516]. (From OE-Core rev: aa87603d1ffd695027847f4df75c0406cf4e14d8) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-11-11devtool: upgrade: reformat --no-patch warning messagePaul Eggleton
* Only log one warning message instead of one per line * Be a bit more verbose * "if list" is more pythonic than "if len(list)" (From OE-Core rev: 2d11e9e6e73648c1cb514c0c10111c7886acae78) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-11-11devtool: upgrade: automatically handle changes to source subdirectoryPaul Eggleton
If the directory where the source code extracts to changes (for example, when upgrading iucode-tool from 1.5 to 2.1.1, the subdirectory in the tarball changed from "iucode_tool-${PV}" to "iucode-tool-${PV}") then handle this automatically. Also handle when it changes to match the default S value (i.e. "${WORKDIR}/${BP}") in which case we just drop setting S in the recipe. Fixes [YOCTO #10939]. (From OE-Core rev: d29881a652bf03627d257a1eac5f02ec17315b8b) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-11-11devtool: upgrade: show messages before source extraction stepsPaul Eggleton
Give the user a little more insight into what's being done. (From OE-Core rev: 9cf2089bd22b9fc4eb0eec8d4924e44519412dad) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-11-11devtool: upgrade: handle recipes that use named SRC_URI checksumsPaul Eggleton
devtool upgrade did not properly handle setting SRC_URI checksums for recipes that use named SRC_URI entries and also use those names in the SRC_URI checksums. A further complication was where the name contained an expression that changed with the version e.g. ${PV} (probably quite rare, but the dnsmasq recipe in meta-networking is currently one such recipe.) All of these are now handled properly. Additionally, drop the _get_checksums() function that wasn't being called from anywhere in the code. Note that this now turns nowrap_vars in recipeutils.py to be a list of regexes, hence things such as [ and ] need to be appropriately escaped. (From OE-Core rev: c914a5e1ad6d96e316746222e5d42f2ba9110060) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-11-11devtool: show some warnings for upgrade versionsPaul Eggleton
* Show a warning in devtool upgrade if the version is less than the current version suggesting that the user may need to bump PE in the recipe * Show a warning in devtool add and devtool upgrade if the version looks like a pre-release version suggesting using a version number that won't mess up the progression when you come to upgrade to the final release version. (From OE-Core rev: 92c4d9be9ed365c449ea1ac5a18ddb15e4a36b2d) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-11-11devtool: upgrade: improve performance and show progress when adding filesPaul Eggleton
When devtool upgrade is upgrading to a new version where the source is fetched as an archive (e.g. a tarball), we create a single commit in the git repository that is the upgrade from the old version to the new. We do this by extracting the old source, committing it, deleting all files, copying in the new files, running git add on each new/changed/deleted file, and then committing the result. When a lot of files have changed in an upgrade (such as QEMU 2.8.1.1 -> 2.10.0) the penultimate step of running git add it can take quite a long time; in order to reduce this and show some feedback to the user, run git add with batches of 100 files at once and also show a progress bar. In a local test with the aforementioned QEMU upgrade it took the time down from over 7 minutes down to about 13 seconds. Fixes [YOCTO #11948]. (From OE-Core rev: 8b184f6c874b60324ee107af53853687173d3434) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-11-11devtool: upgrade: fix not committing deleted files with older git versionsPaul Eggleton
With versions of git older than 2.0, "git add" on a deleted file (i.e. in this case a file that was removed between versions) will not add the delete to be committed by default, with the result that the rebase of patches on top of the new branch will fail. We need to use the -A option in order to force that for older git versions. (From OE-Core rev: c7f4c9f050c11c0de7fcf5badcc19a8fbc6428cf) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-11-11devtool: upgrade: fix accidentally swapped parametersPaul Eggleton
It appears that when fixing the signature unlocking in OE-Core commit 4e9a0be32fc30fb87d65da7cd1a4015c99533aff I swapped the parameters here and did not test it within the eSDK (it does nothing outside of the eSDK) resulting in a TypeError when devtool upgrade was used in the eSDK. Swap the parameters around to the correct ordering. Fixes [YOCTO #12285]. (From OE-Core rev: 05e2c4ada7083f40866846a21fe76c852f1dfefe) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-09-18devtool: ensure recipes devtool is working on are unlocked within the eSDKPaul Eggleton
Alongside reworking the way devtool extracts source, we now need to ensure that within the extensible SDK where task signatures are locked, the signatures of the tasks for the recipes being worked on get unlocked at the right time or otherwise we'll now get taskhash mismatches when running devtool modify on a recipe that was included in the eSDK such as the kernel (due to a separate bug). The existing mechanism for auto-unlocking recipes was a little weak and was happening too late, so I've reimplemented it so that: (a) it gets triggered immediately when the recipe/append is created (b) we avoid writing to the unlocked signatures file unnecessarily (since it's a global configuration file) and (c) within the eSDK configuration we whitelist SIGGEN_UNLOCKED_RECIPES to avoid unnecessary reparses every time we perform one of the devtool operations that does need to change this list. Fixes [YOCTO #11883] (not the underlying cause, but this manifestation of the issue). (From OE-Core rev: 4e9a0be32fc30fb87d65da7cd1a4015c99533aff) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-09-18devtool: rework source extraction so that dependencies are handledPaul Eggleton
Since it was first implemented, devtool's source extraction (as used by the devtool modify, extract and upgrade subcommands) ignored other recipe dependencies - so for example if you ran devtool modify on a recipe that fetches from svn or is compressed using xz then it would fail if those dependencies hadn't been built first. Now that we can execute tasks in the normal way (i.e. tinfoil.build_targets()) then we can rework it to use that. This is slightly tricky in that the source extraction needs to insert some logic in between tasks; luckily we can use a helper class that conditionally adds prefuncs to make that possible. Some side-effects / aspects of this change worth noting: * Operations are a little slower because we have to go through the task dependency graph generation and other startup processing. There's not really any way to avoid this though. * devtool extract didn't used to require a workspace, now it does because it needs to create a temporary bbappend for the recipe. (As with other commands the workspace be created on the fly if it doesn't already exist.) * I want any existing sysroot files and stamps to be left alone during extraction since we are running the tasks off to the side, and especially devtool extract should be able to be used without touching these. However, this was hampered by the automatic removal process in sstate.bbclass triggered by bb.event.ReachableStamps when the task signatures change, thus I had to introduce a way to disable this removal on a per-recipe basis (we still want it to function for any dependencies that we aren't working on). To implement this I elected to use a file written to tmp/sstate-control which gets deleted automatically after reading so that there's less chance of stale files affecting future sessions. I could have used a variable but this would have needed to be whitelisted and I'd have to have poked its value in using the setVariable command. Fixes [YOCTO #11198]. (From OE-Core rev: 830dbd66992cbb9e731b48d56fddf8f220349666) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-09-11devtool: upgrade: check that user has configured git properlyPaul Eggleton
If user.name or user.email haven't been set then git rebase can't really work properly. Check that the user has set these and error out if not. (Elsewhere we are relying on OE's git patch functionality which forces a dummy OE value - that's OK there as it's completely under OE's control and therefore it's OK for a dummy OE user to be the committer, but here the rebase may require intervention so it's reasonable to have the user's actual name and email on the operation.) Fixes [YOCTO #11947]. (From OE-Core rev: 129a3be07e272013be2db17552c13b4d8cc2cf6e) (From OE-Core rev: 802829f1c38d8c5eee11ba1d9ddd37cf02597f6e) Signed-off-by: paul <paul@peggleto-mobl.ger.corp.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-08-31devtool: upgrade: workaround for recipes which apply patches conditional ↵Paul Eggleton
upon class If we're upgrading a recipe that appends additional patches for, say, class-native, and we're just upgrading the target variant, then when we copied the recipe into the workspace we skipped copying the additional patches for the native variant. This caused warnings because the workspace recipe is preferred. Look at SRC_URI for all variants when copying files to work around this. More work is needed to make it easier to work with recipes that use BBCLASSEXTEND where you need to build more than one variant at once, but this at least fixes the immediate ugliness. (From OE-Core rev: 56bf5e93358187e31160d7893f57906bb3dc7ad7) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-08-31devtool: upgrade: fix handling of non-absolute pathsPaul Eggleton
If your BBLAYERS has non-absolute paths in it (e.g. "${COREBASE}/../something") then none of the paths matched in copy_recipe_files() with the result that no files got copied and you ended up with an error later on because the recipe file couldn't be found at the destination. Fix this as well as adding an explicit check to see if no files got copied - error out earlier if so. Fixes [YOCTO #10981]. (From OE-Core rev: 3861486ad06f90c8644ebab119bbc5ddb9e693ca) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-08-23devtool: upgrade: enable branch checking when revision is providedChang Rebecca Swee Fun
When devtool upgrade is run on a recipe with revision specified that is not on master branch, and branch isn't set by --srcbranch or -B, then we should get the correct branch and append the branch to the URL. If the revision was found on multiple branches, we will display error to inform user to provide a correct branch and exit. [YOCTO #11484] (From OE-Core rev: 29ced7387a92aed17b7fe93b1654790a981734c1) Signed-off-by: Chang Rebecca Swee Fun <rebecca.swee.fun.chang@intel.com> Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-07-21recipetool: create: reimplement fetching with normal fetch/unpack tasksPaul Eggleton
Now that we have the ability to run the tasks in a more standard context through tinfoil, change recipetool's fetching code to use that to fetch files using it. This has the major advantage that any dependencies of do_fetch and do_unpack (e.g. for subversion or npm) will be handled automatically. This also has the beneficial side-effect of fixing a recent regression that prevented this fetch operation from working with memory resident bitbake. Also fix devtool's usage of fetch_uri() at the same time so that we can completely replace it. Fixes [YOCTO #11710]. (From OE-Core rev: 9a47a6690052ef943c0d4760630ee630fb012153) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-02-23devtool: upgrade: fix error of import recipeutilsLuck Hoang
upgrade.py imports oe.recipeutils in meta/lib/ but path to oe.recipeutils is not provided. This fails populate_sdk_ext. (From OE-Core rev: 5f140359f859fea9cfe8c8d9c9584bceec875adb) Signed-off-by: Luck Hoang <huyht1205@gmail.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-01-09meta/scripts: Various getVar/getVarFlag expansion parameter fixesRichard Purdie
There were a few straggling expansion parameter removals left for getVar/getVarFlag where the odd whitespace meant they were missed on previous passes. There were also some plain broken ussages such as: d.getVar('ALTERNATIVE_TARGET', old_name, True) path = d.getVar('PATH', d, True) d.getVar('IMAGE_ROOTFS', 'True') which I've corrected (they happend to work by luck). (From OE-Core rev: 688f7a64917a5ce5cbe12f8e5da4d47e265d240f) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-12-16scripts: remove True option to getVar callsJoshua Lock
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: 0a36bd96e6b29fd99a296efc358ca3e9fb5af735) Signed-off-by: Joshua Lock <joshua.g.lock@intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-12-14devtool: fix extraction of source to work in memres modePaul Eggleton
Extracting the source for a recipe (as used by devtool's extract, modify and upgrade subcommands) requires us to run do_fetch, do_unpack, do_patch and any tasks that the recipe has inserted inbetween, and do so with a modified datastore primarily so that we can redirect WORKDIR and STAMPS_DIR in order to have the files written out to a place of our choosing and avoid stamping the tasks as having executed in a real build context respectively. However, this all gets much more difficult when in memres mode since we can't call internal functions such as bb.build.exec_func() directly - instead we need to execute the tasks on the server. To do this we use the buildFile command which already exists for the purpose of supporting bitbake -b, and setVariable commands to set up the appropriate datastore. (I did look at passing the modified datastore to the buildFile command instead of using setVar() on the main datastore, however its use of databuilder makes that very difficult, and we'd also need a different method of getting the changes in the datastore over to the worker as well.) (From OE-Core rev: eb63b5339014fc72ba4829714e0a96a98e135ee2) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-12-14devtool / recipetool: use tinfoil parsing APIPaul Eggleton
Use Tinfoil.parse_recipe_file() and Tinfoil.parse_recipe() instead of the recipeutils equivalents, and replace any local duplicate implementations. This not only tidies up the code but also allows these calls to work in memres mode. (From OE-Core rev: f13b56266ee96dfab65a3a7db50e8051aa9f071a) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-09-03scripts: ensure tinfoil is shut down correctlyPaul Eggleton
We should always shut down tinfoil when we're finished with it, either by explicitly calling the shutdown() method or by using it as a context manager ("with ..."). (From OE-Core rev: 5ec6d9ef309b841cdcbf1d14ac678d106d5d888a) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-09-03lib/oe/patch: commit with a dummy user/email when PATCHTOOL=gitPaul Eggleton
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]. (From OE-Core rev: 765a9017eaf77ea3204fb10afb8181629680bd82) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-08-18devtool/recipetool/meta: Adapt to bitbake API changes for ↵Richard Purdie
multi-configuration builds 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] (From OE-Core rev: 041212fa37bb83acac5ce4ceb9b7b77ad172c5c3) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-07-20devtool: upgrade: record original recipe filesPaul Eggleton
This provides us with the information we need to remove the original version recipe and associated files when running "devtool finish" after "devtool upgrade". (From OE-Core rev: 92eb42c347af919cd9f8739515fdf806c12b5ba8) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-06-02scripts: Fix deprecated dict methods for python3Ed Bartosh
Replaced iteritems -> items, itervalues -> values, iterkeys -> keys or 'in' (From OE-Core rev: 25d4d8274bac696a484f83d7f3ada778cf95f4d0) Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-05-25devtool: upgrade: clarify help text for --srcrev optionPaul Eggleton
The -S / --srcrev option must be specified if fetching from a git repository, so spell that out in the help text. (From OE-Core rev: 1465f205c235a1688a85844ebf5259e8971038ae) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-05-25devtool: upgrade: tweak conflict handlingPaul Eggleton
Make a couple of changes to the rebase operation: 1) Only wrap the actual rebase command in try...except since a failure in any of the other commands should be an error, not a warning 2) If it's a conflict (which unfortunately we can only tell by checking for the keyword "conflict" since git doesn't return error codes based on the type of error) then print a message clarifying that the user needs to resolve the issue themselves to finish the upgrade. (From OE-Core rev: 2a76be958432a35a0de30e9a5433089a54a06cad) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-05-25devtool: upgrade: handle upgrading recipes with a versioned inc filePaul Eggleton
The gdb recipe in OE-Core has an inc file with the version in it; since the inc file is pulled in with a "require ${PV}.inc", when upgrading the recipe we need to also rename the inc file it will fail to parse and the upgrade itself will fail. Fixes [YOCTO #9574]. (From OE-Core rev: 3c623aac9333d20a62475279c72b6b6ec3d7dd6b) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-04-15devtool: upgrade: handle recipes where source is not first entry in SRC_URIPaul Eggleton
It is unusual but not impossible to find recipes whose first entry is not the main source URL but instead some patch or other local file, for example python-cryptography in meta-python (which sets SRC_URI before inheriting pypi). There's nothing inherently wrong with this, and we shouldn't assume that the first entry is the main source URL, so just take the first non-local entry instead. (From OE-Core rev: c868198c1f6006789707b497c2ae34d7cc5e706f) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-02-28devtool: upgrade: print new recipe namePaul Eggleton
Make this consistent with "devtool add" so that the user knows where to find the new recipe. (From OE-Core rev: 28fea4a104ba85aded2ecfe891e9bf997d72a103) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-02-28devtool: upgrade: drop PR on upgradePaul Eggleton
The PR value should be reset to the default when upgrading, so we need to drop it from the newly created file. (From OE-Core rev: 4acf8a6912106dd3da5ceee9e30ccce86211d04b) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-02-28devtool: upgrade: eliminate unnecessary datastore copyPaul Eggleton
We aren't modifying the datastore copy here, so we don't need a copy at all. (From OE-Core rev: 9f05bf98d4dbcb991b684a2ab480c6638c6be292) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-02-28devtool: upgrade: fix several issues with extraction of new sourcePaul Eggleton
Fix several issues when extracting the new version source over the top of the old one (when the recipe is not fetching from a git repo): * Delete the old source first so we ensure files deleted in the new version are deleted. This also has the side-effect of fixing any issues where files aren't marked writeable in the old source and thus overwriting them failed (harfbuzz 1.1.3 contains such files). * Fix incorrect variable name in abspath statement that made it a no-op (From OE-Core rev: 4f7595a514661f0e2418393286849a1cb6c46f0d) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-02-28devtool: upgrade: fix constructing new branch from tarball releasesPaul Eggleton
When we do an upgrade from one tarball version to another we want to: 1) Check out the old version as a new branch 2) Record the changes between the old and new versions as a commit 3) Check out the old version with patches applied 4) Rebase that onto the new branch Where we went wrong was step #1 where instead we checked out the old version with patches applied as the new branch, which meant the rebase didn't do anything and any changes made by the patches to files still in the new version were wiped out. (From OE-Core rev: a4f3e6d5f4c549e36cce1e18801a565a3a3c9b0a) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>