We've had buildhistory for a while and its long been intended to make better use of it. I'm pleased to say that we now have this available on our automated infrastructure (thanks Beth, Michael and others who've helped!).
The output gets shared into a git repository at: http://git.yoctoproject.org/cgit.cgi/poky-buildhistory/ For master builds, there are branches like: http://git.yoctoproject.org/cgit.cgi/poky-buildhistory/log/?h=poky/master/nightly-arm with one per autobuilder build target. These logs are incremental and data is appended to the previous build data. master-next poses some challenges since it can be rebased. Right now the autobuilder is pushing a fresh branch each time, e.g.: http://git.yoctoproject.org/cgit.cgi/poky-buildhistory/log/?h=poky/master-next/nightly-arm These are reset for each new build. Comparisons can be made against the latest master branch but for now that is a manual process since the autobuilder doesn't know how to map "master-next against master". There are also other branches created for other poky-contrib based builds. We do need to start analysing this data as it does highlight there are problems within the builds. For example, looking through the latest master packages diff for arm: http://git.yoctoproject.org/cgit.cgi/poky-buildhistory/commit/?h=poky/master/nightly-arm&id=76be4fa8cbcab7c334ae299188f3c3d7684d5349 why did the attr-dbg package change its FILELIST? It could have been the gcc patch but was it a good change? The files contained in images is also a bit worrying: http://git.yoctoproject.org/cgit.cgi/poky-buildhistory/diff/images/qemuarm/glibc/core-image-sato-sdk/files-in-image.txt?h=poky/master/nightly-arm&id=77580baf448a95c6d66f963d112300a0214c233a The /usr/src/kernel dir/subdir permissions changed. Was that intentional? /var/lib/sudo/lectured changed into /var/db/sudo/lectured. Why? I'd love some help going over this output, logging bugs for issues found and then help in fixing the builds. I'm pretty sure there are some serious reproducibility issues buried in there. By that, I mean that two builds which are supposedly of the same revision, have produced slightly differing results. We do have some tools like buildhistory-diff which are designed to filter the repository data and come up with a list of "serious" problems and filter out normal version changes. We're aware there are shortcomings in those tools but this may give us the push to go and fix or improve them! Cheers, Richard -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
