Re: [Kolab-devel] Process Around Kolab 3.4 Release (Book Fri, 15:00 CET)
"Jeroen van Meeuwen (Kolab Systems)" <[email protected]>
| Newsgroups | gmane.comp.kde.devel.kolab |
|---|---|
| Message-ID | <49536fd1110301acca623b2130446365__26286.0506460585$1424251704$gmane$org@kolabsys.com> |
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 _______________________________________________ devel mailing list [email protected] https://lists.kolab.org/mailman/listinfo/devel