linux/poky.git/bitbake/lib/bb/command.py, branch uninative-2.1

bitbake: cooker: clear extra config settings and remote datastores on client disconnect

2017-09-05T14:00:49+00:00

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

bitbake: command: Fix some bugs identified by BB_SERVER_TIMEOUT

2017-08-31T22:30:03+00:00

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

bitbake: cooker: Ensure we handle inotify before running the next command

2017-08-13T08:28:14+00:00

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

bitbake: bitbake-diffsigs: fix regression after recent server changes

2017-07-27T14:14:20+00:00

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

bitbake: tinfoil: enable access to additional cached items

2017-07-21T07:41:12+00:00

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

bitbake: lib/bb/event: refactor printing events

2017-07-21T07:41:12+00:00

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

bitbake: tinfoil: add internal mode to build_file() function

2017-07-21T07:41:11+00:00

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

bitbake: event/command: Allow UI to request the UI eventhander ID

2017-07-21T07:41:11+00:00

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

bitbake: command / cooker: drop Hob support commands and functions

2017-06-12T14:07:39+00:00

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

bitbake: cooker: add BB_CMDLINE to enable access to UI command line with memres

2017-06-12T14:07:39+00:00

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