Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 197765 - Review Request: libical - A library for parsing iCal component
Summary: Review Request: libical - A library for parsing iCal component
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Nobody's working on this, feel free to take it
QA Contact: Fedora Package Reviews List
Depends On:
TreeView+ depends on / blocked
Reported: 2006-07-06 05:14 UTC by Callum Lerwick
Modified: 2007-11-30 22:11 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2007-06-06 00:06:47 UTC

Attachments (Terms of Use)

Description Callum Lerwick 2006-07-06 05:14:31 UTC
Spec URL:


libical is an Open Source (MPL/LGPL) implementation of the IETF's iCalendar
Calendaring and Scheduling protocols. (RFC 2445, 2446, and 2447). It parses
iCal components and provides a C API for manipulating the component properties,
parameters, and subcomponents.

This library is required for calendaring support in the Citadel groupware server, which I will be submitting soon.

Comment 1 Ralf Corsepius 2006-07-06 06:25:28 UTC
Just some comments:
* The spec file and say:
"This is a modified version of the original libical project."
i.e. this package would conflict with the "original libical"

I am not sufficiently familiar with libical, but this raises concerns on your
- Is this libical*aurore API compatible to the "original libical"? What are the
- Is the "original libical" still alive?
- How is this package supposed to interact with an "original libical"?

* The package installs its headers to /usr/include. Though the headers all are
prefixed "ical*", this pollutes the system header include path.

Besides this, the package seems to be clean.

Comment 2 Ville Skyttä 2006-07-06 06:41:46 UTC
One existing package in FE that could be checked whether/how it works with this
version of libical is gnokii (maintainer Cc'd).

Comment 3 Callum Lerwick 2006-07-06 07:17:47 UTC
libical has lacked a solid upstream in the past. Most of its users have forked
their own copies. (kdepim, sunbird, evolution) This version seems to be an
attempt to merge them back together. The "original libical" has been dead since

According to, libical has not been packaged for any version of
Fedora/Red Hat before at all, ever. It was pulled from Debian a while back,
nothing ever used it. Backward compatability does not seem to be a realistic
concern. Citadel seems to be its sole non-forked user.

Comment 4 Parag AN(पराग) 2006-07-06 08:35:52 UTC
== Not an official review as I'm not yet sponsored ==
* Mock build for development i386 is sucessfull
MUST Items:
     - MUST: rpmlint shows no error 
     - MUST: dist tag is present
     - MUST: The package is named according to the Package Naming Guidelines.
     - MUST: The spec file name matching the base package libical, in the
format libical.spec
      - MUST: This package meets the Packaging Guidelines.
      - MUST: The package is licensed with an open-source compatible license
      - MUST: License file COPYING is included in package.
      - MUST: The sources used to build the package matches the upstream source,
as provided in the spec URL. md5sum is correct  as 36c80c43940841e53e5a985204851c46.
      - MUST: This package owns all directories that it creates. 
      - MUST: This package did not contain any duplicate files in the %files
      - MUST: This package  have a %clean section, which contains rm -rf
      - MUST: This package used macros.
      - MUST: Document files are included like README.txt.
      - MUST: Package did NOT contained any .la libtool archives.
- MUST: Header files are going in a -devel package.
      - MUST: Library files that end in .so (without suffix) are in a -devel
      - MUST: This package contains shared library files located in the dynamic
linker's default paths, and therefore this package is calling ldconfig in %post
and %postun. But Devel package is NOT calling a %post/%postun section that calls
      * Source URL is present and working.
      * BuildRoot is correct BuildRoot:       
%{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
      * BuildRequires is correct
      * devel package contains  the base package using a fully versioned
dependency: Requires: %{name} = %{version}-%{release} 

Comment 5 Michael J Knox 2006-07-21 05:39:00 UTC
Hi.. I will review this package for you.. 


Review for release 0.1.aurore:

* Source libical-0.26-6.aurore.tar.bz2 is the same as upstream
* This is the latest version
* Builds fine in mock
* rpmlint of libical-devel looks OK
* rpmlint of libical looks OK
* File list of libical-devel looks OK
* File list of libical looks OK

Needs work:
* Package does not follow Fedora's package naming guildlines
  (wiki: PackageNamingGuidelines)

I am not certain that the release tag is ok. So I will ask on fedora-packaging. 

* The package should contain the text of the license
  (wiki: Packaging/ReviewGuidelines)

The tagball contains a COPYING file. You should add it to the %docs  


Looks good. Once I find out about the release tag and the COPYING is included,
it should be all good. 

Comment 6 Michael J Knox 2006-07-21 05:43:47 UTC
Actually, I just reviewed an email I sent on a similar subject. 

I asked about non-numeric values in the release string and this was the response. 

" Not if you move the non-numerical bit to the least-significant place (= the
very right). "

So, I am satisfied with that. Fix up the COPYING file and I can approve the

Comment 7 Linus Walleij 2006-07-25 21:41:28 UTC
Gnokii 0.6.12 will use libical if present and useable. It picks
up this package and uses it if present, seems to link and build
fine. (No thorough stress/usage testing though!)

When libical is built and released I will BuildRequires it and
rebuilt gnokii packages.

If you push upstream to put headers in a separate subdir I think
gnokii will have to adopt to that before it can be used.

Comment 8 Callum Lerwick 2006-08-06 00:42:49 UTC
Erk. The COPYING file is null. Thats why I didn't include it.

I'll poke upstream about it.

Comment 9 Toshio Kuratomi 2006-09-05 02:21:35 UTC
Hope upstream is still alive or it'll start to look like the libical name is
cursed :-)  Have you tried Omar's email directly?

