[Pkg-giraffe-discuss] zarafa-7.2.1 RC1 released

[Guido Günther]

Hi,x
On Thu, Oct 01, 2015 at 10:33:50AM +0200, Mark Dufour wrote:
> hi guido,
> 
> sorry for the late reply, I'm really quite busy at the moment.
> 
> I have actually been working on python3 support on and off, I guess since you guys asked about this.. with a patch of about 2,000 lines (mostly in our SWIG bindings), I can now build ZCP with python3 and run the python-zarafa tests (currently not open source) without failures. as it turns out to be quite a bit of work (however fun), I decided to park this for now. perhaps with 7.2.3 we could merge some or all of this work into production. 
> 
> about the daemonization issue: I guess we could move some or all of
> the checks that currently occur _after_ daemonization to before it, so
> we get an error code if it doesn't reach the main loop.. I've put this
> into our internal issue tracker in any case, to see if someone else
> might pick it up. but can't we somehow just ignore this and switch to
> systemd, which should work fine for debian 8 and up..?

As said we're still supproting sysv but I think we're o.k. for experimantal.

> 
> > Well, we just can't ship a non-functional dev package. That just makes
> > no sense and will be (rightfully) a source of frustration for people
> > installing it. We can drop the dev package but if we do that having 7
> > split out libraries packages really makes no sense anymore if _nobody_
> > can use them separately. So I see two ways out of this:
> >
> > 1.) _either_ merge all shared objects (private or not) into a
> >   zarafa-libs and make it clear that this is a purely internal
> >   dependency (from the package description)
> > 2.) _or_ fix up the public headers so people can develop against it.
> > 
> > I would prefer 2.) but if 1.) is quicker we can go that route until
> > 7.2.2 but then again I can't do this soonish so somebody would need
> > to pick this up. The pattern would be pretty much the same as in
> > 26fce433bfbaf7cd9fefa80148d5c742cc1ba481.
> 
> I personally would go for 1) and just keep it this way. because
> cleaning this up is a lot of work, and would benefit just about
> nobody, now or in the future. of course we can always (partially)
> revisit it at some point when there is an actual need for using any of
> this separately..

Went down that road and pushed it. I think we're mostly set. It'd be
nice if somebody would check the packages before I do an upload.
Cheers
 -- Guido