summaryrefslogtreecommitdiffstats
path: root/bitbake/lib/bb/ui/uievent.py
Commit message (Collapse)AuthorAgeFilesLines
* bitbake: bitbake: Convert to python 3 megacommit This needs breaking up into ↵Richard Purdie2016-05-161-2/+2
| | | | | | | | smaller changes. (Bitbake rev: cf51f19aed208a75d38c14cd585d9b9f115e3ba3) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: uievent: improve BBUIEventQueue codeEd Bartosh2016-04-061-2/+8
| | | | | | | | | | | | | Return value of self.BBServer.registerEventHandler differs between jethro and master. To be able to build jethro toaster should be able to communicate with jethro bitbake server i.e. it must work with both old and new registerEventHandler call. (Bitbake rev: f356c154016c428a3b53af61a075de6f14d9d1d9) 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: bitbake: Set process names to be meaninfulRichard Purdie2016-01-301-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | This means that when you view the process tree, the processes have meaningful names, aiding debugging: $ pstree -p 30021 bash(30021)───KnottyUI(115579)───Cooker(115590)─┬─PRServ(115592)───{PRServ Handler}(115593) ├─Worker(115630)───bash:sleep(115631)───run.do_sleep.11(115633)───sleep(115634) └─{ProcessEQueue}(115591) $ pstree -p 30021 bash(30021)───KnottyUI(117319)───Cooker(117330)─┬─Cooker(117335) ├─PRServ(117332)───{PRServ Handler}(117333) ├─Parser-1:2(117336) └─{ProcessEQueue}(117331) Applies to parse threads, PR Server, cooker, the workers and execution threads, working within the 16 character limit as best we can. Needed to tweak the bitbake-worker magic values to tell the workers apart. (Bitbake rev: 539726a3b2202249a3f148d99e08909cb61902a5) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: uievent: refactor retry loopEd Bartosh2016-01-061-9/+6
| | | | | | | | | | Replaced 'while' loop with 'for' loop. Made the code more compact and hopefully more understandable. (Bitbake rev: 4e1e497c8432536b3522295e5b1284844ccea056) Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: uievent: get rid of EventHandler attributeEd Bartosh2016-01-061-2/+2
| | | | | | | | | | This attribute was introduced by mistake. EventHandle is used in the code for the same purpose. (Bitbake rev: 8d505ec8913a7d51de48b4f52bb64c5d6a0bb08e) Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: uievent: add error to registerEventHandler returnEd Bartosh2016-01-061-3/+5
| | | | | | | | | | | | | | | Current code throws Exception("Could not register UI event handler") if event handler can't be registered. The real reason of this is that cooker is in busy state. Error message lacks information about this. Added error message to the return value of registerEventHandler. Included returned error message into the log message and exception text. (Bitbake rev: 07de1ca7d57dcd0cc37406feae2949da12a3fa7a) Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: uievent: catch and log exceptions in receiving eventsAlexandru DAMIAN2015-03-251-1/+6
| | | | | | | | | | | | This patch prevents tracebacks and instead logs exceptions that may happen during event processing. [YOCTO #7216] (Bitbake rev: 0412631fb4a15ff42bf5ee46a77920fa558ae358) Signed-off-by: Alexandru DAMIAN <alexandru.damian@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: uievent: retry on handler registration failureAlexandru DAMIAN2014-06-061-3/+19
| | | | | | | | | | | | | | | | | The registration of a remote UI event handler may fail if the server cooker is currently in some certain states. This may happen, for example, when a remote UI is started very fast after the bitbake server is started, and the server hadn't time to finish initial configuration parsing. Rather than fail outright, we have the remote UI event retry registration for five time at one-second intervals, in the hope it will succeed. (Bitbake rev: c3d520c92ae4ae80d31926a416456df510654b6a) Signed-off-by: Alexandru DAMIAN <alexandru.damian@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: xmlrpc: client - remove fatal errorsAlexandru DAMIAN2014-06-061-1/+2
| | | | | | | | | | | | | | | | | | | | | When we use the XMLRPC client API to connect to a bitbake server, we want to receive errors from the API instead of having the API exiting without warning. Thus the "bb.fatal" calls have been replaced with "bb.warn" calls, and we re-raise the original exception for handling by the original caller. The bitbake starting script has been modified to properly test for failures in calling the client API and handle them. Additional error handling added in the client, as to prevent fatal crashes. (Bitbake rev: eb63f08c33644f64752aaae2146a000956ce894a) Signed-off-by: Alexandru DAMIAN <alexandru.damian@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: server/xmlrpc: Simlify featureset handlingRichard Purdie2014-03-301-2/+2
| | | | | | | | | | Rather than passing featureset around various places where the data doesn't really belong, run a command at connection time to set the appropriate features. This is similar to what the process server does. (Bitbake rev: c3b5cc5691291c74dd315c4439c80e0e4b2b5c1d) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: cooker,xmlrpc,servers: implement CookerFeaturesAlexandru DAMIAN2013-09-221-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Implementing feature set selection that allows a client to enable specific features in the server at connection time. Only enabling of features is supported, as there is no way to safely remove data loaded into the cooker. Once enabled, a feature will remain enabled for the life of the cooker. Client-server connection now supports specifying the feature set required by the client. This is implemented in the Process server using a managed proxy list, so the server cooker will now load dynamically needed features based on what client connects to it. In the XMLRPC server the feature set is requested by using a parameter for registerUIHandler function. This allows observer-only clients to also specify features for the server. The server code configuration now is completly separated from the client code. All hardcoding of client knowledge is removed from the server. The extra_caches is removed as the client can now specify the caches it needs using the feature. The UI modules now need to specify the desired featureSet. HOB is modified to conform to the featureSet specification. The only feature available is CookerFeatures.HOB_EXTRA_CACHES which forces loading the bb.cache_extra:HobRecipeInfo class. (Bitbake rev: 98e594837aab89ea042cfa9f3740d20a661b14e2) Signed-off-by: Alexandru DAMIAN <alexandru.damian@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: knotty, xmlrpc: add observer-only modeAlexandru DAMIAN2013-06-171-0/+1
| | | | | | | | | | | | | | | | | | | | | I add an observer only mode for the knotty UI and the XMLRPC server that will allow the UI to register a callback with a server in order to receive events. The observer-UI is able to send read-only commands to the server, and also is able to register as an event handler. Read-only commands are the commands that do not change the state of the server and have been marked as such in the command module. The observer can switch to a full client if it calls addClient at any time, and the server has no other client running. (Bitbake rev: 4de9ee21f1fa4d04937cc7430fb1fc8b7a8f61e2) Signed-off-by: Alexandru DAMIAN <alexandru.damian@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: uievent: Fix an init raceRichard Purdie2012-12-041-13/+14
| | | | | | | | | | | | | There is a race where the registerEventHandler() server call may happen in a different thread to the main UI, causing the main UI to see httplib.CannotSendRequest exceptions. This moves the call into the main thread, removing the init race and fixing errors I was seeing with the xmlrpc backend. (Bitbake rev: 14cdd3b351d1ab23cb3ea5f853e403a53e67ac1c) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: Add client socket info for BitBakeServerConnectionDongxiao Xu2012-02-231-3/+4
| | | | | | | | | | In server/client split model, the client will bind to a specific address and port. We need to pass the values to BitBakeServerConnection(). (Bitbake rev: c8e19c5c389efc06696084c6f9439ba75472c5b7) Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake none/xmlrpc servers: Only send pickled events to the xmlrpc serverRichard Purdie2011-06-081-1/+1
| | | | | | | Only the xmlrpc server needs pickled events. Use the function names to signify this requirement. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake/uievent: fix queueing of events for xmlrpc before UI has loadedJoshua Lock2011-01-121-2/+5
| | | | | | | | | | | | | | | The recent change to Queue up events before the UI is spawned (in 26eda933379801ef1c8b4b09e67d14f498cd3813) broke the xmlrpc server because the uievent implementation of BBUIEventQueue expects pickled strings for its queue_event() method. This is because the RPC exposed event.send() method must accept pickled strings, but for xmlrpc event.send() is just mapped to queue_event(). Work around this by adding a send_event method which unpickles strings and hands them off to queue_event() which can then be used for the remapping. Signed-off-by: Joshua Lock <josh@linux.intel.com>
* cache: sync the cache file to disk in the backgroundChris Larson2011-01-041-9/+9
| | | | | | | | | | | | | | | | This version uses a thread rather than a process, to avoid problems with waitpid handling. This gives slightly less overall build time reduction than the separate process for it did (this reduces a -c compile coreutils-native by about 3 seconds, while the process reduced it by 7 seconds), however this time is quite insignificant relative to a typical build. The biggest issue with non-backgrounded syncing is the perceived delay before work begins, and this resolves that without breaking anything, or so it seems. (Bitbake rev: 5ab6c5c7b007b8c77c751582141afc07c183d672) Signed-off-by: Chris Larson <chris_larson@mentor.com> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
* Apply some 2to3 transforms that don't cause issues in 2.6Chris Larson2010-07-021-1/+1
| | | | | | | (Bitbake rev: d39ab776e7ceaefc8361150151cf0892dcb70d9c) Signed-off-by: Chris Larson <chris_larson@mentor.com> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
* Formatting cleanupsChris Larson2010-07-021-3/+2
| | | | | | | (Bitbake rev: 2caf134b43a44dad30af4fbe33033b3c58deee57) Signed-off-by: Chris Larson <chris_larson@mentor.com> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
* bitbake: Switch to bitbake-dev version (bitbake master upstream)Richard Purdie2010-01-201-0/+125
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>