summaryrefslogtreecommitdiffstats
path: root/bitbake/lib/bb/command.py
Commit message (Collapse)AuthorAgeFilesLines
* 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>
* bitbake: cooker/command: Add setFeatures commandRichard Purdie2014-03-101-0/+7
| | | | | | | | | Add a command to allow backends to set particular 'features' on the cooker (server). (Bitbake rev: f547d6ec6cfd677d71fa96dd3c69823c00dc6c69) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker/command/hob: Cleanup configuration init/reset functions and ↵Richard Purdie2013-12-031-24/+14
| | | | | | | | | | | | | | | | | | | | | | | | commands initConfigurationData and loadConfigurationData are similar functions, the only reason for them appears to be to be able to reset the pre/post configuration files. The current code is confusing and unmaintainable. Instead this patch creates a new Sync command which allows these to be explicitly set. The init and load functions can then be merged into one. There is then no need for a parseConfiguration command, we can simply reset the server to have the settings take effect. The reset fuction is not an instant value return and triggers an event so it should be an Async command, not a sync one. The number of calls for the set pre/post command is probably higher than it need be but someone with more familiarity with the hob code base can probably figure out the right places its needed (maybe just init_cooker?). (Bitbake rev: bae5210d7e048022f083361964ebec7daf1608f7) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker/command: Add error state for the server and use for ↵Richard Purdie2013-10-141-0/+2
| | | | | | | | | | | | | | pre_serve errors Currently if errors occur when starting the PR service, there is a race that occurs since the UI runs various commands including starting builds before processing the CookerExit(). By adding the error state and refusing to run async commands in this mode, builds are prevented from starting and the UI reaches the exit code with the system shutting down cleanly. (Bitbake rev: 42fa34142ea685f91115a551e74416ca28ef1c91) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake/hob: removing extra parameters from conf files using hobCristiana Voicu2013-10-071-0/+7
| | | | | | | | | | | | | In Hob settings, there is a tab to add/remove extra settings. This patch implements a way to "remove" variables from conf files, through bitbake. But, to keep the history assigment of the variables synchronized, instead of removing, it replaces the lines with blank lines. [YOCTO #5284] (Bitbake rev: bd720fb63cef6b399619b8fbcaeb8d7710f2d6df) Signed-off-by: Cristiana Voicu <cristiana.voicu@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: cooker, command: add a command to return global dataAlexandru DAMIAN2013-09-221-0/+9
| | | | | | | | | | | | | | Adding the 'getAllKeysWithFlags' read-only command that will return a dump of the global data state, together with specified flags for each key. The flag list is passed in as the first parameter to the command. This will be used by UI clients to get the build configuration. (Bitbake rev: 3e094da513e1220319288806cb76ddf804772afd) Signed-off-by: Alexandru DAMIAN <alexandru.damian@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: command: Treat empty messages as failures, not CommandCompletedRichard Purdie2013-09-141-1/+1
| | | | | | | | | Empty messages should trigger CommandFailed, not CommandCompleted as otherwise the exit code will be incorrect. (Bitbake rev: 70a8ead31f9ffc987d9c6db61a926f7a9af8f8b1) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker/command: Add finishcommand to reset cooker stateRichard Purdie2013-09-141-1/+1
| | | | | | | | | | | | | After running a command on the server, it needs to reset to the initial state. This ensures that subsequent clients start from a known state and notice any configuration changes. Ultimately we may want to do more than this buts a good start and better than nothing. (Bitbake rev: dd15648fc2654b8d7c3e00ea7ab3dbf04f24f24b) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker: Rename confusing 'stop' state to 'forceshutdown'Richard Purdie2013-09-141-3/+3
| | | | | | | | | | | | The shutdown state causes the server to finish what its doing, stop was them meant to completely stop it. It doesn't mean the server is stopped though. Renaming the current stop event for forceshutdown gives more meaning to what it actually does. The stopped namespace then becomes available to indicate a completely stopped server. (Bitbake rev: 12e9d33bfae5294e3870dfd1202f63383ad05e92) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: command.py: Call updateCache for all states != runningRichard Purdie2013-08-261-2/+1
| | | | | | | | | | | updateCache handles the logic for shutting down the parsing so we need to call it for all cases when we're not running. This fixes hangs if Ctrl+C is pressed during parsing. (Bitbake rev: 552b8935dd2f9f11e8d5c08a597a7e966b891480) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: Add ui event handlers filteringRichard Purdie2013-08-261-0/+7
| | | | | | | | | | | | | | | | | | | Add functionality to allow UIs to update and change the types of events they recieve. To do this we need to add a new command and also need to be able to obtain the current event hander ID. In the case of xmlrpc, this is straightforward, in the case of the process server we need to save the result in a multiprocessing.Value() so we can retrive it. An excplit command was added to the server API to facilitate this. The same function can also be used to mask or unmask specific log messages, allowing the UI to optionally differ from the standard set of message filtering. Based upon work by Cristiana Voicu <cristiana.voicu@intel.com> (Bitbake rev: ba5a6c88785d9889d4172ec79937ac2a5555327e) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: hob & bitbake: append a value to a variable from hob throught bitbakeCristiana Voicu2013-08-061-2/+3
| | | | | | | | | | | | It was necessary to append ${TOPDIR}/recipes/images to BBFILES. Implemented the mechanism to append a value to a variable: a command and the method in cooker. [YOCTO #4193] (Bitbake rev: 4aedbee90bd92395c2460a68702e6ede00e256c9) Signed-off-by: Cristiana Voicu <cristiana.voicu@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: hob/bitbake: save the description of a custom imageCristiana Voicu2013-08-061-1/+2
| | | | | | | | | | | | When an new image is saved, the dialog for this action has a field for the description. Changed how an image is saved, by appending the DESCRIPTION variable at the end of the .bb file. [YOCTO #4193] (Bitbake rev: 5629007f2b984005e3a8ac5d9b71422cbc2f1409) Signed-off-by: Cristiana Voicu <cristiana.voicu@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: hob/bitbake: create a template (a .bb file) from hob through bitbakeCristiana Voicu2013-08-061-1/+7
| | | | | | | | | | | | | | Modified generateNewImage function from cooker, in order to be used to save a template in Hob. Created a command to ensure that some dirs are created. The templates (recipes) will be saved in {TOPDIR}/recipes/images folder. Called these methods from Hob. [YOCTO #4193] (Bitbake rev: 96ffa00945c7eb09a0132fa47159aef3ef20fb3e) Signed-off-by: Cristiana Voicu <cristiana.voicu@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: call the initConfiguration when reparsingCristiana Voicu2013-06-201-1/+1
| | | | | | | | | | | | As it is implemented now, when parsing the configuration files is needed, it also needs an initialization. Also, implemented a function to create an extra configuration files which can be used as postfile/prefiles when parsing. (Bitbake rev: 5fe23c1b51da14f58f8c483f43f30b48766a0913) Signed-off-by: Cristiana Voicu <cristiana.voicu@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: remove the function for reparse because it does nothingCristiana Voicu2013-06-201-8/+0
| | | | | | | | | | | The command for reparse does nothing, so I have managed to remove it, because it can be misleading. When a reparse is needed, it can be used the parse function. (Bitbake rev: 188eaba121789112ffeb1188f0984d23dfe8df4f) Signed-off-by: Cristiana Voicu <cristiana.voicu@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake & hob: modify some commands and call them from hobCristiana Voicu2013-06-201-3/+13
| | | | | | | | | | | | | This patch adds a new command to create an extra configuration file, in order to create it from Hob. Also, it calls the enable/disable data tracking when needed. Modified the prefiles and postfiles variables because the cooker expects some lists. (Bitbake rev: 92393701adcfa181a1090e3632bc6df7ee7852e6) Signed-off-by: Cristiana Voicu <cristiana.voicu@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-16 08:00:00 +0000