[OE-core] Availability of automated buildhistory for master/master-next and YP autobuilder

Richard Purdie richard.purdie at linuxfoundation.org
Fri Apr 1 14:45:16 UTC 2016

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

The output gets shared into a git repository at:


For master builds, there are branches like:


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.:


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:


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:


The /usr/src/kernel dir/subdir permissions changed. Was that

/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!



More information about the Openembedded-core mailing list