[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