Kolab 3.0 development

From Kolab Wiki

This page applies to Kolab 3.

This page is a draft only
It is still under construction and content may change. Do not rely on the information on this page.

This page collections some information which could be useful for developing on Kolab 3.0 components.

libkolabxml

libkolabxml is the serialization library for the Kolab Format 3.

libkolab

libkolab provides conversions from/to KDE containers, mime message handling and facilities to read and write kolabv2 and kolabv3. The Akonadi-Kolab-Resource as well as the upgradetool are based on this code.

Akonadi-Kolab-Resource

The Akonadi-Kolab-Resource provides the integration of Kolab Objects into KDE. It is implemented as meta resource, reading the data from a normal IMAP-Resource and providing the calendaring, addressbook and notes interfaces for the data.

While the resource originally implemented the complete Kolab Format, the rewrite now uses libkolab and libkolabxml for this task.

The resource is available at: git://anongit.kde.org/clones/kdepim-runtime/cmollekopf/pimRuntimeClone.git in the kolabresource branch (work in progress)

Kolab Folders

Originally the Kolab Resource expected all Kolab Folders to be below INBOX.

Because this is not necessarily possible or desirable, this behaviour has been changed.

• If a folder INBOX is available and usable (writable, folders can be created), it is picked as default parent to create the default kolab folders.
• All folders in the tree with the "/vendor/kolab/folder-type" are interpreted as kolab folders.
• There must be one, and only one, default folder for each type, marked with "/vendor/kolab/folder-type event.default"
• More folders may exist with type only "/vendor/kolab/folder-type event"
• if INBOX was picked as parent, it is shown in the kolab resource as "My Data", otherwise the kolab folders are toplevel in the kolab resource.
• The kolab resource produces one kolab-resource collection tree per imap resource.

Fedora Prerequisites

On Redhat base distributions such as CentOS or Fedora, the following repository is needed for i.e. xsd:

/etc/yum.repos.d/kolab.repo:

[kolab]
name=Kolab
baseurl=http://mirror.kolabsys.com/pub/redhat/kolab-3.0/el6/development/x86_64/
enabled=1

Because the libraries are installed into /usr/local/lib which is not included in the search path on red hat based distributions you need to add the following file:

/etc/ld.so.conf.d/kolab.conf

/usr/local/lib

With 'sudo ldconfig' the cache is updated and the libraries should be found.

Misc

When experimenting with i.e. migration utilities in i.e. two virtual machines with kolab here are a couple of useful commands:

List all available mailboxes:

kolab lm

Clear roundcube cache, after modifying mail spool, so the i.e. the calendar gets updates.

mysql --password=$PASS roundcube -e "truncate table kolab_cache;truncate table cache_index;truncate table cache_messages;"

cyradm

cyradm -u cyrus-admin localhost

list all mailboxes:

lm

show annotations:

info user/christian.mollekopf/Trash@example.org

http://wiki.kolab.org/IMAP_Annotations

Mock

On fedora mock can be used to compile libkolab and libkolabxml in a sandboxed environment.

use the feature-el6-kolab-3.0-development-i386 architecture.

To prepare an srpm:

#!/bin/bash
rm -rf libkolabxml-0.3
mkdir -p libkolabxml-0.3
cp -a AUTHORS autogen-mingw32.sh autogen.sh cmake \
    CMakeLists.txt compiled COPYING DEVELOPMENT \
    INSTALL libkolabxml-version.h.cmake NEWS \
    README README-Mac.txt schemas src testfiles \
    tests libkolabxml-0.3
cp libkolabxml.spec libkolabxml-0.3/
tar zcvf libkolabxml-0.3.tar.gz libkolabxml-0.3/
rm -rf libkolabxml-0.3
rpmbuild -ts libkolabxml-0.3.tar.gz

The spec file is in a separate git repostiory.

Enabling the caching options in /etc/mock/site-defaults.cfg can greatly speed up subsequent building operations.

If you have the chroot directory specified like this:

config_opts['root'] = 'feature-el6-kolab-3.0-development-x86_64.%s' % (os.getpid())

Note that this will create a new chroot every time (based on pid). (In this case also make sure that your caching directories are not relative to root, otherwise they're only wasting space)

Alternatively you can have only one chroot per architecture, and using the --no-clean option you can rebuild very quickly. Note that this affects reproducibility obviously.

To run a fresh build:

/usr/bin/mock -v -r feature-el6-kolab-3.0-development-x86_64 /home/user/rpmbuild/SRPMS/libkolabxml-0.3-0.1.fc16.src.rpm

Without cleaning the buildchroot (speeds up subsequent building):

/usr/bin/mock -v --no-clean -r feature-el6-kolab-3.0-development-x86_64 /home/user/rpmbuild/SRPMS/libkolabxml-0.3-0.1.fc16.src.rpm

To get an interactive shell inside the chroot (to debug building issues):

/usr/bin/mock -v -r feature-el6-kolab-3.0-development-x86_64 --shell