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

Jeroen van Meeuwen (Kolab Systems) vanmeeuwen at kolabsys.com
Wed Feb 18 10:28:05 CET 2015


On 2015-02-13 12:52, Sandro Knauß wrote:
> 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.
> 

Signing is something you do for actual releases:

   http://mirror.kolabsys.com/pub/releases/

>> 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.
> 

It does, however, require a very recent version of kdepimlibs, such that 
for example Enterprise Linux 6 does not ship said recent version of 
kdepimlibs.

Kind regards,

Jeroen van Meeuwen

-- 
Systems Architect, Kolab Systems AG

e: vanmeeuwen at kolabsys.com
m: +41 79 951 9003
w: https://kolabsystems.com

pgp: 9342 BF08


More information about the devel mailing list