aboutsummaryrefslogtreecommitdiffstats
path: root/scripts/lib/devtool
AgeCommit message (Collapse)Author
2017-02-07devtool: improve parse failure handlingpaule/devtool25Paul Eggleton
With the move to tinfoil2, the behaviour when parsing failed has changed a bit - exceptions are now raised, so handle these appropriately. Specifically when if parsing the recipe created when running devtool add fails, rename it to .bb.parsefailed so that the user can run bitbake afterwards without parsing being interrupted. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
2017-01-19devtool: fix source extraction to work with recipe specific sysrootsPaul Eggleton
When extracting source for a recipe within devtool (for extract, modify or upgrade) We need to redirect WORKDIR, STAMPS_DIR etc. under a temporary directory so that: (a) we pick up all files that get unpacked to the WORKDIR, and (b) we don't disturb the existing build However, with recipe-specific sysroots the sysroots for the recipe will be prepared under WORKDIR, and if we used the system temporary directory i.e. usually /tmp) as used by mkdtemp by default, then our attempts to hardlink files into the recipe-specific sysroots will fail on systems where /tmp is a different filesystem, and we'd have to fall back to copying the files which is a waste of time. Put the temp directory under the WORKDIR to prevent that from being a problem. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> [RP: Add needed mkdirhier call] Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-01-06meta/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). Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-12-22devtool: modify: fix usage on the kernelPaul Eggleton
When using devtool modify on the kernel, we have to do a bit of a dance with tinfoil instances because we only find out that we're working on a kernel recipe after tinfoil is initialised, but then we need to build kern-tools-native which we're doing just by running bitbake directly. With the tinfoil2 changes, a datastore for the recipe that we were keeping around across the opening and closing of tinfoil is no longer able to be used. Re-parse the recipe to avoid this problem. (In future this whole thing will be able to be done in the same tinfoil instance thanks to tinfoil2, but that refactoring is yet to be done.) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
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\) Signed-off-by: Joshua Lock <joshua.g.lock@intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2016-12-14devtool: extract: disable basehash mismatch errorsPaul Eggleton
Using the setVariable commands here followed by buildFile will result in "basehash mismatch" errors, and that's expected since we are deviating *at runtime* from what was previously seen by changing these variable values. Set BB_HASH_IGNORE_MISMATCH to turn off the errors. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
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.) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2016-12-14classes/patch: move in logic to commit for additional tasksPaul Eggleton
If PATCHTOOL is "git", and PATCH_COMMIT_FUNCTIONS is set to "1", for additional tasks between do_unpack and do_patch, make a git commit. This logic was previously implemented in devtool itself, but it makes more sense for it to be implemented in the patch class since that's where the rest of the logic is for this (or in lib/oe/patch.py). It also makes it possible for this to work with tinfoil2. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
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. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2016-12-14devtool: package: don't try to initialise tinfoil twicePaul Eggleton
setup_tinfoil() already calls prepare(), we don't need to call it again ourselves and doing so with tinfoil2 results in "ERROR: Only one copy of bitbake should be run against a build directory". Calling prepare() twice should probably still be allowed, so that ought to be fixed separately, but in the mean time this code is still wrong so fix it here. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2016-11-23devtool: fix handling of unicode characters from subprocess stdoutJiajie Hu
In previous implementation, a UnicodeDecodeError exception will be raised if multi-byte encoded characters are printed by the subprocess. As an example, the following command will fail in an en_US.UTF-8 environment because wget quotes its saving destination with '‘'(0xE2 0x80 0x98), while just the first byte is provided for decoding: devtool add recipe http://example.com/source.tar.xz The patch fixes the issue by avoiding such kind of incomplete decoding. Signed-off-by: Jiajie Hu <jiajie.hu@intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2016-11-23devtool: modify: support recipes with only local files as sourcePaul Eggleton
The hello-mod recipe is unusual in that it has only local files in SRC_URI and builds these out of ${WORKDIR}. When you use devtool modify on it, devtool puts all of those files in an "oe-local-files" subdirectory of the source tree, which is not ${S} (or ${B}) any more and thus building the recipe afterwards fails. It's a bit of a hack, but symlink the files in oe-local-files into the source tree (and commit the symlinks with an ignored commit so that the repo is clean) to work around the problem. We only do this at time of extraction, so any files added to or removed from oe-local-files after that won't be handled, but I think there's a limit to how far we should go to support these kinds of recipes - ultimately they are anomalies. I initially tried a hacky workaround where I set effectively set B = "${WORKDIR}" and that allowed it to build, but other things such as the LIC_FILES_CHKSUM checks still broke because they expected to find files in ${S}. Another hack where I set the sourcetree to point to the oe-local-files subdirectory works for hello-mod but not for makedevs since whilst that is similar, unlike hello-mod it does in fact have files in the source tree (since it has a patch that adds COPYING) and thus the same issue occurred. Also tweak one of the tests that tries devtool modify / update-recipe on the makedevs recipe to try building it since that would have caught this issue. Fixes [YOCTO #10616]. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2016-11-23devtool: update-recipe: support replacing remote patchesPaul Eggleton
If you have a patch remotely fetched in a recipe (e.g. from an http server) that needs updating then add a local version and substitute the entry in SRC_URI to point to it. One can argue about how desirable it is to be modifying patches fetched in this way, but then one can argue about how desirable it is to have such patches in the recipe in the first place - and in any case if devtool update-recipe is to correctly transfer changes to such patches made in the git repository within the source tree to the recipe then there isn't much choice but to do it this way. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2016-11-23devtool: update-recipe: fix handling of compressed local patchesPaul Eggleton
It is possible to use gzip or bzip2 to compress patches and still refer to them in compressed form in the SRC_URI value within a recipe. If you run "devtool modify" on such a recipe, make changes to the commit for the patch and then run devtool update-recipe, we need to correctly associate the commit back to the compressed patch file and re-compress the patch, neither of which we were doing previously. Additionally, add an oe-selftest test to ensure this doesn't regress in future. Fixes [YOCTO #8278]. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2016-11-23devtool: update-recipe: check output before treating it as a stringPaul Eggleton
As of the move to Python 3 and the fixes we applied at that time, bb.process.run() will return a byte array of length 0 rather than an empty string if the output is empty. That may be a bug that we should fix, but for now it's easiest to just check the result here before treating it as a string. This fixes running "devtool update-recipe" or "devtool finish" on a recipe which has no source tree, for example initramfs-framework. Fixes [YOCTO #10563]. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2016-11-07devtool: add "rename" subcommandPaul Eggleton
When you run devtool add on a source tree we attempt to figure out the correct name and version for the recipe. However, despite our best efforts, sometimes the name and/or version we come up with isn't correct, and the only way to remedy that up until now was to reset the recipe, delete the source tree and start again, specifying the name this time. To avoid this slightly painful procedure, add a "rename" subcommand that lets you rename the recipe and/or change the version. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2016-11-07devtool: finish: warn if moving recipe to unconfigured destination layerPaul Eggleton
If you run devtool finish to move a recipe created in the workspace by devtool add or devtool upgrade to a layer, and that layer is not currently included in bblayers.conf (perhaps unintentionally), then the recipe will no longer be visible to bitbake. In this scenario, show a warning so that the user isn't surprised by the recipe "going missing". Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2016-11-07devtool: finish: fix error if destination layer is not in bblayers.confPaul Eggleton
If devtool finish is run on a recipe where the recipe file itself is in the workspace (e.g. where devtool add / devtool upgrade has been used) and the specified destination layer is not in bblayers.conf, then we need to avoid running bitbake -c clean at the end because the recipe has been moved, but the bbappend is still present in the workspace layer at that point and so if we do it will fail due to the dangling bbappend. It's difficult to do the clean at the point we'd want to because tinfoil is holding bitbake.lock for most of the time, but in any case cleaning the recipe is less important than it used to be since we started managing the sysroot contents more strictly, so just disable cleaning under these circumstances to avoid the problem. Fixes [YOCTO #10484]. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2016-11-07devtool: add: show recipetool create outputPaul Eggleton
When running devtool add, instead of hiding the recipetool create output, change it so that it's appropriate to show in the devtool context and show it in real-time. This means that you get status output such as when a URL is being fetched (though currently no progress information.) recipetool create now has a hidden --devtool option to enable this display mode. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2016-10-25devtool: runqemu: work around runqemu script path assumptionPaul Eggleton
The new runqemu script assumes that if OECORE_NATIVE_SYSROOT is set then it shouldn't try to run bitbake to find out the values of various variables such as DEPLOY_DIR_IMAGE; this assumption is incorrect for the extensible SDK. To work around this, clear OECORE_NATIVE_SYSROOT in the environment when running runqemu. Fixes [YOCTO #10447]. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-10-05devtool: modify command fails to ignore source filesStephano Cetola
With recent changes to recipeutils, the list of local files returned by get_recipe_local_files could possibly include source files. This only happens when the recipe contains a SRC_URI using subdir= to put files in the source tree. These files should be ignored when populating the list of local files for oe-local-files directory. [YOCTO #10326] introduced in OE-Core revision 9069fef5dad5a873c8a8f720f7bcbc7625556309 Signed-off-by: Stephano Cetola <stephano.cetola@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-10-05devtool: deploy-target: Avoid unnecessary dependency on awk on the targetPeter Kjellerstedt
Relying on that awk is installed on the target just to extract the fourth column (i.e., the free volume size) from `df -P` is an unnecessary dependency for devtool deploy-target. As it is already using sed to mangle the output from `df -P`, this can easily be modified to only extract the free volume size. 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>
2016-10-05devtool: add: build nodejs-native if npm is needed and not availablePaul Eggleton
If the user runs devtool add on an npm:// URL (or source tree that uses node.js), and npm is not available, just build nodejs-native instead of telling the user they need to do it; if that fails because there isn't any such recipe (which would be the default, since it's not in OE-Core) then produce a slightly more readable error message hinting at what the user needs to do. Note that this forces the use of nodejs-native rather than npm on the host - this makes sense for two reasons: (1) we need it to be compatible with nodejs for the target, and (2) we have to have a recipe for that anyway, so allowing you to avoid having a recipe for the native version isn't really beneficial. There's a bit of a hack in here in order to allow this - for node.js sources that aren't fetched via npm we don't know that they are that until we've fetched and unpacked them, by which time we're inside recipetool and have an active tinfoil instance that will prevent bitbake being run. To avoid this being an issue, we allow recipetool to get to the point where we know we need npm and then exit with a specific exit code, at which point devtool can try to build it and then if that succeeds, it will re-execute recipetool. This is definitely not ideal, but it can't really be refactored and done properly until we do the tinfoil2 refactoring; in the mean time though we still want to be helpful to the user. Fixes [YOCTO #10337]. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-10-05devtool: add: display a warning for deprecated -f/--fetch optionPaul Eggleton
We want to remove the -f/--fetch option at some point (as you can now specify a URL as a positional argument instead) so display a warning that it's deprecated if it is used. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-10-05devtool: add: fix error message when only specifying a recipe namePaul Eggleton
We were supposed to be printing out the specified recipe name here but I forgot to specify a parameter for the string. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-09-19devtool: add: drop superfluous validation for recipe namePaul Eggleton
Now that recipeutils.validate_pn() properly validates characters used in the name, we can drop this bit checking for '/' since that's not permitted by validate_pn(). (The FIXME comment here - that I myself apparently wrote - is questionable since that function was clearly never intended to allow '/', perhaps I was misled because it was broken and did so). Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-09-19recipetool: create: support git short form URLsPaul Eggleton
In keeping with making recipetool create / devtool add as easy to use as possible, users shouldn't have to know how to reformat git short form ssh URLs for consumption by BitBake's fetcher (for example user@git.example.com:repo.git should be expressed as git://user@git.example.com/repo.git;protocol=ssh ) - instead we should just take care of that automatically. Add some logic in the appropriate places to do that. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-09-08devtool: update-recipe: support files with subdir=Paul Eggleton
It's rare but there are recipes that have individual files (as opposed to archives) in SRC_URI using subdir= to put them under the source tree, the examples in OE-Core being bzip2 and openssl. This broke devtool update-recipe (and devtool finish) because the file wasn't unpacked into the oe-local-files directory and thus when it came time to update the recipe, the file was assumed to have been deleted by the user and thus the file was erroneously removed. Add logic to handle these properly so that this doesn't happen. (We still have another potential problem in that these files become part of the initial commit from upstream, which could be confusing because they didn't come from there - but that's a separate issue and not one that is trivially solved.) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
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 ..."). 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]. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-08-25devtool: build_image: Fix recipe filterOla x Nilsson
The missing split() causes dev and dbg packages to match. Signed-off-by: Ola x Nilsson <ola.x.nilsson@axis.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2016-08-25devtool: Use the wildcard flag in update_recipe_patchOla x Nilsson
The --wilcard-version flag was only used in the srcrev variant of the update-recipe command. Signed-off-by: Ola x Nilsson <ola.x.nilsson@axis.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
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] Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-07-20devtool: add finish subcommandPaul Eggleton
Add a subcommand which will "finish" the work on a recipe. This is effectively the same as update-recipe followed by reset, except that the destination layer is required and it will do the right thing depending on the situation - if the recipe file itself is in the workspace (e.g. as a result of devtool add), the recipe file and any associated files will be moved to the destination layer; or if the destination layer is the one containing the original recipe, the recipe will be overwritten; otherwise a bbappend will be created to apply the changes. In all cases the layer path can be loosely specified - it could be a layer name, or a partial path into a recipe. In the case of upgrades, devtool finish will also take care of deleting the old recipe. This avoids the user having to figure out the correct actions when they're done - they just do "devtool finish recipename layername" and it saves their work and then removes the recipe from the workspace. Addresses [YOCTO #8594]. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
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". Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2016-07-20devtool: update-recipe: refactor to allow calling separatelyPaul Eggleton
This will be called by "devtool finish" to allow it to update the recipe or create the bbappend depending on the destination. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2016-07-20devtool: reset: refactor to allow calling separatelyPaul Eggleton
This will be called by "devtool finish" to allow it to reset the recipe at the end. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2016-07-20devtool: update-recipe: don't copy local files that haven't changedPaul Eggleton
If there are files in the oe-local-files directory which are identical to the original version, then we shouldn't be copying them to the destination layer. This is particularly important when using the -a option to create a bbappend. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2016-07-20devtool: update-recipe: find and use existing files directoriesPaul Eggleton
devtool update-recipe was defaulting to the ${BPN} named directory when adding patches next to a recipe, but that meant if you already had files in a ${BP} named directory (i.e. name and version) or "files" then you'd end up with two directories next to the recipe, which is usually not what you want. To avoid this, look through FILESPATH and take the first one that's the same level or one level down from the recipe and already exists, if any. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2016-07-12recipetool: create: support specifying a file as the local sourcePaul Eggleton
It is currently possible to specify a file (e.g. a tarball) on the local disk as the source, but you have to know to put file:// in front of it. There's really no need to force users to jump through that hoop if they really want to do this so check if the specified source is a file and prefix it with file:// if that's the case. Also ensure the same works for "devtool add" at the same time. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2016-07-12devtool: return specific exit code for incompatible recipesPaul Eggleton
Certain recipes cannot be used with devtool extract / modify / upgrade - usually because they don't provide any source. Return a specific exit code (4) so that scripts such as scripts/contrib/devtool-stress.py know the difference between this and a genuine failure. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2016-07-12devtool: reset: allow reset to work if the recipe file has been deletedPaul Eggleton
We were attempting to open the recipe file unconditionally here - we need to account for the possibility that the recipe file has been deleted or moved away by the user. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2016-07-12devtool: update-recipe: fix --initial-rev optionPaul Eggleton
In OE-Core revision 7baf57ad896112cf2258b3e2c2a1f8b756fb39bc I changed the default update-recipe behaviour to only update patches for commits that were changed; unfortunately I failed to handle the --initial-rev option which was broken after that point. Rework how the initial revision is passed in so that it now operates correctly. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2016-06-14devtool: reset: allow specifying multiple recipesPaul Eggleton
Allow specifying more than one recipe on the devtool reset command line. Also tweak the help text slightly. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-06-02scripts: python3: change python to python3 in shebangEd Bartosh
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-06-02scripts: python3: convert iterables to listsEd Bartosh
Converted return value of items() keys() and values() to lists when dictionary is modified in the loop and when the result is added to the list. Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-06-02scripts: Fix encoding errors for python3Ed Bartosh
Moved call of decode('utf-8') as close as possible to call of subprocess API to avoid calling it in a lot of other places. Decoded binary data to utf-8 where appropriate to fix devtool and recipetool tests in python 3 environment. Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
2016-06-02scripts: Replace basestring -> str for python3Ed Bartosh
Python 3 doesn't have basestring type as all string are unicode strings. Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
2016-06-02scripts: Fix deprecated dict methods for python3Ed Bartosh
Replaced iteritems -> items, itervalues -> values, iterkeys -> keys or 'in' Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
2016-06-02classes/lib: Update xrange -> range for python3Richard Purdie
xrange() no longer exists in python 3, use range() Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>