summaryrefslogtreecommitdiffstats
path: root/bitbake/lib/bb
Commit message (Collapse)AuthorAgeFilesLines
* bitbake: tinfoil: fix duplication of log messagesPaul Eggleton2017-06-122-3/+4
| | | | | | | | | | | | | | | Adding an additional logger in setup_bitbake() interacts poorly with the logger we have added by default in tinfoil's constructor, with the result that messages may be doubled or even tripled in tinfoil-using scripts. Disable adding this one when calling setup_bitbake() from tinfoil to avoid this problem. Part of the fix for [YOCTO #11275]. (Bitbake rev: 8a5bae76f91f2411187c638a42fa3c762052cf11) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: command / cooker: drop Hob support commands and functionsPaul Eggleton2017-06-122-253/+0
| | | | | | | | | | | | | | | | | | | Drop a number of the commands and support functions that were created solely to support functionality in the now-removed Hob UI. In most cases we now have this functionality elsewhere e.g. to modify config files and recipes we have bb.utils.edit_metadata_file() and friends, and in OE we have oe.recipeutils.patch_recipe_file() and friends which build on top of the former. Additionally, some of it represented pretty egregious incursion of OE metadata-specific references into BitBake code. For now I have left in the find*File functions and commands as they are relatively generic and possibly still useful, but they might be removed in future. (Bitbake rev: a322f13183c66a28d93cc4bc3d839d95fc1d90f4) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker: add BB_CMDLINE to enable access to UI command line with memresPaul Eggleton2017-06-123-3/+9
| | | | | | | | | | | | | | | | | | | | | | | In OpenEmbedded's buildhistory class we want access to the bitbake command line that launched the build, and up to now we were simply using sys.argv from within the event handler to get that. Unfortunately that doesn't work in memory resident mode, since the event handler is naturally executing within the server and thus will give you the command that launched the bitbake server which is much less interesting. Add a dynamic variable BB_CMDLINE to provide access to this, set from sys.argv within the UI process in updateToServer(). (Note that BB_CMDLINE isn't currently passed through to the worker, so this is only really readable from event handlers plus any explicit getVariable calls - in theory an observe-only UI could read it for example.) Part of the fix for [YOCTO #11634]. (Bitbake rev: 8ad31a3eff5cfcb7b1c462578a582dafcbc426d4) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker: set config valid flags in initConfigurationData()Paul Eggleton2017-06-121-6/+2
| | | | | | | | | | | | | | If we set these flags here then we can not only tidy up some of the code that calls initConfigurationData() (and reset() which simply calls the former), we also avoid calling initConfigurationData() an extra time unnecessarily during startup (since setting baseconfig_valid = False in updateConfigOpts() also resulted in initConfigurationData() being called from updateCacheSync() at the end of the command.) (Bitbake rev: 74d2ef99a920aa9e70470ba8e600ea973a3c672a) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker: fix file changes not triggering task re-execution with memresPaul Eggleton2017-06-121-1/+13
| | | | | | | | | | | | | | | | | | | | | | | | If you build a recipe, modify one of the files referred to in SRC_URI, then build it again, it should re-run do_fetch and the tasks that depend upon it to incorporate the modified file. With memory resident mode this was not working unless you restarted the server, because the mtime of the file was cached and thus we never checked the actual file. Clear out the mtime caches in buildTargets() to ensure this isn't an issue. I did a minor refactoring to break this out to its own function since we were already clearing out the build mtime cache here. (The test I used for this was . ./oe-init-build-env-memres, bitbake -c fetch mdadm, modify the comments at the top of one of the patches referred to in the recipe, and then bitbake -c fetch mdadm again and it should re-execute the fetch task ("... 0 didn't need to be re-run".) Fixes [YOCTO #10732]. (Bitbake rev: fe4f3487368bc35043a1ba464e1c69d2c9cbefc6) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cookerdata: fix variable history not showing in bitbake -e with memresPaul Eggleton2017-06-121-1/+1
| | | | | | | | | | | | | | | | | | CookerConfiguration sets the "tracking" option to True when -e is specified in order to have history tracking enabled in the datastore so that we can show variable history (which isn't enabled by default for performance reasons), however in memory resident mode this wasn't doing anything because it was happening on the UI side only. We do have a mechanism for updating the cooker configuration in the server, but the tracking option wasn't being included in the list of options we updated, so we just need to add this option to fix the issue. Fixes [YOCTO #10730]. (Bitbake rev: 57d4977555cf892b15dd0302dfe261fe37d49327) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cookerdata: Add support for BBFILES_DYNAMICPatrick Ohly2017-06-091-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BBFILES_DYNAMIC can be used to activate content only when some other layers are present. The other layers are identified by the collections that they define. The main use case is to avoid .bbappends without the corresponding .bb file in layers that want to modify other layers via .bbappends without introducing a hard dependency on those other layers. .bb files could also be handled via BBFILES_DYNAMIC. Entries in BBFILES_DYNAMIC must have the form <collection name>:<filename pattern>. Example usage: BBFILES_DYNAMIC += " \ clang-layer:${LAYERDIR}/bbappends/meta-clang/*/*/*.bbappend \ core:${LAYERDIR}/bbappends/openembedded-core/meta/*/*/*.bbappend \ " Parsing is aborted when invalid entries are found with an error message like this: ERROR: BBFILES_DYNAMIC entries must be of the form <collection name>:<filename pattern>, not: /work/my-layer/bbappends/meta-security-isafw/*/*/*.bbappend /work/my-layer/bbappends/openembedded-core/meta/*/*/*.bbappend Based on a patch by Richard Purdie. (Bitbake rev: 04f8bd50aa04b12cf91dd6a3154527ad2c24695c) Signed-off-by: Patrick Ohly <patrick.ohly@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: tinfoil: allow extra features to be passed to prepareAndy Voltz2017-06-051-1/+4
| | | | | | | (Bitbake rev: 2e35de1f19dc73a61a18a3eb186efede078d597d) Signed-off-by: Andy Voltz <andy.voltz@timesys.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker: fix undefined dep in generatePkgDepTreeDataAndy Voltz2017-06-051-2/+2
| | | | | | | | | | The loop for populating the depends of the tree data should use dep instead of item. (Bitbake rev: 37c298b27e3f72b21513124237cfeffb22c0e2f0) Signed-off-by: Andy Voltz <andy.voltz@timesys.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: Fix return value checks from subprocess.call()'sMikko Rapeli2017-06-052-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | Python function subprocess.call() returns the return value of the executed process. If return values are not checked, errors may go unnoticed and bad things can happen. Change all callers of subprocess.call() which do not check for the return value to use subprocess.check_call() which raises CalledProcessError if the subprocess returns with non-zero value. https://docs.python.org/2/library/subprocess.html#using-the-subprocess-module All users of the function were found with: $ git grep "subprocess\.call" | \ egrep -v 'if.*subprocess\.call|=\ +subprocess\.call|return.*subprocess\.call' Tested similar patch on top of yocto jethro. Only compile tested core-image-minimal on poky master branch. (Bitbake rev: d2cf67bcaf001acb6be8fc5884fb450649849847) Signed-off-by: Mikko Rapeli <mikko.rapeli@bmw.de> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: ConfHandler: Require whitespace between export and variable nameOla x Nilsson2017-06-052-2/+23
| | | | | | | (Bitbake rev: 22bb7c9270f02ddae72e13d849375feee5f4a98b) Signed-off-by: Ola x Nilsson <olani@axis.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: siggen: Make calc_taskhash match get_taskhash for file checksumsRichard Purdie2017-06-051-1/+2
| | | | | | | | | | | The code in these two functions is meant to be equivlanet in behaviour but isn't. Add in code to ensure files that don't exist are handled consistently by both functions. Users did report being able to generate tracebacks otherwise. (Bitbake rev: c11b4832879354b387a8c9c6a3096f2d621afeac) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: fetch/git: add support for removing arbitrary revs for shallowChristopher Larson2017-06-022-2/+82
| | | | | | | | | | | | | | | | | | | | In certain cases, it's valuable to be able to exert more control over what history is removed, beyond srcrev+depth. As one example, you can remove most of the upstream kernel history from a kernel repository, keeping predominently the non-publically-accessible content. If the repository is private, the history in that repo couldn't be restored via `git fetch --unshallow`, but upstream history could be. Example usage: # Remove only these revs, not at a particular depth BB_GIT_SHALLOW_DEPTH_pn-linux-foo = "0" BB_GIT_SHALLOW_REVS_pn-linux-foo = "v4.1" (Bitbake rev: 97f856f0455d014ea34c28b1c25f09e13cdc851b) Signed-off-by: Christopher Larson <chris_larson@mentor.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: fetch/gitannex: add support for shallow mirror tarballsChristopher Larson2017-06-022-3/+37
| | | | | | | | | | | | When we're building from a shallow mirror tarball, we don't want to do anything with ud.clonedir, as it's not being used when we unpack. As such, disable updating annex in that case. Also include annex files in the shallow tarball. (Bitbake rev: ca0dd3c95502b22c369fbf37f915f45e02c06887) Signed-off-by: Christopher Larson <chris_larson@mentor.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: fetch/gitsm: add support for shallow mirror tarballsChristopher Larson2017-06-022-10/+38
| | | | | | | | | | | | | When we're building from a shallow mirror tarball, we don't want to do anything with ud.clonedir, as it's not being used when we unpack. As such, disable updating the submodules in that case. Also include the repositories in .git/modules in the shallow tarball. It does not actually make the submodule repositories shallow at this time. (Bitbake rev: 6c0613f1f2f9d4f009545f82a9173e80396f9d34) Signed-off-by: Christopher Larson <chris_larson@mentor.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: fetch/git: add support for keeping extra refs for shallowChristopher Larson2017-06-022-1/+63
| | | | | | | | | | | | | | | | | | | | By default, all unused refs (branches & tags) are removed from the repository, as shallow processing scales with the number of refs it has to process. Add the ability to explicitly specify additional refs to keep. This is particularly useful for recipes with custom checkout processes, or whose git-based versioning requires a tag be available (i.e. for `git describe --tags`). The new `BB_GIT_SHALLOW_EXTRA_REFS` variable is a space-separated list of refs, fully specified, and support wildcards. Example usages: BB_GIT_SHALLOW_EXTRA_REFS = "refs/tags/v1.0" BB_GIT_SHALLOW_EXTRA_REFS += "refs/heads/*" (Bitbake rev: 1771934cd9f8b5847c6fcae0a906fb99d6b0db16) Signed-off-by: Christopher Larson <chris_larson@mentor.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: fetch/git: support per-branch/per-url depths for shallowChristopher Larson2017-06-022-23/+73
| | | | | | | | | | | | | | | | Allow the user to explicitly adjust the depth for named urls/branches. The un-suffixed BB_GIT_SHALLOW_DEPTH is used as the default. Example usage: BB_GIT_SHALLOW_DEPTH = "1" BB_GIT_SHALLOW_DEPTH_doc = "0" BB_GIT_SHALLOW_DEPTH_meta = "0" (Bitbake rev: 9dfc517e5bcc6dd203a0ad685cc884676d2984c4) Signed-off-by: Christopher Larson <chris_larson@mentor.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: fetch/git: add support for shallow mirror tarballsChristopher Larson2017-06-022-15/+417
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds support to the git fetcher for fetching, using, and generating mirror tarballs of shallow git repositories. The external git-make-shallow script is used for shallow mirror tarball creation. This implements support for shallow mirror tarballs, not shallow clones. Supporting shallow clones directly is not really doable for us, as we'd need to hardcode the depth between branch HEAD and the SRCREV, and that depth would change as the branch is updated. When BB_GIT_SHALLOW is enabled, we will always attempt to fetch a shallow mirror tarball. If the shallow mirror tarball cannot be fetched, it will try to fetch the full mirror tarball and use that. If a shallow tarball is to be used, it will be unpacked directly at `do_unpack` time, rather than extracting it to DL_DIR at `do_fetch` time and cloning from there, to keep things simple. There's no value in keeping a shallow repository in DL_DIR, and dealing with the state for when to convert the clonedir to/from shallow is not worthwhile. To clarify when shallow is used vs a real repository, a current clone is preferred to either tarball, a shallow tarball is preferred to an out of date clone, and a missing clone will use either tarball (attempting the shallow one first). All referenced branches are truncated to SRCREV (that is, commits *after* SRCREV but before HEAD are removed) to further shrink the repository. By default, the shallow construction process removes all unused refs (branches/tags) from the repository, other than those referenced by the URL. Example usage: BB_GIT_SHALLOW ?= "1" # Keep only the top commit BB_GIT_SHALLOW_DEPTH ?= "1" # This defaults to enabled if both BB_GIT_SHALLOW and # BB_GENERATE_MIRROR_TARBALLS are enabled BB_GENERATE_SHALLOW_TARBALLS ?= "1" (Bitbake rev: 5ed7d85fda7c671be10ec24d7981b87a7d0d3366) Signed-off-by: Christopher Larson <chris_larson@mentor.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: git-make-shallow: add script to make a git repo shallowChristopher Larson2017-06-021-0/+127
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This script will be used by the git fetcher to create shallow mirror tarballs. usage: git-make-shallow [-h] [--ref REF] [--shrink] REVISION [REVISION ...] Remove the history of the specified revisions, then optionally filter the available refs to those specified. positional arguments: REVISION a git revision/commit optional arguments: -h, --help show this help message and exit --ref REF, -r REF remove all but the specified refs (cumulative) --shrink, -s shrink the git repository by repacking and pruning While git does provide the ability to clone at a specific depth, and fetch all remote refs at a particular depth, the depth is across all branches/tags, and doesn't provide the flexibility we need, hence this script. Refs (branches+tags) can be filtered, as the process of history removal scales up rapidly with the number of refs. Even the existing `git fetch --depth=` is extremely slow on an upstream kernel repository with all the branches and tags kept. This uses the same underlying mechanism to implement the history removal which git itself uses (.git/shallow), and the results, when configured similarly, are in line with the results git itself produces with `fetch --depth`. (Bitbake rev: 0254020f0e1911c0eaf99111b91828d2a74a4ee1) Signed-off-by: Christopher Larson <chris_larson@mentor.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: fetch: support multiple mirror tarball filenamesChristopher Larson2017-06-024-42/+47
| | | | | | | | | | | | Remove ud.mirrortarball in favor of ud.mirrortarballs. Each tarball will be attempted, in order, and the first available will be used. This is needed for git shallow mirror tarball support, as we want to be able to use either a shallow or full mirror tarball. (Bitbake rev: 02eebee6709e57b523862257f75929e64f16d6b0) Signed-off-by: Christopher Larson <chris_larson@mentor.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: data_smart: Don't cache/process capitalised overridesRichard Purdie2017-05-181-1/+1
| | | | | | | | | | | | | | | Bitbake now only processes overrides which are lowercase since this allows variables like SRC_URI not to pollute the cache. There was a corner case where XXX_append_SomeThing was still being processed (yet XXX_append_SomeThing_SomeOtherThing would not be). This patch ensures we're consistent and only process lowercase _append/_prepend and _remove operators too. (Bitbake rev: 6eb56624e6d8dc1944e559b4f6584bfe66f566ba) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: lib/bb/fetch2: fix typo in conflicting revision messagePaul Eggleton2017-05-151-1/+1
| | | | | | | | | spcify -> specify (Bitbake rev: c46f183b3ea94789dd83cb280a1bf5735189c9bc) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: lib/bb/COW.py: fix typo in Tim Ansell's namePaul Eggleton2017-05-151-1/+1
| | | | | | | | | See AUTHORS for reference. (Bitbake rev: a6345899ffeb595ca287b295945713eb95032124) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: lib/bb/command: fix overrides in remote datastores where there is ↵Paul Eggleton2017-04-201-0/+3
| | | | | | | | | | | | | | | | | | | | no default If you have, for example, no value set for a variable VARIABLE and a then VARIABLE_pn-something = "value" and then you parse something.bb, you expect getVar('VARIABLE') on the resulting datastore to return "value", but the code here assumed that if the variable wasn't set without overrides then we didn't need to return the overridedata and thus we didn't get the overridden value. In OE this affected the ability to get RECIPE_MAINTAINER for a recipe in a script using tinfoil (since this is only set from an inc file with _pn- overrides for each recipe, and no default is set). (Bitbake rev: b3d2c9917c5fd8278878328794daa107ddf79b64) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: Update version to 1.34.0 for stable releaseRichard Purdie2017-04-191-1/+1
| | | | | | (Bitbake rev: b4da94a368c6c44c6e5b6e6e9a1e041ed84b4554) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: command.py: multiconfig support for findBestProviderJuro Bystricky2017-04-191-2/+8
| | | | | | | | | | | | | | | | | | | | | | | | | In a multiconfig environment, a tinfoil call such as tinfoil.parse_recipe("multiconfig:arduino-101-sss:gcc") can fail with an error such as: File "/data/master/poky/bitbake/lib/bb/tinfoil.py", line 373, in get_recipe_file raise bb.providers.NoProvider('Unable to find any recipe file matching "%s"' % pn) bb.providers.NoProvider: Unable to find any recipe file matching "multiconfig:arduino-101-sss:gcc" The culprit is findBestProvider, which does not handle multiconfig. This patch fixes the error and in the case mentioned above the tinfoil call returns: "multiconfig:arduino-101-sss:/data/master/poky/meta/recipes-devtools/gcc/gcc_6.3.bb" [YOCTO#11210] (Bitbake rev: e9c03fbfd7b057b28645affa263cb4aebfa24b04) Signed-off-by: Juro Bystricky <juro.bystricky@intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: lib/bb/{data, siggen}: Don't warn on SkipRecipe exceptionsNathan Rossi2017-04-122-0/+4
| | | | | | | | | | | | Recipes/variables that raise a SkipRecipe exception are intentionally skipped, and should not generate warnings. [YOCTO #11319] (Bitbake rev: edf6e6094a9f7ad4b2ba06eef8fd34756edbedce) Signed-off-by: Nathan Rossi <nathan@nathanrossi.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: data_smart: Ensure _remove operations on newly set variables are ↵Richard Purdie2017-04-122-0/+8
| | | | | | | | | | | | | | | | cleared We clear append/prepend on newly set variables, we should also clear remove operations. If we don't do this, there is no way we can actually delete a remove operation. Bitbake internally uses parsing=True to avoid these side effects when making its own internal calls. Also add a testcase to bitbake-selftest to ensure we remain consistent going forward from here. (Bitbake rev: 3a319f079d699c870d8531e051ab65e6278d1fa5) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: toaster: fix SDK artifact captureDavid Reyna2017-04-112-3/+31
| | | | | | | | | | | | | | | | | Use the TaskArtifacts event to scan the SDK and ESDK manifests to cleanly collect the respective artifact files. The previous method was broken when the SDK file deployment moved from the do_populate_sdk[_ext] tasks to their sstate tasks. That method is disabled (but not yet removed) in preparation for the rest of refactor work for the parent #10283 work. [YOCTO #10850] (Bitbake rev: 1360d7b847cc01031edb2f4b289fac9560d72fa7) Signed-off-by: David Reyna <David.Reyna@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cache: prevent division-by-zero in load_cahefile()Markus Lehtonen2017-04-111-0/+4
| | | | | | | | | [YOCTO 11315] (Bitbake rev: 227c5acd4b40154bc61202e7bb67a13818a7d727) Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake-diffsigs: colourise outputPaul Eggleton2017-04-101-28/+73
| | | | | | | | | | | | | | | | | | If the output is a TTY, add colour to the output in order to make it easier to read. At the moment this is fairly basic, just add colour to the "titles" of each change and to the diff output. I tried to introduce this without changing the code too much - rather than moving everything over to the new python formatting style, I've introduced a color_format() function which takes care of the colour formatting, either accepting additional format arguments or alternatively leaving the caller to use the old-style formatting (%) to insert values. (Bitbake rev: 04a023c8fdea1e1812fcdcaf00345aab59f9abe1) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: lib/bb/siggen: show word-diff for single-line values containing spacesPaul Eggleton2017-04-101-1/+37
| | | | | | | | | | | | | | | | If a variable value has changed and either the new or old value contains spaces, a word diff should be appropriate and may be a bit more readable. Import the "simplediff" module and use it to show a word diff (in the style of GNU wdiff and git diff --word-diff). Also use a similar style diff to show changes in the runtaskhashes list. I didn't use an actual word-diff here since it's a little different - we can be sure that the list is a list and not simply a free-format string. (Bitbake rev: 20db6b6553c80e18afc4f43dc2495435f7477822) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: lib/bb/siggen: add collapsed mode to compare_sigfiles()Paul Eggleton2017-04-101-23/+28
| | | | | | | | | | | | | | If we just want to drill down to the actual differences then we don't need to see certain things in the output, e.g. basehash changing or the signature of dependent tasks. This will be used for comparing signatures within buildhistory-diff in OE-Core; the default mode as used by bitbake-diffsigs and bitbake -S printdiff remains unchanged for the moment. (Bitbake rev: 6543a59b1ebd3194a7c6421cffc66ebe31a67c62) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: lib/bb/siggen: don't show unchanged runtaskdeps listPaul Eggleton2017-04-101-2/+6
| | | | | | | | | | | | If the runtaskdeps list hasn't actually changed (but the signatures of some of the tasks did) then it doesn't make sense to print out the old and new lists as they are both the same and may be very long, e.g. for do_rootfs in OE. (Bitbake rev: cb170543605288b3e8badfac3a54c588f4c95413) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: lib/bb/siggen: show a diff when dumping changes to multi-line valuesPaul Eggleton2017-04-101-1/+11
| | | | | | | | | | | | | | | | | | When dumping changes to signatures e.g. output of bitbake -s printdiff, if for example a function has changed, it's much more readable to see a unified diff of the changes rather than just printing the old function followed by the new function, so use difflib to do that. Note: I elected to keep to one item in the returned list per change, rather than one line per line of output, so that the caller can still look at changes individually if needed. Thus I've added some handling to bitbake-diffsigs to split the change into lines so that each line is displayed indented. (Bitbake rev: 4d254ae63a35231c98e3f73f669b040ed1144042) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: lib/bb/siggen: add missing path separator to cleaned pathsPaul Eggleton2017-04-101-1/+1
| | | | | | | | | | Printing "pbzip2pbzip2_1.1.13.bb" is ugly, we need to add a separating slash so that we get "pbzip2/pbzip2_1.1.13.bb" instead. (Bitbake rev: 55cd4045a37afc954f4d5091f524756b266064fc) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: Bump version to 1.33.4Richard Purdie2017-04-101-1/+1
| | | | | | (Bitbake rev: fe5d8a0fdaec99721455dead626ecfb72bdeb616) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: runqueue: Allow recrdeptask not to exist for all recipesRichard Purdie2017-04-101-0/+3
| | | | | | | | | | | | | | Currently if you specify a recrdeptask, it must exist for all recipes or you get a python traceback. This is a bug and it should be possible to have recipes which don't have the specified task. As well as preventing such a traceback (which shouldn't happen, it should be a user readable error), this allows us to fix issues in OE-Core which would otherwise trigger the traceback. (Bitbake rev: f93a77f2f188e18de9e3d812e86d77c2f3c71889) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: fetch/local: Drop FILESDIRRichard Purdie2017-04-051-9/+0
| | | | | | | | | | This has long since been deprecated and is no longer used anywhere, FILESPATH is the commonly used varaible which offers much more flexibility. Remove the FILESDIR code and references from bitbake. (Bitbake rev: 751c9dc51fd01fa64a1ff37ba2638110335f71af) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: codeparser: add some commentsPaul Eggleton2017-04-051-0/+23
| | | | | | | | | | | Add a few comments at the top of the file explaining what it's for, and a comment pointing out that you need to increment the cache version when changing any code that changes the output. (Bitbake rev: c1780bc1872bb35bc28c76eff9110717f02d9db2) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake-selftest: add contains testsPaul Eggleton2017-04-051-0/+48
| | | | | | | | | | | Add some tests to verify that we are extracting "contains" information from python expressions in the code in the bb.data and bb.codeparser modules. (Bitbake rev: 88fda492df875dd79b7aecf1f34b38517fc1eb33) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: codeparser: improve handling of contains_any() and filter()Paul Eggleton2017-04-052-4/+9
| | | | | | | | | | | | | | | | Ensure we handle bb.utils.contains_any() as separate items, rather than how we handle contains() where every item must be in the list. Additionally, enable handling bb.utils.filter() which for the purposes of looking at dependencies is the same as contains_any(). Additionally bump the codeparser cache and recipe cache versions to invalidate the user's existing caches (ensuring that the changes take effect and avoiding "taskhash mismatch" errors respectively). (Bitbake rev: 496e3c84820a2a889d99d3604659e47a550941d5) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: lib/bb/data: fix dependency handling for contains and multiple valuesPaul Eggleton2017-04-051-4/+6
| | | | | | | | | | | | | | | | The code that determines variable dependencies uses the codeparser to find references to "contains" type operations e.g. bb.utils.contains(). That function can take multiple items to check, and all specified items have to be present. However this code didn't handle that - it assumed that only one item would be specified and thus it was treating the multiple items as a single item with spaces in between. Split the value and check if all words are present in order to determine whether the check is "set" or "unset". (Bitbake rev: 272f1245acdd4fb85cb78612aa03627a9c246d8f) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: fetch2: Do not fail to create symbolic links if they already existPeter Kjellerstedt2017-04-011-2/+13
| | | | | | | | | | | | | | | When the fetcher retrieves file:// URLs, there is no lock file being used. This means that in case two separate tasks (typically from two concurrent invocations of bitbake) want to download the same file:// URL at the same time, there is a very small chance that they also end up wanting to create a symbolic link to the file at the same time. This would previously lead to one of the tasks failing as the other task would have created the link. (Bitbake rev: 58a03531c8183b165bb7dcad86d8559c92bc150d) Signed-off-by: Peter Kjellerstedt <pkj@axis.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: Bump version to 1.33.3Richard Purdie2017-03-311-1/+1
| | | | | | (Bitbake rev: 2c424b8cb39cba8f20f807e55efe6270996fa356) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bb/utils: extend which() so it can look for just executablesRoss Burton2017-03-311-3/+12
| | | | | | | | | | | | | Normally bb.utils.which() is used by the unpack code to find a file in a variety of places, but it is useful as a slightly more powerful version of os.which(). Support this by allowing it to only return matches which are executable files, instead of just the first filename that matches. (Bitbake rev: c0b94f02f0cba7a424aaa16cf98c0f7a3f62b889) Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: wget: Fix handling of urls with user/passwordRichard Purdie2017-03-311-3/+2
| | | | | | | | | | | | | URL decoding was improved in the core a while ago and this looks like a leftover from those times which caused urls needing a user/password to fail. Use the parameters from the core instead of the broken split implementation. [YOCTO #11262] (Bitbake rev: 6a917ec99d659e684b15fa8af94c325172676062) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: tinfoil: improve get_recipe_file() exception textPaul Eggleton2017-03-311-2/+2
| | | | | | | | | | | | * Turn reasons from a list into a string (usually there will be only one reason, but the interface provides for more than one) and state up front that the recipe is unavailable for clarity * Use quotes around invalid recipe name (Bitbake rev: 8922f1d23400049d2894a97915a533769a24ca07) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: tinfoil: fix get_recipe_file() to return an error on invalid recipePaul Eggleton2017-03-311-1/+1
| | | | | | | | | | | | | This function calls cooker.findBestProvider() but didn't handle the fact that that function returns a tuple (None, None, None, None) when there is no matching recipe. (This fixes devtool in OpenEmbedded showing a traceback when an invalid recipe is specified instead of a proper error message.) (Bitbake rev: 54a4757ca706afc6e98c7692f960592e80cab12b) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: s3.py: Remove hardcoded awsElizabeth 'pidge' Flanagan2017-03-301-2/+4
| | | | | | | | | | | | | This commit looks to see if FETCHCMD_s3 is set and if not, sets it. This is needed because I've use cases where I don't use aws, but s3cmd (due to license). (Bitbake rev: fdeaed70a7d1ff8be1a1de937cb864130b0c2c86) Signed-off-by: Elizabeth 'pidge' Flanagan <pidge@toganlabs.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-14 13:46:43 +0000