[Kolab-devel] Process Around Kolab 3.4 Release (Book Fri, 15:00 CET)

[Sandro Knauß]

Hi,

> > * signing packages. Debian/Ubuntu allows to test the integetry of a
> > source packages via a dedicated gpg signature.
> What is wrong with OBS's signing today?

with OBS signing there is nothing wrong. I am talking about the source package 
aka. tarball. These are till now "only" git snapshots without a dedicated 
signature. f.ex.

http://git.kolab.org/libkolabxml/libkolabxml/snapshot/libkolabxml-([0-9\.]+)\.tar\.gz

we have these tar balls, but there are no signatures for these tarballs.

> We'll want to compile libkolab against KDE PIM libs where those KDE PIM
> libs are of a recent enough version. Think of libcalendaring in this
> case like as if it where a bootstrap library, allowing you to build
> libcalendaring, then libkolab, then KDE PIM libs to ultimately ditch
> libcalendaring and rebuild libkolab (against the KDE PIM libs).

no we do not need libcalendering for bootstrap:
libkolab only need kdepimlibs as dependency and kdepimlibs does not depend on 
libkolab at all.

But in the end I do not care about libcalendering lying around (the libnames 
all differ, so there should no installation problems). The important part is 
that if you use libkolab built with libcalendering within kontact you will 
face funny errors...

With the work done for kontact we can remove all builds against libcalendering 
for debian7 & ubuntu 12.04 and later. The point why this should be discussed 
is, that kdepimlibs had much more dependencies than libcalendering. And it 
affects kolab servers, where i do not have so much knowlege.

sandro

-- 
Sandro Knauß
Software Developer

Kolab Systems AG
Zürich, Switzerland

e: knauss at kolabsys.com
t: +41 43 501 66 91
w: http://kolabsys.com

pgp: CE81539E Sandro Knauß