5357 2013-10-16 11:52:54 +0000 Enhance signature handling 2014-04-02 13:59:44 +0000 1 1 7 Build System, Metadata & Runtime BitBake bitbake 1.6 x86 Multiple VERIFIED FIXED 27 March 2014: Setting documentation flag to "Done." Medium+ enhancement 1.6 M5 5467 1 richard.purdie richard.purdie belen.barros.pena jessica.zhang poky.bs.watcher poky.watcher ross.burton srifenbark sstncr --- --- Done (doc changes complete) oldest_to_newest 37979 0 richard.purdie 2013-10-16 11:52:54 +0000 Currently the interface to bitbake signatures is a bit complex and hard to use. The simple scenario is that you what to know why "bitbake X" is not reusing a given sstate cache. There are some problems. Specifically, the current sstate cache only has siginfo files for the actual sstate tasks (e.g. populate_sysroot) and not the non-sstate tasks (e.g. fetch/patch/configure/compile/install). To address this, we probably need to add a bitbake variable which allows dumping the sigdata at the end of every task and we can dump this straight into the sstate directory. The bitbake call needed at the end of each task is bb.siggen.dump_this_task(xxx.siginfo, d), see sstate.bbclass for how its currently used, we'd trigger this with some kind of new variable for bitbake to notice providing the value of xxx. Once this is done we can assume the sstate cache directory has all the sigdata. We know the name of the endpoint we want, and all the task start points this would have (X:do_fetch, Y:do_fetch and so on) along with intermediate steps. We'd want to search the sstate cache directory for each task in the tree, we'd likely come up with some matches for some points and others where there was mismatch. We'd then be able to list the possible deviations, ordered from least difference to most difference compared to the current build. The challenge is therefore to write such a tool and display this data to the user in a way they can understand. They'd probably have to select a deviated tree, then be able to browse the diffsigs for the points. 38429 1 richard.purdie 2013-11-01 14:56:50 +0000 There are two pieces to this, one is the underlying tooling which is something Paul/I can probably help with. The second is visualising it which is something Ross might be able to help with. Also cc'd Belen to ensure she is in the loop with this as it could have implications for the toaster UI of this data too amongst other things. 41815 2 richard.purdie 2014-03-27 09:53:28 +0000 There is now a bitbake -S printdiff option (compared with bitbake -S none which is the original behaviour). This gives us something to start working with, its far from perfect but its a start. http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=774eb753d8f23d5887c476062acced3bb0ac40c7 41864 3 srifenbark 2014-03-27 15:35:19 +0000 Hi, Working with Richard Purdie, we have created a new paragraph in the "Checksums (Signatures)" section of the BB manual that addresses the new -S option and the fact that the user can now direct BB to use a special signature handler for potential debugging purposes. The change can be viewed here: http://www.yoctoproject.org/docs/1.6/user-manual/user-manual.html#checksums. I am turning the documentation flag to "Done." Scott 42167 4 sstncr 2014-04-02 13:59:44 +0000 Marked as Verified.