MPIR 2.7.0 has arrived, and brings an soname bump with it. As far as
I can tell, nothing in Fedora uses mpir, so I don't think anything
needs to be rebuilt. If I'm wrong about that, send me some hate mail
and I'll rebuild your package.
Following is the list of topics that will be discussed in the FPC
meeting Thursday at 2015-07-02 16:00 UTC in #fedora-meeting-1 on
Local time information (via. rktime):
2015-07-02 09:00 Thu US/Pacific PDT
2015-07-02 12:00 Thu US/Eastern EDT
2015-07-02 16:00 Thu UTC <-
2015-07-02 17:00 Thu Europe/London BST
2015-07-02 18:00 Thu Europe/Paris CEST
2015-07-02 18:00 Thu Europe/Berlin CEST
2015-07-02 21:30 Thu Asia/Calcutta IST
2015-07-03 00:00 Fri Asia/Singapore SGT
2015-07-03 00:00 Fri Asia/Hong_Kong HKT
2015-07-03 01:00 Fri Asia/Tokyo JST
2015-07-03 02:00 Fri Australia/Brisbane EST
Links to all tickets below can be found at:
= Followups =
#topic #508 New GID for openstack-neutron
= New business =
#topic #547 SourceURL addition/clarification - Git Hosting Services
= Open Floor =
For more complete details, please visit each individual ticket. The
report of the agenda items can be found at:
If you would like to add something to this agenda, you can reply to
this e-mail, file a new ticket at https://fedorahosted.org/fpc,
e-mail me directly, or bring it up at the end of the meeting, during
the open floor topic. Note that added topics may be deferred until
the following meeting.
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>