[Kolab-devel] thomas: server/php-kolab/Kolab_Filter issue3192.patch, NONE, 1.1 issue3441.patch, NONE, 1.1 ChangeLog, 1.28, 1.29 Kolab_Filter.spec, 1.18, 1.19 Makefile, 1.7, 1.8

[Richard Bos]

Hi!

Op woensdag 04 maart 2009 10:09:41 schreef Thomas Arendsen Hein:
> > - will those patches be available via the packages kolab-filter [1] and
> > kolab- freebusy [2] on pear.horde.org?  If so, when will they be
> > available?
>
> Gunnar is quite busy at the moment, but I expect those patches to go
> upstream in the preparations for 2.2.1 final (together with unit
> tests).

The unit tests have already proved to be useful (at least for me)!  That's why 
I found the incorrect version of the iCalendar package.  As a side effect I 
learned that the horde package is not at all necessary for the plain kolab-
server.

BTW: how to deal with the horde packages in case the kolab server and the 
webclient are installed and run on 1 server?  In this setup the kolab server 
must use the package in  (e.g.) /usr/share/php5/pear directory, while the web 
client should use the horde packages in /srv/www/htdocs/horde/lib
As the include path is defined in /etc/php.ini should there be 2 php.ini files 
1 for the kolab server and another to be used by the web client? 


> > Why are the patches applied against the rpms, and not upstream (no
> > offence, just curious)?
>
> Some moments ago we were upstream, but as this has changed I do not
> have commit access[1] to their repositories. So the only chance to
> get in changes fast is to use patches. 

ok.

> These patches are not applied
> against the RPM, but against the included unmodified upstream
> tarball, so you might be able integrate them in your RPMs, too.

That's what I actually meant with applied against the rpm (of course they are 
applied against unmodified upstream tarball).  I'll wait for you, hopefully 
you can commit the changes soon to upstream.

> Thomas
>
> [1] I haven't tried to get commit access as they are currently
> moving from CVS to git including at least two important branches in
> each SCM that have to be kept in sync. I'll wait until things settle
> down before trying.

Interesting, also moving to git..... 

-- 
Richard