Red Hat Bugzilla – Bug 434635
Using incorrect upstream
Last modified: 2008-09-06 13:30:53 EDT
Description of problem:
It turns out Citadel is not the current upstream for libical as was presumed
during the review.
The correct upstream on which Citadel' copy is developed can be found here.
Please consider changing vendors.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
nothing's wrong in here.
libical was forked many times.
in review I was pleased to change source. I've changed.
why should I change sources AGAIN and make my osmo broken and also other app,
which name I do not remember?
I apologize for the length of the following.
a few reasons spring to mind:
A) All distros packaging the same version will drive that to become the defacto
standard (see below for a summary of the most used distros shipped libical)
B) The previous upstream maintainers has explictedly handed maintainership over
to this group of developers. Thus they are assumed to be the maintainers of the
one true upstream, we should bolster and support the decision of the previous
maintainers instead of continuing a divisive support of a fork.
C) Upstreams such as Bongo are more likely to cease bundling their own copy of
libical in favor of this solution, an overall gain for users and developers.
This however is depended on them being able to rely on the ABI/API compatible
libical being present on most distros.
Fedora should help in this drive the adoption of the one true upstream for
libical. In the long run it would serve you best as well, it would give you a
place we know has active development to which you could send bugs and it would
be one that in it being used by all distributions you should see patches make
their way upstream instead of each distributions turning their package into a
I know I advised a switch to Citadel during your review, mainly because I was at
that time informed that it was the accepted upstream. Additional research and
communication with several people has revealed that this is not the case. I do
apologize for that, it was however the advice I had to give at the time as
Fedora guidelines do strive to keep us as close to upstream as possible, given
the information available to me at the time that seemed to be the best thing.
I urge you to consider switching to the freeassociation libical for these reasons.
Major distros using freeassociation libical:
Foresight / rPath Linux:
Major distros using citadel libical:
(they will however get the freeassociation one next time they sync with Debian
at the start of their new cycle)
Sabayon / Gentoo:
This is an Ubuntu based distro, but they have been talking about switching their
base to Fedora. Regardless they will move with Ubuntu into the freeassociation
column for the same reason Ubuntu will or go with whatever their new base uses
should they elect to switch base distros.
Major distributions using other libical implementations:
(http://www.aurore.net/projects/libical/ - discontinued fork which is now handed
over to citadel, meaning they ship unsupported and outdated software.
Additionally libical only shipped as an extra package, they will need to switch
come their 2008 release - if you switch I promise to make it my mission to at
least have them consider freeassociation as their replacement)
That should cover the most used distros, a strong trend of using freeassociation
or moving to it eventually can be seen. At the beginning of the Intrepid Ibex
Ubuntu development cycle (roughly 3-4 months and Hardy release date + 6 months
for public availability in a distro release), this will lead to only Gentoo and
PCLinuxOS having a none freeassociation libical due Ubuntu syncing up with
Debian proper and the change thus spreading to the derived distros. Gentoo and
PCLinuxOS should thus be easy to convince to switch to supporting one upstream I
will personally see to that they at least hear the arguments at least.
Test if osmo builds against freeassociation's libical and tell me that.
I have no time for such experiments.
The updated libical spec and srpm can be found here:
I tested osmo on my x86_64 machine running rawhide and it compiled without
complaints, it starts and functionality is complete (to the best of my knowledge
having never used osmo before - it works just the same on my machine as your
original package at least).
If so, you can put this into CVS, because I was thinking about such ability earlier.
Not sure if "others" can build that packages, but you're free to try.
Thank you, I have checked this into development and build a package. As this
seems to be API compatible but not ABI compatible with Citadels libical any
packages depending on libical will need to be recompiled.
Thus I am not recommending building this for F8/7 till we see if there is any
Build is koji here:
So osmo would be built against "mine" libical in < F-9, while bongo cannot not
be available for > F-9.
Not so bad.
well provided nothing breaks in development we are free to push the new libical
and any packages that depend on it to F8/7, but since the current libical works
and this is both a switch to another source base and a version bump.. I am
tending to favor caution for now and dogfood it a bit.
Eventually we will probably benefit from just having one libical (basically less
code for you to support), but there is no hurry - it can simmer for a few weeks
in development first. There we can allow for a little breakage, once any
breakage has been sorted out we can push everything to updates-testing in one go
- thus avoiding users having broken packages.
uour osmo package is the only one currently depending on libical according to
repoquery. I've issued a rebuild for Devel so it doesn't silently break for anyone.
Thanks for all your work (I was too lazy).
You did everything, but it doesn't matter, 'cause we both work on the same :) .
Resolving as RAWHIDE.
I'd like to keep this one open till we have the same libical in all the repos.
At least if this is open and someone for some reason should build a new package
against libical in both F7/8 and devel they will find a bug explaining why
different versions and vendors are used.
I'd love to see the new libical pushed to stable after it has been dogfooded a
bit in devel, as osmo is the only user currently it would be nice if you beat
the living daylights out of it once the new package hits the repo.
Jakub, this has been simmering in Rawhide for a while, if you haven't done so
already then rebuilding using the rawhide spec on F-7/8 and the deps it might
carry (your osmo is the only one) might be a good move, though depending on if
you have seen any problems with it.
I'm not using Osmo, because after packaging I noticed that it's not what I
wanted, however I can maintain it for some time, until I get something more
You think rebuilding Osmo might be now a good idea? Let's update todo list ;) .
I say we sync the development libical package for F-7 and F-8, then issue
rebuilds of apps that depend on it to avoid the ABI change.
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
(In reply to comment #6)
> Thank you, I have checked this into development and build a package. As this
> seems to be API compatible but not ABI compatible with Citadels libical any
> packages depending on libical will need to be recompiled.
> Thus I am not recommending building this for F8/7 till we see if there is any
> fall out.
Looks like libical-0.30 does not have the timezone information provided by the
older versions (Citadel ones?) in Fedora 8, and Osmo (when started from the
terminal) throws a warning about this.
Got a patch to fix the Osmo problem.
Libical has been updated to version 0.32 from Freeassociation on Fedora 8,9 and Rawhide. Osmo has been patched to use this version of Libical.