summaryrefslogtreecommitdiffstats
path: root/bitbake/lib/bb
Commit message (Collapse)AuthorAgeFilesLines
* bitbake: providers: Fix determinism issueRichard Purdie2018-03-091-3/+3
| | | | | | | | | | | | | | | | | | We saw builds where runtime providers were sometimes changing order and the build result was therefore non-deterministic. For example it could show: DEBUG: providers for lib32-initd-functions are: ['lib32-lsbinitscripts', 'lib32-initscripts'] or DEBUG: providers for lib32-initd-functions are: ['lib32-initscripts', 'lib32-lsbinitscripts'] which could cause a test to pass or fail. This change ensures we don't rely on the random order of dictonaries in memory and act deterministically. (Bitbake rev: da85da9b58ed252c7b80a437fb5babff9e6dde48) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: fetch2: Do not fail to create symbolic links if they already existPeter Kjellerstedt2017-12-181-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: 5f5e13bacde95a93633f621ec6b94a022c476a58) Signed-off-by: Peter Kjellerstedt <pkj@axis.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: Replace deprecated git branch parameter "--set-upstream"Andre Rosa2017-11-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | Since 2017-08-17 (git version 2.14.1.473.g3ec7d702a) using deprecated git branch parameter "--set-upstream" causes a fetcher error. Replace it by "--set-upstream-to". https://git.kernel.org/pub/scm/git/git.git/commit/?id=52668846ea2d41ffbd87cda7cb8e492dea9f2c4d says, it's deprecated since 2012-08-30 so hopefully all still supported host distributions have new enough git to support "--set-upstream-to". ERROR: PACKAGE do_unpack: Fetcher failure: ...; git -c core.fsyncobjectfiles=0 branch --set-upstream master origin/master failed with exit code 128, output: fatal: the '--set-upstream' option is no longer supported. Please use '--track' or '--set-upstream-to' instead. ERROR: PACKAGE do_unpack: Function failed: base_do_unpack (Bitbake rev: 991b533f1d61042a7b3edd1fbf3dea0bf9991606) Signed-off-by: Andre Rosa <andre.rosa@lge.com> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: wget: Fix handling of urls with user/passwordRichard Purdie2017-08-291-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: 32a249cf33f79b579a2cf6224c7d23cdb20d376f) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: codeparser.py: support deeply nested tokensPatrick Ohly2017-07-211-12/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | 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 <patrick.ohly@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: siggen: Make calc_taskhash match get_taskhash for file checksumsRichard Purdie2017-06-271-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: df69c0257aaa9f4e2f4a20d130b7bc0ce2ca0848) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker.py: run sanity checks for multiconfigJuro Bystricky2017-03-161-1/+2
| | | | | | | | | | | | 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 <juro.bystricky@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker.py: new multiconfig '*' syntax supportJuro Bystricky2017-03-161-1/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <juro.bystricky@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: data_smart: Fix unneeded variable manipulationRichard Purdie2017-03-161-7/+8
| | | | | | | | | | | | | | | | | 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 <richard.purdie@linuxfoundation.org>
* bitbake: tinfoil: clean environment when starting up cookerPaul Eggleton2017-02-031-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cookerdata: Convert multiconfig to use BB_CURRENT_MCRichard Purdie2017-01-111-2/+3
| | | | | | | | | | | | | | | | | 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 <richard.purdie@linuxfoundation.org>
* bitbake: runqueue: Only start fakeroot workers when neededRichard Purdie2017-01-111-8/+7
| | | | | | | | | | | | | 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 <richard.purdie@linuxfoundation.org>
* bitbake: runqueue: Ensure setscene tasks with overlapping stamps don't ↵Richard Purdie2017-01-111-1/+5
| | | | | | | | | | | | | | | parallel execute In multiconfig, mutliple tasks can execute which share the same stamp file. These must not execute in parallel, the idea is the first should execute, the subsequent ones should see a valid stamp and get skipped. The normal task execution code has stamps code to handle this, this adds similar code to the setscene execute() function to handle the issue there too. (Bitbake rev: df8408a6b54fc908d4de81529b34477b8924d181) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: runqueue: Fix setscene issues with multiconfigRichard Purdie2017-01-111-19/+19
| | | | | | | | | | | | | | | | setscene was being entirelu skipped for multiconfig variants as the tasks were simply not being spotted. If the default config was also being built it masked the problem. When this was fixed by using taskfn instead of fn in lookups against dataCache, several other instances of this problem were highlighted. This goes through and corrects the setscene code to correclty use taskfn instead of fn in the appropriate places meaning setscene tasks for multiconfig now work correctly. (Bitbake rev: a5d81eefe9106f2080001b7313e2b15ab21ea55b) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: siggen: Fix clean_basepath to work with multiconfigRichard Purdie2017-01-111-0/+5
| | | | | | | | | | Tasknames can now start with "multiconfig:" which broke the virtual: comparison code and lead to unpredictable checksums with nativesdk recipes. This adds in handling for the new additional prefix which unbreaks nativesdk builds when using multiconfig. (Bitbake rev: 0ca6b8438624d892ee7ef3b42df0024604b64567) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: build/uihelper: Show better information about multiconfig tasks on UIRichard Purdie2017-01-112-1/+5
| | | | | | | | | | Currently the UI shows X is building, possibly multiple times but doesn't say which of the multilibs that might be. This adds a prefix to the task name so the mulitconfig being built can be identified. (Bitbake rev: dfb775c67a96a79f3b85104870c0ade46ef2a9ea) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: runqueue: Ensure pseudo executes from the correct place (use the ↵Richard Purdie2017-01-111-2/+3
| | | | | | | | | | | | | | right datastore with multiconfig) The location of the fakeroot command and the various environmental values need to be taken from the right multiconfig datastore, not the shared one. This patch ensures the right one is used for cases like a split TMPDIR. [YOCTO #10344] (Bitbake rev: c241f16670cada2cdf45ecddb4961e16edb83486) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: cooker: Handle inofity queue overflows more gracefullyRichard Purdie2017-01-111-0/+8
| | | | | | | | | | | | | | | If many files change and the inotify queue overflows, rather than print a traceback, invalidate the caches and warn the user. [YOCTO #10676] (Bitbake rev: 058f8517c041b80e8b591ad7d34a68281b2d03fc) (Bitbake rev: 4fafb6c6d261de78dd1bc3824a1389d191b70321) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> Signed-off-by: Armin Kuster <akuster808@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: cooker: Fix world taskgraph generation issueRichard Purdie2017-01-111-4/+10
| | | | | | | | | | | | | | | | | | The processing of the "do_" prefix to tasks is currently inconsistent and has resulted in "bitbake world -g" being broken as task prefixes don't get handled correctly. Make the "do_" task prefix handling consistent through various codepaths. [YOCTO #10651] (Bitbake rev: 3d7186353e804c9410096c408bc337a98c8b33fe) (Bitbake rev: 100439e715841ecfd6460d59cd51c831184b328d) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> Signed-off-by: Armin Kuster <akuster808@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: utils: Avoid traceback errorsRichard Purdie2017-01-111-1/+1
| | | | | | | | | | | | | | Avoid errors like: ERROR: Exception handler error: 'NoneType' object has no attribute 'decode' (Bitbake rev: 1aeb45abe56061f044c2347889c191d5256ff21f) (Bitbake rev: 1f08fe503b484d4cf5e093f9e3e4c9bbe0be4eda) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> Signed-off-by: Armin Kuster <akuster808@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: data: fix exception handling in exported_vars()Markus Lehtonen2016-11-161-3/+5
| | | | | | | | | | | | | | | Fix a bug where a totally wrong value of a variable would be exported if an exception happened during d.getVar(). Also, print a warning if an exception happends instead of silently ignoring it. It would probably be best just to raise the exception, instead, but use the warning for now in order to avoid breaking existing builds. [YOCTO #10393] (Bitbake rev: 59c606cfc6e0a4f367344d4e3def6017fb560d75) Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: siggen: Ensure taskhash mismatches don't override existing dataRichard Purdie2016-11-161-9/+9
| | | | | | | | | | | | We recalculate the taskhash to ensure the version we have matches what we think it should be. When we write out a sigdata file, use the calculated value so that we don't overwrite any existing file. This leaves any original taskhash sigdata file intact to allow a debugging comparison. (Bitbake rev: dac68af6f4add9c99cb7adcf23b2ae89b96ca075) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: siggen: Pass basehash to worker processes and sanity check ↵Richard Purdie2016-11-161-4/+9
| | | | | | | | | | | | | | | | | | | | | | | | reparsing result Bitbake can parse metadata in the cooker and in the worker during builds. If the metadata isn't deterministic, it can change between these two parses and this confuses things a lot. It turns out to be hard to debug these issues currently. This patch ensures the basehashes from the original parsing are passed into the workers and that these are checked when reparsing for consistency. The user is shown an error message if inconsistencies are found. There is debug code in siggen.py (see the "Slow but can be useful for debugging mismatched basehashes" commented code), we don't enable this by default due to performance issues. If you run into this message, enable this code and you will find "sigbasedata" files in tmp/stamps which should correspond to the hashes shown in this error message. bitbake-diffsigs on the files should show which variables are changing. (Bitbake rev: 46207262ee6cdd2e49c4765481a6a24702ca4843) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: build: Ensure we preserve sigbasedata files as well as sigdata onesRichard Purdie2016-11-161-1/+1
| | | | | | | | | We don't remove sigdata files, we also shouldn't remove sigbasedata files as this hinders debugging. (Bitbake rev: 06e7c00f2e1ddda6a2632ec2354a3c8f5c34562d) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: toaster: buildinfohelper Handle regex pathsbrian avery2016-11-031-1/+26
| | | | | | | | | | | | | | We were presuming that all the layer dependency information was of the form "^/path/to/layer" to we were just stripping the leading "^" off of the layer information when we were matching the layer priorities to the toaster database. This patch splits out the priorities layer match which gets a regex from the task/recipe match which is gets a path. (Bitbake rev: 82775c80d169266cc18ca2b2065a05c79dc6fbfc) Signed-off-by: brian avery <brian.avery@intel.com> Signed-off-by: Michael Wood <michael.g.wood@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bb.event: fix infinite loop on print_ui_queueAníbal Limón2016-10-151-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | If bitbake ends before _uiready and bb.event.LogHandler was add to the bitbake logger it causes an infinite loop when logging something. The scenario is print_ui_queue is called at exit and executes the log handlers [2] one of them is bb.event.LogHandler this handler appends the same entry to ui_queue causing the inifine loop [3]. In order to fix a new copy of the ui_queue list is created when iterate ui_queue. [YOCTO #10399] [1] https://bugzilla.yoctoproject.org/show_bug.cgi?id=10399#c0 [2] http://git.openembedded.org/bitbake/tree/lib/bb/event.py?id=41d9cd41d40b04746c82b4a940dca47df02514fc#n156 [3] http://git.openembedded.org/bitbake/tree/lib/bb/event.py?id=41d9cd41d40b04746c82b4a940dca47df02514fc#n164 (Bitbake rev: 46fecca9d531a07788b5cac8b2dc6a8267d8b6d0) Signed-off-by: Aníbal Limón <anibal.limon@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: runqueue.py: Remove redundant whitelist checksRandy Witt2016-10-111-1/+4
| | | | | | | | | | | | | The whitelist checks for BB_SETSCENE_ENFORCE were running for every call to execute(). Since the task list doesn't change for each call into execute, the checks only need to be ran once. [YOCTO #10369] (Bitbake rev: f65e631ab6705dfd9188f19ee423eca33bca7d7d) Signed-off-by: Randy Witt <randy.e.witt@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: Update version to 1.32.0Richard Purdie2016-10-111-1/+1
| | | | | | (Bitbake rev: d9713ed13d0c88c7ee38e8d7b52aa525318af6e3) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: depexp: Close UI with error message on NoProvider eventJussi Kukkonen2016-10-111-0/+24
| | | | | | | | | | | | | | Without this the UI just sits there doing nothing. Showing an infobar in-UI would be nicer but not much more useful since currently user couldn't do anything in-UI to fix the situation. Implementation is based on the one in knotty. Fixes [YOCTO #9288] (Bitbake rev: eee9231a543f1d0b9ef3cd8377fc46fd23afb97b) Signed-off-by: Jussi Kukkonen <jussi.kukkonen@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: main: Check bitbake server-only port is a numberBenjamin Esquivel2016-10-091-0/+7
| | | | | | | | | | | | | | | | Either using the memres script or the bitbake call with --server-only if the port is a string instead of a number then the process hangs indefinitely causing a loop that never ends. Add a check at the beginning for the port being a number otherwise show an error message and exit cleanly. [YOCTO #10397] (Bitbake rev: 35927a98daeeb854ef5782e900206af6cd96b3d7) Signed-off-by: Benjamin Esquivel <benjamin.esquivel@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: runqueue: Optimise task id string manipulationsRichard Purdie2016-10-092-52/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | Some task id manipulations were suboptimal: * taskfn_fromtid and fn_from_tid were effectively the same function * many calls to split_tid(), then taskfn_fromtid() * taskfn_fromtid() called split_tid() internally This patch adds split_tid_mcfn() to replace split_tid() and returns the "taskfn" variant being used in many places. We update all core calls to the new function and ignore the return values we don't need since the function call overhead of the split_tid wrapper is higher than ignoring a return value. The one remaining standalone use of taskfn_fromtid is replaced with fn_from_tid. I couldn't see any external usage so it was dropped. There is external usage of split_tid so a wrapper remains for it. Combined together these changes should improve some of the runqueue task manipulation performance. (Bitbake rev: 1bf2ef874fbe47f1320007efa0bdeef8d630b8a1) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bb.runqueue: fix unexpected process death logicChristopher Larson2016-10-091-10/+5
| | | | | | | | | | | | | | | | | | | | | `if w in self.rq.worker` when w *is* self.rq.worker doesn't make a great deal of sense, and results in this error: File ".../poky/bitbake/lib/bb/runqueue.py", line 2372, in runQueuePipe.read(): name = None > if w in self.rq.worker: name = "Worker" TypeError: unhashable type: 'dict' Most likely this was meant to be 'is' rather than 'in', but rather than checking after the fact, just include the name in the iteration, instead. While we're here, also clean up and fix the broken error message. (Bitbake rev: 267e025cad44c8bd0fb157f1f7a2e08df117ba84) Signed-off-by: Christopher Larson <chris_larson@mentor.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: ui/knotty.py: Fix signal handling of SIGWINCH in BBProgressAníbal Limón2016-10-091-7/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add the ability to pass default signal handler for SIGWINCH in BBProgress because with multiple instace of BBProgress the original signal handler set by TerminalFilter (sigwinch_handle) is lost. This is a fix for stack trace due to multiple async calls of ProgressBar _handle_resize (ioctl to terminal fd), see: NOTE: Executing SetScene Tasks Fatal Python error: Cannot recover from stack overflow. Current thread 0x00007f70a4793700 (most recent call first): File "/home/alimonb/repos/poky/bitbake/lib/progressbar/progressbar.py", line 183 in _handle_resize File "/home/alimonb/repos/poky/bitbake/lib/bb/ui/knotty.py", line 58 in _handle_resize File "/home/alimonb/repos/poky/bitbake/lib/bb/ui/knotty.py", line 60 in _handle_resize ... File "/home/alimonb/repos/poky/bitbake/lib/bb/ui/knotty.py", line 60 in _handle_resize ... Aborted (Bitbake rev: 812bd49cb569379ee90d5be28a4b6e60645f1e54) Signed-off-by: Aníbal Limón <anibal.limon@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: toaster: buildinfohelper: Use correct way to get message from ↵Michael Wood2016-10-061-6/+3
| | | | | | | | | | | | | | | LogMessage Use the correct method to get a message value from the LogMessage object rather than constructing it ourselves which is not recommended. This causes an exception when the msg contains a '%' such as when there are wildcards in file names (something2.%.bbappends) (Bitbake rev: 11b3b6a7087554d14a2812a9ae463dce740b879e) Signed-off-by: Michael Wood <michael.g.wood@intel.com> Signed-off-by: bavery <brian.avery@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bb.build: in _exec_task, catch errors from TaskStartedChristopher Larson2016-10-051-16/+24
| | | | | | | | | | | | | | | We don't always want a traceback when an exception is raised by the TaskStarted event handler. Silently return if we get a SystemExit or HandledException, and print the error and return for FuncFailed. This is done via a separate try/catch block, to avoid firing TaskFailed if all the TaskStarted event handlers didn't complete, otherwise the bitbake UIs get unhappy. (Bitbake rev: ca5b788280ad4303cc08a376e847cbbeda31970c) Signed-off-by: Christopher Larson <chris_larson@mentor.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: event: prevent unclosed file warning in print_ui_queueJoshua Lock2016-10-051-3/+3
| | | | | | | | | | | | | | | | Use logger.addHandler(), rather than assigning an array of Handlers to the loggers handlers property directly, to avoid a warning from Python 3 about unclosed files: $ bitbake Nothing to do. Use 'bitbake world' to build everything, or run 'bitbake --help' for usage information. WARNING: /home/joshuagl/Projects/poky/bitbake/lib/bb/event.py:143: ResourceWarning: unclosed file <_io.TextIOWrapper name='/home/joshuagl/Projects/poky/build/tmp/log/cooker/qemux86/20161004094928.log' mode='a' encoding='UTF-8'> logger.handlers = [stdout] (Bitbake rev: 1e23b1f1a80066223b98e18b163840051ac74944) Signed-off-by: Joshua Lock <joshua.g.lock@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: Update version to 1.31.2Richard Purdie2016-10-051-1/+1
| | | | | | (Bitbake rev: 100a0aef3d121d950d89c4152f56957628f2f933) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bb/event.py: fire_ui_handlers enable threading lock supportAníbal Limón2016-10-051-0/+21
| | | | | | | | | | | | | | | In some cases there is a need to fire bb events into multiple python threads so locking is needed (writing to a fd/socket). Adding a helper functions for disable/enable by request to avoid overhead. [YOCTO #10330] (Bitbake rev: a583dc0b296415ec904c081c4de96ceef46732a8) Signed-off-by: Aníbal Limón <anibal.limon@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: data: Fix handling of vardepvalueexcludeRichard Purdie2016-10-011-1/+1
| | | | | | | | | | | | | The value used for exclusion was always being expanded. This is actually a bad idea since in most cases you'd want to exclude an unexpanded value and makes it impossible to use the variable as intended. This adjusts things so the value is not expanded and we can correctly remove things from checksums much more easily. (Bitbake rev: 81bc8201c475d2b6bef0168573915ad0140f6dad) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: toaster: make error message more informativeEd Bartosh2016-09-301-1/+1
| | | | | | | | | | | | | | | | | Error message ERROR: Unprocessed MetadataEvent <bb.event.MetadataEvent object at 0x7f750e671a58> doesn't give a lot of information about the event. It just prints event object, which is always bb.event.MetadataEvent. Including event type into the error message should make it more informative: ERROR: Unprocessed MetadataEvent TaskArtifacts (Bitbake rev: 603c7c13536d3fa1786270e863688c1d2e511196) Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com> Signed-off-by: Michael Wood <michael.g.wood@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: toaster: fix 'Unhandled MetadataEvent' errorEd Bartosh2016-09-301-0/+4
| | | | | | | | | | | | New MetadataEvent 'TaskArtifacts' causes this error. Processing of this event will hopefully be implemented in future. For now it should be enough to just skip it. (Bitbake rev: 114a3fe3f23ef09782c5aa18f425d0d0dbdfdd35) Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com> Signed-off-by: Michael Wood <michael.g.wood@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: toaster: fix handling of EnvironmentErrorEd Bartosh2016-09-301-3/+6
| | | | | | | | | | | | | Due to the bug in processing EnvironmentError exception, toasterui ignores it. As EnvironmentError is a base for OSError and IOError this means that all OSError and IOError exceptions were silently ignored. (Bitbake rev: c8f4ca008bf9396b0ed45d44bfe2220c82a614a9) Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com> Signed-off-by: Michael Wood <michael.g.wood@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: toaster: check if file existEd Bartosh2016-09-301-0/+3
| | | | | | | | | | | | | | | | | | Buildinfohelper assumes that all files mentioned in manifest exist in deploy/ directory, which is not always the case. Toaster crashes with OSError trying to call os.stat on non-existing file. Checking if file exists before processing it should fix this. [YOCTO #10185] (Bitbake rev: 54565e7ca84d2722a2454e7fa52cda564b28b527) Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com> Signed-off-by: Michael Wood <michael.g.wood@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: runqueue: Ensure worker failure is accounted for in task statisticsRichard Purdie2016-09-301-0/+1
| | | | | | | | | | | | | If the worker fails to launch, ensure the task is shown as failed rather than a confusing "all succeeded" message. Patch from Juro Bystricky [YOCTO #10335] (Bitbake rev: 0e9a2ff96d138641501874a1cd7aa6cc7e94d727) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: build.py: fix os.getcwd() exceptionJuro Bystricky2016-09-281-2/+7
| | | | | | | | | | | | | When trying to obtain the current directory from a directory that does not exist anymore, an exception is raised. This patch handles such exception. [YOCTO #10331] (Bitbake rev: 4bcf77589312d9936340d8c308006c2fc9baf67c) Signed-off-by: Juro Bystricky <juro.bystricky@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: knotty: ensure progress bar output is accounted for in displayPaul Eggleton2016-09-231-5/+4
| | | | | | | | | | | | | | | | | | | | When calculating how many lines we'd printed we weren't properly taking the progress bars into account, with the result that sometimes if the last line printed on the terminal wrapped to the next line (which is possible) we backed up less lines than we should have. Additionally, we should always print a newline after updating the progress bar - there's no need to check if there wasn't output (there always will be courtesy of our overridden _need_update()) and we now allow the line to wrap so we don't need to check the other condition either. Hopefully this will fix [YOCTO #10046]. (Bitbake rev: 326d18d96faf02675ba34ad3c3a20cd424b39b91) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: knotty: Show task elapsed timeRichard Purdie2016-09-231-1/+10
| | | | | | | | | | | | | Its often useful to know how long a task has been running for. This patch adds that information to the task display, updating every 5s if there were no other updates so the user can see how long tasks have been running for. [YOCTO #9737] (Bitbake rev: 6c42025e5dd7761213be3f82f3252a7892d2239d) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker/providers: Only add target to world build if task existsRichard Purdie2016-09-222-4/+7
| | | | | | | | | | | A "bitbake world -c unpack" currently breaks as not all tasks have an unpack task. This change allows addition of world targets only if the specified task exists which makes certain commands possible when otherwise you just get errors which can't easily be avoided. (Bitbake rev: ca4f5e6d01b5c8cf315f59bc86194d63c0d3d042) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: fetch2: handle absolute paths in subdirRoss Burton2016-09-222-1/+16
| | | | | | | | | | | | | | | | Currently if you use the subdir parameter in a SRC_URI and pass an absolute path then it gets appended to the unpack directory instead of being used directly. This is inconvenient as it may be useful to use ${S} when you want to unpack a file into the source tree. Change this behaviour so that absolute paths are used directly instead of being appended to the root directory. To ensure that recipes cannot write files to an arbitrary location enforce that the subdir starts with the unpack root. (Bitbake rev: c3873346c6fa1021a1d63bddd9b898a77c618432) Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bb.build: in _exec_task, catch BBHandledExceptionChristopher Larson2016-09-211-0/+3
| | | | | | | | | | We don't want a traceback for this exception, we need to catch it, fire TaskFailed, and return failure. (Bitbake rev: 63966ada459d44d3dc7817ad2a026a22e8f6700f) Signed-off-by: Christopher Larson <chris_larson@mentor.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
generated by cgit v1.2.3-54-g00ecf (git 2.39.0) at 2024-05-28 16:54:25 +0000