From ml at radoeka.nl Sun Mar 1 14:08:28 2009 From: ml at radoeka.nl (Richard Bos) Date: Sun, 1 Mar 2009 14:08:28 +0100 Subject: [Kolab-devel] php failure undefined method Horde_Kolab_Server_ldap::uidForIdOrMail (openSUSE native) In-Reply-To: <20090225121316.18070vbdg0u0i66o@webmail.pardus.de> References: <200902152132.47148.ml@radoeka.nl> <20090225090214.GA26295@xs4all.nl> <20090225121316.18070vbdg0u0i66o@webmail.pardus.de> Message-ID: <200903011408.30165.ml@radoeka.nl> Hi Gunnar, Op woensdag 25 februari 2009 12:13:16 schreef Gunnar Wrobel: > > which is not so bad ;) > > In my eyes this is very, very bad ;) > > You don't link stuff from an installed web application into the system ? > libraries. This is not okay. I have changed the rpm now, so the horde/lib is added to the include_path in php.ini during rpm installation. This works but.... /srv/www/htdocs/horde/lib must come before: /usr/share/php5/PEAR. If the latter is placed before the /srv/www/htdocs/horde/lib some the tests fail with: = /usr/share/php5/PEAR/test/Kolab_Filter/Horde/Kolab/Filter/AllTests.php = 1) testRecurrenceInvitation(Horde_Kolab_Filter_ResourceTest) Only variable references should be returned by reference /usr/share/php5/PEAR/Horde/iCalendar.php:376 /usr/share/php5/PEAR/Horde/Kolab/Resource.php:290 /usr/share/php5/PEAR/Horde/Kolab/Resource.php:451 /usr/share/php5/PEAR/Horde/Kolab/Filter/Incoming.php:141 /usr/share/php5/PEAR/Horde/Kolab/Filter/Base.php:132 /usr/share/php5/PEAR/Horde/Kolab/Test/Filter.php:259 /usr/share/php5/PEAR/test/Kolab_Filter/Horde/Kolab/Filter/ResourceTest.php:78 /usr/share/php5/PEAR/test/Kolab_Filter/Horde/Kolab/Filter/AllTests.php:36 /usr/share/php5/PEAR/test/Kolab_Filter/Horde/Kolab/Filter/AllTests.php:63 2) testLongStringInvitation(Horde_Kolab_Filter_ResourceTest) Only variable references should be returned by reference /usr/share/php5/PEAR/Horde/iCalendar.php:376 /usr/share/php5/PEAR/Horde/Kolab/Resource.php:290 /usr/share/php5/PEAR/Horde/Kolab/Resource.php:451 /usr/share/php5/PEAR/Horde/Kolab/Filter/Incoming.php:141 /usr/share/php5/PEAR/Horde/Kolab/Filter/Base.php:132 /usr/share/php5/PEAR/Horde/Kolab/Test/Filter.php:259 /usr/share/php5/PEAR/test/Kolab_Filter/Horde/Kolab/Filter/ResourceTest.php:108 /usr/share/php5/PEAR/test/Kolab_Filter/Horde/Kolab/Filter/AllTests.php:36 /usr/share/php5/PEAR/test/Kolab_Filter/Horde/Kolab/Filter/AllTests.php:63 The method that is called at line 78 and 108 in ReSourceTest.php is sendFixture. I assume that this method uses a method that is available in both /srv/www/htdocs/horde/lib and /usr/share/php5/PEAR (e.g. Horde/Util), but that one of them is different.... Which is a pity. Is there an easy way to determine which methods are used (function trace)? More about my horde installation below. I would assume that the preferred include_path is (as all kolab-* packages store their files in /usr/share/php5/PEAR): ".:/usr/share/php5:/usr/share/php5/PEAR:/srv/www/htdocs/horde/lib" while I now must specify: ".:/usr/share/php5:/srv/www/htdocs/horde/lib:/usr/share/php5/PEAR" to make sure that the above mentioned tests do not fail.... > > What I would like to know is the following: are the following files > > that are provided by the big horde package: > > Horde/Kolab.php > > Horde/Kolab/Storage/IMAP/cclient.php > > Horde/Kolab/Storage/IMAP/pear.php > > Horde/Kolab/Storage/IMAP.php > > Horde/Kolab/Storage/IMAP/test.php > > Horde/Kolab/Storage/Session.php > > used at the moment? ?They are not available via http://pear.horde.org > > AFAIC determine. ?IOW is it okay to drop them from the big horde > > package? > > The IMAP library was moved from Kolab_Storage to Kolab_Server. So the ? > paths need to be Horde/Kolab/Server/IMAP/... This is provided within ? > the Kolab_Server package from pear.horde.org. okay. I removed Horde/Kolab completely from my horde rpm. > Looks like you are using the unpatched horde-webmail-1.2.0 release. ? > This is plain Horde though and not the Kolab web client. It will not ? > be compatible with the Kolab server. I use the kolab-packages that you distribute via pear.horde.org. Further do I only use horde for the kolab-server. I have not started yet to work on the horde-webclient. Is a patched horde-webclient also needed for the kolab- server (that is not using horde-webclient)? -- Richard From wrobel at pardus.de Sun Mar 1 22:16:36 2009 From: wrobel at pardus.de (Gunnar Wrobel) Date: Sun, 01 Mar 2009 22:16:36 +0100 Subject: [Kolab-devel] php failure undefined method Horde_Kolab_Server_ldap::uidForIdOrMail (openSUSE native) In-Reply-To: <200903011408.30165.ml@radoeka.nl> References: <200902152132.47148.ml@radoeka.nl> <20090225090214.GA26295@xs4all.nl> <20090225121316.18070vbdg0u0i66o@webmail.pardus.de> <200903011408.30165.ml@radoeka.nl> Message-ID: <20090301221636.55421tos3h87nzok@webmail.pardus.de> Quoting Richard Bos : > Hi Gunnar, > > Op woensdag 25 februari 2009 12:13:16 schreef Gunnar Wrobel: >> > which is not so bad ;) >> >> In my eyes this is very, very bad ;) >> >> You don't link stuff from an installed web application into the >> system libraries. This is not okay. > > I have changed the rpm now, so the horde/lib is added to the include_path in > php.ini during rpm installation. This works but.... > /srv/www/htdocs/horde/lib > must come before: /usr/share/php5/PEAR. If the latter is placed before the > /srv/www/htdocs/horde/lib some the tests fail with: > > = /usr/share/php5/PEAR/test/Kolab_Filter/Horde/Kolab/Filter/AllTests.php = > > 1) testRecurrenceInvitation(Horde_Kolab_Filter_ResourceTest) > Only variable references should be returned by reference > /usr/share/php5/PEAR/Horde/iCalendar.php:376 > /usr/share/php5/PEAR/Horde/Kolab/Resource.php:290 > /usr/share/php5/PEAR/Horde/Kolab/Resource.php:451 > /usr/share/php5/PEAR/Horde/Kolab/Filter/Incoming.php:141 > /usr/share/php5/PEAR/Horde/Kolab/Filter/Base.php:132 > /usr/share/php5/PEAR/Horde/Kolab/Test/Filter.php:259 > /usr/share/php5/PEAR/test/Kolab_Filter/Horde/Kolab/Filter/ResourceTest.php:78 > /usr/share/php5/PEAR/test/Kolab_Filter/Horde/Kolab/Filter/AllTests.php:36 > /usr/share/php5/PEAR/test/Kolab_Filter/Horde/Kolab/Filter/AllTests.php:63 > > 2) testLongStringInvitation(Horde_Kolab_Filter_ResourceTest) > Only variable references should be returned by reference > /usr/share/php5/PEAR/Horde/iCalendar.php:376 > /usr/share/php5/PEAR/Horde/Kolab/Resource.php:290 > /usr/share/php5/PEAR/Horde/Kolab/Resource.php:451 > /usr/share/php5/PEAR/Horde/Kolab/Filter/Incoming.php:141 > /usr/share/php5/PEAR/Horde/Kolab/Filter/Base.php:132 > /usr/share/php5/PEAR/Horde/Kolab/Test/Filter.php:259 > /usr/share/php5/PEAR/test/Kolab_Filter/Horde/Kolab/Filter/ResourceTest.php:108 > /usr/share/php5/PEAR/test/Kolab_Filter/Horde/Kolab/Filter/AllTests.php:36 > /usr/share/php5/PEAR/test/Kolab_Filter/Horde/Kolab/Filter/AllTests.php:63 > > The method that is called at line 78 and 108 in ReSourceTest.php is > sendFixture. I assume that this method uses a method that is available in > both /srv/www/htdocs/horde/lib and /usr/share/php5/PEAR (e.g. Horde/Util), > but that one of them is different.... Which is a pity. Is there an easy way > to determine which methods are used (function trace)? More about my horde > installation below. > > I would assume that the preferred include_path is (as all kolab-* packages > store their files in /usr/share/php5/PEAR): > ".:/usr/share/php5:/usr/share/php5/PEAR:/srv/www/htdocs/horde/lib" > while I now must specify: > ".:/usr/share/php5:/srv/www/htdocs/horde/lib:/usr/share/php5/PEAR" > to make sure that the above mentioned tests do not fail.... The correct path for Kolab_FreeBusy and Kolab_Filter should only be /usr/share/php5 That is all. For the Kolab web client it should be sufficient to use: /srv/www/htdocs/horde/lib:/srv/www/htdocs/horde/pear The web client brings all the require dependencies it needs within "lib" and "pear". > > >> > What I would like to know is the following: are the following files >> > that are provided by the big horde package: >> > Horde/Kolab.php >> > Horde/Kolab/Storage/IMAP/cclient.php >> > Horde/Kolab/Storage/IMAP/pear.php >> > Horde/Kolab/Storage/IMAP.php >> > Horde/Kolab/Storage/IMAP/test.php >> > Horde/Kolab/Storage/Session.php >> > used at the moment? They are not available via http://pear.horde.org >> > AFAIC determine. IOW is it okay to drop them from the big horde >> > package? >> >> The IMAP library was moved from Kolab_Storage to Kolab_Server. So >> the paths need to be Horde/Kolab/Server/IMAP/... This is provided >> within the Kolab_Server package from pear.horde.org. > > okay. I removed Horde/Kolab completely from my horde rpm. > >> Looks like you are using the unpatched horde-webmail-1.2.0 release. >> This is plain Horde though and not the Kolab web client. It will >> not be compatible with the Kolab server. > > I use the kolab-packages that you distribute via pear.horde.org. > Further do I > only use horde for the kolab-server. I have not started yet to work on the > horde-webclient. Is a patched horde-webclient also needed for the kolab- > server (that is not using horde-webclient)? No. The patched horde is not needed for the Kolab server to work. But an unpatched horde will not work with the Kolab server. Cheers, Gunnar > > -- > Richard > > _______________________________________________ > Kolab-devel mailing list > Kolab-devel at kolab.org > https://kolab.org/mailman/listinfo/kolab-devel > -- ______ http://kdab.com _______________ http://kolab-konsortium.com _ p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium ____ http://www.pardus.de _________________ http://gunnarwrobel.de _ E-mail : p at rdus.de Dr. Gunnar Wrobel Tel. : +49 700 6245 0000 Bundesstrasse 29 Fax : +49 721 1513 52322 D-20146 Hamburg -------------------------------------------------------------------- >> Mail at ease - Rent a kolab groupware server at p at rdus << -------------------------------------------------------------------- ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digitale PGP-Unterschrift Url : http://kolab.org/pipermail/kolab-devel/attachments/20090301/b9158ec1/attachment.bin From wrobel at pardus.de Sun Mar 1 22:26:00 2009 From: wrobel at pardus.de (Gunnar Wrobel) Date: Sun, 01 Mar 2009 22:26:00 +0100 Subject: [Kolab-devel] Adding features to kolab2.schema In-Reply-To: <200902270902.38223.bernhard@intevation.de> References: <200902261250.47814.martin.konold@erfrakon.de> <200902270902.38223.bernhard@intevation.de> Message-ID: <20090301222600.493021xgn7jcattw@webmail.pardus.de> Quoting Bernhard Reiter : > Am Donnerstag, 26. Februar 2009 12:50:46 schrieb Martin Konold: >> In general I would like to hear your opinion about the proposed change. > > There is a notion when dealing with data privacy and this is that > forms should > be as simple as possible. The problem with many empty slots is that there are > some sort of people that will try to fill all values in. So an empty slot > for dateOfBirth, placeOfBirth and birthName will create entries in there in > some case. Companies might get in trouble filling this data in germany. > Some organisations need this like the citizen registration of the > muncipality. > So I guess I am looking for the use case for some of the values. > This is at least an argument against some of the values. > > Also they would clutter of the screen in web-admin. I guess one would not necessarily need to add full support to the web admin immediately. The web admin does not need to be as rigid as it is now about the user data. If it would behave a little bit more like Turba from Horde does it would be easy for a sys-admin to define the attributes he actually wants to support. So the web admin would only display these. For that it would be good to have the basic schema so that admins can rig their system to their needs without much hassle. This might also make the current global address book more valuable. Cheers, Gunnar > >> Especially I would like to know if you think that the added complexity of >> seperating legal person (like a company or a foundation) from a natural >> person (individual) is worthwile? >> >> (I have my doubts because mail for a company is not so much different from >> mail for an individual) > > Ideally someone would want define relationships between objects, like > users A,B,D are a member of company X and can be reached at subsidery M. > I guess that many directory services are not up to this yet, they seem to be > focussed on digital identities. Given that many companies do have a major > email and street address, keeping one entry for both seems fine to me. > > For billing purposes I would propose a folder with "contact" objects > in Kolab. > Still those do not represent the relationships I have mentioned above. > > Best, > Bernhard > > > -- > Managing Director - Owner: www.intevation.net (Free Software Company) > Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com. > Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 > Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner > -- ______ http://kdab.com _______________ http://kolab-konsortium.com _ p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium ____ http://www.pardus.de _________________ http://gunnarwrobel.de _ E-mail : p at rdus.de Dr. Gunnar Wrobel Tel. : +49 700 6245 0000 Bundesstrasse 29 Fax : +49 721 1513 52322 D-20146 Hamburg -------------------------------------------------------------------- >> Mail at ease - Rent a kolab groupware server at p at rdus << -------------------------------------------------------------------- ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digitale PGP-Unterschrift Url : http://kolab.org/pipermail/kolab-devel/attachments/20090301/8eec791c/attachment.bin From ml at radoeka.nl Sun Mar 1 23:08:38 2009 From: ml at radoeka.nl (Richard Bos) Date: Sun, 1 Mar 2009 23:08:38 +0100 Subject: [Kolab-devel] php failure undefined method Horde_Kolab_Server_ldap::uidForIdOrMail (openSUSE native) In-Reply-To: <20090301221636.55421tos3h87nzok@webmail.pardus.de> References: <200902152132.47148.ml@radoeka.nl> <200903011408.30165.ml@radoeka.nl> <20090301221636.55421tos3h87nzok@webmail.pardus.de> Message-ID: <200903012308.40483.ml@radoeka.nl> Hi Gunnar, Op zondag 01 maart 2009 22:16:36 schreef Gunnar Wrobel: > Quoting Richard Bos : > > Hi Gunnar, > > > > Op woensdag 25 februari 2009 12:13:16 schreef Gunnar Wrobel: > >> > which is not so bad ;) > >> > >> In my eyes this is very, very bad ;) > >> > >> You don't link stuff from an installed web application into the ? > >> system ?libraries. This is not okay. > > > > I have changed the rpm now, so the horde/lib is added to the include_path > > in php.ini during rpm installation. ?This works but.... > > /srv/www/htdocs/horde/lib > > must come before: /usr/share/php5/PEAR. ?If the latter is placed before > > the /srv/www/htdocs/horde/lib some the tests fail with: > > > > = /usr/share/php5/PEAR/test/Kolab_Filter/Horde/Kolab/Filter/AllTests.php > > = > > > > 1) testRecurrenceInvitation(Horde_Kolab_Filter_ResourceTest) > > Only variable references should be returned by reference > > /usr/share/php5/PEAR/Horde/iCalendar.php:376 > > /usr/share/php5/PEAR/Horde/Kolab/Resource.php:290 > > /usr/share/php5/PEAR/Horde/Kolab/Resource.php:451 > > /usr/share/php5/PEAR/Horde/Kolab/Filter/Incoming.php:141 > > /usr/share/php5/PEAR/Horde/Kolab/Filter/Base.php:132 > > /usr/share/php5/PEAR/Horde/Kolab/Test/Filter.php:259 > > /usr/share/php5/PEAR/test/Kolab_Filter/Horde/Kolab/Filter/ResourceTest.ph > >p:78 > > /usr/share/php5/PEAR/test/Kolab_Filter/Horde/Kolab/Filter/AllTests.php:36 > > /usr/share/php5/PEAR/test/Kolab_Filter/Horde/Kolab/Filter/AllTests.php:63 > > > > 2) testLongStringInvitation(Horde_Kolab_Filter_ResourceTest) > > Only variable references should be returned by reference > > /usr/share/php5/PEAR/Horde/iCalendar.php:376 > > /usr/share/php5/PEAR/Horde/Kolab/Resource.php:290 > > /usr/share/php5/PEAR/Horde/Kolab/Resource.php:451 > > /usr/share/php5/PEAR/Horde/Kolab/Filter/Incoming.php:141 > > /usr/share/php5/PEAR/Horde/Kolab/Filter/Base.php:132 > > /usr/share/php5/PEAR/Horde/Kolab/Test/Filter.php:259 > > /usr/share/php5/PEAR/test/Kolab_Filter/Horde/Kolab/Filter/ResourceTest.ph > >p:108 > > /usr/share/php5/PEAR/test/Kolab_Filter/Horde/Kolab/Filter/AllTests.php:36 > > /usr/share/php5/PEAR/test/Kolab_Filter/Horde/Kolab/Filter/AllTests.php:63 > > > > The method that is called at line 78 and 108 in ReSourceTest.php is > > sendFixture. ?I assume that this method uses a method that is available > > in both ?/srv/www/htdocs/horde/lib and /usr/share/php5/PEAR (e.g. > > Horde/Util), but that one of them is different.... ?Which is a pity. ?Is > > there an easy way to determine which methods are used (function trace)? > > ?More about my horde installation below. > > > > I would assume that the preferred include_path is (as all kolab-* > > packages store their files in /usr/share/php5/PEAR): > > ?".:/usr/share/php5:/usr/share/php5/PEAR:/srv/www/htdocs/horde/lib" > > while I now must specify: > > ?".:/usr/share/php5:/srv/www/htdocs/horde/lib:/usr/share/php5/PEAR" > > to make sure that the above mentioned tests do not fail.... > > The correct path for Kolab_FreeBusy and Kolab_Filter should only be > > /usr/share/php5 > > That is all. > > For the Kolab web client it should be sufficient to use: > > /srv/www/htdocs/horde/lib:/srv/www/htdocs/horde/pear > > The web client brings all the require dependencies it needs within ? > "lib" and "pear". Thanks for the info. The directory /srv/www/htdocs/horde/pear is not present at my system yet, as I don't have horde-webclient installed (to be done). We install kolab-filter, freebusy, and the others in /usr/share/php5/PEAR as they are pear based. It shouldn't matter much whether they are installed in /usr/share/php5/PEAR or /usr/share/php5 as you do. I checked for the files that are installed /usr/share/php5/PEAR and /srv/www/htdocs/horde/lib. The files in /usr/share/php5/PEAR are installed from pear.horde.org, the ones installed in /srv/www/htdocs/horde/lib are provided by the horde-3.3.3 tarball. Both contain the same files, and if I compare them the ones coming from pear.horde.org (installed in /usr/share/php5/PEAR) are just way behind of the ones provided by horde-3.3.3 tarball. It's probably the same issue as: https://www.intevation.de/roundup/kolab/issue3293 (Big code duplication and code version messup: Horde libs in 2.2.1). Hence I need the following include path: /srv/www/htdocs/horde/lib:/usr/share/php5/PEAR (indeed that one works) > >> Looks like you are using the unpatched horde-webmail-1.2.0 release. ? > >> ?This is plain Horde though and not the Kolab web client. It will ? > >> not ?be compatible with the Kolab server. > > > > I use the kolab-packages that you distribute via pear.horde.org. ? > > Further do I > > only use horde for the kolab-server. ?I have not started yet to work on > > the horde-webclient. ?Is a patched horde-webclient also needed for the > > kolab- server (that is not using horde-webclient)? > > No. The patched horde is not needed for the Kolab server to work. > > But an unpatched horde will not work with the Kolab server. The last 2 sentences are contradicting. I assume that you refer to the horde- webclient in the last sentence isn't it => "But an unpatched horde-webclient will not work with the Kolab server" -- Richard From itsef-admin at brightsight.com Mon Mar 2 10:03:03 2009 From: itsef-admin at brightsight.com (ITSEF Admin) Date: Mon, 2 Mar 2009 10:03:03 +0100 Subject: [Kolab-devel] New Kontact e35 version in apt "testing"! In-Reply-To: <200902270854.55594.bernhard@intevation.de> References: <200902261258.29754.bernhard@intevation.de> <200902261516.06278.itsef-admin@brightsight.com> <200902270854.55594.bernhard@intevation.de> Message-ID: <200903021003.03318.itsef-admin@brightsight.com> Bernhard, On Friday 27 February 2009 08:54:55 Bernhard Reiter wrote: > Am Donnerstag, 26. Februar 2009 15:16:06 schrieb ITSEF Admin: [...] > > I've been building (K)ubuntu 8.04 packages from the "unstable" packages > > for quite some time now for our users. [...] > > in the mid term we hope to set up a mill for building ubuntu packages > as well, all we need is a maintainer for the packaging of this version. > Thomas, you are a likely candidate to help us here, aren't you? >;) Now, who didn't see that one coming? :-} I'd say, once you're far enough, contact me off-list and we can discuss this. I doubt I'll be able to support anything but Kubuntu 8.04 until well after Kubuntu 9.10 has been released, but we'll cross that bridge when we get to it. I'd be interested in the plans for KDE4, anyway, at some point... > As a packager you would want to start once "unstable" has a new version > ideally right now. Yup, which is exactly what I'm doing - not least because usually, there are fixes in there that help us. > > The difference between "unstable" and "testing" is still not quite clear > > to me - "testing" seems to have seen even more testing, but what exactly? > > A number of people directly install from the "unstable" respository. So it > is about one week of real usage for at least 10 users. > > experimental -> unstable: basic test, change test and better than before > unstable -> testing: real usage for at least a week > > I am still considering when to move to stable. Maybe after another week > given at least about three independent feedbacks that nothing has krept up. Hm - so far, I've never been in that loop, i.e. I never reported back unless something went wrong. Am I right in assuming that "positive" reports would also be helpful for you? In that case I'll try and keep an eye on what comes back from our users after I pushed the latest unstable out here. Regards, Thomas From martin.konold at erfrakon.de Mon Mar 2 10:51:50 2009 From: martin.konold at erfrakon.de (Martin Konold) Date: Mon, 2 Mar 2009 10:51:50 +0100 Subject: [Kolab-devel] Adding features to kolab2.schema In-Reply-To: <20090301222600.493021xgn7jcattw@webmail.pardus.de> References: <200902261250.47814.martin.konold@erfrakon.de> <200902270902.38223.bernhard@intevation.de> <20090301222600.493021xgn7jcattw@webmail.pardus.de> Message-ID: <200903021051.51063.martin.konold@erfrakon.de> Am Sonntag, 1. M?rz 2009 22:26:00 schrieb Gunnar Wrobel: Hi, > If it would behave a little bit more like ? > Turba from Horde does it would be easy for a sys-admin to define the ? > attributes he actually wants to support. So the web admin would only ? > display these. Actually my vision for the future (Kolab 3.x) is that the domain maintainer can define a "template user" for each domain. This templates is then defines preselected values and also (implicitly?) defines which attributes are actually made available in the web admin GUI. The later shall be a subset of those attributes which are available as defined by the schema and the access control lists. Yours, -- martin -- e r f r a k o n Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker Sitz: Adolfstra?e 23, 70469 Stuttgart, Partnerschaftsregister Stuttgart PR 126 http://www.erfrakon.com/ From wrobel at pardus.de Mon Mar 2 10:57:27 2009 From: wrobel at pardus.de (Gunnar Wrobel) Date: Mon, 02 Mar 2009 10:57:27 +0100 Subject: [Kolab-devel] Adding features to kolab2.schema In-Reply-To: <200903021051.51063.martin.konold@erfrakon.de> References: <200902261250.47814.martin.konold@erfrakon.de> <200902270902.38223.bernhard@intevation.de> <20090301222600.493021xgn7jcattw@webmail.pardus.de> <200903021051.51063.martin.konold@erfrakon.de> Message-ID: <20090302105727.87696n4vidg3wd4w@webmail.pardus.de> Quoting Martin Konold : > Am Sonntag, 1. M?rz 2009 22:26:00 schrieb Gunnar Wrobel: > > Hi, > >> If it would behave a little bit more like Turba from Horde does it >> would be easy for a sys-admin to define the attributes he actually >> wants to support. So the web admin would only display these. > > Actually my vision for the future (Kolab 3.x) is that the domain maintainer > can define a "template user" for each domain. This templates is then defines > preselected values and also (implicitly?) defines which attributes are > actually made available in the web admin GUI. Makes sense and would not be very hard if the web admin would support flexible attributes in general. Cheers, Gunnar > > The later shall be a subset of those attributes which are available > as defined > by the schema and the access control lists. > > Yours, > -- martin > > -- > e r f r a k o n > Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker > Sitz: Adolfstra?e 23, 70469 Stuttgart, Partnerschaftsregister > Stuttgart PR 126 > http://www.erfrakon.com/ > > _______________________________________________ > Kolab-devel mailing list > Kolab-devel at kolab.org > https://kolab.org/mailman/listinfo/kolab-devel > -- ______ http://kdab.com _______________ http://kolab-konsortium.com _ p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium ____ http://www.pardus.de _________________ http://gunnarwrobel.de _ E-mail : p at rdus.de Dr. Gunnar Wrobel Tel. : +49 700 6245 0000 Bundesstrasse 29 Fax : +49 721 1513 52322 D-20146 Hamburg -------------------------------------------------------------------- >> Mail at ease - Rent a kolab groupware server at p at rdus << -------------------------------------------------------------------- ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digitale PGP-Unterschrift Url : http://kolab.org/pipermail/kolab-devel/attachments/20090302/13abc6e8/attachment.bin From wrobel at pardus.de Mon Mar 2 11:06:54 2009 From: wrobel at pardus.de (Gunnar Wrobel) Date: Mon, 02 Mar 2009 11:06:54 +0100 Subject: [Kolab-devel] php failure undefined method Horde_Kolab_Server_ldap::uidForIdOrMail (openSUSE native) In-Reply-To: <200903012308.40483.ml@radoeka.nl> References: <200902152132.47148.ml@radoeka.nl> <200903011408.30165.ml@radoeka.nl> <20090301221636.55421tos3h87nzok@webmail.pardus.de> <200903012308.40483.ml@radoeka.nl> Message-ID: <20090302110654.55435vc1jrlp1uxw@webmail.pardus.de> Hi Richard, Quoting Richard Bos : > Hi Gunnar, > > Op zondag 01 maart 2009 22:16:36 schreef Gunnar Wrobel: >> Quoting Richard Bos : >> > Hi Gunnar, >> > >> > Op woensdag 25 februari 2009 12:13:16 schreef Gunnar Wrobel: >> >> > which is not so bad ;) >> >> >> >> In my eyes this is very, very bad ;) >> >> >> >> You don't link stuff from an installed web application into the >> >> system libraries. This is not okay. >> > >> > I have changed the rpm now, so the horde/lib is added to the include_path >> > in php.ini during rpm installation. This works but.... >> > /srv/www/htdocs/horde/lib >> > must come before: /usr/share/php5/PEAR. If the latter is placed before >> > the /srv/www/htdocs/horde/lib some the tests fail with: >> > >> > = /usr/share/php5/PEAR/test/Kolab_Filter/Horde/Kolab/Filter/AllTests.php >> > = >> > >> > 1) testRecurrenceInvitation(Horde_Kolab_Filter_ResourceTest) >> > Only variable references should be returned by reference >> > /usr/share/php5/PEAR/Horde/iCalendar.php:376 >> > /usr/share/php5/PEAR/Horde/Kolab/Resource.php:290 >> > /usr/share/php5/PEAR/Horde/Kolab/Resource.php:451 >> > /usr/share/php5/PEAR/Horde/Kolab/Filter/Incoming.php:141 >> > /usr/share/php5/PEAR/Horde/Kolab/Filter/Base.php:132 >> > /usr/share/php5/PEAR/Horde/Kolab/Test/Filter.php:259 >> > /usr/share/php5/PEAR/test/Kolab_Filter/Horde/Kolab/Filter/ResourceTest.ph >> >p:78 >> > /usr/share/php5/PEAR/test/Kolab_Filter/Horde/Kolab/Filter/AllTests.php:36 >> > /usr/share/php5/PEAR/test/Kolab_Filter/Horde/Kolab/Filter/AllTests.php:63 >> > >> > 2) testLongStringInvitation(Horde_Kolab_Filter_ResourceTest) >> > Only variable references should be returned by reference >> > /usr/share/php5/PEAR/Horde/iCalendar.php:376 >> > /usr/share/php5/PEAR/Horde/Kolab/Resource.php:290 >> > /usr/share/php5/PEAR/Horde/Kolab/Resource.php:451 >> > /usr/share/php5/PEAR/Horde/Kolab/Filter/Incoming.php:141 >> > /usr/share/php5/PEAR/Horde/Kolab/Filter/Base.php:132 >> > /usr/share/php5/PEAR/Horde/Kolab/Test/Filter.php:259 >> > /usr/share/php5/PEAR/test/Kolab_Filter/Horde/Kolab/Filter/ResourceTest.ph >> >p:108 >> > /usr/share/php5/PEAR/test/Kolab_Filter/Horde/Kolab/Filter/AllTests.php:36 >> > /usr/share/php5/PEAR/test/Kolab_Filter/Horde/Kolab/Filter/AllTests.php:63 >> > >> > The method that is called at line 78 and 108 in ReSourceTest.php is >> > sendFixture. I assume that this method uses a method that is available >> > in both /srv/www/htdocs/horde/lib and /usr/share/php5/PEAR (e.g. >> > Horde/Util), but that one of them is different.... Which is a pity. Is >> > there an easy way to determine which methods are used (function trace)? >> > More about my horde installation below. >> > >> > I would assume that the preferred include_path is (as all kolab-* >> > packages store their files in /usr/share/php5/PEAR): >> > ".:/usr/share/php5:/usr/share/php5/PEAR:/srv/www/htdocs/horde/lib" >> > while I now must specify: >> > ".:/usr/share/php5:/srv/www/htdocs/horde/lib:/usr/share/php5/PEAR" >> > to make sure that the above mentioned tests do not fail.... >> >> The correct path for Kolab_FreeBusy and Kolab_Filter should only be >> >> /usr/share/php5 >> >> That is all. >> >> For the Kolab web client it should be sufficient to use: >> >> /srv/www/htdocs/horde/lib:/srv/www/htdocs/horde/pear >> >> The web client brings all the require dependencies it needs within >> "lib" and "pear". > > Thanks for the info. The directory /srv/www/htdocs/horde/pear is not present > at my system yet, as I don't have horde-webclient installed (to be done). We > install kolab-filter, freebusy, and the others in > /usr/share/php5/PEAR as they > are pear based. It shouldn't matter much whether they are installed in > /usr/share/php5/PEAR or /usr/share/php5 as you do. This is true but it can get confusing if you install the same packages in /usr/share/php5 and /usr/share/php5/PEAR. Which is essentially the problem I create with the current kolab-webclient installation as it brings PEAR packages that may already be installed on the system. A decent installation would install each package only once. I have my reasons why I did it that way (a lot of it based on the upstream release policy) but I'm unhappy about it, too. > > I checked for the files that are installed /usr/share/php5/PEAR and > /srv/www/htdocs/horde/lib. The files in /usr/share/php5/PEAR are installed > from pear.horde.org, the ones installed in /srv/www/htdocs/horde/lib are > provided by the horde-3.3.3 tarball. Both contain the same files, and if I > compare them the ones coming from pear.horde.org (installed in > /usr/share/php5/PEAR) are just way behind of the ones provided by horde-3.3.3 > tarball. It's probably the same issue as: > https://www.intevation.de/roundup/kolab/issue3293 (Big code duplication and > code version messup: Horde libs in 2.2.1). Hence I need the > following include > path: > /srv/www/htdocs/horde/lib:/usr/share/php5/PEAR > (indeed that one works) Mixing the horde-3.3.3 release with the PEAR packages from pear.horde.org will not work. It is as simple as that ;) Horde-3.3.3 will also have many bugs when run against a Kolab server. You are on your own there. Cheers, Gunnar > >> >> Looks like you are using the unpatched horde-webmail-1.2.0 >> release. >> This is plain Horde though and not the Kolab web >> client. It will >> not be compatible with the Kolab server. >> > >> > I use the kolab-packages that you distribute via pear.horde.org. >> > Further do I >> > only use horde for the kolab-server. I have not started yet to work on >> > the horde-webclient. Is a patched horde-webclient also needed for the >> > kolab- server (that is not using horde-webclient)? >> >> No. The patched horde is not needed for the Kolab server to work. >> >> But an unpatched horde will not work with the Kolab server. > > The last 2 sentences are contradicting. I assume that you refer to > the horde- > webclient in the last sentence isn't it => > "But an unpatched horde-webclient will not work with the Kolab server" > > -- > Richard > > _______________________________________________ > Kolab-devel mailing list > Kolab-devel at kolab.org > https://kolab.org/mailman/listinfo/kolab-devel > -- ______ http://kdab.com _______________ http://kolab-konsortium.com _ p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium ____ http://www.pardus.de _________________ http://gunnarwrobel.de _ E-mail : p at rdus.de Dr. Gunnar Wrobel Tel. : +49 700 6245 0000 Bundesstrasse 29 Fax : +49 721 1513 52322 D-20146 Hamburg -------------------------------------------------------------------- >> Mail at ease - Rent a kolab groupware server at p at rdus << -------------------------------------------------------------------- ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digitale PGP-Unterschrift Url : http://kolab.org/pipermail/kolab-devel/attachments/20090302/bdf741dc/attachment.bin From bernhard at intevation.de Mon Mar 2 12:53:17 2009 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 2 Mar 2009 12:53:17 +0100 Subject: [Kolab-devel] Adding features to kolab2.schema In-Reply-To: <20090301222600.493021xgn7jcattw@webmail.pardus.de> References: <200902261250.47814.martin.konold@erfrakon.de> <200902270902.38223.bernhard@intevation.de> <20090301222600.493021xgn7jcattw@webmail.pardus.de> Message-ID: <200903021253.18195.bernhard@intevation.de> Am Sonntag, 1. M?rz 2009 22:26:00 schrieb Gunnar Wrobel: > > Also they would clutter of the screen in web-admin. > > I guess one would not necessarily need to add full support to the web ? > admin immediately. The web admin does not need to be as rigid as it is ? > now about the user data. If it would behave a little bit more like ? > Turba from Horde does it would be easy for a sys-admin to define the ? > attributes he actually wants to support. So the web admin would only ? > display these. I thought the idea was that the webadmin would be flexible some day to just show which attributes are there in the schema, thus being more an ldap tool. However this might not be within reach, so doing a template approach this cluttering up problem would be gone. -- Managing Director - Owner: www.intevation.net (Free Software Company) Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com. Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. Url : http://kolab.org/pipermail/kolab-devel/attachments/20090302/bb4825e0/attachment.bin From bernhard at intevation.de Mon Mar 2 12:56:36 2009 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 2 Mar 2009 12:56:36 +0100 Subject: [Kolab-devel] New Kontact e35 version in apt "testing"! In-Reply-To: <200903021003.03318.itsef-admin@brightsight.com> References: <200902261258.29754.bernhard@intevation.de> <200902270854.55594.bernhard@intevation.de> <200903021003.03318.itsef-admin@brightsight.com> Message-ID: <200903021256.36577.bernhard@intevation.de> Am Montag, 2. M?rz 2009 10:03:03 schrieb ITSEF Admin: > > in the mid term we hope to set up a mill for building ubuntu packages > > as well, all we need is a maintainer for the packaging of this version. > > Thomas, you are a likely candidate to help us here, aren't you? >;) > > Now, who didn't see that one coming? :-} I'd say, once you're far enough, > contact me off-list and we can discuss this. I doubt I'll be able to > support anything but Kubuntu 8.04 until well after Kubuntu 9.10 has been > released, but we'll cross that bridge when we get to it. Thanks for the offer, I think Bernhard (Herzog) will at some point set things up in an SCM somewhere and you'll get access. > I'd be interested in the plans for KDE4, anyway, at some point... In what respect? E4 is there for Lenny, as you've probably noticed in the saegewerk. It is in beta. So unless you have Windows or Mac, you better go with e35. > > I am still considering when to move to stable. Maybe after another week > > given at least about three independent feedbacks that nothing has krept > > up. > > Hm - so far, I've never been in that loop, i.e. I never reported back > unless something went wrong. Am I right in assuming that "positive" reports > would also be helpful for you? In that case I'll try and keep an eye on > what comes back from our users after I pushed the latest unstable out here. Yes, positive reports would be very cool. Just send a message like: Moved to version X with Y people for Z days and all is fine. ;) Bernhard -- Managing Director - Owner: www.intevation.net (Free Software Company) Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com. Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. Url : http://kolab.org/pipermail/kolab-devel/attachments/20090302/d5675238/attachment.bin From itsef-admin at brightsight.com Mon Mar 2 16:35:50 2009 From: itsef-admin at brightsight.com (itsef-admin@brightsight.com) Date: Mon, 02 Mar 2009 16:35:50 +0100 Subject: [Kolab-devel] New Kontact e35 version in apt "testing"! In-Reply-To: <200903021256.36577.bernhard@intevation.de> References: <200902261258.29754.bernhard@intevation.de> <200902270854.55594.bernhard@intevation.de> <200903021003.03318.itsef-admin@brightsight.com> <200903021256.36577.bernhard@intevation.de> Message-ID: <20090302163550.18815iesmyqmvy80@gerrit.brightsight.com> Quoting Bernhard Reiter : [Supporting e35 packages for Kubuntu 8.04] > Thanks for the offer, I think Bernhard (Herzog) will at some point set things > up in an SCM somewhere and you'll get access. Grand. >> I'd be interested in the plans for KDE4, anyway, at some point... > > In what respect? > E4 is there for Lenny, as you've probably noticed in the saegewerk. > It is in beta. So unless you have Windows or Mac, you better go with e35. Well, I justed wanted to clarify (as I haven't spent much time on this at all so far): For anything KDE4 based (e.g. Kubuntu 8.10 and onward), e4 *will* be the way to go, right? How long will e35 be supported, then? As I said, it's unlikely we move on before well into Kubuntu 9.10, as I really want KDE4 to stabilise before I touch it anywhere else than on testmachines (never mind having to re-educate users about the new interface... ). I haven't looked at e4 yet - I take it that at least *that* interface won't change as much? :-} [...] > Yes, positive reports would be very cool. > Just send a message like: Moved to version X with Y people for Z days > and all is fine. ;) Grand, will do. Whereto, actually? Cheerio, Thomas From wrobel at pardus.de Mon Mar 2 20:31:17 2009 From: wrobel at pardus.de (Gunnar Wrobel) Date: Mon, 02 Mar 2009 20:31:17 +0100 Subject: [Kolab-devel] Adding features to kolab2.schema In-Reply-To: <200903021253.18195.bernhard@intevation.de> References: <200902261250.47814.martin.konold@erfrakon.de> <200902270902.38223.bernhard@intevation.de> <20090301222600.493021xgn7jcattw@webmail.pardus.de> <200903021253.18195.bernhard@intevation.de> Message-ID: <20090302203117.14393lz60h5adjwg@webmail.pardus.de> Quoting Bernhard Reiter : > Am Sonntag, 1. M?rz 2009 22:26:00 schrieb Gunnar Wrobel: >> > Also they would clutter of the screen in web-admin. >> >> I guess one would not necessarily need to add full support to the >> web admin immediately. The web admin does not need to be as rigid >> as it is now about the user data. If it would behave a little bit >> more like Turba from Horde does it would be easy for a sys-admin >> to define the attributes he actually wants to support. So the web >> admin would only display these. > > I thought the idea was that the webadmin would be flexible some day to just > show which attributes are there in the schema, thus being more an ldap tool. > However this might not be within reach, so doing a template approach this > cluttering up problem would be gone. Ah, right. As far as I know Turba even has some Schema parsing possibilities (based on PEAR::Net_LDAP2). I should keep that in mind if I ever tackle that... hopefully soon. Cheers, Gunnar > > -- > Managing Director - Owner: www.intevation.net (Free Software Company) > Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com. > Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 > Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner > -- ______ http://kdab.com _______________ http://kolab-konsortium.com _ p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium ____ http://www.pardus.de _________________ http://gunnarwrobel.de _ E-mail : p at rdus.de Dr. Gunnar Wrobel Tel. : +49 700 6245 0000 Bundesstrasse 29 Fax : +49 721 1513 52322 D-20146 Hamburg -------------------------------------------------------------------- >> Mail at ease - Rent a kolab groupware server at p at rdus << -------------------------------------------------------------------- ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digitale PGP-Unterschrift Url : http://kolab.org/pipermail/kolab-devel/attachments/20090302/709bcd28/attachment.bin From ml at radoeka.nl Mon Mar 2 21:46:59 2009 From: ml at radoeka.nl (Richard Bos) Date: Mon, 2 Mar 2009 21:46:59 +0100 Subject: [Kolab-devel] php failure undefined method Horde_Kolab_Server_ldap::uidForIdOrMail (openSUSE native) In-Reply-To: <20090302110654.55435vc1jrlp1uxw@webmail.pardus.de> References: <200902152132.47148.ml@radoeka.nl> <200903012308.40483.ml@radoeka.nl> <20090302110654.55435vc1jrlp1uxw@webmail.pardus.de> Message-ID: <200903022147.00632.ml@radoeka.nl> Hi Gunnar, Op maandag 02 maart 2009 11:06:54 schreef Gunnar Wrobel: > >> The correct path for Kolab_FreeBusy and Kolab_Filter should only be > >> > >> /usr/share/php5 > >> > >> That is all. > >> > >> For the Kolab web client it should be sufficient to use: > >> > >> /srv/www/htdocs/horde/lib:/srv/www/htdocs/horde/pear > >> > >> The web client brings all the require dependencies it needs within ? > >> "lib" and "pear". > > > > Thanks for the info. ?The directory /srv/www/htdocs/horde/pear is not > > present at my system yet, as I don't have horde-webclient installed (to > > be done). ?We install kolab-filter, freebusy, and the others in > > /usr/share/php5/PEAR as they > > are pear based. ?It shouldn't matter much whether they are installed in > > /usr/share/php5/PEAR or /usr/share/php5 as you do. > > This is true but it can get confusing if you install the same packages ? > in /usr/share/php5 and /usr/share/php5/PEAR. Which is essentially the ? > problem I create with the current kolab-webclient installation as it ? > brings PEAR packages that may already be installed on the system. > > A decent installation would install each package only once. I have my ? > reasons why I did it that way (a lot of it based on the upstream ? > release policy) but I'm unhappy about it, too. Ah, I'm starting to get it.... I just removed the all in one horde package / rpm (but not the webclient) and executed some tests. It kept on working, but there is one test failing (extra) that I reported before (see below). That particular test works when the big all in one horde package is installed... > > I checked for the files that are installed /usr/share/php5/PEAR and > > /srv/www/htdocs/horde/lib. ?The files in /usr/share/php5/PEAR are > > installed from pear.horde.org, the ones installed in > > /srv/www/htdocs/horde/lib are provided by the horde-3.3.3 tarball. ?Both > > contain the same files, and if I compare them the ones coming from > > pear.horde.org (installed in > > /usr/share/php5/PEAR) are just way behind of the ones provided by > > horde-3.3.3 tarball. ?It's probably the same issue as: > > https://www.intevation.de/roundup/kolab/issue3293 (Big code duplication > > and code version messup: Horde libs in 2.2.1). ?Hence I need the > > following include > > path: > > ? ?/srv/www/htdocs/horde/lib:/usr/share/php5/PEAR > > (indeed that one works) > > Mixing the horde-3.3.3 release with the PEAR packages from ? > pear.horde.org will not work. It is as simple as that ;) Horde-3.3.3 ? > will also have many bugs when run against a Kolab server. You are on ? > your own there. It's not that I want horde-3.3.3 on my system, I'm just trying to figure out what is needed to get kolab running. I believe that I now start to get it :) Do you have an idea what needs to be done to get the failing tests shown below working? = /usr/share/php5/PEAR/test/Kolab_Filter/Horde/Kolab/Filter/AllTests.php = PHPUnit 3.3.15 by Sebastian Bergmann. ...................EE Time: 2 seconds There were 2 errors: 1) testRecurrenceInvitation(Horde_Kolab_Filter_ResourceTest) Only variable references should be returned by reference /usr/share/php5/PEAR/Horde/iCalendar.php:376 /usr/share/php5/PEAR/Horde/Kolab/Resource.php:290 /usr/share/php5/PEAR/Horde/Kolab/Resource.php:451 /usr/share/php5/PEAR/Horde/Kolab/Filter/Incoming.php:141 /usr/share/php5/PEAR/Horde/Kolab/Filter/Base.php:132 /usr/share/php5/PEAR/Horde/Kolab/Test/Filter.php:259 /usr/share/php5/PEAR/test/Kolab_Filter/Horde/Kolab/Filter/ResourceTest.php:78 /usr/share/php5/PEAR/test/Kolab_Filter/Horde/Kolab/Filter/AllTests.php:36 /usr/share/php5/PEAR/test/Kolab_Filter/Horde/Kolab/Filter/AllTests.php:63 2) testLongStringInvitation(Horde_Kolab_Filter_ResourceTest) Only variable references should be returned by reference /usr/share/php5/PEAR/Horde/iCalendar.php:376 /usr/share/php5/PEAR/Horde/Kolab/Resource.php:290 /usr/share/php5/PEAR/Horde/Kolab/Resource.php:451 /usr/share/php5/PEAR/Horde/Kolab/Filter/Incoming.php:141 /usr/share/php5/PEAR/Horde/Kolab/Filter/Base.php:132 /usr/share/php5/PEAR/Horde/Kolab/Test/Filter.php:259 /usr/share/php5/PEAR/test/Kolab_Filter/Horde/Kolab/Filter/ResourceTest.php:108 /usr/share/php5/PEAR/test/Kolab_Filter/Horde/Kolab/Filter/AllTests.php:36 /usr/share/php5/PEAR/test/Kolab_Filter/Horde/Kolab/Filter/AllTests.php:63 FAILURES! Tests: 21, Assertions: 38, Errors: 2. -- Richard From wrobel at pardus.de Tue Mar 3 07:52:07 2009 From: wrobel at pardus.de (Gunnar Wrobel) Date: Tue, 03 Mar 2009 07:52:07 +0100 Subject: [Kolab-devel] php failure undefined method Horde_Kolab_Server_ldap::uidForIdOrMail (openSUSE native) In-Reply-To: <200903022147.00632.ml@radoeka.nl> References: <200902152132.47148.ml@radoeka.nl> <200903012308.40483.ml@radoeka.nl> <20090302110654.55435vc1jrlp1uxw@webmail.pardus.de> <200903022147.00632.ml@radoeka.nl> Message-ID: <20090303075207.789953u51b2f14g8@webmail.pardus.de> Quoting Richard Bos : > Hi Gunnar, > > Op maandag 02 maart 2009 11:06:54 schreef Gunnar Wrobel: >> >> The correct path for Kolab_FreeBusy and Kolab_Filter should only be >> >> >> >> /usr/share/php5 >> >> >> >> That is all. >> >> >> >> For the Kolab web client it should be sufficient to use: >> >> >> >> /srv/www/htdocs/horde/lib:/srv/www/htdocs/horde/pear >> >> >> >> The web client brings all the require dependencies it needs >> within >> "lib" and "pear". >> > >> > Thanks for the info. The directory /srv/www/htdocs/horde/pear is not >> > present at my system yet, as I don't have horde-webclient installed (to >> > be done). We install kolab-filter, freebusy, and the others in >> > /usr/share/php5/PEAR as they >> > are pear based. It shouldn't matter much whether they are installed in >> > /usr/share/php5/PEAR or /usr/share/php5 as you do. >> >> This is true but it can get confusing if you install the same >> packages in /usr/share/php5 and /usr/share/php5/PEAR. Which is >> essentially the problem I create with the current kolab-webclient >> installation as it brings PEAR packages that may already be >> installed on the system. >> >> A decent installation would install each package only once. I have >> my reasons why I did it that way (a lot of it based on the >> upstream release policy) but I'm unhappy about it, too. > > Ah, I'm starting to get it.... I just removed the all in one horde package / > rpm (but not the webclient) and executed some tests. It kept on working, but > there is one test failing (extra) that I reported before (see below). That > particular test works when the big all in one horde package is installed... > > >> > I checked for the files that are installed /usr/share/php5/PEAR and >> > /srv/www/htdocs/horde/lib. The files in /usr/share/php5/PEAR are >> > installed from pear.horde.org, the ones installed in >> > /srv/www/htdocs/horde/lib are provided by the horde-3.3.3 tarball. Both >> > contain the same files, and if I compare them the ones coming from >> > pear.horde.org (installed in >> > /usr/share/php5/PEAR) are just way behind of the ones provided by >> > horde-3.3.3 tarball. It's probably the same issue as: >> > https://www.intevation.de/roundup/kolab/issue3293 (Big code duplication >> > and code version messup: Horde libs in 2.2.1). Hence I need the >> > following include >> > path: >> > /srv/www/htdocs/horde/lib:/usr/share/php5/PEAR >> > (indeed that one works) >> >> Mixing the horde-3.3.3 release with the PEAR packages from >> pear.horde.org will not work. It is as simple as that ;) >> Horde-3.3.3 will also have many bugs when run against a Kolab >> server. You are on your own there. > > It's not that I want horde-3.3.3 on my system, I'm just trying to figure out > what is needed to get kolab running. I believe that I now start to get it :) > Do you have an idea what needs to be done to get the failing tests > shown below > working? You installed the wrong iCalendar library. You need the newest package (Version 0.1.0): http://pear.horde.org/index.php?package=iCalendar From the error below I'm unable to determine which version you might have used. The line numbering seems off (Though I have a vague idea where your test might be failing). In any case you must upgrade to the newest version. If you incorrect library versions in there that might create interesting problems ;) You should check again against the versions in the specs you find in Kolab CVS. Cheers, Gunnar > > = /usr/share/php5/PEAR/test/Kolab_Filter/Horde/Kolab/Filter/AllTests.php = > PHPUnit 3.3.15 by Sebastian Bergmann. > > ...................EE > > Time: 2 seconds > > There were 2 errors: > > 1) testRecurrenceInvitation(Horde_Kolab_Filter_ResourceTest) > Only variable references should be returned by reference > /usr/share/php5/PEAR/Horde/iCalendar.php:376 > /usr/share/php5/PEAR/Horde/Kolab/Resource.php:290 > /usr/share/php5/PEAR/Horde/Kolab/Resource.php:451 > /usr/share/php5/PEAR/Horde/Kolab/Filter/Incoming.php:141 > /usr/share/php5/PEAR/Horde/Kolab/Filter/Base.php:132 > /usr/share/php5/PEAR/Horde/Kolab/Test/Filter.php:259 > /usr/share/php5/PEAR/test/Kolab_Filter/Horde/Kolab/Filter/ResourceTest.php:78 > /usr/share/php5/PEAR/test/Kolab_Filter/Horde/Kolab/Filter/AllTests.php:36 > /usr/share/php5/PEAR/test/Kolab_Filter/Horde/Kolab/Filter/AllTests.php:63 > > 2) testLongStringInvitation(Horde_Kolab_Filter_ResourceTest) > Only variable references should be returned by reference > /usr/share/php5/PEAR/Horde/iCalendar.php:376 > /usr/share/php5/PEAR/Horde/Kolab/Resource.php:290 > /usr/share/php5/PEAR/Horde/Kolab/Resource.php:451 > /usr/share/php5/PEAR/Horde/Kolab/Filter/Incoming.php:141 > /usr/share/php5/PEAR/Horde/Kolab/Filter/Base.php:132 > /usr/share/php5/PEAR/Horde/Kolab/Test/Filter.php:259 > /usr/share/php5/PEAR/test/Kolab_Filter/Horde/Kolab/Filter/ResourceTest.php:108 > /usr/share/php5/PEAR/test/Kolab_Filter/Horde/Kolab/Filter/AllTests.php:36 > /usr/share/php5/PEAR/test/Kolab_Filter/Horde/Kolab/Filter/AllTests.php:63 > > FAILURES! > Tests: 21, Assertions: 38, Errors: 2. > > > -- > Richard > > _______________________________________________ > Kolab-devel mailing list > Kolab-devel at kolab.org > https://kolab.org/mailman/listinfo/kolab-devel > -- ______ http://kdab.com _______________ http://kolab-konsortium.com _ p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium ____ http://www.pardus.de _________________ http://gunnarwrobel.de _ E-mail : p at rdus.de Dr. Gunnar Wrobel Tel. : +49 700 6245 0000 Bundesstrasse 29 Fax : +49 721 1513 52322 D-20146 Hamburg -------------------------------------------------------------------- >> Mail at ease - Rent a kolab groupware server at p at rdus << -------------------------------------------------------------------- ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digitale PGP-Unterschrift Url : http://kolab.org/pipermail/kolab-devel/attachments/20090303/dd6ed3af/attachment-0001.bin From bernhard at intevation.de Tue Mar 3 09:00:18 2009 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 3 Mar 2009 09:00:18 +0100 Subject: [Kolab-devel] Kontact e4 and e35 (was: New Kontact e35 version in apt "testing"!) In-Reply-To: <20090302163550.18815iesmyqmvy80@gerrit.brightsight.com> References: <200902261258.29754.bernhard@intevation.de> <200903021256.36577.bernhard@intevation.de> <20090302163550.18815iesmyqmvy80@gerrit.brightsight.com> Message-ID: <200903030900.18683.bernhard@intevation.de> Am Montag, 2. M?rz 2009 16:35:50 schrieb itsef-admin at brightsight.com: > > E4 is there for Lenny, as you've probably noticed in the saegewerk. > > It is in beta. So unless you have Windows or Mac, you better go with e35. > > Well, I justed wanted to clarify (as I haven't spent much time on this ? > at all so far): For anything KDE4 based (e.g. Kubuntu 8.10 and ? > onward), e4 *will* be the way to go, right? Correct. > How long will e35 be supported, then? We expect it to be about 2 years. This can be even longer, it depends on somebody doing the work. Currently maintenance is mainly funded by KK over paying customers. So as long as customers pay for it, KK will support it. > As I said, it's unlikely we move on before well into ? > Kubuntu 9.10, as I really want KDE4 to stabilise before I touch it ? > anywhere else than on testmachines (never mind having to re-educate ? > users about the new interface... ). I haven't looked at e4 yet - ? > I take it that at least *that* interface won't change as much? :-} e4 is quite close to e35 from the usage point of view. Form the technology side it is all Qt4 and KDE4 under the hood and some more goodies. > > Yes, positive reports would be very cool. > > Just send a message like: Moved to version X with Y people for Z days > > and all is fine. ;) > > Grand, will do. Whereto, actually? kolab-devel@ or kolab-users@ are good places. It depends on your level of feedback I would say. If you are a regular reader on kolab-devel@ I would prefer this list. Best, Bernhard -- Managing Director - Owner: www.intevation.net (Free Software Company) Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com. Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. Url : http://kolab.org/pipermail/kolab-devel/attachments/20090303/3bbb6ae5/attachment.bin From bernhard at intevation.de Tue Mar 3 09:11:43 2009 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 3 Mar 2009 09:11:43 +0100 Subject: [Kolab-devel] Segfault on webclient ! (Solved) In-Reply-To: <49ABEF28.7060300@dah.am> References: <49AAEBD1.6070208@dah.am> <200903021510.47952.bernhard@intevation.de> <49ABEF28.7060300@dah.am> Message-ID: <200903030911.46996.bernhard@intevation.de> Franz, Am Montag, 2. M?rz 2009 15:37:28 schrieb Franz Skale: > Sorry for the misleading lines. no problem, I thought you were having another question about "syncKolab addresses" which I was trying to answer. Now back to your problem on Debian 64bit: > I don't know why ld wants to include the debian libdb-4.6 since > apache-php will be build with db-4.5. > So in my strace the last line was /usr/lib/libdb-4.6.so which is the > debian lib and then came the sagfault. > So i did this temporary workaround (32Bit seems not to have this > problem, anybody out there with the same problem on debian lenny > /32/64 bit ?) I've tried to replicate kolab/issue2982 (OpenLDAP segmentation fault on 64bit) for two weeks and did not see the crash. It might not be related. > What i have done: (Not to interfere debian deps to libdb3-dev on lenny > i build it from source) > 1.) cd /usr/src > apt-get source libdb4-5 > 2.) cd /usr/src/db4.5-4.5.20 > 3.) commented out java things from debian/rules. (Are not relevant to > kolab). > 4.) debian/rules build > 5.) After build complete: > cd dist/ > DESTDIR=/tmp/db-4.5 make install > 6.) mkdir /kolab/RPM/SRC/apache-php > 7.) cd /kolab/RPM/SRC/apache-php > 8.) rpm2cpio /kolab/RPM/PKG/rpm2cpio > /kolab.new/RPM/PKG/apache-php-5.2.8-20081209_kolab.src.rpm |cpio -id > 9.) chown root.root * > 10) edited the php.spec > Changed the db-4.5 line to: > ? ? ?--with-db4=/tmp/db-4.5/usr > 11.) rpmbuild -ba php.spec > 12.) Installed the ned package: > rpm -Uhv --force /kolab/RPM/PKG/apache-php-5.2.9-20090228.amd64-kolab.rpm > 13.) apache will be restarted. > > Config Options for apache-php: > > # ? package options > %option ? ? ? ? with_bdb ? ? ? ? ? ? ? ?yes > %option ? ? ? ? with_ctype ? ? ? ? ? ? ?yes > %option ? ? ? ? with_dom ? ? ? ? ? ? ? ?yes > %option ? ? ? ? with_gd ? ? ? ? ? ? ? ? yes > %option ? ? ? ? with_gettext ? ? ? ? ? ?yes > %option ? ? ? ? with_iconv ? ? ? ? ? ? ?yes > %option ? ? ? ? with_imap ? ? ? ? ? ? ? yes > %option ? ? ? ? with_imap_annotate ? ? ?yes > %option ? ? ? ? with_imap_myrights ? ? ?yes > %option ? ? ? ? with_mbregex ? ? ? ? ? ?yes > %option ? ? ? ? with_mbstring ? ? ? ? ? yes > %option ? ? ? ? with_mcrypt ? ? ? ? ? ? yes > %option ? ? ? ? with_mhash ? ? ? ? ? ? ?yes > %option ? ? ? ? with_mm ? ? ? ? ? ? ? ? yes > %option ? ? ? ? with_openldap ? ? ? ? ? yes > %option ? ? ? ? with_pear ? ? ? ? ? ? ? yes > %option ? ? ? ? with_sqlite ? ? ? ? ? ? yes > %option ? ? ? ? with_ssl ? ? ? ? ? ? ? ?yes > %option ? ? ? ? with_xml ? ? ? ? ? ? ? ?yes > %option ? ? ? ? with_zlib ? ? ? ? ? ? ? yes > > The debian version on db-4.5 does have some x86_64 patches. > The kolab source version for db-4.5 seems to lack from thread support. Hmm, this would be an issue for the OpenPKG guys I guess, but I also think we should explore along these lines. > The Linker SEARCH_DIR was right but why the linker wanted to include > db-4.6 seems to be a miracle. > There is a open thread on the debian list that apt-listchanges is > requesting db4-.5 but 4-6 is debian default. > I think problem could lead to the kolab build problem. > Anyway, now it is working and anyone have troubles with it, can > contact me via the maillinlist. > Please revise my temp solution and then i could post it in the wiki as > you told me. Your descriptions looks nice to me, I'd say you should put a link to your archived post in the wiki right now. ;) Thanks, Bernhard -- Managing Director - Owner: www.intevation.net (Free Software Company) Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com. Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. Url : http://kolab.org/pipermail/kolab-devel/attachments/20090303/13444408/attachment.bin From kolab-issues at intevation.de Tue Mar 3 09:23:51 2009 From: kolab-issues at intevation.de (Thomas Ribbrock) Date: Tue, 03 Mar 2009 08:23:51 +0000 Subject: [Kolab-devel] [issue3448] Enabling Sieve filters in Horde causes Kontact to think "Vacation Message" is on Message-ID: <1236068631.79.0.35247991866.issue3448@intevation.de> New submission from Thomas Ribbrock : Horde client that comes with Kolab 2.2.0 vs. Kontact 922263: If I enable mail filters in the Horde client, then later start Kontact again, Kontact comes back with a message that an "Out of the office reply" is still active and offers to edit/disable it. Unfortunately, it does not display the actual filters then, but only the vacation message dialogue. If a user then disables the vacations message, the complete set of filters set up with Horde is wiped, which is quite annoying. I suppose a possible workaround is to disable Sieve in Kontact and teach all users to use Horde only for filtering, but even then, this should be clearly documented in both Horde and Kontact, as the current situation is confusing for users. ---------- messages: 18846 nosy: itsef_admin priority: bug status: unread title: Enabling Sieve filters in Horde causes Kontact to think "Vacation Message" is on topic: enterprise35, web client ___________________________________________________ Kolab issue tracker ___________________________________________________ From ml at radoeka.nl Tue Mar 3 23:00:05 2009 From: ml at radoeka.nl (Richard Bos) Date: Tue, 3 Mar 2009 23:00:05 +0100 Subject: [Kolab-devel] =?iso-8859-15?q?php_failure_undefined_method=09Hord?= =?iso-8859-15?q?e=5FKolab=5FServer=5Fldap=3A=3AuidForIdOrMail_=28openSUSE?= =?iso-8859-15?q?_native=29?= In-Reply-To: <20090303075207.789953u51b2f14g8@webmail.pardus.de> References: <200902152132.47148.ml@radoeka.nl> <200903022147.00632.ml@radoeka.nl> <20090303075207.789953u51b2f14g8@webmail.pardus.de> Message-ID: <200903032300.07413.ml@radoeka.nl> Hello Gunnar! Op dinsdag 03 maart 2009 07:52:07 schreef Gunnar Wrobel: > > It's not that I want horde-3.3.3 on my system, I'm just trying to figure > > out what is needed to get kolab running. ?I believe that I now start to > > get it :) Do you have an idea what needs to be done to get the failing > > tests shown below > > working? > > You installed the wrong iCalendar library. You need the newest package ? > (Version 0.1.0): > > http://pear.horde.org/index.php?package=iCalendar Right in the bull, well done. That was because I choose to use Horde_iCalendar, which has version 0.0.3. With version 0.1.0 (iCalendar) all is fine, without your pointer (the url above) I would probable not have found the right version. > ?From the error below I'm unable to determine which version you might ? > have used. The line numbering seems off (Though I have a vague idea ? > where your test might be failing). In any case you must upgrade to the ? > newest version. I did, with the good result, see above :) > If you incorrect library versions in there that might create ? > interesting problems ;) You should check again against the versions in ? > the specs you find in Kolab CVS. I did. I now found the spec files in cvs. I did not find them before, I use now the same versions as you (openpkg) do. -- Richard From ml at radoeka.nl Tue Mar 3 23:13:52 2009 From: ml at radoeka.nl (Richard Bos) Date: Tue, 3 Mar 2009 23:13:52 +0100 Subject: [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 In-Reply-To: <20090303162509.E591960094A@lists.intevation.de> References: <20090303162509.E591960094A@lists.intevation.de> Message-ID: <200903032313.53126.ml@radoeka.nl> Hi, Op dinsdag 03 maart 2009 17:25:09 schreef cvs at kolab.org: > ???????* issue3192.patch, issue3441.patch, Kolab_Filter.spec, Makefile: Add > +???????patches for kolab/issue3192 (Forwarding an invitation with Outlook > +???????failed) and kolab/issue3441 (Resources with policy "always accept" > +??????do not work if domain != kolabhost) and bump release number. I hope you don't mind if I ask: - 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? Why are the patches applied against the rpms, and not upstream (no offence, just curious)? -- Richard [1] http://kolab.org/cgi-bin/viewcvs-kolab.cgi/server/php-kolab/Kolab_Filter/ [2] http://kolab.org/cgi-bin/viewcvs-kolab.cgi/server/php- kolab/Kolab_Freebusy/ From thomas at intevation.de Wed Mar 4 10:09:41 2009 From: thomas at intevation.de (Thomas Arendsen Hein) Date: Wed, 4 Mar 2009 10:09:41 +0100 Subject: [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 In-Reply-To: <200903032313.53126.ml@radoeka.nl> References: <20090303162509.E591960094A@lists.intevation.de> <200903032313.53126.ml@radoeka.nl> Message-ID: <20090304090941.GC31167.thomas@intevation.de> * Richard Bos [20090303 23:14]: > Op dinsdag 03 maart 2009 17:25:09 schreef cvs at kolab.org: > > ???????* issue3192.patch, issue3441.patch, Kolab_Filter.spec, Makefile: Add > > +???????patches for kolab/issue3192 (Forwarding an invitation with Outlook > > +???????failed) and kolab/issue3441 (Resources with policy "always accept" > > +??????do not work if domain != kolabhost) and bump release number. > > I hope you don't mind if I ask: Of course not :) > - 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). > 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. 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. 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. -- thomas at intevation.de - http://intevation.de/~thomas/ - OpenPGP key: 0x5816791A Intevation GmbH, Neuer Graben 17, 49074 Osnabrueck - AG Osnabrueck, HR B 18998 Geschaeftsfuehrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From ml at radoeka.nl Wed Mar 4 23:51:01 2009 From: ml at radoeka.nl (Richard Bos) Date: Wed, 4 Mar 2009 23:51:01 +0100 Subject: [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 In-Reply-To: <20090304090941.GC31167.thomas@intevation.de> References: <20090303162509.E591960094A@lists.intevation.de> <200903032313.53126.ml@radoeka.nl> <20090304090941.GC31167.thomas@intevation.de> Message-ID: <200903042351.03145.ml@radoeka.nl> 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 From wrobel at pardus.de Thu Mar 5 08:34:40 2009 From: wrobel at pardus.de (Gunnar Wrobel) Date: Thu, 05 Mar 2009 08:34:40 +0100 Subject: [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 In-Reply-To: <200903042351.03145.ml@radoeka.nl> References: <20090303162509.E591960094A@lists.intevation.de> <200903032313.53126.ml@radoeka.nl> <20090304090941.GC31167.thomas@intevation.de> <200903042351.03145.ml@radoeka.nl> Message-ID: <20090305083440.983147v436ezkb68@webmail.pardus.de> Quoting 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. As mentioned before I hope to be able to add tests soon that check a real, configured server. This should again help to improve native installs (as well as giving us some simple checks when preparing the next release). > > 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? The webclient is fully self contained. It does not need anything in /usr/share/php5 or /usr/share/php5/pear. It solely needs the PEAR packages within the "lib" directory and the "pear" directory. As long as you have an apache server and php5 patched for Kolab you can install it and need nothing else. This approach has its advantages and disadvantages. You can simply take the package and install it anywhere. You can also easily migrate the whole package from one location to another. The main reason why I chose to use the horde-webmail package - which comes with this type of arrangement - as base for the kolab web client was that the package is well separated from the rest of Kolab and can also be easily installed on an external server. On the other hand you get this dreadful code duplication which is pretty bad from a technical perspective. So I'll slightly change the installation of the web client after Kolab server 2.2.1 so that we get the best of both worlds. > > >> > 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. I'll work on getting the patches upstream today. Concerning the PHP code of the Kolab server you can always count on getting the latest code from horde.org. At least as long as the code is under my control :) Having stuff upstream is very important to me as I do get all the infrastructure for decent source releases there which we don't have (or didn't establish) on kolab.org. As this is relevant for supporting the native installations I want to keep it that way. Of course this is problematic for Thomas when he wants to release the next Kolab server version and needs a hotfix for something. Currently I just lacked the time to polish the patches for upstream inclusion but for situations where we have just a single bugfix on a package I might not always immediately release a new version upstream. Cheers, Gunnar > >> 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..... For everyone interested the link to my current repository https://github.com/wrobel The stuff is not documented (yet). "horde-release" is the Kolab web client development. "horde-fw3" is the branch that is considered stable at the moment. "horde" is the Horde git HEAD branch that will become Horde 4 "horde-cvs" is the Horde CVS HEAD branch that will get deprecated once everything moved to git "horde-hatchery" is the experimental Horde area in git For bleeding edge Kolab related stuff: - Branch "t/KOLAB" within "horde-release" is the newest Kolab web client - "horde" will see the Kolab_* PEAR packages rewritten for PHP5 soon. Currently you can watch me restructuring and preparing Kolab_Server for Horde 4 there. - "horde-hatchery" will see a new Kolab web admin based on Horde 4 soon. Cheers, Gunnar > > -- > Richard > > _______________________________________________ > Kolab-devel mailing list > Kolab-devel at kolab.org > https://kolab.org/mailman/listinfo/kolab-devel > -- ______ http://kdab.com _______________ http://kolab-konsortium.com _ p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium ____ http://www.pardus.de _________________ http://gunnarwrobel.de _ E-mail : p at rdus.de Dr. Gunnar Wrobel Tel. : +49 700 6245 0000 Bundesstrasse 29 Fax : +49 721 1513 52322 D-20146 Hamburg -------------------------------------------------------------------- >> Mail at ease - Rent a kolab groupware server at p at rdus << -------------------------------------------------------------------- ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digitale PGP-Unterschrift Url : http://kolab.org/pipermail/kolab-devel/attachments/20090305/7fd331ae/attachment.bin From thomas at intevation.de Thu Mar 5 17:26:47 2009 From: thomas at intevation.de (Thomas Arendsen Hein) Date: Thu, 5 Mar 2009 17:26:47 +0100 Subject: [Kolab-devel] Kolab Server 2.2.1 Release Candidate 1 Message-ID: <20090305162647.GA1490.thomas@intevation.de> Hi! I just uploaded Kolab Server 2.2.1-rc1 which contains about 60 enhancements and fixes compared to beta1. Please make sure to follow the upgrade instructions in 1st.README, especially if upgrading from server 2.2.0 or older. Again many thanks to all the people who helped with this! Documentation and OpenPKG source packages will soon be available in the directory server/beta/kolab-server-2.2.1-rc-1/ of the mirrors listed on http://kolab.org/mirrors.html for example: http://ftp.gwdg.de/pub/linux/kolab/server/beta/kolab-server-2.2.1-rc-1/ ftp://ftp.gwdg.de/pub/linux/kolab/server/beta/kolab-server-2.2.1-rc-1/ rsync://rsync.kolab.org/kolab/RSYNC.txt explains how to get (or mirror) the files via rsync. All files updated since 2.2.1-beta1 are available in the directory server/development-2.2/20090305-since-20081212/ You can check the integrity of the downloaded files with: $ gpg --keyserver hkp://subkeys.pgp.net --recv-key 5816791A or import the key from https://www.intevation.de/~thomas/gpg_pub_key.asc (the same key that I used to sign this email) $ gpg --verify SHA1SUMS.sig $ sha1sum -c SHA1SUMS Binary packages for Debian GNU/Linux (etch/stable) on x86 platforms can be found in the ix86-debian4.0 directory next to the sources. Please look at 1st.README and release-notes.txt (attached for your convenience) for install instructions and more information about this release. Please report any problems you encounter in our issue tracker: https://issues.kolab.org/ Regards, Thomas Arendsen Hein -- thomas at intevation.de - http://intevation.de/~thomas/ - OpenPGP key: 0x5816791A Intevation GmbH, Neuer Graben 17, 49074 Osnabrueck - AG Osnabrueck, HR B 18998 Geschaeftsfuehrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- Kolab Server 2.2 Install and Upgrade Information ================================================ (Version 20090305, Kolab Server 2.2.1-rc1 See http://kolab.org/ for general information about Kolab, or look at http://wiki.kolab.org/ for specific topics. It is recommended to subscribe to the announcement mailing list at http://kolab.org/mailman/listinfo/kolab-announce to receive security advisories and release announcements. Quick install instructions -------------------------- Kolab server and the Kolab web client (based on Horde) will use about 1GB of disk space for the initial install. By default the directory /kolab will be used, which should be an empty directory or a symbolic link to an empty directory. If this directory does not yet exist, it will be automatically created. For production use it is recommended to create a separate partition for /kolab (2GB to have some spare) and partitions for /kolab/var (at least 2GB for log files, virus filtering and caches) and /kolab/var/imapd/spool (with enough space for your users' mails). For evaluation you could start with the 2GB partition for /kolab (or 2GB free space on / if you only have one big partition for your test system) and create the other partitions when needed. Do _not_ use an NFS mounted drive! Make sure that the following names are not in /etc/passwd or /etc/groups, as OpenPKG will want to create them: "kolab" "kolab-r" "kolab-n" To install the Kolab server, you need to download the files from the directory containing this file (1st.README) to some local directory. You can check the integrity of the downloaded files with: $ gpg --keyserver hkp://subkeys.pgp.net --recv-key 5816791A or import the key from https://www.intevation.de/~thomas/gpg_pub_key.asc $ gpg --verify SHA1SUMS.sig $ sha1sum -c SHA1SUMS Then as root, cd into that local directory and run # sh install-kolab.sh 2>&1 | tee /root/kolab-install.log to build and install packages in /kolab. The command output will be logged to install-kolab.log so that you have a reference in case an error occurs during installation. The install script needs to store some files and creates a subdirectory below /tmp (or $TMPDIR if set) for this purpose. The web client might create much load on your server if there are many concurrent users, so you can choose to not install it by adding the option "-x kolab-webclient" to the call to install-kolab.sh. Installing the web client on a separate host is possible, but not discussed here. If you do not want to install the free/busy view tool, add the option "-x kolab-fbview". The binary packages distributed via kolab.org are compiled with the web client and the free/busy view tool. Currently you need to compile from the source packages to install without these features, see kolab/issue2440 for details. By default, the Kolab server will now be started at boottime, so you have to bootstrap the server configuration now to prevent unconfigured components from being started, see kolab/issue1745 for details. Please run: # /kolab/sbin/kolab_bootstrap -b and follow the instructions. Check http://www.openpkg.org/documentation/ for additional documentation about the OpenPKG packaging system. General update instructions --------------------------- Generally an update of the Kolab server works as described in this section, but often you will need to deviate from these instructions as described in the sections below. Please read the release specific update instructions for all releases newer than the one you already have before you start the update, e.g. for upgrading from 2.2.0 to 2.2.1-rc1 you have to follow the instructions for upgrading from 2.2.0 to 2.2.1-beta1, too. In any case you should completely read *all* relevant update instructions *before* starting the upgrade procedure. Always make sure you have a recent backup of your /kolab directory before you attempt the upgrade. The installation of the new packages works just as for the initial installation. Download the files as described above and run # sh install-kolab.sh 2>&1 | tee /root/kolab-update.log If you installed without kolab-webclient or kolab-fbview you need to add the corresponding -x options again. install-kolab.sh will usually automatically determine which packages need to be built. If you have made changes to configuration files or an updated package includes configuration files which are usually regenerated from files in /kolab/etc/kolab/templates/ the old configuration file will be saved with the extension .rpmsave. For files generated from templates you just have to remove the rpmsave file, because services will refuse to start if there still is an rpmsave file, e.g.: # rm /kolab/etc/clamav/*.conf.rpmsave For other changed files (e.g. the template files themselves) you may want to transfer your changes from the .rpmsave backup to the new files. Then regenerate the configuration and restart all Kolab services with: # /kolab/sbin/kolabconf -n # /kolab/bin/openpkg rc all restart Or alternatively if the Kolab server was stopped before the upgrade: # /kolab/bin/openpkg rc openldap start # /kolab/sbin/kolabconf -n # /kolab/bin/openpkg rc all start Upgrade from 2.2.1-beta1 to 2.2.1-rc1 ------------------------------------- Nothing special has to be done for this upgrade. Upgrade from 2.2.0 to 2.2.1-beta1 --------------------------------- 0. Make a backup of your installation and data stored inside /kolab 1. The Kolab server must be stopped: # /kolab/bin/openpkg rc all stop 2. Save the current LDAP data: Copy the contents of the openldap database, use a different output filename if you want. You should make sure that no other users can read the sensitive data contained in the ldif file, e.g. with umask (limited to the slapcat call by using parentheses): # (umask 077 && # /kolab/sbin/slapcat > ~/kolab-2.2.0.ldif) 3. Start the standard upgrade: (as described in the General update instructions) # sh install-kolab.sh 2>&1 | tee /root/kolab-update.log 4. /kolab/etc/kolab/kolab.conf will be saved as kolab.conf.rpmsave, please move it back to the original name: # cd /kolab/etc/kolab && mv kolab.conf.rpmsave kolab.conf 5. Look at *.conf.rpmsave files in the subdirectories of /kolab/etc/, transfer your changes and remove these files. (as described in the General update instructions) 6. Before starting the LDAP server the database must be restored from the ldif (with Horde preferences filtered out, since these are now stored in files): # rm /kolab/var/openldap/openldap-data/* # /kolab/bin/awk '!/^ / {ok=1;} /^objectClass: horde(Person|Group)$/ {ok=0;} /^([a-z]*Prefs|turba(Contact|Members|PGPPublicKey|Type)):/ {ok=0;} {if(ok) print;}' ~/kolab-2.2.0.ldif | /kolab/sbin/slapadd 7. Start the OpenLDAP, generate the configuration files and start the Kolab server: # /kolab/bin/openpkg rc openldap start # /kolab/sbin/kolabconf -n # /kolab/bin/openpkg rc all start Upgrade from 2.2-rc3 to 2.2.0 ----------------------------- Nothing special has to be done for this upgrade. Upgrade from 2.2-rc2 to 2.2-rc3 ------------------------------- You should regenerated the free/busy cache again, as described in the upgrading instructions from 2.2-rc1 to 2.2-rc2. The IMAP annotation /vendor/kolab/xfb-readable (introduced in 2.2-beta3) was renamed to /vendor/kolab/pxfb-readable-for to reflect the actual meaning. After the upgrade the old annotations are still readable, but unused by the server. If you still need to write this annotation for some reason, you have to add it to imapd.annotation_definitions.template and run kolabconf. Upgrade from 2.2-rc1 to 2.2-rc2 ------------------------------- You have to regenerated the free/busy cache, which now can be done automatically. First (optional, but recommended) step is to remove the current cache below /kolab/var/kolab-freebusy/cache: # su - kolab-n $ rm -r /kolab/var/kolab-freebusy/cache/* Now you can use the following command (still as user kolab-n): $ PHP_AUTH_USER=manager PHP_AUTH_PW='managerpassword' /kolab/bin/php \ -c /kolab/etc/apache/php.ini /kolab/var/kolab/www/freebusy/regenerate.php As this will show the manager's password on the command line, you can alternatively open https://yourserver.example.com/freebusy/regenerate.php in a web browser and login as "manager". This needs "Allow unauthenticated downloading of Free/Busy information" to be disabled, which is the default. Upgrade from 2.2-beta3 to 2.2-rc1 --------------------------------- Updating the free/busy cache has to be triggered for all calendar folders of all accounts: - Users need to create or update an appointment in their folders. - Resources can be invited to a new appointment or send them an update to an existing appointment. Upgrade from 2.2-beta2 to 2.2-beta3 ----------------------------------- After upgrading, you should remove the package "kolab-horde-framework", which is no longer needed: # /kolab/bin/openpkg rpm -e kolab-horde-framework Upgrade from 2.2-beta1 to 2.2-beta2 ----------------------------------- Before running install-kolab.sh, you should stop the running Kolab server and remove some packages which got renamed or will no longer be needed by running this command: # /kolab/bin/openpkg rc all stop # /kolab/bin/openpkg rpm -e --nodeps apache2 apache2-php getopt proftpd \ pth sharutils kolab-horde-fbview kolab-resource-handlers Ignore errors about pth or sharutils not being installed, these were included in the beta1 release but not installed by default. Upgrade from Kolab server 2.1 or before --------------------------------------- Instructions for upgrading from Kolab server 2.0 will be added in a future version of this document. These instructions are for upgrading from Kolab server 2.1.0 to 2.2.1: 0. Make a backup of your installation and data stored inside /kolab 1. Before upgrading the Kolab server must be stopped: # /kolab/bin/openpkg rc all stop 2. Save the current LDAP data: Copy the contents of the openldap database, use a different output filename if you want. You should make sure that no other users can read the sensitive data contained in the ldif file, e.g. with umask (limited to the slapcat call by using parentheses): # (umask 077 && /kolab/sbin/slapcat > ~/kolab-2.1.ldif) 3. Some of the old Kolab packages must be removed to avoid conflicts during the upgrade process: # /kolab/bin/openpkg rpm -e --nodeps \ kolabd kolab-webadmin kolab-horde-fbview kolab-horde-framework \ kolab-resource-handlers getopt patch proftpd sharutils 4. New versions of openpkg and openpkg-tools are needed for the upgrade, so you have to install them manually beforehand. As root, cd into the directory of kolab server 2.2 binary packages and run: # /kolab/bin/openpkg rpm -Uvh \ ./openpkg-20071227-20071227.--kolab.rpm # /kolab/bin/openpkg rpm -Uvh \ ./openpkg-tools-1.4.6-20071231.--kolab.rpm If you do not have binary packages for you platform, you have to build them from source first. As root, cd into the Kolab server 2.2 source directory and run: # /kolab/bin/openpkg rpm --rebuild ./openpkg-20071227-20071227.src.rpm # /kolab/bin/openpkg rpm -Uvh \ /kolab/RPM/PKG/openpkg-20071227-20071227.--kolab.rpm # /kolab/bin/openpkg rpm --rebuild ./openpkg-tools-1.4.6-20071231.src.rpm # /kolab/bin/openpkg rpm -Uvh \ /kolab/RPM/PKG/openpkg-tools-1.4.6-20071231.--kolab.rpm ( and must be replaced by the correct values for your system). 5. Start the standard upgrade (as described above): # sh install-kolab.sh 2>&1 | tee /root/kolab-update.log 6. Before starting the LDAP server the database must be restored from the ldif: # rm /kolab/var/openldap/openldap-data/* # /kolab/sbin/slapadd -l ~/kolab-2.1.ldif 7. The format of the TLS session cache changed, therefore you have to truncate it to zero length: # > /kolab/var/imapd/tls_sessions.db 8. /kolab/etc/kolab/kolab.conf will be saved as kolab.conf.rpmsave, please move it back to the original name. # cd /kolab/etc/kolab && mv kolab.conf.rpmsave kolab.conf 9. Remove all *.conf.rpmsave files in the subdirectories of /kolab/etc/ as described above. 10. Start the OpenLDAP, generate the configuration files and start the Kolab server: # /kolab/bin/openpkg rc openldap start # /kolab/sbin/kolabconf -n # /kolab/bin/openpkg rc all start 11. After the successful upgrade some cleanup can be done, by removing obsolete files/directories: # rm -r /kolab/etc/resmgr # rm -r /kolab/etc/proftpd # rm -r /kolab/var/kolab/www/freebusy/cache/* 12. The free/busy cache has to be regenerated for all calendar folders of all accounts, see "Upgrade from 2.2-rc1 to 2.2-rc2" in this file. Additional hints may be available in the Kolab wiki: http://wiki.kolab.org/index.php/Kolab2_Upgrading Direct upgrade from Kolab1 is not supported. We suggest that you back up your IMAP store, install Kolab2 and manually recreate user accounts and then restore the IMAP data from the backup. Known regressions compared to Kolab Server 2.2.0 ------------------------------------------------ The following issues affect the current prerelease, but are expected to be fixed for the final release: kolab/issue3438 (kolabFreeBusyPast is not used) Generating your own 00INDEX.rdf for installations or upgrades ------------------------------------------------------------- The source and binary downloads contain the 00INDEX.rdf file needed by the "openpkg build" command used by install-kolab.sh to install or upgrade a Kolab server. If you already have your own set of binary packages from a previous build, you can use these to create a full binary installer (e.g. to install the packages on a second machine) or or a partial binary installer (for upgrades where you only want to compile the new .src.rpm files instead of everything). To generate this file, you always need all .src.rpm files, so link or copy them in a new directory (needs to be writable by the kolab user of your installation). After this you can link/copy the install-kolab.sh file and your binary rpm files (e.g. from /kolab/RPM/PKG/) into this directory and run the following command as user kolab or root to create the new 00INDEX.rdf file: $ sh install-kolab.sh -X If you want a pure binary installer, you can remove the .src.rpm files now. To be able to use this directory for fresh installations (i.e. not only for upgrades), you need to put the OpenPKG bootstrap file (openpkg-*.src.sh or openpkg---kolab.rpm) into this directory, too. Index generation tries to cache information about source RPMs in the file /kolab/RPM/DB/00INDEX-cache.db, you might want to remove it to save some disk space or restore it after new installations to save some time. Known problems and workarounds ------------------------------ - Compiling openpkg-20071227-20071227 does not work with gcc 4.3, e.g. on Debian/lenny. As a workaround you can install the gcc-4.2 package, but you have to make sure that OpenPKG calls this version by passing the --use_cc option to it via the -O flag of install-kolab.sh, e.g.: # sh install-kolab.sh -O --use_cc=gcc-4.2 ... See kolab/issue2871 (openpkg-20071227-20071227 does not compile with gcc 4.3) for details. - Your system (C library) has to support all languages you want to have available in the web admin interface, the web client and fbview. For most languages you have to use the non-UTF-8 and non-euro locales, i.e. de_DE, fr_FR, it_IT, nl_NL instead of e.g. de_DE at euro. For fbview some languages need a UTF-8 locale, e.g. ja_JP.UTF-8 for Japanese. The web client needs UTF-8 locale in addition to the non-UTF-8 ones in some situations. So it's best to install all variants for every language which shall be supported. See kolab/issue2732 (Horde and Web Admin Interface Language Selection depends on OS locale support) for details. - If login on https://yourserver.example.com/fbview and triggering free/busy regeneration does not work, try as user kolab: /kolab/bin/php -r 'imap_open("{localhost:143/notls}", "" ,"");' If it yields "Segmentation fault (core dumped)", then there probably is a conflict between a dynamically loaded libdb3 from your system and a statically linked libdb4 from the OpenpPKG php package. If it yields a "PHP Warning: ...", this part of the system works correctly. One reason for such a conflict could be the mere presence of /lib/libnss_db.so.*, which is installed on some distributions by default. On Debian systems it is contained in the package "libnss-db". If you really need this library, you could work around the loading of libdb3 by placing a symbolic link with the correct name in /kolab/lib, e.g.: ldd /lib/libnss_db.so.2 libnss_files.so.2 => /lib/tls/libnss_files.so.2 (0xb7f16000) ---> libdb3.so.3 => /usr/lib/libdb3.so.3 (0xb7e6b000) libc.so.6 => /lib/tls/libc.so.6 (0xb7d36000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000) ln -s /dev/null /kolab/lib/libdb3.so.3 See kolab/issue1607 (need to replace gdbm for pfbcache, because of license clash gdbm vs php) for details. - /kolab/sbin/kolab_bootstrap -b fails to start the temporary slapd on Linux 2.4 kernels if binaries compiled on Linux 2.6 (as provided on kolab.org) are used. See kolab/issue1795 for details. - Under some circumstance the Kolab server may not create or delete users or update the configuration after changes have been made in the web interface. This happens most often immediately after the bootstrap. In that case restart the kolabd: /kolab/bin/openpkg rc kolabd restart If user accounts are still not created or deleted, you can try removing the file /kolab/var/kolab/mailbox-uidcache.db and restarting kolabd. See kolab/issue1068 (Mailboxes are not created until kolabd restart) and kolab/issue1098 (Changes in the service tab are not accepted after bootstrap) for details. - If modifying or deleting of address book entries doesn't work, restarting openldap can help, see kolab/issue854 for details. - There is a report that the manager can only see users in the primary domain, see kolab/issue1485. We can't reproduce this problem, please tell us if you can. - Calendar folders for group/resource accounts can't be created for domains which were added after bootstrap, i.e. via the web admin interface. See kolab/issue1313 for details. - When deleting domains via the web admin interface, the corresponding LDAP data and IMAP spool stay on the server and have to be deleted manually. See kolab/issue1571 and kolab/issue1576 for details. - A domain maintainer can not always edit the email aliases for a user, even if the user and the alias is in domains the domain maintainer has access to. See kolab/issue2825 for details. $Id: README.1st,v 1.109 2009/03/05 14:46:04 thomas Exp $ -------------- next part -------------- Kolab Server 2.2 Release Notes ============================== (Version 20090305, Kolab Server 2.2.1-rc1 For upgrading and installation instructions, please refer to the 1st.README file in the package directory. Differences between Kolab 2.1 and 2.2: - Upgrade of central Kolab server components The Apache server shipped with the Kolab server has been upgraded to Apache-2.2.*. At the same time the system was switched to PHP5. Postfix got upgraded to 2.4.* which removes the need for special Kolab patches which were integrated upstream. The Cyrus IMAP server was updated to 2.3.* also removing the need for some, though not all, Kolab specific patches. - Inclusion of the web based Horde Groupware client The Kolab server now provides a web client that supports all the groupware features known from Outlook and Kontact. Thus users are less dependent on their local client and can access their groupware data from anywhere in the world provided they have a standard browser available. - Structural improvements Several components of the Kolab server got restructured so that porting the Kolab server to distributions other than OpenPKG got easier. This also improves the development model in general. - Improvements, bugfixes and upgraded software components The 2.2 release received many improvements and bugfixes for issues found in earlier versions. Additionally all software components have been upgraded to new upstream versions. The specifics are described below. Changes between 2.2.1-beta-1 and 2.2.1-rc-1 - apache-php-5.2.8-20081209_kolab2 Updated Kolab server patches. - imapd-2.3.13-20081020_kolab1 kolab/issue3175 (Cyrus IMAPd 2.3.13 Released) - install-kolab.sh Fixed two problems reported by martin.schulte at guug.de: Repair option -E to not require an argument. Abort cleanly on -c or -X if no OpenPKG environment is found. Cache source RPM information in $PREFIX/RPM/DB/00INDEX-cache.db when generating 00INDEX.rdf - Horde_Notification-0.0.2-20090223 New package needed for running unit tests of Kolab PHP packages. - Horde_Prefs-0.0.3-20090223 New package needed for running unit tests of Kolab PHP packages. - Kolab_Filter-0.1.4-20090303 kolab/issue3192 (Forwarding an invitation with Outlook failed) kolab/issue3299 (Kolab_Filter: big.eml is too big) kolab/issue3364 (manpages for kolabfilter and kolabmailboxfilter) kolab/issue3426 (php error when sending mail with enabled mail filter checking) kolab/issue3441 (Resources with policy "always accept" do not work if domain != kolabhost) kolab/issue3435 (Delivery of invitations fails with no "kolabInvitationPolicy" in ldap) - Kolab_FreeBusy-0.1.2-20090226 kolab/issue3313 (free/busy regeneration as manager broken in 2.2.1-beta1) - Kolab_Server-0.4.0-20090224 New upstream release. Fixed objectClass evaluation to respect case-insensitivity (Horde bug: #7694) Fixed initialization of parameters retrieved from LDAP. Fixed addrsForIdOrMail to return only lowercased mail addresses (as mentioned in kolab/issue3426) Fixed notices when retrieving LDAP attributes. kolab/issue2207 (Make it possible to enable and disable users to be able to use the webclient) kolab/issue2546 (Horde should use name and email from ldap as defaults) - Kolab_Storage-0.4.0-20090224 New upstream release. Fixed list driver to prevent overwriting folder data when authenticating twice (relevant for testing). Allow to supress triggering (relevant for testing). - kolabd-2.2.1-20090304 Add a redirection for the newer horde install location. Add LDAP attribute postfix-message-size-limit and adjust main.cf.template to allow central configuration of the postfix parameter "message_size_limit". Add user attribute kolabHomeServerOnly to create user mailbox on the kolabHomeServer only. Add ldapserver_statedir to kolab.globals to fix kolab_bootstrap on slave servers. Add kolab_cafile to kolab.globals to specify filename for kolab_bootstrap to copy the generated CA certificate. Allow to configure resmgr and freebusy logging via dist_conf Updated doc/README.outlook for Kolab Server 2.2.1. kolab/issue1001 (/kolab/etc/kolab/workaround.sh expects manager password on command line) kolab/issue3331 (kolabfilter uses incorrect delivery backend) kolab/issue3322 (freebusy.conf.template: ldap server can be on another machine) kolab/issue3387 (dist_conf configuration in kolab webclient templates) kolab/issue3408 (Template for inclusion in shell scripts) kolab/issue3447 (Heavy information leak from webclient directories) - kolab-fbview-1.2.0-20081227 kolab/issue3318 (kolab-fbview-1.2.0-20081212 fails to compile on solaris 10) - kolab-webadmin-2.2.1-20090304 Improved Dutch translation. kolab/issue3404 (Present the options in "Action to take for messages that fail the check" nicer) - kolab-webclient-1.2.0-20090226 Fixed a potential IE XSS issue. Fixed handling of folder "owner" for shared user folders with Dovecot. Correct iTip option handling for dimp. kolab/issue2207 (Make it possible to enable and disable users to be able to use the webclient) kolab/issue2546 (Horde should use name and email from ldap as defaults) kolab/issue2738 (horde should allow a setting to suppress groupware folders) kolab/issue3309 (Can not login directly in to dimp) kolab/issue3318 (kolab-fbview-1.2.0-20081212 fails to compile on solaris 10) kolab/issue3328 ([Webclient] DIMP groupware folder names display bug) kolab/issue3329 ([WebClient] Can not accept/deny invitations in Dimp) kolab/issue3387 (dist_conf configuration in kolab webclient templates) kolab/issue3439 (FreeBusy display in web client and fbview depends on kolabHomeServer in LDAP) - PEAR-Horde-Channel-1.0-20090119 kolab/issue2441 (/kolab/RPM/TMP/pear/temp created owned by root) kolab/issue3315 (PEAR-Horde-Channel-1.0 fails to compile on solaris 10) - PEAR-PHPUnit-Channel-1.0-20090119 kolab/issue2441 (/kolab/RPM/TMP/pear/temp created owned by root) kolab/issue3315 (PEAR-Horde-Channel-1.0 fails to compile on solaris 10) - perl-kolab-2.2.1-20090304 Create user mailbox on the kolabHomeServer only, if attribute kolabHomeServerOnly is true. Continue sync if connecting the IMAP server fails, just skip actions that would need it. Improved the ssh handling for slave setups in kolab_bootstrap. Add retry (every minute for 10 times, then every five minutes until successful) to syncrepl configuration. kolab/issue3225 (Remove unused kolab_upgrade script) kolab/issue3321 (slapd.replicas.template and slapd.access.template can be absent) kolab/issue3355 (POD manpages for perl-kolab) kolab/issue3407 (kolab_bootstrap: improve message about importing the CA certificate) - perl-ldap-5.10.0-20081028_kolab1 New upstream version (perl-ldap 0.39) and two patches for syncrepl support, see kolab/issue1755 (syncrepl support (for OpenLDAP >=2.4.6)) - php-5.2.8-20081209_kolab2 Updated Kolab server patches. Packages in the OpenPKG based Kolab server release: - Kolab packages: Added: Horde_Notification-0.0.2-20090223 Horde_Prefs-0.0.3-20090223 Updated: Kolab_Filter-0.1.4-20090303 Kolab_FreeBusy-0.1.2-20090226 Kolab_Server-0.4.0-20090224 Kolab_Storage-0.4.0-20090224 PEAR-Horde-Channel-1.0-20090119 PEAR-PHPUnit-Channel-1.0-20090119 kolab-fbview-1.2.0-20081227 kolab-webadmin-2.2.1-20090304 kolab-webclient-1.2.0-20090226 kolabd-2.2.1-20090304 perl-kolab-2.2.1-20090304 perl-ldap-5.10.0-20081028_kolab1 Unchanged: Horde_Argv-0.1.0-20081209 Horde_Auth-0.1.1-20081209 Horde_Browser-0.0.2-20081209 Horde_CLI-0.0.2-20081209 Horde_Cache-0.0.2-20081209 Horde_Cipher-0.0.2-20081209 Horde_DOM-0.1.0-20081209 Horde_DataTree-0.0.3-20081209 Horde_Date-0.1.0-20081209 Horde_Framework-0.0.2-20081209 Horde_Group-0.1.0-20081209 Horde_History-0.0.2-20081209 Horde_LDAP-0.0.2-20081209 Horde_MIME-0.0.2-20081209 Horde_NLS-0.0.2-20081209 Horde_Perms-0.1.0-20081209 Horde_Secret-0.0.2-20081209 Horde_Serialize-0.0.2-20081209 Horde_SessionObjects-0.0.2-20081209 Horde_Util-0.1.0-20081209 Horde_iCalendar-0.1.0-20081209 Kolab_Format-1.0.0-20081212 PEAR-Auth_SASL-1.0.2-1 PEAR-Date-1.4.7-1 PEAR-HTTP_Request-1.4.3-1 PEAR-Log-1.11.2-1 PEAR-Mail-1.1.14-1 PEAR-Mail_mimeDecode-1.5.0-20081209 PEAR-Net_LMTP-1.0.1-1 PEAR-Net_SMTP-1.3.1-1 PEAR-Net_Socket-1.0.9-1 PEAR-Net_URL-1.0.15-1 PHPUnit-3.3.3-1 clamav-0.94.2-20081212 openldap-2.3.43-20081212 php-smarty-2.6.20-20081212 sqlite-3.6.4-20081212 - OpenPKG packages: Updated: apache-php-5.2.8-20081209_kolab2 imapd-2.3.13-20081020_kolab1 php-5.2.8-20081209_kolab2 Unchanged: amavisd-2.5.3-20080101 apache-2.2.10-20081111 apr-1.2.12-20080101 autoconf-2.61-20080101 automake-1.10-20080101 bc-1.06-20080101 binutils-2.18-20080101 bison-2.3-20080101 bzip2-1.0.5-20080318 config-20060923-20080101 curl-7.17.1-20080101 db-4.5.20.2-20070628 diffutils-2.8.7-20080101 expat-2.0.1-20080101 file-4.23-20080101 flex-2.5.34-20080101 freetype-2.3.5-20080101 fsl-1.7.0-20080101 gawk-3.1.6-20080101 gcc-4.2.2-20080101 gd-2.0.35-20080101 gettext-0.17-20080101 gmp-4.2.2-20080101_kolab grep-2.5.3-20080101 groff-1.19.2-20080101 gzip-1.3.12-20080101 imap-2006k-20080101 jpeg-6b-20080101 libiconv-1.12-20080101 libmcrypt-2.5.8-20080101 libxml-2.6.31-20080111 libxslt-1.1.22-20080101 lzo-2.02-20080101 m4-1.4.9-20080101 make-3.81-20080101 mhash-0.9.9-20080101 mm-1.4.2-20080101 ncurses-5.6.20080112-20080113 openpkg-20071227-20071227 openpkg-tools-1.4.6-20071231 openssl-0.9.8g-20080101 pcre-7.5-20080110 perl-5.10.0-20080103 perl-comp-5.10.0-20080110 perl-conv-5.10.0-20080101 perl-crypto-5.10.0-20080101 perl-db-5.10.0-20080118 perl-dns-5.10.0-20080101 perl-ds-5.10.0-20080104 perl-locale-5.10.0-20080112 perl-mail-5.10.0-20080117 perl-module-5.10.0-20080101 perl-net-5.10.0-20080101 perl-openpkg-5.10.0-20080109 perl-parse-5.10.0-20080117 perl-ssl-5.10.0-20080101 perl-stats-5.10.0-20080101 perl-sys-5.10.0-20080101 perl-term-5.10.0-20080116 perl-text-5.10.0-20080101 perl-time-5.10.0-20080101 perl-util-5.10.0-20080116 perl-www-5.10.0-20080103 perl-xml-5.10.0-20080101 pkgconfig-0.23-20080117 png-1.2.24-20080101 postfix-2.4.6-20080101_kolab procmail-3.22-20080101 readline-5.2.12-20080101 sasl-2.1.22-20080101 sed-4.1.5-20080101 spamassassin-3.2.4-20080107 texinfo-4.11-20080101 zlib-1.2.3-20080101 Changes between 2.2.0 and 2.2.1-beta-1 - apache-2.2.10-20081111 New upstream version, fixes various security issues. - apache-php-5.2.8-20081209_kolab New upstream version, fixes various security issues. Added sqlite2 support for SyncML support in kolab-webclient. - bzip2-1.0.5-20080318 New upstream version, fixes CVE-2008-1372 (denial of service) - clamav-0.94.2-20081212 New upstream version, fixes various security issues. kolab/issue765 (openpkg "junk" warnings) - gawk-3.1.6-20080101 New package, build (not runtime) dependency of sqlite. - gmp-4.2.2-20080101_kolab kolab/issue2928 (gmp-4.2.2-20080101 does not compile on Debian lenny/amd64) - Horde_iCalendar-0.1.0-20081209 kolab/issue3284 (Webclient or resmgr might send invitations that Outlook 2003 does not understand (unquoted CN with Umlauts)) - Kolab_Filter-0.1.3-20081212 A new package replacing kolab-filter (from http://pear.horde.org/index.php?package=Kolab_Filter) Added LDA (dovecot) backend. kolab/issue839 (problem when kolabHomeServer is missing) kolab/issue3074 (Freebusy trigger fails for other users's calenders.) kolab/issue3208 (Free/Busy list is always empty) kolab/issue3256 (resmgr responses should reflect server revision in PRODID) kolab/issue3260 (kolabfilter does not allow empty sender (and therefore MAILER-DAEMON)) kolab/issue3289 (resmgr dies when it should accept, but has not Calender folder access) - only partial fix - Kolab_Format-1.0.0-20081212 New package (from http://pear.horde.org/index.php?package=Kolab_Format) - Kolab_FreeBusy-0.1.2-20081212 A new package replacing kolab-freebusy (from http://pear.horde.org/index.php?package=Kolab_FreeBusy) Fixed handling of extended free/busy information. Fixed identification of the corresponding free/busy server. kolab/issue3208 (Free/Busy list is always empty) kolab/issue3256 (resmgr responses should reflect server revision in PRODID) - Kolab_Server-0.2.0.20081114-20081114 New package (from http://pear.horde.org/index.php?package=Kolab_Server) - Kolab_Storage-0.3.0-20081205 New package (from http://pear.horde.org/index.php?package=Kolab_Storage) - kolabd-2.2.1-20081212 Added configuration option in resmgr.conf for local delivery backend. (Makes it possible to activate the new LDA backend) Activated sqlite support in PHP. Updated the configuration for the newer Kolab_Filter package. kolab/issue765 (openpkg "junk" warnings) kolab/issue936 (kolabquotawarn: system cron used, and firing when server stopped) kolab/issue1310 (kolabquotawarn runs via cron before server was bootstrapped) kolab/issue1755 (syncrepl support (for OpenLDAP >=2.4.6)) kolab/issue2351 (horde doesn't present attachment stuff while compose a message) kolab/issue2440 (Installing binary packages of 2.2 fails without Horde) kolab/issue2446 (Make the used syslog facility configureable (kolabd, kolabconf)) kolab/issue2550 (kolabconf should make some others postfix maps) kolab/issue2910 (obsolete definition of schemacheck in slapd.conf) kolab/issue2911 (Change comments around the idletimeout definiton in the file templates/slapd.conf.template.in) kolab/issue2961 (added smtpd_sasl_authenticated_header = yes for simpler authorization) kolab/issue2994 (Duplicated kolab.conf files in cvs, one should be removed) kolab/issue3005 (Remove specific TLSCertificate code by using new bootstrap_config conditional in slapd.conf.template) kolab/issue3006 (Surround the horde schema include in slapd.conf.template with @@@ conditionals) Remark: this actually added only the code that allows to use @@@if exists(=2.4.6)) kolab/issue2981 (kolab_bootstrap: re-use kolabconf code to read the config file) kolab/issue3006 (Surround the horde schema include in slapd.conf.template with @@@ conditionals) Remark: this actually added only the code that allows to use @@@if exists( for forms in webadmin) kolab/issue1615 (Use