Fixes for toastergui
cover Fixes for toastergui
This patchset fixes creation of Target objects for command line builds and provides a couple of usability fixes for toastergui module.
The following changes since commit 78b7cfc2d29209354a1ed3a3a787c651efd31f28:
toaster: test get_alldeps API (2015-10-05 10:37:47 +0100)
are available in the git repository at:
git://git.yoctoproject.org/poky-contrib elliot/submit/ed/toaster/target-task
http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=elliot/submit/ed/toaster/target-task
Ed Bartosh (6):
event: add new property to BuildBase class
event: add new parameter to Build* event APIs
toaster: add task to the target_information
toaster: add get_or_create_targets API
toaster: ignore ReachableStamps event
toaster: use meaningful logging levels
lib/bb/cooker.py | 8 ++++---- lib/bb/event.py | 18 +++++++++++++----- lib/bb/ui/buildinfohelper.py | 37 +++++++++++++++++++++---------------- lib/bb/ui/toasterui.py | 11 ++++++----- 4 files changed, 44 insertions(+), 30 deletions(-)
--
1.9.3
---------------------------------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
PATCH 1/6 event: add new property to BuildBase class
From: Ed Bartosh <[email protected]>
Added 'task' property to the base class of BuildStarted and BuildCompleted classes to store bitbake task if it's specified.
This is done as without task Build* events can't fully represent bitbake build. Task information is needed by UI classes to properly show or process Build* events.
--- lib/bb/event.py | 8 ++++++++ 1 file changed, 8 insertions(+)
lib/bb/event.py +8 -0
@@ -331,6 +331,7 @@ class BuildBase(Event): def __init__(self, n, p, failures = 0): self._name = n self._pkgs = p + self._task = None Event.__init__(self) self._failures = failures
@@ -352,6 +353,12 @@ class BuildBase(Event): def setCfg(self, cfg): self.data = cfg + def getTask(self): + return self._task + + def setTask(self, task): + self._task = task + def getFailures(self): """ Return the number of failed packages
@@ -361,6 +368,7 @@ class BuildBase(Event): pkgs = property(getPkgs, setPkgs, None, "pkgs property") name = property(getName, setName, None, "name property") cfg = property(getCfg, setCfg, None, "cfg property") + task = property(getTask, setTask, None, "task property")
Signature · 12 lines
1.9.3 --------------------------------------------------------------------- Intel Corporation (UK) Limited Registered No. 1134945 (England) Registered Office: Pipers Way, Swindon SN3 1RJ VAT No: 860 2173 47 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
PATCH 2/6 event: add new parameter to Build* event APIs
From: Ed Bartosh <[email protected]>
Added 't'(task) parameter to BuildStarted and BuildCompleted event APIs. Modified existing calls of above mentioned APIs:
passed bitbake task name as a parameter.
--- lib/bb/cooker.py | 8 ++++---- lib/bb/event.py | 12 ++++++------ 2 files changed, 10 insertions(+), 10 deletions(-)
lib/bb/cooker.py +4 -4
@@ -1313,7 +1313,7 @@ class BBCooker: taskdata.add_provider(self.data, self.recipecache, item) buildname = self.data.getVar("BUILDNAME", True) - bb.event.fire(bb.event.BuildStarted(buildname, [item]), self.expanded_data) + bb.event.fire(bb.event.BuildStarted(buildname, [item], task), self.expanded_data) # Execute the runqueue if not task.startswith("do_"):
@@ -1345,7 +1345,7 @@ class BBCooker: return False if not retval: - bb.event.fire(bb.event.BuildCompleted(len(rq.rqdata.runq_fnid), buildname, item, failures, interrupted), self.expanded_data) + bb.event.fire(bb.event.BuildCompleted(len(rq.rqdata.runq_fnid), buildname, item, task, failures, interrupted), self.expanded_data) self.command.finishAsyncCommand(msg) return False if retval is True:
@@ -1381,7 +1381,7 @@ class BBCooker: return False if not retval: - bb.event.fire(bb.event.BuildCompleted(len(rq.rqdata.runq_fnid), buildname, targets, failures, interrupted), self.data) + bb.event.fire(bb.event.BuildCompleted(len(rq.rqdata.runq_fnid), buildname, targets, task, failures, interrupted), self.data) self.command.finishAsyncCommand(msg) return False if retval is True:
@@ -1394,7 +1394,7 @@ class BBCooker: taskdata, runlist, fulltargetlist = self.buildTaskData(targets, task, self.configuration.abort) buildname = self.data.getVar("BUILDNAME", False) - bb.event.fire(bb.event.BuildStarted(buildname, fulltargetlist), self.data) + bb.event.fire(bb.event.BuildStarted(buildname, fulltargetlist, task), self.data) rq = bb.runqueue.RunQueue(self, self.data, self.recipecache, taskdata, runlist) if 'universe' in targets:
lib/bb/event.py +6 -6
@@ -328,10 +328,10 @@ class StampUpdate(Event): class BuildBase(Event): """Base class for bbmake run events""" - def __init__(self, n, p, failures = 0): + def __init__(self, n, p, t, failures = 0): self._name = n self._pkgs = p - self._task = None + self._task = t Event.__init__(self) self._failures = failures
@@ -376,19 +376,19 @@ class BuildBase(Event): class BuildStarted(BuildBase, OperationStarted): """bbmake build run started""" - def __init__(self, n, p, failures = 0): + def __init__(self, n, p, t, failures = 0): OperationStarted.__init__(self, "Building Started") - BuildBase.__init__(self, n, p, failures) + BuildBase.__init__(self, n, p, t, failures) class BuildCompleted(BuildBase, OperationCompleted): """bbmake build run completed""" - def __init__(self, total, n, p, failures=0, interrupted=0): + def __init__(self, total, n, p, t, failures=0, interrupted=0): if not failures: OperationCompleted.__init__(self, total, "Building Succeeded") else: OperationCompleted.__init__(self, total, "Building Failed") self._interrupted = interrupted - BuildBase.__init__(self, n, p, failures) + BuildBase.__init__(self, n, p, t, failures) class DiskFull(Event): """Disk full case build aborted"""
Signature · 12 lines
1.9.3 --------------------------------------------------------------------- Intel Corporation (UK) Limited Registered No. 1134945 (England) Registered Office: Pipers Way, Swindon SN3 1RJ VAT No: 860 2173 47 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
PATCH 3/6 toaster: add task to the target_information
In reply to Elliot SmithFrom: Ed Bartosh <[email protected]>
Added task information from BuildStarted event to the target_information structure. Made sure 'build' task is not set in Target objects as it shouldn't be shown in Toaster UI.
--- lib/bb/ui/buildinfohelper.py | 6 ++++++ 1 file changed, 6 insertions(+)
lib/bb/ui/buildinfohelper.py +6 -0
@@ -925,6 +925,12 @@ class BuildInfoHelper(object): target_information = {} target_information['targets'] = event._pkgs target_information['build'] = build_obj + task = getattr(event, 'task', '') + if task.startswith('do_'): + task = task[3:] + if task == 'build': + task = '' + target_information['task'] = task self.internal_state['targets'] = self.orm_wrapper.create_target_objects(target_information)
Signature · 12 lines
1.9.3 --------------------------------------------------------------------- Intel Corporation (UK) Limited Registered No. 1134945 (England) Registered Office: Pipers Way, Swindon SN3 1RJ VAT No: 860 2173 47 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
PATCH 4/6 toaster: add get_or_create_targets API
In reply to Elliot SmithFrom: Ed Bartosh <[email protected]>
Target objects are created before the build if build is started from UI in build mode. However, in analysis mode Target objects don't exist and need to be created using information from bitbake events.
Added new API call get_or_create_targets to retrive existing target objects or create them if they don't exist yet.
--- lib/bb/ui/buildinfohelper.py | 29 ++++++++++++++--------------- 1 file changed, 14 insertions(+), 15 deletions(-)
lib/bb/ui/buildinfohelper.py +14 -15
@@ -162,8 +162,6 @@ class ORMWrapper(object): build.bitbake_version=build_info['bitbake_version'] build.save() - Target.objects.filter(build = build).delete() - else: build = Build.objects.create( project = prj,
@@ -184,18 +182,19 @@ class ORMWrapper(object): return build - def create_target_objects(self, target_info): - assert 'build' in target_info - assert 'targets' in target_info - - targets = [] - for tgt_name in target_info['targets']: - tgt_object = Target.objects.create( build = target_info['build'], - target = tgt_name, - is_image = False, - ) - targets.append(tgt_object) - return targets + @staticmethod + def get_or_create_targets(target_info): + result = [] + for target in target_info['targets']: + obj, created = Target.objects.get_or_create(build=target_info['build'], + target=target) + if created: + obj.is_image = False + if target_info['task']: + obj.task = target_info['task'] + obj.save() + result.append(obj) + return result def update_build_object(self, build, errors, warnings, taskfailures): assert isinstance(build,Build)
@@ -932,7 +931,7 @@ class BuildInfoHelper(object): task = '' target_information['task'] = task - self.internal_state['targets'] = self.orm_wrapper.create_target_objects(target_information) + self.internal_state['targets'] = self.orm_wrapper.get_or_create_targets(target_information) # Save build configuration data = self.server.runCommand(["getAllKeysWithFlags", ["doc", "func"]])[0]
Signature · 12 lines
1.9.3 --------------------------------------------------------------------- Intel Corporation (UK) Limited Registered No. 1134945 (England) Registered Office: Pipers Way, Swindon SN3 1RJ VAT No: 860 2173 47 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
PATCH 5/6 toaster: ignore ReachableStamps event
In reply to Elliot SmithFrom: Ed Bartosh <[email protected]>
Added ReachableStamps event to the list of known events to ignore. This should stop toaster throwing error message:
ERROR: Unknown event: <bb.event.ReachableStamps>
--- lib/bb/ui/toasterui.py | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
lib/bb/ui/toasterui.py +2 -1
@@ -308,7 +308,8 @@ def main(server, eventHandler, params ): bb.event.OperationProgress, bb.command.CommandFailed, bb.command.CommandExit, - bb.command.CommandCompleted)): + bb.command.CommandCompleted, + bb.event.ReachableStamps)): continue if isinstance(event, bb.event.DepTreeGenerated):
Signature · 12 lines
1.9.3 --------------------------------------------------------------------- Intel Corporation (UK) Limited Registered No. 1134945 (England) Registered Office: Pipers Way, Swindon SN3 1RJ VAT No: 860 2173 47 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
PATCH 6/6 toaster: use meaningful logging levels
In reply to Elliot SmithFrom: Ed Bartosh <[email protected]>
Changed logging levels to more appropriate ones.
--- lib/bb/ui/toasterui.py | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
lib/bb/ui/toasterui.py +4 -4
@@ -130,14 +130,14 @@ def main(server, eventHandler, params ): if isinstance(event, (bb.build.TaskStarted, bb.build.TaskSucceeded, bb.build.TaskFailedSilent)): buildinfohelper.update_and_store_task(event) - logger.warn("Logfile for task %s", event.logfile) + logger.info("Logfile for task %s", event.logfile) continue if isinstance(event, bb.build.TaskBase): logger.info(event._message) if isinstance(event, bb.event.LogExecTTY): - logger.warn(event.msg) + logger.info(event.msg) continue if isinstance(event, logging.LogRecord):
@@ -316,7 +316,7 @@ def main(server, eventHandler, params ): buildinfohelper.store_dependency_information(event) continue - logger.error("Unknown event: %s", event) + logger.warn("Unknown event: %s", event) return_value += 1 except EnvironmentError as ioerror:
@@ -336,7 +336,7 @@ def main(server, eventHandler, params ): if tb is not None: curr = tb while curr is not None: - logger.warn("Error data dump %s\n%s\n" , traceback.format_tb(curr,1), pformat(curr.tb_frame.f_locals)) + logger.error("Error data dump %s\n%s\n" , traceback.format_tb(curr,1), pformat(curr.tb_frame.f_locals)) curr = curr.tb_next # save them to database, if possible; if it fails, we already logged to console.
Signature · 12 lines
1.9.3 --------------------------------------------------------------------- Intel Corporation (UK) Limited Registered No. 1134945 (England) Registered Office: Pipers Way, Swindon SN3 1RJ VAT No: 860 2173 47 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
Re: [PATCH 1/6] event: add new property to BuildBase class
In reply to Elliot SmithQuoted 8 lines · Elliot Smith
From: Ed Bartosh <[email protected]>
Added 'task' property to the base class of BuildStarted and BuildCompleted classes to store bitbake task if it's specified.
This is done as without task Build* events can't fully represent bitbake build. Task information is needed by UI classes to properly show or process Build* events.
This doesn't make sense I'm afraid. There is no one "task" which a build start/complete event can correspond to. Consider something like:
"bitbake A:do_fetch B:do_rootfs"
There would be one BuildStarted event but task doesn't have a singular value. We therefore don't want to add task information to these events as it will ultimately mislead anything building on top of this information.
I appreciate there is the -c option, but that just means "if there is no specific task specified, use this", i.e. its a default.
Cheers,
Richard
Re: [PATCH 1/6] event: add new property to BuildBase class
Quoted 15 lines · Richard Purdie
Quoted 8 lines · Elliot Smith
From: Ed Bartosh <[email protected]>
Added 'task' property to the base class of BuildStarted and BuildCompleted classes to store bitbake task if it's specified.
This is done as without task Build* events can't fully represent bitbake build. Task information is needed by UI classes to properly show or process Build* events.
This doesn't make sense I'm afraid. There is no one "task" which a build start/complete event can correspond to. Consider something like:
"bitbake A:do_fetch B:do_rootfs"
Quoted 8 lines
There would be one BuildStarted event but task doesn't have a singular value. We therefore don't want to add task information to these events as it will ultimately mislead anything building on top of this information.
I appreciate there is the -c option, but that just means "if there is no specific task specified, use this", i.e. its a default.
OK. can we call it 'default_task' then?
You spotted it's purpose right - it's done to represent the task specified by -c option.
--
Regards,
Ed
Re: [PATCH 1/6] event: add new property to BuildBase class
Quoted 21 lines · Ed Bartosh
Quoted 20 lines · Richard Purdie
Quoted 8 lines · Elliot Smith
From: Ed Bartosh <[email protected]>
Added 'task' property to the base class of BuildStarted and BuildCompleted classes to store bitbake task if it's specified.
This is done as without task Build* events can't fully represent bitbake build. Task information is needed by UI classes to properly show or process Build* events.
This doesn't make sense I'm afraid. There is no one "task" which a build start/complete event can correspond to. Consider something like:
"bitbake A:do_fetch B:do_rootfs"
There would be one BuildStarted event but task doesn't have a singular value. We therefore don't want to add task information to these events as it will ultimately mislead anything building on top of this information.
Quoted 7 lines
Quoted 3 lines
I appreciate there is the -c option, but that just means "if there is no specific task specified, use this", i.e. its a default.
OK. can we call it '
default_task' then?
You spotted it's purpose right - it's done to represent the task specified by -c option.
That would certainly be better. I am a little worried how this would be used in the UI though. Can you explain where and why the UI needs this piece of information?
Cheers,
Richard
Re: [PATCH 1/6] event: add new property to BuildBase class
Quoted 26 lines · Richard Purdie
Quoted 25 lines · Ed Bartosh
Quoted 23 lines · Richard Purdie
Quoted 8 lines · Elliot Smith
From: Ed Bartosh <[email protected]>
Added 'task' property to the base class of BuildStarted and BuildCompleted classes to store bitbake task if it's specified.
This is done as without task Build* events can't fully represent bitbake build. Task information is needed by UI classes to properly show or process Build* events.
This doesn't make sense I'm afraid. There is no one "task" which a build start/complete event can correspond to. Consider something like:
"bitbake A:do_fetch B:do_rootfs"
There would be one BuildStarted event but task doesn't have a singular value. We therefore don't want to add task information to these events as it will ultimately mislead anything building on top of this information.
I appreciate there is the -c option, but that just means "if there is no specific task specified, use this", i.e. its a default.
Quoted 7 lines
Quoted 3 lines
OK. can we call it '
default_task' then?
You spotted it's purpose right - it's done to represent the task specified by -c option.That would certainly be better. I am a little worried how this would be used in the UI though. Can you explain where and why the UI needs this piece of information?
After looking at UI code I think I can implement this functionality differently. Thank you for pointing out to this.
Please merge patches 5 and 6 from this patchset. They're not directly related to 'task' property and can be merged independently.
--
Regards,
Ed
PATCH 1/1 bitbake: normalize build targets
In reply to Richard PurdieBuildStarted event not fully represents build tasks for the targets. If -c option is used to specify default task it's not included into the event.
Made build targets to always look as <target>:do_<task>. Consider default task (do_build or specified by -c command line option) when normalizing.
--- bitbake/lib/bb/cooker.py | 20 +++++++++++++++++++- 1 file changed, 19 insertions(+), 1 deletion(-)
bitbake/lib/bb/cooker.py +19 -1
@@ -1391,10 +1391,28 @@ class BBCooker: build.reset_cache() self.buildSetVars() + # If we are told to do the None task then query the default task + if (task == None): + task = self.configuration.cmd + + if not task.startswith("do_"): + task = "do_%s" % task + taskdata, runlist, fulltargetlist = self.buildTaskData(targets, task, self.configuration.abort) buildname = self.data.getVar("BUILDNAME", False) - bb.event.fire(bb.event.BuildStarted(buildname, fulltargetlist), self.data) + + # make targets to always look as <target>:do_<task> + ntargets = [] + for target in fulltargetlist: + if ":" in target: + if ":do_" not in target: + target = "%s:do_%s" % tuple(target.split(":")) + else: + target = "%s:%s" % (target, task) + ntargets.append(target) + + bb.event.fire(bb.event.BuildStarted(buildname, ntargets), self.data) rq = bb.runqueue.RunQueue(self, self.data, self.recipecache, taskdata, runlist) if 'universe' in targets:
Signature · 1 line
2.1.4
Re: [PATCH] bitbake: normalize build targets
bitbake/lib/bb/cooker.py class BBCooker: · line 1410
Quoted 5 lines · Ed Bartosh
bitbake/lib/bb/cooker.py +4
-0+ for target in fulltargetlist: + if ":" in target: + if ":do_" not in target: + target = "%s:do_%s" % tuple(target.split(":"))
I know it's an unlikely and theoretical case, but just in case the user asks to build foo:: or something, we wouldn't want to explode horribly with a traceback. It's best to do target.split(":", 1) here, so you know we'll get 2 values for the format strings, no more.
Signature · 5 lines
Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics
PATCH v2 1/1 bitbake: normalize build targets
BuildStarted event not fully represents build tasks for the targets. If -c option is used to specify default task it's not included into the event.
Made build targets to always look as <target>:do_<task>. Consider default task (do_build or specified by -c command line option) when normalizing.
--- bitbake/lib/bb/cooker.py | 20 +++++++++++++++++++- 1 file changed, 19 insertions(+), 1 deletion(-)
bitbake/lib/bb/cooker.py +19 -1
@@ -1391,10 +1391,28 @@ class BBCooker: build.reset_cache() self.buildSetVars() + # If we are told to do the None task then query the default task + if (task == None): + task = self.configuration.cmd + + if not task.startswith("do_"): + task = "do_%s" % task + taskdata, runlist, fulltargetlist = self.buildTaskData(targets, task, self.configuration.abort) buildname = self.data.getVar("BUILDNAME", False) - bb.event.fire(bb.event.BuildStarted(buildname, fulltargetlist), self.data) + + # make targets to always look as <target>:do_<task> + ntargets = [] + for target in fulltargetlist: + if ":" in target: + if ":do_" not in target: + target = "%s:do_%s" % tuple(target.split(":", 1)) + else: + target = "%s:%s" % (target, task) + ntargets.append(target) + + bb.event.fire(bb.event.BuildStarted(buildname, ntargets), self.data) rq = bb.runqueue.RunQueue(self, self.data, self.recipecache, taskdata, runlist) if 'universe' in targets:
Signature · 1 line
2.1.4
Re: [PATCH v2] bitbake: normalize build targets
Quoted 9 lines · Ed Bartosh
BuildStarted event not fully represents build tasks for the targets. If -c option is used to specify default task it's not included into the event.
Made build targets to always look as <target>:do_<task>. Consider default task (
do_buildor specified by -c command line option) when normalizing.Signed-off-by Ed Bartosh <[email protected]>
The correct prefix for the commit shortlog is "cooker:". I'd really like to see toaster becoming a little more specific too such as "toaster/xxxx:" instead of the usual "toaster:".
Cheers,
Richard