linux/poky.git/bitbake/lib, branch morty-16.0.2

bitbake: wget: Fix handling of urls with user/password

2017-08-29T14:12:43+00:00

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: 32a249cf33f79b579a2cf6224c7d23cdb20d376f) Signed-off-by: Richard Purdie

bitbake: codeparser.py: support deeply nested tokens

2017-07-21T21:36:09+00:00

For shell constructs like echo hello & wait $! the process_tokens() method ended up with a situation where "token" in the "name, value = token" assignment was a list of tuples and not the expected tuple, causing the assignment to fail. There were already two for loops (one in _parse_shell(), one in process_tokens()) which iterated over token lists. Apparently the actual nesting can also be deeper. Now there is just one such loop in process_token_list() which calls itself recursively when it detects that a list entry is another list. As a side effect (improvement?!) of the loop removal in _parse_shell(), the local function definitions in process_tokens() get executed less often. Fixes: [YOCTO #10668] (Bitbake rev: 887ea6d25cee5114365dfbf1130603599e13ee80) Signed-off-by: Patrick Ohly Signed-off-by: Richard Purdie

bitbake: siggen: Make calc_taskhash match get_taskhash for file checksums

2017-06-27T12:46:44+00:00

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: df69c0257aaa9f4e2f4a20d130b7bc0ce2ca0848) Signed-off-by: Richard Purdie

bitbake: lib/bs4: Fix imports from html5lib >= 0.9999999/1.0b8

2017-03-26T12:19:51+00:00

As of html5lib 0.9999999/1.0b8 (released on July 14, 2016), some modules have moved from _base to base. Handle this, while staying compatible with earlier versions. (Bitbake rev: bdf7a362ecdafd47f309b7a21feac4b94624f287) Signed-off-by: Daniel Lublin Signed-off-by: Richard Purdie

bitbake: cooker.py: run sanity checks for multiconfig

2017-03-16T15:34:08+00:00

Also run sanity check for all additional multiconfig configurations as listed in BBMULTICONFIG, not just the "default" configuration. [YOCTO#10810] (Bitbake rev: 0f7fdaa8212a8b9f1f089d32e652400d6c4b4822) Signed-off-by: Juro Bystricky Signed-off-by: Richard Purdie

bitbake: cooker.py: new multiconfig '*' syntax support

2017-03-16T15:34:08+00:00

Currently you cannot build a target for all the configured multiconfigs without specifying a list. The list can be quite long, requiring to type several lines of text. This enhancement is to support globbing so that you can do this, e.g. instead of: $ bitbake multiconfig:A:bash multiconfig:B:bash bash you can do: $ bitbake multiconfig:*:bash There are real world use cases where it is desirable to use multiconfig with two different tasks. For example: SDKs with multiple toolchains but also containing set of additional host tools, or multiconfig builds requiring one image for the main CPU(s) and a different co-image for a companion CPU. For this reason, two variations of the new syntax are supported. For example, the following: $ bitbake multiconfig:*:meta-toolhchain would expand to: $ bitbake multiconfig:A:meta-toolchain multiconfig:B:meta-toolchain meta-toolchain However the following: $ bitbake multiconfig:*:meta-toolhchain hosttools would expand to: $ bitbake multiconfig:A:meta-toolchain multiconfig:B:meta-toolchain hosttools In other words, if the user specified the "default" task explicitly, it replaces the implicit "default" task. [YOCTO#10680] (Bitbake rev: 3e80d47bea51b64ed6c8bffc033f2d11a630481e) Signed-off-by: Juro Bystricky Signed-off-by: Richard Purdie

bitbake: data_smart: Fix unneeded variable manipulation

2017-03-16T12:49:06+00:00

If was pointed out that if we have: XXX = " A" XXX_remove_inactive-override = "YY" then XXX can become "A" and the leading space can be removed. This is because the remove override code changes the variable value even when there is no removals active. In the process it dirties the cache. We don't really need to do this so tweak the code accordingly. (Bitbake rev: f1ee6dfd3d193a9055320bdd555c1dbaa63f9475) Signed-off-by: Richard Purdie

bitbake: tinfoil: clean environment when starting up cooker

2017-02-03T09:52:19+00:00

During normal bitbake execution, the environment is cleaned of variables not on a whitelist while starting up cooker, and then restored afterwards. Prior to the tinfoil2 rework in master we were taking a number of shortcuts within tinfoil and one of those was not doing this environment cleaning. However, prior to OE-Core rev 3d39ca5c91dbb62fb43199f916bd390cd6212e3d we didn't have any code (as far as I'm aware) that was affected by this shortcut, hence why this wasn't an issue up to now. The result is the following error when attempting to run "devtool build" in the eSDK, as CCACHE_PATH is allowed through from the eSDK's environment setup script: ----------- snip ----------- ccache: error: Could not find compiler "gcc" in PATH ... subprocess.CalledProcessError: Command 'gcc --version' returned non-zero exit status 1 ----------- snip ----------- We can fix this by simply doing the environment filtering while we are starting up cooker, thus the environment when uninative.bbclass comes to do the gcc version check it is not affected by CCACHE_PATH or other variables in the external environment that should be filtered out. For clarity, this patch is only applicable to the bitbake 1.32 branch as used for the OE-Core morty branch - master uses the reworked tinfoil2 and doesn't need this fix. Fixes [YOCTO #10961]. (Bitbake rev: a240f5ff71092cb209c44a071cd6fa07756ccfa0) Signed-off-by: Paul Eggleton Signed-off-by: Richard Purdie

bitbake: cookerdata: Convert multiconfig to use BB_CURRENT_MC

2017-01-11T17:21:47+00:00

People are struggling with multiconfig as the point the conf file is injected into the data store is not what people expect. We can't really use a post config since that is too late and we can't really use a pre config file since that is too early. In OE terms, we need something right around the local.conf point so it behaves in a similar way. A way to handle this is to set the new variable BB_CURRENT_MC to be the currently selected multiconfig, then the metadata itself can choose when to inject the approriate configuration. (Bitbake rev: 1469828fa747da0aaaa3e964954ff17f2b3180fa) Signed-off-by: Richard Purdie

bitbake: runqueue: Only start fakeroot workers when needed

2017-01-11T17:21:47+00:00

Fakeroot workers usually have dependencies that need to be ready before they can be started. Starting them as a block therefore doesn't work as the dependencies may or may not have been built. Therefore start the multiconfig fakeworkers individually upon demand. [YOCTO #10344] (Bitbake rev: ac5ea74152b011256209c8b5664216f290b123e8) Signed-off-by: Richard Purdie