linux/poky.git/bitbake/lib/bb/ui/toasterui.py, branch yocto-2.5.3

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: toaster: fix SDK artifact capture

2017-04-11T17:05:09+00:00

Use the TaskArtifacts event to scan the SDK and ESDK manifests to cleanly collect the respective artifact files. The previous method was broken when the SDK file deployment moved from the do_populate_sdk[_ext] tasks to their sstate tasks. That method is disabled (but not yet removed) in preparation for the rest of refactor work for the parent #10283 work. [YOCTO #10850] (Bitbake rev: 1360d7b847cc01031edb2f4b289fac9560d72fa7) Signed-off-by: David Reyna Signed-off-by: Richard Purdie

bitbake: cooker process: fire heartbeat event at regular time intervals

2016-12-07T10:42:22+00:00

The intended usage is for recording current system statistics from /proc in buildstats.bbclass during a build and for improving the BB_DISKMON_DIRS implementation. All other existing hooks are less suitable because they trigger at unpredictable rates: too often can be handled by doing rate-limiting in the event handler, but not often enough (for example, when there is only one long-running task) cannot because the handler does not get called at all. The implementation of the new heartbeat event hooks into the cooker process event queue. The process already wakes up every 0.1s, which is often enough for the intentionally coarse 1s delay between heartbeats. That value was chosen to keep the overhead low while still being frequent enough for the intended usage. If necessary, BB_HEARTBEAT_EVENT can be set to a float specifying the delay in seconds between these heartbeat events. (Bitbake rev: 7cf22ea057d28c54bd98dc1ab7a43402a29ff1f5) Signed-off-by: Patrick Ohly Signed-off-by: Richard Purdie

bitbake: toasterui.py: warn if buildstats is missing

2016-11-04T12:50:56+00:00

Like for buildhistory, warn if buildstats is missing from INHERIT. CC: Joshua Lock (Bitbake rev: 3570a8cf94354c8ab07513c304ebae33623fea33) Signed-off-by: Olaf Mandel Signed-off-by: Richard Purdie

bitbake: toaster: make error message more informative

2016-09-30T15:52:22+00:00

Error message ERROR: Unprocessed MetadataEvent doesn't give a lot of information about the event. It just prints event object, which is always bb.event.MetadataEvent. Including event type into the error message should make it more informative: ERROR: Unprocessed MetadataEvent TaskArtifacts (Bitbake rev: 603c7c13536d3fa1786270e863688c1d2e511196) Signed-off-by: Ed Bartosh Signed-off-by: Michael Wood Signed-off-by: Richard Purdie

bitbake: toaster: fix 'Unhandled MetadataEvent' error

2016-09-30T15:52:22+00:00

New MetadataEvent 'TaskArtifacts' causes this error. Processing of this event will hopefully be implemented in future. For now it should be enough to just skip it. (Bitbake rev: 114a3fe3f23ef09782c5aa18f425d0d0dbdfdd35) Signed-off-by: Ed Bartosh Signed-off-by: Michael Wood Signed-off-by: Richard Purdie

bitbake: toaster: fix handling of EnvironmentError

2016-09-30T15:52:22+00:00

Due to the bug in processing EnvironmentError exception, toasterui ignores it. As EnvironmentError is a base for OSError and IOError this means that all OSError and IOError exceptions were silently ignored. (Bitbake rev: c8f4ca008bf9396b0ed45d44bfe2220c82a614a9) Signed-off-by: Ed Bartosh Signed-off-by: Michael Wood Signed-off-by: Richard Purdie

bitbake: toasterui, knotty: don't print taskid followed by taskstring which are now in most cases identical

2016-08-20T15:08:59+00:00

* unify the format how the task is described * don't show taskid followed by taskstring as the taskstring is different only for setscene tasks (by _setscene suffix) * the duplicated output was introduced by: 2c88afb taskdata/runqueue: Rewrite without use of ID indirection as reported and confirmed as a bug here: http://lists.openembedded.org/pipermail/openembedded-core/2016-June/123148.html * show: NOTE: Running task 541 of 548 (/OE/build/oe-core/openembedded-core/meta/recipes-core/zlib/zlib_1.2.8.bb:do_package) instead of much longer: NOTE: Running task 541 of 548 (ID: /OE/build/oe-core/openembedded-core/meta/recipes-core/zlib/zlib_1.2.8.bb:do_package, /OE/build/oe-core/openembedded-core/meta/recipes-core/zlib/zlib_1.2.8.bb:do_package) and similarly for failed tasks: ERROR: Task (virtual:native:/OE/build/oe-core/openembedded-core/meta/recipes-core/zlib/zlib_1.2.8.bb:do_install) failed with exit code '1' instead of much longer: ERROR: Task virtual:native:/OE/build/oe-core/openembedded-core/meta/recipes-core/zlib/zlib_1.2.8.bb:do_install (virtual:native:/OE/build/oe-core/openembedded-core/meta/recipes-core/zlib/zlib_1.2.8.bb:do_install) failed with exit code '1' (Bitbake rev: 696693d45f5eff1226866ed79dbfb67161d8cd3f) Signed-off-by: Martin Jansa Signed-off-by: Richard Purdie

bitbake: toasterui: ensure that the Build object is always available

2016-08-10T23:09:27+00:00

Many of the methods in toasterui and buildinfohelper rely on the internal state of the buildinfohelper; in particular, they need a Build object to have been created on the buildinfohelper. If the creation of this Build object is tied to an event which may or may not occur, there's no guarantee that it will exist. This then causes assertion errors in those methods. To prevent this from happening, add an _ensure_build() method to buildinfohelper. This ensures that a minimal Build object is always available whenever it is needed, either by retrieving it from the BuildRequest or creating it; it also ensures that the Build object is up to date with whatever data is available on the bitbake server (DISTRO, MACHINE etc.). This method is then called by any other method which relies on a Build object being in the internal state, ensuring that the object is either available, or creating it. (Bitbake rev: 0990b4c73f194ec0be1762e4e48b1a525d8349fb) Signed-off-by: Elliot Smith Signed-off-by: Richard Purdie

bitbake: toaster: show progress of recipe parsing in recent builds area

2016-08-10T23:09:26+00:00

Modify buildinfohelper and toasterui so that they record the recipe parse progress (from ParseProgress events in bitbake) on the Build object. Note that because the Build object is now created at the point when ParseStarted occurs, it is necessary to set the build name to the empty string initially (hence the migration). The build name can be set when the build properly starts, i.e. at the BuildStarted event. Then use this additional data to determine whether a Build is in a "Parsing" state, and report this in the JSON API. This enables the most recent builds area to show the recipe parse progress. Add additional logic to update the progress bar if the progress for a build object changes. [YOCTO #9631] (Bitbake rev: f33d51d46d70e73e04e325807c1bc4eb68462f7b) Signed-off-by: Elliot Smith Signed-off-by: Richard Purdie