Builing kopano for Centos
-
Hi Kopano community,
First of all congratulations with this excellent project with ditto documentation!
Being a Zarafa user for many years now, and realizing that the reason the “old” Clearos box is still running; I am trying to set up Kopano for my own personal use. Having bad experiences with nightly builds, they are there for testing, I am opting for compiling it from sources targeting centos 7. Flowing the lead of the Suse maintainers, already succeeded and have have an running setup,
My first question is about the releasing-policy; or how to be more precise, how do they relate to ‘stable’ ?
Is it like it’s Friday afternoon-beer time and you decide it is about time to push a release out? – just kidding – nevertheless I can follow the lead of (the close to the source sitting) maintainers at Suse, I would prefer to build it form release tagged source, rather than a snapshot, so I know where I am looking at.
Other questions are regarding (build)dependencies;
-
Jsoncpp > 1.4.0 #the package in the el7 epel repo (0.10.5) is still based on the 0.x.y branch (which holds compatibility with some ancient compilers) but supersedes 1.4.x in time-line.
Is there a exscind reason, other than 0.x.y wont build for arm-architecture, to demand > 1.4.x? -
Libs3 > ? Requirements regarding Libs3 version is a bit fuzzy, not that important as I probably opt for building it without amazon S3 support. Never the less I got quirky builds with the el7 epel libs3-2.
Are there minimum requirement for libs3? -
And this worries me a bit:
https://forum.kopano.io/topic/1404/kopano-8-6-80-source-compilation-error
Until now no problems building it with gcc 4.8.5, I it is always possible to use a devtootsetX, however for arm this is not so eminent.
Is gcc 4.8.x being dropped?
Grzt
Mark Verlinde -
-
@markvnl said in Builing kopano for Centos:
Is it like it’s Friday afternoon-beer time and you decide it is about time to push a release out? – just kidding
Why not, that doesn’t sounds too bad ;-)
Version tagging is a bit different for each project. In WebApp a new version is tagged once a sprint has concluded, for Groupware Core we tag (with the exception of x.y.80-99, since they are reserved for nightly, beta and rc versions) when we are confident it contains what we want in it. There is a delay between tagging and an actual binary release to customers since here we do final qa checks. qa could keep a release back (as it happened with 8.6.x until 8.6.2) in case its not declared “fit for customers”. Tags will be kept in that case and the dance begins again once a new version is tagged.
In regards to specific versions of dependencies and buildtools. We usually try to work with the versions being available in the distributions we support. if that is not possible we compile and maintain these dependencies ourselves. So its a recommendation to check which packages and versions we provide for any custom builds
As for gcc 4.8.5. There are concrete plans to retore gcc 4.x in general, the only reason holding back for the moment is that this is still required for Debian 8, once this distribution is out of support there is no reason for us anymore to optimize for newer versions.
