Bug 5298 - Add 'paths searched to sstate object' to the data collected about tasks
Summary: Add 'paths searched to sstate object' to the data collected about tasks
Status: VERIFIED OBSOLETE
Alias: None
Product: Toaster
Classification: Build System, Metadata & Runtime
Component: toaster (show other bugs)
Version: unspecified
Hardware: All Multiple
: Medium enhancement
Target Milestone: 1.6
Assignee: Alexandru Damian
QA Contact: Mihail Stanciu
URL:
Whiteboard:
Depends on:
Blocks:
 
Reported: 2013-10-01 11:01 UTC by Belen Barros Pena
Modified: 2014-08-11 09:28 UTC (History)
3 users (show)

See Also:
OS type for building Yocto: ---
Type of Regression: ---
Verified:
Documentation change: No (bug/feature does not impact docs)


Attachments
Task information to be collected (17.55 KB, application/vnd.oasis.opendocument.spreadsheet)
2013-10-01 11:01 UTC, Belen Barros Pena
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Belen Barros Pena 2013-10-01 11:01:21 UTC
Created attachment 1535 [details]
Task information to be collected

When creating the list of information to be collected about tasks, we decided to include the following:

* The path where the sstate object was found (path_to_sstate_obj)

* The path to the Python / Shell script executed for a task (source_url)

* Path(s) searched to sstate object: BitBake's shared state code works by looking in SSTATE_DIR and SSTATE_MIRRORS for shared state files. This piece of information shows the path(s) BitBake searched for files for a certain task. The path searched should only display when different from path_to_sstate_obj

The latter is missing from the Tasks Django model, and it should be added, being particularly useful for tasks with sstate_result returning 'missing' or 'failed'.
Comment 1 Alexandru Damian 2013-11-18 12:13:13 UTC
I'm not sure if this can't be done at UI level by displaying the SSTATE_DIR and SSTATE_MIRRORS. Do we need different information here ?
Comment 2 Belen Barros Pena 2013-11-18 18:10:27 UTC
(In reply to comment #1)
> I'm not sure if this can't be done at UI level by displaying the SSTATE_DIR
> and SSTATE_MIRRORS. Do we need different information here ?

I am not sure the above would be enough.

There are 2 pieces of information we'd like to show:

1. If the sstate object was found, where? 
2. If the sstate object was searched in places other than 1, where?

So a successful sstate task will have 1, but it might or might not have 2. An example here:

http://www.yoctoproject.org/toaster/task-details-prebuilt-sstate.html

A failed sstate task will not have 1, but will have 2. Examples here:

http://www.yoctoproject.org/toaster/task-details-sstate-missed.html
http://www.yoctoproject.org/toaster/task-details-sstate-failed.html

The key thing is identifying where within the places listed in SSTATE_DIR and SSTATE_MIRRORS the object was found, and which places where searched unsuccessfully.
Comment 3 Belen Barros Pena 2013-12-19 10:20:28 UTC
If the shared state object is found, we show the uri where it was found. If the shared state object is not found, we show the uri(s) where it was searched (SSTATE_DIR and SSTATE_MIRRORS)
Comment 4 Mihail Stanciu 2014-08-11 09:28:16 UTC
Verified.