summaryrefslogtreecommitdiffstats
path: root/bitbake/lib/bb/command.py
Commit message (Collapse)AuthorAgeFilesLines
* bitbake: command: Ensure we catch/handle exceptionsRichard Purdie2021-08-061-3/+11
| | | | | | | | | | | If an exception occurs in early setup, bitbake could just hang. Return the exception rather than doing that. [YOCTO #14408] (Bitbake rev: c8a4107132ce51f84ae84bf1ceb1c3fd90f156d3) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: tinfoil/data_smart: Allow variable history emit() to function remotelyRichard Purdie2021-04-181-0/+12
| | | | | | | | | | We can't access the emit() function of varhistory currently as the datastore parameter isn't handled correctly, nor is the output stream. Add a custom wrapper for this function which handles the two details correctly. (Bitbake rev: ba0fa084ccd2b1ade96425d158fd31e49e42f286) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: command: Ensure exceptions inheriting from BBHandledException are ↵Richard Purdie2020-10-101-1/+5
| | | | | | | | | | | | | | visible Previous changes allowed BBHandledException to be detected but not exceptions which inherit from it. Fix this. The code really needs totally reworking to preserve the exceptions. [YOCTO #14054] (Bitbake rev: ef762d92df6c2554c6248e80212f984d9ec4c651) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker/command: Fix disconnection handlingRichard Purdie2020-09-121-1/+2
| | | | | | | | | | After the recent init changes, if a client disconnects before issuing a command, the cooker can break in the reset handlers. Add some guards in the code to prevent this. (Bitbake rev: 12605e30e4c4e1ae6a67c97363b892ebf0b9566c) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker: Defer configuration init to after UI connectionRichard Purdie2020-08-251-1/+8
| | | | | | | | | | | | | Currently we end up parsing the base configuration multiple times as initially, the right settings haven't come from the UI. We can defer this until later in startup using runCommand as a trigger. The advantage to doing this is improved startup times and ultimately we should be able to avoid the double parse of the base configuration. (Bitbake rev: 3caa43b665604475d2c87ba505efb0b9fca9c2e9) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: server/process: Simplfy idle callback handler functionRichard Purdie2020-08-131-1/+1
| | | | | | | | | | Having the idle callbacks abstracted via the configuration object makes no sense. Its like this for historical reasons from the multiple server backends but we don't need this now so simplfy. (Bitbake rev: e56c49717355c9493b07d5fc80981a95ad8a0ec8) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: command: Handle multiconfig in findSigInfoJoshua Watt2020-07-251-3/+3
| | | | | | | | | | Changes the findSigInfo command to accept a recipe specified with the multiconfig prefix (Bitbake rev: 379951b6417eacbafc92ac1413ae1358bafdddfb) Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker: Fix unmatched files handling leading to misleading warningsRichard Purdie2020-07-211-1/+1
| | | | | | | | | | | | | | | | | | | | | Currently if all recipes in a layer are skipped, there are warnings that the BBFILE_PATTERN_ entry didn't match anything. We probably shouldn't do this for skipped recipes. The current code is hard to understand, not least as it passes variables which functions modify by reference rather than giving a return value. Update calc_bbfile_priority() to return values rather than modifying them. Refactor the code to try and make it clearer what its doing and fix the skipped recipe issue by passing in the list of parsed files. The function is complicated by the need to not rerun regex matching more than we ever have to which complicates the flow, it would be easier if we just reran operations multiple times. (Bitbake rev: 969cb27b4d978551817612ff4558bec81cfb655c) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: command: Move split_mc_pn to runqueueJoshua Watt2020-06-101-7/+1
| | | | | | | | | | | | | All of the other multiconfig splitting functions are located in runqueue so move the function to split a pn/fn there also so that its easier to see them all together. Fixes a case where the findBestProvider() command wasn't working for multiconfig because it was looking for a prefix of "multiconfig:" instead of the newer "mc:" (Bitbake rev: 325827af66434affc2da460cc8b9a5c460e38056) Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: cooker: Split file collections per multiconfigJoshua Watt2020-06-101-8/+29
| | | | | | | | | | | | Splits the cooker to track a collection per multiconfig instead of a single collection for all multiconfigs. Practically speaking, this allows each multiconfigs to each have different BBMASKs that apply to it instead of each one using the mask specified in the base configuration. (Bitbake rev: dd6d8eca2027f8d9be8a734a493227b440075e49) Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: tinfoil: Add back ability to parse on top of a datastoreRichard Purdie2020-04-061-2/+1
| | | | | | | | | | | This option was removed recently as we didn't realise the layerindex relies upon it. Add back the API which it turns out can be supported as long as we assume the datastore passed in is a remote datastore which it usually would be unless created locally. (Bitbake rev: 4618da2094189e4d814b7d65672cb65c86c0626a) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: tinfoil: Simplify remote datastore connectionsRichard Purdie2020-03-241-66/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current approach to remote datastores used in tinfoil is breaking. For example, adding a devupstream extension to a recipe with a git upstream, making it the preferred version and then running "devtool modify" on it causes get_srcrev() circular dependency issues. The problem is the override handling in the datastore is broken. This gets broken since remotedata:recieve_datastore() sets d.dict but doesn't update d.overridedata (or d.inchistory or d.varhistory). We could play whack-a-mole but the current implementation seems to be flawed to me. It also doesn't cover, or only partially covers some datastore operations and each needs new dedicated command API. Instead, step back and reimplement the way the datastore connector works. With this change, the datastore is either remote or local but the data is not spread on two sides of the connection. All the API is proxied over the connection by a single function for the datastore (and two to support variable history and include history). This code does not support using the datastore as a parameter to any data store functions. We did have one case of that but its just bad code and can be replaced. The result is something which is much simpler and less invasive to the datastore code itself, meaning its behaviour should be much more consistent. The existing tests for the remote data no longer make any sense and are removed. The one bug this code would have is if key/value pairs are returned over the IPC and those values contained a DataSmart object since we don't recurse into return values to find such things. Nothing appears to do that currently so lets worry about it if its ever an issue. This change should simplfy a ton of other issues and avoid a ton of other bugs so is a huge net gain. Tested with bitbake's and OE's selftests. (Bitbake rev: 85e03a64dd0a4ebe71009ec4bdf4192c04a9786e) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: command: Add mc parameter to findProviders commandJoshua Watt2020-03-071-1/+5
| | | | | | | | | | | Adds a multiconfig selection parameter to the findProviders command. This allows a client to find the providers for a specific multiconfig instead of the base configuration. (Bitbake rev: 95bb446137734865f3fe04fe97681d90250deb11) Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: lib: amend code to use proper singleton comparisons where possibleFrazer Clews2020-01-191-1/+1
| | | | | | | | | | | amend the code to handle singleton comparisons properly so it only checks if they only refer to the same object or not, and not bother comparing the values. (Bitbake rev: b809a6812aa15a8a9af97bc382cc4b19571e6bfc) Signed-off-by: Frazer Clews <frazer.clews@codethink.co.uk> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: Drop duplicate license boilerplace textRichard Purdie2019-05-041-12/+0
| | | | | | | | | | With the introduction of SPDX-License-Identifier headers, we don't need a ton of header boilerplate in every file. Simplify the files and rely on the top level for the full licence text. (Bitbake rev: 695d84397b68cc003186e22f395caa378b06bc75) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: Add initial pass of SPDX license headers to source codeRichard Purdie2019-05-041-0/+2
| | | | | | | | | | | | | | | | | This adds the SPDX-License-Identifier license headers to the majority of our source files to make it clearer exactly which license files are under. The bulk of the files are under GPL v2.0 with one found to be under V2.0 or later, some under MIT and some have dual license. There are some files which are potentially harder to classify where we've imported upstream code and those can be handled specifically in later commits. The COPYING file is replaced with LICENSE.X files which contain the full license texts. (Bitbake rev: ff237c33337f4da2ca06c3a2c49699bc26608a6b) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker: clear extra config settings and remote datastores on client ↵Paul Eggleton2017-09-051-0/+3
| | | | | | | | | | | | | | | | | | disconnect When the UI disconnects, we can throw away any server-side remote datastores we created in response to calls from the UI, and we *must* drop everything in extraconfigdata or it will taint any future operations. Dropping extraconfigdata upon disconnect fixes taskhash mismatch errors when running devtool.DevtoolTests.test_devtool_update_recipe_local_files within oe-selftest with BB_SERVER_TIMEOUT=100 in OpenEmbedded. (Bitbake rev: 1ca2eec459424892391f060442ef38cf28d6a54a) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: command: Fix some bugs identified by BB_SERVER_TIMEOUTRichard Purdie2017-08-311-1/+2
| | | | | | | | | | | | | | | | | | | | The 'needconfig' flag was meant to be the default as most commands do need it and the "False" cases were the exception. The code was written backwards with a default False value. Invert this to match the intent, resulting in the config being reparsed if metadata has changed. Also ensure the second level configuration is parsed for the getLayerPriorities command as otherwise it can return stale info. With these changes: BB_SERVER_TIMEOUT=100 oe-selftest -r bblayers.BitbakeLayers.test_bitbakelayers_add_remove passes instead of fails. (Bitbake rev: af3c8928a69f204d5ced02c947485990ac04a776) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker: Ensure we handle inotify before running the next commandRichard Purdie2017-08-131-0/+2
| | | | | | | | | | | | | | The inotify watch events are handled "at idle" which could in theory mean a command could run before any preceeding inotify events have been processed. This leads to a theoretical race window where those events may have a signficicant effect on the command. Add a mechanism to allow us to ensure all pending events are processed before running commands. (Bitbake rev: bf76cd7e5881adf264b8ba64e27a5b6ca9df4fde) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake-diffsigs: fix regression after recent server changesPaul Eggleton2017-07-271-0/+11
| | | | | | | | | | | | | | | | | | We were bridging the gap between the server and UI here by calling a bb.siggen.find_siginfo, a function defined and set on that module from the metadata. This worked from the UI side before but since the recent server changes is no longer accessible. Create a new command so this can execute on the server side and return the result by way of a new event. (We're still running compare_sigfiles() on the signature generator but that isn't quite the same thing and does still work.) Fixes [YOCTO #11844]. (Bitbake rev: fdcea991baa4f83d9c98d468d7b49c8c388a4a15) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: tinfoil: enable access to additional cached itemsPaul Eggleton2017-07-211-0/+32
| | | | | | | | | | | Add access to fn_provides, packages, packages_dynamic and rproviders on the recipecache object. This requires an additional corresponding command plumbing to be added. (Bitbake rev: 3df9b7c615174a6557581f3cd157842a28f6bb26) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: lib/bb/event: refactor printing eventsPaul Eggleton2017-07-211-0/+2
| | | | | | | | | | | | We really ought to have just one place where the string representation of these events is produced. This doesn't take any real control away from the UI - if an alternative representation is desired, that can still be made. (Bitbake rev: cb15db2a799be6d8eab9a2a43a9a573f89229cff) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: tinfoil: add internal mode to build_file() functionPaul Eggleton2017-07-211-3/+6
| | | | | | | | | | | | | | | | | In OE's devtool we want to repeatedly run build_file() without showing unnecessary messages and triggering buildhistory for each call. build_file() is just a wrapper around the buildFile command. Change the final "hidewarning" parameter of the buildFile command to "internal" and have this call a new buildFileInternal() function without triggering any of the normal build events, silencing the normal info messages from the runqueue ("Executing RunQueue Tasks", "Tasks Summary" etc.) and avoiding calling parseConfiguration() which we've already done at this point. (Bitbake rev: ba53e067a2d448dd63b4ca252557ce98aa8e6321) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: event/command: Allow UI to request the UI eventhander IDRichard Purdie2017-07-211-0/+5
| | | | | | | | | | | | The UI may want to change its event mask however to do this, it needs the event handler's ID. Tweak the code to allow this to be stored and add a command to query it. Use the new command in the process server backend. (Bitbake rev: f8cf2cb58b80ce74f756a11a9773b6b0e78d51ee) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: command / cooker: drop Hob support commands and functionsPaul Eggleton2017-06-121-60/+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-121-1/+2
| | | | | | | | | | | | | | | | | | | | | | | 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: 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: 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: data_smart: implement missing remote datastore operationsPaul Eggleton2017-03-221-0/+25
| | | | | | | | | | | | | | | | | | | | | | | | Enable the following operations from a remote datastore to affect the other end: * setVarFlag() * delVar() * delVarFlag() * renameVar() In practice I don't expect these to be used much, but they should be present so that the implementation is at least reasonably filled out and that the tests pass. Also add tests for the interface, mostly by subclassing the existing local test classes so that they are using a remote datastore. (These don't actually test remote usage via tinfoil, just that the datastore's interface can be used.) (Bitbake rev: 282dc0719d22a39df746eea762ebe05c66aa8f8a) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: tinfoil: fix override handling in remote datastoresPaul Eggleton2017-03-221-3/+9
| | | | | | | | | | | | | | | | | | | There was a huge gap in the remote datastore code introduced in the tinfoil2 rework - we weren't handling overrides at all, since these are stored separately from the actual data in the DataSmart object. Thus, when a datastore actually represents a remote datastore we need to go back to that remote datastore to get the override data as well, so introduce code to do that. To avoid a second round-trip I had to modify the _findVar() function to return the override data as well. This will increase the overhead a little when that data is superfluous, but without making the function even uglier I don't think there's a way to avoid that. (Bitbake rev: 4f9d6f060ed247fb6fa2f45668a892a1788d3f91) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker/command: Drop expanded_dataRichard Purdie2016-12-161-3/+3
| | | | | | | | | | | | | | | Some of our metadata assumes that BuildStarted and BuildCompleted events see the same data store. This is the case for buildTarget but not for buildFile and recent changes mean this is now a problem. The update_data() call is now an empty operation and there is no difference between the expanded_data and data so we can simply remove the expanded_data and its references and use data everywhere. This has been inteded for a while but the above issue makes this more pressing to finally clean up. (Bitbake rev: e3694e738e98f26f413ada6860ca7d829d3662f0) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: runqueue: enable setVariable command to affect task executionPaul Eggleton2016-12-141-0/+1
| | | | | | | | | | | | Allow the client to set variables with the setVariable command and have those changes take effect when running tasks. This is accomplished by collecting changes made by setVariable separately and pass these to the worker so it can be applied on top of the datastore it creates. (Bitbake rev: 69a3cd790da35c3898a8f50c284ad1a4677682a4) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker: allow buildFile warning to be hidden programmaticallyPaul Eggleton2016-12-141-1/+5
| | | | | | | | | | If we want to use this function/command internally, we don't want this warning shown. (Bitbake rev: 5cfbb60833e7b12d698c1c2970c17ccf2a4971bf) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: tinfoil: pass datastore to server when expanding python referencesPaul Eggleton2016-12-141-6/+5
| | | | | | | | | | | | | | | | | | | | If you're expanding a value that refers to the value of a variable in python code, we need to ensure that the datastore that gets used to get the value of that variable is the client-side datastore and not just the part of it that's on the server side. For example, suppose you are in client code doing the following: d.setVar('HELLO', 'there') result = d.expand('${@d.getVar("HELLO", True)}') result should be "there" but if the client part wasn't taken into account, it would be whatever value HELLO had in the server portion of the datastore (if any). (Bitbake rev: cbc22a0a9aadc8606b927dbac0f1407ec2736b35) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: tinfoil: implement server-side recipe parsingPaul Eggleton2016-12-141-0/+44
| | | | | | | | | | | | | It's not really practical for us to parse recipes on the client side, we need to do it on the server because that's where we have the full python environment (including any "pure" python functions defined in classes). Thus, add some functions to tinfoil do this including a few shortcut functions. (Bitbake rev: 8f635815d191c9d848a92d51fdbf5e9fd3da1727) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: tinfoil: rewrite as a wrapper around the UIPaul Eggleton2016-12-141-0/+195
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Rewrite tinfoil as a wrapper around the UI, instead of the earlier approach of starting up just enough of cooker to do what we want. This has several advantages: * It now works when bitbake is memory-resident instead of failing with "ERROR: Only one copy of bitbake should be run against a build directory". * We can now connect an actual UI, thus you get things like the recipe parsing / cache loading progress bar and parse error handling for free * We can now handle events generated by the server if we wish to do so * We can potentially extend this to do more stuff, e.g. actually running build operations - this needs to be made more practical before we can use it though (since you effectively have to become the UI yourself for this at the moment.) The downside is that tinfoil no longer has direct access to cooker, the global datastore, or the cache. To mitigate this I have extended data_smart to provide remote access capability for the datastore, and created "fake" cooker and cooker.recipecache / cooker.collection adapter objects in order to avoid breaking too many tinfoil-using scripts that might be out there (we've never officially documented tinfoil or BitBake's internal code, but we can still make accommodations where practical). I've at least gone far enough to support all of the utilities that use tinfoil in OE-Core with some changes, but I know there are scripts such as Chris Larson's "bb" out there that do make other calls into BitBake code that I'm not currently providing access to through the adapters. Part of the fix for [YOCTO #5470]. (Bitbake rev: 3bbf8d611c859f74d563778115677a04f5c4ab43) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: command: provide a means to shut down from the client in memres modePaul Eggleton2016-12-141-0/+8
| | | | | | | | | | In memory resident mode we don't really want to actually shut down since it's only the client going away. (Bitbake rev: 74db369c46043116359101cab70486afd82372c0) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: Convert to python 3Richard Purdie2016-06-021-1/+1
| | | | | | | | | Various misc changes to convert bitbake to python3 which don't warrant separation into separate commits. (Bitbake rev: d0f904d407f57998419bd9c305ce53e5eaa36b24) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: command: make setEventMask readonlyEd Bartosh2016-03-071-0/+1
| | | | | | | | | | | | | | | | Executing setEventMask command when bitbake server is in readonly mode causes runCommand to fail with the following error: 'Not able to execute not readonly commands in readonly mode' Set readonly attribute for setEventMask command to make it working for Toaster UI. This should not do any harm as this command doesn't influence cooker state. (Bitbake rev: 8a47d30b2555255fbf6049c5ed69b29664c32b17) Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com> Signed-off-by: brian avery <avery.brian@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: command: Add getSetVariable commandRichard Purdie2015-10-291-0/+10
| | | | | | | | | | There are some use cases where we want to read a variable but also set the variable to the value read, effectively locking in any expansion of it. This adds such a command. (Bitbake rev: 0c0c524691e3d2ffd9953a106fcc06262cbde910) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: command: ensure sync commands that read configuration see updatesRichard Purdie2015-08-191-1/+12
| | | | | | | | | | | | Add a means of ensuring that synchronous commands that read the results of the configuration trigger a reparse of the configuration if any underlying files have changed. (Bitbake rev: aaf3cc024315450c1674819edf2a4e5cdf293f35) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: command: intercept SystemExit to avoid trashing the serverPaul Eggleton2015-08-191-1/+1
| | | | | | | | | | | | If sys.exit() is called within a command run over XMLRPC, the XMLRPC server is effectively trashed (apparently listening but no longer able to respond to commands). We need to intercept the SystemExit exception and deal with it as we would any other exception. (Bitbake rev: 95e391acbc3b4efd6c77637a1ce815012ae0f09b) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker: properly fix bitbake.lock handlingRichard Purdie2015-08-011-6/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If the PR server or indeed any other child process takes some time to exit (which it sometimes does when saving its database), it can end up holding bitbake.lock after the UI exits, which led to errors if you ran bitbake commands successively - we saw this when running the PR server oe-selftest tests in OE-Core. The recent attempt to fix this wasn't quite right and ended up breaking memory resident bitbake. This time we close the lock file when cooker shuts down (inside the UI process) instead of unlocking it, and this is done in the cooker code rather than the actual UI code so it doesn't matter which UI is in use. Additionally we report that we're waiting for the lock to be released, using lsof or fuser if available to list the processes with the lock open. The 'magic' in the locking is due to all spawned subprocesses of bitbake holding an open file descriptor to the bitbake.lock. It is automatically unlocked when all those fds close the file (as all the processes terminate). We close the UI copy of the lock explicitly, then close the server process copy, any remaining open copy is therefore some proess exiting. (The reproducer for the problem is to set PRSERV_HOST = "localhost:0" and add a call to time.sleep(20) after self.server_close() in lib/prserv/serv.py, then run "bitbake -p; bitbake -p" ). Cleanup work done by Paul Eggleton <paul.eggleton@linux.intel.com>. This reverts bitbake commit 69ecd15aece54753154950c55d7af42f85ad8606 and e97a9f1528d77503b5c93e48e3de9933fbb9f3cd. (Bitbake rev: a29780bd43f74b7326fe788dbd65177b86806fcf) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: command.py: Unlock function included into CommandsSync classLeonardo Sandoval2015-07-091-0/+6
| | | | | | | | | | Function which calls cooker's unlock method, which in turn unlocks bitbake.lock file. (Bitbake rev: e97a9f1528d77503b5c93e48e3de9933fbb9f3cd) Signed-off-by: Leonardo Sandoval <leonardo.sandoval.gonzalez@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker: Rename event_data -> expanded_dataRichard Purdie2015-01-231-3/+3
| | | | | | | | | | event_data would be better named expanded_data, then we can widen its scope to other places in cooker where we need to access an expanded data store. We certainly don't want multiple expanded data stores. (Bitbake rev: 1a3c1c9203e1a1452314954f1cfd771e5c1ce89b) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: command/cooker/knotty: Fix memres handling of command environment ↵Richard Purdie2015-01-211-1/+2
| | | | | | | | | | | | | | | | changes If the environment changes, we need memory resident bitbake to adapt to those changes. This adds in functionality to handle this alongside the configuration option handling code. This means that the common usage: MACHINE=X bitbake Y now works with the memory resident server. (Bitbake rev: 4d1343010da757a0c126bc22475354da44aaf8e3) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: knotty: Ensure commandline parameters are updated in memres serverRichard Purdie2014-09-231-0/+4
| | | | | | | | | | | | | | | | When using options like -k, -f, -v and so on with the memory resident server, they'd currently only be set on the initial values passed to the original command. This ensures they now match those specified on the commandline for the options where this makes sense. To make this work, a command to update the options on the server side is required so this is added. [YOCTO #5292] (Bitbake rev: 1c75cc4d0c8b606c1fe76e6bf60bf6a32298b105) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: command: Trigger updateCache to shut down any active parser threadsRichard Purdie2014-08-231-0/+3
| | | | | | | | | | | | | If we trigger a shutdown whilst parsing for whatever reason, in some cases we were not closing down the parser threads. This change ensures we do so. The function names are not entirely intuitive but the behaviour is more correct (and commented). The previous bug with the stdout failure would trigger this one, if there was a cold cache and parsing was required (but not otherwise). (Bitbake rev: 25bfa2478f1c3a8eb695e1e5760e06db5be8f2fc) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: command/runqueue: Fix shutdown logicRichard Purdie2014-07-211-1/+1
| | | | | | | | | | | | | | If you hit Ctrl+C at the right point, the system processes the request but merrily continues building. It turns out finish_runqueue() is called but this doesn't stop the later generation and execution of the runqueue. This patch adjusts some of the conditionals to ensure the build really does stop. (Bitbake rev: 39b08c604ba713100e174c136f81f18eca6ef33d) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: cooker: mark setFeatures command as read-onlyAlexandru DAMIAN2014-04-011-0/+4
| | | | | | | | | | | | | | | | This patch makes sure that the setFeatures command is marked as read-only and that it can only run if the cooker is in the initial state. Additionally, remove logging from the XMLRPC module in favor of sending the exception to the client for easy processing. [YOCTO #6089] (Bitbake rev: f0a1a3e24757f7658d272035620465f92a3e4c3c) Signed-off-by: Alexandru DAMIAN <alexandru.damian@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-13 22:51:56 +0000