Following up on the ABI checking topic raised in the "API Break
Detection" section near the end of the post
I'd like to summarize where we stand at the moment and what we plan do.
We discussed this topic on the #fedoral-devel IRC channel yesterday and
here is what stuck to my mind. Others are of course welcome to add what
I have forgotten and to correct me when I a wrong.
To start, we'd like to have an automated way to check the ABI
compatibility of binaries embedded in packages that are submitted to the
updates-testing repository. When an incompatible change is detected,
the package will be prevented from auto-increasing it's karma count. I
guess a manual intervention will then be required to increase the karma
or a new package version needs to be submitted again.
Under the hood, the current informal plan seems to be to come up with a
Taskotron checking task, which, for a given package named P, will
compare the ABIs of the binaries embedded in P against their
counterparts in the latest known stable version of P that is present in
the stable repository. The result of the comparison shall be a report
showing the ABI difference of the offending binaries, if those changes
are deemed harmful or possibly harmful, from an ABI compatibility
At this moment, we do have a command line tool named "abidiff" that
knows how to compare two shared library binaries and emits a report
about the differences in their ABI. That tool needs the debug info of
the binaries too. We are currently working on a tool named
"abipkgdiff" that takes two RPMs and compares the shared library
binaries. That tool should be ready enough (hopefully) in the coming
When the "abipkgdiff" command line tool is ready , I guess the plan is
to use it in a new Taskotron task that, when invoked on a given package,
gets the stable version of that package as well as the debuginfo
packages from koji, executes abipkgdiff to compare the package against
it's stable version and emits the resulting report.
So, that is the first "baby step" we talked about.
There are obviously going to be many other baby steps coming up, and
I'll write something about them a little bit later on this topic,
possibly in the wiki, rather. Needless to say, even the baby steps in
this note need to be refined, I guess we'll do that on the wiki some
where. But until then, I thought I'd drop this note to let you know
where we stand.
Thank you for reading so far.
: A change in a the ABI of a shared library is considered
"compatible", if an application linked with the older version of the
library is still going to function reliably when executed against the
newer version of the library, without being re-linked. Otherwise, the
ABI change is considered "incompatible".
: abidiff manual documentation can be consulted at
: abipkgdiff is being hacked on by Sinny Kumari in a branch of the
upstream libabigail git repo at
Hi dear developers,
after upgrading to tb-38.0.1, thunderbird-lightning-3.3-5.fc22.x86_64
has been obsoleted (as the formus are telling), but still the addons
manager of tb shows lightning as installed extension which can be
activated and removed.
Because I thougt that tb-lighning is now obsolete, I removed the
extension, but then I get rid totally from the calendars. So my
question: how t get the calendars running in TB without installing
lightning from the moz. extension pages?
Fedora release 22 (Twenty Two)
Joachim Backes <joachim.backes(a)rhrk.uni-kl.de>