linux/poky.git/bitbake/lib/bb/command.py, branch krogoth-15.0.1

bitbake: command: make setEventMask readonly

2016-03-07T17:23:04+00:00

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 Signed-off-by: brian avery Signed-off-by: Richard Purdie

bitbake: command: Add getSetVariable command

2015-10-29T07:35:51+00:00

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

bitbake: command: ensure sync commands that read configuration see updates

2015-08-19T17:05:45+00:00

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 Signed-off-by: Paul Eggleton Signed-off-by: Richard Purdie

bitbake: command: intercept SystemExit to avoid trashing the server

2015-08-19T17:05:44+00:00

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

bitbake: cooker: properly fix bitbake.lock handling

2015-08-01T06:34:09+00:00

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 . This reverts bitbake commit 69ecd15aece54753154950c55d7af42f85ad8606 and e97a9f1528d77503b5c93e48e3de9933fbb9f3cd. (Bitbake rev: a29780bd43f74b7326fe788dbd65177b86806fcf) Signed-off-by: Paul Eggleton Signed-off-by: Richard Purdie

bitbake: command.py: Unlock function included into CommandsSync class

2015-07-09T17:00:21+00:00

Function which calls cooker's unlock method, which in turn unlocks bitbake.lock file. (Bitbake rev: e97a9f1528d77503b5c93e48e3de9933fbb9f3cd) Signed-off-by: Leonardo Sandoval Signed-off-by: Richard Purdie

bitbake: cooker: Rename event_data -> expanded_data

2015-01-23T11:33:54+00:00

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

bitbake: command/cooker/knotty: Fix memres handling of command environment changes

2015-01-21T14:37:39+00:00

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

bitbake: knotty: Ensure commandline parameters are updated in memres server

2014-09-23T19:06:06+00:00

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

bitbake: command: Trigger updateCache to shut down any active parser threads

2014-08-23T08:31:42+00:00

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