Description of problem: It turns out Citadel is not the current upstream for libical as was presumed during the review. https://gna.org/bugs/?10790 The correct upstream on which Citadel' copy is developed can be found here. http://freeassociation.sourceforge.net/ Please consider changing vendors. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
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 small fork. 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. For reference: Major distros using freeassociation libical: openSUSE: http://www.novell.com/products/linuxpackages/opensuse/libical-devel.html Debian: http://debian.mirror.inra.fr/debian/pool/main/libi/libical/libical_0.30-1.diff.gz Mandriva: http://archives.mandrivalinux.com/changelog/2007-11/msg01549.php Foresight / rPath Linux: http://lists.rpath.org/pipermail/foresight-commits/2007-December/015881.html Major distros using citadel libical: Fedora Ubuntu: http://mirror.ne.gov/ubuntu/pool/universe/libi/libical/libical_0.27-1.diff.gz (they will however get the freeassociation one next time they sync with Debian at the start of their new cycle) Sabayon / Gentoo: http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-libs/libical/libical-0.27.ebuild?view=markup Linux Mint: 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: PCLinuxOS: http://distro.ibiblio.org/pub/linux/distributions/texstar/pclinuxos/apt/pclinuxos/2007/SRPMS.extra/libical-0.26.7-1pclos2007.src.rpm (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: SPEC: http://dnielsen.fedorapeople.org/libical.spec SRPM: http://dnielsen.fedorapeople.org/libical-0.30-1.fc9.src.rpm 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 fall out. Build is koji here: http://koji.fedoraproject.org/koji/taskinfo?taskID=464715
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. http://koji.fedoraproject.org/koji/taskinfo?taskID=466094
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. REOPEN
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 interesting. 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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
(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.