An update about: Checking the ABI of packages submitted to the updates-testing Fedora repository
mkrizek at redhat.com
Wed Jul 1 13:16:24 UTC 2015
----- Original Message -----
> From: "Dodji Seketeli" <dodji at seketeli.org>
> To: "Fedora Devel" <devel at lists.fedoraproject.org>
> Cc: kparal at fedoraproject.org, mkrizek at fedoraproject.org, skumari at fedoraproject.org, sgallagh at fedoraproject.org,
> tflink at fedoraproject.org
> Sent: Thursday, June 25, 2015 10:52:47 AM
> Subject: An update about: Checking the ABI of packages submitted to the updates-testing Fedora repository
> A little update about this project we have been tinkering about.
> First thing first, a tracking ticket has been opened against the
> Taskotron project to follow the progress of this effort:
> Just so you remember the big picture, for each stable package named
> N-stable-V-R, whenever a new update N-update-V-R is submitted, we want
> to compare the binaries (mostly C and C++ libraries) to see if there
> has been any harmful ABI change. If there has been any, then the
> update will not be pushed *automatically* to the stable repository
> when it reaches the karma threshold; rather, it will require a
> conscious decision by the maintainer.
> A number of things need to fall into place before we can actually
> have a working system.
> After discussing this in the audit trail of the tracking issue and on
> IRC, we are now heading toward triggering the ABI checks each time
> someone submits a build N-update-V-R to Koji. Whenever the
> information of a new build is broadcasted on the fedmsg bus, a
> dedicated Taskotron task kicks off and performs the following steps:
> 1/ retrieve the relevant N-stable-V-R package
> 2/ retrieve the debug info packages for N-stable-V-R and N-update-V-R
> 3/ perform an ABI comparison between N-stable-V-R and N-update-V-R,
> using their debug info as necessary input.
> 4/ store the result of the comparison in the ResultDB database.
> Then, when the package N-udpate-V-R is later submitted to Bodhi, the
> update creation process would query ResultDB for the result of the
> relevant ABI check that happened at build time. The decision to allow
> an automatic push of the update to stable will depend on the result of
> that query.
> For this system to start working, we need a set of things to fall into
> place. As noted in the tracking issue that I linked to above, we
> need to:
> * Extend koji directive to allow the download of debug info
> package. https://phab.qadevel.cloud.fedoraproject.org/T494.
> This is done now.
> * Support "latest stable build" with koji
> directive. https://phab.qadevel.cloud.fedoraproject.org/T491.
> * Have an abipkdiff tool, from the libabigail project that
> would compare binaries embedded in two RPMs and produce a
> report. This is tracked by
> The tool recently started to work in the branch
> ksinny/abipkgtool. We are still working on it, but it can
> be used for prototyping already.
> * Have a Taskotron task that will use all of the above to
> perform the ABI comparison and store the result in ResultDB.
> Note that in the beginning, we'll perform only a basic kind of
> comparison: checking that no public symbols of functions and
> variables present in the stable version disappeared in the
> Obviously, the Libabigail tools can perform more sophisticated
> comparison involving the full signature of the functions and
> variables, including their sub-types. But we think that
> should be left for later when the whole system works for the
> basic kind of ABI checks first.
> I still need to file a tracking issue for this. I guess I
> can file it to Phabricator instance of Taskotron and assign
> it to myself?
> * Write a system wide change proposal for this project.
> So this is where we stand at the moment.
>From what I understood, the current status of the ABI comparison is that it only
works with C/C++ programs. Have you given a thought on how do we know that the build
under test includes a C program and so we should run the comparison on it? Currently
we just listen on fedmsgs that koji sends about completed builds. So we need
something that would tell us "this rpm includes a program in X language - run Y check
on it". This is essentially a general concern for the future checks that would
run on builds that include programs in a specific language.
> So if you have any comment, please do not hesitate. And more
> importantly, if you feel like you can land us a helping hand, that would
> be greatly appreciated because obviously, this is far far far from being
> a one person project. I'd like to thank those who stepped up so far:
> Tim Flink, Kamil Páral, Martin Krizek, Sinny Kumari and Stephen
> Thank you for reading so far.
More information about the devel