summaryrefslogtreecommitdiffstats
path: root/scripts/lib/devtool/upgrade.py
Commit message (Collapse)AuthorAgeFilesLines
* meta/lib+scripts: Convert to SPDX license headersRichard Purdie2019-05-091-12/+1
| | | | | | | | | | | | | | | | | | | | | | | 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>
* devtool: add --all option to check-upgrade-statusRoss Burton2019-02-021-1/+2
| | | | | | | | | | 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>
* devtool: add a command to print an overall list of recipes that can be updatedAlexander Kanavin2019-01-261-0/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* logging: use warning instead warnChen Qi2018-07-261-3/+3
| | | | | | | | | | | | | | | | 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>
* devtool/upgrade: fix the order of license checksum representationChen Qi2018-05-151-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* devtool: rename the suggested license change tag to 'License-Update:'Alexander Kanavin2018-01-181-2/+2
| | | | | | | (From OE-Core rev: 3905ae20330f204f3c8997e2d5aaf15dcf5a860c) Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: add license checksum change handling to 'devtool upgrade'Alexander Kanavin2017-12-181-2/+73
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* devtool: provide useful defaults for version/commit when upgrading recipesAlexander Kanavin2017-12-181-4/+12
| | | | | | | | | | 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>
* devtool: add a 'latest-version' commandAlexander Kanavin2017-12-181-0/+26
| | | | | | | | | | | | | | | | | | | | | | | | | 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>
* devtool: implement conditional patch handlingPaul Eggleton2017-11-111-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* devtool: upgrade: reformat --no-patch warning messagePaul Eggleton2017-11-111-4/+2
| | | | | | | | | | | | * 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>
* devtool: upgrade: automatically handle changes to source subdirectoryPaul Eggleton2017-11-111-5/+23
| | | | | | | | | | | | | | | | | 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>
* devtool: upgrade: show messages before source extraction stepsPaul Eggleton2017-11-111-0/+2
| | | | | | | | | | 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>
* devtool: upgrade: handle recipes that use named SRC_URI checksumsPaul Eggleton2017-11-111-13/+40
| | | | | | | | | | | | | | | | | | | | | 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>
* devtool: show some warnings for upgrade versionsPaul Eggleton2017-11-111-2/+7
| | | | | | | | | | | | | | | | * 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>
* devtool: upgrade: improve performance and show progress when adding filesPaul Eggleton2017-11-111-2/+9
| | | | | | | | | | | | | | | | | | | | | | | 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>
* devtool: upgrade: fix not committing deleted files with older git versionsPaul Eggleton2017-11-111-1/+1
| | | | | | | | | | | | | | 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>
* devtool: upgrade: fix accidentally swapped parametersPaul Eggleton2017-11-111-1/+1
| | | | | | | | | | | | | | | | 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>
* devtool: ensure recipes devtool is working on are unlocked within the eSDKPaul Eggleton2017-09-181-3/+6
| | | | | | | | | | | | | | | | | | | | | | | | | 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>
* devtool: rework source extraction so that dependencies are handledPaul Eggleton2017-09-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* devtool: upgrade: check that user has configured git properlyPaul Eggleton2017-09-111-1/+26
| | | | | | | | | | | | | | | | | | | 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>
* devtool: upgrade: workaround for recipes which apply patches conditional ↵Paul Eggleton2017-08-311-1/+1
| | | | | | | | | | | | | | | | | | | | 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>
* devtool: upgrade: fix handling of non-absolute pathsPaul Eggleton2017-08-311-0/+3
| | | | | | | | | | | | | | | | 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>
* devtool: upgrade: enable branch checking when revision is providedChang Rebecca Swee Fun2017-08-231-5/+22
| | | | | | | | | | | | | | | | | 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>
* recipetool: create: reimplement fetching with normal fetch/unpack tasksPaul Eggleton2017-07-211-2/+8
| | | | | | | | | | | | | | | | | | | | 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>
* devtool: upgrade: fix error of import recipeutilsLuck Hoang2017-02-231-0/+4
| | | | | | | | | | | 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>
* meta/scripts: Various getVar/getVarFlag expansion parameter fixesRichard Purdie2017-01-091-1/+1
| | | | | | | | | | | | | | | | | 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>
* scripts: remove True option to getVar callsJoshua Lock2016-12-161-10/+10
| | | | | | | | | | | | | 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>
* devtool: fix extraction of source to work in memres modePaul Eggleton2016-12-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* devtool / recipetool: use tinfoil parsing APIPaul Eggleton2016-12-141-1/+1
| | | | | | | | | | | | | 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>
* scripts: ensure tinfoil is shut down correctlyPaul Eggleton2016-09-031-41/+44
| | | | | | | | | | | 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>
* lib/oe/patch: commit with a dummy user/email when PATCHTOOL=gitPaul Eggleton2016-09-031-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* devtool/recipetool/meta: Adapt to bitbake API changes for ↵Richard Purdie2016-08-181-1/+1
| | | | | | | | | | | | | | 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>
* devtool: upgrade: record original recipe filesPaul Eggleton2016-07-201-6/+10
| | | | | | | | | | | | 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>
* scripts: Fix deprecated dict methods for python3Ed Bartosh2016-06-021-1/+1
| | | | | | | | | | 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>
* devtool: upgrade: clarify help text for --srcrev optionPaul Eggleton2016-05-251-1/+1
| | | | | | | | | | 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>
* devtool: upgrade: tweak conflict handlingPaul Eggleton2016-05-251-3/+9
| | | | | | | | | | | | | | | | 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>
* devtool: upgrade: handle upgrading recipes with a versioned inc filePaul Eggleton2016-05-251-0/+8
| | | | | | | | | | | | | | 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>
* devtool: upgrade: handle recipes where source is not first entry in SRC_URIPaul Eggleton2016-04-151-1/+9
| | | | | | | | | | | | | | 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>
* devtool: upgrade: print new recipe namePaul Eggleton2016-02-281-0/+1
| | | | | | | | | | | 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>
* devtool: upgrade: drop PR on upgradePaul Eggleton2016-02-281-3/+4
| | | | | | | | | | | 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>
* devtool: upgrade: eliminate unnecessary datastore copyPaul Eggleton2016-02-281-4/+3
| | | | | | | | | | | 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>
* devtool: upgrade: fix several issues with extraction of new sourcePaul Eggleton2016-02-281-2/+12
| | | | | | | | | | | | | | | | | 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>
* devtool: upgrade: fix constructing new branch from tarball releasesPaul Eggleton2016-02-281-1/+1
| | | | | | | | | | | | | | | | | | | | 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>
* devtool: upgrade: fix renaming of recipe if PV is not in namePaul Eggleton2016-02-281-11/+11
| | | | | | | | | | | | | If the actual value of PV isn't in the name of the recipe (for example, a git or svn recipe) there's no point trying to rename it. Additionally, we already have the original filename, there's no need to guess it - just pass it in. (From OE-Core rev: e144db3650b4a7c0a59066621905f34a5400303e) 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>
* devtool: upgrade: fix moving version-specific files directoryPaul Eggleton2016-02-281-1/+1
| | | | | | | | | | | We were trying to move this from the current directory instead of the path. Let's just use shutil.move() instead of shelling out to mv. (From OE-Core rev: 60454a0ba154d6c777e0c2b05b887b4e4fcde986) 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>
* devtool: upgrade: fix version argument checkingPaul Eggleton2016-02-281-2/+7
| | | | | | | | | | | | | | | | For recipes that specify SRCREV, the code here wasn't quite doing the right thing. If the recipe has a SRCREV then that needs changing on upgrade, so ensure that the user specifies it. If it doesn't, then it'll be "INVALID" not None since the former is the actual default, so handle that properly as well. Additionally an unset variable was being erroneously passed when raising the error about the version being the same leading to a traceback, so fix that as well. (From OE-Core rev: 1d0f821371d1cb93e30fad86f0c20e38cb93b54b) 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>
* devtool: upgrade: drop superfluous call to validate_pnPaul Eggleton2016-02-281-5/+0
| | | | | | | | | | | | | The recipename argument to devtool upgrade specifies an existing recipe, so by definition the name will be valid (or it won't exist) - we don't need to validate it ourselves, that's only needed for situations like in devtool add where we're creating a new recipe. (From OE-Core rev: 1e2bc7d861555a04350a87f19047efdc717046be) 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>
* devtool: upgrade: make source tree path optionalPaul Eggleton2016-02-281-7/+15
| | | | | | | | | | | | Make devtool upgrade consistent with devtool add/modify in defaulting to sources/<recipename> under the workspace if no source tree path is specified. (From OE-Core rev: 8a952407b192313515e91570632446b6dff01665) 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>
* devtool: categorise and order subcommands in help outputPaul Eggleton2016-02-211-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | The listing of subcommands in the --help output for devtool was starting to get difficult to follow, with commands appearing in no particular order (due to some being in separate modules and the order of those modules being parsed). Logically grouping the subcommands as well as being able to exercise some control over the order of the subcommands and groups would help, if we do so without losing the dynamic nature of the list (i.e. that it comes from the plugins). Argparse provides no built-in way to handle this and really, really makes it a pain to add, but with some subclassing and hacking it's now possible, and can be extended by any plugin as desired. To put a subcommand into a group, all you need to do is specify a group= parameter in the call to subparsers.add_parser(). you can also specify an order= parameter to make the subcommand sort higher or lower in the list (higher order numbers appear first, so use negative numbers to force items to the end if that's what you want). To add a new group, use subparsers.add_subparser_group(), supplying the name, description and optionally an order number for the group itself (again, higher numbers appear first). (From OE-Core rev: e1b9d31e6ea3c254ecfe940fe795af44761e0e69) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
generated by cgit v1.2.3-54-g00ecf (git 2.39.0) at 2024-11-12 00:56:35 +0000