summaryrefslogtreecommitdiffstats
path: root/scripts
Commit message (Collapse)AuthorAgeFilesLines
* recipetool: create: add basic support for generating linux kernel recipesPaul Eggleton2016-03-021-0/+99
| | | | | | | | | | | | | | Add support for detecting a Linux kernel source tree and generating a basic kernel recipe using meta-skeleton's linux-yocto-custom recipe as a base. Implements [YOCTO #8981]. (From OE-Core rev: 39cab544b80ca4450106c9ede3180929ba24703c) 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>
* recipetool: create: add support for out-of-tree kernel modulesPaul Eggleton2016-03-021-0/+152
| | | | | | | | | | | | | | | Detect kernel modules by looking for #include <linux/module.h>, and handle the various styles of Makefile that appear to be used. I was able to use this code to successfully build a number of external kernel modules I found. Implements [YOCTO #8982]. (From OE-Core rev: a85604f2eb2438b4caf0832c2ea15b5822f7e9a1) 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>
* combo-layer: handle empty commits during "init --history"Patrick Ohly2016-03-021-1/+1
| | | | | | | | | | | | | | | | | When importing the components during the "combo-layer init" with full history and relocation into a destination directory, components with empty commits were not handled because the "mv" command was invoked with just one parameter. Replacing that with a find/xargs pair avoids the problem and should also fix the handling of filenames with special characters (in particular spaces). (From OE-Core rev: fd9d08b8ba512151615a03fda61a103760a0683c) Signed-off-by: Patrick Ohly <patrick.ohly@intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* wic: don't throw away our created swap partitionChristopher Larson2016-02-281-0/+1
| | | | | | | | | | | | | We were creating the partition, mkswap'ing it, and then not dd'ing it into place in the final image, as source_file wasn't being set for swap partitions. This would result in a swap partition that couldn't be enabled on target until mkswap was run. (From OE-Core rev: 7580942a66f84c2120763c2d9665e2cec8e25138) Signed-off-by: Christopher Larson <chris_larson@mentor.com> Signed-off-by: Ross Burton <ross.burton@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: modify: fix source tree default name when mapping virtualsPaul Eggleton2016-02-281-17/+18
| | | | | | | | | | | | | | If you for example ran devtool modify virtual/libusb0 without specifying a source tree path, the default was <workspace>/sources/virtual/libusb0 which isn't correct - it should be using the mapped name i.e. libusb-compat (in the default OE-Core configuration). Reorder some of the code to ensure that the mapped name is used. (From OE-Core rev: c51736df17da8e6e561dd5b7ce59cb08254da870) 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: add: tweak auto-determining name failure messagePaul Eggleton2016-02-281-1/+1
| | | | | | | | | | As suggested by Khem Raj. (From OE-Core rev: 36cc6b81d0281348a0f241a80ddd427745a6a678) 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>
* oe-selftest: Add support for lib/oeqa/selftest subdirectoriesCostin Constantin2016-02-281-25/+28
| | | | | | | | | | | | | | This patch adds functionality to allow creating subdirectories inside lib/oeqa/selftest for all layers present in BBLAYERS. Like this, test cases can be grouped into organized directories. Addresses [YOCTO #7865] (From OE-Core rev: 445b84456659ebb355149f6b0dca543b0bb2679c) Signed-off-by: Costin Constantin <costin.c.constantin@intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: update-recipe: create config fragmentMarkus Lehtonen2016-02-281-1/+55
| | | | | | | | | | | | | | | | | | | | | | | | Create config fragment if the user makes modifications to kernel config. User may change .config e.g. by directly editing it or by running the 'do_menuconfig' bitbake task. Devtool generates one monolithic fragment by simply doing a diff between .config and .config.baseline files in the source directory. If either of these files is missing, the config fragment is not gerenrated or updated. The output is a file, 'devtool-fragment.cfg' that gets added to SRC_URI in the recipe (as well as copied into the 'oe-local-files' directory if that is present in the source tree). ${S}/.config will be a symlink to ${B}/.config. We need to do this as devtool is not able to access ${B} because ${B} is set in a .bbappend in the workspace layer which is not parsed by devtool itself. [YOCTO #8999] (From OE-Core rev: 524da136e5b837a60682516ac08f3092c635e934) Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: sync: update kernel configMarkus Lehtonen2016-02-281-1/+5
| | | | | | | | | | | Copy kernel config is copied to the source directory at a later phase in _extract_source() so that it gets copied when devtool sync is done, too. (From OE-Core rev: ff895be7a46c4b3b1b791e5387490d90bb34fce2) Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* scripts/oe-selftest: Use site.USER_SITE to run coverage configuration code ↵Humberto Ibarra2016-02-281-12/+34
| | | | | | | | | | | | | | | | | | | | | | for sub-process Coverage in oe-selftest currently requires to create or modify a sitecustomize.py file according the coverage tool setup instructions (http://coverage.readthedocs.org/). This file has to be located in the system's python folder, which is not a good solution since this folder is not accesible to non-privileged users. The best solution so far is to create this file in the home directory. This is implemented by creating the temporal file in the user site default folder. [Yocto #8930] (From OE-Core rev: 3f9b1658d745b536eff1017b2c74a9dff46b6f4a) Signed-off-by: Humberto Ibarra <humberto.ibarra.lopez@intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* scripts/oe-selftest: Add filtering to the coverage data gathered by oe-selftestHumberto Ibarra2016-02-281-7/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When --coverage is used, oe-selftest gathers coverage data from the testcases executed. The command lacks a way of filtering which files to gather coverage data from. This patch adds three options to specify which files should be considered. The --coverage-source option specifies folders, while --coverage-include and --coverage-omit specify patterns to have an extra level of filtering. Some examples: 1. oe-selftest --run-all-tests --coverage Gathers coverage data from the default poky folders 2. oe-selftest --run-all-tests --coverage --coverage-include /home/me/poky/scripts/* Gathers coverage data only for the files located under '/home/me/poky/scripts' 3. oe-selftest --run-all-tests -coverage --coverage-omit /home/me/poky/meta* Gathers coverage data. Files inside all the folders starting with 'meta' under '/home/me/poky' are omited 4. oe-selftest --run-all-tests --coverage --coverage-source /home/me/poky/bitbake Gathers coverage data only from files inside the folder: '/home/me/poky/bitbake' [Yocto #8920] (From OE-Core rev: 923481c7d8c09ed9b03109cf4debcc6b07845c59) Signed-off-by: Humberto Ibarra <humberto.ibarra.lopez@intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* meta-yocto: Rename to meta-poky to better match its purposeRichard Purdie2016-02-282-2/+2
| | | | | | | | | | | | | | | | | "poky" is the reference distribution for the Yocto Project. This renames the layer within the meta-yocto repository to meta-poky, better matching what that layer contains. A layer.conf file is left behind as this is the only way which allows existing builds to migrate safely to the new name. It will be removed at some future point. This change requires the corresponding OE-Core change to handle the migration and the changes to the infrastructure to support this. (From meta-yocto rev: d0c88df2e14672fca4ebbde93c5efbcd0e4fa9b6) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* recipetool: create: improve CMake package mappingPaul Eggleton2016-02-212-14/+40
| | | | | | | | | | | | | | * Package names are actually case sensitive near as I can tell, so we shouldn't be lowercasing them everywhere. * Look for CMake packages in pkgdata and map those back to recipes, so we aren't dependent on the hardcoded mappings (though those are still preserved). * Avoid duplicates in the unmapped package list (From OE-Core rev: 2ddad52ccca07245eea43d9b844c6c7d4b667ca3) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* recipetool: create: add additional extension mechanismsPaul Eggleton2016-02-212-8/+113
| | | | | | | | | | | | | | | | | | Add a means of extending the dependency extraction for autotools and cmake. Note: in order to have this work, you need to have an __init__.py in the lib/recipetool directory within your layer along with the module implementing the handlers, and the __init__.py needs to contain: # Enable other layers to have modules in the same named directory from pkgutil import extend_path __path__ = extend_path(__path__, __name__) (From OE-Core rev: 915dea9f89cd737e5ba167c384e8d314c5c23c49) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: modify: tweak help description for behaviour changePaul Eggleton2016-02-211-2/+2
| | | | | | | | | | I should have adjusted this in OE-Core commit 80a44e52609a89d9ffe816181ae193af491c06ac where the behaviour changed. (From OE-Core rev: 13409a2b899bb74b8060c840b8c7ef8759d099cb) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: deploy-target: preserve existing filesPaul Eggleton2016-02-211-9/+78
| | | | | | | | | | | | | | | | If files would be overwritten by the deployment, preserve them in a separate location on the target so that they can be restored if you later run devtool undeploy-target. At the same time, also check for sufficient space before starting the operation so that we avoid potentially failing part way through. Fixes [YOCTO #8978]. (From OE-Core rev: a2da55712691bcf1066c53d813107d75213d6b10) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: undeploy-target: support undeploying all recipesPaul Eggleton2016-02-211-20/+39
| | | | | | | | | | | | | | | | | | | | | If you want to put the target device back to exactly how it was before devtool deploy-target started poking things into it, then it would make things easier if you didn't have to figure out which recipes were deployed. Now that we have the list stored on the target we can determine this reliably, so add a -a/--all option to undeploy-target to undeploy everything that has been deployed. One of the side-effects of this is that the dry-run functionality for undeploy-target had to be reimplemented to actually run the script on the target, since we have no way of knowing what's been deployed from the host side. We don't need to do the same for deploy-target though since we know exactly which files will be deployed without referring to the target. (From OE-Core rev: 41fed83060f0041e14e455d1446397bda277d953) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: deploy-target: write deployed files list to targetPaul Eggleton2016-02-211-41/+103
| | | | | | | | | | | | | | | | | | | | | When running devtool deploy-target, we save a list of deployed files, and this list is used by devtool undeploy-target (or the next time deploy-target is run if the list is present, in case any files have been renamed or deleted since the first time). We were writing this file to the host, but it makes more sense to write the list to the target instead, so that if we for example swap in a different board, or switch hosts, things will work as expected. In order to do this properly we have to construct a shell script and ship it over to the target so we can run it. The manifest is written out to a hidden directory in the root (/.devtool). Fixes [YOCTO #7908]. (From OE-Core rev: a16a0c9334b785e2df896266c8911a2c7a1806b8) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: sdk-update: tweak command-line handling of updateserverPaul Eggleton2016-02-211-4/+7
| | | | | | | | | | | | Get the default value for updateserver from the configuration file and show it in the help; also only make the parameter optional if it's specified. This means we can also drop the check in the function as argparse will then ensure it's specified if there's no config setting. (From OE-Core rev: 82497bde58fc8bdae8d8acfbf025a1a90b14cc3e) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: (un)deploy-target: add help descriptionsPaul Eggleton2016-02-211-0/+2
| | | | | | | | | Add a long description used when running --help on the specific command. (From OE-Core rev: eb7787d1652fd84a149fd394969f4f1099406051) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* scripts/lib/argparse_oe: tweak title above optionsPaul Eggleton2016-02-211-0/+4
| | | | | | | | | | | | | | Naming these as "optional arguments" is perhaps slightly confusing since some of the positional arguments might also be optional; in addition it's rare (though possible) for options to be mandatory - up until recently we had a recipetool option (-o) that was mandatory. It's not perfect, but change it to "options" so it's at least a bit more appropriate. (From OE-Core rev: 55e675de6191bf7eccd26df29189f2a6faa40a20) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: categorise and order subcommands in help outputPaul Eggleton2016-02-2112-20/+114
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* devtool: update-recipe: don't show workspace recipe warning if no updatePaul Eggleton2016-02-211-5/+9
| | | | | | | | | | If we didn't make any changes to the file then there's no point warning the user that we have done. (From OE-Core rev: 391b9ba30d802ac420ddf382588e03e718861c01) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: reset: fix preserving patches/other files next to recipesPaul Eggleton2016-02-211-4/+4
| | | | | | | | | | | | | | | | If files had been created next to the recipe (for example devtool add, edit the source and commit and then devtool update-recipe), running devtool reset failed to preserve those files and gave an error due to trying to rmdir the directory containing them which wasn't empty. Fix the preservation of files in the "attic" directory properly so we catch anything under the directory for the recipe, and replicate the same structure in the attic directory rather than slightly flattening it as we were before. (From OE-Core rev: bbe63eb97ae7f78959f117d6066ef821c4da1c77) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool / recipetool: use common code for launching editorPaul Eggleton2016-02-213-17/+19
| | | | | | | | | | | | | | | Looking at Chris Larson's code for starting the user's editor for "recipetool newappend" it was slightly better than what I wrote for "devtool edit-recipe" in that it checks VISUAL as well as EDITOR and defaults to vi if neither are set, so break this out to its own function and call it from both places. The broken out version passes shell=True however in case it's a more complicated command rather than just a name of an executable. (From OE-Core rev: 184a256931e8cdc7bea97a905c4e67a435964de0) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: minor fix for error messagePaul Eggleton2016-02-211-1/+1
| | | | | | | | | | There is no -N/--name option for devtool, that's a recipetool option - with devtool you just specify the name as a positional argument. (From OE-Core rev: d2bc0cba5ca8a7220ffe1ef96acf856fe972ce7c) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: Don't recursively look for .devtoolbase in --basepathRandy Witt2016-02-211-12/+16
| | | | | | | | | | | | If the user specifies --basepath on the commandline, only the directory specified should be searched for .devtoolbase. Otherwise when --basepath is a child of the sdk directory, .devtoolbase will always be found and devtool will only show options meant to be used within an sdk. (From OE-Core rev: 3bb07c61220b89384a76c745e33be37aad5095c0) Signed-off-by: Randy Witt <randy.e.witt@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* linux-yocto: Work around PAT issue on qemux86Richard Purdie2016-02-151-1/+1
| | | | | | | | | | | | We have an issue with PAT handling on older processes with limited PAT bits, see the patch description for the full problem. This replaces the runqemu workaround with a kernel patch until we can get the kernel trees sorted out and discuss a proper fix with upstream. It should be safe everywhere so is applied unconditionally. (From OE-Core rev: e00f0794a535c8e68ae1c87c8b01dd65645d570b) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* wic: fix processing of --use-uuidEd Bartosh2016-02-151-0/+3
| | | | | | | | | | | | | | | Processing of this option was lost during recent change of wks parsting. It was discovered during the work on booting wic images under qemu. Now, when -use-uuid is fixed it's possible to specify root partition by partition uuid. This will be done in the following commit. (From OE-Core rev: b4882e0b84d7fd4c85ee95386e94722485eafc2b) (From OE-Core rev: 73e9e3f150bf2de9b27c2ccc73e3dee334ee73fe) Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqemu: support path/to/<image>-<machine>.wicEd Bartosh2016-02-151-4/+6
| | | | | | | | | | | | | | Supported providing wic image path to runqemu: runquemu path/to/<image>-<machine>.wic [YOCTO #8691] (From OE-Core rev: 58a3bfb1e4b493200820cdf0bf3fc79e31e792de) (From OE-Core rev: e6150971ea4eea49b802a12aea5ab733e894c92d) Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqemu: don't set KERNEL for wic imagesEd Bartosh2016-02-152-2/+2
| | | | | | | | | | | | | | | | Wic images should be boot as is, without pointing qemu to the kernel binary. Current code doesn't use kernel, but sets KERNEL variable and shows kernel path in the console output. This can confuse users. Changed runqemu and runqemu-internal code to avoid setting KERNEL variable and show kernel path. (From OE-Core rev: 474caa7ed5ff05caa5d49d270b283882fa616ed1) (From OE-Core rev: 35e776e00cce25f2c9c45500612fb66022ec4739) Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqemu: add support for wic imagesEd Bartosh2016-02-152-9/+10
| | | | | | | | | | | | | | Quemu should be able to run wic images this way: runqemu <machine> <image recipe> wic Tested with 'runqemu qemux86-64 wic-image-minimal wic' (From OE-Core rev: 8716be799949cb8bde7fa49cbea61312a3a93bb7) (From OE-Core rev: dd42931bf99b8bbd4ad452b3941d957f41b81796) Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* scripts/sstate-cache-management.sh: Change wordingJan Sarenik2016-02-151-2/+2
| | | | | | | | | Use "out of" rather than "from" in the output. (From OE-Core rev: c712529030c71b45bb8ae647c17319c2647aedff) Signed-off-by: Jan Sarenik <jajomojo@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* scripts/runqemu-internal: Work around qemux86 PAT bugs in linux 4.4.1Richard Purdie2016-02-121-1/+1
| | | | | | | | | | | | | | Since the upgrade of qemux86 to 4.4.1 we're seeing PAT issues when starting the X server. We need to fix the problem but the failing sanity tests mask out other issues and we need a workaround. Merge this for now until we can figure out the full issue. This is better than changing the kernel defconfig or reverting to old kernel versions. (From OE-Core rev: 2749ba318bf322cb5014689532372473004e92b9) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* recipetool: create: set S when we set SRC_URI from local git repoPaul Eggleton2016-02-111-0/+1
| | | | | | | | | | | | | | If you specify a local directory which happens to be a git repository with an origin remote (and it is in fact remote), we can use that for SRC_URI as implemented by OE-Core revision b143d414846854dc8b3e0a47358daf5646eded38, however we also need to set S if the recipe is going to be of any use fetching from that SRC_URI later. (From OE-Core rev: 8bbbd2d63f1bc752f9a30054a089dc2caf5fd84c) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* recipetool: create: convert http git URLs that don't end in .git but contain ↵Paul Eggleton2016-02-111-4/+6
| | | | | | | | | | | | | | /git/ When recipetool create is given a URL that starts with http(s):// and contains /git/, such as the URLs at git.yoctoproject.org, it's fairly safe to assume it's a git repository and not something that should be fetched with wget, so rewrite the URL. (From OE-Core rev: 3ca04757a670e8b6f78799cc0454d75691809ac4) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* recipetool: create: ensure URL parameters don't make it into the namePaul Eggleton2016-02-111-1/+1
| | | | | | | | | | | When auto-detecting the name for a recipe from the URL, strip off any parameters (";name=value...") before parsing the URL, otherwise this just ends up in the recipe name which is undesirable. (From OE-Core rev: d3c46b5d0abd56bcadd4f2f1ef985f13d67f605b) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: add: fix adding from a local source directoryPaul Eggleton2016-02-111-1/+1
| | | | | | | | | | | | | Fix a regression introduced in in OE-Core revision aedfc5a5db1c4b2b80a36147c9a13b31764d91dd where specifying a local source tree without specifying a name resulted in a traceback. Fixes [YOCTO #9086]. (From OE-Core rev: 67ea9d21f20a371a0ee443b46326018cb1527b62) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: modify: make -x the default behaviourPaul Eggleton2016-02-111-6/+8
| | | | | | | | | | | | | | | It's going to be more common for users not to have the prepared source tree for a recipe already, so the default behaviour ought to be to extract it for them from the recipe. Change the default to extract (effectively making the -x option a no-op) and add a --no-extract/-n option to disable it. Later we can look at trying to be smart and reusing an existing source tree instead of erroring out if it exists; for now this is just the default reversal. (From OE-Core rev: 80a44e52609a89d9ffe816181ae193af491c06ac) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* recipetool: create: determine name/version from github/bitbucket URLsPaul Eggleton2016-02-111-9/+35
| | | | | | | | | | | | | | Both BitBucket and GitHub provide "release" downloads that unfortunately don't include the actual project name. For recipetool this means we have to have special handling for these URLs or else the current code assumes the name of the project is something like "v0.9.1". Borrow and adapt some code from autospec to do this, and put it in its own function for clarity. (From OE-Core rev: e8435fde7f82c39cc0efe1d4bf043b29f63898e9) 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-17 22:30:44 +0000