The Version-Release string doesn't look right to me.  You have:

  Version: 0.26.6
  Release: 0.1.aurore%{?dist}

The tarball is libical-0.26-6.aurore.tar.bz2
The tarball unzips to: libical-0.26

This isn't definitive but maybe:
  Version: 0.26
  Release: 0.1.6.aurore%{?dist}

More Licensing Woes:

  (C) COPYRIGHT 1999 Eric Busboom

  This package is free software and is provided "as is" without
  express or implied warranty.  It may be used, redistributed and/or
  modified under the same terms as perl itself. ( Either the Artistic
  License or the GPL. )

The README says dual licensed LGPL/MPL but this conflicts.... Probably Eric
Busboom needs to be contacted to see if he relicensed the library at some point
and this was an oversight.

hula uses an embedded copy of libical-0.24 so I'd like to see an active upstream
that I can tell the hula developers they should start porting to.

Comment 10 Michael J Knox 2006-09-16 20:30:38 UTC
Sorry. Due to my stepping out for a while, I am unable to complete this review. 

Comment 11 Jason Tibbitts 2006-10-02 02:41:06 UTC
It would still be good to see a response to Toshio's questions.

Comment 12 Callum Lerwick 2006-12-11 11:02:05 UTC
I emailed on Oct 28, no reply so far. Sigh, looks like this
upstream may have died as well.

Comment 13 Callum Lerwick 2006-12-12 22:26:14 UTC
From the lead Citadel developer:

Mon 11 Dec 2006 12:43:30 PM EST from IGnatius T Foobar @uncnsrd

> Do you guy's have contact with Omar at all? Is libical dead again? Is
> there a new maintainer?

I've sent him a few emails but I seem to have lost touch with him.

He was given admin access to the SourceForge site, and we all expected that he
was going to upload his code there, which would essentially make it *the* new
version. Andrea Campi and Eric Busboom were happy to hand over maintainership of
it to him.

I really don't want to take ownership of libical if we don't have to.

Comment 14 Jason Tibbitts 2007-06-01 02:14:37 UTC
So, nearly six months later, any chance that something can happen here?  Or
should this ticket just be closed?

Comment 15 Jason Tibbitts 2007-06-06 00:06:47 UTC
No response; closing.

Note You need to log in before you can comment on or make changes to this bug.