6050 2014-03-26 16:53:49 +0000 All task descriptions in documentation.conf should appear in Toaster 2014-04-04 15:35:48 +0000 1 1 7 Build System, Metadata & Runtime Toaster toaster unspecified x86 Multiple VERIFIED FIXED Medium normal 1.6 M5 1 belen.barros.pena bluelightning alexandru.damian belen.barros.pena bluelightning cristiana.voicu richard.purdie --- --- No (bug/feature does not impact docs) oldest_to_newest 41781 0 belen.barros.pena 2014-03-26 16:53:49 +0000 Right now, only a small number of the tasks described in documentation.conf are stored in the toaster database and therefore exposed via the help tooltips in the task tables. We need to find a way to expose all the task descriptions available in documentation.conf 41883 1 david.reyna 2014-03-28 00:22:35 +0000 The missing "do_*" task descriptions are not in the bitbake environment, as tested by "bitbake -e". The proposed solution is to directly append the "[doc]" values for "do_*" names as found in "documentation.conf". The path to "documentation.conf" file(s) can be found in the "BBINCLUDED" environment variable. 41888 2 bluelightning 2014-03-28 09:45:55 +0000 I would rather us figure out why these aren't coming through, because that is the real bug. In future it's likely we will move the do_*[doc] definitions in documentation.conf out to the various places where the corresponding functions are defined, which will mean a bypass like this will not work. 41912 3 david.reyna 2014-03-29 04:48:06 +0000 A few implementation comments: * The reason that the five or so task descriptions were present in the Variables table and not the others is that (a) they were defined in the bitbake environment, and (b) they also had an assignment. * The 'save_build_variables' method in 'buildinfohelper.py' can be adjusted to not skip environment variables with only a description, but while another 20 task descriptions will appear they are not a complete nor sufficient list. * My solution is to (a) scan 'BBINCLUDED' for all 'documentation.conf' files, (b) if that file exists then parse all of the task names and descriptions, and (c) add them to the Variable table. This is sufficient for this release, and can provide backwards compatibility as (some of) these descriptions move to new locations (re: Paul's comment). Also in the next release we should consider holding these in a single table not keyed by builds, since they are defined at the bitbake level and not per project. 41946 4 bluelightning 2014-03-31 09:09:08 +0000 As I've said I don't want to go down the road of looking for documentation.conf directly. I'd suggest the following: 1) We should probably store these doc varflags in a separate table; that way we can keep the "doc only" variables filtered out of the variable list, and we're only searching through a short list of values every time we want to get the description of a particular variable/function. 2) If there are still ones missing after doing this, then we need to figure out why that is. Everything in documentation.conf should be able to come through, we shouldn't need any workarounds. 41969 5 david.reyna 2014-03-31 16:07:35 +0000 Paul, let me discuss your concerns. What is your specific concerned that one bitbake backend component reads the data of another bitbake component? The values from "documentation.conf" are simply not in the bitbake environment (which is I think your concern #2). I got from it at most 14 task descriptions, with ZERO overlap with the actual tasks used in my simple test build (bitbake base-files). We could probably ask for the bitbake env people to be added all of it to the environment, but I suspect that they would much rather have Toaster spend a tiny bit of one-time per project data collection rather that cost every single bitbake execution this unnecessary overhead. If it is a space and data isolation concern, your suggestion #1 is exactly the same as my closing comment. I did not strongly suggest it because I am not sure Alex wants to make any schema changes at this late date, but if he is OK I am certainly OK. I will point out that the overhead is rather miniscule compared to the size of rest of the project's data, the time to gather the data it almost nothing, and the interface has pretty much zero delay in looking up the values. 41973 6 bluelightning 2014-03-31 17:13:42 +0000 My concern is that the whole point of documentation.conf was that values from it would be accessible within BitBake. If that doesn't work we might as well not have implemented it that way at all. I'm not expecting the doc varflags to show up with bitbake -e. I am expecting toaster to collect them, but not by looking for the file and reading it. I can look at how the code is working for this tomorrow and advise on the proper solution. 42214 7 bluelightning 2014-04-03 10:21:49 +0000 I've sent a fix to the bitbake-devel list for this: http://lists.openembedded.org/pipermail/bitbake-devel/2014-April/004626.html 42291 8 bluelightning 2014-04-04 13:26:44 +0000 Fix merged to master: http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=432505d5636a0303dfe3db26db15055d98624dc8 42303 9 belen.barros.pena 2014-04-04 15:35:48 +0000 verified in master:21f9cc27d764c2c232d751968bdff8e29947ba7b