summaryrefslogtreecommitdiffstats
path: root/scripts/lib/devtool
Commit message (Collapse)AuthorAgeFilesLines
...
* 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: finish: fix "layer not in bblayers.conf" warning when path specifiedPaul Eggleton2017-11-111-2/+4
| | | | | | | | | | | | | | | | | devtool finish will check if the destination layer is part of bblayers.conf so that we avoid the user getting confused about the recipe vanishing from their configuration if it isn't. devtool finish also accepts a path underneath a layer so that you have a bit more control over where it ends up. However if you used a path underneath a layer then it wasn't converting this to the base of the layer before checking it against BBLAYERS, thus the warning was being shown erroneously in that case. (From OE-Core rev: ab1b8d55e551fea3e8656aab7a786d1bfec62d0f) 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: finish: ensure repository is clean before proceedingPaul Eggleton2017-11-112-2/+32
| | | | | | | | | | | | | | | | | | If the git repository for a recipe in the workspace has uncommitted changes in it then it's possible that the user has forgotten to commit something, so check and exit if there are any. Provide a -f/--force option to continue in the case where the uncommitted changes aren't needed. Separately, if the repository is in the middle of a rebase or git am / apply then error out (without the opportunity to force) since the user really needs to sort this out before finishing. (From OE-Core rev: bfebd18982c0c82ef2da63ec8f22175c93b2e308) 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: reset: print source tree base pathPaul Eggleton2017-11-111-5/+5
| | | | | | | | | | | | | If S points to a subdirectory of the source rather than the "base" of the source tree then print that rather than the subdirectory path when telling the user they need to remove the source tree, since that is the directory that they will need to remove. (From OE-Core rev: 9e8808099046478e98c6cf1903dc6787d69132fc) 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: make find-recipe and edit-recipe always work with any recipePaul Eggleton2017-11-111-12/+14
| | | | | | | | | | | | | | After some reconsideration I think it's a bit annoying for users to be forced to use an option to work with recipes where the file isn't in the workspace, so let's just have these commands check the workspace first for the recipe, and if it isn't there then load the cache and get it that way. (From OE-Core rev: 46683c61069a386658676a79d797062404bf1140) 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-113-3/+23
| | | | | | | | | | | | | | | | * 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: fix handling of oe-local-files when source is in a subdirectoryPaul Eggleton2017-11-111-9/+15
| | | | | | | | | | | | | | | | | | If S points to a subdirectory of the source rather than the "base" of the source tree then we weren't handling the oe-local-files directory properly - it got extracted to the base of the tree but devtool update-recipe and devtool finish assumed it would be under S which would be the subdirectory, thus it would be missing and devtool would assume the files had been deleted and remove them from the recipe. Record the base of the source tree in the bbappend and read it into the in-memory workspace so we can use that to find out where oe-local-files should be found. (From OE-Core rev: 30d2ea67b2c4727e23d06a35745b1afa64b130cc) 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: standard: Expand SRCREV before using it in _update_recipe_srcrevPeter Kjellerstedt2017-10-161-1/+1
| | | | | | | | | | | | | | | | If SRCREV contains a variable reference, any devtool command that would try to update it would fail. E.g., if SRCREV = "R${PV}", then devtool finish without having committed any changes would fail with: oe.patch.CmdError: Command Error: 'sh -c 'git format-patch R${PV} -o /tmp/oepatchb_doareb -- .'' exited with 0 Output: fatal: bad revision 'R' (From OE-Core rev: 094499c819722ad698ccb64ec65dd439b211c31c) Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* scripts: drop True option to getVar callsMing Liu2017-09-261-4/+4
| | | | | | | | | Search made with the following regex: getVar ?\((.*), True\). (From OE-Core rev: b848c3cb495905605283c57c79f2ed8ca17758db) Signed-off-by: Ming Liu <liu.ming50@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: ensure recipes devtool is working on are unlocked within the eSDKPaul Eggleton2017-09-183-11/+56
| | | | | | | | | | | | | | | | | | | | | | | | | 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-182-147/+64
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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/standard: set a preferred provider when adding a new recipe with devtoolJuan M Cruz Alcaraz2017-09-131-0/+42
| | | | | | | | | | | | | | | | | | | | A recipe added with "devtool add" requires to be able to take precedence on recipes previously defined with PREFERRED_PROVIDER. By adding the parameter "--provides" to "devtool add" it is possible to specify an element to be provided by the recipe. A devtool recipe can override a previous PREFERRED_PROVIDER using the layer configuration file in the workspace. E.g. devtool add my-libgl git@git://my-libgl-repository --provides virtual/libgl [YOCTO #10415] (From OE-Core rev: adeea2fe6895898a5e6006e798898f0f5dabd890) Signed-off-by: Juan M Cruz Alcaraz <juan.m.cruz.alcaraz@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@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: status: Sort entries before printingOla x Nilsson2017-09-111-1/+1
| | | | | | | | | | Sorted entries are easier to read. (From OE-Core rev: d0a123ec564f6d36977e472f8bc63f9c050ee616) Signed-off-by: Ola x Nilsson <olani@axis.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: add: add explicit srcrev/branch optionsPaul Eggleton2017-08-311-2/+15
| | | | | | | | | | | | | | | | At the moment when fetching source from a git repository you have to know that you can specify the revision and branch in the URL with ';rev=' and ';branch=' respectively, and you can also get thrown off by the shell splitting on the ; character if you forget to surround the URL in quotes. Add explicit -S/--srcrev and -B/--srcbranch options (consistent with devtool upgrade) to make this easier for the user to discover and use. (The rev and branch URL parameters will continue to work, however.) (From OE-Core rev: 2d86cac853d6daa496c0315a5cb0662ebf1165b0) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: edit-recipe: fix regressionPaul Eggleton2017-08-311-4/+11
| | | | | | | | | | | | | | OE-Core commit 5a16b3c804c5eca331a1c08a7ce31a54909af105 attempted to use the same function to get the path to a recipe as the new "find-recipe" command it implemented, except that cannot work because (a) it didn't return anything and (b) event if it had tried, a command function can only return an exit code and we don't want that for find-recipe if it succeeded. Split out a separate reusable function for both commands. (From OE-Core rev: d5191840212adbf480961ba6fc68e1ab17e5a77a) Signed-off-by: Paul Eggleton <paul.eggleton@linux.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: update-recipe: ensure patches get deleted in srcrev modePaul Eggleton2017-08-311-1/+2
| | | | | | | | | | | | | | | | Patches that we identify as having been "deleted" (i.e. patches in SRC_URI that no longer appear in the git tree) need to be dropped even if we're updating in srcrev mode. This fixes the case where HEAD of the git tree is valid upstream (i.e. no extra commits), but there are patches left over in the recipe, e.g. when we do devtool upgrade and then all of the commits rebased on top of the new branch get skipped. Fixes [YOCTO #11972]. (From OE-Core rev: 350f83dc1e317aeb93539f13966caca6d894f569) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: deploy-target: Support stripped libs and execsTobias Hagelborn2017-08-271-4/+29
| | | | | | | | | | | | | | | | | | | | New devtool deploy-target option --strip which enables deploying stripped binaries, saving some space on target. * Copies the files of ${D} into a new directory and strips them in place * Used oe.package.strip_execs for stripping directory * Added devtool.conf option "strip" for changing default behavior Config example: [Deploy] strip = true [YOCTO #11227] (From OE-Core rev: 7f10c5118793da6ded59ae6e60e796152dbd7ca3) Signed-off-by: Tobias Hagelborn <tobiasha@axis.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: import: new plugin to import the devtool workspaceLeonardo Sandoval2017-08-232-0/+180
| | | | | | | | | | | | | | | | Takes a tar archive created by 'devtool export' and imports (untars) it into the workspace. Currently the whole tar archive is imported, there is no way to limit what is imported. https://bugzilla.yoctoproject.org/show_bug.cgi?id=10510 [YOCTO #10510] (From OE-Core rev: 2de8ba89ef10fefcc97246dfeb4b8d1e48ee8232) Signed-off-by: Leonardo Sandoval <leonardo.sandoval.gonzalez@linux.intel.com> Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: append md5sum only if not already presentLeonardo Sandoval2017-08-231-2/+5
| | | | | | | | | | | In case the proposed md5sum to be appended to the .devtool_md5 file is already present, do not append it. (From OE-Core rev: f958c5cba3b0d24ca696b2b707857009c9a7b5b8) Signed-off-by: Leonardo Sandoval <leonardo.sandoval.gonzalez@linux.intel.com> Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: export: new plugin to export the devtool workspaceLeonardo Sandoval2017-08-231-0/+119
| | | | | | | | | | | | | | | | | | By default, exports the whole workspace (all recipes) including the source code. User can also limit what is exported with --included/--excluded flags. As a result of this operation, a tar archive containing only workspace metadata and its corresponding source code is created, which can be properly imported with 'devtool import'. https://bugzilla.yoctoproject.org/show_bug.cgi?id=10510 [YOCTO #10510] (From OE-Core rev: f9bc3b5101b554a72298266519dbdd1497f262a6) Signed-off-by: Leonardo Sandoval <leonardo.sandoval.gonzalez@linux.intel.com> 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>
* devtool: sdk-update: fix pulling updates from gitAndrea Galbusera2017-08-091-1/+1
| | | | | | | | | | | | | Commit 4657bc9d165e51981e034e73e7b92552e873eef7 replaced the git pull logic with the git fetch + git reset --hard combo, but resetting to HEAD does not really pull in new commits from remote... Replace with resetting to the upstream branch instead. (From OE-Core rev: 0dcdb146f59a184419bffd4f24cdf8343a43c0ea) Signed-off-by: Andrea Galbusera <gizero@gmail.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: fix handling of errors during task executionPaul Eggleton2017-08-091-0/+10
| | | | | | | | | | | | | | | | | | | * If an error is logged while executing a task, we need to ensure we exit instead of assuming everything went OK. * If we receive CookerExit, the server is shutting down and we need to stop waiting for events and probably exit (knotty does this). This will occur if an exception or bb.fatal() happens during an event handler. This fixes a couple of issues highlighted when using devtool upgrade or modify on a non-supported recipe with intel-iot-refkit together with bitbake master, but I'd be very surprised if it were hard to reproduce in other scenarios. (From OE-Core rev: 65e644368fc9c294af96906528ee0cf30305e0a6) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: standard: enable options for PREMIRRORS and MIRRORSChang Rebecca Swee Fun2017-07-211-0/+3
| | | | | | | | | | | | Since we have provide an option to manually enable PREMIRRORS and MIRRORS in recipetool, we need to make sure devtool is having the same options as devtool uses recipetool in creating new recipes. (From OE-Core rev: 198bddeb928a318c3ad168bcb4f83b5cd9a604fb) Signed-off-by: Chang Rebecca Swee Fun <rebecca.swee.fun.chang@intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: find-recipe: enable new subcommand for devtoolChang Rebecca Swee Fun2017-07-211-4/+14
| | | | | | | | | | | | | | | | | | | devtool find-recipe will prints out the path to the recipe in a workspace. This subcommand can also help to find recipe outside of current workspace using "-a" or "--any-recipe" option. This enhancement helps developer to get the recipe path when working with devtool. [YOCTO #11434] (From OE-Core rev: 5a16b3c804c5eca331a1c08a7ce31a54909af105) Signed-off-by: Chang Rebecca Swee Fun <rebecca.swee.fun.chang@intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* scriptutils: pass in logger as parameterChang Rebecca Swee Fun2017-07-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | logger was not defined in scriptutils.py based on the observation in python traceback. Traceback (most recent call last): File "/workdir/poky/scripts/devtool", line 351, in <module> ret = main() File "/workdir/poky/scripts/devtool", line 338, in main ret = args.func(args, config, basepath, workspace) File "/workdir/poky/scripts/lib/devtool/utilcmds.py", line 55, in edit_recipe return scriptutils.run_editor(find_recipe(args, config, basepath, workspace)) File "/workdir/poky/scripts/lib/scriptutils.py", line 141, in run_editor logger.error("Execution of '%s' failed: %s" % (editor, exc)) NameError: name 'logger' is not defined We pass in logger as parameter to run_editor() from where it has been called (devtool/utilcmds.py and recipetool/newappend.py), which both modules already has logger setup. (From OE-Core rev: 21f04b61973dd9029f0e6bff5445e31cd762bf32) Signed-off-by: Chang Rebecca Swee Fun <rebecca.swee.fun.chang@intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: Setup logging before calling prepareRichard Purdie2017-07-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | This avoids test failures like: INFO - ====================================================================== INFO - FAIL [1.755s]: test_devtool_layer_plugins (devtool.DevtoolTests) INFO - ---------------------------------------------------------------------- INFO - Traceback (most recent call last): File "/media/build1/poky/meta/lib/oeqa/core/decorator/__init__.py", line 32, in wrapped_f return func(*args, **kwargs) File "/media/build1/poky/meta/lib/oeqa/selftest/cases/devtool.py", line 1354, in test_devtool_layer_plugins self.assertEqual(result.output, s[::-1]) AssertionError: "NOTE: Starting bitbake server...\noY senu[36 chars]rciM" != "oY senuZ s'enoynA morF tiforP oN edaM tfosorciM" - NOTE: Starting bitbake server... oY senuZ s'enoynA morF tiforP oN edaM tfosorciM INFO - ---------------------------------------------------------------------- since there is corruption in the output. Setting the logging up before calling tinfoil.prepare() resolves this. (From OE-Core rev: 3c479fb17ae4d3e7e5f0889af0f68257ef66475c) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* recipetool: create: refactor code for ensuring npm is availablePaul Eggleton2017-07-212-57/+8
| | | | | | | | | | | | | | | | | | | Across devtool and recipetool we had an ugly set of code for ensuring that we can call an npm binary, and much of that ugliness was a result of not being able to run build tasks when tinfoil was active - if recipetool found that npm was required and we didn't know beforehand (e.g. we're fetching from a plain git repository as opposed to an npm:// URL where it's obvious) then it had to exit and return a special result code, so that devtool knew it needed to build nodejs-native and then call recipetool again. Now that we are using real build tasks to fetch and unpack, we can drop most of this and move the code to the one place where it's still needed (i.e. create_npm where we potentially have to deal with node.js code in a plain source repository). (From OE-Core rev: 8450de16ddb02d863204b411a94c6d84e0f88817) 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: extract: refactor kern-tools-native handlingPaul Eggleton2017-07-211-32/+5
| | | | | | | | | | | | When extracting linux-yocto kernel source, we don't need to dance around shutting down and starting up tinfoil anymore, we can just execute the tasks as needed when needed using tinfoil's new build_targets() function. This allows us to tidy up the code structure a bit. (From OE-Core rev: 5c7f5031023fb74b5f2f26d6b3c829981f2f54d2) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool/standard: Fix lock in _prep_extract_operationAníbal Limón2017-06-121-0/+1
| | | | | | | | | | | | | | | | | | | If for any reason the parse_recipe fail in extract command the process gets locked because Cooker is expecting the finish event by tinfoil. For example: $ devtool extract remake /tmp/remake ERROR: remake is unavailable: remake was skipped: PREFERRED_PROVIDER_virtual/make set to make, not remake (From OE-Core rev: 2c0062b59178fa668b26487b6d2f1e81a0d868e0) Signed-off-by: Aníbal Limón <anibal.limon@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: deploy-target: Let script continue even if rm failsDaniel Lublin2017-06-031-1/+1
| | | | | | | | | | | | | | The remote script is run with `set -e`, so doing rm without -f on a $file that is already gone will exit the whole script, failing any redeployment. Assume a use case where packages sometimes produces certain test binaries stored on volatile media (tmpfs), and where the system is occasionally rebooted. (From OE-Core rev: db54c9a22a9b66c673df8e836de5e47fc9edda0b) Signed-off-by: Daniel Lublin <daniel@lublin.se> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: Compare abspath of both B and SOla x Nilsson2017-06-031-1/+1
| | | | | | | | | | | | | | | | Either both or none of the paths must be passed through os.path.abspath or things like 'A//B', 'A/./B/', and 'A/B/' in S will cause unintentional mismatches even when B = "${S}". Using os.path.abspath for both seems more likely to be correct as that will also handle the case where ${B} != ${S} but the abspaths are equal. (From OE-Core rev: 061f2aab40fecbfe0dcb928baa95d6b3a6b45eed) Signed-off-by: Ola x Nilsson <olani@axis.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: deploy-target: Don't use find -execDaniel Lublin2017-06-031-1/+5
| | | | | | | | | | | find may be provided by busybox, which might be compiled without support for -exec. (From OE-Core rev: 404e8e3661469175e1ea087ebfaf3a7867bf4df2) Signed-off-by: Daniel Lublin <daniel@lublin.se> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool/standard.py: Enable perf to be buildableSaul Wold2017-05-251-1/+4
| | | | | | | | | | | | | | | | | | | Perf is a tool build from the kernel source, which is normally available in /work-shared/..., but when devtool is used to modify the kernel source code, perf is not buildable since it gets an error about being unable to add a depends to a non-exisit task do_patch. This patch removes do_patch from the SRCTREECOVEREDTASKS and creates an empty do_patch task to enable the VarFlags code to have someplace to attach depends information to. [YOCT #11120] (From OE-Core rev: 86c793595e560e7bc52e3cd2a2752746e6adcb76) Signed-off-by: Saul Wold <sgw@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: extract: drop erroneous bb.event.TaskStartedPaul Eggleton2017-04-141-1/+0
| | | | | | | | | | | This is a non-existent event - we already have the actual bb.build.TaskSucceeded further down in the list hence why it wasn't noticed earlier. (From OE-Core rev: 4e059a5ceb6f44401154e89e37f56de1d664a7cb) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: extract: fix handling of failed tasksPaul Eggleton2017-04-141-0/+3
| | | | | | | | | | | | | If a task such as do_fetch fails when we're extracting source for a recipe (within devtool modify / upgrade / extract / sync) then we should naturally stop processing instead of blundering on; in order to do that we need to be listening for the TaskFailed event. Thanks to Richard Purdie for noticing and fixing this. (From OE-Core rev: 9174b845bf6a6be7753bf6b921959b1f3f2dcbc0) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: modify: add --keep-temp option for debuggingPaul Eggleton2017-04-141-1/+2
| | | | | | | | | | | | Most of the other extract-based commands have this option but oddly I left it out for modify - I guess because if I was debugging an issue here I just used devtool extract to do so, but there's no reason why we can't have it here and it is useful. (From OE-Core rev: 98fbc46e1a51237213bd7825a922389d3ab2ad9b) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: add: prevent repeatedly running recipetoolPaul Eggleton2017-04-131-0/+4
| | | | | | | | | | | | If recipetool returns with exit code 14 this means devtool needs to build nodejs-native and then call it again. If recipetool returns exit code 14 again then clearly something has gone wrong and we should just quit with an error. (From OE-Core rev: 8d7cced6e06d7c2037f5ab75ac859f501129532e) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: add: fix node.js/npm handling with recipe specific sysrootsPaul Eggleton2017-04-132-12/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The change over to recipe specific sysroots means that we can no longer get a known location simply from configuration for the npm binary - we need to get the recipe sysroot for nodejs-native, look there for npm if we need to check it's present, and add that to PATH when calling out to npm. Unfortunately this means anywhere we need to get that path we have to have parsed all recipes, otherwise we have no reliable way of resolving nodejs-native. Thus we have to change recipetool create to always parse all recipes (the structure of the code does not allow us to do this conditionally). In the worst case, if npm hasn't already been added to its own sysroot and we are fetching from a source repository rather than an npm registry, this gets a bit ugly because we end up parsing recipes three times: 1) recipetool startup, which then fetches the code and determines it's a node.js module, finds that npm isn't available and then exits with a specific error to tell devtool it needs to build npm 2) when we invoke bitbake -c addto_recipe_sysroot nodejs-native 3) when we re-invoke recipetool This code is badly in need of refactoring, but now is unfortunately not the time to do that, so we're going to have to live with this ugliness for now. Fixes [YOCTO #10992]. (From OE-Core rev: acfdbd796c99882b8586023c8c6b848716105c8d) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: point runqemu to correct native bindirbrian avery2017-04-051-1/+3
| | | | | | | | | | | | | | devtool/runqemu.py was relying on STAGING_BINDIR_NATIVE to find the host tools it needed like qemu-system-<arch>. In the post RSS world, this no longer exists. This patch points it to {STAGING_DIR}/{BUILD_ARCH}/{bindir_native}. [YOCTO #11223] (From OE-Core rev: 1910f9e9336bfedc8278a3bc02e7e7f934a4fc86) Signed-off-by: brian avery <brian.avery@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: open kconfig fragment in binary modeStephano Cetola2017-03-281-1/+1
| | | | | | | | | | | | | | When devtool writes to the kconfig fragment, it writes the output of the diff command returned from pipe.communicate(). This function returns binary objects. We should open the kconfig fragment file in binary mode if we expect to write binary objects to it. [YOCTO #11171] (From OE-Core rev: 72bec63ab0e78753fb6ed1794d11beef9485c014) Signed-off-by: Stephano Cetola <stephano.cetola@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: tidy up handling of parse failuresPaul Eggleton2017-03-221-2/+9
| | | | | | | | | | | | Since the tinfoil2 refactoring, if an error occurred during parsing, we were showing a traceback and not correctly exiting (since we weren't calling shutdown()). Fix both of these issues. (From OE-Core rev: 18304036e1b513fd12c049dbf549ba75c503ed84) 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>
generated by cgit v1.2.3-54-g00ecf (git 2.39.0) at 2024-11-15 14:20:05 +0000